[00:00] What about rdeps? [00:00] I have a vague recollection of stuff breaking when we multiarched libxml2 in precise [00:01] Oh? [00:01] Stupid configure scripts and the like [00:01] rbuild-deps, you mean? Hrm. [00:01] The multiarching landed right after oneiric was released, and hasn't been changed (in precise) since, just security updates. [00:02] But maybe some rbuilddeps needed fixing. [00:02] Not even sure how best to check that. [00:02] oneiric-changes mbox grep? [00:02] s/oneiric/precise/ [00:02] google finds parser, pyabiword, gnustep-base [00:02] without trying too hard [00:03] I guess this points to "just revert skype in oneiric" for now, then. :/ [00:03] so that's an existence proof at least [00:03] This'll take a proper rdep analysis. [00:03] If we care. [00:03] I do kind of care [00:03] Or, if our partner agreement with Skype cares. [00:03] Well, I mean I care about not breaking buildability of oneiric [00:04] Right, no. I meant "if we care about upgrading Skype, we can look into this more". [00:04] We should absolutely revert it for now. [00:04] And not MA libxml2 without an rdep check. [00:05] Any chance somebody who can actually upload to partner could do that? :) [00:05] +- # Strip '-L/usr/lib' off since this is always in the link path. [00:05] +- XML_LIBS=`echo $XML_LIBS | sed -e 's|-L/usr/lib||'` [00:05] WCPGW [00:05] what's that from? [00:05] That was our gnustep-base patch. [00:06] People who think they're smarter than autoconf should have their eyebrows ritually shaved into funny patterns [00:06] And this is why my partner uploads, despite often being identical, aren't copied between releases... [00:06] To revert oneiric, I need to reupload >= precise. [00:07] Well, to revert it properly. [00:07] Will do both in a sec. [00:07] Personally I don't care that much about that ... [00:07] Well, oneiric needs to be done, but breaking the upgrade path is also wrong, so I'll do the other bit after. [00:08] Debian #643026 [00:08] Debian bug 643026 in libxml2 "please add multi-arch support for libxml2" [Normal,Fixed] http://bugs.debian.org/643026 [00:08] contains analysis of rdep .la pollution in Debian [00:14] cjwatson: That's an unfortunately large list. Worth examining later, if we want (or have an obligation) to update skype in oneiric, but I'll upload the revert ASAP. [00:16] slangasek: hopefully you have some idea of what our obligations are here ... [00:16] oneiric only has five months to run [00:20] Sadly, it's not just a plugin or something, the main binary is linked to it. [00:21] Then again, given that we're tearing apart a deb from upstream called "skype-precise.deb", I think their intentions were clear. :P [00:21] And it's probably sheer luck that it works on oneiric at all. [00:31] * infinity wonders why the replaces/breaks is getting revved on every version, but stays with the status quo for now. [00:39] cjwatson: oneiric and precise both uploaded, if you want to give them a look before accepting. [00:45] cjwatson: Actually, I'll accept them so they build, you can review when you come back before I copy. [01:08] infinity: LGTM as long as those [i386] build-deps are still sane in the reverted version (which presumably they are since it built). [01:08] I guess those are to calculate skype-bin shlibdeps. [01:13] tar: Skipping to next header [01:13] xzcat: gcc-4.7.2.tar.xz: Compressed data is corrupt [01:13] tar: Exiting with failure status due to previous errors [01:13] something is very wrong ... [01:13] It'd great if someone could binary New nepomuk-widgets. It's blocking builds we need to get done to get KDE 4.10 Beta 1 out. [01:25] rescored gcc-4-7 (was at -1). whoever did rescore this without mentioning it ... [01:27] ScottK, done. but just ping me directly if you see me online ;-P [01:27] doko: Will do. Thanks. [01:28] doko: I didn't do the rescore, but I think it was to let some of the other package builds get through first. [01:34] doko: On a Panda? [01:37] infinity, ain, schort, and something else, did give it back now three times [01:38] doko: Three different machines in a row seems a bit excessive... [01:39] Though working now, apparently. [01:39] let's see, the first one died after 36min [01:39] Oh, not with that erorr, then. [01:39] but my local build is going on for 2h [01:40] doko: I'm the one who rescored gcc on powerpc, unless this absolutely needs to be in the release pocket today... [01:40] doko: I figured blocking one of the two buildds for hours might be unpleasant while there's a backlog. [01:41] ahh, maybe. however I think we should then decide on dropping powerpc or getting decent resource [01:41] s [01:41] There's one that's temporarily dead. [01:41] doko: We have decent resources, someone just killed a machine today. [01:41] Or yesterday, rather. [01:42] Can we not knee-jerk a "we should drop an arch" every time we have a short backlog? :P [01:42] ScottK, there was one which was temporarily alive ,-P [01:42] Next time there's a KDE langpack upload, we should drop i386. [01:42] infinity: do you simply upload eglibc, or is there some magic repository I am missing? [01:42] doko: It was alive for quite a while [01:43] xnox: There's not magic repo right now, since I rebased with Debian and haven't pushed my SVN anywhere useful (cause that was going to turn into git at some point)... [01:43] xnox: s/not/no/ [01:43] xnox: You looking for something specific? The debdiff between us and Debian is actually readable now. [01:43] infinity: ack. after checking the usual places. No, just want to fix something ubuntu specific =) [01:43] doko: It just didn't get fixed today because we're temporarily down a UK DCE so nobody could go and look at it. [01:43] cjwatson, heh, come on, it's 3am [01:44] well 2am in London =) [01:44] * xnox wonders if there are night buses from my place in the general direction of the dc =) [02:28] * infinity sighs about forgetting to --auto-approve those copies. === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik [10:41] could some archive admin review that asap please ^^^^ ? [10:42] (image build starts at 13:32 UTC, would be great if it could make that) [10:48] ogra_: You could just delete debian/ubuntu-defaults-nexus7.{post,pre}inst [10:48] ogra_: Hm, the Depends line looks wrong [10:49] Depends: ${misc:Depends}, locales [10:49] ${ubuntudefaults:Depends} [10:49] Shouldn't the first line there end with a comma? Otherwise I think ${ubuntudefaults:Depends} will be lost [10:49] well, i wasnt sure the defaults builder doesnt need the DH entires in the pre/postinst [10:49] hmm, [10:49] debhelper automatically creates maintainer scripts if it needs to [10:50] * ogra_ drops [10:50] a skeleton like that is strictly redundant [10:51] please reject then, i have a new upload ready [10:51] Just upload with a new version number [10:51] What's hooks/chroot for? Seems to be basically empty [10:52] (FWIW the apparently wrong Depends is the only thing I've seen so far that *needs* to be fixed - the rest are cosmetic) [10:54] no idea, i didnt make that package, achiang just took a general skeleton package for ubuntu-defaults-builder i think, i guess we can clean up the uneeded stuff === mmrazik is now known as mmrazik|lunch [11:02] argh, the last upload had all bzr stuff in it [11:03] * ogra_ properly removes it [11:04] I'm obviously misunderstanding something rather fundamental about xinput coordinate transformation matrices; I can't work out why the left and right rotations given don't matrix-multiply to produce the identity [11:04] heh, ask bryan :) [11:05] thats his stuff, i find it confusing too [11:05] I assume the way translations are stuffed into an affine transformation is what's confusing me [11:05] it's been 15 years since I did the underlying maths :) [11:05] especially since if you use a mouse, both input devices are completely inverted from a cursor POV, but still both work (the cursor behaves very odd though) [11:06] anyway, I'm fine with this once Depends are fixed [11:06] yeah, i made some bzr mess i'm trying to fix atm [11:09] cjwatson, 0.33 uploaded with the fixes, please ignore the bzr noise (0.32 had the whole tree) [11:12] lgtm, thanks [11:17] * cjwatson stares at gmp. You built everywhere only three weeks ago === mmrazik|lunch is now known as mmrazik [12:03] stgraber, are you still the one to poke for an isotracker entry (if so, i would like to see ubuntu-desktop armhf+nexus7) [12:03] (no hurry) === agateau_ is now known as agateau [13:03] * cjwatson enables -proposed for precise builds [13:40] ogra-cb_: yep. I'll add it with the same tests as a desktop image for now (or something similar). balloons can then tweak that [13:44] stgraber: well, can you just add it the way AC100 preinstalled test is? [13:44] stgraber: nah, that one is bad as well =( [13:44] * xnox <---- ignore [13:45] xnox: ac100 is lubuntu [13:46] stgraber: well, it's the only 'preinstalled' test we currently have. As on nexus7 there is no "automatic, manual, oem partitioning" [13:46] xnox: right, but I believe we have those tests split into testsuites now so I should be able to only have the post-install ones, then someone can write some for the flashing part + oem-config (once we have it) and we can link that [13:47] \0/ awesome, you rock [14:04] OK, these precise builds might be a bit messed up, I'm going to do another pass in a bit [14:04] In the middle of enablement kernel / SB backports [14:18] ogra-cb_: it's added, currently with the same testsuite as the ac100 as our testsuites aren't as well split as I thought they were. I'm sure balloons will fix that :) [14:18] ogra-cb_: I'm running a test build now to confirm that they auto-publish fine [14:18] ogra_: Damn, I forgot to accept the binaries [14:18] sorry [14:22] cjwatson, yeah, no biggie, tell me when they are promoted an i can trigger a new build [14:22] * ogra-cb_ guesses in 1h should be safe [14:22] Oh, they need to be in main do they? [14:23] nope [14:23] Oh, you mean migrated to release [14:23] nexus7 builds from universe as the ac100 does [14:23] yeah [14:23] "findable by live-build" :) === seb128_ is now known as seb128 [14:24] Should publish to -proposed at 14:33 UTC and if you're lucky be copied in time for the 15:03 run [14:24] yeah so 1h should be relatively safe ... [14:24] or a bit above 1h [14:25] I'll keep an eye on it [14:25] ogra-cb_: alright, auto-publish worked fine so you should be good to go [14:26] ignore that server image build failure; I c-ced it because I'd forgotten to deploy code first [14:26] stgraber, thanks a lot ! [14:55] cjwatson: TTBOMK we have no obligation to make the new skype available for oneiric; if it's going to be a chore, I'd just leave it as-is [14:56] wfm [15:27] ogra-cb_: it's available for cdimage builds now [15:28] yay [15:28] * ogra-cb_ fires off a build then [16:37] Is there anybody in the SRU team who can help publish three im-switch SRUs related to bug 875435? [16:37] Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress] https://launchpad.net/bugs/875435 [17:17] stgraber: Would you mind seeing if the current batch of precise desktop/alternate/server (whatever you have time for) images boot at all under SB? It probably isn't worth spending time test-installing just yet, since I haven't finished smoke-testing the installer even normally. [17:19] cjwatson: yep, I can test them after lunch (will start the download now) [17:20] cjwatson: alternates are red in jenkins https://jenkins.qa.ubuntu.com/view/Precise/view/ISO%20Testing%20Dashboard/ [17:20] 20121123 is green, all later respins red. [17:20] although it could be just jenkins / test problem === didrocks1 is now known as didrocks [17:22] Thanks, looking [17:23] Not obvious from the log ... it just stops in the middle of installing packages [17:24] I'm doing manual smoke-testing so I'll see how it looks [17:29] last precise-alternate (.3) stopped in the middle of installation because it timed out after 40 min [17:30] timed out? hmm [17:30] OK, I'll have to investigate that manually [17:31] well, s/timeout/the job is killed if installation is not finished in less than 40 min/ [17:32] oh, so it might just have been slow? [17:33] indeed, it seems to be actively doing stuff 40 minutes after it starts [17:33] yes, but nothing obvious. I restarted it, we'll see. If it fails again, I'll have a look at the server. [17:33] i do wonder about the timeout and the VM server load, cause the raring-desktop-utah-smoke jobs also loose connection and are failed. [17:36] Trying to see if any one step is taking particularly long [17:39] xnox, I don't think it's related, jobs were running at different times, on differents hosts and testing different images [17:40] jibel: ok. i need to learn how to check where the jobs were run on the private instance. [17:41] Base system installation takes 10 mins vs. 3, and pkgsel dramatically slower [17:41] I wonder if this is some kind of I/O regression in the kernel [17:42] I'd compare with quantal alternates except there aren't any [17:44] Generating locales seems about the same speed either way [17:45] xnox, ah right, it is not easily accessible on the public instance. On the public instance, you'll find this information at the beginning of console output 'Building remotely on XXXX'. [17:45] thanks. [17:45] On the private instance, go to the detail of the run and it's displayed at the top right of the page. [17:48] Comparable steps in quantal server amd64 default on 23 Oct were about as fast as earlier precise, but the run on 6 Nov was slow [17:48] In fact it timed out [17:49] Likewise 1 Nov [17:51] And yet - same kernel [17:52] jibel: Is there any parallelisation going on here? [17:53] Hmm, in fact these two runs were allegedly testing the same CD image [17:53] * cjwatson strips timestamps and diffs [17:55] Some differences in KVM-related output - was the host system changed? [18:00] Ah, this one timed out a lot talking to us.archive, which confuses matters [18:01] And the next run succeeded [18:02] Really rather inclined to blame the host system here. [18:04] yeah and the current .3 also succeeded on the rerun. [18:05] jibel: is there no intercepting proxy to a local mirror? (UDS style, you think you talk to us.archive.ubuntu.com, but actually it's a really fast local mirror instead) [18:07] xnox: The diff between the failed and successful precise-alternate-amd64-default runs shows only trivial differences in download times [18:07] So I think that's a red herring [18:07] hm. [18:07] I like this: http://jenkins.qalab:8080/view/Precise/view/ISO%20Testing/job/precise-alternate-amd64_static_validation/116/console [18:07] *sigh* [18:07] one sec [18:08] jibel: static_validation jobs are not pushed to public? [18:08] anyway it run static checks on the ISO, and asserts over-sized image. (and checks a few other sanity bits as well) [18:30] xnox: static validation tests for precise are published [18:30] xnox: https://jenkins.qa.ubuntu.com/view/Precise/view/All%20Precise/job/precise-alternate-amd64_static_validation/ [18:33] hmm... ok, it's just they are not in this view https://jenkins.qa.ubuntu.com/view/Precise/view/ISO%20Testing%20Dashboard/ [18:33] thanks. [18:35] sigh, my nexus images are still to big, i already dropped libO and TB [18:35] * ogra-cb wonders what else he coudl drop [18:36] How big do they need to be? [18:37] the sparse image file needs to be around 680M [18:37] Oh. Heavens. Good luck with that. :/ [18:37] make_ext2fs adds about 100M for the inodes to the tarball size [18:37] so my rarball needs to be 530M [18:37] Oh, wait. The sparse one being the thing with the tarball in it? [18:38] yes [18:38] I'd say the bug here is in make_ext2fs, surely. [18:38] bug ? [18:38] its a limitation of fastboot [18:38] the image gets written to the state partition on the device, that limits the image size [18:39] from there it gets flashed to the actual target partition [18:39] Well, yes, but why does it need to be ext2, and why does it need to be sparse with a ton of useless extra inodes? [18:39] its an ext4 [18:39] Or that. Even worse. [18:39] It definitely doesn't need a journal. :P [18:39] dont ask me why the file format needs to be like it is, i have no source for the bootloaer [18:40] i would have preferred to format the partition from the initrd, but that doesnt work, the bootloader contains a GPT somewhere ... hardcoded [18:40] and normal fs operations dont work on the partitions [18:41] the only working filesystem is the one you pre-create with make_ext2fs and flash via fastboot [18:41] else you get a filesystem that quickly starts eating itself and in the end you end up with an endless reboot loop [18:43] fastboot itself has a way to flash the file in chunks, but that sadly is very unreliable and often makes you end up with an unbootable rootfs partition [18:45] Anyhow, you could temporarily drop all the ^hp* and ^printer-driver* stuff? [18:46] But trying to think of a more elegant solution to the tiny image problem might be nice. [18:47] can't you do some trick like only including a kernel/initrd/minimal system in the image you flash, partition/format from there, then transfer the rest from the machine you're flashing it from (using usb mass storage or some network trick)? [18:47] * stgraber is planning on supporting the nexus7 for Edubuntu but our base image is > 2GB, so there's no way 680MB will work for us :) [18:48] anyway, time to reboot to test precise alternate amd64 on secureboot... [18:49] infinity, well, i could use a tar.bz2 and lose rsyncability of the image [18:49] ogra-cb: Oh, but your rootfs contains a tarball still. You could make that a tar.xz instead. [18:49] ogra-cb: I bet that buys you about 20%. [18:49] or xz [18:49] yeah [18:50] it means changes to live-build and debian-cd though [18:50] Only live-build, surely. [18:50] cjwatson: alternate amd64 won't boot. Checking why now. [18:50] Since by the time it gets to cdimage, it's wrapped up in an .img that we don't look at. [18:50] * ogra-cb remembers how hard it was to teach debian-cd about the combo of bootimg and tar.gz for ac100 [18:50] Or an .ext4 in this case. [18:51] tight [18:51] cjwatson: Talking to yourself? :) From: Colin Watson err right [18:51] well, the other obstacle is that xz needs to be in the initrd for unpacking [18:51] that only works if it doesnt pull in a million deps [18:51] LB_COMPRESSION already supports xz, so no live-build changes. [18:52] Just a livecd-rootfs twiddle. [18:52] oh, sweet ! [18:52] (base)adconrad@cthulhu:~/build/live/live-build-3.0~a57$ ldd /usr/bin/unxz [18:52] linux-vdso.so.1 => (0x00007fff7b1f4000) [18:52] liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f708616e000) [18:52] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7085dab000) [18:52] libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7085ba6000) [18:52] /lib64/ld-linux-x86-64.so.2 (0x00007f70863ab000) [18:53] ah, should be doable i guess [18:53] About 200K between xz and liblzma.so.5.0.0 [18:53] Ish. [18:54] cjwatson: that's weird, I can't spot anything obviously wrong. Running under qemu in EFI mode, I'm getting into grub minimal, so something may be wrong in the grub.cfg lookup but that doesn't explain why it just plain won't boot on my machine. Investigating some more... [18:55] infinity, any idea about rsync/zsync capabilities of xz files ? [18:56] we just stick to gz because of that iirc [18:59] Are we actually using rsyncable gzip anyway? [18:59] debian-cd does [18:59] I don't even see mention of --rsyncable in gzip(1) anymore. Did the patch get dropped? [18:59] i havent checked what live-build uses actually [18:59] live-build just calls gzip. [18:59] heh [19:00] Which also means it's using -6 and not -9 [19:00] so i dont have rsyncability anyway [19:00] hmpf, that sounds liek waste [19:00] *like [19:00] Grab your tarball and 'gunzip foo.tar.gz && gzip -9 foo.tar' and see if it shrinks. [19:01] $ gzip --help | grep rsync [19:01] --rsyncable Make rsync-friendly archive [19:01] xnox: Ahh, so the manpage patch got lost. Weird. [19:01] info gzip has it though [19:01] xz claims to produce random output [19:01] but not tested if that is in fact true from run to run. [19:02] xz shouldn't be particularly rsyncable, no. [19:03] cjwatson: tried another media, still won't boot with or without SB, so something must be confusing the firmware (I'm booting from a USB stick). Trying with raring now to confirm that the testing procedure is correct and that something is somehow different on the image. [19:06] http://paste.ubuntu.com/1380182/ [19:07] ^-- xz definitely saves some space, but build time will go through the roof. Compressing the tarball is already a large chunk of the build. [19:11] Some fraction of packages built on ain (not all though) are ending up in chroot wait. [19:11] Maybe all now though. [19:11] infinity: ^^^ [19:12] ScottK: Fixing. [19:12] Thanks. [19:12] I'll go ahead and retry the relevant packages. [19:12] ScottK: I'm on that too. [19:13] OK. [19:13] I won't then. [19:16] infinity, intresting ! i wouldnt have expected that --rsycable actually compresses more than plain -9 [19:18] so if we actually could move -6 to -9 --rsyncable it might already save enough [19:18] cjwatson: so, raring server boots fine both with and without secureboot. Trying precise server to check that it behaves like the alternate. [19:18] ogra-cb: rsyncable beating -9 is almost certainly a fluke with this particular stream of data. [19:18] hmm, k [19:19] * ogra-cb isnt really thrilled by raising boottime [19:20] i suspect bzip2 might be mildly less demanding [19:20] bzip2 is pretty vile for decompression, actually. [19:23] ogra-cb: http://paste.ubuntu.com/1380212/ [19:23] urgh [19:24] ogra-cb: I don't see bzip2 being a win really. For ratio and decompression, xz is the clear winner, it's just that it kills build times. [19:24] And isn't rsyncable. [19:24] i dont care about the latter [19:24] (But neither is bz2) [19:24] given our img contant is a tarball built with -6 [19:24] *content [19:25] Well, it wouldn't be if we changed this. :P [19:25] There's also the possibility of me tearing all this apart, making rootfses export as uncompressed tarballs, and doing the compression on nusakan. [19:26] But that's a bit of a step backward from my goal of eventuall having images entirely created on buildds. [19:26] well, that would mean you do the post processing there as well [19:26] (Which is actually true for the tarball ones) [19:26] right [19:27] and i really like the fact that the img creation can even happen there too [19:27] cjwatson: alright, so final result is: raring server amd64 => boots, precise * amd64 => won't boot [19:27] cjwatson: all tests done with and without secureboot on uefi [19:27] stgraber: That's not encouraging. [19:27] * ogra-cb wouldnt want to have to backport updates of android-tools-fsutils to nusakan all the time there aare fixes [19:28] ogra-cb: Oh, right, cause the tarball is inside the stupid ext4 image. Grr. [19:28] yeah [19:28] ogra-cb: Yeah, forget that idea, then. [19:28] infinity: yeah... and the /EFI directory is quite clearly correct when comparing the images, so my guess is on some header/xoriso related magic [19:28] well, technically its possible to do it in cdimage [19:28] infinity: it might be that if I was to boot from an actual cdrom it'd work, it's just that I don't have a cdrom drive so can only test with usb sticks :) [19:28] ogra-cb: Well, it's probably the right thing to do regardless to flip on -9 for gzip in live-build, but I doubt it'll buy us much. [19:28] its just so much more people involved [19:29] stgraber: Given that our targets are USB, CD, and DVD, I'd say "doesn't work from USB" is a bit of an issue. [19:30] cjwatson, infinity: checking some more, there's one clear difference. fdisk/parted report a GPT partition table and an EFI partition on the raring images but not on precise [19:30] ogra-cb: Maybe I should grab the actual tarball in question there instead of core, and do some tests on a Panda to see about compression time and such. [19:31] (well, parted is pretty much useless on those weird partition table, but fdisk definitely shows a different structure between precise and raring) [19:31] i can live with another 30min added ... but not with something like 2h [19:32] hmm, i cant run simg2img on the current image [19:33] ogra-cb: Grabbing the current image to do some Panda abuse. [19:34] (Is it actually gzipped, or is that debian-cd accidentally renaming it?) [19:34] infinity, i fear you need to grab the tarball from the builder, i have massive probs converting it here [19:35] the .gz comes from debian-cd [19:35] the .img is make_ext2fs and needs to be converted back using simg2img [19:35] which prints for meL [19:35] error: file_write: write: File too large [19:36] ogra@chromebook:/media/ogra/b62274f4-1646-4cc6-9aea-5226914074bb/ogra$ ls -l raring-preinstalled-desktop-armhf+nexus7.img-out [19:36] -rw-r--r-- 1 root root 6442450944 Nov 23 20:34 raring-preinstalled-desktop-armhf+nexus7.img-out [19:36] so i suspect thats our actual size limit [19:37] Oh, it's not actually an ext4 filesystem, but some goofy container format? [19:37] I was assuming I could just mount it. [19:37] no, you need to convert it, it has everythong an ext4 has [19:38] but the unused metadata is compressed if i understand it right [19:38] after you converted it with simg2img you can just mount it as ext4 [19:39] aha, despite the moaning, simg2img actually works [19:40] simg2img raring-preinstalled-desktop-armhf+nexus7.img raring-preinstalled-desktop-armhf+nexus7.img-out [19:40] sudo mount -o loop raring-preinstalled-desktop-armhf+nexus7.img-out /mnt [19:40] ogra@chromebook:/media/ogra/b62274f4-1646-4cc6-9aea-5226914074bb/ogra$ ls /mnt/ [19:40] rootfs.tar.gz [19:41] I'll get there eventually. [19:41] Doing this on a Panda wasn't smart. [19:41] oh, yeah [19:42] Also, wait, what? [19:42] My .img is 700597824, how did yours SHRINK when unsparsing it? [19:42] heh [19:42] Oh, I'm missing a digit. [19:42] i fell into the same trap [19:42] yeah [19:42] La la la. [19:43] well, i did the same, thats why i thought simg2img would be broken [19:43] What package is simg2img in? [19:43] android-tools-fsutils [19:43] * infinity does this part on his laptop. [19:43] yeah [19:44] the chromebook copes fine here btw :) [19:45] For some value of "fine". [19:45] heh, reading the ubuntu-users ML is like doing timewarps all the time [19:45] "ubuntu dropped non-PAE kernels OMG !!!111one" [19:45] Welcome to Quantal? [19:46] yeah [19:46] I dunno, I was pretty miffed when Ubuntu dropped 486 and 586 support. [19:46] Now, I've given up caring. [19:46] its funny, you often get the same discussions on -devel and -users ... just with a year delay [19:47] and on -users everything is so much more fatal :) [19:53] ogra-cb: Wow, I wish you hadn't suckered me into reading that. [19:53] ogra-cb: I really liked the "will precise get firefox 17?!" thread within minutes of the upstream announcement. [19:53] lol [19:53] yeah [19:54] * stgraber is glad he's not subscribed to -users [19:54] its reallly entertaining at times [19:54] -devel-discuss is already enough entertainment for me ;) [19:54] heh [19:58] oh shriek [19:58] http://linuxo.com/content/how-install-ubuntu-1210-non-pae-cpu [20:00] I can't quite sort out why an LTS isn't good enough for people with old hardware. [20:01] well, i cant quite make out why people come up with such weird howtos [20:01] cd /cdrom [20:01] sudo dpkg --root=/target -i *.deb [20:01] Some warnings will be displayed when running the above command: [20:01] ...ignore these warnings ... [20:02] cjwatson, the timeouts occur more frequently since beginning of November, and seems to affect a specific system which has been reinstalled on Oct. 24. [20:03] I'll notify our sysadmins and will increase the timeout on this slave until he figures what is wrong. [20:03] ogra-cb: Ignoring dpkg errors is always sane and reasonable! [20:04] ogra-cb: I'm a bit more disturbed by the bzr branch hosting deb binaries, rather than a PPA building the sources in an auditable fashion. [20:05] ogra-cb: Maybe I'm paranoid, but I'd have serious trust issues there. [20:07] wow, and people have to use a bzr branch to keep up to date with security updates, wow [20:22] 595792585 Nov 23 18:11 rootfs.tar.gz [20:22] 347673980 Nov 23 21:20 rootfs.tar.xz [20:23] 250M ! [20:26] root@chromebook:/mnt# time xz -z -c rootfs.tar >/home/ogra/Desktop/rootfs.tar.xz [20:26] real 24m54.916s [20:26] root@chromebook:/mnt# time gzip -c rootfs.tar >/home/ogra/Desktop/rootfs.tar.gz [20:26] real 4m17.067s [20:26] hmm [20:28] i could surely live with 20min added to the build time ... but i fear the panda will be a lot worse === yofel_ is now known as yofel [21:41] ogra-cb: Yeah, my xz test isn't going so well here. Still running. [21:41] ogra-cb: Also, going from gzip to gzip -9 --rsyncable bumped it up from 8m to 24m. [21:42] ogra-cb: Though, that did save a ton of space. [21:42] Oh, crap. No. [21:42] * infinity gets to redo this all over again. [21:42] Was overwriting my .9.rsync with the xz test. [21:54]