[00:31] cjwatson: Oh, hrm. I suppose I could fix this in base-files-udeb instead. [00:31] Please tell me there isn't a base-files-udeb. [00:31] Do you mean rootskel? [00:31] Oh, or, whatever has the base filesystem. :P [00:32] Doesn't seem like the ideal place to work around PI things, though. [00:32] I hadn't looked. [00:32] Well, that's how amd64 works around it. [00:32] By shipping the lib64 -> lib symlink. [00:32] If I fix this in mklibs (which doesn't look too painful), that could go away. [00:32] True. [00:33] So you mean a /lib/armhfouyqwourtuwtriqur -> /lib symlink? [00:33] But it would be just as easy to ship.. .Yeah. [00:33] It's one or the other. Symlink the directory, or have mklibs install ldlib to its full path. [00:33] I guess that wouldn't be totally awful, although a proper fix would be better [00:33] The latter feels more correct, but the other hack already exists for amd64. [00:33] No upgrade problems, at least. [00:34] So we can switch later. [00:34] What, you mean you don't regularly install apt in your d-i initrds and upgrade them? [00:34] :P [00:35] So, yeah, what's responsible for that lib64 symlink? You reckon rootskel? [00:35] Sadly, the d-i build log was unhelpful. [00:35] rootskel, yes. [00:35] ./debian/rootskel.links.amd64:1:lib lib64 [00:36] lp:~ubuntu-core-dev/rootskel/ubuntu [00:36] Yeah, let's go with that [00:37] Yeah. It feels more correct to fix it in mklibs, but I'm also not sure what fallout that might cause when it tries to install amd64's PI to /lib64 [00:37] (which is correct, but I have no idea what order these things happen in) [00:38] We'd have to fix mklibs then upload eglibc and rootskel at around the same time, yes. [00:38] eglibc wouldn't need an upload. [00:39] It gets ldlib path from readelf. [00:39] Oh, yeah, duh [00:39] Where it lives in the udeb is irrelevant. [00:39] As I discoverde. :P [00:39] discovered, too. [00:39] The d-i build system unpacks all the base udebs (probably in roughly alpha order) and then runs mklibs. [00:39] So if it has a symlink there it might even work OK. [00:40] But yeah, I could remove the link from rootskel and fix mklibs. It's tempting. [00:40] Or, true, if the link's already in place, it would probably DTRT, since it's not absolute. [00:40] right [00:40] Yeah, maybe I'll fix this the way that seems more elegant, even if it's more work. [00:41] Cause adding a new symlink for any new arch with a m-a PI seems broken. [00:41] At run-time, udpkg basically just extracts stuff by calling tar [00:41] It wants libc6-udeb when it gets to the point of retrieving further installer components beyond its base system, since only the base system gets reduced so it needs a full libc at that point [00:42] Still a bit odd that it worked before that point for Tobin. [00:43] I'm moderately unsure as to what Tobin's breakage is right now. I'll need to play. [00:43] I can't quite think why specifically unpacking a new libc6-udeb would have hosed things if the problem was that the PI was in the wrong place. [00:43] Well, he moved his PI to the right place manually and repacked the initrd. [00:44] Otherwise, he would have never gotten that far. [00:44] Does udpkg freak out about overwriting unowned files? [00:45] I suppose it couldn't possibly, or this reduction business would fail horribly. [00:46] * infinity blinks and wonders where qemu-system-arm went. [00:48] Oh, in universe, in qemu-system. I must have napped through that package split. [00:52] Err, wait. [00:52] I can't test this with qemu. [00:52] No vexpress images. [00:55] udpkg doesn't give a shit about file ownership. [00:55] In fact it doesn't track it. [00:55] qemu doesn't have other arm targets yet? Boo. [00:57] S'ok. I can test the mklibs stuff locally. I just wanted to see if I could reproduce Tobin's thing. Which will have to wait for my Panda or QuickStart to be idle. [00:57] Silly bootstrapping. [00:57] Err, just my Panda. [00:57] No QS images either. :P [00:57] Fair enough. I'll leave you to reproduce with Tobin. :-P [00:57] (I'm sure you needed that image) [00:58] Dot dot dot. [00:58] I hate you SO MUCH right now. [00:58] You know, I don't think I know anyone else who spells out ellipses. [00:58] Sometimes, you need to. [00:58] For maximum effect. [04:38] cjwatson: Would appreciate comments and/or laughter on http://lucifer.0c3.net/~adconrad/mklibs.patch [04:38] cjwatson: (Presented as an upload to sid rather than precise, as Debian/armhf needs the fix just as badly) [04:41] cjwatson: As called by d-i, both mklibs and mklibs-copy appear to DTRT with my patchs for armhf, amd64, and i386. [04:41] cjwatson: Can't think of any corner cases that might blow up, but I also didn't feel the overwhelming desire to actually read all of mklibs. [07:31] infinity: ld_path_name == "/lib/" will never be true, as dirname doesn't return something with a trailing slash [07:33] (not foo == bar => foo != bar) [07:36] infinity: I know it was partly pre-existing, but testing os.access(dest_path + "/" + ld_file_name, os.F_OK) seems bizarre - why would the PI *basename* exist in dest_path? Should that be s/ld_file_name/ld_full_path/? [07:36] (OTOH maybe I'm missing something odd that mklibs does) [07:37] infinity: seems basically plausible though === jibel_ is now known as jibel [10:56] cjwatson: No, dest_path is lib/ Which seemed effin' wrong to me too, but that's how the code it written. [10:57] s/it/is/ [10:58] cjwatson: And point taken on ld_path_name not containing a trailing slash. Oops. [11:00] cjwatson: (dest_path being lib instead of root is why I then install to ../ld_full_path) [11:00] cjwatson: The whole this is just plain weird. [11:01] cjwatson: patch updated. [11:24] ubiquity: adconrad * r5108 trunk/ (3 files in 2 dirs): Fix the armhf symlinks to point to actual files [12:38] hmpf, seems my cia setup is broken, i just released ubiquity 2.9.7 [12:42] sigh and i'm missing 100MB of build deps ... [12:42] fun [12:43] * ogra_ twiddles thumbs waiting for them to install [13:13] ogra_: Are you testbuilding before you upload, after chastising me for wanting to do the same? :P [13:14] infinity, nope ... [13:14] So... You uploaded? [13:14] but i would appreciate if someone else could upload i dont get my chroot right here and dont want to waste another hour [13:14] Oh. I was just going to do an -nc upload. No refresh. [13:14] Cause I'm a filthy cheater. [13:15] it needs bout 100MB build deps to even roll a source package :/ [13:15] how about I just upload it, guys :) [13:15] and somehow thats still not working ... its so long ago that i built ubiquity that i have to check the docs ... grmbl [13:15] cjwatson, please do [13:16] also just changing the name in the changelog and not adding [ Colin Watson ] (e.g. as dch -r does) is a bit rude :) [13:16] ah, i was missing a debian/rules update [13:16] not that I vastly care [13:16] oops, sorry ... i didnt see a reference to infinity either (though he explained that above) [13:17] up to people to put themselves in the changelog if they want [13:17] right, it was just confusing [13:19] uploading now [13:20] bah, and now my chroot works :P [13:20] well, at least i have it ready for next time [13:20] and i know that armhf chroots work for building source packages :) [13:20] you don't need most of the build-deps to build the source package anyway [13:21] well, it complains and stops if i dont have some of the python bits [13:21] -d [13:21] (pyflakes etc) [13:21] oh, yeah, sure, but that's small [13:21] point is you don't need everything [13:21] i didnt feel brave enough to -d ... (i noticed the note indeed) [13:21] well, i have a proper chroot for next time ... so thats already good :) [13:22] you don't have to be brave; you can try it and then check that the debdiff looks right. [13:22] ^ [13:23] I think you should just need debhelper, dh-di, and pyflakes, maybe one or two other bits. certainly not most of the libraries. [13:23] Like I said, I was just going to do an -nc upload. But not if everyone else was falling over themselves to upload. :P [13:24] -nc is fine if you've done 'debian/rules update' and there were no Python changes, yes. [13:24] It's worth running 'make -C d-i check' though. [13:28] hmm, but xz is really bad on arm [13:29] even ctrl-c'in the xz creation took 5 mins until it got through ... [13:30] depressing [13:33] On which machine? [13:33] ac100 indeed [13:33] The ac100's 512M of RAM doesn't really make it shine. [13:33] in an armhf chroot [13:34] My phone has more. :/ [13:34] intrestingly compressing inside the hf chroot seems to be lots and lots heavier than unpacking under armel in the host rootfs [13:35] xz compression is a lot slower than decompression anyway [13:35] apparently [13:36] Fairly well-known. [13:36] (But, for a source package, I'd still rather take a couple of minutes longer and save the space.) [13:36] but i was hoping that hf improves it a bit [13:36] vs el [13:36] I would be surprised if it did any significant floating-point work. [13:36] yes, apparently it doesnt [13:36] Compression algorithms rarely do, although there's the odd exception. [15:51] In bug 901502 I see the following in syslog: [15:51] Launchpad bug 901502 in ubiquity "I booted into Lubuntu Installation rather than running installation from the live desktop. After inputting my user info and proceeding, the installer encountered an error." [Undecided,New] https://launchpad.net/bugs/901502 [15:51] Dec 7 20:19:58 ubuntu kernel: [ 28.072013] loop1: rw=0, want=13608534816, limit=1048576 [15:52] Dec 7 20:19:58 ubuntu kernel: [ 28.072021] EXT2-fs (loop1): error: ext2_free_branches: Read failure, inode=98360, block=1701066851 [15:52] Dec 7 20:19:58 ubuntu kernel: [ 28.072023] attempt to access beyond end of device [15:52] Is that indicative of media or memory issues? [18:44] cjwatson: I'm uploading my mangled mklibs as an ubuntu1 revision for now, so we can test it. Feel free to give it an eyeball or two and upload to Debian and sync over my changes. [21:41] Damn. I guess I should have tested my new mklibs with a full d-i build. [22:42] Oh, FFS. [22:42] *headdesk* [22:42] lrwxrwxrwx 1 adconrad adconrad 4 Oct 17 15:01 lib64 -> /lib [22:42] Thanks, whatever udeb unpacked that symlink. [22:46] :) [22:46] Apparently the concept of relative symlinks is a lost art. [22:46] * infinity fixes. [22:47] And, it's debhelper's fault? [22:47] debian/rootskel.links.amd64:lib lib64 [22:47] ^-- That's creating absolute links? Ick. [22:51] You know, I'm tempted to just take the links out of rootskel. I don't really need them anymore. [22:57] * infinity does so, and feels pretty good about the whole affair.