[00:03] <bkerensa> mhall119: I'm digging the new scopes... But tell me the preview scope left-click bit is a bug?
[00:35] <mhall119> bkerensa: I think it was design to make previews more discoverable and usable on touch (where you don't have right-click)
[00:35] <mhall119> I don't know if this is the final design though
[00:35] <bkerensa> mhall119: Hmm I know there is a bug open for it but I was wondering if it really was a bug
[00:36] <bkerensa> mhall119: can the preview be toggled off? It adds an extra click to open anything ;/
[00:36] <mhall119> bkerensa: I don't know the details of the new API yet, sorry
[11:08] <daker> maybe you have to check this http://instantserver.io/ free ubuntu server instance for 30min :)
[22:05] <bkerensa> Ubuntu XPS 13 no longer available online ;/
[22:05] <bkerensa> ofc right after I get a Dell Preferred Acct
[22:43] <TheLordOfTime> i don't think they've offered any Ubuntu systems lately, i'd have seen the announcement already
[22:43]  * TheLordOfTime has a dell preferred account
[22:43] <TheLordOfTime> but that might be specific to a region


[00:02] <slangasek> cyphermox: let's see
[00:03] <slangasek> cyphermox: I don't want to review the shell code; you've tested this?
[00:07] <slangasek> cyphermox: there's still a 'ROUNDTTT' outer loop here, isn't there?  Do we not care that DEVICE= is modified after the first loop?
[00:09] <slangasek> of course, the ROUNDTTT variable isn't being used in the dhclient case, either
[00:12] -queuebot:#ubuntu-release- Unapproved: gnome-terminal (yakkety-proposed/main) [3.20.2-1ubuntu3 => 3.20.2-1ubuntu4] (ubuntu-desktop)
[00:16] <cyphermox> well, it could be if things are failing, but then DEVICE will be reset too.
[00:16] <cyphermox> I tested it here for both xenial and yakkety with rootfs on iscsi
[00:26] <slangasek> cyphermox: ah indeed, it does reset on the next loop
[00:27] <slangasek> ok lgtm
[00:28] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu5]
[00:59] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.3]
[01:13] -queuebot:#ubuntu-release- Unapproved: brltty (yakkety-proposed/main) [5.4-0ubuntu3 => 5.4-0ubuntu4] (core)
[01:27] -queuebot:#ubuntu-release- Unapproved: cloud-utils (yakkety-proposed/main) [0.29-0ubuntu3 => 0.29-0ubuntu4] (edubuntu, ubuntu-server)
[01:45] -queuebot:#ubuntu-release- Unapproved: witty (yakkety-proposed/universe) [3.3.5+dfsg-1ubuntu1 => 3.3.5+dfsg-1ubuntu2] (no packageset)
[01:46] -queuebot:#ubuntu-release- Unapproved: accepted witty [source] (yakkety-proposed) [3.3.5+dfsg-1ubuntu2]
[01:50] -queuebot:#ubuntu-release- Unapproved: netatalk (yakkety-proposed/universe) [2.2.5-1 => 2.2.5-1ubuntu1] (no packageset)
[01:51] -queuebot:#ubuntu-release- Unapproved: accepted netatalk [source] (yakkety-proposed) [2.2.5-1ubuntu1]
[02:16] -queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160922-0ubuntu1 => 0.1.1+16.10.20160926.1-0ubuntu1] (no packageset) (sync)
[02:17] -queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20160926.1-0ubuntu1]
[03:02] -queuebot:#ubuntu-release- New source: ubuntu-terminal-app (yakkety-proposed/primary) [0.7.216]
[03:25] <slangasek> wxl: your guided install test still in progress on i386?
[03:26] <wxl> slangasek: yeah. just got home. had to go to a shindig while it was still running
[03:30] <slangasek> wxl: ok.  I think that's the only outstanding test at the moment; once that's done, assuming success are you happy for us to publish?
[03:31] <wxl> slangasek: probably. if there's something wrong with the notes, it should be minor and readily resolved
[03:54] -queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been marked as ready
[03:54] -queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been marked as ready
[04:11] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [ppc64el] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:12] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [amd64] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:12] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [armhf] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:12] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [arm64] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:12] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [i386] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:13] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-1 => 10.2.7-2] (no packageset) (sync)
[04:13] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-2]
[04:16] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [s390x] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[04:55] -queuebot:#ubuntu-release- Unapproved: libfilezilla (yakkety-proposed/universe) [0.6.1-1 => 0.7.0-1] (no packageset) (sync)
[04:55] -queuebot:#ubuntu-release- Unapproved: python-schema (yakkety-proposed/universe) [0.6.2-1 => 0.6.5-1] (no packageset) (sync)
[04:55] -queuebot:#ubuntu-release- Unapproved: accepted libfilezilla [sync] (yakkety-proposed) [0.7.0-1]
[04:55] -queuebot:#ubuntu-release- Unapproved: lbfgsb (yakkety-proposed/universe) [3.0+dfsg.2-1 => 3.0+dfsg.3-1] (no packageset) (sync)
[04:55] -queuebot:#ubuntu-release- Unapproved: accepted python-schema [sync] (yakkety-proposed) [0.6.5-1]
[04:55] -queuebot:#ubuntu-release- Unapproved: netqmail (yakkety-proposed/universe) [1.06-5 => 1.06-6] (no packageset) (sync)
[04:56] -queuebot:#ubuntu-release- Unapproved: libcypher-parser (yakkety-proposed/universe) [0.5.1-1 => 0.5.2-1] (no packageset) (sync)
[04:56] -queuebot:#ubuntu-release- Unapproved: accepted lbfgsb [sync] (yakkety-proposed) [3.0+dfsg.3-1]
[04:56] -queuebot:#ubuntu-release- Unapproved: accepted netqmail [sync] (yakkety-proposed) [1.06-6]
[04:56] -queuebot:#ubuntu-release- Unapproved: accepted libcypher-parser [sync] (yakkety-proposed) [0.5.2-1]
[05:10] -queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src-gles (yakkety-proposed/universe) [5.6.1-7ubuntu1~2 => 5.6.1-7ubuntu2~1] (no packageset) (sync)
[05:10] -queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (yakkety-proposed/main) [5.6.1-7ubuntu1~2 => 5.6.1-7ubuntu2~1] (kubuntu, qt5, ubuntu-desktop) (sync)
[05:11] -queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src-gles [sync] (yakkety-proposed) [5.6.1-7ubuntu2~1]
[06:04] -queuebot:#ubuntu-release- Unapproved: sofia-sip (yakkety-proposed/universe) [1.12.11+20110422.1-2ubuntu1 => 1.12.11+20110422.1-2.1] (no packageset) (sync)
[06:05] -queuebot:#ubuntu-release- Unapproved: accepted sofia-sip [sync] (yakkety-proposed) [1.12.11+20110422.1-2.1]
[06:06] -queuebot:#ubuntu-release- Unapproved: evolution-rss (yakkety-proposed/universe) [0.3.95-5ubuntu1 => 0.3.95-6] (no packageset) (sync)
[06:06] -queuebot:#ubuntu-release- Unapproved: accepted evolution-rss [sync] (yakkety-proposed) [0.3.95-6]
[06:24] <flocculant> slangasek: I bet you're glad to have said that :)
[06:24] <flocculant> thanks
[06:24] <slangasek> yep, bedtime now ;)
[06:24] -queuebot:#ubuntu-release- Unapproved: doona (yakkety-proposed/universe) [0.7+git20131211-1 => 1.0+git20160212-1] (no packageset) (sync)
[06:25] <flocculant> sleep the sleep of the righteous :)
[06:25] -queuebot:#ubuntu-release- Unapproved: accepted doona [sync] (yakkety-proposed) [1.0+git20160212-1]
[06:26] -queuebot:#ubuntu-release- Unapproved: arp-scan (yakkety-proposed/universe) [1.8.1-2ubuntu1 => 1.9-1] (no packageset) (sync)
[06:26] -queuebot:#ubuntu-release- Unapproved: accepted arp-scan [sync] (yakkety-proposed) [1.9-1]
[06:43] -queuebot:#ubuntu-release- New binary: kactivities-kf5 [powerpc] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
[06:44] -queuebot:#ubuntu-release- Unapproved: filezilla (yakkety-proposed/universe) [3.20.0-1ubuntu2 => 3.21.0-2ubuntu1] (no packageset)
[06:45] -queuebot:#ubuntu-release- Unapproved: accepted filezilla [source] (yakkety-proposed) [3.21.0-2ubuntu1]
[06:47] -queuebot:#ubuntu-release- Builds: 34 entries have been added, updated or disabled
[07:09] <pitti> slangasek: congrats!
[07:10] <pitti> slangasek: I *knew* there was something fishy when nothing came up last Wednesday :/
[07:23] <acheronuk> can someone accept kjsembed in the queue? that is a blocker on plasma desktop bugfix updates building on armhf
[07:24]  * acheronuk cheers for beta release. good job
[07:28] <flocculant> pitti: running out of time here before work, but when you did http://changelogs.ubuntu.com/changelogs/pool/universe/x/xubuntu-default-settings/xubuntu-default-settings_16.10.1/changelog did something similar happen to Ubuntu - ref the bugs on https://lists.ubuntu.com/archives/ubuntu-release/2016-September/003908.html
[07:29] <flocculant> because if I go back to before that change - locking works and so does the guest session
[07:29] <flocculant> bbl
[07:29] <pitti> slangasek: will you deal with dropping the beta-2 block hints, or want me to?
[07:30] <pitti> flocculant: will have a look
[07:30] <flocculant> pitti: thanks :)
[07:36] <jamespage> hi release team - I synced a NEW package from debian experimental yesterday - networking-sfc - needed for the new version of vmware-nsx which is compat with openstack newton
[07:36] <jamespage> if it could be accepted that would unblock my upload for vmware-nsx
[07:36] <jamespage> cheers
[08:02] <jamespage> cpaelzer, ovs 2.6.0 is released
[08:02]  * jamespage works that now
[08:03] -queuebot:#ubuntu-release- Unapproved: networking-ovn (yakkety-proposed/universe) [1.0.0~rc1-0ubuntu1 => 1.0.0~rc2-0ubuntu1] (no packageset)
[08:03] -queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (yakkety-proposed) [1.0.0~rc2-0ubuntu1]
[08:04] <cpaelzer> thanks jamespage
[08:11] -queuebot:#ubuntu-release- Unapproved: ifstat (yakkety-proposed/universe) [1.1-8build1 => 1.1-8.1] (no packageset) (sync)
[08:11] -queuebot:#ubuntu-release- Unapproved: accepted ifstat [sync] (yakkety-proposed) [1.1-8.1]
[08:33] <pitti> Laney: I suppose slangasek went straight to a well-deserved sleep after sending the announcement; do you know a reason to not unblock?
[08:34] -queuebot:#ubuntu-release- New: accepted networking-sfc [sync] (yakkety-proposed) [2.0.1~git20160926.27f311e-1]
[08:35] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [sync] (yakkety-proposed) [0.3-1]
[08:36] <pitti> jamespage: done
[08:36] <jamespage> pitti, thanks!
[08:36] <Laney> pitti: I don't; we would normally do that at the same time as releasing (or when it becomes clear there will be no more respins)
[08:36] <pitti> jamespage: it'll hit binNEW again, so if I forget, please prod me again
[08:36] <jamespage> willdo
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [amd64] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [armhf] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [powerpc] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [s390x] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [arm64] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [ppc64el] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] <Laney> I forgot exactly when we put a full britney block in though
[08:36] -queuebot:#ubuntu-release- New: accepted kactivities-kf5 [i386] (yakkety-proposed) [5.26.0-0ubuntu1]
[08:36] <Laney> Might be worth doing some archaeology to find out when we did that last cycle (I think later on)
[08:37] <pitti> Laney: ok; there's a metric ton of stuff that's ready, and it woudl help to clean up to figure out what's wrong with the rest of it
[08:37] <pitti> imestamp: Thu 2016-08-25 23:05:47 +0100
[08:37] <Laney> timestamp: Tue 2016-04-19 21:31:30 +0100
[08:37] <Laney> message: Add block for xenial final
[08:37] <pitti> message:
[08:37] <pitti>   Drop beta 1 freeze
[08:37] <Laney> ok
[08:37] <pitti> Thursday evening, that sounds pretty much like "after release"
[08:37] <Laney> i'll do it
[08:37] <pitti> Laney: cheers
[08:38] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [ppc64el] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:38] <Laney> As long as we can take the blame together. :P
[08:38]  * pitti looks at the rest of NEW
[08:38] <Laney> (done)
[08:38] <pitti> Laney: I'll take the bullet :)
[08:38] <Laney> I want to finish up gnome-keyring/upstart/unity-lens-applications and then will take a blast through the queue
[08:39] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [amd64] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:39] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [i386] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:39] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [sync] (yakkety-proposed) [5.6.1-1]
[08:40] -queuebot:#ubuntu-release- New: accepted mcloud [sync] (yakkety-proposed) [1.0.0+16.10.20160927.3-0ubuntu1]
[08:40] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [arm64] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:41] -queuebot:#ubuntu-release- New binary: networking-sfc [amd64] (yakkety-proposed/none) [2.0.1~git20160926.27f311e-1] (no packageset)
[08:41] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [armhf] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:43] <pitti> flocculant: looks like that bug already has the necessary apparmor profile update?
[08:44] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [ppc64el] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:44] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [i386] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:45] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [amd64] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:46] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [arm64] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:46] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [armhf] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:47] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [s390x] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [amd64] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [armhf] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [ppc64el] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [s390x] (yakkety-proposed/none) [5.6.1-1] (no packageset)
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [arm64] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [s390x] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [i386] (yakkety-proposed) [0.3-1]
[08:48] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [powerpc] (yakkety-proposed/none) [0.3-1] (no packageset)
[08:48] -queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [powerpc] (yakkety-proposed) [0.3-1]
[08:57] -queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [powerpc] (yakkety-proposed/universe) [5.6.1-1] (no packageset)
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [amd64] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [armhf] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [powerpc] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [s390x] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [arm64] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [ppc64el] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [i386] (yakkety-proposed) [5.6.1-1]
[08:59] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [source] (yakkety-proposed) [0.7.216]
[09:00] <pitti> jamespage: meh, new python2 packages? without a py3 one?
[09:00] <pitti> (sfc-networking)
[09:00] <jamespage> pitti, its a constraint due to the fact that neutron is not quite there yet with py3
[09:00] <jamespage> next cycle there is a cross project objective to get to py3
[09:00] <jamespage> so it might actually happen...
[09:01] -queuebot:#ubuntu-release- New: accepted networking-sfc [amd64] (yakkety-proposed) [2.0.1~git20160926.27f311e-1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted gnome-getting-started-docs [source] (yakkety-proposed) [3.22.0-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted gtkimageview [sync] (yakkety-proposed) [1.6.4+dfsg-1.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted qqwing [sync] (yakkety-proposed) [1.3.4-1.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted media-hub [sync] (yakkety-proposed) [4.6.0+16.10.20160909-0ubuntu1]
[09:03] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [ppc64el] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:04] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [amd64] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:04] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [i386] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:04] -queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (yakkety-proposed) [1.8.7-1ubuntu8]
[09:04] -queuebot:#ubuntu-release- Unapproved: accepted eigen3 [source] (yakkety-proposed) [3.3~beta2-2ubuntu2]
[09:05] -queuebot:#ubuntu-release- Unapproved: accepted murano [sync] (yakkety-proposed) [1:3.0.0~rc1-1]
[09:06] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [arm64] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:06] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [s390x] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (yakkety-proposed) [7.1.5-1ubuntu2]
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (yakkety-proposed) [0.29-0ubuntu4]
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (yakkety-proposed) [5.6.1-7ubuntu2~1]
[09:07] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [armhf] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:07] -queuebot:#ubuntu-release- Unapproved: accepted brltty [source] (yakkety-proposed) [5.4-0ubuntu4]
[09:07] -queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (yakkety-proposed) [3.20.2-1ubuntu4]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted xfsdump [source] (yakkety-proposed) [3.1.6+nmu1build1]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu2]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted kjsembed [source] (yakkety-proposed) [5.26.0-0ubuntu2]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (yakkety-proposed) [0.44.2-1ubuntu3]
[09:08] -queuebot:#ubuntu-release- Unapproved: accepted libffi [sync] (yakkety-proposed) [3.2.1-6]
[09:10] -queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (yakkety-proposed/universe) [3.22.0-1ubuntu1] (ubuntugnome)
[09:10] -queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [powerpc] (yakkety-proposed/none) [0.7.216] (no packageset)
[09:11] <xnox> Laney, wasn't the freeze meant to stay on until the release?!
[09:11] <pitti> xnox: unapproved yes
[09:11] <pitti> xnox: but not the migration blocks
[09:11] <xnox> ah, that.
[09:11] <Laney> Be calm
[09:11] <Laney> :)
[09:12] <xnox> pitti, so we don't need to "contact #ubuntu-release" to unblock every tiny package from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html right?
[09:12] <pitti> correct
[09:12] <xnox> cool.
[09:12] <pitti> we review stuff between upload and accepting into -proposed (i. e. in unapproved)
[09:13] -queuebot:#ubuntu-release- Unapproved: rejected libgksu [source] (yakkety-proposed) [2.0.13~pre1-9ubuntu1]
[09:15] -queuebot:#ubuntu-release- Unapproved: libgksu (yakkety-proposed/universe) [2.0.13~pre1-8ubuntu1 => 2.0.13~pre1-9ubuntu1] (edubuntu)
[09:30] <flocculant> pitti: yes - but if I use newest xubuntu default settings, that apparmor update and light locker - we are hit with bug 1622303
[09:30] <flocculant> so still not right here
[09:40] -queuebot:#ubuntu-release- Unapproved: libdbusmenu (xenial-proposed/main) [12.10.3+16.04.20160223.1-0ubuntu1 => 16.04.1+16.04.20160927-0ubuntu1] (ubuntu-desktop) (sync)
[09:40] -queuebot:#ubuntu-release- Unapproved: libdbusmenu (yakkety-proposed/main) [12.10.3+16.04.20160223.1-0ubuntu1 => 16.04.1+16.10.20160927.2-0ubuntu1] (ubuntu-desktop) (sync)
[09:41] <bluesabre> flocculant, pitti, the only change to xubuntu-default-settings (between working and broken locking) was the migration to the systemd user session, https://launchpad.net/ubuntu/yakkety/+source/xubuntu-default-settings/+changelog
[09:43] <bluesabre> flocculant, pitti, for the sake of simplicity, is it a release requirement for yakkety that all desktop sessions by moved over to the systemd units, or would it be fine if we were to roll back those changes (since they seem to be not fully compatible for xfce/light-locker)?
[09:44] <pitti> bluesabre: it's fine to roll back; we specifically did the transition in a way to not have a lockstep
[09:45] <pitti> bluesabre: you can confirm that it's working by changing the Exec= line back to the previous value
[09:45] <bluesabre> pitti, thanks, will check that out
[09:45] <pitti> -Exec=startxfce4
[09:45] <pitti> +Exec=/usr/share/xfce4/scripts/run-systemd-session xubuntu-session.target
[09:45] <pitti> i. e. revert that
[09:45] <pitti> if that works, there is a bug in the systemd migration
[09:46] <pitti> if not, something else changed
[09:46] <pitti> bluesabre: my suspicion is that this is actually fallout from moving from session to user bus
[09:47] <pitti> as the unit itself is quite simple -- the entire session runs in one unit, it's not split up
[09:47] <pitti> (yet)
[09:52] <bluesabre> pitti, yes, only making that changes restores the previous locking behavior (everything works)
[09:52] <pitti> bluesabre: ok, thanks (and sorry for not noticing)
[09:52] <pitti> bluesabre: so I guess upload that change for now to take the pressure off?
[09:53] <bluesabre> pitti, no problem. We'll go ahead and make these changes for yak, is there anything else you'd like me to investigate or should we save it for z now?
[09:54] <pitti> bluesabre: I'll try to get around to debugging it properly, but upstart will stay around for y anyway, so this isn't urgent
[09:54] <pitti> try before y, I mean
[09:54] <Ukikie> bluesabre: Look at -session too.
[09:54] <bluesabre> pitti, great, thanks
[09:54] <bluesabre> Ukikie, already on it :)
[09:55] <pitti> bluesabre: thank you!
[10:08] -queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (yakkety-proposed/universe) [16.10.1 => 16.10.2] (xubuntu)
[10:12] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15.2ubuntu1 => 2.16] (desktop-core, ubuntu-server)
[10:12] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.15.2+16.10.3 => 2.16+16.10] (desktop-core, ubuntu-server)
[10:15] -queuebot:#ubuntu-release- Unapproved: webkit2gtk (yakkety-proposed/main) [2.12.5-1 => 2.14.0-1] (kubuntu, ubuntu-desktop) (sync)
[10:15] <jbicha> tracking bug for webkit2gtk is bug 1625897
[10:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (yakkety-proposed/universe) [16.10.4 => 16.10.5] (ubuntugnome)
[10:18] -queuebot:#ubuntu-release- Unapproved: jmock (yakkety-proposed/universe) [1.2.0-3 => 1.2.0-4] (no packageset) (sync)
[10:19] -queuebot:#ubuntu-release- Unapproved: accepted jmock [sync] (yakkety-proposed) [1.2.0-4]
[10:27]  * apw has a look at the snapds
[10:55] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20160908-0ubuntu1 => 16.10+16.10.20160926-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[10:55] -queuebot:#ubuntu-release- Unapproved: unity-lens-applications (yakkety-proposed/main) [7.1.0+16.10.20160602-0ubuntu1 => 7.1.0+16.10.20160927-0ubuntu1] (ubuntu-desktop) (sync)
[10:56] -queuebot:#ubuntu-release- Unapproved: vinagre (yakkety-proposed/universe) [3.18.2-1build1 => 3.22.0-1] (desktop-extra) (sync)
[11:02] -queuebot:#ubuntu-release- Unapproved: libgnomekbd (yakkety-proposed/main) [3.6.0-1ubuntu2 => <IP_ADDRESS>-1] (kubuntu, ubuntu-desktop) (sync)
[11:03] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.16+16.10]
[11:08] -queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.5 => 20101020ubuntu451.6] (core)
[11:13] -queuebot:#ubuntu-release- Unapproved: gnome-session (yakkety-proposed/main) [3.20.2-1ubuntu3 => 3.20.2-1ubuntu4] (ubuntu-desktop)
[11:13] -queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu31 => 1.13.2-0ubuntu32] (core)
[11:14] <Laney> pitti: ^- those two would be best reviewed by you for sanity
[11:15] <flocculant> pitti: thanks for looking at that earlier - I can now not panic :)
[11:21] -queuebot:#ubuntu-release- Unapproved: indicator-appmenu (yakkety-proposed/main) [15.02.0+16.04.20151104-0ubuntu1 => 15.02.0+16.10.20160927-0ubuntu1] (ubuntu-desktop) (sync)
[11:47] -queuebot:#ubuntu-release- New sync: python-tenacity (yakkety-proposed/primary) [3.0.0-1]
[11:48] -queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~b2+dfsg1-1 => 4.0.0~rc1+dfsg1-1] (no packageset) (sync)
[11:48] -queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0~rc1+dfsg1-1]
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted libgksu [source] (yakkety-proposed) [2.0.13~pre1-9ubuntu1]
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted libdbusmenu [sync] (yakkety-proposed) [16.04.1+16.10.20160927.2-0ubuntu1]
[11:52] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20160926-0ubuntu1]
[11:52] -queuebot:#ubuntu-release- Unapproved: accepted unity-lens-applications [sync] (yakkety-proposed) [7.1.0+16.10.20160927-0ubuntu1]
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted indicator-appmenu [sync] (yakkety-proposed) [15.02.0+16.10.20160927-0ubuntu1]
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted vinagre [sync] (yakkety-proposed) [3.22.0-1]
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted libgnomekbd [sync] (yakkety-proposed) [<IP_ADDRESS>-1]
[11:55] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (yakkety-proposed) [16.10.5]
[11:57] <pitti> Laney: instead of copying the whole loop, would you mind just using state=active,failed?
[11:57] <Laney> pitti: The action is different in each case
[11:57] <pitti> Laney: oh, reset-failed vs. stop
[11:57] <Laney> reset-fail
[11:57] <Laney> yes :)
[11:58] <pitti> Laney: I still don't understand how this can actually happen -- stopping the target shold stop all the units too
[11:58] <pitti> due to the PartOf=; units can be failed afterwards, but not running
[11:58] <Laney> It's in the case when the session crashes, so things don't get stopped
[11:59] <Laney> Most things go to failed because they are connected to X, but not things like unity-gtk-module
[11:59] <Laney> guess that it's mostly oneshot jobs
[12:00] <pitti> Laney: my intention for this was to use restart; so "stop" and "start" separately should do that?
[12:00] <pitti> Laney: but independently of the "how", good catch!
[12:02] <Laney> I tried stop actually, but I think it didn't stop everything
[12:02] <Laney> can't remember the details off the top of my head
[12:04] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (yakkety-proposed) [16.10.2]
[12:04] <pitti> Laney: ok; this is just optimization, so nevermind
[12:04] <Laney> pitti: Okay - we can obviously fix that if it turns out to work
[12:04]  * pitti presses da button
[12:05] <Laney> I wonder if I was getting confused with the gnome-session part of the fix
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (yakkety-proposed) [3.20.2-1ubuntu4]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted upstart [source] (yakkety-proposed) [1.13.2-0ubuntu32]
[12:05] <Laney> If I tried "stop", but gnome-session was killing the session - so I thought that "stop" didn't work
[12:05] <Laney> and only later on realised what the real issue was
[12:05]  * Laney shrugs
[12:05] <Laney> thanks for reviewing!
[12:06] -queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (yakkety-proposed) [2.27-8ubuntu2]
[12:11] -queuebot:#ubuntu-release- Unapproved: openvswitch (yakkety-proposed/main) [2.6.0~git20160912.dc61b4e-0ubuntu4 => 2.6.0-0ubuntu1] (ubuntu-server)
[12:13] <jamespage> ^^ that openvswitch update switches from snapshot from git -> final release of 2.6.0
[12:13] <jamespage> its a bit diff because it also includes the autotools generated as part of the upstream release process for the tarball
[12:13] <jamespage> bit/big
[12:33] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.1 => 5.5.1+dfsg-16ubuntu7.2] (kubuntu, qt5, ubuntu-desktop) (sync)
[12:52] -queuebot:#ubuntu-release- Unapproved: anjuta (yakkety-proposed/universe) [2:3.20.0-1 => 2:3.22.0-1~ubuntu1] (desktop-extra)
[12:58] <slashd> hi SRU team, can you please nominate LP: #1607920 affecting Xenial and Yakkety release ?
[12:58] <slashd> arges_ ^
[12:58] <arges_> slashd: sure
[13:00] <slashd> arges_ thanks
[13:01] <slashd> arges thanks
[13:08] -queuebot:#ubuntu-release- Unapproved: pysparse (yakkety-proposed/universe) [1.1-2 => 1.1.1-1] (no packageset) (sync)
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted pysparse [sync] (yakkety-proposed) [1.1.1-1]
[13:16] -queuebot:#ubuntu-release- Unapproved: libpam-mount (yakkety-proposed/main) [2.14-1.1 => 2.14-2] (ubuntu-server) (sync)
[13:18] -queuebot:#ubuntu-release- Unapproved: twisted (yakkety-proposed/main) [16.4.0-2 => 16.4.1-1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
[13:34] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu14 => 4.3.3-5ubuntu15] (core)
[13:38] -queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [<IP_ADDRESS>60927-0ubuntu1]
[13:38] -queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [sync] (yakkety-proposed) [2.14-2]
[13:38] -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (yakkety-proposed) [4.3.3-5ubuntu15]
[13:45] -queuebot:#ubuntu-release- Unapproved: siege (yakkety-proposed/main) [4.0.2-1 => 4.0.2-1ubuntu1] (core)
[13:48] -queuebot:#ubuntu-release- Unapproved: accepted siege [source] (yakkety-proposed) [4.0.2-1ubuntu1]
[13:49] -queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (yakkety-proposed) [3.22.0-1ubuntu1]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [amd64] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [armhf] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [powerpc] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [s390x] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted python-tenacity [sync] (yakkety-proposed) [3.0.0-1]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [i386] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [arm64] (yakkety-proposed) [0.7.216]
[13:49] -queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [ppc64el] (yakkety-proposed) [0.7.216]
[13:55] -queuebot:#ubuntu-release- New binary: python-tenacity [amd64] (yakkety-proposed/none) [3.0.0-1] (no packageset)
[14:06] -queuebot:#ubuntu-release- New: accepted python-tenacity [amd64] (yakkety-proposed) [3.0.0-1]
[14:15] -queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit-gles (yakkety-proposed/universe) [1.3.2085+16.10.20160915 => 1.3.2104+16.10.20160919.3] (ubuntu-qt-packages) (sync)
[14:15] -queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit (yakkety-proposed/main) [1.3.2085+16.10.20160915 => 1.3.2104+16.10.20160919.3] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit-gles [sync] (yakkety-proposed) [1.3.2104+16.10.20160919.3]
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit [sync] (yakkety-proposed) [1.3.2104+16.10.20160919.3]
[14:22] -queuebot:#ubuntu-release- Unapproved: vmware-nsx (yakkety-proposed/universe) [8.0.0-2ubuntu2 => 9.0.0~git20160927.64c87d2-0ubuntu1] (no packageset)
[14:23] -queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [source] (yakkety-proposed) [9.0.0~git20160927.64c87d2-0ubuntu1]
[14:30] -queuebot:#ubuntu-release- Unapproved: gallery-app (yakkety-proposed/universe) [0.0.67+16.10.20160609.1-0ubuntu1 => 0.0.67+16.10.20160921-0ubuntu1] (no packageset) (sync)
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted gallery-app [sync] (yakkety-proposed) [0.0.67+16.10.20160921-0ubuntu1]
[14:32] <slashd> hi SRU team and/or arges, can you also please nominate LP: #1452202 affecting Trusty, Xenial and Yakkety release ?
[14:37] -queuebot:#ubuntu-release- Unapproved: libpam-mount (yakkety-proposed/main) [2.14-2 => 2.14-2ubuntu1] (ubuntu-server)
[14:38] -queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [source] (yakkety-proposed) [2.14-2ubuntu1]
[14:41] <arges> slashd: ok
[14:41] <slashd> arges, thanks again ;)
[14:41] -queuebot:#ubuntu-release- Unapproved: spl-linux (yakkety-proposed/universe) [<IP_ADDRESS>-0ubuntu1 => <IP_ADDRESS>-2] (no packageset) (sync)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted spl-linux [sync] (yakkety-proposed) [<IP_ADDRESS>-2]
[14:46] -queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (yakkety-proposed/universe) [0.4+16.10.20160916-0ubuntu1 => 0.4+16.10.20160927-0ubuntu1] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: python-novaclient (xenial-proposed/main) [2:3.3.1-2 => 2:3.3.1-2ubuntu1] (openstack, ubuntu-server)
[15:36] -queuebot:#ubuntu-release- Unapproved: firefox (yakkety-proposed/main) [49.0+build4-0ubuntu1 => 49.0+build4-0ubuntu2] (kubuntu, mozilla, ubuntu-desktop)
[15:42] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (xenial-proposed) [2:9.2.0-0ubuntu1]
[15:43] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (xenial-proposed) [2.0.5-0ubuntu1]
[15:44] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (xenial-proposed) [2:8.1.1-0ubuntu1]
[15:46] -queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (xenial-proposed) [1:5.1.2-0ubuntu1]
[15:47] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
[15:49] -queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (xenial-proposed) [1:8.2.0-0ubuntu1]
[15:50] -queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
[15:51] -queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
[15:52] -queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (xenial-proposed) [1:5.1.1-0ubuntu1]
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (xenial-proposed) [1:4.1.0-0ubuntu1]
[15:55] -queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (yakkety-proposed) [49.0+build4-0ubuntu2]
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted python-novaclient [source] (xenial-proposed) [2:3.3.1-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- Unapproved: gobject-introspection (yakkety-proposed/main) [1.49.1-2ubuntu1 => 1.50.0-1ubuntu1] (ubuntu-desktop)
[16:06] -queuebot:#ubuntu-release- Unapproved: gri (yakkety-proposed/universe) [2.12.23-9build4 => 2.12.23-9ubuntu1] (no packageset)
[16:07] -queuebot:#ubuntu-release- Unapproved: accepted gri [source] (yakkety-proposed) [2.12.23-9ubuntu1]
[16:08] -queuebot:#ubuntu-release- Unapproved: gcc-6 (yakkety-proposed/main) [6.2.0-3ubuntu15 => 6.2.0-5ubuntu11] (no packageset)
[16:11] -queuebot:#ubuntu-release- Unapproved: accepted anjuta [source] (yakkety-proposed) [2:3.22.0-1~ubuntu1]
[16:11] -queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [source] (yakkety-proposed) [1.50.0-1ubuntu1]
[16:11] -queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (yakkety-proposed) [6.2.0-5ubuntu11]
[16:13] -queuebot:#ubuntu-release- New sync: python-os-api-ref (yakkety-proposed/primary) [0.3.0+dfsg1-1]
[16:14] -queuebot:#ubuntu-release- Unapproved: murano-agent (yakkety-proposed/universe) [1:3.0.0~b2-1 => 1:3.0.0~rc1-1] (no packageset) (sync)
[16:14] -queuebot:#ubuntu-release- Unapproved: accepted murano-agent [sync] (yakkety-proposed) [1:3.0.0~rc1-1]
[16:39] <pitti> apw: I'm sure you won't mind reviewing an 830 kB patch for an SRU, right?
[16:39]  * pitti runs away really really fast
[16:52] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [sync] (yakkety-proposed) [0.4+16.10.20160927-0ubuntu1]
[16:52] <jgrimm> can openipmi in xenial migrate now? excuses says blocked on freeze (otherwise looks like it is verification-done)
[16:53] <jgrimm> nacc^^ fyi
[16:55] <slangasek> jgrimm: "blocked on freeze" is status quo for everything in SRU, we don't use proposed-migration to migrate those packages (yet).  The status on http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that bug #1311888 is not marked as verification-done
[16:57] <jgrimm> oh, that's a different bug i was looking at.  i'll sort
[16:57] <jgrimm> slangasek, thanks, i was only looking at 1596474
[16:57] <nacc> jgrimm: ack, it's on my list to go verify that one
[16:58] <jgrimm> thanks nacc
[16:59] <slangasek> I love that component-mismatches randomly reports different reverse-dependencies for platform-api in -proposed vs. devel
[16:59] <wxl> slangasek: hey thanks for all the hard work yesterday/this week. glad to have the release finally done!
[16:59] <slangasek> wxl: me too ;)  you're welcome
[17:00] <slangasek> sorry I kneecapped the lubuntu image with that xserver-xorg-input-vmmouse removal
[17:00] <wxl> and gee KernelFreeze is right around the corner, thank God!
[17:00] <slangasek> (really sorry, since we could've been done 8 hours earlier if I hadn't ;)
[17:00] <wxl> yeah well, stuff happens. at least the solution was fairly obvious
[17:02] <wxl> slangasek: am i right to remember that we usually have final images the monday before release?
[17:03] <slangasek> wxl: I believe the checklist says to start preparing these images 1 week before release; I can't say what's been typical for image availability recently
[17:03] <doko> slangasek: will the release be delayed by a week?
[17:03] <wxl> oh that's an interesting question
[17:03] <slangasek> doko: no plans to do so
[17:05] <wxl> argh where does that checklist live again slangasek ?
[17:07] <wxl> slangasek: https://wiki.ubuntu.com/ReleaseProcess seems to suggest release-3
[17:07] <wxl> slangasek: oh no i'm reading it wrong. release-6
[17:14] -queuebot:#ubuntu-release- Unapproved: python3.5 (yakkety-proposed/main) [3.5.2-4ubuntu3 => 3.5.2-6] (core) (sync)
[17:18] -queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.0~rc1-0ubuntu1 => 1:7.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[17:20] -queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu6 => 2.1.0-1ubuntu7] (ubuntu-server, virt)
[17:20] -queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.173 => 3.174] (ubuntu-desktop, ubuntu-server)
[17:28] -queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0~rc1-0ubuntu1 => 3:10.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[17:30] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu13]
[17:35] <slangasek> xnox: it seems that component-mismatches ignores Built-Using until the package is actually promoted, at which point it becomes "rescued", which unfortunately leaves these deps invisible from the high-level overview until the MIR is done.  Do you think that's fixable?
[17:40] -queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.1.0-0ubuntu4 => 1:6.2.0-0ubuntu1] (openstack)
[17:43] <tsimonq2> I thought main packages could have universe deps now?
[17:47] <cjwatson> build-deps, not runtime deps
[17:48] -queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0~rc1-0ubuntu1 => 2:10.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[17:52] -queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0~rc1-0ubuntu2 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[17:53] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.16]
[18:00] -queuebot:#ubuntu-release- Unapproved: neutron-fwaas (yakkety-proposed/main) [1:9.0.0~rc1-0ubuntu1 => 1:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[18:01] -queuebot:#ubuntu-release- Unapproved: neutron-lbaas (yakkety-proposed/universe) [2:9.0.0~rc1-0ubuntu1 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[18:02] -queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (yakkety-proposed/main) [2:9.0.0~rc1-0ubuntu1 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
[18:07] -queuebot:#ubuntu-release- Unapproved: openstack-trove (yakkety-proposed/universe) [1:6.0.0~rc1-0ubuntu1 => 1:6.0.0~rc2-0ubuntu1] (no packageset)
[18:07] -queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (yakkety-proposed) [1:6.0.0~rc2-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.9.0-0ubuntu1 => 2.10.0-0ubuntu1] (openstack, ubuntu-server)
[18:16] -queuebot:#ubuntu-release- Unapproved: ubuntu-core-meta (yakkety-proposed/universe) [0.6.14build1 => 0.6.15] (no packageset)
[18:17] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-core-meta [source] (yakkety-proposed) [0.6.15]
[18:20] -queuebot:#ubuntu-release- Unapproved: python-swiftclient (yakkety-proposed/main) [1:3.0.0-3 => 1:3.1.0-1] (openstack, ubuntu-server) (sync)
[18:20] -queuebot:#ubuntu-release- Unapproved: ubuntu-core-meta (yakkety-proposed/universe) [0.6.14build1 => 0.6.16] (no packageset)
[18:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-core-meta [source] (yakkety-proposed) [0.6.16]
[19:03] <xnox> slangasek, i don't believe component-mismatches has any inteligence wrt built-using at the moment. At the time I looked at it, I did minimal work needed to generate britney excuse & generate seeds that roughly look correct.
[19:03] <xnox> so in components missmatches, you want graph to generate extra edges for the built-using packages, and etc. i guess?
[19:04] <xnox> (together with MIR links generated)
[19:04] <slangasek> xnox: yeah basically :)
[19:05] <xnox> ok. added a google keep post it note about this irc chat log
[19:17] <infinity> xnox: Why would c-m need to understand built-using?  Nothing should end up in built-using without being a build-dep, and c-m already understands build-deps.
[19:17] <infinity> (Or are we saying that if it's in built-using, it needs to be in the same component?)
[19:17] <infinity> I guess that makes some sense.
[19:19] <infinity> So, yeah.  I guess we didn't need built-using to be processed before reorg and now do.  Derp.  Ignore me.
[19:55] <sakrecoer> wxl, slangasek: regarding the url for beta2 release notes of ubuntu studio: the link is wrong here: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes we used the same model for the url as everyone else...
[19:56] <sakrecoer> oh, wait, i wasn't logged in :) i thought it was immutable..
[19:56] <sakrecoer> i'll fix it then :)
[21:10] -queuebot:#ubuntu-release- Unapproved: python-django (xenial-proposed/main) [1.8.7-1ubuntu5.2 => 1.8.7-1ubuntu5.3] (ubuntu-server)
[21:15] -queuebot:#ubuntu-release- Unapproved: pollinate (precise-proposed/main) [4.21-0ubuntu1~12.04 => 4.23-0ubuntu1~12.04] (no packageset)
[21:15] -queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.21-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04] (no packageset)
[21:16] -queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.21-0ubuntu1~16.04 => 4.23-0ubuntu1~16.04] (ubuntu-server)
[21:20] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-41.61] (core, kernel)
[21:21] -queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu1 => 1.0.42-0ubuntu2] (no packageset)
[21:36] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-41.61]
[21:54] <slangasek> sakrecoer: thanks for fixing!  I link checked the email, since those really are immutable; the ones in the release notes were copy-paste from previous series
[22:00] <valorie> ubuntu-release team: thanks so much for your work on the beta
[22:00] <wxl> three cheers for release team
[22:00] <wxl> hip hip
[22:00] <wxl> horray
[22:00] <wxl> hip hip
[22:00] <wxl> horray
[22:00] <wxl> hip hip
[22:00] <wxl> horray!
[22:00] <valorie> I hope we (the kubuntu team) can get the rest of our stuff into the final with your help
[22:00] <valorie> hurray!
[22:01] <wxl> valorie: in other words, prepare for many incoming requests? XD
[22:01] <valorie> most are in -proposed I think
[22:02] <valorie> but applications got freezed out
[22:02] <wxl> yeah
[22:02] <valorie> most of frameworks made it in
[22:02] <wxl> well that's the most important stuff
[22:02] <valorie> I hope the rest are migrating
[22:02] <valorie> plasma seems to have made it
[22:03] <wxl> i'd expect more changes in applications than in frameworks or plasma, tho. no?
[22:03] <valorie> some if not most of apps is just bugfixes which would be really nice to have
[22:03] <valorie> most of the work over the past year or so has been porting them to frameworks
[22:04] <valorie> bugfixes are always wanted!
[22:04] <wxl> neat
[22:05] <wxl> i should upgrade from trusty/plasma4 one of these days
[22:06] <valorie> lol
[22:06] <wxl> i actually need to pull out my home and start from scratch, though. i tried using multiarch to migrate from i386 to amd64 and it's really a pain to deal with the packages. a fresh start would be much preferred
[22:06] <valorie> ya think?
[22:06] <wxl> that said, it's not even worth using the backports :/
[22:06]  * valorie has been running yakkety since it opened for business
[22:06] <valorie> on my production laptop
[22:07] <wxl> at work i run what everyone else runs. i'm starting to rethink that idea tho XD
[22:07] -queuebot:#ubuntu-release- Unapproved: rejected snap-confine [source] (yakkety-proposed) [1.0.42-0ubuntu2]
[22:07] <wxl> due to TLS requirements, we're going to need to go 64 bit everywhere within the next year though, so everyone's going to get new machines/builds
[22:07] <wxl> so they'll invariably end up with plasma5
[22:08] <wxl> i'm not 100% sure i'm sold on the black and white icons, but hey, that's what Windows 10 is doing, so... ;)
[22:08] <valorie> \o/
[22:09] <valorie> everything is adjustable
[22:09] <wxl> yes yes i know
[22:10] <wxl> but i'm disinclined to mess with graphics stuff too much. you know me, i'm a cli guy mostly. in fact, though i type this to you through konsole, it's only one window cuz i got tmux ;)
[22:11] <valorie> lol
[22:19] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-41.61~14.04.1] (kernel)
[22:20] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-41.61~14.04.1]
[22:49] -queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.3 => 2.10.95-0ubuntu2.4] (core)
[22:55] -queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu1 => 1.0.42-0ubuntu3] (no packageset)
[22:58] <jdstrand> stgraber: fyi ^
[22:58] <stgraber> looking at it and apparmor now
[22:59] <stgraber> oh, apparmor was xenial, so not what I thought it was :)
[23:00] <jdstrand> stgraber: no, not apparmor, snap-confine
[23:00] <jdstrand> stgraber: I mean, tyhicks would probably appreciate a look at apparmor, but I was pointing at snap-confine :)
[23:01] <tyhicks> stgraber: not what you thought it was but that apparmor upload is just a simple delta on top of the existing apparmor in -proposed to fix some regression test failures
[23:01] <stgraber> accepted snap-confine, looking at apparmor for xenial now (different tool)
[23:01] -queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (yakkety-proposed) [1.0.42-0ubuntu3]
[23:01] <tyhicks> thanks
[23:02] <jdstrand> stgraber: thanks!
[23:02] <stgraber> apparmor accepted
[23:02] <tyhicks> stgraber: thank you
[23:03] -queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.4]
[23:23] -queuebot:#ubuntu-release- Unapproved: singular (yakkety-proposed/universe) [4.0.3-p1+ds-3build2 => 4.0.3-p1+ds-3ubuntu1] (no packageset)
[23:24] -queuebot:#ubuntu-release- Unapproved: accepted singular [source] (yakkety-proposed) [4.0.3-p1+ds-3ubuntu1]
[23:28] -queuebot:#ubuntu-release- Unapproved: mako (yakkety-proposed/main) [1.0.4+ds1-1 => 1.0.4+ds1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
[23:46] -queuebot:#ubuntu-release- Unapproved: seabios (yakkety-proposed/main) [1.8.2-1ubuntu1 => 1.8.2-1ubuntu2] (ubuntu-server)


[06:53] <dholbach> good morning
[10:05] <bdrung> tumbleweed: i think we should do another u-d-t upload.
[10:05] <bdrung> tumbleweed: any progress on bug #878868?
[10:06] <tumbleweed> I'm ignoring that one
[10:06] <tumbleweed> it should be possible now that LP has changelog access, though
[10:08] <tumbleweed> bdrung: we need to review that open merge request
[10:11] <bdrung> tumbleweed: this one: https://code.launchpad.net/~ursinha/ubuntu-dev-tools/fix_getBinaryPackage/+merge/159076 ?
[10:17] <tumbleweed> yes-
[10:38] <bdrung> tumbleweed: and there is https://code.launchpad.net/~brian-murray/ubuntu-dev-tools/fix-params/+merge/125786
[18:44] <alo21> hi... I got an error while running merge-buildpackage -rafekroot -k<GPG_KEY>. this is the error: dpkg-source: info: local changes detected, the modified files are:
[18:44] <alo21>  gramophone2-0.8.13a-2ubuntu1/Makefile
[18:44] <alo21> dpkg-source: info: you can integrate the local changes with dpkg-source --commit
[18:44] <alo21> dpkg-source: error: aborting due to unexpected upstream changes
[18:44] <alo21> it's weird..
[18:48] <alo21> why I got that?
[19:09] <geser> alo21: check what have changed in that file (you might want to run the mentioned command to get a patch file for easier review)
[19:12] <alo21> geser, I run the command, but I got: dpkg-source: info: fuzz is not allowed when applying patches // dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/typoCorrection.patch/ --reject-file=- < gramophone2-0.8.13a-2ubuntu1/debian/patches/typoCorrection.patch gave error exit status 1
[19:13] <alo21> typoCorrection.patch is a debian one...not mine
[19:14] <geser> hmm, I assume this is a normal merge (grab-merge) and not a bzr merge one, right?
[19:14] <alo21> geser, right
[19:16] <geser> did the Ubuntu patch per chance tried to modify the same file as the debian patch?
[19:17] <alo21> geser, the patch which I've just created?
[19:18] <geser> the existing Ubuntu delta which MoM tried to re-apply on the new Debian revision
[19:19] <geser> checking the current delta, it looks like it also modifies Makefile but not using a patch
[19:20] <alo21> geser, the patch which MoM said me to create is the same debdiff in ubuntu repo...the debian patch is in debian folder
[19:21] <geser> MoM took the existing delta, applies it on the new Debian revision and tars everything up for download and review
[19:22] <geser> it doesn't know about patch systems and blindly applies the existing delta
[19:22] <geser> which is probably the reason for this
[19:23] <geser> before you tried to figure out how to fix this to make dpkg-source happy again: just start from the new Debian revision and merge manually (create a new patch which applies cleanly on the existing ones)
[19:23] <geser> which be by faster as the changes are pretty small
[19:27] <alo21> geser, ok.. thanks for the advice
[19:27] <alo21> Do I have to create a .patch or a debdiff?
[19:28] <geser> both, the .patch file (in debian/patches; see how the other are named) is part of the source packages, the debdiff for sponsoring/review of the merge
[19:29] <alo21> so...  I have to upload debdiff only
[19:30] <geser> yes, you only need to attach the debdiff to the sponsoring bug (the debdiff contains all you changes to the package, incl. your newly created patch)
[19:31] <alo21> geser, Can I directly upload the previous debdiff? It contains the same changes I have to do
[19:32] <geser> no, as it misses the new changelog entry
[19:32] <alo21> well
[19:50] <alo21> geser, here is the patch (http://pastebin.ubuntu.com/5707851/). Could you see if there is something to correct, please?
[20:09] <geser> the changelog entry shouldn't be part of the patch file itself (it's still a part of the debdiff and you have to keep the older Ubuntu changelog entries too)
[20:13] <TheLordOfTime> there's a backport in precise and quantal  in universe that is affected by a null pointer dereference bug, is there any easy way to get those backports bugfixed?
[20:13] <alo21> geser, ok... so the patch shouldn't have the entry log, but only the debdiff.... anyway I tried to run debuild -S -sa on the patched source and I got this issue: dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/cflags.diff/ --reject-file=- < gramophone2-0.8.13a.orig.7lQL3u/debian/patches/cflags.diff gave error exit status
[20:13] <TheLordOfTime> the fix isn't in saucy or raring btw
[20:13] <alo21> *status 1
[20:14] <geser> TheLordOfTime: fix saucy, SRU raring, backport the SRU to precise and quantal
[20:15] <TheLordOfTime> geser:  does it need to be fixed in debian first?
[20:16] <TheLordOfTime> or can we just get the fix in saucy, raring, etc.?
[20:17] <geser> TheLordOfTime: it would make fixing saucy easier, just a sync in that case :)
[20:17] <TheLordOfTime> i'll poke debian
[20:17] <TheLordOfTime> although i think they won't update until NextReleaseOfSoftware
[20:17] <TheLordOfTime> :/
[20:17] <alo21> TheLordOfTime, so... It's better to send the patch in debian first, right?
[20:18] <TheLordOfTime> alo21:  you can ignore me talking to geser
[20:18] <TheLordOfTime> separate issue
[20:18] <geser> talk to the DD on how to proceed: wait on Debian or move ahead and fix in Ubuntu first
[20:18] <TheLordOfTime> lrn2readhighlights
[20:18] <TheLordOfTime> geser:  the software is called 'znc'
[20:18] <TheLordOfTime> so tbh i can just go in and erase the installed module and upload a rebuilt one to the production server
[20:18] <geser> TheLordOfTime: if Debian will fix it with a new upstream release, you still have to SRU in raring
[20:18] <TheLordOfTime> geser:  that's a given :P
[20:19] <geser> alo21: no idea right now, what you are doing wrong, sorry
[20:20] <alo21> geser, do not worry


[00:08] <JanC> 0.6.5 is pretty much antique…  :-/
[00:10] <JanC> is the daemon/application actually stopping, or does upstart only think so?
[00:11] <JanC> if it's actually stopping (or crashing), try to make it log
[01:27] <ikonia> JanC: I think it's acutally not a problem, I think it's my actual job thats just defined wrong
[01:27] <ikonia> it's a php job - I think it's launching it and exiting, rather than launching it and keeping it alive,
[01:28] <ikonia> and yes, it's pretty much the dark ages of upstart, but it's what is in centos 6


[01:12] <ScottK> sarnold: No always.
[03:38] <slangasek> stgraber: hey, could you please commit your changes from casper 1.332?  (Since there's a documented Vcs-Bzr field, and the importer is balking)
[03:43] <stgraber> slangasek: hmm, I don't have those commits around anymore. Anyway, I just updated the packaging branch with a manual import of 1.332 so the content and the tags should be fine now.
[03:43] <slangasek> stgraber: ok, thanks
[04:46] <pitti> Good morning
[04:52] <lifeless> morning pitti
[06:03] <pitti> smoser: ah, today's cloud images work again (ssh)
[07:30] <dholbach> good morning
[08:01] <alkisg> LTS desktop packages are supposedly supported for 3y, and server packages for 5y. But that doesn't match what `apt-cache show package | grep Supported` says:
[08:01] <alkisg> dpkg -l | awk '/^ii/ { print $2 }' | xargs apt-cache show | grep ^Supported | sort -u
[08:01] <alkisg> Supported: 18m
[08:01] <alkisg> Supported: 5y
[08:01] <alkisg> ==> no "3y" anywhere there, although many packages don't have a "Supported" line in their control file. How can I see for how long a package is supported?
[08:07] <StevenK> alkisg: That changed with Precise, everything is 5y
[08:07] <alkisg> Thank you StevenK, and I assume the packages that are supported for 18m is just minor bugs...
[08:08] <StevenK> I'm not certain of the rules
[08:08] <StevenK> I just know that desktop stopped being 3 years and started being 5.
[08:09] <alkisg> Thanks, it answers my concerns, the 18m packages are too few to bother with anyway :)
[08:10] <alkisg> Maybe they are part of flavors that were not LTS, e.g. lubuntu maintained packages etc
[08:14] <tjaalton> who's maintaining the vuds scheduling?
[08:16] <seb128> tjaalton, nobody
[08:16] <seb128> tjaalton, track leads and some others have edit access
[08:16] <seb128> tjaalton, but I don't think there is one person responsive for the schedule
[08:17] <seb128> tjaalton, would be easier it you asked what you really want to know ;-)
[08:20] <pitti> tjaalton: for changes, poke one of the track leads
[08:24] <tjaalton> seb128: the hybrid session got dropped from the schedule since it was mistakenly marked as superseded
[08:24] <tjaalton> pitti: thanks, who is the track lead?
[08:24] <seb128> tjaalton, I can schedule things
[08:25] <tjaalton> seb128: oh, cool. well could we have the first slot tomorrow?
[08:25] <tjaalton> it was originally today at 1800UTC but it was bad for me & tseliot
[08:26] <seb128> no
[08:26] <seb128> http://summit.ubuntu.com/uds-1305/2013-05-15/display
[08:26] <seb128> there is no slot left at this time
[08:26] <seb128> would thursday 15utc in client 2 works for you?
[08:27] <tjaalton> nope :/
[08:28] <tjaalton> oh well, put it back where it was, today 1805-1900
[08:28] <seb128> tkamppeter, hey, would it be ok if the oprint dialog design session is moved from tomorrow 2pm to thursday 3pm?
[08:28] <tjaalton> is it ok to lead the session without video? :)
[08:29] <seb128> tjaalton, ^ if that works for Till I can put yours there, otherwise let's do today 18h
[08:29] <seb128> tjaalton, yeah, audio is fine
[08:30] <tjaalton> seb128: yeah that would be fine
[08:30] <tjaalton> no, great
[08:30] <pitti> jibel: FTR, run-adt-test -sl works again for saucy, so it really was the openssh issue
[08:50] <tkamppeter> seb128, no problem.
[08:50] <seb128> tkamppeter, thanks
[08:51] <seb128> tjaalton, hybrid is on schedule for tomorrow 2pm utc
[08:59] <tjaalton> tkamppeter, seb128: woohoo, thanks :)
[09:02] <seb128> yw ;-)
[09:47] <pitti> stgraber: I now added a NM test for hotplugging ethernet (with veth), still works fine
[09:48] <pitti> stgraber: but that's using "ip link add name ethXX type veth peer name vethXX", not your two-command approach
[09:48] <pitti> stgraber: I guess that eliminates the race
[10:36] <Quintasan> dholbach: ping
[10:44] <dholbach> Quintasan, pong
[10:46] <Quintasan> dholbach: Do you happen to know who can I ask about jobs at Canonical? I'd like to know on what I might actually work on.
[10:50] <dholbach> Quintasan, is it about a specific job?
[10:51] <Quintasan> dholbach: Yeah, software engineer job id 622
[10:51] <dholbach> Quintasan, can you give me a link please?
[10:55] <Quintasan> uhhh
[10:55] <Quintasan> dholbach: https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=622
[10:55] <Quintasan> There you go
[10:55] <dholbach> thanks
[11:02] <dholbach> Quintasan, I'll find out and get back to you
[11:02] <Quintasan> dholbach: Thanks!
[11:18] <ekarlso-> How come running "backportpackage -b -u ppa:endre-karlson/virtualization -s raring -d precise openvswitch" doesn't put a package at https://launchpad.net/~endre-karlson/+archive/virtualization ?
[11:26] <ekarlso-> cjwatson: ? :)
[11:36] <tumbleweed> ekarlso-: what *did* it do?
[11:55] <cjwatson> ekarlso-: 2013-05-14 11:30:46 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20130514-112605-003226/~endre-karlson/virtualization/ubuntu/openvswitch_1.9.0-0ubuntu1~ubuntu12.04.1~ppa1_source.changes': Signing key E4B4AA25FA856267A8267A6A
[11:55] <cjwatson> FDDCC098A811ECB6 not registered in launchpad.
[11:56] <cjwatson> ekarlso-: https://help.launchpad.net/Packaging/UploadErrors#The_upload_appears_to_work_but_I_don.27t_get_any_email_about_it
[12:46] <mpt> cyphermox_, is it possible to tell what kind of Bluetooth 2.1 pairing a device uses (numeric, alphanumeric, numeric comparison, etc) before trying to pair to it? I.e. is the pairing scheme broadcast along with the device name, or is it revealed only when pairing starts?
[12:59] <tedg> The coffee at this hotel is good, but the service sucks.  ★★☆☆☆
[13:02] <roadmr> Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team?
[13:09] <cyphermox_> mpt: I'll check and let you know. I'm not sure how pairing works precisely tbh
[13:18] <ekarlso-> cjwatson: I have uploaded my fingerprint for the key
[13:36] <ekarlso-> suggestions ?
[13:37] <ekarlso-> nvm :p
[13:39] <cjwatson> ekarlso-: OK.  You'll need to retry the upload after doing that
[13:40] <ekarlso-> ok, thanks :)
[13:40] <cjwatson> ekarlso-: ... looks like you managed it
[13:40] <ekarlso-> yes :)
[13:47] <mardy> kenvandine: does the latest signon-ui fix the integration tests for you (it does for me)?
[13:47] <avalon78> hi,i want to ask sth on ip header declaration....right channel?
[13:47] <kenvandine> mardy, i'll check
[13:51] <sconklin__> @pilot in
[13:51] <bl4de> wow, guys, I'm trying GoLang...is incredible!
[13:55] <psusi> I glanced at it once, seemed kind of nice
[13:59] <cjwatson> stgraber: hmm, so I scheduled the language pack refresh session for 1905 UTC today, but I just remembered I have a RL conflict this evening (choir practice), so we can't have two parallel foundations sessions in the last two slots today
[14:00] <cjwatson> stgraber: would it be inconvenient if I moved it to tomorrow, say 1605 UTC?
[14:01] <stgraber> cjwatson: I don't have anything at 16:05 UTC tomorrow, so fine by me
[14:02] <cjwatson> stgraber: ok, done
[14:12] <bkerensa> cjwatson: are you foundation track lead?
[14:14] <mitya57> Mirv: can we sync new qtchooser from debian? in 26-3 they finally added auto-fallback to qt4 versions, which is a very nice feature
[14:15] <cjwatson> bkerensa: with bdmurray, yes
[14:16] <Laney> what's the number on the y axis (and the one that appears when you hover on the graph) on an errors.u.c detailed page?
[14:34] <xnox> smoser: am now. what's up?
[14:36] <smoser> xnox, i sent you mail, and opened a bug and subscribed you.
[14:36] <smoser> generally was a really big PITA because you didn't answer me :)
[14:37] <xnox> smoser: i'm so sorry =) off on vacation.
[14:37]  * xnox is catching up on irc pings first.
[15:02] <bdmurray> pitti: could you have a look at bug 1179979?
[15:08] <pitti> bdmurray: ah, funny; I had thought that the kernel already resolves duplicates in /proc/self/exe
[15:09] <pitti> oh wait, that's python, so we need to look at the second arg
[15:09] <pitti> bdmurray: right, will fix
[15:09] <bdmurray> pitti: great, thanks!
[15:09] <pitti> bdmurray: I just did an apport upload some 10 mins ago..
[15:10] <bdmurray> I needed ev's help to sort out the difference between the buckets since they looked so similar. ;-)
[15:19] <mitya57> bkerensa: chromium non-maintenance was pre-qengho_ time, not relevant anymore :)
[15:20] <bkerensa> mitya57: wat
[15:20] <bkerensa> i have no idea what is qengho?
[15:21] <mitya57> s/what/who/ (check the changelog entries) :)
[15:21] <seb128> bkerensa, he's the ubuntu chromium maintainer (and on his channel)
[15:22] <bkerensa> ah
[15:22] <bkerensa> well thats great news then
[15:26] <chrisccoulson> oh, i missed the start of uds?
[15:27] <seb128> chrisccoulson, yes
[15:30] <Laney> yeah, you missed the decision to switch to mosaic as the default browser
[15:30] <chrisccoulson> *shrug*
[15:30] <chrisccoulson> ;)
[15:30] <TheMuso> lol
[15:31] <chrisccoulson> i was hoping for lynx. never mind
[15:32] <mdeslaur> w3m-img FTW
[15:32] <Laney> hell yeah
[15:33] <jpds> chrisccoulson: GET.
[15:33] <chrisccoulson> heh
[15:34] <cjwatson> Who needs GET when you have nc?
[15:34] <cjwatson> (uphill, both ways, in the snow)
[15:34] <mitya57> telnet.
[15:34] <TheMuso> I'd take any of those choices. :)
[15:35] <Laney> wetstring.iso
[15:36] <cjwatson> I used to work for a high-performance web server company some of whose customers ... well, let's say they were the sort of people who *really* needed very high performance on lots of static files in 2000, and whose web sites you might not actually want to look at in a real web browser
[15:36] <cjwatson> our support staff were encouraged to use low-level text-only HTTP clients where appropriate
[15:37] <mdeslaur> cjwatson: hehe :P
[15:37] <stgraber> ;)
[15:37] <TheMuso> Ah... The way the web should have remained... :p
[16:11] <seb128> greyback, dpm, pitti, mhall119, any of you coming to https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind ?
[16:11] <pitti> seb128: no, I'm in the upgrade testing one
[16:11] <seb128> pitti, ok
[16:11] <greyback> seb128: I have no idea why I'm invited to that!
[16:14] <seb128> greyback, no worry, I asked in case ;-)
[16:21] <mhall119> seb128: no, I'm in app dev sessions all day
[16:21] <seb128> mhall119, no worry
[16:43] <lool> pitti: did I tell you how awesome the nm tests you're adding are?  it's really cool stuff
[16:44] <pitti> lool: :) glad that you like them :)
[17:17] <seb128> stgraber, pitti: can you mark https://code.launchpad.net/~timo-jyrinki/unity-lens-files/precise.sru.hiddenfiles/+merge/162780 as merged?
[17:18] <stgraber> done
[17:20] <seb128> thanks
[17:48] <cjwatson> mhall119: are you collecting session videos in some kind of central account or anything?
[17:49] <mhall119> cjwatson: no, but they will remain linked on summit
[17:50] <mhall119> there was no easy way that we could find last time to put them all in the same place on YouTube
[17:50] <mhall119> but Summit is searchable and has session descriptions and links to BPs and Etherpad, so it gives us other features too
[17:50] <cjwatson> mhall119: ok, so I don't need to do anything special?
[17:51] <cjwatson> having already filled out the broadcast url
[17:51] <mhall119> cjwatson: nope, just end the hangout and that's it
[17:51] <cjwatson> cool
[17:54] <slangasek> cjwatson: last time there was a halfway-coordinated effort to use 'standard' tags on the videos so they could be found later
[17:55] <slangasek> cjwatson: #uds, #uds-1305 for starters
[18:45] <Daviey> ev: Do you know if improved whoopsie-daisy experience on server is on a vUDS topic?
[18:57] <tjaalton> does anyone know why libtool forces link_all_deplibs to "no"?
[18:58] <tjaalton> or, in other words, libtool in debian is patched to do that, but why..
[18:59] <cjwatson>   * Don't add the contents of dependency_libs to the link line when
[18:59] <cjwatson>     linking programs.  Closes: #191425, #199423, #238681.
[18:59] <cjwatson> is I believe the relevant changelog entry
[18:59] <tjaalton> ah, thanks
[19:00] <cjwatson> there are several problems with overlinking
[19:01] <cjwatson> one is performance on startup; another (more serious) is that you get screwed unnecessarily if one of your library deps changes the soname of something it links against
[19:01] <cjwatson> now you are trying to load libfoo1 and libfoo2 into memory at the same time and hilarity ensues
[19:02] <cjwatson> now, why this isn't upstream I can't help you with
[19:02] <tjaalton> right, it's been there for nine years now :)
[19:03] <slangasek> does our patched libtool DTRT for static linking, and does it work on non-Linux?
[19:03] <tjaalton> git/beta version of sssd fails to build and the fedora guys noticed the patch, now thinking how to fix the issue for sssd
[19:03] <cjwatson> I indeed assume that there are some portability problems
[19:03] <slangasek> right, anything that fails to link on Ubuntu as a result of that libtool patch is itself buggy
[19:04] <tjaalton> they created internally shared libs that various bits link to, they used to be statically linked
[19:04] <tjaalton> https://lists.fedorahosted.org/pipermail/sssd-devel/2013-May/015053.html
[19:05] <pitti> slangasek: I've got five positive (and zero negative) pieces of feedback for the new udev in my PPA now; is there a chance you could test it on your LVM setup, too?
[19:06] <stgraber> pitti: ah, that reminds me I need to comment about the new network device name
[19:06] <xnox> pitti: hmmm... which one? i can test my non-trivial lvm here as well.
[19:06] <pitti> stgraber: yeah, I guess I'll forward port the old rules generator for the time being, to separate that question from the general update
[19:06] <pitti> xnox: that'd be great -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037084.html
[19:06] <slangasek> pitti: not immediately; but as you can see there are lots of others around with LVM in use who should be able to help make sure this is tested before upload :)
[19:07] <pitti> slangasek: hehe
[19:08] <pitti> xnox: there's nothing known-broken there with LVM, but we have a patch which was nontrivial to port, so I'd rather make double sure it's still right
[19:13] <xnox> pitti: even with that patch, I don't think we were watching and using DM_COOKIEs correctly though. As nested LVMs sometimes did not come up for me before. I just check to make sure, my normal servers reboot with the upgrade ;-)
[19:14] <pitti> xnox: yeah, I think we should not kill the udev in the initramfs and start a new one
[19:14] <pitti> it should be possible to start it once in initramfs and just keep it running, as both /dev and /run are already move-mounted into the real system anyway
[19:15] <slangasek> if we don't mind the memory penalty of running a process out of the initramfs indefinitely instead of backed by the filesystem
[19:16] <slangasek> what is the argument for needing to keep it running from the initramfs?
[19:16] <cjwatson> I always wondered whether there could be a udevadm control command to tell it to pivot
[19:18] <pitti> slangasek: it seems a bit pointless to stop and restart it, but more importantly, it seems we had some problems with our lvm package that expects some events to never get lost, but shutting down and restarting udev would lose some events
[19:19] <pitti> at least that's how I understood the purpose of that dm-cookies patch
[19:26] <xnox> correct. and one ideally wants the cookies to check which VGs were scanned or not, thus not to "find" the wrong one by accident (in case of nested LVMs, fake-raids etc)
[19:30] <slangasek> pitti: yes; and I think the right solution is to get that upstreamed, not to carry a shared library penalty on every system due to processes running from the initramfs
[19:30] <pitti> sure; at this point it's only thinking aloud anyway
[19:31]  * pitti waves good night
[19:37] <lifeless> barry: sorry! I missed the UDS session
[19:37] <lifeless> stgraber: ^
[19:37] <lifeless> was in a meeting :(
[19:40] <barry> lifeless: darn.  maybe we can set up a time for us to chat
[19:41] <seb128> cjwatson, just saw your scribus merge, is it right to build-depends on a virtual package (libtiff-dev)? some other packages do "libtiff5-dev | libtiff-dev" ... is there one more correct than the other one?
[19:41] <infinity> seb128: Build-depending on virtuals is fine.
[19:42] <xnox> seb128: in ubuntu we transitioned to newer tiff ahead of debian. any should be fine, as long as you choose the better one =)
[19:42] <seb128> xnox, what's the preferred way?
[19:42] <xnox> any = is in real or virtual.
[19:42] <cjwatson> seb128: yes, it's fine
[19:42] <infinity> seb128: Binary deps are meant to declare a "real" preference, but build-deps have no such policy.
[19:42] <xnox> seb128: 5 i think.
[19:42] <cjwatson> seb128: there's only one provider of libtiff-dev at any one time so the distinction is immaterial
[19:42] <infinity> seb128: (And, in Debian, build-deps on virtuals are preferred, as it makes binNMUs easier for transitions, since Debian's buildds don't respect alternate deps, intentionally)
[19:43] <cjwatson> xnox: no
[19:43] <seb128> I guess we rely on one version only having the provide?
[19:43] <seb128> ok, cjwatson already said that :p
[19:43]  * xnox is confused.
[19:43] <infinity> xnox: Evidently. ;)
[19:44] <infinity> xnox: Virtual build-deps are the preferred method, so transitions aren't a painful mess.
[19:44] <cjwatson> I went through quite a few libtiff-dev r-build-deps a couple of releases ago; this ended up being the natural pattern for most of them, but I didn't bother pushing against the flow in cases where the Debian maintainer had decided to be specific
[19:44] <xnox> i see.
[19:44] <infinity> xnox: And alternate build-deps only work in Ubuntu because we hacked sbuild to make it work so we could do the main/universe split, they're explicitly not followed in Debian.
[19:44] <xnox> infinity: that. thanks.
[19:45] <seb128> infinity, what happens if several package provide the virtual? do we get a random version picked on build depending of the position of the moon?
[19:45] <cjwatson> Though libtiff5-dev | libtiff-dev works in both, as long as you don't mind it never picking other versions in Debian.
[19:45] <infinity> (ie: on a Debian buildd, "libtiff4-dev | libtiff-dev" == "libtiff4-dev")
[19:45] <xnox> infinity: limitation or intention?
[19:45] <xnox> (in debian)
[19:45] <cjwatson> seb128: You shouldn't use this in cases where several packages provide the virtual, indeed.
[19:45] <infinity> xnox: It's intentional in Debian.
[19:45] <cjwatson> But I knew what was happening with libtiff-dev.
[19:46] <infinity> sbuild's resolver actually does try to intelligently select in the case of multiple providers, it's not random.
[19:46] <seb128> cjwatson, right, I was wondering because infinity said it's the preferred way for transitions
[19:46] <cjwatson> In the case of transitions which follow the only-one-package-provides-preferred-virtual pattern.
[19:46] <infinity> seb128: The Debian release team prefers things they can binNMU.  Individual library/stack maintainer may know better in specific cases.
[19:46] <cjwatson> I'd be more cautious about it for others.
[19:46] <lifeless> barry: yeah that would be good
[19:46] <seb128> ok, makes sense
[19:46] <seb128> cjwatson, infinity, xnox: thanks ;-)
[19:46] <barry> stgraber: ^^
[19:47] <seb128> btw do you know if debian plans to start the libtiff transition soon?
[19:47] <stgraber> barry: yep, we can do that
[19:47] <infinity> I suspect it'll start sometime after people are done being grumpy about doko and I doing toolchain transitions.  *cough*
[19:47] <seb128> lol
[19:49] <cjwatson> Debian tends to try to avoid overlapping transitions
[19:49] <cjwatson> I think there's a decent queue :)
[19:49] <cjwatson> http://lists.debian.org/debian-release/2013/05/msg00127.html
[19:50] <xnox> seb128: there are 27 planned transitions filed, a few uncoordinated transitions started (even before wheezy release). Oh tiff3 is not out of the debian, ouch.
[19:51] <seb128> well, it's not like the delta was hard to maintain... ;-)
[21:02] <TheMuso> ugh forgot to include changelog entries from debian with a merge upload. :S easy to do when working with git buildpackage.
[21:04] <roadmr> oh, a git user!
[21:10] <TheMuso> Yes, since Debian uses git to maintain the packaging for the package I was working on, and I maintain the Ubuntu delta in the same repo.
[21:10] <TheMuso> c
[21:45] <stokachu> stgraber: ive got both bug 859600 and 1094319 in shape for a sponsorship if youve got time
[21:48] <bdmurray> barry: still about I'm curious about python tracebacks ending in 'ValueError: bad marshal data'
[21:52] <barry> bdmurray: yeah
[21:52] <bdmurray> https://errors.ubuntu.com/problem/5b56cf70bb8fe037f020c4a2536d214092cb9823
[21:52] <bdmurray> there is an example
[21:54] <bdmurray> I gather this is due to corrupt .pyc files?
[21:54] <barry> bdmurray: yeah, gotta be
[21:55] <bdmurray> I wonder if apport should help out here
[21:57] <barry> bdmurray: maybe we need a post-installation .pyc checker, but this one is happening in threading which comes with the stdlib.  i really should bring this up on debian-python ml
[21:57] <bdmurray> barry: if you look at http://people.canonical.com/~brian/tmp/phased-updates.html
[21:58] <bdmurray> every duplicity error for version 0.6.18-0ubuntu3.1 ends in bad marshal data
[22:02] <barry> bdmurray: looks like they're all in "import threading" too.  that's pretty curious
[22:02] <bdmurray> barry: ?     import time, types, re, calendar
[22:02] <bdmurray> ValueError: bad marshal data (string ref out of range)
[22:02] <bdmurray> from https://errors.ubuntu.com/problem/550cc32bf32c9dfe4901e6010c000ad39b69d5f4
[22:03] <barry> okay, not that one ;)
[22:06] <bdmurray> actually there are a lot of EOFError's about duplicity too
[22:06] <bdmurray> https://errors.ubuntu.com/?release=Ubuntu%2012.04&package=duplicity&period=year
[22:09] <barry> bdmurray: my best guess is that this is a systematic problem with the writing of .pyc files during package installation.  even though there's no atomic writes of pycs until python 3.3, i still can't think of a scenario that could cause this to happen.  can you do me a favor?  can you compile a list of public bugs of this type and send me an email?  i'll try to formulate something for debian-python, and perhaps upstream
[22:11] <bdmurray> barry: public launchpad bugs with ValueError ... bad marshal data and /or EOFError: EOF read where ...
[22:11] <cjwatson> barry: note that pyc files are handled specially by ubiquity, although I can't imagine how it'd matter
[22:11] <barry> bdmurray: yes
[22:11] <bdmurray> barry: okay both it is!
[22:11] <cjwatson> But just in case these are all during installation
[22:11] <barry> bdmurray: thanks!
[22:12] <barry> cjwatson: interesting.  what does ubiquity do specially?
[22:12] <cjwatson> We exclude .pyc files from the live filesystem to save space; ubiquity goes through and calls pycompile and friends a bunch of times to recreate them after installation
[22:12] <barry> i guess there's no way to know whether the pyc was created at system installation time or via subsequent package installation
[22:13] <cjwatson> Not easily, though anything that's on the live image and that hasn't been upgraded since installation from a live image would fall into that category
[22:13] <cjwatson> https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L334
[22:13] <cjwatson> (configure_python)
[22:14] <barry> cjwatson: is there any way more than call to configure_python() could run at the same time?
[22:15] <cjwatson> No, that's all single-threaded/single-process
[22:16]  * barry wonders how hard it would be to "backport" atomic pyc writing to python 2.7 - can't be backport-no-quotes because it's C in 2.7 and python (importlib) in 3.3
[22:16] <cjwatson> Indeed it's only ever called once period
[22:16] <cjwatson> And it should be strictly after all files from the live image have been copied to disk
[22:16] <barry> yeah. i can't think of how this could happen in single-threaded/process
[22:17] <barry> bdmurray: have you ever run across this bug in python3 code?
[22:17] <barry> (this or any similar?)
[22:17] <cjwatson> Just worth mentioning in case you wind up down some confusing blind alley and it turns out to be the fault of this code.  It may be unrelated
[22:17] <barry> cjwatson: thanks
[22:18] <barry> the big problem of course is that i have no idea how to reproduce this, but i could certainly try a few fresh installs to see if i can trigger the problem
[22:18] <barry> cjwatson: so ubiquity is possibly a good clue
[22:23] <bdmurray> barry: I haven't looked closely but will keep an eye out
[22:25] <barry> bdmurray: cool.  my working hypothesis is that we have a race condition in writing .pyc files under some conditions.  py3.3 writes them atomically and so should be immune, but py2.7 does not.  if we see this problem with py3.3 then i really have nfc ;)
[22:27] <cjwatson> barry: I suppose it is possible that ubiquity runs something else as root in parallel with that which might cause python to write the .pyc files on its own
[22:27] <barry> cjwatson: that could do it
[22:28] <cjwatson> There *shouldn't* be, and I can't think of an obvious place to start looking
[22:28] <cjwatson> The only thing being run in the chroot at that point is py_compile.py (etc.) itself
[22:28] <cjwatson> I think
[22:29] <cjwatson> But it's perhaps worth some detailed strace investigation at around the point plugininstall.py kicks off (just after "Copying files" finishes)
[22:29] <sconklin__> @pilot out
[22:30] <barry> cjwatson: actually, i'm looking at the code now.  i need to investigate in more detail when dinner isn't ready <wink>, but i actually think that 2.7 may open the pyc file O_EXCL|O_CREAT|O_WRONLY|O_TRUNC
[22:31] <infinity> barry: Couldn't this happen pretty much any time you're updating a python module via dpkg and also running some root-owned python process in parallel?
[22:31] <infinity> barry: (Like, I dunno, python-apt)
[22:33] <infinity> barry: Or, as the many errors point to, duplicity, since it's probably cronned as root, and can sometimes trip at just the wrong time (during a package update when the pyc files are briefly missing or being recreated).
[22:33] <barry> infinity: it could.  3.3's behavior is a bit different than 2.7 here, since it writes the pyc to a pseudo-random file and then atomically renames it into place after successful write.  py2.7 doesn't do the atomic rename
[22:34] <infinity> barry: That should be vaguely trivial to knock up a fix for.
[22:34] <barry> infinity: yes, i think so too
[22:35] <barry> (slightly less trivial in 2.7 since the import machinery is in C there, but not really that bad i suspect)
[22:36] <infinity> barry: mkstemp(3)?
[22:37] <bdmurray> a lot of these are upgrades rather than fresh installs
[22:37] <mwhudson> i'm fairly sure python 2 isn't *hilariously* vulnerable to pyc-writing races
[22:37] <infinity> barry: I'm not inclined to believe this is a harder problem to solve in C than in Python. :)
[22:37] <barry> infinity: for posix perhaps :)  the question is whether we want to try to get a cross platform fix upstream or just hack it into debuntu's version.  i'll probably try to chat with a few of the other upstream import machinery experts so we can come to some consensus on the problem and proper fix
[22:39] <barry> infinity: it's probably not, although the specific algorithm would be different a bit
[22:39] <infinity> barry: A google for "mkstemp win32" gets me http://gitorious.org/git-win32/mainline/blobs/8cfc8e4414bbb568075a948562ebb357cb84b6c3/win32/mkstemp.c
[22:39] <infinity> Or a much longer one in a random pastebin.  Heh.
[22:40] <barry> mwhudson: yeah, it's *probably* true, but not as hardened as 3.3.  e.g. 2.7 opens excl|creat but no atomic rename afaict
[22:40] <barry> infinity: yeah, but it's not like i'm personally ever gonna test it on windows :)
[22:40] <mwhudson> barry: sure
[22:41] <cjwatson> Gah, still no armhf porter box?
[22:41] <infinity> Or http://msdn.microsoft.com/en-us/library/t8ex5e91%28VS.80%29.aspx ..
[22:41] <infinity> cjwatson: Need a panda?
[22:41] <cjwatson> that'd be nice
[22:41] <cjwatson> as long as it's remotely :)
[22:44] <infinity> cjwatson: shiva.0c3.net
[22:45] <cjwatson> infinity: Cool, thanks.  No schroot?
[22:45] <goddard> how many packages are in ubuntu?
[22:45] <goddard> or in the repositories i should say
[22:45] <cjwatson> which version, which architecture, and do you mean binary packages or source packages?
[22:45] <goddard> how many for a given version at a time?
[22:45] <goddard> like 13.04 for example
[22:45] <cjwatson> different answers depending on which version, which is why I'm asking you.
[22:46] <infinity> cjwatson: See /msg
[22:46] <goddard> all x86 etc..
[22:47] <goddard> can i get a list of all debs in the ubuntu repositories?
[22:47] <cjwatson> sure, you can grab the Packages files from archive.ubuntu.com/dists/
[22:47] <cjwatson> er /ubuntu/dists/
[22:48] <cjwatson> 13.04 has 20477 source packages; as for binary packages,  amd64 41005  armhf 39953  i386 41054  powerpc 40161
[22:48] <mwhudson> argh
[22:48] <goddard> cjwatson: that was quick how did you get those numbers :D
[22:49] <mwhudson> anyone got some random tips for figuring out why / is being mounted read only?
[22:49] <cjwatson> goddard: I grepped the Sources and Packages files
[22:50] <cjwatson> grep-dctrl is good for advanced tricks, but for this it's sufficient to just count matches for ^Package:
[22:51] <goddard> cjwatson: so the software list is stored locally
[22:52] <cjwatson> apt fetches Packages files in order to work out what to present to you, if that's what you mean, yes
[22:53] <cjwatson> Though I ran my grep jobs on a machine with the full archive since that was faster than downloading the indices over my ADSL
[22:54] <goddard> cjwatson: still a little fuzzy to me
[22:55] <goddard> cjwatson: and you have a full archive of 13.04?
[22:56] <cjwatson> I'm an Ubuntu archive administrator ...
[22:56] <cjwatson> I have *the* full archive :-P
[22:56] <sarnold> :)
[22:56] <cjwatson> But it's all on archive.ubuntu.com
[22:56] <cjwatson> (You only need the index files for this sort of thing, not the whole enormous site)
[22:57] <infinity> mwhudson: dmesg may have enlightening info.
[22:57] <infinity> mwhudson: Controllers resetting, write/read errors, etc.
[22:58] <goddard> cjwatson: so that is like a few TB?
[22:58] <goddard> cjwatson: and thats btw
[22:58] <goddard> thanks*
[22:59] <cjwatson> dists/raring/ is 3.5GB, but that's including all the installer images and such in there
[22:59] <cjwatson> The Packages and Sources files in there are only 73MB
[23:00] <cjwatson> The whole thing is pretty enormous, sure; I don't want to trash this machine's buffer cache by running du to find out
[23:02] <mwhudson> infinity: seems to be a less deep problem actually, running mount / -o remount,rw works fine
[23:04] <infinity> mwhudson: That doesn't imply fineness.  It just means you've ignored the kernel's attempts to save you from yourself.
[23:04] <mwhudson> hmm
[23:04] <mwhudson> mountall: Plymouth command failed
[23:04] <mwhudson> mountall: Disconnected from Plymouth
[23:04] <mwhudson> mountall: Skipping mounting / since Plymouth is not available
[23:04] <infinity> Oh, or maybe it never got mounted rw in the first place.
[23:06] <mwhudson> is there some way of making that more verbose?
[23:06] <infinity> mountall is voodoo to me.  I'd suggest slangasek, but he's supposedly not here.
[23:06] <slangasek> yeah, so don't suggest me
[23:06] <infinity> (Though the error message implies that plymouth either isn't there, or isn't running... Did you break it somehow?)
[23:07] <mwhudson> i don't know how this is supposed to work
[23:07] <mwhudson> is it in the initramfs or in the rootfs?
[23:07] <infinity> That depends.
[23:08] <mwhudson> this is a 'linaro engineering build'
[23:08] <slangasek> mwhudson: that message only appears if it can't connect to plymouth *and* there's an error mounting the root filesystem
[23:08] <slangasek> so this is special++
[23:08] <infinity> If you have a FRAMEBUFFER=y initramfs config (either explicitly or transitively via something like full disk encryption), then plymouth will be in the initrd.
[23:09] <slangasek> s/full disk encryption/installation of the 'cryptsetup' package/
[23:09] <mwhudson> slangasek: i just love being special
[23:09] <infinity> Or that.
[23:09] <mwhudson> i doubt that is involved
[23:09] <infinity> mwhudson: If it's an LEB, all bets are off.  It might just be broken. :P
[23:10] <mwhudson> yeah
[23:10] <mwhudson> this very same image worked last week though :/
[23:10] <mwhudson> and if i run mount / -o remount,rw and reboot ... it works
[23:10] <infinity> A new definition of time-based release wherein the release only works one time?
[23:11] <mwhudson> i still see
[23:11] <mwhudson> mountall: Plymouth command failed
[23:11] <mwhudson> mountall: Disconnected from Plymouth
[23:11] <mwhudson> but not the skipping / one
[23:11]  * mwhudson brb
[23:34] <mwhudson> infinity, slangasek: is there some way i can make plymouth and/or mountall super verbose?
[23:34] <slangasek> mwhudson: well, from the error messages I infer that you're managing to crash plymouth, so not really
[23:35] <slangasek> (and mountall's verbose output is supposed to go *to plymouth*, so no dice there either)
[23:35] <slangasek> mwhudson: you can try to run plymouth post-boot and see what you get?
[23:35] <mwhudson> yay
[23:36] <mwhudson> root@localhost:~# plymouth --ping
[23:36] <mwhudson> root@localhost:~# echo $?
[23:36] <mwhudson> 1
[23:36] <mwhudson> i guess that's bad?
[23:36] <mwhudson> hm get the same on my system
[23:53] <slangasek> mwhudson: you would need to start plymouth first; see the /etc/init/plymouth* upstart jobs


[15:28] <rouca> Hi, I am rouca from debian, just send you a mail
[15:48] <rouca> ccdm94: thanks for all
[15:49] <ccdm94> rouca: np! Thank you for the quick response!


[19:52] <piers> Hello!
[19:54] <piers> I'm trying to understand how i can bond two network interfaces in netplan, so that I can connect to the bonded interface through the network manager GUI