| === darkxst_ is now known as darkxst | ||
| smb | infinity, hm just saw the uploads to bind and dhcp... is it still a lie that dhcp went through and bind is still in proposed? | 06:59 |
|---|---|---|
| smb | practically it seems to work... a little scary though | 08:23 |
| === sil2100_ is now known as sil2100 | ||
| Odd_Bloke | Could I get an AA to migrate gce-utils from {wily,xenial}-proposed to {wily,xenial} in partner, please? The versions in question are 1.3.3-0ubuntu2 and 1.3.3-0ubuntu1~15.10.0. | 09:14 |
| apw | Odd_Bloke, should we expect the backport to wily to be an older version than that for xenial ? | 10:10 |
| Odd_Bloke | apw: Oh, sigh, the xenial update didn't get backported like I thought it did; thanks for catching that. | 10:12 |
| Odd_Bloke | apw: (ubuntu2 is removing a package which we're leaving in wily, and some packaging cleanup, but it's probably worth having them in sync) | 10:12 |
| Odd_Bloke | apw: (Could we at least get xenial migrated whilst I fix up wily?) | 10:27 |
| apw | Odd_Bloke, if there is a sensible reason xenial has moved on, for a xenail only fix that seems fine to be out of sync, it just looks ok at first view hese the question | 10:29 |
| Odd_Bloke | apw: I do want to pull the changes back to wily, so hold off there; xenial is good to go though. :) | 10:32 |
| smb | apw, Oh hm, were you thinking that we should send out uploads for apt-cacher-ng for P and T today so they can bake? | 10:59 |
| apw | smb, that sounds familiar, vaguly ... | 11:05 |
| Odd_Bloke | apw: This new wily gce-utils supersedes the ubuntu2 that's already in the queue. :) | 11:17 |
| apw | Odd_Bloke, ack | 11:25 |
| Odd_Bloke | apw: Thanks. :) | 11:26 |
| infinity | smb: Uhh. Something's very wrong with the isc-dhcp packaging. | 11:53 |
| infinity | smb: Oh. Or maybe actually bind9. Hrm. | 11:54 |
| smb | infinity, no I think it is kind of ok because the deps are only build deps... but odd | 11:54 |
| infinity | smb: No, the deps should be deps. | 11:54 |
| infinity | smb: dhclient is linked against those libs. | 11:54 |
| smb | infinity, maybe statically? | 11:55 |
| infinity | base)adconrad@nosferatu:~$ apt-cache show isc-dhcp-client | egrep '^Version|^Depends' | 11:55 |
| infinity | Version: 4.3.3-5ubuntu10 | 11:55 |
| infinity | Depends: libc6 (>= 2.15), debianutils (>= 2.8.2), iproute2 | 11:55 |
| infinity | Version: 4.3.3-5ubuntu9 | 11:55 |
| infinity | smb: ^-- Ick. | 11:55 |
| infinity | Depends: libc6 (>= 2.15), libdns162, libisc160, debianutils (>= 2.8.2), iproute2 | 11:55 |
| infinity | smb: Yes, it could be statically linked in the new build, but that would be a failure on bind9's part too, since dhcp didn't change. | 11:55 |
| infinity | smb: What does ldd say on your system? On mine (running ubuntu9), libdns and libisc are dynamically linked. | 11:56 |
| infinity | (For /sbin/dhclient) | 11:56 |
| smb | infinity, a sec | 11:56 |
| apw | infinity, oh .. those libdns* htings are all not installable in britney for bind9 | 11:56 |
| apw | oh no those are all -export versions, hrm | 11:57 |
| smb | infinity, nothing of bind9 | 11:57 |
| infinity | apw: Yeap, looks like packaging errors galore here. | 11:57 |
| infinity | smb: Okay, so it ended up statically linked. Oops. | 11:57 |
| infinity | smb: Sounds like lamont buggered up some things. ;) | 11:57 |
| smb | infinity, maybe... I never checked for that. Though I did the revert of no-export libs for dhcp | 11:59 |
| infinity | smb: Without looking, my assumption is that lib*-export-dev lack a .so | 11:59 |
| infinity | And then there's the unrelated bit where the udebs have broken deps. | 12:00 |
| infinity | And someone also might have failed to fix the shlibs to account for udebs, so the dhcp-udeb dep will end up right (but no proof of that, just a solid bet :P) | 12:01 |
| infinity | lamaaaaaaaaaaaaaant! | 12:01 |
| flexiondotorg | Could someone in the release team provide n ack for this FFe please - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1557229 | 12:05 |
| ubot5 | Launchpad bug 1557229 in ubuntu-mate-artwork (Ubuntu) "FFe: ubuntu-mate-artwork 16.04.4 new release [debdiff and tarball attached]" [Low,New] | 12:05 |
| smb | infinity, So doko was bringing up other rdeps on #ubuntu-devel. I am not aware of any. Would they not also show up in Britney if there would be any? | 12:09 |
| infinity | smb: Why would they? The bind upload didn't make anything uninstallable. | 12:10 |
| infinity | (base)adconrad@nosferatu:~$ reverse-depends -b src:bind9 | 12:10 |
| infinity | smb: I see a few. But whether any of them link to the offending library or need to use the export libs (or did in the past), I don't know. | 12:10 |
| infinity | smb: Ahh, wily reveals all. | 12:11 |
| smb | infinity, I thought maybe in one of the reasons that hold back the new bind9... | 12:11 |
| infinity | smb: http://paste.ubuntu.com/15414142/ | 12:12 |
| infinity | smb: So, old rdeps never used export, it was always just dhcp. | 12:13 |
| smb | ah | 12:13 |
| smb | and nice... another command I had already installed but never properly used... | 12:16 |
| lamont | infinity: it's always been statically linked, I thought | 12:42 |
| infinity | lamont: Definitely not. | 12:42 |
| infinity | lamont: Or, at least, not since the libbind-dev switch. Let me check wily. | 12:43 |
| infinity | lamont: If it was statically linked, though, you wouldn't need the udebs. :P | 12:43 |
| lamont | check sid | 12:43 |
| lamont | infinity: good point | 12:43 |
| lamont | gar | 12:43 |
| smb | fwiw it seems in Trusty it was statically linked as well | 12:44 |
| infinity | (wily-amd64)root@nosferatu:~# ldd /sbin/dhclient | 12:44 |
| infinity | linux-vdso.so.1 => (0x00007ffe9c36b000) | 12:44 |
| infinity | libirs-export.so.91 => /lib/x86_64-linux-gnu/libirs-export.so.91 (0x00007f097f815000) | 12:44 |
| infinity | libdns-export.so.100 => /lib/x86_64-linux-gnu/libdns-export.so.100 (0x00007f097f4e7000) | 12:44 |
| infinity | libisc-export.so.95 => /lib/x86_64-linux-gnu/libisc-export.so.95 (0x00007f097f296000) | 12:44 |
| infinity | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f097eecc000) | 12:44 |
| infinity | libisccfg-export.so.90 => /lib/x86_64-linux-gnu/libisccfg-export.so.90 (0x00007f097ecbe000) | 12:44 |
| infinity | /lib64/ld-linux-x86-64.so.2 (0x000055e4e44d1000) | 12:44 |
| infinity | Definitely not static in wily. | 12:44 |
| infinity | smb: Yeah, very statis in trusty, but I'd call that a bug, not a feature. | 12:44 |
| infinity | The way it was in wily looks most "correct" to me. | 12:44 |
| lamont | smb: 9.9.5-5 or -6ish is when the -export stuff came to be | 12:45 |
| infinity | lamont: Anyhow, see #ubnutu-devel, doko's mangling it. | 12:45 |
| smb | infinity, Yeah I would agree... | 12:45 |
| lamont | before that it was a local copy of th elibrary source in dhcpd | 12:45 |
| * lamont goes there | 12:45 | |
| doko | no debian import since two days. anything wrong on our side? | 14:36 |
| cyphermox | doko: wasn't DIF on feb 18, or do we no longer do that? | 14:41 |
| doko | cyphermox, sure, but we make new versions available, so we can syncpackage them | 14:42 |
| Laney | It's a known error in Launchpad, which is being worked on | 14:42 |
| cyphermox | oh, ok you mean importing data in LP | 14:42 |
| cjwatson | doko: Yes, multiple problems due to Debian archive changes, all of which I'm working on | 14:44 |
| cjwatson | In fact I just pushed the last of the necessary fixes up for review | 14:44 |
| cjwatson | Dropping {Sources,Packages}.gz and Files/MD5sum fields in experimental caused some havoc in all kinds of places, Launchpad included | 14:46 |
| cjwatson | doko: I suspect the fixes will roll out on Monday at this point, unfortunately - (a) most likely reviewer will be asleep now, (b) I was unlikely to get an LP deployment done on a Friday afternoon anyway | 15:05 |
| doko | no haste, we can always sync manually if needed | 15:08 |
| xnox | infinity, stgraber: could i trick you two into accepting https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 ? | 16:04 |
| ubot5 | Launchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New] | 16:04 |
| xnox | it's a merge that fixes a bunch of horible things that we are ought to take. | 16:04 |
| cyphermox | davmor2: fyi: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237 | 16:14 |
| ubot5 | Launchpad bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4→ 16.04 dies midway taking out the session." [Critical,Confirmed] | 16:14 |
| * cyphermox kicks the upgrader around some more | 16:15 | |
| davmor2 | cyphermox: nice so it looks like it is a mix of screensaver and compiz wiping out the system then | 16:16 |
| cyphermox | maybe. | 16:16 |
| davmor2 | willcooke: ^ | 16:16 |
| cyphermox | the screensaver blanking the screen might be doing something compiz doesn't like | 16:16 |
| davmor2 | cyphermox: indeed | 16:17 |
| cyphermox | I've disabled the screensaver completely for now, we'll see if things carry on happily then | 16:17 |
| cyphermox | it's not a fix, but it gives us something to look into | 16:17 |
| davmor2 | cyphermox: I still blame gcc just cause it doesn't get picked on enough :) | 16:18 |
| cyphermox | *shrugs* it could be some really funky thing deep down in the entrails of software, I don't know, but in doubt I rather blame anything other than gcc until I know better. | 16:20 |
| cyphermox | ie. if graphics fail, it's far more likely to be the graphics driver or the thing that makes things pretty than say, X, even if X has its own issues. | 16:21 |
| cyphermox | then proceed from there with the more likely, once all the likely things are proven not to be the issue, proceed with the unlikely and outrageous ideas | 16:21 |
| cyphermox | and I'm gonna need a veggie burger, so back after lunch ;) | 16:23 |
| davmor2 | cyphermox: yeah but don't forget in 14.04 and 16.04 we have completely incompatible versions of gcc so it could contribute :) | 16:23 |
| willcooke | I tried disabling the screensaver during some testing last week | 16:28 |
| willcooke | it just postponed the inevitable crash :) | 16:28 |
| cyphermox | willcooke: dpms blanking doesn't seem to break the install, at least | 17:24 |
| willcooke | O_o | 17:27 |
| willcooke | oh | 17:27 |
| willcooke | right | 17:27 |
| willcooke | so thats good | 17:27 |
| willcooke | I thinbk | 17:27 |
| slangasek | tumbleweed: uhoh. does reverse-depends also not know about multiarch :any depends? 'reverse-depends -c main src:python-defaults' does not show python-bandit, which Depends: python:any | 17:46 |
| tumbleweed | slangasek: it does not | 17:46 |
| slangasek | :/ | 17:46 |
| tumbleweed | at the time, such syntax was not valid | 17:46 |
| davmor2 | cyphermox: enquiring minds need to know what happened with the upgrade with screensaver off? | 19:57 |
| cyphermox | it eventually froze | 20:05 |
| cyphermox | not crashed | 20:05 |
| cyphermox | so I started over, waiting for the screensaver to come up now, and I think it just did | 20:05 |
| cyphermox | yep | 20:06 |
| cyphermox | updating compiz + libglib2.0-0 from xenial (and whatever packages that pulls) seems to be sufficient | 20:06 |
| cyphermox | that certainly reduces the number of packages to look at already | 20:06 |
| davmor2 | cyphermox: I don't envy you but good man :) I wish you well in your quest | 20:49 |
| cyphermox | davmor2: I reduced it to some 15-20 packages related to compiz and gnome in some way; ie. cairo/pango, unity, wayland, nux, fontconfig, gail, libgtk, libatk, and libbamf, basically | 20:53 |
| cyphermox | all desktop stuff, so I'll let eleni look at compiz for now, and just make sure I was wrong about the screensaver not being disabled | 20:53 |
| superm1 | cyphermox: wouldn't it be safer to spin up a new session with a basic window manager and nothing for users to poke at and "use" to do the upgrade? something that looked like the session that is used for ubiquity/oem-config | 21:25 |
| superm1 | you could at least better limit which libraries and apps are getting pulled out from under you | 21:26 |
| infinity | superm1: Relogging into a lightweight "upgrade session" has been discussed a few times by a few people. No one's really specced it or done the work, though. And it's questionable if everyone would want the feature, so we'd probably still have to support live upgrades. | 21:30 |
| infinity | superm1: Though, I think computers might be mostly fast enough today for us to get away with a 2-stage "we downloaded everything, now give us your computer for an hour while we upgrade" thing without people screaming too loudy. | 21:31 |
| infinity | tumbleweed: For a closed arch, the simplest way to interpret foo:bar {build-,}deps is just to strip off ':.*' ... This is what Ubuntu's sbuild did, for instance, for a long time. :P | 21:32 |
| superm1 | infinity: yeah 2 stages is what i was thinking when i mentioned this, and it would allow for a simpler upgrade session that doesn't need network | 21:32 |
| infinity | tumbleweed: That's likely the quickest solution for reverse-deps. | 21:33 |
| tumbleweed | infinity: it's using python-debian | 21:33 |
| tumbleweed | which I think used to choke on those? | 21:33 |
| infinity | tumbleweed: Oh. Well, python-debian knows how to DTRT. | 21:33 |
| infinity | But it didn't always, indeed. | 21:33 |
| superm1 | but i guess it would take some time to spec that out and figure out implementation and that might be more than just bandaiding around the breakage found in live test | 21:33 |
| infinity | superm1: Yeah, the big concern I have with it is the bandaid effect. Yes, LTS->LTS is hard(er), but if people are writing sloppy postinsts and playing fast and loose with dependencies, eventually the same breakage will hit an SRU, which we want to live update by design. | 21:34 |
| infinity | superm1: Cause I refuse to move to a Windows "we'll install your software on reboot, no really" model. | 21:35 |
| cyphermox | infinity: well, you could tell: reboot to XYZ when you're ready to do the distro upgrade; and stop the user in grub when they do | 21:42 |
| cyphermox | (reboot) | 21:42 |
| cyphermox | not that pretty, but it could make it a very painfully obvious, limited environment in which to do upgrades | 21:43 |
| cyphermox | but that's work, and our thing currently tends to work, ish, except when it doesn't | 21:43 |
| * cyphermox kicks compiz | 21:43 | |
| infinity | cyphermox: Why reboot? Having an upgrade target in systemd and gunning for it would do the same thing. | 21:44 |
| cyphermox | or that, whatever | 21:45 |
| infinity | cyphermox: But, yeah, such things encourage the idea that "the upgrader will fix it", which is wrong-headed. | 21:45 |
| cyphermox | yeah, I know | 21:45 |
| cyphermox | but at least we don't explode because some random very critical lib gets messed up underneat some other very critical piece | 21:45 |
| infinity | cyphermox: Maybe if we wrote such a simple upgader environment, the compromise would be that we wouldn't enable it until a week before release, and the rest of the time, developers and power users are "stuck" doing live upgrades and fixing their effin bugs. :P | 21:46 |
| cyphermox | wfm | 21:46 |
| infinity | cyphermox: So the lightweight upgrader is there to paper over things we didn't notice, rather than paper over everyone being lazy. | 21:46 |
| cyphermox | yeah | 21:47 |
| cyphermox | I'm not sure this current crash (i'll blame compiz because I can) is about laziness though, really some obscure weirdness | 21:47 |
| infinity | Fair enough. | 21:48 |
| cyphermox | hah, so it really doesn't matter if there is a screensaver popping up or not, I got the crash anyway | 21:48 |
| infinity | But most of those are usually about either undeclared ABI changes (eek) or dependencies not tight enough for other similar reasons, or applications that disagree with you swapping files out from under them, etc. | 21:48 |
| cyphermox | I agree | 21:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!