[02:52] <pitti> Good morning
[03:19] <pitti> infinity: slangasek's bug 1491145 reminded me of debian bug 779559 again; is that still something you can/want to work on, or should I try?
[06:24] <infinity> pitti: Ahh, oops.  I knew there was something I was forgetting.  I don't care where the patch comes from, now that we all agree on what the output should be.
[06:24] <infinity> pitti: So, if you're keen to dive into the Perl, be my guest, it should be trivial (ab)use of some existing methods and a few lines of glue, IMO.
[06:24] <pitti> infinity: I won't have much time for it either this week, just asking
[06:24] <infinity> pitti: But yeah, it's on my TODO, just slightly forgotten, ish.
[06:24] <pitti> but without having looked into it yet it doesn't sound particularly difficult?
[06:25] <pitti> (I'll probably think otherwise after I've seen the Perl :) )
[06:25] <infinity> pitti: Most of the dep parsing stuff is nicely broken out into reusable methods, ish.
[06:25] <infinity> pitti: So, it really should just be "take control field X, apply dep parsing method Y, vomit into new control field Z".
[06:26] <infinity> pitti: With a bit of extra open/read glue because it's another control file.  Though, dpkg-source might already read that now to set the Test: types.
[06:27] <infinity> pitti: Anyhow, I'm going to sleep.  Remind me again if you don't get to it, and I will.
[07:06] <dholbach> good morning
[07:49] <caribou> infinity: pitti: well I'm able to reproduce the rsyslog build failure on a Trusty host with a Wily schroot but not on a Wily host & wily schroot
[07:50] <pitti> caribou: ah, the buildds run a trusty or even precise kernels, so that might be it
[07:51] <caribou> pitti: thanks to cjwatson's suggestion of diffing the build logs
[07:51] <caribou> pitti: well now I can reproduce so I should be able to fix it
[08:28] <Laney> @pilot in
[09:19] <doko> jamespage, libcommons-cli-java ping
[09:36] <zyga> doko:
[09:37] <zyga> doko: I'm working on the patch all morning, it should be ready soon (plainbox)
[09:44] <cjwatson> pitti: almost entirely trusty, with the exception of the non-virtual armhf builders
[09:49] <TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks
[09:55] <jamespage> doko, hullo
[09:57] <doko> jamespage, could you have a look at libcommons-cli-java ping to de-mavenfy the package?
[09:57] <jamespage> doko, I need to clear through the openstack milestone 2 blockages first, and then I can take a peek
[09:57] <jamespage> doko, is it a new upstream version?
[09:57] <jamespage> for other packages I've just reverted the debian folder to a previous ant based one
[09:58] <doko> jamespage, was walking through the packages with ebourg which ones could be synced
[10:06] <jamespage> anyone know if there is a problem with upload queue processing?
[10:06] <cjwatson> jamespage: details?
[10:06] <jamespage> hmm - maybe its just email notifications
[10:06] <cjwatson> still details?
[10:06] <jamespage> cjwatson, checking
[10:07] <cjwatson> I made some changes to upload email notifications recently so I would rather like to know if there's a problem with them
[10:07] <jamespage> cjwatson, did that involve adding some headers per chance?
[10:07] <cjwatson> "some changes" -> completely refactored
[10:07] <cjwatson> jamespage: yes, they now have X-Launchpad-Message-Rationale and X-Launchpad-Notification-Type
[10:08] <jamespage> cjwatson, specifically I've done a few uploads this morning - python-mock, python-django-compressor, and a load of PPA uploads
[10:08] <jamespage> cjwatson, I've not seen email notifications for them since...
[10:09] <jamespage> 1930 ish yesterday
[10:09] <jamespage> that's 'Accepted' notifcations
[10:09] <cjwatson> jamespage: the logs claim to have mailed you about python-mock this morning
[10:09] <cjwatson> jamespage: http://paste.ubuntu.com/12252145/
[10:10] <cjwatson> jamespage: could you check that it hasn't been filtered off somewhere?
[10:11] <jamespage> cjwatson, that's my suspicion
[10:11] <jamespage> cjwatson, looking atm
[10:13] <jamespage> cjwatson, do you happen to know the X-Launchpad-Message-Rationale they should have?
[10:13] <jamespage> 'Changed-By'?
[10:13] <cjwatson> jamespage: Probably "Requester"
[10:13] <cjwatson> or possibly "Changed-By"
[10:14] <jamespage> cjwatson, ah-ha - found them
[10:14] <cjwatson> if you signed the upload that will take precedence and it should be "Requester"
[10:14] <cjwatson> (which is slightly vague because that level of the code can't currently tell the difference between uploads and syncs - may change in future)
[10:14] <jamespage> cjwatson, I see a requester tagged email for the upload, and then a changed-by for the proposed->release pockey migration
[10:14] <cjwatson> Right
[10:14] <cjwatson> Because you didn't request that copy
[10:15] <cjwatson> Also, X-Launchpad-Notification-Type: package-upload
[10:15] <jamespage> yes - thanks for the clarification
[10:16] <cjwatson> It should be more filterable now, but it's true that some configurations may require tweaking
[10:24] <doko> arges, please finish transitions if you start them (libecap). now hopefully done
[10:25] <doko> arges, argh, no. squid3 needs an update
[10:26] <rbasak> I was supposed to do a squid3 merge to fix that, but didn't manage it before feature freeze
[10:26] <rbasak> I'd forgotten about the libecap complication
[10:28] <cjwatson> jamespage: documented on https://help.launchpad.net/LaunchpadMessageRationale now
[10:45] <LocutusOfBorg1> Laney, please ping me if you intend to do any virtualbox related work
[10:46] <LocutusOfBorg1> I'm working on an MRE
[10:46] <LocutusOfBorg1> https://titanpad.com/IVSgUZauQV
[10:46] <Laney> LocutusOfBorg1: should I sponsor the lts thingy or not?
[10:46] <LocutusOfBorg1> I don't know
[10:47] <LocutusOfBorg1> should we really split the package an maintain two?
[10:47] <LocutusOfBorg1> also I prefer to start from a virtualbox-lts-wily instead
[10:48] <LocutusOfBorg1> but I guess all the effort is waiting for an MRE and debian bug 794466
[10:48] <Laney> I don't know much about the LTS stack
[10:48] <Laney> does every rdep of the renamed stuff need to be renamed too?
[10:49] <Laney> Anyway, happy to wait if you want
[10:52] <Laney> slangasek: bug #1429327 is in the queue but it looks like you're handling it, right?
[10:52] <Laney> (unsubscribed sponsors, feel free to re-add)
[10:59] <LocutusOfBorg1> Laney, I guess so, but we can't maintain an lts-* virtualbox package at each release...
[11:00] <ricotz> Laney, regarding https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048 -- the ppa contains proper versioned source of the succeeded rebuilds
[11:00] <Laney> ricotz: thanks!
[11:01] <LocutusOfBorg1> I would appreciate a feedback from who uploaded the lts breaking-rdeps xserver-xorg-core
[11:03] <Laney> LocutusOfBorg1: Maybe a thread on -devel is in order
[11:10] <doko> diwic, pulseaudio has an unconditional b-d on trust-store
[11:10] <tjaalton> LocutusOfBorg1: what broke?
[11:11] <diwic> doko, and trust-store is not in main...?
[11:12] <diwic> doko, oh, it is not :-/
[11:12] <LocutusOfBorg1> tjaalton, bug 1424769
[11:12] <diwic> doko, thanks.
[11:13] <tjaalton> LocutusOfBorg1: ah, so need renamed backports for lts-*
[11:14] <LocutusOfBorg1> I have to upload a virtualbox-lts-{utopic,vivid,wily} and so on?
[11:14] <tjaalton> utopic isn't supported anymore
[11:14] <tjaalton> but yes
[11:14] <Laney> tjaalton: could we do that more automatically?
[11:14] <LocutusOfBorg1> and maintain all of them?
[11:15] <tjaalton> LocutusOfBorg1: it's no different from stock $release
[11:15] <Laney> or at least find out what gets broken as a start
[11:15] <tjaalton> well this was all done before me
[11:15] <LocutusOfBorg1> and specially people should be aware of a different vbox package
[11:15] <tjaalton> dunno why virtualbox didn't get the love
[11:16] <LocutusOfBorg1> well what does happen when an user has mesa-lts-utopic and switch to mesa-lts-vivid?
[11:16] <LocutusOfBorg1> is that automatic? virtualbox gets removed, right?
[11:16] <LocutusOfBorg1> he has to know about virtualbox-lts-wily
[11:16] <LocutusOfBorg1> hoping somebody uploaded it together with the rest of the lts stack
[11:17] <tjaalton> one does not "switch to mesa-foo"
[11:17] <tjaalton> that's never supported
[11:17] <LocutusOfBorg1> well the user notices a new mesa is available
[11:17] <tjaalton> how exactly?
[11:17] <LocutusOfBorg1> apt?
[11:17] <LocutusOfBorg1> synaptic?
[11:17] <Laney> it's new packages
[11:17] <tjaalton> ooh, a new package
[11:18] <LocutusOfBorg1> yes
[11:18] <Laney> you would have to go looking for it
[11:18] <tjaalton> it's not shown in updates
[11:18] <Laney> but uninstallability is a real issue
[11:18] <LocutusOfBorg1> somebody should upload the virtualbox new lts-wily package together with mesa-lts wily I guess
[11:18] <tjaalton> yes
[11:19] <tjaalton> sometime between nov-jan
[11:19] <Laney> and -vivid for 14.04.3
[11:20] <Laney> how can we tell which packages need this treatment?
[11:20] <tjaalton> so why wasn't this an issue for precise lts backports?
[11:21] <tjaalton> search for packages that provide xorg-vide-abi-foo
[11:21] <tjaalton> -video
[11:21] <tjaalton> err
[11:22] <tjaalton> virtualbox-guest-x11 just Provides xorg-driver-video
[11:22] <tjaalton> hm no
[11:22] <tjaalton> the xserver provides the abi of course, drivers depend on it
[11:23] <tjaalton> got that all wrong
[11:23] <Laney> is it anything that depends on xorg-video-abi-XXX?
[11:23] <tjaalton> right
[11:23] <Laney> seems it is just virtualbox + xorg + drivers
[11:25] <Laney> tjaalton: is there some documentation/process for the lts backports that we an add this to?
[11:26] <tjaalton> no
[11:26] <tjaalton> just scripts for renaming stuff
[11:29] <Laney> can you take a note to add the r-deps check maybe? :)
[11:31] <tjaalton> 14:31 < mlankhorst> no, we never did any virtualbox backport
[11:32] <tjaalton> also, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says that newer point-release are not (recommended) for virtual machines
[11:33] <tjaalton> so dunno, i'd rather not support it tbh
[11:36] <Laney> I think that probably means as guest
[11:36] <Laney> it's not reasonable to expect people to consider if they might ever want to install virtualbox when originally installing the LTS
[11:36] <tjaalton> that's where you need the package, not on host
[11:39] <doko> barry, restored zope.security changes, needed for schooltool
[11:44] <Laney> tjaalton: Oh right, that's where the broken package is - meh, this sucks as an experience though
[11:45] <Laney> https://ubuntu.com/download/desktop is all "get 14.04.3"
[12:00] <diwic> doko, tvoss is going to work on getting trust-store into main
[12:00] <diwic> doko, then we can redo the build
[12:01] <doko> diwic, tvoss: this is fine too, but not the problem. trust-store isn't built on all archs
[12:01] <diwic> doko, but it is not a build dependency on all archs, is it?
[12:02]  * diwic checks
[12:02] <tvoss> diwic, just let me know what you want me to do :)
[12:03] <diwic> doko, libtrust-store-dev is only listed as a build-dep for armhf, i386, and amd64
[12:03] <diwic> doko, and I believe trust-store builds on all those three, right?
[12:07] <doko> diwic, tvoss: my bad ... so yes, starting writing MIRs for trust-store and all its dependencies
[12:10] <Laney> cyphermox: are you handling bug #1432062? i.e. can I remove sponsors?
[12:17] <TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks, or how to safely delete them
[12:17] <tjaalton> LocutusOfBorg1: are you willing to test a lts-vivid build of vbox?
[12:22] <LocutusOfBorg1> tjaalton, I'm uploading it right now on my ppa
[12:24] <tjaalton> erm, the debdiff should look something like http://sprunge.us/LUTL
[12:25] <LocutusOfBorg1> tjaalton, yes sure, it is basically renaming files
[12:25] <tjaalton> but if you miss anything it's gonna fail, this was done with a script
[12:26] <LocutusOfBorg1> actually the packaging changes not too much, so I applied the debdiff for utopic and it applied almost cleanly
[12:26] <LocutusOfBorg1> after a sed to vivid
[12:26] <LocutusOfBorg1> let's see the upload how it goes
[12:26] <tjaalton> vbox build-depends on gcc-4.9? that won't work
[12:27] <tjaalton> heh, and libglu1-mesa-dev which isn't coinstallable with the backports
[12:27] <tjaalton> so no it's not going to work
[12:28] <Laney> doko: kodi needed FFe, also there was a sponsor bug to close, please check before syncing
[12:30] <LocutusOfBorg1> tjaalton, yes, gcc-4.9 was forced to avoid use of gcc-5 in Debian
[12:30] <LocutusOfBorg1> for glu1-mesa-dev let me test once it is built :)
[12:31] <tjaalton> does trusty have gcc-4.9? it didn't build here because of it
[12:31] <LocutusOfBorg1> tjaalton, the problem was gcc-5 too new, so we forced gcc-4.9
[12:31] <caribou> pitti: I think I found the fix for rsyslog's FTBS.
[12:31] <LocutusOfBorg1> any compiler < 4.9 is fine
[12:31] <caribou> pitti: How should I push the fix ? debdiff or MP ?
[12:32] <tjaalton> LocutusOfBorg1: so a backport can't be reliably scripted
[12:32] <LocutusOfBorg1> well not when gcc has a major release
[12:32] <pitti> caribou: I'd prefer a debdiff, much easier (on the original sponsoring bug is fine, or email, or pastebin -- whatever you prefer)
[12:32] <pitti> caribou: and nice work!
[12:32] <caribou> pitti: I'll push a debdiff on the merge bug
[12:33] <LocutusOfBorg1> the problem was a bug in gcc-5 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 fixed here https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218248
[12:34] <caribou> pitti: was rather nasty : tcpflood.c uses rand() + SomeValue and in some cases this calculation wraps to a negative value
[12:34] <caribou> when the result of rand() is close to RAND_MAX
[12:34] <caribou> and the result > 32 bits
[12:35] <caribou> pitti: I'm also pushing the fix upstream
[12:35] <caribou> pitti: so reproducing it is not systematic as it depends on the random value
[12:40] <Laney> ricotz: karlyriceditor kino have ricotz1 versions too still
[12:47] <pitti> Riddell: so doko and I just untangled (at least one aspect of) the akonadi uninstallability
[12:47] <ricotz> Laney, repushed, seems launchpad lost them somehow
[12:47] <Laney> ricotz: thanks, copying the first lot now
[12:47] <pitti> Riddell: https://launchpad.net/ubuntu/+source/kdepim/4:15.08.0-0ubuntu1 drops knode (i. e. NBS), but knode depends on a lot of NBS/old/uninstallable libraries
[12:48] <pitti> Riddell: if dropping knode was intentional, the kdepimlibs binary needs to drop its Depends: knode
[12:48] <doko> pitti, wait a moment until sitter appears, or join #kubuntu-devel
[12:48] <pitti> Riddell: is that intentional?
[12:48] <sitter> I am here :P
[12:48] <pitti> sitter: hello
[12:48] <ricotz> Laney, libde265 isn't listed in the transition page, I forgot some regex-name-tweaks
[12:49] <pitti> sitter: so either the knode binary needs to get back, or kdepim needs to drop its depends: to it
[12:49] <Laney> ricotz: I just copied everything built in the ppa
[12:49] <caribou> pitti: debdiff is now on LP: #1464201
[12:49] <Laney> assuming it works
[12:49] <ricotz> Laney, ok, expect the failed one of course ;)
[12:49] <Laney> yes
[12:49] <pitti> sitter: same for kaddressbook-mobile, AFAICS
[12:49] <doko> pitti, already dropped in 15.08.0-0ubuntu2
[12:50] <ricotz> Laney, I might propose another transition for "libav-tools"
[12:50] <pitti> . o O { there once was a time when changelogs documented such major changes.. }
[12:50] <doko> Laney, does this ffmpeg stuff interfer with kde?
[12:50] <pitti> doko: no, http://launchpadlibrarian.net/216056388/kdepim_4%3A15.08.0-0ubuntu1_4%3A15.08.0-0ubuntu2.diff.gz does no such thing
[12:51] <Laney> no we still have the old binaries
[12:51] <ricotz> doko, kde got silently transitioned already
[12:51] <sitter> pitti, doko: ubuntu1 shouldhn't have a reference to either of those packages
[12:51] <doko> ricotz, no
[12:51] <Laney> ok there we go, seems the copies happened
[12:51] <ricotz> doko, yes
[12:51] <sitter> hm
[12:52]  * Laney goes to lunch
[12:52] <sitter> pitti: the kdepim*libs* package you say?
[12:52] <Laney> @pilot out
[12:52] <pitti> sitter, doko: oh, ok; well, then *something* else is missing :/
[12:52] <doko> ricotz, no or else pitti or sitter would talk about it
[12:52] <ricotz> http://people.canonical.com/~ubuntu-archive/transitions/html/ffmpeg.html
[12:52] <ricotz> look at the good ones
[12:53] <sitter> pitti: libakonadiprotocolinternals1 is missing
[12:53] <ricotz> of course this only tracks dependencies, runtime deps are not considered like apps using "libav-tools"
[12:53] <sitter> due to reappear through the new akonadi1 source though which is building now
[12:54] <Laney> ricotz: will you look at the ftbfs?
[12:54] <pitti> sitter: yeah, I figure that's NBS as well, I didn't wade through all of the rdependencies yet (there's lots of transitions at the same time..)
[12:54] <pitti> sitter: ah, so libakonadiprotocolinternals1 will come back?
[12:54] <sitter> yep
[12:54] <ricotz> Laney, they are toolchain and qt related, so currently not
[12:55] <sitter> doko: regarding ffmpeg off the top of my head we only have one package that directly links to ffmpeg all other stuff is abstracted through phonon/gstreamer/libvlc
[12:55] <ricotz> Laney, will the transition page update itself?
[12:55] <Laney> yes
[12:55] <ricotz> ok
[12:56] <sitter> doko, ricotz: only ffmpegthumbs should have needed a rebuild on the kde side of things and that apparently picked it up as part of the kde applications 15.08 landing https://launchpad.net/ubuntu/+source/ffmpegthumbs/4:15.08.0-0ubuntu1/
[12:57] <ricotz> sitter, and kfilemetadata?
[12:58] <sitter> also seems built against ffmpeg https://launchpadlibrarian.net/213741522/buildlog_ubuntu-wily-amd64.kfilemetadata_4%3A4.14.2-0ubuntu2_BUILDING.txt.gz
[12:59] <ricotz> sitter, right, just saying there are more ;)
[12:59] <sitter> ah yeah, I forgot about that bugger ^^
[12:59] <ricotz> sitter, looking at apps using "libav-tools" aka avconv is needed too
[13:00] <sitter> that list should be slightly longer
[13:00] <sitter> ricotz: what do we need to do to them?
[13:00] <ricotz> exactly
[13:01] <pitti> caribou: uploaded, cheers!
[13:01] <caribou> pitti: thanks!
[13:01] <ricotz> sitter, make them use the "ffmpeg" package and its ffmpeg binary
[13:01] <caribou> pitti: let's cross finger & hope it builds :-)
[13:01] <doko> ricotz, sitter: not before we get the current migration done
[13:02] <sitter> I'll send a mail to the kubuntu list, lest we forget
[13:04] <barry> doko: thanks
[13:05] <cyphermox> good morning!
[13:05] <cyphermox> Laney: fixed up bug 1432062.
[13:14] <pitti> caribou: oh noes
[13:15] <pitti> read value 23, but expected value 22
[13:15] <pitti> caribou: I pretend I didn't see that and just retry
[13:16] <caribou> pitti: can be a race condition, his testbench is subjec to that
[13:16] <caribou> pitti: it builds fine on i386, want me to retry here ?
[13:16] <pitti> caribou: that was on amd64 this time; I guess/hope it'll build the second time
[13:16] <pitti> caribou: I guess the tests are still quite new and need to mature a bit
[13:17] <caribou> pitti: I'll keep an eye on this
[13:17] <caribou> pitti: indeed. The upstream maintainer does agree & I know that the debian maintainer is also closely working with him on that
[13:18] <caribou> pitti: I just sent the DM my fix
[13:18] <pitti> caribou: say hello to mbiebl_ from me :)
[13:18] <caribou> pitti: will do :)
[13:28] <caribou> pitti: \o/ it built
[13:40] <ricotz> doko, does this looks fine to you http://pastebin.ubuntu.com/12253274/
[14:07] <Odd_Bloke> arges: We've identified a fairly important regression caused by the last set of cloud-init uploads, and I have a fix ready to be uploaded by someone, but another version has just hit {t,v}-proposed; what's the correct way of handling this?
[14:09] <arges> Odd_Bloke: well I assume your fixes are a superset of the previous changes, then we can upload over the current -proposed version
[14:10] <Odd_Bloke> arges: Should I just ask whoever ends up doing my upload to pull from -proposed, apply my debdiff and then upload?
[14:11] <arges> Odd_Bloke: Just make sure we don't drop fixes that are already there. Does the current version in -proposed cause the regression?
[14:11] <Odd_Bloke> arges: Nope, it's completely orthogonal.
[14:11] <Odd_Bloke> The version that got released from -proposed last week causes the regression.
[14:12] <Odd_Bloke> And we now have a new test case for changes to the Azure bits of the code. :p
[14:13] <arges> Odd_Bloke: yea so make sure the new upload contains the fixes in -proposed as well. That should be sufficient
[14:13] <Odd_Bloke> OK, cool.
[14:13] <Odd_Bloke> arges: Thanks. :)
[14:13] <arges> Odd_Bloke: no problem
[14:14] <revolve> Hello there, I'm having a problem with redhat cluster manager in 12.04, it's producing this error: Starting cman... /usr/lib/lcrso/service_amf.lcrso: open failed: /usr/lib/lcrso/service_amf.lcrso: undefined symbol: logsys_rec_end
[14:15] <revolve> I've also built it and its dependencies from src, experienced the same thing, and replaced them with the version from the repos again
[14:17] <Logan> Laney: <3
[14:20] <rbasak> revolve: this is a development channel. Try #ubuntu or #ubuntu-server. When you do it might also be useful to state which package you're having a problem with.
[14:20] <revolve> thanks
[14:26] <Laney> hey Logan!
[14:26] <Logan> thanks for all the syncs :P
[14:26] <Laney> cyphermox: thx
[14:51] <slangasek> Laney: sorry, bug #1429327 - which queue?  I'm not handling anything with respect to that at the moment
[14:51] <infinity> pitti: Is the weird "skip everything, then pass" mode in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/ppc64el/n/nvidia-graphics-drivers-352-updates/20150902_105426@/log.gz a behaviour of autopkgtest or the nvidia tests themselves?
[14:52] <Laney> slangasek: the ~ubuntu-sponsors queue
[14:52] <infinity> pitti: Seems weird that's not a failure or, ideally, a new "skipped" state.
[14:52] <pitti> infinity: in between, it's from the dkms package's generalized dkms testing script
[14:52] <infinity> pitti: (Only noticed because I had to re-run a ppc64el nvidia test due to a different "failure", and I was curious how nvidia could ever regress on ppc64el in the first place :P)
[14:52] <pitti> infinity: we don't build it on ppc64el, so none of the binaries  works
[14:53] <pitti> infinity: ah, funny; I just re-kicked that test too
[14:53] <pitti> (temp failure resolving ports.u.c.)
[14:53] <infinity> pitti: Right, none of the binaries available should lead to a "skip", I would think, but I guess skip==success is alright for now, just surprising.
[14:53] <infinity> pitti: Is there blocking serialisation on retries, or did we just start two jobs? :)
[14:54] <pitti> infinity: we started two
[14:54] <infinity> Go us.
[14:54] <pitti> infinity: sorry to wolfe for wasting a whopping 3 minutes of their time
[14:54] <infinity> pitti: Yeah, not a big deal for this no-op test. :)
[14:54] <slangasek> Laney: ah, yes I don't think that belongs in the sponsors queue
[14:54] <infinity> pitti: But maybe some locking would be in order, somewhere down the todo after in-progress UI feedback of some sort.
[14:54] <pitti> infinity: so, the more interesting thing here would be to auto-retry on DNS resolution glitches
[14:54] <infinity> Or maybe before it.
[14:55] <LocutusOfBorg1> dholbach, now the syncpackage should work
[14:55] <LocutusOfBorg1> syncpackage -f -s mapreri -V 0.7.2+dfsg-2 flightcrew && syncpackage -f -s mapreri -V 0.8.7+dfsg-2 sigil
[14:55] <LocutusOfBorg1> :)
[14:55] <infinity> pitti: Optimising for network issues (especially in our own DC) leaves a bad taste in my mouth.
[14:55] <pitti> infinity: right, if/once we expose the pending queues, this will be much simpler
[14:55] <infinity> pitti: But if this is generic code that's also making its way back to Debian, I agree, since their distributed network is much less reliable than ours is (or should be).
[14:56] <pitti> infinity: I already have the usual apt-get update || { sleep 15; apt-get update } loop for update, due to the dreaded Hash Sum Mismatches, but not for dist-upgrade or install
[14:56] <dholbach> LocutusOfBorg1, aren't the two packages from yesterday synced already?
[14:56] <pitti> infinity: yeah, hopefully less of an issue once ppc64el moves into scalingstack
[14:56] <dholbach> LocutusOfBorg1, but I'm busy right now - just about to join a call
[14:56] <infinity> pitti: Yeah.  apt 1.1 will save us on the mismatch thing.  Not that we'll be backporting that to << 16.04, though.
[14:56] <pitti> infinity: cjwatson's LP report today sounded like this might actually happen soon
[14:57] <LocutusOfBorg1> dholbach, no problem, I remembered they were in incoming
[14:57] <infinity> pitti: Though, the *other* mismatch bug (Translations-specific) should be fixed once IS rolls out my trivial mirror change.
[14:57] <dholbach> right - yeah, I think they're synced and in wily now :)
[14:58] <infinity> pitti: So, you'll just be left with that tiny "I downloaded Release before the dists switch and Packages after" race window.
[14:58] <infinity> Which, I realise, is a very visible window at scale. :/
[14:59] <pitti> infinity: yeah, it seems everyone (autopkgtest, launchpad buildd, etc.) uses that same "try again after sleep" approach (I got it from Colin)
[15:00] <infinity> pitti: Yup, it's gross, but we know we don't pulse more than every 5m (realistically, every 15 or so), so the odds of hitting the same race twice in a row are pretty slim.  The sleep is entirely unnecessary, though.
[15:00] <infinity> pitti: Given that the reason it fails is because you're on a new dists tree halfway through "apt-get update", you know the second run will also be on the new dists tree, unless you sleep too long.  So don't sleep at all, IMO.
[15:01] <infinity> pitti: So, you can optimise out that waste 15s, if you like.
[15:01] <infinity> s/waste/wasted/
[15:01] <pitti> infinity: ah, good point
[15:02] <infinity> pitti: Though, you have an extra fun problem, in that you use archive/ports instead of ftpmaster, so you could concievably hit the race on mirror1, retry, and hit the race on mirror2 because it's a few seconds behind. :P
[15:03] <infinity> pitti: Arguably, you should just use ftpmaster.
[15:04] <pitti> infinity: yeah, I'm going to for armhf; for ppc64el that needs to go via proxy, but should still be better than the mirror hopefully
[15:05] <pitti> infinity: the cloud instances already use ftpmaster.internal
[15:05] <pitti> just didn't do the magic for the LXC boxes yes
[15:05] <pitti> yet
[15:05] <pitti> (bug 1490899)
[15:06] <infinity> pitti: Ahh, kay, if scalingstack is using ftpmaster, than I'll just assume that's the way forward.
[15:06] <infinity> pitti: The other (disgusting) option I had, if there were concerns of CPU/bandwidth pressure on pepo, would be to break your resolver. ;)
[15:07] <pitti> infinity: pepo?
[15:07] <infinity> pitti: host archive.ubuntu.com > chroot/etc/hosts
[15:07] <infinity> pitti: pepo == ftpmaster
[15:07] <pitti> ah
[15:08] <infinity> pitti: If there ever is a concern, the resolver-breaking approach would work, so you still round-robin between builds but guarantee a consistent single-host per build.
[15:08] <infinity> pitti: But also ew. ;)
[15:14] <mterry> arges, thanks for fixing my tgt version for trusty
[15:14] <arges> mterry: no problem! glad that bug finally got fixed
[15:26] <ricotz> Laney, could you copy the 3 remaining packages: fuse-emulator-utils, karlyriceditor, kino
[15:28] <Laney> ricotz: I don't see fuse-emulator-utils
[15:28] <Laney> but for the rest ok
[15:29] <ricotz> Laney, ah sorry, regarding bino: http://pastebin.ubuntu.com/12253274/
[15:51] <mapreri> dholbach: actually sigil ain't synced yet (uploaded in debian only this morning)
[15:52] <dholbach> mapreri, yep, sorry - I was commenting on flightcrew and gimp-help which LocutusOfBorg1 asked me to sync yesterday evening
[15:53] <mapreri> dholbach: well, now if you sync sigil you should add -b 1491459
[15:53] <mapreri> :)
[15:53] <dholbach> no, I won't get around to it today
[15:53] <dholbach> I'm still in a call and need to run afterwards
[15:53] <mapreri> i don't really care about the -s
[15:54] <mapreri> fine for me, whenever before wily release ;P
[18:33] <doko> pitti, autopkgtest for kde4pimlibs in progress for some hours on armhf ... :-/
[19:04] <ricotz> slangasek, hi, could you take care of https://code.launchpad.net/~ricotz/ubuntu-transition-tracker/ffmpeg/+merge/269963
[19:52] <doko> barry, something already installs python3.5
[19:58] <doko> barry, this is plainbox, but when built locally it doesn't have this dep
[20:01] <infinity> doko: I assume it's the usual "install_scripts sets shebang incorrectly" misfeature.
[20:01] <infinity> doko: So, when the last install_scripts is the 3.5 one, you get python3.5 as the shebang.
[20:01] <doko> otoh, we want python3.5 in the end ;p
[20:02] <infinity> doko: dh_python3 --shebang=/usr/bin/python3 worked around it last time I saw this.
[20:02] <infinity> doko: We don't ever want versioned shebangs, IMO.
[20:02] <infinity> (unless something actually only works with that version)
[20:04] <doko> infinity, something else, can somebody other than pitti manage autopkg tests?
[20:04] <infinity> doko: Define "manage".
[20:06] <doko> infinity, http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ (triggered by akonadi1) Test in progress for 5h
[20:06] <infinity> doko: I'm not sure any of us know how the infra works yet to play with it if it explodes, but that should be coming along.  As for retrying tests, a select few of us can do that, but work's in progress to open it up.
[20:06] <infinity> doko: Oh, stalled tests, I can't do much about, but I can retry it.  Maybe it's not stalled, but lost. :P
[20:07] <infinity> (It's on the TODO to make the in-progress stuff less opaque too)
[20:07] <doko> infinity, it will fail, and I can do that too
[20:08] <doko> infinity, can you set it to ignore? or jibel ?
[20:08] <infinity> I can ignore it for promotion.
[20:08] <doko> would be nice to see what britney thinks then ...
[20:09] <doko> ohh mehh, rtg limiting the list of architectures for packages ...
[20:10] <infinity> doko: Not really.
[20:11] <doko> ?
[20:11] <infinity> doko: All the other binaries in that package were already arch-restricted.
[20:11] <infinity> doko: For some reason, the -dev was arch:any, it was just a bug.
[20:12] <infinity> Given the library was arch-restricted, having the -dev not match made no sense. :P
[20:12] <doko> no
[20:12] <doko> Package: mstflint
[20:12] <doko> Architecture: linux-any
[20:12] <infinity> Oh, I thought you were talking about numactl
[20:13] <infinity> Bah, and he *just* left IRC.
[20:14] <infinity> And that's even reverting a change I made.  Excellent. :P
[20:14] <doko> sent email
[20:18] <doko> looks like the hint was good enough, the whole mess seems to migrate
[22:13] <doko> jamespage, what's the status of jenkins? there are still packages depending on jenkins in wily. remove these? otoh, why not keep jenkins in -proposed and file a block-proposed issue?
[22:24] <barry> lifeless: ping
[22:28] <slangasek> ricotz: done, with modifications
[22:35] <lifeless> barry: pong
[22:36] <barry> lifeless: hi.  i was looking at pyjunitxml.  i see debuntu is a bit behind upstream, and i was also wondering if 0.7 is compatible with py3.5
[22:36] <lifeless> barry: I haven't specifically tested
[22:36] <lifeless> barry: but if its not it should get fixed :)
[22:37] <barry> lifeless: ok! :)  i'm about to do a test build with 0.7...
[22:37] <lifeless> hmm, I need to move it over to git too
[22:37] <lifeless> long tail of projects to migrate
[22:37] <barry> lifeless: probably so
[22:37] <barry> i hear ya there :)
[22:38] <barry> lifeless: 6 test failures in 3.5.  i'll file a bug
[22:39] <lifeless> barry: all test-only issues
[22:39] <lifeless> barry: qualname stuff
[22:40] <barry> lifeless: hard to say from the output here
[22:40] <lifeless> barry: I just reproduced and checked
[22:40] <lifeless> - <testcase classname="junitxml.tests.test_junitxml.Succeeds" name="test_me" time="0.000">
[22:40] <barry> lifeless: ah
[22:40] <lifeless> + <testcase classname="junitxml.tests.test_junitxml.TestJUnitXmlResult.test_unexpected_success_test.&lt;locals>.
[22:40] <barry> yep
[22:40] <lifeless> thats an inner class showing pu
[22:40] <lifeless> up
[22:41] <barry> ack.  should i file a bug?  i'd like to be able to track 3.5 compat since this is a seeded package
[22:41] <lifeless> sure
[22:41] <lifeless> I won't get to it today
[22:41] <barry> lifeless: no worries.  i am eod.
[22:42] <barry> lifeless: LP: #1491635
[22:43] <barry> lifeless: thanks.  ttyl.
[22:43] <lifeless> barry: ciao :)
[22:45] <doko> infinity, user-mode-linux needs more changes than bumping the linux version
[23:02] <slangasek> uml still exists?
[23:02] <doko> yeah, some nerd is till updating
[23:04] <lifeless> doko: nerd?
[23:06] <doko> go away
[23:07] <lifeless> wow, this isn't the Ubuntu-devel that I remember.
[23:08] <doko> wrong channel
[23:18] <lifeless> doko: I agree - its the wrong channel for aggressive and insulting behaviour. I'm not sure how best to put this - but I think your last three messages are really quite far outside the Ubuntu CoC which still applies to the best of my knowledge.