[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
=== salem_ is now known as _salem
[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?
=== mfisch is now known as Guest83454
[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
=== Malsasa_ is now known as Malsasa
[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:19] <ubottu> bug 1503052 in aptitude (Ubuntu) "aptitude does not start - symbol lookup error" [Undecided,Confirmed] https://launchpad.net/bugs/1503052
[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:38] <ubottu> bug 1435466 in nodejs (Ubuntu) "nodejs fails to build on arm64 due to libv8 dependency" [Undecided,Fix committed] https://launchpad.net/bugs/1435466
[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:09] <ubottu> Launchpad bug 1503207 in qtbase-opensource-src (Ubuntu) "qtmake's linux-g++-m64 spec sets -m64 on aarch64-linux-gnu" [Undecided,New]
[10:22] <Mirv> doko: thanks!
=== hikiko-lpt is now known as hikiko
=== _salem is now known as salem_
[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 :)
=== Malsasa_ is now known as Malsasa
[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)
=== davidcalle_ is now known as davidcalle
[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
=== Guest83454 is now known as mfisch
=== mfisch is now known as Guest94490
[14:20] <barry> didrocks: i'd like to get doko's opinion on LP: #1500768
[14:20] <ubottu> Launchpad bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged] https://launchpad.net/bugs/1500768
[14:23] <popey> cyphermox: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1503306
[14:23] <ubottu> Launchpad bug 1503306 in plymouth (Ubuntu) "Cannot enter LUKS passphrase after installing nvidia-current" [Undecided,New]
[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:39] <ubottu> Launchpad bug 1503311 in python-traceback2 (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
[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] <ubottu> bug 22417 in valgrind (Ubuntu) "valgrind doesn't work with gstreamer based apps" [Medium,Fix released] https://launchpad.net/bugs/22417
[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
=== magicalC1icken is now known as magicalChicken
[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:00] <ubottu> bug 1502529 in ubuntu-release-upgrader (Ubuntu) ""Upgrading Ubuntu to version " not translated" [Undecided,Confirmed] https://launchpad.net/bugs/1502529
=== Guest94490 is now known as mfisch
=== mfisch is now known as Guest62625
=== Malsasa_ is now known as Malsasa
=== pat__ is now known as pmcgowan
[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:25] <ubottu> Launchpad bug 1503311 in python-traceback2 (Ubuntu) "Sync request of python-traceback2 1.4.0-3 from Debian testing: FTBFS due to failing unit tests" [Undecided,Confirmed]
[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
=== fginther` is now known as fginther
[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:13] <ubottu> bug 874479 in juffed (Ubuntu) "Cannot be run" [Undecided,Fix released] https://launchpad.net/bugs/874479
[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!
=== salem_ is now known as _salem
[22:50] <ginggs> hi, who can i bug about a MIR (LP: #1421209)?
[22:50] <ubottu> Launchpad bug 1421209 in nvidia-modprobe (Ubuntu) "[MIR] nvidia-modprobe" [Undecided,New] https://launchpad.net/bugs/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:14] <ubottu> Launchpad bug 1502529 in ubuntu-release-upgrader (Ubuntu) ""Upgrading Ubuntu to version " not translated" [High,Confirmed]
[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.