[00:15] pitti, barry, infinity: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3 [00:34] pitti: LP: #1440388 [00:34] Launchpad bug 1440388 in ubuntu-system-service (Ubuntu) "please port ubuntu-system-service to Python3" [Undecided,Fix committed] https://launchpad.net/bugs/1440388 [00:39] 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? [00:39] Launchpad bug 1501588 in wpa (Ubuntu) "Wily's wpasupplicant frequently fails on WPA enterprise networks" [Critical,Confirmed] https://launchpad.net/bugs/1501588 [01:11] lfaraone: well, so in my case the downgrade doesn't actually solve it [01:12] 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] 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] 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] 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 === nudtrobert1 is now known as nudtrobert === ubott2 is now known as ubottu === Ursinha-afk_ is now known as Ursinha === Ursinha is now known as Guest82331 === inaddy is now known as tinoco === rsalveti_ is now known as rsalveti === psivaa_ is now known as psivaa === czchen_ is now known as czchen === plars_ is now known as plars === broder_ is now known as broder === balkamos_ is now known as balkamos === Guest82331 is now known as Ursinha === Ursinha is now known as ursula1234 === ursula1234 is now known as Ursinha === elijah_ is now known as elijah [04:43] I have yet to try to downgrade. I'll play with it later. [04:44] except now I can't repro :( === dcmorton_ is now known as dcmorton === larsu_ is now known as larsu === jamesh_ is now known as jamesh === dholbach_ is now known as dholbach [09:26] Laney: any chance for the devel-permissions Qt thread answering? [09:28] I pinged the others yesterday [10:46] snakefruit (various archive cron jobs, http://people.canonical.com/~ubuntu-archive/, etc.) going down soon for a RAM upgrade === marcusto_ is now known as marcustomlinson_ === marcustomlinson_ is now known as marcustomlinson [11:30] snakefruit back [11:52] cjwatson, if you are interested .... my kernel package install prob from yesterday is caused by: [11:52] + rm -r var/lib/dpkg var/log/apt [11:52] + 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] (i use the rootfs chroot after tarball creation, snappy removes dpkg ...) [11:52] (or parts of it) [12:25] 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] because cron has a separate environment and doesn't see your DBUS_SESSION_BUS_ADDRESS [12:29] 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 === _salem is now known as salem_ [12:52] 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? === niedbalski_ is now known as niedbalski === gammax is now known as nic === nic is now known as gammax === happyaro1 is now known as happyaron === happyaron is now known as Guest39250 === Guest39250 is now known as happyaron === hikiko is now known as hikiko|ln [14:26] cyphermox: looks like fwupdate-signed is in dependency wait since a couple of hours. do you know what is going on? [14:26] probably waiting for fwupdate itself, lemme look === mardy_ is now known as mardy [14:29] oh, crap, missing a character. [14:29] mvo_: yeah it's broken because yeah. [14:31] cyphermox: thanks for checking === hikiko|ln is now known as hikiko [14:41] mvo_: it will be fixed shortly. [14:45] ta [14:58] chrisccoulson, tyhicks, smoser: do you know who's running the libv8/node.js session in the core track in a few? [14:58] is it doko? [14:58] doko i assumed [14:58] hum, he's not online [14:59] I saw doko at breakfast about 20 minutes ago [15:09] 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:09] bug 1510720 in vm-builder (Ubuntu) "vm-builder doesn't support ppc64el" [Medium,Fix released] https://launchpad.net/bugs/1510720 [15:19] dholbach: There's a nodejs session? Who registered it? :P [15:20] infinity, http://summit.ubuntu.com/uos-1511/meeting/22590/nodejs-and-libv8-for-1604/ [15:21] cyphermox: https://bugs.launchpad.net/ubuntu/trusty/+source/haproxy/+bug/1481737 [15:21] Launchpad bug 1481737 in haproxy (Ubuntu Trusty) "HAProxy init script does not work correctly with nbproc configuration option" [Medium,In progress] [15:24] barry: caribou: pitti: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1513110 [15:24] unity, for lack of a better idea where this would need to be reported :/ [15:24] Launchpad bug 1513110 in unity (Ubuntu) "global menus are broken and cannot be clicked" [Undecided,New] [15:27] barry: also; https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/1513113 [15:27] Launchpad bug 1513113 in bamf (Ubuntu) "name to icon matching for Terminal broken in xenial" [Undecided,New] [15:28] cyphermox: that's a byobu bug [15:28] Trevinho: I'm happy to fix that in byobu, but I need a real fix in bamf or whatever [15:28] cyphermox: LP: #1512498 [15:29] Launchpad bug 1512498 in gnome-terminal (Ubuntu) "gnome-terminal thinks it's Byobu Terminal" [High,Confirmed] https://launchpad.net/bugs/1512498 [15:29] Trevinho: is it? [15:29] Trevinho: in vivid, unity/bamf/whatever stopped showing the byobu icon entirely [15:29] seems very wrong if some random app can break the matching for another [15:29] kirkland, Trevinho: you might want to dupe one of those two bugs to the other [15:29] 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] Trevinho: cyphermox: instead showing the gnome-terminal one [15:29] cyphermox: I agree with that -- that could be a security problem, honestly [15:29] kirkland: in a meeting, we can discuss later [15:29] kirkland: stretching "security" a bit, but hey ;) [15:30] 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] heh [15:31] 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] Well good way to get attention :) [15:32] kirkland: Trevinho: you guys will dedupe the two bugs? [15:32] Trevinho: ;-) [15:34] 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] jgdx: I won't, but I'll make sure somebody will ;) [15:35] larsu, thanks :) [15:35] Trevinho: have you seen LP: #1513110 ? That's a nasty one we're all seeing here at the sprint [15:35] Launchpad bug 1513110 in unity (Ubuntu) "global menus are broken and cannot be clicked" [High,Confirmed] https://launchpad.net/bugs/1513110 [15:35] Trevinho: Nasty and entertaining! [15:36] Trevinho: Not only are the menus busted, but it exposes another shrinking window sizing bug. :P [15:36] it's a fun way to resize terminals though, maybe it should be a feature [15:36] infinity: don't blame me... :P It's kirkland that used the hard hand ;-) [15:37] Trevinho: Hrm? Are we talking about different bugs here? [15:37] 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] chrisccoulson: Could you add a comment to bug 1512099? [15:37] this is stock xenial? [15:37] bug 1512099 in firefox (Ubuntu Wily) "Don't report plugin-container crashes with Apport" [Undecided,Triaged] https://launchpad.net/bugs/1512099 [15:37] Trevinho: I don't think I've broken window sizing [15:38] infinity: ohhhh. sorry, I'm in on hangoout so so I ddid't read that properly [15:38] kirkland: no you didn't, sorry I misunderstood [15:38] kirkland: WAY TO GO DUSTIN. [15:38] kirkland: YOU BREAK EVERYTHING. [15:38] muuuhahahahaha [15:41] hey, I no longer have indicators :) [15:41] \o/ [15:41] cyphermox: I blame kirkland. [15:41] 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] I'm waiting for the "self-destruct sequence initiated" message. [15:43] slangasek: no rush. SRU template fixed. Not sure how I missed the testcase earlier. bug 1509120 [15:43] bug 1509120 in nfs-utils (Ubuntu) "Process accounting deadlock with idmapd callout when writing to NFSv4 mount" [Medium,In progress] https://launchpad.net/bugs/1509120 [15:43] pitti: correct, it simply doesn't use cgmanager [15:55] barry, is the python3 session in 5 min? [15:55] mterry: yes [16:09] hallyn: i'm not entirely sure [16:13] 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] hallyn: no, as it will not publish as far as i can know. [16:21] hallyn: sru should be (a) quick and (b) fast to do / validate. === francisco is now known as Guest47869 [16:31] xnox: and sru would then enable it for power8? [16:32] hallyn: that is that needs to be tested. [16:32] xnox: ok, thanks :) [16:33] let's try [16:35] 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] hallyn: sorry, no context, in what way is it disabled? [16:37] it simply doesn't seem to be available for power8 in wily. [16:37] hallyn: an arch: all binary exists for all architectures, that's the point [16:38] right, but power8 didn't exist last time vmbuilder was uploaded [16:38] should that have become available anyway automatically? [16:38] hallyn: power8 is not a different architecture [16:38] hallyn: it was just a change in default toolchain for ppc64el/xenial [16:38] cjwatson: bug 1510720 is the original reporter [16:38] bug 1510720 in vm-builder (Ubuntu) "vm-builder doesn't support ppc64el" [Medium,Fix released] https://launchpad.net/bugs/1510720 [16:39] hallyn: none of this is making any sense [16:39] hallyn: this isn't some magical archive thing, afaics the reporter is complaining that the *code* doesn't support ppc64el? [16:39] hallyn: why does it need to be architecture: any? [16:40] cyphermox: yay, fwupdate-signed is now pending publication [16:41] cjwatson: it doesn't [16:41] disregard comment where i said that [16:41] hallyn: so I have no idea why you need to rebuild, or what a no-change rebuild would achieve [16:41] hallyn: https://launchpad.net/ubuntu/wily/ppc64el/python-vm-builder shows that it's there [16:41] cjwatson: actually, i'm seeing it now on a power8 anyway. wtf [16:42] cjwatson: i thought a rebuild would magically fill in some db field saying "this exists for that platform" [16:42] i was wrong [16:42] cjwatson: sorry for the noise, thanks [16:43] hallyn: I think this must be talking about all the architecture conditionals in vm-builder, not about archive-level stuff [16:44] e.g. ./VMBuilder/plugins/ubuntu/maverick.py which seems to be the current list of valid flavours by inheritance [16:44] 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] when in doubt, ask reporter for a copy-paste of error messages :) [16:45] sarnold: well i just tol dhim it is there, if he meant the other thing he'll shout i'm sure [16:45] thanks again [16:45] :) [16:49] mvo_: yep [16:50] 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] doko, you can probably sync openexr as well [16:58] 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] dkessel, yes [17:00] mterry: oh, you even worked on a python3 port. i wondered about that while reading the the session notes from today. [17:01] dkessel, yeah, I've been slowly working on python3 pieces that need to get it ready [17:01] dkessel, next piece I was doing was strings/bytes [17:01] dkessel, but I never finished it [17:01] dkessel, and don't have time this cycle likely [17:01] dkessel, but would gladly help someone else! :) [17:03] mterry: well it would be great not to have duplicity require a download of python2 with all that stuff, right? :) [17:03] are the dependencies all there on python3? [17:04] dkessel, for the core, I believe so. For all the backed plugins, I'm less sure [17:05] But it would be nice to avoid the download. Especially since *eventually* we'll need to port to py3 anyway [17:14] is your port a pure manual port? or did you run 2to3 initially? [18:15] 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] seb128, done [18:17] doko, thanks [18:18] 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] cyphermox: hm, fwudate-signed is still not published, should I ask someone in #ubuntu-relase to binary-NEW it? [18:20] pitti: how can I retrigger the autopkgtest for libapache2-mod-perl2? It should be fixed by my libbsd-resource-perl upload yesterday [18:20] which will unblock apache2, which will unblock php5, and will make me TIL on half the archive [18:21] seb128, no, I'm on it. no work around yet [18:22] doko, ok, thanks [18:22] mdeslaur, https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests [18:23] hrm, guess I can't put off installing the vpn any longer... :P [18:25] seb128: thanks [18:25] mdeslaur, yw [18:29] seb128, would you like to look at https://launchpad.net/ubuntu/+source/openexr/2.2.0-7/+build/8264422 ? [18:45] hjd: done === bipul_ is now known as bipul [18:56] slangasek, hi [18:59] cjwatson: ty :) They still failed though, but looks like the initial problem is gone [19:36] doko, looks like you subscribed foundations team to fonts-font-awesome, but not modernizr [19:37] tkamppeter: hullo [19:39] mdeslaur: you can't right now (needs ubuntu_archive@snakefruit), I've done it [19:39] mdeslaur: thanks for fixing! [19:40] pitti: thanks! [19:40] mterry, ugh, I thought I did ... now done [19:40] doko, perfect thanks :) [19:51] mterry: hey! So are those recommendations you made on the unity-api MIR bug required for changing the component to main? [19:51] Or is it fine enough as is? [20:01] 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:01] Launchpad bug 1454740 in utopic-backports "Please backport libguestfs 1:1.28.6-1ubuntu1 (universe) from vivid" [Undecided,New] [20:09] How do I send a patch for a package like `tzdata`? [20:10] https://mm.icann.org/mailman/listinfo/tz [20:11] infinity: [20:12] It's already in their package, and in the wily version of tzdata, but not the precise (12.04) version of tzdata. [20:12] machinaut: precise has the same version as wily. [20:12] (base)adconrad@nosferatu:~$ rmadison -a source tzdata | egrep 'precise|wily' [20:12] tzdata | 2012b-1 | precise | source [20:12] tzdata | 2015g-0ubuntu0.12.04 | precise-security | source [20:13] tzdata | 2015g-0ubuntu0.12.04 | precise-updates | source [20:13] tzdata | 2015g-1 | wily | source [20:13] 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] machinaut: Oh. Yes, I didn't backport that change intentionally. [20:14] Crap. Exactly that backport was what I was looking for. Whats the reason? [20:14] I don't backport packaging changes, only zone info changes. [20:14] 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] Is there any way to get leap-seconds otherwise on a precise system? [20:15] The canonical URL for it is... Hold on. [20:16] https://www.ietf.org/timezones/data/leap-seconds.list [20:17] 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] infinity: will precise continue to get leap-second updates to its 'right/' timezone infos? [20:18] machinaut: Yeah. [20:18] 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] Roger, wilco, thanks! [20:32] 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 === salem_ is now known as _salem [21:43] kirkland: Trevinho: barry: I think we want to revert that revert: https://git.gnome.org/browse/gnome-terminal/commit/?id=b735feff4ca0a88b389a89d151bb075bf39e32f8 [21:45] cyphermox: yeah that would be the easiest fix.. [21:46] cyphermox: however, being a gnome-terminal-server just a single instance, is this working for all the created windows? [21:46] Trevinho: I don't know, I haven't tried [21:46] i.e. if you've a gnome-terminal and a byobu instance open, will this cause any issue? [21:46] ok [21:46] but being on terminal-app... Maybe... [21:47] it seems reasonable, though [21:57] You can see from the referenced bug that both desrt and larsu have worked on this issue [21:57] I think you should talk to them and work it through upstream [21:57] * Laney isn't really here though - bye :) [21:58] Laney spotted! === nobuto_ is now known as nobuto === _salem is now known as salem_ === salem_ is now known as _salem