[02:35] <pitti> Good morning
[02:36] <sarnold> good morning pitti :)
[02:40] <pitti> sarnold: just looking again, there are 195 unretraced issues; for some reason I now get tons of hash sum mismatches/download errors from Launchpad debs
[02:40] <sarnold> pitti: ugh :/
[02:48] <pitti> bdmurray: the downloaded debs say "None of the range-specifier values in the Range request-header field overlap the current extent of the selected resource."
[02:49] <pitti> bdmurray: whatever that wants to tell me :/
[02:52] <TJ-> pitti: Client user agent is asking for  e.g. byte-range 1000000-1005000 but the resource on the server is only 999999 bytes long
[02:53] <sarnold> but why would apt download byte ranges instead of the entire file?
[02:53] <TJ-> multiple connections?
[02:53] <pitti> I suppose this is from the fallback for downloading debs/ddebs directly from Launchpad
[04:13] <tjaalton> infinity: no u-s-d running?
[04:13] <tjaalton> infinity: that's usually the case, or such. it can't/doesn't load the prefs
[04:15] <tjaalton> and thanks for fixing piuparts :)
[04:40] <pitti> smoser: is there some way to disable the overlayroot=tmpfs? With merely dropping it I can't log into the VM at all any more
[04:41] <pitti> smoser: or maybe use a permanent overlay?
[05:34] <doko> pitti, looking at the failed autopkg tests triggered by python-apt ... these seem to succeed, but the status update seems to be delayed for some hours
[05:57] <doko> sitter, https://launchpad.net/ubuntu/+source/kde4libs/4:4.14.12-0ubuntu2
[06:00] <sitter> brrr
[06:34] <tjaalton> how to disable apparmor temporarily? aa-status shows profiles are in enforced mode even after "stopping" apparmor, same thing if I try aa-complain /etc/apparmor.d/*
[06:35] <jjohansen> tjaalton: desktop/server?
[06:35] <tjaalton> jjohansen: desktop
[06:35] <jjohansen> tjaalton: stop does nothing to apparmor
[06:35] <tjaalton> ok
[06:35] <tjaalton> how useful :)
[06:35] <jjohansen> you can use teardown
[06:35] <jjohansen> which will unload all the profiles
[06:36] <jjohansen> tjaalton: its because stopping apparmor puts the system in a bad state, you can't just restart it
[06:36] <tjaalton> jjohansen: yep, that seems to work
[06:36] <jjohansen> you need to restart all the servcies as well
[06:36] <jjohansen> tjaalton: you can also use apparmor=0 on the grub kernel command line to disable it for that boot
[06:37] <tjaalton> yeah noticed that, didn't want to reboot
[06:37] <tjaalton> debugging an issue running tests in sbuild
[06:37] <tjaalton> fails on ubuntu, works on debian
[06:37] <tjaalton> (sssd)
[06:37] <tjaalton> so trying this just for fun
[07:10] <pitti> barry: python-pex fails on armhf/ppc64el now: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#wheel
[07:10] <pitti> barry: it seems there is no "./script" to run there?
[07:11] <pitti> barry: it succeeds on i386/amd64, so this looks like a built file; maybe the file exists, but it has a nonexisting hash-bang, i. e. missing test dep?
[07:26] <dholbach> good morning
[07:54] <tjaalton> when trying to upload to my own ppa I get "Half-converted block: incoming --> ~%(ppa)s", using dput-ng
[07:55] <tjaalton> anyone know how to fix it?
[07:56] <tjaalton> all the other ppa's in .dput.cf work
[08:00] <wgrant> tjaalton: What's your dput commandline and your .dput.cf?
[08:01] <wgrant> PPAs haven't required a custom .dput.cf for many years.
[08:01] <wgrant> Since, like, Jaunty or something.
[08:03] <tjaalton> wgrant: this is the "default" ppa which doesn't work http://pastebin.com/KZQQsfCw
[08:03] <tjaalton> and note i'm using dput-ng
[08:04] <tjaalton> could just be a bug in it actually
[08:04] <cjwatson> That's not the default dput-ng config though
[08:04] <wgrant> tjaalton: Hm, nowadays it's just "dput ppa:tjaalton/ppa"
[08:04] <wgrant> I don't know if dput-ng supports that syntax, but I'd hope so...
[08:04] <cjwatson> Not if you've manually modified incoming like that though
[08:04] <tjaalton> yeah could be I've messed it since it started complaining
[08:05] <cjwatson> The default is   incoming = ~%(ppa)s
[08:05] <cjwatson> you probably want to set it back to that and use ppa:tjaalton/ppa or ppa:tjaalton/ubuntu/ppa
[08:06] <tjaalton> so can't just use "dput alias foo_sources"=
[08:06] <tjaalton> ?
[08:07] <wgrant> If you want to have a stanza for each PPA you can.
[08:07] <tjaalton> since it still complains even if I change incoming to "incoming = ~%(ppa)s"
[08:07] <wgrant> What exactly does your config look like, and what is the command you're running?
[08:07] <wgrant> If you have a variable in incoming, you need to have a value for that variable in the commandline.
[08:08] <tjaalton> ahah, so can't use that then
[08:09] <tjaalton> it's like on pastebin
[08:09] <wgrant> The pastebinned version doesn't use a variable, though.
[08:09] <tjaalton> no, since apparently it wouldn't work
[08:09] <wgrant> With that one, you can indeed just "dput ppa whatever.changes"
[08:09] <tjaalton> nope
[08:09] <tjaalton> doesn't work
[08:09] <wgrant> It does, if it's in the right config file.
[08:09] <tjaalton> my "test" ppa with "~tjaalton/test/ubuntu" works
[08:10] <wgrant> Unless dput-ng doesn't let you override existing stanzas, or something weird like that.
[08:10] <wgrant> Most people just use the default 'ppa' stanza in /etc/dput.cf, which uses the variable.
[08:10] <tjaalton> oh
[08:11] <tjaalton> yeah now I see that /etc/dput.cf has the same stanza name
[08:11] <tjaalton> yep, and having it in .dput.cf doesn't override the default, so had to rename mine
[08:12] <tjaalton> then it works
[08:12] <tjaalton> thanks :)
[08:12] <wgrant> Interesting.
[08:12] <wgrant> With normal dput, ~/.dput.cf wins.
[08:12] <Laney> infinity: Did you fix it?
[08:12] <Laney> It sounds like unity-settings-daemon went south
[08:14] <tjaalton> wgrant: guess I'll file a bug against dput-ng
[08:17] <tjaalton> now to the real issue.. certain sssd tests fail to run on launchpad and my own sbuilder created by mk-sbuild, but pass fine with the howto from https://wiki.debian.org/sbuild
[08:17] <pete-woods> pitti: hey! another PR for dbusmock https://github.com/martinpitt/python-dbusmock/pull/13/files
[08:18] <pete-woods> landing into the overlay vital (fixes important deficiency in connection activation)
[08:18] <pete-woods> thanks for your time, in advance! :)
[08:20] <infinity> Laney: unity-settings-daemon appears to be running.
[08:21] <Laney> anything in ~/.cache/upstart/unity-settings-daemon.log?
[08:21] <cjwatson> tjaalton: I'd start by diffing the installed package sets in the chroots (or maybe even diff -ru'ing the chroots)
[08:21] <infinity> Laney: (unity-settings-daemon:1355): GLib-GIO-CRITICAL **: g_dbus_proxy_get_object_path: assertion 'G_IS_DBUS_PROXY (proxy)' failed
[08:21] <infinity> Laney: Over and over.
[08:21] <infinity> Laney: That's it.
[08:21] <Laney> Sounds bad
[08:22] <tjaalton> cjwatson: actually, it might be caused by the overlay, I'll test that first. Testing it with sid and on sid, so the package sets should be identical :)
[08:23] <cjwatson> Oh, you mean sid passes but wily fails
[08:23] <cjwatson> OK, certainly could be all kinds of reasons for that
[08:24] <tjaalton> sid passes on sbuild with a tarball based chroot, fails with sid on my own ubuntu host and a sid vm with overlay-sbuild
[08:24] <tjaalton> so building sid on wily fails (has always failed), building sid on sid w. tarball works
[08:26] <lavii> hello to all
[08:26] <lavii> as i am completely new to the ubuntu development. I am intrested in to fixing the bugs. so please help me form where i will start ???????
[08:26] <cjwatson> tjaalton: There's no particular guarantee that the package sets are identical and you should check
[08:26] <cjwatson> lavii: https://wiki.ubuntu.com/UbuntuDevelopment has various starting points
[08:29] <lavii> sir, i start studying the packing guide
[08:29] <tjaalton> cjwatson: ok
[08:31] <lavii> cjwatson: thanks sir
[08:43] <pitti> pete-woods: ack, will look; I have another one pending too
[08:43] <pete-woods> pitti: I think there might still be some TODOs in jonas' powerd one
[08:51] <cpaelzer> lavii: I totally like the doc cjwatson referred to, on top I sometimes like to read the same in "multiple views", so if you want you can also look at http://packaging.ubuntu.com/html/index.html especially section 4 and 5
[08:58] <lavii> cpaelzer: Yes sir i also studying that sections....
[08:59] <doko> Mirv, qtmake's defaults seem to be wrong on arm64:
[08:59] <doko> $ fgrep -r -- -m64 /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/
[08:59] <doko> /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/qmake.conf:QMAKE_CFLAGS            = -m64
[08:59] <doko> /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/qmake.conf:QMAKE_LFLAGS            = -m64
[09:00] <doko> there is no -m64 on this architecture
[09:19] <seb128> mvo_, hey, saw bug #1503052? unsure if that's fixed with your rebuilds, but if some abi changed shouldn't the package name change or the library breaks on things?
[09:20] <sitter> doko: kde4libs should be fixed in new upload. thanks for pointing it out
[09:26] <tjaalton> cjwatson: ok, so extracted the tarball and made it an overlay schroot and tests pass there fine. package diff doesn't show much http://pastebin.com/kaQYx7E7
[09:27] <cjwatson> ok, you probably know better than I do at this point :)
[09:27] <tjaalton> heh, ok
[09:27] <tjaalton> I'll let upstream replicate the setup and figure out why they fail
[09:31] <infinity> Laney: Very helpful analysis. :P
[09:35] <Laney> infinity: Sorry, I got distracted :(
[09:36] <Laney> infinity: Does the problem still happen after a restart of unity-settings-daemon (and/or your session)?
[09:36] <Laney> If so, maybe a backtrace with G_DEBUG=fatal-criticals would be good
[09:36] <Laney> Assuming those criticals are current and the log isn't stale...
[09:36] <infinity> Laney: So, killing u-s-d mostly fixed it, and relogging then was happy.  But rebooting returned it to the broken state.
[09:37] <infinity> Laney: Which might point to something racey going on.
[09:37] <mvo_> seb128: I have a look. the problem is that the abi name between debian and ubuntu was the same but the abi was actually incompatible because of a slightly different patchset for the gcc5 transition
[09:37] <infinity> Laney: But also need sleep, so maybe I'll try to come up with a consistent reproducer tomorrow and file a bug.
[09:38] <pitti> hey infinity!
[09:38] <Laney> If it's giving you criticals you can find out where those are coming from with G_DEBUG=fatal-criticals
[09:38] <pitti> infinity: what still needs to happen for bug 1435466?
[09:38] <Laney> might point out what is racing with what
[09:38] <Laney> infinity: 'night
[09:38] <pitti> infinity: oh, nevermind then -- good night!
[09:38] <Laney> Or maybe there are more warnings/criticals at startup time
[09:39] <Laney> Also unity-settings-daemon --replace --debug is good to know
[09:39] <infinity> seb128: There is a Breaks from libapt-pkg to aptitude.
[09:39] <Laney> But not that helpful if replacing doesn't fix the problem
[09:39] <infinity> seb128: Which is probably good enough for upgrade, now that it's all migrated.  THere was just a window where it kinda went a bit oops.
[09:40] <infinity> pitti: See my PPA with all the build failures, or for a good example, see node-srs in wily-proposed compared to sid.
[09:40] <Laney> srs business
[09:41] <pitti> infinity: ah, so it's not just missing manual testing, but fixing tons of packages too
[09:41] <seb128> mvo_, thanks
[09:41] <infinity> pitti: There's something fishy going on where forking gcc from node build scripts is breaking on Ubuntu but not Debian, need to sort out if (a) that's a regression we can blame on node4, and then decide how/when to fix it.
[09:41] <mvo_> seb128: sorry for this, there was no better way to fix this (because it was already broken)
[09:42] <seb128> mvo_, no worry
[09:42] <infinity> mvo_: aptitude is fine how with the rebuild, AFAICT, I'd just close that bug if I were you.  We could have been more anal with an exact shlibdep version to force the issue, but I don't see this being a real problem for upgrades now that the world has migrated.
[09:42] <Mirv> doko: ok. do you think it's used somewhere? I googled a bit and https://codereview.qt-project.org/#/c/81010/ ended with "Abandoned, It is actually not needed, jsu a matter of calling the non-64 mkspec"
[09:42] <Mirv> (from a Debian maintainer)
[09:43] <doko> Mirv, but the non-64 mkspec is missing a lot of the defines and includes in qplatformdefs.h
[09:43] <infinity> mvo_: The problem would have been that aptitude migrated before apt (due to the lack of exact shlibdep), I suspect, but I'm not really worried about that upgrade order being a problem now.
[09:44] <mvo_> infinity: yeah, I just checked in a schroot, looks fine in wily-current
[09:46] <Mirv> doko: ok. if you could file a Debian bug against qtbase-opensource-src to state what's needed/missing I can discuss with the pkg-kde folks to see whether it needs an upstream bug report or what.
[09:57]  * doko is removing libav
[09:59] <didrocks> doko: hey, did you get any progress on python 3.4.3 regression in trusty with barry?
[10:00] <doko> didrocks, no, didn't get feedback from barry
[10:02] <didrocks> doko: do you mind checking with him again? this regression is hurting badly in particular people using python in professional environment
[10:02] <doko> didrocks, yeah, can ping him again
[10:02] <didrocks> thx
[10:09] <doko> Mirv, https://bugs.launchpad.net/debian/+source/qtbase-opensource-src/+bug/1503207
[10:22] <Mirv> doko: thanks!
[12:43] <smoser> pitti, i'm sorry. what was your question ?
[12:44] <smoser> wrt disable overlayroot=?
[12:48] <smoser> pitti, what i was doing to persist changes is just to mount-image-callback the original image and then make changes and then boot a new one. but i'll poke for a minute on getting a overlay to a disk.
[12:50] <pitti> smoser: right, that's what I've done
[12:50] <pitti> smoser: so this particular one is fixed now, but I'm sure the next bug will come :)
[13:25] <smoser> pitti, where is 'fix-committed' committed ?
[13:26] <pitti> smoser: as in "it's in proposed" (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#open-iscsi)
[13:26] <pitti> smoser: I'm looking at the nova arm failure, just doing too many things at once
[13:28] <smoser> pitti, thanks.
[13:28] <smoser> i added some stuff to http://bazaar.launchpad.net/~smoser/maas/maas-ephemeral-sniff/revision/21
[13:28] <smoser> mainly:
[13:28] <smoser> a.) link to xkvm for you
[13:29] <smoser> b.) suport for OVERLAY_DISK so you can get changes persisted.
[13:30] <smoser> pitti, do you think just creating the /run/resolvconf/interface is the right thing to do ?
[13:30] <smoser> rather than 'resolvconf --enable-updates'
[13:30] <smoser> oh. wait.l that doesn't even do the mkdir itself.
[13:31] <pitti> smoser: cool, thanks!
[13:31] <smoser> i guess this is fine. unfortunate that we code that path in 2 places now.
[13:31] <pitti> smoser: yes, like that we don't duplicate the --enable-updates, and don't break update-rc.d disable resolvconf
[13:31] <pitti> smoser: this just puts the info into /run, and when resolvconf starts up for real, it'll see it
[13:32] <pitti> smoser: worked fine in my testing, even with the additional "sleep 5" in resolvconf's unit to make it guaranteed-later than the udev rules
[13:32] <pitti> smoser: yes, it's indeed not elegant, but with all the poking in ifupdown's innards that's going on there it doesn't make things much worse..
[13:33] <smoser> yeah, i think its fine.
[13:33] <smoser> it was guaranteed after 'mounted MOUNTPOINT=/run' in upstart boot
[13:33] <smoser> which was when rsolvconf ran.
[13:33] <smoser> its good. thank you.
[13:34] <pitti> smoser: how was that guaranteed?
[13:34] <smoser> because openiscsi ran after that.
[13:34] <pitti> smoser: /run is pretty much the first thing that gets mounted (in fact, already by initramfs), so this isn't any real ordering restriction
[13:34] <sil2100> doko: I'm looking now into the ubuntuone-client-data amd64 build failure, filling in a bug to track it
[13:35] <sil2100> doko: I generally fill in a bug for every FTBFS I'm working on if anything
[13:35] <pitti> smoser: right, but so did the udev rules; we just didn't have these rules in the past, but an upstart job
[13:35] <smoser> pitti, in upstart *resolvconf* job ran on  mounted /run. so it ran very early, and that would block other stuff.  anything afeter virtual-mounts or whatever that event was.
[13:35] <smoser> right.
[13:35] <pitti> smoser: ah, resolvconf's upstart job blocked the udevadm trigger job?
[13:36] <pitti> that would have done it (but sounds a bit odd)
[13:36] <pitti> smoser: I thought about ordering resolvconf.service before systemd-udev-trigger.service, but it seemed unnecessary serialization
[13:36] <pitti> smoser: it would work too, though
[13:37] <smoser> pitti, well, we get to do this again for networkd :)
[13:38] <pitti> smoser: heh, argh yes
[13:38] <smoser> other parts of this setup will break there too.
[13:39] <smoser> cloud-initramfs-dyn-netconf reads initramfs 'ip=' stuff and writes /etc/network/interface style files.
[14:09] <popey> Got a bug for you lovely foundations people :) - just install nvidia-current on my MacBook Pro running 15.10 and now I can't type in my LUKS password. text doesn't go in the box, but over the top of the plymouth splash... http://imgur.com/mlCVqpL
[14:13] <seb128> popey, 1386005 ?
[14:14] <seb128> popey, seems like slangasek / cyphermox were looking at it at least
[14:17] <cyphermox> popey: please file a new bug report
[14:18] <cyphermox> use apport, so we got all that we need...
[14:18] <popey> cyphermox: file the bug against plymouth?
[14:19] <cyphermox> yes please
[14:19] <popey> ok
[14:20] <barry> didrocks: i'd like to get doko's opinion on LP: #1500768
[14:23] <popey> cyphermox: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1503306
[14:23] <popey> cyphermox: let me know if there's anything else you want from it
[14:23] <cyphermox> popey: thanks.
[14:23] <popey> np
[14:29] <cyphermox> oh yay, I think I see a possible fix
[14:34] <didrocks> barry: doko: another option, as the python new release introduces a regression, if this can't be fixed properly, is to revert…
[14:34] <seb128> barry, didrocks is right, you can't land a regression through -updates and deal with it through -backport letting LTS users with broken code by our fault
[14:35] <seb128> barry, either we fix the components that are impacted, through -updates, or if we can't then we revert the change
[14:35] <didrocks> while we are speaking about it, I have yet another bug opened due to this…
[14:35] <didrocks> https://github.com/ubuntu/ubuntu-make/issues/156
[14:35] <seb128> barry, LTS doesn't claim to be perfect, we prefer stability/not breaking exising users over fixing bugs that were there
[14:37] <seb128> barry, let the incompatibile behaviour change to people doing serie upgrades, users on stable updates should be able to run production code without having risk to hit failures because things become incompatible
[14:39] <sil2100> doko, seb128: working on this now https://bugs.launchpad.net/ubuntu/+source/python-traceback2/+bug/1503311 <- will try merging from debian as they have a "fix"
[14:41] <barry> seb128, didrocks which is why i want to get doko's opinion on the bug.  i didn't land python 3.4.3,  so i don't know what's involved in reverting that specific change.  i suspect it's better to update requests and urllib3 than revert a security fix in python tho.  i'm willing to help with requests and urllib3
[14:42] <didrocks> barry: my specific issue is that the regression is in distro for a couple of weeks, I did the debug and found the issue a week ago now and despite multiple pings, nothing is moving…
[14:42] <seb128> barry, are we sure that urllib3 is the only thing that is/can be impacted?
[14:42] <didrocks> also 3.4.3-1ubuntu1~14.04.1 isn't in the security pocket, but -updates
[14:43] <didrocks> the latest security update is 3.4.0-2ubuntu1.1
[14:43] <didrocks> which was working fine
[14:43] <didrocks> so reverting wouldn't have security impact (or it's been handled the wrong way, via the wrong channel)
[14:45] <barry> no, i don't know what else might be affected.  there aren't any negative comments in python bug 22417 and this one was only found by us so far afaict
[14:45] <barry> https://bugs.python.org/issue22417
[14:45] <slangasek> seb128, didrocks: there doesn't appear to be a bug tagged 'regression-update' for this SRU? https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-update&orderby=-id&start=0
[14:46] <slangasek> (if an SRU has a regression, this is the preferred escalation path)
[14:46] <slangasek> because yes, if there's a regression we should remove the package from -updates until the regression is fixed
[14:46] <seb128> slangasek, yeah, barry said he would look at it and didrocks trusted that it would be handled
[14:46] <seb128> we should have tagged it directly
[14:46] <barry> well, i did look at it
[14:46] <seb128> doing that now
[14:46] <seb128> barry, well, it's a regression in a SRU of a LTS, it can break production code, it ought to be dealt with and not delayed :-/
[14:47] <barry> i've found discussions in requests about the issue and they pointed to urllib3 which required a change to handle the issue
[14:47] <seb128> barry, if the fix is not obvious the proper thing to do is probably to revert the SRU while the solution is being worked
[14:48] <seb128> slangasek, didrocks, barry, tagged now
[14:48] <didrocks> thanks seb128
[14:49] <slangasek> thanks
[14:49] <didrocks> barry: not only found only by us, see the duplicate + the bug above
[14:49] <didrocks> barry: so, users (in corporate environment via proxy) gets this at least
[14:50] <slangasek> didrocks, seb128, barry: so as there's a confirmed regression in python3.4 in trusty-updates, I'm going to back this package out again; debugging should happen in -proposed, not in -updates where it will continue to impact users
[14:51] <seb128> slangasek, thanks a lot
[14:51] <seb128> and +1 on debugging should happen in proposed
[14:51] <barry> okay, but what i'm trying to say is that i didn't upload it so i want to get some opinion from the person who did
[14:53] <didrocks> thanks slangasek
[14:53] <slangasek> barry: getting opinions regarding the proper fix from the uploader is fine; but the policy to revert first when faced with a regression in -updates that isn't immediately fixed needs to not be a matter of opinion
[14:56] <seb128> barry, yeah, sorry you got pulled in while trying to help, no blaming there, we should just have removed it from -updates by standard procedure and then let doko, who did the upload, sort out the regression
[14:57] <barry> seb128: thanks
[16:00] <bdmurray> pitti: Do you have any idea why the "Launchpad automatic translations update" would be running for ubuntu-release-upgrader but really be out of date?
[16:00] <bdmurray> see bug 1502529
[16:39] <bdmurray> cjwatson: Do you have any idea why the "Launchpad automatic translations update" would be running for ubuntu-release-upgrader but really be out of date?
[16:41] <cjwatson> bdmurray: There's no record of Launchpad ever having done a direct commit for that branch.  Why do you believe it to be running?
[16:42] <bdmurray> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk r2906 says there was an automatic translation update
[16:43] <cjwatson> Oh, that's not the branch you quoted in the bug
[16:45] <cjwatson> bdmurray: https://translations.launchpad.net/ubuntu-release-upgrader/trunk/+pots/ubuntu-release-upgrader/sv/+translate?batch=10&show=all&search=Upgrading+Ubuntu is where it actually comes from
[16:46] <cjwatson> bdmurray: I suspect that it's sharing translations with vivid rather than with wily, because https://translations.launchpad.net/ubuntu shows the translation focus as vivid
[16:46] <cjwatson> wgrant: ^- shouldn't we have updated that to wily at some point?
[16:47] <bdmurray> hunh
[16:48] <cjwatson> so pretty sure that's the root cause but I'm not sure of the usual process here
[16:49] <bdmurray> cjwatson: okay, that's interesting
[17:25] <sil2100> doko: looking for a sponsor of a sync to fix a FTBFS for wily: https://bugs.launchpad.net/debian/+source/python-traceback2/+bug/1503311
[17:56] <seb128> could somebody retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+build/8093872 ?
[18:01] <cjwatson> seb128: done
[18:01] <seb128> cjwatson, thanks
[20:04] <kruger_> the uuid present in ".disk/casper-uuid-generic" is hardcoded inside the kernel (vmlinuz) on the dvd?
[20:13] <genii> There's a bug in juffed which has been fixed since Nov 4 2014, the current package for Vivid has it, but Trusty and Utopic still don't ... is there some standard timeline for it to go into trusty/utopic universe ( where it normally is) or backports or is that not bothered with normally? ( bug 874479 ) In this case the fix was to install shared libs to /lib/x86_64-linux-gnu/  instead of legacy /usr/lib64/
[20:15] <sarnold> genii: it probably just takes someone preparing, building, testing debdiffs, then subscribing sponsors or asking for it to be handled during someone's patch piloting time
[20:21] <genii> sarnold: OK, thanks
[20:54] <wgrant> cjwatson: Translations are shared between series within a context, and then additionally between all linked contexts. The translation focus setting just affects links in the web UI, and it is managed by Ubuntu's translation people.
[21:39] <doko> sil2100: done
[21:39] <sil2100> doko: thanks!
[22:50] <ginggs> hi, who can i bug about a MIR (LP: #1421209)?
[22:52] <sarnold> ginggs: probably tyhicks, when he returns from vacation; I doubt we'll have time to get to this one before 15.10 is released, though.
[22:52] <ginggs> sarnold: thanks :(
[22:53] <sarnold> ginggs: why do they have their own package for it rather than just a udev script and instructions "add this line to your /etc/modules"?
[22:54] <ginggs> i have no idea
[22:56] <sarnold> it'd be worth pressing nvidia for an answer on that one; there's a reasonably good chance I'll do the security team portion of the MIR and I'm certainly going to be looking for an answer to that question :)
[22:58] <cjwatson> wgrant: Hm.  That was my best guess.  Do you know why that ubuntu-release-upgrader trunk translation matches 15.04 rather than 15.10 then?
[23:02] <wgrant> cjwatson: Because the English string is different.
[23:03] <ginggs> sarnold: thanks, I've just passed that on to tseliot
[23:03] <wgrant> 15.04 vs 15.10
[23:03] <sarnold> ginggs: thanks!
[23:03] <wgrant> ubuntu-release-upgrader trunk says 15.04, so it shares with Ubuntu's 15.04 string
[23:05] <wgrant> cjwatson: Looking over scrollback, it seems that the underlying problem is that the template is not updated in the upstream project.
[23:05] <wgrant> cjwatson: The translations being exported are current for the upstream project.
[23:05] <wgrant> The template in wily just happens to be different.
[23:10] <cjwatson> wgrant: aha, right, that would make sense, I wonder why wily differs
[23:10] <cjwatson> bdmurray: ^-
[23:10] <wgrant> Well
[23:11] <wgrant> The most likely problem is that someone is that someone just hasn't uploaded the new template to the ubuntu-release-upgrade project.
[23:11] <wgrant> (or the autoimport is disabled, or not approved, or something)
[23:11] <wgrant> It seems reasonable that wily's template should refer to wily's version.
[23:12] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/po/ubuntu-release-upgrader.pot still shows the 15.04 string
[23:12] <wgrant> That'd do it.
[23:12] <cjwatson> Right, I meant I wonder why trunk differs from wily
[23:12] <cjwatson> Suggests somebody goofed
[23:12] <wgrant> And here I was trying to investigate a potential translation sharing bug!
[23:12] <wgrant> That's a nice easy solution.
[23:12] <cjwatson> Looks to me that somebody needs to regenerate the .pot and commit it to trunk
[23:13] <cjwatson> The source file is correct: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/gtkbuilder/DistUpgrade.ui
[23:13] <wgrant> Aha
[23:13] <cjwatson> So it probably got regenerated as part of a source package build somewhere
[23:14]  * cjwatson explains the situation in https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1502529
[23:16] <wgrant> Thanks.
[23:17] <cjwatson> infinity: https://code.launchpad.net/~cjwatson/ubuntu-archive-publishing/inline-release/+merge/273622 if you get a minute
[23:17] <wgrant> cjwatson: The things to remember about sharing are that only translations for identical English strings are shared, and the rules defining the sharing subset are documented in the large comment in _queryPOTemplates
[23:18] <wgrant> And if anyone ever removes a Packaging link, you can be reasonably confident that translation sharing is broken even within the distro or product for both ends of that link without manual intervention.
[23:18] <cjwatson> Yeah.  Particularly great since literally anyone can change Packaging links
[23:18] <wgrant> :D
[23:24] <infinity> cjwatson: Looks reasonable, though "(re-)signing $CANDIDATE inline" seems a little harder to parse than just "(re-)signing $INRELEASE" would be, no?
[23:24] <infinity> cjwatson: All looks logically sane, though.


[17:31] <blackboxsw> powersj: I'm not quite understanding the need for ctest -- tree_collect or tree_run versus just collect and run
[17:32] <blackboxsw> if you don't pass a --deb to tox -e citest -- run doesn't it just perform the existing run against the cloud-init in the current branch?
[17:32] <blackboxsw> ... which seems to be the intent behing tree_run?
[17:32] <powersj> if you use collect and run you use the cloud-init that comes with the image itself. If you use tree_* you are going to run using the local tree.
[17:32] <blackboxsw> behind* rather
[17:32] <blackboxsw> ohhh
[17:32] <powersj> if you use --deb as you said, it will pull in that deb, but why force the developer to have a deb built locally.
[17:33] <powersj> tree_* will go and build the deb for you so you don't have to have all the build deps and build env setup.
[17:33] <blackboxsw> feels strange to me that citest -- run, since you have source locally in order to run these tests, wouldn't use the cloud-init tree as default test target
[17:34] <blackboxsw> ahhh it's to avoid debs
[17:34] <blackboxsw> ahhh it's to avoid deps
[17:34] <blackboxsw> ok
[17:34] <blackboxsw> ok I'm good now. thx
[17:35] <blackboxsw> though it kinda feels like instead of tree_collect and tree_run we could just provide a   citest -- run --use-tree option right?
[17:35] <blackboxsw> or is there more to it than that? it seems tree_(run|collect) is just a mirror of run|collect right?
[17:36] <powersj> Well there are lots of options to go along with the building and I think this made the argparsing much easier
[17:36] <blackboxsw> thanks. I'll keep firing questions as I go through this until I get the context.
[17:37] <powersj> please do :)
[18:15] <blackboxsw> powersj: do you know where the template_override verbs are used "when: - create\n-copy" etc that I see in platforms.yaml?
[18:16] <blackboxsw> it seems template_overrides is only used on lxd-specific cases.
[18:17] <blackboxsw> but I don't really know where the consumer of that template is
[18:17] <powersj> so keep in mind we only have lxd as a platform, no other platforms are enabled right now
[18:17] <powersj> as far as when, I don't know off the top of my head
[18:17] <powersj> I'll try to look and see
[18:19] <powersj> looks like images/lxd.py:update_templates
[18:19] <blackboxsw> tests/cloud_tests/images/lxd.py yeah was just typing that too
[18:19] <blackboxsw> thanks
[18:36] <blackboxsw> ahh so these are lxd specifc metadata config options when building and configuring  containers
[18:40] <powersj> yeah
[18:40] <powersj> if I recall we added this to later add various platform specific configs/options down the road
[18:40] <powersj> e.g. kvm with a couple storage devices or with multiple networks
[18:48] <blackboxsw> powersj: so I'm going through tests/cloud_tests/releases.yaml  and looking over feature flags in general. Do you know where ubuntu_user or lsb_release feature actually  turns into some sort of feature setup in #cloud-config during these vm tests?
[19:22] <powersj> blackboxsw: if you look at the test case yaml you will see the feature flags called out. The feature flags are not a cloud-init thing, but an integration test thing.
[21:11] <blackboxsw> man josh, this is a beast.
[21:11] <blackboxsw> 3700 lines. sorry it's taking me a while
[21:12] <blackboxsw> sorry 3200 lines
[21:12] <blackboxsw> adding another set of small nits
[21:13] <powersj> blackboxsw: no worries ;0
[21:13] <blackboxsw> :/ that I'm only 1/3 through it
[21:14] <blackboxsw> I'm gaining knowledge though on how different parts interact... so not just a code review.
[21:26] <blackboxsw> so, powersj feature flags are just arbitrary strings that some unit tests claim to require and some distros and series claim to support per releases.yaml?
[21:26] <powersj> bingo
[21:26] <blackboxsw> it's basically a set of bools that each release claims to support. man I thought there was more to it.
[21:28] <blackboxsw> ok, so is it kindof out goal to make tests flexible enough to avoid having to exlude it based on a feature?
[21:28] <blackboxsw> is the the feature flag really just intended to save time via skips
[21:29] <blackboxsw> that last statement should have been a question: "or is the the feature flag really just intended to save time via skips?"
[21:32] <powersj> I think no to both. For example, we want to be able to have apt based tests that only run on debian, and just skip on centos/rhel/fedora
[21:33] <powersj> Yes the test case could have logic that collects what release it was on and exit before hand, but that seems more complicated than just saying this test needs x feature so don't run on y.


[09:28] <cpaelzer> Hi, the s390x builders seem to be disabled on all but four of them - is there a maintenance going on that I missed to be aware?
[09:29] <cpaelzer> or are these breakign apart - I've seen in the backlog that we have had some issues with s390x builders recently
[09:29] <cpaelzer> so do they just need a manual stab again to get them running for now or is this any worse than the last few times?
[09:38] <cpaelzer> ok, maybe it was the automation - but now all the builders got reset and are in cleaning state
[10:09] <tomwardill> cpaelzer: they're being reset every 30 minutes atm, the underlying cloud isn't happy and we've not managed to get to the bottom of it all yet
[10:11] <cpaelzer> thanks tomwardill
[10:11] <cpaelzer> that is what I eventually derived from the backlog, but I wasn't sure if I was seeing something new
[10:11] <tomwardill> np, sorry for the inconvenience :)
[10:12] <tomwardill> no, it's still ongoing atm
[10:12] <cpaelzer> good to know


[04:07] <Fudge> it's always in the last place you look
[08:00] <willcooke> o/
[08:04] <Laney> yello
[08:05] <flexiondotorg> Morning
[08:05] <flexiondotorg> Trevinho, Thanks for the tip on G+, I'll have an experiment :-)
[08:12] <seb128> hey willcooke Laney flexiondotorg
[08:12] <flexiondotorg> o/
[08:12] <willcooke> morning all
[08:12] <seb128> bah, http://people.canonical.com/~ubuntu-archive is still 503
[08:16] <Laney> weird
[08:17] <seb128> I mentioned it on #is earlier
[08:17] <seb128> but restarted after upgrades and forgot to rejoin
[08:17] <seb128> unsure if somebody picked it up, still not working though
[08:17] <seb128> Laney, is it 503 for you as well?
[08:18] <sarnold> yeah, being investigated
[08:20] <Laney> seb128: it is back
[08:21] <seb128> Laney has magical powers!
[08:21] <seb128> Laney, what did you do?
[08:21] <Laney> nothing
[08:21] <Laney> someone else fixed it
[08:21] <Laney> but I took their credit
[08:22] <Laney> I guess they restarted apache though, because it wasn't running before and is now
[08:24]  * Laney tries to get laptop back working ._.
[08:30] <seb128> what's the issue?
[08:30] <seb128> your upstart/dbus/systemd hacks/experiments?
[08:30] <Laney> it's all pitti's fault!
[08:30] <seb128> yeah, he's hidding in shame
[08:52] <seb128> happyaron, hey, how is the n-m works/updates/srus going? ;-)
[08:54] <happyaron> seb128: doing the vpn plugin things
[08:54] <seb128> happyaron, k, do you think you are going to get those ready today?
[08:55] <happyaron> will that work for tomorrorw? or do we do sru on fridays?
[09:03] <seb128> happyaron, are those updates that complex?
[09:04] <seb128> happyaron, we can upload on friday, then up to SRU team, they are usually fine getting things in proposed on friday
[09:04] <seb128> but they are not going to copy over to updates on friday next week
[09:06] <happyaron> not so complex, but I'm going off from work today soon... (17:06)
[09:07] <happyaron> I can give them to you before you start tomorrow
[09:11] <happyaron> seb128: well I'll give you most of them later today after dinner
[09:12] <seb128> happyaron, tomorrow is fine, just trying to understand what is blocking them, it's some work but shouldn't take 10+ days, but I'm probably overlooking some complexity?
[09:13] <happyaron> just trying to get all the vcs stuff done altogether
[09:13] <happyaron> and nm is not the only thing I'm doing...
[09:15] <seb128> happyaron, you should update your trello :p
[09:15] <happyaron> k..
[09:16] <seb128> happyaron, sorry I don't mean to stress you, I just want to see those moving, if you are busy on other things maybe I can help with that round of nm updates?
[09:16] <seb128> happyaron, or maybe we need to shuffle priorities, unsure what other things you work on and if they are higher priority that the nm stable update SRU
[09:16] <seb128> willcooke, ^
[09:17] <happyaron> well I think it's sort of my problem, i.e. in the time of switching to procedures I'm not familiar with
[09:18] <seb128> right, fair enough, learning curve
[09:18] <seb128> I guess I was expect that we do the SRUs as easy/debdiff updates
[09:18] <seb128> then you take time to see how you want to adjust the workflow etc for y
[09:18] <seb128> I was expecting*
[09:19] <willcooke> yeah, let's get the SRUs out of the way, and then we can work on upstreaming patches etc etc
[09:19] <seb128> but if you rework the vcs and learn the packages it takes time indeed
[09:19] <happyaron> for what I'm doing is trying to get everything sorted in a single try without doing things again, not expecting that we need SRUs so quickly
[09:20] <seb128> happyaron, well, you said yesterday that vpn&co plugins don't work in the LTS due to version mismatch ... that's sort of an important issue I think?
[09:21] <happyaron> yep, and I expected to give that to you tomorrow. for our timezone it's nice that I work in the morning and later when you EU guys are up I'm in the afternoon.
[09:23] <seb128> yeah
[09:23] <seb128> happyaron, thanks Aron, enjoy your dinner ;-)
[09:23] <seb128> happyaron, tomorrow is fine, let's stick to that
[09:23] <happyaron> :)
[09:24] <happyaron> but yeah I'll avoid fridays for sru
[09:24] <seb128> that's better
[09:24] <seb128> but not the end of the world
[09:24] <seb128> as said we can get them in proposed
[09:24] <seb128> they are just not going to be copied after the week
[09:24] <seb128> but on the monday after, so we just extend the testing period
[09:25] <happyaron> understand, but for stuff that's not working, let it migrate quicker could be better
[09:27] <seb128> yeah, we can argue with the sru team to move it earlier if it's well tested
[09:27] <seb128> speaking of which do you know if anyone from kde testing their regression with the nm in proposed?
[09:27] <seb128> that's still not moved over
[09:27] <seb128> unsure why
[09:29] <happyaron> I only talked with the uploader of that update once in bug comments, let me help to test that if things is not moving this weekend
[09:33] <seb128> k
[09:34] <seb128> can you maybe ping him again if you know where to find him?
[09:34] <seb128> thanks
[09:34] <happyaron> ok
[09:35] <seb128> ok, I'm going for early lunch before having a solid afternoon work then ;-)
[09:35] <seb128> bbiab
[09:36] <happyaron> have a nice lunch, :)
[09:36] <seb128> thanks!
[09:55] <Fudge> how do people import mbox files from the ubuntu mail archives into thunderbird?
[10:18] <Fudge> yay I found an extension
[10:20] <andyrock> hey all
[10:28] <willcooke> morning andyrock
[10:31] <hikiko> andyrock, Trevinho when you have a moment could you get a look at this branch: https://code.launchpad.net/~hikiko/unity/unity.shadows-on-existing-pixmaps/+merge/284068 it's getting too old... ;-)
[10:31] <andyrock> sure
[10:31] <hikiko> thanks!
[11:23] <seb128> hey andyrock hikiko!
[11:24] <hikiko> hey seb128 :)
[11:25] <hikiko> andyrock, are there any instructions on how to use metacity with unity?
[11:25] <hikiko> (is this possible?)
[11:25] <andyrock> hikiko: without compiz?
[11:25] <hikiko> I don't know, which are the options?
[11:26] <hikiko> I remembered you used metacity to see if a bug was coming from compiz or not
[11:26] <andyrock> hikiko: it's not possible
[11:27] <andyrock> there is the standalone version of unity
[11:27] <andyrock> but without window management
[11:27] <hikiko> oh I see you can't combine compiz compositor with metacity window manager then
[12:09] <Laney> exciting
[12:09] <Laney> I haxed dbus-daemon to activate all the things using systemd
[12:10] <Laney> it seems to even vaguely work
[12:10] <Laney> for apps too
[12:10] <Laney> May 26 13:09:20 nightingale dbus-daemon[2639]: Activating via systemd: service name='ca.desrt.dconf-editor' unit='dbus-ca.desrt.dconf-editor.service'
[12:10] <Laney> May 26 13:09:20 nightingale systemd[2613]: Starting DBUS1: ca.desrt.dconf-editor...
[12:10] <Laney> May 26 13:09:20 nightingale dbus-daemon[2639]: Successfully activated service 'ca.desrt.dconf-editor'
[12:11] <Laney> May 26 13:09:20 nightingale systemd[2613]: Started DBUS1: ca.desrt.dconf-editor.
[12:23] <seb128> Laney, so it makes anything dbus activate looks like a systemd job?
[12:23] <seb128> do they need to ship an unit for that?
[12:24] <Laney> nein
[12:24] <Laney> that's what broke my laptop yesterday
[12:25] <Laney> there's a generator
[12:27] <seb128> the generator create the systemd units?
[12:27] <Laney> yes sir
[12:27] <seb128> I see
[12:27] <seb128> cool!
[12:27] <seb128> no p_itti until monday to cheers though
[12:28]  * Laney is going to be off monday too
[12:28] <Laney> bank holiday
[12:28] <seb128> oh
[12:28] <seb128> enjoy! :-)
[12:28] <Laney> may is a weird month
[12:28] <Laney> all countries have them at different times
[12:28] <seb128> yeah, we also have our share of holidays
[12:28] <seb128> but few of them are synced between countries it seems
[12:28] <seb128> right
[12:29] <Laney> real europe counts as one country :P
[12:29] <seb128> canada has monday, germany today, you have monday
[12:29] <seb128> haha
[12:29] <desrt> saluton, karaj
[12:30] <seb128> hoi desrt
[12:30] <Laney> what up homeslice
[12:30] <desrt> not very much is "happening", my l33t dudes
[12:31]  * desrt makes a contorted face
[12:32] <desrt> know what i hate?  how some people put the orange pair first when terminating an rj45 connector.   You can just use decor which + gtk-windoiw-decorator which uses metacity for theming, but not mixing the WMs
[12:33] <desrt> blue is pair 1 -- in the centre
[12:34] <desrt> orange is pair 2 -- surrounding the centre
[12:34] <Trevinho> hikiko|ln: as for that branch, I've some work in progress with it... I'll try to get it done ASAP
[12:34] <desrt> green to the left, brown to the right
[12:34] <Laney> I never actually managed to make a working cable
[12:34]  * desrt makes them all the time -- except for last night
[12:35] <desrt> >:|
[12:35] <Laney> come over and do mine
[12:35] <Laney> want to run it up the outside of the house
[12:36] <desrt> got conduit?
[12:37] <hikiko|ln> thanks Trevinho, did you find a bug? because I've tested it with edge-case windows (eg those blob-shaped ones that change in real-time) and it seemed to work well
[12:37] <Trevinho> hikiko|ln: I had crashes when adding/readding borders to chrome, but I also did some code optimizations around
[12:38] <Laney> it's "outdoor use" cable
[12:38]  * Laney needs food
[12:42] <desrt> the conduit is not to protect it against the weather... it's to protect it against mechanical damage
[12:50] <hikiko|ln> mmm, why it crashes? I'll get a look, I didn't see that problem, thanks Trevinho
[13:04] <hikiko> Trevinho, willcooke should I top approve sam's branch? https://code.launchpad.net/~smspillaz/compiz/compiz.animationaddon-returns/+merge/295497 he fixed 1 issue he had and so far his change doesn't affect unity or any default plugins
[13:06] <Trevinho> hikiko: sure, however we do use animations plugin
[13:06] <Trevinho> but not the addon
[13:08] <hikiko> Ok let me double check the animations 1 final time and i will top approve it
[13:08] <Trevinho> it's probably just a cleanup from my quick look
[13:09] <hikiko> Yes he just added a function for some raw code as far as i remember
[13:10] <Trevinho> hikiko: ok, go for it then... I'll include it in next landing round
[13:11] <Trevinho> hikiko: there are also other GL  related reviews if you want join the party.. https://code.launchpad.net/~smspillaz/compiz/+activereviews
[13:11] <Trevinho> hikiko: they're new plugins, so just check they're ok... Since there's no regression alert there
[13:12] <hikiko> sure
[13:13] <hikiko> sure I'll get a look
[13:18] <seb128> flexiondotorg, your g+ post you typoed "Sotware Bouqitue" in the title, missing "f" and swap of letters in boutique
[13:18]  * flexiondotorg has typing issues.
[13:19] <flexiondotorg> Thanks, I'll got a fix that.
[13:19] <seb128> yw!
[14:04] <Laney> this cable is not getting damaged in that way
[14:04] <Laney> only by my inability to wire the thing up
[14:17] <willcooke> ou est didrocks
[14:17]  * larsu bets France
[14:17] <larsu> hey willcooke :)
[14:17] <willcooke> what up larsu, congrats!!
[14:18] <seb128> hey larsu!
[14:18] <desrt> party in #u-d
[14:18] <larsu> hello seb128!
[14:18] <larsu> hey desrt :)
[14:18] <desrt> where's laney and attente?
[14:18] <seb128> congrats?
[14:18] <larsu> yeah.. congrats?
[14:18] <desrt> larsu: i heard the news!  congrats!
[14:18] <larsu> thanks!!!!!!
[14:18] <desrt> it's so awesome
[14:18] <desrt> you're gonna be really happy
[14:19] <larsu> more than I am anyway?
[14:19] <attente> ???
[14:19] <Laney> HAHA
[14:19] <larsu> hi attente
[14:19] <Laney> I feel the same
[14:19] <attente> hi larsu!
[14:19] <larsu> and hallo Laney
[14:19] <Laney> tag
[14:19] <desrt> attente: where are you?  i miss you
[14:19] <desrt> it's been like... 16 hours
[14:20]  * attente hugs desrt
[14:20] <larsu> don't you two live in the same city?
[14:20] <Laney> attente: https://www.trainingbeta.com/bouldering-strength-and-power-program/
[14:21] <Laney> last night makes me thing I need some strength and power
[14:21] <Laney> larsu: is there real news or are these people trolling?
[14:22] <larsu> trolling
[14:22] <Laney> aww
[14:22] <Laney> i was looking forward to being happy for you
[14:22] <Laney> can I be happy for you anyway?
[14:22] <attente> me too
[14:22] <larsu> it's a national holiday in germany
[14:22] <larsu> not in berlin
[14:23]  * larsu blames religion
[14:23] <Laney> hey you get to live in a cool city
[14:23] <Laney> it's like a holiday every day
[14:23] <larsu> Laney, attente: yes, you can!
[14:23] <larsu> haha indeed
[14:23]  * larsu just had delicious pad thai
[14:23] <attente> national holiday... but not in berlin...
[14:23] <Laney> you can have the holiday if you leave berlin
[14:24] <Laney> there's a solid ring of people standing on the boundary
[14:24] <larsu> attente: federalism!
[14:24] <attente> larsu: that does sound like a religion
[14:24] <larsu> I should have put national in quotes
[14:24] <larsu> haha
[14:24] <larsu> or said "state"
[14:25] <Laney> If you only have a few good burns in you every day on your project, and you want to climb harder for longer, this program will give you the mental and physical stamina you need to project strong all day
[14:25] <Laney> that is such a climbing sentence
[14:25] <desrt> reminds me of a friend of mine and his opinions on guitar magazines
[14:27] <attente> Laney: have you tried this? how effective is it?
[14:27] <Laney> a couple of my pals are doing it
[14:27] <Laney> one of them complains about doing too much training and not enough climbing /o\
[14:28] <Laney> the other guy is super keen though
[14:28] <Laney> they have this climbing diary where they document each one and how far they get every time
[14:28]  * Laney is going to try the trial
[14:29] <happyaron> seb128: still around?
[14:29] <seb128> happyaron, yes, it's 4pm ;-)
[14:30] <happyaron> what about sponsoring this -openconnect plugin? it was finished last week but not uploaded
[14:30] <happyaron> https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6404038/+listing-archive-extra
[14:30] <cyphermox> seb128: fwiw, I noticed there is in fact a 3G -specific signal level icon for https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1571574, I'm updating everything to use that
[14:31] <ubot5`> Launchpad bug 1571574 in network-manager-applet (Ubuntu) "[SRU] 3G (WWAN) icon missing" [High,In progress]
[14:31] <seb128> cyphermox, great!
[14:31] <happyaron> thx cyphermox
[14:31] <larsu> seb128: 4pm on a Thursday!!!
[14:32] <seb128> happyaron, is that the one which p_itti comment about, #23 on the bug
[14:32] <larsu> how do you not have that holiday?!
[14:32] <cyphermox> happyaron: have you tested the vpn plugins? there's often some corner cases that may fail
[14:32] <seb128> larsu, you mean it's ice cream time?
[14:32] <seb128> :-)
[14:33] <larsu> haha yes!
[14:33] <cyphermox> ice cream!
[14:33] <happyaron> cyphermox: most of them need update to >= 1.2.0 for version mismatches
[14:33] <seb128> larsu, guess where p_itti is :p
[14:33] <larsu> eating ice cream in the sun I hope
[14:33] <Laney> making some really dark bread
[14:33] <cyphermox> happyaron: that's not what I mean, they still need to be tested. no point in updating to something broken
[14:33] <Laney> and/or gardening
[14:34]  * Laney knows pi_tti's life
[14:34] <seb128> :-)
[14:34] <seb128> or playing basketball
[14:34] <seb128> he seems to have got into it
[14:34] <Laney> maybe basketball and/or taekwondo
[14:34] <larsu> while eating ice cream
[14:34] <Laney> one of those beer hats modified to dispense ice cream instead
[14:34] <happyaron> cyphermox: ic, will double check when making any updates..
[14:35] <seb128> "please can hold that scone for me, need to throw the ball now" :p
[14:36] <larsu> hehe
[14:36] <Laney> sooooooooooooo css nodes are fun
[14:36] <Laney> also running 3 copies of the widget factory is fun
[14:36] <seb128> larsu, see what you did to Laney!
[14:37] <Laney> especially when you open the switcher
[14:37]  * larsu slowly walks away
[14:37] <Laney> compiz hates that
[14:37] <willcooke> Laney, I feel your pain
[14:37] <seb128> Marrrrcooooo
[14:37] <larsu> haha :)
[14:37] <flexiondotorg> willcooke, Have you got an LP bug reference for the white centres in progress bars?
[14:37] <seb128> what's the issue with the switcher?
[14:37] <Laney> i guess the live previews
[14:37] <Laney> seems to kill everything
[14:37] <willcooke> flexiondotorg, sec...
[14:38] <seb128> weird, it should be able to handle that :-/
[14:38] <cyphermox> flexiondotorg: thanks if you fix that, it's fugly.
[14:38] <seb128> no really slowdown here
[14:38] <Laney> with more than one?
[14:38] <Laney> it doesn't always happen
[14:38] <seb128> yeah, just tried with 3
[14:38] <flexiondotorg> cyphermox, Is fixed, willcooke and Laney have the details.
[14:38] <cyphermox> weee
[14:39] <Laney> ho hum
[14:39] <willcooke> flexiondotorg, cyphermox https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1052936
[14:39] <Laney> probably drivers get involved
[14:39] <ubot5`> Launchpad bug 1052936 in ubuntu-themes (Ubuntu) "Progress bar in "Progress" section has a hole in it" [Medium,Triaged]
[14:39] <seb128> yeah
[14:39] <seb128> or hidpi = more pixels
[14:39] <seb128> or something
[14:39] <Laney> different machine
[14:39] <seb128> ah
[14:39] <seb128> dunno then :-)
[14:39] <Laney> http://people.canonical.com/~laney/weird-things/gtk320.png
[14:39] <willcooke> flexiondotorg, cyphermox - I'm working on a fix
[14:39] <willcooke> flexiondotorg, cyphermox - nearly there, just need time to finish it.
[14:40] <cyphermox> cool, not a problem
[14:40] <Laney> every pixel on there has given me one new grey hair
[14:40] <cyphermox> it's not breaking things, it just looks ugly and I saw it a lot testing apturl and aptdaemon
[14:40] <willcooke> cyphermox, ditto
[14:40] <seb128> nice
[14:41] <Laney> still don't know what is up with that left linked button
[14:41] <Laney> comboboxes are hard
[14:43] <willcooke> cyphermox, actually, I think it's done.  Would you take a branch out for a test drive?
[14:43] <cyphermox> willcooke: tbh, can I haz a PPA instead?
[14:43] <willcooke> cyphermox, sure, lemme find out how to do that....
[14:43] <cyphermox> oh
[14:44] <Laney> lazzzzzzzzzzzy
[14:44] <Laney> bzr bd!
[14:44] <cyphermox> well, I can build it myself too ;)
[14:44]  * willcooke needs to learn anyway
[14:44] <Laney> turn off --with scour in debian/rules if you do that
[14:44] <cyphermox> +1
[14:44]  * Laney 's tips
[14:44]  * willcooke smiles and nods and goes to look it up
[14:44] <cyphermox> Laney: seb128: gnome-common uninstallable?
[14:44] <Laney> willcooke: for local build, not ppa
[14:45] <Laney> what
[14:45] <willcooke> ah, kk
[14:45] <cyphermox> I don't know, sbuild is unhappy with building nm-applet here
[14:46] <seb128> cyphermox, what's the error?
[14:46] <Laney> laney@snakefruit:~$ /home/ubuntu-archive/bin/chdist apt-get yakkety-amd64 --dry-run install gnome-common >/dev/null 2>&1 && echo what you talkin about cyphermox
[14:46] <Laney> what you talkin about cyphermox
[14:46] <cyphermox> just "gnome-common is uninstallable"
[14:46] <Laney> same with proposed
[14:46] <seb128> try to apt-get install it
[14:46] <seb128> and see what's the actual error
[14:46] <cyphermox> nah, I see what it is
[14:47] <happyaron> unit tests of n-m randomly fail on my box, and I need reboot to get that work again
[14:47] <cyphermox> build with yakkety-proposed+main
[14:47] <happyaron> dunno why
[14:47] <seb128> happyaron, :-/
[14:47] <cyphermox> main-only build fails, gnome-common is in universe now?
[14:47] <Laney> you can build with universe
[14:47] <cyphermox> of course
[14:47] <seb128> yeah archive reorg
[14:48] <cyphermox> yeah, just had muscle-memory
[14:48] <seb128> :-)
[14:49] <happyaron> seb128: you might remember I stucked during our sprint saying unit tests problem
[14:49] <seb128> happyaron, yeah, you said you had local issues not happening in the ppa
[14:49] <seb128> did you ask cyphermox if he knows about those?
[14:50] <happyaron> nope, but doing now. cyphermox ^^^
[14:50] <cyphermox> unit tests for n-m can be confused by the interfaces on your system, especially if you're also running containers and whatnot
[14:51] <cyphermox> better to run in a pristine environment
[14:51] <happyaron> no containers
[14:51] <happyaron> ok
[14:51] <Sweet5hark1> *grumble*. /me had a ftbfs in the beta snap, now set it to  "make -j1" and it seems to be doing fine. Buildsystem race conditions ftw (esp. if they are happening in building bundled projects: aka a make triggering other build systems, possibly multiple ones in parallel ...) *grumble*
[14:52]  * Laney saw a post the other day about building gstreamer with meson
[14:53] <Laney> apparently they got loads of speedup
[14:54] <qengho> ninja is fast.
[14:57] <willcooke> cyphermox, https://code.launchpad.net/~willcooke/ubuntu-themes/progress-bars
[15:01] <flocculant> seb128: re 'recent' files - have stuff from yesterday showing as yesterday
[15:02] <seb128> flocculant, yesterday before current time?
[15:02] <seb128> or after?
[15:02] <flocculant> was yesterday ~07:30
[15:02] <seb128> and what time is it now for you? :-)
[15:03] <Sweet5hark1> Laney, quengo: guys, this would suck with any build system. The annoying part is stacking build systems on top of buildsystems. Jenga-style development again.
[15:03] <flocculant> seb128: on another note - I have a file that says accessed 26/01/2015 - which I assume was the *first* time it was accessed as I opened/modified it yesterday
[15:04] <flocculant> seb128: it's currently 16:03, that file with 'yesterday' this morning showed the 'time' rather than yesterday
[15:04]  * Laney snuggles Sweet5hark1
[15:04] <Laney> you are experiencing the fun of bundling
[15:05] <flocculant> seb128: I would anticipate tomorrow ~08:00 it saying 25/01/16
[15:05] <Sweet5hark1> aye
[15:05]  * Sweet5hark1 pouts
[15:05]  * happyaron goes to his bed
[15:05] <flocculant> happyaron: don't take a pout
[15:05] <flocculant> awful tasting fish
[15:06] <happyaron> :)
[15:07] <seb128> flocculant, ok, thanks, I need to look more, still seems confusing behaviour
[15:07] <seb128> happyaron, night!
[15:07] <seb128> happyaron, btw did you see my comment about openconnect?
[15:08] <flocculant> seb128: ack - personally I'm confused why it's saying the 'accessed' time if that's the original, would make more sense to show the more recent one *shrug*
[15:08] <seb128> yeah
[15:08] <flocculant> and happy enough to look again later
[15:08] <happyaron> seb128: the dependency thing?
[15:08] <seb128> it's supposed to do that
[15:08] <happyaron> ah will look tomorrow
[15:08] <seb128> happyaron, yes, p_itti blocked the SRU due to that, cf the bug
[15:08] <happyaron> ic
[15:09] <flocculant> seb128: aah right - ok - well then I'd call bug :)
[15:10] <flocculant> which is easy to do when you can't fix them ;)
[15:11] <seb128> hehe
[15:39] <attente> seb128: hey, do you have a chance to try out the ppa?
[15:41] <qengho> Laney: I want to implement appstream for this chromium release. Can you point me to a source package whose appstream data is exemplary?
[15:41] <Laney> qengho: gnome-software probably has it right
[15:41] <qengho> Awesome. Thanks.
[15:42] <Laney> You should get upstream to ship this
[15:42] <seb128> attente, hey, oh sorry, forgot ...going to do that in a bit
[15:43] <cyphermox> seb128: Laney: willcooke's code branch looks good for the theming
[15:44] <cyphermox> I tested with the adwaita and ambiance themes in gnome-shell.
[15:44] <seb128> cyphermox, great!
[15:45] <cyphermox> ah there he is
[15:49] <cyphermox> hm, actually maybe I'm not testing this right
[15:55] <cyphermox> willcooke: your code branch looks good to me
[15:55] <willcooke> cyphermox, thx.  I'm going to keep it on here for a bit and see if I can find anything that broke.
[15:55] <willcooke> Laney, might be another merge ^
[15:59] <seb128> willcooke, you might want to get the light theme updated as well? (unsure why the bug doesn't show there but better to not have the code diverge between those)
[16:00] <willcooke> seb128, good call, will do
[16:09] <seb128> tiheum, hey, do you think we could easily get phone-<level>-charging icons?
[16:10] <seb128> tiheum, try to figure out what to do with bug #1470080
[16:10] <ubot5`> bug 1470080 in indicator-power (Ubuntu) "Broken icon in indicator when iphone attached" [High,Triaged] https://launchpad.net/bugs/1470080
[16:10] <seb128> willcooke, ^
[16:10] <willcooke> ack, thx seb128
[16:11] <seb128> the issue is that the charging/discharging
[16:11] <seb128> it's that it tries to load "phone-<level>-charging" icons
[16:11] <seb128> which we don't have
[16:11] <seb128> unsure what to do with that
[16:11] <seb128> best option would be to get those icons
[16:13] <seb128> if we can't easily then either display a battery one? or a standard phone icon?
[16:14] <seb128> but /usr/share/icons/suru/devices/scalable/phone-symbolic.svg doesn't look good in the indicator
[16:18] <tiheum> seb128, hi, I think that the best option is to add a (pixel-perfect) 'phone charging' icon to ubuntu-mono-light and ubuntu-mono-dark themes
[16:19] <seb128> tiheum, do you think you could work on that when you have some spare cycles?
[16:20] <tiheum> seb128, sure, it might not take too long. I add ubuntu-themes to the bug's affected projects.
[16:20] <seb128> tiheum, I added the package, feel free to add the upstream project as well
[16:20] <seb128> tiheum, thanks!
[16:20] <willcooke> thanks tiheum
[16:23] <tiheum> seb128, just one thing: do we need only one icon whatever the charge level of the phone is or several icons (and which ones)?
[16:27] <tiheum> seb128, actually I've just check the status icon in ubuntu-mono-light and we have already a few icons that could be used when charging a phone. Look into /usr/share/icons/ubuntu-mono-light/status/24
[16:27] <seb128> oh
[16:27] <tiheum> icon are called gpm-phone-XXX.svg where XXX is the charge level
[16:27] <tiheum> *icons
[16:29] <tiheum> or xfm-phone-XXX.svg
[16:29] <seb128> yeah, trying that
[16:29] <seb128> the charge levels are by 10
[16:30] <tiheum> nope, 20
[16:32] <seb128> in the code
[16:32] <seb128> oh, rather 10 with fallback to 20
[16:33] <seb128> tiheum, k, so those icons are not -charging
[16:33] <seb128> I guess the code could fallback to try to load the non charging version
[16:33] <seb128> as a fallback
[16:34] <seb128> also the menu looks weird with those because they don't have the same ratio as the battery ones
[16:34] <seb128> but at least the panel looks fine
[16:34] <seb128> charles, ^
[16:36] <seb128> charles, tiheum, http://people.canonical.com/~seb128/device.png
[16:36] <seb128> willcooke, ^
[16:36] <charles> hm, indicator-power's code looks like it should be requesting an icon like gpm-phone-100
[16:37] <seb128> does it?
[16:38] <seb128>       case UP_DEVICE_STATE_CHARGING:
[16:38] <seb128> has all its icons -charging
[16:38] <seb128> do we do the iconspace thing where we drop the suffix until we find something?
[16:38] <seb128> i.e icon-something-else looking to icon-something?
[16:40] <charles> seb128, for charging it would request something like gpm-phone-080-charging
[16:40] <charles> for discharging it would be gpm-phone-080
[16:40] <seb128> right
[16:41] <seb128> well the phone is plugged
[16:41] <seb128> so it's charging
[16:41] <charles> so, right, we dont have -charging icons
[16:41] <seb128> unsure if we should fallback to non charging in those cases
[16:41] <seb128> also see the screenshot for the menu layout issue
[16:41] <charles> yeah, same
[16:43] <charles> IMO falling back to icon-something when icon-something-else is unavailable is better than a broken icon
[16:44] <charles> but it would be better to have a phone-foo-charging icon
[16:46] <charles> not sure what appearance they would have though
[16:46] <charles> tiheum, do you think it would make sense to add phone charging icons different from the current phone icons?
[16:46] <charles> also mpt ^
[16:49] <tiheum> charles, what do you mean?
[16:49] <charles> tiheum, eg right now there's gpm-phone-040.svg. Would it make sense to have another icon to show a charging phone, eg gpm-phone-040-charging.svg
[16:50] <seb128> with a small charging sign on it or something
[16:50] <tiheum> seb128, charles: oh, I see
[16:51] <tiheum> it would make sense but it's tricky because the icons are tiny
[16:51] <tiheum> note that the main battery icon is larger than the other indicators
[16:52] <seb128> attente, gnome-software from the ppa looks fine to me, installing/starting/remove a software, refreshing for updates, looking at review, searching for a snap ... did you specific issues?
[16:52] <seb128> I'm going to keep playing a bit with it
[16:52] <seb128> but no regression that I can see so far
[16:52] <seb128> tiheum, right, that leads to http://people.canonical.com/~seb128/device.png
[16:52] <tiheum> so a phone + a charge level + a sign... it's a lot to combine in one tiny icon :)
[16:53] <tiheum> yeah, in the menu, the icon is only 16x16 px
[16:53] <tiheum> 24x24 in the panel which is better but still small
[16:53] <seb128> charles, can we get the fallback to drop -charging?
[16:54] <charles> seb128, yes.
[16:54] <seb128> charles, thanks
[16:54] <charles> seb128, that won't fix the menu alignment issue but at least it'll get the broken icon off the panel
[16:54] <seb128> right
[16:54] <attente> seb128: it feels like some of the aptd transactions are slower for some reason, and sometimes i find after an update/search, the spinner kind of just runs forever
[16:55] <seb128> attente, k, I didn't use it enough to see, in fact I didn't use g-s since Prague I think
[16:55] <seb128> so difficult to say
[16:55] <seb128> but we keep it in proposed for a while and see the feedback
[16:55] <attente> yeah, not sure if that's a regression though either or if the archive version does it too
[16:55] <attente> ok
[16:58] <seb128> attente, get some more people on the channel to install it maybe, like willcooke & Laney, and see what's the feedback is by monday (no sru on friday anyway) and we can decide next week if we SRU it or if it needs more work?
[16:58] <attente> ok, sounds good
[16:59] <willcooke> attente, how do I test?  What needs doing?
[16:59] <willcooke> also: did the "update all" patch get in?
[16:59] <willcooke> (that was a thing being worked on, I think)
[16:59] <attente> willcooke: https://launchpad.net/~attente/+archive/ubuntu/gnome-software
[16:59] <willcooke> ((might be wrong))
[16:59] <seb128> I think that one is mainly a rebase on current stable upstream
[16:59] <attente> update all should be working
[16:59] <willcooke> attente, do I need to enable propsed as well, or just add the PPA?
[17:00] <willcooke> attente, @ update all - sweet!
[17:00] <attente> willcooke: just the ppa
[17:00] <willcooke> oki dokey
[17:00] <willcooke> and what should I be looking out for?
[17:00] <attente> i guess just try to do the usual activities, search, install, remove, updating
[17:00] <seb128> you play with it and see if it feels like it's working as before
[17:00] <seb128> looking for potential regressions in performances or behaviour
[17:01] <willcooke> I'd better play with the current version a bit more first then :)
[17:01] <seb128> yeah :-)
[17:01] <willcooke> am I a bad person.
[17:01] <willcooke> :)
[17:01] <attente> :) don't worry. you can always install the current version over the new one
[17:03] <Laney> night!
[17:03]  * Laney has marginally improved spinbuttons
[17:03]  * Laney screams
[17:03]  * Laney is off to a new micro pub to get away from it all
[17:04] <Laney> http://www.fhp.co.uk/news/micropub-a-pottle-of-blues-opens-in-beeston
[17:04] <seb128> night Laney!
[17:05] <willcooke> cya Laney
[17:23] <willcooke> hrmmmmmm
[17:23] <willcooke> I think I see why Radiance works
[17:24] <willcooke> and it's a one line fix if so....
[17:31] <seb128> willcooke, what is it? who fixed it? ;-)
[17:31] <willcooke> seb128, I think it's related to background-image
[17:31] <willcooke> just testing it now
[17:32] <willcooke> meh, that just made it wors
[17:32] <willcooke> e
[17:32] <willcooke> :)
[17:34] <willcooke> seb128, what's a good GUI diff tool?
[17:35] <seb128> meld?
[17:35] <seb128> it's the only one I know
[17:35]  * willcooke uses g-s to install it
[18:33] <charles> seb128, I've pushed work to lp:~charlesk/indicator-power/lp-1470080-missing-icon-when-apple-devices-connected to fall back to icon 'foo' if icon 'foo-charging' is unavailable
[18:33] <charles> seb128, could you test it with your apple device?
[18:33] <willcooke> charles, I can do that
[18:33] <charles> willcooke,  yay
[18:33] <willcooke> charles, seb128 would never own an Apple device :)
[18:35] <willcooke> charles, have you got time for a bit of hand-holding?  I need help getting it built.  If not, I can ask Seb to help me in the morning
[18:37]  * willcooke installs build-deps for indicator-power & cmake
[18:37] <charles> willcooke, I'll make a silo for it and build there. Would that be ok?
[18:37] <willcooke> charles, oh - maybe I did it :_
[18:37] <willcooke> :)
[18:37] <willcooke> I did cmake . and then make
[18:37] <willcooke> and something is happening
[18:37] <willcooke> I've got an indicator-power-service binary in src
[18:38] <charles> willcooke, ok from the terminal "$stop indicator-power" to stop the one that's already running for you
[18:38] <charles> and then you can run the one you just built, ie build/src/indicator-power-service
[18:38] <charles> and it should show up in the panel
[18:38] <willcooke> $ stop indicator-power-service
[18:38] <willcooke> stop: Unknown job: indicator-power-service
[18:39] <willcooke> can I just pkill it?
[18:39] <charles> willcooke, "stop indicator-power" not "stop indicator-power-service"
[18:39] <willcooke> ah!
[18:39] <willcooke> thx
[18:39] <charles> when you're done testing you can "$start indicator-power" to bring it back
[18:40] <willcooke> damn it, now the phone is fully charged :)
[18:40]  * willcooke uses battery
[18:40] <willcooke> MINECRAFT!!
[18:40] <charles> lol
[18:41] <charles> willcooke, you're familiar with the bug? if not popey's screenshot @ https://launchpadlibrarian.net/210338198/Selection_486.png from https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1470080 shows it in action
[18:41] <ubot5`> Launchpad bug 1470080 in indicator-power (Ubuntu) "Broken icon in indicator when iphone attached" [High,Triaged]
[18:42] <willcooke> checking
[18:47] <willcooke> charles, looks good!
[18:47] <charles> willcooke, \o/
[18:47] <willcooke> I've got some screenshots here, sec...
[18:49] <willcooke> charles, http://imgur.com/a/jACV7
[18:50] <charles> good good
[18:50] <willcooke> thanks a lot charles!
[18:51] <charles> tedg, as per ^ I made a couple more commits to https://code.launchpad.net/~charlesk/indicator-power/lp-1470080-missing-icon-when-apple-devices-connected/+merge/295752 after your Approve -- one to add the fallback icons, and one to make the device tests more readable as you suggested
[18:52] <charles> tedg, the former was literally a one-liner, replacing a 'break;' with a comment so that a switch's state-charging case could fall through to state-discharging
[18:52] <charles> tedg, the ripple effects in the unit tests though... :D
[18:53] <charles> willcooke, thanks for testing it out on your Apple device
[18:53] <willcooke> yw!
[18:58]  * tedg can't believe willcooke admitted publicly to owning an Apple device
[18:59]  * willcooke <-- hates freedom
[19:01] <willcooke> right, dinner time
[19:01] <willcooke> thanks chaps
[19:01] <willcooke> g'night