| CIA-59 | ubiquity: superm1 * r2980 ubiquity/ (5 files in 4 dirs): merge with mythbuntu-ubiquity branch. this should get rid of the rest of code duplication in mythbuntu_ui. All definitions should be calling their parent for as much common functionality as possible | 06:41 |
|---|---|---|
| superm1 | cjwatson, I introduced a fair deal of experimental stuff for the mythbuntu frontend in the above commits. i'd like to get these out in a package as soon as possible so there is plenty of testing time on dailies for regressions etc. are the rest of the pieces that get their source code pulled into ubiquity in a stabilish state that i can do that release? | 07:01 |
| === evan_ is now known as evand | ||
| cjwatson | superm1: I think so, yes | 09:42 |
| cjwatson | superm1: have you done an upload involving an update of d-i/source/ before? | 09:43 |
| xivulon | so have been experimenting with grub2 this w/e, and from what I can see it works well with the looback+ntfs module | 10:08 |
| xivulon | that would allow to avoid the bindmounted /boot dir and all related gymmicks | 10:09 |
| xivulon | I still need a configuration file in windows though, pointing to the correct loop file | 10:09 |
| xivulon | would you want me to move to grub2? | 10:10 |
| evand | We're only adding the option of grub2 this release. I'm slightly weary of forcing wubi users to it when we don't know what hardware it breaks on yet. cjwatson, do you have any thoughts on this? | 10:12 |
| evand | to slightly rephrase, we're only adding grub2 as an option | 10:12 |
| xivulon | well consider that I am updating from grub4dos not from grub legacy | 10:13 |
| cjwatson | I think experimentation should come before committing to it (i.e. "move to grub2") | 10:13 |
| cjwatson | add it as an option first, see how it goes, and then decide | 10:13 |
| cjwatson | there's just no way to reasonably give a yes/no answer at this point; we do not have enough information | 10:13 |
| xivulon | I will leave both the grub4dos code in there and add the grub2 code then, I will make it configurable from the makefile | 10:14 |
| xivulon | grub2 will of course require some changes in other existing ubuntu packages that deal with the bidnmounted boot | 10:16 |
| cjwatson | superm1: apparently mythweb.postinst configure is hanging during livefs builds. Could you chase it down please? It requires sysadmin intervention every time it happens to avoid breaking all our other livefs builds, so it's pretty urgent | 10:16 |
| cjwatson | any Ubuntu packages that deal with bind-mounted /boot should be checking whether it is bind-mounted, and therefore no changes should be needed aside from making it not bind-mounted any more | 10:16 |
| cjwatson | if they aren't checking that, they are already buggy | 10:16 |
| xivulon | evand, as mentioned at UDS, would you be interested in adding USB creator functionality to wubi? | 10:17 |
| xivulon | main issue is the boot menu (we would either have to use the grub menu or we would need to add syslinux) | 10:18 |
| xivulon | the only extra functionality is to write the mbr, and I have already a wubildr.mbr, which should do (in case of grub menu). | 10:20 |
| xivulon | could be done adding a new UI page or modifying the current installation page. | 10:25 |
| evand | xivulon: I'm not sure I follow what you mean by "USB creator functionality to wubi"? If you mean the ability to write USB disks from Wubi, I think that code should live inside usb-creator, and for the latter to grow a MFC/PyGTK/Windows.Forms/whatever frontend. | 10:26 |
| xivulon | most of the functionality to do usb creator is already available in wubi (including bittorrent, mirror selection, and signature/md5 checks), and that also provides a windows UI for python | 10:28 |
| xivulon | although not compatible with PyGTK | 10:28 |
| xivulon | In terms of interface you could come very close to the actual one, and not show the wubi dialogs at all, or add the optionality to the wubi dialog | 10:29 |
| evand | usb-creator does not download a copy of the ISO yet, but I'm keen to keep a common code path to avoid debugging problems. I also think we should present a consistent interface. | 10:30 |
| evand | I think the code for windows should live in the usb-creator package and not diverge too much from the existing frontend and backend. | 10:32 |
| xivulon | I guess all I am saying is that it would be possible to merge the 2 projects, the current implementation should support multiple backends/frontends | 10:34 |
| xivulon | so you could think of usb-creator as a wubi for linux, using pygtk, while the windows version uses the win32 wrapper | 10:35 |
| evand | That seems to violate the unix philosophy of do one thing and do it well, in my humble opinion. | 10:35 |
| evand | Merging the two projects, that is. | 10:35 |
| xivulon | not sure I agree, doing a usb bootable device is a strict subcase of what I have to do anyway | 10:37 |
| xivulon | otehr than dumping the mbr the rest of the code would be very similar | 10:37 |
| xivulon | This also means that if wubi is ported to linux, you can use that for usb-creator functionality | 10:38 |
| evand | Hrm | 10:40 |
| xivulon | anyway I am not going to insist, I thought it would have been beneficial to both, I would have gained a linux port and you a windows one | 10:40 |
| evand | I'll give it some thought | 10:40 |
| evand | And at the least give you a better answer | 10:41 |
| superm1 | cjwatson, yeah i chased it down yesterday re mythweb.postinst. there was an unnecessary db_stop in there. it should be fixed now | 14:03 |
| cjwatson | superm1: thanks | 14:03 |
| === davmor2 is now known as davmor2-away | ||
| CIA-59 | ubiquity: superm1 * r2981 ubiquity/ (d-i/manifest debian/changelog): Automatic update of included source packages: apt-setup | 14:28 |
| CIA-59 | ubiquity: superm1 * r2982 ubiquity/debian/changelog: releasing version 1.11.4 | 14:31 |
| superm1 | well i think i did the upload right, however bzr doesn't want to push my tag of the revision. since i was operating on bound branch i had to tag after the commit | 14:40 |
| superm1 | (sorted out the tag. it's up there now) | 14:56 |
| xivulon | by the way, I had a couple of issues on the w/e: I did not manage to preseed the password (get asked the question again), and clocksetup (utc) crashed | 14:56 |
| xivulon | "ClockSetup failed with code 1" (d-i clock-setup/utc boolean false) | 15:21 |
| cjwatson | xivulon: no idea, need your logs, please file a bug | 15:26 |
| cjwatson | (as ever, am interested in crashes, but unfortunately summaries of them are usually worse than useless) | 15:27 |
| xivulon | will do so tonight | 15:27 |
| === davmor2-away is now known as davmor2 | ||
| TheMuso | cjwatson: If I was to debug the problems with ubiquity+dmraid on a live CD, would it just be a matter of running ubiquity, trying to do an install onto a dmraid array, and getting the logs and recording the UI behavior? I'm thinking this may be worth looking into since users seem to want it on the live CD. | 21:41 |
| cjwatson | TheMuso: probably a good start at least | 22:03 |
| TheMuso | cjwatson: Ok thanks, I'll play with that today. | 22:04 |
| cjwatson | I'd have expected the problems to be either (a) ubiquity/partman interaction or (b) UI | 22:05 |
| TheMuso | Ok | 22:06 |
| Rudd-O | hey there | 22:58 |
| cjwatson | hi | 23:00 |
| Rudd-O | hey there colin | 23:01 |
| Rudd-O | did you get my mail? | 23:01 |
| cjwatson | I did, seems to be in direct competition with evand's usb-creator tool though :-) | 23:07 |
| cjwatson | anyway, probably more evand's kind of thing to play with | 23:08 |
| cjwatson | I'm paying more attention to the server installer side of things at the moment | 23:08 |
| cjwatson | currently working on a cdebconf extension to let us run aptitude during installation, disconnecting properly from debconf and clearing newt out of the way | 23:09 |
| cjwatson | (I have a new baby at the moment so unfortunately have very little time for anything other than primary-task type stuff, making e-mail responses a bit slow) | 23:10 |
| Rudd-O | oh, interesting | 23:14 |
| Rudd-O | so you're basically eliminating the use of newt? why? | 23:14 |
| cjwatson | not in the least | 23:15 |
| cjwatson | just need to clear it out of the way in order to run a full-screen ncurses application at one point, which is too complicated to use debconf | 23:15 |
| cjwatson | i.e. stop newt, run aptitude, restart newt the way it was - simple enough but requires a cdebconf plugin to do it. Should also fix some of the bugs in the rescue shell | 23:16 |
| Rudd-O | OH | 23:19 |
| Rudd-O | so what's your approach? are you storing the screen state before spawning the fullscreen app? | 23:20 |
| cjwatson | most of the state's in the frontend already - easier to just tear down newt, save off the few bits and pieces that aren't preserved by doing so, and then let the next debconf protocol command that needs to update the screen set it all back up again | 23:21 |
| cjwatson | this is already my second try at the same basic idea though so we'll have to see whether it works :) | 23:21 |
| Rudd-O | ah okay, clever | 23:21 |
| Rudd-O | quick question though | 23:22 |
| cjwatson | progress bars are basically the only thing that don't magically resolve themselves, since you can nest another question on top of a progress bar | 23:22 |
| Rudd-O | can you simply change to an unused VT? | 23:22 |
| cjwatson | I did consider that | 23:22 |
| Rudd-O | run the app there, and then chvt back to the original VT? | 23:22 |
| Rudd-O | that way the console code takes care of preserving your state | 23:22 |
| cjwatson | if possible, I'd prefer to run it on the same VT in order to force it to be modal | 23:22 |
| Rudd-O | which is even cooler now that the kernel has code to save the console backboffers | 23:23 |
| Rudd-O | well, yes, that'd be better and it'd also be compatible with vt emulators | 23:23 |
| cjwatson | I don't want to have to deal with somebody attempting to interact with tasksel while aptitude is running, or getting confused because they switched to tty4 to look at some logs and now they have to switch to tty5 rather than tty1 to get back | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!