[00:15] <doko> pitti, barry, infinity: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3
[00:34] <barry> pitti: LP: #1440388
[00:39] <lfaraone> stgraber: re LP #1501588 , I've heard similar reports from people in our Ubuntu deployment (and experiencing the problem myself); is downgrading wily to 2.1 (vivid's version) an acceptable fix, or would it be better to find the problematic patch and revert it?
[01:11] <stgraber> lfaraone: well, so in my case the downgrade doesn't actually solve it
[01:12] <stgraber> lfaraone: one thing I've noticed here and it may well be the source of the problem is that NM is misbehaving wrt IPv6 MTU. It's occasionally getting a frame without a MTU and so interprets it as MTU=0, it then attempts to set the interface MTU to 0, fails and falls back to the minimal MTU of 1280
[01:13] <stgraber> lfaraone: so from that point on, my network interface has a wrong MTU (1280 instead of 1500) which prevents wpa_supplicant from setting up an EAP session and leads to the error I've reported
[01:13] <stgraber> lfaraone: I only came up with that theory a couple of hours ago when noticing the wrong MTU and a lot of MTU related messages from NM in /var/log/syslog
[01:14] <stgraber> and that'd explain why downgrading the kernel, firmware and wpa_supplicant didn't do the trick here, it looks like, at least for me, the main issue is NM
[04:43] <lfaraone> I have yet to try to downgrade. I'll play with it later.
[04:44] <lfaraone> except now I can't repro :(
[09:26] <Mirv> Laney: any chance for the devel-permissions Qt thread answering?
[09:28] <Laney> I pinged the others yesterday
[10:46] <cjwatson> snakefruit (various archive cron jobs, http://people.canonical.com/~ubuntu-archive/, etc.) going down soon for a RAM upgrade
[11:30] <cjwatson> snakefruit back
[11:52] <ogra_> cjwatson, if you are interested .... my kernel package install prob from yesterday is caused by:
[11:52] <ogra_> + rm -r var/lib/dpkg var/log/apt
[11:52] <ogra_> + rm usr/bin/dpkg-query usr/bin/dpkg-split usr/bin/dpkg-divert usr/bin/dpkg-trigger usr/bin/dpkg-statoverride usr/bin/dpkg-maintscript-helper
[11:52] <ogra_> (i use the rootfs chroot after tarball creation, snappy removes dpkg ...)
[11:52] <ogra_> (or parts of it)
[12:25] <antgel> Hi all, I was referred here from #u. I'm trying to run nm-tool (or nmcli) from a user's crontab. It works from the shell, but from cron, it fails with Could not initialize NMClient /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; type="method_call", sender=":1.613" (uid=1000 pid=7278 comm="nm-tool ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.Ne
[12:27] <mgedmin> because cron has a separate environment and doesn't see your DBUS_SESSION_BUS_ADDRESS
[12:29] <antgel> mgedmin: Any pointers to where I can configure this? It seems bizarre as default, but I don't mind tweaking the config. I'll google the variable you mention in any case
[12:52] <antgel> mgedmin: Okay, I added something to pull that envvar in, and I can see it in cron via echo $DBUS_SESSION_BUS_ADDRESS. But the call still fails, in the same way. Any clues?
[14:26] <mvo_> cyphermox: looks like fwupdate-signed is in dependency wait since a couple of hours. do you know what is going on?
[14:26] <cyphermox> probably waiting for fwupdate itself, lemme look
[14:29] <cyphermox> oh, crap, missing a character.
[14:29] <cyphermox> mvo_:  yeah it's broken because yeah.
[14:31] <mvo_> cyphermox: thanks for checking
[14:41] <cyphermox> mvo_: it will be fixed shortly.
[14:45] <mvo_> ta
[14:58] <dholbach> chrisccoulson, tyhicks, smoser: do you know who's running the libv8/node.js session in the core track in a few?
[14:58] <dholbach> is it doko?
[14:58] <smoser> doko i assumed
[14:58] <dholbach> hum, he's not online
[14:59] <chrisccoulson> I saw doko at breakfast about 20 minutes ago
[15:09] <hallyn> hi - can a no-build rebuild (of vm-builder) be done in wily without the need for an SRU?  This would be to enable the build for power8.  (bug 1510720)
[15:19] <infinity> dholbach: There's a nodejs session?  Who registered it? :P
[15:20] <dholbach> infinity, http://summit.ubuntu.com/uos-1511/meeting/22590/nodejs-and-libv8-for-1604/
[15:21] <caribou> cyphermox: https://bugs.launchpad.net/ubuntu/trusty/+source/haproxy/+bug/1481737
[15:24] <cyphermox> barry: caribou: pitti: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1513110
[15:24] <cyphermox> unity, for lack of a better idea where this would need to be reported :/
[15:27] <cyphermox> barry: also; https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/1513113
[15:28] <Trevinho> cyphermox: that's a byobu bug
[15:28] <kirkland> Trevinho: I'm happy to fix that in byobu, but I need a real fix in bamf or whatever
[15:28] <barry> cyphermox: LP: #1512498
[15:29] <cyphermox> Trevinho: is it?
[15:29] <kirkland> Trevinho: in vivid, unity/bamf/whatever stopped showing the byobu icon entirely
[15:29] <cyphermox> seems very wrong if some random app can break the matching for another
[15:29] <barry> kirkland, Trevinho: you might want to dupe one of those two bugs to the other
[15:29] <Trevinho> kirkland: yeah, I need to add some support to desktop API to change that, but... It's something that's going to work only with gnome-terminal probably
[15:29] <kirkland> Trevinho: cyphermox: instead showing the gnome-terminal one
[15:29] <kirkland> cyphermox: I agree with that -- that could be a security problem, honestly
[15:29] <Trevinho> kirkland: in a meeting, we can discuss later
[15:29] <cyphermox> kirkland: stretching "security" a bit, but hey ;)
[15:30] <kirkland> cyphermox: imagine a PPA or random package in the archive that ships an icon.png which is a goatse type image, but replaces firefox/chrome's icon
[15:31] <cyphermox> heh
[15:31] <kirkland> Trevinho: so I'm happy to revert the byobu change (which I agree is wrong) as soon as the other one gets fixed;  I've left it there to call attention to the problem, which hasn't received much attention thus far :-)
[15:31] <Trevinho> Well good way to get attention :)
[15:32] <cyphermox> kirkland: Trevinho: you guys will dedupe the two bugs?
[15:32] <kirkland> Trevinho: ;-)
[15:34] <jgdx> larsu, hey, when Albert approves [1], will you be landing it too? [1] https://code.launchpad.net/~larsu/gsettings-qt/lp1503693/+merge/276190
[15:35] <larsu> jgdx: I won't, but I'll make sure somebody will ;)
[15:35] <jgdx> larsu, thanks :)
[15:35] <barry> Trevinho: have you seen LP: #1513110 ?  That's a nasty one we're all seeing here at the sprint
[15:35] <infinity> Trevinho: Nasty and entertaining!
[15:36] <infinity> Trevinho: Not only are the menus busted, but it exposes another shrinking window sizing bug. :P
[15:36] <cyphermox> it's a fun way to resize terminals though, maybe it should be a feature
[15:36] <Trevinho> infinity: don't blame me... :P It's kirkland that used the hard hand ;-)
[15:37] <infinity> Trevinho: Hrm?  Are we talking about different bugs here?
[15:37] <hallyn> arges: can a no-build rebuild of vm-builder in wily be done without an SRU?
[15:37]  * larsu is not seeing that
[15:37] <bdmurray> chrisccoulson: Could you add a comment to bug 1512099?
[15:37] <larsu> this is stock xenial?
[15:37] <kirkland> Trevinho: I don't think I've broken window sizing
[15:38] <Trevinho> infinity: ohhhh. sorry, I'm in on hangoout so so I ddid't read that properly
[15:38] <Trevinho> kirkland: no you didn't, sorry I misunderstood
[15:38] <infinity> kirkland: WAY TO GO DUSTIN.
[15:38] <infinity> kirkland: YOU BREAK EVERYTHING.
[15:38] <kirkland> muuuhahahahaha
[15:41] <cyphermox> hey, I no longer have indicators :)
[15:41] <infinity> \o/
[15:41] <infinity> cyphermox: I blame kirkland.
[15:41] <pitti> hallyn: so just running https://github.com/hallyn/lxcfs/commits/testing should suffice, I don't need a newer cgmanager to go along with this? (on xenial)
[15:41] <cyphermox> I'm waiting for the "self-destruct sequence initiated" message.
[15:43] <chiluk> slangasek: no rush.  SRU template fixed.  Not sure how I missed the testcase earlier.  bug 1509120
[15:43] <hallyn> pitti: correct, it simply doesn't use cgmanager
[15:55] <mterry> barry, is the python3 session in 5 min?
[15:55] <barry> mterry: yes
[16:09] <arges> hallyn: i'm not entirely sure
[16:13] <hallyn> stgraber: ^ do you know?  vm-builder is arch:all, not built for power8;  someone wants it in wily for power8.  Can we do a no-build rebuild without going through sru, and would that enable it for power8 in wily?
[16:21] <xnox> hallyn: no, as it will not publish as far as i can know.
[16:21] <xnox> hallyn: sru should be (a) quick and (b) fast to do / validate.
[16:31] <hallyn> xnox: and sru would then enable it for power8?
[16:32] <xnox> hallyn: that is that needs to be tested.
[16:32] <hallyn> xnox: ok, thanks :)
[16:33] <hallyn> let's try
[16:35] <hallyn> cjwatson: is there a flag that cna be set in the back end to make vm-builder in wily be enabled for power8?
[16:35]  * hallyn holds his finger over the dput button, under the assumption answer will be no
[16:37] <cjwatson> hallyn: sorry, no context, in what way is it disabled?
[16:37] <hallyn> it simply doesn't seem to be available for power8 in wily.
[16:37] <cjwatson> hallyn: an arch: all binary exists for all architectures, that's the point
[16:38] <hallyn> right, but power8 didn't exist last time vmbuilder was uploaded
[16:38] <hallyn> should that have become available anyway automatically?
[16:38] <cjwatson> hallyn: power8 is not a different architecture
[16:38] <cjwatson> hallyn: it was just a change in default toolchain for ppc64el/xenial
[16:38] <hallyn> cjwatson: bug 1510720 is the original reporter
[16:39] <cjwatson> hallyn: none of this is making any sense
[16:39] <cjwatson> hallyn: this isn't some magical archive thing, afaics the reporter is complaining that the *code* doesn't support ppc64el?
[16:39] <cjwatson> hallyn: why does it need to be architecture: any?
[16:40] <mvo_> cyphermox: yay, fwupdate-signed is now pending publication
[16:41] <hallyn> cjwatson: it doesn't
[16:41] <hallyn> disregard comment where i said that
[16:41] <cjwatson> hallyn: so I have no idea why you need to rebuild, or what a no-change rebuild would achieve
[16:41] <cjwatson> hallyn: https://launchpad.net/ubuntu/wily/ppc64el/python-vm-builder shows that it's there
[16:41] <hallyn> cjwatson: actually, i'm seeing it now on a power8 anyway.  wtf
[16:42] <hallyn> cjwatson: i thought a rebuild would magically fill in some db field saying "this exists for that platform"
[16:42] <hallyn> i was wrong
[16:42] <hallyn> cjwatson: sorry for the noise, thanks
[16:43] <cjwatson> hallyn: I think this must be talking about all the architecture conditionals in vm-builder, not about archive-level stuff
[16:44] <cjwatson> e.g. ./VMBuilder/plugins/ubuntu/maverick.py which seems to be the current list of valid flavours by inheritance
[16:44] <hallyn> cjwatson: i had wondered that at first, maybe it is that after all.
[16:44]  * hallyn wishes h'ed yanked it from the archive before 14.04
[16:44] <sarnold> when in doubt, ask reporter for a copy-paste of error messages :)
[16:45] <hallyn> sarnold: well i just tol dhim it is there, if he meant the other thing he'll shout i'm sure
[16:45] <hallyn> thanks again
[16:45] <sarnold> :)
[16:49] <cyphermox> mvo_: yep
[16:50] <seb128> doko, I think your babeltrace delta can be dropped and the package can be synced from Debian, you might want to have a look to that
[16:56] <seb128> doko, you can probably sync openexr as well
[16:58] <dkessel> mterry: looks like you had one or too looks into duplicity's codebase - i am confused what the upstream VCS for it is... is it hosted on launchpad bzr?
[16:58] <mterry> dkessel, yes
[17:00] <dkessel> mterry: oh, you even worked on a python3 port. i wondered about that while reading the the session notes from today.
[17:01] <mterry> dkessel, yeah, I've been slowly working on python3 pieces that need to get it ready
[17:01] <mterry> dkessel, next piece I was doing was strings/bytes
[17:01] <mterry> dkessel, but I never finished it
[17:01] <mterry> dkessel, and don't have time this cycle likely
[17:01] <mterry> dkessel, but would gladly help someone else!  :)
[17:03] <dkessel> mterry: well it would be great not to have duplicity require a download of python2 with all that stuff, right? :)
[17:03] <dkessel> are the dependencies all there on python3?
[17:04] <mterry> dkessel, for the core, I believe so.  For all the backed plugins, I'm less sure
[17:05] <mterry> But it would be nice to avoid the download.  Especially since *eventually* we'll need to port to py3 anyway
[17:14] <dkessel> is your port a pure manual port? or did you run 2to3 initially?
[18:15] <hjd> Could someone please trigger a rebuild of node-iconv and node-nan on Xenial? They might work a bit better now that node-gyp should be installable again :)
[18:17] <doko> seb128, done
[18:17] <seb128> doko, thanks
[18:18] <seb128> doko, I didn't follow the replies, but is there any workaround we could try for the binutils aarch64 issue that is blocking webkit? that's basically holding the cheese/evolution-data-server/poppler/libgtop/gnome-desktop transitions in xeny-proposed
[18:18] <mvo_> cyphermox: hm, fwudate-signed is still not published, should I ask someone in #ubuntu-relase to binary-NEW it?
[18:20] <mdeslaur> pitti: how can I retrigger the autopkgtest for libapache2-mod-perl2? It should be fixed by my libbsd-resource-perl upload yesterday
[18:20] <mdeslaur> which will unblock apache2, which will unblock php5, and will make me TIL on half the archive
[18:21] <doko> seb128, no, I'm on it. no work around yet
[18:22] <seb128> doko, ok, thanks
[18:22] <seb128> mdeslaur, https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[18:23] <mdeslaur> hrm, guess I can't put off installing the vpn any longer... :P
[18:25] <mdeslaur> seb128: thanks
[18:25] <seb128> mdeslaur, yw
[18:29] <doko> seb128, would you like to look at https://launchpad.net/ubuntu/+source/openexr/2.2.0-7/+build/8264422 ?
[18:45] <cjwatson> hjd: done
[18:56] <tkamppeter> slangasek, hi
[18:59] <hjd> cjwatson: ty :)  They still failed though, but looks like the initial problem is gone
[19:36] <mterry> doko, looks like you subscribed foundations team to fonts-font-awesome, but not modernizr
[19:37] <slangasek> tkamppeter: hullo
[19:39] <pitti> mdeslaur: you can't right now (needs ubuntu_archive@snakefruit), I've done it
[19:39] <pitti> mdeslaur: thanks for fixing!
[19:40] <mdeslaur> pitti: thanks!
[19:40] <doko> mterry, ugh, I thought I did ... now done
[19:40] <mterry> doko, perfect thanks  :)
[19:51] <sil2100> mterry: hey! So are those recommendations you made on the unity-api MIR bug required for changing the component to main?
[19:51] <sil2100> Or is it fine enough as is?
[20:01] <sarnold> Do we have plans on supporting ZFS in trusty's HWEs? This deserves a look, perhaps for an SRU https://bugs.launchpad.net/trusty-backports/+bug/1454740
[20:09] <machinaut> How do I send a patch for a package like `tzdata`?
[20:10] <infinity> https://mm.icann.org/mailman/listinfo/tz
[20:11] <machinaut> infinity:
[20:12] <machinaut> It's already in their package, and in the wily version of tzdata, but not the precise (12.04) version of tzdata.
[20:12] <infinity> machinaut: precise has the same version as wily.
[20:12] <infinity> (base)adconrad@nosferatu:~$ rmadison -a source tzdata | egrep 'precise|wily'
[20:12] <infinity>  tzdata | 2012b-1              | precise          | source
[20:12] <infinity>  tzdata | 2015g-0ubuntu0.12.04 | precise-security | source
[20:13] <infinity>  tzdata | 2015g-0ubuntu0.12.04 | precise-updates  | source
[20:13] <infinity>  tzdata | 2015g-1              | wily             | source
[20:13] <machinaut> On my wily machine tzdata is version "2015g-1" and on precise its "2015g-0ubuntu0.12.04".  What's missing is a leap-seconds file.
[20:13] <infinity> machinaut: Oh. Yes, I didn't backport that change intentionally.
[20:14] <machinaut> Crap.  Exactly that backport was what I was looking for.  Whats the reason?
[20:14] <infinity> I don't backport packaging changes, only zone info changes.
[20:14] <infinity> If you file a bug justifying why you want/need the leap second file (running an ntp server and want to point at it?), I can perhaps SRU just for that.
[20:15] <machinaut> Is there any way to get leap-seconds otherwise on a precise system?
[20:15] <infinity> The canonical URL for it is... Hold on.
[20:16] <infinity> https://www.ietf.org/timezones/data/leap-seconds.list
[20:17] <machinaut> I was looking for a operating-system provided method (cant hit the web for other reasons).  I think I might just parse it out of the 'right/UTC' zoneinfo then.
[20:17] <machinaut> infinity: will precise continue to get leap-second updates to its 'right/' timezone infos?
[20:18] <infinity> machinaut: Yeah.
[20:18] <infinity> machinaut: I can ship the leap second file too in a future update, just file a bug with a justification and I'll make it happen on the next upstream bump.
[20:19] <machinaut> Roger, wilco, thanks!
[20:32] <dobey> the problem with watching the uos sessions after the fact, is that you can't just go round pinging the people while you're listening to it
[21:43] <cyphermox> kirkland: Trevinho: barry: I think we want to revert that revert: https://git.gnome.org/browse/gnome-terminal/commit/?id=b735feff4ca0a88b389a89d151bb075bf39e32f8
[21:45] <Trevinho> cyphermox: yeah that would be the easiest fix..
[21:46] <Trevinho> cyphermox: however, being a gnome-terminal-server just a single instance, is this working for all the created  windows?
[21:46] <cyphermox> Trevinho: I don't know, I haven't tried
[21:46] <Trevinho> i.e. if you've a gnome-terminal and a byobu instance open, will this cause any issue?
[21:46] <Trevinho> ok
[21:46] <Trevinho> but being on terminal-app... Maybe...
[21:47] <Trevinho> it seems reasonable, though
[21:57] <Laney> You can see from the referenced bug that both desrt and larsu have worked on this issue
[21:57] <Laney> I think you should talk to them and work it through upstream
[21:57]  * Laney isn't really here though - bye :)
[21:58] <Trevinho> Laney spotted!