| pitti | Good morning | 02:52 |
|---|---|---|
| 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? | 03:19 |
| ubottu | bug 1491145 in dpkg (Ubuntu) "trigger tests for updated reverse test dependencies" [Medium,Triaged] https://launchpad.net/bugs/1491145 | 03:19 |
| ubottu | Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open] http://bugs.debian.org/779559 | 03:19 |
| === nudtrobert1 is now known as nudtrobert | ||
| 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:24 |
| 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:25 |
| 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:26 |
| infinity | pitti: Anyhow, I'm going to sleep. Remind me again if you don't get to it, and I will. | 06:27 |
| dholbach | good morning | 07:06 |
| === zbenjamin_ is now known as zbenjamin | ||
| 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:49 |
| pitti | caribou: ah, the buildds run a trusty or even precise kernels, so that might be it | 07:50 |
| 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 | 07:51 |
| Laney | @pilot in | 08: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 | ||
| doko | jamespage, libcommons-cli-java ping | 09:19 |
| zyga | doko: | 09:36 |
| zyga | doko: 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 | ||
| cjwatson | pitti: almost entirely trusty, with the exception of the non-virtual armhf builders | 09: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 tasks | 09:49 |
| jamespage | doko, hullo | 09:55 |
| 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:57 |
| doko | jamespage, was walking through the packages with ebourg which ones could be synced | 09:58 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| cjwatson | jamespage: could you check that it hasn't been filtered off somewhere? | 10:10 |
| jamespage | cjwatson, that's my suspicion | 10:11 |
| jamespage | cjwatson, looking atm | 10:11 |
| 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:13 |
| 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:14 |
| cjwatson | Also, X-Launchpad-Notification-Type: package-upload | 10:15 |
| jamespage | yes - thanks for the clarification | 10:15 |
| cjwatson | It should be more filterable now, but it's true that some configurations may require tweaking | 10:16 |
| doko | arges, please finish transitions if you start them (libecap). now hopefully done | 10:24 |
| doko | arges, argh, no. squid3 needs an update | 10:25 |
| 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:26 |
| cjwatson | jamespage: documented on https://help.launchpad.net/LaunchpadMessageRationale now | 10:28 |
| LocutusOfBorg1 | Laney, please ping me if you intend to do any virtualbox related work | 10:45 |
| 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:46 |
| 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:47 |
| LocutusOfBorg1 | but I guess all the effort is waiting for an MRE and debian bug 794466 | 10:48 |
| ubottu | Debian bug 794466 in src:virtualbox "Virtualbox might not be suitable for Stretch" [Critical,Open] http://bugs.debian.org/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:48 |
| Laney | Anyway, happy to wait if you want | 10:49 |
| Laney | slangasek: bug #1429327 is in the queue but it looks like you're handling it, right? | 10:52 |
| ubottu | bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327 | 10:52 |
| Laney | (unsubscribed sponsors, feel free to re-add) | 10:52 |
| LocutusOfBorg1 | Laney, I guess so, but we can't maintain an lts-* virtualbox package at each release... | 10:59 |
| === gammax90 is now known as gammax | ||
| 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:00 |
| LocutusOfBorg1 | I would appreciate a feedback from who uploaded the lts breaking-rdeps xserver-xorg-core | 11:01 |
| ubottu | Launchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New] | 11:02 |
| Laney | LocutusOfBorg1: Maybe a thread on -devel is in order | 11:03 |
| doko | diwic, pulseaudio has an unconditional b-d on trust-store | 11:10 |
| tjaalton | LocutusOfBorg1: what broke? | 11:10 |
| diwic | doko, and trust-store is not in main...? | 11:11 |
| diwic | doko, oh, it is not :-/ | 11:12 |
| LocutusOfBorg1 | tjaalton, bug 1424769 | 11:12 |
| ubottu | bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Medium,Triaged] https://launchpad.net/bugs/1424769 | 11:12 |
| diwic | doko, thanks. | 11:12 |
| tjaalton | LocutusOfBorg1: ah, so need renamed backports for lts-* | 11:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| tjaalton | sometime between nov-jan | 11:19 |
| Laney | and -vivid for 14.04.3 | 11:19 |
| 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:20 |
| tjaalton | search for packages that provide xorg-vide-abi-foo | 11:21 |
| tjaalton | -video | 11:21 |
| tjaalton | err | 11:21 |
| 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:22 |
| 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:23 |
| Laney | tjaalton: is there some documentation/process for the lts backports that we an add this to? | 11:25 |
| tjaalton | no | 11:26 |
| tjaalton | just scripts for renaming stuff | 11:26 |
| Laney | can you take a note to add the r-deps check maybe? :) | 11:29 |
| tjaalton | 14:31 < mlankhorst> no, we never did any virtualbox backport | 11:31 |
| tjaalton | also, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says that newer point-release are not (recommended) for virtual machines | 11:32 |
| tjaalton | so dunno, i'd rather not support it tbh | 11:33 |
| 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:36 |
| doko | barry, restored zope.security changes, needed for schooltool | 11:39 |
| Laney | tjaalton: Oh right, that's where the broken package is - meh, this sucks as an experience though | 11:44 |
| Laney | https://ubuntu.com/download/desktop is all "get 14.04.3" | 11:45 |
| diwic | doko, tvoss is going to work on getting trust-store into main | 12:00 |
| diwic | doko, then we can redo the build | 12:00 |
| 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:01 |
| * diwic checks | 12:02 | |
| tvoss | diwic, just let me know what you want me to do :) | 12:02 |
| 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:03 |
| doko | diwic, tvoss: my bad ... so yes, starting writing MIRs for trust-store and all its dependencies | 12:07 |
| Laney | cyphermox: are you handling bug #1432062? i.e. can I remove sponsors? | 12:10 |
| ubottu | 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: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 them | 12:17 |
| tjaalton | LocutusOfBorg1: are you willing to test a lts-vivid build of vbox? | 12:17 |
| LocutusOfBorg1 | tjaalton, I'm uploading it right now on my ppa | 12:22 |
| tjaalton | erm, the debdiff should look something like http://sprunge.us/LUTL | 12:24 |
| 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:25 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:26 |
| 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:27 |
| Laney | doko: kodi needed FFe, also there was a sponsor bug to close, please check before syncing | 12:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ubottu | 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:33 |
| 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:34 |
| 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:35 |
| Laney | ricotz: karlyriceditor kino have ricotz1 versions too still | 12:40 |
| 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:47 |
| 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:48 |
| 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 |
| ubottu | 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 |
| 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:49 |
| 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:50 |
| 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:51 |
| * Laney goes to lunch | 12:52 | |
| sitter | pitti: the kdepim*libs* package you say? | 12:52 |
| Laney | @pilot out | 12: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: | ||
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| ricotz | sitter, and kfilemetadata? | 12:57 |
| sitter | also seems built against ffmpeg https://launchpadlibrarian.net/213741522/buildlog_ubuntu-wily-amd64.kfilemetadata_4%3A4.14.2-0ubuntu2_BUILDING.txt.gz | 12:58 |
| 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 | 12:59 |
| sitter | that list should be slightly longer | 13:00 |
| sitter | ricotz: what do we need to do to them? | 13:00 |
| ricotz | exactly | 13:00 |
| 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:01 |
| sitter | I'll send a mail to the kubuntu list, lest we forget | 13:02 |
| barry | doko: thanks | 13:04 |
| cyphermox | good morning! | 13:05 |
| cyphermox | Laney: fixed up bug 1432062. | 13:05 |
| ubottu | 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:05 |
| pitti | caribou: oh noes | 13:14 |
| pitti | read value 23, but expected value 22 | 13:15 |
| pitti | caribou: I pretend I didn't see that and just retry | 13:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| caribou | pitti: \o/ it built | 13:28 |
| ricotz | doko, 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_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:07 |
| 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:09 |
| Odd_Bloke | arges: Should I just ask whoever ends up doing my upload to pull from -proposed, apply my debdiff and then upload? | 14:10 |
| 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:11 |
| Odd_Bloke | And we now have a new test case for changes to the Azure bits of the code. :p | 14:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| Logan | Laney: <3 | 14:17 |
| 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:20 |
| Laney | hey Logan! | 14:26 |
| Logan | thanks for all the syncs :P | 14:26 |
| Laney | cyphermox: thx | 14:26 |
| slangasek | Laney: sorry, bug #1429327 - which queue? I'm not handling anything with respect to that at the moment | 14:51 |
| ubottu | bug 1429327 in multipath-tools (Ubuntu) "Boot from a unique, stable, multipath-dependent symlink" [Medium,In progress] https://launchpad.net/bugs/1429327 | 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| pitti | infinity: yeah, it seems everyone (autopkgtest, launchpad buildd, etc.) uses that same "try again after sleep" approach (I got it from Colin) | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| infinity | pitti: Arguably, you should just use ftpmaster. | 15:03 |
| 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:04 |
| 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:05 |
| ubottu | 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| mterry | arges, thanks for fixing my tgt version for trusty | 15:14 |
| arges | mterry: no problem! glad that bug finally got fixed | 15:14 |
| ricotz | Laney, could you copy the 3 remaining packages: fuse-emulator-utils, karlyriceditor, kino | 15:26 |
| Laney | ricotz: I don't see fuse-emulator-utils | 15:28 |
| Laney | but for the rest ok | 15:28 |
| ricotz | Laney, ah sorry, regarding bino: http://pastebin.ubuntu.com/12253274/ | 15:29 |
| mapreri | dholbach: actually sigil ain't synced yet (uploaded in debian only this morning) | 15:51 |
| dholbach | mapreri, yep, sorry - I was commenting on flightcrew and gimp-help which LocutusOfBorg1 asked me to sync yesterday evening | 15:52 |
| 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:53 |
| mapreri | fine for me, whenever before wily release ;P | 15:54 |
| doko | pitti, autopkgtest for kde4pimlibs in progress for some hours on armhf ... :-/ | 18:33 |
| ricotz | slangasek, hi, could you take care of https://code.launchpad.net/~ricotz/ubuntu-transition-tracker/ffmpeg/+merge/269963 | 19:04 |
| doko | barry, something already installs python3.5 | 19:52 |
| doko | barry, this is plainbox, but when built locally it doesn't have this dep | 19:58 |
| 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:01 |
| 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:02 |
| doko | infinity, something else, can somebody other than pitti manage autopkg tests? | 20:04 |
| infinity | doko: Define "manage". | 20:04 |
| 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:06 |
| 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:07 |
| 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:08 |
| doko | ohh mehh, rtg limiting the list of architectures for packages ... | 20:09 |
| infinity | doko: Not really. | 20:10 |
| 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:11 |
| 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:12 |
| infinity | Bah, and he *just* left IRC. | 20:13 |
| infinity | And that's even reverting a change I made. Excellent. :P | 20:14 |
| doko | sent email | 20:14 |
| doko | looks like the hint was good enough, the whole mess seems to migrate | 20:18 |
| === danwest is now known as danwest-afk | ||
| 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:13 |
| barry | lifeless: ping | 22:24 |
| slangasek | ricotz: done, with modifications | 22:28 |
| lifeless | barry: pong | 22:35 |
| 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:36 |
| 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:37 |
| barry | lifeless: 6 test failures in 3.5. i'll file a bug | 22:38 |
| lifeless | barry: all test-only issues | 22:39 |
| lifeless | barry: qualname stuff | 22:39 |
| 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.<locals>. | 22:40 |
| barry | yep | 22:40 |
| lifeless | thats an inner class showing pu | 22:40 |
| lifeless | up | 22:40 |
| 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:41 |
| barry | lifeless: LP: #1491635 | 22:42 |
| ubottu | Launchpad bug 1491635 in pyjunitxml "Test failures (and FTBFS) in Wily with Python 3.5" [Undecided,New] https://launchpad.net/bugs/1491635 | 22:42 |
| barry | lifeless: thanks. ttyl. | 22:43 |
| lifeless | barry: ciao :) | 22:43 |
| doko | infinity, user-mode-linux needs more changes than bumping the linux version | 22:45 |
| slangasek | uml still exists? | 23:02 |
| doko | yeah, some nerd is till updating | 23:02 |
| lifeless | doko: nerd? | 23:04 |
| doko | go away | 23:06 |
| lifeless | wow, this isn't the Ubuntu-devel that I remember. | 23:07 |
| doko | wrong channel | 23:08 |
| 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. | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!