#ubuntu-installer 2007-10-01
<CIA-18> ubiquity: superm1 * r2294 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py): install xmltv from on-cd repo if requested
<CIA-18> ubiquity: superm1 * r2295 ubiquity/ (debian/changelog scripts/mythbuntu/apply-drivers): correct minor typo in nvidia xorg creation
<CIA-18> ubiquity: superm1 * r2296 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py): process conflicts before installing items
<siretart> how do you test d-i? with qemu or do you prefer some other virtualisation technique?
<cjwatson> vmware or real hardware, depending
<siretart> hm. virtualbox seems to be working great as well..
<cjwatson> yeah, I've been meaning to try it
<cjwatson> but ENOTIME
<CIA-18> oem-config: cjwatson * r330 oem-config/ (debian/changelog oem-config-dm): * Start dcopserver when running the KDE frontend (LP: #145226).
<CIA-18> ubiquity: cjwatson * r2297 ubiquity/ (bin/ubiquity-dm debian/changelog):
<CIA-18> ubiquity: * Start dcopserver when running the KDE frontend in automatic-ubiquity
<CIA-18> ubiquity:  mode (LP: #145226).
<CIA-18> oem-config: cjwatson * r331 oem-config/build/ (config.guess config.sub ltmain.sh): update libtool files to 1.5.24-1ubuntu1
<CIA-18> oem-config: cjwatson * r332 oem-config/ (configure configure.ac): bump to 1.20
<CIA-18> oem-config: cjwatson * r333 oem-config/lib/frontend/kde_ui.py: import oem_config.i18n in KDE frontend
<CIA-18> oem-config: cjwatson * r334 oem-config/debian/po/templates.pot: debconf-updatepo
<CIA-18> oem-config: cjwatson * r335 oem-config/.bzrignore: ignore debian/oem-config-check
<CIA-18> oem-config: cjwatson * r336 oem-config/lib/ (frontend/gtk_ui.py i18n.py): missing imports
<CIA-18> oem-config: cjwatson * r337 oem-config/ (debian/changelog oem-config-firstboot):
<CIA-18> oem-config: * Add a --debug option to oem-config-firstboot to make debugging a bit
<CIA-18> oem-config:  less painful.
<CIA-18> oem-config: cjwatson * r338 oem-config/lib/frontend/kde_ui.py: only translate widgets once UI has been created
<CIA-18> oem-config: cjwatson * r339 oem-config/ (gui/qt/sysconf.ui lib/frontend/kde_ui.py): fix stray references to button_back and button_next
<xivulon> cjwatson, evand, howdy
<xivulon> couple of things: sent you a msg to do some realistic planning about wubi
<cjwatson> hello
<xivulon> hi
<xivulon> just back
<xivulon> hope you had a restful w/e
<xivulon> cjwatson, point #2 is, how I mentioned last week, that szaka suggested to upgrade the version of ntfs-3g
<xivulon> my uinderstanding of the subject is zip
<xivulon> so I don't know if someone with more experience wants to have a better look into the subject to see if an upgrade makes sense
<cjwatson> it's already on my list
<cjwatson> you're the second person to ask me about it today :)
<xivulon> cjwatson, tried to do some bisecting last friday. In several circumstances I can run mkfs.ext3 manually, but was not able to pinpoint the problematic line. I'll resume my testing tonight
<xivulon> zeroing is not a factor
<cjwatson> yeah, I saw your comments; I have not had any time to look myself
<xivulon> cjwatson, as mentioned in the email, also did a small change to lupin, that, coupled with your early_command patch, is the backup plan
<CIA-18> oem-config: cjwatson * r340 oem-config/lib/frontend/kde_ui.py: KDE frontend: retranslate some widgets when language changes
<CIA-18> oem-config: cjwatson * r341 oem-config/lib/frontend/ (gtk_ui.py kde_ui.py): retranslate back and next button labels when language changes
<CIA-18> oem-config: cjwatson * r342 oem-config/lib/frontend/kde_ui.py: fix widget name
<CIA-18> oem-config: cjwatson * r343 oem-config/ (gui/qt/sysconf.ui lib/frontend/kde_ui.py lib/i18n.py): fix widget name clash; retranslate heading labels immediately
<cjwatson> oops, uncommitting
<CIA-18> oem-config: cjwatson * r343 oem-config/ (gui/qt/sysconf.ui lib/frontend/kde_ui.py lib/i18n.py): fix widget name clash; retranslate heading labels immediately
<cjwatson> that's better
<CIA-18> oem-config: cjwatson * r344 oem-config/lib/frontend/kde_ui.py: retranslate everything when switching away from language page
<cjwatson> argh, this is such a mess
<CIA-18> oem-config: cjwatson * r345 oem-config/lib/frontend/kde_ui.py: fix heading label retranslation
<CIA-18> oem-config: cjwatson * r346 oem-config/debian/ (changelog control rules):
<CIA-18> oem-config: * Remove use of dh_python, since it's a no-op now. Bump debhelper
<CIA-18> oem-config:  build-dependency to 5.0.37.3ubuntu2 (a.k.a. dh_python from 5.0.38) for
<CIA-18> oem-config:  this.
<CIA-18> oem-config: cjwatson * r347 oem-config/ (debian/changelog oem-config-dm): * Clean up subprocesses even if oem-config-dm is interrupted.
<_MMA_> Hi guys. I'm hoping someone besides Colin can help be out with some bugs in the Ubuntu Studio daily alt disks. I have the bugs reported if anyone wants to look. There's 3.
<_MMA_> Thanx Colin. Now there's 2. :)
<cjwatson> _MMA_: FWIW base-installer is a very specific component of the alternate installer that deals with installing the base system and the kernel. If you don't know the exact installer component responsible for a bug in the alternate installer, the catch-all package is "debian-installer".
<cjwatson> (I've reassigned your two bugs to the correct component)
<_MMA_> Ahh... Ok. Ill look again. Thanx.
<evand> cjwatson: fyi, there are other issues caused by the version of ntfs-3g that we're using as well: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/135370/comments/13
<evand> err rather, fwiw
<cjwatson> evand: hmm, I had thought that that was fixed by the 3>&- tweak in partman-basicfilesystems 54ubuntu4
<cjwatson> though I hadn't gone round and closed all the bugs yet, and I do see your point with szaka mentioning various cases that are improved with the newer ntfs-3g
<CIA-18> ubiquity: cjwatson * r2298 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py): - Retranslate oem_id_label when the language is changed.
<cjwatson> evand: how does http://paste.ubuntu.com/525/ look to you? somebody suggested it in that gtk bug report
<cjwatson> I haven't tested it yet though
<evand> cjwatson: looks good.  It'll be great to finally have a fix for that bug, even if it's just a workaround.
<cjwatson> dunno if it'll work without an intervening gtk.main() mind you
<cjwatson> hopefully that won't be an issue
<CIA-18> oem-config: cjwatson * r348 oem-config/ (3 files in 2 dirs):
<CIA-18> oem-config: * GTK frontend:
<CIA-18> oem-config:  - Go forward when activating rows in language or keyboard treeviews.
<CIA-18> oem-config: cjwatson * r349 oem-config/lib/frontend/gtk_ui.py: GTK frontend: retranslate widgets when changing language
<cjwatson> _MMA_: Luke's having a go at the remaining tasksel bug
<_MMA_> cjwatson: Yes. If I could Id give him a big hug. :)
<_MMA_> cjwatson: He's on our Ubuntu Studio team.
<cjwatson> yep
* _MMA_ owes way too many people a beer in Boston.
<superm1_> cjwatson, would you be able to look and see if our task is properly listed in our seed?
<CIA-18> oem-config: cjwatson * r350 oem-config/lib/frontend/gtk_ui.py: translate widgets from all glade files, not just the main one
<cjwatson> superm1_: which seed?
<superm1_> cjwatson, https://code.edge.launchpad.net/~mythbuntu/ubuntu-seeds/mythbuntu.gutsy
<cjwatson> that's a seed branch - which seed?
<superm1_> oh sorry, desktop seed
<cjwatson> one sec, something weird happened and I'm having to check out again
<cjwatson> superm1_: any particular reason why you don't want the desktop task offered by tasksel?
<cjwatson> Task-Test-new-install: skip skip
<superm1_> i didn't know what that meant
<cjwatson> were you copying that from ubuntustudio?
<superm1_> yeah
<cjwatson> yeah, that's a special case
<cjwatson> I'd remove that line
<superm1_> okay
<cjwatson> the description doesn't seem to make sense with "desktop"?
<cjwatson> or am I just not smart enough? :)
<superm1_> well the way it functions, you can use it with an existing desktop if you want to
<superm1_> but the mythbuntu-desktop package provides all the packages common to all roles
<cjwatson> hmm, ok
<cjwatson> other than that it looks fine, just needs to be added to tasksel
<superm1_> okay so how does that happen?
<cjwatson> by the magic cjwatson switch
<superm1_> hehe
<superm1_> does this also mean that this will be an available task on the alternate install disks?
<cjwatson> done in bzr
<cjwatson> no, no room on the CDs
<superm1_> well but it can grab packages from internet?
<cjwatson> it won't, though
<cjwatson> in any event the alternate install disk deliberately doesn't offer tasksel
<cjwatson> it's all on automatic
<cjwatson> it'll be offered by netboot
<superm1_> right
<cjwatson> oh, one more seed bug
<cjwatson> you need to include the mythbuntu-desktop package in your desktop seed as well as making it Key
<superm1_> so it depends upon itself?
<cjwatson> no
<cjwatson> the seed is not the same as the metapackage
<superm1_> oh when the meta is generated, it will ignore that then?
<cjwatson> and the metapackage build system (assuming you're using the standard one) skips packages with the same name
<cjwatson> right
<superm1_> okay
<CIA-18> oem-config: cjwatson * r351 oem-config/d-i/update-control: fix base build-dep
<CIA-18> oem-config: cjwatson * r352 oem-config/ (d-i/manifest debian/changelog):
<CIA-18> oem-config: * Automatic update of included source packages: console-setup 1.16ubuntu5,
<CIA-18> oem-config:  localechooser 1.38ubuntu2, user-setup 1.14ubuntu3.
<CIA-18> oem-config: cjwatson * r353 oem-config/ (debian/changelog scripts/localechooser-apply):
<CIA-18> oem-config: * Make sure the selected locale at least exists (we should really install
<CIA-18> oem-config:  the language pack, but this is a stopgap measure).
<CIA-18> oem-config: cjwatson * r354 oem-config/debian/changelog: releasing version 1.20
<cjwatson> hooray, it works
<CIA-18> ubiquity: cjwatson * r2299 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-18> ubiquity: * Work around http://bugzilla.gnome.org/show_bug.cgi?id=56070 by hiding
<CIA-18> ubiquity:  and re-showing the button widgets, following a suggestion by Scott
<CIA-18> ubiquity:  Horowitz.
<CIA-18> oem-config: cjwatson * r355 oem-config/ (configure configure.ac): bump to 1.21
<CIA-18> oem-config: cjwatson * r356 oem-config/ (debian/changelog lib/frontend/gtk_ui.py):
<CIA-18> oem-config: * Work around http://bugzilla.gnome.org/show_bug.cgi?id=56070 by hiding
<CIA-18> oem-config:  and re-showing the button widgets, following a suggestion by Scott
<CIA-18> oem-config:  Horowitz.
<evand> awesome
<superm1> cjwatson, did you have a time frame in mind for when 1.6.1 was going to be uploaded to the archive at this point?
<cr3> how can I preseed a single package I'm installing with dpkg?
<cjwatson> superm1: no, don't normally plan that sort of thing very closely
<superm1> cjwatson, okay that's what i was assuming
<cjwatson> cr3: makes no difference how it's installed. If you mean outside the context of the installer's preseeding framework, use debconf-set-selections?
<cr3> cjwatson: that's exactly what I was looking for, thanks
<cjwatson> superm1: outer bound is probably Thursday or so, FWIW; we'll need to start the process of locking down for RC at that point
<cjwatson> (though there'll still be some slack)
<superm1> cjwatson, okay, well at this point the only other thing that i'm planning on possibly getting in (beyond bug fixes) will be a partitioning recipe
<superm1> so that should be fine
<cjwatson> that would go in partman-auto, not ubiquity
<superm1> well right
<cjwatson> oh, well
<superm1> but there would be ubiquity changes to list it as an option?
<cjwatson> unless you mean preseeded with partman-auto/expert_recipe
<superm1> would there not
<cjwatson> no
<cjwatson> aside from sucking in the new partman-auto source
<cjwatson> you might not want to do it that way though
<superm1> well but i wouldn't want to list it in gtk/kde frontends
<cjwatson> partman-auto/expert_recipe could be done on the CD image
<superm1> hrm
<cjwatson> TBH, if you haven't settled on partitioning code at this point, I'd strongly advise deferring it to hardy
<superm1> yeah good call.
<cjwatson> it's not a good thing to mess with at the last minute
<superm1> enough other items to sort out before release here anyway
<cjwatson> tweaks, sure ... but not new code
<mebrown> cjwatson, evand, are the scripting changes in today's daily gutsy?
<mebrown> just did a quick test without good results and wanted to ask before I started debuggin.
#ubuntu-installer 2007-10-02
<cjwatson> mebrown: no, only in bzr
<cjwatson> they'll be in 1.6.1
<mebrown> which day can I expect them to be in daily gutsy? (I'm working on other details right now and have hacked in all the patches from evan and everthing is working fine)
<mebrown> So it is not a huge rush to get them in.
<cjwatson> by Thursday
<mebrown> ok. Thanks. All my stuff is working great with the latest patch set.
<cjwatson> good to know
<cjwatson> Evan and I were talking about splitting up the "automation failed" and "installation failed" cases
<cjwatson> since they're logically distinct
<mebrown> I'll mark fix confirmed as soon as I see them in a daily build.
<cjwatson> so you might need to adjust your preseeding a little if that happens; Evan can let you know at any rate
<mebrown> for my case, I dont think it really matters. Just let me know.
<cjwatson> right, it doesn't matter in your case (the two hooks would want to be the same)
<cjwatson> but we need to think generally too :-)
<mebrown> right.
<mebrown> completely understand and can deal with any changes given a warning.
<mebrown> So, just keep me in mind and let me know if it changes.
<mebrown> Personally, I would probably separate them.
<superm1> evand, have you tested your code from evand@ubuntu.com-20070928190548-mdrjta41znoro86g and evand@ubuntu.com-20070928192642-q1l4bx157irqvvzt ?
<superm1> i just encountered an error with GrubInstaller failing with code 1 with a locally built package doing a normal install
<superm1> where it was trying to issue the command 'grub-install false'
<cjwatson> +                self.preseed('grub-installer/bootdev', 'false')
<cjwatson> hmm, quite, that's wrong, that's not a boolean
<cjwatson> evand: (all yours though, I'm going to bed ...)
<superm1> night cjwatson
<superm1> i'm imagining that should just be self.preseed('grub-installer/bootdev', bootdev) at that point
<CIA-18> ubiquity: superm1 * r2300 ubiquity/ubiquity/components/install.py: when not in automatic, preseed the bootdev obtained from debconf, not 'false'
<superm1> (i just verified that worked correctly in my vm)
<evand> oh wow, whoops
<evand> thanks for noticing that and the subsequent fix, superm1
<superm1> no prob
<CIA-18> ubiquity: cjwatson * r2301 ubiquity/ (debian/changelog gui/glade/ubiquity.glade):
<CIA-18> ubiquity: * Make the OK button the default widget in the create and edit partition
<CIA-18> ubiquity:  dialogs.
<CIA-18> ubiquity: cjwatson * r2302 ubiquity/debian/changelog: reorg
<CIA-18> ubiquity: superm1 * r2166 mythbuntu-ubiquity/ (192 files in 19 dirs): merge with trunk
<CIA-18> ubiquity: superm1 * r2167 mythbuntu-ubiquity/scripts/install.py:
<CIA-18> ubiquity: locally disable (unnecessary) calls to cache.open(None) after discussion
<CIA-18> ubiquity: in #ubuntu-devel with mvo
<cjwatson> superm1: could you please test that by deliberately breaking a package or something?
<superm1> cjwatson, i was just going to see if i could.
<superm1> (that's not on trunk if you didn't realize)
<superm1> any recommendations on how to deliberately break something?
<cjwatson> might be easier to do on removal
<cjwatson> stick 'exit 1' near the top of /var/lib/dpkg/info/ubiquity.prerm?
<superm1> k
<cjwatson> I forget how I did it last time
<cjwatson> but if you get it right you should get a dialog box with the names of broken packages
<superm1> cjwatson, yeah it does work correctly http://imagebin.org/10797
<superm1> the installer throws that and then continues on
<cjwatson> superm1: no, it's not ...
<cjwatson> superm1: it's not listing the broken packages
<cjwatson> it should say:
<superm1> there is a second dialog
<superm1> let me imagebin it
<cjwatson> The following packages are in a broken state:
<cjwatson> ubiquity
<cjwatson> instead, it has a blank line
<superm1> http://imagebin.org/10798
<cjwatson> sure, but the first dialog is bust
<cjwatson> and that dialog is generated directly after the code you removed ...
<superm1> so with this way of doing it, would just modifying that other dialog make sense?
<cjwatson> no
<cjwatson> the change you made is demonstrably incorrect
<cjwatson> because self.broken_packages(cache) isn't working
<cjwatson> might be worth taking that to mvo
<cjwatson> broken_packages iterates over the cache and does cache._depcache.IsInstBroken() on each
<cjwatson> the second dialog is a lot less neat if multiple packages break; I'd rather have the summary
<superm1> well the order of those two are reversed, i uploaded them backwards
<superm1> and i thought that first one was generated because an InstallError would have been thrown
<cjwatson> no, look at the code right after the line you removed
<cjwatson> the bit that asks the broken_install or broken_remove debconf question
<superm1> oh  i see
<jimcooncat> I'm setting up an automated netboot install server, and I'd like to run badblocks before partitioning. Looks like this is only on the wishlist for d-i.
<jimcooncat> Perhaps I could netboot a livecd to run badblocks?
<jimcooncat> How do you netboot a live cd?
<jimcooncat> sorry, gotta go
<evand> isn't that what SMART is for?
<cr3> anyone happen to know if there's python code to to parse those dpkg .templates files?
<cjwatson> cr3: they're not dpkg, they're debconf
<cjwatson> please don't invent code outside debconf to parse them
<cjwatson> you can use debconf-copydb to extract them in a form you can parse
<cjwatson> ubiquity/i18n.py in ubiquity does this
<cjwatson> (and is better than parsing *.templates or even /var/cache/debconf/templates.dat directly because we might quite reasonably switch to a new database format - using debconf-copydb insulates you from that)
#ubuntu-installer 2007-10-03
<cr3> cjwatson: thanks for the advice
<xivulon> cjwatson, autopartiotion-loop line 188 should use $mount_move
<cjwatson> so it should
<xivulon> going to do a quick test now
<cjwatson> fixed in 0ubuntu11
* cjwatson -> bed
<xivulon> can you pls also put the latest lupin edits into the ISO?
<xivulon> tomorrow I mean
<xivulon> together with autopartition-loop
<cjwatson> uploaded
<xivulon> thanks
<cjwatson> I don't normally think in terms of "putting something into the ISO", BTW
<cjwatson> I upload it and the automatic build processes take care of the rest :)
<cjwatson> anyway, really bedtime
<xivulon> good night
<CIA-18> oem-config: cjwatson * r357 oem-config/debian/changelog: reorg
<CIA-18> oem-config: cjwatson * r358 oem-config/ (debian/changelog lib/frontend/gtk_ui.py): - Remove some duplication of work now done in oem_config.i18n.
<CIA-18> oem-config: cjwatson * r359 oem-config/debian/ (110 files in 3 dirs): * Add lots of translations from Rosetta.
<CIA-18> oem-config: cjwatson * r360 oem-config/debian/ (changelog rules): * Don't ignore 'make distclean' errors other than missing Makefiles.
<CIA-18> oem-config: cjwatson * r361 oem-config/debian/ (changelog rules): * Remove d-i/source/console-setup/Keyboard/MyKeyboardNames.pl on clean.
<CIA-18> ubiquity: cjwatson * r2303 ubiquity/debian/ (changelog rules): * Remove d-i/source/console-setup/Keyboard/MyKeyboardNames.pl on clean.
<CIA-18> ubiquity: cjwatson * r2304 ubiquity/ (bin/ubiquity-dm debian/changelog debian/control):
<CIA-18> ubiquity: * Only run gnome-settings-daemon if it exists, removing dependency on
<CIA-18> ubiquity:  gnome-control-center (LP: #147852).
<CIA-18> oem-config: cjwatson * r362 oem-config/debian/changelog: releasing version 1.21
<CIA-18> oem-config: cjwatson * r363 oem-config/ (configure configure.ac): bump to 1.22
<CIA-18> oem-config: cjwatson * r364 oem-config/ (debian/changelog debian/control oem-config-dm):
<CIA-18> oem-config: * Only run gnome-settings-daemon if it exists, removing dependency on
<CIA-18> oem-config:  gnome-control-center (LP: #147852).
<CIA-18> oem-config: cjwatson * r364 oem-config/ (debian/changelog debian/control oem-config-dm):
<CIA-18> oem-config: * Only run gnome-settings-daemon if it exists, removing dependency on
<CIA-18> oem-config:  gnome-control-center (LP: #147852).
<CIA-18> oem-config: cjwatson * r364 oem-config/ (debian/changelog debian/control oem-config-dm):
<CIA-18> oem-config: * Only run gnome-settings-daemon if it exists, removing dependency on
<CIA-18> oem-config:  gnome-control-center (LP: #147852).
<cjwatson> damn that code duplication
<cjwatson> and CIA event duplication too ;)
<cjwatson> (it gave me 500 internal server error the first two times, so I assumed it hadn't got it)
* cjwatson goes back to try to sleep again
* Starting logfile irclogs/ubuntu-installer.log
<CIA-18> ubiquity: cjwatson * r2305 ubiquity/debian/ (changelog ubiquity.templates): * Add advanced button text to translation template (LP: #147612).
<CIA-18> ubiquity: cjwatson * r2306 ubiquity/ (5 files in 3 dirs):
<CIA-18> ubiquity: * Add install button text to translation template, distinguished from the
<CIA-18> ubiquity:  window title (LP: #103925).
<CIA-18> ubiquity: cjwatson * r2307 ubiquity/ (debian/changelog ubiquity/i18n.py): * Load strings for "Use as:" and "Mount point:".
<CIA-18> ubiquity: cjwatson * r2308 ubiquity/debian/ (79 files in 2 dirs): * Update translations from Rosetta.
<CIA-18> ubiquity: cjwatson * r2309 ubiquity/debian/po/ (79 files): debconf-updatepo
<CIA-18> ubiquity: cjwatson * r2310 ubiquity/ (d-i/manifest debian/changelog):
<CIA-18> ubiquity: * Automatic update of included source packages: base-installer
<CIA-18> ubiquity:  1.81ubuntu4, partman-auto-loop 0ubuntu11, partman-target 50ubuntu5.
<CIA-18> ubiquity: cjwatson * r2311 ubiquity/debian/changelog: releasing version 1.6.1
<xivulon> cjwatson, what's your view on the non-interactive version of wubi (one with implicit --liveboot)?
<cjwatson> you mean on including something on the Ubuntu CDs that just does that?
<cjwatson> sounds good to me
<xivulon> yeah
<xivulon> just to go around bios issues
<cjwatson> yes
<xivulon> I think it's unrealistic at this point to ship loop installations :(
<cjwatson> once it slipped past beta, it was a pretty slim chance, unfortunately
<xivulon> As mentioned, if it is easy to make it work later on (with the standlone version), that's still okish
<cjwatson> well, no worse than feisty
<soren> Any clue which package this actually belongs to: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/97160 ?
<cjwatson> soren: looks like it belongs to ubiquity to me
<cjwatson> though I've no idea what might cause it in 7.04
<soren> Alright. Thanks.
<soren> One of the Danish translators asked me, because he couldn't find anything like that in the ubiquity translations.
<soren> I'll tell him to look harder :)
<xivulon> cjwatson, is the early_command patch uploaded?
<cjwatson> xivulon: ages ago
<cjwatson> soren: I'm not sure why people think it's a translation bug ...
<xivulon> also, it would be good if we used zeroing at least for the swap file, since that does not tolerate holes
<cjwatson> xivulon: *sigh* you told me yesterday that zeroing wasn't important
<cjwatson> could you file a bug please?
<xivulon> cjwatson, it's not relevant for the mkfs issue, but it still has some merits
<soren> cjwatson: Oh, good point.
<xivulon> particularly for the swap file
<cjwatson> soren: it might be, but it certainly isn't a dead cert
<soren> cjwatson: Well, ubiquity itself only seems to have two translatable strings, and they both look sane, so if it indeed *is* a translation bug, I don't think it's in ubiquity itself.
<xivulon> cjwatson, I will generate a non interactive build for wubi tonight. I'd like to use a different name not to confuse the 2: wubi-liveboot.exe?
<xivulon> I'll be in boston from wed. Hope I won't miss relevant installer discussion. I'll prepare a blueprint for discussing wubi and related issues.
<cjwatson> soren: they're almost all in debian-installer
<cjwatson> soren: ubiquity's po-debconf strings are borged into there and hidden from /ubuntu/+source/ubiquity
<cjwatson> because many of them are common with the rest of the installer
<cjwatson> xivulon: wubi-liveboot.exe> sure
<cjwatson> tell me what to wget when it's ready
<soren> cjwatson: Yes, I suspected something like that.
<soren> cjwatson: ...which was why I was interested in which particular piece of the puzzle was involved at that point in the installation. I guessed partman, but he couldn't see anything wrong there either. Anyhow, don't worry about it. He got something to work with, so he's happy now :)
<evand> how on earth is it possible to have incorrect number of arguments on a SUBST when the first argument is *always* specified?
<cjwatson> that was exactly what I was wondering
<cjwatson> I have no clue
<evand> I think a set -x is in order if he still can reproduce it.
<evand> ah! I figured it out.  Play with IFS and you're going to get bitten, apparently.
<evand> erm bit
<tormod> hi, I am pretty keen on fixing bug #148341 for Gutsy. What do you think?
<evand> I'll defer to cjwatson on that.
<cjwatson> evand: ah, yes, I always keep the interval where IFS is non-default as small as possible
<cjwatson> tormod: your latest patch is fine by me
<cjwatson> evand: ^-- (I'm off to bed, but apply it if you like)
<tormod> cjwatson: cool! I guess a debdiff won't help - this bzr?
<cjwatson> tormod: waste of your time
<tormod> cjwatson: thought so :)
<cjwatson> patch can apply patches against files other than the one named in the patch just fine
<evand> cjwatson: heh, I thought I did as well
<evand> cjwatson: will do
<xivulon> cjwatson, latest autopartition code is not on today's build
#ubuntu-installer 2007-10-04
<CIA-18> ubiquity: evand * r2312 ubiquity/ (configure configure.ac): Bump to 1.6.2
<CIA-18> ubiquity: evand * r2313 ubiquity/debian/ (changelog init):
<CIA-18> ubiquity: * Add 'only-ubiquity' option to kernel cmdline to run ubiquity in a
<CIA-18> ubiquity:  minimal session. Thanks Tormod Volden (LP: #148341).
<CIA-18> ubiquity: evand * r2314 ubiquity/ (debian/changelog ubiquity/components/migrationassistant.py): * Filter out partition selections that do not have any users.
<evand> I probably should've stuck 'migration-assistant' in there somewhere.
<xivulon> cjwatson, evand, I uploaded the wubi-cdonly version
<xivulon> http://wubi-installer.org/devel/minefields/
<xivulon> one thing: if the CD is inserted when you reboot all is dandy
<xivulon> but if the CD is not inserted the user is thrown into the shell
<xivulon> it would be nice to have some sort of message like: please insert the CD and press enter
<xivulon> by the way, the flag changed from "--liveboot" to "--cdboot"
<xivulon> In Ubuntu-cdboot the flag is always set
<cjwatson> xivulon: please mail Henrik to tell him about that
<xivulon> will do
<cjwatson> since he will need to adjust winfoss
<cjwatson> I'll make it be wubi-cdboot.exe on the disk
<xivulon> please test it
<xivulon> also have a look at this issue about the CD not being inserted. I seemed to remember that the initrd would ask for it, but maybe I am confusing with the alternate one
<cjwatson> you are confusing it with alternate
<cjwatson> I'm not going to add that feature to casper at this point
<xivulon> hmm, not sure then if it's wise to include wubi at all
<xivulon> if users have no CD they will see the initrd sh
<xivulon> anyway try it by changing your boot priority, with and without CD, then you decide
<cjwatson> if they have no CD then they will hardly be running wubi-cdboot from the CD
<cjwatson> this is about what we put on the CD, so by definition they have a CD
<xivulon> cjwatson, what I mean is if the bios is 1HD, 2CD, but if at the time they reboot the tray is open
<cjwatson> *shrug* don't do that then :)
<cjwatson> it's still better than not having the facility
<cjwatson> IMO
<xivulon> sure
<xivulon> I'll have to change the reboot text
<xivulon> now it asks to remove the cd
<xivulon> will do tonight
<cjwatson> oh, yeah, that would be excessively confusing in this case
<cjwatson> and clearly not necessary
<xivulon> I forgot to do that yesterday, it's a quick fix
<xivulon> but cannot do it now
<xivulon> by the way, yesterday build still had old autopartition/lupin
<xivulon> and am still stack with this mkfs issue (when running strace mkfs, it works)
<cjwatson> gar STOP LEAVING
<cjwatson> really inconvenient
<smp> Hi,i am tring to install my debian distro from local network,I booted from the network and got the installation prompt.but after installed hardware detection phase it failed because it didnot find any installation media in my cdrom as i am using the same initrd/kernel/preseed file for network installation which is same for normal installation (from CD).SO HOW TO OVERCOME THE PROBLEM..?Plz help
<cjwatson> smp: I'm afraid we don't offer help with Debian here
<cjwatson> smp: (though I would suggest *not* using the same initrd as for CD installation; there's a specialised netboot initrd which is likely to work much better!)
<cjwatson> smp: if the above doesn't help, #debian-boot on irc.oftc.net would be more appropriate
<smp> Cjwatson:thanks,but can u tell me is there any way to do the normal installation so that it should not go to check installation media in local cdrom drive.
<cjwatson> see above, please
<cjwatson> this channel is for the Ubuntu installer, not Debian
<smp> cjwatson:rather it should download files from my local server where i mounted my iso image.can i do it by suppling any boot parameters
<cjwatson> no, use netboot
<smp> for ubuntu also if i want to do the same thing i think this problem will come
<cjwatson> for Ubuntu, use netboot
<cjwatson> the cdrom initrd will not work in this circumstance
<smp> but how to modify the exsisting initrd for netboot?
<cjwatson> you don't.
<cjwatson> download the netboot initrd from the archive
<cjwatson> you cannot do this based on the cdrom initrd.
<smp> i have the installer source code .and i compiled it and then i got mini.iso inside /installer/temp
<cjwatson> there is no need to build it yourself
<cjwatson> both Debian and Ubuntu ship this in their archives
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386/current/images/netboot/ for Ubuntu; see the Debian installer web site for the Debian links
<smp> ok,but i need my custom initrd.how to do that ?
<cjwatson> folks customising the initrd are expected to be experts and/or to read the documentation. Failing that, please ask in the correct place.
<cjwatson> I'm happy to help if you're customising Ubuntu, but it doesn't sound like you are at present. In the meantime, I don't think it's fair to ask me to support Debian in an Ubuntu channel.
<smp> ok.can u tell me some sources to modify ubuntu's exsisting netboot initrd
<cjwatson> 'apt-get source debian-installer' on an Ubuntu system
<smp> cjwatson:thanks for ur help.but this will download only the source code in my system.what i have.i need some docs to change/compile the source code
<cjwatson> there is documentation in the doc/ subdirectory of the debian-installer source package, though it hasn't been adapted for Ubuntu
<cjwatson> I cannot teach you how to be a developer in general though
<CIA-18> ubiquity: jriddell * r2315 trunk/ (debian/changelog ubiquity/frontend/PartitionsBarKde.py): red looks dangerous to our western eyes, change ext 3 in kde partition bar to cyan
<xivulon> I changed the reboot text
<CIA-18> migration-assistant: evand * r63 migration-assistant/ (debian/changelog ma-ask): * Fix IFS handling (LP: #145712, #135149)
<mebrown> quick question: what are the 'mkisofs' command parameters that are used to create the live cd?
<mebrown> The last step of my installation is going to create a new live CD image of the reinstallation partition for the customer to burn if they want
<mebrown> evand, ping.
<mebrown> evand, just tested todays daily build and looks like everything is there and works.
<evand> mebrown: great!  I'm trying to find the answer to your question.
<mebrown> ok, thx.
<mebrown> I have a mkisofs cmdline that I am using in the meantime...
<mebrown> mkisofs -o /target/home/ubuntu-dell-reinstall.iso \
<mebrown>     -b isolinux/isolinux.bin -c isolinux/boot.catalog \
<mebrown>     -no-emul-boot -boot-load-size 4
<mebrown>     -boot-info-table \
<mebrown>     -pad -r -J -joliet-long -N -hide-joliet-trans-tbl \
<mebrown>     -publisher "Dell Inc." \
<mebrown>     -V "Dell Ubuntu Reinstallation Media" \
<mebrown>     /cdrom/
<evand> /usr/bin/mkisofs -r -V Ubuntu\ 7.10\ amd64 -o /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/debian-cd/amd64/gutsy-desktop-amd64.raw -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -sort /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/gutsy-amd64/1.weights boot1 CD1
<evand> from: ttp://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/gutsy/daily-live-20071004.log
<evand> mebrown: ^
<mebrown> thanks.
<evand> anytime
<mebrown> I'll update my script
<mebrown> Right now, I am wrestling with language pack stuff.
<mebrown> What I was thinking:
<evand> ah yes, be aware that there's an outstanding bug that I have to fix tonight where the langugage pack step will fail without a network connection
<mebrown> hmmm.
<mebrown> so that will work in tomorrows daily?
<evand> hopefully
<evand> if not soon thereafter
<mebrown> I need to run this idea by you... just a sec, brb
<evand> ok
<mebrown> What I was thinking was creating a repo with all the language packs
<mebrown> just like the repo that is already on the DVD
<mebrown> but smaller.
<mebrown> I need an easy way to do this, and havent really figured anything out.
<mebrown> I was thinking I could use apt-get in download-only mode
<mebrown> and then I would have to add those to the repo and redo the repo metadata
<mebrown> We have pared down the languages to 5 or 6
<evand> hrmm
<mebrown> english, french, german, portugues, spanish, simplified chinese
<mebrown> also (unrelated): need to find a way to get rid of the "remove media and press enter to reboot" at the end.
<evand> you might be able to get around that by shutting down usplash: /etc/init.d/usplash start
<evand> that's not a typo
<evand> I'm not sure if that will work or not, it's untested
<mebrown> ok. I'll test it, then... :)
<evand> have you looked into debmirror for grabbing the languages?
<evand> you might want to run your current idea by cjwatson
<evand> he may know of a better way
<mebrown> no, I havent
<mebrown> I didnt even know about debmirror
<bdmurray> evand: I was looking at bug 128258 and wondered what happens to people who installed from a tribe CD that didn't create '/etc/papersize'.  Do you have any idea?
<evand> bdmurray: not sure
<evand> I'd have to test that myself to find out :)
<bdmurray> It is easy enough to manually fix but I wonder if many people will run into it.
<evand> do we usually provide repair fixes for bugs that occur during the development cycle?
<bdmurray> Another good question that I don't have the answer for.
<bdmurray> I'm not sure how many things look at '/etc/papersize' too.
<evand> hrm, cjwatson ^
<mebrown> evand, '/etc/init.d/usplash start' does not fix
<mebrown> there is a text line:
<mebrown> "Please remove the disc and close the tray (if any) and press ENTER:"
<mebrown> on the console
<mebrown> and no shells that I can use to see what is giving that message... :(
<mebrown> Is there already a launchpad on this issue?
<evand> mebrown: not yet, but please file a bug and assign me to it.  I'll take care of it when I get back, but I have to step out for a few hours.
<mebrown> against ubiquity?
<mebrown> or casper?
<evand> hrm, casper
<mebrown> https://bugs.launchpad.net/dell/+bug/149159
<evand> thanks
<mebrown> evand, cjwatson ping...  is there a way to run automatic-ubiquity in text mode?
<mebrown> am thinking of future systems where X doesnt run.
<mebrown> need to be able to install them initially. we would update x server debs in the post-install.
#ubuntu-installer 2007-10-05
<boss> hi,i am new bie in ubuntu.I want to know how to install ubuntu in the client machines from the local server where internet connection is not available.I have CD rom drive only in a single machine(server).
<booxter> Hello! I'm a Belarusian Latin translator and I would like to see Ubuntu LiveCD and installer to be Belarusian-Latin supported. What should I do to take the goal? Is there a technical possibility for doing this?
<mpt> booxter, you want to translate the installer into Belarusian?
<booxter> mpt, yes
<mpt> booxter, you can do that on https://translations.launchpad.net/ubuntu
<mpt> booxter, for example, https://translations.launchpad.net/ubuntu/gutsy/+lang/be
<booxter> Launchpad technically doesn't support our be@latin locale...
<booxter> so we need some kind of "manual" way of translation
<mpt> Oh, I'm sorry, that's Belarusian Cyrillic, isn't it
<mpt> You want Belarusian Latin
<mpt> ok, so you need to get Belarusian Latin registered in Launchpad
<booxter> yes, we need
<booxter> but there is a known bug that prevents us from doing so
<booxter> sr@Latn (Serbian Latin) also has such problem
<cjwatson> getting the installer to support that is a lot harder
<cjwatson> you really need to get it done upstream in Debian
<booxter> our locale technically is a variant of "be" locale
<cjwatson> simply having the translation there isn't enough - localechooser needs to support it too
<mpt> oh
<cjwatson> and it takes an enormous number of uploads of individual components to Ubuntu to add a new language, diverging each of them from Debian individually
<cjwatson> so I prefer not to do it that way, and to ask people to get the base installer translated in Debian first
<booxter> So should we at first translate debian installer?
<cjwatson> right
<booxter> are there any significant changes between vanilla installer and ubuntu one?
<cjwatson> yes
<cjwatson> so just translating the Debian installer won't be enough, but it's the first step
<booxter> hm, as I know there are several "levels" of Debian translation
<booxter> what levels are sinificant for Ubuntu, what are less?
<booxter> And after what level can we incorporate Ubuntu version of installer to make sure we are ready?
<cjwatson> level 1 is the only one that's a blocker here
<cjwatson> obviously the rest don't hurt
<mpt> booxter, I'm discussing it in #launchpad with one of the Launchpad Translations developers
<booxter> Are other levels not used for Ubuntu version?
<mpt> Apparently Cyrillic->Latin conversion can be done automatically for Serbian, and maybe for Belarusian too
<mpt> but there's no schedule for implementing it yet
<booxter> mpt, we in Belarusian community already begins to use such translation, but not fully automatically (because we use different convensions and so on)
<cjwatson> booxter: they're used to one extent or another, but some particular packages there are less important than others and in any event it doesn't usually block switching on a language in localechooser
<cjwatson> there's a point at which packages begin to become subject to language packs, at which point it all gets a lot easier for you
<cjwatson> but the core installer, mostly the stuff in level 1 plus dpkg, apt, tasksel, probably a couple of others I forget right now, isn't subject to language packs because this is all before language packs get installed
<booxter> cjwatson, we already reported a bug about Language chooser
<cjwatson> you did? where?
<cjwatson> I won't fix it directly in Ubuntu anyway - like I say, this really needs to be done in Debian first otherwise the maintenance burden for us to diverge every installer component from Debian is intolerable
<cjwatson> but I'm more than happy to support the language once the basic bits are done in Debian and uploaded there
<booxter> hm, ok, we'll do our best for Debian Installer and after level 1 will come here again:)
<cjwatson> sounds lovely
<booxter> ;)
<CIA-18> ubiquity: cjwatson * r2316 ubiquity/debian/ (79 files in 2 dirs): * Update translations from Rosetta.
<CIA-18> ubiquity: cjwatson * r2317 ubiquity/ (d-i/manifest debian/changelog):
<CIA-18> ubiquity: * Automatic update of included source packages: choose-mirror 2.15ubuntu2,
<CIA-18> ubiquity:  debian-installer-utils 1.48ubuntu2.
<CIA-18> ubiquity: cjwatson * r2318 ubiquity/debian/ (changelog rules): * Disable the intro message, as Ubuntu 7.10 is approaching.
<CIA-18> ubiquity: cjwatson * r2319 ubiquity/debian/changelog: releasing version 1.6.2
<CIA-18> ubiquity: evand * r2320 ubiquity/ (configure configure.ac): bump to 1.6.3
<CIA-18> ubiquity: evand * r2321 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-18> ubiquity: * Remember to not use the migration-assistant dbfilter when using
<CIA-18> ubiquity:  --no-migration-assistant, again (LP: #148766).
<CIA-18> ubiquity: evand * r2322 ubiquity/ubiquity/frontend/ (kde_ui.py noninteractive.py): Apply the previous change to the kde and noninteractive frontends.
<mebrown> cjwatson, saw your commit for #149159 (console reboot message). is this in todays daily build?
<cjwatson> it should be$ wget -q -O- http://cdimage.ubuntu.com/daily-live/current/gutsy-desktop-i386.manifest | grep ^casper
<cjwatson> casper 1.109
<cjwatson> yes
<mebrown> thx.
<mebrown> did you see my email about language packs?
<mebrown> really need some help with that one, as I am not a debian/dpkg/apt expert
<cjwatson> language-pack-* shouldn't have external dependencies
<cjwatson> it's only a problem at all if you need language-support-* too
<mebrown> I want a complete and good experience for our non-english-speaking customers
<cjwatson> evand: could you help mebrown out? I have a deadline of today for UDS planning
<evand> cjwatson: sure
<cjwatson> germinate may be useful
<mebrown> ok. I looked at debmirror yesterday and it didnt seem useful (no dependency tracking, afaict)
<mebrown> I'll take a look at germinate.
<cjwatson> debmirror does not follow dependencies
<evand> https://wiki.ubuntu.com/SeedManagement might help with setting up a seed for germinate.
<mebrown> thanks. reading...
<mebrown> evand: regarding noninteractive... doesnt work
<evand> mebrown: where does it fall over?
<mebrown> No cut-n-paste, but it traces back:
<mebrown> frontend/noninteractive.py, line 133 in watch_debconf_fd_helper
<cjwatson> I would avoid trying text installs in gutsy. They aren't well enough tested.
<mebrown>   return callback(souce, dbbconf_condition)
<cjwatson> at least not using ubiquity
<mebrown> file ubituqity/filteredcommand.py, line 179 in process_input
<mebrown> file ubituqity/filteredcommand.py, line 112, process_line
<mebrown> ubiquity/debocnffilter.py, line 236
<mebrown> file ubiquity/components/language.py line 105
<mebrown> file ubiquity/filteredcommand.py, line 359 in run
<mebrown>   -> if not self.frontend.installing:
<mebrown> AttributeError: wizard instance has no attribute 'installing'
<mebrown> and it starts X before falling over.
<mebrown> What I am trying to accomplish:
<mebrown> Need to have a way to install machines that potentially dont have X support in the current gutsy image
<cjwatson> mebrown: I understand your need, but 7.10 isn't yet ready to fill it with the live CD
<mebrown> ok.
<mebrown> we can respin the image, I suppose
<mebrown> if we get a machine like this.
<cjwatson> we should be able to fix the specific bug above though
<mebrown> or, can probably force vesa mode
<cjwatson> I think that's more likely to work
<mebrown> just want to make sure I have a fallback
<cjwatson> oh, forcing vesa should be pretty safe
<mebrown> because we *always* get machines that come down with no X support (we install addon stuff in post)
* evand has added the above bug to his todo list
<mebrown> evand, did you need a lp?
<evand> mebrown: if it's not too much trouble
<mebrown> ok.
<mebrown> https://bugs.launchpad.net/dell/+bug/149473
<evand> thank you
<evand> cjwatson: I know you're busy, so feel free to respond to this whenever you have free time.  What is the reasoning for marking bugs as invalid in a package and then adding them to a different package, rather than just switching the package?
<mebrown> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/149477
<mebrown> I'm installing a machine now to try out germinate. Will probably have more questions in a couple hours, but it looks like this is probably what I want.
<evand> great
<cjwatson> evand: usually an accident
<cjwatson> evand: note though that you can't just reassign from a package to an upstream project
<cjwatson> so say if a bug is really a cdimage bug then it has to have a task opened on ubuntu-cdimage and the Ubuntu task rejected
<evand> ok
<evand> thanks
<CIA-18> ubiquity: evand * r2323 ubiquity/ (debian/changelog ubiquity/frontend/noninteractive.py):
<CIA-18> ubiquity: * Update noninteractive frontend to use recent changes to
<CIA-18> ubiquity:  FilteredCommand (LP: #149473).
<bdmurray> cjwatson: Did you see my /etc/papersize question?
<cjwatson> bdmurray: no
<bdmurray> I believe there was a bug in ubiquity where papersize was not being set which is now fixed but what happens to people who installed with ubiquity before it was fixed.
<bdmurray> It is probably a small number of people and I don't know how many things look at that file either.
<cjwatson> there was a bug, upgrades aren't handled, it should probably be release-noted
<cjwatson> a core library looks at that file which I believe a number of desktop applications use
<bdmurray> Okay, do we have process for release noting things?
<cjwatson> we need to create some release notes :-)
<cjwatson> hang on a mo
<cjwatson> aha, GutsyGibbon/ReleaseNotes
<cjwatson> please feel free to add to that
<bdmurray> Okay, will do.
<bdmurray> Thanks.
<mebrown> is there a bug in today's daily build regarding sudo?
<mebrown> oem install
<evand> not that I'm aware of
<mebrown> when I create a user at firstboot, that user cant sudo
<evand> hrm
<mebrown> and I cant login as root
<mebrown> since I didnt set pw
<evand> I'm assuming they're not in the admin group?
<mebrown> I think it has been there for a little bit since I saw that yesterday too
<mebrown> correct, not in admin group
<mebrown> groups=1000(dell)
<mebrown> bug against firstboot?
<mebrown> shouldnt that user be  created as an admin, since there isnt any other way to log in as root, otherwise?
<mebrown> that is how it used to work.
<mebrown> at least in feisty
<cjwatson> I think it's a bug in your image
<cjwatson> it normally is given admin privileges
<mebrown> pulled fresh today, saw the same thing yesterday
<cjwatson> are you creating any other non-system users or groups?
<mebrown> no.
<cjwatson> mebrown: ok, is this from the alternate or desktop CD?
<mebrown> create 'oem' user in preseed
<mebrown> this is the live cd
<mebrown> booted with oem-mode and preseed
<cjwatson> can I have your preseed file?
<cjwatson> without passwords
<mebrown> yup.
<mebrown> just a sec, I'll post it.
<cjwatson> a bug report on oem-config would be the best avenue
<mebrown> cjwatson, email address?
* mebrown just cleaned out inbox...
<cjwatson> mebrown: https://bugs.launchpad.net/ubuntu/+source/oem-config/+filebug
<cjwatson> but if you'd really prefer e-mail, cjwatson@ubuntu.com
<cjwatson> just that my inbox is a disaster area
<mebrown> I'll file a bug
<cjwatson> mebrown: I'm out for a bit now
<cjwatson> fwiw
<mebrown> just thought that would be the fastest way to get it to you
<cjwatson> for the record, IRC is one of the worst possible ways to paste large quantities of stuff
<mebrown> ok, sorry.
<cjwatson> it sits there for ages gradually pasting line by line :-/
<mebrown> just trying to figure out a quick way to get you the info.
<cjwatson> anyway, have to go pick my wife up
<mebrown> bug is being entered.
<mebrown> have fun.
<evand> mebrown: in the event that you do need to paste a large amount to IRC: http://pastebin.ubuntu.com/
<mebrown> ah, yes. I forget about that...
<mebrown> https://bugs.launchpad.net/dell/+bug/149582
#ubuntu-installer 2007-10-06
<mebrown> cjwatson, evand, ping.
<mebrown> https://bugs.launchpad.net/dell/+bug/135602
<mebrown> marked as 'invalid', but I see this bug in today's daily.
<mebrown> hmm... Ok, I see that it is closed as a dup of: https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/23537
<mebrown> which is 'fix released'
<mebrown> but question remains: when will this hit the daily builds?
<mebrown> cjwatson, --^
<mebrown> cjwatson_,, did you see my last couple sentences?
<cjwatson_> nope
<mebrown> ok...
<mebrown>  https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/23537
<mebrown> which is 'fix released'
<cjwatson> yep
<mebrown> I dont see it fixed in today's daily
<mebrown> and I tried your wget manifest| grep trick
<mebrown> and dont see oem-config listed... :(
<cjwatson> I'll have to try it out
<cjwatson> it's not in the live image, grep for it in .list
<cjwatson> /pool/main/o/oem-config/oem-config_1.21_i386.deb
<mebrown> which looks to me like it should be fixed...
<cjwatson> should be
<mebrown> as lp# shows closed in 1.20
<mebrown> but...
<mebrown> when I tried it out. I installed all language packs on my list and chose 'spanish' as the language
<mebrown> and the rest of the screens were still in english
<mebrown> (I speak spanish pretty well, so it is easy for me to test...)
<mebrown> should I re-open the lp#?
<cjwatson> let me try it
<mebrown> I have to go for tonight in a min
<cjwatson> it's 23:30 here, if I don't respond or fix it or something, sure, reopen it
<mebrown> ok.
<mebrown> british time?
<cjwatson> yes
<mebrown> ok. Well, have a great weekend.
<mebrown> send me an email if you need anything.
<cjwatson> ok
<mebrown> I have this issue and iirc one other one that are important to me to get the Dell install going
<mebrown> https://bugs.launchpad.net/dell/+bug/149582
<mebrown> is the other critical one.
<mebrown> for the installer
<cjwatson> yeah, you mentioned that, I'll look at the same time
<mebrown> If you need anything from me, I'll be checking email this weekend. I know you are in the last few days worth of changes before the release.
<cjwatson> I have a lingering suspicion it's because you're preseeding the username and full name when that's not necessary
<cjwatson> (or shouldn't be anyway)
<cjwatson> but I can't think of a reason why that would actually break this
<mebrown> ok. If it isnt needed, I can just as easily take it out.
<mebrown> just remove the value, or the entire line?
<cjwatson> leave it there for now
<cjwatson> maybe it's a generic bug, in which case I can squash it
<mebrown> ok.
<cjwatson> Spanish is a good test case BTW, because its oem-config translation is complete
<cjwatson> the translation team was nice and speedy
<mebrown> Well, I'm going now. Let me know if you need anything from my side. You have my preseed.
<mebrown> Yeah,
<mebrown> I'm considering changing my desktop to spanish by default
<mebrown> to get more practise
<mebrown> just noticed testing today that there werent very many untranslated strings around the desktop at all
<mebrown> (as compared to, say, chinese)
<mebrown> ttfn.
<xivulon> cjwatson,evand I am out of ideas with the mkfs bug
<xivulon> to make a long story short, if I pause at the end of autopartition-loop and run strace mkfs.ext3 /dev/loop2 it works
<xivulon> if run mkfs without strace it doesn't
<xivulon> any hint of what I may try?
<cjwatson> xivulon: sorry, I have no bright ideas, sounds like a race but who knows
<CIA-18> ubiquity: cjwatson * r2324 ubiquity/ (debian/changelog scripts/install.py):
<CIA-18> ubiquity: * Remove excessive blank lines in GDM and KDM configuration files in OEM
<CIA-18> ubiquity:  mode.
<xivulon> cjwatson is the update of ntfs-3g going to happen? maybe that can address it (hmm might test that)
* xivulon testing ntfs-3g 1.1913
<J-Georg_> Morning.
<J-Georg_> I have a grub-related problem installing Ubuntu, could anyone help me a little?
<CIA-18> oem-config: cjwatson * r365 oem-config/ (debian/changelog lib/frontend/gtk_ui.py):
<CIA-18> oem-config: * GTK frontend:
<CIA-18> oem-config:  - Make sure the next button remains the default widget despite being
<CIA-18> oem-config:  hidden and re-shown.
<cjwatson> J-Georg_: it's a weekend and I was mostly planning to do other things; if you explain your problem and hang around for a bit, I or somebody may be able to
<J-Georg_> Ok, the installation just fails to grub-install (hd0). The root partition is an ext3 at /dev/sda5 and if I chroot to /target and try to do it by hand it fails with "/boot/grub/stage1 not read correctly."
<J-Georg_> I had to create menu.lst by myself as it didn't exist.
<J-Georg_> I was browsing the forums and checked fstab and mtab as suggested but they look fine to me.
<cjwatson> just one disk?
<J-Georg_> Yes.
<J-Georg_> device.map looks ok as well...
<cjwatson> normally that error is because fstab and menu.lst are out of sync (and beware that grub counts partition numbers from zero not from one)
<cjwatson> but it's possible that it could also be because grub's internal low-level read-stuff-from-the-disk code is breaking
<cjwatson> which is liable to be beyond me :-/
<J-Georg_> Right...
<J-Georg_> I'll take another look at fstab and menu.lst
<cjwatson> I'm sorry that may not be a very satisfying answer
<cjwatson> in extremis, you could try installing lilo
<CIA-18> ubiquity: cjwatson * r2325 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-18> ubiquity: * GTK frontend:
<CIA-18> ubiquity:  - Make sure the next button remains the default widget despite being
<CIA-18> ubiquity:  hidden and re-shown.
<J-Georg_> In fstab /dev/sda5 was identified by UUID. Changed it to /dev/sda5, it didn't help.
<J-Georg_> In menu.lst root is set to (hd0,4)
<cjwatson> if you want to try to dig into exactly what's failing, there should be log and image files left over from grub-install's attempts to read back stage1 lying around in /tmp
<cjwatson> it copies the files to /boot/grub/ and then tries to read them back using the 'dump' command in the grub shell, then does a binary compare to ensure they're the same
<cjwatson> I trust you don't have a separate /boot?
<J-Georg_> No, it's on the same sda5
<cjwatson> the other problem you *could* be having is that maybe you have a sufficiently wacky BIOS that grub is having trouble reading from the logical partition
<cjwatson> might be worth trying to put a small /boot on a primary partition if possible
<cjwatson> also, put /boot near the start of the disk
<cjwatson> depending on the vintage and bugginess of the BIOS, it may have trouble reading from later in the disk
<J-Georg_> Ok. Now I can see in the tmp file that:
<J-Georg_> Error 17: Cannot mount selected partition
<J-Georg_> As a result to dump command.
<cjwatson> 17 : Cannot mount selected partition
<cjwatson>      This error is returned if the partition requested exists, but the
<cjwatson>      filesystem type cannot be recognized by GRUB.
<cjwatson> interesting
<J-Georg_> Wait a little...
<J-Georg_> let me check fdisk output
<J-Georg_> /dev/sda5 xxxx xxxxx   xxxxxxxx 7 HPFS/NTFS
<J-Georg_> Shouldn't it be Linux?
<J-Georg_> Or doesn't it matter if fstab says it's ext3?
<cjwatson> that does matter
<J-Georg_> Well, changing id
<cjwatson> or at least it certainly could matter, ext2fs_mount does check that
<cjwatson> interesting how it got that way - I'd like to see your installation logs
<cjwatson> (/var/log/syslog and /var/log/partman if you're still in the installer)
<cjwatson> if you could try to copy those out before you finish the installation and reboot, I'd appreciate it
<J-Georg_> Already rebooted...
<J-Georg_> Sry.
<cjwatson> damn
<cjwatson> are they in /var/log/installer/ ?
<cjwatson> I guess you've probably trashed them now so I won't be able to figure out why this happened :-/
<cjwatson> if you were using the alternate installer, there's a chance they might still be there
<J-Georg_> Well, the partitioning was done in Windows.
<J-Georg_> Hence the NTFS setting.
<cjwatson> ah
<J-Georg_> Ubuntu installer didn't complain about it and created ext3 happily on it.
<cjwatson> could you file a bug on partman-base? (that may not be the right package but it's a start)
<J-Georg_> But failed at the grub stage.
<cjwatson> and explain the situation
<J-Georg_> Ok.
<cjwatson> were you using the alternate install CD or the desktop CD?
<cjwatson> feel free to just paste this whole IRC log into the bug
<J-Georg_> Desktop CD.
<cjwatson> ok
<J-Georg_> Ok, trying to install again now with right ID.
<J-Georg_> It's AMD 64 install cd.
<cjwatson> that shouldn't matter
<J-Georg_> Ok.
<J-Georg_> Thanks for guidance, anyway :)
<J-Georg_> The hint about tmp files was very helpful :)
<cjwatson> should probably copy the grub log output to the syslog
<cjwatson> this is weird, it definitely tries to set the partition id
<cjwatson> J-Georg_: did you use automatic partitioning?
<cjwatson> I guess not if you did the partitioning in Windows
<cjwatson> J-Georg_: perhaps you could describe to the best of your memory exactly what you did in the partitioner
<J-Georg_> Used manual partitioning.
<cjwatson> J-Georg_: any more detail?
<CIA-18> oem-config: cjwatson * r366 oem-config/debian/ (59 files in 2 dirs): * Update translations from Rosetta.
<CIA-18> oem-config: cjwatson * r367 oem-config/ (d-i/manifest debian/changelog):
<CIA-18> oem-config: * Automatic update of included source packages: user-setup 1.14ubuntu4
<CIA-18> oem-config:  (LP: #149582).
<CIA-18> oem-config: cjwatson * r368 oem-config/debian/changelog: releasing version 1.22
<J-Georg_> Right...
<J-Georg_> It still doesn't work...
<J-Georg_> Wait a little...
<J-Georg_> I changed the partition Id but it's again HPFS/NTFS...
<J-Georg_> Weird...
<cjwatson> remember to save the logs this time, please
<cjwatson> I'm off to do other things for a while (comment about weekend above :-))
<J-Georg_> Ok, thanks anyway.
<J-Georg_> There's only version file in /var/log/installer
<cjwatson> /var/log/syslog and /var/log/partman are the ones you want before reboot
<cjwatson> they're only copied into /var/log/installer/ right at the end
<J-Georg_> Ok.
<xivulon> cjwatson, the only way to go around the mkfs issue is to run mkfs on the file and not on the loopdevice (no need to detach the loopdevice)
<xivulon> how difficult would that be to override the current partman behaviour?
#ubuntu-installer 2007-10-07
<CIA-18> ubiquity: cjwatson * r2326 ubiquity/ (debian/changelog scripts/install.py):
<CIA-18> ubiquity: * Shell out to sed for now rather than using flaky, complicated, and above
<CIA-18> ubiquity:  all incorrect code to edit gdm.conf and kdmrc for autologin in OEM mode
<CIA-18> ubiquity:  (LP: #149985).
<cr3> cjwatson: would you mind a quick debian filesystem naming convention question for my project which is unfortunately off-topic for this channel?
<cjwatson> cr3: send me mail and I'll answer in work hours, unless it's super-urgent
<cr3> cjwatson: it's not super urgent, just something I happen to be working on right now and I noticed you were active on #ubuntu-devel. I'd still appreciate your feedback which can indeed wait until working hours, so I'll send an email :)
<cr3> cjwatson: sent and thanks in advance :)
<CIA-18> ubiquity: cjwatson * r2327 ubiquity/debian/ (79 files in 2 dirs): * Update translations from Rosetta.
<CIA-18> ubiquity: cjwatson * r2329 ubiquity/debian/changelog: releasing version 1.6.3
#ubuntu-installer 2008-09-29
<CIA-50> ubiquity: cjwatson * r2859 ubiquity/ (aclocal.m4 configure debian/changelog):
<CIA-50> ubiquity: Revert part of intltool 0.40.4 change (described in bug 275795) that
<CIA-50> ubiquity: caused top_builddir not to be set in po/Makefile.
<CIA-50> ubiquity: cjwatson * r2860 ubiquity/ (configure configure.ac): bump to 1.10.1
<CIA-50> ubiquity: cjwatson * r2861 ubiquity/debian/changelog: releasing version 1.10.1
<davmor2> cjwatson: Xubuntu has a usplash again now :)
<cjwatson> excellent
<CIA-50> ubiquity: cjwatson * r2862 method-filesystem-split/ (9 files in 6 dirs):
<CIA-50> ubiquity: Split up method and filesystem in the partitioning UI into two separate
<CIA-50> ubiquity: widgets.
<CIA-50> ubiquity: cjwatson * r2864 method-filesystem-split/ubiquity/components/partman.py: teach get_current_filesystem to handle detected filesystems that are not yet being used
<CIA-50> ubiquity: cjwatson * r2863 method-filesystem-split/ubiquity/frontend/gtk_ui.py: get_sensitive() -> get_property('sensitive')
<CIA-50> ubiquity: cjwatson * r2865 method-filesystem-split/ubiquity/components/partman.py: fix detection of 'filesystem' in method_choices
<CIA-50> ubiquity: cjwatson * r2862 ubiquity/ (debian/changelog ubiquity/components/partman.py):
<CIA-50> ubiquity: Only show the "EFI boot partition" option while creating a partition if
<CIA-50> ubiquity: the current hardware supports it usefully.
#ubuntu-installer 2008-09-30
<CIA-50> ubiquity: cjwatson * r2866 method-filesystem-split/ (4 files in 3 dirs):
<CIA-50> ubiquity: Automatically set the method when the mount point is set or unset
<CIA-50> ubiquity: (LP: #274297).
<CIA-50> partman-base: cjwatson * r107 ubuntu/ (3 files in 3 dirs): Exit straight away if a called script is killed by a signal.
<CIA-50> partman-auto: cjwatson * r271 ubuntu/ (choose_partition/auto/do_option debian/changelog): Exit straight away if a called script is killed by a signal.
<CIA-50> partman-partitioning: cjwatson * r686 ubuntu/ (debian/changelog free_space/new/do_option): Exit straight away if a called script is killed by a signal.
<CIA-50> ubiquity: cjwatson * r2867 method-filesystem-split/ubiquity/ (components/partman.py frontend/gtk_ui.py frontend/kde_ui.py): fix filesystem editing
<CIA-50> ubiquity: cjwatson * r2868 method-filesystem-split/ubiquity/frontend/gtk_ui.py: pass filesystem name when creating partitions, not description
<CIA-50> ubiquity: cjwatson * r2863 ubiquity/ (3 files in 2 dirs):
<CIA-50> ubiquity: When creating a new partition, default to logical if a primary partition
<CIA-50> ubiquity: already exists, since there are stricter constraints on primary
<CIA-50> ubiquity: partitions and the only real reasons for them are Microsoft operating
<CIA-50> ubiquity: systems or boot partitions (LP: #218938).
<yannickm1> hi.... Can someone give me hand to solve a problem with installer CD customization?
<yannickm1> *knock knock* anyone ?
<superm1> yannickm1, it's a little bit early in the morning for the european work day.  if you hang out for a bit, someone should pop in that can help you out a little bit
<yannickm1> oic :)
<yannickm1> i'll try later on then... I'm in australia lol
<superm1> yannickm1, your best bet is to leave yourself idle in here and pose the question you're having
<superm1> check back later on then
<yannickm1> yeah i'll try in the evening from home
<yannickm1> thanks :)
<yannickm1> Hi... I'm having some major pains customizing a ubuntu CD (spend many hours tracking down the reason, and down to having located the problem happens when i replace the ubuntu-keychain with my own which includes my key to sign the repositories. However the package i've created seems fine and i can't find any reason what is wrong). The problem it's causing is that in the networking bit, it's trying to use PPPOE when it shouldn
<yannickm1> persia ?
<persia> Yes?
<yannickm1> I was wondering if you could help with a bizzare problem i'm having with a ubuntu cd customization
<yannickm1> spend many hours tracking down the reason, and down to having located the problem happens when i replace the ubuntu-keychain with my own which includes my key to sign the repositories. However the package i've created seems fine and i can't find any reason what is wrong). The problem it's causing is that in the networking bit, it's trying to use PPPOE when it shouldn't (failing of course)
<yannickm1> any idea why changing the keychain causes ppoe to occur ? :(
<persia> No idea at all how a change in the keyrings could do that.  Are you sure it's not that changing the keyrings changed the trust in some other package, which causes the change?
<yannickm1> possibly
<yannickm1> but the old keys are in the keyring, so it shouldn't be problem
<yannickm1> i have a script that takes an iso (been trying with server), and rebuilds a new one
<yannickm1> i've just kinda ran out of ideas.. and i don't know how to track down the problem further... that script is the minimum i could in terms of modifications
<yannickm1> that's why i came to this channel in hope of finding someone with some time and expertise in the installer to identify the issue :)
<persia> Hrm.  I may not be entirely the right person then :)  I have been learning about the various quirks of ubiquity and d-i to support live images for some flavours, but all my work has been based on the assumption of a working liveCD, and it sounds like your issue happens earlier in the process.
<yannickm1> ok thanks... i'll wait for more ppl get be online then :)
<cjwatson> yannickm1: I think you're best off making customised CDs unsigned
<cjwatson> yannickm1: PPPOE getting pulled in sounds like you accidentally fed the installer udebs from universe or something
<persia> I've another preseeding question.  With the fix to 182004, I've gone back to working with --automatic, but it appears that setting a blank password isn't working.  Do I need to use a construction like "", or should just "d-i passwd/user-passwd password" and "d-i passwd/user-password-again password" be sufficient?
<cjwatson> the latter ought to be sufficient
<cjwatson> after you've fixed the typo in the first bit
<cjwatson> oh, but user-setup won't accept a blank password, probably
<cjwatson> you'd have to add a preseedable thing to permit forcing that
<persia> The typo exists only in IRC.  I'll look at user-setup.  Thanks.
<CIA-50> ubiquity: cjwatson * r2864 ubiquity/ (5 files in 3 dirs): Initialise auto-login checkbox from debconf database (LP: #276247).
<davmor2> strange one for you.  Ubuntu, Xubuntu, Kubuntu all get a usplash for the installed system from netboot however edubuntu doesn't :-/
<davmor2> I just checked edubuntu artwork and usplash 0.1.0-55ubuntu1 are both installed so I'm guessing it should be displayed?
<cjwatson> dpkg -l usplash-theme-ubuntu edubuntu-artwork-usplash, please
<cjwatson> and check whether splash is in /boot/grub/menu.lst
<davmor2> splash is in yes
<davmor2> usplash-theme-ubuntu = 0.19
<davmor2> edubuntu-artwork-usplash = 0.1.0-55ubuntu1
<cjwatson> all sounds as expected. you'll need to talk to Edubuntu folks
<cjwatson> i.e. the installer is behaving as intended
<davmor2> cjwatson: okay thanks :)
<tckb> can anybody tell me whos the creater of ubiguity
<tckb> fuck u
<tckb> all
<tckb> here
<TheMuso> Lovely.
<persia> Grrr.  I completely forgot to fix debian/rules when adding grub support to lpia for ubiquity.  Any chance of an upload for beta, or did I miss.
<persia> Actually, never mind.  There's something else wrong too.  It's not worth delaying anyone else for my mistake.
<lool> Heya
<yannickm1> Hi... Can anyone help me with an installer problem... I've been trying to customize a ubuntu cd. but after i customize it, in the network setup fase, it tries to bring up PPPOE when it shouldn't (failing of course). I spent many hours tracking down the reason, and got down to having located the problem happening when i replace the ubuntu-keychain with my own which includes my key to sign the repositories, plus repackaging/re
<davmor2> xivulon: just running the wubi tests now :)  Umenu update has fixed the invalid disc message :)
<yannickm1> anyone can provide some help with tracing the issue ?
<cjwatson> yannickm1: I already answered you earlier today
<cjwatson> 10:58 <cjwatson> yannickm1: I think you're best off making customised CDs unsigned
<cjwatson> 10:59 <cjwatson> yannickm1: PPPOE getting pulled in sounds like you accidentally fed the installer udebs from universe or something
<cjwatson> yannickm1: for anything beyond that, I'd need to see the installer syslog
<yannickm1> oic
<yannickm1> i can just make it unsigned, it doesn't verify or anything ?
<yannickm1> i did a comparison of the Packages files, and they contain exactly the same
<yannickm1> packages
<cjwatson> it does verify it if the signature is there, but it *should* work if you just delete Release.gpg as well
<cjwatson> let me know if it doesn't
<yannickm1> what could cause it to pull in others ?
<cjwatson> anyway, there is no reason that makes sense to me why that should affect pppoe
<cjwatson> please put the installer syslog somewhere I can see it
<yannickm1> can i send you that by email ?
<cjwatson> I'd prefer you found some other way
<cjwatson> paste.ubuntu.com or something
<yannickm1> interesting didn't know about that one lol
<yannickm1> k i'm guessing you probably are around here frequently so i'll pop by
<cjwatson> I am, yes
<yannickm1> so by the way tell me if i understand correctly how the installer works
<cjwatson> it's the sort of thing that *could* happen due to some kind of signature problem, but it would be an indirect effect at most
<yannickm1> the debs used by the installers are the ones in the installer 'Packages' file right ?
<cjwatson> ok, there are two Packages files on the CD
<cjwatson> well, actually, more, but two types
<yannickm1> yup
<cjwatson> /dists/hardy/*/binary-*/Packages refers to .debs; those include what gets installed on the target system
<cjwatson> /dists/hardy/*/debian-installer/binary-*/Packages refers to .udebs; those are components of the installer itself
<yannickm1> yup that was my assumption
<yannickm1> so for PPPOE to get activated, it has to have the correct udeb in the packages, which by default isn't the case... is that correct ?
<cjwatson> right, I think it's in ppp-udeb or else pppoe-something
<cjwatson> I don't believe we ship that by default
<cjwatson> it would really be a lot easier if I could see the log, though. :)
<yannickm1> hmm... i see... i was doing the customization of a server CD btw ... Yup i'm trying to setup one in a VM... i have the logs but on my laptop at the office
<yannickm1> so in terms of signatures, is there any checks done during installation ?
<cjwatson> yes, if Release.gpg is present
<cjwatson> the installer is supposed to be set up to allow unauthenticated repositories on the CD as well, though
<yannickm1> hmm... i see
<yannickm1> ok well then i'll give it a try unauthenticated... thanks for the help !!!
<davmor2> xivulon: You around?
<CIA-50> ubiquity: cjwatson * r2869 method-filesystem-split/ (4 files in 3 dirs): merge from trunk
<CIA-50> ubiquity: cjwatson * r2865 ubiquity/debian/ (ubiquity.install-lpia changelog rules): Add some more grub pieces on lpia.
<cjwatson> persia: ^- should fix your problems I think
<davmor2> xivulon: when you get this jockey is a bit temperamental in the wubi install.
<persia> cjwatson: Does that include the addition of the ntfsprogs dependency that was also in my local testing branch but not yet committed?
<cjwatson> no, I wasn't sure if you wanted that
<cjwatson> if you do, I'll add it
<cjwatson> I think that needs a partman-partitioning change though
<persia> I do.  I've been preparing a branch adding the grub and ntfsprogs dependencies in debian/rules, and adding ubiquity.install-lpia.
<persia> I'll go look there then.  I got a new laptop last week, that was lpia, and came with Vista installed, so I suspect it's probably best to support ntfs.
<cjwatson> I'll just do it now
<persia> OK.  Thank you.
 * persia goes back to the interrupted investigation of user-setup to force preseeding of blank passwords
<CIA-50> partman-partitioning: cjwatson * r687 ubuntu/debian/ (changelog rules): Add NTFS dependencies on lpia.
<CIA-50> ubiquity: cjwatson * r2866 ubiquity/debian/ (changelog rules): Add ntfsprogs dependency on lpia.
<lool> cjwatson: Is there a chance ubiquity be reuploaded before beta?
<cjwatson> I hadn't been planning on it. Is it a showstopper?
<cjwatson> (and if so this discussion should be on #-release)
<lool> cjwatson: I think this bug prevents successful installation, but I don't think it should delay beta for the other images as our installation was always borken
<lool> And we use dailies for testing anyway
<persia> lool: Our preseed is broken anyway, so just pushing ubiquity doesn't solve everything.
<lool> persia: What's the issue with the preseed?  is this related to the changes to the seen flags?
<persia> lool: It's related to user-setup wanting passwords not to be zero characters in length.
<lool> persia: But can't StevenK easily fix our preseed?
<persia> lool: Yes, but then we have different behaviour than desired, because the user has a password.
<lool> Sorry, you're saying our preseed is broken; can't StevenK fix it in whatever way is needed?
<persia> No, I'm saying that d-i doesn't support the preseed as written.
<persia> The preseed is correct, it's just not supported.
<cjwatson> right
<cjwatson> user-setup refuses this, which is correct for interactive use
<cjwatson> but it should be made possible to preseed something else
<persia> RIght, so I'm fiddling with user-setup to have a new passwd/user-no-password boolean which defaults to false to allow this.
<cjwatson> could you call it passwd/allow-empty-password please to match the error template better?
<lool> Ok, I understand the issue better
<persia> Sure.  No problem.
<lool> Thanks
<persia> Thanks for the suggestion.
<kirkland> cjwatson: hey, strange happening with raid installs, perhaps you have an idea...
<kirkland> cjwatson: when doing the partitioning in the installer, it seems imperative that the underlying RAID partitions are *not* marked "bootable"
<kirkland> cjwatson: as long as that's the case, the grub-install against /dev/md0 works fine, and the installed system behaves as expected
<cjwatson> imperative at what stage?
<kirkland> cjwatson: however, if the underlying RAID partition is marked "bootable", the installation succeeds, but the system is not bootable
<kirkland> cjwatson: yielding a segfault in kvm
<kirkland> cjwatson: i have not yet tried real hardware
<cjwatson> oh, right
<cjwatson> that ought to be relatively simple to account for
<kirkland> cjwatson: this sounds familiar to you?
<kirkland> cjwatson: or, at least, you can put me on the trail?
<cjwatson> well, the bootable thing may be what the BIOS chains to
<cjwatson> or at least tries to chain to
<kirkland> cjwatson: you reckon i should look to solve this in kvm, or in the installer?
<cjwatson> both :-)
<kirkland> :-)
<cjwatson> a kvm segfault is clearly a kvm bug
<kirkland> cjwatson: yeah
<cjwatson> but we perhaps shouldn't mark RAID partitions as bootable either
<cjwatson> I don't know, was /boot in the RAID partition?
<kirkland> cjwatson: right, i was thinking about just manually overriding that in the installer bits
<cjwatson> also, did you mark any of the partitions as bootable at the partitioner stage?
<kirkland> cjwatson: yeah, everything on one big raid partition
<cjwatson> or did you just leave all of them unbootable?
<cjwatson> you see, there's an awkward conflict here ...
<cjwatson> there are some BIOSes that will refuse to boot, period, if there's no bootable partition at all
<kirkland> cjwatson: if i mark nothing "bootable", everything works fine
<cjwatson> on your BIOS
<kirkland> ah, erg
<cjwatson> seb128 ran into this in the 5.04 cycle
<cjwatson> so I know it happens in practice :)
<kirkland> k
<cjwatson> so if you only had one big RAID partition, then I think that needs to be fixed in kvm
<kirkland> cjwatson: okay, so work items are ...
<kirkland> cjwatson: 1) teach KVM to deal with raid partitions marked "bootable"
<xivulon> davmor2: hi
<kirkland> cjwatson: actually, i think if I could solve (1), that might take care of the problem
<davmor2> xivulon: hello
<davmor2> xivulon: wubi is missing the progress bar on uninstall in vista it lags on xp but is there
<xivulon> sorry could you rephrase?
<davmor2> xivulon: in vista when you remove the wubi install the progress bar doesn't move.  In Xp it lags behind the text but is there
<xivulon> is the progressbar at zero or at an intermediate level?
<davmor2> zero
<davmor2> never shows at all the text is correct at the bottom of the uninstaller window but no bar
<xivulon> I think I know the reason, could you open a bug report if you haven't done so already?
<xivulon> in any case the uninstaller should be very quick
<davmor2> donehttps://bugs.edge.launchpad.net/wubi/+bug/276389
<davmor2> xivulon: it is but it is noticeable too
<cjwatson> kirkland: yes, I think that's it
<kirkland> cjwatson: okay, i'll see what i can do with that
<xivulon> I have assigned it to me
<xivulon> davmor2 what was the other issue about jockey?
<xivulon> I must admit I haven't used jockey so far
<davmor2> xivulon: Jockey wouldn't download the nvidia drivers.  However after shutting jockey down and trying again it worked fine and it's happen a couple of times
<xivulon> is jockey launched by ubiquity or is it run post-install?
<cjwatson> jockey is not launched by ubiquity
<davmor2> post-install
<xivulon> could that be a race condition in networking?
<xivulon> not sure why wubi would interfere in such case though
<davmor2> could be on both times it's happened I've run other tests and and come back to it and it's been fine
<xivulon> then it is probably a jockey issue
<davmor2> I don't think it's anything major
<xivulon> by the way cjwatson and evand, we did some preliminary testing with mythbuntu in wubi together with superm1 and seems ok
<davmor2> xivulon: ah but it doesn't happen when I use it on a normal install
<evand> fantastic
<cjwatson> good to hear
<davmor2> nice one
<xivulon> there is no need though to change the wubi build that ships on the other ubuntu ISOs
<evand> xivulon: how is wubi in 8.10?  Any critical issues?
<evand> ah, great
<xivulon> evand, not that I am aware of.
<superm1> xivulon, i've got another daily that will at least have that .disk/info file fixed.  I'll be experimenting with the preseed tonight to see if I trigger any unexpected behavior
<xivulon> so the plan for mythbuntu might be to ship a new version of wubi only in mythbuntu ISO and in the stand-alone on ubuntu.com
<xivulon> thus minimizing delta
<xivulon> in any case the version on CD will only allow the CD distro, so it makes no difference
<xivulon> evand, it wouldn't hurt though if you also tested wubi/umenu :)
<evand> xivulon: can you elaborate on what you mean by "CD distro"?
<evand> xivulon: as soon as I get a working VMWare on 2.6.27 :)
<xivulon> in return I will test usb installer (have to buy a new usb card though)
<xivulon> evand I mean each CD is specific for a particular distro, if you run Wubi off the Xubuntu CD you can only select "Xubuntu" in the desktop environment selector of wubi
<evand> Yeah, I should pick up another one and test two at a time (unless someone knows how to create fake devices for HAL)
<xivulon> hence there is no need to add mythbuntu in there
<evand> well, there is in the sense that we want to keep all the code centralized, but I see the point you're making.
<xivulon> On my side is a small change, mostly implies a different isolist.ini and one or two preseed templates
<evand> indeed
<xivulon> we'll decide though once we have more testing
<xivulon> the bugs I have open are: 204133 where I committed the change in wubi but I am waiting for cking to have an opinion
<xivulon> basically last time myself and davmor2 tested syncio support for ntfs the performance hit was considerable
<xivulon> so I am not sure it is a good idea to turn it on
<evand> ah, indeed
<xivulon> see the last few comments on the bug
<xivulon> Also there is 243105, because of it, we are still extracting the full ISO now, even though that sometimes fails
<xivulon> ah one thing I wanted to ask, cjwatson, if you remembered in 8.04 we moved keyboard/locale settings from preseed to boot arguments
<xivulon> I assume there is no need to change it back
<cjwatson> not to my knowledge ...
<xivulon> I will leave it like that then unless someone complains
<xivulon> davmor2: on jockey can you try to get some logs?
<CIA-50> partman-partitioning: cjwatson * r688 ubuntu/debian/changelog: releasing version 59ubuntu7
<CIA-50> ubiquity: cjwatson * r2867 ubiquity/ (d-i/manifest debian/changelog):
<CIA-50> ubiquity: Automatic update of included source packages: partman-partitioning
<CIA-50> ubiquity: 59ubuntu7.
<jg> ping superm1
<superm1> hi jg
<jg> hi.
<superm1> i believe you are the same jg that I just saw an email from?
<jg> yup.
<jg> playing with one of your fine products this afternoon.
<jg> currently in the middle of an install of a current intrepid build.
<CIA-50> ubiquity: cjwatson * r2862 intrepid-beta/ (8 files in 4 dirs): merge r2864-2867 from trunk
<jg> superm1: should I expect any surprises here in a few minutes as it completes?
<superm1> jg, well depends on if your XT has AMD graphics
<jg> yup.
<jg> it does.
<superm1> jg, then just dont try to do fglrx with it.  the open driver should be pretty functional, but i saw some quirky crashy behavior a few times
<jg> x1250, IIRC.
<jg> ok; wasn't intending to; I'll be building my X bits from source when I get the machine stabilized anway.
<jg> what do I do to get the wireless running?
<jg> superm1: I tried on Fedora F10, and was defeated....
<superm1> jg, did you get one with broadcom or with intel?
<superm1> i'd guess broadcom based on that response
<jg> yup.
<jg> superm1: broadcom.
<superm1> jg, should work out of the box with 'wl' on intrepid then
<jg> wasn't obvious from the web site which was which....
<jg> cool.
<jg> I saw you did some patches around ID'ing the N-Trig.
<jg> What's the state there?
<jg> superm1: I note it seems to be able to imitate a wacom...
<superm1> jg, yeah that top level usb device is id'ed, but the hid stuff is still not going to come up any nicer
<superm1> jg, if you look at the FDI file for it imiating wacom, you'll see it as HID XXXX:YYYY or something similar
<jg> superm1: I'm negotiating with N-Trig's president to try to get docs; keep fingers crossed....
<superm1> jg, perhaps we should move this to a pm though or another channel this isn't exactly "installer" related
<jg> ok.
<jg> sorry.
<CIA-50> ubiquity: cjwatson * r2863 intrepid-beta/debian/changelog: releasing version 1.10.2
<CIA-50> ubiquity: cjwatson * r2868 ubiquity/debian/changelog: merge from intrepid-beta branch
<cr3> in busybox, is there a way to list the network interfaces considering ifconfig is not there?
<cr3> nevermind, I think I'm supposed to use the ip command
<persia> cjwatson: After looking at bzr history, thank you *very* much for that particular dance.  While none of it seemed critical, it's all extremely helpful.
<cjwatson> cr3: correct
<cjwatson> persia: no problem, hope the history was educational
<persia> cjwatson: The ubiquity changes were byte-for-byte the same as my local copy (started from post auto-login addition).  partman-partitioning looks straightforward.  The revision pulls back and forth were rather interesting, and demonstrate power of VCS source management.
<cjwatson> persia: byte-for-byte> heh
<persia> cjwatson: Aside from me forgetting it, I think there's only one way to do it: add the string ":lpia" in two places, and copy one of the other ubiquity.install-${arch} packages that used grub :)
<persia> I just need to add more steps in my fix-things process: because of the way that the installer packages get included, etc. it seems easiest to just fix live, recover patches, and apply them, but this isn't sufficient.  If we ever decide to have a special geode arch, I'm now well prepared.
<cr3> during the installation sequence, should the network interfaces be detected before ethdetect is called in /var/lib/dpkg/info/ethdetect.postinst?
<persia> cr3: live session or alternate?
<cr3> persia: alternate
<cr3> persia: network install even, but I don't think it will matter much at that point
<persia> cr3: Well, yes and no and maybe.  that postinst runs in the chroot, so the chroot is probably not natively network aware until that point.  The host either has network or not compeltely independently of what happens in the chroot.
<cr3> persia: does it really run in the chroot? that /var script is in the initrd.gz cpioball
<persia> Ah, then we're talking about two different /var/lib/dpkg/info/ethdetect.postinsts :)
<cr3> persia: good point, there is probably another ethdetect udeb installed afterwards. out of curiosity, I'll have a quick gander
<cr3> I just checked and e1000 gets loaded before ethdetect is called, weird
<persia> cr3: No, the udeb install postinst is probably the right place for network discovery during the boot into the minimal system (but I'm guessing, rather than knowing that).
<persia> I was talking about /target/var/lib/... which is compeltely different.
<persia> In the unexpected case where networking isn't enabled in the host, it's conceivably possible that enabling it on the target may also enable it on the host.
<cr3> persia: right, but maybe there's some other hw-detect script being called beforehand which also happens to catch maybe some network controllers such as the e1000
<persia> cr3: Quite possibly.  Unfortunately, I don't know much about that environment: most of my experience is either with debootstrap off some cobbled-together boot (maybe an old scrap disk, or whatever), or using the LiveCD (or analogues thereto).
<persia> (there is a gap of several years between the two when I nursed a potato -> hardy instance, and only upgraded by component, rather than replacing the system)
<cjwatson> cr3: in practice, drivers often get loaded by udev out-of-sync with d-i
<cjwatson> nowadays, ethdetect is basically there to finish up just in case
<cjwatson> and cope with things that don't get loaded by udev for whatever reason
<cjwatson> persia: no such thing as ethdetect in the target
<cr3> cjwatson: thanks so much, so I will be temporarily modify ethdetect to workaround the e1000 problem. this is not ideal but I can't find a better solution
<cjwatson> what workaround exactly?
<cr3> cjwatson: brace yourself....
<cr3> modprobe e1000; lspci -d "8086:1096" -nm | cut -d' ' -f 3,4,6,7 | tr -d '"' | head -n 1 > /sys/bus/pci/drivers/e1000/new_id
<cjwatson> oh, right, ok
<cjwatson> I thought you meant something to suppress e1000, in which case ethdetect wouldn't have been sufficient
<cr3> the installation seems to be running smoothly now but I'll probably have to supplement something else for after reboot, not a problem
<xivulon> hmm evand been testing wubi, last version shows page "who are you"
<xivulon> is there anything new that needs preseeding?
<cjwatson> xivulon: yeah, user-setup/encrypted-private-passphrase
<cjwatson> probably just preseed that to false
<cjwatson> err, sorry, I meant user-setup/encrypted-private
<cjwatson> though actually I'm not sure why that would cause ubiquity --automatic to stop
<cjwatson> a debug log would help
<xivulon> there is also an autologin box I can see in the ui, is that relevant
<xivulon> am running now without debugging mode
<cjwatson> no, I don't think so - the underlying d-i code doesn't ask that
<cjwatson> so it shouldn't cause the installer to halt
<xivulon> ok re-running the installer
<xivulon> will take 5-10 mins
<CIA-50> cdrom-detect: cjwatson * r427 ubuntu/debian/ (4 files): merge from lp:~tormodvolden/cdrom-detect/usb-drive-install
<CIA-50> cdrom-detect: cjwatson * r428 ubuntu/debian/changelog: fix changelog typo
<kirkland> cjwatson: interestingly, if i set the bootable flag on the 0xfd raid partitions post installation in a running system, i do not reproduce the kvm segfault
<xivulon> bizarre, I rerun the installer and wasn't asked anything, I wonder what could I have typed into username/password to trigger that
<xivulon> anyway time to sleep, have a good night
#ubuntu-installer 2008-10-01
<kirkland> cjwatson: okay, even more odd...  i cannot reproduce the kvm segfault with bootable partitions anymore
<acoc> is anyone familiar with a "No alternate CD for i386!" error in the publish-daily script in cdimage
<TheMuso> acoc: What do you mean exactly?
<acoc> sorry I forgot I was running on battery, then it died
<acoc> TheMuso: I've been playing around with the cdimage to compile an xubuntu daily cd by hand and ended up with that error on the last step of the build-image-set script
<TheMuso> acoc: There is likely a component/package that you haven't installed that you need. What version of Ubuntu are you running the cdimage code on?
<acoc> ozos is the distro, it's basically xubuntu-hardy with the e17 wm
<acoc> that's what I'm working on improving
<TheMuso> acoc: Ok, have you made sure britney is running properly?
<acoc> it runs without errors
 * TheMuso doesn't know the bits intimately, but I've set up cdimage before, so have a good idea of whats needed.
<TheMuso> Ok.
 * TheMuso tries to think of what he needed to install to get it to work.
<TheMuso> acoc: I believe there are a lot of deps that debian-cd needs. Have a look in its readme file. There are a lot of perl bits needed.
<acoc> ok, I have the apt debian-cd installed, but I had run cjwatson's checkout
<acoc> it ran successfully
<TheMuso> acoc: Without seeing a log, I am not sure what the problem is then.
<acoc> TheMuso, I understand, the truth is that I used debmirror for most of the syncing because I wanted to avoid the code I didn't need
<acoc> so basically I avoided the whole ananosync part and did each step by hand
<acoc> I may ultimately have to go the whole route of the complete cron.daily, but I just wanted to ask if anyone was familiar with this error
<TheMuso> acoc: You probably don't have the indices files, as well as the installer-* bits within the dists structure.
<TheMuso> They are needed.
<acoc> I rsynced those as well
<TheMuso> Well I'm out of ideas at the moment.
<acoc> when I googled the No alternate CD for i386! error it came up with a chat archive that cjwatson had fixed, but he didn't give details, so maybe I'll ask him tomorrow
<acoc> but I do appriciate it TheMuso, I probably should have asked you questions earlier, it would have saved a lot of time
<acoc> sounds like you did something very similarly
<TheMuso> acoc: Yeah, but I managed to get it running.
<TheMuso> Mind you, that was a while ago, and certainly not the latest code.
<acoc> haha, yeah well maybe by intrepid I'll get it running
<acoc> mind you I'm doing the hardy
<acoc> alright, I guess I'm going to hit the hay, thanks for the effort TheMuso
<TheMuso> np
<davmor2> cjwatson: I've put a note into https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/271554 to tie it into https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/271512 but I've not duped them as they're still slightly different
<evand> cjwatson: If you have any available time for reviews, I would very much appreciate a code review on bug 276656
<cjwatson> acoc: don't use debian-cd from the Ubuntu archive. It won't even start to work.
<cjwatson> acoc: use the one referred to from configs/devel in my cdimage code.
<cjwatson> "No alternate CD for i386" just means that the build failed somewhere above.
<davmor2> cjwatson: I don't know if you can help but I'm getting a weird wubi error when shutting down with the latest Kubuntu cd.  /et/init.d/rc: 372: /etc/rc6.d/S60umountroot: i/o error and same thing for reboot on S90.  Which log would the error show up in?
<cjwatson> I don't know, sorry
<cjwatson> evand: is there any reason not to just exclude *any* mounted device, not just /cdrom or /hd-media?
<davmor2> cjwatson: ui for the new partitioner works fine for Vista
<windswept> hello all
<windswept> I am looking to find out if there is an easy place that I can download a prebuilt casper directory for xubuntu
<windswept> I guess I am going to have to fix the documenation since things are not clear at ALL.
<cjwatson> "prebuilt casper directory"?
<cjwatson> I'm not sure what you mean
<windswept> sorry directory casper that is on the live install cd's of the desktop
<cjwatson> it's constructed by the livecd-rootfs package
<windswept> I downloaded the entire xubuntu-alternative because
<cjwatson> the alternate install CD doesn't use casper at all
<cjwatson> it's in the desktop CD
<windswept> I don't yet have a live 8.04.01 installation.
<cjwatson> perhaps it would help if you explained what you were trying to achieve
<cjwatson> a casper directory is not much use on its own
<windswept> I ony found out about that after downloading the alternative. why. because if you want to netboot aka I want to install from my local network. the installation documentation says use alternative.
<windswept> now that it is on my local network I want to install off of it. but alternative setup does not.
<cjwatson> which installation documentation? URL please
<cjwatson> the image you want for netboot installation is usually neither the alternate nor the desktop CD, but http://archive.ubuntu.com/ubuntu/dists/hardy/main/installer-i386/current/images/netboot/mini.iso
<cjwatson> err, sorry
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/hardy-updates/main/installer-i386/current/images/netboot/mini.iso
<cjwatson> that's assuming that you have a local Ubuntu archive mirror (otherwise it'll download it from archive.ubuntu.com)
<windswept> oye no wonder I am having hell. it is not easily explained anywhere.
<cjwatson> https://help.ubuntu.com/8.04/installation-guide/i386/
<cjwatson> just need to be careful to get the images from /dists/hardy-updates/ rather than /dists/hardy/
<windswept> sorry, I have done many network installations using fedora, redhat,centos, solaris but anytime I want to do a similar deal for debian it is just annoying.
<windswept> I do not want to have a mirror just download a live cd or two,  copy the files in to /tftpboot  setup my nfs and configure my dhcpd server
<windswept> seems like I am asking WAY to much.
<windswept> the docs imply that the netboot is on only the alternative, and it is but that is not the version that you want to use if you want to do the above.
<cjwatson> if you can be a little less aggressive, I might be able to help you.
<cjwatson> but I'm not interested in offering help for free in order to get shouted at, I'm afraid
<windswept> sorry about this.  it just can seem to be very frustrating.
<windswept> and I was looking to just get a url and be done.  thanks for the last one.
<cjwatson> the process of netbooting a live CD is much less stable and flexible than the process of netbooting the text-mode installer
<cjwatson> if you really want to do it, https://wiki.ubuntu.com/LiveCDNetboot is the best set of directions I know of
<cjwatson> but I also know there are a number of bugs in that procedure :-/
<cjwatson> so at the moment I have trouble recommending it in good conscience
<windswept> yes,  I would not recommend this for a classroom of 10 students and 3 hours.
<windswept> I have done the above with various versions of fedora/centos
<cjwatson> there are various bugs related to this, e.g. #182940 and #268005
<cjwatson> they have a good deal of information but unfortunately not much in the way of conclusion
<windswept> thank you
<cjwatson> most of the people doing large-scale network installations do the local-mirror approach; I agree that people doing relatively small-scale work lose out a bit
<evand> cjwatson: good call, it just hadn't occurred to me.
<evand> I'll rewrite it as such
<cjwatson> thanks
<cjwatson> any progress on those two partitioning bar bugs that keep getting duped?
<evand> On them, but no progress yet.  I'll give them a larger chuck on time today.
<evand> of*
<davmor2> evand: m-a works kinda with vista
<evand> yeah, I was able to get in some vista fixes submitted by Mandriva this cycle
<davmor2> evand: can I have a word with you about bug https://bugs.edge.launchpad.net/wubi/+bug/276693
<evand> davmor2: No idea on that one.  I'd suggest talking to xivoulon.
<davmor2> evand: okay ta I'm hoping that Riddell will be able to confirm it
<evand> davmor2: I imagine it's going to end up being not-Kubuntu specific.
<davmor2> evand: doesn't effect any of the other distros and has only been introduced with 30.1 so I don't know what the cause is :(
<evand> It doesn't happen in Ubuntu?
<cjwatson> xivulon mailed me this morning about a umountfs fix he needed
<cjwatson> could easily be connected with that
<cjwatson> seems that we lost all the umountfs work from hardy in the intrepid sysvinit merge :-/
<evand> Ah, yikes.
<davmor2> evand: Vista m-a doesn't import backdrop or mail (but I need to double check on the mail, I'm pretty sure it's setup)
<evand> davmor2: ok, please file bugs for those
<davmor2> No Probs
<davmor2> mail might work apparently sp1 for vista installed a new version of microsoft mail that wiped the settings (nice)
<evand> I haven't given any consideration to Microsoft Mail, so I'd be quite surprised if that works.
<davmor2> evand: Wow how the hell do microsoft manage to screw up a mail client.... I can't connect to either gmail or my own server :(
<davmor2> doesn't seem to like ssl
<evand> No idea, but last time I used Outlook I wanted to inflict massive amounts of pain on myself to take my mind off the outlook experience
<davmor2> yes but at least it connects yes sucks to hell and back but connects
<evand> heh
<davmor2> Outlook on xp connects to both servers with no complaints Vista with MM fails to connect to either mail server
<evand> odd
<davmor2> gmail doesn't list MM as a client it supports
<davmor2> this is Imap by the way :)
<CIA-50> installation-guide: cjwatson * r421 installation-guide/ (build/entities/urls.ent debian/changelog):
<CIA-50> installation-guide: * Backport from intrepid:
<CIA-50> installation-guide:  - Drop bogus "/ubuntu" from URL to example-preseed on help.ubuntu.com.
<CIA-50> installation-guide: cjwatson * r422 hardy-proposed/ (debian/changelog en/appendix/preseed.xml):
<CIA-50> installation-guide: Update how to suppress the removal of existing LVM data using
<CIA-50> installation-guide: preseeding (Frans Pop).
<CIA-50> installation-guide: cjwatson * r423 hardy-proposed/ (debian/changelog en/appendix/chroot-install.xml):
<CIA-50> installation-guide: Don't recommend passing http://archive.ubuntu.com/ubuntu to
<CIA-50> installation-guide: debootstrap; it can figure out a good default for itself, and that URL
<CIA-50> installation-guide: is wrong for ports architectures (see
<CIA-50> installation-guide: https://answers.launchpad.net/ubuntu/+source/debian-installer/+question/38180).
<CIA-50> installation-guide: cjwatson * r424 hardy-proposed/ (debian/changelog en/install-methods/downloading-files.xml):
<CIA-50> installation-guide: Point to /dists/hardy-updates/ rather than /dists/hardy/ for downloading
<CIA-50> installation-guide: installation files, so that people reading this don't get bitten by LP
<CIA-50> installation-guide: #94398/#234486.
<davmor2> cjwatson: https://bugs.launchpad.net/bugs/271376 also effects the main install but the usplash and artwork for edubuntu are in so it should display correct?
<cjwatson> davmor2: I'm nearly certain it's a different bug
<davmor2> cjwatson: with netboot all the others have the correct usplash present
<cjwatson> I really must ask you to ask the Edubuntu people
<cjwatson> netboot> OK, feel free to reopen it and assign it to some package that isn't the installer then
<cjwatson> err, or usplash
<cjwatson> it seems very likely that it's an edubuntu-artwork bug
<davmor2> cjwatson: okay no probs
<cjwatson> sorry, just can't deal with all the derivatives :)
<davmor2> cjwatson: modified :)
<acoc> cjwatson: hi I realized I had skipped the check-installable script and saw I had a version mismatch in python warning
<acoc> cjwatson: is this critical
<cjwatson> acoc: what is the exact text of the warning?
<acoc> /home/acoc/projects/ubuntu_devel/work/britney/update_out/check_out.py:4: RuntimeWarning: Python C API version mismatch for module britney: This Python has API version 1013, module britney has version 1012.
<acoc> and then   import britney;
<acoc> cjwatson: I posted up everything I've done at http://pastebin.com/m1ea230
<cjwatson> you probably need to 'make clean; make' in britney/update_out/
<cjwatson> does it run without other errors?
<cjwatson> hmm, you already built britney from source
<cjwatson> what version of python are you using?
<cjwatson> (python -V)
<acoc> Python 2.5.2
<acoc> both Python 2.4 and 2.5 are installed with dev from apt
<cjwatson> ah, right; 'bzr pull' in the britney directory, that should sort it out
<cjwatson> we were using python2.4 to build the extension but just running with whatever /usr/bin/python happened to be
<acoc> ok thanks, I'll let you know how it goes
<cjwatson> that's probably not why publication failed in your log though
<acoc> ok, I'm re-running everything just to make sure
<cjwatson> looks like you don't have IMAGE_TYPE set when you're calling build-image-set (or similar)
<acoc> that's possible, I mostly just replaced it with daily whenever I thought it was required
<acoc> ok it just passed check-installable
<acoc> I'll re-run exporting IMAGE_TYPE as daily
<acoc> hmm no luck, but it was better because it kept everything in scratch in the daily folder instead of me having to move it over manually
<CIA-50> ubiquity: cjwatson * r2864 intrepid-beta/ (debian/changelog scripts/install.py):
<CIA-50> ubiquity: Back out DVD performance fixes for beta; they cause files from some
<CIA-50> ubiquity: packages that actually are installed (language packs) to be missing from
<CIA-50> ubiquity: the installed system. Works around LP #276657, but this needs a better
<CIA-50> ubiquity: fix for Ubuntu 8.10.
<soren> cjwatson: When you have a minute, could you take a peek at http://bazaar.launchpad.net/~soren/tasksel/limit-section/revision/1377 ? We want to offer the tasksel interface on first boot in a virtual machine, but only the server ones.
<soren> cjwatson: I'm about to call it a day, so no rush.
<cjwatson> soren: ok, queued up, won't be for a few hours though
<soren> cjwatson: "sometime today" sounds fantastic. Thanks.
<CIA-50> ubiquity: cjwatson * r2865 intrepid-beta/ (configure configure.ac): bump to 1.10.3
<CIA-50> ubiquity: cjwatson * r2866 intrepid-beta/debian/changelog: releasing version 1.10.3
<CIA-50> ubiquity: cjwatson * r2869 trunk/ (configure configure.ac debian/changelog scripts/install.py): merge from intrepid-beta branch
<acoc> cjwatson, whenever you have a min, I was looking at publish-daily and some formatting problems made me miss it at first but at line 92 why is the TYPE variable set defaulted to alternative for new dists
<acoc> cjwatson: changing it to desktop gets me past the no alternative cd error, but then I get in trouble with keys
<acoc> would anyone mind explaining what should be in the $CDIMAGE_ROOT/secret/dot-gnupg directory (keeping in mind I don't know much about public keys)
<cjwatson> acoc: because that's what "daily" means for us; "daily-live" is the desktop CDs
<cjwatson> acoc: dot-gnupg contains secring.gpg and pubring.gpg for whatever key is signing your built CD images
<acoc> cjwatson: could you explain what an alternative install is
<cjwatson> it's a copy of ~/.gnupg - the reason I put it in a separate directory for our builds is that we had several users wanting to run CD builds and gpg doesn't like using a .gnupg from another user's home directory!
<cjwatson> acoc: the alternate install CD uses the text mode installer
<cjwatson> the one that builds up the target system from scratch using .debs, as opposed to copying a prebuilt live filesystem onto the target disk
<evand> hooray, the segmented bar issues are fixed, I just need to properly commit it to ubiquity.intrepid-beta
<cjwatson> evand: trunk, I think ...
<cjwatson> I don't think Steve will let us have that for beta now
<acoc> cjwatson: ok, so if I wanted a livecd install, I should be doing a daily-live IMAGE_TYPE
<evand> ah, I thought we were using the beta branch until post-release, no?
<cjwatson> acoc: right
<evand> That is, things that wont make it into 8.10 go into trunk, things that will go into beta and get merged into trunk.
<cjwatson> acoc: then, you'll need to arrange for the live filesystem to be built somewhere else with livecd-rootfs or similar
<cjwatson> cdimage doesn't do that bit itself - the reason for that is that cdimage is designed to be able to build CD images for multiple CPU architectures, and you can only build the live filesystem on a machine of the same architecture
<cjwatson> so I had to split those two bits apart
<cjwatson> evand: things that won't make it into 8.10 beta go into trunk
<evand> cjwatson: noted
<cjwatson> I was just branching quickly for beta because there were things in trunk that were fine for 8.10 but not as late uploads for the beta
<evand> ah, ok
<cjwatson> acoc: however, note that "no alternate CD for i386!" means "something broke" not "I didn't think I was building an alternate CD"
<cjwatson> if you see what I mean
<cjwatson> acoc: you might consider not bothering to sign your images; it makes a difference for us because seventy zillion people are downloading them but you might not care
<acoc> cjwatson: how do you not sign them
<cjwatson> acoc: if you just don't bother creating files under dot-gnupg then you'll get a warning message about it but you can ignore that
<cjwatson> "No keys found; not signing images."
<cjwatson> i.e. do nothing
<acoc> ok, I think I understand
<acoc> do you have any other suggestions/things I should try
<cjwatson> well, that depends on what you're stuck on ;-)
<acoc> well I guess since I have everything built for a daily, I'd like to try to get that working
<acoc> that reminds me of something
<cjwatson> ok, so what's the current error?
<acoc> let me find it
<acoc> ok finally found it
<acoc> my /www/full/xubuntu/hardy/daily/current/ has hardy-desktop-i386.iso
<cjwatson> soren: argh, change to translated help text, that'll be complicated
<acoc> is that right or should it be alternative
<cjwatson> acoc: alternate, not alternative
<cjwatson> daily should be alternate
<cjwatson> I suspect an inconsistently set IMAGE_TYPE
<acoc> what should IMAGE_TYPE be
<cjwatson> oh, and you aren't using cron.daily are you?
<acoc> no I'm not using cron.daily
<cjwatson> you probably should
<cjwatson> it wraps all this up for you
<cjwatson> actually, the thing you're *really* missing is CDIMAGE_INSTALL=1
<cjwatson> but cron.daily sets that
<acoc> ok, I was trying to avoid syncing everything, so I was using debmirror to only get the hardy i386 stuff
<cjwatson> that's easily solved, CDIMAGE_NOSYNC=1 cron.daily
<acoc> oh I see
<acoc> ok thanks I do that then
<cjwatson> soren: I'm half-tempted to just not document it in --help
<cjwatson> soren: at least until upstream take it
<cjwatson> soren: I'd maybe go for if ($options{section}) { @tasks = grep { $options{section} eq $_->{section} } @tasks; } just because it's easier to read
<cjwatson> (properly indented obviously)
<cjwatson> soren: I think the general approach is probably OK though
<CIA-50> ubiquity: evand * r2870 ubiquity/ (3 files in 3 dirs):
<CIA-50> ubiquity: * Accurately place and calculate the total size of the new partitions
<CIA-50> ubiquity:  (LP: #271512).
<CIA-50> ubiquity: * Calculate the allocation for the labels after adding a new segment in
<CIA-50> ubiquity:  segmented_bar (LP: #271554).
<cjwatson> yay
#ubuntu-installer 2008-10-02
<bdmurray> evand: quitting a only ubiquity install takes me to a full desktop is that expected?
<evand> bdmurray: if you quit the installer, you mean?
<evand> err yeah, that's what you said :)
<evand> yes, it's expected
<bdmurray> evand: 'kay, thanks
<soren> cjwatson: lp:~soren/tasksel/limit-section You like?
<CIA-50> tasksel: cjwatson * r1377 ubuntu/ (debian/changelog tasksel.pl): merge from lp:~soren/tasksel/limit-section
<cjwatson> soren: WFM
<cjwatson> thanks
<soren> Great. Thank *you*.
<CIA-50> oem-config: cjwatson * r534 oem-config/ (debian/changelog oem-config-firstboot): Log messages from update-rc.d rather than throwing them away.
<davmor2> xivulon: wubi still has no backdrops for Xubuntu or Kubuntu during install was that something that couldn't be fixed?
<xivulon> avmor2 haven't tested kubuntu yet
<davmor2> np's
<xivulon> more importantly I had a chat with cjwatson yesterday, and he submitted a patch reverting the umountfs changes
<xivulon> would be good if you could test those changes as I will be able to do so only tonight
<davmor2> cool so it should unmount cleanly now?
<davmor2> cjwatson: did that fix get into the re-re-re-rolled cds from yesterday?
<cjwatson> no
<xivulon> don't think they are in the ISO yet, you will probably have to patch /etc/init.d/umountfs manually
<cjwatson> I just sent them to xivulon by mail
<xivulon> cjwatson a paste would do I guess
<cjwatson> http://paste.ubuntu.com/53150/
<xivulon> davmor2 all yours :)
<davmor2> right so in time for rc then or the day after beta is released :)
<xivulon> I did test similar changes (my version offline) and it worked well, should be almost identical to the above but did not have a chance to compare/test yet
<cjwatson> day after beta if it works for somebody
<davmor2> I has kubuntu wubi installing now what do I need to do?
<davmor2> s/has/have
<cjwatson> after it's installed, apply that patch to /etc/init.d/umountfs, then reboot and see if it's clean
<davmor2> cjwatson: Right never applied a patch is it a magic command line thing or just swapping the file out?
<cjwatson> wget -q -O- http://paste.ubuntu.com/53153/plain/ | sudo patch /etc/init.d/umountfs
<davmor2> it's installed now just booting up
<cjwatson> you'll need to install the patch package first
<xivulon> cjwatson no chance to have the patch in for beta?
<davmor2> cjwatson: thanks :)
<cjwatson> no
<cjwatson> xivulon: ^-
<xivulon> :(
<davmor2> xivulon: we will not re-test again ;)
<xivulon> cjwatson I guess it will be okish if people will get it via updates
<cjwatson> xivulon: there was no possible way you could have expected it to get into beta when it wasn't tested until the day of beta
<davmor2> patched rebooting now
<davmor2> bingo
<davmor2> cjwatson: It' worked,  do you want it rebooting again just to be sure?
<cjwatson> once is fine
<cjwatson> I'll upload that, thanks
<davmor2> okay
<xivulon> thanks a lot
<cjwatson> that doesn't mean it's in for beta - the beta CDs have already been rolled
<davmor2> :D
<xivulon> cjwatson I assume that if it is in the archive people will get it on first update, correct?
<cjwatson> xivulon: once it's built, yes
<xivulon> this should minimize tickets
 * davmor2 scurries off to write down patch info 
<xivulon> Can we edit the release note caveats and suggest people to update?
<cjwatson> feel free
<cjwatson> I assume they're on the wiki, haven't looked yet
<cjwatson> but really, people running the beta will be upgrading anyway
<xivulon> yep should be fine
<xivulon> thanks a lot
<xivulon> superm1 will test the preseed tonight
<xivulon> davmor2 can you remind me of the backdrop bug #?
<davmor2> https://bugs.launchpad.net/wubi/+bug/208818
<davmor2> only now both xubuntu and Kubuntu have no backdrop whereas Ubuntu does
<xivulon> davmor2 not sure that one is in wubi domain
<xivulon> davmor2, when you tested ntfs syncio, was that booting from a normal intrepid installation
<davmor2> yes I did an install along side of xp and tested
<davmor2> I think let me double check
<davmor2> xivulon: no I did it on both wubi and an install if memory serves but definitely an intrepid install I used it to check m-a
<davmor2> xivulon: Why?
<xivulon> cking asked
<xivulon> I guess he was checking whether it was a loop issue rather than an ntfs one
<davmor2> cjwatson: why is the default hostname ubuntu on alternate even on a kubuntu and Xubuntu installs?  is it just a individual package that is used across all the desktops, he guesses wildly hoping to be right.
<cjwatson> the latter, and because it's not especially clear to me that it's worth changing
<cjwatson> bug 120087
<cjwatson> I'd do it if the Kubuntu or Xubuntu developers (respectively) came to me and asked for it
<davmor2> Okay cool I just wondered I never normally look at it
<davmor2> just hit enter
<cjwatson> I don't want to do it unilaterally
<CIA-50> debian-installer: cjwatson * r968 ubuntu/ (14 files in 3 dirs): Move ports architectures to 2.6.25-2 kernels.
<StevenK> cjwatson: Does that mean I can NBS out 2.6.25-1?
<cjwatson> no
<cjwatson> please wait until (a) after beta (b) linux-ports-meta is done
<StevenK> Certainly
<StevenK> cjwatson: d-i is one of the steps, and is usually done after -meta, so I thought I'd ask
<cjwatson> StevenK: note that I have not uploaded the above change
<cjwatson> I was just sticking it into bzr while I remembered
<StevenK> Mmmmm, point
 * cjwatson goes argh at bug 274219
<cjwatson> I think I want a stretch to do nothing else but fix all our LVM and RAID bugs
<CIA-50> partman-base: cjwatson * r108 ubuntu/ (choose_partition/partition_tree/do_option debian/changelog):
<CIA-50> partman-base: Disable backup while displaying device/partition locked errors; it makes
<CIA-50> partman-base: no sense and it can cause us to exit without closing the FIFO to
<CIA-50> partman-base: parted_server (LP: #274219).
<mathiaz> Hi - when defining a partition recipe, what's the order of the limits ? min_size max_size priority ?
<cjwatson> see doc/devel/partman-auto-recipe.txt in debian-installer
<cjwatson> <limits>::=<minimal size>_<priority>_<maximal size>_<parted fs>
<mathiaz> cjwatson: right - however the preseed example in https://help.ubuntu.com/8.04/installation-guide/amd64/preseed-contents.html seems to be different
<mathiaz> cjwatson: in the section about partitioning raid
<mathiaz> cjwatson: 1000 5000 4000 raid
<mathiaz> cjwatson: hm - it seems that only this line is odd - all the other examples in expert_recipe makes sense.
<cjwatson> priority isn't necessarily <max
<cjwatson> it's a bit weird
<CIA-50> debian-installer: cjwatson * r969 ubuntu/ (3 files in 2 dirs): Move mainline architectures to 2.6.27-5 kernels.
<kirkland> cjwatson: TheMuso: http://people.ubuntu.com/~kirkland/Screenshot-1.png
<kirkland> cjwatson: looks like a bug against partman-base
<cjwatson> kirkland: heh, looks like it
<kirkland> cjwatson: i'm filing a bug now, will try to fix it
<kirkland> cjwatson: another question...
<kirkland> cjwatson: i tested an upgrade from hardy to intrepid, as I was curious what the default BOOT_DEGRADED value would be set to
<kirkland> cjwatson: it was set to "true" which was unintended and unexpected
<kirkland> cjwatson: I'm looking at mdadm.config and mdadm.postinst, where I have
<kirkland>     db_get mdadm/boot_degraded
<kirkland>     BOOT_DEGRADED="${RET:-false}"
<kirkland> and i'd expect it to default to "false" if unset, but that's not happening, empirically
<cjwatson> I think you need a DEBCONF_DEBUG=developer trace
<cjwatson> trying to zen it will be a pain
<kirkland> cjwatson: okay, so i'd like to simplify my test case
<kirkland> cjwatson: intrepid install that doesn't actually have raid or mdadm installed
<kirkland> cjwatson: so no BOOT_DEGRADED value
<kirkland> cjwatson: and then install mdadm
<kirkland> cjwatson: that should run the same exec path, right?
<kirkland> cjwatson: rather than doing a full hardy -> intrepid upgrade, correct?
<cjwatson> ... maybe
<cjwatson> that's not obviously the same as a hardy system with mdadm installed
<cjwatson> it depends on the maintainer scripts
<cjwatson> you could take an intrepid install that doesn't have mdadm installed, install hardy's mdadm (if that works), and then upgrade
<kirkland> cjwatson: okay, that sounds better
<persia> There seems to be a piece I'm missing in lpia grub support, and I'm having trouble tracking it down.  Specifically, I'm failing with a DeconfError that grub-installer/bootdev doesn't exist.  While this isn't in the debconf DB, From my reading of the code, I'd expect to receive a return value of '', rather than an error.  Could someone point me at what I may be missing?
<cjwatson> if it's not in the DB at all then you'll get an error
<cjwatson> though I'm surprised it's not in the db
<persia> I was a little surprised as well, given that ubiquity appears to have an extra hammer to force the setting: that's why I assumed I was supposed to skip it with a ''.
 * persia looks at ubiquity again, harder
<cjwatson> check /var/lib/dpkg/info/ubiquity.templates
<cjwatson> and also try 'echo GET grub-installer/bootdev | sudo debconf-communicate' from a terminal on the live CD
<persia> before or after a failed install?
<cjwatson> either
<kirkland> cjwatson: what do the :sl1: and :sl3: mean in the templates file?
<kirkland> cjwatson: i notice that other text with embedded %s have :sl1: and seem to be working properly...  while partman/text/raid_device has :sl3:
<cjwatson> they're translation categorisations from Debian
<cjwatson> they have no significance to the installer itself
<cjwatson> %s is handled manually with printf, not by anything in (c)debconf
<kirkland> red herring then
<kirkland> cjwatson: the odd thing is that the only way I can actually get a literal "RAID%s" printed to screen in the installer shell is to:
<kirkland> printf "RAID%%s"
<kirkland> or
<kirkland> printf "RAID%s" %s
<cjwatson> well, or anything that doesn't go through printf
<kirkland> cjwatson: the relevant code is extracted here: http://pastebin.ubuntu.com/53228/
<cjwatson> I can't even find that text
<cjwatson> ah, right
<kirkland> cjwatson: partman-base
<cjwatson> kirkland: the 0 there is suspicious too
<cjwatson> provisionally, bearing in mind I'm on the phone, I suspect buggered debconf protocol interaction
<kirkland> cjwatson: is there a possibility that this code is duplicated elsewhere?
<kirkland> cjwatson: partman-* is a bit of a maze to me, still
<cjwatson> I don't *think* so
<cjwatson> at the risk of being a broken record, DEBCONF_DEBUG=developer is your friend
<persia> cjwatson: Thanks.  That was it precisely.
<kirkland> cjwatson: :-)  sure
<cjwatson> persia: hmm. what was it? :)
<persia> cjwatson: Missing templates.
<cjwatson> do you know why?
<persia> No, but at least I know have a path I can follow.
<persia> s/know/now/
<cjwatson> ok
<kirkland> cjwatson: the DEBCONF_DEBUG=developer goes on the kernel boot line?
<cjwatson> yes
<kirkland> cjwatson: http://pastebin.com/f2265a5d0  <- partman debconf debugged
<kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
<kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
<kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
<kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
<kirkland> that's from syslog
<cjwatson> can I have the full syslog? context would be good
<cjwatson> debconf debugging doesn't show up in /var/log/partman
<kirkland> cjwatson: fwiw, Hardy does *not* suffer the same string formatting problem
<kirkland> cjwatson: i debdiff hardy vs. intrepid partman-base, and didn't find a bloody glove
<kirkland> cjwatson: i suppose I can check debconf hardy v intrepid, if you think that might be more productive
<cjwatson> I don't think it's remotely likely that it's a debconf fault
<cjwatson> could I have the full syslog?
<kirkland> cjwatson: all attached to that bug
<kirkland> cjwatson: https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/277153
<persia> And now I even know why, and how to fix it.  While I'm at it, is there a reason partman-efi is built for amd64, except in ubiquity?
 * persia looks for amd64 bugs against partman-efi, with the intention of turning it on
<CarlFK> cjwatson: [   38.557201]  sdb: unknown partition table
<CarlFK> different box/everything from that other box
<CarlFK> should I open a new bug?
<CarlFK> http://dev.personnelware.com/carl/a/dhcp91/sfdisk.txt
<CarlFK> http://dev.personnelware.com/carl/a/dhcp91/fdisk.txt
<CarlFK> maybe the boot=?
<cjwatson> persia: no, that just sounds like a bug
<cjwatson> CarlFK: that means that the kernel doesn't understand the partition table
<cjwatson> (not the installer)
<persia> cjwatson: Thanks for the confirmation.  I'll definitely fix it then, rather than continuing my search for previous bugs that would have disabled it.
<cjwatson> CarlFK: and fdisk doesn't seem to think it's all that great either
 * persia files a summary bug for tracking, and prepares a branch for pushing
<CarlFK> cjwatson: it is similar to https://bugs.launchpad.net/ubuntu/+bug/273379 - wondering if I should append logs to it or open a new bug
<cjwatson> CarlFK: I have no way to know
<cjwatson> CarlFK: if in doubt, a new bug explicitly referencing the old bug is better
<CarlFK> will do.
<cjwatson> and saying that you don't know whether it's the same bug, to fend off triagers
<cjwatson> it looks different, at first glance
<CarlFK> another issue: same box, after picking the partitions on hdc:  [File system has an incompatible feature enabled.  Compatible features are has_journal, dir_index, filetype, sparse_super and large_file.  Use tune2fs or debugfs to remove features.]
<CarlFK> logs: http://dev.personnelware.com/carl/temp/Oct02/b/dhcp91/
<CarlFK> pretty sure this isn't my fault..
<cjwatson> that's a well-known bug :-(
<CarlFK> need more logs ?
<cjwatson> hmm, or is it, I can't find a bug where it should be (partman-basicfilesystems)
<cjwatson> oh, of course, bug 59620
<cjwatson> CarlFK: could you attach that syslog and partman to bug 59620? this is a new manifestation (ext2 with some unusual feature enabled)
<CarlFK> will do.
<cjwatson> CarlFK: 'tune2fs -l /dev/sdc1' would be good too
<CarlFK> cjwatson: should the first be against parted or linux?
<cjwatson> CarlFK: linux
<cjwatson> kirkland: note how most of the matches for "RAID%s" are closely followed by something where the substitution *did* work
<cjwatson> kirkland: it's only right at the end where it went nuts
<kirkland> cjwatson: well, i was more puzzled by the fact that that's the only screen that *doesn't* work
<kirkland> cjwatson: lots and lot of RAID.*%s.* all over that interface that printed fine
<cjwatson> kirkland: I diagnose debconf protocol getting out of step, perhaps due to random stuff echoed to stdout somewhere
<kirkland> cjwatson: i know, because I've clicked through those screens _thousands_ of times this release cycle :-P
<cjwatson> so the debconf protocol is command on stdin, response on stdout
<cjwatson> if something else witters on stdout, it can get confused
<kirkland> cjwatson: that seems, um, fragile?
<cjwatson> it works :-)
<kirkland> :-)
<cjwatson> it's considered a bug, yes
<cjwatson> but it's very very difficult to fix
<cjwatson> it's been considered a bug almost as long as debconf has existed
<cjwatson> for the most part, various workarounds take care of it - for example the standard debconf shell confmodule redirects stdout to stderr so that you can't hit it by accident that way
<kirkland> yeah
<cjwatson> but that's not altogether foolproof and accidents do happen
<kirkland> cjwatson: so, i verified that we don't have this problem in hardy
<kirkland> hardy.1 anyway
<cjwatson> oh
<cjwatson> I have a guess
<cjwatson> let me verify it
<cjwatson> hmm, bad guess, never mind :)
<cjwatson> (I thought debconf-set-selections might write to stdout)
<kirkland> :-(
<cjwatson> it does seem to be right there where it screws up though
<cjwatson> oh, of course
<cjwatson> we pipe input to debconf-set-selections, which uses debconf ...
<cjwatson> go to jail, go directly to jail, do not pass go, do not collect two hundred pounds
<evand> haha
<cjwatson> I think it might be easier to just duplicate debconf-set-selections' functionality
<cjwatson> which in this case is just writing to the logfile
<cjwatson> kirkland: try http://paste.ubuntu.com/53261/
<kirkland> cjwatson: which source are you looking at?
<kirkland> cjwatson: ah
<cjwatson> mdadm
<cjwatson> sorry, that was my fault, I should have known better
<kirkland> cjwatson: okay, i'll give that a shot
<CarlFK> can I create a .tar with the BusyBox tar ?
<CarlFK> pretty sure I have been told no before
<CarlFK> Usage: tar -[zxtvO] - assuming those are the same as http://www.busybox.net/downloads/BusyBox.html there is no -c
<cjwatson> debian/config/config.udeb:# CONFIG_FEATURE_TAR_CREATE is not set
<persia> Fix for bug 277225 about udebs for grub-installer/lpia and partman-efi/lpia+amd64 is in lp:~persia/ubiquity/lpia-grub
<CarlFK> cjwatson: thanks.  I'll note that in my script for the next time I try to figure this out :)
<cjwatson> persia: huh, I thought I added grub-installer/lpia already
<cjwatson> oh, d-i/lists. bah
<persia> cjwatson: Yeah.  I was sure the debian/ubiquity.install-lpia was the last bit, and then found this one.
<cjwatson> thanks, I wrote that so should've known :)
<persia> Anything else you can think of?
<cjwatson> well, I didn't think of this
<cjwatson> that *should* be it
<persia> OK.  Let's hope this is good then :)
<CIA-50> ubiquity: cjwatson * r2871 ubiquity/ (d-i/lists/lpia d-i/lists/amd64 debian/changelog): merge from lp:~persia/ubiquity/lpia-grub
<cjwatson> the lp: short form is the finishing touch on this workflow for me
<cjwatson> for some reason it makes a big difference
<persia> Not having to type the entire string?
<cjwatson> I guess so, though that seems trivial
<persia> No, it's time consuming, and easy to get wrong.  Short is good.
<cjwatson> maybe it's just that I get to use the keyboard rather than having to copy-and-paste with the mouse, and that feels better
<persia> I must say, that for all I'm still unhappy with the few universe or multiverse packages that use bzr packaging that I occasionally encounter, working with bzr packaging on the installer has been incredibly pleasant.
<persia> I find myself actually almost looking forward to proper source-package branches, although I still need to sort out performance issues.
<cjwatson> I wonder what the difference is
<cjwatson> I think it makes a big difference to be working on the same branches a lot; the worst slownesses are branching from scratch and pushing up new branches
<cjwatson> (and the latter should be fixed once they get stacked branches working)
<persia> It's also my special combination of high bandwidth and high latency.
<persia> I can download 1GB over a well-served torrent in about 5 minutes.
<persia> Anything where I can get a big TCP window, I can download fast, but the slow-start algorithm means I need a lot of bits to fill the pipe.
<persia> bzr does lots of little transactions, which is particularly bad for me, especially at 150-200ms from LP.
<CarlFK> cjwatson:  some how this: #3 primary   29.7 GB   K ntfs       /windowsÂ Â Â Â (good)
<CarlFK> caused Oct  2 19:36:25 kernel: [ 3492.564405] ReiserFS: sdc3: warning: unknown mount option "umask=007"
<CarlFK> stuff: http://dev.personnelware.com/carl/temp/Oct02/c/dhcp91/
<kirkland> cjwatson: \o/  that fixed it
<kirkland> cjwatson: also, i've regression tested the default-BOOT_DEGRADED-to-false-on-upgrade change I made,
<kirkland> cjwatson: both look good
<cjwatson> cool
<cjwatson> CarlFK: sorry, it's after 9pm and I have a headache, I'm not sure I can look at this now
<CarlFK> no prob - uploadng stuff to lp
<cjwatson> something asynchronous would be better, yes :)
<CarlFK> package: installer?
<cjwatson> no such package
<cjwatson> debian-installer would be fine
<CarlFK> thaks
<xivulon> cjwatson can confirm that the umountfs patch works well
<xivulon> evand, cjwatson, could you please have a quick look at cking comment on https://bugs.edge.launchpad.net/wubi/+bug/204133/comments/59 and let me know what you think is the best course of action about activating syncio in wubi?
<xivulon> my 2c is that we should turn it on, since cking is concerned about data loss (although I did not have any such report in 8.04)
<xivulon> the wubi delta is minimal, I only add it to the ROOTFLAGS in menu.lst if fs==ntfs, not sure about the actual impact in terms of performance
<xivulon> in case we can remove lupin-sysctl hacks
<xivulon> superm1, I see you have metalinks up :)
<xivulon> on the dailys though the URL contains the builddate, which makes things tricky
<xivulon> would it be possible to have a stable URL (redirect or server side symlink)?
<xivulon> I would also need a link for what will be the final metalink URL
<superm1> xivulon, can you let tgm4883 know?
<superm1> he's the one who handled all the metalink stuff
<xivulon> sure
<superm1> xivulon, so about the no networking thing - it happens in the "install only" mode on the disk too (no live env)
<superm1> is that the same case as the regular ubuntu too?  Is network manager wrecking havock?
<xivulon> superm1 can you remind me about the networking issue?
<superm1> xivulon, network manager doesnt' start up on it's own
<superm1> when you go into only-ubiquity or automatic-ubiquity
<superm1> i would guess this affects Ubuntu too, but I can't tell for sure since I can't switch VTs in only-ubiquity in a VM
<xivulon> would not think that is an issue for wubi, except for updates
<superm1> well it is for the mythbuntu installed wubi
<superm1> because that means that you cant connect to your backend - which is critical for it to work
<xivulon> ah of course
<superm1> that's the exact issue you were seeing
<superm1> i bet it's because the init script for ubiquity is set to start before network manager's and they don't run in parallel
<superm1> bingo.  S29ubiquity and S30NetworkManager
<superm1> evand, was there a good reason why you chose 29 for ubiquity's init script then?
<xivulon> I am building a new version to try
<xivulon> there is no i386 iso for today http://www.mythbuntu.org/devel/dailies/081001/
<xivulon> or yesterday
<xivulon> I'll use the 30th
<xivulon> ps rsync on the server would be welcome :)
<superm1> xivulon, http://uk.cdimages.mythbuntu.org/mythbuntu-8.10-beta-desktop-i386.iso
<superm1> that's a later one
<superm1> what should be syncing across servers right now
<superm1> the daily build for i386 broke yesterday i believe
<xivulon> downloading
<persia> superm1: Which VM solution are you using?
<superm1> persia, virtualbox
<superm1> when i hit ctrl-alt-fX, it switches my VT of the host system even if the keyboard is grabbed
<persia> Ah.  I have a solution for switching VTs in KVM, but not for vbox.
<superm1> vmware grabs it fully too
<superm1> but my box with vmware workstation is out of commission for now
<xivulon> superm1 in vb it is Alt Gr + Fn
<cjwatson> xivulon: umountfs> cool, thanks. apparently I uploaded it and forgot about it anyway :)
<xivulon> cjwatson, well I tested the original patch, not the actual package
<cjwatson> sure, but that's ok
<cjwatson> xivulon: syncio> seems like it makes sense to activate it
<xivulon> agreed
<cjwatson> superm1: 29> it needs to go before gdm
<xivulon> I am building a new version with mythbuntu too right now
<cjwatson> superm1: NetworkManager probably needs to move a bit earlier in order to give us space for ubiquity without having to change the name :-)
<xivulon> cjwatson in case we need to deactivate lupin-sysctl
<cjwatson> superm1: uk.cdimages is a pretty confusing name
<superm1> cjwatson, that's the main mirror that our images start at before they get spit out
<cjwatson> is that United Kingdom or Ukraine? :-) (neither one has the ISO-3166 code UK)
<superm1> cjwatson, and then we have a redirect URL that people use
<cjwatson> the UK's code is GB
<superm1> cjwatson, ah.  it should be united kingdom.
<cjwatson> compare gb.archive.ubuntu.com
<superm1> cjwatson, but our redirect URL detects where you're coming from and if you are united kingdom and the bandwidth is within limits for the month offer that mirror
<superm1> ah i always assumed uk.archive.ubuntu.com was united kingdom too
<cjwatson> only due to wildcard DNS
<cjwatson> and the fact that the master is in the UK
<superm1> ah
<superm1> well Daviey, see the above ^.  You want to get that DNS corrected?
<superm1> cjwatson, is the order of resolving init scripts case sensitive?  So if NetworkManager was brought down to 29, would it resolve before or after ubiquity?
<cjwatson> it's C locale, in which N < u
<cjwatson> though n < u anyway so case doesn't matter
<xivulon> cjwatson have pushed rev111 for lupin disabling lupin-sysctl
<cjwatson> ok, what happens to people upgrading from wubi beta installs if they upgrade to that version of lupin?
<cjwatson> xivulon: I also changed it to 0.22 not 0.21ubuntu1 - might want to use dch -iU rather than dch -i for when you're changing packages maintained natively in Ubuntu
<xivulon> made note
<xivulon> cjwatson good point, as it is now I guess upgrading will be left with lupin-sysctl
<cjwatson> that's probably as desired, since they won't get menu.lst changed ...
<xivulon> correct
<cjwatson> I was worried about lupin getting upgraded but menu.lst not having syncio yet
<cjwatson> xivulon: could you add an explicit note about that to the changelog in case others don't follow the reasoning?
<cjwatson> possibly as a comment in debian/rules too
<xivulon> sure
<Daviey> superm1, cjwatson: UK domain noted, will sort it.
<cjwatson> thanks
<kirkland> cjwatson: kees was about to sponsor my mdadm changes, fyi
<kirkland> cjwatson: if you wanted to check them first
<cjwatson> if it's basically just including the patch I suggested, I don't think I need to
<kirkland> cjwatson: it does that, plus 2 more things....
<kirkland> cjwatson: it solves the default-to-false on hardy->intrepid upgrades
<cjwatson> ok, sure, I can have a look
<kirkland> cjwatson: which is also a 2-liner
<kirkland> cjwatson: and mathiaz really wanted to change the debconf text
<kirkland> http://people.ubuntu.com/~kirkland/mdadm/mdadm.debdiff
<kirkland> cjwatson: apologies, that debdiff contains all the po BS
<cjwatson> kirkland: I think that makes sense, except that your changelog comment for the root_on_raid fix is incorrect
 * kirkland looks
<cjwatson> kirkland: the problem isn't writing to stdout (that was just a hypothesis I had), it's that we're causing debconf-set-selections to read from a pipe from echo rather than from the debconf input fd
<cjwatson> so perhaps something like "do not pipe input to debconf-set-selections as that breaks debconf; write directly to the preseed log file instead" would be more accurate
<kirkland> cjwatson: my bad
<cjwatson> I'm all for pedagogical changelog entries :)
<cjwatson> anyway, otherwise fine
<xivulon> cjwatson rev 113
<xivulon> superm1 can you please remind how to get the password for the backend
<cjwatson> xivulon: ok, you didn't need the second changelog line :-) users will see it all at once
<superm1> xivulon, as indicated in the gui, /etc/mythtv/mysql.txt :)
<cjwatson> I removed it
<cjwatson> xivulon: uploaded, thanks
<xivulon> superm1, yep nm really needs to be started up upfront
<superm1> xivulon, i filed a bug against network manager on it
<superm1> xivulon, too bad, that's the only gating factor from wubi working with mythbuntu with that preseed that i see
<xivulon> do you want also a backend role?
<xivulon> or maybe leave the question unanswered?
<superm1> xivulon, well that's a complicated question.  you can't preseed to setup multiple drives can you - both a loop mount and a real file system?
<xivulon> by the way mounted with syncio started copying files 1m ago'
<xivulon> is it? hmm I have ROOTFLAGS=syncio, but cannot see any trace in /proc/mounts...
<xivulon> not sure how to check that
<superm1> xivulon, because you'd have to mount the recordings partition to be on your NTFS filesystem and the install on the loop mount.  can you do that with a preseed right now?
<xivulon> well the ntfs partition is going to be mounted as /host, so you can preseed /host/yourpath
<superm1> is it always mounted as /host?
<xivulon> yes
<superm1> if we preseed a path that doesnt yet exist, like C:/ubuntu/mythtv, would that get made by the installer?
#ubuntu-installer 2008-10-03
<superm1> or /host/ubuntu/mythtv I suppose
<xivulon> yep, although you cannot be completely sure about /host/ubuntu but will do for 8.10
<cjwatson> ./autopartition-loop:285:               mkdir -p "/host${path%/*}"
<cjwatson> so yes
<superm1> xivulon, why wouldn't /host/ubuntu do it?  isn't that where the loop image gets stored?
<xivulon> finished copying now
<xivulon> so seems syncio is in because it seems a bit slower, not 10x worse though as predicted by cking
<xivulon> superm1 yes, but in the future it might be /host/mythbuntu
<superm1> xivulon, well what happens for kubuntu,xubuntu etc?
<superm1> do they get /host/xubuntu?
<xivulon> no all in /host/ubuntu in 8.10, I meant things might change in future versions, but we will have time to do it properly then
<mathiaz> hm - in a partman recipe, if I set a priority that is bigger than the size of the disk is, the install fails (with an unable to create partition error)
<mathiaz> is that expected ? although the minimum size fits the disk
<mathiaz> http://paste.ubuntu.com/53318/ <- that's the partman expert recipe - however the drives are 1GB in size.
<mathiaz> the last partition is not created.
<cjwatson> mathiaz: I'm totally not going there after midnight, but you can ask me again tomorrow ...
<mathiaz> cjwatson: sure
<superm1> xivulon, ah well that would just be modfiying the preseed anyway if that behavior changed
<superm1> xivulon, i'll do some experiments with a preseed for master backend frontend then too and see how things work out
<xivulon> cool
<xivulon> have a build ready
<xivulon> test went well
<xivulon> other than nm
<xivulon> I think that the main advantage of allowing a backend is sparing me the trouble to answer "What is a backend? Why can't I press forward?" :P
<xivulon> evand wubi rev 509 is up
<xivulon> superm1 http://wubi-installer.org/devel/minefield/Wubi-8.10-rev509.exe
<xivulon> evand wubi 509 is required if we have lupin 111+
<xivulon> hi, didn't notice that the kde3.5 -kde4 dicothomy has been abolished
<xivulon> will need a new revision for wubi
<davmor2> xivulon: Yes kubuntu is just kde 4.1.2 now
<xivulon> Ok uploaded wubi rev 5.10 (evand all yours), Davmor, please test http://wubi-installer.org/devel/minefield/Wubi-8.10-rev510.exe
<xivulon> davmor2 ^
<xivulon> that also contains the uninstaller progressbar fix by the way
<xivulon> have to go now
<cjwatson> http://cdimage.ubuntu.com/netboot/ - some folks here might be interested in that set of landing pages
<cjwatson> they're just links to the right bits of the archive
<davmor2> cjwatson: sweet
<persia> cjwatson: Should those be scheduled to test cases, etc. as with other images?
<davmor2> persia: netboot is
<persia> Ah.  I suppose I was confused by two images vs. 7 images, but it all becomes clear now.
<davmor2> http://iso.qa.ubuntu.com/qatracker/build/netboot/all
<persia> Yeah :)
<cjwatson> I'll update for older releases as well when I have a chance
<davmor2> I've just done all the vista updates and am resaving the partitions.  15.85 GB for vista and nearly 2 gig for system partition so nearly 20gig total
<xivulon> evand can we have a new iso with new wubi (510) and lupin (115) and sysvinit (2.86.ds1-59ubuntu9)?
<davmor2> xivulon: is this to remedy the loop issue
<cjwatson> xivulon: let's wait for the cron jobs to be turned back on
<xivulon> ok
<cjwatson> Steve hasn't done that so it wouldn't surprise me if he's intentionally letting cdimage cope with the beta load for a while
<xivulon> davmor2: what loop issue do you refer to exactly?
<davmor2> xivulon: https://bugs.edge.launchpad.net/wubi/+bug/204133 this one
<xivulon> ah yes
<superm1> xivulon, okay i downloaded it.  i'm going to do a build today with my own patched network manager on our hotfixes PPA and make sure that network manager bug is resolved
<xivulon> cjwatson, cking was mentioning that it might be better to use dm-loop as opposed to loop for performance reasons, do you think it would be feasible?
<cjwatson> I don't know anything about it - it doesn't *sound* difficult
<xivulon> would not think so, I have asked cking to join us though
<xivulon> hi cking, was discussing with cjwatson about your suggestion to use dm-loop as opposed to losetup
<cking_> Ok. its a case of modprobing dm-loop and then I using dmlosetup (this is a symlink to the dmsetup binary)
<cjwatson> does that amount to some arguments to dmsetup?
<cjwatson> (otherwise we could change dmsetup-udeb to add that symlink I suppose)
<cjwatson> is dmlosetup equivalent to mount in that setup?
<cking_> cjwatson: The rune I used was:
<cking_> dmlosetup loop1 /mnt/ntfs/wubi_ext3.img
<cking_> and then mount -o loop /dev/mapper/loop1 /some/mount/point
<cking_> that's it
<cking_> ..of course the path names need to be changed to match the Wubi config
<xivulon> if I want to list the loop devices, can I still use losetup?
<cking_> xivulon: not sure. never tried that
<xivulon> would be good to know as some script that does not actually mount the devices, might be using losetup to check the setup
<xivulon> or detach them
<cking_> dmlosetup -f is reporting that this it's not currently implemented .. and AFAIK losetup won't help us for this case
<cking_> xivulon: mm.. I don't know how to list the dmloop devices.
<xivulon> does $(dmlosetup /dev/loop$loopn) spit out the same string as losetup?
<cking_> xivulon: ..just a mo.
<cking_> xivulon: /dev/mapper is populated with loopN when loopN is created. You can therefore tell which dm-loop devices are being used
<cking_> /dev/mapper/control should always exist for 0-N dm-loop devices
<superm1> xivulon, can you pop in #ubuntu-mythtv-dev again
<superm1> tgm has some more questions
<xivulon> the files that need to be modifed should only be autopartition-loop and initramfs/scripts/local
<xivulon> init.d scripts should be fine, have to check grub/grub-installer but should be ok
<xivulon> superm1 sure
<xivulon>  #ubuntu-mythtv-dev again
<xivulon>  #ubuntu-mythtv-dev again
<xivulon> ops paste gone wrong
<cjwatson> dmlosetup doesn't exist in Ubuntu
<cking_> cjwatson: it's a symlink to dmsetup
<cjwatson> not here it ain't
<cjwatson> command-not-found reckons it's not in intrepid
<cking_> cjwatson: one needs to symlink it by (hand at the moment) - which needs to be fixed
<cjwatson> ah
<cjwatson> somebody should file a bug on devmapper about that
<cking_> cjwatson: yep... I seemed to overlook it back in July when I started faffing around with dm-loop
<cking_> cjwatson: I will create a bug report in a short while for this
#ubuntu-installer 2008-10-04
<nxvl> evand: around?
<CIA-50> partman-ext3: cjwatson * r741 ubuntu/ (check.d/nomountpoint_ext3 debian/changelog): merge from lp:~nvalcarcel/partman-ext3/ubuntu
<CIA-50> partman-ext3: cjwatson * r742 ubuntu/check.d/nomountpoint_ext3: don't need the quotes
<CIA-50> partman-ext3: cjwatson * r743 ubuntu/debian/changelog: releasing version 52ubuntu3
<CIA-50> partman-jfs: cjwatson * r726 ubuntu/ (check.d/nomountpoint_jfs debian/changelog):
<CIA-50> partman-jfs: * check.d/nomountpoint_jfs:
<CIA-50> partman-jfs:  - Make $RET look for a boolean value (LP: #256459).
<CIA-50> partman-jfs: cjwatson * r727 ubuntu/debian/changelog: releasing version 26ubuntu2
<CIA-50> partman-reiserfs: cjwatson * r806 ubuntu/ (check.d/nomountpoint_reiserfs debian/changelog):
<CIA-50> partman-reiserfs: * check.d/nomountpoint_ext3:
<CIA-50> partman-reiserfs:  - Make $RET look for a boolean value (thanks, Nicolas ValcÃ¡rcel;
<CIA-50> partman-reiserfs:  LP: #256459).
<CIA-50> partman-reiserfs: cjwatson * r807 ubuntu/debian/changelog: releasing version 41ubuntu3
<CIA-50> partman-reiserfs: cjwatson * r808 ubuntu/debian/changelog: retroactively fix changelog
<CIA-50> partman-xfs: cjwatson * r760 ubuntu/ (check.d/nomountpoint_xfs debian/changelog):
<CIA-50> partman-xfs: * check.d/nomountpoint_xfs:
<CIA-50> partman-xfs:  - Make $RET look for a boolean value (thanks, Nicolas ValcÃ¡rcel;
<CIA-50> partman-xfs:  LP: #256459).
<CIA-50> partman-xfs: cjwatson * r761 ubuntu/debian/changelog: releasing version 41ubuntu2
<nxvl> cjwatson: partman-basicfilesystems is fine, it doesn't present this problem
<nxvl> is the only one who was fixed
<lfaraone> Hey, can someone please look at bug 277302? It's a potential security issue, and there's a bzr branch with a fix attached.
<lfaraone> (triaged, medium) "NetworkManager is starting up "after" ubiquity in only-ubiquity mode": https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/277302
<cjwatson> nxvl: right, I checked partman-basicfilesystems already
<cjwatson> lfaraone: it's not a security issue; you'd need asac for that, who isn't here
<cjwatson> lfaraone: (I do agree it's a bug)
<cjwatson> lfaraone: it's targeted for 8.10 so there shouldn't be a danger of it getting lost or anything
<cjwatson> lfaraone: but probably need to wait for a weekday
<cjwatson> lfaraone: FWIW I was slightly surprised at your statement on #ubuntu-devel that Ubuntu is upstream for NetworkManager; that isn't true last I checked :-)
<cjwatson> oh, unless you meant ubiquity
<nxvl> cjwatson: it was the first i checked until i found partman-ext3 which had the issue
<nxvl> cjwatson: btw, i've found that there is not much information on how to test/develop/find stuff for starting in the installer team
<cjwatson> nxvl: have you tried http://wiki.ubuntu.com/InstallerDevelopment?
<cjwatson> that's my main advertised jumping-off point; if it needs more that's the page that should be extended
<nxvl> cjwatson: yes
<nxvl> cjwatson: i was thinking more in a "how d-i works"
<nxvl> since some people can think that it's one whole program, which is not
<nxvl> and yesterday i had a lot of problems finding were that bug was
<nxvl> since i didn't know were to look for the secuence of modules
<nxvl> am i clear?
<cjwatson> nxvl: there's a paper by Frans Pop linked from that wiki page
<cjwatson> I think it's called "Debian-Installer internals"
<cjwatson> nxvl: doc/devel/menu-item-numbers.txt in the debian-installer source package is also a useful rough guide, although only lists the top level
<nxvl> ok, i will check that
<nxvl> thank you
<cjwatson> indeed, InstallerDevelopment mentions / links to both of those :-)
<cjwatson> links to both now
<nxvl> i will take that in account for jaunty
<nxvl> :D
<lfaraone> cjwatson: yeah, I ment ubiquity
#ubuntu-installer 2008-10-05
<CarlFK> what do I run to regen grub/menu.lst?
<CarlFK> so that this will take effect # defoptions=vga=6
<CarlFK> looks like /sbin/update-grub.
#ubuntu-installer 2009-09-28
<ogra> cjwatson, i committed an ABI bump (and a minor size change for the imx netboot image) to d-i to match the recent versions of imx/dove
<ogra> apparently the kernels were uploaded shortly after your d-i upload yesterday :/
<cjwatson> ogra: ok, could you please do the CIA things in http://wiki.ubuntu.com/Installer/Development so that this channel gets notified automatically
<ogra> cjwatson, do you monitor the platform.$RELEASE seeds with it too ?
<cjwatson> no
<ogra> (i usually bump the ABI there as well)
<ogra> ok
<cjwatson> ogra: please go ahead and debcommit -r and upload that
<ogra> will do
<ogra> gar
 * ogra wonders why CIA didnt pick up the commits now
<cjwatson> ogra: well, there's no change in the branch on LP. Perhaps you need to push
<cjwatson> ogra: (or, indeed, use 'bzr bind' so that you don't need to remember)
<ogra> i did push, weird
<CIA-33> debian-installer: ogra * r1179 debian-installer/debian/changelog: fix mail address
<ogra> ha
<CIA-33> ubiquity: cjwatson * r3484 ubiquity/ (d-i/get-sources debian/changelog):
<CIA-33> ubiquity: d-i/get-sources: Clear Dir::Etc::sourceparts, so that any local
<CIA-33> ubiquity: /etc/apt/sources.list.d/ isn't used.
<CIA-33> casper: cjwatson * r696 trunk/ (debian/changelog scripts/casper-bottom/25configure_init):
<CIA-33> casper: Upstart moved /etc/event.d/ to /etc/init/; adjust shell provision on VTs
<CIA-33> casper: to match (LP: #434769).
<CIA-33> casper: cjwatson * r697 trunk/debian/changelog: releasing version 1.195
<ogra> cjwatson, i was just grepping for "serial" in d-i and a bunch of dmesg files showed up, is there any specific reason to carry it in the code branch ?
<ogra> (just curious)
<cjwatson> not worth the delta of removing them, IMO
<cjwatson> and they aren't mine to remove upstream
<ogra> well, i was just wondering why they are there at all :)
<cjwatson> they're in doc/ ...
<cjwatson> I assume that whoever did the port (tbm?) found them useful
<cjwatson> we do occasionally grep dmesg for things in d-i, so it's not entirely unreasonable
<ogra> ah, i didnt know info/ is doc
<cjwatson> look at the start of the path ... :)
<ogra> lol, ok
<ogra> i'm definately blind
<ogra> hmm. the d-i code to autodetect serial consoles is definately more elegant than my current casper script
<CIA-33> ubiquity: cjwatson * r3485 ubiquity/debian/ (3 files):
<CIA-33> ubiquity: Cope with the possibility that /etc/init.d/usplash may not exist, in
<CIA-33> ubiquity: anticipation of usplash switching to Upstart jobs.
<CIA-33> ubiquity: cjwatson * r3486 ubiquity/debian/changelog: releasing version 1.99.25
<CIA-33> debian-installer: ogra * r1180 debian-installer/debian/control: add redboot bootloader binaries to build-dep for the SD card netinst image for babbage boards
<CIA-33> debian-installer: lool * r1181 ubuntu/debian/changelog: add changelog entry
<cjwatson> ogra: could you 'bzr nick ubuntu' in that branch so that CIA's messages look right, please?
<ogra> oh, i thought the nick is whats in front of the colon
 * ogra fixes
<cjwatson> bzr cia-project is what's in front of the colon
<ogra> yeah, understood that now
<CIA-33> debian-installer: lool * r1182 ubuntu/ (3 files in 3 dirs):
<CIA-33> debian-installer: * pkg-lists updates for armel+dove:
<CIA-33> debian-installer:  - Add netboot/armel/dove.cfg to pull the input modules for USB keyboards.
<CIA-33> debian-installer:  - Add cdrom/armel/dove.cfg to pull input modules as well as fat modules.
<CIA-33> debian-installer: lool * r1183 ubuntu/debian/changelog: Release 20081029ubuntu64
<davmor2> cjwatson: I think you might of over fixed the side by side install issue.  Vista now shows up in wubi's grub install even though ubuntu doesn't :)
<CIA-33> ubiquity: cjwatson * r3487 ubiquity/debian/ (changelog rules): Disable the intro message in preparation for Ubuntu 9.10 beta.
<CIA-33> ubiquity: cjwatson * r3488 ubiquity/debian/changelog: releasing version 1.99.26
<lamalex> cjwatson: My company are not looking like they're willing to sign over the copyright for the partition size patch
<lamalex> (why I have no fscking idea)
<lamalex> IP rights are the biggest load of bs
#ubuntu-installer 2009-09-29
<CIA-33> casper: cjwatson * r698 trunk/ (debian/changelog scripts/casper-bottom/19keyboard):
<CIA-33> casper: Extend our hack that arranges to run setupcon after usplash exits to
<CIA-33> casper: cover the new Upstartified usplash as well.
<CIA-33> casper: cjwatson * r699 trunk/debian/changelog: releasing version 1.196
<CarlFK> box PXE boots, can load both ibex and karmic installers, run them, but can't get a dhcp response.  I just installed karmic from cd, it booted and got a dhcp response
<CarlFK> Intel  82557 Ethernet pro 100mb nic
<CarlFK> 03:04.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)
<mpt> evand, hi, where is your gallery of Ubiquity screenshots of each stage?
<evand> mpt: http://people.canonical.com/~evand/screenshots/
<evand> I should probably update some of those (the slideshow especially).  I'll pull down the latest daily-live and do that now.
<mpt> evand, yes, I see 8.10 there, I think the text has changed a bit since then
<evand> http://people.canonical.com/~evand/screenshots/ubiquity/1.12.3/ is Jaunty, but the point still stands.
<mpt> ah, thanks
<ogra> cjwatson, d-i is quite unhappy on armel (imx51, vfat image) due to the fact that there is no dist/stable symlink to dist/karmic, ghiven that vfat doesnt support symlinking, is there any way around that ? i tried moving karmic -> stable which gets me through partman but then debootstrap cant find the codename for the release
<cjwatson> ogra: are you using cdrom-detect?
<ogra> i thought lool added that recently
<cjwatson> it's a question suggesting a yes or no answer ;-)
<cjwatson> actually, not sure that's relevant. could I please have a full syslog
<mpt> evand, sorry for the silly question, but is Wubi on the live CD?
<cjwatson> yes
<evand> mpt: indeed it is.  In the root of the CD.
<mpt> thanks
<ogra> cjwatson, i see cdrom-detect in the log and indeed its the part that fails when looking for dist/stable, i'll save the log somewhere, d-i installs are not a high prio on armel atm
<cjwatson> well, it was my memory that cdrom-detect would be the relevant bit, but on looking at the code I can't see exactly which bit might fail. that's why I asked for the log
<lool> cjwatson: Do you remember that weird missing font issue I had a while ago on lpia?  I just hit the same on armel alternates: black squares when prompted by to type some keys to detect my layout
<lool> bug #357630
<ubottu> Launchpad bug 357630 in kvm "fonts don't match chars used in d-i" [Wishlist,Invalid] https://launchpad.net/bugs/357630
<ogra> cjwatson, http://people.canonical.com/~ogra/syslog dont handle it as high prio though, armel alternate is just a nice to have
<cjwatson> ogra: why did you say that cdrom-detect is the part that fails? (it isn't)
<ogra> in the UI it seems to be the part that fails
<cjwatson> it fails due to something else
<ogra> i have to mount /dev/mmcblk0p2 manually and move the dir
<cjwatson> at least so the log suggests?
<cjwatson> what is the error message in the UI?
 * lool managed to load components from CDROM with the latest dove alternate, yeah!
<lool> Just need a preseed fix for cdrom-detext
<ogra> well, that it could not detect a cd i then get offered to load cd drivers from removable media
<cjwatson> please don't paraphrase error messages
<ogra> sorry, i dont recall the exact text and already overwrote my SD
<cjwatson> ok, can't help then, sorry
<cjwatson> feel free to come back when you have the exact text
<ogra> i'll do it again later
<cjwatson> and then I can grep for the relevant code paths
<cjwatson> I'd like to fix this but since you say it's not high-priority I don't want to spend too much time investigating something that might turn out to be a red herring
<ogra> right
<ogra> i'll test again after the live test
<ogra> which is the actual image we care about
<dpm> cjwatson: good morning, I've just been pointed out by translators that there is something wrong with the ubiquity templates, now both 'ubiquity-desktop' and 'ubiquity' are the same templates. It seems that the wrong template was uploaded for 'ubiquity' -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity
<cjwatson> how could that have happened?
<cjwatson> do you mean I did a wrong manual upload or something?
<dpm> I don't know, it seems to have happened 13 hours ago. Was there an upload at about that time?
<cjwatson> a package upload yes, but I didn't do anything manual
<cjwatson> if the package upload caused something bad to happen, then metadata in Launchpad must be wrong
<dpm> let me grab some launchpadders...
<cjwatson> and it wasn't the first package upload since I was last aware of the metadata being changed around
<jtv> dpm, you called?
<dpm> yes, thanks for coming, jtv, here's the issue:
<dpm> https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity
<dpm> has 2 templates
<dpm> which are now identical
<dpm> the 'ubiquity' one is wrong
<dpm> it used to be a much bigger template
<dpm> and we don't know what has caused to change it
<dpm> there was a package upload about 13 hours ago
<dpm> but cjwatson hadn't done any manual uploads
<jtv> The configuration is pretty weird.
<jtv> The ubiquity-desktop template has domain "ubiquity"
<jtv> whereas the ubiquity template has domain "debconf"
<jtv> The ubiquity-desktop template also has filename po/ubiquity.pot
<cjwatson> so somebody screwed up the rename
<cjwatson> po/ubiquity.pot is correct for ubiquity-desktop
<jtv> I see two uploads, both approved to be imported into the ubiquity template.
<cjwatson> the ubiquity template should come from debian/real-po/templates.pot
<cjwatson> I have no idea what its domain should be, domains aren't significant to debconf translations so it would be an artificial construction
<jtv> I'm editing the entry.
<cjwatson> jtv: how do we avoid losing translation data here?
<cjwatson> can we revert that part of the db to before the incorrect import?
<jtv> cjwatson: the translation data should come back instantly when the templates are set right again.
<dpm> jtv: I just got disconnected. Just to make sure, did you get my previous messages with the description of the issue?
<cjwatson> dpm: I'll paste you the relevant bits in /msg
<jtv> dpm: no
<jtv> dpm: unless you mean the one 22 minutes ago
<jtv> nothing after that
<cjwatson> we got everything up to "but cjwatson hadn't done any manual uploads"
<cjwatson> to clarify, I did manual uploads *ages* ago
<jtv> Meanwhile I've approved the new uploads to go into the right templates.
<dpm> jtv: any ideas on what could have happened here?
<dpm>  I see that https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity/+imports?field.filter_status=all&field.filter_extension=pot shows two approved templates
<dpm>  To further confuse matters, it seems that debian/real-po/templates.pot will be imported into 'ubiquity' (which would be the correct template)
<dpm>  whereas po/ubiquity.pot seems that will _also_ be imported into 'ubiquity' <- that might be the problem. That template should be imported into 'ubiquity-desktop'
<cjwatson> weeks, I think
<jtv> dpm: I thought I just fixed that!?
<cjwatson> I *think* I did check after that and observed sane output, though I don't remember for sure
<dpm> jtv: what did you fix and what needed fixing?
<cjwatson> jtv: he's pasting what he said between being disconnected and realising he was disconnected
<jtv> phew, still fixed
<jtv> cjwatson: silly me!  thanks
<jtv> dpm: somehow, both templates got approved for the same template.  I can't think why, but given the strange configuration it's not entirely unthinkable
<jtv> Figuring this out could take some effort.  Normally template approvals are based on paths, which in this case shouldn't present a problem (even if they are weird).
<jtv> So _if_ this was an auto-approval, why was it not based on paths?
<jtv> Or was it based on paths, and have the paths changed since?
<cjwatson> they haven't changed since the last time we worked on the configuration here; they have certainly not *exchanged*
<jtv> Evan Dandrea also uploaded a template btw
<jtv> That was on Friday.  It was po/ubiquity.pot but it went into the ubiquity template, not the ubiquity-desktop one.
<cjwatson> that would have been a package upload
<cjwatson> so that just means we know the configuration was broken at least back to Friday
<cjwatson> Evan's package upload was actually on Thursday but I guess it took a while to get through the queue
<jtv> May be timezones as well.  The time I see is localized for me and says Friday 01:03 ICT, so that's Thursday for you.
<evand> Yeah, I was in PDT on Thursday.
<jtv> So that was a package upload?
<evand> yes
<CIA-33> tasksel: cjwatson * r1422 ubuntu/ (6 files in 3 dirs):
<CIA-33> tasksel: Omit tasks with no descriptions (namely ubuntu-edu-preschool,
<CIA-33> tasksel: ubuntu-edu-primary, ubuntu-edu-secondary, and ubuntu-edu-tertiary;
<CIA-33> tasksel: LP: #438546).
<jtv> I'm digging through the templates approval logic a bit
<CIA-33> tasksel: cjwatson * r1423 ubuntu/debian/changelog: releasing version 2.73ubuntu22
<jtv> Nope, no way that could have gotten auto-approved without a path match
<jtv> Which leaves 2 possibilities: manual approval, or an upload to a page for the wrong template.
<jtv> cjwatson: do you still use the lp translations tools for uploading these files?
<cjwatson> yes
<dpm> jtv: is there a way to track if it was manually approved? I'm not concerned about who did it, I'm only interested to see if we'll have to keep an eye on this template
<cjwatson> I no longer have the command lines to hand
<jtv> dpm: we'd have to ask the sysadmins to dig through access logs.  Ugly.
<jtv> Anyway, what if the confusion happened because a translation domain got confused with a template name?
<dpm> jtv: don't worry, I'll ask at the u-t-c list
<jtv> One template is name ubiquity and the other has domain ubiquity, that's bound to cause trouble somewhere.
<jtv> What do we know about when this template started being wrong?
<ogra> cjwatson, mind if i make the "debian/genbuilddeps" instructions more explicit when i actully do the missing run for my last b-d change from yesterday ?
<ogra> "Note that this comment can also be used to generate a Build-Depends line, by running the debian/genbuilddeps program." makes it sound very optional and i always forget it
<cjwatson> jtv: the template was renamed from "debconf" to "ubiquity" a while back because "debconf" was 'confusing'.
<cjwatson> I think that was not clearly the best possible decision
<cjwatson> ogra: I'd prefer you didn't introduce another thing to make that file more complicated to merge
<jtv> cjwatson: ubiquity-debconf might have been safer
<cjwatson> ogra: if you want it changed, mail me improved text and I'll look at changing it upstream
<cjwatson> dpm: ^-
<ogra> ok, couldnt debian/genbuilddeps be run automatically ?
<cjwatson> no.
<cjwatson> leave that alone please :)
<ogra> ok
<cjwatson> generating build-deps entirely automatically tends to be bad and wrong; I expect people to read comments
<ogra> i wasnt planning to :)
<cjwatson> (it causes problems with timestamp ordering in builds)
<cjwatson> cf. why that cdbs debian/control generation option is generally considered forbidden
<ogra> ah
<dpm> cjwatson: jtv, I still believe that 'debconf' alone might be confusing to translators when it appears in the global list of templates to translate, as there is no connection to the ubiquity source package there. jtv: I'd be more than happy to have 'ubiquity-debconf' and 'ubiquity-desktop' if necessary, but I don't see the problem in the previous name. What is confusing right now is the domain name, but if I understand it correctly, it is not releva
<dpm> nt in those particular templates, so we could change the domain names to match the template names
<jtv> dpm: having them match would be best from my perspective, yes.
<dpm> so, jtv, cjwatson, would you agree if I do the following changes?
<dpm> Template name: ubiquity-debconf (renamed from ubiquity)
<dpm> Domain name: ubiquity-debconf (renamed from debconf)
<dpm> Template name: ubiquity-desktop (stays the same)
<dpm> Domain name: ubiquity-desktop (renamed from ubiquity)
<jtv> dpm: wonderful
<jtv> molt bÃ©
<dpm> thanks :)
<cjwatson> hang on, what's the effect of changing the ubiquity -> ubiquity-desktop domain in Launchpad?
<cjwatson> BTW I think it's a bug that 'debconf' is displayed to translators on its own without the context of the package name as well
<cjwatson> s/is/was/
<cjwatson> I mean, no wonder they were confused if they weren't told what package it was in :)
<jtv> Changing the domain means that the MO files will be installed with a different name.
<jtv> But if this is apparently an installer thing, does that matter?
<cjwatson> this isn't in language packs
<cjwatson> so I assume the answer to that is roughly "what MO files?"
<cjwatson> right, in this case they just get merged into a .desktop file
<cjwatson> or files
<dpm> oh dear my connection is flaky today, too much rain, I guess. jtv, I'm not trying to be annoying, just checking if you had the chance to answer the last question :)
<jtv> dpm: last I saw from you was "thanks"
<jtv> Then from cjwatson, what's the effect of changing the domain?
<dpm> yes, then I said
<dpm> jtv: in that particular case, since ubiquity-desktop is not exported in language packs, there will be no effect in that, I guess?
<jtv> dpm: missed that, but based on what colin says, that's right.
<dpm> ok, thanks.
<cjwatson> so those changes sound fine then; presumably translators will need to be notified again
<dpm> cjwatson: yes, I have to respond the e-mail in which they were wondering about the duplicate templates, so I'll announce that there
<dpm> I can do the domain name changes straight away, but for the template name changes do you think it's better if I wait until the templates have been imported, jtv?
<jtv> dpm: doesn't matter.  The uploads are attached to templates.  They don't remember domain names as such.
<dpm> jtv: that's what I meant, the domain name changes are ok, but the template name changes, can I do them straight away or better wait until the approved templates in the queue have been imported?
<jtv> dpm: no need to wait.
<dpm> great, thanks
 * jtv goes hunter-gathering
<dpm> cjwatson: and the last question on this: in the e-mail where the duplicate template was pointed out, Timo was also mentioning that there are some untranslated items. Is the next translation export scheduled, so that I could tell translators to test them?  (once the templates issue has been sorted). Or would you rather prefer to have a bug filed for all untranslated strings?
<dpm> https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002784.html
<cjwatson> dpm: I *hate* *hate* *hate* combined bugs for translation issues
<cjwatson> they're abysmally painful to deal with
<dpm> good that I asked :)
<cjwatson> one bug per problem would be easier, after somebody has confirmed that they aren't just missing translations - i.e. that the string in question is actually not translatable
<cjwatson> we have lots of old translation bugs lying around because we haven't quite fixed one out of seven issues reported or something
<cjwatson> it's just hopeless
<dpm> ok, I'll recommend that, then
<cjwatson> thanks
<dpm> np, just so I or the other translators can figure out whether the translations do not appear simply because they haven't been exported, where is the best place to quickly track the dates in which there were translation exports? The package changelogs?
<cjwatson> yes
<dpm> great, thanks
<cjwatson> I'd look now but I'm doing wubi testing
<cjwatson> hmm, wubi just sits there at the end of partman for me
 * cjwatson tries it not in verbose mode
<cjwatson> ah, there we go
<evand> cjwatson: thanks for unbreaking oem-config (whereby it would go straight into oem-config rather than the preparation desktop).  That one had me scratching my head a bit.
<cjwatson> yeah, I screwed up the job a bit
<cjwatson> evand: could you upload a new wubi soonest, please?
<cjwatson> the current image still has grub 1.97~beta2
<cjwatson> ubiquity shutdown is still messy :-/
<davmor2> cjwatson: very
<evand> weird.  I uploaded a new one this morning
<evand> I guess it didn't pick it up
<evand> or something is still pulling the wrong version
 * evand digs
<davmor2> flickering between desktop and shutdown text.  Should xsplash take over on shutdown cjwatson
<cjwatson> no the problem is that gdm keeps respawning
<cjwatson> evand: was the last desktop CD build since then?
<evand> cjwatson: 20090929.1 was, yes
<cjwatson> I don't think that's the sole cause of the problems here though
<cjwatson> though it would impede a fix
<evand> hrm, using wubi from rookery shows grub 1.97~beta3
 * evand grabs the actual cd image
<cjwatson> oh, I have 20090929 here
<cjwatson> not .1
<evand> ah, that would do it
<cjwatson> I guess I'll rsync that quickly then
<evand1> hrm, automatic-ubiquity is broken
<davmor2> evand1: is that what wubi uses?
<evand1> yes
<evand> ah, maybe it's not broken after all
<evand> ignore me for the time being :)
<lool> I think we're using g-i for amd64 netboots, it there a way to disable it?
<evand> mpt: http://people.canonical.com/~evand/screenshots/ubiquity/9.10-beta-candidate/
<CIA-33> ubiquity-slideshow-ubuntu: evand * r157 ubiquity-slideshow-ubuntu/debian/changelog: Use correct version number in the changelog.
<mpt> evand, thanks -- why does <http://people.canonical.com/~evand/screenshots/ubiquity/9.10-beta-candidate/4-automatic-partitioning.png> not include the side-by-side option?
<lool> Ah, I know why I get the issue with the fonts
<lool> It happens in non-fb mode
<ogra> non fb defaults to vt102
<ogra> (for TERM)
<lool> ogra: Funny, it's in that piece of code you quoted the otherday
<lool> readlink /proc/self/fd/0 returns /dev/console which d-i understands as a serial console
<ogra> yeah
<ogra> whyevery though
<ogra> *ever
<lool> Hmm no, that's only if I break with init=/bin/sh
<lool> Bah
<davmor2> mpt: I'm assuming that the partition is too small to fit 2 installs side-by-side
<davmor2> mpt: if you would like I can take a shot that shows up as many different install methods as possible for you?
<superm1> ate
<superm1> oops, sorry
<mpt> davmor2, thanks but no, I was just wondering why it is missing
<mpt> davmor2, if it's hidden for that reason, probably there should be an explicit explanation of why it's not there
<mpt> otherwise people who are expecting it will wonder why
<davmor2> mpt: that's what I'm assuming the issue is.  But I'll be running a whole heap of installs so I can take a quick screenshot if you change your mind
<evand> mpt: I didn't have enough space on the existing partition for both.
<davmor2> Yay assumption correct :)
<mpt> evand, would you like a bug report for explaining that in Lucid then?
<evand> mpt: please
<mpt> k
<evand> ah, looks like "splash" breaks the ubiquity upstart job somehow.
<mpt> evand, reported bug 438709
<ubottu> Launchpad bug 438709 in ubiquity "No explanation on partitioning screen of why dual-booting option isn't available" [Undecided,New] https://launchpad.net/bugs/438709
<evand> mpt: thanks!
<CIA-33> casper: cjwatson * r700 trunk/ (debian/changelog scripts/casper-bottom/25configure_init): Fix tty device name construction to work with new upstart (LP: #438678).
<cjwatson> evand: maybe ubiquity's upstart job needs to emit starting-dm
<cjwatson> cf. recent gdm change
<cjwatson> same for oem-config I suppose
<cjwatson> something like http://paste.ubuntu.com/281338/ maybe?
<evand> cjwatson: cool, I'll look into that.  Thanks
<cjwatson> maybe we should turn off splash for the beta
<cjwatson> for the live CD
<evand> yeah, ugly, but I agree
<evand> actually, let me see if this really fixes it
<evand> oddly, using break=bottom also makes it disappear
<evand> so I'll have to repack the squashfs
<cjwatson> break=bottom kills usplash I think
<cjwatson> so if my speculation is right, that the problem is that usplash doesn't get killed at the right time ...
<evand> ahhh
 * cjwatson wonders why c-a-f1 doesn't work in wubi
<cjwatson> while installing, I mean
<evand> it doesn't work anywhere
<evand> ogra posted a bug
<evand> bug 438678
<ubottu> Launchpad bug 438678 in casper "25configure_init uses /dev/ttyN.conf instead of /dev/ttyN for /etc/init/tty*.conf mangling" [Medium,Fix committed] https://launchpad.net/bugs/438678
<ogra> cjwatson fixed it already :)
<cjwatson> that wasn't quite what I meant though, I don't think
<cjwatson> in this case, it simply doesn't switch away from X at all
<cjwatson> it's not that it switches away but the command that's running is broken
<cjwatson> which is what I'd expect from a bogus upstart job - unless upstart is taking the trouble to notice the failure and actively tear down the termianl
<evand> oh, my apologies
 * ogra is confused ... 
<ogra> /usr/share/initramfs-tools/scripts/casper-bottom/22serialtty is clearly in the package ... buildlog and dpkg -L both agree
<ogra> but i dont see it in my livefs
<ogra> nor in initramfs
<rgreening> evand: bug 438316
<ubottu> Launchpad bug 438316 in udev "hal does not properly present USB media on Acer Aspire 6930" [Undecided,New] https://launchpad.net/bugs/438316
<ogra> and i definately have the right casper version
<rgreening> evand: that's the info we discussed the other day regarding my usb issue.. if you have any other suggestions... or ideas
<evand> cjwatson: that indeed fixes it
<evand> rgreening: cool, I'll take a look in a bit
<rgreening> evand: much appreciated. you'll likely have a better idea where to go next.... more so than I
 * rgreening is stumped!
<cjwatson> ogra: lool made it executable recently in bzr; I can't immediately see a mechanism by which that would cause that particular failure, but I suppose it's possible
<cjwatson> lool: could you do the CIA stuff in http://wiki.ubuntu.com/Installer/Development to your casper branch so that commits show up here, please?
<rgreening> evand: on another note, this Acer issue prompted me to buy a Dell... hahah
<ogra> cjwatson, yeah, and not seeing it atm was just my stipidity
<evand> heh
<ogra> *stupidity
<ogra> cjwatson, i did /usr/share/initramfs-tools/scripts/casper-bottom/<tab><tab> ... which indeed doesnt show nonexecutable files (do'h)
<CIA-33> ubiquity: evand * r3489 ubiquity/debian/ (3 files):
<CIA-33> ubiquity: Emit starting-dm in the ubiquity and oem-config upstart jobs.
<CIA-33> ubiquity: Thanks Colin Watson!
<cjwatson> evand: can you confirm that simply removing splash makes it work ok?
<evand> cjwatson: already have
<evand> I can double-double check though :)
<cjwatson> ok, good - slangasek sounded like he didn't want to rebuild the livefs if possible
<cjwatson> nah, that's ok :)
<evand> okay
<cjwatson> any idea why wubi installations often seem to hang on "Checking the installation..."?
<evand> should I upload this change to ubiquity just in case we need to rebuild anyway?
<evand> not sure offhand.
<davmor2> cjwatson: is that about the 7% mark?
<evand> I didn't notice it in my testing
<cjwatson> davmor2: no
<cjwatson> evand: might as well get it into the queue, yes
<evand> okay
<cjwatson> it's immediately after "Computing the new partitions..." as a secondary progress message, and that progress message isn't cleared, but the progress bar sits at 100% and it says "Checking the installation..." as a primary progress message
<cjwatson> BTW, as a general rule, progress percentages aren't necessarily all that useful - they often aren't quite the same between systems. The text of the message is more useful
<cjwatson> you can't easily get from a percentage to the place in the code that's responsible
<davmor2> cjwatson: cool remember that for future reference
<cjwatson> evand: I'm not sure it's entirely reproducible, as I've been seeing it intermittently, although more often than not
<cjwatson> of course "Checking the installation..." is a fairly long set of steps at the start - perhaps more informative to say that it happens after guided partitioning
<cjwatson> ah, now after rebooting into Windows and back, it works. maybe a filesystem needed checking? ugh
<evand> I imagine the lack of a vt doesn't help here
<cjwatson> that may have been why I was pondering this, yes :)
<cjwatson> oh well, let's see if it manages to comprehend my hacked cd
<cjwatson> j,,
<cjwatson> oops
<cjwatson> hmm. I see the wubi bug. now I wonder how I fix it
<evand1> oh?
<cjwatson> when lupin-support is installed, /host isn't bind-mounted onto /target
<cjwatson> onto /target/host that is
<cjwatson> and so /etc/grub.d/10_lupin ignores the device
<CIA-33> ubiquity: evand * r3490 ubiquity/debian/changelog: releasing version 1.99.27
<evand1> ah
<cjwatson> if I'm very lucky, it's a one-liner
<cjwatson> but a livefs rebuild, sadly
<lool> cjwatson: Sure; is there a list of packages for which we use CIA?
<lool> cjwatson: I now realize casper is an installer-ish package
<cjwatson> there isn't
<cjwatson> sorry
<lool> cjwatson: (You're aware we cant rebuild the armel livefses?)
<cjwatson> yes
<cjwatson> wubi is not used on armel, last I checked :)
<CIA-33> casper: lool * r701 trunk/ (debian/changelog scripts/casper-bottom/22serialtty): scripts/casper-bottom/22serialtty: pass -L to getty and set term to vt100.
<CIA-33> casper: lool * r702 trunk/ (debian/changelog scripts/casper-bottom/22serialtty): scripts/casper-bottom/22serialtty: set +x...
<lool> cjwatson: Ok; just making sure you dont rebuild all livefses or something
<lool> cjwatson: Not something you'd do, but I wasn't sure there werent other changes  :)
<CIA-33> partman-auto-loop: cjwatson * r53 ubuntu/ (debian/changelog finish.d/create_host_mountpoint):
<CIA-33> partman-auto-loop: Bind-mount /host on /target/host during installation, to match the
<CIA-33> partman-auto-loop: installed system after reboot (LP: #435153).
<CIA-33> partman-auto-loop: cjwatson * r54 ubuntu/debian/changelog: releasing version 0ubuntu18
<CIA-33> ubiquity: cjwatson * r3491 ubiquity/ (d-i/manifest debian/changelog):
<CIA-33> ubiquity: Automatic update of included source packages: partman-auto-loop
<CIA-33> ubiquity: 0ubuntu18.
<ogra> lool, there is a list in the filter on the cia website
<ogra> (in the custom filter, not the one you get on the first page)
<CIA-33> ubiquity: cjwatson * r3492 ubiquity/debian/changelog: releasing version 1.99.28
<lool> ogra: Oh right
 * lool would love colours
 * ogra hands lool some pots with paint
<lool> I remember playing with setting up my own cia server when it was regularly going down and setting up some cute colours for committer/project etc.; it's certainly nice to have so much time on one's hands  :-)
<rgreening> evand1: hey
<rgreening> evand1: you know that USB issue I have? If I insert a CD and then plug in the stick it works. But I must insert a CD device first.. that is bizarre.
<rgreening> evand1: I've updated the bug 438316 with newer narrowed down info. Im so stumped .. haha
<ubottu> Launchpad bug 438316 in udev "hal does not properly enumerate USB devices unless CD-ROM inserted as first device" [Undecided,New] https://launchpad.net/bugs/438316
<cjwatson> davmor2: and grub.cfg?
<davmor2> cjwatson: that should be in the disks/boot/grub folder right?
<cjwatson> no, it's inside root.disk
<cjwatson> ignore disks/boot/grub, I know it's an empty directory and it's a minor wubi bug that it's still being created
<davmor2> under boot/grub on root.disk there is only grubenv
<cjwatson> wuh
<cjwatson> well that would explain the problem, but it didn't happen to me
<cjwatson> I wonder if you have filesystem corruption
<cjwatson> *is* there anything in /ubuntu/disks/boot/grub/ ?
<davmor2> no
<cjwatson> ok, I don't know what the problem might be :(
<cjwatson> there's no indication in the logs
<davmor2> I'll wipe wubi run a check on the vista fs and reinstall and see if it was just a glitch
<cjwatson> what size is your installation?
<cjwatson> just in case I can reproduce it with a larger installation or something
<cjwatson> although that'll be tomorrow at this point, not today
<davmor2> whatever the default is I think it's 16gig
<davmor2> 2 ticks and I'll tell you
<cjwatson> hmm, I won't be able to manage that here
<cjwatson> I can do up to about 8GB
<davmor2> 17 gb infact
<cjwatson> but mine is 5GB right now, and there shouldn't be any intrinsic difference ther
<cjwatson> e
<cjwatson> davmor2: hmm, also you can't have been seeing this problem last time because you *did* have a grub.cfg then
<cjwatson> I dunno, wubi just anecdotally seems not very stable to me - I suspect there's some underlying kernel issue
<cjwatson> I'll do another test with a non-hacked-up image tomorrow
<davmor2> cjwatson: vista sack of crap disk check utility is just finishing off after hmm 30 minutes of running so I'll be able to re run the install maybe today :(
<ramvi> I don't understand why it doesn't say anywhere what's needed to compile wubi
<ramvi> On the wiki it says to do: make prerequisites, but it doesnt work
<evand1> ramvi: that's out of date documentation
<ramvi> What's needed? mingw32..
<ramvi> I'm still getting errors
<evand1> build-essential, grub-pc
<ramvi> evand1: thank you
<ramvi> evand1: Sorry to bother you, but I'm still getting the error:
<ramvi> sh: msgfmt: not found
<ramvi> make: *** [translations] Error 127
<evand1> evan@bunny:~$ dpkg -S /usr/bin/msgfmt
<evand1> gettext: /usr/bin/msgfmt
<evand1> so gettext as well
<ramvi> evand1: thank you! I'll update the wiki
<evand1> thanks
#ubuntu-installer 2009-09-30
<davmor2> meh
<davmor2> evand1: cjwatson: wubi just locked up at scanning disks
<davmor2> rebooted now it's working meh
<davmor2> may have to try this again tomorrow
<davmor2> fail
<davmor2> I'm checking the cd incase it's a bad burn
<xivulon> cjwatson, tested wubi and is fine here :)
<davmor2> xivulon: sweet
<xivulon> only minor thing, is that the grub2 menu should be hidden, as discussed a few days ago'
<xivulon> davmor2, please test it yourself and let me know if there is any issue
<davmor2> I think I might of had a dud burn or something
<StevenK> xivulon: Oooh, does Wubi work now?
<xivulon> StevenK works for me, please try it out and report any problem
<StevenK> xivulon: I shall
<xivulon> for this cycle it is mostly merit of cjwatson
<davmor2> xivulon: out of interest what size partition did you give wubi?
<xivulon> 5GB
<davmor2> I was having issues last night at the default of 17gb
<xivulon> what sort of issues?
<davmor2> no grub.cfg at all
<xivulon> hmm that should be independent of the partition size
<davmor2> but as I say I'm hoping it was just down to a bum burn and am trying again this morning
<xivulon> in case you have the same issue post in lp
<davmor2> cjwatson: Wubi worked Yay \o/
<davmor2> must of just been a bad burn
<xivulon> davmor2 cool
<cjwatson> davmor2: there definitely seems to be some instability
<cjwatson> it works, but only sometimes, AFAICS
<cjwatson> I have a hard time putting your previous problem down to a bad burn; if that were the case I'd expect some log messages
<davmor2> cjwatson: I'm just trying a 64 bit one now I'll let you know
<davmor2> cjwatson: the only flaw I had in the 32bit one was with the gdm respawn at the end
<cjwatson> right
<davmor2> dj64bit just locked up on scanning disks
<davmor2> cjwatson: ^
<davmor2> don't where the dj came from
<evand> davmor2: by locked up do you mean you cannot use the mouse and keyboard?
<davmor2> evand: mouse moves, no c-a-fx though
<cjwatson> C-A-Fx is broken on Wubi installation, I don't know why
<cjwatson> and this is the same kind of instability I was referring to
<cjwatson> reboot and try again :-/
<davmor2> cjwatson: reboot it's now gone sailing past that point no issues so far
<evand> lovely
<davmor2> cjwatson: that time it's worked fine Meh
<evand> superm1: cody-somerville: would you be so kind as to add resierfsprogs to your respective live seeds.  Thanks!
<davmor2> evand, cjwatson: would you like me to post a bug that wubi is a little erratic and you may need to reboot?
<cjwatson> sure, though I don't think I'll be able to do anything much about it myself :(
<davmor2> cjwatson: no but at least it can be release noted :)
<cody-somerville> evand: done
<davmor2> cjwatson: bug 439279
<ubottu> Launchpad bug 439279 in wubi "There seems to be some instability with the installer" [Undecided,New] https://launchpad.net/bugs/439279
<davmor2> cjwatson: on kubuntu wubi install I get:
<davmor2> Try (hd0,0): NTFS5: No wubildr
<davmor2> same for hd (0,1)
<davmor2> and then Try (hd0,2): NTFS5: _  with the _ being the cursor then nothing
<cjwatson> would be interesting to know if it reproduces
<davmor2> I'll re-run it now
<evand> I'll give wubi a testing as soon as I get to the bottom of this usplash not showing the eject CD message issue I'm seeing.
<davmor2> cjwatson: reboot give exactly the same result
<davmor2> 3 reboots
<davmor2> trying a reinstall
<cjwatson> yeah, I meant reinstall I'm afraid
<cjwatson> I'll give it a try myself later - this sounds more like instability than something intrinsically Kubuntu-related though
<davmor2> cjwatson: this time it's been dropped into sh:grub>
<ara> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/439306
<ubottu> Launchpad bug 439306 in ubiquity "Migration assistant didn't migrate Firefox bookmarks" [Undecided,New]
<ara> evand, ^
<cjwatson> evand: ^-
<cjwatson> snap
<ara> :)
<evand> long known problem
<evand> migrationassistant will get replaced at some point
<evand> but right now it doesn't understand sqlite
<cjwatson> maybe there's a test case somewhere that we can annotate to say this
<davmor2> cjwatson: I'm going to try a 64kub wubi install
<cjwatson> I don't know if completing the matrix there is going to add much information, TBH
<davmor2> if this one fails dismally too do you want me to bother loop mounting the drive to get the logs off it?
<cjwatson> it seems somewhat unstable and nondeterministic in all combinations
<cjwatson> it's not that any one thing always fails dismally, or always succeeds
<cjwatson> it's that all of them are somewhat random
<cjwatson> sure, logs won't hurt
<davmor2> okay cool :)
<cjwatson> from what I can gather I don't think we should label failures as specific to any particular build though
<davmor2> just wubi
<davmor2> cjwatson: http://www.davmor2.co.uk/wubi/syslog1
<cjwatson> could this go on a bug or something please, I can't really look just now
<davmor2> cjwatson: yeah do you want a new bug or will my generic wubi is a bit screwed bug do?
<cjwatson> though again, doesn't show any *evidence* of breakage that I can see
<cjwatson> the same one should be ok
<cjwatson> would like /boot/grub/grub.cfg too if it exists
<cjwatson> or a note if it doesn't
<davmor2> no probs
<davmor2> cjwatson: that's interesting the last kubuntu failure has a grub.cfg that looks correct
<cjwatson> how does it fail this time?
<davmor2> sh:grub>
<cjwatson> search -s -f -n /ubuntu/disks/root.disk
<ara> dpm, I don't know if this should be a bug in firefox or casper/ubiquity: bug 439392
<evand> cjwatson: if you happen to do any testing with KVM later, can you confirm bug 439385 ?
<ubottu> Launchpad bug 439392 in firefox-3.5 "After an installation of Karmic beta in Spanish, firefox is not localized in Spanish" [Undecided,New] https://launchpad.net/bugs/439392
<ubottu> Launchpad bug 439385 in usplash-theme-ubuntu "text fails to display with KVM's cirrus video card." [Undecided,New] https://launchpad.net/bugs/439385
<CIA-33> ubiquity: cjwatson * r3493 ubiquity/ (debian/changelog scripts/install.py): Use a separate PROGRESS REGION for each install plugin (LP: #438979).
<cjwatson> ara: is the Spanish firefox localisation package installed?
<cjwatson> ara: oh, this is probably the open bug about language-support packages not being installed at all following their reorganisation
<dpm> ara: thanks for the heads up, I think it is a problem with the es_ES locale, let me see if I can dig the bug out...
<cjwatson> I was going to fix that for beta but didn't have time
<cjwatson> evand: ok
<cjwatson> ara,dpm: I'm thinking of bug 434173
<ubottu> Launchpad bug 434173 in language-selector "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [Undecided,Fix committed] https://launchpad.net/bugs/434173
<ara> cjwatson, it is happening in the live environment as well
<cjwatson> ara: live environments are expected not to have complete localisation; there is not enough space
<ara> cjwatson, ok
<cjwatson> oh yes, that's why I didn't fix bug 434173 - I can't because language-selector hasn't been uploaded yet
<ubottu> Launchpad bug 434173 in language-selector "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [Undecided,Fix committed] https://launchpad.net/bugs/434173
<dpm> <asac> dpm: the country code is only an issue if the exported .po files have that
<dpm> <asac> like es-ES -> broken
<dpm>  fi -> works
<dpm> I think it is a particular bug in FF
<cjwatson> dpm: so possibly two overlapping issues here
<dpm> yep
<cjwatson> (a) localisation package not installed (b) it wouldn't work if it were
<cjwatson> I'll make 434173 release-critical for the final release
<evand> I've run into the scanning disks wubi bug :-/
<superm1> evand, what's wrong with making it a recommends for ubiquity (reiserfsprogs)? wouldn't that fix the problem without requiring all seeds to explicitly declare it?
<evand> superm1: I don't see any problem with that.  I was just following the existing convention.
<superm1> evand, okay so i guess next logical question is why was that existing convention defined that way?
<evand> cjwatson: ^ ?
<CarlFK> are there any size constraints for the netboot initrd?    what is at: http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/netboot/ubuntu-installer/i386/initrd.gz
<CarlFK> I am getting "E100_request_firmware failed to load firmware "e100/d101m_ucode.bin file not found."  if that is expected because there isn't room, ... grumble... else I'll file a bug
<evand> cjwatson: so I found a bit of a workaround for the not having getty and wubi failing issue.  Wait for the slideshow to appear, click on a link.  When Firefox opens, type irc: in the address bar, then select a custom handler of /usr/bin/xterm ;)
<cjwatson> evand: reiser> don't have strong feelings either way
<cjwatson> evand: haha
<evand> Is there a bug open for the ubiquity lock ups when running under wubi bug?
<evand> I can't seem to find it under ubiquity, partman-auto-loop, or wubi
<cjwatson> CarlFK: I *think* that's the responsibility of the kernel to ship the right bits in the firmware udebs
<cjwatson> evand: I thought davmor2 filed one on wubi - bug 439279?
<ubottu> Launchpad bug 439279 in wubi "There seems to be some instability with the installer" [Undecided,New] https://launchpad.net/bugs/439279
<evand> ah weird. Somehow I missed that.  Thanks
<CarlFK> cjwatson: isn't the installer kernel the same as the kernel that gets installed? (so should have all the same support... so something broke)
<cjwatson> CarlFK: the kernel image (vmlinuz) itself is, but the module selection is stripped down
<cjwatson> (and always has been)
<CarlFK> cjwatson: ok - as long as its intentional and not an opps.  but I am guessing good nic support is something the netboot kernel should have - Ill bug all this and let someone make a decision
<cjwatson> stick the bug on linux, it's probably just a matter of adding that file to nic-firmware
<mikefletcher_> Hi.  In Jaunty I used to be able to add 'text' to the boot options on the live cd and I would end up in a logged in shell.  I opened bug 434769 to cover this regression.  It has been fixed but I retested on the latest nightly and it doesn't work.  My Question: What package should this bug be under?
<ubottu> Launchpad bug 434769 in casper "Login Prompt on Live CD Text Mode" [Medium,Fix released] https://launchpad.net/bugs/434769
<cjwatson> mikefletcher_: that's bug 438678
<ubottu> Launchpad bug 438678 in casper "25configure_init uses /dev/ttyN.conf instead of /dev/ttyN for /etc/init/tty*.conf mangling" [Medium,Fix committed] https://launchpad.net/bugs/438678
<cjwatson> mikefletcher_: sorry about the fix being incomplete - the more complete fix will land right after beta, we didn't have time to squeeze it into beta builds
<mikefletcher_> cjwatson: ok thanks! I'll watch 438678 and test after its fixed.
<mikefletcher_> cjwatson: X crashes my pc when the livecd boots.  Is there any other way to get a logged in text console on a livecd?
<cjwatson> only ones very early in weird environments
<cjwatson> well
<cjwatson> you could boot with 'break=casper-bottom' as a kernel argument, then run:
<cjwatson> sed -i 's/basename \$f/& .conf/g' /scripts/casper-bottom/25configure_init
<cjwatson> exit 0
<cjwatson> that ought to fix it
<cjwatson> but you'd have to do that every boot, it's not a great workaround
<mikefletcher_> cjwatson: ok, I will try that.  I just need to setup something to grab x logs after it dies.  Thank you very much.
<davmor2> evand: that's the all new generic wubi's bost bug
<cjwatson> you know, I wonder if http://paste.ubuntu.com/282302/ is the source of some of this wubi trouble too
<cjwatson> nothing handles the loop variable, so --set=loop is pretty odd
<cjwatson> hmm, that said it shouldn't matter
<cjwatson> nah, never mind, that's a red herring, reverting
<cjwatson> evand: would appreciate a new wubi build from updated trunk after beta
<evand> sure thing
<davmor2> evand, cjwatson: what package is most likely to be causing the gdm/kdm respawn issue on ubiquity only installs, like wubi and install from menu?
<cjwatson> davmor2: I don't know yet, but I'm on it
<davmor2> bug 439405
<ubottu> Launchpad bug 439405 in ubuntu "GDM and KDM both respawn at restart from ubiquity only installs" [Undecided,New] https://launchpad.net/bugs/439405
<cjwatson> or I would be if I could reproduce it at the moment
<cjwatson> just assign it to me?
<cjwatson> I think we can put it on ubiquity for the moment, but it may not be that
<CIA-33> ubiquity: cjwatson * r3494 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-33> ubiquity: * GTK frontend:
<CIA-33> ubiquity:  - When switching language, translate other top-level widgets (dialogs)
<CIA-33> ubiquity:  and their children, as well as the main notebook pages.
<lamalex> evand: My comany is being really weird about signing over the IP to that patch, I can't get them to comprehend that it's beneficial for everyone if we don't have to carry it
<lamalex> "BUT IT'S OUR IP. WE CAN'T GIVE IT TO ANOTHER COMPANY"
<evand> no worries
<evand> I understand
<lamalex> still working on it, will let you know if anything changes
<evand> okay
<evand> thanks for the update
<lamalex> np
<CIA-33> ubiquity: evand * r3495 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
<CIA-33> ubiquity: Port fix for return_to_partitioning from the GTK+ frontend to the
<CIA-33> ubiquity: KDE frontend (LP: #439184).
<CIA-33> ubiquity: evand * r3496 ubiquity/debian/ (changelog control):
<CIA-33> ubiquity: Explicitly depend on reiserfsprogs so that we don't have to add it
<CIA-33> ubiquity: to every live seed (LP: #431976).
#ubuntu-installer 2009-10-01
 * evand blinks at https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/289115
<ubottu> Error: This bug is private
<evand> I'm trying to do a pass of all the configure_bootloader bugs.  Some of them are quite interesting.
<evand> if there was any doubt, installing to an SD card seems to work fine
<evand> though I can't find a machine capable of booting from one :)
<cjwatson> evand: bug 289115> there are several squashfs errors before the python backtrace in the log - I think it's a case for a "sorry, mate, your CD's bust" stock reply if you have one lying around
<ubottu> Bug 289115 on http://launchpad.net/bugs/289115 is private
<evand> ah, I missed that in amongst all the NetworkManager noise when I looked last night
<evand> good deal
<evand> thanks cjwatson
<davmor2> cjwatson, evand: is this something similar https://bugs.launchpad.net/ubuntu/+source/casper/+bug/436418 guys gets stdin errors but when I checked yesterday the install was fine.
<ubottu> Launchpad bug 436418 in casper "Installation from USB media fails on Acer Aspire One" [Undecided,New]
<cjwatson> not directly the same thing, certainly
<cjwatson> we get all sorts of bugs that are hardware problems of some kind, though it's not always easy to sort them out
<cjwatson> we nearly missed a genuine serious squashfs bug once because I was automatically dismissing all squashfs errors as hardware problems :-/
<cjwatson> "works with 9.04 but not with alpha 6" doesn't sound easily dismissable as a hardware bug ...
<cjwatson> (especially on USB where you don't have random burn errors)
<cjwatson> it'd be nice if we knew which process was saying "stdin: error 0"
<evand> if memory serves, that appears at least once for me on a perfectly fine iteration of casper.
<evand> but obviously not necessarily the same thing, as you say
 * evand should read logs first more often :-/
<CIA-33> usb-creator: evand * r225 trunk/debian/changelog: releasing version 0.2.8
<CIA-33> usb-creator: evand * r226 trunk/ (debian/changelog usbcreator/install.py):
<CIA-33> usb-creator: Properly catch exceptions around modifying the syslinux
<CIA-33> usb-creator: configuration (LP: #439977).
<rgreening_> yay
<xivulon> davmor2, evand, have noticed 439279
<davmor2> xivulon: Yes I wrote
<davmor2> it
<evand> 0.2.8 was uploaded ages ago, I just forgot to debcommit -r.  It's waiting to be accepted, which will occur after beta.
<xivulon> hmm haven't seen that myself, quite annoying, does it happen often?
<CIA-33> grub-installer: cjwatson * r813 ubuntu/ (debian/changelog grub-installer): Fix typo in fallback case when computing $disc_offered_devfs.
<davmor2> xivulon: nearly every time on kubuntu it fails.  On ubuntu it work 80% of the time but the other 20% needs rebooting at least
<cjwatson> xivulon: I've observed it quite a bit, but it may be because syncio apparently got lost
<cjwatson> also, wubi wasn't passing syncio correctly
<cjwatson> I've fixed both of those in changes queued for post-beta
<cjwatson> evand: I have http://paste.ubuntu.com/282991/ in ~/bin/ubuntu-release
<xivulon> thanks for that, sorry for the trouble
<cjwatson> I don't know if that's all of it. I'm not sure if syncio explains the random hangs I see in the middle of the installer
<cjwatson> I was speculating that we might need to wait for sreadahead to finish, but that could be a total red herring
<xivulon> any such report on the ntfs-3g mailing list?
<evand> cjwatson: neat, thanks!
<cjwatson> I think I'll see how it goes with the new ntfs-3g/wubi and work from there
<cjwatson> xivulon: syncio was always an Ubuntu patch so I don't think it's something upstream should be bothered about
<xivulon> true
<CIA-33> grub-installer: cjwatson * r814 ubuntu/ (debian/changelog grub-installer):
<CIA-33> grub-installer: If /boot is on an MD device and we're using GRUB 2, install GRUB there
<CIA-33> grub-installer: rather than (hd0); GRUB 2 will interpret that as meaning that it needs
<CIA-33> grub-installer: to install to each of the RAID members (LP: #427048).
<xivulon> but if it was a sreadahead / syncio interaction, wouldn't the issue also be present post-install?
<xivulon> well I assume once you install and reboot the test is usually finished...
<xivulon> and why do reboots help? Does it always work when you reboot?
<cjwatson> I mean rebooting to try the installer again
<cjwatson> I haven't made any significant use of the installed system
<cjwatson> in davmor2's failing tests, the installed system was just unbootable because grub was screwed in some way; for example, missing grub.cfg with no indication in the logs that it failed to write grub.cfg (which there *really* should have been)
<cjwatson> that's what made me think syncio might be involved
<xivulon> that seems plausible, I would be surprised though if you have a high failure rate on Kubuntu on first reboot and high (full?) success rate on second reboot
<xivulon> with same syncio settings
<cjwatson> I don't think anyone's managed to measure success rate on second reboot
<cjwatson> it's definitely very intermittent for me
<cjwatson> and davmor2's results seem all but random
<cjwatson> some successes, some failures, not much in the way of rhyme or reason
<cjwatson> we'll see what happens once we know syncio is in place, I guess
<xivulon> ok then, I misinterpreted the bug report
<cjwatson> the fact that partitioning seems to hang sometimes suggests to me that maybe something is hanging on to the disk
<cjwatson> but the fact that I seem entirely unable to switch away from X in wubi impedes investigation
<xivulon> The syncio is only a boot arg so davmor2 should be able to test on kubuntu
<cjwatson> no
<cjwatson> support for it was accidentally removed from ntfs-3g in a merge
<cjwatson> actually during the jaunty cycle, so of course this may not be the whole issue
<cjwatson> I put it back in and there's an upload in the queue for post-beta
<xivulon> hmm could it be that it was moved upstream so that -o sync is enough?
<xivulon> I also removed it in jaunty cycle, and I do not recall if it was an omission during python translation or deliberate because of -o sync
<cjwatson> no, I grepped for the underlying O_SYNC etc. options and there were no matches
<cjwatson> I spoke to the person who merged it, and he wasn't aware of why he'd removed it, and thought it was an accident
<cjwatson> hmm
<cjwatson> that said it may well be that -o sync would be good enough
<cjwatson> but wubi doesn't pass that
<cjwatson> not unless it's on FAT anyway
<cjwatson> so I'm not convinced - at this point we should probably get syncio working again and stick with that
<cjwatson> the fact that other instability is new since jaunty does sort of suggest to me that it might be something to do with upstart doing things in parallel, and sreadahead is a likely candidate for trouble there, but I've had no opportunity to prove this yet
<xivulon> I'll have a quick chat with cking
<cjwatson> I'd like to minimise change *for karmic* even if cking says it's ok; we can make bigger changes for lucid
<cjwatson> we're having so much trouble getting this to work as it is that I think it is important to keep things under control
<xivulon> cjwatson, cking does not remember any relevant change in that respect, so it is likely that it was lost in traslation on my side, and similarly on the ntfs-3g side
<xivulon> so yes adding it back seems the most reasonable path
<CIA-33> apt-setup: cjwatson * r172 ubuntu/ (apt-setup-verify debian/changelog):
<CIA-33> apt-setup: Use debconf-apt-progress for our Ubuntu-specific all-in-one-go 'apt-get
<CIA-33> apt-setup: update' run.
<CIA-33> apt-setup: cjwatson * r173 ubuntu/ (6 files in 3 dirs):
<CIA-33> apt-setup: Re-enable progress bar cancellation. Thanks to debian-installer-utils
<CIA-33> apt-setup: 1.70 and fixes in debconf, it all seems to work fine now (LP: #172879).
<cody-somerville> What does the noprompt boot option do?
<cjwatson> see casper 1.109 changelog
<CIA-33> console-setup: cjwatson * r114 ubuntu/ (Keyboard/ckbcomp debian/changelog):
<CIA-33> console-setup: Forbid Unicode keysyms in the range 0xf000-0xffff, as kbd 1.15-1 rejects
<CIA-33> console-setup: the entire keymap if it contains any keysyms in that range (LP:
<CIA-33> console-setup: #416949).
<cjwatson> AnAnt: ^- told you I'd get round to it eventually ;-)
<CIA-33> console-setup: cjwatson * r115 ubuntu/debian/ (changelog config.proto): Add default codeset/layout/variant for Asturian.
<CIA-33> console-setup: cjwatson * r116 ubuntu/debian/ (changelog config.proto):
<CIA-33> console-setup: * Backport from trunk (Jordi Mallach):
<CIA-33> console-setup:  - Set XKBVARIANT to "cat" for Catalan.
<CIA-33> console-setup: cjwatson * r117 ubuntu/debian/changelog: releasing version 1.34ubuntu3
<CIA-33> console-setup: cjwatson * r118 ubuntu/debian/ (changelog config.proto): Fix backports of Asturian and Catalan changes in 1.34ubuntu3.
<CIA-33> console-setup: cjwatson * r119 ubuntu/debian/changelog: releasing version 1.34ubuntu4
<AnAnt> cjwatson: thanks !
<AnAnt> to be honest, I lost hope
<AnAnt> that you would ever have time for it
<cjwatson> that'll teach you a lesson then ;-)
<CarlFK> cjwatson:    bug 439456  "missing nic firmware" I mentioned yesterday.  is this something you can decide on and make happen?
<ubottu> Launchpad bug 439456 in linux "netboot e100/d101m_ucode.bin not found" [Undecided,New] https://launchpad.net/bugs/439456
<cjwatson> CarlFK: I'm not a kernel developer - #ubuntu-kernel would probably be a better place to poke
<davmor2> cjwatson: if there  was a fix for the keyboard detection in oem  on the cd's it didn't get past to the dvds
<cjwatson> I don't even know how that was fixed, I think it was luck :)
<cjwatson> I suspect it was in fact not really fixed and you happened not to run across it for some reason, TBH
<CarlFK> cjwatson: will do
<TheMuso> cjwatson: I noticed in the installer for UbuntuStudio, there are still the prompts about the grub command-line for linux/defaults etc. I have also noticed that this is fixed for Ubuntu proper. Do I have to do anything to get rid of these prompts for the studio installer?
<cjwatson> TheMuso: uh, first I've heard of it, can you get me an installation syslog made with DEBCONF_DEBUG=developer on the installer boot command line please?
<TheMuso> cjwatson: Will do as soon as I can.
<CIA-33> apt-setup: cjwatson * r174 ubuntu/debian/changelog: releasing version 1:0.41ubuntu2
<CIA-33> casper: cjwatson * r703 trunk/debian/changelog: releasing version 1.197
#ubuntu-installer 2009-10-02
<Nivex> Good evening.
<shtylman> cjwatson: was that device mapper issue ever resolved?
<Nivex> I'm not able to get the karmic Server beta installer to prompt me for iSCSI target information.
<Nivex> I've just started reading up on how d-i works, so I apologize for not being able to give more than that at the moment.
<Nivex> hmm, partman-iscsi isn't getting loaded (/lib/partman/init.d/40iscsi isn't present)
<Nivex> drat.  I did an "anna-install partman-iscsi" early on, it's getting loaded now, but still no prompt.
<Nivex> evenin' kirkland
<kirkland> howdy
<Nivex> I'm trying to get the iSCSI install working in the Karmic Beta and not having much luck
<cjwatson> Nivex: the way it's supposed to work is that if you don't have any disks, you get that big prompt for drivers - but the very top item in that selection should be "login to iSCSI targets"
<cjwatson> Nivex: you should not need to mess around with anna-install by hand, although good initiative :)
<cjwatson> hmm, that said, let me try to remember what *is* supposed to load partman-iscsi ...
<cjwatson> ah, maybe that is indeed a bug - I think it should be Priority: standard in the archive so that it gets automatically loaded. I'll fix that
<cjwatson> Nivex: try just booting with "anna/choose_modules=partman-iscsi" as a boot parameter, I suspect it'll be happier if it's there from the start
<CIA-33> partman-iscsi: cjwatson * r25 ubuntu/debian/ (changelog control): Change priority to standard to match overrides.
<evand> I picked the wrong day to pull an image off of releases.ubuntu.com.
<CIA-33> usb-creator: evand * r227 trunk/debian/changelog: releasing version 0.2.9
<CIA-33> ubiquity-slideshow-ubuntu: evand * r158 ubiquity-slideshow-ubuntu/ (267 files in 12 dirs): Updated translations from Launchpad.
<CIA-33> ubiquity-slideshow-ubuntu: evand * r159 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 8
<Nivex> cjwatson: I added the "anna/choose_modules=partman-iscsi" boot parameter and still no joy
<cjwatson> Nivex: right, is there a "login to iSCSI targets" entry at the top of the driver prompt?
<Nivex> Ah, yes, there it is.  I had booted this morning with my dummy hard disk
<Nivex> expecting to see an option in the manual partitioner
<cjwatson> there *should* be one of those two
<cjwatson> err, too
<cjwatson> are you seeing the partitioner but no option, or are you seeing an error before the partitioner starts?
<Nivex> partitioner with no option
<cjwatson> oh, I see
<CIA-33> partman-iscsi: cjwatson * r26 ubuntu/ (choose_partition/iscsi/choices debian/changelog):
<CIA-33> partman-iscsi: Stop checking disk-detect/iscsi/enable before deciding whether to offer
<CIA-33> partman-iscsi: an option in the partitioner, as that template doesn't exist any more.
<cjwatson> that should fix it
<cjwatson> but in the meantime, "login to iSCSI targets" should do the trick
<cjwatson> thanks for your report
<CIA-33> partman-iscsi: cjwatson * r27 ubuntu/debian/changelog: releasing version 3
<Nivex> cool.  Some poor soul in the forums bumped into the same problem an filed LP#435290.  We might want to update that with this discussion.
<cjwatson> I'll close it, thanks
<cjwatson> shame nobody saw that and assigned it to an installer package :(
<Nivex> by folding the iSCSI bits into partman, does this mean the alternate installer will have this support as well as server?
<cjwatson> partman-iscsi isn't on the alternate CD, so no, although netboot will have it
<cjwatson> I didn't think it was a high enough priority for the alternate install CD to justify the CD space
<Nivex> ah ok.  As long as netboot has it, I'm happy :)
<cjwatson> please do let me know if it's still broken after this
<Nivex> Is there a daily spin I can grab?
<cjwatson> should be tomorrow, http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<Nivex> alrighty, I'll check back in tomorrow for the image
<cody-somerville> evand, just ignoring exceptions is not a fix for LP #439977
<ubottu> Launchpad bug 439977 in usb-creator ""Installation failed"" [Undecided,Triaged] https://launchpad.net/bugs/439977
<evand> cody-somerville: apologies, I didn't intend for it to be
<cody-somerville> evand, The change shouldn't have been uploaded.
<evand> I disagree.
<cody-somerville> evand, Now usb-creator will both seem successful and the resulting usb fail to boot alternative images correctly.
<evand> It fixed a bug.  It didn't fix your exact bug, but it was still an important fix.
<evand> I've seen your mail.  If usb-creator is going to process every .cfg file in that directory, I'd like to look the existing code over to make sure it wont explode in currently unforeseen ways.  I haven't had a chance to do that just yet.
<cody-somerville> evand, All you did was ignore any possible exceptions
<cody-somerville> evand, and you code will throw an exception on every run
<cody-somerville> evand, *your
<evand> It set out to ignore any exceptions around that code to begin with.
<cody-somerville> evand, the syslinux mangling is a critical part of your tool
<cody-somerville> evand, I've provided a patch for this among other things. Why did you not even comment on it instead of ignoring it all together?
<evand> What makes you think it will throw an exception on every run?
<cody-somerville> evand, from my comment: "I've also uncovered another bug in that code. You fail to reset the command variable so a ValueError is thrown since you ask for the index of the command for the previous non-blank line for lines that *are* blank. I'll include the fix in the branch."
<evand> First of all, calm down.  As I said above, I did not ignore your patch.  I just have not had a chance to review the possible implications of it.
<cody-somerville> evand, You misinterpret my text. I am calm. Just asking.
<evand> I saw the bug and your email before you sent the follow up.
<evand> reviewing now
<cody-somerville> evand, thanks. Let me know if there is any problems or you'd prefer I did something differently.
<evand> will do, thanks
<CIA-33> grub-installer: cjwatson * r815 ubuntu/debian/changelog: releasing version 1.43ubuntu4
<rgreening> morning evand
<evand> hello
<rgreening> evand: I assume you'll be at UDS, yes?
 * rgreening got his invite last night
<rgreening> :P
<evand> until they fire me for gross misconduct :)
<evand> congratulations!
<rgreening> muhaha
<rgreening> ty
<rgreening> so, I have 3 blueprints up already
<rgreening> ha
<evand> great
<cjwatson> evand: you have plans in that area? ;-)
<evand> lol
<evand> not yet, no
 * rgreening doesn't see evand doing anything "gross" :)
<evand> cjwatson: looking at bug 438155, would you say it's a bug that loadkeys explodes on UTF data (try `ckbcomp -layout ar | loadkeys -mu`), or is there a better way to get the desired output than the approach frontends/kde_components/Keyboard.py is taking?
<ubottu> Launchpad bug 438155 in ubiquity "ubiquity kde crashes at keyboard when using Arabic" [Undecided,New] https://launchpad.net/bugs/438155
<evand> I'm learning as I go with respect to this, unfortunately
<cjwatson> evand: console-setup 1.34ubuntu3 should fix that, I think?
<cjwatson> we had to cause loadkeys to ignore 0xf000-0xffff, since the kernel doesn't consider them Unicode (personally I think the ignoring went a little far in completely bailing out of the whole keymap, but hey)
<cjwatson> and console-setup hadn't been updated to account for that
<evand> ahh
<davmor2> rgreening: You don't know evand ;)
<rgreening> bwahaha
<cjwatson> evand: not absolutely certain it fixes that bug, since I was working on something else, but it sounds pretty similar
 * rgreening thinks evand will have to come with the kubuntu team to medieval times in Dallas :P
<evand> indeed, sounds like it.  I'll confirm just as soon as my modem realizes it's not rated at 28800 bps.
<evand> rgreening: there's a medieval times in Dallas?
<evand> I've been to the one in New Jersey a few times
<evand> but not for about 15 years.
<rgreening> heh
<superm1> it's fun to do at least once in your life
<superm1> 've done the chicago one before
<rgreening> evand: boo.. I just got a PFO from Canonical regardingthat foundations job...
<rgreening> hah. their loss
<evand> rgreening: sorry to hear that
<rgreening> no odds... Im sure they couldn't afford me :)
<evand> :)
<rgreening> haha
<cjwatson> I don't think that's personal, the opening just closed AIUI
<rgreening> AIUI?
<evand> as I understand it
<rgreening> doh
<rgreening> hah
<rgreening> no hard feelings here.. :)
<rgreening> I applied as it would be beneficial to them more than me :) I already have a great job with a national telco and I run an entire region :)
 * rgreening likes to toot his horn all too often ... just kick me at UDS :P
<evand> haha
<evand> cody-somerville: I haven't forgotten about your merge, the kernel just hates my usb disk or my usb disk hates data, and is taking ages to write to.
 * evand out for a while
<cody-somerville> :)
<rgreening> evand: 0.2.9... almost at 0.3.0... haha
<rgreening> evand: looks like we may need a 0.3.0 soon :)   bug 440719
<ubottu> Launchpad bug 440719 in usb-creator "usb-creator-kde crashed with UnicodeEncodeError in add_file_source_dialog()" [High,Triaged] https://launchpad.net/bugs/440719
<rgreening> need to fix using str cast to utf8 cast instead.. my bad on that.
#ubuntu-installer 2009-10-03
<xivulon> done another installation and all looks good as far as I can see, did anyone experience any issue with 439279 post beta?
<xivulon> cjwatson, it would be nice if we could hide the grub menu in a wubi installation as discussed some time ago'
<Nivex> diskless iSCSI install seemed to work OK.  couldn't test boot since gpxe isn't playing nice with my VM
<Nivex> logging in to iSCSI targets from the manual partitioner with a disk present doesn't work.  I'll be filing a bug on that soon.
<cjwatson> ok, please attach the syslog when you do
<Nivex> done.  LP#441690
<cjwatson> thanks
<CIA-33> partman-iscsi: cjwatson * r28 ubuntu/ (choose_partition/iscsi/do_option debian/changelog): Source /lib/partman/lib/base.sh as well as iscsi-base.sh.
<cjwatson> fixed one of the problems evident in your log but I'm a little stumped as to the other; it'll wait until working hours, I guess
<CIA-33> ubiquity: cjwatson * r3497 ubiquity/ (debian/changelog scripts/install.py):
<CIA-33> ubiquity: Install a dummy initctl similar to the dummy start-stop-daemon while
<CIA-33> ubiquity: doing anything that might install or remove packages in the target
<CIA-33> ubiquity: system, so that attempts to control Upstart jobs won't do anything.
<CIA-33> partman-target: cjwatson * r774 ubuntu/ (17 files in 3 dirs): merge from Debian 64
<komputes> How come I cannot translate ubiquity? https://edge.launchpad.net/ubiquity
#ubuntu-installer 2009-10-04
<cjwatson> https://translations.launchpad.net/ubuntu/karmic/+source/ubiquity
<jimp> What's the status of Ubuntu on the PS3?  Is that expected to work in Karmic?
<jimp> I seem to have a hard time geting the installer to go very far, I'm presuming lack of RAM is the biggest issue.
<jimp> The netboot installer seems to be working pretty well.
<sweettie79> hello everyone
<CIA-33> partman-target: cjwatson * r775 ubuntu/debian/changelog: releasing version 64ubuntu1
#ubuntu-installer 2010-10-04
<CIA-28> apt-setup: cjwatson * r193 ubuntu/debian/ (apt-mirror-setup.templates-ubuntu changelog):
<CIA-28> apt-setup: Default apt-setup/extras to false; it will be preseeded to true on
<CIA-28> apt-setup: desktop images (LP: #653200).
<CIA-28> apt-setup: cjwatson * r194 ubuntu/debian/changelog: releasing version 1:0.45ubuntu3
<CIA-28> user-setup: cjwatson * r226 ubuntu/ (debian/changelog user-setup-apply): Fix syntax error introduced in 1.28ubuntu9.
<CIA-28> user-setup: cjwatson * r227 ubuntu/debian/changelog: releasing version 1.28ubuntu10
<charlie-tca> Todays alternate image does not create the user
<cjwatson> known and fixed
<cjwatson> user-setup 1.28ubuntu10
<charlie-tca> Thanks
<cjwatson> charlie-tca: fixed Ubuntu alternate image up now
<charlie-tca> Happens in Xubuntu alternate and live cd's too
<cjwatson> yeah, I'm not going to rebuild them all by hand sorry, tomorrow's daily builds will pick up the fix
<charlie-tca> That's fine. Thanks
<cjwatson> oh well, I guess I can, Xubuntu alternate/desktop rebuilding
<cjwatson> ev: could you roll a new build of wubi?
<cjwatson> ev: any luck with that ubiquity grub device default bug?
<superm1> is there a bug opened for the ubiquity grub default device?
<cjwatson> yes, but the number escapes me right now
<cjwatson> something about installations to USB installing to the internal hard disk
<superm1> bug 630529 perhaps?
<ubot2> Launchpad bug 630529 in ubiquity (Ubuntu) "Installing from USB drive writes boot sector to USB not HDD (affects: 1) (heat: 6)" [High,Incomplete] https://launchpad.net/bugs/630529
<cjwatson> sounds plausisble
<cjwatson> -s
<Colten> I'm trying to instal unbuntu 10.04.1 on my computer and I've run into a problem.  When installing, it gets to the point "NET: Registered protocol family 1" and then stops.  It passes protocol family 2 just above it and I had to turn off acpi from the boot options, if that's relevant.
<cody-somerville> What package contains the dumpet command?
<superm1> http://ftp-master.debian.org/new/dumpet_2.1-1.html
#ubuntu-installer 2010-10-05
<ev> cjwatson: unable to reproduce it thusfar
<ev> rolling a new wubi now
<ev> done
<cjwatson> ta
<bobba> Hi - I've tried to replace the kernel on the install CD, and when booting I get an error "can't open /scripts/casper" .  I was wondering if anyone could point me at something I might have done wrong?
<bobba> (I was trying to follow https://help.ubuntu.com/community/LiveCDCustomization to replace the kernel)
<CIA-28> grub-installer: cjwatson * r869 ubuntu/ (debian/changelog grub-installer):
<CIA-28> grub-installer: Install GRUB to the SATA RAID or multipath device when /boot is on such
<CIA-28> grub-installer: a device, rather than installing to the first hard disk (LP: #603854).
<CIA-28> grub-installer: cjwatson * r870 ubuntu/debian/changelog: releasing version 1.55ubuntu4
<CIA-28> debian-installer: cjwatson * r1368 ubuntu/debian/changelog: releasing version 20100211ubuntu29
#ubuntu-installer 2010-10-06
<CIA-28> ubiquity: evand * r4414 trunk/ (d-i/manifest debian/changelog):
<CIA-28> ubiquity: Automatic update of included source packages: apt-setup
<CIA-28> ubiquity: 1:0.45ubuntu3, base-installer 1.107ubuntu3, choose-mirror
<CIA-28> ubiquity: 2.33ubuntu2, grub-installer 1.55ubuntu4, user-setup 1.28ubuntu10.
<CIA-28> ubiquity: evand * r4415 trunk/debian/changelog: releasing version 2.4.6
<CIA-28> ubiquity: cjwatson * r4416 ubiquity/ (debian/changelog ubiquity/misc.py):
<CIA-28> ubiquity: Fix code to ensure that GRUB isn't installed to the installation device
<CIA-28> ubiquity: when it's a USB stick; this was a combination of the installation device
<CIA-28> ubiquity: typically being a partition rather than a disk device, and the fact that
<CIA-28> ubiquity: grub-mkdevicemap now emits /dev/disk/by-id/ names rather than
<CIA-28> ubiquity: traditional device names (LP: #630529).
<CIA-28> ubiquity: cjwatson * r4417 ubiquity/debian/changelog: releasing version 2.4.7
<tjaalton> is it possible to have two keys for the crypted disks, one personal and the other for the admins?
<bladernr> Hey... got a question about the Free Software Only option for installing Maverick.
<bladernr> That should disable ALL restricted repos, correct?
<cjwatson> bladernr: yes
<cjwatson> (I see your bug)
<cjwatson> (rather, I see the bug number, haven't reproduced yet)
<u1106-laptop> is there any special way to report ubiquity bugs observed in Maverick RC?
<bladernr> cjwatson:  cool. thanks.  FWIW, I did the Free Software Only install twice just to be sure I hadn't done something wonky but got the same results both times :/
#ubuntu-installer 2010-10-07
<CIA-28> choose-mirror: cjwatson * r636 ubuntu/debian/ (changelog choose-mirror-bin.templates-in): Set mirror/suite Default to maverick (LP: #656037).
<CIA-28> choose-mirror: cjwatson * r637 ubuntu/ (choose-mirror.c debian/changelog):
<CIA-28> choose-mirror: Accept a mirror/suite default even if the base system is on the CD
<CIA-28> choose-mirror: (workaround for maverick).
<CIA-28> choose-mirror: cjwatson * r638 ubuntu/debian/changelog: releasing version 2.33ubuntu3
<superm1> cjwatson, re bug 656037 doesn't there still need to be a ubiquity task to pull in the newer choose-mirror?
<ubot2> Launchpad bug 656037 in choose-mirror (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/656037
<cjwatson> superm1: ev already uploaded it.  I don't normally bother with explicit ubiquity tasks
<cjwatson> I probably ought to have uploaded d-i based on this, but I don't think this should generally matter for d-i so I'm inclined to skim over that
<superm1> cjwatson, oh okay, i didn't see anything from CIA-28, so i didn't realize that
<cjwatson> I think ev forgot to push
<jussi> heya all, where in the ubquity branch do I find the text for the slides in kubuntu?
<cjwatson> nowhere, it's in ubiquity-slideshow-ubuntu
#ubuntu-installer 2010-10-08
<CIA-28> ubiquity: evand * r4418 trunk/ (d-i/manifest debian/changelog):
<CIA-28> ubiquity: Automatic update of included source packages: apt-setup
<CIA-28> ubiquity: 1:0.45ubuntu4, choose-mirror 2.33ubuntu3.
<CIA-28> ubiquity: cjwatson * r4419 ubiquity/ (debian/changelog scripts/plugininstall.py):
<CIA-28> ubiquity: Log which package (albeit only the first one) caused us to declare
<CIA-28> ubiquity: language support incomplete.
<CIA-28> ubiquity: cjwatson * r4420 ubiquity/scripts/plugininstall.py: say you're happy now, once more with syntax
<CIA-28> ubiquity: cjwatson * r4421 ubiquity/ (debian/changelog ubiquity/plugins/ubi-language.py):
<CIA-28> ubiquity: Initialise release_notes_found in KDE prepare plugin, so that it doesn't
<CIA-28> ubiquity: break in oem-config mode (LP: #656983).
<soren> Slightly on the edge of the channel's topic, but I'm curious if you're aware that installs to XFS filesystems is horrendously slow? dpkg unpack takes /ages/.
#ubuntu-installer 2010-10-09
<cjwatson> soren: blame ext4's requirement to use fsync in order to get safe atomic rename (it's hard to tell whether the filesystem needs this, so dpkg needs to be conservative)
<ev> I thought XFS was agreed to be a Very Bad Thing(tm), no?  The kernel guys were loudly complaining about it the other day.
 * soren has sworn by xfs for at least half a decade. admittedly, yesterday I mostly swore at or about it instead.
<ev> heh
<ev> fair enough
<ev> I'm just content to fanboy the unicorns promised by btrfs
#ubuntu-installer 2010-10-10
<cjwatson> Riddell: I tested wubi on Windows 7 and it worked fine.  There are bugs indicating factors we don't understand, so I can't swear it will work for all Windows 7 users, but it certainly isn't fundamentally incompatible or anything.
<cjwatson> ECHAN
<someguy> Morning, i am trying to run a dualboot (ubuntu 10.4 / win7) on a hw raid10. After following this how to: http://www.howtoforge.com/creating-a-dual-boot-system-on-raid10-ubuntu-windows i am stuck at the ubuntu installer. It does not detect the Swap Partition and says it can not mount swap to none. I tried it several times and didn't find help for that problem in the web.
<CIA-5> ubiquity: evand * r4384 maverick-cleanup/ubiquity/plugin.py: Nevermind that last commit. It feels wrong.
<CIA-5> ubiquity: evand * r4422 trunk/ (40 files in 12 dirs): Merge with the maverick-cleanup branch.
#ubuntu-installer 2011-10-03
<CIA-45> ubiquity-slideshow-ubuntu: cjwatson * r390 ubiquity-slideshow-ubuntu/debian/changelog: changelog for last commit
<CIA-45> ubiquity-slideshow-ubuntu: evand * r391 ubiquity-slideshow-ubuntu/ (381 files in 7 dirs):
<CIA-45> ubiquity-slideshow-ubuntu: Update translations from Launchpad at the request of the Lithuanian
<CIA-45> ubiquity-slideshow-ubuntu: translation team.
<CIA-45> ubiquity-slideshow-ubuntu: evand * r392 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 49
<CIA-45> ubiquity: cjwatson * r5015 trunk/ (3 files in 2 dirs):
<CIA-45> ubiquity: Preserve ordering of disks returned by partman-auto rather than
<CIA-45> ubiquity: shuffling them based on dictionary ordering (LP: #770711). This uses
<CIA-45> ubiquity: collections.OrderedDict, which requires Python >= 2.7.
<infinity> cjwatson: Have I been smoking the good stuff all weekend, or didn't you commit a partman/OrderedDict change already?
<infinity> Hrm.  Maybe you were just discussing it.
<cjwatson> just discussing - I hadn't tested it at that point
<cjwatson> jibel: bug 743359 - have you seen this yourself with 2.8.1?  do you have up-to-date logs?  I couldn't see any logs from 2.8.1 in that bug or its dups
<ubot2> Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359
<cjwatson> jibel: there are reports from beta 2 but that's an earlier version
<jibel> cjwatson, yes I reproduced it this morning. I'll upload the logs
<cjwatson> thanks
 * cjwatson reproduces bug 856418.  How curious
<ubot2> Launchpad bug 856418 in ubiquity "KDE OEM Mode Hang On Shutdown" [High,Incomplete] https://launchpad.net/bugs/856418
 * ev is on bug 769350 - have a solution but looks like my code is interacting poorly with partman, investigating
<ubot2> Launchpad bug 769350 in partman-auto "resized partition size doesn't count swap space size." [High,Triaged] https://launchpad.net/bugs/769350
<ev> ah no, it's just monday morning not using logger correctlyt
<gema_> I had a wiki that had turned into an immutable page... any idea what I may have done wrong?
<cjwatson> you probably got logged out
<gema_> and there goes my Monday morning moment! thanks, cjwatson
<stgraber> ev: going to be poking at ubiquity this week, trying to fix as many milestoned bugs as possible before the sprint. Do you have some in particular you want me to look at or should I just go through the current list?
<ev> hmm
<ev> seeing where we stand with bug 800760 would be good
<ubot2> Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Medium,Confirmed] https://launchpad.net/bugs/800760
<stgraber> ok, I'll start with that then.
<ev> thanks
<cjwatson> bug 830946 just appeared on our milestone list
<ubot2> Launchpad bug 830946 in ubiquity "Nothing displayed on embedded terminal." [Medium,Confirmed] https://launchpad.net/bugs/830946
<ev> really? That's a bit silly. It's a UI nit at best.
<ev> but okay
<cjwatson> jibel: would you like to explain your milestoning?
<CIA-45> ubiquity: cjwatson * r5016 trunk/ (bin/oem-config-prepare debian/changelog):
<CIA-45> ubiquity: Run only those parts of oem-config-prepare that require root access as
<CIA-45> ubiquity: root; in particular displaying confirmation dialogs is now done as the
<CIA-45> ubiquity: calling user, which avoids KDE confusion (LP: #856418).
<cjwatson> ev: I'm happy to dig out APUE and have another crack at bug 743359 if you like
<ubot2> Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359
<ev> please do
<ev> I'm at my wits end with that one
<ev> thanks
<cjwatson> I think you were actually right with the process group idea now that I look at it more closely, but we need to take more care to ensure that update-apt-cache is actually a separate pgrp
<cjwatson> and maybe repeated-retry-for-a-bit-until-dead would be a good idea
<jibel> cjwatson, I milestoned bug 830946 because it is a regression over Natty, has duplicates, clear instructions how to reproduce it and it can not be fixed with a SRU.
<ubot2> Launchpad bug 830946 in ubiquity "Nothing displayed on embedded terminal." [Medium,Confirmed] https://launchpad.net/bugs/830946
<jibel> It is medium importance because it doesn't limit the functionality of a core application.
<cjwatson> As long as you don't mind it being ignored
<cjwatson> (we still have a large High list)
<cjwatson> ev: do you have a copy of APUE, by the way?  bit of a brick of a book, but very useful
<ev> I do!
<ev> I haven't leafed through it in ages though
<ev> should really get back on that
<ev> I really wish there was an ebook version though
<ev> always a pain to have that extra weight in the suitcase for UDS and the sprints
<cjwatson> yeah, I don't carry it
<cjwatson> I think the way I use it (lots of flicking about) would not be very e-book friendly, although searching would be useful
<cjwatson> though OTOH it has excellent contents/indexing
<cjwatson> ev: I guess the probability of encountering this bug goes up the older the image you're using has got
<cjwatson> since 'apt-get upgrade' will take longer
<ev> indeed
<ev> or if, say, you're on fibre to the canonical datacenter
<cjwatson> sadly I only have current images :-)  I'll see if I can fake something up
<cjwatson> for example "drop all outgoing packets" might slow apt-get down enough that copy_all beats it
<ev> heh, nice
<CIA-45> ubiquity: stgraber * r5017 ubiquity/bin/ubiquity-dm: temp
<stgraber> doh, I need to make CIA clever when I do temporary commits ;)
<ev> hah! I'm an idiot
<ev> was wondering why int(value * 1024 * 1024) wasn't working
<ev> beacause that's a rather large string it's turning into an integer
<ev> because*
<cjwatson> d'oh
<ev> I'm blaming that one on it being Monday
<cjwatson> I blame many things on that
<cjwatson> Although it has the disadvantage of being an excuse that only works for 20% of the working week.  Blaming things on there being a 'y' in the day works better.
<ev> lol
<cjwatson> boo, that doesn't work because apt-get update isn't pointed at /target/var/cache/apt
<cjwatson> maybe if I stick the iptables between update and upgrade ...
<bdmurray> Have you all seen bug 825238?
<ubot2> Launchpad bug 825238 in casper "screen reader does not start in a11y installation" [High,Confirmed] https://launchpad.net/bugs/825238
<bdmurray> translation bugs, bug 838141, don't require a ubiquity task correct?
<ubot2> Launchpad bug 838141 in ubiquity "English strings in Swedish translation" [Undecided,New] https://launchpad.net/bugs/838141
<ev> I could definitely use some extra pairs of eyes on the following merges:
<ev> https://code.launchpad.net/~ev/partman-partitioning/save-swap-size/+merge/77970
<ev> https://code.launchpad.net/~ev/ubiquity/factor-swap-in-resize/+merge/77973
<cjwatson> bdmurray: translation> there's only any point in making it ubiquity's problem if the string is untranslatable (i.e. doesn't appear in the pot files)
<bdmurray> cjwatson: okay, thanks
<cjwatson> ok, that seems to reliably reproduce this; nice wide race window
<bdmurray> cjwatson: where does this dialog come from? https://launchpadlibrarian.net/78625495/translation1.png
<cjwatson> bdmurray: console-setup
<cjwatson> bdmurray: that part should be fixed as of 26 Sep though
<cjwatson> yep, installation media from 20110831
<cjwatson> so you should just be able to mark that part as done
<ev> hm, I might have misunderstood which partition min_size and max_size refer to.  Rubbish.
<bdmurray> cjwatson: okay, thanks
<cjwatson> min_size and max_size refer to the partition being resized
<cjwatson> https://code.launchpad.net/~ev/partman-partitioning/save-swap-size/+merge/77970 is entirely full of conflicts, and in any case wanted to be proposed against lp:~ubuntu-core-dev/partman-partitioning/ubuntu not lp:partman-partitioning
<ev> yikes
<ev> will fix
<ev> and indeed
<cjwatson> um, wow, um, complicated
<cjwatson> it's not feasible to have something we call out to from ubiquity directly rather than doing it in the resizing library?
<cjwatson> I can't actually find a bug in it as such, just worried about testing
<cjwatson> 'decode_recipe $(get_recipedir)/[0-9][0-9]atomic linux-swap' is a scary lilne
<cjwatson> *line
<cjwatson> but I guess as long as we make sure it's tested both in d-i and ubiquity ...
<cjwatson> perhaps it would be worth having an NIHed python recipe decoder in P
<cjwatson> although there's some non-trivial logic there; perhaps a wrapper that hides the evil of shelling out
<ev> I just wanted to be sure we weren't hardcoding an assumed swap size
<cjwatson> oh, agreed
<ev> but yes, I suppose something in ubiquity itself would work
<ev> ah
<cjwatson> I guess I was thinking of shipping a tiny script that did . /lib/partman/lib/recipes.sh; decode_recipe blah; echo "$scheme" and then parse its output in a python library
<cjwatson> but this is probably a smaller change for 11.10
<CIA-45> ubiquity: stgraber * r5017 ubiquity/ (bin/ubiquity-dm debian/changelog): Update ubiquity-dm to set gsettings keys instead of gconf
<stgraber> ev: ^ that bit is just for ubiquity-dm. The code seems to "work" here (when copy/pasted and ran separately) but I didn't try ubiquity-dm itself
<cjwatson> does that need a bug closure in the changelog?
<stgraber> I didn't include the bug closure because the bug includes quite a bit more than just ubiquity-dm. I'll now be working on the others.
<cjwatson> ok
<stgraber> bug 800760
<ubot2> Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Medium,Confirmed] https://launchpad.net/bugs/800760
<CIA-45> ubiquity: cjwatson * r5018 trunk/ (debian/changelog scripts/install.py scripts/update-apt-cache):
<CIA-45> ubiquity: Go back to killing update-apt-cache's process group, but this time make
<CIA-45> ubiquity: sure that it's in a separate process group and make more of an effort to
<CIA-45> ubiquity: ensure that it terminates (LP: #743359).
<cjwatson> ev: ^- a double-check of that wouldn't hurt, though it passes my torture test now and I watched it killing the process group
<ev> cjwatson: will do.  About to head out to the cinema with some millbank folk, but I'll have a look first thing in the morning
<ev> as I also fix up these merge proposals
<cjwatson> I think I may be mostly out of steam for today, but should I do an upload?
<stgraber> ev: in plugininstall.py the code won't work with current NM. Should I port it to the new NM or just drop it (no longer using gconf + gnome-keyring but instead ini files in /etc/NetworkManager/system-connections)?
<cjwatson> max testing time and all that
<stgraber> ev: should be fairly trivial to change (copytree of /etc/NetworkManager/system-connections should do the trick)
<stgraber> cjwatson: I'll probably have a few more commits today. I can do an upload when I'm done. When is the deadline to get something in tomorrow's dailies?
<ev> cjwatson: by all means
<ev> stgraber: we definitely still need the functionality
<cjwatson> stgraber: I wouldn't worry about exactness of that
<ev> as the installer now has that wireless page
<ev> but whatever is cheapest, really
<cjwatson> sometime tonight your time should be OK
<cjwatson> I'll do a translation refresh now
<stgraber> ev: ok, I'll replace that code by a simple copytree of all of NM's config then
<ev> brill
<ev> thanks
<stgraber> cjwatson: ok, will upload before leaving the office then
<cjwatson> cool, thanks
<CIA-45> ubiquity: stgraber * r5019 ubiquity/ (debian/changelog scripts/plugininstall.py): Update copy_network_config to work with Network Manager 0.9 storing the configuration system wide
<CIA-45> ubiquity: cjwatson * r5019 trunk/debian/ (changelog real-po/hr.po real-po/sk.po): Update translations from Launchpad.
<cjwatson> um, sorry, I beat you to that, you'll need to merge
<cjwatson> (bound branches FTW)
<CIA-45> ubiquity: stgraber * r5020 ubiquity/ (debian/changelog scripts/plugininstall.py): Update copy_network_config to work with Network Manager 0.9 storing the configuration system wide
<cjwatson> or uncommit/recommit, fair enough :)
<stgraber> merging easily gets messy, uncommit/recommit is easy when it's only one commit, gets tricky when it's multiple including multiple changes to the same file
 * cjwatson is out of steam.  See you later
<CIA-45> ubiquity: stgraber * r5021 ubiquity/ubiquity/gsettings.py: Add initial implementation of gsettings module
<CIA-45> ubiquity: stgraber * r5022 ubiquity/bin/ubiquity-dm: Port ubiquity-dm to the new gsettings module
<stgraber> ok, now that I have that gsettings module, porting the rest of the code should be pretty easy
<CIA-45> ubiquity: stgraber * r5023 ubiquity/ubiquity/components/apt_setup.py: Port apt_setup proxy configuration to gsettings
<stgraber> ouch, gtk_ui.py is going to be fun to switch to gsettings...
<CIA-45> ubiquity: stgraber * r5024 ubiquity/ubiquity/gsettings.py: If SUDO_USER is set, use that for gsettings by default
<CIA-45> ubiquity: stgraber * r5025 ubiquity/ubiquity/frontend/gtk_ui.py: Switch gtk_ui from gconf to gsettings
<infinity> Ugh.  This anacron thing is killing me. :/
<CIA-45> ubiquity: stgraber * r5026 ubiquity/ubiquity/misc.py: Add a note that we need to convert misc.py to gconf (currently not needed as the function is disabled)
<infinity> And I realised that just touching stamp files probably won't help, since it's already running by the time the installer launches, and the delay is ticking.
<infinity> I'm at the point where I'm considering just stopping anacron and cron before the install, and starting it/them at the end.
<infinity> Or maybe changing the default cron.daily delay from 5 minutes to an hour or something...
<infinity> Or make the apt update cronjob exit if [ -x /usr/bin/ubiquity ] ... How evil would that be? :P
<CIA-45> ubiquity: stgraber * r5027 ubiquity/debian/changelog: Update changelog
<stgraber> ok, there we go for gsettings. Now the fun part, testing all of that...
<stgraber> going to run 2-3 test installs trying to stress test the changes, if that works I'll upload to the queue
<infinity> Any brilliant thoughts on my cron.daily-during-install headaches? :)
<stgraber> checking for oem-config/ubiquity would definitely be the easiest way to fix your use case with minimal impact to other ways of installing Ubuntu
<stgraber> though I think it'd be good for everyone not to have these start on first boot
<infinity> Hrm.
<infinity>        -u, --update
<infinity>               incremental  update, reindexing only those packages whose version has changed since
<infinity>               the last run
<infinity> ^-- Note that the call in cron.daily doesn't use -u
<infinity> I wonder if this would make things significantly happier..
<stgraber> oh, interesting, would probably be a good idea to poke mvo to confirm that -u does what it's supposed to and check that we can indeed use it in the cron
<stgraber> but that sounds like a good solution both for the first boot usecase and for the "this cron job takes hours to run" problem :)
<infinity> Testing to see if it actually matters in practice.
<infinity> It might just be I/O bound on writing the massive DB regardless.
<infinity> Hrm, no, -u does seem to be significantly faster.
<infinity> And you'd think it was introduced for just this use case. :P
<infinity> If only mvo was around.
<superm1> infinity, you have casper in your ubiquity setup no?  how about nuking the job from casper?
<infinity> No casper, no.
<infinity> We have jasper, which doesn't do anything on second boot.  (It resizes the root fs, massages some stuff on the filesystem, then reboots into oem-config)
<infinity> Could add some code to run on second boot, though, we don't remove it until later.
<infinity> Seems unpleasant, however.
<infinity> And I don't want this to be ARM-specific.
<infinity> That said, '-u' seems to make a HUGE difference here.
<infinity> Next test is to alter an install image with -u and see if my timeouts go away.
<infinity> (PS: dbus timeouts killing installer processes is a pretty awful failure mode)
<superm1> i feel like there really shouldn't be any cron jobs allowed to really run during install or during oem-config
<infinity> Yeah, I'm inclined to agree.
<infinity> And stopping anacron/cron at the beginning of the install and starting them at the end does sound sane.
<superm1> so maybe it's better to tell ubiquity to stop it / restart it
<superm1> yeah
<infinity> So, 42s for -u, 346s without.
<infinity> I have a feeling this should be done anyway. :P
<CIA-45> ubiquity: stgraber * r5028 ubiquity/ubiquity/ (frontend/gtk_ui.py gsettings.py): Fix obvious mistakes found by pyflakes
<infinity> So, some sort of disable_cron() called from main, right after acquire_lock(), and an atext.register(enable_cron)
<infinity> This might not be that ugly.
<infinity> I'm assuming there are no python upstart bits, I probably just need to fork shells?
<infinity> apt-cache search upstart python seems to agree.
<superm1> well actually it looks like anacron is disabled for a standard ubiquity install already to me
<superm1> there is some code in casper's 25configure_init to do it
<stgraber> you can control upstart over dbus, but subprocess.Popen is going to be a lot easier :)
<infinity> superm1: Ahh, but that's in casper.  It should be in the installer itself, methinks.
<stgraber> well, if you just use the live environment and don't start ubiquity, you still don't want xapian update running as it's going to eat your memory (aufs) for no good reason
<superm1> but you also don't want cron being mean in oem-config, so maybe needs to be both then
<infinity> It completey diverts anacron?
<superm1> yeah
<superm1> another way to solve it then is to divert during oem-config-prepare
<infinity> What un-diverts them?
<stgraber> probably nothing
<superm1> nothing needs to, it's only effective in the live environment
<infinity> Oh, bleh.
<infinity> Right.
<infinity> Not the case for me.
<infinity> My live == My installed system.
<stgraber> yeah, PPA build of ubiquity succeeded!
<stgraber> now to wait 2 hours to get the i386 one and be able to do some tests :)
<stgraber> oh actually, just having ubiquity and ubiquity-frontend-gtk may be enough for my tests
<CIA-45> ubiquity: stgraber * r5029 ubiquity/ubiquity/gsettings.py: Convert booleans before giving them to subprocess
<stgraber> interesting, apparently we can't hide "suspend" from the session indicator...
<stgraber> so during install the user can still suspend the machine. I guess it's still better than shutdown or reboot though :)
<stgraber> infinity: planning on pushing some changes to ubiquity in the next hour or can I upload it?
<infinity> stgraber: No, go to town.
<CIA-45> ubiquity: stgraber * r5030 ubiquity/debian/changelog: releasing version 2.8.2
<infinity> stgraber: I need to talk to mvo tonight when he gets in to work.
<CIA-45> ubiquity: stgraber * r5031 ubiquity/scripts/plugininstall.py: Skip LTSP live when copying network to the target
<Guest45434> cjwatson: ping, do you think its possible to get one last d-i upload to boost the size of the OMAP4 images?
<infinity> Guest61019: Commit fix, upload, ask forgiveness?
<infinity> Guest61019: It'll end up being me or Colin that reviews it anyway. :P
<Guest61019> infinity: k
<cjwatson> NCommand1r: go ahead
<cjwatson> NCommand1r: actually
<cjwatson> NCommand1r: could you just commit but not upload?  if you're going to do that, I'd like to refresh translations in the same upload
<cjwatson> NCommand1r: and I have the scripts for that
<NCommand1r> cjwatson: sure, I'll commit in about an hour or so (network here is going about the same speed as a tortise)
<cjwatson> NCommand1r: I'll commit the translations before that, then, and you can upload
<cjwatson> I'll be in bed in an hour
<NCommand1r> k
<NCommand1r> k
<cjwatson> just awaiting the tarball now
<CIA-45> debian-installer: cjwatson * r1546 ubuntu/ (3 files in 2 dirs): Update help text translations from Launchpad.
<cjwatson> NCommander: ^- there, just make sure to include that
#ubuntu-installer 2011-10-04
<fixxxermet> Are there any books out which detail use of cobbler (orchestra) in the datacenter for large-scale system deployment?
<ev> fixxxermet: entirely wrong channel for that question. Try #ubuntu-server
<fixxxermet> ev: thanks
<ev> sure thing!
<ev> good luck
<fixxxermet> hmm, my boss is idling in there.
<ogra_> if you dont get along with the installer chapter in that book and find a bug, please come back though :)
<stgraber> good morning
<stgraber> ev: hey! While working on the gsettings changes yesterday, I noticed that prepare() in apt_setup doesn't seem to be called/used during install, at least looking at all the gsettings keys being accessed I couldn't find any access to the HTTP proxy keys
<stgraber> ev: do you know if that part of the code is supposed to work/be used and what exactly uses it so I can test that the HTTP proxy stuff actually works
<cjwatson> .prepare should be called from FilteredCommand
<ev> indeed
<cjwatson> I would be astonished if it weren't called, because it's the thing that defines what command is called
<cjwatson> if it weren't called then it wouldn't work at all
<cjwatson> check that there aren't import failure exceptions or something?
<stgraber> I'll be doing some more tests once I'm done zsyncing today's daily and add some debug to both the gsettings module and apt_setup.py itself
<CIA-45> usb-creator: cjwatson * r359 trunk/debian/ (changelog rules):
<CIA-45> usb-creator: Build with dh_translations, to localize the .policy file at runtime.
<CIA-45> usb-creator: LP: #853227
<CIA-45> usb-creator: cjwatson * r360 trunk/debian/ (changelog control):
<CIA-45> usb-creator: Build-depend on dh-translations and bump required debhelper version, to
<CIA-45> usb-creator: support previous change.
<ev> thanks for that
<CIA-45> ubiquity: stgraber * r5032 ubiquity/debian/changelog: Update changelog
<CIA-45> usb-creator: cjwatson * r361 trunk/debian/changelog: releasing version 0.2.34
<stgraber> ev, cjwatson: Just did an install using today's daily with apt_setup.py set to print something at the beginning of prepare() and at the beginning of the gsettings function + patched gsettings to print every key that's read or modified. I see all of the usual keys being accessed/changes but no reference to the proxy stuff...
<stgraber> and no import/stacktrace errors in the debug log
<cjwatson> what is mirror/http/proxy set to?
<stgraber> oh, interesting, it's actually set to http://http://172.21.20.1:3128 which seems to indicate that the code worked (though logging didn't)
<stgraber> well "worked", that value is invalid but at least it's set to something :)
<CIA-45> ubiquity: stgraber * r5033 ubiquity/ (debian/changelog ubiquity/components/apt_setup.py): Fix PROXY url as the gsettings host key already contains http://
<cjwatson> is it guaranteed to contain http:// ?
<cjwatson> I wonder if it would be worth e.g. adding http:// only if it didn't contain a colon, or something
<stgraber> I guess it'd be safer indeed. It seems to always start with http:// on my systems, but there's no clear specification on it that I could find.
<stgraber> cjwatson: I'm going to use .startswith("http://") and if it doesn't, then prepend it. This should take care of the case where we get an IPv6
 * cjwatson nods
<cjwatson> (should've thought of that :-) )
<CIA-45> ubiquity: stgraber * r5034 ubiquity/ubiquity/components/apt_setup.py: Make sure that the proxy host starts with http://, if it doesn't then prepend it
<stgraber> now to finally fix bug 657086 :)
<ubot2> Launchpad bug 657086 in ubiquity "No restart option after choosing to "Continue Testing"" [High,Won't fix] https://launchpad.net/bugs/657086
<stgraber> ev: stealing that one from you ^
<ev> by all means
<ev> :)
<ev> trying to finish off that resize considering swap set of patches, keep getting pulled into other things :-/
<CIA-45> ubiquity: stgraber * r5035 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): Fix gtk_ui to only set the gsettings keys once as for some reason these functions seem to be called multiple times...
<stgraber> and that's bug 657086 fixed (at least it disappeared here :))
<ubot2> Launchpad bug 657086 in ubiquity "No restart option after choosing to "Continue Testing"" [High,Won't fix] https://launchpad.net/bugs/657086
<cjwatson> yay
<stgraber> still wondering why these functions get called multiple times though, that'd be the real bug though making sure a key can only be changed once is still a good thing to check...
<stgraber> ev: looking at bug 651932. Should we also make the "Install this third-party software" option depend on network being available? (looking at the code, this seems to install ubuntu-restricted-addons which isn't on the CD)
<ubot2> Launchpad bug 651932 in ubuntu-release-notes "Without internet connection, the installer shouldn't recommend the updates during installation, or third party software" [Undecided,Fix released] https://launchpad.net/bugs/651932
<superm1> stgraber, doesn't it also call jockey to install wireless drivers (which are in the pool)?
<cyphermox> ev: I noticed if I'm connected to wired and try to connect to wireless in the installer, I can never click "Continue", the button remains "Connect". I'm under the impression that's because the code is checking for what the default connection is, rather than just what's active for a particular device
<cyphermox> is this already reported as a bug?
<ev> cyphermox: not to my knowledge.  Please file one and assign it to me, providing as much details on the steps needed to reproduce as possible
<cyphermox> sure
<ev> do make sure you're using the latest version too.  Newer versions of ubiquity should skip the wireless page entirely if you're on wired ethernet
<ev> assuming you can see the Interwebs
<stgraber> superm1: it could be, but then the description is going to be inaccurate on systems that run without internet connectivity (as the description doesn't mention drivers but only MP3 support)
<cyphermox> ev: then i'm most likely not using the latest version; I was using 20111004 livecd.
<ev> mm, that should have it
<ev> perhaps there's a bug there
<stgraber> cyphermox: that should be ubiquity 2.8.2
<cyphermox> yu[
<cyphermox> *yup
<stgraber> ok, I didn't commit anything related to network/wireless after that release, so any network/wireless problem you see will also happen with trunk
<cyphermox> in the live session I can't seem to get back to the wireless page, just a second
<cyphermox> and I no longer get to the wireless page, as expected
<stgraber> superm1: ok, that was just me not reading properly ;) so indeed the UI says it's both drivers + addons. Drivers are on the CD, addons aren't. I'll quickly make sure we can still install with that option selected when internet isn't available.
<stgraber> superm1: if that's the case I'll just mention it in the bug and close it as the download updates part has been fixed
<cyphermox> stgraber: seems it's just because NM might be slow to establish the connection. If the connection is established to wired before the welcome dialog pops up, the wireless page is skipped, otherwise you'll get to it
 * cjwatson tries to disentangle LANG vs. LC_* logic from language-selector
<cjwatson> y'all should speak English
<ev> Is that British English or English?
<cjwatson> yes
<ogra_> lol
<ev> well played :)
<charlie-tca> Xubuntu has a problem with ubiquity crashing on today's desktop image - bug 867620
<ubot2> Launchpad bug 867620 in ubiquity "Xubuntu failed to install, Ubiquity crashed" [Undecided,New] https://launchpad.net/bugs/867620
<charlie-tca> I can confirm that is crashes a few minutes after entering name/password/etc
<charlie-tca> Do you need a ubiquity --debug for this?
<cjwatson> stgraber: ^- that looks like yours
<ev> okay, I've created https://code.launchpad.net/~ev/partman-partitioning/save-swap-size-real/+merge/78122 and updated https://code.launchpad.net/~ev/ubiquity/factor-swap-in-resize/+merge/77973 for the resize fix
<charlie-tca> If it helps, the Xubuntu desktop images shrunk last night by about 9MB
<ev> if I could have another pair of eyes on that before I merge, I'd greatly appreciate it
<stgraber> cjwatson: looking
<ev> also, if anyone has ideas for a fun 5 minute talk on some aspect of automated testing, do sign up: https://wiki.ubuntu.com/UDS-P/TestingInUbuntu
<ev> trying to foster knowledge sharing at UDS
<stgraber> charlie-tca: I'll have a fix in the next ubiquity, do you want me to paste you a workaround too?
<charlie-tca> no, we can wait. Will that be in tomorrows images?
<stgraber> I think so, we'll probably have enough changes in ubiquity for a release later today
<charlie-tca> Great! Thank you
<charlie-tca> If we are looking at Friday to start smoke testing the final images, we need to make sure they work
<charlie-tca> Does this crash have anything to do with http://cdimages.ubuntu.com/xubuntu/daily-live/ being our of sync?
<charlie-tca> Xubuntu current is dated 2011-10-04, but the listings only show 2011-10-03 and 2011-10-02
<charlie-tca> Never mind; browser refresh fixes that
<cjwatson> ubiquity crashes wouldn't affect CD builds anyway, no
<charlie-tca> Thank you
<CIA-45> ubiquity: stgraber * r5036 ubiquity/ (debian/changelog ubiquity/gsettings.py): Better handle the case where a gsettings key isn't set.
<CIA-45> ubiquity: stgraber * r5037 ubiquity/ (debian/changelog ubiquity/components/apt_setup.py): Don't crash when the PROXY ignore-hosts list is empty
<stgraber> charlie-tca: ^ there you go
<stgraber> charlie-tca: I'll do a quick test install of xubuntu to make sure we don't get some other gsettings weirdness as XFCE uses gsettings but doesn't seem to completely share the schema with gnome
<charlie-tca> Okay, thank you
<stgraber> I'll start poking at bug 813065 while Xubuntu downloads
<ubot2> Launchpad bug 813065 in casper "Live session switches to VT console briefly" [High,Confirmed] https://launchpad.net/bugs/813065
<CIA-45> ubiquity: stgraber * r5038 ubiquity/ (bin/ubiquity-dm debian/changelog): Clear the console just before killing X in ubiquity-dm, this should give us a blank screen while waiting for lightdm to start.
<bdmurray> can the ubiquity task in bug 855042 be closed?
<ubot2> Launchpad bug 855042 in ubiquity "ubiquity hangs while jockey-text at 100% CPU" [High,Confirmed] https://launchpad.net/bugs/855042
<stgraber> charlie-tca: good thing I tested or tomorrow's Xubuntu build would have failed just a line after today's ;)
<charlie-tca> Wow!
<charlie-tca> This is not a good time for those to fail, either.
<stgraber> yeah, just making sure I can install xubuntu i386 + boot it, then I'll commit what I have so tomorrow's ubiquity at least lets you install :)
<charlie-tca> Thank you for being persistent
<stgraber> I'll also do a quick test install of kubuntu just to make sure I didn't mess up anything there with my gsettings changes
<CIA-45> ubiquity: stgraber * r5039 ubiquity/ubiquity/components/apt_setup.py: One more fix to apt_setup to skip proxy config also if gsettings returns None
<stgraber> charlie-tca: xubuntu installs with current trunk (at least on i386)
<charlie-tca> That works for me
<charlie-tca> stgraber: you do know I will whine tomorrow if amd64 fails, right ;)
<charlie-tca> I suspect if i386 works, amd64 will also, though.
<stgraber> I'm sure you will :)
<stgraber> though all the changes I did applied to the python code, so pretty unlikely to be arch specific :)
<charlie-tca> That was my thought too.
<stgraber> cjwatson, ev, infinity: Ok, so current ubiquity trunk fixes quite a few bugs and has been tested on ubuntu, xubuntu and kubuntu. Any of you planning on pushing changes in the next hour or can I upload what we have?
<stgraber> I'd like to have it uploaded soonish so it makes it to the next Edubuntu daily build (one of the first ones to build apparently)
<CIA-45> ubiquity: stgraber * r5040 ubiquity/bin/ubiquity-dm: Update comment in ubiquity-dm (s/upstart messages/boot-time messages/g)
<cjwatson> stgraber: go ahead, I still need to fix up some locale handling but I'm not going to do that tonight
<cjwatson> stgraber: subprocess.Popen(['clear']) - shouldn't we wait for that to exit to avoid a race condition, i.e. subprocess.call instead?
#ubuntu-installer 2011-10-05
<CIA-45> ubiquity: stgraber * r5041 ubiquity/bin/ubiquity-dm: Make the clear call in ubiquity-dm clear the right tty
<CIA-45> ubiquity: stgraber * r5042 ubiquity/bin/ubiquity-dm: Wait until clear in ubiquity-dm returned
<CIA-45> ubiquity: stgraber * r5043 ubiquity/bin/ubiquity-dm: Don't fail if we can't open the tty
<CIA-45> ubiquity: stgraber * r5044 ubiquity/debian/changelog: releasing version 2.8.3
<CIA-45> ubiquity: evand * r5045 trunk/ (debian/changelog ubiquity/plugins/ubi-console-setup.py):
<CIA-45> ubiquity: Handle the keyboard query window closed callback being fired twice
<CIA-45> ubiquity: (LP: #865493).
<ev> ugh, this is why I need the Ubuntu geonames server set up in a Vagrant configuration: https://bugs.launchpad.net/ubuntu-geonames/+bug/837054
<ubot2> Launchpad bug 837054 in ubuntu-geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Confirmed]
<CIA-45> ubiquity: evand * r5046 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py):
<CIA-45> ubiquity: Allow focusing of labels when we're in the screen reader
<CIA-45> ubiquity: acessibility profile, so that Orca can read them
<CIA-45> ubiquity: (LP: #856782, LP: #856773).
<ev> tried to get the resize widget usable from the keyboard
<ev> but I can't seem to navigate it, even in a simple test application
<ev> using a keyboard that is
<ev> f6 and f8 do nothing
<cjwatson> grr, why is localechooser-apply installed in two places
<cjwatson> wasted an hour of testing time due to that :(
<CIA-45> ubiquity: cjwatson * r5047 trunk/ (4 files in 2 dirs):
<CIA-45> ubiquity: Don't install duplicate copies of console-setup-apply,
<CIA-45> ubiquity: localechooser-apply, and netcfg-wrapper.
<ev> eep
<ev> I'm currently losing time to virtualbox yet again losing the location of my windows 7 disk
<ev> despite it being *right there*
<cjwatson> I'm sure everything would be easier if Simplified and Traditional Chinese had two different language codes
<cjwatson> sigh
<ev> ugh, this definitely appears to be trashed
<cjwatson> argh, why am I getting I/O errors inside kvm
 * cjwatson tries giving it a bit more memory
<ev> :)
<ev> I'm getting "Windows failed to start" using the Windows setup CD
<ev> I don't think today is turning out to be a stellar one for compuing
<ev> computing even
<cjwatson> this is my third try; if this fails I'll have to resort to (shock) real hardware
<ev> hahaha
<Peanut> I am upgrading an install-server, re-using the preseed.cfg for a lucid LTS (previously karmic). As expected, I get a few questions popping up - how can I figure out which d-i entries correspond to the questins that pop up?
<stgraber> argh, just noticed I get "shutdown" and "log out" in the session indicator when installing using ubiquity-dm
<stgraber> I guess I'll have to fix that, seems like I missed it in my tests yesterday
<stgraber> btw, any reason why we even have indicator-session when in install-only mode?
<superm1> is that the same indicator applet that shows you your name?
<superm1> if so, i noticed that during an oem-config run it briefly pops up the "OEM" name too
<ev> stgraber: so they can reboot if they really didn't mean to boot the Ubuntu CD
<stgraber> ev: ah, ok
<CIA-45> ubiquity: evand * r5048 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py):
<CIA-45> ubiquity: Make sure we account for the size of the installation and swap
<CIA-45> ubiquity: partition when calculating the bounds for the partition resizer
<CIA-45> ubiquity: (LP: #769350).
<stgraber> fun, starting a live session, killing lightdm and starting ubiquity-dm makes gsettings work just fine, doesn't help to reproduce the bug though :)
<stgraber> ok, I "think" I found the bug. for some reason we don't have $USER set in the environment when using ubiquity-dm
<stgraber> so ubiquity tries to change the gsettings options for root instead of for the ubuntu user
<CIA-45> ubiquity: stgraber * r5049 ubiquity/ (bin/ubiquity-dm debian/changelog): Update ubiquity-dm to export self.username as SUDO_USER.
<stgraber> ev: that one line should be all that's needed to fix my gsettings bug, release when you want :)
<ev> yay
<ev> just waiting for the publisher
<ev> and while I do, I'll fire up pbuilder
<CIA-45> ubiquity: evand * r5050 trunk/.bzrignore: Update bzrignore.
<ev> just trying to get a working pbuilder build
<ev> the last one curiously segfaulted somewhere in the depths of gettext
<stgraber> ev: found out what made it segfault?
<stgraber> superm1: for bug 868668, is the firewall/router on your network rejecting the connections on tcp/80 or just ignoring them?
<ubot2> Launchpad bug 868668 in ubiquity "Installer hangs when progressing to timezone page for 45 sec" [Undecided,New] https://launchpad.net/bugs/868668
<stgraber> superm1: I'd expect wget to give up quite quickly if it gets reject but the timeout value can be pretty high if it just doesn't get any response
<superm1> stgraber, ignores them
<superm1> it's annoying that DNS resolves though
<stgraber> ok, so would probably be worth tweaking the timeouts in the code a bit so it doesn't take that long
<stgraber> I'll have a quick look at that once I'm done testing Edubuntu
<stgraber> superm1: is it only tcp/80 that's being dropped or everything except 8080 to whatever your proxy server is?
<cjwatson> dropping packets really is rubbish, you should get that fixed
<cjwatson> I consider that hostile firewall design ...
<stgraber> cjwatson: it's unfortunately common :( I've seen that one quite a few company and university networks, though in some cases it's not so much dropping everything as just not having a route to the outside (with the same result)
<superm1> stgraber, everything except local network servers and what the proxy server is
<cjwatson> it's common, but I don't think it should be tolerated when it can be changed
<superm1> and it's the latter where there is no route to the outside really
<cjwatson> BTW I knew the timezone page was slow in this case but did not consider it RC, as most people can still easily complete the questions before ubiquity finishes copying files
<cjwatson> I'm not sure why it's been escalated through oem-priority given that
<superm1> it's more the oem-config scenario that it matters
<cjwatson> ah, I guess that does have a similar problem, yes
<superm1> because testers get to the page and it's hung and bugs get filed
<cjwatson> the fix is probably pretty invasive though
<cjwatson> for oneiric
<superm1> if it's not fixed for oneiric, it might just need to be SOP for oneiric to unplug the cable before going through oem-config or something i guess then
<cjwatson> I'm just trying to think of what a fix would look like
<stgraber> I'm surprised it takes 45s, the code indicates it should take 15s + loading time of the ubiquity page, so let's say 20s maximum
<stgraber> and testing here seems to match that
<cjwatson> 30s for rdate maybe?
<cjwatson> rdate is already wrapped in progresscancel; there's no progress bar on that page, but that means ubiquity at least has a way to cancel it
<cjwatson> the wget is trickier
<cjwatson> we have the connectivity check in the ubiquity frontend, so maybe we could stub out that wget
<stgraber> yeah, that was my plan too, except that I just noticed that the connectivity check is buggy :)
<cjwatson> oh?
<stgraber> it uses --timeout=15 but it's been running for 6 minutes here :)
<cjwatson> !
<cjwatson> it's not just repeatedly running?
<stgraber> same pid
<cjwatson> stubbing out the wget would require either a change in ubiquity, or a compat script
<cjwatson> er, a change in *tzseteup
<cjwatson> can't type, YKWIM
<stgraber> ok, found the problem
<stgraber> we start wget with -T 15 but not with -t 1 for the connectivity check
<stgraber> so it waits 15s per try, with a possibly infinite number of retries
<cjwatson> ah, yes
<cjwatson> default is 20
<stgraber> -t 1 -T 15 is what's being used by tzsetup and probably a good idea of the connectivity test too
<cjwatson> well, allegedly, that would give five minutes though
<cjwatson> agreed
<cjwatson> I think the easiest would be to give ubi-timezone a plugin_set_online_state method so that it gets told about state, and then before it starts the d-i callout it can preseed tzsetup/geoip_server to empty if it doesn't have connectivity
<cjwatson> that will get rid of the wgwet
<cjwatson> and probably simplest to preseed clock-setup/ntp to false as well, which will get rid of the rdate
<cjwatson> slightly brutal but that seems like the least invasive fix
<cjwatson> stgraber: are you OK with doing that?
<CIA-45> ubiquity: stgraber * r5051 ubiquity/ubiquity/ (frontend/base.py plugins/ubi-language.py): Whenever we call wget with a timeout, also set the number of tries to 1 instead of default of 20
<stgraber> cjwatson: yep
<CIA-45> ubiquity: stgraber * r5052 ubiquity/debian/changelog: Update changelog
 * cjwatson fails to understand why ubi-language has its own implementation of check_returncode *and* a plugin_set_online_state method
<cjwatson> oh, it's talking to a different URL
<cjwatson> try:
<cjwatson>     import lsb_release
<cjwatson>     _ver = lsb_release.get_distro_information()['RELEASE']
<cjwatson> except:
<cjwatson>     _ver = '10.10'
<cjwatson> classy
<stgraber> :)
 * cjwatson fixes
<CIA-45> ubiquity: cjwatson * r5053 trunk/ (debian/changelog ubiquity/plugins/ubi-language.py): Bump fallback Ubuntu version number in ubi-language to 11.10.
<stgraber> cjwatson: http://paste.ubuntu.com/703017/
<cjwatson> stgraber: s/thing/think/ in the changelog :)
<cjwatson> stgraber: what happens if we get to the timezone page before the 15 seconds for the initial check have elapsed?
<cjwatson> stgraber: I wonder if maybe we'd be better off initialising self.online = False
<cjwatson> with a TODO comment saying that we can flip this once we have the ability to abort the wget / rdate in progress
<stgraber> well, the way ubiquity seems to work is that it first runs plugin_set_online_state as True if Network Manager says we're online. Then starts the wget in background and sends a False if it timeouts or doesn't match the expected content.
<stgraber> so whatever default we set in ubi-timezone, it'll always be True until wget times out
<cjwatson> hm
<cjwatson> that's awkward then; many users won't take as long as 15 seconds to get past the first page
<stgraber> indeed
<stgraber> we could change the logic to be offline until we get the right content from wget
<stgraber> I personaly think it'd make sense though we need to make sure that server will scale on release day :)
<cjwatson> actually, are you sure?  the network_change stuff only calls set_online_state if False
<cjwatson> I don't see code setting it to True unless it gets a response from wget
<stgraber> I only assumed it was as ubi-prepare always shows I'm connected until wget times out
<stgraber> but maybe it's just the default on ubi-prepare that's wrong too
<cjwatson> yeah, that's just ubi-prepare
<cjwatson> the actual underlying code looks OK
<stgraber> ok, setting self.online to False by default then
<cjwatson> the rest looks fine
<cjwatson> I wish my Chinese handling tests weren't taking forever and a day
<CIA-45> ubiquity: stgraber * r5053 ubiquity/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Don't contact geoip or run rdate if we don't have internet connectivity
<stgraber> cjwatson: should I try to make ubi-prepare consistent with ubi-timezone (as in, not showing you're online when wget is still running)?
<stgraber> argh, forgot to pull again... time to bzr bind that branch :)
<CIA-45> ubiquity: stgraber * r5054 ubiquity/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Don't contact geoip or run rdate if we don't have internet connectivity
<cjwatson> I think leave ubi-prepare alone at this point
<cjwatson> and maybe file a bug
<cjwatson> anyone want to comment on http://paste.ubuntu.com/703026/ and http://paste.ubuntu.com/703027/, for bug 590108?
<ubot2> Launchpad bug 590108 in ubiquity "User get wrong system language after executing oem-config, if he is a foreigner in the country he selected in timezone select stage" [Medium,In progress] https://launchpad.net/bugs/590108
<cjwatson> I've yet to test this all the way through, working on that
<stgraber> the comments make sense, it indeed won't affect anything that's not pt or zh, as for the rest, can't comment much without testing (and I already did my chinese install of the day ;))
<cjwatson> I'm on about my fifth :-/
<cjwatson> I probably could have made it more general but decided it was safest to constraint it
<cjwatson> constrain*
<cjwatson> gah.  coffee.
<cjwatson> I'll go ahead with localechooser - I've tested that at least in d-i
<CIA-45> localechooser: cjwatson * r165 ubuntu/ (debian/changelog post-base-installer.d/05localechooser):
<CIA-45> localechooser: For cases where selecting a different location may imply a different
<CIA-45> localechooser: dialect of the language, i.e. Portuguese and Chinese, take care to set
<CIA-45> localechooser: LANG to something reflecting the location and
<CIA-45> localechooser: LANGUAGE/LC_MESSAGES/LC_CTYPE/LC_COLLATE to something reflecting the
<CIA-45> localechooser: language (LP: #590108). This roughly matches the behaviour of
<CIA-45> localechooser: language-selector.
<cjwatson> and that needs to go ASAP
<CIA-45> localechooser: cjwatson * r166 ubuntu/debian/changelog: releasing version 2.37ubuntu2
<cjwatson> stgraber: so did pbuilder work OK for you or was it just ev?  (or have you tried?)
<stgraber> cjwatson: didn't try. I usually push to a PPA for testing
<cjwatson> I can try it locally now if that would be helpful
<cjwatson> waiting for an install anyway
<cjwatson> running it through now
<stgraber> currently building in a PPA: https://launchpad.net/~stgraber/+archive/experimental/+build/2825494
 * cjwatson requests a ubiquity translations export
<cjwatson> built cleanly here
<cjwatson> ooh, and that looks suspiciously like a correct /etc/default/locale
<cjwatson> now I just have to test oem-config
<stgraber> ubiquity also built fine for both i386 and amd64 on the PPA builders
<CIA-45> ubiquity: cjwatson * r5055 trunk/ (9 files in 3 dirs): Update translations from Launchpad.
#ubuntu-installer 2011-10-06
<ev> Really not sure what was causing that segfault. Will have to dig in the morning.
<ev> Anything I can do to help right now?
<cjwatson> I'm finishing up testing of my pt/zh changes; not sure if stgraber has anything else in progress?
<stgraber> nope, I'm good for the day
<cjwatson> ok, going as fast as I can then
<ev> :)
<stgraber> just ran a test install with the current trunk, installed fine and booted fine, though that's still with the old localechooser and partman-partitioning (forgot to update d-i/source before pushing to my PPA)
<cjwatson> found one minor bug in the oem-config code, tweaking and retesting
<cjwatson> and I've requested a d-i translation tarball since I need to reupload that
<cjwatson> preferably before I pass out
<stgraber> Running a quick test of OEM now to make sure the ubi-timezone appears immediately now
<stgraber> oh, and it obviously won't because I forgot to re-upgrade to the version in my PPA post-install...
<cjwatson> looking better now ...
<stgraber> superm1: confirmed that ubi-timezone shows up after only a second or two with the new ubiquity
<CIA-45> debian-installer: cjwatson * r1548 ubuntu/ (5 files in 2 dirs): Update help text translations from Launchpad.
<CIA-45> ubiquity: cjwatson * r5056 trunk/ (debian/changelog scripts/localechooser-apply scripts/tzsetup):
<CIA-45> ubiquity: For cases where selecting a different location may imply a different
<CIA-45> ubiquity: dialect of the language, i.e. Portuguese and Chinese, take care to set
<CIA-45> ubiquity: LANG to something reflecting the location and
<CIA-45> ubiquity: LANGUAGE/LC_MESSAGES/LC_CTYPE/LC_COLLATE to something reflecting the
<CIA-45> ubiquity: language (LP: #590108). This roughly matches the behaviour of
<CIA-45> ubiquity: language-selector.
<CIA-45> debian-installer: cjwatson * r1549 ubuntu/debian/changelog: releasing version 20101020ubuntu71
<cjwatson> ev,stgraber: shall I go ahead and upload ubiquity then?
<stgraber> yep, everything looks good, go ahead
<CIA-45> ubiquity: cjwatson * r5057 trunk/ (d-i/manifest debian/changelog):
<CIA-45> ubiquity: Automatic update of included source packages: localechooser 2.37ubuntu2,
<CIA-45> ubiquity: partman-partitioning 81ubuntu3.
<cjwatson> ev: it's not critical at all, but FWIW, I think SWAPSIZE is actually in decimal megabytes (as is usual in partman) rather than binary megabytes
<CIA-45> ubiquity: cjwatson * r5058 trunk/debian/changelog: releasing version 2.8.4
<superm1> stgraber, phenomenal thanks!
<ev> cjwatson: okay
<ev> sh
<ev> shall we fork off the release branch from here then?
<ev> and oh happy days! My Windows VM has very randomly decided to work again
<CIA-45> wubi: evand * r238 trunk/ (data/wubildr-disk.cfg debian/changelog): Use the Plymouth splash (LP: #862007).
<ev> neat, I happened upon quite the interesting edge case bug: https://bugs.launchpad.net/wubi/+bug/869014
<ubot2> Launchpad bug 869014 in wubi "OSError: [Errno 22] Invalid argument removing C:\ubuntu\disks\root.disk" [Undecided,New]
<ev> looks like chkdsk is our only recourse there
<cjwatson> ev: release branch> maybe, depends whether you want to get going with stuff for P really
<ev> cjwatson: well I was thinking for the swapsize fix
<ev> to land that on trunk so it's not forgotten
<cjwatson> sure
<ev> cool, will do after I sort these two wubi issues
<cjwatson> ev: should bug 769350 be reassigned and closed?  it looks like it didn't get closed due to source package mismatch
<ubot2> Launchpad bug 769350 in partman-auto "resized partition size doesn't count swap space size." [High,Triaged] https://launchpad.net/bugs/769350
<ev> yes, on it now
<cjwatson> ta
<CIA-45> wubi: evand * r239 trunk/ (4 files in 3 dirs):
<CIA-45> wubi: Handle filesystem corruption when trying to uninstall Wubi
<CIA-45> wubi: (LP: #869014).
<cjwatson> ev: what happened to jibel's cd_path fix in wubi r237.1.1?  r238 doesn't seem to contain it despite merging that revision, and bug 869144
<ubot2> Launchpad bug 869144 in wubi "(Wubi) Global name 'cd_path' is not defined" [Undecided,New] https://launchpad.net/bugs/869144
<cjwatson> in fact all the actual content of 237.1.1 seems missing
 * ev looks
<ev> wow, how on earth did this happen?
<ev> I can see the delta in bzr diff -c
<ev> but you're right - it's just not there
<ev> oh wait a minute
<ev> ahhh
<ev> I did do a bzr revert before committing my other changes, but somehow that doesn't seem to have wiped the merge part
<ev> (I had jibel's code merged in my local branch, but not committed)
<cjwatson> if you do bzr revert with a path it (intentionally) doesn't forget the merge
<cjwatson> so maybe you did bzr revert . or bzr revert src or similar
<cjwatson> (you can do bzr revert --forget-merges, although too late now obviously)
<cjwatson> probably best to just recommit the delta if you want it ...)
<ev> could be
<ev> indeed
<ev> I'm getting his updated changes merged in now
<ev> any idea why vt.handoff would not work in the wubi disk images offhand?
<ev> when I leave it out, everything is happy
<ev> we get a plymouth splash and the system boots
<cjwatson> missing grub modules?
<cjwatson> gfxmode and/or gfxpayload not set in wubi grub.cfg?
<cjwatson> (did it work with the previous image style anyway?)
<ev> ah, I hadn't checked, but that makes sense
<cjwatson> probably worth just pulling out vt.handoff now rather than trying to make it work?
<cjwatson> for 11.10
<CIA-45> wubi: evand * r240 trunk/ (5 files in 4 dirs):
<CIA-45> wubi: * Add support for disk image installation (LP: #859696). Thanks
<CIA-45> wubi:  Jean-Baptiste Lallement!
<CIA-45> wubi: * Correctly define cd_path (LP: #861702).
<ev> cjwatson: indeed, that's the game plan :)
<ev> it hasn't been built on any wubi images anyway
<CIA-45> wubi: evand * r241 trunk/ (data/wubildr-disk.cfg debian/changelog):
<CIA-45> wubi: Drop vt.handoff for 11.10. We'll fix this by including the correct
<CIA-45> wubi: GRUB modules in 12.04.
<ev> now to just give this thing a few more tests and then I'll pass it off to get signed
<ev> http://people.canonical.com/~evand/wubi/oneiric/wubi-r241.exe if you want to play along at home
<sheeparegreat> what is the config option I need to pass to get a seeded install to work in CD install only mode with no networking?  There are some Debian docs saying netcfg/disable but this doesn't seem to be a valid option.
<sheeparegreat> I've tried lots of different options but I cannot get a CD install to go all the way through without halting on an error about connecting to an internet repo
<stgraber> do we have anything scary I can help fixing or should I just continue with my current smoke testing of the images + upgrades?
<ev> I haven't seen anything scary just yet
<ev> shadeslayer: is this a desktop CD or server/alternate CD?
<sheeparegreat> ev: it's the alternative CD for LTS.  I've got a seeds file which works when there are network repos available.  When I install it on a VM with no networking it gives an error.  I'm after the magic to tell the installer to just use the CD and not use the network at all.
#ubuntu-installer 2011-10-07
<jibel> ev, thanks for the review and the merge of wubi.
<jibel> i'll test it this morning.
 * ev tries to figure out how plymouth ends up inside the livecd initramfs
<superm1> ev, casper/conf-hooks.d/casper
<superm1> it declares FRAMEBUFFER=y which pulls in the plymouth initramfs hook
<ev> ahhh, that's the magic rune I was missing
<ev> thanks!
<ev> http://paste.ubuntu.com/703989/plain/ - though I imagine that has to wait for P
<jibel> ev, did you test a wubi installation of kubuntu or xubuntu ?
<ev> not yet
<jibel> ev, ok, will do then.
<ev> cool
<CIA-45> netcfg: cjwatson * r1281 ubuntu/ (debian/changelog netcfg.c): Fix crash when there are no network interfaces (LP: #870212).
<CIA-45> netcfg: cjwatson * r1282 ubuntu/debian/changelog: releasing version 1.68ubuntu7
<stgraber> cjwatson: argh, sorry for that, should have thought of the no network card case...
<cjwatson> so should I when reviewing it ... :-)
#ubuntu-installer 2011-10-08
<CIA-45> debian-installer: cjwatson * r1550 ubuntu/debian/changelog: No-change rebuild to pick up new components.
<CIA-45> debian-installer: cjwatson * r1551 ubuntu/debian/changelog: releasing version 20101020ubuntu72
#ubuntu-installer 2012-10-01
<psivaa> Reported bug 1059403 for quantal server upgrade failures, just in case it has not been noticed
<ubot2> Launchpad bug 1059403 in update-manager "dist-upgrade.py returns 1 due to /var/log/dist-upgrade/* not found in P2Q server upgrades" [Undecided,New] https://launchpad.net/bugs/1059403
<cjwatson> Upgrades => not this channel
<psivaa> cjwatson, ok thanks and apologies :), trying to find the right channel now
<cjwatson> There's no specific channel for upgrades.
<cjwatson> #ubuntu-devel or #ubuntu-release if you don't feel that the standard rls-q-incoming tag is enough.
<psivaa> ahh ok, that bug is tagged rls-q-incoming
<ogra_> xnox, imho bug 1008717 should be closed, if anyone sees it again he can re-open, no need to clutter the buglist with it
<ubot2> Launchpad bug 1008717 in ubiquity-slideshow-ubuntu "Ubiquity displays scrollbars inside of slideshow" [Undecided,Invalid] https://launchpad.net/bugs/1008717
<xnox> ogra_: ok.
 * ogra_ wonders if hggdh actually formatted the device instead of a partition in bug 1028983
<ubot2> Launchpad bug 1028983 in partman-base "armhf-omap4: a disk formatted with ext4 fails to mount with partman" [Medium,Confirmed] https://launchpad.net/bugs/1028983
<ogra_> (i.e. there is no part table but a partition signature at the start of the device ... does partman handle such cases ? )
<cjwatson> In theory, but it's not well-tested and pretty likely to break.
<ogra_> k, i'll ask him about it ... and to worst case attach a dd of the first 1M of the device to the bug if he cant tell
<xnox> cjwatson: I have a VM up with USB passthrough for the bluetooth dongle. lsusb in the VM correctly shows "Camblidge Silicon Radio, Ltd Blueototh Dongle (HCI mode)" and blutoothd started and enabled adapter on /or/bluez/1122/hci0
<xnox> but there is no "bluetooth applet" that I can see or click. and nothing crashed so far.
<cjwatson> I doubt that that bug actually has anything much to do with the hardware anyway
<cjwatson> The crash seems a bit early for that
<cjwatson> Might need to work with psivaa since apparently he can reproduce it ...
<xnox> why do we have bluetooth anyway?
<xnox> for keyboards or sound or both? but I see no UI to pair things up.
<cjwatson> Dunno, grep history
<xnox> ubiquity-dm mode
<xnox> ok
<xnox> 5 minutes later the bluetooth applet got spawned. and it works fine
<xnox> as per documentation.
<psivaa> cjwatson, xnox if this is about bug 1049215, i have not seen that crash lately, but i'll try if i can reproduce and update the bug
<ubot2> Launchpad bug 1049215 in ubiquity "ubiquity-bluetooth-agent crashed with ImportError in /usr/lib/python3/dist-packages/gi/__init__.py: could not import gobject (error was: EOFError('EOF read where not expected',))" [Medium,Incomplete] https://launchpad.net/bugs/1049215
<cjwatson> psivaa: Somebody attached it to an ISO test report from beta-2, apparently
<cjwatson> Otherwise I'd be inclined to discount it as unreproducible
<cjwatson> I assumed that was you
<psivaa> cjwatson, just a sec checking
<psivaa> cjwatson, for beta 2 it was jibel that reproduced this and added the bug to the tracker, i'll see if i could reproduce this
<jibel> I couldn't reproduce this crash. I'd leave it incomplete until it expires or we find a reproducible test case.
<xnox> psivaa: jibel: cool, thanks.
<jibel> xnox, I have a very similar case to bug 1059570, installing to a brand new SSD. Ubiquity is responsive but installation never ends, the last command executed is /usr/share/grub-installer/grub-installer.
<ubot2> Launchpad bug 1059570 in ubiquity "Installation does not finish in 12.10 - ubiquity pause after "ubuntu finish-install: Disabling CD in sources.list"" [Undecided,New] https://launchpad.net/bugs/1059570
<jibel> It's reproducible, I ran an installation in debug mode and will file a new report.
<xnox> hmmm
<xnox> interesting
<jibel> xnox, bug 1059619
<ubot2> Launchpad bug 1059619 in grub-installer "Installation never ends" [Undecided,New] https://launchpad.net/bugs/1059619
 * xnox is actually not sure how the successful logs end. But 100 progress seems like that would be the end.
<stgraber> oh, CIA died again?
<xnox> stgraber: cia.vc is dead forever. debian moved to self-hosted KGB which is in perl and doesn't support bzr.
<xnox> stgraber: I was thinking to add RSS-to-IRC notifications from bzr branches on launchpad. as RSS feeds are provided for all branches.
<stgraber> yeah, that'd work and would also work better when not using bound branches
<stgraber> I could add the feature to queuebot but then it'd really have to be renamed ;)
<xnox> stgraber: I was thinking a new bot with all lp:ubuntu/* branches going to #ubuntu-cia channel & then people could relay interesting branches to other channels as well. ~ cia style
<stgraber> cjwatson: hey there. I got assigned https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-autocreate-preseed for this cycle but don't really have a clear idea of what's needed there exactly (sorry, only got around to that spec now, was pretty low on my todo list...)
<stgraber> xnox: ubuntu/* won't quite work for all the installer branches though, but yeah, having a generic bot that you can poke and get into your channel watching some LP branches would be nice
<cjwatson> stgraber: it's basically a request for a program with a big pile of heuristics to generate a reasonable preseed file from an installed system
<stgraber> xnox: if it's easy, it should probably have its own LP account and subscribe to e-mail notifications for the branches it's interested in, then you'd get proper "push" notifications and don't have to refresh all the RSS feeds every minute or so
<cjwatson> since you can't just use debconf-get-selections --installer - e.g. partman preseeding will be totally wrong, there are a bunch of other things that shouldn't be preseeded, etc.
<stgraber> cjwatson: ok, so essentially write something that takes debconf-get-selections, strips anything that's not actually set to something relevant, get rid of all the partman keys and output a preseed with the result?
<cjwatson> Something like that
<cjwatson> I expect it'll be a big pile of special cases
<cjwatson> Since d-i debconf templates aren't really introspectable enough to let you do it all automatically
<stgraber> yeah, definitely sounds like it... I'll put that on my todo and try to come up with something like that during the 6 hours car trip down to Maine.
 * cjwatson hopes you're not driving
<stgraber> haha, no, I have highvoltage for that ;) really, nobody would want to see me drive a car...
<jibel> xnox, another recent report with same symptoms bug 1059584
<ubot2> Launchpad bug 1059584 in ubiquity "Ubiquity not finish installing" [Undecided,New] https://launchpad.net/bugs/1059584
<xnox> jibel: just quick questions: did you boot cd or usb? real hardware / VM? bios / uefi?
 * xnox can't figure it out from the logs quickly
<jibel> xnox, USb created with dd on hardware and bios
<xnox> jibel: thanks.
<xnox> cjwatson: interesting... first time I see patch used in the install target ;-) I used to have a snippet to transverse sources/patches.d/$included-source/series and apply each series to sources/$included-source but it was when I had ~5 large tarball components and 30k of patch series.
<xnox> not worth for a single patch ;-)
<xnox> but looks good =)
<cjwatson> Yeah, I was going to do it with sed but it was too complex
<cjwatson> I suspect in R I want to move all the d-i patches to quilt
<xnox> that would be nice. =)
<xnox> I have partman.py run function refactoring for R-day0
<xnox> as per earlier discussions.
<bdmurray> xnox: I believe bug 1047128 is a duplicate of bug 1055326 but is there more work in the former?
<ubot2> Launchpad bug 1047128 in ubiquity "apt-install grub-efi, network lost while retrieving updated grub-efi packages" [High,Confirmed] https://launchpad.net/bugs/1047128
<ubot2> Launchpad bug 1055326 in ubiquity "During installation, flashplugin fails to install with: IOError: [Errno socket error] [Errno -2] Name or service not known" [High,Fix released] https://launchpad.net/bugs/1055326
<cjwatson> Separate code so I wouldn't advise duping those
<cjwatson> And I thought I'd already dealt with the /run bind-mount during grub-installer
<cjwatson> Oh, beta-1.  I already fixed that, just different bug
<cjwatson>   * Bind-mount /run while running grub-installer, so that the resolver works
<cjwatson>     (LP: #1047550).
<cjwatson> ubiquity 2.12.0
<cjwatson> I'll dup
<bdmurray> thanks
<stgraber> cjwatson: if you have a minute, does http://paste.ubuntu.com/1254567/ looks reasonable to you? I'm trying to fix bug 898787
<ubot2> Launchpad bug 898787 in ubiquity "(k|l|x)ubuntu 11.10 failed to install with error in install_misc.py assert cache._depcache.broken_count == 0" [High,Triaged] https://launchpad.net/bugs/898787
<stgraber> cjwatson: basically the function installing the langpacks ignores pretty much any exception it receives, the problem is that the python-apt code in ubiquity doesn't actually raise an exception but instead uses an assert which makes ubiquity fail completely
<stgraber> I believe the change I'm making should make ubiquity fail in a similar way for all cases we care about but prevent any crash from happening when installing a langpack
#ubuntu-installer 2012-10-02
<stgraber> cjwatson: did you have a chance to look at that diff I pasted yesterday? or do you prefer a MP for it?
<cjwatson> Oh, right, one sec
<cjwatson> Yeah, I think that's fine
<stgraber> ok, I'll commit it then, hopefully that'll be the end of the weird langpacks related bugs :)
<cjwatson> I've said that before ;-)
 * xnox *giggles*
<stgraber> :)
<Gioyik> Hello
<Gioyik> I have a question
<Gioyik> i like to port the ubuntu installer to ArchLinux, how can i do it? Any guide?
<xnox> Gioyik: there are two: ubiquity (graphical) and debian-installer (text based). The graphical one, is more-or-less a frontend to the text based one.
<xnox> so it heavily relies on debian-installer, partman and apt
<xnox> and debian-installer in turn heavily relies on udebs and debconf based configuration.
<xnox> which is all very debian specific...
<xnox> Gioyik: or you could take the UI, but then write your own backend logic for arch-way of installing. But you'll end up with something "inspired-by" or "rewritten-from-scratch".
<xnox> Gioyik: just the design is outlined here http://goo.gl/Kokw5
<Gioyik> i like to port ubiquity, a graphical installer, is posible to do it in a easy way?
<cjwatson> There is not likely to be any easy way, no.  It has a large number of Debian/Ubuntu-specific assumptions.
<cjwatson> There has never been any effort to make it more portable than that.
<xnox> Gioyik: no, because it simply constructs automatic-preseeding to the debian-installer. Ubiquity is pretty, but doesn't actually do any bits of the installation.
<cjwatson> Or at least nothing that resulted in code being merged into the mainline.
<cjwatson> xnox: Well, that's not true.  But the bits it does are done Debian-specifically.
<xnox> cjwatson: ok, true.
<stgraber> jibel: can you still reproduce bug 960077?
<ubot2> Launchpad bug 960077 in casper "live session with persistence - keyboard layout selected during first boot is used" [Medium,Incomplete] https://launchpad.net/bugs/960077
<stgraber> jibel: I'm looking at it as a potential duplicate of bug 946406 but I'm having no luck reproducing the issue
<ubot2> Launchpad bug 946406 in casper "suspect race condition Keyboard layout, oem-config not set on persistent USB image" [High,Incomplete] https://launchpad.net/bugs/946406
<cjwatson> Gioyik: I'm not saying it's impossible, but it will be a long project and you'll have to do most of the legwork yourself.
<cjwatson> Since there's no precedent there's no guide.
<Gioyik> Mmmmm Ok Thanks foy your answers!
<jibel> stgraber, I'll try and tell you.
<stgraber> jibel: thanks
<jibel> stgraber, I can't reproduce 960077. the right layout is active every time. I'll close it.
<stgraber> jibel: ok. I checked all the code again and can't find anything wrong with it, though it's a known problematic part of casper...
<stgraber> my guess is that in some cases, the keyboard layout ends up in the user's gsettings and so even if /etc/default/keyboard is correct, the layout still end up being wrong... but until I can reproduce it, I can't be sure and the various report of this are really blurry on what the user actually did...
<jibel> stgraber, well compared to the bug report, there is only 1 layout listed in the keyboard settings and the applet is not displayed, while there were 4 before. So something changed here.
<stgraber> yeah... having just one keyboard listed is the expected behaviour when you boot directly into the live session
<stgraber> the only case where you should have more than one is if you go through ubiquity-dm
<stgraber> but those bits are mostly owned by the desktop team, so things tend to change quite often... :)
<stgraber> anyway, I did find quite a bunch of problems with persistence (though couldn't find bugs for those) which I fixed and a new casper is now in the upload queue waiting for review
<stgraber> I'll kick a rebuild once that's approved and then prepare the next batch of fixes (trying to cleaup casper a bit so I don't have to do that on release week ;))
<cjwatson> ... again
 * xnox =)
<stgraber> oh, that's a fun one... why is keyboard-configuration calling update-initramfs? :)
<stgraber> that's making the "try ubuntu" button take something like a minute on my i7 test laptop
<cjwatson> Because the initramfs contains keyboard configuration
<cjwatson> Might make sense to divert update-initramfs around that, maybe
<stgraber> oh right and as I'm using a persistent media, it can actually do something with an update initramfs...
<stgraber> we already divert update-initamfs to casper-update-initramfs
<cjwatson> Mm, nested diversions probably won't wowrk
<cjwatson> *work
<jibel> I was blaming my netbook where it takes much more than 1 minute
<stgraber> I'll have to dig what was the exact reason for casper-update-initramfs and if we can't simply have that script exit 0 and be done with it
<stgraber> I'm not really sure I actually want the live image to update the initrd even if the boot media is writable
<cjwatson> upgrades of persistent live CDs
<cjwatson> please don't revert that, it was a bug with Mark's attention on it
<cjwatson> care needed
<cjwatson> there were people running live images with persistence and wanting to be able to upgrade them across kernel ABI bumps and the like
<cjwatson> whether this is a good idea or not, we have no real way to stop them doing this, so it's better to make it not explode
<stgraber> wow, we have really weird users ;)
<cjwatson> yeah, some of them pay our salaries ;-)
<cjwatson> if we can't easily fix performance issues without breaking that, we'd better leave the performance issues in place until we figure it out properly
<stgraber> ok, so I guess I'll change that script to exit 0 if the target isn't writable, that should take care of the cdrom use csae
<stgraber> for the persistent media, well, it's apparently a "feature" that it's terribly slow, so I'll just leave it as is ;)
<cjwatson> just be careful, I have a vague memory that [ -w ] didn't DTRT
<infinity> Isn't -w just a permissions check?
<infinity> You likely want something like wrapping a touch in a break/rollback or some such.
<stgraber> I'll probably copy/paste the hack I have in dhclient-script. : >> "$file" and check the return code
<infinity> Yeah, that. :P
<cjwatson> -w is access(3) I think
<cjwatson> And doesn't work if the fs refuses after that
 * cjwatson peers at bug 1057485.  I can't make that tooltip say anything other than AM or PM in Greek
<ubot2> Launchpad bug 1057485 in ubiquity "ubiquity-kde codepage problem in Timezone map (Timezone.py)" [High,Triaged] https://launchpad.net/bugs/1057485
<cjwatson> In either 12.04 or 12.10
 * cjwatson tries to reproduce this indirectly instead ...
<stgraber> ok, I think http://paste.ubuntu.com/1256333/ will do the trick
<cjwatson> Seems reasonable
<stgraber> jibel: bingo! reproduced the bug!
<stgraber> jibel: or at least found a way to get the same symptoms.
<stgraber> 1) let it boot to ubiquity-dm, choose French and Essayer Ubuntu. 2) Reboot the system 3) Stop the boot in gfxboot, choose German and Ubuntu ohne Installation ausprobieren => you get an azerty layout instead of qwertz
<ogra_> such a commmon usecase even !
<stgraber> now to figure out how to fix that...
<ogra_> :)
<stgraber> ogra_: depends where. I have a lot of friends nagging me about it, but they are from the swiss loco and we have four languages and 2 keyboard layouts in the same country, so it happens...
<ogra_> heh, yeah, but you are a weird country :)
<ogra_> once seb and didrocks succeeded we'll all have to speak french anyway :)
<stgraber> but yeah, getting ch-fr instead of ch-de isn't nearly as problematic as my example with fr and de ;) (ch-fr and ch-de are both qwertz layouts with only some accents swapped)
<stgraber> as long as we don't need to switch to azerty too, it's fine ;)
<ogra_> ++
 * ogra_ wants a kbd with Ã on it 
<stgraber> I'm extremely glad I never had to learn that one, it's already enough of a mess in my head when moving between qwertz and qwerty :)
<ogra_> not that i ever use that char ... but it makes me feel warm and cosy :)
<stgraber> ogra_: my US int keyboard has it (not printed though, but alt-gr + s gives you Ã)
<ogra_> cool
<stgraber> US int with alt-gr dead keys (altgr-intl) is really quite good. I get most common accented letters pressing just two keys (without dead keys) and for the rest you can compose them with the dead keys. And everything else is standard US qwerty so everything just works ;)
<ogra_> my prob with the germany layout (not sure its like that on others) is that deadkeys steals my tilde
<ogra_> and indeed i always forget to hit space when i need a tilde ...
<infinity> I'm a pretty big fan of compose keys.
<infinity> Compose+s+s isn't all that hard.
<stgraber> US int is just shift + ` to get you ~, it's not a dead key. To get the matching dead key you need to do altgr+shift+`+key-to-put-the-~-on
<ogra_> well, my finger memory is usually stronger than my fanboyship
<ogra_> thats also my prob with unitys broken alt tab behavior
<stgraber> so if you want Ã±, you can use altgr+shift+`+n but then again, you could just use altgr+n which would give you the same thing :)
<infinity> That sentence gave me a headache.
<infinity> I think it might be time to finally sleep for a bit.
<jibel> stgraber, that's what I did but the other way around, german first then french, aber ohne GlÃ¼ck
<stgraber> jibel: odd. Anyway, I know how to fix it, it just won't be really pretty as I'll need to wipe a gsettings key from casper...
<stgraber> yay for ugly hacks in casper... http://paste.ubuntu.com/1256656/
<stgraber> I initially wanted to do it the same way as the accessibility stuff by writing a script on the target, though that wouldn't work in all cases as I really want that key flushed before ubiquity-dm starts...
<stgraber> that's going to be one hell of a casper changelog...
<stgraber> every time I fix a bug I'm finding a couple others, though hopefully we'll be good for a while after that with people complaining of weirdness on persistent systems
<stgraber> ogra_: I took bug 984276 from you as I was messing with that code anyway.
<ubot2> Launchpad bug 984276 in casper "installing casper on a non live system causes update-initramfs to fail" [High,Confirmed] https://launchpad.net/bugs/984276
<ogra_> stgraber, thanks so much ...
<ogra_> i'm pushing that bug since ages
<stgraber> ogra_: my guess is that removing the few lines in the postinst will do the trick
<stgraber> ogra_: it was trying to make the symlink and call update-initramfs from the postinst for some unknown (and AFAICS undocumented) reasons
<stgraber> nowadays it's a casper hook making the symlink at boot time (+ a dpkg divert), so the one from postinst shouldn't be needed at all (I still need to test to be 100% sure)
<cjwatson> Well in general anything that ships code in /usr/share/initramfs-tools/ calls update-initramfs.
<ogra_> well, it is helpful if you locally want to roll a live initrd if the postinst runs it
<stgraber> cjwatson: yeah, that part is fine, it's the part about making /usr/sbin/update-initramfs a symlink from the postinst that wasn't
<cjwatson> Oh, err, check bzr history for that, I added that
<cjwatson> Check what bug I was fixing and make sure you aren't reintroducing it :-)
<stgraber> cjwatson: yeah, the change was http://paste.ubuntu.com/1256798/ and that's linked with bug 591207. Though I fail to see the reason for the postinst part of the change.
<ubot2> Launchpad bug 591207 in casper "Casper's USB update-initramfs shim should look for initrd.img in /boot" [High,Fix released] https://launchpad.net/bugs/591207
<stgraber> I'll recheck in a bit, maybe it's something obvious I'm just not seeing
<cjwatson> It was probably needed to handle live media with the previous broken update-initramfs.
<cjwatson> It may no longer be necessary.
<cjwatson> Since nobody should still be running a system booted from code before that fix.
<cjwatson> At least not and expect to upgrade it to quantal in one step.
<stgraber> oh yeah, that makes sense. Will add a mention of that in the changelog.
<stgraber> cjwatson: I see you are the one who moved bug 296129 from ubiquity to casper though I'm not really sure how we'd fix that in casper without causing huge log files for those using persistence. What do you think of getting ubiquity to chmod -x /usr/sbin/logrotate at the beginning of the install and restoring it post-install?
<ubot2> Launchpad bug 296129 in casper "live Installer may rotate syslog during install and copy only a portion to /target/var/log/installer/syslog" [Medium,Triaged] https://launchpad.net/bugs/296129
<stgraber> the cron.daily script checks for the executable bit on /usr/sbin/logrotate and exits 0 if it's not set, so we wouldn't be getting an error from the cron job and unless we're horribly unlucky, the logs shouldn't have been rotated by the time apport is triggered (cron.daily would have to trigger in the few seconds after install for that to happen)
<cjwatson> stgraber: That sounds like a good option, yes
<cjwatson> I probably wasn't thinking about persistence at the time
#ubuntu-installer 2012-10-03
<cjwatson> ubiquity release coming up
<xnox> ok =) with translations?
 * xnox yeah \0/
<cjwatson> Indeed
<cjwatson> Mainly so that I stop getting bugged about the accessibility indicator
<xnox> cjwatson: can reproduce with 3rd of October 9:15am image, btw. Still not fixed.
 * xnox is trying to be funny
<cjwatson> *whack*
 * xnox that one was funny =)
<jibel> xnox, I got bug 1059619 on another machine and another disk (SSD too if it matters) Is there any additional information I can provide ?
<ubot2> Launchpad bug 1059619 in grub-installer "Installation never ends" [High,New] https://launchpad.net/bugs/1059619
<xnox> jibel: not sure. cjwatson have you seen ^^^^ grub-mount is hanging in os-prober
<xnox> not sure if it's fallout from me using grub-mount and possibly not cleaning up after myself.... since afaik I unmount only `mount` mounts, but not `grub-mount` mounts....
<xnox> hmm...
<cjwatson> You need to unmount grub-mount mounts as well
<cjwatson> So I guess that might be related, yes
<xnox> that's what I am thinking now.
<xnox> both mounted and grub-mounted partitions are lazily unmounted (umount -l) as soon as in partman-auto changes I did
<stgraber> I'm going to subscribe ~ubuntu-installer to casper bugmail, shout if you think it's a bad idea.
<stgraber> ev, cjwatson: Actually, looks like one of you needs to do it, it's one of the few LP teams where I'm not (indirectly) an owner/admin :) https://bugs.launchpad.net/ubuntu/+source/casper/+subscriptions
<cjwatson> stgraber: done
<stgraber> thanks, should make it easier to keep the bug count to a sane value
<stgraber> ok, enough casper for this release I think, that's us getting from 150 bugs down to just 55, I think that's enough of an improvement :)
#ubuntu-installer 2012-10-04
<JSX> hello ppl
<JSX> i've got a question about preseeds
<JSX> is it   "d-i  mirror/country   string  enter information manually" OR   ""d-i  mirror/country   string manual"" if i want to set my own mirror in a ubuntu preeseed
<JSX> ?
<cjwatson> the latter
<JSX> thanks!
<cjwatson> the former scheme was what we used to use, but it was problematic and is obsolete
<JSX> i've changed it for ubuntu 11 and ubuntu 12 preseeds, is it also string manual for version 10?
<JSX> *probably* it is; will test it. thanks cjwatson
<cjwatson> If you'd waited I could have looked it up for you ...
<xnox> Was this implemented the preseed/a_later_than_early_command ?
<cjwatson> Huh?
<xnox> "Evan needs to add a "a bit later than early command" preseed variable so that testing scripts can run once the desktop is available."
<xnox> From https://wiki.ubuntu.com/UbiquityAutomation
<cjwatson> Don't know
<xnox> cause preseed/early_command is a bit too early for testing scripts.
<xnox> ev: ^^^^ ?!
<cjwatson> It should be called ubiquity/something if so, not the above :)
 * xnox prefers descriptive names.
 * xnox dodges a whack from cjwatson 
<ev> xnox: not sure if that's necessary
<ev> whatever it is, it can be an upstart job created during early_command
<ev> that runs when the desktop is available
<xnox> ev: yeap, I was thinking about upstart jobs waiting on starting ubiquity for example.
#ubuntu-installer 2012-10-05
<Riddell> cjwatson: am I ok to add some strings which are in the UI but don't have translations? pastebin.ubuntu.com/1250077/
<cjwatson> Riddell: Yes, doing that kind of thing doesn't make things any worse for anyone
<cjwatson> Riddell: You seem to have effectively changed "Before:" to "Before" and "After:" to "After" in that patch
<cjwatson> Not clear that's desirable
<Riddell> good catch
<cjwatson> stgraber: would you have a moment to look over bug 1021449?  getting e-mail about it, don't have bandwidth to deal with it
<ubot2> Launchpad bug 1021449 in ubiquity "12.04 install error on Vaio PCG-7HBP" [Undecided,Confirmed] https://launchpad.net/bugs/1021449
<stgraber> cjwatson: I don't think I'll be of much help, I'm in a small town in Maine with very slow internet and just a laptop with me. (LTSP hackfest, will be back to work on Tuesday)
<cjwatson> ah
<cjwatson> I'll have to punt it for now - too many other things to do myself
#ubuntu-installer 2013-09-30
<psivaa> cjwatson: reported bug #1233056 for saucy server installs, occurring on the images produced soon after saucy beta2..
<psivaa> hmm.. i've reported against base-installer but dont seem to see any recent changes..
<psivaa> https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1233056
<cjwatson> Looks like out-of-sync kernel again
<cjwatson> I'll check
<psivaa> cjwatson: ack
<cjwatson> It's certainly not a base-installer bug
<psivaa> yea, thought as much
<cjwatson> Odd, though, because I checked and d-i had been updated for the new kernel
<cjwatson> (I checked on Saturday IIRC)
<cjwatson> psivaa: can't reproduce with current saucy-server-i386.iso
<psivaa> cjwatson: hmm, strange, the smoke tests with 20130930 failed with the same error and i tried manually with 20130928 amd64 and was able to reproduce
<psivaa> let me try with current i386
<cjwatson> Yeah, I see the failure.  Was wondering if it might be something odd about the strange way the smoke tests are set up (IIRC they do some of the boot process manually)
<cjwatson> I'm not surprised that 20130928 failed, but I think it ought to have been fixed since then
<cjwatson> I'll grab amd64 too on the off-chance
<psivaa> cjwatson: tried manually and see the same failure with today's i386 installation, (on libvirt/kvm ) http://pastebin.ubuntu.com/6175225/
<cjwatson> Blink, why didn't that happen for me
<psivaa> :)
<cjwatson> I'll look harder, thanks :-/
<psivaa> yw
<cjwatson> This still works perfectly for me
<cjwatson> Oh, wait, I'm on an outdated image despite having just rsynced it
 * cjwatson reboots reality
<cjwatson> Ah!  current vs. pending
<psivaa> cjwatson: yea, it does not make a lot of sense to promote amd64+mac to /current whilst keeping i386 and amd64 in /pending
<cjwatson> That's a different problem
<cjwatson> amd64+mac needs to be slaved to amd64 somehow; Adam mentioned that to me a few days ago
<cjwatson> But my confusion was just not driving my own scripts correctly
<psivaa> cjwatson: the bug (https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/1233056) says you could not reproduce.. is that an old message or are you still not able to reproduce?
<cjwatson> That's an old message
<cjwatson> I think it's a stale lock on cdimage - retrying
<psivaa> ack
<cjwatson> psivaa: fixed per smoke test output
 * cjwatson closes the bug
<psivaa> cjwatson: thanks
#ubuntu-installer 2013-10-01
<TheMuso> xnox: Is there any reason why org.gnome.desktop.background show-desktop-icons is unset in bin/ubiquity-dm? Bzr revision 5814 doesn't mention that change in its changelog. Leaving it unset when one clicks the "try Ubuntu" button in ubiquity causes keyboard and accessibility issues.
<xnox> TheMuso: so unsetting that key, will not load nautilus on the desktop by default.
<xnox> which we really don't need nor want in the ubiquity-dm, as we want gnome-settings-daemon to paint the background for us.
<xnox> TheMuso: with "show-desktop-icons" as true, I get no wallpaper painted in ubiquity by gnome-settings-daemon. No sound in my VM for some reason today, will test on spare laptop.
<brendand> how do i properly mount a disk image file?
<brendand> sudo mount -o loop -rw -t auto saucy-server-cloudimg-armhf-disk1.img tmp
<brendand> mount: you must specify the filesystem type
<cjwatson> -rw isn't a valid mount option.  you probably meant -o loop,rw
<cjwatson> as for the rest, I don't know what type the cloud images are and we don't produce them, ask the server team
<xnox> brendand: is it partitioned? maybe you want $ sudo kpartx -a saucy-server*.img and then mount the partitions, which should be mapped in /dev/mapper/loop*p1 and somesuch.
<brendand> xnox, kpartx doesn't show anything
<brendand> xnox, does that mean it isn't partitioned?
<cjwatson> brendand: Please ask the server/cloud people
<brendand> cjwatson, should the above work for a desktop image, so i have a reference point?
<cjwatson> $ sudo mount -o loop saucy-desktop-amd64.iso /mnt
<cjwatson> [sudo] password for cjwatson:
<cjwatson> mount: warning: /mnt seems to be mounted read-only.
<cjwatson> <cjwatson@amber ~/cdimage>$
<brendand> cjwatson, that's a yes then
<brendand> #query ubuntu-server
<brendand> doh
<brendand> for one thing that should be join
<xnox> brendand: sudo mount -o loop precise-server-cloudimg-armhf.img /mnt
<xnox> brendand: works here..... what image did you download?
<brendand> xnox, oh - saucy. let me try precise then
<xnox> brendand: ..... what URL did you use to download your image?
<brendand> xnox, and it's the armhf image
<brendand> xnox, http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-armhf-disk1.img
<xnox> brendand: file saucy-server-cloudimg-armhf-disk1.img
<xnox> saucy-server-cloudimg-armhf-disk1.img: QEMU QCOW Image (v2), 1480550400 bytes
<xnox> brendand: http://askubuntu.com/questions/4396/how-do-i-mount-a-qcow2-disk-image
<brendand> i should have known that - thanks!
<TheMuso> xnox: Right, we should probably re-enable it when the user clicks "Try Ubuntu", more for accessibility reasons than anything else...
#ubuntu-installer 2013-10-02
<xnox> TheMuso: i'm thinking on exit, reset the keys to their default values?
<slowe> Quick question: is it normal/expected for a local network install via HTTP to change /etc/apt/sources.list to show only the internal HTTP server?
<infinity> slowe: sources.list after a network install will always be populated with the server you installed from, yes.
<infinity> slowe: (Unless you pre-seed a different mirror)
<slowe> infinity: Pre-seeding with an external mirror pulls the files from the external mirror, defeating the purpose of installing locally, yes? Any workarounds other than replacing sources.list after install or setting up your own local mirror?
<infinity> slowe: I think there's a way to preseed what apt-setup will do after the initial install, but I could be wrong.  I'm not a preseed wizard.  A next best option would be a late_command that twiddles sources.list
<GrueMaster> Twiddling sources.list is how I used to deploy systems with a netboot install.
<GrueMaster> Very simple to do.
<slowe> GrueMaster: Thanks, I'll look into it. Much appreciated.
<slowe> infinity: Thanks for your help. I'll have a closer look at using a late_command to modify sources.list as you (and others) suggested. Appreciate the help.
<TheMuso> xnox: Yes that would be acceptable.
#ubuntu-installer 2013-10-03
<psivaa> cjwatson: apw: UEFI shim signature verification (?) fails with todays images..
<psivaa> reported bug against linux-signed: bug #1234649
<ubot2> Launchpad bug 1234649 in linux-signed (Ubuntu) "UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 images" [Undecided,New] https://launchpad.net/bugs/1234649
<psivaa> not sure if that's the right package tough
<cjwatson> Nothing I can help with
<cjwatson> Reassigned to shim-signed - you want slangasek
<psivaa> cjwatson: ack, thanks
<cjwatson> (Though could also be the fault of sbsigntool or utah itself)
<cjwatson> What release are you running this on?
<cjwatson> I mean, utah itself
<psivaa> this is saucy
<cjwatson> OK, no idea why anything would've changed recently then
 * xnox ponders if this is my check failing. I've written tests to verify sb signatures, statically.
<apw> sbsigntool changed, but a month back, and (cjwatson) isn't the sbsigntool we use on the backend at least separatly manually upgraded
<apw> xnox, you added a new test ?
<cjwatson> apw: Dunno
<xnox> apw: i added the test, way back when, to utah static tests to extract signed things from the .iso and execute sbverify on them.
<psivaa> apw: 0.6-0ubuntu1~12.04.1 is the version of sbsigntool that's being used for this test
<xnox> $ sbverify --cert microsoft-uefica-public.pem /mnt/EFI/BOOT/BOOTx64.EFI
<xnox> warning: data remaining[1230256 vs 1355656]: gaps between PE/COFF sections?
<xnox> PKCS7 verification failed
<xnox> 139756278539968:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate has expired
<xnox> Signature verification failed
<xnox> has microsoft certificate got updated?! /me goes to poke slangasek / jdstrand / et al
 * apw would expect the public ones to change over time, like they do on websites
<xnox> apw: well, the microsoft cert is listed as valid for 15 years, until 2026
<apw> well doh
<apw> xnox, but they may use an intermediate cert from that master one
<apw> i would expect them to get the master out yearly and make a cert for that year
<xnox> psivaa: raring iso also failing verification.
<xnox> apw: did microsoft sign us for 2 years only =/ O_o
<xnox> apw: extracted certs from the signature, there is intermediate cert which expired today, and it only lasts 15months, vs all other certs last for 15 years.
<apw> hmmm i wonder if they missed
<apw> xnox, ^^
<apw> xnox, is that one ours or one of m$'s
<xnox> apw: m$'s
#ubuntu-installer 2013-10-04
<xnox> cjwatson: i have plenty of u1 page fixes in ubiquity committed. I was thinking to upload. Are there ubiquity translation updates that needs to be done? Also will the hw-detect upload be accepted? (would make sense to get that embedded/included in the ubiquity)
<cjwatson> I can't accept the hw-detect upload since I have changes in it
<cjwatson> I can do a ubiquity translation update pass
<xnox> cool, thanks.
<stgraber> accepted (hw-detect)
<cjwatson> <joeyh> debconf-updatepo... also known as "I'm feeling unproductive today.
<cjwatson>         Please give me a huge diff to check in"
<cjwatson> xnox: done
<cjwatson> actually maybe I should do the imported GTK translations too
<cjwatson> Hmm.  I should, but they've changed how time-format default handling works, so I'm going to defer that until I have time to work it out.
<cjwatson> xnox: So go for it once hw-detect's in the archive so you can update it
<xnox> unit tests are broken =/
<xnox> need to do bisect, cause it's not obvious which one of my changes broke it. and i have an event to attend. will look into it later tonight, or maybe early next week.
<xnox> EOD.
#ubuntu-installer 2013-10-06
<zerosum>  can anyone help with installing ubuntu 13.04 with a usb, i get to the grub boot menu select install ubuntu, then nothing happens black screen
#ubuntu-installer 2014-10-03
<slashd> Is there any limitation using crypto method on a preseed file for more than 1 disk ? I got a recipe here that is working fine with 1 disks but as soon as I add a second one it failed with the error message : The automatic partitionning recipe contains the definition of a volume group that does not contain any physical volume
<slashd> BTW the same recipe is working if I switch to LVM method with more than 1 disk
<slashd> I found a way by using late_command that should suffice
#ubuntu-installer 2015-10-02
<FourDollars> Hi, could you help https://bugs.launchpad.net/bugs/1456443 for trusty?
<FourDollars> This bug needs to update ubiquity to include the new partman-base.
#ubuntu-installer 2016-10-04
<tsimonq2> hmm I
<tsimonq2> hmm I'm having trouble building ubiquity
<tsimonq2> I'm reading over the docs again now, but I'll be here just in case I run into any issues
#ubuntu-installer 2016-10-05
<tsimonq2> so I'm having troubles building it because I'm getting thrown this: Can't locate Debian/Debhelper/Sequence/d_i.pm in @INC (you may need to install the Debian::Debhelper::Sequence::d_i module)
<tsimonq2> I'm installing dh-di now
<tsimonq2> hmm seems to work
<tsimonq2> then I get thrown these by Lintian:
<tsimonq2> W: ubiquity source: diff-contains-bzr-control-dir .bzr
<tsimonq2> W: ubiquity source: unknown-field-in-dsc testsuite-triggers
<tsimonq2> W: ubiquity source: ancient-standards-version 3.9.4 (current is 3.9.8)
#ubuntu-installer 2016-10-06
<mgedmin> hi!
<mgedmin> yesterday I poked around daily livecd images for ubuntu gnome
<mgedmin> and noticed that the syslinux help screens claim the minimum RAM requirements are just 384 MB
<mgedmin> does anyone remember which ubuntu package has the sources for those syslinux help files?
<mgedmin> afaiu they're shared between all flavours
<acheronuk> cyphermox: thank you. testing installer from your ppa :)
<acheronuk> kubuntu slideshow I mean
<acheronuk> (Photo, 1280x726) https://irc-attachments.kde.org/ZlFpP9F9/file_677.jpg
<acheronuk> (Photo, 1280x726) https://irc-attachments.kde.org/l2PJWumV/file_679.jpg
<acheronuk> (Photo, 1280x726) https://irc-attachments.kde.org/1e0b0SgB/file_681.jpg
<cyphermox> mgedmin: gfxboot-theme-ubuntu maybe?
<cyphermox> file a bug, worst case I can go fix it
<jalt> Hi, how can I blacklist a module from running during an unattended xenial desktop (ubiquity) install? Passing module_name.blacklist=yes in the boot options didn't work, possibly because the modprobe inside the squashfs re-detected it.
<jalt> For context, I have a fully working unattended install setup with a bootable usb and presseed, but it doesn't work on a laptop that has an onboard realtek eth interface whose driver (r8169) is broken. I added another eth interface which works fine, but ubiquity/dhclient insist on trying to get dhcp on the broken interface, and install hangs.
<cyphermox> jalt: https://wiki.archlinux.org/index.php/kernel_modules#Using_kernel_command_line_2
<jalt> thanks for the tip cyphermox, i will try it.
#ubuntu-installer 2016-10-07
<mgedmin> https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1631255
<mgedmin> (I've given up trying to find the actual source of those help texts after a fruitless search)
#ubuntu-installer 2016-10-08
<acheronuk> from #kubuntu-devel
<acheronuk> [17:54] <marco-parillo> Traceback (most recent call last):
<acheronuk> [17:54] <marco-parillo>   File "/usr/lib/ubiquity/ubiquity/frontend/kde_components/PartitionModel.py", line 66, in setData
<acheronuk> [17:54] <marco-parillo>     item.partman_column_format_toggled(value.toBool())
<acheronuk> [17:54] <marco-parillo> AttributeError: 'int' object has no attribute 'toBool'
<acheronuk> ^^ cyphermox
<acheronuk> <marco-parillo> Trying to use an existing partition, make it root, format ext4 and click the box.
<acheronuk> <marco-parillo> I am not sure what I did...maybe clicking too fast. I repeated it more slowly, and it is installing. Slideshow is back! Thank you.
#ubuntu-installer 2017-10-03
<tsimonq2> cyphermox: Hey, would you happen to know what this would be caused by? bug 1721114
<tsimonq2> grr no bugbot, here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1721114
<cyphermox> did the seeds for lubuntu-next change recently?
<cyphermox> I don't see anything obvious, though maybe that 'pvs' missing would point to lvm2 not being on the image.
<cyphermox> btw, the same looks to be true for the lubuntu image too
<tsimonq2> cyphermox: Nope, no seed change...
<cyphermox> I'll have a look in a bit
<acheronuk> [21:20] <genii> I tried on my Acer D260 notebook, 64 bit install from a liveusb to another USB ( 128G )
<acheronuk> would installing like that ^^^ have any relevance?
#ubuntu-installer 2017-10-05
<Laney> psusi's triaging on grub-installer reports is impressive
<cyphermox> acheronuk: no
<cyphermox> acheronuk: in the past it tended to make things a little confusing as you can hardly differentiate one USB from the next in some cases, but that should have been fixed since about maverick.
<acheronuk> cyphermox: ok. something just sounded familiar about problems with that, but if it should all be ok nowadays then good
<cyphermox> I think so
<cyphermox> I have done an install like that a long while ago, it was working. regressions happen, so if someone finds this they should file a bug
#ubuntu-installer 2018-10-03
<xnox> Laney, i am suspicious about ros-ros-comm adt test on cosmic on i386 triggered by python2.7/2.7.15-4ubuntu4 -> has it been continiously running for multiple hours now; killing the VM to oblivion, and autopkgtest cloud continiously auto-restarting it, or some such?
<xnox> Laney, it should only take just over an hour to complete, but it seems to be actually running and running for hours, and I think I did catch a running log with a much higher command, than the current command9 before.
<Laney> how many should it have?
<Laney> try running it locally?
<xnox> i think command24 is the highest.
<xnox> also no idea why i started talking in this channel
<Laney> good for it to have some activity :-)
<Laney> it could be that it times out
<Laney> and we need to put it in long_tests or something
<xnox> Laney, but like i see no long / test runs about it from the results page...
<xnox> Laney, are there any more logs that you might have access about it? It does look suspicious.
<xnox> i.e. i'd would want to know if it was autorestarted or not.
<xnox> http://autopkgtest.ubuntu.com/running#pkg-ros-ros-comm
<Laney> it finished?!?!?!
<xnox> Laney, well yeah, weird. now waiting 5-10 minutes for the results to appear in all the right pages.
<xnox> Laney, must be scared of you logging-in ;-)
<Laney> heh
<xnox> Laney, it's back from the dead. running "still" now at 2h.... http://autopkgtest.ubuntu.com/running#pkg-ros-ros-comm
<xnox> Laney, did it restart?
<xnox> it's done command1 and now doing command2, when i pinged you it was at command9 at least.
<xnox> so it did jump back.
<xnox> i fear it might be doing this in perpetuity.
<Laney> ok lemme save the log
<Laney> catch it in the act of being naughty
<Laney> Timed out waiting for ssh. Aborting! Console log:
<Laney> ------- nova console-log b6f59c2d-bad8-46fe-9399-9ca91765b66c (adt-cosmic-i386-ros-ros-comm-20181003-131224) ------
<Laney> ---------------------------------------------------
<Laney> ------- nova console-log af7053b5-66b5-4396-a600-a3b09634f399 (adt-cosmic-i386-ros-ros-comm-20181003-131224) ------
<Laney> ERROR (CommandError): No server with a name or ID of 'af7053b5-66b5-4396-a600-a3b09634f399' exists.
<Laney> ---------------------------------------------------
<Laney> ERROR (CommandError): Unable to delete the specified server(s).
<Laney> dunno what that even means, the server failed to provision??????
<xnox> muahahhaha
<xnox> Laney, meanwhile, it seems to me, it is written like that, because they did not want to write a shell script.
<xnox> Laney, i think all of this can run on a single VM.... instead of gazzilion VMs.
<Laney> it does mean they get separate results which can be nice
<Laney> but maybe this is taking it a bit far
<xnox> if separates logs is important, i can create separate logs in artifacts per test-command.....
<xnox> 144 VMs vs 6 VMs is imho a change worth doing here
<xnox> given no deps are conflicting, and there is no breaks-testbed, and there is no needs-root, etc
<xnox> this is abuse of resources
<Laney> in the future we'll have the ability to skip / track regressions per test
<Laney> in that sense splitting your tests up in to separate autopkgtests is sensible
<Laney> but I wouldn't object if you were to consolidate this a bit :-)
<xnox> well, ideally we would want some kind of a reporting api thing, such that a single test can export a report of multiple tests.
<Laney> it'll probably eventually finish by luck
<xnox> this runs trivial single g++ on a oneline file, testing api compilation.....
<Laney> yes OK, that probably doesn't need to be N different tests ...
 * Laney didn't look at what they actually are
<xnox> sure.
<xnox> if not these failures, i wouldn't either =)
<xnox> in total it is a 35s test; with hours of VM setups =)
<Laney> ;_;
<Laney> CLOUD!
<Laney> it got up to test 11 this time and I'm about to have to go :(
<Laney> 12*
<Laney> stupid thing
#ubuntu-installer 2019-09-30
<xnox> Laney:  o/
<Laney> welcome
<Laney> HAHA
<Laney> just noticed the /title :d
<Laney> :D*
<xnox> ooooh
<Laney> anyway
<Laney> forgetting that
<Laney> if it's ok to push those deps up (real impact is adding gir1.2-gudev-1.0 to all isos) then I will upload that
<xnox> Laney:  it's good
<Laney> YEAHHHHHHHHHHHHHH
<Laney> oh there's actually a test for this, which mocks Popen /o\
<xnox> Laney:  meanwhile i'm having an intimate moment with casper, systemd and weird way we setup rootfs & /cdrom mount points
<Laney> sounds cosy
<Laney> the reboot thing?
<xnox> Laney:  in general, ugrly shutdown messages, possibly will resolve reboot thing too, but i doubt it.
<xnox> subiquity is better, let's see if it does things to the desktop too
<Laney> bollocks to this
<Laney> I've wasted too much time, not going to port the tests to umockdev
<Laney> let me just do the /sbin/udevadm -> udevadm fix
<xnox> Laney:  one liner for the win
