CIA-59ubiquity: 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 possible06:41
superm1cjwatson, 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
cjwatsonsuperm1: I think so, yes09:42
cjwatsonsuperm1: have you done an upload involving an update of d-i/source/ before?09:43
xivulonso have been experimenting with grub2 this w/e, and from what I can see it works well with the looback+ntfs module10:08
xivulonthat would allow to avoid the bindmounted /boot dir and all related gymmicks10:09
xivulonI still need a configuration file in windows though, pointing to the correct loop file10:09
xivulonwould you want me to move to grub2?10:10
evandWe'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
evandto slightly rephrase, we're only adding grub2 as an option10:12
xivulonwell consider that I am updating from grub4dos not from grub legacy10:13
cjwatsonI think experimentation should come before committing to it (i.e. "move to grub2")10:13
cjwatsonadd it as an option first, see how it goes, and then decide10:13
cjwatsonthere's just no way to reasonably give a yes/no answer at this point; we do not have enough information10:13
xivulonI will leave both the grub4dos code in there and add the grub2 code then, I will make it configurable from the makefile10:14
xivulongrub2 will of course require some changes in other existing ubuntu packages that deal with the bidnmounted boot10:16
cjwatsonsuperm1: 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 urgent10:16
cjwatsonany 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 more10:16
cjwatsonif they aren't checking that, they are already buggy10:16
xivulonevand, as mentioned at UDS, would you be interested in adding USB creator functionality to wubi?10:17
xivulonmain issue is the boot menu (we would either have to use the grub menu or we would need to add syslinux)10:18
xivulonthe 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
xivuloncould be done adding a new UI page or modifying the current installation page.10:25
evandxivulon: 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
xivulonmost 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 python10:28
xivulonalthough not compatible with PyGTK10:28
xivulonIn 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 dialog10:29
evandusb-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
evandI 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
xivulonI guess all I am saying is that it would be possible to merge the 2 projects, the current implementation should support multiple backends/frontends10:34
xivulonso you could think of usb-creator as a wubi for linux, using pygtk, while the windows version uses the win32 wrapper10:35
evandThat seems to violate the unix philosophy of do one thing and do it well, in my humble opinion.10:35
evandMerging the two projects, that is.10:35
xivulonnot sure I agree, doing a usb bootable device is a strict subcase of what I have to do anyway10:37
xivulonotehr than dumping the mbr the rest of the code would be very similar10:37
xivulonThis also means that if wubi is ported to linux, you can use that for usb-creator functionality10:38
xivulonanyway 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 one10:40
evandI'll give it some thought10:40
evandAnd at the least give you a better answer10:41
superm1cjwatson, yeah i chased it down yesterday re mythweb.postinst.  there was an unnecessary db_stop in there.  it should be fixed now14:03
cjwatsonsuperm1: thanks14:03
=== davmor2 is now known as davmor2-away
CIA-59ubiquity: superm1 * r2981 ubiquity/ (d-i/manifest debian/changelog): Automatic update of included source packages: apt-setup14:28
CIA-59ubiquity: superm1 * r2982 ubiquity/debian/changelog: releasing version 1.11.414:31
superm1well 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 commit14:40
superm1(sorted out the tag.  it's up there now)14:56
xivulonby 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) crashed14:56
xivulon"ClockSetup failed with code 1" (d-i clock-setup/utc boolean false)15:21
cjwatsonxivulon: no idea, need your logs, please file a bug15:26
cjwatson(as ever, am interested in crashes, but unfortunately summaries of them are usually worse than useless)15:27
xivulonwill do so tonight15:27
=== davmor2-away is now known as davmor2
TheMusocjwatson: 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
cjwatsonTheMuso: probably a good start at least22:03
TheMusocjwatson: Ok thanks, I'll play with that today.22:04
cjwatsonI'd have expected the problems to be either (a) ubiquity/partman interaction or (b) UI22:05
Rudd-Ohey there22:58
Rudd-Ohey there colin23:01
Rudd-Odid you get my mail?23:01
cjwatsonI did, seems to be in direct competition with evand's usb-creator tool though :-)23:07
cjwatsonanyway, probably more evand's kind of thing to play with23:08
cjwatsonI'm paying more attention to the server installer side of things at the moment23:08
cjwatsoncurrently working on a cdebconf extension to let us run aptitude during installation, disconnecting properly from debconf and clearing newt out of the way23: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-Ooh, interesting23:14
Rudd-Oso you're basically eliminating the use of newt?  why?23:14
cjwatsonnot in the least23:15
cjwatsonjust 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 debconf23:15
cjwatsoni.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 shell23:16
Rudd-Oso what's your approach?  are you storing the screen state before spawning the fullscreen app?23:20
cjwatsonmost 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 again23:21
cjwatsonthis is already my second try at the same basic idea though so we'll have to see whether it works :)23:21
Rudd-Oah okay, clever23:21
Rudd-Oquick question though23:22
cjwatsonprogress bars are basically the only thing that don't magically resolve themselves, since you can nest another question on top of a progress bar23:22
Rudd-Ocan you simply change to an unused VT?23:22
cjwatsonI did consider that23:22
Rudd-Orun the app there, and then chvt back to the original VT?23:22
Rudd-Othat way the console code takes care of preserving your state23:22
cjwatsonif possible, I'd prefer to run it on the same VT in order to force it to be modal23:22
Rudd-Owhich is even cooler now that the kernel has code to save the console backboffers23:23
Rudd-Owell, yes, that'd be better and it'd also be compatible with vt emulators23:23
cjwatsonI 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 back23:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!