[12:47] <dpm> hi cjwatson. It seems that there were some new strings in the d-i POT template that got imported after string freeze. Translators are asking what these strings were and how they got in the template (https://lists.ubuntu.com/archives/ubuntu-translators/2010-April/003620.html), I interpret mostly out of curiosity. It's nothing urgent, but if you've got a minute and you know where they came from, could you tell me a few words, so I reply to the thread?
[12:47] <dpm> (or you might want to reply yourself, whatever you prefer)
[12:49] <dpm> These are the strings, for reference: https://translations.edge.launchpad.net/ubuntu/lucid/+source/debian-installer/+pots/debian-installer/ca/+translate?show=untranslated
[12:55] <cjwatson> dpm: yes, I know, I ran the manual import :-)
[12:55] <cjwatson> unfortunately it was too late - I hadn't noticed that the automatic stuff was failing
[12:55] <cjwatson> so it's my bad, but I realised too late to be able to do anything about it
[12:56] <cjwatson> dpm: the important ones I'm specifically aware of having introduced were those in partman-ext3 and grub-installer
[12:56] <cjwatson> dpm: if translators work on those, I can commit to getting updates to those two packages into 10.04.1
[13:01] <cjwatson> dpm: more detail on what went wrong: firstly, I'd forgotten to run the semi-automatic push to Launchpad for some time; secondly, I'd forgotten to update the template build job to point to Lucid; thirdly, when I realised this was broken and tried to rush in a fix in time for the non-langpack freeze, I discovered that hosting changes on people.canonical.com had removed some packages I was relying on so I had to move it ...
[13:01] <cjwatson> ... in a hurry; fourthly, once I did upload it to Launchpad, it took something like a week to get through the import queue and so I missed the boat
[13:06] <dpm> cjwatson, thanks for the detailed info
[13:06] <cjwatson> the hypothesis on the list that it is a general update from upstream is false
[13:07] <cjwatson> though I probably merged one or two packages, and wouldn't have been particularly concerned if the odd translation was out of date
[13:07] <dpm> right
[13:11] <dpm> cjwatson, and yes, I can confirm what you and others noticed already, the imports queue was pretty full during the translation deadlines. There was not much that could be done there, but in the near future, with automatic generation of templates and message sharing between src packages and LP projects (with translations from bzr branches) this should be much alleviated, as translations will be imported from bzr branches regularly instead of from the
[13:11] <dpm>  packages upon upload
[13:20] <cjwatson> is that actually going to happen for source packages?
[13:20] <cjwatson> I asked for that some time ago
[13:29] <dpm> cjwatson, yes, the LP devs can give a much better insight than I, but basically, that's going to be the first step towards better upstream integration: improving the imports. The way it will work the upstream projects' (both external and hosted) translations will be imported from their bzr branches, and messages will be shared between the upstream project and the Ubuntu source packages. The Ubuntu source packages will still have to create a POT temp
[13:29] <dpm> late on build, but translations will be imported from the upstream branches. Unfortunately, I'm not sure it will help for d-i in the current form, since we get separate templates from upstream which we merge into one, don't we? So in that case, I'm still not sure what would be best. As a translator I prefer a single template (unless it's overly big), but if separating it into the same templates as upstream provides more automation, that would defini
[13:29] <dpm> tely be worth looking at
[13:29] <dpm> henninge and I have just signed up for a plenary at UDS to give an overview
[13:30] <cjwatson> that's not quite right
[13:30] <cjwatson> upstream maintain it as a single template, and we merge into one that roughly matches the set of strings in that template
[13:31] <cjwatson> upstream run automatic scripts that split up that template into individual source packages
[13:31] <cjwatson> the unit of merge from Debian to Ubuntu is the source package
[13:31] <dpm> oh, right, I thought they maintaned it in the split templates as well
[13:31] <cjwatson> nope
[13:31] <cjwatson> if they did, I wouldn't bother doing the merge :)
[13:31] <dpm> :)
[13:32] <dpm> so that might turn out to be very useful for d-i translations as well
[13:34] <cjwatson> maybe; I think it would take quite a lot for me to trust it to do fully automatic commits, since there are a number of specialised requirements that if broken can end up entirely breaking the installer
[13:35] <cjwatson> and there are memory implications to including new translations, and I'm still concerned about merge issues
[13:44] <CIA-3> migration-assistant: evand * r102 migration-assistant/ (debian/changelog ma-script-utils): unmount_os can be called without arguments (LP: #536673).
[13:44] <ubottu> Launchpad bug 536673 in ubiquity "ubiquity crashed with InstallStepError in configure_hardware()" [High,Triaged] https://launchpad.net/bugs/536673
[14:02] <CIA-3> partman-base: cjwatson * r209 ubuntu/ (debian/changelog partman-commit):
[14:02] <CIA-3> partman-base: Remove cleanup trap in partman-commit, whose only effect is to break
[14:02] <CIA-3> partman-base: repeated runs of partman-commit (LP: #536673).
[14:02] <ubottu> Launchpad bug 536673 in ubiquity "ubiquity crashed with InstallStepError in configure_hardware()" [High,Triaged] https://launchpad.net/bugs/536673
=== ogra_ is now known as ogra
[14:40] <jeffhaas> Hi, Please let me know  if there is a better channel for this question.  I am contemplating an upgrade to Ubuntu 10.4, if there is a fix for my broadcom wireless card.  Currently I am using Broadcom STA wireless driver, which has found my hardware, but the network manager will not connect as it should.  It could be the wireless definition in ubnuntu 9.10 is eth2.  I have been through the forums, and tried all the twiki helps on this, s
[14:40] <jeffhaas> o I was hoping a solution will come with the new version of ubuntu.  I have Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller.  Thanks for the help ahead of time.  Cheers, Jeff
[14:50] <ev> jeffhaas: please ask in #ubuntu+1
[14:50] <ev> this channel is for development of the installer
[14:57] <jeffhaas> thanks
[15:34] <shtylman> ev: I tried the installer in qemu... and it was horribly slow... and not just the installer... the whole system was slow :( ... virtualbox is much faster for me
[15:34] <ev> shtylman: was that qemu or kvm?
[15:35] <shtylman> um... I ran the comman qemu... but I do have the kvm stuff installed
[15:35] <shtylman> so I think it uses it if it finds it
[15:36] <ev> shtylman: what's the output of `kvm-ok`
[15:36] <cjwatson> I'm not aware that qemu uses kvm bits if it finds them
[15:36] <shtylman> INFO: Your CPU supports KVM extensions
[15:36] <shtylman> INFO: /dev/kvm does not exist
[15:36] <shtylman> HINT: sudo modprobe kvm_intel
[15:36] <shtylman> KVM acceleration can NOT be used
[15:36] <shtylman> :(
[15:36] <cjwatson> qemu and kvm have totally different performance characteristics here
[15:37] <cjwatson> try 'sudo modprobe kvm_intel', and then run kvm-ok again
[15:37] <shtylman> indeed that works
[15:37] <ev> shtylman: that'd be why it was so slow
[15:37] <shtylman> I thought I had done that before
[15:37] <cjwatson> then run it as kvm rather than as qemu
[15:37] <shtylman> gotcha
[15:37] <shtylman> thanks guys :)
[15:38] <ev> sure thing
[15:38] <cjwatson> you shouldn't have to - qemu-kvm installs an upstart job that loads that module
[15:38] <cjwatson> unless you only just installed that package and maybe it doesn't run on install or something
[15:38] <cjwatson> though it looks like it does
[15:38] <shtylman> cjwatson: it does... I might have unloaded it in the past myself
[15:38] <cjwatson> I suppose you might have the module blacklisted for some reason
[15:39] <shtylman> cause vbox didn't play nice
[15:39] <cjwatson> grep kvm /etc/modprobe.d/*
[15:39] <shtylman> I was under the impression I reloaded it... but I suppose not
[15:39] <shtylman> kvm-ok I did not know about... but its handy
[16:11] <kirkland> cjwatson: i'm seeing some init.d scripts and init jobs not being run from time to time;  qemu-kvm being one of them (i only notice when I try to run kvm and the module isn't loaded)
[16:11] <kirkland> cjwatson: /etc/init.d/screen-cleanup and /etc/init.d/nfs-kernel-server being two others
[16:11] <kirkland> cjwatson: since i added --verbose to my kernel command line, i have not seen the problem again
[16:12] <cjwatson> the paths that would cause failures for those two different types of scripts are spectacularly different
[16:12] <cjwatson> init.d scripts being run is dependent on appropriate links in /etc/rc*.d/
[16:12] <kirkland> cjwatson: all three fail to run, when i see the problem
[16:12] <cjwatson> nevertheless, do you understand my point?
[16:12] <kirkland> cjwatson: i've only seen it happen on my quad core
[16:12] <kirkland> cjwatson: yes, i certainly do
[16:13] <cjwatson> might be worth checking whether it's "not run" or "run but doesn't do anything"
[16:15] <kirkland> cjwatson: i'm also finding the server installer particularly slow
[16:16] <kirkland> cjwatson: at beta2, i installed 2 UEC machines in a live demo presentation from the same usb stick, sequentially in under 25 minutes
[16:16] <kirkland> cjwatson: today's iso has been installing for over 20 minutes (on one machine)
[16:17] <cjwatson> I haven't noticed any particular slowdown myself ...
[16:17] <cjwatson> if there is any I suppose it must be in the kernel?
[16:17] <kirkland> cjwatson: it's the "select and install software" step that is crawling
[16:18] <bladernr> ev:  ping
[16:18] <ev> bladernr: pong
[16:19] <bladernr> ev:  davmor2 asked me to bug you about this... did an install (dual boot) of Lucid on a WinXP system.  Ran migration assistant on both XP users and instead of getting two user accounts in Ubuntu, I get a single account who owns ALL data from the XP user accounts, and no other accounts created.
[16:19] <ev> right, that's intended behavior
[16:19] <bladernr> ev:  I think this is A: a bug and B: a possible security concern because now you have a third user who now owns all personal data from the XP install
[16:20] <bladernr> so the expected post-install action for the new Ubuntu user is to then manually re-create all the XP users under Ubuntu, and then separate potentially thousands of personal files between them?
[16:21] <bladernr> slangasek says it's not a security issue as the Ubuntu user is de-facto an admin (and I can see his point there)
[16:22] <ev> bladernr: We used to have this behavoir and it was a complete mess
[16:23] <bladernr> ev:  ack
[16:23] <ev> (behavoir> it used to create an account for each user it was importing from, and you had to set a password for each one of those users before you could proceed past the migration-assistant page)
[16:24] <ev> I agree with Steve that it's not a security concern.  Everything that migration-assistant does, you can do yourself with the live CD.
[16:24] <bladernr> ev:  I'm still going to open a bug at least and hope that this can be investigated and maybe de-messed for the next release cycle.  For example, on my own Windows system here, I have nearly 40,000 photographs in my account, and my wife has almost as many in her account.  Having to manually sort those out after a migration  would be an absolute nightmare (not to mention the 20,000 or so mp3s, 5000 or so text documents, etc
[16:25] <ev> bladernr: sure
[16:25] <bladernr> ev:  like I said, I can see slangasek's point and am not so concerned about that point... thanks for the explanation...
[16:25] <ev> file it against the migration-assistant source package
[16:25] <ev> anytime
[16:26] <bladernr> though IMHO, I would have preferred to just enter account info for each new account myself, but then again, that's just me and me != world
[16:26] <bladernr> heh
[16:26] <bladernr> other than that though, let me say that you guys did a great job in getting the installer in shape
[16:31] <ev> Thanks a lot!  I very much take such comments to heart.
=== ara_ is now known as ara
=== ara is now known as Guest4805
=== Guest4805 is now known as ara
[18:18] <shtylman> ev cjwatson: do you guys use the default display driver for qemu? cause when I do, my colors are weird in the vm
[18:20] <cjwatson> yes
[18:20] <cjwatson> well, except that I don't use qemu, I use kvm
[18:20] <cjwatson> my standard invocation is kvm -monitor stdio -m 512 <blah>
[18:20] <shtylman> right... kvm I meant
[18:22] <shtylman> weird... still strange colors for the wallpaper in kubuntu
[18:22] <shtylman> its amusing
[18:22] <shtylman> and the kvm is still slow
[18:22] <shtylman> maybe kubuntu isn't meant to run in kvm :)
[20:09] <pixel> Hey guys, I'm customizing a very minimalist version of ubuntu, and I tried to use SLiM for login manager, the problem is that it didn't let the live-cd user to autologin, and i believe it was what prevented "only-ubiquity" mode to function as well, so what I want to do is to remove SLiM and after the installation, install the .deb package, but how can I add this to ubiquity?
[22:45] <ev> shtylman: -vga std