[01:11] <CIA-59> ubiquity: cjwatson * r2818 ubiquity/ (debian/changelog ubiquity/filteredcommand.py):
[01:11] <CIA-59> ubiquity: Fix mysterious crash if a debconffilter doesn't get started for some
[01:11] <CIA-59> ubiquity: reason (LP: #125538).
[04:17] <CIA-59> usb-creator: evand * r12 usb-creator/ (7 files in 5 dirs):
[04:17] <CIA-59> usb-creator: * Properly set the labels of the progress dialog on install startup.
[04:17] <CIA-59> usb-creator: * Do not make the dialogs modal.
[04:17] <CIA-59> usb-creator: * Elevate privileges using gksu.
[04:17] <CIA-59> usb-creator: * Added a .desktop file (LP: #267788).
[08:13] <davmor2> is cdimages.u.c down?
[09:00] <cjwatson> 02:39 <MattJ> Is cdimage.ubuntu.com down intentionally?
[09:00] <cjwatson> 02:41 <james_w> MattJ: http://91.189.88.34/ should get you there
[09:00] <cjwatson> 02:41 <MattJ> james_w: thank you so much :)
[09:00] <cjwatson> 02:41 <james_w> only some of the servers behind cdimage are down, so going directly to one that isn't works
[09:17] <davmor2> cjwatson: ta :) Rsync still worked so I got the images I just need to see if they would work :)
[09:44] <soren> cjwatson: Are you familiar with di-live?
[09:44] <cjwatson> no
[09:44] <soren> https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002239.html
[09:45] <cjwatson> beyond a general awareness that they've gone down a road I investigated and decided was ultimately doomed
[09:45] <soren> Ah :)
[09:45] <cjwatson> er, hmm, this doesn't seem to be the same as the live CD stuff based on d-i
[09:46] <cjwatson> ok, in this case I'm actually not familiar with it at all, sorry
[09:46] <soren> These people have devised a system for creating live CD's for servery kinds of things, and then use this "di-live" thing to run the installer from that running system.
[09:46] <soren> It might be worth a look.
[09:47] <cjwatson> it looks fairly competently done
[09:48] <cjwatson> they've taken quite a similar approach to ubiquity in some ways
[09:49] <cjwatson> soren: yeah, I quite like the look of that. Certainly don't reject it out of hand
[09:49] <cjwatson> you could invite them in here
[09:49] <soren> Certainly.
[09:52] <soren> done
[10:02] <xivulon> cjwatson would it be feasible to avoid O_DIRECT flags in parted_server?
[10:03] <cjwatson> did upstream say they couldn't fix it to actually work?
[10:04] <cjwatson> we could make parted fall back from O_DIRECT to !O_DIRECT
[10:05] <cjwatson> we can't just drop it - it was added for a reason
[10:05] <xivulon> I have asked both szaka and cking but got no reply so far, szaka mentioned in the bug he would add it to the todo list, but I am not sure how long that will take nor if he means honouring O_DIRECT or ignoring O_DIRECT
[10:06] <xivulon> fall back will do!
[10:06] <cjwatson> that should be straightforward
[10:06] <cjwatson> I doubt it matters much whether it's honoured or ignored, for loopback
[10:07] <cjwatson> it just needs to be not rejected
[10:07] <cjwatson> (at least from parted's point of view; I can see why szaka might feel it's hard to do properly)
[10:07] <xivulon> that is what I asked him to do indeed
[10:08] <cjwatson> hmm, open(2) documents that some file systems may ignore it
[10:08] <cjwatson> sorry, may not implement it - and may fail with EINVAL
[10:08] <cjwatson> so maybe working around it in parted is actually the right thing to do
[10:12] <xivulon> I have opened bug #269947
[10:14] <cjwatson> something like http://paste.ubuntu.com/47108/ should do it
[10:18] <xivulon> looks good, I could test that tonight
[10:19] <cjwatson> I'll upload it once I've done some basic testing
[10:19] <xivulon> thanks a lot
[10:20] <cjwatson> oh, hang on, soren already disabled O_DIRECT altogether
[10:20] <cjwatson> soren: would a fallback not be better?
[10:20] <davmor2> Guys give me a ping when you have a working solution that I can test and I'll run it on all versions of windows :)
[10:20] <soren> cjwatson: That's what I started out with, but Jim Meyering thought otherwise.
[10:21] <soren> Well, actually some dude from SuSE though otherwise, and Jim agreed.
[10:21] <cjwatson> really? interesting. so in that case why is the bug still open? :)
[10:22] <soren> It's not.
[10:22]  * soren whistles
[10:22] <soren> bug 252684
[10:23] <cjwatson> I'll dup, thanks
[10:23] <soren> http://lists.alioth.debian.org/pipermail/parted-devel/2008-August/002392.html
[10:24] <soren> Sorry about the lack of paperwork.
[10:25] <cjwatson> davmor2: today's image should already have Soren's fix
[10:28] <davmor2> cjwatson: cool I'll see how things go then :)
[10:28] <davmor2> xivulon: has the latest wubi been included on the cd yet?
[10:37] <xivulon> should be rev 507
[10:37] <xivulon> check also that busybox is the right version (ubuntu6 if I recall correctly)
[10:38] <xivulon> yes busybox is there too
[10:41] <CIA-59> ubiquity: cjwatson * r2819 ubiquity/ (apport/ubiquity.py debian/changelog): Add /var/log/casper.log to apport-generated bugs.
[10:42] <xivulon> davmor2 all seems in order, please test
[10:42] <davmor2> xivulon: Np's I'll give it a whirl after I get some smoke tests out of the way :)
[11:31] <cjwatson> OK. If you have a casper branch (assuming it's just following trunk, and that you don't have any extra revisions on it), then please remove it and check it out again.
[11:32] <cjwatson> If you have a non-trivial branch with some unmerged revisions, then please talk to me and we'll get it sorted out
[11:39] <davmor2> cjwatson: I've got issues with the display of the new partition viewer on ubiquity
[11:41] <davmor2> I'll take an image of it after and post it somewhere so you can see what I mean.
[11:52] <davmor2> Hmmm an attempt to configure apt to install additional packages from the CD failed not good :(
[12:06] <exodos> hi, im trying to use ubuntu-installer to install hardy on xen domU
[12:06] <exodos> (as described in here: http://wiki.debian.org/DebianInstaller/Xen)
[12:07] <exodos> the problem is d-i partitioning is not working so I'm looking for a way around it
[12:08] <exodos> i started terminal, created partitions and filesystems, and mounted the rootfs on /mnt
[12:09] <exodos> is there a way do say d-i that partitioning is already done and it can proceed with base system installation?
[12:13] <cjwatson> yes, but with caveats
[12:13] <cjwatson> you'll need to mount it on /target, not /mnt
[12:13] <cjwatson> you will need to create /target/etc/fstab
[12:14] <cjwatson> with that in mind, edit /var/lib/dpkg/info/partman-base.postinst and put 'exit 0' on the second line
[12:14] <cjwatson> stuff might go wrong later; this is not a usual path ...
[12:14] <exodos> cjwatson: I will check that, thx a lot!
[12:27] <exodos> are there any plans for future to make d-i working under xen?
[12:32] <cjwatson> I thought it was mostly a matter of providing a suitable kernel, but honestly I know very little about it
[12:36] <alonswartz> soren: I'm one of the developers behind TurnKey Linux, and the author of di-live. I heard you had some questions so I thought I'd drop in here and say hi.
[12:55] <davmor2> cjwatson: Any idea why if you try installing ubuntu on the live cd directly (rather than through live session) you get the wrong theme?
[12:56] <davmor2> you get the default gnome theme (grey/blue bar etc)
[13:07] <davmor2> xivulon: Yay it worked :)  Wubi in XP installed :)
[13:13] <xivulon> davmor2 good news :)
[13:13] <xivulon> davmor2: couple of things to test a) install a new kernel b) see if suspend/hibernation works
[13:14] <xivulon> the latter was disabled, but it __might__ be that the 27 kernel supports suspending to a swap file
[13:15] <xivulon> you might to enable hibernation manually or run the underlying commands (let me have a quick look)
[13:26] <xivulon> apparently uswsusp can support hibernation to a swap file...
[13:30] <cjwatson> davmor2: I've noticed that it seems to be a sort of halfway house (it's not quite the default GNOME theme, I don't think, but it's certainly not ours either), but I don't know why
[13:31] <cjwatson> alonswartz: I don't have any specific questions about di-live (I've only had a chance to glance over it), but I noticed there was some inspiration from ubiquity there and it seemed to be rather well-written, so I thought you should be invited in here and that this would be the best place for discussions of it
[13:33] <alonswartz> cjwatson: thanks for the invitation, and compliment.
[13:34] <cjwatson> also in case there was anything you were stuck on ...
[13:34] <alonswartz>  Yes, I built heavily on ubiquities design in leveraging d-i code. I originally thought that I would patch ubiquity to support installation from the console, but when I got into the thick of things, I realized that the way to go was modular...
[13:35] <cjwatson> the reimplementation of main-menu is a nice idea; I did try that sort of approach originally for oem-config (whose general design grew into ubiquity) but found there were too many crossovers
[13:35] <cjwatson> actually, if I were doing ubiquity over again I'd probably take that kind of approach. The current ubiquity main loop came from Guadalinex' code and I was never very happy with it.
[13:36] <cjwatson> most of ubiquity's complexity is due to the requirement for a designed UI rather than one generated from the debconf protocol, though.
[13:36] <cjwatson> I take it you're just using debconf's dialog interface?
[13:37] <alonswartz> yes, i noticed that. I understand that ubiquity came out of the need for a GUI installer, it was just a pity that d-i got wrapped up in that
[13:37] <cjwatson> mm, I didn't want to maintain two partitioners. :)
[13:37] <alonswartz> hehe...
[13:37] <alonswartz> in the long run it would have been easier ;)
[13:37] <cjwatson> in fact there were a lot of things where I felt the, uh, business logic was the hard bit and I still feel it's worth not duplicating that
[13:38] <cjwatson> plus I like d-i and wanted to make use of it. :)
[13:38] <alonswartz> in the future, it might be an idea to consider seperating the GUI code from the d-i code for maintainance and modular reasons
[13:39] <alonswartz> re-using d-i code is definately the way to go
[13:39] <alonswartz> no point in re-inventing the wheel
[13:39] <cjwatson> I'd like to figure out a clearer way to do debconffilter. I think it's the right general approach but it's undeniably hard to program in. Maybe the problem is that it isn't really testable
[13:39] <cjwatson> (automatically)
[13:40] <cjwatson> or maybe the problem is that most programmers have trouble wrapping their heads around state machines
[13:41] <cjwatson> the reason it's interwoven is that there are lots of cases where we need to advance the d-i code just a little bit (rather than by a whole component) in order to figure out how to update the UI
[13:41] <cjwatson> the partitioner is the really obvious case, but e.g. keyboard configuration too
[13:42] <cjwatson> originally I wanted to do it by way of cdebconf custom widgets
[13:46] <alonswartz> its a really interesting concept - creating a debconf filter layer for interception (and possibly injection), but undoubtably complex
[13:49] <alonswartz> how did you perform testing, seems to me like a nightmare, especially if you say that auto-testing is out of the questions
[13:54] <cjwatson> unfortunately most of the testing I did was system testing, just plug it in, watch the debug information, and see if it's driving it the right way
[13:54] <cjwatson> I don't think auto-testing is out of the question, but I'm not very good at building test harnesses
[13:54] <cjwatson> the trick is figuring out how to isolate the d-i code, I think
[13:55] <cjwatson> and instrument the bits you can't isolate
[13:55] <cjwatson> we've managed successful unit testing of some small bits of d-i, like the kernel selection code in base-installer, but nobody's managed to build a test harness for the partitioner yet
[13:56] <cjwatson> the usual failure mode with debconffilter is that the d-i code heads off down some path you didn't predict
[13:56] <alonswartz> one of the barriers i found when coding di-live, was testing. Most of my testing was done in a segregated chroot, but testing the partitioner was done in a vm. I can only imagine the extra hurdles you had to jump over with the debconf filtering layer...
[13:59] <alonswartz> have you thought of any other approaches than the filtering layer ?
[14:01] <cjwatson> only custom widgets (i.e. "Type: timezone_map" in a templates file that invokes special debconf plugin, that sort of thing)
[14:01] <cjwatson> the problem with that is that it tends to involve substantial changes to the d-i code, and you end up basically copying and pasting chunks of it into the GUI plugin since it needs to do much the same job
[14:02] <cjwatson> so in the end I rejected that idea as not viable
[14:06] <alonswartz> i have not given GUI interaction much thought, but it seems like an interesting problem to solve, especially the priority of code-reuse
[14:14] <alonswartz> when performing the copy of the live filesystem, you use /rofs as the source. From what I understand you do this for "maximum reproducability" - have you considered adding the option of copying the overlay aswell ?
[14:17] <alonswartz> overlay = live overlay (with possibly a  white or black list)
[14:24] <cjwatson> I'm open to suggestions, but I've never seen a way to do it well
[14:24] <davmor2> xivulon: it's todays cd and seems to be the most up-to-date kernel suspend failed to restart
[14:24] <cjwatson> mostly people want to copy user-level customisations and such, and those aren't just a matter of copying the overlay in a desktop environment; the username is different, and gconf has a habit of embedding the username into its database as well
[14:25] <cjwatson> so it would have to be quite a sophisticated operation
[14:25] <cjwatson> it's possible that it would work better in serverland
[14:28] <alonswartz> its a feature that i plan on working on in near future for di-live. implementing it in serverland should be easier though.
[14:30] <alonswartz> besides for user customizations, did you come across any instability issues regarding certain live content that you *don't* want in the installed system ?
[14:32] <cjwatson> well, the thing to be careful of with copying the live overlay is that the user's quite able to change files in e.g. /usr
[14:33] <cjwatson> you definitely can't copy the whole overlay, because it includes the customisations made by casper to make the system bootable as a live CD; you don't want those on the installed system
[14:33] <cjwatson> so you have to be selective. The easiest way to be selective is just to copy things in /home
[14:34] <cjwatson> then what if the user upgraded a package from backports (not that uncommon) on the live CD, and used it? That could easily result in data in /home that the installed system can't read, unless you figure out how to copy everything except for casper's modifications
[14:35] <cjwatson> at some point of course you might decide that you don't care, but I didn't want to have to deal with the sort of wildly complicated bug report that this could result in
[14:35] <cjwatson> I figured KISS was the way forward :)
[14:37] <xivulon> davmor2 did it use to work on your machine/vm in 8.04?
[14:37] <alonswartz> i suppose it depends on what the objective of copying the live system state to the hard disk would be.
[14:38] <davmor2> xivulon: can't remember I think it worked on the intel based machine I'll try it on vista after and see
[14:38] <alonswartz> in the case of a server type appliance the user might want to test out the system live, maybe configure a database, install or configure a cms or what ever, and then decide thats what he wants. it would then be nice to have the option whether to install the vanilla system, or the customized system
[14:39] <cjwatson> right, I agree that the appliance case is very different
[14:39] <alonswartz> i suppose its a all or nothing situation, if the user installs packages, customizes configurations, etc. then you have to take all the data across
[14:39] <cjwatson> one approach would be to extend casper to be able to reverse all its modifications reliably
[14:40] <alonswartz> we have highly customized casper btw, so its not really an issue
[14:40] <cjwatson> oh, of course you also have to figure out how to reliably remove di-live itself from the target system; the ease of that depends on how many dependencies it has
[14:41] <cjwatson> in ubiquity's case we remove it using python-apt, which is easier since we know the state of the copied filesystem
[14:41] <alonswartz> nice catch, its on my todo list...
[14:42] <alonswartz> don't you do i diff of the installed packages and the manifest, or something like that?
[14:43] <cjwatson> we do a diff of two manifests
[14:44] <cjwatson> you could do it even if further packages had been installed if you were careful; only resolve problems by removing packages if those packages are in the diff between the two manifests
[14:46] <alonswartz> can you point me to the code that uninstalls ubiquity ?
[14:50] <cjwatson> yes, remove_extras in scripts/install.py
[14:51] <alonswartz> thanks ;)
[14:57] <alonswartz> it seems pretty involved. i was thinking of just passing a list of packages to be removed to apt in the target chroot - what am i missing ?
[14:58] <CIA-59> usb-creator: evand * r13 usb-creator/ (debian/changelog gui/usbcreator.glade scripts/install.py):
[14:58] <CIA-59> usb-creator: Work around a bug in syslinux wherein it can only find the configuration
[14:58] <CIA-59> usb-creator: file for the option labels in the root of the device.
[14:59] <cjwatson> alonswartz: robustness - if you do that and just one of them fails, apt may not remove any of the rest, or may leave the system in some kind of half-broken state
[15:00] <alonswartz> is their any reason it would fail? the system should be in prestine state, as its a direct copy of /rofs
[15:01] <alonswartz> and if it does fail, we could intercept the exception - which would then be a bug, and should be reproducable...
[15:04] <alonswartz> cjwatson: unfortunately i gotta run off to a meeting. it was great to finally meet you, and thanks for the informative chat. i'm sure we'll be chatting soon again...
[15:28] <davmor2> cjwatson: I thought the landscape-client was being dropped from desktop installs?
[17:44] <kirkland> cjwatson: fyi, i have tested the latest ISO, and mdadm/boot-degraded fix is verified \o/
[17:44] <cjwatson> excellent
[17:47] <kirkland> cjwatson: i just thought i'd note that, since I was unable to verify one small part of that, before publication of the updated package
[17:59] <Goosemoose> hey cjwatson. im picking up from last week. http://pastebin.com/d14f645a7 shows how the installer is failing when trying to join the domain using my script as part of late_command. the error is: Error: Unable to start daemon [code 0x00080018]. Is there some reason likewise wouldn't start? Should I try starting it manually even though it says it tried to start it?
[17:59] <cjwatson> Goosemoose: I'm honestly not sure how much I can help with this. I don't know likewise at all
[18:01] <cjwatson> Goosemoose: maybe putting 'mount /proc' at the start of your post_install_tasks script and 'umount /proc' at the end would help; it's possible /proc isn't mounted in the chroot at that point
[18:03] <Goosemoose> ok
[18:03] <Goosemoose> ill try that
[18:03] <Goosemoose> i cant find much on preseed and likewise on the forums at all
[18:03] <Goosemoose> I did get this as well: Sep 12 22:18:03 log-output: /target/etc/nsswitch.conf: No such file or directory
[18:04] <Goosemoose> as I was trying to remove the nsswitch.conf so I could wget a new copy. Does this just mean it hadn't been created by that point in the install process?
[18:04] <cjwatson> did you put /target/etc/nsswitch.conf in your post_install_tasks script, rather than /etc/nsswitch.conf?
[18:04] <Goosemoose> yes
[18:04] <cjwatson> you shouldn't have done that
[18:04] <cjwatson> put it back to /etc/nsswitch.conf
[18:04] <Goosemoose> oh, I thought you said everything was installed in the /target dir until reboot
[18:04] <Goosemoose> my mistake
[18:04] <cjwatson> and I also said that putting 'chroot /target' in front of the call to post_install_tasks was all you needed, and said several times that you shouldn't add references to /target to post_install_tasks
[18:05] <Goosemoose> ahh , very true. sorry about that
[18:05] <cjwatson> 'chroot /target /post_install_tasks' means, roughly, that everything in the post_install_tasks is implicitly done with reference to /target
[18:05] <cjwatson> so you don't need to, and shouldn't, refer to /target in there
[18:05] <Goosemoose> yeah i forgot I had changed to do that
[19:16] <cr3> what's that kernel parameter I could pass during installation of the alternate to interrupt the installation at some point, perhaps around early command?
[19:17] <cjwatson> I don't know of such a thing. You could make your early_command return an error :)
[19:21] <cr3> cjwatson: hm, I thought I recalled something of way to interrupt the installer but I guess there's not much use case for that... and there's an easy workaround as you pointed out :)
[19:23] <cr3> cjwatson: I wrote a nifty little program in C this weekend to check the log file for patterns which I will wrap in a shell script to test for specific phases of the installation
[19:23] <cr3> I'm quite anxious to try it out
[21:14] <Goosemoose> cjwatson, it looks like i got it to join the domain, who knows more about likewise though because it through a bunch of pam errors
[21:14] <Goosemoose> and wont let me login as a domain user
[21:44] <cr3> might someone have a good example of a project using autotools and packaged using cdbs both as a deb and a udeb?
[22:03] <hardwire> cr3: wireless-tools ?
[22:04] <hardwire> maybe not
[22:04] <cr3> hardwire: heh, doesn't use autotools nor cdbs :)
[22:04] <hardwire> I'm not on my game today.
[22:04] <hardwire> can't you query the source package lists via those fancy dpkg query tools?
[22:05] <hardwire> or grep
[22:06] <hardwire> cat /var/lib/apt/lists/*Sources | grep cdbs -B 10 | grep autotool -B 10 | grep Package
[22:06] <hardwire> maybe I'm insane
[22:06] <hardwire> I'd like to think it's a possibility
[22:06] <cr3> for some reason, DEB_DH_INSTALL_SOURCEDIR only applies to the deb which calls dh_install with --sourcedir but that argument is not used for the udeb
[22:11] <cr3> ok, so cdbs seems to be borked when using DEB_DH_INSTALL_SOURCEDIR. using DEB_DH_INSTALL_ARGS := --sourcedir=$(DEB_DESTDIR) seems to work
[22:17] <Goosemoose> cjwatson: Sep 15 17:38:12 log-output: /post_install_tasks: 14: unmount: not found
[22:17] <Goosemoose> cjwatson: looks like unmount /proc isn't valid. i don't see an error for the mount which is strange
[22:27] <evand> Goosemoose: shouldn't that be umount?
[22:27] <Goosemoose> evand, that might explain it ;)
[22:27] <Goosemoose> thanks
[22:28] <evand> no problem
[22:29] <Goosemoose> time to restart and try another network install
[23:15] <xivulon> wubi 8.10 seems ok now
[23:21] <cjwatson> hardwire: grep-dctrl is your friend
[23:21] <cjwatson> Goosemoose: likewise> don't know, you could try #ubuntu-server
[23:21] <hardwire> cjwatson: totally.. I totally forgot the command
[23:22] <Goosemoose> cjwatson, that's where im trying right now