| CIA-9 | grub-installer: cjwatson * r789 ubuntu/debian/po/ (59 files): eliminate spurious .po file differences from Debian | 01:34 |
|---|---|---|
| CIA-9 | grub-installer: cjwatson * r790 ubuntu/ (debian/changelog grub-installer): | 02:46 |
| CIA-9 | grub-installer: Drop code to handle error messages in dmraid's output, which is no | 02:46 |
| CIA-9 | grub-installer: longer needed. | 02:46 |
| CIA-9 | grub-installer: cjwatson * r791 ubuntu/debian/changelog: releasing version 1.38ubuntu1 | 02:51 |
| twb | Can encrypted filesystems be created (particularly the root filesystem) from d-i in 8.04? If not, how about 9.04? | 02:55 |
| * twb goes looking at the installation guide... | 02:55 | |
| cjwatson | core encrypted filesystem support was in 8.04, but I really couldn't say about the root filesystem | 02:58 |
| twb | OK, thanks | 03:02 |
| davmor2 | xivulon: morning | 08:49 |
| xivulon | hi davmor2, sorry but need to rush out | 08:50 |
| xivulon | pls send me an email | 08:50 |
| === cjwatson_ is now known as cjwatson | ||
| xivulon | davmor2, hi | 09:49 |
| xivulon | so that swap thing, had a quick look yesterday and couldn't kill the swapon and mkswap processes | 09:50 |
| xivulon | with the kernel error reported | 09:50 |
| xivulon | at this stage though I am mostly interested in knowing whether that is a regression from r129. | 09:51 |
| davmor2 | I can have a look at that after. But I don't think so. Also it only affects fat. If cking has had a look I can wipe the system and drop 129 on to check | 09:52 |
| xivulon | let me have a quick chat with cking | 09:54 |
| xivulon | evand could you please build r136? | 10:05 |
| xivulon | quite sure it is not a regression though | 10:13 |
| evand | xivulon: already have, it's up on http://people.ubuntu.com/~evand/wubi/karmic | 10:27 |
| xivulon | ah cool was looking into jaunty (as it is still an update) | 10:27 |
| xivulon | I think we should release 136 as an update, I will then move on with trunk to deal with karmic and grub2 niceties | 10:28 |
| evand | I'm keen to not put it in the jaunty directory as if we ever need to rebuild those CDs, then we'll want to use the version of Wubi that was released with 9.04 | 10:33 |
| evand | if you're planning on pushing 136 to wubi-installer.org, I would strongly suggest getting the QA team to look at it, given the potential for regressions | 10:33 |
| xivulon | I will | 10:47 |
| xivulon | davmor2 you already tested 136 didn't you? | 10:48 |
| xivulon | evand apw is pushing a fat module patch to address this swap file freeze | 11:00 |
| xivulon | would it be possible to build a kernel live CD initrd so we can have that tested? | 11:00 |
| xivulon | ..kernel plus CD initrd... | 11:01 |
| davmor2 | xivulon: yes kubuntu works but fat didn't. So it is correct in that the things that didn't work do, if that makes sense | 11:09 |
| evand | xivulon: sure | 11:14 |
| xivulon | thanks | 11:16 |
| xivulon | evand you might want to doublecheck the 134-136 diff, if you ignore the po files should be a very small delta | 11:17 |
| xivulon | or we might want to revert 135 and only add 136 patch (URL fix) | 11:18 |
| xivulon | seems safe enough to me | 11:18 |
| evand | r129 was what was released with jaunty | 11:18 |
| CIA-9 | partman-target: cjwatson * r765 ubuntu/ (72 files in 4 dirs): merge from Debian 60 | 11:19 |
| xivulon | I posted r134 because that was the one we tested so far | 11:19 |
| evand | sure, but if we're talking of pushing this as an update to Jaunty, I think it's only fair that we consider the delta from Jaunty, even if we have already tested part of it. | 11:19 |
| xivulon | of course | 11:20 |
| xivulon | it's just that 134-136 will be less tested | 11:20 |
| xivulon | davmor2 please grill 136 when you have some time | 11:21 |
| CIA-9 | partman-target: cjwatson * r766 ubuntu/debian/changelog: make changelog a bit more concise | 11:23 |
| CIA-9 | partman-target: cjwatson * r767 ubuntu/debian/po/ (66 files): debconf-updatepo | 11:26 |
| CIA-9 | partman-target: cjwatson * r768 ubuntu/debian/changelog: releasing version 60ubuntu1 | 11:29 |
| davmor2 | will do I'm away for a bit though now | 11:36 |
| CIA-9 | partman-crypto: cjwatson * r681 ubuntu/ (18 files in 3 dirs): merge from Debian 37 | 11:55 |
| CIA-9 | partman-crypto: cjwatson * r682 ubuntu/debian/po/ (ast.po et.po kk.po): debconf-updatepo for new translations | 11:59 |
| CIA-9 | partman-crypto: cjwatson * r683 ubuntu/debian/changelog: releasing version 37ubuntu1 | 12:00 |
| evand | cjwatson: regarding the comment "Colin thinks it will need more than a preseed." in https://wiki.ubuntu.com/InstallUpdatesWhenInstallingUbuntu , am I correct in assuming you're referring to the need for the mentioned checkbox to disable it in addition to a preseed, or is there an additional detail that the specification is missing? | 12:17 |
| cjwatson | evand: the former | 12:21 |
| evand | okay, just wanted to be sure before I deleted it. Thanks | 12:21 |
| cjwatson | I just thought a preseed would be too hidden away for many people | 12:22 |
| CIA-9 | partman-base: cjwatson * r158 ubuntu/ (9 files in 3 dirs): merge from Debian 130 | 12:29 |
| ubottu | Error: Could not parse data returned by Debian: HTTP Error 404: No such bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130;mbox=yes) | 12:29 |
| CIA-9 | partman-base: cjwatson * r159 ubuntu/debian/po/ (ast.po et.po): debconf-updatepo for new translations | 12:30 |
| cjwatson | oh, hmm, I think partman-base needs to wait until parted is merged | 12:31 |
| evand | hidden> sure, agreed | 12:48 |
| === cjwatson_ is now known as cjwatson | ||
| rgreening | evand1: ping | 14:36 |
| evand1 | rgreening: pong | 15:00 |
| rgreening | hey evand1 | 15:01 |
| rgreening | I was going to try and move DBusGMainLoop and gobject calls to frontend via wrappers. This way we can use same for Qt and allow for only one backend.. thoughts? | 15:01 |
| rgreening | or better idea evand1? | 15:02 |
| rgreening | for example: a new class method called DBusMainLoop to encapsulate DBusGMainLoop or DBusQtMainLoop... | 15:03 |
| evand1 | I think it's reasonable for the frontend to provide an event loop, though I'm cautious about the backend depending on the frontend to manage the install subprocess. I'll give it some thought and see if I can come up with a better solution. | 15:11 |
| rgreening | evand1: well, I think the gobject timeouts are more for indicating progress which should be signals to the FE to update, etc... but this is not currently whats being done. | 15:14 |
| rgreening | we definately have to pull out the gobject and glib specifics somehow. the KDE FE cannot work with the current backend. I've tried many ways, and gobject causes crashing all over evand1 | 15:16 |
| evand1 | good point | 15:22 |
| rgreening | evand1: here's how I propose to move DBusGMainLoop... http://paste.ubuntu.com/197095/ | 15:22 |
| rgreening | then I would need to work on gobject... | 15:22 |
| evand1 | hrm, I think that's at least reasonable enough until we find something better | 15:23 |
| evand1 | feel free to commit that | 15:24 |
| rgreening | evand1: ok, that's a first step.. let me do that for the kde_frontend.py and I'll comit both... | 15:24 |
| rgreening | evand1: this is basically the last showstopper for me... cause as it stands, everything crashes when I try and format or make a startup disk... I think gobject and Qt threads are stomping on one another... | 15:25 |
| rgreening | :) | 15:25 |
| evand1 | heh | 15:25 |
| CIA-9 | usb-creator: rgreening * r109 usb-creator/usbcreator/ (backend.py gtk_frontend.py kde_frontend.py): | 15:28 |
| CIA-9 | usb-creator: Make a new class method for frontends to encapsulate the appropriate DBus MainLoop call for Gtk | 15:28 |
| CIA-9 | usb-creator: and Qt respectively. The backend will then call this method, rather than use a direct call to | 15:28 |
| CIA-9 | usb-creator: DBusGMainLoop. | 15:28 |
| CIA-9 | usb-creator: Cleanup some unrequired imports statements as well. | 15:28 |
| evand1 | superm1: apologies for bugging you again about the oem-config spec, but were you guys asking for the ability to have custom pages, and if so to what extent? That is, are you looking for the ability to drop some python code and glade information in without having to modify any existing code, or do you want something more like zenity for oem-config? | 15:35 |
| evand1 | The size and scope of the oem-config spec have me slightly worried. | 15:36 |
| CIA-9 | usb-creator: rgreening * r110 usb-creator/usbcreator/ (backend.py gtk_frontend.py kde_frontend.py): | 15:54 |
| CIA-9 | usb-creator: We shouldn't need to pass a parameter to DBusMainLoop, as the wrapper should not change the | 15:54 |
| CIA-9 | usb-creator: default behaviour of the call it is wrapping (i.e. DBusGMainLoop(set_as_default=True) ). | 15:54 |
| evand1 | cjwatson: given your comments in the remaining task in the design section of https://wiki.ubuntu.com/OemConfigServer , do you have an opinion on how this should be implemented? | 15:58 |
| cjwatson | I think I wanted to offer a skeleton class | 16:00 |
| evand1 | cjwatson: apologies, I'm trying to understand what you mean here and meshing that with what you've written in the server spec, and I just keep speculating. Could you please elaborate a bit, as I'm not quite sure what the interface of this skeleton class (for the OEM) would be. | 16:19 |
| cjwatson | err, nor am I, that's why it never got done :) | 16:31 |
| cjwatson | basically my observation was that in the case of a debconf confmodule that just goes INPUT GO GET INPUT GO GET or whatever, the component is going to be of a very simple form | 16:32 |
| cjwatson | it'll essentially pass everything through to the frontend in some standardisable form | 16:32 |
| cjwatson | in the case of the server frontend, it just needs to pass all the questions straight through; in the case of graphical frontends it would presumably need to render them in the main window in some fairly simple way | 16:32 |
| cjwatson | and it would be convenient if there were a way to write a very simple declarative component that just gives the backend path, or even just leave out the component altogether and have it be implicit somehow, or something like that | 16:34 |
| cjwatson | alternatively, make it possible, easy, and documented to have a component that doesn't involve a backend, and just asks a series of questions for itself | 16:34 |
| cjwatson | but at any rate collapse those two separate pieces down to one for simple cases | 16:34 |
| Torgoton1 | My install "seems" to be locked up loading partman-base. 3.5 hours so far, but this is a lowmem 486. I tried to activate a console, but it has not yet responded. partman-base always seems to lock it up. Any way to find out what's going on? | 17:35 |
| cjwatson | not if it won't activate a console; you'll need to have one available beforehand | 17:36 |
| cjwatson | anything on tty4? | 17:36 |
| Torgoton1 | there was a bogus packet size or three about 3.5 hours ago. | 17:41 |
| Torgoton1 | Console switching is very responsive. ;) | 17:42 |
| Torgoton1 | heh. app failed to start. didn't freeze my gems. | 17:42 |
| Torgoton1 | oooh but I did. | 17:43 |
| Torgoton1 | oops. Don't mind me. Wrong channel. | 17:46 |
| === mcasadevall is now known as NCommander | ||
| cr3 | evand: just a quick thought about the networking issue with my ubiquity installs: might it be possible that in-target apt-get causes networking stuff to run on the installed system, which could potentially populate /etc/network/interfaces? | 18:26 |
| cr3 | evand: I can imagine that the target seems needs networking somehow, so perhaps it configures it at that point using the system configuration instead of network-manager | 18:27 |
| cr3 | s/seems/system | 18:27 |
| cjwatson | if anything is populating /etc/network/interfaces automatically, it should be shot | 18:27 |
| cjwatson | anything other than the installer that is | 18:27 |
| cjwatson | if something needs networking and doesn't have it, the appropriate response is to fail, not to try to magically set up /etc/network/interfaces and break the rest of the world ... | 18:28 |
| === nxvl_ is now known as nxvl | ||
| cr3 | cjwatson: I seem to have found the problem with network/interfaces containing eth0: casper/scripts/casper-bottom/23networking creates the interface if [ "$method" != dhcp ] || [ ! -x /root/usr/sbin/NetworkManager ], and then ubiquity/scripts/install.py copies interfaces and resolv.conf in the configure_network method | 18:58 |
| cjwatson | so which of those conditions is true for you? | 19:03 |
| cjwatson | oh, are you netbooting? | 19:03 |
| cr3 | cjwatson: "$method" != dhcp because $method is being set to "manual" because ! -z "$NETBOOT" | 19:03 |
| cjwatson | right, which is necessary because otherwise NM would tear down the network when the desktop starts up | 19:03 |
| cr3 | cjwatson: yep, I'm trying again without netboot and just nfsroot | 19:03 |
| cjwatson | so why is copying over the interfaces file not appropriate for you? | 19:04 |
| cr3 | cjwatson: because when rebooting: 1. network manager doesn't bring up the interface; 2. the system doesn't bring up the interface either because it is set to manual rather than dhcp | 19:05 |
| cr3 | cjwatson: so copying might be appropriate, as long as interfaces was in a state which brought up the interface upon reboot | 19:06 |
| cjwatson | the reason we copy interfaces from the running live session is that the user might have configured NM (e.g. wireless ESSID) and expect that to stick | 19:06 |
| cjwatson | or rather configured networking in general | 19:07 |
| cr3 | cjwatson: I'm not sure I agree with the assumption that: if the network was setup automatically during a netboot, it should be set manually upon reboot | 19:07 |
| cjwatson | I'm not quite sure how to reconcile that with your case | 19:07 |
| cjwatson | it wasn't deliberate for netboot | 19:07 |
| cjwatson | it's a consequence of a more general requirement | 19:07 |
| cr3 | cjwatson: it seems like different concepts are being coerced into the value of $method, where "dhcp" implies both nm should be used or the interface should be setup manually | 19:08 |
| cjwatson | sure, it's a hack | 19:09 |
| cjwatson | err, except you've misstated that | 19:10 |
| cjwatson | "dhcp" doesn't imply that the interface should be set up manually | 19:10 |
| cr3 | heh, I thought I'd get away with that :) | 19:10 |
| cr3 | on the one hand, in the more general use case, it seems that the configuration wants to be preserved on the target system. on the other hand, in the netboot use case, that's not necessarily the case | 19:11 |
| cr3 | cjwatson: what would you say if I had my success_command script remove those eth0 lines from the target interfaces file? I would rather that than having the script change "manual" for "dhcp", so that I can have nm kick in upon reboot | 19:13 |
| cr3 | cjwatson: also, it might be worthwhile to document this problem in a bug, but I'm not sure whether it should be assigned to casper (creating the live interfaces file) or ubiquity (copying it over) | 19:17 |
| cr3 | cjwatson: I suspect the solution will require somekind of communication between casper and ubiquity, perhaps in the form of a comment, so that ubiquity can make a more informed decision about how interfaces should be copied | 19:18 |
| cjwatson | cr3: success_command> sounds reasonable | 19:23 |
| cjwatson | cr3: start with a bug with tasks on both packages; it would help massively to have a clear description of exactly what is going wrong, and a clear specification of what the behaviour should be for netboot | 19:24 |
| cr3 | cjwatson: I'll need your help for the latter part, so I'll at least do a best effort for the first parts | 19:25 |
| cjwatson | well, I don't know what the behaviour should be for netboot | 19:27 |
| cjwatson | I don't mean a specification as in a wiki document | 19:27 |
| cjwatson | I mean a clear description | 19:27 |
| cr3 | cjwatson: done, reported bug #388060 (despite losing half my report due to pasting outside the darn text area and the back button not recoving my text :( | 19:56 |
| ubottu | Launchpad bug 388060 in casper "netboot insall of live cd results in a manual network interface configuration" [Undecided,New] https://launchpad.net/bugs/388060 | 19:56 |
| cr3 | the subject of the bug could probably be better, it barely sounds like english | 19:57 |
| orbitus | cjwatson, is there a preseed hook post dist detect but prior to partitioning? i'd like to wipe the target with dd prior to partitioning. if there is a partman command for the same that would work | 22:31 |
| orbitus | s/dist/disk/ | 22:31 |
| cjwatson | orbitus: only in 8.10 and later, not in 8.04 I'm afraid; partman/early_command | 22:51 |
| shtylman_ | cjwatson: im told that we will be pushing for a slideshow in the installer for 9.10 ... is that true? ... and how will that manifest :) | 22:56 |
| * shtylman_ hasn't been too active on the installer recently due to me OO.org work | 22:57 | |
| cjwatson | shtylman_: Evan knows more about that than I do, I'm not up-to-date | 23:00 |
| shtylman_ | cjwatson: thanks...will ping him... :) | 23:01 |
| shtylman_ | I imagine you have had your hands full with grub2? | 23:02 |
| cjwatson | that plus merges plus writing my own specs plus reviewing other people's ... | 23:05 |
| orbitus | cjwatson, any means of faking it? | 23:09 |
| cjwatson | orbitus: yes, it's just tedious | 23:15 |
| cjwatson | orbitus: basically you need to have a preseed/early_command that writes out a file /lib/partman/display.d/01early (call it whatever you like as long as it starts with 01 and is in that directory) with the stuff you want to run, and make it executable | 23:17 |
| cjwatson | you may need to 'mkdir -p /lib/partman/display.d' first - I'm not sure that that directory will necessarily exist yet when preseed/early_command runs | 23:18 |
| cjwatson | you might want to put 'if [ -f /var/lib/partman/initial_auto ]; then exit 0; fi' near the top of your 01early script, as otherwise it may run more than once | 23:19 |
| orbitus | cjwatson, thanks very much | 23:23 |
| cjwatson | I implemented partman/early_command largely because it was getting embarrassing having to explain that rubbish all the time :-) | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!