| === superm1_ is now known as superm1 | ||
| === cjwatson_ is now known as cjwatson | ||
| xivulon | cjwatson, when you have a couple of minutes can we discuss about wubi inclusion plan? | 09:58 |
|---|---|---|
| === cjwatson_ is now known as cjwatson | ||
| xivulon | cjwatson ping | 13:32 |
| cjwatson | xivulon: pong. It's always better just to say the thing you would have said after the ping, rather than the ping/pong game | 13:35 |
| xivulon | Hi colin, as mentioned previously wanted to discuss about wubi inclusion, is that ok to do it now? | 13:36 |
| cjwatson | what about it? :-) | 13:42 |
| cjwatson | IRC has lots of latency; I find it better to just accept the latency and have a laggy conversation rather than trying to find times that suit everyone ... | 13:42 |
| xivulon | first did you do any work on that yourself/evand? | 13:43 |
| cjwatson | not since UDS; dunno about evand | 13:43 |
| cjwatson | I have been busy with spec approval, roadmap preparation, performance reviews | 13:43 |
| cjwatson | etc. | 13:43 |
| xivulon | second, I think it would be easier to add the hardy branch to daily build (did not check if it's already there) | 13:43 |
| cjwatson | hardy branch of wubi? sure | 13:44 |
| xivulon | then we remove hack by hack | 13:44 |
| xivulon | branch for lupin | 13:44 |
| xivulon | https://code.launchpad.net/~ubuntu-installer/lupin/hardy | 13:44 |
| cjwatson | ok | 13:44 |
| xivulon | at the moment that is the same for gutsy | 13:44 |
| cjwatson | oh, then there's nothing to do | 13:44 |
| cjwatson | the branch itself isn't in the daily build | 13:44 |
| xivulon | that's already in? | 13:45 |
| cjwatson | uploads made from the branch are in the daily build | 13:45 |
| xivulon | good | 13:45 |
| cjwatson | if the branch hasn't changed since gutsy, there is no upload to make | 13:45 |
| xivulon | hacks that would be quick for you to move upstream: | 13:45 |
| xivulon | add /boot to fstab | 13:47 |
| CIA-4 | oem-config: cjwatson * r386 oem-config/ (4 files in 2 dirs): | 13:48 |
| CIA-4 | oem-config: * Automatic update of included source packages: console-setup 1.19ubuntu1, | 13:48 |
| CIA-4 | oem-config: localechooser 1.42ubuntu1, tzsetup 1:0.19, user-setup 1.16ubuntu1. | 13:48 |
| xivulon | cjwatson note that the hacks to be removed are in now in wubi not in lupin, since wubi was overriding the initrd (to avoid shipping a different initrd) | 13:49 |
| xivulon | the boot hacks are in http://codebrowse.launchpad.net/~ubuntu-installer/wubi/hardy/files/ago%40nbago-20071108222051-y9zlwe38au12i4jf?file_id=finish.d-20071008002841-x6i7u2jcizw74pyu-12 | 13:50 |
| xivulon | I am sure there is a far better way to add stuff to fstab | 13:50 |
| xivulon | fstab.d if my memory doesn't fail me | 13:50 |
| saispo | a new installer will be out for the next hardy ? the simple debian installer will continue to exist or it will die ? | 13:51 |
| cjwatson | finish.d is definitely wrong | 13:51 |
| cjwatson | d-i is not going to die as long as I'm around | 13:51 |
| saispo | yeah ^_^ | 13:51 |
| CIA-4 | oem-config: cjwatson * r387 oem-config/debian/ (changelog control): XS-Vcs-Bzr -> Vcs-Bzr | 13:52 |
| cjwatson | saispo: most of d-i has already been merged from Debian | 13:52 |
| cjwatson | saispo: so I don't know what you mean by "a new installer" | 13:52 |
| xivulon | cjwatson finish.d hacks simply append the boot line to fstab and mount it. As mentioned doing it via fstab.d (?) would be better. | 13:52 |
| cjwatson | fstab.d yes | 13:53 |
| cjwatson | can be done in partman-auto-loop. Is there a bug filed with a patch? | 13:53 |
| cjwatson | IRC is just about the worst way to track this stuff :) | 13:53 |
| saispo | cjwatson: as you say about irc and the latency :) i see a new team name, a discussion and i think a new installer will come, that's all cjwatson :) | 13:53 |
| cjwatson | saispo: the installer is modular, and little components of it are always being upgraded. What new team name? | 13:54 |
| saispo | lupin ? | 13:54 |
| CIA-4 | oem-config: cjwatson * r388 oem-config/debian/changelog: releasing version 1.24 | 13:54 |
| saispo | cjwatson: yep, and i use it all days and i use it for creating my cd's. d-i is wonderfull | 13:54 |
| cjwatson | saispo: lupin is specifically for installation via Windows; this was partially in place in gutsy | 13:55 |
| saispo | ok | 13:55 |
| saispo | don't know that, thanks for your explaination | 13:55 |
| cjwatson | saispo: the Windows installer work does *not* supersede either d-i or ubiquity; it's an additional method, not a replacement | 13:55 |
| saispo | k | 13:55 |
| xivulon | cjwatson https://bugs.launchpad.net/ubuntu/+source/partman-auto-loop/+bug/173659 | 13:59 |
| cjwatson | I was hoping for a patch against partman-auto-loop, but OK ;-) | 13:59 |
| xivulon | I can do the patch later on today | 13:59 |
| cjwatson | thanks | 13:59 |
| xivulon | Not on a linux machine at the moment | 13:59 |
| cjwatson | if you do it in fstab.d, you shouldn't need a separate script to mount it | 14:00 |
| xivulon | nice | 14:00 |
| cjwatson | partman-target should automatically mount stuff listed in fstab.d | 14:00 |
| cjwatson | of course it should not hardcode "ubuntu" | 14:01 |
| cjwatson | partman-auto-loop fetches that from the preseed file rather than it being hardcoded | 14:01 |
| xivulon | sure | 14:01 |
| xivulon | issue #2 is http://codebrowse.launchpad.net/~ubuntu-installer/wubi/hardy/annotate/ago%40nbago-20071108222051-y9zlwe38au12i4jf?file_id=ntfs_3g-20071020080255-gmmr0086kisglkaq-3 | 14:03 |
| xivulon | Basically making sendsigs skip userspace filesystems. There are at least 2 bugs on it. | 14:03 |
| cjwatson | there's already a bug, no need to bring it up on IRC unless you have a patch that I've missed | 14:03 |
| xivulon | The above is a quick patch for the reported bug | 14:04 |
| cjwatson | partman-auto-loop bzr already has a correction to add pidof mount.ntfs | 14:04 |
| xivulon | But it does not fix the root issue | 14:04 |
| cjwatson | and this is already in the spec | 14:04 |
| cjwatson | we don't need to go over it again :) | 14:04 |
| xivulon | The gutsy one was wrong, not sure if it has been fixed since | 14:05 |
| cjwatson | we don't need to go over this again on IRC, it's in the spec | 14:05 |
| xivulon | There where 2 issues, 1) no mkdir varrun 2) did not work with /sbin/mount.ntfs but works with mount.ntfs | 14:05 |
| xivulon | ok will check that later | 14:06 |
| cjwatson | you put it there :) | 14:06 |
| cjwatson | fixed partman-auto-loop to use pidof blah rather than pidof /sbin/blah | 14:09 |
| cjwatson | I'll fix ntfs-3g in the next upload | 14:10 |
| cjwatson | which I guess can be nowish | 14:11 |
| cjwatson | dear ntfs-3g upstream, stop changing the damned soname | 14:11 |
| evand | heh | 14:13 |
| xivulon | That was the relevant bug by the way: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/150831 | 14:15 |
| cjwatson | thanks, I missed that | 14:16 |
| CIA-4 | ubiquity: evand * r2370 ubiquity/ (configure configure.ac): bump to 1.7.2 | 14:16 |
| xivulon | cjwatson what was the init process that copied /dev/.initramfs/varrun -> /var/run? | 14:17 |
| cjwatson | xivulon: ntfs-3g 1:1.1120-1ubuntu1 should obsolete http://codebrowse.launchpad.net/~ubuntu-installer/wubi/hardy/annotate/ago%40nbago-20071108222051-y9zlwe38au12i4jf?file_id=ntfs_3g-20071020080255-gmmr0086kisglkaq-3 | 14:18 |
| xivulon | That has to run quite early on I guess... Wouldn't make sense to have the pidof in there directly? | 14:18 |
| cjwatson | $ grep -r varrun /etc/init.d | 14:18 |
| cjwatson | /etc/init.d/mountkernfs.sh: for file in /dev/.initramfs/varrun/*; do | 14:18 |
| CIA-4 | ubiquity: evand * r2371 ubiquity/debian/ (changelog control): * XS-Vcs-Bzr is now Vcs-Bzr. | 14:18 |
| cjwatson | I think it's best the way it is for now | 14:18 |
| xivulon | What I mean is that if ntfs is in use by the time you run mountkernfs.sh is executed, it should be pretty safe to skip it, and that way we would not need to patch separately autopartition-loop | 14:21 |
| cjwatson | I think the current approach (with the bug fixes I just uploaded) is sufficient and avoids the need to encode filesystem-specific stuff in the mountkernfs, which is supposed to be as generic as possible | 14:22 |
| xivulon | ok | 14:23 |
| xivulon | next | 14:23 |
| xivulon | One more template: http://codebrowse.launchpad.net/~ubuntu-installer/wubi/hardy/annotate/ago%40nbago-20071108222051-y9zlwe38au12i4jf?file_id=extra.templates-20071101223742-1yyt3rc9cs3pkchh-2 | 14:24 |
| cjwatson | that sounds like it should have a patch associated with it, and be filed as a bug ...? | 14:24 |
| cjwatson | 141217? | 14:24 |
| cjwatson | no | 14:24 |
| xivulon | The error message should be raised by autopartition-loop (will provide patches separately), just need that template in | 14:25 |
| cjwatson | the template and the code to use it should be submitted in a single patch | 14:26 |
| cjwatson | as a general rule, we don't add templates without code to use them | 14:27 |
| xivulon | Makes sense then | 14:27 |
| cjwatson | templates are for the most part just an extension of code | 14:27 |
| xivulon | I will have to diff autopartition-loop, will do that tonight and give you the patches against that | 14:28 |
| xivulon | On a side note, as mentioned, unless fallocate is available, I'd use windows-side virtual file generation, or we'd have to use zeroing on linux side which is painfully slow | 14:29 |
| cjwatson | we should be getting a new enough kernel to use fallocate | 14:30 |
| xivulon | that also depend on ntfs-3g / vfat using that | 14:30 |
| cjwatson | correct | 14:31 |
| xivulon | Anyway I have the code for windows side file generation, removing that is not a big deal | 14:31 |
| cjwatson | this is something we already discussed in Cambridge, and it's in the spec :) | 14:32 |
| xivulon | re template, I had a discussion with szaka, get_ntfs_resize_range (ntfsresize info), can return false negatives, i.e. give a malformed ntfs error, even though ntfs-3g can actually use the partition | 14:45 |
| xivulon | cjwatson, I also had a proposal to generalize external hooks in lupin, not sure what your view is on that https://bugs.launchpad.net/ubuntu/+source/casper/+bug/144798 (see last comment) | 14:53 |
| xivulon | finally (for today), can I remind you of #140458? I have tried one of the programs to generate metalinks, and as far as I can see, looks to me, can that be added to the build process? | 14:54 |
| xivulon | ...looks well to me... | 14:54 |
| cjwatson | 144798> desperately need to fix naming to be in line with d-i standards | 14:54 |
| cjwatson | 140458> I'll ask slangasek to look at it, I don't have time myself | 14:55 |
| xivulon | cjwatson, can you add your suggestion to 144798? So we take it from there? | 14:55 |
| cjwatson | I'll think about it | 14:56 |
| cjwatson | I want to have an actual suggestion | 14:56 |
| cjwatson | but basically any boot parameter that doesn't contain a slash is incorrectly named | 14:56 |
| cjwatson | at least any installer parameter | 14:56 |
| cjwatson | because unless it contains a slash it will be carried over to the installed system and encoded forever in users' bootloader configurations | 14:57 |
| cjwatson | there are a small number of exceptions but they are very much finite and we should avoid growing them | 14:57 |
| xivulon | in my proposal though we only have 1 parameter (we can add a slash to it): custom_installation | 14:58 |
| cjwatson | that is incorrectly named. | 14:58 |
| cjwatson | I've commented on the spec to that effect | 14:58 |
| cjwatson | s/spec/bug/ | 14:58 |
| xivulon | all I mean that should be the only one to fix | 14:58 |
| cjwatson | sure | 14:58 |
| cjwatson | but my point is that it is actually more than an aesthetic consideration and therefore it's something I'd like developers to bear in mind | 14:59 |
| xivulon | additional hooks, preseed, and override files follow a specific directory structure/naming convention withing the custom_installation folder | 14:59 |
| cjwatson | yes, I read the bug | 14:59 |
| cjwatson | I will think about it :) | 14:59 |
| xivulon | There is one thing though, about the path | 14:59 |
| xivulon | custom_installation=??? | 15:00 |
| cjwatson | I do not have an opinion yet | 15:00 |
| xivulon | ??? = Find Path matching XYZ | /dev/sda/path | /dev/by-uuid/xyz/path ... | 15:00 |
| cjwatson | the latter two are abominations | 15:01 |
| cjwatson | possibly // might be an acceptable syntax | 15:01 |
| cjwatson | but definitely not something that looks like a device node but isn't | 15:01 |
| cjwatson | : would probably be closer than // | 15:02 |
| cjwatson | so /dev/sda:/path | 15:02 |
| xivulon | find:/path | /dev/sda:/path | /dev/by-uuid/xyz:/path | 15:02 |
| cjwatson | I'm not certain I'm recommending that yet, but it's definitely better than /dev/sda/path | 15:02 |
| xivulon | agreed. we could also merge url paths in there | 15:03 |
| xivulon | 15:11 | |
| xivulon | is /custom/installation ok as a parameter name? | 15:12 |
| cjwatson | no | 15:16 |
| cjwatson | leading slashes aren't allowed, and the first bit should generally be named for the component implementing it | 15:16 |
| cjwatson | hence things like partman-auto-loop/partition | 15:16 |
| xivulon | custom/installation then | 15:16 |
| xivulon | as that would probably span several components (casper being one of the most important) | 15:17 |
| cjwatson | not custom/ | 15:17 |
| cjwatson | casper/ would be fine | 15:18 |
| xivulon | casper/custom-installation? | 15:18 |
| cjwatson | debian-installer/ is available for general things, though this isn't very d-i specific | 15:18 |
| xivulon | debian-installer/custom? | 15:18 |
| cjwatson | something like that. I have to go and prepare for a client phone call now | 15:19 |
| xivulon | sure, maybe edit the bug if you have any good idea | 15:19 |
| xivulon | ps It would be nice to implement the same mechanism on live and alternate | 15:20 |
| xivulon | the implementation is different, but there is no much reason to have 2 separate override mechanisms | 15:20 |
| xivulon | cjwatson, do you think it is safe to have the following in umountfs? | 16:07 |
| xivulon | [ -x /usr/lib/lupin/host_device ] && [ "$DEV" = "$(/usr/lib/lupin/host_device)" ] && continue' | 16:08 |
| bdmurray | cjwatson: Have you seen the recent comments in bug 150930? | 16:12 |
| cjwatson | xivulon: I guess, would need to refresh memory on the context | 16:22 |
| cjwatson | bdmurray: hmm, apparently I shelved my fix for that | 16:24 |
| cjwatson | I wonder why | 16:24 |
| CIA-4 | ubiquity: cjwatson * r2372 ubiquity/ (debian/changelog scripts/install.py): | 16:26 |
| CIA-4 | ubiquity: * Copy xserver-xorg/config/display/modes to the installed system before | 16:26 |
| CIA-4 | ubiquity: reconfiguring usplash (LP: #150930). | 16:26 |
| cjwatson | perhaps that will do the job | 16:26 |
| bdmurray | Was that done before after Hardy Alpha 1? | 16:27 |
| cjwatson | CIA's commit messages are more or less real-time | 16:28 |
| cjwatson | i.e. I committed it just now | 16:28 |
| bdmurray | Okay, great. | 16:28 |
| cjwatson | I've not really tested it though, it just looks plausible ... | 16:29 |
| xivulon | cjwatson, that's because umountfs tries to umount the /host drive before umounting other hosted systems. | 16:29 |
| cjwatson | oh, in *umountfs*? I really, really don't think it should have anything involving "lupin" in it | 16:29 |
| xivulon | we discussed that briefly, and you mentioned your concerns re umount order | 16:29 |
| cjwatson | if that's needed, it should be made generic and pushed into sysvinit properly | 16:29 |
| xivulon | cjwatson, yes that is needed I am afraid | 16:30 |
| cjwatson | then it does not belong in lupin | 16:30 |
| xivulon | that's why I wanted it upstream ;) | 16:30 |
| cjwatson | right, but it shouldn't be done by calling /usr/lib/lupin/anything | 16:30 |
| cjwatson | (quite apart from the fact that /usr/lib is a crazy place for programs to live ...) | 16:30 |
| xivulon | that can be anything you want... Just for illustrative purposes | 16:31 |
| xivulon | any script that returns an host device | 16:31 |
| xivulon | if there is one... | 16:31 |
| cjwatson | I don't think it should hardcode /host, either. The question you're trying to ask is "is this filesystem used to implement /"? | 16:31 |
| cjwatson | s/"?/?"/ | 16:31 |
| cjwatson | it shouldn't matter what it's called | 16:31 |
| cjwatson | and, as I said, it would be better to just topologically sort filesystems and unmount them in the right order | 16:32 |
| cjwatson | so no, I don't think it's safe to have the line you quoted in umountfs. :) | 16:32 |
| xivulon | I guess so, to rephrase "is / a file/folder inside of this device?" | 16:32 |
| cjwatson | (folder is a Windows term) | 16:32 |
| xivulon | directory | 16:32 |
| cjwatson | :-) | 16:33 |
| xivulon | of course | 16:33 |
| xivulon | one case is when root is a loopinstallation file, another is when root is a directory inside another root filesystem | 16:34 |
| xivulon | have to think about a good detection algorithm | 16:36 |
| cjwatson | "topological sort" | 16:36 |
| cjwatson | that's the name of the algorithm | 16:36 |
| xivulon | anyway on top of the line above, you'd also need /etc/init.d/mounthost, /etc/init.d/umounthost | 16:36 |
| cjwatson | it's the process of taking a directed acyclic graph and ordering it from leaves to root (or vice versa) | 16:37 |
| cjwatson | shouldn't need mounthost/umounthost | 16:37 |
| xivulon | An implementation is now in lupin-support | 16:37 |
| cjwatson | mounthost has to be done in the initramfs anyway, and umounthost can be handled by a more intelligent umountfs | 16:37 |
| cjwatson | or umountroot | 16:37 |
| xivulon | the idea is that if you skip host in umountfs you have to unmount it later on | 16:38 |
| cjwatson | you just have umountroot unmount anything that's left over at the end | 16:38 |
| xivulon | that will do | 16:38 |
| xivulon | I was thinking of a script after umount root | 16:38 |
| cjwatson | I'm trying to avoid script proliferation here in what is a very delicate area | 16:38 |
| xivulon | similarly when you mount | 16:38 |
| cjwatson | /etc/init.d/mounthost just makes no sense :) | 16:38 |
| xivulon | Well you have to mount /host before mounting /... | 16:38 |
| cjwatson | it has to be done in the initramfs - if you don't have /host mounted you don't have / mounted and therefore can't see /etc/init.d | 16:39 |
| cjwatson | this is already done in initramfs-tools | 16:39 |
| xivulon | what about remounting it | 16:39 |
| xivulon | rw + checks... all things you do normally to / | 16:39 |
| cjwatson | could be done by checkroot | 16:39 |
| cjwatson | definitely shouldn't be called mount* though since that's not what it does | 16:40 |
| xivulon | ok we agree, I have preliminary implementation of both in lupin-support (but as separate scripts) | 16:40 |
| xivulon | yeah checkhost might be more appropriate | 16:40 |
| cjwatson | it's probably reasonable for checkroot to remount,rw anything that's already mounted | 16:40 |
| cjwatson | there is no reason for it to be a separate script, imo | 16:41 |
| xivulon | makes sense | 16:41 |
| cjwatson | I realise that when you're writing an overlay-type system then separate files make sense, but when integrating things into the distribution it always makes sense to think about whether you can do it in the existing code | 16:42 |
| xivulon | Back to "topological sort" isn't it sufficient to check that the root device is not itself a mountpoint? | 16:42 |
| cjwatson | the root filesystem is always a mountpoint | 16:43 |
| cjwatson | $ mountpoint / | 16:43 |
| cjwatson | is a mountpoint | 16:43 |
| xivulon | I mean the device, so that / is mounted on /host/myfile -> device = /host -> check if /host is mounted | 16:44 |
| cjwatson | why not do it the proper, generic way? | 16:44 |
| xivulon | the above does not hardcode "/host" | 16:45 |
| xivulon | that was just for an example | 16:45 |
| xivulon | so that / is mounted on /host/myfile -> device = /host -> check if /host is mounted | 16:45 |
| cjwatson | ok, do what you like :-/ | 16:46 |
| xivulon | so that / is mounted on /XYZ/myfile -> device = /XYZ -> check if /ZYZ is mounted | 16:46 |
| xivulon | not sure what you mean by generic | 16:46 |
| xivulon | isn't the above generic enough? | 16:46 |
| cjwatson | avoiding hardcoding assumptions about mount point structure | 16:46 |
| cjwatson | so that we don't have just the same problem again when somebody creates an even more convoluted chain of stuff :) | 16:46 |
| xivulon | I think we are saying the same thing | 16:48 |
| xivulon | You'd have to get the / device, and try understand what it is: either it is a real device, or a file/folder inside of another mountpoint. | 16:49 |
| xivulon | Do you have different suggestion? | 16:50 |
| cjwatson | I suggest doing this all the way down the filesystem tree | 16:50 |
| xivulon | I see you want the full unmount order not just host-root | 16:51 |
| cjwatson | well | 16:51 |
| cjwatson | some of that probably comes from the order you get things out of /proc/mounts in | 16:51 |
| cjwatson | so a simpler option might just be to ignore anything in /proc/mounts that comes before / | 16:52 |
| cjwatson | I think /proc/mounts might be effectively topologically sorted anyway | 16:52 |
| xivulon | as you reminded me some time ago' though that gets a bit complicated in the case of userspace filesystems | 16:53 |
| xivulon | so /host might depend on /usr, (even though /host is mounted by the initrd) | 16:53 |
| cjwatson | I didn't say that /host might, I said that some other ntfs-3g filesystem might | 16:54 |
| cjwatson | and in that case the filesystem in question should be mounted after /usr and so should appear later in /proc/mounts than /usr ... | 16:54 |
| cjwatson | look at your /proc/mounts and you should see what I mean | 16:55 |
| xivulon | cannot do it now, but I see what you mean, and I am quite sure that /host is indeed before / | 16:55 |
| xivulon | I think it's a good idea | 16:56 |
| cjwatson | the only wart is that there are two / mountpoints; the first is rootfs and is actually the initramfs / | 16:57 |
| cjwatson | so ideally you need to figure out the current / | 16:57 |
| cjwatson | but, SMOP :) | 16:57 |
| xivulon | Last point was a patch vs grub-install/update-grub (now I modified update-grub only, but I am not sure whether the code should be moved to grub-install) | 17:02 |
| xivulon | grub-install will do, unless menu.lst is deleted and gets regenerated by update-grub | 17:03 |
| cjwatson | grub-install doesn't touch menu.lst at all, so if this is to change something in menu.lst, it should be in update-grub | 17:06 |
| cjwatson | grub-installer (note difference; grub-install is a part of grub that installs the grub binary to disk, grub-installer is a d-i component) does make sure to call update-grub | 17:06 |
| xivulon | I meant grub-installer | 17:27 |
| xivulon | I seemed to rememebt that it generates an initial menu.lst | 17:29 |
| cjwatson | not really - grub-installer calls update-grub and then adjusts the result a bit | 17:30 |
| xivulon | in this case see if http://codebrowse.launchpad.net/~ubuntu-installer/lupin/hardy/annotate/ago%40nb-ago-20071029092615-uys52n7pb00aw6js?file_id=updategrub-20071021190150-hexwoe8fo26l1f9b-10 can be used | 17:37 |
| xivulon | you may want to generalize on line 300-302 | 17:38 |
| xivulon | The modifications at line 701-... are a workaround to problems with device.map mismatch between grub and grub4dos | 17:42 |
| cjwatson | could you turn that into a patch against update-grub and file it as a bug report on grub, please? | 17:45 |
| xivulon | sure | 17:47 |
| cjwatson | thanks | 17:47 |
| xivulon | cjwatson, on update-grub it is kind of difficult to understand whether / is using a host-device since I assume I cannot rely on /proc/mounts but only on fstab | 19:08 |
| xivulon | this is an issue when update-grub is executed at installation | 19:10 |
| xivulon | Well in fact autopartition-loop will mount the host-device as /host anyway... | 19:12 |
| xivulon | is it possible to use a preseed recipe to mount-move a directory? | 22:28 |
| xivulon | I meant mount bind | 22:29 |
| cjwatson | in update-grub, you can rely on /proc being mounted | 22:30 |
| cjwatson | you can do anything with preseeding. | 22:31 |
| cjwatson | depends when you want it mounted | 22:31 |
| cjwatson | a preseed/early_command script can write out a fstab.d script that instructs partman to do the bind-mount | 22:31 |
| xivulon | that's for adding boot to fstab in autopartition-loop | 22:32 |
| xivulon | I was thinking there might no be any need for a separate script at all, but a change of preseed file instead | 22:32 |
| cjwatson | like I say, you can do anything with preseeding, it's just a question of how difficult it is | 22:32 |
| cjwatson | but many of those things require using a preseed file to write out a script | 22:33 |
| cjwatson | there is no simpler way to do what you are asking | 22:33 |
| xivulon | I mean a preseed recipe | 22:33 |
| xivulon | not a script | 22:33 |
| cjwatson | you can't do bind-mounts in those | 22:33 |
| xivulon | ok | 22:34 |
| xivulon | then we need a new preseed variable | 22:38 |
| cjwatson | I don't think so | 22:38 |
| cjwatson | you need to provide a lot more justification for that | 22:38 |
| cjwatson | you certainly don't need it for /boot, since we'll be doing that directly in partman-auto-loop | 22:38 |
| xivulon | If I add boot via fstab.d I ma | 22:40 |
| xivulon | may | 22:40 |
| xivulon | OT any particular reason to insist on sh for all those scripts as opposed to python or similar? | 22:45 |
| cjwatson | python is not available in the initrd, and it would be a further memory hog to add it | 22:59 |
| cjwatson | and any code that used python would have zero chance to go upstream to d-i | 23:00 |
| cjwatson | so, I do insist on sh | 23:00 |
| cjwatson | ubiquity is OK because it's in an entirely different environment | 23:00 |
| xivulon | I was thinking more "outside" of the initrd, as in the live-iso/ubiquity | 23:02 |
| xivulon | things like partman or update-grub | 23:02 |
| cjwatson | partman is used in the initrd! | 23:02 |
| cjwatson | in d-i | 23:03 |
| xivulon | in d-i | 23:03 |
| cjwatson | I have no desire whatsoever to fork partman between d-i and ubiquity | 23:03 |
| cjwatson | it's hard enough to maintain as it is | 23:03 |
| cjwatson | update-grub isn't part of the installer as such, so not my call | 23:03 |
| cjwatson | I imagine it's just using the simplest facilities available | 23:03 |
| cjwatson | also, it used to be in / not /usr, and so couldn't use python | 23:03 |
| xivulon | d-i has also gone gtk though, at least on debian if I am not wrong | 23:04 |
| cjwatson | partly, but only by means of a cdebconf frontend | 23:04 |
| cjwatson | (I wrote a fair chunk of the code) | 23:04 |
| cjwatson | and that still does not use python | 23:04 |
| xivulon | if they can take gtk, python wouldn't be that much burden | 23:04 |
| cjwatson | it has been explicitly rejected | 23:04 |
| cjwatson | please don't push this, it is not worth it | 23:04 |
| cjwatson | gtk provides real new user-visible facilities. python only makes developers' lives easier. | 23:05 |
| xivulon | I am not pushing it, just wondering, since I think that a lot of the script I am seeing would be much easier to maintain in python | 23:05 |
| cjwatson | therefore gtk is more worthy of the memory requirement. | 23:05 |
| cjwatson | most of the parts of d-i I know well would not be significantly easier to maintain in python | 23:06 |
| cjwatson | those that include algorithms hard to express in shell are generally written in C | 23:06 |
| xivulon | fair enough [end of rant] | 23:07 |
| cjwatson | at the end of the day, it's the way that the core d-i development team like it :) | 23:08 |
| xivulon | if it was for me sh would be used only for interactive tasks... | 23:09 |
| cjwatson | we feel differently | 23:09 |
| cjwatson | (which is fine, people are allowed to differ :-)) | 23:09 |
| xivulon | sure | 23:10 |
| cjwatson | personally, I think sh is an excellent glue language for the purpose of tying lots of different processes together, and (if you observe a few simple if poorly-known quoting rules) is much better-suited to that task than any other language I've seen | 23:11 |
| cjwatson | but I don't expect everyone to agree with me | 23:11 |
| xivulon | they also say that python is an excellent glue language ;-) | 23:12 |
| cjwatson | it's much more verbose for the same task | 23:12 |
| cjwatson | and its signal handling is poor | 23:12 |
| xivulon | but clearer | 23:13 |
| cjwatson | do you understand its signal handling well enough to explain it to me? :) | 23:13 |
| xivulon | not sure what you mean by that | 23:13 |
| cjwatson | what does Python do with SIGPIPE and why is this bad for subprocesses? | 23:13 |
| cjwatson | if you don't know this, you can't claim Python is clearer for gluing subprocesses together ;-) | 23:13 |
| cjwatson | (this is a real bug that has caused critical ubiquity bugs of the form "erased my entire partition table without warning" | 23:14 |
| cjwatson | ) | 23:14 |
| xivulon | I normally do not call external programs from within python | 23:16 |
| xivulon | I tend to use libraries or wrappers, so errors are exceptions, and that works well | 23:16 |
| cjwatson | so, I said "for the purpose of tying lots of different processes together" | 23:17 |
| cjwatson | I was explicitly talking about calling external programs | 23:17 |
| cjwatson | suffice it to say that Python has at least one critical design flaw in this area that makes it very easy to do the job badly, and that this design flaw does not exist in sh | 23:17 |
| cjwatson | so for this purpose I find Python's apparent clarity to be misleading | 23:18 |
| cjwatson | even though it is certainly excellent in other areas | 23:18 |
| xivulon | I agree that running unmodified programs is easier, but in the long end, creating a library of the desired wrappers may be more convenient | 23:18 |
| xivulon | is not one-off tasks we are talking here... | 23:18 |
| cjwatson | now you're just dodging the problem | 23:18 |
| cjwatson | in the long run, it may also *not* be more convenient :) | 23:19 |
| cjwatson | an explicit design goal of d-i is to reuse existing code, which often includes programs built by other packages | 23:19 |
| xivulon | the situation though is not as bad as you make it, since today most things are available as a module | 23:19 |
| xivulon | so there is little need to run external programs directly | 23:20 |
| cjwatson | *shrug* not true IME | 23:20 |
| cjwatson | it very much depends on what you're doing | 23:21 |
| cjwatson | and, I repeat, this is a design flaw that has caused data loss | 23:21 |
| cjwatson | in order to avoid it one has to write some very non-obvious code | 23:21 |
| cjwatson | it'll bite you as soon as you call even one external program from Python and expect it to do the right thing in the event that your program takes e.g. an uncaught exception | 23:24 |
| cjwatson | (such as KeyboardInterrupt) | 23:24 |
| xivulon | As mentioned not something I usually do, but I can see what you are saying, as mentioned, if calling a program from python is essential writing binding for it is usually a good approach | 23:28 |
| CIA-4 | ubiquity: evand * r2373 ubiquity/ (5 files in 4 dirs): * Strip out support for creating multiple users in migration-assistant. | 23:30 |
| cjwatson | xivulon: perhaps, but of course the binding still needs to take account of this | 23:31 |
| cjwatson | anyway, bedtime | 23:31 |
| xivulon | thx for the chat goodnight | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!