gmane.linux.ubuntu.devel

Re: syncing from testing? [was: Quantal open for development]

Steve Langasek — 2012-05-24T15:43:08

Hi Colin,

On Thu, May 24, 2012 at 11:23:08AM +0100, Colin Watson wrote:

To date I'm only aware that we've discussed using testing migration scripts
to ensure archive installability; our reasons for pulling from testing for
the LTS have generally had more to do with the other main aspect of testing,
namely the filtering out of release-critical bugs.  Do you foresee us doing
that kind of RC bug tracking as part of -proposed migration?

If not - and I hope not ;) - I think it will still to our advantage to track
testing for the RC bug gauntlet aspect.

Cheers,

Re: syncing from testing? [was: Quantal open for development]

Scott Kitterman — 2012-05-24T10:28:55


Colin Watson <cjwatson< at >ubuntu.com> wrote:


Thanks for the follow-up.

Where can I read about this plan for our own version of a Testing migration?

Scott K

Re: syncing from testing? [was: Quantal open for development]

Colin Watson — 2012-05-24T10:23:08

Sorry I'm late in following up on this.

The general consensus at UDS was indeed largely as you say: we should
sync from unstable for non-LTS by default, and we agreed to switch to
unstable for this cycle.  I will try to remember to not have this debate
in future non-LTS cycles. :-)

Actually implementing this for quantal was blocked on some toolchain
work on ARM which we wanted to take the opportunity to complete before
doing another pile of syncs, but Adam told me this morning that this was
complete.  I've dug myself into a little bit of a hole by telling
Launchpad that quantal's parent series is wheezy, but I'm in the process
of hacking my way around that in the auto-sync script.  I expect to do
an initial auto-sync from unstable later today.

There remains some question about what to do with future LTS cycles.
Depending on the progress of work on running our own equivalent of
Debian's testing migration (which I seriously hope will be complete by
T, given that it's currently scheduled for quantal!), it's quite
possible that we'll reach the point where syncing from testing merely
introduces an extra source of delay and risk, rather than being a useful
protection.  However, I don't think we can answer that question until we
have some practical experience with running our own migration scripts.

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

Re: dh_python2 and /usr/share/pyshared in quantal

Barry Warsaw — 2012-05-23T02:57:21


Before you do this, I think some groundwork needs to be laid.  First, you need
to get general consensus that eradication of pyshared is a goal to be
achieved.  You don't need (and won't get) 100% consensus, but I think you need
the majority of developers to agree that this is a goal, and to commit to
helping make this happen.  The debian-python mailing list is the right place
to have this discussion.  Without consensus, bugs will just get Won't Fixed
and/or Ubuntu will just carry even more deltas from Debian, which I think we
all agree is not good.

(Take the dh_python2 transition as a model.  We didn't get - and still don't
have - 100% agreement about it, but we got a majority of developers to agree
that it was the right thing to do, and with official deprecation of
python-central and python-support, it became the defacto standard helper for
Python 2.  These facts can be used in bug reports, patches, wiki pages, and
other means of communication to rally developers around the transition.
Ubuntu can still lead, but it makes it easier to push patches back to Debian,
with reasonable justification, so that you only have to route around the small
number of holdouts.  And yes, we decided that it was important enough for us
to carry deltas and pay the ongoing cost for those holdouts.)

Part of that consensus must include appropriate updates to python-policy so
that we have documented best practices that other developers can refer to.
Also, you need transition guidelines so that developers who want to conform to
the new standards know what changes to make to their packages.  This
information is also useful to contributors who want to help with the
transition.

(We had *a lot* of external contributions for the dh_python2 transition, and
having a wiki page with very clear instructions was immensely helpful for
everyone involved.)

Once consensus is reached, I think you also need a plan for achieving the
goal.  Just breaking packages isn't good enough because the people who will
suffer will be our users, who probably can't fix the problem themselves.  How
will violations be tracked?  Will you just leave it up to users to file bugs?
How to be sure that those bugs are appropriately triaged to be caused by
pyshared import violations?  What's the plan for getting those fixed?  Again,
even if you can find 100% of those violations, you need a way to follow up to
make sure the change doesn't just result in a stack of bugs that never get
looked at or fixed.

Can you use a less drastic strategy for achieving your goal?  If prohibiting
pyshared imports really is the only way, I'd definitely want to do a code
review on the implementation, just to be sure it doesn't have unintended
side-effects.

So maybe this doesn't affect nearly as many packages, but I still think you
need a little more planning before taking the hard-line step of prohibiting
imports.

Cheers,
-Barry

Re: dh_python2 and /usr/share/pyshared in quantal

Micah Gersten — 2012-05-23T02:14:23

That would probably work too :)

Micah

Re: dh_python2 and /usr/share/pyshared in quantal

Scott Kitterman — 2012-05-23T02:12:44

Of the four packages on the list that I've touched, none of them do that.  In 
one of them, python-qt4, debian/rules only mentions pyshared to remove empty 
directories left there.  It's an artifact of the way the build system works, 
not a bug related to sys.path.

Scott K

Re: dh_python2 and /usr/share/pyshared in quantal

Scott Kitterman — 2012-05-23T02:10:09

Next time you decide to gratuitously break things, please have some discussion 
of it first.

Scott K

Re: dh_python2 and /usr/share/pyshared in quantal

Stefano Rivera — 2012-05-23T02:07:23

Hi Micah (2012.05.23_04:02:36_+0200)

I'd have thought a grep through the lintian lab would be sufficient?

SR

Re: dh_python2 and /usr/share/pyshared in quantal

Micah Gersten — 2012-05-23T02:02:36

An i386 rebuild should be sufficient for this.  As the builders have
been mostly idle and a rebuild on i386 should be done before alpha1
week, maybe now is a good time?

Re: dh_python2 and /usr/share/pyshared in quantal

Matthias Klose — 2012-05-23T01:54:07

no, not that excellent. For larger changes we do these changes in the archive,
like the glib header changes during the late precise cycle, which can but have
not to be reverted later.


again, any use of pyshared in sys.path is a bug.

  Matthias

Re: dh_python2 and /usr/share/pyshared in quantal

Matthias Klose — 2012-05-23T01:49:07

that is plain wrong. pyshared *is* an implementation detail for the working of
the package. Every package having pyshared on sys.path for testing, building,
installation is buggy.

So i'll modify the interpreter do disallow imports from pyshared to catch
exactly these misuses.



no, it's not about that.


Again, no. Debian probably will only start such things after their next release,
so it's legitimate to go ahead witch changes for 28 packages.

thanks, Matthias

PS: Scott, if you choose to move a discussion from a bug report to a ML, please
mention this in the bug report next time.

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

Re: Quantal open for development

Stefano Rivera — 2012-05-22T22:43:24

Hi Colin (2012.05.22_14:30:57_+0200)

Thanks.

Now that that's back, here's a list of the packages that haven't been
merged in a long time:

http://qa.ubuntuwire.org/oldmerges/

Now that it's the beginning of a new LTS cycle, it's a great time to go
and do those scary merges that nobody else dares to. :)

You probably want to sort by the superseded column. You can see who last
touched a package by hovering over the Uploaded column.

Note that a couple of the packages near the top of that list (like
configure-debian) have odd version numbers, and don't actually have
anything to be done.

SR

Re: dh_python2 and /usr/share/pyshared in quantal

Barry Warsaw — 2012-05-22T19:32:45


+1

-Barry

Re: dh_python2 and /usr/share/pyshared in quantal

Scott Kitterman — 2012-05-22T19:21:10

My hope (as one of the Python policy authors) is to eventually divorce the 
policy from any implementation specifics.  To the extent implementation specific 
details of pysupport or pycentral are mentioned, I consider them historical 
warts to be gotten rid of as soon as we can.

Scott K

P.S. re the other message - understand about the reverse engineering.

Re: dh_python2 and /usr/share/pyshared in quantal

Barry Warsaw — 2012-05-22T18:50:45


This is a really excellent point.


Fair enough.

-Barry

Re: dh_python2 and /usr/share/pyshared in quantal

Barry Warsaw — 2012-05-22T18:49:53

Just to be clear, I was mostly trying to reverse engineer the rationale for
the change, not defend it.  I agree with the decision to revert it.

On May 22, 2012, at 11:42 AM, Scott Kitterman wrote:


Thanks for the explanation.


Actually, I read python-policy as being a bit ambiguous here.  To me, it
clearly says pyshared is the location for source code common for multiple
Python (2) versions, but I think it's less than clear that this also applies
to non-code common files.

The other two hits for 'pyshared' in python-policy.txt are in the deprecated
python-support and python-central sections, so might be misconstrued as being
implementation details of those helpers respectively (there's no mention of it
in the dh_python2/3 section).


Agreed, and the debian-python list is probably a better place to discuss the
nuances of Python policy.

Cheers,
-Barry

Re: dh_python2 and /usr/share/pyshared in quantal

Sebastien Bacher — 2012-05-22T17:22:39

Le 22/05/2012 17:33, Barry Warsaw a écrit :
Hey,

Do we really need to break the archive version to figure those out, 
can't we do an archive rebuild of some way using a custom or ppa build?

Sebastien Bacher