[00:06] seb128: I don't have GTK_IM_MODULE set anymore; the default GTK IM became less inadequate [00:06] (and if that caused the display of text to be completely changed, someone should be thwapped :) [00:06] slangasek, ok, so I don't know why some people get it and some don't [00:06] yeah, dunno [00:18] * ogra hugs popey for his eternal patience with karl f. larsen [00:18] haha [00:18] Where can I spectate? [00:20] Caesar, ubuntu-users ML [00:21] * bigon is wondering is upload that fix #516359 could not also contains fixes for #497497 and #472444 [00:21] https://lists.ubuntu.com/archives/ubuntu-users/2010-February/209987.html is worth a read [00:21] and after that thread (but only after) https://lists.ubuntu.com/archives/ubuntu-users/2010-February/210545.html [00:22] hehe [00:23] *g* [00:23] i had missed that first one [00:23] he's calmed down a lot [00:23] karl is my best entertainment on that list, without him i would probably have unsubbed a year ago ... [00:23] sadly he caused so much damage [00:24] indeed [00:24] but yes, its a lot better recently [00:24] he's on moderation [00:24] the only person who is [00:24] Was he that guy at UDS? [00:24] the fun thing is that re is really rarely offending to anyone [00:24] yeah, he's calmed down enough to come off mod i reckon [00:24] but he manages to get perople so far over the edge that *they* get offending [00:24] yeah, vicious circle [00:25] watching him is like a psychological study of masses [00:25] Lucid: now with stubble [00:25] that could be said of vast swathes of the ubuntu community [00:26] yeah, indeed, but karl is really special [00:26] he's what 75 years old or something? [00:26] resistent to any learning ... [00:26] yeah [00:26] behaving like 12 or so :) [00:26] we have a cantankerous old git in our local Linux User Group, he's much the same, but much less gun-ho [00:26] he hates ubuntu too :) [00:26] heh [00:26] karl loves it i think [00:27] i stuck an ubuntu sticker on the underside of his debian laptop once.. he went mental [00:27] lol [00:27] lovely guy, we do love to wind eachother up now and then [00:28] * ogra will print "Karl F. Larsen Groupie" t-shirts and hand them out at uds ! [00:28] to all ML mods :) [00:28] heh [00:29] * kees heads head on desk. [00:29] every time I get dmsetup export support into Debian, they rip it back out since it is "unused". [00:30] hmm? [00:42] pitti: this is not a 1 day task, I'm about 1/4 of the way done with the devmapper+lvm2 merge, just so you don't duplicate work and start it too. [00:53] Amaranth: that user in the flash bug has been problematic [00:53] Yeah, I can see that :) [00:53] Amaranth: I'm talking to LP admins about it now [01:12] Amaranth: fyi. I've sent a polite please don't "send as" email; a call from a vaguely irrelevant authority has worked in the past; so hopefully will this time. we shall see. === jcastro_ is now known as jcastro === jamesh_ is now known as jamesh === persia` is now known as persia === dmb is now known as d === d is now known as ______dmb [03:55] Hi, I'm working on fixing bug #520240. This is my first ever attempt at a patch for Ubuntu/Debian. I updated the rules and added the file that I needed to add, however when I run debuild -us -uc to build the package I get the following lintian error. Now running lintian... [03:55] E: libapache2-mod-authz-unixgroup: duplicate-conffile /etc/apache2/mods-available/authz_unixgroup.load [03:55] Finished running lintian. How can I fix this? [03:55] Launchpad bug 520240 in libapache2-mod-authz-unixgroup "Does not install create /etc/apache2/mods-avaiable/authz_unixgroup.load file" [Undecided,New] https://launchpad.net/bugs/520240 [03:56] spenser: #ubuntu-motu might be more appropriate [03:56] ohh ok thank you [04:51] !ops [07:42] Good morning [07:42] kees: right, understood; thanks so much for taking care of it! [07:59] good morning === tkamppeter_ is now known as tkamppeter [08:36] mvo, hi [08:36] hey tkamppeter [08:37] mvo, I have changed and uploaded HPLIP [08:37] tkamppeter: ok, I will upload update-notifier, lets see if it works then [08:38] Here is the debdiff of HPLIP, so that you do not need to wait for the upload to finish processing: http://pastebin.ubuntu.com/373777/ [08:48] E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle. [08:48] known? [08:49] oh, bug #516727, sorry for the noise [08:49] Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Confirmed] https://launchpad.net/bugs/516727 [08:49] mvo, you can try with the debdiff (http://pastebin.ubuntu.com/373777/) for the case the HPLIP package is not yet ready for yyou to download. [08:50] mvo, please tell me when you have uploaded update-notifier, then I can try with a real printer. [08:51] siretart: *grumpf* again? we had that in every release I think :( [08:51] siretart: thanks, do you have this bug? if so, can you attach /var/lib/apt/dpkg/status and your /etc/apt/sources.list (or mail it to me)? [08:52] mvo: I've just removed openoffice.org-filter-binfilter and am just doing a dist-upgrade [08:52] as for sources.list, plain lucid + some ppas (motumedia + chromium) [08:52] siretart: aha, so its lucid->lucid? [08:52] yes [08:53] ok [08:53] I'm not dist-upgrading that often, every few weeks or so [09:45] cjwatson: are you still working on the gnu-efi merge (bug 488797), or is it okay to sponsor? [09:45] Launchpad bug 488797 in gnu-efi "Please merge gnu-efi 3.0i-2(main) from debian squeeze(main)" [Undecided,Confirmed] https://launchpad.net/bugs/488797 [10:35] Hi, pitti. As far as I know, you are one of the developers of the dist-utils-extra package; correct? If so, could you please have a look at this: https://answers.edge.launchpad.net/python-distutils-extra/+question/100558 Thanks in advance. [10:36] frafu: will have a look [10:36] thanks [10:39] ev: just for clarification, 20100211 doesn't work either [10:42] frafu: answered [10:42] pitti: thanks [10:49] Keybuk: indeed, I've fixed the problem in casper and have just been waiting for ftpmaster to catch up so I can build new CDs [10:50] sweet [10:58] pitti: I'm almost ready with lvm2. [11:00] Keybuk: upstream debian chopped up their udev rules for devmapper and lvm2. I'll need to revisit doing Hardy->Lucid upgrades, but for the moment, things look to be correct, even if it results in 3 udev rules files in lvm2 and 2 in dmsetup. [11:00] kees: I didn't think we used upstream or Debian rules? [11:00] * Keybuk is pretty sure he wrote the rules in our package [11:01] Keybuk: we used upstreams, but heavily heavily modified them. while walking them trying to find differences, I've mostly convinced myself they're sane now. [11:01] Keybuk: the only "new" one is the "trigger vgchange" file. [11:02] Keybuk: I'm going to upload this to a PPA first; I don't want to break the world, and there is a ton of changes in it. [11:03] Keybuk: changelog looks like this so far: http://paste.ubuntu.com/373861/ [11:03] have you checked the rules against those shipped in the udev packages? [11:04] kees: looks sane [11:05] Keybuk: afaict, udev doesn't ship anything for dm devices (including lvm). [11:05] rules/packages/64-device-mapper.rules [11:05] while Debian's rules are somewhat differently arranged, it seems that the bugs we've been fixing with our rules were being fixed by them as well. [11:05] rules/suse/64-device-mapper.rules [11:06] cause it'd be worth updating udev with new rules if they're much different [11:06] kees: is every case of "undefined reference to `__stack_chk_fail'" valid to add "-fno-stack-protector" or do I need to do more checks? [11:06] -rw-r--r-- root/root 2643 2010-02-10 15:36 ./lib/udev/rules.d/55-dm.rules [11:06] -rw-r--r-- root/root 767 2010-02-10 17:14 ./lib/udev/rules.d/60-persistent-storage-dm.rules [11:06] kees: in the source package, not installed [11:07] geser: the reverse. any time you find "undefined reference to `__stack_chk_fail'", you should find out why the linker is bad. :) [11:07] Keybuk: ah, well, one thing at a time. :) [11:07] kees: "while you're in there" :p [11:07] -rw-r--r-- root/root 509 2010-02-10 15:36 ./lib/udev/rules.d/60-persistent-storage-lvm.rules [11:07] -rw-r--r-- root/root 272 2010-02-10 17:40 ./lib/udev/rules.d/85-lvm2.rules [11:07] -rw-r--r-- root/root 550 2010-02-10 17:41 ./lib/udev/rules.d/56-lvm.rules [11:07] these are the ones I'm curious about [11:08] our 85-lvm2.rules is the new one [11:08] that's the one that runs vgscan/vgchange no? [11:08] well, "new" in that it's the watershed/vgchange hammer [11:08] but they renamed their rules from lvm2 to lvm [11:08] I figured I'd just keep ours as 85-lvm2.rules for sanity [11:08] it should probably be called 85-lvm-auto.rules or something [11:09] possibly [11:09] geser: sometimes it's a sign that you're linking with "ld" instead of "gcc" [11:09] kees: I was looking at http://launchpadlibrarian.net/38115510/buildlog_ubuntu-lucid-i386.mknbi_1.4.4-2_FAILEDTOBUILD.txt.gz [11:10] geser: ld -N -Ttext 0x92800 -e _start --oformat binary -o first32@0x92800.linux start32@0x92800.o first32.o memsizes.o printf.o string.o [11:10] swap ld with gcc for now [11:10] if you can [11:10] kees: does it make a difference that gcc is called with -ffreestanding? [11:10] geser: otherwise, build the .o files with -nostdlib [11:11] geser: it should yes, as freestanding uses nostdlib, iirc [11:13] kees: in this case building the .o files with -nostdlib would be the right fix, correct? [11:14] geser: yeah, I think that would work. [11:14] thanks, will try out if this fixes the FTBFS [11:14] geser: it's likely a bug that it stackprotector should be disabled when -ffreestanding exists [11:22] Keybuk, bug 520028 ... shouldnt there be a stronger dependency on dbus from upstart (if thats really at fault here) [11:22] Launchpad bug 520028 in project-rootstock "ubuntu-minimal doesn't build correctly for karmic" [Undecided,New] https://launchpad.net/bugs/520028 [11:22] "stronger dependency" ? [11:22] you mean like PRE-DEPENDS [11:23] wing-commander scott% dpkg -s upstart | grep dbus [11:23] Pre-Depends: libc6 (>= 2.4), libdbus-1-3 (>= 1.2.16), libnih-dbus1 (>= 1.0.0), libnih1 (>= 1.0.0), libudev0 (>= 147), sysvinit-utils, sysv-rc, initscripts, mountall [11:25] Keybuk, libdbus-1-3 only recommends dbus [11:26] and apparently that guy has a prob if dbus isnt installed (which doesnt happen with plain debootstrap) [11:26] cjwatson: My shell foo is failing me, can "run this, and then this, and if either one of them is successful, run this other thing" be expressed? [11:28] ogra: upstart doesn't depend on dbus (the daemon) though [11:28] Keybuk, if the daemon is essential for booting i think it should be either pulled in by debootstrap or by upstart [11:28] it's not essential for booting [11:29] the fact you can install ubuntu-minimal with debootstrap and go is a good sign here [11:29] it means that whatever he's using (which is not debootstrap, the bug is on something called "project-rootstock") is failing to build a correct image [11:29] rootstock is a wrapper to debootsrap [11:30] (and a bit more) [11:31] the deps are correct, anyway [11:31] upstart pre-depends libdbus [11:31] libdbus recommends dbus [11:31] the dbus daemon is not a requirement, but is present in all but unusual situations [11:31] which is the correct meaning [11:31] define an unusal situation :) [11:31] stripped down installs [11:31] embedded platforms [11:32] highly focused specialised things [11:32] if he just runs debootstrap (which he essentially did) then dbus is apparently missing [11:32] sure [11:32] nothing wrong with that [11:32] i would expect debootstrap to create a basic functional system [11:33] it does [11:34] ogra@osiris:~/Devel/branches/project-rootstock$ sudo chroot /var/build/lucid-arm-chroot/ dpkg -l dbus|grep ^ii [11:34] ogra@osiris:~/Devel/branches/project-rootstock$ [11:34] you know what [11:34] why do you bother asking me things? [11:34] you never listen to my answers [11:34] I've said four times that you don't need the dbus daemon [11:34] and yet you continue to ignore me [11:34] ok, sorry [11:35] I'll explain it one more time [11:35] Upstart uses peer-to-peer D-Bus [11:35] no, its ok [11:36] when you want to talk to Upstart, you open an AF_UNIX socket and connect to @/com/ubuntu/upstart [11:36] the protocol you talk is the D-Bus protocol [11:36] as implemented by libdbus [11:36] but there is no bus daemon involved [11:36] the thing listening on that socket is init itself [11:36] this means that the D-Bus daemon (in the dbus package) is not required [11:36] you *can* also use the D-Bus daemon if you prefer [11:36] if it's running, Upstart will connect to it [11:36] and then you can use libdbus to open a bus connection (to the system bus) [11:36] and address messages to com.ubuntu.Upstart on that [11:37] and reach the init daemon [11:37] the advantage of doing this is that since the bus daemon is an intermediary, you can do this as non-root [11:37] the bus daemon security policy permits read-only queries [11:37] this is why "status", "initctl list", etc. all work as normal users [11:37] but "stop", "start", etc. don't [11:37] so [11:37] while you need libdbus [11:37] you do not *need* dbus [11:38] and since the entire boot is done as root, nothing will try and use it anyway [11:38] right, understood [11:38] mountall uses this peer-to-peer connection too [11:38] fwif [11:38] so it only needs libdbus, not dbus-daemon [11:39] you only need dbus if you want system bus services, like Network Manager, or Avahi, etc. [11:39] but since those aren't part of minimal, you don't get the bus daemon [11:39] right, and they usually depend on the daemon if there is no packaging error [11:40] Keybuk, thanks a lot for that intro, i really didnt mean to annoy you [11:41] exactly [11:41] since I know for a fact that ubuntu-minimal works [11:41] and he doesn't say anywhere how "boot doesn't work" [11:41] and is using a non-standard way of building it [11:41] I'm inclined to believe he's screwed up [11:41] right [11:41] I'm also quite happy to be proved wrong here ;) [11:41] well, he is using a bare debootstrap [11:41] thats what rootstock does if you dont specify anything extra [11:42] pitti: I don't think I was ever working on it - my comment just meant what it said on the tin [11:42] pitti: feel free to sponsor [11:43] i used to install ubuntu-minimal by default on top of that if you dont use any options ... but that was removed at some point by lool (i think to gain debian compatibility), i'll re-add it [11:43] I'm not 100% sure a bare debootstrap boots [11:43] you'd have to check with cjwatson on that one [11:44] I can't remember what debootstrap actually installs [11:44] cjwatson: hi! in doing the devmapper/lvm2 merge I ran into a change you made that I think is no longer needed, but I wasn't sure how to validate it for sure. [11:44] cjwatson: you set DH_OPTIONS="" before doing the shlibs build to get sane symbols for udebs. I think this is fixed upstream, but I don't know quite what to look for. [11:46] StevenK: there might be a more concise way, but I would write it as something like: CODE1=0; command1 || CODE1=$?; CODE2=0; command2 || CODE2=$?; if [ "$CODE1" -eq 0 ] || [ "$CODE2" -eq 0 ]; then command3; fi [11:47] Keybuk,ogra: debootstrap installs priority: required and important; dbus is priority: optional [11:47] right [11:47] Keybuk,ogra: debootstrap certainly installs ubuntu-minimal, unless something went wrong [11:48] well, not the metapackage, does it ? [11:48] yes, the metapackage [11:48] ok [11:48] apt-cache show ubuntu-minimal | grep ^Priority: [11:48] :) [11:48] important ... ok [11:48] cjwatson: ok, so debootstrap output should boot [11:49] Keybuk, it usually does for me [11:49] ogra: I'm going to ask a very pertinent question [11:49] we stopped hardcoding the list of packages to use for debootstrap in 2005; it's all priority-driven nowadays [11:49] but that user seems to be on karmic [11:49] which may reveal how silly the reporter is being [11:49] he installed debootstrap [11:49] ... [11:49] kees: let me check ... [11:49] did he install a kernel as well? [11:50] and a boot-loader? [11:50] cjwatson: specifically this: http://launchpadlibrarian.net/16954645/devmapper_2%3A1.02.25-1ubuntu4_2%3A1.02.25-1ubuntu5.diff.gz [11:50] Keybuk, well, thats up to the user with rootstock ... but apparently after installing dbus his system booted ... who knows what he did inbetween first boot and dbus [11:50] yeah, I was just tracking down the changelog to refresh my memory [11:50] I certainly remember why that was needed, so I'll double-check Debian [11:50] cjwatson: what should I look for in the udebs? [11:51] ogra: which makes no sense [11:51] cjwatson: CODE1=... eew, let's not have that in antimony's crontab please :) [11:51] cjwatson: the debian build of libdevmapper* in lvm2 is now very different [11:51] an ubuntu-minimal install basically consists of upstart, udev, mountall and getty [11:51] Keybuk, ?? [11:51] right [11:51] that boots perfectly, *really fast* :p [11:51] kees: you actually want to look at the shlibs file in the run-time library's control area [11:51] and make sure it has some plausible-looking udeb: entries [11:52] debdiff between old and new libdevmapper1.02.1-udeb don't show regressions there, but let me unpack it and actually look at it [11:52] you won't see it when debdiffing the udeb [11:52] the breakage was exposed by building other udebs against devmapper [11:53] hrm, perhaps I don't know what "run-time library's control area" is [11:53] libdevmapper1.02.1 rather than libdevmapper1.02.1-udeb [11:53] the DEBIAN/shlibs file, which won't register on debdiff [11:53] oh! er, okay [11:54] ah-ha, yes. my current merge breaks it. [11:54] so, err ... the Debian mirror I'm looking at doesn't actually appear to have a current libdevmapper1.02.1-udeb [11:54] Hah, damn. slangasek guessed what I wanted it for ;-) [11:55] StevenK: the mail from lool was a clue [11:55] it builds clvm, lvm2-udeb, and lvm2 [11:55] ah-ha, I just missed it, it does show in the debdiff of the regular debs, oops. [11:55] am I missing something obvious? [11:56] libdevmapper 1.02.1 [-libdevmapper1.02.1-] {+libdevmapper-event1.02.1+} (>= [-2:1.02.27)-] [11:56] [-udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.27)-] {+2:1.02.39)+} [11:56] how to fix this in the current merge is not immediately obvious, though. [11:57] slangasek: if you have a cleaner answer to the question asked ... [11:57] cjwatson: I want to revisit the premise :) [11:57] well, I sort of agree there, if this is imx51/dove stuff [11:57] fwiw, current package looks like this: https://edge.launchpad.net/~kees/+archive/ppa/+sourcepub/962485/+listing-archive-extra [11:57] the fact that doing those builds involves two separate invocations is a bug in and of itself [11:57] and I said so from the beginning, I think [11:57] StevenK, lool: the whole reason we're running this as two commands instead of one was to work around some armel buildd bug... do we know that this is still an issue? [11:58] does anybody know what I should be doing if "bzr merge-package <...>" says "ERROR: No such tag: upstream-2.0.3"? [11:58] james_w maybe^ :) [11:58] slangasek: I'm doing it as two seperate builds since I didn't want imx51 to impact on dove and vis-vrsa [11:58] eww, libdevmapper* has a different set of version numbers, no wonder I missed it [11:58] *vise versa [11:58] cjwatson: mind bending :) [11:59] kees: Debian's package seems to have correct shlibs [11:59] libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39) [11:59] udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39) [11:59] dholbach: you're supposed to be able to fall back on bzr merge [11:59] cjwatson: perhaps it's the addition of libdevmapper-event that is breaking it [11:59] slangasek: "ok" [11:59] StevenK: er, and what makes you think that running them as a single command will cause them to "impact" each other? [12:00] kees: ah yes, that's quite possible [12:00] slangasek: So, "ARCHES='armel+imx51 armel+dove' buildlive" ? [12:00] * kees tries the DH_OPTION= fix... [12:00] wisdom teeth are impacted, people are affected by the effects of events [12:00] as a .sig I saw once said [12:02] cjwatson: hmpf, no love. [12:02] StevenK: ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live - but again, I was told the original reason for the split was to work around some strange autobuilder bug [12:02] s/autobuilder/livefs buildd/ [12:03] I'm happy enough to try that and see what happens [12:03] yes, while clementine is supposed to serialize builds that apparently doesnt work right [12:03] Er, it has, and does [12:03] Because I've seen it, multiple times [12:04] well, if you are confident. go ahead and try it [12:04] Hopefully that will make lool happy too [12:04] i know we had issues in the past which initially resulted in that weird crontab entry [12:13] kees: do you have a bzr branch or something I can check out? [12:13] or should I just use source from your ppa? [12:14] cjwatson: I can create one, if you want, but go ahead and snag the source from my ppa. [12:14] kees: and did you literally try DH_OPTION=, or the correctly spelled DH_OPTIONS=? [12:14] I'm about 5 hours overdue for bedtime. ;) [12:14] cjwatson: it was the correctly spelled DH_OPTIONS= [12:14] cjwatson: what's melting my mind now is how what's in the built deb got there. [12:14] libdevmapper 1.02.1 libdevmapper-event1.02.1 (>= 2:1.02.39) [12:14] that's in libdevmapper [12:14] yet... [12:15] it's in no shlibs file in the build tree [12:15] dpkg-checkbuilddeps: Unmet build dependencies: libreadline5-dev [12:15] don't suppose that's easily upgradeable to readline6? [12:15] * cjwatson hates having to switch back and forth [12:15] $ cat ./debian/libdevmapper1.02.1/DEBIAN/shlibs [12:15] libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39) [12:15] udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39) [12:15] *hold face* [12:16] cjwatson: I can try it with 6 [12:19] kees: build in progress here [12:20] cjwatson: it built fine with readline6, so I'll flip that. [12:20] this is _really_ odd. what is changing the shlibs file between debian/libdevmapper1.02.1/DEBIAN/shlibs and the deb [12:26] cjwatson: aargh, I'm an idiot. DH_OPTIONS= worked fine, I just changed my version for the PPA upload. so I had ubuntu1 and ubuntu1~kees1 .debs. I was checking the wrong one. [12:26] ev: Executing grub-install hd(0) failed. This is a fatal error. [12:26] s/an idiot/way past bedtime/ [12:27] bah [12:27] okay, uploading the fix to my PPA, heading to bed [12:27] kees: ah, ok :) [12:27] Keybuk: did you change your preseed? Surely that should be grub-install (hd0) [12:27] ev: err, (hd0) is what it said [12:27] was retyping without paying complete attention [12:28] syslog says "no mapping exists for 'hd0'" [12:28] kees: I tend to use DH_VERBOSE=1 pretty liberally for debugging this kind of thing [12:29] Keybuk: clearly a bug, but can you use /dev/sda rather than (hd0)? [12:30] we're finally managing to get on the road to deprecating (hdX,Y) names for most purposes [12:30] and it might work around whatever the problem is [12:30] cjwatson: how do I do that? [12:31] ubiquity partman-auto/disk string /dev/sda [12:31] grub-installer/bootdev /dev/sda [12:31] is what I have in my seed [12:31] ev: I don't have anything about grub in there right now? [12:31] Keybuk: indeed, this is a workaround for the aforementioned bug [12:31] huh [12:32] why is (hd0) turning up at all then [12:32] # Try to avoid using (hd0) as a boot device name. Something which can be [12:32] # turned into a stable by-id name is better. [12:32] default_bootdev_os="$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2)" [12:32] it only uses (hd0) if that fails [12:33] you want the full logs? [12:33] Keybuk: yes please, and could you also run 'chroot /target grub-mkdevicemap --no-floppy -m -' from a shell prompt after the failure and see what it says? [12:34] maybe I forgot to mount /proc and friends before calling grub-mkdevicemap [12:38] * ogra wonders how to tell jockey to not sacn on every start [12:38] *scan [12:40] StevenK, ogra, slangasek: Only the buildlive calls need to be split though, not the cron-ports.daily-live one [12:41] yes [12:42] lool: but it's precisely that splitting that makes it a PITA to check the return code [12:44] right; if it absolutely has to be serialised for some reason, that serialisation needs to be done inside the buildlive script itself [12:44] but I would hope that isn't really necessary [12:44] slangasek: I don't think it's particularly bad if we run the image building code if the livefs failed [12:44] we need to be consistent about this across architectures. it's a pain for armel to be substantially different [12:45] cjwatson: http://people.canonical.com/~scott/daily-installer/20100211.1-max/ [12:45] IMO the easiest way is to add a livefs builder.. [12:45] that has the syslog and stuff [12:45] lool: even if it causes previous successful builds to be rotated off? [12:45] lool, ++ send hardware :P [12:45] That would make things more symetric and would alleviate the image building time for armel.... [12:45] lool: why can't we just run the two live filesystem builds in parallel? [12:45] slangasek: It shouldn't be a failed build [12:45] lool: want to give up a buildd to do it? :) [12:46] sure, it takes longer, but it takes longer *anyway* right now [12:46] cjwatson: we only have one livefs builder, and it happened that the serialization code didn't work [12:46] cjwatson: running the chroot grub-mkdevicemap outputs [12:46] cjohnston, because the build machine is already underpowered [12:46] (hd0) /dev/sda [12:46] But it was years ago, perhaps that would work now [12:46] I never got the chance to debug it [12:46] ogra: we're already running two builds [12:46] no, it wouldn't be a failed build, it would just be an ISO that's identical to the previous build and therefore redundant [12:46] years ? [12:46] the symptom was that the livefs buildd was stuck [12:46] right [12:46] ogra: it makes no logical difference to underpoweredness whether we fire off two builds at once and have one stick on a lock until the other's done, or explicitly serialise them [12:46] so this is a red herring [12:46] cjwatson, yes, i know, but we cant run them at the same time [12:46] slangasek: Yeah, and I don't have a big problem with that! [12:46] cjwatson: the failure mode was that the livefs buildd required a hard reset [12:47] ogra: livecd.sh doesn't try though, it uses locks [12:47] (hard reset == someone goes to data center to reboot) [12:47] slangasek: right, but I'd much rather we debugged that ... [12:47] certainly [12:47] Keybuk: permission errors on syslog [12:47] cjwatson, we have no control about the kernel on these machines and its not a good kernel ... [12:48] cjwatson: bah [12:48] I keep fixing that [12:48] i.e. it produces unexpected lockups in several cases [12:48] I don't mind trying the lock thing again; I still believe the best thing which can happen is a second livefs builder [12:48] yes [12:48] its the only proper solution [12:48] I have no objection to a second livefs builder. I do object to the way the scripts are laid out right now [12:48] but we lack HW for that [12:48]