[00:06] * skaet doesn't mind hard, just dislikes wasting time because tools aren't there to do the job.
[00:22] * infinity notes that writing tools is often a good solution to lacking tools.
[00:51] * skaet --> TGIF.
[01:00] hmm, I guess if the lucid-main autotest still hasn't given us results after 3h30, that's a good sign
[01:00] it only takes 2.5h to fail on mono :)
[01:05] slangasek: But what does it fail on at 3:45? ;)
[01:05] we'll see!
[03:05] libtelepathy-qt4-farsight2 can be removed due to NBS if someone is awake (infinity). No rdepends left.
[03:08] ScottK: That was quick.
[03:08] The only rdepend was the -dev from the same source.
[03:08] Kind of a self-licking ice cream cone for NBS.
[03:09] A self... Licking... Ice cream cone? Why does that metaphor somehow sound terribly dirty?
[03:10] ScottK: Removed.
[03:10] Dunno. Look in the mirror.
[03:10] Thanks.
[03:13] * infinity is a bit shocked that the only thing on outdate.txt is the libical FTBFS.
[03:13] Oh, outdate_all is less pleasant.
[03:14] Yes, but main looks pretty decent. Feel free to fix the LO FTBFS on armel.
[03:14] I'll let Jani do it, since he so LOVES libreoffice.
[03:14] cjwatson: Daviey is reporting an issue with the d-i netboot images; it appears libcrypto is in the initramfs but libssl is not, so pulling the libssl-udeb doesn't work without also pulling the libcrypto-udeb... I think we want to respin d-i for this?
[03:16] slangasek: I don't follow the second half of that run-on sentence.
[03:16] infinity: libcrypto in the initramfs is 1.0.0; libssl is not there; things trying to pull in libssl w/o libcrypto fail
[03:17] so if we refresh the initramfs to contain current libcrypto matching the libssl in the archive, this goes away
[03:17] They probably shouldn't do that anyway, or you get image/component skew post-release too.
[03:17] But rebuilding is a quick fix.
[03:18] well, ultimately it seems the problem is libssl1.0.0-udeb has wrong deps
[03:18] Depends: libc6-udeb (>= 2.15), libcrypto1.0.0-udeb (>= 1.0.0)
[03:18] Needs to tighten that up?
[03:18] yeah; there's a new symbol version
[03:18] That would fix it, then.
[03:18] Perhaps we should fix the actual bug. :P
[03:19] that's also acceptable ;)
[03:19] A respin to freshen things afterward is a bad idea, but maybe after testing with an intentional skew to make sure the bug's fixed.
[03:19] s/is/isn't/
[03:20] libcrypto 1.0.0 libssl1.0.0 (>= 1.0.0)
[03:20] libssl 1.0.0 libssl1.0.0 (>= 1.0.0)
[03:20] udeb: libcrypto 1.0.0 libcrypto1.0.0-udeb (>= 1.0.0)
[03:20] udeb: libssl 1.0.0 libssl1.0.0-udeb (>= 1.0.0)
[03:20] Looks like the shlibs are just plain wrong across the board.
[03:21] * infinity fixes.
[03:23] Although. Shouldn't dh_makeshlibs be working this magic without intervention?
[03:24] * infinity builds openssl so he can stop guessing.
[03:25] Nevermind, I can't read. Fixing. :P
[03:26] the symbols file is also entirely missing the new symbols
[03:26] so that's bad too
[03:26] BTW, if you look at component mismatches, the source/binary demotions for telepathy-farsight should be good to do.
[03:26] It shouldn't be.
[03:26] infinity: "shouldn't"?
[03:27] slangasek: Yes. Shouldn't. What's mising?
[03:28] slangasek: I can't see how they could be missing and the build not fail.
[03:31] infinity: dpkg-gensymbols doesn't require missing symbols to be treated as a failure, and it isn't by default
[03:31] Actually, I think those can be removed. Let me check.
[03:31] slangasek: No, I suppose not. And the way it's used here is odd.
[03:31] slangasek: But I don't see how there could be symbols present in the library but not in the symbols file?
[03:31] slangasek: Barring a pretty massive bug in dpkg-gensymbols.
[03:32] the symbols file isn't autogenerated
[03:33] Are we talking about the same one?
[03:33] The one in the binary package is.
[03:33] The one in the source package only has 6 lines.
[03:33] Anyhow, the shlibdeps thing is fixed.
[03:34] Huh, and I just got a ton of 1.0.1 symbols in debian/libssl1.0.0/DEBIAN/symbols
[03:35] And those are the only difference between that and my installed copy.
[03:35] hmm
[03:35] I'm not actually sure how that's even possible, given that the thing I changed is after dpkg-gensymbols...
[03:36] Puzzling.
[03:37] Anyhow, is there a bug for the dependency thing?
[03:39] Ugh, and a clean target that doesn't clean.
[03:40] slangasek or infinity: telepathy-farsight (src): libtelepathy-farsight-dev libtelepathy-farsight-doc libtelepathy-farsight0 libtelepathy-farsight0-dbg (binaries) should all be removed now.
[03:40] none filed no
[03:41] Kay, one more test build to see if this magical appearance of symbols seems to be a recurring thing.
[03:41] And then I'll upload. :P
[03:41] (Either way, the shlibs will be fixed, which is the nastier bug, symbols files are optional anyway)
[03:42] Or I might be living in the past. Are they still optional?
[03:42] if the symbols file exists it will be used exclusively and the shlibs file is ignored.
[03:43] Well, the shlibdeps call in the package itself seemed to DTRT after I fixed the shlibs.
[03:43] But, the symbols file also magically fixed itself, so that's not much of a test.
[03:47] dpkg-gensymbols -Pdebian/libssl1.0.0/ -plibssl1.0.0 -c4
[03:47] urk
[03:47] that -c4 is exactly what should *not* let the package out the door without a complete symbols file
[03:47] slangasek: Well, a second try here, and it gave me all the 1.0.1 symbols again.
[03:48] slangasek: So, I'm kinda puzzled as to how it didn't before.
[03:48] right, so why didn't it do that on the buildd
[03:48] you see the broken .symbols in the package too, right? It's not some local corruption of mine?
[03:48] Yeah, same here.
[03:49] dpkg-shlibdeps: warning: debian/openssl/usr/bin/openssl contains an unresolvable reference to symbol CRYPTO_gcm128_release@OPENSSL_1.0.1: it's probably a plugin.
[03:49] from the build log :/
[03:49] http://paste.ubuntu.com/897340/
[03:49] ^-- Diff from local to build.
[03:50] slangasek: And all I've changed is the dh_makeshlibs call on the *next* line, so I can't see how it would have changed the symbols file.
[03:50] slangasek: Though -c4 clearly won't do any good when debian/libssl.symbols is a template, not a full list.
[03:50] (I didn't even know you could wildcard/template until just now)
[03:51] well, it would throw an error if there were any new symbols not matching those wildcards
[03:51] But there aren't.
[03:51] (which should be safe enough, given those wildcards)
[03:51] And it won't whine if it's missing symbols that match the wildcards, which is the case on the buildd.
[03:52] For whatever moon-phase-induced reason.
[03:52] hmm, that seems like a bug in dpkg-gensymbols though
[03:52] -c1 is "fail if some symbols have disappeared". There's a wildcard matching nothing. Shouldn't that count?
[03:52] Maybe?
[03:52] I dunno.
[03:54] slangasek: It had this problem on every arch, it wasn't moon phase.
[03:55] slangasek: I'm going to revert my other fix and see if this is reproducible here. But if it is, I'm not sure I'd understand why.
[03:56] AIUI, the dpkg-gensymbols line only works as a sanity check
[03:56] because dh_makeshlibs will call dpkg-gensymbols a second time
[03:56] and overwrite
[03:56] Oh!
[03:56] And maybe it's blatantly ignoring symbols that are >> 1.0.0 because of the dep constraint.
[03:57] That seems like kinda weird behaviour.
[03:57] yes, it does
[03:57] But explains what I'm seeing here with my shlibs fix magically fixing the symbols too.
[03:57] * slangasek nods
[03:59] Yeah, I'm going to just upload this and ponder the implications of debhelper and/or dpkg bugs later.
[04:02] Erk.
[04:02] Maybe not.
[04:02] Rebuilding 1.0.1-2ubuntu1 here still gets me a correct symbols file.
[04:02] So my computer's smarter than the buildds.
[04:02] Never a good sign.
[04:02] Time for a clean chroot.
[04:04] any -j madness possible?
[04:04] I was -j2 here.
[04:04] But so are almost all the buildds.
[04:04] I could try not.
[04:05] it's a pretty linear debian/rules
[04:05] Yeah.
[04:05] And the logs certainly seem to show it in order.
[04:05] I don't see the usual interleaving that says "something broke"
[04:07] It's weird what random greps turn up.
[04:07] test_buildd_recipe: 'archive_purpose': 'puppies',
[04:27] infinity: the only thing I can think of that's different now is that libssl1.0.0 1.0.1 is going to be installed in the build chroot
[04:27] whereas the first time around, it wasn't
[04:28] slangasek: So, a local build of the previous source in a clean buildd chroot still gives me all the 1.0.1 symbols.
[04:28] slangasek: Ahh, but my chroot does have 1.0.1 installed, yes.
[04:28] slangasek: Still, while I don't entirely understand what's wrong, every test here seems to imply that accepting the above package will "fix" things. :P
[04:29] Maybe the dh_makeshlibs isn't actually using the just-built library?
[04:30] Not seeing how that would happen either, though. :/
[04:35] slangasek: Bingo.
[04:36] ?
[04:36] slangasek: lrwxrwxrwx 1 buildd buildd 37 Mar 24 04:17 ./debian/libssl1.0.0/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 -> /lib/x86_64-linux-gnu/libssl.so.1.0.0
[04:36] absolute symlinks in the package, resolving to the system libraries.
[04:36] ah
[04:37] Probably just need to -X those, since I'm pretty sure those links need to be absolute, per policy.
[04:37] Though it's been a while since I read that section.
[04:37] pretty sure those links shouldn't be there at all
[04:37] Anything that crosses top-level dirs, right?
[04:37] that's the idea
[04:38] but why should /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 exist at all? It's redundant
[04:38] I was about to say "for braindead upstreams that dlopen absolute paths", but they're never going to look in the multi-arch path anyway. :P
[04:38] openssl (0.9.8g-15ubuntu2) jaunty; urgency=low
[04:38] * Move runtime libraries to /lib, for the benefit of wpasupplicant
[04:38] (LP: #44194). Leave symlinks behind in /usr/lib (except on the Hurd)
[04:38] since we used to set an rpath there.
[04:38] -- Colin Watson Fri, 06 Mar 2009 12:48:52 +0000
[04:38] that reasoning no longer applies
[04:38] we should just kill them
[04:39] Seems fair.
[04:39] infinity: care to do the honors?
[04:39] Yup.
[04:39] Reject my current upload, plox.
[04:39] rejecting previous upload
[04:41] Oh wow, the linking for the .so hurts.
[04:41] Anyhow, fixing the runtime links. :P
[04:42] Hrm.
[04:43] slangasek: Will the shlibs madness also follow the -dev links (which have the same issue)?
[04:43] slangasek: Or is *.so ignored?
[04:43] /(\.so\.|\.so$)/ && -f $_ &&
[04:44] Looks like it'll trip up on the dev links too.
[04:44] So, need to at least -X those.
[04:44] really? odd
[04:44] Well, unless I can't read pcre.
[04:45] -Xitem, --exclude=item
[04:45] Exclude files that contain item anywhere in their filename or directory from being
[04:45] treated as shared libraries.
[04:45] oh, but isn't that what the -f $_ is for?
[04:45] ^-- Cause "anywhere" is useful...
[04:45] i.e., this should never match symlinks
[04:46] Hrm. If it never matches symlinks, then I still don't know how we got here. :P
[04:46] yep
[04:48] so I can reproduce the error by downgrading libssl10.0.
[04:49] infinity: oh, but of course dh_makeshlibs only looks at the tmpdir of the current binary package
[04:49] so dropping the compat /usr/lib symlinks is sufficient
[04:50] Oh, since it's only libssl1.0.0 we care about, the -dev will be ignored...
[04:50] Can you quickly confirm that by just removing them by hand and re-running dh_makeshlibs?
[04:50] yes, confirmed
[04:52] Reuploaded.
[04:53] (and perl's -f returns true for symlinks, probably by analogy with [, using stat vs. lstat; so that's that mystery explained)
[04:54] Yeah, makes sense. test does the same.
[04:54] Oh, you just said that.
[04:54] and that could also be a bug in dpkg-gensymbols
[04:54] Yeah, arguably. Following symlinks seems inherently dangerous.
[04:54] Not only the package->system issue, but cross-package linking.
[04:54] You want the real library, not a ghost.
[04:55] care to file a bug on dpkg?
[04:55] Later tonight, sure. I'm currently multitasking between work and life (as of a few minutes ago)
[04:55] And I think life's about to win.
[04:55] By virtue of being slightly prettier.
[04:56] ok :)
[04:56] Oh, that's why my upload isn't in the queue.
[04:56] .upload in your way? :)
[04:57] No.
[04:57] */55
[04:57] We need to fix that.
[04:57] ?
[04:57] It used to be a gap left for a security queue from dak->soyuz.
[04:57] So, the "no queue run at 55" thing is, like, 4 years obsolete?
[04:58] Feel free to fix lp_queue's crontab and ping a LOSA to mirror it to their deployment bits.
[04:58] (Or I'll do that later too)
[04:59] it's not clear to me that won't give someone an aneurysm
[04:59] so I'll pass for now :)
[04:59] Heh.
[05:00] Alright, I'll take care of it with webops later when I'm not distracted. ;)
[06:04] whoo, lucid-main upgrade test succeeded on i386
[06:04] (and failed on amd64... baby steps)
[06:05] dpkg: unrecoverable fatal error, aborting:
[06:05] fork failed: Cannot allocate memory
[06:05] heh
[06:39] slangasek: *raise brow*
[06:39] it's not beta-critical
[06:40] but obsolete conffiles are now being looked at by the auto upgrader
[06:40] so I figured I'd shoot a couple
[06:41] slangasek: Oh, no, I was raising my brow at the "fork failed: Cannot allocate memory"
[06:41] oh
[06:42] well, clearly the amd64 upgrade went so well that the VM couldn't contain itself
[06:42] *snicker*
[06:46] Anyhow, since we need to enter respin city at some point anyway, and this looks correct, I'm accepting it.
[07:53] session failed to start with latest unity, great :/
[08:05] Can you respin ubuntu alternate. It failed because versions of gnome-control-center and gnome-control-center-data didn't match.
[17:49] can someone look at the FFe request bug #963062?
[17:49] Launchpad bug 963062 in distro-info "[FFE] distro-info should have posix shell cmdline tool" [Medium,New] https://launchpad.net/bugs/963062
[17:55] I suppose I can :)
[17:59] tumbleweed: distro-info was written in many languages: python, haskell, shell, ...
[17:59] maybe i will rewrite it i C one day :)
[18:00] tumbleweed: btw, would requesting a FFe for lintian makes sense?
[18:03] bdrung: sure, latest lintians are nice to have
[18:12] tumbleweed: thanks. btw, why is there a timeframe given?
[18:23] bdrung: so tha twe don't end up with a pile of approved FFes that haven't landed
[18:24] k
[18:24] tumbleweed: i would do it right now, but https://launchpad.net/debian/+source/distro-info is slow in grabbing the new version
[18:35] bdrung: thanks for your work on distro-info, and splitting out the config.
[18:36] tumbleweed: This FFe makes perfect sense.. To SRU the config file, a data source package just needs uploading, rather than rebuilding a binary(s)
[18:36] Daviey: already approved
[18:36] Top Banana
[18:38] Daviey: you're welcome
[18:53] cjwatson: Are you around?
[18:53] cjwatson: I suspect d-i needs a rebuild, following the openssl bump...
[18:54] main-menu[569]: (process:7356): wget.gnu: /lib/libcrypto.so.1.0.0:
[18:54] version `OPENSSL_1.0.1' not found (required by /lib/libssl.so.1.0.0)
[18:54] (seeing the same thing with curl aswell)
[18:59] Daviey: are you still seeing that after the latest openssl upload?
[18:59] the latest libssl1.0.0-udeb in the archive should now declare a correct dependency on libcrypto1.0.0-udeb (>= 1.0.1), meaning that both should be pulled in for you
[19:00] (d-i should get a respin at some point, but that's an optimization rather than a bugfix)
[19:06] slangasek: when was that published?
[19:07] slangasek: I've been trying to work around it, by using a local udeb mirror.
[19:07] Daviey: after we spoke last night :)
[19:07] Daviey: ~10 hours ago?
[19:07] hmm
[19:07] let me try it
[19:07] 1.0.1-2ubuntu2
[19:07] Daviey: Please do. This should fix the real bug.
[19:07] Daviey: (As in, libssl-udeb should now pull in libcrypto-udeb and override the mismatched one in the initrd)
[19:08] Daviey: Once you've proven that's true then, yeah, a d-i rebuild to freshen things is still a good plan at some point.
[19:09]