[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] <slangasek> hmm, I guess if the lucid-main autotest still hasn't given us results after 3h30, that's a good sign
[01:00] <slangasek> it only takes 2.5h to fail on mono :)
[01:05] <infinity> slangasek: But what does it fail on at 3:45? ;)
[01:05] <slangasek> we'll see!
[03:05] <ScottK> libtelepathy-qt4-farsight2 can be removed due to NBS if someone is awake (infinity).  No rdepends left.
[03:08] <infinity> ScottK: That was quick.
[03:08] <ScottK> The only rdepend was the -dev from the same source.
[03:08] <ScottK> Kind of a self-licking ice cream cone for NBS.
[03:09] <infinity> A self... Licking... Ice cream cone?  Why does that metaphor somehow sound terribly dirty?
[03:10] <infinity> ScottK: Removed.
[03:10] <ScottK> Dunno.  Look in the mirror.
[03:10] <ScottK> Thanks.
[03:13]  * infinity is a bit shocked that the only thing on outdate.txt is the libical FTBFS.
[03:13] <infinity> Oh, outdate_all is less pleasant.
[03:14] <ScottK> Yes, but main looks pretty decent. Feel free to fix the LO FTBFS on armel.
[03:14] <infinity> I'll let Jani do it, since he so LOVES libreoffice.
[03:14] <slangasek> 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] <infinity> slangasek: I don't follow the second half of that run-on sentence.
[03:16] <slangasek> 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] <slangasek> so if we refresh the initramfs to contain current libcrypto matching the libssl in the archive, this goes away
[03:17] <infinity> They probably shouldn't do that anyway, or you get image/component skew post-release too.
[03:17] <infinity> But rebuilding is a quick fix.
[03:18] <slangasek> well, ultimately it seems the problem is libssl1.0.0-udeb has wrong deps
[03:18] <slangasek> Depends: libc6-udeb (>= 2.15), libcrypto1.0.0-udeb (>= 1.0.0)
[03:18] <infinity> Needs to tighten that up?
[03:18] <slangasek> yeah; there's a new symbol version
[03:18] <infinity> That would fix it, then.
[03:18] <infinity> Perhaps we should fix the actual bug. :P
[03:19] <slangasek> that's also acceptable ;)
[03:19] <infinity> 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] <infinity> s/is/isn't/
[03:20] <infinity> libcrypto 1.0.0 libssl1.0.0 (>= 1.0.0)
[03:20] <infinity> libssl 1.0.0 libssl1.0.0 (>= 1.0.0)
[03:20] <infinity> udeb: libcrypto 1.0.0 libcrypto1.0.0-udeb (>= 1.0.0)
[03:20] <infinity> udeb: libssl 1.0.0 libssl1.0.0-udeb (>= 1.0.0)
[03:20] <infinity> Looks like the shlibs are just plain wrong across the board.
[03:21]  * infinity fixes.
[03:23] <infinity> Although.  Shouldn't dh_makeshlibs be working this magic without intervention?
[03:24]  * infinity builds openssl so he can stop guessing.
[03:25] <infinity> Nevermind, I can't read.  Fixing. :P
[03:26] <slangasek> the symbols file is also entirely missing the new symbols
[03:26] <slangasek> so that's bad too
[03:26] <ScottK> BTW, if you look at component mismatches, the source/binary demotions for telepathy-farsight should be good to do.
[03:26] <infinity> It shouldn't be.
[03:26] <slangasek> infinity: "shouldn't"?
[03:27] <infinity> slangasek: Yes.  Shouldn't.  What's mising?
[03:28] <infinity> slangasek: I can't see how they could be missing and the build not fail.
[03:31] <slangasek> infinity: dpkg-gensymbols doesn't require missing symbols to be treated as a failure, and it isn't by default
[03:31] <ScottK> Actually, I think those can be removed.  Let me check.
[03:31] <infinity> slangasek: No, I suppose not.  And the way it's used here is odd.
[03:31] <infinity> slangasek: But I don't see how there could be symbols present in the library but not in the symbols file?
[03:31] <infinity> slangasek: Barring a pretty massive bug in dpkg-gensymbols.
[03:32] <slangasek> the symbols file isn't autogenerated
[03:33] <infinity> Are we talking about the same one?
[03:33] <infinity> The one in the binary package is.
[03:33] <infinity> The one in the source package only has 6 lines.
[03:33] <infinity> Anyhow, the shlibdeps thing is fixed.
[03:34] <infinity> Huh, and I just got a ton of 1.0.1 symbols in debian/libssl1.0.0/DEBIAN/symbols
[03:35] <infinity> And those are the only difference between that and my installed copy.
[03:35] <slangasek> hmm
[03:35] <infinity> I'm not actually sure how that's even possible, given that the thing I changed is after dpkg-gensymbols...
[03:36] <infinity> Puzzling.
[03:37] <infinity> Anyhow, is there a bug for the dependency thing?
[03:39] <infinity> Ugh, and a clean target that doesn't clean.
[03:40] <ScottK> 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] <slangasek> none filed no
[03:41] <infinity> Kay, one more test build to see if this magical appearance of symbols seems to be a recurring thing.
[03:41] <infinity> And then I'll upload. :P
[03:41] <infinity> (Either way, the shlibs will be fixed, which is the nastier bug, symbols files are optional anyway)
[03:42] <infinity> Or I might be living in the past.  Are they still optional?
[03:42] <slangasek> if the symbols file exists it will be used exclusively and the shlibs file is ignored.
[03:43] <infinity> Well, the shlibdeps call in the package itself seemed to DTRT after I fixed the shlibs.
[03:43] <infinity> But, the symbols file also magically fixed itself, so that's not much of a test.
[03:47] <slangasek>         dpkg-gensymbols -Pdebian/libssl1.0.0/ -plibssl1.0.0 -c4
[03:47] <slangasek> urk
[03:47] <slangasek> that -c4 is exactly what should *not* let the package out the door without a complete symbols file
[03:47] <infinity> slangasek: Well, a second try here, and it gave me all the 1.0.1 symbols again.
[03:48] <infinity> slangasek: So, I'm kinda puzzled as to how it didn't before.
[03:48] <slangasek> right, so why didn't it do that on the buildd
[03:48] <slangasek> you see the broken .symbols in the package too, right?  It's not some local corruption of mine?
[03:48] <infinity> Yeah, same here.
[03:49] <slangasek> 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] <slangasek> from the build log :/
[03:49] <infinity> http://paste.ubuntu.com/897340/
[03:49] <infinity> ^-- Diff from local to build.
[03:50] <infinity> 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] <infinity> slangasek: Though -c4 clearly won't do any good when debian/libssl.symbols is a template, not a full list.
[03:50] <infinity> (I didn't even know you could wildcard/template until just now)
[03:51] <slangasek> well, it would throw an error if there were any new symbols not matching those wildcards
[03:51] <infinity> But there aren't.
[03:51] <slangasek> (which should be safe enough, given those wildcards)
[03:51] <infinity> And it won't whine if it's missing symbols that match the wildcards, which is the case on the buildd.
[03:52] <infinity> For whatever moon-phase-induced reason.
[03:52] <slangasek> hmm, that seems like a bug in dpkg-gensymbols though
[03:52] <slangasek> -c1 is "fail if some symbols have disappeared".  There's a wildcard matching nothing.  Shouldn't that count?
[03:52] <infinity> Maybe?
[03:52] <infinity> I dunno.
[03:54] <infinity> slangasek: It had this problem on every arch, it wasn't moon phase.
[03:55] <infinity> 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] <slangasek> AIUI, the dpkg-gensymbols line only works as a sanity check
[03:56] <slangasek> because dh_makeshlibs will call dpkg-gensymbols a second time
[03:56] <slangasek> and overwrite
[03:56] <infinity> Oh!
[03:56] <infinity> And maybe it's blatantly ignoring symbols that are >> 1.0.0 because of the dep constraint.
[03:57] <infinity> That seems like kinda weird behaviour.
[03:57] <slangasek> yes, it does
[03:57] <infinity> But explains what I'm seeing here with my shlibs fix magically fixing the symbols too.
[03:57]  * slangasek nods
[03:59] <infinity> Yeah, I'm going to just upload this and ponder the implications of debhelper and/or dpkg bugs later.
[04:02] <infinity> Erk.
[04:02] <infinity> Maybe not.
[04:02] <infinity> Rebuilding 1.0.1-2ubuntu1 here still gets me a correct symbols file.
[04:02] <infinity> So my computer's smarter than the buildds.
[04:02] <infinity> Never a good sign.
[04:02] <infinity> Time for a clean chroot.
[04:04] <slangasek> any -j madness possible?
[04:04] <infinity> I was -j2 here.
[04:04] <infinity> But so are almost all the buildds.
[04:04] <infinity> I could try not.
[04:05] <slangasek> it's a pretty linear debian/rules
[04:05] <infinity> Yeah.
[04:05] <infinity> And the logs certainly seem to show it in order.
[04:05] <infinity> I don't see the usual interleaving that says "something broke"
[04:07] <infinity> It's weird what random greps turn up.
[04:07] <infinity> test_buildd_recipe:         'archive_purpose': 'puppies',
[04:27] <slangasek> 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] <slangasek> whereas the first time around, it wasn't
[04:28] <infinity> 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] <infinity> slangasek: Ahh, but my chroot does have 1.0.1 installed, yes.
[04:28] <infinity> 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] <infinity> Maybe the dh_makeshlibs isn't actually using the just-built library?
[04:30] <infinity> Not seeing how that would happen either, though. :/
[04:35] <infinity> slangasek: Bingo.
[04:36] <slangasek> ?
[04:36] <infinity> 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] <infinity> absolute symlinks in the package, resolving to the system libraries.
[04:36] <slangasek> ah
[04:37] <infinity> Probably just need to -X those, since I'm pretty sure those links need to be absolute, per policy.
[04:37] <infinity> Though it's been a while since I read that section.
[04:37] <slangasek> pretty sure those links shouldn't be there at all
[04:37] <infinity> Anything that crosses top-level dirs, right?
[04:37] <slangasek> that's the idea
[04:38] <slangasek> but why should /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 exist at all?  It's redundant
[04:38] <infinity> 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] <slangasek> openssl (0.9.8g-15ubuntu2) jaunty; urgency=low
[04:38] <slangasek>   * Move runtime libraries to /lib, for the benefit of wpasupplicant
[04:38] <slangasek>     (LP: #44194). Leave symlinks behind in /usr/lib (except on the Hurd)
[04:38] <slangasek>     since we used to set an rpath there.
[04:38] <slangasek>  -- Colin Watson <cjwatson@ubuntu.com>  Fri, 06 Mar 2009 12:48:52 +0000
[04:38] <slangasek> that reasoning no longer applies
[04:38] <slangasek> we should just kill them
[04:39] <infinity> Seems fair.
[04:39] <slangasek> infinity: care to do the honors?
[04:39] <infinity> Yup.
[04:39] <infinity> Reject my current upload, plox.
[04:39] <slangasek> rejecting previous upload
[04:41] <infinity> Oh wow, the linking for the .so hurts.
[04:41] <infinity> Anyhow, fixing the runtime links. :P
[04:42] <infinity> Hrm.
[04:43] <infinity> slangasek: Will the shlibs madness also follow the -dev links (which have the same issue)?
[04:43] <infinity> slangasek: Or is *.so ignored?
[04:43] <infinity>             /(\.so\.|\.so$)/ && -f $_ &&
[04:44] <infinity> Looks like it'll trip up on the dev links too.
[04:44] <infinity> So, need to at least -X those.
[04:44] <slangasek> really?  odd
[04:44] <infinity> Well, unless I can't read pcre.
[04:45] <infinity>        -Xitem, --exclude=item
[04:45] <infinity>            Exclude files that contain item anywhere in their filename or directory from being
[04:45] <infinity>            treated as shared libraries.
[04:45] <slangasek> oh, but isn't that what the -f $_ is for?
[04:45] <infinity> ^-- Cause "anywhere" is useful...
[04:45] <slangasek> i.e., this should never match symlinks
[04:46] <infinity> Hrm.  If it never matches symlinks, then I still don't know how we got here. :P
[04:46] <slangasek> yep
[04:48] <slangasek> so I can reproduce the error by downgrading libssl10.0.
[04:49] <slangasek> infinity: oh, but of course dh_makeshlibs only looks at the tmpdir of the current binary package
[04:49] <slangasek> so dropping the compat /usr/lib symlinks is sufficient
[04:50] <infinity> Oh, since it's only libssl1.0.0 we care about, the -dev will be ignored...
[04:50] <infinity> Can you quickly confirm that by just removing them by hand and re-running dh_makeshlibs?
[04:50] <slangasek> yes, confirmed
[04:52] <infinity> Reuploaded.
[04:53] <slangasek> (and perl's -f returns true for symlinks, probably by analogy with [, using stat vs. lstat; so that's that mystery explained)
[04:54] <infinity> Yeah, makes sense.  test does the same.
[04:54] <infinity> Oh, you just said that.
[04:54] <slangasek> and that could also be a bug in dpkg-gensymbols
[04:54] <infinity> Yeah, arguably.  Following symlinks seems inherently dangerous.
[04:54] <infinity> Not only the package->system issue, but cross-package linking.
[04:54] <infinity> You want the real library, not a ghost.
[04:55] <slangasek> care to file a bug on dpkg?
[04:55] <infinity> Later tonight, sure.  I'm currently multitasking between work and life (as of a few minutes ago)
[04:55] <infinity> And I think life's about to win.
[04:55] <infinity> By virtue of being slightly prettier.
[04:56] <slangasek> ok :)
[04:56] <infinity> Oh, that's why my upload isn't in the queue.
[04:56] <slangasek> .upload in your way? :)
[04:57] <infinity> No.
[04:57] <infinity> */55
[04:57] <infinity> We need to fix that.
[04:57] <slangasek> ?
[04:57] <infinity> It used to be a gap left for a security queue from dak->soyuz.
[04:57] <infinity> So, the "no queue run at 55" thing is, like, 4 years obsolete?
[04:58] <infinity> Feel free to fix lp_queue's crontab and ping a LOSA to mirror it to their deployment bits.
[04:58] <infinity> (Or I'll do that later too)
[04:59] <slangasek> it's not clear to me that won't give someone an aneurysm
[04:59] <slangasek> so I'll pass for now :)
[04:59] <infinity> Heh.
[05:00] <infinity> Alright, I'll take care of it with webops later when I'm not distracted. ;)
[06:04] <slangasek> whoo, lucid-main upgrade test succeeded on i386
[06:04] <slangasek> (and failed on amd64... baby steps)
[06:05] <slangasek> dpkg: unrecoverable fatal error, aborting:
[06:05] <slangasek>  fork failed: Cannot allocate memory
[06:05] <slangasek> heh
[06:39] <infinity> slangasek: *raise brow*
[06:39] <slangasek> it's not beta-critical
[06:40] <slangasek> but obsolete conffiles are now being looked at by the auto upgrader
[06:40] <slangasek> so I figured I'd shoot a couple
[06:41] <infinity> slangasek: Oh, no, I was raising my brow at the "fork failed: Cannot allocate memory"
[06:41] <slangasek> oh
[06:42] <slangasek> well, clearly the amd64 upgrade went so well that the VM couldn't contain itself
[06:42] <infinity> *snicker*
[06:46] <infinity> Anyhow, since we need to enter respin city at some point anyway, and this looks correct, I'm accepting it.
[07:53] <jibel> session failed to start with latest unity, great :/
[08:05] <jibel> Can you respin ubuntu alternate. It failed because versions of gnome-control-center and gnome-control-center-data didn't match.
[17:49] <bdrung> can someone look at the FFe request bug #963062?
[17:49] <ubot2`> Launchpad bug 963062 in distro-info "[FFE] distro-info should have posix shell cmdline tool" [Medium,New] https://launchpad.net/bugs/963062
[17:55] <tumbleweed> I suppose I can :)
[17:59] <bdrung> tumbleweed: distro-info was written in many languages: python, haskell, shell, ...
[17:59] <bdrung> maybe i will rewrite it i C one day :)
[18:00] <bdrung> tumbleweed: btw, would requesting a FFe for lintian makes sense?
[18:03] <tumbleweed> bdrung: sure, latest lintians are nice to have
[18:12] <bdrung> tumbleweed: thanks. btw, why is there a timeframe given?
[18:23] <tumbleweed> bdrung: so tha twe don't end up with a pile of approved FFes that haven't landed
[18:24] <bdrung> k
[18:24] <bdrung> tumbleweed: i would do it right now, but https://launchpad.net/debian/+source/distro-info is slow in grabbing the new version
[18:35] <Daviey> bdrung: thanks for your work on distro-info, and splitting out the config.
[18:36] <Daviey> 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] <tumbleweed> Daviey: already approved
[18:36] <Daviey> Top Banana
[18:38] <bdrung> Daviey: you're welcome
[18:53] <Daviey> cjwatson: Are you around?
[18:53] <Daviey> cjwatson: I suspect d-i needs a rebuild, following the openssl bump...
[18:54] <Daviey> main-menu[569]: (process:7356): wget.gnu: /lib/libcrypto.so.1.0.0:
[18:54] <Daviey> version `OPENSSL_1.0.1' not found (required by /lib/libssl.so.1.0.0)
[18:54] <Daviey> (seeing the same thing with curl aswell)
[18:59] <slangasek> Daviey: are you still seeing that after the latest openssl upload?
[18:59] <slangasek> 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] <slangasek> (d-i should get a respin at some point, but that's an optimization rather than a bugfix)
[19:06] <Daviey> slangasek: when was that published?
[19:07] <Daviey> slangasek: I've been trying to work around it, by using a local udeb mirror.
[19:07] <slangasek> Daviey: after we spoke last night :)
[19:07] <infinity> Daviey: ~10 hours ago?
[19:07] <Daviey> hmm
[19:07] <Daviey> let me try it
[19:07] <slangasek> 1.0.1-2ubuntu2
[19:07] <infinity> Daviey: Please do.  This should fix the real bug.
[19:07] <infinity> Daviey: (As in, libssl-udeb should now pull in libcrypto-udeb and override the mismatched one in the initrd)
[19:08] <infinity> 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] <Daviey> /var/log/apache2/access.log:2590:10.55.55.3 - - [24/Mar/2012:14:51:33 -0400] "GET /ubuntu/pool/main/o/openssl/libssl1.0.0-udeb_1.0.1-2ubuntu2_i386.udeb HTTP/1.1" 200 149682 "-" "Wget"
[19:09] <Daviey> no dice
[19:09] <Daviey> I did notice that if i anna-install'd wget-udeb by hand.. it *ddi* work
[19:09] <Daviey> did*
[19:09] <Daviey> so i'm not fully convinced it's just an optimzation
[19:09] <infinity> So, we have a d-i bug here too perhaps.
[19:10] <infinity> (Not "an it needs rebuilding" bug, but an "it's doing something wrong" bug)
[19:10] <infinity> Hrm, who accepted linux-firmware?
[19:11] <Daviey> right.. adding an early_command to install wget-udeb doesn't work.. but dropping to the console and anna-instaling after failure, makes it work
[19:11] <infinity> How are you installing it with the early_command?
[19:13] <infinity> Still anna-install?
[19:13] <Daviey> yes
[19:14] <infinity> Oh, but early.  I wonder if early is using lists local to the initrd, before we've updated to see what the interwebs have to offer.
[19:14] <infinity> THough, then you'd be getting the old version.  Nevermind.
[19:14] <infinity> Daviey: Anyhow, we can (and will) rebuild d-i, but could you file a bug about this behaviour?  It's obviously wrong.
[19:14] <ScottK> bdrung: distro-info-data source accepted.
[19:14] <Daviey> infinity: I've set the mirror/* to be my custom local forked archive
[19:15] <infinity> Daviey: And undoing that and using the defaults gives the same issues?
[19:15] <Daviey> infinity: yes
[19:15] <infinity> Kay/
[19:16] <infinity> Yeah, please file a bug.
[19:16] <infinity> And now I'm just concerned that whoever accepted linux-firmware may force me to bump d-i floppy sizes again before I can rebuild it. :P
[19:16] <Daviey> I wish i could work out why an ann-install in early is different to later stages
[19:17] <infinity> If you'd prefer to track it down instead of filing a bug, that doesn't hurt my feelings either. ;)
[19:17] <Daviey> infinity: you can chain packages in anna-install foo bar ?
[19:17] <infinity> Daviey: I'm not much of an anna expert.
[19:19] <infinity> And yes, anna allows multiple package arguments.
[19:19] <infinity> (And by extension, anna-install, which is just a thin shim)
[19:27] <Daviey> Would it be bad karma to do a d-i no-change-rebuild without speaking to Colin first?
[19:27] <slangasek> no
[19:27] <slangasek> sounds like infinity might be working on it though?
[19:27] <Daviey> slangasek: Do you already have the source locally?
[19:28] <slangasek> probably not any current source :)
[19:28] <Daviey> infinity: are you?
[19:28]  * Daviey pulls
[19:28] <infinity> Daviey: See above.
[19:28] <infinity> Daviey: It may well fail because of the new linux-firmware.
[19:29] <infinity> Daviey: I'd rather make sure that's not true first.
[19:29] <Daviey> infinity: Suggestions on how to debug that?
[19:31] <infinity> Daviey: Sure, try to build locally for both amd64 and i386, if it works, we're good.  If it fails with "device full", it needs twiddling.
[19:31] <infinity> Daviey: I was going to do this in a little bit.
[19:31] <Daviey> Interesting, looking at the chanelog for the last debian-installer upload
[19:32] <Daviey> It seems to be netboot failing, rather than cd
[19:33] <infinity> "It"?
[19:33] <Daviey> infinity: the issue i am seeing..
[19:33] <Daviey> I need to reproduce the the latest daily.
[19:44] <Daviey> infinity: confirmed, curl works from the current daily iso.. but *not* from netboot image.
[19:51] <infinity> Well, we can definitely rebuild d-i to paper over it for now, but I'm curious about why anna-install hates you in early_command but not later.
[19:56] <jdstrand> infinity: re hamster-indicater> hamster is a time tracking tool. it used to have something for gnome-panel; this gives that something back to unity
[19:57] <jdstrand> infinity: that something is an indicator that allows you to see yuor current activity and how long you've been at it, along with methods to change tasks, etc
[19:59] <jdstrand> infinity: it's quite handy and I've been using the indicator from the ppa for probably going on a year
[20:00] <infinity> jdstrand: Kay.  Was mostly just curious, since the description was wildly unhelpful.  And also figured it might be something watching my CPU cores (ie: my system's hamsters).  :P
[20:02] <jdstrand> heh
[20:02] <bdrung> ScottK: thanks. should i sync distro-info 0.6 or wait until lp picks 0.7 up?
[20:02] <jdstrand> the longer description is more helpful. I didn't ever notice how bad the short description is :)
[20:03] <ScottK> bdrung: I'd wait for 0.7.
[20:03] <jdstrand> it is essentially "echo $srcpkg" | sed 's/\-/ /' :)
[20:03] <jdstrand> not the greatest
[20:04] <infinity> jdstrand: Given that short descriptions shouldn't even mention the package, yeah, it's not ideal. ;)
[20:05] <infinity> jdstrand: (though, in the case of glueish packages, it's hard to avoid, when perhaps what you want is "foo-indicator: add indicator support to foo, a utility that tracks your fooishness")
[20:06]  * jdstrand nods
[20:06] <jdstrand> I can fix it up once approved
[22:01] <cjwatson> infinity: d-i mostly ignores versioned dependencies.  This is documented
[22:02] <cjwatson> (doc/devel/modules.txt)
[22:03] <cjwatson> Daviey: cdrom (daily ISO) vs. netboot differs because libcrypto1.0.0-udeb is in the netboot initrd but not in the cdrom initrd
[22:06] <cjwatson> So this is simply that anna/libd-i doesn't do version checks.  It's intentionally reduced compared to a full dependency resolver; I doubt that we'll "fix" this.
[22:22] <Daviey> cjwatson: if i anna-install libcrypto1.0.0-udeb from early_command, will it work around this?
[22:48] <infinity> cjwatson: Hrm.  That seems to kinda negate the usefulness of having versioned deps in udebs then, especially in the post-release initrd/archive skew case.