User1: ev, ARGH !
User2: ?
User1: ev, what did change in oem-config with the last upload, it doesnt start on the armel images anymore
User1: seems it looks for an oem user
User2: logs please
User1: i get a traceback on the screen for line 94 and 531, i cant easily get logs of that borad
User1: pwd.getpwnam()
User1: and it ends with a KeyError ... getpwnam(): name not found: oem
User2: you don't have USERNAME set in casper
User1: we dont use casper
User1: the images are preinstalled, we cant create a user there
User1: it worked without until yesterday
User1: crap
User2: that code hasn't changed
User1: * Run oem-config-wrapper as the user oem rather than root.
User1: - Fixes issues with pulseaudio applet not working
User1: - Prevents root terminals from ctrl-alt-t (LP: #594233)
User1: there we go i guess
User2: ah
 * ogra sighs
User1: superm1, is there a way to not do this ? ^^^
User1: we need to run as root on the preinstalled images
User3: Do we?  Can we not create an oem user in jasper?  Why do we need root?
User1: persia, i really dont want to keep any fragments of the oem user
User1: afaik that user is originally created in the aufs mounted setup
User3: Oh right, cleanup without layered fs would be painful.
User1: ev might prove me wrong here (please !)
User3: Maybe oem-config-wrapper should try to run as "oem" and fall back to "root" if it fails?
User1: ++
User1: good idea
 * ogra adds an oem user to test with
User1: ev, hmm, the language table design seems to have changed, its only populating 2/3 of the vertical space of the window (all langs are there but i needs to scroll a lot more sideways now)
User1: heh
User1: the hostname ends with a hyphen for me ... <user>-
User1: ah, nice, the progressbar is a lot more informative now
User2: User1 hostname> can you pastebin me the output of dmidecode?
User1: ev, arm board, i doubt i even have it installed ... let me see once oem-config finished (10-15min)
User1: ugh, taking that back, it already finished
User1: that cant be right
User1: yeah, seems debconf didnt apply *anything*
User1: wrong kbd and language
User2: ogra, User3 http://paste.ubuntu.com/494660/ - look okay?
 * ogra hugs ev
User1: awesome !
User1: you rock !
User1: (and it does look ok :) )
User3: ev, Looks clean to me.  Thanks for the quick fix even before ogra dug into it :)
User2: sure thing
User4: ev, good morning
User2: hi ara
User2: good morning
User4: ev, I started testing ISOs with 2.3.18 as part of the pairwise testing cycle I told you about
User2: awesome!
User2: anything come up so far?
User4: ev, after reboot, I got dropped to grub shell
User2: gah
User4: ev, bug 640341
User5: Launchpad bug 640341 in ubiquity (Ubuntu) "After installation, I get dropped to a grub shell (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/640341
User4: ev, let me know if you need any other information or if you need me to rerun with -d
User2: sure thing
User2: thanks
User4: you're welcome
User6: that log doesn't show it installing grub
User2: indeed
User2: in kvm trying to reproduce and dig at it now
User2: I suspect it's fallout from the --no-bootloader option
User1: ev, verified, no dmidecode installed on armel
User1: ev, hrm, and archdetect only returns armel/unknown
User1: i guess thats why i dont have anything behind the hyphen ?
User2: User1 found the problem
User2: I think
User1: well, it should return /omap4 at least .... /me looks into archdetect
User2: User1 ^ see if that fixes it ending in a - for you
User1: will do
User2: if you have a chance
User2: thanks!
User3: I thought we were falling back to laptop-detect when dmidecode didn't work.
User2: we are
User2: the code was broken though
User2: it was testing for a null string where one never existed
User3: Aha!
User2: ARGH
User6: User7 would you care to review Sebastian's proposed version of oem-config-remove-gtk in bug 637517?  since you wrote it to start with ...
User5: Launchpad bug 637517 in ubiquity (Ubuntu) (and 2 other projects) "oem-config-remove-gtk crashed with AttributeError in _run_transaction() (affects: 2) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/637517
User2: *sigh*
User1: grr, i hate if i typo commit messages
User3: Trick is not to use bound branches, so you can uncommit :)
User6: if you're uploading libd-i, please take care with the non-VCSified stuff in the source package
User1: persia, i didnt push yet ... but CIA exposes the embarrasment world :)
User1: err, crap i *did* push
User1: cjwatson, you mean the autoreconf run ?
User1: or is there anything else i'm missing
User6: I mean that you need to debdiff carefully against the previous source package and ensure that there is only the change you made
User4: ev, I have seen that you found the issue with grub
User4: ev, anyway to recover my installation? :)
User2: User4 indeed, thanks for pointing that out so quickly
User4: would rescue mode do the trick?
User1: cjwatson, ah, k
User2: User4 go into a live CD, mount your root partition on /mnt, bind mount sys, proc, and dev into /mnt, then run sudo chroot /mnt grub-installer /dev/sda (where /dev/sda is the disk you want to install the bootloader to the MBR of)
User4: thanks, will try that
User4: ev, is this bug going to happen to everybody? or it is only certain installations?
User2: User4 everyone
User2: I'll upload a new ubiquity shortly
User2: and ask if I can do a respin
User4: ev, OK, I will send an email to avoid people testing this one
User2: cool, thanks!
User1: cjwatson, does that look right to you ? http://paste.ubuntu.com/494729/ i'm using a fresh maverick chroot for the autofoo but not ending up with 2010 in the copyrights seems weird
User6: User1 please just copy (cp -a to preserve timestamps) the files in from the previous source package
User1: oh, ok
User6: the last autotools update was done in a Debian system
User6: so it won't match exactly, I shouldn't imagine
User1: ah, that explains it
User7: cjwatson, sure i'll take a look today
User6: thanks
User7: ogra, if you run oem-config as root, you're going to see some weird behaviors in the panel still
User7: so it would be better if you could set up jasper to create an oem user
User7: (or some other place that's appropriate)
User1: superm1, well, i dont want to add users to the preinstalles FS
User1: what weird behavior beyond sound would that be ?
User1: (i dont mind disabling the sound applet)
User1: NM seems to work fine
User7: well as long as NM works fine i guess that works
User1: k
User1: evan already added a fallback in case oem doesnt exist
User1: so we should be fine again
User8: is there a problem with ubiquity in today's daily build that installs a system that's not bootable?
User8: (at least, that's the problem I have on Edubuntu :) )
User9: hi ev, it seems that the last ubiquity upload introduced new strings, which gives no time to translators to translate them before today's deadline. May I ask you to fetch translations later? I've filed bug 640482, it would be great if you could comment on that. Thanks!
User5: Launchpad bug 640482 in ubiquity (Ubuntu) (and 1 other project) "Please download translations for new strings after NonLanguagePackDeadline (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/640482
User2: User9 yes
User2: I planned to send a mail out to the translation team about this
User2: I'm happy to upload a new ubiquity with just translations before the LanguagePackDeadline
User10: The 10.10 amd64 beta ISO doesn't boot on a Macbook Pro. Depending on how I boot "Windows" mode or EFI, I get a black screen w/ the text "Select CD-ROM Boot Type" or a kernel panic, "unable to mount root fs on unknown block". Is this expected behavior?
User9: ev, cool. Yeah, if you could send that e-mail as well, that would be great
User2: will do
User6: User10 the intention was for the EFI work not to change behaviour on Macs
User6: User10 I think somebody with the hardware is going to have to debug this, though
User6: Macs are weird and their behaviour is hard to predict remotely
User10: User6 "not change behavior" = it's supposed to be broken? I haven't booted from an ISO since Jaunty or so on this machine, so I'm not sure what the expected behavior is these days.
User10: User6 Is there anything I can do to help debug? The i386 install works fine, not sure if that's useful data or not
User6: obviously it isn't supposed to be broken :)
User6: i386 doesn't have the EFI bits, deliberately
User6: I don't know how to debug Mac booting
User6: I know that there are some Macs that refuse to boot from multi-catalog El Torito CD-ROMs due to buggy firmware
User6: if yours is one of those, i386 may be the only useful fallback
User6: though that seems odd given that apparently it gives you a choice?  what level is the choice at?
User10: User6 This machine is 3 years old, so certainly might fit into that category.
User10: User6 Apple's firmware boot chooser gives me a couple options. From the CD I can choose "windows" or "EFI boot". The former dumps me at a prompt that I think is from the firmware, it says "Select CD-ROM boot type". The prompt is a dead-end, the machine doesn't accept input at that point.
User6: what happens if you press 1 and enter?
User6: from the prompt
User10: User6  The "EFI boot" option in the boot chooser gets me to a grub menu that includes "install ubuntu" and "check disc for defects". I choose 'Install Ubuntu", and a few seconds later I get a kernel panic
User6: http://jowie.com/blog/post/2008/02/24/Select-CD-ROM-Boot-Type-prompt-while-trying-to-boot-from-Vista-x64-DVD-burnt-from-iso-file.aspx may be related
User6: generally speaking I'm not expecting the EFI option to work on Macs, since AFAIK they're still not UEFI-compliant
User10: User6 I found that, haven't tried to remaster a disc yet
User10: ok, I believe that. So I should be trying to get around the "select cd-rom..." prompt.
User6: the article seems a bit confused and not obviously directly relevant
User6: obviously we're not using Microsoft's boot sector
User10: agreed
User6: it's possible isolinux has a similar problem, though
User6: though it does seem to at least try to strip off the version
User10: User6 this seems directly related, not especially promising though (bug is still 'NEW')" https://bugzilla.redhat.com/show_bug.cgi?id=527443
User5: bugzilla.redhat.com bug 527443 in syslinux "boot.iso does not boot with MacBook Pro 2,1 or iMac 2006 late" [Medium,New]
User6: I suppose there's an outside chance that it might be worth trying to get the EFI option to work, although I suspect that will run into video problems later
User10: yeah - no acceleration, from what I understand. Not sure that's worth it for the user.
User10: Would be nice if there were a, "sorry, we already know this isn't going to work. Try the i386 CD" type of message from grub.
User6: no grub
User6: oh, for efi?  um
User6: not sure that the amount of hacking required to do that is worth it
User6: and I don't know exactly which models are affected
User10: agreed. I do know that newer MBP models boot fine from the amd64 ISO, so there's some cutoff of machines from within the last 3 years.
User10: sounds like a bunch of work
User6: it might be worth trying remastering with isolinux-debug
User10: ok
User6: User7 maybe the changelog should give credit to Sebastian?
User7: cjwatson, it does
User6: assuming you used his code, I didn't check :)
User6: ah, ok
User7: it's got his name right above at least
User6: I assumed you used debcommit so the commit message was identical
User6: ah, debcommit doesn't show the [ ... ] bit
User6: ok
User7: debcommit strips the [ user ] stuff
User7: yeah
User2: oh wow, gconftool.set doesn't actually work, and probably hasn't ever
 * ev fixes
User7: i'm sure it was working before
User7: you can't use a terminal in the current dailies because of it...
User2: perhaps it's just due to the way I'm bootstrapping ubiquity
User2: missing an environmental variable or something like that
User2: but this does seem correct
User7: without config source it's supposed to just use the default path, so is there a scenario that the path that should be in use isn't the default?
User2: hm, not sure
User2: I'll play with it in a minute
User2: see if I can get a better answer
ubuntu-installer
Ubuntu IRC