| rbasak | May I have an SRU team ack for a Saucy SRU for https://launchpad.net/bugs/1245113 please, before I do the work? | 09:00 |
|---|---|---|
| ubot2 | Launchpad bug 1245113 in libapache2-mod-auth-pgsql (Ubuntu Saucy) "libapache2-mod-auth-pgsql is missing in 13.10 amd64" [Undecided,New] | 09:00 |
| rbasak | It's a regression - the package was dropped from Debian due to falling behind on the Apache 2.4 transition, and has now been reinstated. Is an SRU for Saucy NEW acceptable here? | 09:00 |
| rbasak | I see low SRU regression risk because it would be a new package. | 09:01 |
| cjwatson | rbasak: seems reasonable to me | 09:57 |
| rbasak | cjwatson: thanks! | 10:03 |
| === peterm-ubuntu is now known as Peter_lunch | ||
| === doko_ is now known as doko | ||
| shadeslayer | re posting here since I was asked to | 15:50 |
| shadeslayer | are there plans to whitelist arm64 from britney so that packages can transition to -release even if arm64 isn't built? | 15:50 |
| cjwatson | shadeslayer: No, quite the contrary, we stopped whitelisting it. | 15:50 |
| shadeslayer | ah I see | 15:50 |
| * cjwatson looks through the pending failures | 15:51 | |
| shadeslayer | there seem to be odd segementation faults when unpacking things, or configuring things, at other times there are weird issues with the compiler | 15:52 |
| cjwatson | Yes, some of the buildds are unreliable hardware | 15:52 |
| shadeslayer | ( unpacking sgml for eg caused segmentation faults , which is just weird _ | 15:52 |
| cjwatson | But we have 2/4 reliable now | 15:52 |
| shadeslayer | oh | 15:52 |
| shadeslayer | okay, just annoying it is | 15:52 |
| cjwatson | beebe and birch are the reliable ones | 15:53 |
| cjwatson | But magic and twombly manage to build enough stuff that it's worth keeping them around until we have better | 15:54 |
| xnox | should we cron, auto-reptry if arm64 FTBFS, and last builder is "magic, twombly"? (since presumably any new hardware will be reliable) | 15:55 |
| cjwatson | No | 15:55 |
| xnox | ok. | 15:55 |
| cjwatson | Some of the failures are real | 15:55 |
| cjwatson | But feel free to manually retry ICEs labelled as "unreproducible", bizarre segfaults, etc. that occur on magic or twombly | 15:57 |
| cjwatson | If necessary we can force them onto beebe/birch, but usually it's worth just retrying a couple of times | 15:58 |
| shadeslayer | okay | 16:02 |
| infinity | shadeslayer: I've been going through "out of date on arm64" builds and retrying where appropriate, though I haven't done so in the last ~48h. | 16:15 |
| infinity | cjwatson: Looks like you've got this round covered? | 16:16 |
| infinity | (Though, a lot of the kde/c++ stuff you retried will almost certainly just fail again on poor magic/twombly) | 16:16 |
| cjwatson | I did a bunch, yeah. Figured we could down magic/twombly and try again as necessary | 16:20 |
| shadeslayer | infinity: cjwatson can we somehow just whitelist KDE SC packages from britney + on arm64? | 16:20 |
| shadeslayer | it's annoying that it's holding back the KDE SC packages, and we don't have the man power to take care of arm64 right now, we usually fix those towards the end of the cycle | 16:21 |
| cjwatson | shadeslayer: No. | 16:22 |
| shadeslayer | oh :( | 16:22 |
| cjwatson | shadeslayer: Not prepared to do that; it makes proposed-migration willing to break other things in poor trade-offs. | 16:22 |
| cjwatson | shadeslayer: Besides, KDE SC packages are held back for other reasons anyway | 16:23 |
| cjwatson | (e.g. you have armhf failures) | 16:23 |
| infinity | shadeslayer: There should be very few reasons why something would have built in the previous version but fail in the current version. arm64 isn't that particularly weird. | 16:23 |
| infinity | shadeslayer: Our flaky builder issue, we'll sort on our end. Real failures should probably actually be looked at. :P | 16:24 |
| cjwatson | Usually the KDE SC problems are that you upload everything in a giant lump and then you don't retry failures due to build-dep ordering ... | 16:24 |
| cjwatson | IME every KDE SC upload batch involves me going round retrying stuff | 16:24 |
| shadeslayer | build dep ordering? I thought LP took care of things if one of the Build Deps hasn't been built yet so it'll just wait | 16:25 |
| shadeslayer | then retry periodically | 16:25 |
| cjwatson | e.g. I just retried kalgebra/armhf kanagram/amd64 kanagram/armhf | 16:26 |
| cjwatson | It depends on how they aren't met | 16:26 |
| cjwatson | If they're directly unavailable, yes | 16:26 |
| cjwatson | If one of the build-deps is uninstallable due to something further down the stack, it fails and has to be retried manually | 16:26 |
| cjwatson | Which you folks apparently never do | 16:26 |
| infinity | Which is a bug on our end, to be sure, but it's been like this for 8 years, you'd think people would notice. | 16:27 |
| cjwatson | Right | 16:27 |
| cjwatson | I'm pretty sure I mentioned it at the last KDE SC release too :-( | 16:28 |
| shadeslayer | sigh, thanks for pointing that out, I'll keep a eye on those from now on | 16:28 |
| cjwatson | Right, putting magic and twombly on manual | 16:28 |
| cjwatson | Basically, anything in state "Failed to build" is never retried manually | 16:29 |
| cjwatson | Er | 16:29 |
| cjwatson | Is never retried automatically | 16:29 |
| shadeslayer | it's just that I tend to upload towards the end of the day, then let it work overnight, then next morning look at everything | 16:29 |
| cjwatson | "Dependency wait" may be retried automatically | 16:29 |
| shadeslayer | gotcha | 16:29 |
| cjwatson | shadeslayer: I've come along days afterward sometimes. | 16:29 |
| shadeslayer | sorry about that | 16:29 |
| xnox | shadeslayer: it would auto-resolve if the build-dependencies are more strict e.g. Build-depends: libkde-core (>= $the_just_uploaded_version_of_libkde) across the board, that way it would autoresolve itself overnight. | 16:30 |
| cjwatson | Anyway, you're stuck on libav/samba | 16:30 |
| xnox | =) | 16:30 |
| cjwatson | xnox: No, they generally are strict | 16:30 |
| shadeslayer | ^^ | 16:30 |
| shadeslayer | I think the issue is that the dev package itself might be un installable | 16:31 |
| cjwatson | xnox: But if the thing they build-depend on directly is *uninstallable* when the build happens, not just unavailable, nothing auto-resolves | 16:31 |
| xnox | right. | 16:32 |
| xnox | cjwatson: re:samba -> about 26 packages (libfoo0 & libfoo-dev) from samba4 packages are colapsed into (samba-dev & samba-libs). What's the best way to provide transitional packages? Upload src:samba4 with all of them converted into dummy transitional packages, or to add all of them to src:samba ? | 16:33 |
| xnox | (src:samba will need correct Replaces/Conflicts) | 16:33 |
| shadeslayer | Riddell: poke https://launchpad.net/ubuntu/+source/calligra/1:2.7.5-0ubuntu2 | 16:33 |
| cjwatson | do we need transitional packages at all? | 16:34 |
| cjwatson | src:samba4 is slated for removal AIUI | 16:34 |
| shadeslayer | ah drat, you uploaded it, so someone else must approve | 16:35 |
| xnox | cjwatson: right. we don't need them for libs, as everything transitioned to new build-deps / deps in -proposed. But we do need samba4 -> samba transitional package, no? | 16:36 |
| xnox | cjwatson: or is it something for people to manually resolve. | 16:37 |
| xnox | at the moment, samba4 is uninstallable, are you saying that simply src:samba4 needs to be removed from -release and that's it? | 16:37 |
| xnox | well, I blocked it with a bug tag. I should remove the tag I guess. | 16:38 |
| xnox | (maybe once libav9 transitions) | 16:38 |
| cjwatson | xnox: I don't know, I'm kind of buried in urgent grub2 bugs | 16:39 |
| xnox | ok, sorry. | 16:39 |
| cjwatson | so hopefully somebody can work it out :) | 16:39 |
| xnox | =))))))))))))))) i think, libav will transition once mythtv finishes building in trusty-proposed, and then samba4 can be dealt with separately. | 16:40 |
| Laney | oh, that's why output changed | 16:46 |
| xnox | Laney: yeah, see excuses. | 16:46 |
| Laney | indeed | 16:46 |
| xnox | Laney: i'm now slightly confused about samba4. i'll do upgrades in chroot from samba4 installed in trusty -> samba in trusty-proposed and check what happens. | 16:47 |
| Laney | xnox: you think we'll need something in addition to what Debian did? | 16:49 |
| xnox | i assert that what debian did was not enough, let me verify that. | 16:52 |
| shadeslayer | could someone poke at https://launchpadlibrarian.net/157748907/buildlog_ubuntu-trusty-amd64.mdbtools_0.7.1-1_FAILEDTOBUILD.txt.gz < I don't understand why it's failing because it builds in pbuilder and the sbuild I created with sbuild-launchpad-chroot | 16:52 |
| xnox | shadeslayer: it's trying to do internet access to www.oasis-open.org ?! | 16:53 |
| shadeslayer | oh, dafuq | 16:53 |
| xnox | shadeslayer: i think it's missing build-dependencies on local copies of those .dtd enteties. | 16:54 |
| shadeslayer | right | 16:54 |
| xnox | it is for sure packaged. | 16:54 |
| shadeslayer | xnox: so, it builds fine on Debian | 16:58 |
| xnox | Laney: so in debian, those that had samba installed get upgraded to samba 4.x series. Those that had samba4 installed on dist-upgrade from stable -> testing get samba4 removed and no samba 4.x installed. | 16:59 |
| xnox | granted debian only shipped a beta in wheezy release, but we actually had samba4 released in raring and up. | 17:00 |
| xnox | Laney: shouldn't samba4 auto-upgraded to samba package? | 17:00 |
| Laney | I suppose so | 17:01 |
| infinity | shadeslayer: Without looking at the build log, you're probably missing a build-dep on docbook-xml. | 17:06 |
| cjwatson | Debian's builders aren't consistently firewalled from the internet | 17:07 |
| infinity | shadeslayer: We don't allow outside internet access from our buildds. | 17:07 |
| cjwatson | Ours are | 17:07 |
| infinity | shadeslayer: Easiest way to test is to install build-deps in a chroot, then pull the plug on your internets and try the build. :P | 17:08 |
| infinity | (Or intentionally break resolv.conf, or similar) | 17:08 |
| shadeslayer | okay | 17:08 |
| shadeslayer | checking now | 17:08 |
| infinity | shadeslayer: But it's probably just docbook-xml you need. | 17:08 |
| infinity | We need an sbuild hook that breaks chroot intenet after installing build-deps. | 17:09 |
| infinity | That would be handy. | 17:09 |
| infinity | Still, not EXACTLY what the buildds see, but a close approximation for most people. | 17:10 |
| stgraber | infinity: yeah, I initially wanted to do something like that for sbuild-launchpad-chroot but there wasn't an easy way of getting what I wanted... I think the idea would be to have sbuild have a flag to use CLONE_NEWNET, then create a veth pair on a private subnet and do masquerading on the host side of the pair but only for the archive machines | 17:15 |
| infinity | stgraber: Also needs to be able to resolve itself and a few limited machines (like the archive), but nothing else. | 17:17 |
| infinity | stgraber: The draconian DNS resolution policy we have has caused some really curious build failures before. | 17:17 |
| shadeslayer | apparently also needs rarian-compat | 17:17 |
| infinity | stgraber: But just cutting off ALL network works for 99% of tests like this. | 17:17 |
| shadeslayer | oh hah | 17:27 |
| shadeslayer | debian bug #718465 | 17:28 |
| ubot2 | Debian bug 718465 in mdbtools "mdbtools: Don't build-depend on rarian-compat" [Normal,Fixed] http://bugs.debian.org/718465 | 17:28 |
| === gaughen is now known as gaughen_af | ||
| === gaughen_af is now known as gaughen_afk | ||
| xnox | libav migrated \o/ | 20:10 |
| mdeslaur | \o/ | 20:10 |
| Laney | woot | 20:46 |
| Laney | xnox: shouldn't you unblock samba? | 20:49 |
| xnox | Laney: yeah, will do in a sec. testing it here. it's not quite right, but i think it's good enough. also filed debian bug about it. | 20:50 |
| xnox | Laney: once powerpc build is published, it should also all migrate. | 20:52 |
| Laney | yes, hence asking about unblocking | 20:52 |
| Laney | to not miss a britney cycle | 20:52 |
| Laney | looks like src:samba4 still builds some actual packages | 20:53 |
| xnox | correct. | 21:08 |
| xnox | Laney: there is src:samba autopkgtest running. | 21:08 |
| xnox | Laney: and my CI/QA vpn DNS is wrong cause i'm failing to access d-jenkins =( | 21:09 |
| xnox | Laney: can you hint it past adt failure? since we know it does pass. and #8 was testing trusty/main instead of trusty-proposed. | 21:09 |
| Laney | 10.98.3.6 | 21:09 |
| === gaughen_afk is now known as gaughen | ||
| xnox | Laney: do you have jenkins-foo to re-trigger adt test? | 21:11 |
| Laney | anyone does AFAIK | 21:11 |
| Laney | will it pass? | 21:11 |
| xnox | yeah. | 21:11 |
| xnox | Laney: by jenkins-foo i mean "known where/how to click in jenkins UI" not necessary ACL =) | 21:12 |
| Laney | hmm | 21:12 |
| Laney | where's the Matrix Reloaded thing gone? | 21:12 |
| xnox | oh, lp SSO login =) | 21:12 |
| Laney | I've never logged into jenkins | 21:13 |
| Laney | is that now required? | 21:13 |
| xnox | no idea, but i cannot find a way to retrigger it either. | 21:15 |
| xnox | Laney: ah. http://10.98.3.6:8080/job/trusty-adt-samba/build Access Denied, missing the Build permission =( | 21:17 |
| Laney | hmm | 21:18 |
| Laney | why did it get the trusty-release one? | 21:19 |
| xnox | maybe because of my block-proposed bug, britney did version specific adt test of the release version, and jenkins run it. | 21:20 |
| xnox | maybe it will request proposed version next time around, and it rerun it =/ | 21:21 |
| xnox | wait and see i guess. | 21:21 |
| Laney | might just force it | 21:24 |
| Laney | smells like a bug that this was requested | 21:24 |
| * Laney finishes making dinner first | 21:25 | |
| xnox | darn. samba4-clients is still uninstallabe | 21:46 |
| Laney | doh | 21:51 |
| xnox | all autopackage tests passed, waiting on samba/armhf | 23:07 |
| xnox | Laney: all in =) | 23:32 |
| === thomi_ is now known as thomi | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!