gmane.linux.ubuntu.devel

Ubuntu Server Team Meeting Minute 20120522

Serge Hallyn — 2012-05-23T21:23:52

Meeting started by s3h at 16:01:01 UTC.  The full logs are available at
http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-22-16.01.log.html
.

== Meeting summary ==

 *Review ACTION points from previous
''LINK:'' https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter   (Daviey, 16:04:06)
''LINK:'' https://blueprints.launchpad.net/~james-page/+specs?searchtext=servercloud-q&role=assignee   (Daviey, 16:04:12)
''LINK:'' https://blueprints.launchpad.net/~james-page/+specs?searchtext=servercloud-q&role=assignee   (s3h, 16:04:57)
''LINK:'' http://people.canonical.com/~davewalker/delta.html   (Daviey, 16:06:53)
''ACTION:'' zul talk to arosales and jamespage offline about SRU tracker  (s3h, 16:07:05)

 *Quantal Development

Specs currently under consideration are at https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter.  If a spec is missing, let Daviey know.

Blueprints which $user is responsible for driving to Approved state can be found at https://blueprints.launchpad.net/~$user/+specs?searchtext=servercloud-q&role=assignee.  Please set those which require review to Review state.

Daviey urges now is the time for frantic work on merges.  http://people.canonical.com/~davewalker/delta.html shows the delta with sid.

''ACTION:'' zul to also pull Ursinha into SRU tracker talks  (s3h, 16:08:28)

 *Ubuntu Server Team Events

 *Weekly Updates & Questions for the Kernel Team (smb)
''LINK:'' http://people.canonical.com/chucks/libvirt   (s3h, 16:29:37)

 *Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)

 *Open Discussion
''LINK:'' https://wiki.ubuntu.com/MainInclusionProcess and https://wiki.ubuntu.com/UbuntuMainInclusionRequirements should be reviewed by interested people  (jdstrand, 16:37:18)

There may be interest in having a server team member added to the MIR team.  The idea would be for the server team member to review desktop packages, and vice versa.  Interested server team members are urged to email arosales and Daviey.

''ACTION:'' email arosales/Daviey if interested in ubuntu-mir membership  (s3h, 16:38:20)
''ACTION:'' arosales to follow up with Ursinha on best approach for blueprint management this cycle  (s3h, 16:46:18)

 *Announce next meeting date and time

Tuesday May 29 at 1600 UTC.  right here.

Meeting ended at 16:51:06 UTC.



== Votes ==




== Action items ==

 * zul talk to arosales and jamespage offline about SRU tracker
 * zul to also pull Ursinha into SRU tracker talks
 * email arosales/Daviey if interested in ubuntu-mir membership
 * arosales to follow up with Ursinha on best approach for blueprint management this cycle



== Action items, by person ==

 * arosales
 ** zul talk to arosales and jamespage offline about SRU tracker
 ** email arosales/Daviey if interested in ubuntu-mir membership
 ** arosales to follow up with Ursinha on best approach for blueprint management this cycle
 * Daviey
 ** email arosales/Daviey if interested in ubuntu-mir membership
 * jamespage
 ** zul talk to arosales and jamespage offline about SRU tracker
 * Ursinha
 ** zul to also pull Ursinha into SRU tracker talks
 ** arosales to follow up with Ursinha on best approach for blueprint management this cycle
 * zul
 ** zul talk to arosales and jamespage offline about SRU tracker
 ** zul to also pull Ursinha into SRU tracker talks



== People present (lines said) ==

 * s3h (75)
 * SpamapS (56)
 * arosales (23)
 * zul (22)
 * Daviey (19)
 * jdstrand (16)
 * Ursinha (15)
 * rbasak (9)
 * jamespage (8)
 * smoser (7)
 * ubottu (7)
 * meetingology (7)
 * roaksoax (5)
 * smb (4)
 * hggdh (4)
 * jimbaker` (3)
 * m_3 (3)
 * lynxman (1)
 * utlemming (1)

Next Ubuntu Algorithm Classess

bdfhjk — 2012-05-23T17:39:48

Hello,

We have a monthly delay, because ACM ICPC (International Algorithm
Competition) was held in Poland and everyone were busy at that time.

Next classess will be held on 25.05 at 17:00 UTC (Time in your city
http://bit.ly/KLG8Lh), freenode IRC chat <http://webchat.freenode.net/> (
webchat.freenode.net), channel *#ubuntu-classroom*
Here is the link to notes:
https://docs.google.com/document/d/1Okbul4AIzQTR4CVGLcx-dmIXkdToNvLiJkIZurxNB8Q/edit



Marek Bardoński

Patch pilot report, 22/05/2012.

Luke Yelavich — 2012-05-23T06:44:45

Bug #1002909  sync mpqc - Synced.

Bug #1002885 merge lastfm - Wasn't really a merge, more a sync and fix FTBFs due to our glib.h change, so uploaded.

Bug 1002875 sync istanbul - Synced.

Bug 1002869 sync inspircd - Already synced.

lp:~logatron/ubuntu/quantal/netatalk/fix-for-992849 - The patch to fix a typo wasn't present in bzr, marked needs fixing.

lp:~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.march-merge2b - Needs fixing, using deprecated glib functions.

lp:~logatron/ubuntu/quantal/ac100-tarball-installer/fix-for-848188 - Uploaded

Patch pilot report 2012-05-22

Barry Warsaw — 2012-05-22T23:24:27

Patch pilot report 2012-05-22

* Reviewed python3 branch for software-properties
  https://code.launchpad.net/~glatzor/software-properties/python3/+merge/105755
  Needs Fixing

* Reviewed python-couchdb merge from Debian merge proposal:
  https://code.launchpad.net/~dmitrij.ledkov/ubuntu/quantal/python-couchdb/merge/+merge/104527
  Needs Fixing

* Reviewed, approved, and uploaded python-tz packaging merge that adds Python
  3 support:
  https://code.launchpad.net/~takluyver/ubuntu/quantal/python-tz/merge-py3/+merge/105551

* Reviewed landscape-client merge proposal:
  https://code.launchpad.net/~bkerensa/ubuntu/quantal/landscape-client/fix-for-962974/+merge/103843
  Suggested that the change be pushed to lp:landscape-client

* Sync'd canto 0.7.10-3 with Ubuntu delta for dh_python2.
  LP: #1002861

Cheers,
-Barry

dh_python2 and /usr/share/pyshared in quantal

Scott Kitterman — 2012-05-22T14:49:15

In https://launchpad.net/ubuntu/+source/python-defaults/2.7.3-0ubuntu3 Ubuntu 
modified dh_python2 to drop creation of /usr/share/pyshared and creation of 
python version specific symlinks to /usr/lib/python2.7/dist-packages/.

I believe this change should be reverted, but rather than just upload, wanted 
to discuss it first.  See https://bugs.launchpad.net/ubuntu/+source/python-
defaults/+bug/1001912 for additional discussion.

I've checked with Piotr Ożarowski (POX), the upstream developer for dh_python2 
and he does not support removing this feature of dh_python2 until after 
pysupport and pycentral are removed.  Even with a single supported python 
version (as Ubuntu has now) it's still useful because pysupport installs files 
in the same location.  It avoids some namespace issues.

This change breaks dozens of packages and has negligible (if any) advantages.

Additionally, the Python policy lists /usr/share/pyshared as the correct 
location to install version independent python files, so removing it moves away 
from the documented policy.

I'd like to understand if there's some compelling reason to make this change 
for quantal.  If not, it should be reverted sooner rather than later as 
packages built with this version are being misbuilt.

Scott K

Patch Pilot Report 20120521

James Page — 2012-05-21T17:10:21

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385
  - Review revised patch for quantal and uploaded alongside bug
https://pad.lv/1000678
  - Nominated for 12.04 - SRU information needs more work.
  - Worked with vibhav to prepare SRU information + uploaded to
precise-proposed.

https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/985981
  - Re-based to version in quantal and uploaded.

https://bugs.launchpad.net/ubuntu/+source/cfitsio3/+bug/1001572
  - Uploaded

https://code.launchpad.net/~kroq-gar78/ubuntu/precise/activemq/sid-merge/+merge/106539
  - Merge from Debian testing for SRU - not appropriate and not
correct either so pointed the proposer at the SRU process with some
general guidance - also commented in bug.

https://code.launchpad.net/~kroq-gar78/ubuntu/quantal/activemq/sid-merge/+merge/106540
  - Disapprove - package can now be synced from Debian testing -
however it FTBFS due to the switch to openjdk-7 as default Java in
Ubuntu only.
  - Synced the package instead with attribution to the proposer of
this merge - FTBFS due to Java 7 can be dealt with ontop of latest
Debian packaging changes.

< at >pilot out

Cheers

James

- -- 
James Page
Ubuntu Core Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPunb9AAoJEL/srsug59jDGEkP/icVhIsI1zloAJ1bUB1nIcVK
QbYYs+8jP8qfBjKxYVfBqZwmLusNEVOcb1J/PguJivhKrO32T3eqnxbP5BFgoZIC
0R73l/ggTQeqBLWhhtxh9oRCgxEa3Jy65MRtLAm+piXbEtYF43TFs0dkMnnstVl2
V54upEgg9bi8OARMxOtltCUCe4qDZWhw47dhNO/WjBPJmYPr8tp+fJygRkOZtM7G
7unJ+gwDv4QEVhdRBjsWCawnzU0C8qlrg44qnoz9db4g/u8QXfCZJXI/OjGKk49E
2sSntIE3UNjCLlZOuLl8NoTskLquItPaN2/GiPZ0vanujM7TGWwHEdnadeZREMEU
puELpr65HUkVdUq1fNGzVzmS864x1Jw3nDJI/dT5n00zR0ijxdfi/ObIol0aHy6+
xrxJsB9/PaBA/sq3nvUSHgyBZPR/oTrwolZVyeEd2Qn2sJxf4zYcyQ0pBTDfTiIC
q/AHfwUmzqh+MJrxBcnAbKV5xk5ycvlvorjeQGJ55/lfa5GPEZblnWBae4P1Cyxz
BYzkrq+xFxff5HZMNaIegO83QglSXO5vqi6Fs/8EVZORATp6izmbAAtbsR0KrZCV
wM7agUzbdvpxPAsE5LDcWUWKK1e1D9+EAz3bCotw3rHdI3pn7puSJLHLIEr0c3/Q
Zw3I/oO7kegWfkzkN+7F
=ID3Z
-----END PGP SIGNATURE-----

Improving the release notes for 12.10

Kate Stewart — 2012-05-18T19:05:57

Hi,
   With UDS just last week, why am I starting a note off about the
release notes for 12.10 you ask?  ;)    Because this is the time we're
all putting together our blueprints, and the best opportunity to get
some standardized formats in place,  so we can get a bit smarter about
generating our release notes for this upcoming cycle.  :D

   Historically the release notes are pulled together manually as we 
go through the cycle.  This tends to involve a lot of last minute
reminders and a bit of a scramble to get the editing and summarizing
done.   This cycle,  based on the discussions at UDS[1],  we'd like to
try something different:  basically using a standard section in the
blueprint to capture the release notes, and then automating them being
copied to the right products WIKI pages when the blueprint is marked
done.

   Some teams will also be experimenting this cycle with using even more
standardized format for the whiteboards in the blueprints[2],  of which
the "Release Notes:", section will be part of.  

   My request for 12.10, is that if you have a feature you're working
on,  that needs to go in the release notes for 12.10,   Please add a
"Release Notes:" section to the end of your blueprint whiteboard.  Once
the blueprint is approved, we'll be setting up the cross linkage from
the blueprint to the ReleaseNotes and TechnicalOverviews for 12.10 over
the next week ( using topic-quantal-XXXXX-release-notes blueprints), and
see if we can figure out some good patterns of automating that part next
time. ;)

   When the feature is complete,  and you're ready to make the release
note visible,  mark the blueprint done,  and the release note text will
be copied to the right places.

Thanks for your help with getting this prototyped.  :)   

Please let me know if you have questions. 

Kate

[1] https://blueprints.launchpad.net/ubuntu/+spec/other-q-release-notes
[2] https://wiki.ubuntu.com/BlueprintSpec

Apport API users: Watch your data types / Python 3 porting

Martin Pitt — 2012-05-18T14:41:09

Hello Ubuntu developers,

I just uploaded Apport 2.1 to Quantal. A big change in that version is
that the whole code now works with both Python 2 and 3, except for the
launchpadlib crash database backend (as we do not yet have a
python3-launchpadlib package).

I took some care that apport report objects get along with both
strings ("unicode" type in Python 2) and byte arrays ("str" type in
Python 2) in values, so most package hooks should still work. However,
now is the time to check whether they also work with Python 3, to make
the impending transition to Python 3 easier.

However, you need to watch out if you use projects or scripts which
directly use python-apport to process reports: The open(), write(),
and write_mime() methods now require the passed file descriptors to be
open in binary mode. You will get an exception otherwise.

A common pattern so far has been code like

  report = apport.Report()
  report.load(open('myfile.crash'))

This needs to be changed to

  report = apport.Report()
  with open('myfile.crash', 'rb') as f:
      report.load(f)

The "with" context is not strictly required, but it takes care of
timely closing the files again. This avoids ResourceWarning spew
when you run this in test suites or enable warnings.

Thanks,

Martin

Pilot Report 2012-05-17

Bryce Harrington — 2012-05-18T00:12:35

80 items at start, 70 (actually, 63) by end.

221112 keyboard-config: [SRU] Fix problem with space bar for fr(oss) keymap
  + Uploaded to quantal in 2.5-1ubuntu2
  + Filed SRU

825624 xkeyboard-config: [SRU] Add dead_hook and dead_horn to latin keymap
  + Uploaded to quantal in 2.5-1ubuntu2
  + Filed SRU

1000355 drbd8 - lucid sru
  + Already sponsored by timg-tpi; unsub sponsors

829819 balazarbrothers - spelling fix
  + Already accepted by Debian.  Too minor to diverge; disapproved branch

1000541 ia32-libs - Drop fluendo depends
  + Fix was uploaded for precise but not quantal
  + sponsored quantal upload 

994752 lxc
  + Already sponsored; unsub sponsors

quantal/emacs23/merge-23.4
  + Reviewed two branches from Laney, uploaded the second

1000557, 1000558, 1000560, 1000561 - texlive-* sync requests
  + sync'd

Branches needing set to Work In Progress:
 (I'm unable to set this for some reason; perhaps someone else could?)
 https://code.launchpad.net/~logatron/ubuntu/precise/xchat/fix-for-584207/+merge/102993
 https://code.launchpad.net/~kroq-gar78/ubuntu/precise/ubuntu-dev-tools/fix-988009/+merge/103595
 https://code.launchpad.net/~paolorotolo/rhythmbox/fix-for-991107/+merge/104368
 https://code.launchpad.net/~mitya57/app-install-data-ubuntu/unity-mail-fix/+merge/105514
 https://code.launchpad.net/~dmitrij.ledkov/ubuntu/quantal/bogl/merge/+merge/104578
 https://code.launchpad.net/~kroq-gar78/ubuntu/precise/dkms/fix-989998/+merge/103962
 https://code.launchpad.net/~bkerensa/ubuntu/precise/landscape-client/fix-for-962974/+merge/101839

Python 3 port of ubiquity

Colin Watson — 2012-05-17T17:51:05

I uploaded a Python 3 port of ubiquity today, which I've been dealing
with on and off for a while.  It was surprisingly easier than I
expected, although there were a few interesting roadblocks.  I mostly
embarked on this to get some practice in writing Python 3 code, with a
side order of thinking that it would be a good idea to attack the stack
of things to port from the top down rather than the bottom up, in case
any of the work became unnecessary as a result.

I'd done a Python 3 port before, namely germinate (assisted at the time
by http://python3porting.com/), so I had a rough idea of the sort of way
I find it useful to attack these problems.  In particular, my preference
is definitely to avoid using 2to3 except as a sort of first cut at a
to-do list.  A great deal of the problem can be demolished simply by
porting to a sufficiently modern Python 2 style first.

Thus, I started with a few old standbys: print function, 'except
Exception as value', module renamings, and so on.  To start with, I
found I could either guess randomly at common problems or run 2to3 in
its default report-only mode, find a single category of problem (for
instance, "map returns an iterator rather than a list"), grep for it
through the whole codebase, and think of a way to make all occurrences
valid in both Python 2 and 3.  After a while I got to the point where it
was worth adding --python2 and --python3 options to ubiquity's test
suite so that I could try both (the test runner re-execs itself, so I
couldn't just run it under different interpreters), and could continue
until the test suite passed.

A few specific notes on things I did in this stage:

 * The test suite used things like mock.patch("__builtin__.open").  I
   defined a helper like this:

     if sys.version >= '3':
         def builtin_patch(name):
             return mock.patch("builtins.%s" % name)
     else:
         def builtin_patch(name):
             return mock.patch("__builtin__.%s" % name)

 * gettext.install only takes unicode=1 (or unicode=True or whatever) in
   Python 2; that's unnecessary in Python 3.  The neatest approach I
   found was:

     kwargs = {}
     if sys.version < '3':
         kwargs['unicode'] = 1
     gettext.install(domain, LOCALEDIR, **kwargs)

 * If you're using python-apt, you *must* port entirely to the 0.8 API.
   python-apt tolerated this under Python 2, but the old API is compiled
   out under Python 3.  /usr/share/python-apt/migrate-0.8.py may be of
   some partial help.

 * It's probably not news to anyone that you have to get your binary vs.
   text data model solid when porting to Python 3.  There was one
   wrinkle I hadn't thought of, though.  ubiquity uses subprocesses
   quite a bit, and they return binary data by default.  Initially I
   tried .decode(), but after a while I realised that you can pass
   universal_newlines=True to subprocess.Popen (etc.) to get text output
   directly; this is much neater, works under both Python 2 and 3, even
   improves non-Unix support under Python 2 if you care ;-), and I
   recommend this approach.  There were a couple of exceptions in
   ubiquity, either where requiring straight-up binary data or where
   dealing with text that's potentially in mixed encodings indicated by
   field names.

 * Three-arg raise is particularly awful for compatibility, because the
   Python 2 form is an uncatchable SyntaxError in Python 3; you have to
   use exec() to work around this.  ubiquity only had one instance of
   this, so I used six.reraise().

 * pyflakes got upset with functions/methods defined two ways depending
   on sys.version, so I had to add some exclusions.

 * python-libxml2 hasn't been ported.  If you're currently using this,
   consider whether you can just use something in the standard library
   instead, rather than the larger python(3)-lxml.  I switched ubiquity
   over to xml.etree.cElementTree, and aside from the expected
   footprint-related virtues of using the stdlib, it actually ran faster
   in our case.

 * I had to port PyICU to get the test suite working.  This had been
   done upstream, but required packaging.

 * Be careful with what 2to3 says about list/iterator/view-related
   changes on dictionary methods and similar.  Its conservative approach
   is to add list() more or less everywhere, but if you're actually
   using .items() etc. only as an iterator, you can leave it as-is.
   Watch out for cases where you modify the dictionary while iterating
   over it, though; in that case you'll indeed need list().

 * I know others (including Barry) advocate 'from __future__ import
   unicode_literals'.  I found this a good approach in tests, but it
   makes me nervous in library code since it could easily end up
   changing your API.  I'd say only attempt this if you have
   exceptionally good test coverage.

Now, ubiquity's test suite isn't everything it might be, although I was
pleased to find that it got me most of the way.  However, I still had to
attack some frontend/backend glue code, and the KDE frontend is
currently untested (any volunteers?).  PyKDE4 had been ported upstream,
but required packaging; thanks to Philip Muškovac for reviewing and
uploading my patch there.  There were then a few other things to fix,
including calling sip.setapi("QVariant", 1) until I figure out what's
going on with the new QVariant API, and joyously discovering that most
bits of PyQt4 finally return ordinary Unicode strings in Python 3 rather
than messing about with QString objects.

But, finally, it all works at least in my tests.  I expect there'll be a
bit of shakedown time, but once things have settled I anticipate the
main benefit being that we stop having failures only in languages that
use non-ASCII characters, which has been a headache for us in the past.
I also expect to be able to drop the compatibility code once everything
is working and it's clear that we're past the point of no return in
using only Python 3 on the desktop image.

I definitely felt a tipping point here: once I'd ported a couple of
packages, my approach to subsequent ones has been to go through all the
changes I made for previous ports and duplicate each of them, which
really speeds things up.  Plus, of course, each library helps another
batch of packages.  Now that both GTK (via PyGI) and PyKDE are usable,
it should be possible to attack quite a few multiple-frontend programs
in Ubuntu; so please do!

qmake configured correctly for multiarch library directories?

Josh Stratton — 2012-05-16T06:33:50

I recently upgraded to 12.04 and now see two library directories on my
system, /usr/lib/ and /usr/lib/i386-linux-gnu. The former is about
30% bigger than the latter. When I switched to this new Ubuntu
version, my build started to break as qmake now links against
/usr/lib/i386-linux-gnu, so any libraries I were referencing residing
in /usr/lib are now missing. For example, I can include -lGL and
-lpython as they are both in /usr/lib/i386-linux-gnu, but when I
include -lassimp it fails as the build only includes this new
multiarch dir -L/usr/lib/i386-linux-gnu.

$ qmake-qt4 --version
QMake version 2.01a
Using Qt version 4.8.1 in /usr/lib/i386-linux-gnu

$ qmake -query
QT_INSTALL_PREFIX:/usr
QT_INSTALL_DATA:/usr/share/qt4
QT_INSTALL_DOCS:/usr/share/qt4/doc
QT_INSTALL_HEADERS:/usr/include/qt4
QT_INSTALL_LIBS:/usr/lib/i386-linux-gnu
QT_INSTALL_BINS:/usr/bin
QT_INSTALL_PLUGINS:/usr/lib/i386-linux-gnu/qt4/plugins
QT_INSTALL_IMPORTS:/usr/lib/qt4/imports
QT_INSTALL_TRANSLATIONS:/usr/share/qt4/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/lib/qt4/examples
QT_INSTALL_DEMOS:/usr/lib/qt4/demos
QMAKE_MKSPECS:/usr/share/qt4/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.1

I know there was a bit of work to get cmake compatible with the
multiarch specification, but haven't heard much about qmake, but I was
wondering if I really had to hardcode /usr/lib into my CXX flags. I
just want to know if this is the required configuration when using
qmake now or if there's something incorrect on my system and there's a
more elegant way to configure qmake system-wide to use both
directories...

so this...

g++ -L/usr/lib/i386-linux-gnu ...

looks like this...

g++ -L/usr/lib/i386-linux-gnu -L/usr/lib ...

I did find the following link, but it doesn't tell me much about what
happened in the transition.

http://wiki.debian.org/QtMultiarchTransition

I tried a hello-world example in cmake and saw the following output,
which seems to include both directories correctly.

CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
"/usr/lib/gcc/i686-linux-gnu/4.6;/usr/lib/i386-linux-gnu;/usr/lib;/lib/i386-linux-gnu;/lib")

However, in my hello-world example of qmake and my current project, I
get the following:

g++ -Wl,-O1 -o foo -L/usr/lib/i386-linux-gnu -lQtGui -lQtCore -lpthread

Like I said, the majority of my libraries are still in /usr/lib and
now qmake doesn't link against them by default. Is this a bug? Is
this just an accepted consequence of multiarch? Or is there something
I need to configure that wasn't handled properly in my upgrade?

PulseAudio 2.0 now available for testing for quantal.

Luke Yelavich — 2012-05-16T00:36:51

Hey folks,
PulseAudio 2.0 was recently released, and the audio team would like to get this into quantal at some point, but before we do, some testing is required to make sure things don't massively break. We don't believe they will, but its better to be sure.

PulseAudio 2.0 packages are available in the Ubuntu Audio dev PPA, https://launchpad.net/~ubuntu-audio-dev/+archive for quantal and precise. Precise packages are also available to help get increased testing coverage, as I am sure many of you are not yet running quantal.

If you find any regressions with PulseAudio 2.0, please file a bug against pulseaudio in launchpad, and clearly state in the bug subject that you are testing PulseAudio 2.0. Please also state whether you are running quantal or precise, just in case the bug is reproduceable on one, but not the other.

All being well, PulseAudio 2.0 will be uploaded to Quantal at the end of May, in time for alpha 1.

Thanks in advance.

Luke

event based initramfs

Phillip Susi — 2012-05-11T03:54:36

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was a bit confused when I saw this uds event.  It is unclear to me why we would want to add upstart to the initramfs.  I think it is important to remember that the the whole purpose of the initramfs is to help the kernel find the root fs, so things that aren't needed to access the root fs really shouldn't be there, lest it add bloat and slow down booting.  After listening to the audio of the session, it seems like there are a few issues people are trying to address with upstart in the initramfs:

1)  Want to fix bugs with mdadm/luks

I don't see what this has to do with upstart at all.  If your root is encrypted, then you must prompt for the password before you can continue, so there is no reason to do this event driven rather than procedural.  Luks volumes not mounted at boot should be handled by udisks or something that can interact with the desktop.  mdadm, dmraid, and lvm have already been converted to event driven and handled via udev and are done the same in both the initramfs and in the real system.  The criticism I have of the current system there is that they are automatically added to the initramfs when installed.  The multipath-tools package has a separate -boot flavor that handles copying the binaries and udev rules to the initramfs only if you require it to boot.  I think mdadm, dmraid, cryptsetup, and lvm
  should follow that same model to avoid adding things to the initramfs that aren't needed there.

2)  Want to get boot splash going asap

Wouldn't it be better to just get through the initrd faster, or skip it entirely ( as discussed at uds-p )?  If you're spending less than 2-3 seconds in the initrd anyhow, it seems counterproductive to make it larger/slower to display the splash screen now instead of after switching to the real root.

If there is still an appreciable time between the point where plymouth loads and where you can actually login where it might make sense to continue showing the splash screen instead of having X control the display, maybe we could let X initialize in the background and switch from the plymouth tty to the X tty only once it is ready for you to login.

3)  Want to do friendly recovery when the root fs can't be mounted

I'm not sure putting recovery in the initrd is worth the bother given the rather small number and rarity of failures that can prevent finding the root fs, but if you do want to do this, it certainly would need to be in an alternate initrd rather than bloating the primary initrd with significant weight that is not needed the vast majority of the time.  Rather than putting it in an initrd, it may make more sense just to have a separate recovery partition to boot instead of the usual root fs.

4)  Want to move mountall to initramfs to support separate /usr

This requires a copy of /etc/fstab in initramfs, and a flag to mountall to only mount / and /usr read-only, then exit.  I don't get why anyone would want /usr on a different filesystem in the first place and therefore, why we should spend effort on supporting this.  What does having upstart and mountall in the initramfs add to this, as opposed to just adding a second call to mount to the existing init scripts?  In the old days, the differentiation was that you could at least boot to single user mode and try to do some recovery without /usr.  What is it that we want to be able to do in rescue mode that requires things from /usr?  If there is a good case for having them in a rescue mode, then maybe they shouldn't be in /usr in the first place?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPrI18AAoJEJrBOlT6nu754BsIAMMZbgHgcJg94Xf9iLW7eVWs
YcJLkKpPeo8SUXuiF+IYYCVKhQPJPQled+gWD+Pw2ScmKesX8Q4GLO1zEUQqTsBa
QyqMXRAIuZYVfBicLbePZ6552+FM9v+S+386Be6C66hriv7/eFCd5fr1EqGmmMr2
354ulsEiLzwVQa/nuWicahOSh9GkHG8Z+sCbgIp1drhKR4rlxSYapdv+MUnDne6x
MHHKrSBjOgdmGbOOrDdTXkYgQSYxoYlEuDwToiyTxL7td+LNLVcm2e4KmKCcyU+7
i3Xv6oVEm7NO+YiVJUscI2tttxSQIuDZLNWVKGIxiWLZ4WM2KFlgBGY+kx4nFqM=
=By+t
-----END PGP SIGNATURE-----

Minutes from the Developer Membership Board meeting - 2012-05-09

Iain Lane — 2012-05-09T23:46:35

== Developer Membership Board meeting, 2012-05-09 ==

Chair: laney

Present: barry stgraber tumbleweed micahg bdrung

=== MOTU application Ante Karamatić ===

Application: https://wiki.ubuntu.com/AnteKaramatic/DeveloperApplicationMOTU

Voting: +1 barry tumbleweed micahg stgraber laney bdrung

The application is accepted.

Action: micahg to add permissions.

=== Per-Package uploader Ike Panhc ===

Application: https://wiki.ubuntu.com/IkePanhc/DeveloperApplication-PPU

Voting for linux-armadaxp, linux-meta-armadaxp, linux-highbank and
linux-meta-highbank (the latter two for discussion and approval on the mailing
list after the enter the archive)

Voting: +1 barry laney tumbleweed stgraber
        +0 micahg bdrung

The application is accepted.

ACTION: stgraber to add permissions

=== Per-Package uploader James Hunt ===

Application: https://wiki.ubuntu.com/JamesHunt/PPUApplication

Voting for friendly-recovery, libnih, mountall, upstart

Voting: +1 barry laney tumbleweed stgraber micahg bdrung

The application is accepted.

ACTION: stgraber to add permissions

=== AOB ===

Chair for next meeting: micahg

New mailing list for discussion of Arsenal

Bryce Harrington — 2012-05-08T16:50:05

(No, not the football team...)

Arsenal is our tool for creating listings of bug reports.  As per
yesterday's session at UDS, we've set up an open membership team and
mailing list for further discussion about development, installation, and
usage.

Join the team, and the mailing list here:

  https://launchpad.net/~arsenal-user

Arsenal is currently used by a bunch of teams across Ubuntu to help
do queries against Launchpad to track bugs and generate statistics.

Bryce

UDS-Q Architecture Preview

Allison Randal — 2012-05-08T00:49:50

Here's a little help putting the sea of UDS sessions into context (the
web version also has clickable links from topics to sessions
http://allisonrandal.com/2012/05/07/uds-q-architecture-preview/):

I’ve shuffled and reshuffled the sessions several times, looking for the
"governing dynamic", the thematic structure that holds the Quetzal
together. I’ve settled, appropriately, on "quantization". In general
terms, quantization is a process of separating a continuous stream into
significant values or "quanta", such as image pixels from the continuous
colors of real life, or discrete atomic energy levels. The theme applies
on multiple levels. First, there's the process attendees are going
through right now (in person or remote), surfing the sea of sessions,
determining how to divide their time for maximum value.

From a historical perspective, there was another UDS here in California
not too long ago, where I recall the schedule was dominated by the
desktop. We’re in a different world today, and what struck me reading
through blueprints for Quantal is the segmentation of topics. Ubuntu has
grown up, and while shipping a gorgeous desktop will always be
important, other forms of hardware, both smaller and larger, have an
equal and greater influence on Ubuntu's direction into the future. How
do you choose between cloud, metal, TV, and phones, when they're all so
interesting, and have so much potential as game-changers for Ubuntu (and
Linux in general)? These different domains of use also lead to
differentiation in design, development, and integration. Some
significant quanta to watch are:

    * Cloud: Juju (integration, charms, charm store, charm testing,
charm workflow, release process, with upstart, world tour), Open Stack
(roadmap, HA, ARM, charms, backporting, SRUs), Ubuntu Cloud images
(roundtable, cloud-init and cloud-utils, publishing), Eucalyptus, Xen, Ceph
    * Metal: MAAS ("metal as a service"), ARM server (enhancements,
deployment, benchmarking, storage), MySQL (round table, utilities), Open
Compute Project, libvert, Chef, XCP, OpenFlow, LXC, KVM, Hadoop,
PowerNap, btrfs
    * Client: mobile design, TV (control options, GStreamer, get
involved), cloud printing, hybrid graphics, USB video, Kubuntu (roadmap,
Active), backup enhancements, GNOME, Qt 5, X.org, Gwibber
    * Apps: developer experience, events, documentation, developer
portal, upstreams, promotion, Quickly

And like an atom that retains its fundamental structure at multiple
energy levels, Ubuntu is still Ubuntu, unified at the core as a
distribution and as a community, even across multiple "product" targets.
Since this is the first release after an LTS, there’s more room than
usual to re-examine the core at a fundamental level, with an eye to
where we want to be by the next LTS.

    * Intelligence: metrics, crash data (part 1, part 2), bug data
(Arsenal, automated triage agents, release importance, shadow database)
    * Precision: login speed, app startup time, +1 maintenance,
automated desktop testing (including LibreOffice, migrations, HDA sound
cards, kernel certification, harness), distributed hardware testing, ISO
testing, Checkbox
    * Scaling: apt at hyperscale (followup session TBA later in the
week), large application performance
    * Security: AppArmor (testing, development, integration), eCryptfs,
desktop lockdown
    * Leadership: summit, developer advisory team, code of conduct
review, LoCo portal, MOTU developer membership board
    * Process improvements: release (tech overview, meetings,
infrastructure, schedule and interlocks), use of -proposed, UDD,
third-party .debs, SRU process, archive admin API, archive reorg, phased
package updates, buildd usage

And those are only the highlights. :) It's going to be a great week, and
a great cycle!

Allison

Quantal: End of the line for i386 non-PAE

Tim Gardner — 2012-05-02T14:57:10

As decided by the Tech Board, 12.04 is the last release to have the i386
non-PAE kernel flavour. So, how do we upgrade folks ? IIRC a non-PAE
kernel was installed because 1) there was less then 4GB RAM, or 2) their
CPU did not have PAE support.

The folks in case 2 are simply out of luck (and no longer supported).

I have removed the non-PAE kernel meta package from Quantal that would
allow a non-PAE upgrade. Its likely that folks attempting an upgrade to
Quantal will be left with a Precise kernel.

Any ideas on how we might allow PAE capable CPUs to upgrade? Is this the
job of update-manager ? It seems likely that Debian must have
encountered this issue before.

rtg

Creating isos from PPAs

Chase Douglas — 2012-05-01T16:53:03

Hi all,

I would like to have a developer tool that allows for someone to spin an
ubuntu iso with a set of ppas enabled. Then someone else, say someone
from the design team, could run the iso under test drive or even on
metal to see the changes. I imagine this is possible, but I don't know
where to look. Any pointers would be appreciated.

Thanks!

Patch pilot report 2012-04-30

Colin Watson — 2012-04-30T22:48:36

I didn't get very much done this shift because I was mainly focusing on
opening quantal, but I didn't want to do no sponsoring at all this
month, so:

#990378: grub-ipxe: update-grub fragment inconsistent with other GRUB scripts' format
  Uploaded.

#990983: This wil enable the use memcache support what was not working and this wil close ubuntu bug 987404  Summary (one line): Sync mod-gnutls 0.5.10-1.1 (universe) from Debian sid (main)
  Offered SRU advice.

#978228: Multiarch support for libpaper
  Suggested NMUing to Debian and we can sync, since the maintainer said
  that would be OK.

#988984: [SRU] Clustered VGs require monitoring to be turned on
  Uploaded to quantal and precise-proposed; but the latter clashed with
  an existing SRU, so asked for tidy-ups.

#927828: sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed.
  Uploaded to quantal and precise-proposed.

lp:~yofel/software-properties/lp-944876
  Already uploaded to precise-proposed; marked as merged.

THANKS

Daniel Holbach — 2012-04-30T10:28:38

Hello everybody,

I've been completely overwhelmed by the general reactions to the Ubuntu
12.04 release. It's clear that this was the best Ubuntu release ever.

To get a feel for how people love the work you've all been doing, check out

https://twitter.com/#!/ubuntudev

where I just retweeted a few of the incoming messages of praise and thanks.

Keep up the good work everyone!

Have a great day,
 Daniel

Considering removing flags export from dpkg-buildpackage for quantal

Colin Watson — 2012-04-28T00:39:54

On #ubuntu-release today we've been discussing the possibility of
removing our hack from dpkg-buildpackage that exports the default output
of dpkg-buildflags in the environment.  This was an ugly hack to start
with, and some months ago we had to make it even more ugly temporarily
(https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034351.html),
but on the general understanding that we would revert the whole lot
after 12.04 and start relying on dpkg-buildflags.

The effects of this change require some analysis; they were certainly
not obvious to me.  Many of the default flags set by dpkg-buildflags are
in fact already the defaults in Ubuntu's compiler:

  -fstack-protector --param=ssp-buffer-size=4
  -D_FORTIFY_SOURCE=2
  -Wformat -Wformat-security
  -Wl,-z,relro

-Werror=format-security is output by dpkg-buildflags, but we filter that
out in the dpkg-buildpackage export hack at the moment to avoid causing
lots of build failures in unsuspecting packages.

The last remaining issue for default builds is therefore
-Wl,-Bsymbolic-functions.  This is subtle: we use it (IIRC) as a
performance improvement for shared libraries, and I wouldn't like that
to regress.  It's not trivial to detect whether a library has been built
that way, but after some fiddling I noticed that it shows up in the
output of 'objdump -R': a library built with -Wl,-Bsymbolic-functions
has more entries there.

I'm therefore currently building all of precise/main in a couple of
amd64 cloud instances with our hack removed from dpkg-buildpackage in
the build chroot, with the intention of checking for any build failures,
but also of extracting all the resulting shared libraries, running
'objdump -R' over them, and comparing against the corresponding shared
libraries in the archive.  That should give us a general idea of how
much work it will be to ensure that all shared libraries continue to be
built with -Wl,-Bsymbolic-functions (except where that had already been
disabled for one reason or another).  I hope to be able to report on
this after the weekend.

The other likely effect of removing this export hack is that putting
hardening options in DEB_BUILD_OPTIONS might start working differently.
However, this only affects local builds, and it can be fixed by
modifying packages to support dpkg-buildflags correctly.  This is a
release goal for wheezy
(http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags), so
it's reasonable to expect Debian package maintainers to take patches for
this.

Any other comments?