pittiGood morning02:52
pittiinfinity: 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
ubottubug 1491145 in dpkg (Ubuntu) "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/149114503:19
ubottuDebian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open] http://bugs.debian.org/77955903:19
=== nudtrobert1 is now known as nudtrobert
infinitypitti: 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
infinitypitti: 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
pittiinfinity: I won't have much time for it either this week, just asking06:24
infinitypitti: But yeah, it's on my TODO, just slightly forgotten, ish.06:24
pittibut without having looked into it yet it doesn't sound particularly difficult?06:24
pitti(I'll probably think otherwise after I've seen the Perl :) )06:25
infinitypitti: Most of the dep parsing stuff is nicely broken out into reusable methods, ish.06:25
infinitypitti: So, it really should just be "take control field X, apply dep parsing method Y, vomit into new control field Z".06:25
infinitypitti: 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:26
infinitypitti: Anyhow, I'm going to sleep.  Remind me again if you don't get to it, and I will.06:27
dholbachgood morning07:06
=== zbenjamin_ is now known as zbenjamin
caribouinfinity: 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 schroot07:49
pitticaribou: ah, the buildds run a trusty or even precise kernels, so that might be it07:50
cariboupitti: thanks to cjwatson's suggestion of diffing the build logs07:51
cariboupitti: well now I can reproduce so I should be able to fix it07:51
Laney@pilot in08:28
=== 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
dokojamespage, libcommons-cli-java ping09:19
zygadoko: I'm working on the patch all morning, it should be ready soon (plainbox)09:37
=== greyback__ is now known as greyback
=== sitter_ is now known as sitter
cjwatsonpitti: almost entirely trusty, with the exception of the non-virtual armhf builders09:44
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 tasks09:49
jamespagedoko, hullo09:55
dokojamespage, could you have a look at libcommons-cli-java ping to de-mavenfy the package?09:57
jamespagedoko, I need to clear through the openstack milestone 2 blockages first, and then I can take a peek09:57
jamespagedoko, is it a new upstream version?09:57
jamespagefor other packages I've just reverted the debian folder to a previous ant based one09:57
dokojamespage, was walking through the packages with ebourg which ones could be synced09:58
jamespageanyone know if there is a problem with upload queue processing?10:06
cjwatsonjamespage: details?10:06
jamespagehmm - maybe its just email notifications10:06
cjwatsonstill details?10:06
jamespagecjwatson, checking10:06
cjwatsonI made some changes to upload email notifications recently so I would rather like to know if there's a problem with them10:07
jamespagecjwatson, did that involve adding some headers per chance?10:07
cjwatson"some changes" -> completely refactored10:07
cjwatsonjamespage: yes, they now have X-Launchpad-Message-Rationale and X-Launchpad-Notification-Type10:07
jamespagecjwatson, specifically I've done a few uploads this morning - python-mock, python-django-compressor, and a load of PPA uploads10:08
jamespagecjwatson, I've not seen email notifications for them since...10:08
jamespage1930 ish yesterday10:09
jamespagethat's 'Accepted' notifcations10:09
cjwatsonjamespage: the logs claim to have mailed you about python-mock this morning10:09
cjwatsonjamespage: http://paste.ubuntu.com/12252145/10:09
cjwatsonjamespage: could you check that it hasn't been filtered off somewhere?10:10
jamespagecjwatson, that's my suspicion10:11
jamespagecjwatson, looking atm10:11
jamespagecjwatson, do you happen to know the X-Launchpad-Message-Rationale they should have?10:13
cjwatsonjamespage: Probably "Requester"10:13
cjwatsonor possibly "Changed-By"10:13
jamespagecjwatson, ah-ha - found them10:14
cjwatsonif 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
jamespagecjwatson, I see a requester tagged email for the upload, and then a changed-by for the proposed->release pockey migration10:14
cjwatsonBecause you didn't request that copy10:14
cjwatsonAlso, X-Launchpad-Notification-Type: package-upload10:15
jamespageyes - thanks for the clarification10:15
cjwatsonIt should be more filterable now, but it's true that some configurations may require tweaking10:16
dokoarges, please finish transitions if you start them (libecap). now hopefully done10:24
dokoarges, argh, no. squid3 needs an update10:25
rbasakI was supposed to do a squid3 merge to fix that, but didn't manage it before feature freeze10:26
rbasakI'd forgotten about the libecap complication10:26
cjwatsonjamespage: documented on https://help.launchpad.net/LaunchpadMessageRationale now10:28
LocutusOfBorg1Laney, please ping me if you intend to do any virtualbox related work10:45
LocutusOfBorg1I'm working on an MRE10:46
LaneyLocutusOfBorg1: should I sponsor the lts thingy or not?10:46
LocutusOfBorg1I don't know10:46
LocutusOfBorg1should we really split the package an maintain two?10:47
LocutusOfBorg1also I prefer to start from a virtualbox-lts-wily instead10:47
LocutusOfBorg1but I guess all the effort is waiting for an MRE and debian bug 79446610:48
ubottuDebian bug 794466 in src:virtualbox "Virtualbox might not be suitable for Stretch" [Critical,Open] http://bugs.debian.org/79446610:48
LaneyI don't know much about the LTS stack10:48
Laneydoes every rdep of the renamed stuff need to be renamed too?10:48
LaneyAnyway, happy to wait if you want10:49
Laneyslangasek: bug #1429327 is in the queue but it looks like you're handling it, right?10:52
ubottubug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/142932710:52
Laney(unsubscribed sponsors, feel free to re-add)10:52
LocutusOfBorg1Laney, I guess so, but we can't maintain an lts-* virtualbox package at each release...10:59
=== gammax90 is now known as gammax
ricotzLaney, regarding https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048 -- the ppa contains proper versioned source of the succeeded rebuilds11:00
Laneyricotz: thanks!11:00
LocutusOfBorg1I would appreciate a feedback from who uploaded the lts breaking-rdeps xserver-xorg-core11:01
ubottuLaunchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New]11:02
LaneyLocutusOfBorg1: Maybe a thread on -devel is in order11:03
dokodiwic, pulseaudio has an unconditional b-d on trust-store11:10
tjaaltonLocutusOfBorg1: what broke?11:10
diwicdoko, and trust-store is not in main...?11:11
diwicdoko, oh, it is not :-/11:12
LocutusOfBorg1tjaalton, bug 142476911:12
ubottubug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Medium,Triaged] https://launchpad.net/bugs/142476911:12
diwicdoko, thanks.11:12
tjaaltonLocutusOfBorg1: ah, so need renamed backports for lts-*11:13
LocutusOfBorg1I have to upload a virtualbox-lts-{utopic,vivid,wily} and so on?11:14
tjaaltonutopic isn't supported anymore11:14
tjaaltonbut yes11:14
Laneytjaalton: could we do that more automatically?11:14
LocutusOfBorg1and maintain all of them?11:14
tjaaltonLocutusOfBorg1: it's no different from stock $release11:15
Laneyor at least find out what gets broken as a start11:15
tjaaltonwell this was all done before me11:15
LocutusOfBorg1and specially people should be aware of a different vbox package11:15
tjaaltondunno why virtualbox didn't get the love11:15
LocutusOfBorg1well what does happen when an user has mesa-lts-utopic and switch to mesa-lts-vivid?11:16
LocutusOfBorg1is that automatic? virtualbox gets removed, right?11:16
LocutusOfBorg1he has to know about virtualbox-lts-wily11:16
LocutusOfBorg1hoping somebody uploaded it together with the rest of the lts stack11:16
tjaaltonone does not "switch to mesa-foo"11:17
tjaaltonthat's never supported11:17
LocutusOfBorg1well the user notices a new mesa is available11:17
tjaaltonhow exactly?11:17
Laneyit's new packages11:17
tjaaltonooh, a new package11:17
Laneyyou would have to go looking for it11:18
tjaaltonit's not shown in updates11:18
Laneybut uninstallability is a real issue11:18
LocutusOfBorg1somebody should upload the virtualbox new lts-wily package together with mesa-lts wily I guess11:18
tjaaltonsometime between nov-jan11:19
Laneyand -vivid for 14.04.311:19
Laneyhow can we tell which packages need this treatment?11:20
tjaaltonso why wasn't this an issue for precise lts backports?11:20
tjaaltonsearch for packages that provide xorg-vide-abi-foo11:21
tjaaltonvirtualbox-guest-x11 just Provides xorg-driver-video11:22
tjaaltonhm no11:22
tjaaltonthe xserver provides the abi of course, drivers depend on it11:22
tjaaltongot that all wrong11:23
Laneyis it anything that depends on xorg-video-abi-XXX?11:23
Laneyseems it is just virtualbox + xorg + drivers11:23
Laneytjaalton: is there some documentation/process for the lts backports that we an add this to?11:25
tjaaltonjust scripts for renaming stuff11:26
Laneycan you take a note to add the r-deps check maybe? :)11:29
tjaalton14:31 < mlankhorst> no, we never did any virtualbox backport11:31
tjaaltonalso, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says that newer point-release are not (recommended) for virtual machines11:32
tjaaltonso dunno, i'd rather not support it tbh11:33
LaneyI think that probably means as guest11:36
Laneyit's not reasonable to expect people to consider if they might ever want to install virtualbox when originally installing the LTS11:36
tjaaltonthat's where you need the package, not on host11:36
dokobarry, restored zope.security changes, needed for schooltool11:39
Laneytjaalton: Oh right, that's where the broken package is - meh, this sucks as an experience though11:44
Laneyhttps://ubuntu.com/download/desktop is all "get 14.04.3"11:45
diwicdoko, tvoss is going to work on getting trust-store into main12:00
diwicdoko, then we can redo the build12:00
dokodiwic, tvoss: this is fine too, but not the problem. trust-store isn't built on all archs12:01
diwicdoko, but it is not a build dependency on all archs, is it?12:01
* diwic checks12:02
tvossdiwic, just let me know what you want me to do :)12:02
diwicdoko, libtrust-store-dev is only listed as a build-dep for armhf, i386, and amd6412:03
diwicdoko, and I believe trust-store builds on all those three, right?12:03
dokodiwic, tvoss: my bad ... so yes, starting writing MIRs for trust-store and all its dependencies12:07
Laneycyphermox: are you handling bug #1432062? i.e. can I remove sponsors?12:10
ubottubug 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/143206212:10
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 them12:17
tjaaltonLocutusOfBorg1: are you willing to test a lts-vivid build of vbox?12:17
LocutusOfBorg1tjaalton, I'm uploading it right now on my ppa12:22
tjaaltonerm, the debdiff should look something like http://sprunge.us/LUTL12:24
LocutusOfBorg1tjaalton, yes sure, it is basically renaming files12:25
tjaaltonbut if you miss anything it's gonna fail, this was done with a script12:25
=== MacSlow is now known as MacSlow|lunch
LocutusOfBorg1actually the packaging changes not too much, so I applied the debdiff for utopic and it applied almost cleanly12:26
LocutusOfBorg1after a sed to vivid12:26
LocutusOfBorg1let's see the upload how it goes12:26
tjaaltonvbox build-depends on gcc-4.9? that won't work12:26
tjaaltonheh, and libglu1-mesa-dev which isn't coinstallable with the backports12:27
tjaaltonso no it's not going to work12:27
Laneydoko: kodi needed FFe, also there was a sponsor bug to close, please check before syncing12:28
LocutusOfBorg1tjaalton, yes, gcc-4.9 was forced to avoid use of gcc-5 in Debian12:30
LocutusOfBorg1for glu1-mesa-dev let me test once it is built :)12:30
tjaaltondoes trusty have gcc-4.9? it didn't build here because of it12:31
LocutusOfBorg1tjaalton, the problem was gcc-5 too new, so we forced gcc-4.912:31
cariboupitti: I think I found the fix for rsyslog's FTBS.12:31
LocutusOfBorg1any compiler < 4.9 is fine12:31
cariboupitti: How should I push the fix ? debdiff or MP ?12:31
tjaaltonLocutusOfBorg1: so a backport can't be reliably scripted12:32
LocutusOfBorg1well not when gcc has a major release12:32
pitticaribou: I'd prefer a debdiff, much easier (on the original sponsoring bug is fine, or email, or pastebin -- whatever you prefer)12:32
pitticaribou: and nice work!12:32
cariboupitti: I'll push a debdiff on the merge bug12:32
LocutusOfBorg1the 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=21824812:33
ubottugcc.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:33
cariboupitti: was rather nasty : tcpflood.c uses rand() + SomeValue and in some cases this calculation wraps to a negative value12:34
caribouwhen the result of rand() is close to RAND_MAX12:34
caribouand the result > 32 bits12:34
cariboupitti: I'm also pushing the fix upstream12:35
cariboupitti: so reproducing it is not systematic as it depends on the random value12:35
Laneyricotz: karlyriceditor kino have ricotz1 versions too still12:40
pittiRiddell: so doko and I just untangled (at least one aspect of) the akonadi uninstallability12:47
ricotzLaney, repushed, seems launchpad lost them somehow12:47
Laneyricotz: thanks, copying the first lot now12:47
pittiRiddell: 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 libraries12:47
pittiRiddell: if dropping knode was intentional, the kdepimlibs binary needs to drop its Depends: knode12:48
dokopitti, wait a moment until sitter appears, or join #kubuntu-devel12:48
pittiRiddell: is that intentional?12:48
sitterI am here :P12:48
pittisitter: hello12:48
ricotzLaney, libde265 isn't listed in the transition page, I forgot some regex-name-tweaks12:48
pittisitter: so either the knode binary needs to get back, or kdepim needs to drop its depends: to it12:49
Laneyricotz: I just copied everything built in the ppa12:49
cariboupitti: debdiff is now on LP: #146420112:49
ubottuLaunchpad bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.12.0-1 (main) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/146420112:49
Laneyassuming it works12:49
ricotzLaney, ok, expect the failed one of course ;)12:49
pittisitter: same for kaddressbook-mobile, AFAICS12:49
dokopitti, already dropped in 15.08.0-0ubuntu212:49
ricotzLaney, 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
dokoLaney, does this ffmpeg stuff interfer with kde?12:50
pittidoko: no, http://launchpadlibrarian.net/216056388/kdepim_4%3A15.08.0-0ubuntu1_4%3A15.08.0-0ubuntu2.diff.gz does no such thing12:50
Laneyno we still have the old binaries12:51
ricotzdoko, kde got silently transitioned already12:51
sitterpitti, doko: ubuntu1 shouldhn't have a reference to either of those packages12:51
dokoricotz, no12:51
Laneyok there we go, seems the copies happened12:51
ricotzdoko, yes12:51
* Laney goes to lunch12:52
sitterpitti: the kdepim*libs* package you say?12:52
Laney@pilot out12:52
=== 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:
pittisitter, doko: oh, ok; well, then *something* else is missing :/12:52
dokoricotz, no or else pitti or sitter would talk about it12:52
ricotzlook at the good ones12:52
sitterpitti: libakonadiprotocolinternals1 is missing12:53
ricotzof course this only tracks dependencies, runtime deps are not considered like apps using "libav-tools"12:53
sitterdue to reappear through the new akonadi1 source though which is building now12:53
Laneyricotz: will you look at the ftbfs?12:54
pittisitter: 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
pittisitter: ah, so libakonadiprotocolinternals1 will come back?12:54
ricotzLaney, they are toolchain and qt related, so currently not12:54
sitterdoko: 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/libvlc12:55
ricotzLaney, will the transition page update itself?12:55
sitterdoko, 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:56
ricotzsitter, and kfilemetadata?12:57
sitteralso seems built against ffmpeg https://launchpadlibrarian.net/213741522/buildlog_ubuntu-wily-amd64.kfilemetadata_4%3A4.14.2-0ubuntu2_BUILDING.txt.gz12:58
ricotzsitter, right, just saying there are more ;)12:59
sitterah yeah, I forgot about that bugger ^^12:59
ricotzsitter, looking at apps using "libav-tools" aka avconv is needed too12:59
sitterthat list should be slightly longer13:00
sitterricotz: what do we need to do to them?13:00
pitticaribou: uploaded, cheers!13:01
cariboupitti: thanks!13:01
ricotzsitter, make them use the "ffmpeg" package and its ffmpeg binary13:01
cariboupitti: let's cross finger & hope it builds :-)13:01
dokoricotz, sitter: not before we get the current migration done13:01
sitterI'll send a mail to the kubuntu list, lest we forget13:02
barrydoko: thanks13:04
cyphermoxgood morning!13:05
cyphermoxLaney: fixed up bug 1432062.13:05
ubottubug 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/143206213:05
pitticaribou: oh noes13:14
pittiread value 23, but expected value 2213:15
pitticaribou: I pretend I didn't see that and just retry13:15
cariboupitti: can be a race condition, his testbench is subjec to that13:16
cariboupitti: it builds fine on i386, want me to retry here ?13:16
pitticaribou: that was on amd64 this time; I guess/hope it'll build the second time13:16
pitticaribou: I guess the tests are still quite new and need to mature a bit13:16
cariboupitti: I'll keep an eye on this13:17
cariboupitti: indeed. The upstream maintainer does agree & I know that the debian maintainer is also closely working with him on that13:17
cariboupitti: I just sent the DM my fix13:18
pitticaribou: say hello to mbiebl_ from me :)13:18
cariboupitti: will do :)13:18
cariboupitti: \o/ it built13:28
ricotzdoko, does this looks fine to you http://pastebin.ubuntu.com/12253274/13:40
=== kickinz1|afk is now known as kickinz1
=== MacSlow|lunch is now known as MacSlow
Odd_Blokearges: 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:07
argesOdd_Bloke: well I assume your fixes are a superset of the previous changes, then we can upload over the current -proposed version14:09
Odd_Blokearges: Should I just ask whoever ends up doing my upload to pull from -proposed, apply my debdiff and then upload?14:10
argesOdd_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_Blokearges: Nope, it's completely orthogonal.14:11
Odd_BlokeThe version that got released from -proposed last week causes the regression.14:11
Odd_BlokeAnd we now have a new test case for changes to the Azure bits of the code. :p14:12
argesOdd_Bloke: yea so make sure the new upload contains the fixes in -proposed as well. That should be sufficient14:13
Odd_BlokeOK, cool.14:13
Odd_Blokearges: Thanks. :)14:13
argesOdd_Bloke: no problem14:13
revolveHello 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_end14:14
revolveI've also built it and its dependencies from src, experienced the same thing, and replaced them with the version from the repos again14:15
LoganLaney: <314:17
rbasakrevolve: 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
Laneyhey Logan!14:26
Loganthanks for all the syncs :P14:26
Laneycyphermox: thx14:26
slangasekLaney: sorry, bug #1429327 - which queue?  I'm not handling anything with respect to that at the moment14:51
ubottubug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/142932714:51
infinitypitti: 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:51
Laneyslangasek: the ~ubuntu-sponsors queue14:52
infinitypitti: Seems weird that's not a failure or, ideally, a new "skipped" state.14:52
pittiinfinity: in between, it's from the dkms package's generalized dkms testing script14:52
infinitypitti: (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
pittiinfinity: we don't build it on ppc64el, so none of the binaries  works14:52
pittiinfinity: ah, funny; I just re-kicked that test too14:53
pitti(temp failure resolving ports.u.c.)14:53
infinitypitti: 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
infinitypitti: Is there blocking serialisation on retries, or did we just start two jobs? :)14:53
pittiinfinity: we started two14:54
infinityGo us.14:54
pittiinfinity: sorry to wolfe for wasting a whopping 3 minutes of their time14:54
infinitypitti: Yeah, not a big deal for this no-op test. :)14:54
slangasekLaney: ah, yes I don't think that belongs in the sponsors queue14:54
infinitypitti: But maybe some locking would be in order, somewhere down the todo after in-progress UI feedback of some sort.14:54
pittiinfinity: so, the more interesting thing here would be to auto-retry on DNS resolution glitches14:54
infinityOr maybe before it.14:54
LocutusOfBorg1dholbach, now the syncpackage should work14:55
LocutusOfBorg1syncpackage -f -s mapreri -V 0.7.2+dfsg-2 flightcrew && syncpackage -f -s mapreri -V 0.8.7+dfsg-2 sigil14:55
infinitypitti: Optimising for network issues (especially in our own DC) leaves a bad taste in my mouth.14:55
pittiinfinity: right, if/once we expose the pending queues, this will be much simpler14:55
infinitypitti: 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:55
pittiinfinity: 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 install14:56
dholbachLocutusOfBorg1, aren't the two packages from yesterday synced already?14:56
pittiinfinity: yeah, hopefully less of an issue once ppc64el moves into scalingstack14:56
dholbachLocutusOfBorg1, but I'm busy right now - just about to join a call14:56
infinitypitti: Yeah.  apt 1.1 will save us on the mismatch thing.  Not that we'll be backporting that to << 16.04, though.14:56
pittiinfinity: cjwatson's LP report today sounded like this might actually happen soon14:56
LocutusOfBorg1dholbach, no problem, I remembered they were in incoming14:57
infinitypitti: Though, the *other* mismatch bug (Translations-specific) should be fixed once IS rolls out my trivial mirror change.14:57
dholbachright - yeah, I think they're synced and in wily now :)14:57
infinitypitti: So, you'll just be left with that tiny "I downloaded Release before the dists switch and Packages after" race window.14:58
infinityWhich, I realise, is a very visible window at scale. :/14:58
pittiinfinity: yeah, it seems everyone (autopkgtest, launchpad buildd, etc.) uses that same "try again after sleep" approach (I got it from Colin)14:59
infinitypitti: 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
infinitypitti: 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:00
infinitypitti: So, you can optimise out that waste 15s, if you like.15:01
pittiinfinity: ah, good point15:01
infinitypitti: 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. :P15:02
infinitypitti: Arguably, you should just use ftpmaster.15:03
pittiinfinity: yeah, I'm going to for armhf; for ppc64el that needs to go via proxy, but should still be better than the mirror hopefully15:04
pittiinfinity: the cloud instances already use ftpmaster.internal15:05
pittijust didn't do the magic for the LXC boxes yes15:05
pitti(bug 1490899)15:05
ubottubug 1490899 in Auto Package Testing "armhf/ppc64el tests might use earlier binary packages than britney sees" [High,In progress] https://launchpad.net/bugs/149089915:05
infinitypitti: Ahh, kay, if scalingstack is using ftpmaster, than I'll just assume that's the way forward.15:06
infinitypitti: The other (disgusting) option I had, if there were concerns of CPU/bandwidth pressure on pepo, would be to break your resolver. ;)15:06
pittiinfinity: pepo?15:07
infinitypitti: host archive.ubuntu.com > chroot/etc/hosts15:07
infinitypitti: pepo == ftpmaster15:07
infinitypitti: 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
infinitypitti: But also ew. ;)15:08
mterryarges, thanks for fixing my tgt version for trusty15:14
argesmterry: no problem! glad that bug finally got fixed15:14
ricotzLaney, could you copy the 3 remaining packages: fuse-emulator-utils, karlyriceditor, kino15:26
Laneyricotz: I don't see fuse-emulator-utils15:28
Laneybut for the rest ok15:28
ricotzLaney, ah sorry, regarding bino: http://pastebin.ubuntu.com/12253274/15:29
mapreridholbach: actually sigil ain't synced yet (uploaded in debian only this morning)15:51
dholbachmapreri, yep, sorry - I was commenting on flightcrew and gimp-help which LocutusOfBorg1 asked me to sync yesterday evening15:52
mapreridholbach: well, now if you sync sigil you should add -b 149145915:53
dholbachno, I won't get around to it today15:53
dholbachI'm still in a call and need to run afterwards15:53
maprerii don't really care about the -s15:53
maprerifine for me, whenever before wily release ;P15:54
dokopitti, autopkgtest for kde4pimlibs in progress for some hours on armhf ... :-/18:33
ricotzslangasek, hi, could you take care of https://code.launchpad.net/~ricotz/ubuntu-transition-tracker/ffmpeg/+merge/26996319:04
dokobarry, something already installs python3.519:52
dokobarry, this is plainbox, but when built locally it doesn't have this dep19:58
infinitydoko: I assume it's the usual "install_scripts sets shebang incorrectly" misfeature.20:01
infinitydoko: So, when the last install_scripts is the 3.5 one, you get python3.5 as the shebang.20:01
dokootoh, we want python3.5 in the end ;p20:01
infinitydoko: dh_python3 --shebang=/usr/bin/python3 worked around it last time I saw this.20:02
infinitydoko: We don't ever want versioned shebangs, IMO.20:02
infinity(unless something actually only works with that version)20:02
dokoinfinity, something else, can somebody other than pitti manage autopkg tests?20:04
infinitydoko: Define "manage".20:04
dokoinfinity, http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ (triggered by akonadi1) Test in progress for 5h20:06
infinitydoko: 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
infinitydoko: Oh, stalled tests, I can't do much about, but I can retry it.  Maybe it's not stalled, but lost. :P20:06
infinity(It's on the TODO to make the in-progress stuff less opaque too)20:07
dokoinfinity, it will fail, and I can do that too20:07
dokoinfinity, can you set it to ignore? or jibel ?20:08
infinityI can ignore it for promotion.20:08
dokowould be nice to see what britney thinks then ...20:08
dokoohh mehh, rtg limiting the list of architectures for packages ...20:09
infinitydoko: Not really.20:10
infinitydoko: All the other binaries in that package were already arch-restricted.20:11
infinitydoko: For some reason, the -dev was arch:any, it was just a bug.20:11
infinityGiven the library was arch-restricted, having the -dev not match made no sense. :P20:12
dokoPackage: mstflint20:12
dokoArchitecture: linux-any20:12
infinityOh, I thought you were talking about numactl20:12
infinityBah, and he *just* left IRC.20:13
infinityAnd that's even reverting a change I made.  Excellent. :P20:14
dokosent email20:14
dokolooks like the hint was good enough, the whole mess seems to migrate20:18
=== danwest is now known as danwest-afk
dokojamespage, 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:13
barrylifeless: ping22:24
slangasekricotz: done, with modifications22:28
lifelessbarry: pong22:35
barrylifeless: 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.522:36
lifelessbarry: I haven't specifically tested22:36
lifelessbarry: but if its not it should get fixed :)22:36
barrylifeless: ok! :)  i'm about to do a test build with 0.7...22:37
lifelesshmm, I need to move it over to git too22:37
lifelesslong tail of projects to migrate22:37
barrylifeless: probably so22:37
barryi hear ya there :)22:37
barrylifeless: 6 test failures in 3.5.  i'll file a bug22:38
lifelessbarry: all test-only issues22:39
lifelessbarry: qualname stuff22:39
barrylifeless: hard to say from the output here22:40
lifelessbarry: I just reproduced and checked22:40
lifeless- <testcase classname="junitxml.tests.test_junitxml.Succeeds" name="test_me" time="0.000">22:40
barrylifeless: ah22:40
lifeless+ <testcase classname="junitxml.tests.test_junitxml.TestJUnitXmlResult.test_unexpected_success_test.&lt;locals>.22:40
lifelessthats an inner class showing pu22:40
barryack.  should i file a bug?  i'd like to be able to track 3.5 compat since this is a seeded package22:41
lifelessI won't get to it today22:41
barrylifeless: no worries.  i am eod.22:41
barrylifeless: LP: #149163522:42
ubottuLaunchpad bug 1491635 in pyjunitxml "Test failures (and FTBFS) in Wily with Python 3.5" [Undecided,New] https://launchpad.net/bugs/149163522:42
barrylifeless: thanks.  ttyl.22:43
lifelessbarry: ciao :)22:43
dokoinfinity, user-mode-linux needs more changes than bumping the linux version22:45
slangasekuml still exists?23:02
dokoyeah, some nerd is till updating23:02
lifelessdoko: nerd?23:04
dokogo away23:06
lifelesswow, this isn't the Ubuntu-devel that I remember.23:07
dokowrong channel23:08
lifelessdoko: 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.23:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!