[01:08] <CarlFK> did these boot params change?  (they seem to be ignored) append initrd=ubuntu/jaunty/initrd.gz root=/dev/rd/0 rw locale=en_US console-setup/layoutcode=en
[01:09] <CarlFK> er, not all of them, just locale=en_US console-setup/layoutcode=en
[01:11] <cjwatson> CarlFK: console-setup/layoutcode=en has never been valid. Where did you get it?
[01:11] <cjwatson> locale=en_US should still be valid
[01:19] <cjwatson> CarlFK: there's no "en" keyboard layout name. I think what you probably wanted was console-setup/layoutcode=us
[01:35] <CIA-28> casper: cjwatson * r610 trunk/ (2 files in 2 dirs):
[01:35] <CIA-28> casper: [ -w /cdrom ] turns out not to be a sufficient test for files under
[01:35] <CIA-28> casper: /cdrom being writable; with busybox, it always returns true even for
[01:35] <CIA-28> casper: read-only filesystems. Explicitly check for the read-only flag in mount
[01:35] <CIA-28> casper: output to work around this.
[01:42] <CIA-28> casper: cjwatson * r611 trunk/ (debian/changelog scripts/casper-helpers):
[01:42] <CIA-28> casper: Fix where_is_mounted helper function to actually produce output (thanks,
[01:42] <CIA-28> casper: Steve Dodd; LP: #346941).
[01:47] <CIA-28> casper: cjwatson * r612 trunk/ (debian/changelog scripts/casper-helpers):
[01:47] <CIA-28> casper: Add a comment to find_cow_device explaining why the choice of
[01:47] <CIA-28> casper: filesystems is restricted (I asked for this comment in LP #230703 but it
[01:47] <CIA-28> casper: apparently never got written).
[01:49] <CIA-28> casper: cjwatson * r613 trunk/debian/changelog: releasing version 1.169
[08:56] <Mirv> cjwatson: don't know if you noticed (or have time), but I noticed problems with three more strings in debian-installer even after the latest template update. or one string actually missing, two not somehow showing up trasnlated even though they should. bug #356333
[08:59] <Mirv> the two strings not showing up is a bit strange, though I think there once was a similar issue.
[09:15] <mvo> did we at some point installed without devpts in fstab? I got a bunch of reports that its misisng and that causes trouble with vte
[09:41] <cjwatson> Mirv: it'd really make my life easier if you filed separate bugs for problems that seem to be separate :-/
[09:41] <cjwatson> Mirv: the first string has a 'TODO i18n' comment in the source
[09:42] <Mirv> cjwatson: ok, I can do that. sorry about that, I just thought about them as the "last bunch of I18N problems".
[09:42] <cjwatson> Mirv: "Use weak password?" was marked fuzzy in Finnish last time I synced that translation; I'm not sure what's up with the extended description of that template
[09:43] <cjwatson> I'll have a look once my net connection has freed up from my daily mirror sync so that I can rsync an updated CD image, thanks
[09:46] <Mirv> split the bug reports into two
[09:46] <Mirv> and ok
[09:51] <cjwatson> mvo: I don't think we've *ever* installed with devpts in fstab. It's supposed to be mounted by mountdevsubfs.sh
[09:53] <mvo> cjwatson: oh, right. sorry
[09:55] <evand> cjwatson: regarding https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/325958/comments/35 the warning being broken is new to me.  How is it broken for you?
[09:56] <cjwatson> evand: I see the triangle warning icon, but no text
[09:56] <cjwatson> evand: a test run yesterday with MID was the first time I've ever seen text there, so I guess it isn't always missing
[09:57] <evand> hrm, ok.  I'll look into that today after I've finished the m-a fix.
[10:03] <CIA-28> ubiquity: cjwatson * r3189 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): merge from lp:~robert-ancell/ubiquity/trunk
[10:04] <CIA-28> ubiquity: cjwatson * r3190 ubiquity/ubiquity/frontend/gtk_ui.py: typo
[10:28] <cjwatson> Mirv: are you by any chance testing on amd64?
[10:29] <cjwatson> Mirv: I noticed that yesterday's amd64 daily build was actually using a live filesystem that was somewhat out of date due to build failures, and specifically it predated the upload in which I incorporated some new user-setup strings into ubiquity; today's amd64 CD looks better
[10:32] <CIA-28> user-setup: cjwatson * r170 ubuntu/debian/ (7 files in 2 dirs): Update Ubuntu-specific strings from Launchpad.
[10:33] <cjwatson> hmm, there is something wrong with my translation update script though
[10:36] <cjwatson> requires coffee before investigation
[10:50] <Mirv> cjwatson: just i386 under virtualbox
[10:59] <cjwatson> ok, odder still then
[11:06] <ogra> cjwatson, any objections to merge lool's code as is (with the hardcoded paths to fis and fconfig) so i can start building testimages ? reverting the path should only be a one line change later
[11:51] <davmor2> evand: can you have a quick look at ubiquity-kde-frontend.  Step 4 of 6 displays no bars for install side-by-side and if I click on use entire disk I get bars black for current and grey for after
[11:57] <davmor2> evand: http://www.davmor2.co.uk/kde4of6.png
[12:01] <evand> davmor2: will do
[12:13] <davmor2> evand: it's 20090407's iso I just confirmed it and ubiquity is 1.12.4 as is the kde-frontend
[12:24] <davmor2> evand: also on step 5 I got /!\ next to every text box
[12:24] <evand> ok
[12:28] <Mirv> I suggested a gettext usage method for the "removes [stuff] and replaces them with [Ubuntu]" case. ngettext should be able to cope with it.
[12:29] <Mirv> I just haven't checked the python side of things, but probably quite similar
[12:32] <cjwatson> yeesh, automatically removing fuzzy messages is unreasonably painful
[12:32] <cjwatson> tmp="$(mktemp)"; for x in *.po; do msggrep -K -F -f ../../../new-strings "$x" | msgattrib --only-fuzzy --no-wrap - | grep ^msgid | tail -n +2 | sed 's/^msgid "//; s/"$//' > "$tmp"; msggrep -v -K -F -f "$tmp" "$x" | sponge "$x"; msgmerge --backup=none --previous -q -N -U "$x" templates.pot; done; rm -f "$tmp"
[12:33] <cjwatson> Mirv: unfortunately debconf templates don't support anything like ngettext
[12:34] <Mirv> cjwatson: ouch. well, then it would be two separate strings emulating ngettext for most languages, maybe
[12:34] <Mirv> (some could need more than two)
[12:34] <Mirv> or could it be "This will delete %s and install %s." (no it/them)
[12:37] <Mirv> mentioned the possibilities in the bug report
[13:08] <ogra> cjwatson, did you see my above question ?
[13:09] <cjwatson> ogra: I thought lool was going to be ready with redboot-tools today, though, and lool recommended waiting until that was in place
[13:09] <cjwatson> as I read it, anyway
[13:09] <cjwatson> lool: ^-
[13:09] <ogra> right, we dont have any test images yet though
[13:09] <ogra> would be helpful to be able to start building even without redboot-tools in place
[13:11] <cjwatson> I'm not going to merge lool's patch over lool's recommendation not to do so, so please discuss this with him
[13:13] <ogra> we discussed it on the phone
[13:13] <ogra> but he seems to be afk atm
[13:14] <ogra> i cant build test images as the cdimage user from his home is the point here and would like to see the scripts in interaction with the whole cdimage stuff to track down probs
[13:15] <ogra> but lets wait until he returns
[13:28] <lool> ogra: As I said, I'd love if we could get a manual run, but would prefer not merging the current version as it has hardcoded pathnames; the version will work, but it's going to use these hardcoded pathnames in the history
[13:28] <lool> ogra: Can't you run it from a /src/cdimage-testing or something?
[13:28] <lool> /srv
[13:28] <cjwatson> lool: do you have the necessary redboot-tools package now?
[13:29] <lool> cjwatson: No, I'm afraid I've spent the morning on UNR issues as prompted by this morning's email
[13:29] <lool> I'll start working on that now
[13:29] <ogra> its currently only the missing binary blob thats the prob
[13:29] <lool> ogra: And installing the package on antimonu
[13:29] <lool> *antimony
[13:29] <ogra> yes
[13:29] <ogra> i was referring to the package :)
[13:30] <cjwatson> the missing binary blob is not a problem. Just commit it to data/jaunty/ in debian-cd
[13:30] <cjwatson> I'm happy for it to be there for the moment
[13:30] <cjwatson> (I've said this a couple of times already but maybe at times when nobody was paying attention)
[13:30] <ogra> right
[13:30] <lool> I heard it
[13:30] <ogra> i did
[13:30] <ogra> but loic wants it in the package
[13:31] <lool> I commented that it would hence require two tickets if we go this route and two redboot-tools installs
[13:32] <cjwatson> well, do you want to start building CDs today or not? :)
[13:32]  * ogra would like to :)
[13:32] <cjwatson> if you do, then it depends on whether somebody has time to put the blob in redboot-tools
[13:35] <lool> Ok; /me goes making a clean blob and adding it in the package
[13:36] <CIA-28> user-setup: cjwatson * r171 ubuntu/debian/ (63 files in 2 dirs):
[13:36] <CIA-28> user-setup: Update Ubuntu-specific strings from Launchpad, including some strings
[13:36] <CIA-28> user-setup: previously stuck with old fuzzy translations due to a scripting error
[13:36] <CIA-28> user-setup: (LP: #356876).
[13:37] <ogra> lool, the blob we use is clean
[13:37] <ogra> its empty
[13:37] <lool> How did you create it?
[13:37] <ogra> fconfig on an sd and doing nothing but pressing enter
[13:38] <cjwatson> Mirv: [fx: sweats]
[13:38] <lool> ogra: Did you start from a zeroed SD?
[13:39] <cjwatson> 356876 was painful :)
[13:39]  * lool sighs at /dev/mmcblk0p2 has gone 14341 days without being checked, check forced.
[13:39] <CIA-28> user-setup: cjwatson * r172 ubuntu/debian/changelog: releasing version 1.23ubuntu17
[13:39] <ogra> lool, from an sd with redboot and our fis setup on it indeed
[13:39] <ogra> but beyond that, yes, i zeroed before
[13:40] <lool> ogra: Crap, our images wont work
[13:40] <lool> I need to unpad redboot first
[13:40] <ogra> you pad redboot ?
[13:40] <ogra> aww
[13:41] <lool> I don't, it's padded in the package
[13:41] <ogra> oh
[13:41] <ogra> we can add my unpadding code from the builder script to the package
[13:41] <ogra> smells like the cleaner way
[13:41] <ogra> nobody ever needs the padded binary
[13:41] <ogra> and while we do that we could move the bin to 7usr/lib
[13:42] <ogra> (no idea why nobody catched its in /usr/share)
[13:42] <ogra> (my script pulls the path out of the package info, so i didnt notice)
[13:43] <ogra> lool, should i add these two fixes to redboot-imx ?
[13:44] <lool> ogra: I reported that it's in /usr/share
[13:46] <ogra> i meant the reviewers
[14:10] <Mirv> cjwatson: great! the scripts look "nice", I hadn't even heard of sponge which is apparently in moreutils.
[14:11] <cjwatson> my approach to this kind of problem tends to be that they can all be solved given a sufficient number of invocations of msggrep and msgmerge
[14:12] <lool> cjwatson: ticket for redboot-tools filed; will ship the data in redboot
[14:12] <lool> cjwatson: happy if you can ack the ticket or whatever you usually do
[14:36] <CIA-28> ubiquity: cjwatson * r3191 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[14:36] <CIA-28> ubiquity: * KDE frontend:
[14:36] <CIA-28> ubiquity:  - Fix typo in installation_medium_mounted handler (LP: #354515).
[14:37] <CIA-28> ubiquity: cjwatson * r3192 ubiquity/debian/changelog: clarify Robert's changelog message
[14:54] <lool> cjwatson: fconfig.bin uploaded in redboot-imx in the archive
[14:54] <CIA-28> console-setup: cjwatson * r101 ubuntu/debian/po/ (fi.po sv.po): Update Ubuntu-specific strings from Launchpad (overriding old stuck fuzzy strings)
[14:56] <CIA-28> partman-auto: cjwatson * r286 ubuntu/debian/po/ (14 files): Update Ubuntu-specific strings from Launchpad (overriding old stuck fuzzy strings)
[14:58] <cjwatson> lool: thanks. do you need to update the ticket for that?
[14:58] <lool> cjwatson: No, it's orthogonal
[14:59] <cjwatson> ok, you mean a separate ticket, or not involving IS at all?
[14:59] <ogra> redboot-imx gets pulled in during build
[14:59] <lool> cjwatson: we need redboot-tools on antimony for the fis and fconfig commands
[14:59] <cjwatson> oh, of course, you can extract it from the archive
[14:59] <lool> cjwatson: we're unpacking redboot-imx from the mirror
[15:00] <lool> However I do need to adjuste the post-boot stuff for a variety of things
[15:14] <CIA-28> partman-target: cjwatson * r758 ubuntu/debian/po/ (62 files): Update Ubuntu-specific strings from Launchpad (overriding old stuck fuzzy strings)
[15:25] <xivulon> cjwatson, was reading the discussion on portable ubuntu
[15:25] <xivulon> it is something I evaluated long time ago' (was andlinux to be precise)
[15:26] <xivulon> it could be integrated with wubi, either using wubi as downloader/installer or, if hardware profiles were available, even using both at the same time
[15:26] <xivulon> do you think that hardware profiles are possible at all?
[15:27] <cjwatson> what are hardware profiles?
[15:27] <xivulon> like booting the same root partition with different hardware configurations (xorg.con for instance)
[15:28] <xivulon> like laptop/desktop mode
[15:28] <xivulon> in the case above I could have a configuration for colinux and one for real-hardware
[15:29] <xivulon> would also be a neat feature for usb-creator
[15:29] <cjwatson> best done by appropriate handling of boot parameters in userspace
[15:30] <xivulon> I guess I could use boot parameters and have an init script to swap configuration files appropriately
[15:30] <xivulon> but that is only part of the solution
[15:31] <xivulon> we would need also to generate hardware configurations
[15:31] <cjwatson> we try very hard to make Ubuntu detect things at run-time, not have hardware configurations wired into its filesystem
[15:31] <xivulon> it might be interesting for instance to boot into "generic mode" (=live cd) and "specialize"
[15:32] <cjwatson> it's a design goal that the root filesystem should be portable between computers
[15:32] <cjwatson> the live CD is anything but generic
[15:32] <cjwatson> well, generic among computers I suppose, but no more than the installed system is
[15:32] <cjwatson> I think you're overestimating how much is hardwired in an installed system; it's really not very much
[15:33] <xivulon> ah that's interesting
[15:35] <cjwatson> it should be really easy for the system to detect colinux at boot time if anything needs to be customised for it, for instance
[15:35] <cjwatson> hardware profiles are unnecessary complexity here, and therefore should be eliminated from consideration
[15:36] <xivulon> yes if things are fully dynamic it is obviously much better
[15:37] <xivulon> I do not see much issues then in merging wubi and portable ubuntu, in fact that would even allow us to install completely in windows via colinux
[15:37] <xivulon> then either use dual boot, or have a the gnome panel in windows, or, better, as a windows menu
[15:38] <xivulon> do you think the above would be reasonable?
[15:39] <cjwatson> in principle, though I'd have to see the patches :-)
[15:40] <xivulon> basically on top of the ISO I would need to download a colinux runtime package, containing colinux, xming, pulse audio and so on
[15:41] <xivulon> then generating a disk images and launching ubiquity from colinux   preseed
[15:42] <xivulon> I'd assume that this approach would be better (but longer) than using a pre-made image or the ISO   unionfs
[15:43] <xivulon> I would then install both grub4dos/grub2 and appropriate windows-side colinux shortcuts
[15:43] <cjwatson> an squashfs overlay (with aufs) might in principle be doable but we've never yet attempted to actually deploy a multiple-squashfs approach, so I suspect we would run into an amusing array of bugs
[15:43] <cjwatson> btw, grub2 now appears to work in jaunty installations if you have any reasonable way to give it a try
[15:43] <cjwatson> d-i grub-installer/grub2_instead_of_grub_legacy boolean true
[15:44] <cjwatson> god knows what it'll do with wubi :-)
[15:44] <xivulon> I did try grub2 it and it was successful on my setup
[15:44] <lool> cjwatson: I think people in cdimage can trigger an update of the ports mirror from an internal archive; would you mind running an update to grab the latest redboot-imx on that mirror?  it's not on the public ports.u.c though, it finished building 30 minutes ago
[15:44] <xivulon> at the end I dropped the idea to deploy it because we already have enough issues with the rewrite
[15:45] <lool> The one I'd like to have is redboot-imx51-babbage_200910-0ubuntu2_armel.deb
[15:47] <xivulon> never used aufs yet, but I used overlays in early prototype of wubi (to modify debian-installer)
[15:47] <cjwatson> lool: the easiest way to do it with proper locking is to trigger a ports build, really
[15:48] <cjwatson> I've kicked off one for ubuntu-server
[15:48] <lool> Thanks
[16:02] <evand> cjwatson: are you able to make this call?
[16:03] <cjwatson> evand: call?
[16:03] <evand> Ubuntu One in the install
[16:03] <cjwatson> oh, crap. how come it wasn't in my calendar?
[16:03] <cjwatson> yes, I can make it. what number?
[16:16] <xivulon> cjwatson, I think it would be interesting to use squashfs   aufs on a sparse file, quite some fireworks, but would be very interesting if it worked
[16:20] <xivulon> is it possible to do an OEM-installation and do the first boot with a preseed file to initialize the system?
[16:25] <davmor2> xivulon: afternon
[16:26] <davmor2> evand: any joy with kubuntu?
[16:38] <evand> davmor2: I can reconfirm it and have been working on a fix.
[16:39] <davmor2> evand: sorry must of missed the confirm and cool :)
[16:39] <evand> err reproduce*
[16:40] <davmor2> evand: phew thought I must of missed it :)
[16:47] <lool> cjwatson: It seems the ubuntu-server run didn't pick up ubuntu2; probably it was too early
[16:48] <cjwatson> lool: oh, I failed to read properly, you said it wasn't on ports.ubuntu.com yet
[16:49] <cjwatson> it's still not
[16:49] <cjwatson> it's probably publishing right now and will be available in ~10 minutes
[16:49] <lool> Excellent
[16:50] <cjwatson> and then I can kick off another random build after that
[16:51] <cjwatson> aha, and lamont resolved your ticket
[16:51] <ogra> well, you could do a ports-live one directly :)
[16:51] <lool> cjwatson: yup, only waiting for that .deb now :)
[16:52] <ogra> cjwatson, what does eth ubiquity reboot dialog use ? just gnome-session ?
[16:53] <ogra> *gnome-session-save i meant
[16:53] <ogra> or does it call reboot directly
[16:55] <lool>             execute("sudo", "-u", user, "-H",
[16:55] <lool>                     "gnome-session-save", "--kill", "--silent")
[16:55] <lool> actually it does:             execute("gdm-signal", "--reboot")
[16:55] <ogra> yeah
[16:56] <lool> I wonder why the two are required
[16:56] <ogra> gnome-session-save --kill --silent is the one the menu item does as well
[16:58] <ogra> gdm-signal comes from powermanagement-interface which we dropped in jaunty iirc
[17:00] <ogra> gdm-signal only tells gdm what to do if the session has ended ... beyond that its a no-op
[17:00] <cjwatson> while you're right that gdm-signal is no longer present, it's interesting that it appears to work anyway :-
[17:00] <cjwatson> :-)
[17:00] <cjwatson> I assume gdm DTRT anyway ...
[17:00] <ogra> yeah
[17:00] <ogra> well, we appear to have some users seeing hands on the babbage
[17:00] <cjwatson> is there a better modern approach?
[17:01] <ogra> i dont think so, seb would know
[17:01]  * lool had it here
[17:01] <ogra> but your system is weird :P
[17:01] <lool> cjwatson: I think gnome-session should do the right thing
[17:01] <ogra> no fresh jaunty
[17:01] <xivulon> got disconnected, last q was if there is a way to initialize an oem-config on first boot with a preseed file or boot args
[17:01] <ogra> lool, it doesnt here
[17:02] <ogra> on the installed system it simply kills my session
[17:02] <lool> When I looked, gnome-panel was calling gnome-session for such stuff
[17:02] <ogra> but drops me to gdm
[17:02] <lool> the args might be incorrect
[17:02] <ogra> there is no arg for reboot
[17:03] <ogra> neither for shutdown
[17:03] <ogra> gnome-session-save really only applies to the session
[17:04] <lool> I know for sure that the power button calls gnome-session --something (via GPM I guess)
[17:04] <ogra> right
[17:04] <ogra> but gpm cares for the reboot being queued in gdm
[17:04] <cjwatson> xivulon: you can try to preseed the debconf database before oem-config starts, although it isn't necessarily very good at honouring this in all cases
[17:04] <ogra> or shutdown
[17:05] <lool> ogra: No; it can trigger a reboot right now
[17:06]  * ogra wonders how
[17:06] <ogra> the actual shutdown/reboot is done by gdm
[17:06] <lool> request_reboot() in gnome-session/gsm-manager.c
[17:06] <lool> Yes, it will be done by gdm
[17:06] <lool> It's not queued until you logout though
[17:06] <ogra> by setting a variable in gdm actually
[17:06] <lool>         if (! gsm_manager_is_logout_inhibited (manager)) {
[17:06] <lool>                 manager_attempt_reboot (manager);
[17:07] <lool> That's inhibit in case there's an update in progress
[17:07] <lool> cjwatson: Nowadays it's via consolekit
[17:07] <lool>         consolekit = gsm_get_consolekit ();
[17:07] <lool>         do_attempt_reboot (consolekit);
[17:07] <lool> Not GDM anymore
[17:07] <xivulon> cjwatson, thx, I think we can play with that!
[17:08] <ogra> lool, well, gnome-session-save doesnt reboot here no matter which arg combo i use
[17:08] <lool> http://paste.ubuntu.com/146284/
[17:08] <ogra> so i wonder why it does that on the live image
[17:09] <ogra> or how
[17:09] <cjwatson> lool: do you think we need to change the current code for jaunty?
[17:09] <lool> cjwatson: gnome-session/gsm-consolekit.c is how you'd implement it with consolekit nowadays
[17:09] <lool> cjwatson: it would be best I guess
[17:09] <lool> cjwatson: Perhaps seb128 has better advice
[17:09]  * ogra hasnt seen the hang ever here though 
[17:10] <ogra> i just heard it from two people now
[17:10] <lool> cjwatson: FYI this made shutdown/reboot/login sound and a bunch of things work for me this cycle since I'm using startx and not gdm :)
[17:11] <lool> ogra: I don't think the gnome-session-save cmdline can do it directly, it can only show you a GUI to do it
[17:11] <ogra> right
[17:11] <ogra> so why does the system reboot properly ?
[17:11] <lool> But almighty dbus can tell CK to reboot now muahaha
[17:11] <cjwatson> lool: well, it'd need to be in python, but yes
[17:12] <lool> cjwatson: Sure, just wanted to hint at the implementation with inhibit and all
[17:12] <cjwatson> at least python-dbus is already in desktop
[17:12] <lool> ogra: perhaps that fails and it falls back to reboot?
[17:12] <lool> I mean /sbin/reboot
[17:12] <ogra> lool, how does the system even know it should reboot ?
[17:12] <ogra> ubiquity only calls gnome-session-save --kill --silent
[17:13] <lool> /sbin/reboot is quite convincing
[17:13] <ogra> gdm-signal isnt there
[17:13] <lool> cjwatson: still no ubuntu2, gmrpf
[17:13] <ogra> so nothing in the system knows that a reboot should follow the session killing
[17:13] <ogra> *why* does the system reboot
[17:14] <cjwatson> I don't think it would be good for ubiquity to call reboot directly if it has a more graceful alternative
[17:14] <ogra> no, indeed
[17:14] <lool> ogra:         if (os.path.exists("/usr/bin/gdm-signal") and
[17:14] <ogra> i'm just trying to find out why its working at all
[17:14] <lool> ogra: So it goes to else which does "reboot"
[17:14] <ogra> oh !
[17:14] <ogra> ok
[17:14] <lool> cjwatson: Agreed
[17:15] <ogra> which in our case sometimes doesnt end the session properly
[17:15] <ogra> now it starts to make sense
[17:15] <cjwatson> oh, haha
[17:15] <cjwatson> so it's doing exactly what I said would be bad
[17:15] <ogra> and likely depends on the speed of your rootfs device
[17:16] <ogra> which is why i dont see it but others do
[17:16] <lool> poked seb
[17:16] <ogra> its a race
[17:17] <cjwatson> I'll work on converting ubiquity to consolekit
[17:17] <ogra> there is code in update-notifier already
[17:17] <ogra> likely just a copy paste job
[17:18] <lool> cjwatson: seb seems to say we might have to use the old GDM interface directly
[17:20] <cjwatson> let's stick to one channel, I'm reading #ubuntu-devel
[17:30] <lool> cjwatson: redboot ubuntu2 is here!  Packages.gz still lists ubuntu1 though, waiting a little longer
[17:42] <lool> cjwatson: This time it's in; could you please kick a build?
[17:42] <lool> Package: redboot-imx51-babbage
[17:42] <lool> Version: 200910-0ubuntu2
[17:43] <ogra> cute
[17:43] <lool> cjwatson: Also the Priority: extra seems wrong in the overrides, I've fixed it in the package
[17:43] <lool> (set to optional)
[17:45] <lool> cjwatson: Could you please close https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/357101 when uploading the new shutdown mechanism?
[17:49] <ogra> lool, is the debian-cd code merged ? i can trigger a ports-live build
[17:50] <lool> ogra: I need a ftp-ports update, so could you please launch any build if cjwatson didn't do so already?
[17:50] <cjwatson> I'll do it
[17:50] <lool> Thanks
[17:50] <cjwatson> lool: am I good to merge your branch now?
[17:50] <cjwatson> lool: or are you still working on it?
[17:51] <lool> cjwatson: No, I'd like to run it once and add a couple of changes
[17:51] <lool> cjwatson: It will take 5 minutes after the next ftp-ports run
[17:51] <cjwatson> running now
[17:51] <lool> cjwatson: Basically the new clean fconfig.bin requires setting a couple of vars
[17:51] <cjwatson> lool: why is Priority: extra wrong? if this isn't "specialised hardware" I don't know what is :)
[17:51] <cjwatson> I think I set that intentionally
[17:52] <lool> Oh ok; I thought extra was for -dbg or conflicting stuff, but missed the special hardware argument, thanks
[17:55] <cjwatson> actually policy nowadays says "specialized requirements"; the hardware bit was from memory
[17:56] <cjwatson> not that priorities below standard make a big difference nowadays
[18:00] <lool> cjwatson: Good to merge now!
[18:01] <lool> cjwatson: note that I uncommitted the last rev you might have reviewed last time; the new rev has the same commit message but doesn't use stuff in my ~/, has proper double quoting, and I think I addressed other comments
[18:02] <cjwatson> lool: cool. just debian-cd?
[18:02] <lool> I think so
[18:02] <lool> yes
[18:03] <lool> cjwatson: Then it would be cool to actually kick a run  :)  ARCHES=armel for-project ubuntu cron.ports_daily-live
[18:03] <ogra> ++
[18:06] <cjwatson> lool: ok, merged, deployed, and running
[18:06] <lool> ogra: I did a fis list and fconfig -l on the generated image, as well as xxd at the redboot offset; everything seems in palce
[18:06] <lool> cjwatson: thanks \o/
[18:06] <ogra> yahoo!
[18:07] <lool> The partition seems good as well  1      16.8MB  666MB  649MB  primary  fat32        lba
[18:07] <ogra> 649 ?
[18:07] <ogra> thats huge
[18:07] <lool> That's the size of what's on the Ubuntu CD?
[18:07] <ogra> my whole image is 650
[18:07] <ogra> no, the iso is 606MB
[18:08] <cjwatson> lool: did you consider doing the dd I suggested to set a non-fs data partition type?
[18:08] <lool> ogra: We can inspect whether there's any free space later on
[18:08] <ogra> though you have some higher efficiency on iso
[18:08] <lool> cjwatson: No, I did not create the partition at all yet
[18:08] <lool> cjwatson: This is still in the TODO, just like alternate installer support (or testing thereof)
[18:09] <lool> cjwatson: I intent to shrink the TODO for at least this, I really care about having this safety net in place, but it wasn't blocking image creation
[18:09]  * cjwatson nods
[18:10] <lool> Wee it seems it built
[18:11] <lool> Oh there's an ISO as well
[18:11] <lool> From a previous run I guess
[18:12] <cjwatson> yes, that doesn't look too bad
[18:12] <lool> cjwatson: It's the only image in MD5SUMS, and someone mentionned that the UNR .img wasn't in MD5SUMS
[18:12] <lool> I think vfat images clobber the MD5SUMS file
[18:12] <ogra> jaunty-desktop-armel.img geez !
[18:12]  * ogra rsyncs
[18:12] <cjwatson> yes, the iso was carried over. I've deleted it and it won't recur
[18:12] <cjwatson> lool: more likely, single-arch rebuilds clobber MD5SUMS
[18:13] <lool> cjwatson: Ah good point, I'll check that thing about UNR then
[18:13] <cjwatson> I'll just regenerate it
[18:13] <ogra> we'll need the html changes
[18:13] <lool> It's true, the .img isn't in MD5SUMS
[18:16] <lool> ogra: Hmm look at the size of the UNR ISO versus VFAT
[18:16] <lool> But you're doing VFAT as well, not sure why yours would be smaller
[18:17] <ogra> wow, the rsync only took 1min
[18:17] <ogra> jaunty-desktop-armel.img
[18:17] <ogra>    675282944 100%   10.58MB/s    0:01:00 (xfer#1, to-check=0/1)
[18:17] <lool> I hope it's not empty
[18:17] <ogra> -rw-rw-r-- 1 ogra ogra 644M 2009-04-07 19:10 jaunty-desktop-armel.img
[18:18] <ogra> md5 matches too :)
[18:18]  * ogra dd's
[18:19] <ogra> ooooh thats so exciting :)
[18:23] <cjwatson> I've hand-hacked the HEADER.html and MD5SUMS so that at least it's downloadable. The script that generates HEADER.html needs to be fixed properly though.
[18:23] <cjwatson> I can probably do that tomorrow
[18:25]  * ogra wants dd++ .... its so slow
[18:28] <ogra> BOOTMESSAGES !
[18:29] <ogra> lool, ^^^ ...
[18:29] <ogra> if oit now doesnt jump into initramfs we have won
[18:29] <ogra> eeek
[18:29] <ogra> and it does
[18:29] <ogra> lool, awww ... you didnt use the same cmdline
[18:30] <lool> ogra: I didn't?
[18:30] <ogra> boot=casper LIVEMEDIA=/dev/mmcblk0p1 -- is missing
[18:30] <lool> ogra: It should be there
[18:30] <ogra> (not sure we still need LIVEMEDIA but surely boot=casdper)
[18:30] <lool>     EXTRA_ARGS="boot=casper LIVEMEDIA=/dev/mmcblk0p1 --"
[18:30] <ogra> i see both consoles and the preseed
[18:31] <ogra> but there it stops
[18:31] <ogra> quoting issue ?
[18:32] <lool> ogra: I know it's only set if CDIMAGE_LIVE = 1, but I don't see why it wouldn't
[18:32] <ogra> weird
[18:33] <lool> URGH
[18:33] <lool> ogra: Ok, code moved around, EXTRA_ARGS is set after being used
[18:33] <ogra> heh
[18:34] <ogra> there is another ports-live run going on atm
[18:34] <lool> cjwatson: I committed an update to fix this; would you mind
[18:34] <ogra> so we likely have to wait until thats finished
[18:34] <cjwatson> no you don't, it's for a different project
[18:35] <cjwatson> cdimage supports parallel builds in most cases
[18:35] <ogra> oh, i missed the x :)
[18:35] <ogra> but we need to commit first anyway
[18:36] <cjwatson> merged, deployed, running again
[18:36] <ogra> thanks
[18:36] <cjwatson> (it'll probably screw up MD5SUMS etc. again)
[18:41] <cjwatson> lool: need to fix .list file generation for vfat
[18:43] <ogra> hmm, md5 matches http://cdimage.ubuntu.com/ports/daily-live/20090407.2/MD5SUMS#
[18:43] <ogra> -#
[18:53]  * cjwatson -> out
[18:53] <ogra> yay, boots
[18:54] <ogra> lool, ^^^
[18:54]  * ogra sees an X cursor ...
[18:56] <ogra> hmm, no gnome-keyring issues
[18:56] <lool> cjwatson: Argh, I'm afraid I broke Ubuntu MID and Ubuntu Netbook Remix generation since Friday: I didn't export IMAGE_FORMAT in etc/config, which is why both an ISO and a .img are showing
[18:57] <lool> cjwatson: just committed the fix to ~lool/cdimage; sorry about that
[18:58] <lool> cjwatson: Might be good to trigger a re-run of these two and remove the .isos afterwards
[18:59] <lool> ogra: cool
[18:59] <lool> ogra: Anything which needs fixing in it still?
[18:59] <lool> ogra: I'm curious about why LIVEMEDIA and -- are needed
[18:59] <ogra> no, apart from the known bugs its fine
[19:00] <ogra> -- is for people modifying the cmdline
[19:00] <ogra> stuff added after -- will end up in the installed system ...
[19:00] <ogra> stuff before that is ignored
[19:00] <lool> Ok; I think I've seen an image where it wasn't set
[19:00] <ogra> LIVEMEDIA was what i used in the beginning to speed up casper scanning for the livefs
[19:01] <lool> ogra: So we could drop it?
[19:01] <ogra> i dont think we need it, but i'd like to verify that first
[19:01] <ogra> i'll test an image without it tomorrow
[19:01] <lool> ogra: Would like it if you could cause the root partition will change if I add a non-FS data part at the beginning of the image
[19:01] <ogra> i'll start an inmstall of the new image now and let that run over night
[19:03]  * ogra tries to make sense out of "if you could cause the root partition will change"
[19:04] <lool> ogra: if you could, because the root partition will change
[19:04]  * lool blames the batteries of his keyboard
[19:04] <ogra> ah
[19:04] <lool> Oh and that bug I wrote the other day was also due to the batteries
[19:04] <ogra> yeah, will test that tomorrow first thing
[19:05] <ogra> lets see if the install finishes properly now
[19:05] <ogra> (beyond that i need to go and buy food soon, susie is angry already)
[19:06] <ogra> cjwatson, confirming the $() vs ${} issue is fixed on the partitioning window (in german at least)
[19:09] <ogra> lool, install running, see you tomorrow ... awesome work !
[19:09] <lool> bye
[19:17]  * lool writes his image too
[19:27] <lool> cjwatson: .list generation > because this is done after the final image is built, it's not trivial: the mtools expect to work on a VFAT image, you can't tell them to read within a partition table or in the middle of a file; I could either generate the .list earlier in the build, but this is not really the way debian-cd expects this to happen, or re-extract the VFAT and then run mdir on it, but that's heavy
[20:11] <lool> Hmm ubiquity hanged for me at the partition step; the partition screen never came up and I see nothing in the log
[20:11] <lool> Looks like the system is mostly idle
[20:16] <lool> debug log ends at "widget found for partman/progress/init/title" followed by an OK from debconf
[20:17]  * lool gives up for tonight
[22:34] <alefteris> cjwatson, this string has propably changed? http://people.ubuntu.com/~cjwatson/d-i-translations/el.vars. I can't find it..
[23:06] <superm1> cjwatson, with some minor modifications to our factory install procedures, i've done a grub2 install successfully w/ today's daily :)  It appears device numbering is a little different for grub2, and matches kernel device numbering properly.
[23:55] <cody-somerville> cjwatson, Is there any reason Ubuntu uses casper instead of live-initramfs?
[23:56] <cjwatson> superm1: yeah, I think they changed it to be 1-based
[23:56] <cjwatson> cody-somerville: casper predates live-initramfs
[23:56] <cjwatson> we were there first, basically
[23:59] <cjwatson> cody-somerville: there is some complex history and we should certainly do some work on merging changes that have been made in live-initramfs, but I don't think it would be appropriate to switch to it wholesale