[02:52] Good morning [03:19] 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? [03:19] bug 1491145 in dpkg (Ubuntu) "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/1491145 [03:19] Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open] http://bugs.debian.org/779559 === nudtrobert1 is now known as nudtrobert [06:24] 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] 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] infinity: I won't have much time for it either this week, just asking [06:24] pitti: But yeah, it's on my TODO, just slightly forgotten, ish. [06:24] but without having looked into it yet it doesn't sound particularly difficult? [06:25] (I'll probably think otherwise after I've seen the Perl :) ) [06:25] pitti: Most of the dep parsing stuff is nicely broken out into reusable methods, ish. [06:25] pitti: So, it really should just be "take control field X, apply dep parsing method Y, vomit into new control field Z". [06:26] 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] pitti: Anyhow, I'm going to sleep. Remind me again if you don't get to it, and I will. [07:06] good morning === zbenjamin_ is now known as zbenjamin [07:49] 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] caribou: ah, the buildds run a trusty or even precise kernels, so that might be it [07:51] pitti: thanks to cjwatson's suggestion of diffing the build logs [07:51] pitti: well now I can reproduce so I should be able to fix it [08:28] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney [09:19] jamespage, libcommons-cli-java ping [09:36] doko: [09:37] doko: I'm working on the patch all morning, it should be ready soon (plainbox) === greyback__ is now known as greyback === sitter_ is now known as sitter [09:44] pitti: almost entirely trusty, with the exception of the non-virtual armhf builders [09:49] 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] doko, hullo [09:57] jamespage, could you have a look at libcommons-cli-java ping to de-mavenfy the package? [09:57] doko, I need to clear through the openstack milestone 2 blockages first, and then I can take a peek [09:57] doko, is it a new upstream version? [09:57] for other packages I've just reverted the debian folder to a previous ant based one [09:58] jamespage, was walking through the packages with ebourg which ones could be synced [10:06] anyone know if there is a problem with upload queue processing? [10:06] jamespage: details? [10:06] hmm - maybe its just email notifications [10:06] still details? [10:06] cjwatson, checking [10:07] 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] cjwatson, did that involve adding some headers per chance? [10:07] "some changes" -> completely refactored [10:07] jamespage: yes, they now have X-Launchpad-Message-Rationale and X-Launchpad-Notification-Type [10:08] cjwatson, specifically I've done a few uploads this morning - python-mock, python-django-compressor, and a load of PPA uploads [10:08] cjwatson, I've not seen email notifications for them since... [10:09] 1930 ish yesterday [10:09] that's 'Accepted' notifcations [10:09] jamespage: the logs claim to have mailed you about python-mock this morning [10:09] jamespage: http://paste.ubuntu.com/12252145/ [10:10] jamespage: could you check that it hasn't been filtered off somewhere? [10:11] cjwatson, that's my suspicion [10:11] cjwatson, looking atm [10:13] cjwatson, do you happen to know the X-Launchpad-Message-Rationale they should have? [10:13] 'Changed-By'? [10:13] jamespage: Probably "Requester" [10:13] or possibly "Changed-By" [10:14] cjwatson, ah-ha - found them [10:14] if you signed the upload that will take precedence and it should be "Requester" [10:14] (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] cjwatson, I see a requester tagged email for the upload, and then a changed-by for the proposed->release pockey migration [10:14] Right [10:14] Because you didn't request that copy [10:15] Also, X-Launchpad-Notification-Type: package-upload [10:15] yes - thanks for the clarification [10:16] It should be more filterable now, but it's true that some configurations may require tweaking [10:24] arges, please finish transitions if you start them (libecap). now hopefully done [10:25] arges, argh, no. squid3 needs an update [10:26] I was supposed to do a squid3 merge to fix that, but didn't manage it before feature freeze [10:26] I'd forgotten about the libecap complication [10:28] jamespage: documented on https://help.launchpad.net/LaunchpadMessageRationale now [10:45] Laney, please ping me if you intend to do any virtualbox related work [10:46] I'm working on an MRE [10:46] https://titanpad.com/IVSgUZauQV [10:46] LocutusOfBorg1: should I sponsor the lts thingy or not? [10:46] I don't know [10:47] should we really split the package an maintain two? [10:47] also I prefer to start from a virtualbox-lts-wily instead [10:48] but I guess all the effort is waiting for an MRE and debian bug 794466 [10:48] Debian bug 794466 in src:virtualbox "Virtualbox might not be suitable for Stretch" [Critical,Open] http://bugs.debian.org/794466 [10:48] I don't know much about the LTS stack [10:48] does every rdep of the renamed stuff need to be renamed too? [10:49] Anyway, happy to wait if you want [10:52] slangasek: bug #1429327 is in the queue but it looks like you're handling it, right? [10:52] bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327 [10:52] (unsubscribed sponsors, feel free to re-add) [10:59] Laney, I guess so, but we can't maintain an lts-* virtualbox package at each release... === gammax90 is now known as gammax [11:00] Laney, regarding https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048 -- the ppa contains proper versioned source of the succeeded rebuilds [11:00] ricotz: thanks! [11:01] I would appreciate a feedback from who uploaded the lts breaking-rdeps xserver-xorg-core [11:02] Launchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New] [11:03] LocutusOfBorg1: Maybe a thread on -devel is in order [11:10] diwic, pulseaudio has an unconditional b-d on trust-store [11:10] LocutusOfBorg1: what broke? [11:11] doko, and trust-store is not in main...? [11:12] doko, oh, it is not :-/ [11:12] tjaalton, bug 1424769 [11:12] bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Medium,Triaged] https://launchpad.net/bugs/1424769 [11:12] doko, thanks. [11:13] LocutusOfBorg1: ah, so need renamed backports for lts-* [11:14] I have to upload a virtualbox-lts-{utopic,vivid,wily} and so on? [11:14] utopic isn't supported anymore [11:14] but yes [11:14] tjaalton: could we do that more automatically? [11:14] and maintain all of them? [11:15] LocutusOfBorg1: it's no different from stock $release [11:15] or at least find out what gets broken as a start [11:15] well this was all done before me [11:15] and specially people should be aware of a different vbox package [11:15] dunno why virtualbox didn't get the love [11:16] well what does happen when an user has mesa-lts-utopic and switch to mesa-lts-vivid? [11:16] is that automatic? virtualbox gets removed, right? [11:16] he has to know about virtualbox-lts-wily [11:16] hoping somebody uploaded it together with the rest of the lts stack [11:17] one does not "switch to mesa-foo" [11:17] that's never supported [11:17] well the user notices a new mesa is available [11:17] how exactly? [11:17] apt? [11:17] synaptic? [11:17] it's new packages [11:17] ooh, a new package [11:18] yes [11:18] you would have to go looking for it [11:18] it's not shown in updates [11:18] but uninstallability is a real issue [11:18] somebody should upload the virtualbox new lts-wily package together with mesa-lts wily I guess [11:18] yes [11:19] sometime between nov-jan [11:19] and -vivid for 14.04.3 [11:20] how can we tell which packages need this treatment? [11:20] so why wasn't this an issue for precise lts backports? [11:21] search for packages that provide xorg-vide-abi-foo [11:21] -video [11:21] err [11:22] virtualbox-guest-x11 just Provides xorg-driver-video [11:22] hm no [11:22] the xserver provides the abi of course, drivers depend on it [11:23] got that all wrong [11:23] is it anything that depends on xorg-video-abi-XXX? [11:23] right [11:23] seems it is just virtualbox + xorg + drivers [11:25] tjaalton: is there some documentation/process for the lts backports that we an add this to? [11:26] no [11:26] just scripts for renaming stuff [11:29] can you take a note to add the r-deps check maybe? :) [11:31] 14:31 < mlankhorst> no, we never did any virtualbox backport [11:32] also, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says that newer point-release are not (recommended) for virtual machines [11:33] so dunno, i'd rather not support it tbh [11:36] I think that probably means as guest [11:36] it's not reasonable to expect people to consider if they might ever want to install virtualbox when originally installing the LTS [11:36] that's where you need the package, not on host [11:39] barry, restored zope.security changes, needed for schooltool [11:44] tjaalton: Oh right, that's where the broken package is - meh, this sucks as an experience though [11:45] https://ubuntu.com/download/desktop is all "get 14.04.3" [12:00] doko, tvoss is going to work on getting trust-store into main [12:00] doko, then we can redo the build [12:01] diwic, tvoss: this is fine too, but not the problem. trust-store isn't built on all archs [12:01] doko, but it is not a build dependency on all archs, is it? [12:02] * diwic checks [12:02] diwic, just let me know what you want me to do :) [12:03] doko, libtrust-store-dev is only listed as a build-dep for armhf, i386, and amd64 [12:03] doko, and I believe trust-store builds on all those three, right? [12:07] diwic, tvoss: my bad ... so yes, starting writing MIRs for trust-store and all its dependencies [12:10] cyphermox: are you handling bug #1432062? i.e. can I remove sponsors? [12:10] bug 1432062 in multipath-tools (Ubuntu) "multipath-tools-boot: support booting without user_friendly_names on devices with spaces in identifiers" [Medium,Confirmed] https://launchpad.net/bugs/1432062 [12:17] 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] LocutusOfBorg1: are you willing to test a lts-vivid build of vbox? [12:22] tjaalton, I'm uploading it right now on my ppa [12:24] erm, the debdiff should look something like http://sprunge.us/LUTL [12:25] tjaalton, yes sure, it is basically renaming files [12:25] but if you miss anything it's gonna fail, this was done with a script === MacSlow is now known as MacSlow|lunch [12:26] actually the packaging changes not too much, so I applied the debdiff for utopic and it applied almost cleanly [12:26] after a sed to vivid [12:26] let's see the upload how it goes [12:26] vbox build-depends on gcc-4.9? that won't work [12:27] heh, and libglu1-mesa-dev which isn't coinstallable with the backports [12:27] so no it's not going to work [12:28] doko: kodi needed FFe, also there was a sponsor bug to close, please check before syncing [12:30] tjaalton, yes, gcc-4.9 was forced to avoid use of gcc-5 in Debian [12:30] for glu1-mesa-dev let me test once it is built :) [12:31] does trusty have gcc-4.9? it didn't build here because of it [12:31] tjaalton, the problem was gcc-5 too new, so we forced gcc-4.9 [12:31] pitti: I think I found the fix for rsyslog's FTBS. [12:31] any compiler < 4.9 is fine [12:31] pitti: How should I push the fix ? debdiff or MP ? [12:32] LocutusOfBorg1: so a backport can't be reliably scripted [12:32] well not when gcc has a major release [12:32] caribou: I'd prefer a debdiff, much easier (on the original sponsoring bug is fine, or email, or pastebin -- whatever you prefer) [12:32] caribou: and nice work! [12:32] pitti: I'll push a debdiff on the merge bug [12:33] 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:33] gcc.gnu.org bug 65693 in rtl-optimization "[4.8/4.9 Regression] ICE in assign_by_spills, at lra-assigns.c:1419" [Normal,Resolved: fixed] [12:34] pitti: was rather nasty : tcpflood.c uses rand() + SomeValue and in some cases this calculation wraps to a negative value [12:34] when the result of rand() is close to RAND_MAX [12:34] and the result > 32 bits [12:35] pitti: I'm also pushing the fix upstream [12:35] pitti: so reproducing it is not systematic as it depends on the random value [12:40] ricotz: karlyriceditor kino have ricotz1 versions too still [12:47] Riddell: so doko and I just untangled (at least one aspect of) the akonadi uninstallability [12:47] Laney, repushed, seems launchpad lost them somehow [12:47] ricotz: thanks, copying the first lot now [12:47] 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] Riddell: if dropping knode was intentional, the kdepimlibs binary needs to drop its Depends: knode [12:48] pitti, wait a moment until sitter appears, or join #kubuntu-devel [12:48] Riddell: is that intentional? [12:48] I am here :P [12:48] sitter: hello [12:48] Laney, libde265 isn't listed in the transition page, I forgot some regex-name-tweaks [12:49] sitter: so either the knode binary needs to get back, or kdepim needs to drop its depends: to it [12:49] ricotz: I just copied everything built in the ppa [12:49] pitti: debdiff is now on LP: #1464201 [12:49] Launchpad bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.12.0-1 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1464201 [12:49] assuming it works [12:49] Laney, ok, expect the failed one of course ;) [12:49] yes [12:49] sitter: same for kaddressbook-mobile, AFAICS [12:49] pitti, already dropped in 15.08.0-0ubuntu2 [12:50] Laney, I might propose another transition for "libav-tools" [12:50] . o O { there once was a time when changelogs documented such major changes.. } [12:50] Laney, does this ffmpeg stuff interfer with kde? [12:50] 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] no we still have the old binaries [12:51] doko, kde got silently transitioned already [12:51] pitti, doko: ubuntu1 shouldhn't have a reference to either of those packages [12:51] ricotz, no [12:51] ok there we go, seems the copies happened [12:51] doko, yes [12:51] hm [12:52] * Laney goes to lunch [12:52] pitti: the kdepim*libs* package you say? [12:52] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:52] sitter, doko: oh, ok; well, then *something* else is missing :/ [12:52] ricotz, no or else pitti or sitter would talk about it [12:52] http://people.canonical.com/~ubuntu-archive/transitions/html/ffmpeg.html [12:52] look at the good ones [12:53] pitti: libakonadiprotocolinternals1 is missing [12:53] of course this only tracks dependencies, runtime deps are not considered like apps using "libav-tools" [12:53] due to reappear through the new akonadi1 source though which is building now [12:54] ricotz: will you look at the ftbfs? [12:54] 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] sitter: ah, so libakonadiprotocolinternals1 will come back? [12:54] yep [12:54] Laney, they are toolchain and qt related, so currently not [12:55] 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] Laney, will the transition page update itself? [12:55] yes [12:55] ok [12:56] 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] sitter, and kfilemetadata? [12:58] also seems built against ffmpeg https://launchpadlibrarian.net/213741522/buildlog_ubuntu-wily-amd64.kfilemetadata_4%3A4.14.2-0ubuntu2_BUILDING.txt.gz [12:59] sitter, right, just saying there are more ;) [12:59] ah yeah, I forgot about that bugger ^^ [12:59] sitter, looking at apps using "libav-tools" aka avconv is needed too [13:00] that list should be slightly longer [13:00] ricotz: what do we need to do to them? [13:00] exactly [13:01] caribou: uploaded, cheers! [13:01] pitti: thanks! [13:01] sitter, make them use the "ffmpeg" package and its ffmpeg binary [13:01] pitti: let's cross finger & hope it builds :-) [13:01] ricotz, sitter: not before we get the current migration done [13:02] I'll send a mail to the kubuntu list, lest we forget [13:04] doko: thanks [13:05] good morning! [13:05] Laney: fixed up bug 1432062. [13:05] bug 1432062 in multipath-tools (Ubuntu) "multipath-tools-boot: support booting without user_friendly_names on devices with spaces in identifiers" [Medium,Confirmed] https://launchpad.net/bugs/1432062 [13:14] caribou: oh noes [13:15] read value 23, but expected value 22 [13:15] caribou: I pretend I didn't see that and just retry [13:16] pitti: can be a race condition, his testbench is subjec to that [13:16] pitti: it builds fine on i386, want me to retry here ? [13:16] caribou: that was on amd64 this time; I guess/hope it'll build the second time [13:16] caribou: I guess the tests are still quite new and need to mature a bit [13:17] pitti: I'll keep an eye on this [13:17] pitti: indeed. The upstream maintainer does agree & I know that the debian maintainer is also closely working with him on that [13:18] pitti: I just sent the DM my fix [13:18] caribou: say hello to mbiebl_ from me :) [13:18] pitti: will do :) [13:28] pitti: \o/ it built [13:40] doko, does this looks fine to you http://pastebin.ubuntu.com/12253274/ === kickinz1|afk is now known as kickinz1 === MacSlow|lunch is now known as MacSlow [14:07] 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] 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] arges: Should I just ask whoever ends up doing my upload to pull from -proposed, apply my debdiff and then upload? [14:11] 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] arges: Nope, it's completely orthogonal. [14:11] The version that got released from -proposed last week causes the regression. [14:12] And we now have a new test case for changes to the Azure bits of the code. :p [14:13] Odd_Bloke: yea so make sure the new upload contains the fixes in -proposed as well. That should be sufficient [14:13] OK, cool. [14:13] arges: Thanks. :) [14:13] Odd_Bloke: no problem [14:14] 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] 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] Laney: <3 [14:20] 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] thanks [14:26] hey Logan! [14:26] thanks for all the syncs :P [14:26] cyphermox: thx [14:51] Laney: sorry, bug #1429327 - which queue? I'm not handling anything with respect to that at the moment [14:51] bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327 [14:51] 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] slangasek: the ~ubuntu-sponsors queue [14:52] pitti: Seems weird that's not a failure or, ideally, a new "skipped" state. [14:52] infinity: in between, it's from the dkms package's generalized dkms testing script [14:52] 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] infinity: we don't build it on ppc64el, so none of the binaries works [14:53] infinity: ah, funny; I just re-kicked that test too [14:53] (temp failure resolving ports.u.c.) [14:53] 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] pitti: Is there blocking serialisation on retries, or did we just start two jobs? :) [14:54] infinity: we started two [14:54] Go us. [14:54] infinity: sorry to wolfe for wasting a whopping 3 minutes of their time [14:54] pitti: Yeah, not a big deal for this no-op test. :) [14:54] Laney: ah, yes I don't think that belongs in the sponsors queue [14:54] pitti: But maybe some locking would be in order, somewhere down the todo after in-progress UI feedback of some sort. [14:54] infinity: so, the more interesting thing here would be to auto-retry on DNS resolution glitches [14:54] Or maybe before it. [14:55] dholbach, now the syncpackage should work [14:55] syncpackage -f -s mapreri -V 0.7.2+dfsg-2 flightcrew && syncpackage -f -s mapreri -V 0.8.7+dfsg-2 sigil [14:55] :) [14:55] pitti: Optimising for network issues (especially in our own DC) leaves a bad taste in my mouth. [14:55] infinity: right, if/once we expose the pending queues, this will be much simpler [14:55] 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] 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] LocutusOfBorg1, aren't the two packages from yesterday synced already? [14:56] infinity: yeah, hopefully less of an issue once ppc64el moves into scalingstack [14:56] LocutusOfBorg1, but I'm busy right now - just about to join a call [14:56] 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] infinity: cjwatson's LP report today sounded like this might actually happen soon [14:57] dholbach, no problem, I remembered they were in incoming [14:57] pitti: Though, the *other* mismatch bug (Translations-specific) should be fixed once IS rolls out my trivial mirror change. [14:57] right - yeah, I think they're synced and in wily now :) [14:58] pitti: So, you'll just be left with that tiny "I downloaded Release before the dists switch and Packages after" race window. [14:58] Which, I realise, is a very visible window at scale. :/ [14:59] infinity: yeah, it seems everyone (autopkgtest, launchpad buildd, etc.) uses that same "try again after sleep" approach (I got it from Colin) [15:00] 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] 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] pitti: So, you can optimise out that waste 15s, if you like. [15:01] s/waste/wasted/ [15:01] infinity: ah, good point [15:02] 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] pitti: Arguably, you should just use ftpmaster. [15:04] 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] infinity: the cloud instances already use ftpmaster.internal [15:05] just didn't do the magic for the LXC boxes yes [15:05] yet [15:05] (bug 1490899) [15:05] bug 1490899 in Auto Package Testing "armhf/ppc64el tests might use earlier binary packages than britney sees" [High,In progress] https://launchpad.net/bugs/1490899 [15:06] pitti: Ahh, kay, if scalingstack is using ftpmaster, than I'll just assume that's the way forward. [15:06] 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] infinity: pepo? [15:07] pitti: host archive.ubuntu.com > chroot/etc/hosts [15:07] pitti: pepo == ftpmaster [15:07] ah [15:08] 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] pitti: But also ew. ;) [15:14] arges, thanks for fixing my tgt version for trusty [15:14] mterry: no problem! glad that bug finally got fixed [15:26] Laney, could you copy the 3 remaining packages: fuse-emulator-utils, karlyriceditor, kino [15:28] ricotz: I don't see fuse-emulator-utils [15:28] but for the rest ok [15:29] Laney, ah sorry, regarding bino: http://pastebin.ubuntu.com/12253274/ [15:51] dholbach: actually sigil ain't synced yet (uploaded in debian only this morning) [15:52] mapreri, yep, sorry - I was commenting on flightcrew and gimp-help which LocutusOfBorg1 asked me to sync yesterday evening [15:53] dholbach: well, now if you sync sigil you should add -b 1491459 [15:53] :) [15:53] no, I won't get around to it today [15:53] I'm still in a call and need to run afterwards [15:53] i don't really care about the -s [15:54] fine for me, whenever before wily release ;P [18:33] pitti, autopkgtest for kde4pimlibs in progress for some hours on armhf ... :-/ [19:04] slangasek, hi, could you take care of https://code.launchpad.net/~ricotz/ubuntu-transition-tracker/ffmpeg/+merge/269963 [19:52] barry, something already installs python3.5 [19:58] barry, this is plainbox, but when built locally it doesn't have this dep [20:01] doko: I assume it's the usual "install_scripts sets shebang incorrectly" misfeature. [20:01] doko: So, when the last install_scripts is the 3.5 one, you get python3.5 as the shebang. [20:01] otoh, we want python3.5 in the end ;p [20:02] doko: dh_python3 --shebang=/usr/bin/python3 worked around it last time I saw this. [20:02] doko: We don't ever want versioned shebangs, IMO. [20:02] (unless something actually only works with that version) [20:04] infinity, something else, can somebody other than pitti manage autopkg tests? [20:04] doko: Define "manage". [20:06] infinity, http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ (triggered by akonadi1) Test in progress for 5h [20:06] 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] 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] (It's on the TODO to make the in-progress stuff less opaque too) [20:07] infinity, it will fail, and I can do that too [20:08] infinity, can you set it to ignore? or jibel ? [20:08] I can ignore it for promotion. [20:08] would be nice to see what britney thinks then ... [20:09] ohh mehh, rtg limiting the list of architectures for packages ... [20:10] doko: Not really. [20:11] ? [20:11] doko: All the other binaries in that package were already arch-restricted. [20:11] doko: For some reason, the -dev was arch:any, it was just a bug. [20:12] Given the library was arch-restricted, having the -dev not match made no sense. :P [20:12] no [20:12] Package: mstflint [20:12] Architecture: linux-any [20:12] Oh, I thought you were talking about numactl [20:13] Bah, and he *just* left IRC. [20:14] And that's even reverting a change I made. Excellent. :P [20:14] sent email [20:18]