[11:27] <saispo> hi cjwatson
[03:14] <JD> cjwatson: you make me sad :P
[03:14] <JD> *goes back to reading bug*
[03:15] <saispo> cjwatson: why isolinux is not synced on debian for gutsy ?
[03:16] <JD> cjwatson: I think that one's going to be an forwarded to upstream
[03:19] <cjwatson> JD: good luck ...
[03:19] <JD> :)
[03:20] <cjwatson> saispo: because getting gfxboot working again after merging 3.36 took me several days of staring very hard at x86 assembly code. I have precisely no desire to do that again before gutsy
[03:20] <saispo> ok
[03:20] <saispo> because i have no gfxboot with gutsy isolinux
[03:21] <saispo> but work with feisty isolinux...
[03:21] <cjwatson> works for us. make sure you have upgraded your gfxboot and gfxboot-theme-ubuntu as well.
[03:21] <cjwatson> they need to be in sync as several formats changed incompatibly
[03:21] <saispo> i have the latest gfxboot for feisty yes
[03:21] <cjwatson> GUTSY
[03:21] <cjwatson> not feisty
[03:21] <saispo> yes
[03:21] <saispo> excuse me
[03:22] <cjwatson> I think you must have made a mistake somewhere around there then ...
[03:22] <cjwatson> or else it's a bug in the new code
[03:22] <saispo> the cd is generated well, but when i boot on
[03:22] <saispo> i just have
[03:22] <saispo> boot:
[03:22] <saispo> and i must press enter and the installation begin, but no gfx, and no menu
[03:23] <cjwatson> it is entirely possible for the CD to be generated properly with out-of-sync versions of syslinux, gfxboot, and gfxboot-theme-ubuntu; the fact that it was generated properly proves nothing, I'm afraid
[03:23] <cjwatson> we had that problem for quite some time in gutsy
[03:23] <cjwatson> if that is not your problem, I do not know what it is
[03:24] <saispo> will try... work well for me with dapper, edgy, feisty but not gutsy
[03:24] <saispo> cjwatson: ok, i will say you the result of my test
[03:42] <saispo> cjwatson: i add gfxboot, syslinux, gfxboot-theme-ubuntu on my custom seeds and it work...
[03:43] <saispo> but why germinate don't grab it or something else, don't know
[03:44] <cjwatson> glad it worked. we don't seed it ourselves
[03:44] <cjwatson> (except for sticking gfxboot and gfxboot-theme-ubuntu in supported)
[03:46] <saispo> in my STRUCTURE file i have not supported in the list of my seeds
[03:46] <saispo> maybe this
[03:46] <saispo> ?
[03:46] <saispo> thanks for your advice, i will inspect this...
[04:26] <xivulon> evand, I noticed that casper/scripts/casper-bottom/24preseed interprets paths passed via preseed/file as relative to /root (i.e. squashfs), is that the intended behaviour?
[04:29] <cjwatson> hmm, sort of
[04:30] <cjwatson> actually, yes, it is. is there a problem with that?
[04:30] <cjwatson> /root seemed like an implementation detail that shouldn't be exposed
[04:35] <xivulon> cjwatson, not a problem, I was expecting the preseed paths to be absolute (so that you can pass a preseed in the initrd or /cdrom), i'll have to rectify my code for that, no big deal
[04:35] <cjwatson> /cdrom should be bind-mounted as /root/cdrom by that point
[04:36] <cjwatson> in fact move-mounted
[04:36] <cjwatson> cf. casper/scripts/casper-bottom/05mountpoints
[04:37] <xivulon> hence /cdrom/* paths would still work... got it
[04:38] <cjwatson> I think initrd preseeding is better done by hardwiring code to load /preseed.cfg if it exists, like d-i does
[04:38] <cjwatson> no need to make that configurable with preseed/file
[04:40] <cjwatson> I'll do that now. Won't help with locale or keyboard configuration at present though (nor will preseed/file) - those still need to be passed on the command line
[04:40] <xivulon> how does load/preseed.cfg work exactly? where do I find the relevant code?
[04:41] <cjwatson> preseed/debian-installer-startup.d/S35initrd-preseed
[04:41] <xivulon> what my find_preseed script does at the moment, it finds a preseed file on HD (scanning all block devs) and copies it on another location (specified in preseed/file)
[04:41] <cjwatson> but there's not much to say; if /preseed.cfg exists in the initrd, it loads it
[04:42] <xivulon> sure, I was asking about initrd preseed to evand
[04:42] <xivulon> he mentioned that it was not implemented in ubiquity and suggested to use preseed/file
[04:42] <cjwatson> right, I understand your problem that it needs to go on a disk
[04:43] <cjwatson> let me get some coffee and think about it
[04:43] <xivulon> originally find_preseed would copy the preseed file onto / (or should it be /root???)
[04:43] <cjwatson> / is fine
[04:44] <cjwatson> well, if it lands in /preseed.cfg and is done before 24preseed
[04:44] <xivulon> yep that's handled by 07find_preseed http://codebrowse.launchpad.net/~ago/lupin/gutsy/annotate/ago%40nb-ago-20070828232545-yq4hwd9yh08j60vw?file_id=07find_preseed-20070822005932-q4z4avo19xlog9up-6
[04:45] <xivulon> You'd need to edit line 24 and remove lines 30-35
[04:45] <cjwatson> ok, if that just copies it to /preseed.cfg in the initrd, all's good
[04:45] <cjwatson> I'll upload casper now to make that work
[04:46] <cjwatson> CR/LF is accepted fine, as I said
[04:46] <xivulon> great
[04:46] <cjwatson> I just changed partman-auto-loop to bail out if any of the specified image paths already existe
[04:46] <cjwatson> -e
[04:46] <cjwatson> should help with one of your other comment blocks
[04:46] <xivulon> yes
[04:47] <xivulon> the check can also be performed within check_loopinstall_folder always in 07find_preseed #76
[04:48] <cjwatson> up to you, just seemed neat to put it with the partman stuff
[04:48] <xivulon> the advantage of having it in partman is that it will be checked even when you do not use HD preseeding
[04:49] <cjwatson> probably no harm in it being in both places if you like
[04:50] <xivulon> whatever you prefer, we can maybe factor out the checks used by partman so that I use the same routine
[04:51] <cjwatson> I doubt that's feasible unfortunately
[04:51] <xivulon> n.p.
[04:51] <cjwatson> the hard bit is picking apart the preseeding to find the image paths, and then the rest is debconf error handling which you probably can't use
[04:52] <xivulon> lupin-helpers can be merged with casper-helpers
[04:52] <xivulon> http://codebrowse.launchpad.net/~ago/lupin/gutsy/annotate/ago%40nb-ago-20070828232545-yq4hwd9yh08j60vw?file_id=lupinhelpers-20070822005932-q4z4avo19xlog9up-5
[04:54] <xivulon> Last bit required for stand-alone installer is find_iso http://codebrowse.launchpad.net/~ago/lupin/gutsy/annotate/ago%40nb-ago-20070828232545-yq4hwd9yh08j60vw?file_id=20find_iso-20070822005932-q4z4avo19xlog9up-7
[04:54] <cjwatson> (coffee has got more urgent. excuse me)
[04:56] <xivulon> when you are back: re image-paths in preseed, I actually do the reverse in find_preseed>fix_preseeed:
[04:57] <xivulon> since in my case preseed is generated from within windows, and linux devices are unknown, I have a file pattern within the preseed file which is used to discover the actual linux device
[04:57] <xivulon> The preseed is then passed through sed to set the appropriate device
[04:58] <xivulon> All this to say that image-paths are known in my case, since part of the preseed file must be generated/edited within find_preseed
[05:03] <cjwatson> I think it makes most sense for lupin-helpers to remain separate, since it's really just there for the lupin scripts
[05:04] <cjwatson> could we move lupin under ~ubuntu-installer so that we can commit to it directly? I can add you to the ubuntu-installer team (you applied a while back)
[05:05] <xivulon> Sure, I'd be glad, but I can only commit when I am at home
[05:05] <cjwatson> xivulon: are you set up to be able to do mail filtering? the ubuntu-installer team gets all ubiquity bugs, so the volume can be quite high there, and I don't like to add people without checking that they're prepared for that
[05:05] <cjwatson> at home> understood
[05:06] <cjwatson> just that it would let me release packages for you :-)
[05:06] <xivulon> of course
[05:06] <xivulon> ;P
[05:06] <cjwatson> (we want this in main, so ...)
[05:06] <xivulon> re filtering, I use gmail, which should be fine
[05:07] <cjwatson> ok, approved then
[05:07] <xivulon> thanks
[05:07] <cjwatson> I suggest you filter anything with X-Launchpad-Bug:
[05:07] <cjwatson> shall I push ~ago/lupin/gutsy to ~ubuntu-installer/lupin/gutsy then?
[05:08] <xivulon> Sounds good to me
[05:08] <cjwatson> you can then just do 'bzr bind bzr+ssh://bazaar.launchpad.net/~ubuntu-installer/lupin/gutsy' to switch over to that
[05:08] <xivulon> line 24 and remove lines 30-35
[05:08] <cjwatson> mkay
[05:09] <xivulon> As mentioned to do initrd preseed, you need to remove line 24 and remove lines 30-35 in find_preseed
[05:09] <xivulon> sorry I mean you need to EDIT line 24 and remove lines 30-35
[05:09] <cjwatson> right, I'll prod that and turn it into a package
[05:09] <cjwatson> I assume you're OK for this to be packaged as 'lupin' in Ubuntu?
[05:10] <cjwatson> just like to confirm these things :)
[05:10] <xivulon> line 24 and remove lines 30-35
[05:10] <cjwatson> I understand, you can stop saying that now ;-)
[05:10] <xivulon> stat rosa pristina nomine, nomina nuda tenemus
[05:11] <cjwatson> anyone else on the lupin team is welcome to membership of ubuntu-installer if they jump on here and confirm mail filtering
[05:12] <cjwatson> heh, my Latin isn't what it used to be, I had to look that up
[05:12] <xivulon> I think geza kovacs would be glad to take part, but I do not think he is reading this at this point, it would be better to send him an email (I can do that)
[05:12] <cjwatson> well put
[05:15] <cjwatson> 30-35> did you mean 33-38? I don't see why you'd want to remove file= support but not preseed/file=
[05:16] <xivulon> yep
[05:17] <cjwatson>     mkdir -p "${PRESEED}"
[05:17] <cjwatson> "${PRESEED%/*}" I suspect that should be
[05:18] <xivulon> I forwarded your offer to the other wubi devs: geza, ecology (NSIS interface), hampusW (downloader). I asked them to send you an email directly if interested, hope you do not mind
[05:19] <cjwatson> no problem
[05:19] <cjwatson> I'm conscious I'm late and am keen to get this in place for gutsy
[05:20] <xivulon> I think the backend is almost there, we should start also thinking about the windows GUI...
[05:20] <cjwatson> indeed
[05:23] <evand> Is there anything particularly wrong with the current one, or did we decide to ask the questions in ubiquity and I just forgot?
[05:24] <cjwatson> it needs to land on the CDs ...
[05:24] <cjwatson> we didn't decide to ask the questions in ubiquity AFAIK
[05:24] <cjwatson> xivulon: suitable Maintainer address for lupin?
[05:25] <evand> ahh, indeed
[05:28] <xivulon> cjwatson I can maintain lupin code, there is not much left anyway
[05:28] <cjwatson> sure, I just need an address to put in the control file
[05:29] <cjwatson> agostino.russo@gmail.com?
[05:29] <xivulon> evand,cjwatson, re interface, you can see the current one in: http://wubi-installer.org/screenshots.php
[05:29] <xivulon> cjwatson yes, that's the email
[05:29] <xivulon> as you see there are 6 questions.
[05:30] <xivulon> username/password: do we keep it in the windows frontend or move it to ubiquity?
[05:30] <cjwatson> windows
[05:31] <evand> should the windows frontend grab that list of reserved users out of the iso then?
[05:31] <xivulon> desktop environment: my understanding is that the field will be hidden when we launch from CD
[05:31] <cjwatson> the duplication will be a pain but it's not worth the UI awfulness to avoid it
[05:31] <cjwatson> evand: we might have to figure out some build magic
[05:31] <evand> ok
[05:31] <cjwatson> like build-depending on user-setup and grabbing the file from there or something
[05:31] <cjwatson> but no rush
[05:32] <cjwatson> xivulon: licence for lupin?
[05:32] <xivulon> Anything you wish to change in current interface other than branding?
[05:32] <xivulon> gplv2
[05:32] <cjwatson> honestly right now I just want it in place
[05:32] <cjwatson> thanks
[05:32] <xivulon> do you prefer gplv3?
[05:33] <cjwatson> I don't care
[05:33] <cjwatson> v2 or later maybe?
[05:33] <cjwatson> but obviously up to you
[05:33] <xivulon> ok
[05:34] <cjwatson> xivulon: confirm http://pastebin.ubuntu.com/37/ ?
[05:35] <xivulon> Sounds good to me
[05:37] <xivulon> cjwatson, one think I thought should mention is that find_iso will mount the device hosting the iso file (/isodevice), not sure if that affects other casper scrpits that scan devices
[05:38] <cjwatson> something might want to move-mount that into /root, not sure
[05:38] <cjwatson> maybe not
[05:38] <cjwatson> probably won't be a problem, but if it is it should be easy to solve
[05:40] <xivulon> I use the LIVEMEDIA trick to have the ISO mounted on /cdrom thus using existing casper code
[05:41] <cjwatson> I've committed initial packaging
[05:41] <xivulon> Thanks
[05:41] <cjwatson> wouldn't it be better to just mount it on /cdrom directly
[05:41] <cjwatson> ?
[05:41] <cjwatson> LIVEMEDIA is a bit of a fuckup perpetuated by Debian
[05:41] <cjwatson> in fact you have to use /cdrom otherwise ubiquity will get confused
[05:42] <xivulon> You mentioned that,
[05:42] <xivulon> But the advantage of using LIVEMEDIA is that I do not have to override casper/scripts/casper
[05:42] <cjwatson> oh, wait a sec, LIVEMEDIA isn't what I thought it was
[05:42] <xivulon> I just set LIVEMEDIA=/path/to/HD/ISO/file
[05:43] <cjwatson> so the /isodevice mount is purely internal to lupin?
[05:43] <xivulon> Then there is some code in casper that checks that before looking for CD-roms
[05:43] <cjwatson> yeah
[05:43] <cjwatson> I was thinking of the /live_media mount that existed in casper at one point until we ripped it out again
[05:43] <cjwatson> LIVEMEDIA looks fine
[05:44] <xivulon> good
[05:44] <cjwatson> I haven't packaged the xinit-ubiquity stuff - I have an untested diff sitting in my ubiquity tree that merges that into ubiquity
[05:44] <xivulon> I haven't tested xinit-ubiquity yet
[05:44] <cjwatson> (which I'd never have got round to if you hadn't done the first version, so much appreciated)
[05:44] <xivulon> Also we now need initrd preseeding in ubiqity!
[05:44] <cjwatson> err. why?
[05:45] <cjwatson> ubiquity doesn't do any preseeding
[05:45] <xivulon> I mean in the livecd initrd
[05:45] <xivulon> casper
[05:45] <cjwatson> it just processes stuff set by casper
[05:45] <cjwatson> oh, I already uploaded casper 1.98 to do that
[05:45] <xivulon> casper/casper-bottome/24preseed -> check for /preseed.cfg
[05:45] <cjwatson> update :-)
[05:46] <xivulon> you are quick
[05:46] <cjwatson> it'll take a short while to build and stuff, but it's in the queue
[05:48] <xivulon> did you work on sysctl by any chance?
[05:50] <xivulon> Also on disabling suspend/hibernation, last time you mentioned acpi-support, but the issue is that we need to remove the suspend/hibernate buttons from gnome/kde dialogs and to my knwledge (admittedly very limited) that is not achieved via acpi-support but via policy commands
[05:53] <cjwatson> sysctl> not yet :-(
[05:53] <xivulon> I may try tonight
[05:53] <cjwatson> we could just nobble powermanagement-interface
[05:53] <cjwatson> that would be OK
[05:54] <cjwatson> and probably a hell of a lot easier
[05:58] <xivulon> looking at it
[06:02] <xivulon> I notice that /usr/sbin/pmi > query (capabilities) will return the value of /etc/default/acpi-support:ACPI_SUSPEND/ACPI_HIBERNATE
[06:03] <xivulon> In my naive world, gnome and kde should query pmi for capabilities before displaying suspend/hibernate buttons, hence by editing /etc/default/acpi-support you should be able to hide the buttons
[06:04] <xivulon> Last time I tried it though, it did not quite work like that...
[06:10] <cjwatson> they certainly used to query it
[06:10] <cjwatson> I was thinking of editing the pmi script
[06:10] <cjwatson> should be trivial
[06:15] <xivulon> Do you mean pmi query and pmi capability? As mentioned, last time I tried, whatever value is returned there, the gnome suspend/hibernate buttons are still displayed
[06:16] <xivulon> But maybe I did something wrong.
[06:16] <cjwatson> gnome-session?
[06:18] <xivulon> cjwatson, don't take my word for it, have a go (should be sufficient to edit /etc/default/acpi-support).
[06:18] <cjwatson> tricky on powerpc ;-) but yes
[06:18] <cjwatson> I'm reading the source instead
[06:20] <xivulon> The only way I found to disable those buttons was via gnome policies, via gconftool-2 --set --type bool /apps/gnome-power-manager/can_hibernate false
[06:21] <xivulon> I'll give it another go to the pmi approach tonight, as mentioned I'd expect gnome to check pmi capabilities at startup.
[06:23] <cjwatson> evand: not required for gutsy
[06:23] <evand> s/whatever/what/
[06:24] <cjwatson> (it's, uh, a top-down thing ...)
[06:24] <evand> did he ever get back to you on what he wanted, or is it still a matter of other pieces coming together first?
[06:27] <cjwatson> I think I understand what's wanted, but word is it is not urgent and there are more important things to do
[06:27] <cjwatson> (AIUI the plan is jabber)
[06:27] <evand> ah, indeed
[06:27] <xivulon> cjwatson, looking at this https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/47303
[06:27] <evand> oh, I thought it was jabber + openid
[06:28] <xivulon> seems like can_suspend is set in postinst and not at gnome startup
[06:29] <cjwatson> is that relevant though? I thought this stuff was implemented by gnome-session and gdm
[06:34] <cjwatson> oh, I'm wrong, gnome-session queries gpm
[06:34] <cjwatson> you are in a twisty maze of packages, all subtly different
[06:34] <xivulon> and I didn't dip into kde yet...
[06:49] <xivulon> evand, can we have an m-a "light-settings" option in m-a as discussed some time ago'?
[06:49] <xivulon> light-settings=all settings that do not involve large files. E.g. contacts yes, emails no, desktop background yes, myimages no...
[06:51] <evand> hrmm, sure
[06:52] <xivulon> AIM Triton, Internet Explorer, Yahoo, MSN, Opera, Firefox, Wallpaper, User Picture, Outlook Express, Gaim
[06:52] <xivulon> ...for instance
[06:52] <evand> indeed, nothing that requires copying large amounts of data around
[06:53] <xivulon> yeah, that is a good default for wubi. I do not see why people should avoid their bookmarks and contacts, but I can understand why they may want to skip their emails or music collection
[06:53] <evand> in the meantime you can always preseed those options.  m-a wont fail if it can't find something.
[06:53] <evand> err, it wont cause the d-i component to fail, that is
[06:53] <xivulon> I am alreading doing that
[06:54] <xivulon> The ones I preseed are the ones you see above
[06:54] <evand> ah, indeed
[07:21] <cjwatson> xivulon: ok, I've fixed hal to honour pmi; will upload that shortly
[07:28] <xivulon> that's great
[07:28] <xivulon> cjwatson, evand, if you did not notice the grub4dos devs have made the required changes, so relative paths in menu.lst are now supported
[07:28] <cjwatson> I got your mail about that
[07:29] <xivulon> All is required on your side is to set menu.lst to: #groot(hdX,Y)/host/ubuntu/
[07:30] <cjwatson> "grep -q ' /host fuse' /proc/mounts" is a sufficient test to stick in pmi, right?
[07:30] <cjwatson> if that matches, then disallow suspend and hibernate
[07:31] <xivulon> hibernate I would suspend if swap is on a file (if I understood that correctly), suspend if / is mounted via fuse
[07:33] <cjwatson> so if (swap is on file); then (do not hibernate)?
[07:33] <xivulon> So is my understanding
[07:34] <xivulon> E.g. I might loopmount on top of ext3. In this case suspend should work (no fuse) but hibernation will not.
[07:34] <xivulon> A more relevant case might be vfat, but I did not specifically test hibernation/suspend in there
[07:36] <xivulon> Probably better: if fuse is used when mounting / OR swap is on file do not hibernate
[07:37] <xivulon> if fuse is used when mounting / do not suspend
[07:37] <cjwatson> swapon -s | tail -n +2 | awk '$2 == "file" { exit 1 }'
[07:37] <cjwatson> ^-- test for swap on file
[07:42] <cjwatson> done, powermanagement-interface 0.3.16
[07:45] <xivulon> #groot(hdX,Y)/host/ubuntu/
[07:45] <cjwatson> yeah, I have to go out now though
[07:45] <cjwatson> that's your lot for today :-)
[07:46] <xivulon> typo #groot(hdX,Y)/host/ubuntu should read #groot(hdX,Y)/ubuntu/
[07:46] <cjwatson> ok
[07:47] <xivulon> #groot(hdX,Y)/host/ubuntu/
[07:47] <xivulon> I have this web chat client that submits messages when I type ctrl+v, apologies
[07:47] <cjwatson> I did wonder :)
[07:49] <xivulon> Anyway wanted to say that the path might be /ubuntu/disks or whatever is the folder that contains "boot" as seen from the windows side
[07:51] <xivulon> so whatever is bindmounted to /boot stripped out of "/host" and "/boot": /host/ubuntu/disks/boot -> groot(hdX,Y)/ubuntu/disks
[08:34] <xivulon> evand, I was reading about bulletproof-x
[08:35] <xivulon> I noticed that not there is a feature whereby you can scan the CD for *inf files
[08:35] <xivulon> To get monitor refresh rates and such
[08:36] <xivulon> Thirst thing I though is why not scanning the HD as well?
[08:37] <xivulon> That would be a nice m-a add-on that may potentially address several X configuration issues
[08:41] <evand> hrmm, 'tis an interesting idea, but I think the xorg maintainers would treat the inability to grab the right refresh rate as a bug.
[08:42] <xivulon> I was reading http://arstechnica.com/journals/linux.ars/2007/08/29/ubuntu-xorg-maintainer-demonstrates-bulletproof-x
[08:42] <evand> hrmmm
[08:42] <xivulon> "Unfortunately, it doesn't work to select just any of the generic monitors, so users may find they need to trial-and-error a solution. Fortunately, there is a cool new featureAdd Model which allows users to add a new monitor by using the Windows driver CD"
[08:44] <xivulon> On m-a side I would simply copy all *.inf files in *\windows into a /etc/wininf folder and have suche inf parser look for that folder
[08:44] <evand> indeed, I'll have to talk to bryce about it and add it to the todo list.  Neat!
[09:23] <superm1> evand, were you guys aware that the button for release notes wasn't working?
[09:25] <superm1> we were going to publish, and then picked up on that
[09:25] <evand> arr lame, no I wasn't.  I'll look into that now.
[09:55] <evand> superm1: it appears to be a gtk bug.  Still investigating though.
[09:56] <superm1> evand, okay well i guess that's good and bad news.
[09:56] <superm1> evand, since it probably is affecting a few other pyGTK apps i've written :)
[09:56] <evand> heh
[09:59] <evand> yeah, manually constructing a LinkButton in the python console in the LiveCD and on my gutsy system has the same problem of not launching firefox.
[10:02] <superm1> live cd being tribe5 shipped with this issue?
[10:02] <superm1> or it showed up later
[10:08] <evand> hrm, lets see
[10:17] <evand> sometime after tribe 3.  I'll narrow it down further in a bit.
[10:40] <evand> seems to be an issue prior to tribe 5
[10:44] <superm1> is there a gtk bug made for it yet?
[10:44] <superm1> that you found
[10:44] <evand> haven't looked yet