[01:15] <slangasek> chrisccoulson: ok; so it's not synchronous, but does it still give us enough information to fix?  There can't be too many calls to XRRSetScreenSize in the code :)
[01:19] <chrisccoulson> slangasek - there won't be many calls to it, but it would be good to get an xtrace log to see what parameters are being passed in the call
[01:19] <slangasek> chrisccoulson: ok, I'll find the time somewhere to do an xtrace run; probably will be after RC
[01:20] <chrisccoulson> i'm just looking at the very limited randr documentation for RRSetScreenSize, and it says this: "All active monitors must be configured to display a subset of the specified size, else a Match error results"
[01:20] <chrisccoulson> but that doesn't say much. i think i'll have to just look at the server code instead
[01:22] <slangasek> smoser, pitti: "in th past, that has had the AMIs in paren for ec2" - did that not work right on the first pass?
[01:24] <slangasek> pitti: yes, we use the AMIs instead of the datestamps for EC2 on the tracker because that's the unique identifier within EC2 and how testers locate it (in theory you could re-bundle the same UEC image more than once for publishing to EC2, so the datestamp isn't unique)
[01:25] <slangasek> chrisccoulson: anyway, to fix this properly, wouldn't libxrandr have to be fixed to make RRSetScreenSize /check/ for that Match error (_XReply)?
[01:29] <chrisccoulson> slangasek - _XReply is for fetching the response back from the server (and also fetching the errors). However, it looks like the server doesn't actually give a response for RRSetScreenSize, and I assume this is why there is no call to _XReply there
[01:29] <slangasek> ah
[01:30] <chrisccoulson> libxrandr (and libx11) generally doesn't check returned errors either - it is up to the applications to trap the errors and deal with them appropriately
[01:30] <chrisccoulson> in this case, the error goes untrapped because g-s-d is not expecting it
[01:40] <smoser> slangasek, i think we got it worked out.
[01:40] <slangasek> smoser: well, if it didn't publish right the first time, I'd like to understand why, since I need those scripts to work when I go to publish the RC on Thursday :)
[01:42] <slangasek> superm1: mythbuntu candidate images are up; no known RC showstoppers remaining anywhere, please test
[01:42] <slangasek> cody-somerville, luisbg, TheMuso: xubuntu, ubuntustudio are also up
[01:42] <smoser> slangasek, everything worked fine.
[01:42] <slangasek> smoser: ok, so pitti just didn't know to look at the table?
[01:43] <smoser> slangasek, pitti just didn't know that we wanted the AMIs to appear as the "release"
[01:43] <smoser> so at first he put 20091020.1
[01:43]  * slangasek nods
[01:43] <smoser> everything worked perfectly otherwise.
[01:44] <smoser> as a point of reference, full build and publish took 95 minutes
[01:44] <smoser> publish is about 65 of that i think. something around there.
[01:44] <slangasek> smoser: ok, thanks - I'll be sure to schedule accordingly
[01:45] <smoser> slangasek, but also remember that we can publish ahead of time, and just not set public
[01:45] <smoser> setting public takes < 1 minute
[01:45] <smoser> so if these RC candidates are going good, we publish them to RC but keep them private, then at "release time" we just flip them to public
[01:46] <slangasek> smoser: right; I still have to remember to do the publishing far enough in advance :)
[01:46] <smoser> once published as private we even have all the ami/aki/ari ids.
[01:46] <smoser> yeah, theres almost no real reason to not do that right now
[01:46] <smoser> as we can just delete private ones with no harm
[01:46] <cjwatson> we do that kind of pre-publishing with the ISO images too
[01:46] <cjwatson> different implementation but same goal
[01:47] <smoser> slightly different implementation :) full of a lot less slop
[01:48] <cjwatson> what I mean really is that there's already a "pre-publish stuff" slot in the schedule, to an extent
[01:48] <smoser> right.
[02:39] <TheMuso> Hrm. Is it known that usplash doesn't pulsate when asking for the encryption passphrase, or is that what is wanted now?
[02:41] <TheMuso> Seems not.
[03:02] <avb> guys, new bugfix release of a webkit is out
[03:03] <avb> hope its not too late for an update
[03:05] <avb> also can somebody update midori to 0.2?
[03:08] <sladen> avb: https://wiki.ubuntu.com/KarmicReleaseSchedule  upstreamversionfreeze was a little while ago (Ubuntu is releasing in a week and a half!)
[03:09] <avb> sladen: but as i know during this time its still allowed to upload minor updates, no?
[03:10] <avb> issue is that 1.1.15.2 contains couple bugs which leads to crash and cosing some usability problems which was fixed in 1.1.15.3
[03:10] <avb> this is just a bugfix release, no new features of code changes was introduced
[03:10] <avb> all is kept for 1.1.16
[03:12] <porthose> avb, then submit a FFe https://wiki.ubuntu.com/FreezeExceptionProcess good luck :)
[03:12] <avb> porthose: thanks for a link
[03:12] <avb> ill try
[03:13] <avb> porthose: same policy goes for universe as well?
[03:14] <porthose> they are different for main and universe read the doc :)
[03:14] <avb> yes, i see now :)
[03:15] <ajmitch_> as long as it's just bugfixes, you have a chance of getting changes in
[07:11] <RPG_Master_> I had an Idea and the guys in #ubuntu-offtopic suggested I tell everyone here
 When you go to make a file Public, Ubuntu should ask "Which are you going to be sharing this with, Windows or Linux?" Then decide which to install, gShare or Samba
[07:15] <RAOF> RPG_Master_: Why not just unconditionally install samba?  What does setting up a FTP server & advertising it via zeroconf get you over just setting up a CIFS share?
[07:19] <RPG_Master_> RAOF: It's FLOSS....
[07:19] <RAOF> So's samba.
[07:19]  * RPG_Master_ is 15 with no coding experience
[07:19] <RPG_Master_> :/
[07:19] <RPG_Master_> sorry for waisting your time :(
[07:20] <RAOF> No problem.
[07:20] <RAOF> It's not a waste of time if it ends up being interesting :)
[07:20] <RPG_Master_> RAOF: so there is no benefit over Samba?
[07:21] <RAOF> It probably has fewer buttons to tweak.
[07:21] <RAOF> But I don't think it's got any obvious advantages, no.
[07:21] <RPG_Master_> I just kinda assumed because samba is based off of a Microsoft product there must be a better way of doing file sharing...
[07:23] <RAOF> Not really.  CIFS works.
[07:23] <RPG_Master_> RAOF:  Well, thanks. At least I learned something :P
[07:23] <RAOF> There's plenty of useful, good, Microsoft technology.  Just because it's Microsoft's, doesn't mean it's bad :).
[07:24] <slangasek> samba isn't based off a Microsoft product; it's protocol-compatible with Windows filesharing
[07:24] <RPG_Master_> Ah, so it was just used by Windows?
[07:24] <slangasek> the protocol isn't even Microsoft's, it's IBM's ;)
[07:24] <RPG_Master_> :P
[07:24] <slangasek> (with a few decades of embrace-and-extend piled on...)
[07:24] <RPG_Master_> Which is why its good :P
[07:25] <RAOF> slangasek: Heh.  You learn something new every day :)
[07:25] <RPG_Master_> RAOF: really :P
[07:25] <slangasek> RAOF: somewhere there's a history of the fact that when Samba was getting started, it was because Tridge wanted to use it for connecting to *Unix* machines; then someone came along and said "oh hey, this works with Windows too!"
[07:25] <spm> I miss some of the features that decnet had that went walkies when nt3 etc came out. ms-net v1 was embraced and extended by all sorts of companies.
[07:26] <spm> gah. s/decnet/pathworks/
[07:26] <RPG_Master_> Well then, we should change the name of the network folder to, say "Network Folders"
[07:26] <RPG_Master_> :P
[07:26] <RPG_Master_> Instead of Windows Folders
[07:27] <RPG_Master_> Wait
[07:27] <RPG_Master_> *Windows Networks
[07:28] <slangasek> true, we should
[07:28] <slangasek> I think that warrants a bug on the gvfs-backends package
[07:31] <RPG_Master_> slangasek: Hey, I think I just contributed to Ubuntu :D
[07:31] <slangasek> RPG_Master_: thanks :)
[07:42] <RPG_Master_> Well, I am glad I could contribute *something* to ubuntu after all that its done for me... I want to hurry up and learn python so I can do more! :)
[07:54] <pitti> Good morning
[07:54] <pitti> slangasek: AMIs> the previous images didn't have AMIs, so I just added the build timestamps; I'm more educated now
[07:55] <slangasek> pitti: morning
[07:55] <slangasek> pitti: EC2 images /always/ have AMIs, they may just not have been posted there :)
[07:55] <pitti> slangasek: ... in the tracker, I meant
[07:55] <slangasek> (s/may just not have been/weren't/)
[07:56] <pitti> yeah, I was just confused
[08:19] <liw> hmm... this has happened twice now: something keeps adding a second keyboard layout to GNOME (US, in addition to my native Finnish), and then switching to it; I've deleted the US layout yesterday, and it's back today
[08:20] <liw>  any suggestions?
[09:03] <pitti> liw: did you have US selected in gdm?
[09:03] <liw> pitti, no. the keyboard layout changed on the fly, suddenly, in the middle of typing
[09:03] <liw> (not that I know of, that is; if it's US there, I didn't choose it)
[09:04] <liw> (stupid US keyboard layout, not fit for humans ;-)
[09:04] <pitti> it's the best ever for programmers :)
[09:04]  * pitti switched from de to us a few years back
[09:04] <pitti> suddenly vim, C, LaTeX etc. were so much easier :)
[09:05] <pitti> liw: anyway, could you check this:
[09:05] <pitti> gconftool -g /desktop/gnome/peripherals/keyboard/kbd/layouts
[09:05] <pitti> this probably has fi and us right now
[09:05] <pitti> liw: reset it with gconftool -u /desktop/gnome/peripherals/keyboard/kbd/layouts
[09:05] <liw> produces [fi] but since I've already removed the extra layout, that is not surprising
[09:05] <pitti> then log out, back in, and make sure that you select fi in gdm
[09:05] <pitti> liw: or just keep it as it is, and log out/in with fi selected in gdm
[09:05] <pitti> does either of those add us/
[09:06] <pitti> ?
[09:06] <liw> why does it matter what I have in gdm, since it worked fine for hours?
[09:06] <pitti> liw: we had a recent change in gdm which fixed the selection of keyboard layouts that you pick in gdm
[09:06] <pitti> liw: it was really spontaneously added while gnome was running?
[09:06] <liw> yes
[09:06] <liw> er
[09:06] <pitti> or it was there all the time and you just didn't notice?
[09:06] <seb128> pitti, he said that the layout changed during session use
[09:06] <pitti> seb128: well, that's not the same
[09:06] <liw> the layout changed in the middle
[09:07] <pitti> you could accidentally press both alt keys or so
[09:07] <liw> I don't know if the us keyboard was there from the beginning
[09:07] <seb128> pitti, right
[09:07] <pitti> it doesn't prove that the new layout was _added_ to the gconf key
[09:07] <liw> pressing both alt keys does not seem have an effect
[09:07]  * fatal^ switches keyboard layout on both-shift .... don't know if it's the default.
[09:07] <pitti> liw: system -> prefs -> keyboard -> layouts -> layout settings can set a key combination for switching layouts
[09:08] <pitti> fatal^: I believe nothing is the default
[09:08] <liw> hm, gdm did have us as they default layout, how stupid of it
[09:09] <liw> pitti, there is no key combo defined for switching layouts
[09:09] <liw> (which is good, since if there were, I would be hitting it randomly and tearing my hair out)
[09:10] <liw> if I choose US layout in gdm, and log in, I have US layout
[09:11] <liw> however, that's not what happened this morning: I was typing happily for hours when it suddenly changed in the middle of a word
[09:12] <liw> in the middle of a word with letters with umlauts, so less than a second earlier I still had the Finnish layout...
[09:12] <pitti> liw: I meant, if you chose fi layout and didn't have us configured before, do you get us configured in GNOME after that?
[09:13] <pitti> so, I have no idea what could have changed the layout then, I'm afraid
[09:14] <liw> pitti, yeah, it's very mysterious; I'll keep an eye on things and see if I can debug further if it happens again
[09:15] <liw> (too many moving parts and layers in computers these days, and I've put more in myself: keyboard -> kvm switch -> desktop machine -> kernel -> x -> gnome -> synergy -> laptop -> laptop's x/gnome stack *sigh*)
[09:25] <soren> ~[5~[5~/win 43
[09:25] <soren> nice.
[09:26] <seb128> the examples directory on the current iso desktop is a blank document icon, bug?
[09:36] <maxb> What order do I approach people to get a fix into karmic at this point? main-sponsors then release, or the other way around?
[09:39] <pitti> maxb: since it can't go into RC any more, it's best to subscribe ubuntu-release to the bug and nominate it for karmic; you can sub the sponsors at the same time
[09:40] <maxb> OK, sponsors are already subbed, just wasn't sure on the protocol of when to sub ubuntu-release
[09:40] <slangasek> "nominate for karmic" - dunno if you look at that, but I don't
[09:43] <maxb> evidently not, since I've had it nominated for karmic for a long time, and it hasn't garnered it any attention
[09:43] <slangasek> yes, anybody can nominate, so nominations are really just noise today
[09:44] <maxb> Sad, but given I don't have a suggestion how to fix it, I can't really complain.
[09:45] <pitti> slangasek: I do if I get bug mail through u-release subscription
[09:45] <slangasek> pitti: right, but the subscription's the important thing then, not the nomination :)
[09:45] <seb128> pitti, want to win quite some CD space?
[09:45] <pitti> but I don't watch the nomination bug list in general, indeed
[09:45] <pitti> seb128: gimme, gimme, gimme!
[09:45] <seb128> pitti, seems gnome-games documentation has not been langpacked for some reason
[09:45] <pitti> seb128: you're proposing to replace GNOME with XFCE?
[09:46] <seb128> and that's quite some images there
[09:46] <pitti> :)
[09:46] <seb128> I'm running baobab on the current iso
[09:46] <slangasek> replace gdm with startx
[09:46] <slangasek> /etc/init/startx.conf
[09:46] <seb128> it's like 10 megs of documentation, if it was in langpack we could win some
[09:47] <pitti> we aren't under serious space pressure for karmic, so I woudln't throw a lot of effort on it
[09:47] <pitti> but if it's cheap, why not
[09:47] <pitti> (like, a no-change rebuild)
[09:47] <seb128> well, I'm wondering if it's just a matter of rebuild
[09:47] <seb128> but it was uploaded on september 24
[09:47] <seb128> but it was uploaded on september 24 which should be after your change
[09:47] <pitti> but we can only do that if we're actually going to update langpacks again
[09:48] <seb128> is there any way to see from the build log if the stripper was in place?
[09:48] <pitti> sure
[09:48] <seb128> oh right
[09:48] <seb128> pitti, http://launchpadlibrarian.net/32242856/buildlog_ubuntu-karmic-i386.gnome-games_1%3A2.28.0-0ubuntu1_FULLYBUILT.txt.gz
[09:48] <seb128> ^ build log
[09:49] <slangasek> are we assured of having time to get the translations back into the final langpack export for release if we do that?
[09:49] <seb128> hum
[09:49] <seb128> "pkgstriptranslations: gnibbles does not contain translations, skipping"
[09:50] <seb128> weird
[09:50] <seb128> oh, translations, dog
[09:50] <seb128> doh
[09:50] <seb128> ignore that
[09:50] <pitti> slangasek: the condition for that is that the langpack build is started after gnome-games finished to build on at least one arch
[09:51] <pitti> (it doesn't go through Rosetta, it's just parked in soyuz)
[09:51] <seb128> well it's not worth bothering if we don't have anything to put on the CD instead anyway
[09:51] <seb128> but if we could add some extra langpacks...
[09:51] <pitti> ArneGoetje: did you schedule another langpack export/build over the weekend?
[09:51] <slangasek> pitti: oh, really?
[09:51] <pitti> seb128: yeah, it'd just be an extra langpack
[09:52] <pitti> slangasek: yes, it just uses launchpadlib to grab the built stuff straight from the librarian, which has it seconds after the build finished
[09:52] <pitti> so, I think we should consider updating the langpacks again independently
[09:53] <pitti> and if we do that, we could just as well do the rebuild, but then only on Friday
[09:53] <slangasek> pitti: doesn't that mean translators also have no opportunity to extend/fix these translations?
[09:53] <pitti> slangasek: correct; at least not in Rosetta, only by patching
[09:53] <pitti> slangasek: long term this should be fixed, of course
[09:54] <pitti> but given how documentatino translation works right now, it's a major project
[09:54]  * slangasek nods
[09:54] <pitti> i. e. their po files could be imported and changed in Rosetta, but you'd have to add them to the source package
[09:55] <pitti> since documentation is translated at build time
[09:55] <slangasek> sure
[09:55] <pitti> slangasek: and then we of course need rosetta support for "translating" images :)
[09:55] <slangasek> just make sure the images are all svg, and use po4a <cackle>
[09:57] <pitti> seb128: hm, I think this case is a pkgstriptranslations bug
[09:57] <pitti> I don't think we should mess with it in karmic any more
[09:57] <seb128> right
[09:57] <seb128> we don't really need to win space now anyway
[09:57] <seb128> but would be nice to fix next cycle
[09:57] <seb128> pitti, do you want me to file a bug?
[09:58] <seb128> in which case what do I write in the bug? ;-)
[09:58] <pitti> also, _shht_ we still need some potential savings up our sleeve for further releases :-P
[09:58] <seb128> lol
[09:58] <pitti> seb128: "gnome-games help not stripped", and a pointer to the build log should suffice
[09:58] <seb128> pitti, ok thanks
[10:04] <seb128> pitti, bug #457027
[10:05] <pitti> seb128: merci
[10:06] <seb128> pitti, de rien
[10:51] <apachelogger> asac: what do we do about the firefox installer?
[10:52] <asac> apachelogger: not sure.
[10:52] <asac> apachelogger: question is what _can_ we do
[10:52] <asac> apachelogger: you think you can upload a package with all .po things sedded?
[10:52] <asac> for after RC?
[10:53] <asac> we should definitly check with Riddell
[10:54] <apachelogger> well, I could push a package with string changes, utc could probably update the existing translations to match new template
[10:54] <apachelogger> dpm: ping
[10:58] <dpm> hey apachelogger
[10:58] <dpm> it's about the above?
[11:00] <apachelogger> dpm: aye
[11:00] <dpm> if you upload a new package and it contains translations and a new template, they should be imported automatically, but you can ping us to double-check
[11:01] <asac> have to run some errands
[11:01] <asac> bb in 2h
[11:01] <apachelogger> dpm: is there some tool to export all existing pos of a package?
[11:03] <dpm> apachelogger, Launchpad can do that (exporting a tarball with all PO files). As the project maintainer you should be able to do that (let me give you the link). If you can't, you might be hitting bug 425578, in which case I can do the download for you, if you like
[11:07] <dpm> apachelogger, try this link -> https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+export (it's from the main template page at https://translations.edge.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/)
[11:07] <apachelogger> dpm: thanks :)
[11:08] <dpm> np
[11:08] <dpm> just let me know if there is anything else I can do
[11:09] <dpm> apachelogger, also, now that I've got you here, do you think you could have a look at bug 439964?
[11:09] <apachelogger> huh
[11:24] <apachelogger> dpm: http://aplg.kollide.net/images/osiris/snapshot047.png
[11:24] <apachelogger> i'll incorporate the fix in the upload
[11:25] <apachelogger> it's a one-liner anyway :D
[11:25] <dpm> apachelogger, awesome, thanks
[11:48] <seb128> hum
[11:48] <seb128> is the "use the full disk to install" supposed to create a swap too?
[11:48] <seb128> I got a "swap mounting failed" dialog asking if I want to change the partitions or continue
[11:50] <cjwatson> seb128: it should create a swap partition
[11:53] <seb128> cjwatson, http://people.canonical.com/~seb128/install.png
[11:53] <seb128> cjwatson, any hint on how to get details about the issue?
[11:55] <wolfe> wonderful
[11:55] <wolfe> seb128: check the logs?
[11:55] <cjwatson> blink, that's weird
[11:55] <seb128> wolfe, what log?
[11:55] <cjwatson> seb128: /var/log/syslog, /var/log/partman
[11:55] <seb128> cjwatson, thanks
[11:56] <seb128> invalid argument error
[11:56] <cjwatson> or 'ubuntu-bug ubiquity' from inside the live environment, after exiting the installer
[11:56] <seb128> swapon: /dev/sda5: erreur de lecture de l'entête de zone d'échange (swap)
[11:57] <seb128> and the error is "invalid argument"
[11:58] <seb128> cjwatson, ok, will open a bug, thanks
[11:58] <cjwatson> "read swap header failed"
[11:58] <wolfe> seb128: interesting..
[11:59] <wolfe> seb128: you are using a new hard drive? what brand?
[11:59] <cjwatson> (on something that's just been mkswapped)
[11:59] <wolfe> also, is the swap at the very end of the hard drive?
[12:00] <wolfe> I had an issue which was fairly common in certain hard drives where the space assigned didn't match the actual physical capacity. I'd receive such an error when it tried to read/write to the hard drive space which didn't exist.
[12:00] <wolfe> or your hard drive could be going bad as well. :)
[12:00] <cjwatson> or it could be an installer bug
[12:00]  * cjwatson is happy to blame hardware but not as a first resort. :-)
[12:01] <wolfe> cjwatson: if ithe hard drive is hitachi/ibm, I blame it first
[12:02] <wolfe> or maxtor
[12:02] <cjwatson> I don't, because that's a recipe for missing installer bugs until it's too late.
[12:08] <seb128> cjwatson, wolfe: it's a kvm with a .img
[12:08] <seb128> ie not real hardware
[12:08] <wolfe> It still uses real hardware, heh
[12:09] <wolfe> makes me want to ask if you're using software raid
[12:09] <seb128> well I've no issue on my laptop out of that kvm install one
[12:09] <seb128> doesn't mean it's not a hardware issue though
[12:09] <seb128> I will retry before opening a bug
[12:10] <cjwatson> if you have the logs, I'd prefer you opened a bug now before losing the evidence
[12:11] <cjwatson> if it's not consistently reproducible, so be it, maybe we'll have to close it
[12:15] <seb128> cjwatson, bug #457099
[12:16] <seb128> cjwatson, do you need any extra details before I try again?
[12:22] <cjwatson> seb128: a detailed description of how you got into this situation, from kvm disk initialisation, would be good :)
[12:22] <cjwatson> seb128: it looks to me as if, when you started up this instance of the installer, kvm was unable to recognise the previous swap partition as a swap partition; I wonder if that's related
[12:22] <cjwatson> err s/kvm/libparted/
[12:23] <cjwatson> seb128: also can you reproduce the error with 'sudo swapon /dev/sda5' from the command line?
[12:26] <doko__> bug 436617
[12:28] <seb128> cjwatson, ok, I added a comment to the bug, the kvm img I used had issues (ie wouldn't boot after a recent update) so maybe it's corrupted, I was expecting the use full disk to just reset it and make a clean install but maybe it's wrong expectation
[12:28] <cjwatson> I think that is a sound expectation
[12:28] <cjwatson> normally speaking anyway
[12:28] <seb128> cjwatson, the desktop seems frozen after some gstreamer codec install though so I can't try the swapon, I will reboot the image
[12:30] <rio> hi, i just came across a bug, that has been reported 2 years ago, but it's still unassigned, what is going on? :S
[12:31] <rio> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/91389
[12:32] <seb128> cjwatson, right, a swapon gives the same issue, the swap partition is screwed
[12:34] <cjwatson> rio: too many bugs and not enough developers
[12:35] <rio> :( i might check out the source and see what i can do next week
[12:47] <seb128> example-content should really have an icon the the Examples desktop entry
[12:47] <seb128> the white paper icon on karmic looks weird
[12:59] <seb128> cjwatson, anything else required on this swap issue before I redo the partionning manually to workaround the issue?
[13:01] <cjwatson> seb128: no, I don't think so
[13:01] <seb128> cjwatson, ok thanks
[13:03] <Keybuk> swap issue?
[13:05] <seb128> Keybuk, corrupted swap partition breaking ubiquity install
[13:06] <Keybuk> ah
[13:06] <seb128> I though that a take over disk install would redo partitions too
[13:06] <seb128> but apparently it doesn't
[13:06] <seb128> and breaks on trying to swapon the corruption swap there
[13:06] <seb128> corrupted
[13:07] <cjwatson> it *does* redo the partitions actually, I can see that in the log
[13:08] <seb128> weird that the partition is still corrupted then
[13:09] <cjwatson> maybe not hard enough, or maybe there's a bad block under the .img file and nothing is noticing, or something; but it's definitely trying
[13:09] <asac> apachelogger: so you found a solution?
[13:26] <Keybuk> cjwatson: thought
[13:26] <Keybuk> cjwatson: ssh shouldn't cache IP address hosts thingies for .local names
[13:32] <Keybuk> sladen: about?
[13:36] <pitti> Keybuk: hi
[13:37] <pitti> Keybuk: are you okay with the proposed solution in bug 428435? (comment 50)
[13:37] <Keybuk> pitti: no, that will only lead to data corruption
[13:38] <Keybuk> and frankly, screwing around with partition detection this close to release is a BAD IDEA
[13:38] <pitti> I'm open for better suggestions
[13:38] <pitti> but given that vol_id behaved like that since hardy at least, it seems to be the safest option right now
[13:38] <pitti> I don't think we can squeeze in a proper migration solution at this point?
[13:39] <Keybuk> why bother with a migration solution?
[13:40] <Keybuk> this is one of those bugs that'll bite hard
[13:40] <Keybuk> because you'll stop detecting valid ext4 partitions as a result
[13:40] <seb128> hum
[13:40] <seb128> ubiquity hates kvm there today or something
[13:41] <seb128> I did rm the .img, created a new one using kvm-img and I still get install failure
[13:42] <pitti> Keybuk: no, we don't
[13:43] <pitti> Keybuk: migration> because you dist-upgrade your server and then it can't boot any more; not good
[13:43] <pitti> Keybuk: if there was a case where mkfs.ext4 over luks ever left enough traces of luks, this would have broken in hardy
[13:44] <Keybuk> we never migrated any other filesystem type this way
[13:44] <Keybuk> there are numerous "my filesystem was fat and is now ext4" type bugs since hardy
[13:44] <Keybuk> I just tell them to go away
[13:44] <pitti> correct
[13:44] <pitti> but so far we tolerated exactly that for luks-over-ext
[13:45] <pitti> and karmic is the very first release whose cryptsetup behaves correctly finally
[13:45] <pitti> (cf. the looong discussion we had in #u-release this morning with slangasek)
[13:45] <Keybuk> this is surely fixable with a quick perl script, no?
[13:46] <Keybuk> to zero the bits of the superblock that luks doesn't use
[13:46] <pitti> I 100% agree that cryptsetup was buggy, and that blkid should behave the way it does now
[13:46] <Keybuk> sounds a lot less hairy than rewiring blkid, with all the unexpected consequences you can cause
[13:46] <pitti> but we can't go from "four releases broken" to "we reject existing installs" without at least offering some help to affected users
[13:47] <Keybuk> sure, but wouldn't that help be better if it was help to fix their broken filesystem image
[13:47] <Keybuk> rather than just carrying on honouring it
[13:47] <pitti> sure
[13:47] <pitti> that's why we proposed to do exactly that for lucid
[13:47] <pitti> I don't want to keep that blkid behaviour forever
[13:48] <Keybuk> right, but why not do it for karmic?
[13:48] <pitti> -EINTRUSIVE?
[13:48] <pitti> it needs carefully engineered/tested initramfs scripts at least
[13:48] <pitti> which wouldn't even address broken USB sticks, etc.
[13:48] <Keybuk> err
[13:48] <Keybuk> you don't have to do that
[13:48] <Keybuk> you can just have it available and give it to anyone affected
[13:48] <pitti> and not just initramfs (for root), but also in mountall (for encrypted /home etc.)
[13:49] <Keybuk> this is a lot less intrusive than major rewiring of our filesystem detection library
[13:51] <pitti> Keybuk: you still need the logic to detect that at various places, like initramfs, init script, dk-disks/gnome/etc.
[13:51] <seb128> cjwatson, I did apport-collect on https://launchpad.net/bugs/457099 for installation breaking using a new kvm-img just created do you think it's the same issue?
[13:51] <seb128> cjwatson, ie local disk issue or something?
[13:51] <Keybuk> you're saying that a quick perl script for anyone effected by the bug is somehow worse than rewriting code which can have unforseen consequences
[13:51] <pitti> Keybuk: since right now it just silently breaks
[13:51] <pitti> Keybuk: it's not unforeseen; it just restores the behaviour that we shippped for several releases
[13:51] <Keybuk> pitti: no you don't; we don't have that logic for any of the other problems
[13:52] <Keybuk> pitti: you're not understanding me
[13:52] <Keybuk> blkid is *complex* code
[13:52] <Keybuk> this is not a one line fix
[13:52] <Keybuk> in previous releases we had *different* code
[13:52] <Keybuk> it's not a matter of reverting a patch, or porting a patch
[13:52] <pitti> well, I wrote a thorough test script and am just looking into the code
[13:52] <Keybuk> you would have to make some fundamental changes to blkid
[13:52] <slangasek> Keybuk: a "quick perl script" is a lot less helpful to the affected users, most of whom will discover the problem only after rebooting to karmic, and if they have any partitions that get decrypted post-initramfs, they won't even be able to boot the old kernel to recover
[13:52] <Keybuk> pitti: does your test script cover any cases that do not include luks or ext4?
[13:53] <Keybuk> slangasek: it's a lot better than (say) breaking everyone who uses lvm right before release
[13:53] <pitti> see bug; I tested luks/ext[234]/swap/vfat; I don't want to touch behaviour of everything except luks
[13:53] <Keybuk> changes to blkid tend to have that effect
[13:53] <Keybuk> pitti: that's my point
[13:53] <Keybuk> changes to blkid tend to affect everything
[13:53] <pitti> right, that's my intention :)
[13:53] <Keybuk> one minor change to one prober has unforseen knock-on effects on the other probers
[13:53] <slangasek> bleh, why is blkid this brittle?
[13:53] <pitti> we'd fix initramfs/boot/dk-disks all at the same time
[13:54] <Keybuk> slangasek: because what it's doing is brittle
[13:54] <pitti> with the "if you see luks, stop detecting" change (pretty much what vol_id did)
[13:54] <Keybuk> slangasek: it is examining a block device for a unique signature
[13:55] <pitti> also, we have an internal test suite, now an external test script, and an image which reproduces this problem from a user
[13:55] <Keybuk> I don't care about fixing the problem, and testing that the fix is successful
[13:55] <Keybuk> I care about everything else you break in the process
[13:56] <pitti> well, that's pretty much what already happened; new blkid breaks systems which worked before
[13:56] <slangasek> Keybuk: but it's the *existing* behavior that consists of "if it matches more than one prober, curl up in a ball and rock in the corner"; how can any possible change be more brittle than the current behavior? :P
[13:56] <pitti> and while admittedly they were broken to begin with, that makes little difference to upgraders who suddenly have a broken installation
[13:57] <pitti> slangasek: well, if you detect two you might pick the wrong one and destroy data
[13:57] <Keybuk> slangasek: that code is there for a reason
[13:57] <pitti> but we already discussed that for this reason we shoul djust restore the "luks > everything else" special case
[13:57] <pitti> since we know that luks was broken in the past
[13:57] <Keybuk> take the FAT vs. ext4 issue
[13:57] <slangasek> pitti: the proposal to change blkid at all is predicated on the notion that we it's possible to know what the right one is
[13:57] <Keybuk> if you accidentally pick FAT when it was ext4, you screw the ext4 filesystem
[13:58] <Keybuk> if you accidentally pick ext4 when it was FAT, you screw the FAT filesystem
[13:58] <pitti> sure
[13:58] <Keybuk> the problem is, over time, we tended to favour one or the other
[13:58] <pitti> we all agree on those
[13:58] <Keybuk> and then realised we were just bouncing between two different equal sized groups of people
[13:58] <slangasek> Keybuk: yes, it's there because upstream punted by generalizing from cases where there's no right answer
[13:58] <pitti> Keybuk: I doubt that they are equal-sized for luks/ext
[13:58] <Keybuk> there are just as many people who mke2fs over a FAT filesystem (hard drive installs) as those who format ext disks as FAT (usb keys)
[13:59] <pitti> Keybuk: I already demonstrated that ext* has not had that problem for years
[13:59] <Keybuk> pitti: luks/swap is pretty common
[13:59] <Keybuk> pitti: as is luks/anything else lvm
[13:59] <pitti> whereas our isntaller used the broken cryptsetup since at least gutsy
[13:59] <primes2h> mvo: Hello, could you have a look at this bug #344693 about update-manager please? :)
[14:00] <Keybuk> slangasek: if you think blkid's behaviour is wrong, then supply patches to fix it, and an address to receive all the bug reports ;)
[14:00] <Keybuk> and promise that you will fix them all
[14:00] <slangasek> nobody promises to fix all bug reports :P
[14:00] <Keybuk> it comes with a free life-long contact with Ted Tso ;)
[14:01] <slangasek> how about: I think its behavior is wrong, so I'll write a scathing blog entry ;)
[14:01] <pitti> Keybuk: we did not say that blkid's behaviour is wrong
[14:01] <Keybuk> pitti: going back through LP, LUKS vs. swap is the favourite case
[14:01] <pitti> well, at least I don't say that
[14:01] <slangasek> pitti: heh, I did
[14:01] <Keybuk> slangasek: haha :p
[14:02] <Keybuk> I think he already did
[14:02] <mvo> primes2h: I have seen it. it requires unfuzzying a lot of translations
[14:02] <pitti> Keybuk: my point is just to keep it wrong for karmic, to avoid having to rip apart several places to deal with the fallout
[14:02] <cjwatson> seb128: it looks the same, but I haven't debugged it yet. What kvm-img format are you using, out of interest?
[14:02] <Keybuk> pitti: and my point is, due to way the code works, I don't think it's easy to keep it wrong without causing more problems
[14:02] <seb128> cjwatson, just "kvm-img create karmic.img 6800MB"
[14:03] <seb128> cjwatson, whatever default format that is
[14:03] <cjwatson> ok, I've been using -f qcow2 myself
[14:03] <primes2h> mvo: do you mean we are not in time to do this because the tomorrow deadline?
[14:03] <Keybuk> pitti: you'd certainly have to reopen the dozen or so "my swap partition is detected as LUKS" bugs
[14:04] <mvo> primes2h: timming is not ideal. I wil try to get to it today
[14:04] <primes2h> mvo: ok, thank you very much indeed. :)
[14:05] <mvo> primes2h: I requested a LP export now for the unfuzzing
[14:05] <Keybuk> slangasek: OOI, how do you think it should work?
[14:07] <slangasek> Keybuk: given that no LUKS partition *can* be activated without external configuration telling how to decrypt it (i.e.: /etc/crypttab), I think in all cases it's safe to prefer LUKS over * if the alternative is returning no UUID at all
[14:08] <lilli> hi
[14:08] <liw> is it a policy decision that the ubuntuone-client* packages get forcefully added upon upgrade from jaunty?
[14:09] <Keybuk> slangasek: but then that would you get bugs like "I reformatted by old LUKS partition, and it's still detected as LUKS" :)
[14:09] <pitti> liw: that's the case for every upgrade; ubuntu-desktop dependencies determine what gets newly installed
[14:09] <lilli> I was looking to create a bot that automatically runs debuild... How can I force debuild to be executed without asking anythings?
[14:09] <Keybuk> or, more annoyingly
[14:09] <Keybuk> "I repartitioned my disk, and a LUKS signature just happens to be at exactly the wrong point, and /usr doesn't mount"
[14:09] <pitti> Keybuk: but that just means that the other mkfs is _also_ broken
[14:09] <pitti> Keybuk: and if it is, it'd be broken with current blkid as well
[14:09] <Keybuk> sure, this is exactly why we punted this problem to the mkfs tools
[14:10] <Keybuk> hmm
[14:10] <slangasek> Keybuk: "and /usr doesn't mount" - that doesn't seem to be a regression over the current behavior, though
[14:10] <Keybuk> though I think slangasek is partially right here
[14:10] <Keybuk> at least with crypto filesystems, there's no danger of mounting as the wrong type and having the mount succeed
[14:10] <Keybuk> which is what the code is trying to guard against
[14:10] <liw> pitti, even for recommends? that's pretty suboptimal :(
[14:10] <Keybuk> in that case, it fits in with RAID
[14:10] <Keybuk> (also no danger)
[14:11] <pitti> liw: recommends are pretty much dependencies, yes; and a lot of new stuff that you probably want are recommends as well
[14:11] <Keybuk> yes, I think slangasek gets +1 insightful
[14:11] <Keybuk> http://people.canonical.com/~scott/slangasek.patch
[14:11] <Keybuk> ^ now that *is* a one line fix
[14:11] <pitti> that's why we just want to reintroduce the luks special case, no anything else (ext4 vfs. fat or so)
[14:11] <liw> pitti, I'd like a solution that lets me remove a package and not get it forced one me on upgrades, but I see the problem that our dependency tools aren't up to it right now
[14:12] <jdstrand> slangasek: do I need to tag/nominate/milestone a bug in any particular way for ubuntu-release-notes to make sure you see it for karmic?
[14:13] <slangasek> jdstrand: just needs to have a task open on that project
[14:13] <jdstrand> ok
[14:13] <slangasek> jdstrand: extra points for offering some text :)
[14:14] <jdstrand> slangasek: :)
[14:14] <pitti> Keybuk: hm, I had expected to set BLKID_IDINFO_TOLERANT in ./shlibs/blkid/src/probers/luks.c
[14:14] <liw> other issue I had with my upgrade just now: upon first login, epiphany wanted permission to access every password I had stored, even though I wasn't accessing any sites that required passwords; a) having to answer the same question for dozens of passwords separately is a tad annoying b) why does it want those passwords in the first place?
[14:14] <Keybuk> pitti: that wouldn't have worked
[14:14] <Keybuk> pitti: both filesystems have to be tolerant
[14:14] <pitti> Keybuk: but I guess your approach of considering usage instead of fs is nicer
[14:18] <primes2h> mvo: great!
[14:18] <pitti> Keybuk: oh? blkid_do_safeprobe() just treats it as a boolean (anyway, I didn't test that yet, it was just what I was about to try)
[14:18] <pitti> with that patch, ./test-luks-blkid.sh succeeds again
[14:18] <pitti> $ blkid -p /tmp/ext3-luks.img
[14:18] <Keybuk> pitti: any intolerant detected filesystem will set intol
[14:18] <pitti> /tmp/ext3-luks.img: UUID="fa583620-b1ef-448c-b4c3-7aaa794849f8" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
[14:19] <Keybuk> so if you have two matches, and one of them is intolerant, you get the ambivalent result
[14:19] <pitti> and it also detects the previously broken image now
[14:19] <Keybuk> thus LUKS + ext4, if LUKS is marked tolerant, ext4 isn't so it'd fail
[14:19] <pitti> Keybuk: ah, right, read it backwards
[14:20] <pitti> Keybuk: so, with this patch it passes internal test suite and my two tests
[14:21] <pitti> mkswap seems to clean up the superblocks properly, I didn't notice breakage there in karmic (but did in hardy/jaunty)
[14:21] <Keybuk> ok, sent the patch upstream
[14:22] <pitti> Keybuk: oh, you want to keep it permanently? I assumed it'd be a tempoprary workaround until we can offer tools to point out the problem and fix it on your partitions?
[14:22] <Keybuk> it fits the pattern
[14:23] <Keybuk> we break out of RAID there because you need to activate them so you can't do too much damage
[14:23] <slangasek> well, this is hardly an Ubuntu-local problem, I think it ought to be upstream
[14:23] <Keybuk> slangasek is right that the same applies to crypto too
[14:23] <Keybuk> and the crypto probers are lumped in with RAID in that section
[14:29] <pitti> Keybuk: do you want to do the upload or shall I?
[14:29] <Keybuk> I'm doing it
[14:29] <Keybuk> since I bet you don't have git set up ;)
[14:29] <pitti> not for util-linux
[14:30] <pitti> ok, thanks
[14:30] <pitti> ah, no debian/patches/
[14:30] <Keybuk> no, it's maintained in git ;)
[14:32] <Keybuk> (one of the few cases where the Debianish Vcs header is actually correct in Ubuntu's case too)
[14:33] <Keybuk> kees: about?
[14:43] <primes2h> mvo: BTW, this ( bug #456115) is even worse as bug concerning translations but we are too late now I think.
[14:50] <LaserJock> slangasek: would it be possible to get an Edubuntu rebuild today?
[14:51] <slangasek> LaserJock: certainly possible, but not something I would particularly advise - what's up?
[14:51] <apachelogger> asac: aye, though, I need all sorts of freeze exceptions and a trademark exception from TB, so that the installer can ship the proper logo
[14:51] <tseliot> Keybuk: who can I ask about what we should/could use to set the background at boot? Does the DX team deal with this?
[14:51] <Keybuk> I think so
[14:52] <LaserJock> slangasek: looks like cjwatson fixed bug #452429
[14:52] <slangasek> LaserJock: ah, right
[14:52] <asac> apachelogger: pleaes open bugs on the things
[14:53] <asac> so i can comment
[14:53] <mvo> primes2h: you should talk to cr3 about the checkbox bug, maybe its not too late
[14:53]  * apachelogger first needs to find out which freezes we are exactly in right now :D
[14:53] <primes2h> mvo: ah, ok. Thanks. :)
[14:54] <slangasek> LaserJock: rebuilding now
[14:54] <LaserJock> slangasek: awesome, thanks
[14:54] <LaserJock> slangasek: do you know roughly how long those take?
[14:55] <slangasek> LaserJock: I have no estimate for how long it'll take to build, though, since cjwatson has specifically changed the type of livefs build we're doing
[14:55] <LaserJock> k
[14:55] <slangasek> for all I know, this will blow up horribly with an oversized livefs or something
[14:55] <LaserJock> heh
[14:55] <LaserJock> I hope not
[14:56] <apachelogger> asac: btw, bug 439431 ... I am still thinking that conflicts&replaces from the firefox side of things would be most reliable
[14:56] <primes2h> cr3: Hello, Could you have a look on this bug #456115? It's quite a blocking one.
[14:56] <asac> apachelogger: i would just open a single bug with RC freeze exception + UI exception
[14:57] <primes2h> cr3: Re-trying bug #456115
[14:57] <primes2h> uff
[14:58] <primes2h> cr3: bug #456115
[14:58] <asac> apachelogger: just replaces would probably work too
[14:58] <asac> apachelogger: ship same .desktop file ... replace ... and when firefox gets uninstalled it reappears
[14:58] <cr3> primes2h: is it simply a question of grabbing the .po files from launchpad?
[14:59] <primes2h> cr3: ehm, no. po file in fully translated.
[14:59] <primes2h> cr3: but those strings are not present
[14:59] <cr3> primes2h: ah, let me have a look then
[15:00] <primes2h> cr3: in fact there were strings present in Jaunty but missing in Karmic
[15:00] <ion> keybuk: I was looking at old bootcharts from intrepid and jaunty. They all have the same characteristics, with the HDD spending most of its time seeking. (Low throughput, full utilization).
[15:00] <apachelogger> asac: that however requires installer updates to match latest firefox desktop file + prevents user from using older/newer firefox packages + possibly disrupts the UI appearance of kdesudo (since that thingy will only show icon and proper name if binary name == desktop file name)
[15:00] <primes2h> cr3: and there are other new strings (in Karmic) that are not present at all
[15:01] <asac> apachelogger: not sure what you mean
[15:01] <primes2h> cr3:  I mean in the po's.
[15:01] <asac> apachelogger: we ship firefox.desktop
[15:02] <asac> thats supposely always the same
[15:02] <apachelogger> we do?
[15:02] <asac> yes
[15:02] <apachelogger> oh, I though we had like firefox-3.5.desktop and stuff :)
[15:02] <asac> otherwise your panel launchers would disappear
[15:02] <asac> apachelogger: the non-default firefox branches have versioned desktop files
[15:02] <asac> but the default ... which is what matters -- always ships firefox.desktop
[15:02] <apachelogger> well
[15:02] <asac> apachelogger:  dpkg -L firefox-3.5-branding  | grep desktop
[15:02] <asac> /usr/share/applications/firefox.desktop
[15:03] <apachelogger> it is getitng ugly
[15:03] <asac> imo it would create the user experience you want
[15:03] <apachelogger> changing the desktop file name means changing the desktop file's translation domain
[15:03] <apachelogger> means even more intrusive change :S
[15:03] <asac> apachelogger: ah ok
[15:03] <Keybuk> ion: yeah, my laptop has certainly suffered for a few releases now
[15:03] <asac> apachelogger: note that down for lucid then. not sure if the bug is really that bad that it needs to be addressed
[15:03] <asac> if we know we have a the right approach in lucid
[15:04] <apachelogger> agreed, postpone for lucid then
[15:04] <ion> keybuk: Also, changing the IO scheduler didn’t help.
[15:04] <Keybuk> ion: the kernel team fixed cfq in a recent update
[15:04] <Keybuk> so it doesn't perform worse than deadline again
[15:04] <ion> Ok
[15:05] <cr3> primes2h: strange, it seems that my setup.cfg and POTFILES.in are configured properly, not sure why my .in files aren't being detected
[15:05] <asac> apachelogger: cool. so file a bug about the late change and list what changes this involves .. i will comment that part of these are necessary and try to poke around to get permissions etc.
[15:05] <asac> apachelogger: maybe outline how we get the translation issue resolved diligently at this point
[15:05] <apachelogger> aye aye
[15:05] <asac> thx a lot
[15:07] <primes2h> cr3: really strange. But It should be nice to have it fixed in time for the translation deadline (tomorrow)
[15:08] <cr3> primes2h: I'm still looking into it, I'd like that too
[15:10] <primes2h> cr3: thanks you very much :)
[15:11] <primes2h> -s
[15:12] <apachelogger> asac: bug 457228
[15:20] <asac> ok commented subscribed a few folks
[15:20] <asac> lets see
[15:27] <janito_> hello, I am trying to build an iso using a jaunty deboostrap, the grub meny shows nicely, the kernel gets loaded but I am just dropped into the initramfs prompt, what I am missing ?
[15:32] <cr3> primes2h: I found the problem, I'll be pushing my changes and submitting for an sru shortly
[15:32] <cr3> primes2h: err, I mean ffe.. we're not at sru yet :)
[15:32] <primes2h> cr3: Thank you very much indeed. :)
[15:35] <primes2h> cr3: As soon as the new po are ready, I'm going to traslate the italian one. Thanks again.
[15:35] <slangasek> cr3: submitting for an ffe> you should arrange to upload directly to the freeze queue, to save a round trip with the release team
[15:37] <primes2h> cr3: ...and I'll report it to translator ML.
[15:39] <dconlon> Got directed here from ubuntu-bugs, on booting X hangs at 100% cpu if an xorg.conf exists. Am here for help and can give whatever time you need to debug this. (Full updated install, xorg 1:7.4+3ubuntu7) Perhaps an issue with the fglrx driver(version 2:8.660-0ubuntu4)
[15:43] <cr3> slangasek: how do I do that?
[15:43] <cr3> primes2h: should I upload the .pot file separately or something, or just uploading the new package should be sufficient?
[15:44] <slangasek> smoser: will you take care of ec2 prepublishing for rc, or should I make sure I get that done today?
[15:44] <slangasek> cr3: sponsorship queue?
[15:45] <cr3> slangasek: I'm really clueless, I was just thinking of pinging mathiaz to review which should be pretty quick
[15:45] <slangasek> that's fine
[15:46] <cr3> slangasek: I could even drop by his home right next to the office and pester him in person too :)
[15:46] <Keybuk> kees: what package supplies restorecon?  I can't find it
[15:47] <slangasek> Keybuk: policycoreutils
[15:47] <primes2h> cr3: maybe uploading .pot file separately should be quicker but I'm not sure
[15:48] <smoser> slangasek, i will publish to private today after rounds of testing
[15:48] <slangasek> smoser: ok
[15:48] <slangasek> smoser: thanks!
[15:48] <smoser> no problem. i think its at the point where you *could* do it
[15:48] <smoser> :)
[15:49] <Keybuk> slangasek: should whatever-that-does be done for every mount?
[15:53] <slangasek> Keybuk: I'm not sure
[15:54] <Keybuk> no, me neither
[15:54] <Keybuk> SELinux is not normally high on my "I care" list
[15:54] <Keybuk> but I'm feeling generous
[16:04] <primes2h> cr3: tell me when you have done please so I can go on. Thanks
[16:14] <Keybuk> pitti: could apport-retracer not lookup strings in .mo files and translate files back to English?
[16:14] <Keybuk> Die werzelordnersystem ist kaput
[16:14] <pitti> I hope that's not actually part of a real German .po file :)
[16:15] <maco> so uh what's that 2nd word?
[16:15] <pitti> Keybuk: we know the locale and thus the language, we just don't know the domain or which part of the string is literal and which are macros
[16:15] <pitti> Keybuk: so, could be on a best-effort basis
[16:15] <pitti> maco: root file system probably
[16:16] <pitti> this is not really German
[16:16] <Keybuk> oh, I just made that word up
[16:16] <maco> oh ok
[16:17] <Keybuk> the actual bug I was looking at was in Spanish
[16:18] <liw> a heuristic based on package name and some fuzzy pattern matching to do reverse translations back to English would be awesome
[16:19] <pitti> a better fix would be to not translate logged messages, though
[16:19] <liw> apport should then include both versions of the text, of course
[16:19] <liw> pitti, but sometimes the people who read log files need them in their native language :(
[16:19] <liw> (everyone should just start using Finnish for everything, that'd solve all problems)
[16:19] <pitti> so, we can request a package name -> list of domains mapping from rosetta
[16:20] <pitti> and try all of those domains whether we find the string
[16:20] <pitti> liw: you're too late; seb128 already proclaimed French as the universal language
[16:20] <maco> pitti: what about translating them but having a numerical error code? that way the user can see whats up and the triagers can look at the list of error codes?
[16:20] <maco> ...or i could read liw's next line
[16:21] <Keybuk> liw: there's not enough time left before the sun dies to finish a sentence
[16:21] <liw> maco, numeric codes would work if all apps used them, but alas...
[16:21] <liw> Keybuk, but there's always time for another portion of Bananenkartoffeln
[16:22] <tseliot> liw: why Finnish? Is it easier?
[16:22] <liw> tseliot, yes: I knew Finnish by 3, but I still haven't been able to learn French
[16:22] <pitti> liw: Bananenkartoffeln> eww
[16:23] <apachelogger> pitti: ahoy, any suggestions on how to squeeze the changed translations for kubuntu-firefox-installer in?
[16:23] <Keybuk> ooh, Stollen!
[16:23] <Keybuk> it's nearly time!
[16:23] <pitti> yummy
[16:23] <pitti> apachelogger: you could upload them directly to Rosetta right now, including teh changed .pot file (not sure whether that'll work, though)
[16:23] <pitti> dpm: ^ ?
[16:24] <pitti> dpm: context: we're about to change some strings in kubuntu-firefox-installer (trademark issue, no choice); can we pre-upload that to Rosetta, so that they'll be part of the langpack export tomorrow?
[16:24] <tseliot> liw: French should be even more difficult to learn than Italian is (and Italian is extremely difficult to learn) as it evolved more from Latin than Italian did. Spanish is much easier
[16:24] <cjwatson> mmm Stollen. Hungry now.
[16:24]  * apachelogger still got no po tarball to manipulate though
[16:24] <pitti> apachelogger: alternatively I can manally merge them into the langpacks after building them; should't be too hard
[16:24] <apachelogger> rosetta export queue must be longish
[16:24] <apachelogger> ok
[16:25] <davmor2> cjwatson: don't steal hunger that's just daft ;)
[16:25] <pitti> apachelogger: so perhaps just grab the set of changed .po files, tar them, and mail them to me?
[16:25] <cjwatson> davmor2: Stollen is an extremely yummy kind of German cake
[16:25] <apachelogger> pitti: probably easiest ... once I've gotten the po files -.-
[16:25] <pitti> I use to translate that as "christmas cake"
[16:26] <davmor2> cjwatson: I know I was being daft :) It stops the insanity
[16:26] <pitti> apachelogger: I thought you changed them in the source?
[16:26] <cjwatson> pitti: I would, but it confuses English people as Christmas cake here is very different
[16:26] <davmor2> pitti: just cake works over hear ;)
[16:26] <apachelogger> pitti: the pos are currently only handled in rosetta, so I need to export them first and then apply the changes
[16:27] <apachelogger> or rather, rosetta needs to export them :D
[16:27] <jbicha> is anyone willing to sponsor my patch for bug 440098?
[16:27] <pitti> apachelogger: ah, I see
[16:27] <dpm> apachelogger, (pitti, thanks for the background info) you could upload a tarball with the new pot file and the po files. The imports queue is nearly empty, so it should get importing quickly.
[16:27] <dpm> imported, I meant
[16:27] <pitti> apachelogger: LP is a little on the unhurried side since yesterday :-(
[16:27] <pitti> dpm: cool, so you can actually override the .pot files from package builds? nice
[16:28] <pitti> apachelogger: ^ I think that's easiest then, and avoids cluttering the translations with the next update
[16:28]  * apachelogger pets lp and hopes for the best
[16:28] <dpm> pitti, yes, although we tend to do it only when necessary
[16:31] <jayy_123> can anyone help me solve a speaker problem running Jaunty on a Thinkpad x200? No sound...
[16:42] <apachelogger> dpm: do I have bump the revision dates to override the current rosetta versions?
[16:43] <dpm> apachelogger, what are you trying to do? which revision dates you mean? The ones on the PO files?
[16:43] <apachelogger> dpm: yes, po revisions
[16:43] <slangasek> Keybuk: for the immediate case, did you get the Spanish translation you needed or did you work around it?
[16:43] <slangasek> tseliot: what's difficult about Italian?
[16:44] <Keybuk> slangasek: the dpkg term log disagreed with the subject of the report
[16:44] <Keybuk> so I marked it as Invalid
[16:44] <slangasek> mmk
[16:44] <Keybuk> after repeating the spanish text out loud in a funny voice
[16:44] <slangasek> heh
[16:44] <tseliot> slangasek: tenses (a lot of irregular verbs), orthography, accents, etc
[16:45] <dpm> apachelogger, just a question, so I get a picture of what you are trying to do. You downloaded translations from Launchpad, have a new local template and you are trying to merge them with some other translations?
[16:45] <slangasek> tseliot: <handwave> :
[16:45] <slangasek> )
[16:45] <tseliot> hehe
[16:45] <apachelogger> dpm: more like replace all occurances of Firefox with Mozilla Firefox
[16:47]  * dpm is thinking
[16:50] <primes2h> slangasek: tseliot: Italian language is even difficult for Italians themselves ;)
[16:50] <apachelogger> 哈拉爾德西特 <- apparently that would be my name in zh_tw :D
[16:50] <tseliot> primes2h: absolutely
[16:51] <james_w> I finally have a diff for bug 307019: http://paste.ubuntu.com/298363/
[16:51] <james_w> it's not very nice though
[16:51] <james_w> adds a new string, and I'm not sure we can steal translations for it from elsewhere
[16:51] <slangasek> primes2h: yes, but that's just because none of y'all are raised to speak it ;)
[16:52] <dpm> apachelogger, so I think it will not be necessary to bump the 'PO-Revision-Date' of the PO files, but I'd update the 'POT-Creation-Date' of the POT template (intltool, xgettext or whathever you are using to create the template should have done it automatically)
[16:52] <james_w> dpm: you will know better than me the issues involved in re-using a translation from elsewhere
[16:53] <james_w> dpm: I re-used the string from gnome-control-center, but I assume that I would have to use the same accelerator to use the translations verbatim?
[16:53] <dpm> james_w, looking...
[16:53] <primes2h> slangasek: I told you that because I AM italian ;) :D
[16:54] <slangasek> primes2h: già veduto :)
[16:55] <dpm> apachelogger, actually, I'm told by danilo that LP doesn't look at 'POT-Creation-Date', so you shouldn't have to worry about that, either
[16:57] <primes2h> slangasek: s/veduto/visto. QED :)
[16:57] <slangasek> heh
[16:59] <slangasek> mdeslaur: did you mean for your http://iso.qa.ubuntu.com/qatracker/result/3266/288 test to be marked as failed?  Did you experience any bugs other than the UbuntuOne bug you listed?
[16:59] <dpm> james_w, I need some context here: which src package are we talking of?
[16:59] <mdeslaur> slangasek: no other bug. UbuntuOne was part of the test procedure, so I marked it as failed
[17:00] <mdeslaur> slangasek: should I change it to pass?
[17:00] <slangasek> mdeslaur: I consider that a pass
[17:00] <mdeslaur> slangasek: ok, changing
[17:01] <dpm> james_w, and which new string is added?
[17:01] <james_w> dpm: "Change Password..."
[17:01] <james_w> in the .ui file
[17:01] <slangasek> (at the level of granularity I have in the test tracker, if every bug that disrupted a test case meant the test is treated as failed, we'd have a uselessly large amount of red)
[17:02] <dpm> james_w, ah, ok, sorry, I see it in the diff, thanks
[17:02] <james_w> in gnome-about-me it is the same words, but "Change Passwo_rd..."
[17:02] <mdeslaur> slangasek: np
[17:02] <apachelogger> dpm: too late :)
[17:02] <dpm> you're too quick!
[17:02] <apachelogger> unfortunately :P
[17:03] <nxvl> cjwatson: is there any documentation on how to migrate from ext3 to ext4?
[17:04] <nxvl> Keybuk: ^^
[17:05] <apachelogger> asac, pitti, dpm: all set for upload
[17:05] <pitti> apachelogger: nice; so please go ahead, upload the new PO/POT to Rosetta and k-f-i to unapproved
[17:06] <asac> apachelogger: great. so it seems you know what to do?
[17:06] <dpm> apachelogger -> https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+pots/kubuntu-firefox-installer/+upload
[17:06] <dpm> here you can upload the tarball
[17:07] <cjwatson> nxvl: ext4.wiki.kernel.org
[17:07]  * jdong silently grumbles about btrfs
[17:07] <Keybuk> what's wrong with btrfs?
[17:08] <jdong> Keybuk: just btrfsck
[17:08] <dpm> apachelogger, remember that the tarball must contain both the POT and PO files, otherwise the translations won't get imported
[17:08] <jdong> the documentation clearly states it works online or offline
[17:08] <jdong> running it online ended in an abort()
[17:08] <jdong> mail their list, and a developer tells me btrfsck doesn't support online fsck :)
[17:09] <jdong> other than that, I love btrfs.... Now if only that grub-probe "bug" is fixed....
[17:09] <Keybuk> now that btrfs and dpkg are friends, I must try it again
[17:09] <nxvl> cjwatson: thank you!
[17:09] <jdong> I've been running it as a root fs with btrfs modules/progs built from git
[17:09] <jdong> pretty decent; performance at least matches-ish ext4
[17:10] <jdong> the only annoyance is grub-probe can't find the device for /
[17:10] <dpm> apachelogger, (all inside the 'po' directory) ^
[17:10] <apachelogger> dpm: all queued
[17:10] <jdong> (debian bug 540786)
[17:12] <cjwatson> jdong: somebody posted a patch against GRUB Legacy to the upstream list, but it'll need fairly extensive work to port to grub2
[17:12] <cjwatson> I'd like to make that happen, but we're not particularly close
[17:12] <dpm> apachelogger, ok yes, I can see them.
[17:13] <Keybuk> we should just port grub to use blkid, clearly
[17:13] <apachelogger> pitti: package uploaded
[17:17] <kees> Keybuk: thanks :)
[17:17] <Keybuk> kees: for?
[17:17] <jdong> cjwatson: *nods* yeah, reading up on the mailing list chatter, it does seem like significant work is involved
[17:18] <Keybuk> the whole bootloader-needs-to-read-the-root-filesystem problem seems like a misdesign to me
[17:18] <jdong> what would be the alternative?
[17:19] <Keybuk> for example, having the boot loader understand a single common and simple filesystem
[17:19] <Keybuk> FAT for argument's safe
[17:19] <Keybuk> and placing kernels and initrds into that
[17:20] <Keybuk> that way the boot loader can load the kernel and initrd
[17:20] <jdong> that does sound more reasonable
[17:20] <Keybuk> and they can worry about filesystem support for the root
[17:20] <jdong> I suppose grub and such already do that, just beyond.
[17:21] <jdong> for some inappropriate definition of "simple" filesystem *grin*
[17:21] <kees> Keybuk: not won't fixing 456942.  ;)
[17:21] <dpm> james_w, if it makes sense for the accelerator to be there, I'd just put the "Change Passwo_rd..." one on the .ui file, then you can be sure that the translations also match the original string. I believe if the original string doesn't have an accelerator and the translation has one, it will not be rendered as an accelerator, so that would be the worst case. So I think the best thing to do if you want this change to be transparent to translators and us
[17:21] <dpm> ers is to use "Change Passwo_rd..." in the UI file and reuse the g-c-c translation
[17:21] <kees> Keybuk: but, I'd like to see it fixes -- I tried to answer your questions, can you take a look at it again?
[17:22] <james_w> dpm: the issue is that _R is already used on this dialog
[17:22] <Keybuk> kees: I think I'm getting a reputation when people thank me for simply not "Won't Fix"ing their bug ;)
[17:23] <kees> Keybuk: you're very literal in your bug handling.  ;)
[17:23] <jdong> so what's the state/future of grub legacy? Is it just that grub2 is preferred, or is -legacy in the evil, not recommended, deprecated category already?
[17:23] <james_w> dpm: so I could pick another for English, but it would then be very hard to pick one for translations that didn't collide with whatever they are already using on this dialog, correct?
[17:23] <dpm> james_w, correct
[17:24] <james_w> dpm: so as we are so late I think I would be better going with no accelerator?
[17:24] <cjwatson> jdong: nobody at all is prepared to take upstream responsibility for grub legacy, and it's just quietly bitrotting
[17:24] <cjwatson> jdong: of course, bootloaders are the sort of thing that can quietly bitrot more happily than most; there's unlikely to be any harm in staying with it if it's working for you
[17:25] <cjwatson> jdong: but we didn't go so far as to automatically upgrade people to grub2 on upgrade to karmic, because dealing with initial installs was hard enough
[17:25] <dpm> james_w, yes, but the accelerator will then have to be removed from the strings you pick up from g-c-c
[17:25] <james_w> dpm: I think I can do that without breaking them?
[17:25] <jdong> cjwatson: I see; just trying to figure out the most un-evil workaround for a btrfs based rootfs; right now I have an evil wrapper script around grub-probe; figure for now maybe using legacy grub would be cleaner
[17:26] <dpm> james_w, I guess so, you've got superpowers!
[17:26] <james_w> dpm: I can see underscores at least :-)
[17:27] <Keybuk> kees: I'm still waiting for someone SELinux-related to actually join the Upstart ML and discuss what needs to be done there
[17:27] <dpm> :)
[17:27] <james_w> I just wondered if you were going to tell me of a language that uses purely patterns of underscores
[17:27]  * Ng wonders why a future last mount time is a failworthy event on boot
[17:27] <kees> Keybuk: nothing is needed there since the initramfs handles it.  :)  but, email Caleb Case (ccase@tresys.com) if you really want to find out.
[17:28] <Keybuk> kees: I think Caleb is one of those people who objects strongly to that approach
[17:28] <kees> Keybuk: anyway, will it be possible to get the tmpfs-mounts-call-restorecon-before-they're-marked-mounted fix in?
[17:28] <Keybuk> he was being rather rude about me at LPC
[17:28] <Keybuk> (not realising I was sat behind him at the time)
[17:28] <dpm> james_w, not that I know of :)
[17:28] <Keybuk> kees: dunno, it's RC tomorrow - and I don't really understand the problem yet
[17:28] <kees> Keybuk: well, at the time, you were pretty unfriendly about putting selinux patches into upstart.  :P
[17:28] <Keybuk> kees: absolutely untrue
[17:28] <Keybuk> seriously
[17:28] <kees> Keybuk: did you read my reply?
[17:29] <Ng> http://mairukipa.tenshu.net/fsckishard.jpg - should I file a bug about that against mountall?
[17:29] <kees> Keybuk: ok, I don't know the history there, just restating what he'd expressed.
[17:29] <Keybuk> exactly, he was being rude and frankly making shit up
[17:29] <Keybuk> that kind of thing is not likely to make me feel like I want to deal with him
[17:29] <kees> I would assume "misunderstanding something" instead of "making shit up", but ok
[17:30] <kees> Keybuk: right, it's RC, but without tmpfses coming up with the right labels, SELinux cannot sanely transition files, process, etc, that use a given mount
[17:30] <Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000276.html
[17:30] <Keybuk> is the relevant mail
[17:31] <Keybuk> err, I mean
[17:31] <Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000273.html
[17:31] <Keybuk> I think I'm being perfectly polite and wanting to support SELinux in those ;)
[17:32] <kees> sure, and that's Chad not Caleb, but still, I'm not trying to fix that; I want to see mountall fixed.  ;)
[17:32] <Keybuk> exactly
[17:32] <Keybuk> but no, I'm not going to talk to Caleb ;)
[17:33] <kees> Keybuk: does 456942 have enough information to justify calling out to restorecon?
[17:33] <Keybuk> kees: I'd rather include the actual libselinux library calls
[17:34] <kees> Keybuk: why?
[17:34] <Keybuk> because fork/exec/wait/etc. is expensive!
[17:35] <kees> expensive only on machines running selinux, but I'll go check.  I suspect it involves parsing config files, etc.  one sec
[17:36] <Keybuk> no, not at all
[17:36] <Keybuk> because every single mount will call restorecon
[17:36] <kees> no.... policycoreutils is in universe.
[17:36] <Keybuk> so?
[17:37] <Keybuk> I still have to fork(), still have to exec(), but also then need to deal with ENOENT :)
[17:37] <kees> what?  access("/usr/sbin/restorecon", X_OK) once at the start of mountall and just don't call it.
[17:38] <kees> s|/usr||
[17:38] <Keybuk> still seems easier to just copy the relevant couple of libselinux calls into mountall
[17:42] <LaserJock> slangasek: it looks like Edubuntu 20091021 built OK, can the iso tracker get updated?
[17:44] <Riddell> evand: what is it that creates the icon on the desktop to run oem-config-prepare after an oem install?
[17:45] <Ng> oh it's fsck not mountall
[17:45] <Ng> blah
[17:45] <kees> Keybuk: it looks like there is a lot of logic in dealing with selinux contexts...
[17:48] <evand> Riddell: scripts/install.py in ubiquity bzr, line 2170
[17:57] <Riddell> evand: thanks, that's bug 386099 incase you're interested
[18:01] <elops> I have a cronjob, whose last act is to shadow a section of the filesystem with lndir.  The cronjob succeeds for the most part, but lndir mysteriously only mirrors about 10% of the target path.  When I run the lndir command standalone, outside a cron job, it works fine.  Anyone have any ideas?
[18:03] <slangasek> LaserJock: done
[18:05] <elops> I have it purge the contents of the target directory, and then run "lndir /srv/nfsmount /work/localcopy" so that when I run test code each day, I don't alter the data on the nfs server, but can still save files.
[18:05] <elops> each morning, I find I have 2 our of 10 of the folders that exist in /srv/nfsmount populated in /work/localcopy.  I then end up running the command manually, and get what I want.
[18:06] <kees> Keybuk: http://people.canonical.com/~kees/restorecon.patch
[18:07] <Keybuk> kees: coding style! :p
[18:07] <kees> Keybuk: sorry, was trying to follow yours -- what would you like to see changed?
[18:07] <Keybuk> that's nothing like mine! :p
[18:08] <Keybuk> root_hook won't ever get run though
[18:08] <Keybuk> you realise that? :)
[18:08] <Keybuk> you actually don't need it, mountall asserts the root is always mounted when it starts
[18:08] <kees> obviously I don't.  :P
[18:08] <kees> ok
[18:08] <Keybuk> (since otherwise what would mountall be on)
[18:08] <Keybuk> just having that access() check in main() somewhere would be ok
[18:08] <elops> the line from crontab: 30 0 * * * /srv/moritzhome/dbBackup/backup.sh
[18:08] <elops> any ideas here?
[18:10] <kees> Keybuk: refresh the URL.  what would you like changed with the style?
[18:12] <Keybuk> kees: will just manually apply
[18:12] <Keybuk> (and there's a crasher bug in your code there, but :p)
[18:12] <kees> Keybuk: I can commit to the bzr tree if you like
[18:12] <kees> what's the crasher?  (nih is still new to me...)
[18:12] <Keybuk> s'ok, just committing it now
[18:12] <Keybuk> kees: nih_local things need to be set to NULL
[18:13] <kees> ah-ha
[18:13] <Keybuk> otherwise you free uninitialised data for some code paths
[18:15] <Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/karmic/mountall/ubuntu/revision/140
[18:16] <kees> heh, internal server error, but yes, thanks!
[18:17] <Keybuk> yeah, keep hitting reload
[18:17] <Keybuk> LP gets there eventually
[18:17] <Keybuk> you missed args out of the spawn() call too btw :p
[18:17] <mathiaz> slangasek: is https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview the wiki page that will be used for release notes?
[18:17] <kees> you caught and earlier revision
[18:17] <mathiaz> slangasek: I'd like to add a section about mysql upgrades
[18:18] <elops> WHAT does absolute link type mean?
[18:18] <kees> Keybuk: I had cut/pasted spawn, replaced args with NULL briefly while researching nih_str_array_add, etc.  anyway, thank you very much, now SELinux has a chance at working again.  :)  That and with a pile of policy updates for the upstartifications, but that doesn't concern anything in main.  :)
[18:19] <Keybuk> it would be nice to figure out how to get selinux and upstart to co-operate
[18:19] <Keybuk> but selinux people don't tend to do the 'c' word
[18:20] <kees> be nice, be nice. :)
[18:20] <d33d> question - are there packages I can package if I learn it?
[18:23] <kees> Keybuk: afaik, it's just a matter of the core of this patch: https://lists.ubuntu.com/archives/ubuntu-hardened/2007-November/000230.html
[18:23] <Keybuk> kees: except that patch is wrong on so many levels
[18:23] <kees> Keybuk: i.e. selinux_init_load_policy(&enforce); with a check of return code and enforcingness
[18:23] <Keybuk> because it then doesn't enforce init itself
[18:24] <Keybuk> and afaict, you can't reload the policy
[18:24] <Keybuk> or have different policies for different groups of services
[18:25] <kees> Keybuk: ok, well, if you want, restart that thread.  as it stands, this work fine from the initramfs via the external load_policy tool.
[18:25] <kees> *works
[18:41] <joaopinto> is there any documentation describing the official iso's build process ?
[18:48] <davmor2> joaopinto: you need to pray the iso gods sacrificing small child in the name of the cd you require and then as if by magic it arrives ;)
[18:49] <joaopinto> right :P
[18:51] <LaserJock> davmor2: children? I've been sacrificing lolcats, now I know why my .isos have had problems
[18:53] <joaopinto> I am trying to create a base iso without the using the initrd/config from an existing cd
[18:59] <ion> It would be nice if Launchpad already had the lucid milestone for Ubuntu, or whatever’s needed so that i can push changes intended for lucid to lp:~ion/ubuntu/lucid/mountall/blahblah.
[18:59] <ion> s/milestone/series/
[19:01] <pitti> lool: I'd appreciate if you could confirm bug 457537, so that we can go ahead with cleaning up component-mismatches
[19:04] <joaopinto> I must have squashfs-tools mismatch
[19:40] <slangasek> mathiaz: no, https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes
[19:56] <Keybuk> clearly I am having a bad laptop month
[19:56] <highvolt1ge> Keybuk: at least it's not a bad laptop /year/ :)
[19:56] <mathiaz> slangasek: thanks - I've added a section about MySQL upgrades (5.0 to 5.1 transition and MySQL cluster support)
[19:56] <highvolt1ge> (like I've been having)
[19:57] <mneptok> Keybuk: try a different club?
[19:57] <mneptok> oh .... wait. not what you meant by "laptop" in this context.
[19:57] <highvolt1ge> I guess all these laptops are burning up with all this super-fast booting
[19:58]  * mneptok puts his sequinned man-pantied back in the drawer
[19:58] <ion> keybuk: I split the lucid fsck change to two commits for better readability. https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/lucid
[20:01] <ccheney> is lp really slow today?
[20:01] <pitti> since yesterday already
[20:01] <ccheney> ok i thought my internet connection was buggy
[20:02] <ion> keybuk: What happened to your laptop this time?
[20:02] <Keybuk> ion: spare laptop has suddenly decided it's not interested in AC power
[20:03] <ScottK> It if was his netbook (mini 10v), I'd have guessed it was "touchpad finally drove hime to throw it through a window".
[20:05] <Keybuk> heh
[20:05] <Keybuk> no, the XPS
[20:05] <ccheney> ScottK: yea the mini 10/10v touchpad is fail
[20:06] <ScottK> Based on my experience with it the next two netbooks we bought here were from HP.
[20:06] <ccheney> at least it doesn't have the buttons on both sides of the touchpad like some netbooks, but still not very good
[20:06] <jcastro> cjwatson: I have hardware to help test bug #413135; which DVD image do I need to test, i386, amd64, or both?
[20:06] <ScottK> jcastro: I got both of the primary plasma netbook developers signed up to do my open week session with me.
[20:07] <jcastro> ScottK: awesome, could you mail me like a 2 line bio and/or pics for the glossy pdf? If not they won't be in the PDF (which isn't the end of the world but I'd like to have all speakers represented)
[20:07] <ScottK> OK.  I'll ask.
[20:14] <ion> keybuk: When mountall says ‘CLEAR’ to usplash, nothing seems to happen. Is someone working on that?
[20:16] <mathiaz> cr3: hey - reviewing checkbox 0.8.5
[20:16] <mathiaz> cr3: processors_info.py has been renamed to processor_info.py - why?
[20:17] <cr3> mathiaz: that was supposed to have been done in 0.8.4, but patching seemed to have failed for that renaming
[20:18] <mathiaz> cr3: well - bzr probably handled that
[20:18] <cr3> mathiaz: the original motivation for changing processors to the singular form is that checkbox now reports processor information and the processor count as part of that information
[20:18] <mathiaz> cr3: the debdiff show a rename before 0.8.4 and 0.8.5
[20:18] <mathiaz> cr3: ok - you may wanna document that in the changelog
[20:20] <cr3> mathiaz: under 0.8.4, since it was originally done upstream in 0.8.4?
[20:21] <joaopinto> why does the livecd the the livecd uses syslinux instead of grub, more customization?
[20:26] <mathiaz> cr3: hm no - in the 0.8.5
[20:27] <mathiaz> cr3: the actual diff happens in 0.8.5
[20:27] <mathiaz> cr3: at least from a package point of view
[20:27] <cr3> mathiaz: not upstream though
[20:27] <cr3> mathiaz: ok
[20:29] <Keybuk> ion: oh, someone should fix usplash ;)
[20:37] <lool> pitti: Hey
[20:37] <lool> pitti: Did you work on the gnome-user-guide split?
[20:37] <Keybuk> cjwatson: so, you know how we go through the dictionary looking for words beginning with 'u' to name things?
[20:37] <lool> pitti: I wonder whether it's normal that langsel offers to install gnome-user-guide-en when you first launch it, yet it's not seeded
[20:37] <Keybuk> I've been going through Urban Dictionary ...
[20:37] <lool> slangasek: Hmm or perhaps it was you working on that gnome-user-guide split
[20:37] <Keybuk> lovely word, "umaga"
[20:37] <Keybuk> nice name for a project
[20:38] <pitti> lool: I didn't work on that, but why is it wrong?
[20:38] <Keybuk> of course, it does mean Shrivelled-up Monkey Penis in Somoan, but I think that's a minor problem
[20:38] <ion> keybuk: Heh, it seems it has been reported 1½ years ago. Bug #215666
[20:38] <Keybuk> ion: the best bugs are the old ones
[20:38] <lool> pitti: I had a report that this gets fired on initial install of UNR, on first boot; I think one needs to do slightly more to trigger the bug though
[20:39] <lool> pitti: But my impression was that we were trying to seed a full english environment
[20:39] <lool> It's a bit weird to finish install and then you discover by going to your prefs that you actually lack some stuff
[20:39] <lool> pitti: Even on my karmic desktop, I dont have the package and langsel offers me to fix my system
[20:40] <jcastro> cjwatson: nevermind the platform is in the bug title, the instructions mailed to me weren't clear. *whistles*
[20:40] <pitti> lool: that's just the same as with any other language now, though
[20:40] <pitti> lool: if you want to have it by default, please feel free to seed it, of course
[20:41] <lool> pitti: It's not clear to me why we seed gnome-user-guide and not gnome-user-guide-en and we also always seed the en langpack
[20:42] <lool> I dont think I mind having it in by default; I guess it makes sense to have an user guide by default; I just wonder whether this is inconsistent
[20:42] <lool> Or perhaps that was done on purpose to save space, I'm not sure
[20:42] <pitti> lool: gnome-user-guide is "C", i. e. en_US; -en is en_GB etc.
[20:43] <pitti> lool: yes, it was; also for openoffice.org-en-{gb,za}
[20:43] <pitti> that saved dozens of MB
[20:43] <lool> pitti: Aha
[20:43] <lool> pitti: So it's fine for me
[20:43] <pitti> we just install en_US by default now
[20:43] <lool> pitti: Isn't langsel confused if it tries to install -en for me though?
[20:44] <lool> I have LANG="en_US.UTF-8"
[20:44] <cr3> mathiaz: done
[20:44] <pitti> lool: hm, looks like it then
[20:45] <pitti> lool: hm, it only considers languages, not countries
[20:45] <pitti> lool: so for "full" english language support it's actually justified (same as GB/ZA OO.o help and translations)
[20:45] <lool> Hmm
[20:46] <lool> pitti: perhaps ubiquity folks would have a good understanding of what we try to obtain upon install since they maintain the code pulling langpacks etc.
[20:50] <lool> I actually saw the same thing in https://bugs.launchpad.net/ubuntu-moblin-remix/+bug/457479
[20:55] <mathiaz> cr3: checkbox 0.8.5 sponsored
[20:55] <cr3> mathiaz: thanks!
[20:55] <mathiaz> cr3: it's waiting in the unapproved queue
[20:55] <cr3> primes2h: ^^^ the new .pot file should be made available shortly
[20:55] <cr3> I wonder if launchpad will grab the new .pot file automatically
[20:55] <mathiaz> cr3: I don't think so
[20:56] <mathiaz> cr3: the package won't be accepted before RC is released (if it's accepted)
[20:57] <cr3> mathiaz: I'll upload the .pot file separately then
[20:57] <d33d> Newbie question - so .deb files are packages....so when someone is "packaging" are they creating these .deb files or is that 2 separate, totally different things?
[20:58] <ttx> mathiaz: hey
[20:58] <cr3> primes2h: I uploaded my latest po/pot files and they're in the import queue right now: https://translations.edge.launchpad.net/checkbox/trunk/+imports
[20:58] <mathiaz> ttx: yo!
[20:58] <ttx> mathiaz: do you have a UEC setup available atm
[20:59] <mathiaz> ttx: hm - not *right* *now*
[20:59] <mathiaz> ttx: I'm in the process of having hw for it
[20:59] <mathiaz> ttx: cr3 is lending me two machines until RC is released
[21:00] <mathiaz> EtienneG: are you using the hw for your UEC playground?
[21:00] <ttx> mathiaz: I could use some confirmation on bug 457281 and bug 457283
[21:00] <cr3> ttx: mathiaz and I share a symbiotic relationship: I depend on him for checkbox and he depends on me for hardware.
[21:00] <EtienneG> mathiaz, yes
[21:00] <ttx> cr3: that sounds dirty
[21:00] <EtienneG> mathiaz, btw, did someone ever tested running the cc on a different machine than the clc
[21:01] <mneptok> ttx: you should see their spandex suits and space helmets
[21:01] <EtienneG> yo mneptok
[21:01] <mneptok> EtienneG: 'lu!
[21:01] <mathiaz> EtienneG: hm - eucalyptus upstream was supposed to do that IIRC
[21:01] <ttx> EtienneG: I think we have a test report from the eucalyptoids in multi-component mode
[21:01] <EtienneG> mathiaz, ttx, I am jut wondering about a couple details of components registration
[21:02] <mathiaz> ttx: I'll have a look at your bugs once I've got my UEC up and running
[21:02] <mneptok> EtienneG: it's the coldest day here in New Mexico yet. 12C!
[21:02] <mneptok> >:P
[21:02] <ttx> mathiaz: cool thx
[21:02] <EtienneG> ttx, I am not really interested in multi-cluster, I just want to register a cc to a clc that is not localhost
[21:02] <ttx> mathiaz: haven't seen nurmi today
[21:02] <EtienneG> mneptok, awesome!  Think about next July when the mercury 38C
[21:03] <mneptok> EtienneG: rarely that bad. 35C is max here.
[21:03] <ttx> mathiaz: so we could use confirmed bugs before tomorrow's eucacall
[21:03] <mneptok> EtienneG: with 0% humidity
[21:03] <mathiaz> ttx: okdokioikeodoko
[21:03] <ttx> EtienneG: let me dig that report
[21:03] <EtienneG> mneptok, pfft!  I would rather keep my -30C!
[21:03] <EtienneG> no, really!
[21:03] <mneptok> OMG, mathiaz is becoming Ned Flanders.
[21:05] <smoser> its funny cause its true.
[21:07] <ttx> EtienneG: I just fwded you an email thread talking about multi-cluster or multi-component tests
[21:07] <ttx> EtienneG: that might help
[21:07] <primes2h> cr3: Many thanks! :)
[21:08] <ttx> EtienneG: documentation is in progress
[21:08] <EtienneG> ttx, thanks a bunch
[21:08] <EtienneG> ttx, I am just looking at a single-cluster setup, (clc+walrus) -> (cc+sc) -> (nc)
[21:09] <EtienneG> I am at the step where I need to register the cc with the clc somehow
[21:10] <smoser> Keybuk, you around ?
[21:11] <Keybuk> yup
[21:11] <ttx> EtienneG: that's what they call "multicomponent" -- not that well covered in what I sent you, I admit
[21:12] <smoser> Keybuk, ec2-init has a startup script that runs via sysvinit
[21:13] <smoser> previously (beta) output from this script went to console (which we could then see from the ec2/uec console-grabbing tools)
[21:13] <smoser> since then, it has disappeared, and i see
[21:13] <smoser> etc/init/rc.conf and etc/init/rc-sysinit.conf have changes to 'console'
[21:13] <smoser> in them
[21:13] <EtienneG> ttx, it is a start.  I will hammer nurmi if I have any question
[21:14] <smoser> we want/need  to write output to the console, how should we be doing that ?
[21:14] <Keybuk> smoser: "console output"
[21:15] <smoser> right, if it were a upstart config
[21:15] <smoser> but it is run via rc-sysinit. i'd like to not change your config files.
[21:15] <Keybuk> oh, >/dev/console ? :)
[21:15] <Keybuk> it was changed as a default because of the "No console messages during boot" rule imposed for karmic by Design/DX
[21:16] <smoser> yeah, i realized the >/dev/console would have worked...
[21:17] <smoser> my other option is configuring rsyslog to write there and running it through logger
[21:17] <smoser> but even then, i'm not sure how i would guarantee myself that rsyslog would be up
[21:18] <Keybuk> that works too
[21:18] <EtienneG> ttx, got my answer in the email thread you sent: ssh keys need to be manually exchanged
[21:20] <kirkland> dtchen: howdy
[21:21] <kirkland> dtchen: i'm trying to debug what i think is a nasty pulse audio issue, affecting kvm, libvirt, and/or virt-manager
[21:21] <kirkland> dtchen: sometimes the VM guest just "hangs" while booting
[21:21] <kirkland> dtchen: it looks like a sound issue to me
[21:22] <kirkland> dtchen: what can I do to try and debug this?
[21:22] <kirkland> dtchen: basically, if i remove the sound device from the vm, it boots fine
[21:23] <kirkland> dtchen: but sometimes, when the vm has a sound device, it hangs on boot
[21:23] <kirkland> dtchen: strace of kvm shows it hanging at: futex(0xbafc20, FUTEX_WAIT_PRIVATE, 2, NULL
[21:24] <cjwatson> jcastro: i386
[21:25] <smoser> Keybuk, so if i want to go the rsyslog route, how can i guarantee that it will be up when /etc/init.d/ec2-init runs
[21:26] <jcastro> cjwatson: it'll be 10+ hours before I can get the ISO, but will do my best to test asap
[21:26] <cjwatson> joaopinto: because grub legacy wasn't what you might call exceptionally reliable at booting CDs, and we didn't want to try to switch both the installed system and the CD to grub2 at once. Furthermore, the graphical menu patch to grub2 hasn't landed yet so it would be a substantial regression in terms of prettiness at the moment
[21:26] <cjwatson> Keybuk: umaga> hah
[21:28] <cjwatson> jcastro: 3+ hours to jigdo .template here, then most of the rest should come off the local mirror
[21:28] <joaopinto> cjwatson, tks
[21:28] <cjwatson> jcastro: but I'll be away all day tomorrow
[21:29] <primes2h> cr3: But is it sufficient to upload po/pot files in trunk?
[21:30] <primes2h> cr3: Doesn't them need to be uploaded in Karmic directly?
[21:30] <cr3> primes2h: I don't know, I'm not particularly familiar with translations
[21:30] <primes2h> cr3: It's better to put them in Karmic checkbox queue
[21:32] <primes2h> https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+imports
[21:32] <primes2h> cr3: https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+imports
[21:33] <primes2h> Those are the .pos used in language packs.
[21:34] <cr3> primes2h: uploaded, is that better?
[21:46] <Keybuk> smoser: you can't, it's started in parallel
[21:47] <smoser> thats what i thought
[21:47] <Keybuk> you can use openlog with LOG_CONSOLE of course
[21:47] <Keybuk> so syslog() outputs to the console if syslog isn't up
[21:51] <smoser> Keybuk, thank you. i'd like to avoid C here if possible. maybe this just needs to write to /dev/console
[21:52] <primes2h> cr3: That's nice. Imported! Thank you very much indeed.
[22:00] <joaopinto> cjwatson, is the desktop cd based on debootstrap+casper+ubuntu-desktop+ubiquity+casper => squashfs image ?
[22:00] <joaopinto> ops, one casper :P
[22:01]  * dupondje prays somebody includes fix @ https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[22:17] <EtienneG> mathiaz (or ttx, or whoever): do you have any idea what actually generate the ssh authentication keypair when installing eucalyptus?  I just installed eucalyptus-cloud and eucalyptus-walrus on a machine, and /var/lib/eucalyptus/.ssh is empty.  I am wondering it is a bug or if I forgot a step somewhere
[22:17] <mathiaz> EtienneG: was it from an ISO?
[22:18] <EtienneG> mathiaz, no.  I did a plain server install, and am going to do a so-called "multi-component" install
[22:18] <mathiaz> EtienneG: right - that's why
[22:18] <EtienneG> mathiaz: but I found the problem, and I am afraidit might be a bug
[22:19] <mathiaz> EtienneG: IIUC the ssh key generation is done at install time
[22:19] <mathiaz> EtienneG: and I think it's probably eucalytpus-cc that does so
[22:19] <EtienneG> mathiaz, indeed
[22:20] <EtienneG> mathiaz: but i am not quite sure it is correct.  You would need the keypair on the CLC
[22:20] <mathiaz> EtienneG: if you install walrus/cloud on another machine, you'd probably have to copy the public key from the CC to the walrus/cloud
[22:20] <EtienneG> mathiaz, or rather, you would need a keypair on the clc, and one on the cc (could be, but does not have to, be the same)
[22:20] <Dink> Hellow, not sure if its here where I need to post this but I am currently running Karmic and something funky is going on. Initially when I logged in compiz.real was eating up all my cpu. I then changed "visual effects" to none and cpu went back to normal. I then looked at where I was logged in and it seems like gdm started on tty1 and not 7. All other tty seem to be unusable. If this is the wrong plac
[22:20] <Dink> e to post this I apologize and please redirect me to the correct channel.
[22:21] <EtienneG> mathiaz, ok, I will copy the keypair from the cc to the clc.  The multi-compoenents install needs to be sorted out anyway, it still requiremanual ssh key exchange
[22:22] <mathiaz> EtienneG: yes - it's the same thing you need to do when you install the nodes from packages (instead of ISO)
[22:22] <mathiaz> EtienneG: you need to copy the ssh key from the CC to the nodes
[22:22] <mathiaz> EtienneG: usually euca_conf discover will tell you exaclty what needs to be done
[22:23] <EtienneG> mathiaz, it does not anymore, at least not when registering a cluster on the clc
[22:23] <mathiaz> EtienneG: oh probably
[22:23] <mathiaz> EtienneG: I've seen that only when try to register nodes
[22:23] <mathiaz> EtienneG: the case of registering a cluster on the clc hasn't been covered probably
[22:24] <mathiaz> EtienneG: this needs to be documented at least
[22:24] <mathiaz> EtienneG: (bug is welcome as well - but won't be fixed in karmic I think)
[22:24] <mathiaz> EtienneG: (as there is a workaround)
[22:24] <EtienneG> mathiaz, right.  This is actually to be fixed in euca_conf, IIUC
[22:25] <mathiaz> EtienneG: I'd guess so as well.
[22:25] <EtienneG> (looking now)
[22:26] <ccheney> slangasek: ping
[22:27] <EtienneG> mathiaz, 1455 line of shell .. .oh dear!
[22:27] <EtienneG> I give up
[22:29] <EtienneG> will check tht tomorrow ...
[23:20] <slacker_nl> hello, has anything changed with the boot sequence that might explain "timeouts" on mounting file systems?
[23:21] <slacker_nl>  i've been having some weird messages at boot, unable to mount partions x y and z hit esc to enter some kind of shell, laptop boots and all, with everything mounted
[23:21] <ion> What kind of partitions are they?
[23:21] <slacker_nl> ext3
[23:21] <slacker_nl> ion: http://pb.opperschaap.net/74 fstab
[23:22] <ion> Did i understand correctly – they are mounted correctly in the end?
[23:23] <slacker_nl> ion: yes
[23:23] <slacker_nl> the messages repeats itself several times
[23:23] <ion> That’s probably just the usplash issue where the CLEAR command doesn’t actually remove the message when it manages to mount the partition in question.
[23:23] <slacker_nl> the biggest problem is, it isn't logged somewhere (at least, cannot find anything in my logs)
[23:24] <slacker_nl> ion: you have a bug number for that issue?
[23:27] <shtylman> ccheney: man...people really won't let that oo filepicker bug die... :)
[23:33] <ion> slacker_nl: Bug #215666
[23:35] <slacker_nl> ion: thnx
[23:36] <slacker_nl> ion: but karmic is using xsplash right..
[23:37] <ion> slacker_nl: X can’t be started before important filesystems have been mounted, thus no xsplash yet when those messages need to be shown. For karmic, usplash handles them.
[23:37] <ccheney> shtylman: heh
[23:38] <ccheney> shtylman: its what happens when linux gets to easy to use ;-)
[23:38] <shtylman> haha
[23:38] <slacker_nl> ion: i see, yet, the same message appears when I get the kubuntu logo
[23:39] <slacker_nl> ion: i'll make some screencast/pictures tomorrow so I can show you/add it to a bug report
[23:54] <ion> keybuk: Ah. CLEAR doesn’t do anything when not in VERBOSE mode. Should i patch usplash to always clear the text on CLEAR, or mountall to send CLEAR in VERBOSE mode?
[23:54] <cjwatson_> ion: former sounds better to me
[23:55] <ion> Ok, a moment...
[23:55] <cjwatson> (gone for the night)
[23:57] <dmoerner> is there a bug report referencing the removal of gcc-3.3 from karmic (like http://bugs.debian.org/536776)? I'm trying to convince a vendor that they really need to get rid of dependencies on libstdc++5 if they want to be competitive
[23:57] <dmoerner> i can't find it on google, but obviously gcc-3.3 has been dropped
[23:58] <cjwatson> dmoerner: according to the publication history (https://launchpad.net/ubuntu/+source/gcc-3.3/+publishinghistory), we just removed it in line with Debian
[23:59] <ion> https://code.edge.launchpad.net/~ion/usplash/karmic (didn’t test it yet, about to do that)
[23:59] <joaopinto> dmoerner, https://bugs.launchpad.net/ubuntu/+source/gcc-3.3/+bug/418372
[23:59] <cjwatson> ah, heh, that too
[23:59] <dmoerner> joaopinto, cjwatson: thanks!