[00:06] <cjwatson> superm1: as you say, the prefix problem should be a separate bug
[00:11] <persia> lamont, Thanks for trying the fpc/armel bootstrap again.  Do you have any recommendations on how we could ensure that the test-builds match your experiences on the buildds?
[00:13] <cjwatson> manjo: could you please test the server CD in preference to the desktop CD right now?
[00:13] <cjwatson> I think I've asked this before
[00:14] <manjo> cjwatson, yep... I was tring to get the desktop installed coz I had something else I needed to do wrt drm ...
[00:14] <cjwatson> manjo: it's harder to get the desktop CD to work in general, and while it does need to happen and I welcome the bug reports, given time constraints it's essential to address the shorter critical path for the server CD
[00:14] <cjwatson> this is not me trying to dodge your reports, but I really want to know whether the fixes I've made so far are sufficient for server
[00:15] <manjo> cjwatson, ack
[00:15] <manjo> cjwatson, will do it and comment on the bug report ... is that ok ?
[00:16] <manjo> cjwatson, was going to grab a quick dinner with wife atm
[00:16] <manjo> cjwatson, do I need to use that hack that I posted on the bug report ?
[00:17] <manjo> ie if that fails on normal install
[00:17] <cjwatson> not for d-i-based installations, no
[00:17] <manjo> ok
[00:19] <superm1> cjwatson, on maverick, actually just trying to apt-get install grub-efi runs into that same problems
[00:20] <cjwatson> superm1: do you have grub-pc installed on the same system?
[00:20] <superm1> cjwatson, well i was just trying from a live disk, so yes, it's installed already
[00:21] <cjwatson> indeed.  they conflict
[00:21] <cjwatson> ubiquity needs to take special care to deal with that
[00:25] <cjwatson> cf. bug 349835 and bug 353273, which you may remember - essentially the same thing I think
[00:25] <superm1> oh yeah, i do recall those
[00:26] <cjwatson> I think it's fixable in much the same way, but will fake up a test environment for it before committing anything
[00:36] <manjo> cjohnston, installing server right now, 90% done (and angry wife)
[00:36] <manjo> cjwatson, ^
[00:37] <cjohnston> no love :-(
[00:37] <manjo> cjohnston, I keep typing your nick sorry
[00:38] <manjo> cjohnston, hitting tabs :)
[00:39] <cjwatson> type one extra letter before the tab ;-)
[00:39] <sbeattie> mathiaz: in your last upload/merge of whois, you seem to have managed to lose the separate mkpasswd package, without a conflicts/replaces.
[00:39] <manjo> yep need to practice 3 letters + tab
[00:41] <cjwatson> sbeattie: seems to be the same in Debian
[00:41] <sbeattie> cjwatson: the mkpasswd bit I think was an ubuntu-specific change.
[00:41] <sbeattie> (mkpasswd as a separate package)
[00:42] <cjwatson> ah
[00:44] <YokoZar> Riddell: Yeah I got a whole host to tackle
[00:44] <sbeattie> It got separated out sometime in the lucid cycle, and is published that way; thus people upgrading from lucid that have mkpasswd get an install failure.
[00:44]  * sbeattie goes to file a bug.
[00:45] <manjo> cjwatson, server install is complete ... but cannot boot from HDD... error: unknown filesystem grub rescue>
[00:45] <manjo> cjwatson, but I need to run, keep wife happy
[00:45] <cjwatson> ok, that'll be the same as the desktop one.  could I have a separate bug for that when you have a moment?
[00:45] <cjwatson> (and that one *does* belong on grub2)
[00:45] <manjo> cjwatson, will do when I head back from dinner
[00:45] <superm1> cjwatson, i already split it up, bug 632775
[00:46] <cjwatson> ah right
[00:46] <cjwatson> thanks
[00:46] <superm1> sure np
[00:46] <manjo> cjwatson, so add to that bug ?
[00:46] <cjwatson> if you have anything new to add, sure
[00:46] <cjwatson> logs would be good
[00:46] <manjo> ok.. nothing new ...
[00:46] <manjo> heading out... laters
[00:47] <cjwatson> well, there are no logs in that bug right now
[00:47] <cjwatson> if you have logs, that would be new
[00:47] <cjwatson> (from an install that wasn't having grub-efi installation problems)
[00:47] <manjo> yep
[00:48] <cjwatson> it's not obvious from the grub-install code :(
[00:49] <cjwatson> oh, duh, I guess I know
[00:51] <cjwatson> I think this is going to need something a bit like http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/2465, only for EFI
[00:52] <cjwatson> specifically the bit that handles a partition-only prefix "drive"
[00:52] <cjwatson> the alternative is hardcoding the entire prefix device, which is seriously undesirable
[00:53] <cjwatson> then the EFI grub-install will have to find the partition number for /boot/grub and hardcode that but make sure to leave out the drive
[00:57] <sbeattie> mathiaz: the whois bug is bug 632791, for the record.
[00:58] <superm1> cjwatson, what would be the problem with something simpler like http://pastebin.com/tYSjjyXN ?  that way you are just searching for the right UUID without having to hardcode drive or partition number, just letting serach.fs_uuid find it. is the worry boot delay then?
[01:10] <cjwatson> superm1: it's good to avoid UUID searching (which is slow and requires embedding a configuration file) if possible, yes
[01:10] <cjwatson> pastebin.com is slow
[01:10] <cjwatson> probably all the junk in its framing
[01:12] <cjwatson> if /efi and /boot/grub are on the same drive, then we can make use of the fact that EFI has a call to retrieve a device handle for the loaded image (i.e. GRUB itself)
[01:13] <cjwatson> which tells us the drive and then we just need to fill in the right partition number
[01:13] <superm1> ooh pastebinit does work with paste.ubuntu.com, i'll just use that instead from now on
[01:13] <cjwatson> something like http://paste.ubuntu.com/490082/ (against upstream so paths are a bit different) in combination with a change to grub-install
[01:15] <superm1> ah i see
[01:18] <cjwatson> probably something like http://paste.ubuntu.com/490089/, all this totally untested
[01:19] <cjwatson> extra comma in the grub_partition sed
[01:20] <cjwatson> 's/^[^,]*,//; s/)$//'
[01:20] <cjwatson> anyway, that should be the structure of it - but bedtime for me
[05:07] <lamont> persia: there's a tarball on kakadu in my home directory... that and a bbg3 board should be sufficient for reproducing things
[05:08]  * persia renews the wish that any of the available imx51 HW was based on that revision of the babbage.
[05:27] <lamont> yeah.
[05:27] <lamont> anyway, sleep for me.
[05:29] <mwhudson> persia: can you explain babbage board versions to me?
[05:29] <mwhudson> i've googled and completely don't understand the few things i find :)
[05:30] <persia> mwhudson, Note that the following is gleaned from a variety of hearsay.  it is likely to be incomplete, and may well be inaccurate.
[05:30] <mwhudson> persia: noted
[05:31] <persia> My understanding is that there were several revisions of a reference board produced by freescale.
[05:31] <persia> some of these were released to customers and partners, as bbg 1.0, 2.0, 2.5, 3.0, possibly more.
[05:31] <persia> I think there were even two different versions of bbg 1.0, although I'm less sure of that.
[05:32] <persia> I know of two devices in current retail that appear to be based on these reference designs: the Sharp Netwalker and the Genesi Efika.MX
[05:32] <mwhudson> ah ok, so they were never sold to random passers by in the same way that say the beagle is?
[05:32] <persia> I believe the Netwalker was based on 2.0 and the Efika.MX was based on 2.5, but that's as much of a guess as any surety.
[05:33] <mwhudson> and they're all based on imx.51 chips right?
[05:33] <persia> Freescale has also announced a development program, such that certain folks can purchase a bbg 3.0 at a price roughly equialent to a Netwalker + an Efika.MX.
[05:33] <mwhudson> (is that a chip or a chip family)
[05:33] <persia> But I've heard rumours of availability issues there.
[05:34] <persia> Yes, they are all versions of a reference motherboard for the i.MX51 SoC.
[05:35] <mwhudson> ok
[05:35] <mwhudson> are i.mx51s particularly nice in some way?
[05:35] <persia> The beagle is kinda special: Ti helped design a reference board, but the board design is open, so anyone can make them and sell them.  I don't believe TI actually sells them directly.
[05:37] <persia> i.MX51x is a chip family, I think.  I don't know the disctinctions between versions.  Could be revisions, could be extensions, etc.  Unlikely to make a difference running Ubuntu, as we have little to no software that would take advantage of extensions.
[05:38] <persia> The i.MX51x series is particularly nice in a number of ways, and insufficient in a number of other ways.  I'd have to recommend comparing Freescale's datasheets with those of some of their competitors.
[05:38] <mwhudson> http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=IMX51_FAMILY actually seems *reasonably* helpful on that front
[05:38] <persia> But that gets into the same sort of mess that one hits in comparing, say, Freescale powerpc vs. IBM powerpc, or AMD vs VIA for IA32.
[05:38] <mwhudson> it seems that you'd mostly likely be running ubuntu on a 515
[05:39] <mwhudson> persia: weeeeeeeeeeeeeell the fact that it's a SoC does make some difference there?
[05:39] <mwhudson> though i guess intel and amd use different socket
[05:39] <mwhudson> s
[05:39] <persia> Kinda, sorta.
[05:40] <persia> So it's comparison of CPU+chipset+some peripherals vs. just CPU+socket (with chipset competition per-socket)
[05:40] <mwhudson> mm
[05:40] <persia> So more like powerpc than IA32, just because the powerpc market has similar tendencies towards vertical consolidation.
[05:40] <mwhudson> ok, anyway, i have sucked up a little bit more (noted as possibly inaccurate) information, thanks
[05:40] <mwhudson> right
[05:42] <persia> So, today, if you want an ARM device, your choices are limited to beagle (low specs), the imx51 devices noted above (note that there is currently no imx51 kernel in Ubuntu), or some other devices that run Android which could conceivably be hacked to run Ubuntu.
[05:42] <mwhudson> was it the i.mx51 series that had some earlier versions that had bugs in their neon support?
[05:42] <persia> My recommendation is to wait, unless you're up for kernel maintenance.
[05:42] <mwhudson> well
[05:42] <mwhudson> i'm getting a beagle xm in the mail soon :)
[05:42] <persia> I heard something about that, but I think there was a kernel patch that made it less bad.  I'm unsure.
[05:42] <mwhudson> ok
[05:43] <persia> beagle XM isn't bad, just be aware it's a low-spec platform :)  Makes a handy project box, server, very lightweight client, etc.
[05:43] <mwhudson> yeah, it's just for testing and such
[05:44] <persia> And you may well find lots more folks with deeper knowledge than I on #ubuntu-arm.  I know I've seen folks from a few SoC vendors and ODMs there, as well as the usual free software folk.
[05:44] <mwhudson> given that i, you know, work for this organization with an arm focus now
[05:45] <persia> Heh.  I'm not going to complain about more ports users :)  I just want to be sure folk understand that low-spec devices are low-spec, and that even really cool acceleration stuff and great ISAs don't completely make up for 512MB RAM and relatively slow clocks.
[05:46] <persia> Especially because I keep hearing about devices that will be released "Real Soon Now" that don't have those limitations.  1GB+, 1GHz+, etc.  Mind you, I've been hearing that for well over a year now.
[05:46] <mwhudson> even *i've* been hearing that for a few months
[07:32] <nigelb> lucidfox: I'm having a busy day, but I just dropped by to say: AWESOME blog post!
[07:34] <lucidfox> nigelb> Thanks!
[08:34] <vish> lucidfox: you should have ended it with "Based on a real life story!" :D
[08:35] <lucidfox> vish> Hehehe
[08:35] <lucidfox> I don't generally like naming and shaming, though
[08:36] <vish> lucidfox: yup.. but me having watched the whole events transpire from beginning to end .. it was really pretty well written ;)
[09:18] <chrisccoulson> is there anybody available who knows about the process for creating language packs (specifically how the mozilla translations are imported)?
[09:19] <chrisccoulson> i need to get bug 632760 fixed
[09:20] <micahg> chrisccoulson: are you sure this is a langpack issue and not an upstream one?
[09:20] <chrisccoulson> micahg - the upstream xpi's use a hyphen
[09:20] <chrisccoulson> launchpad is mangling them on import
[09:21] <cjwatson> you might try lp:langpack-o-matic
[09:21] <chrisccoulson> cjwatson, thanks
[09:21] <cjwatson> (are you sure it's on import into launchpad, not export into language packs?)
[09:21] <chrisccoulson> cjwatson, well, i'm not sure really
[09:21] <chrisccoulson> i still don't know how this stuff works ;)
[09:22] <cjwatson> noticing things like this in 'import' in lp:langpack-o-matic:
[09:22] <cjwatson>         locale = tar.split('.')[0].replace('-', '_')
[09:22] <chrisccoulson> heh :)
[09:23]  * cjwatson looks at the langpack export
[09:24] <dpm> chrisccoulson, there is also more background info on http://is.gd/f0syl - Arne used to upload the xpis manually into LP from upstream, and then langpack-o-matic does the rest
[09:26] <chrisccoulson> dpm, thanks
[09:31] <theGuest_> good morning everyone! are you guys aware of bug 624251 in gparted?
[09:33] <cjwatson> theGuest_: sure, I can look at that
[09:33] <cjwatson> thanks
[09:33] <theGuest_> cjohnston, thanks!
[09:33] <theGuest_> cjwatson, hm autocomplete...
[09:37] <cjwatson> chrisccoulson: I don't think it's on the LP side, since LP just feeds langpack-o-matic .po files
[09:38] <cjwatson> chrisccoulson: you might try lp:~arnegoetje/rosetta/po2xpi-arne too - I believe that src/rosetta_xpi_to_sources is what langpack-o-matic calls
[09:38] <cjwatson> chrisccoulson: and there's definitely a bunch of stuff there that's working with chrome.manifest
[09:39] <chrisccoulson> cjwatson - thanks, just looking there now
[09:40] <cjwatson> (BTW I have no operator privileges for langpacks - I just conveniently happen to have a login on that machine)
[09:44] <cjwatson> james_w`: would you mind looking into why the lp:debian/sid/gparted import is out of date?
[10:06] <Daviey> james_w`, Are you about?
[10:08] <Daviey> cjwatson, Perhaps you could help if you have a moment... I encountered a deb src 3 issue yesterday. and seems james_w` also discovered it a few weeks ago.  Essentially, it doesn't do what it says on the tin - regarding overriding binaries.  There is a pretty minimal patch that fixes it, what do you think if i were to cherry pick it for Maverick dpkg? http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff_plain;h=4d2b04f
[10:09] <cjwatson> Daviey: yes, that's fine to cherry-pick
[10:09] <Daviey> rockin', thanks cjwatson
[10:12] <doko> seb128: any idea about #632594
[10:12] <seb128> bug #632594
[10:12] <seb128> no
[10:13] <seb128> didrocks, ^?
[10:13] <seb128> not sure who touched it recently but I've no clue about it
[10:13] <seb128> I'm using compiz for years and never really touched it
[10:14] <ricotz> seb128, do you have a moment, gssdp and gupnp need a rebuild against g-i 0.9.3
[10:14] <didrocks> metacity is working here
[10:14] <didrocks> not sure why buildds have issues
[10:15] <doko> just want to have a working xvfb again :-/
[10:15]  * didrocks looks about what changed in metacity
[10:15] <seb128> could be an xorg issue as well
[10:15] <seb128> ricotz, no change rebuilds?
[10:17] <ricotz> seb128, yes, but gupnp could also be synced from debian
[10:17] <seb128> ok
[10:18] <seb128> could you open bugs about that?
[10:18] <didrocks> doko: nothing in metacity from what I can see of, even not change to codebase (just removing some deprecated patch)
[10:19] <didrocks> last version isn't in bzr. fixing this (but no big change on it too)
[10:19] <ricotz> seb128, ok, there are 3 more sync request of packages which depend on these two, i hope they make it in too
[10:22] <seb128> ricotz, can you open one bug and summarize the changes required in it?
[10:22] <seb128> didrocks, doko: could be an #ubuntu-x issue rather then
[10:24] <persia> I thought the dbus-not-available-during-builds was a dbus-change.  I can't find it right now, but I thought I remembered an email from Keybuk about it a couple months back.
[10:42] <ricotz> seb128, i filed these two bugs - https://bugs.edge.launchpad.net/ubuntu/+source/gssdp/+bug/633019 - https://bugs.edge.launchpad.net/ubuntu/+source/gupnp/+bug/633020
[10:42] <seb128> ricotz, thanks
[10:43] <seb128> I will deal with those today
[10:44] <ricotz> seb128, syncing gupnp 0.13.5-1 from debian/experimental might be worth it, very few changes
[10:44] <seb128> ok
[10:45] <seb128> I will review those
[10:46] <bilalakhtar> zul: ping, ping, ping! A major regression!
[10:47] <bilalakhtar> Bug #626723
[10:47] <ricotz> seb128, these are the request which depend on these two - https://bugs.edge.launchpad.net/ubuntu/+source/rygel/+bug/630528 - https://bugs.edge.launchpad.net/ubuntu/+source/gupnp-av/+bug/630510 - https://bugs.edge.launchpad.net/ubuntu/+bug/630524
[10:48] <bilalakhtar> zul: What would be the right way to go? If I go ahead and make that call mild, then bug #582963 will have to be reopened
[10:57] <Daviey> bilalakhtar, zul won't be online for another 1-2 hours.
[11:00] <Daviey> cjwatson, Are you doing AA work today?
[11:03] <Daviey> cjwatson, Would you be able to look at the upload to lucid-proposed, eucalyptus 1.6.2-0ubuntu30.4.  The other AA doing today is kirkland.  It's his upload, so might be bad karma for him to ack it himself. :(
[11:04] <cjwatson> yep, was going to do it last night but ran out of day
[11:07] <cjwatson> Daviey: duplicate vgextend in util/wrappers.conf - can you confirm that that's harmless?
[11:09] <Daviey> cjwatson, I believe it's harmless  - it's a whitelist, but if you'd rather be certain i can test it.
[11:10] <Daviey> I imagine kirkland did test it before uploading.
[11:11] <cjwatson> no, that's fine, I checked the code and agree it's harmless
[11:12] <Daviey> great
[11:12] <cjwatson> accepting
[11:13] <Daviey> \o/
[11:13] <Daviey> thanks.
[11:23] <Daviey> bilalakhtar, Looking at that bug, It would be unfortunate if a fix to an issue the desktop is seeing breaks server.  Would it be possible to see if the isig flag is actually required, it what seems to be stty or plymouth?
[11:24] <bilalakhtar> Daviey: Well, I have unassigned me
[11:25] <Daviey> bilalakhtar, Is that from fear of stepping on zul's toes?
[11:29] <Daviey> bilalakhtar, Ah, guessing you timed out.
[11:29] <Daviey> bilalakhtar_,, Is that from fear of stepping on zul's toes?
[11:29] <bilalakhtar_> Daviey: nope!
[11:30] <Daviey> oh good.
[12:18] <ricotz> chrisccoulson, hello, i want to propose a sru including this mentioned fix in this bug - https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
[12:19] <ricotz> chrisccoulson, do you had any concerns about this fix?
[12:19] <chrisccoulson> ricotz, yes
[12:19] <chrisccoulson> it's wrong for a start
[12:19] <chrisccoulson> the patch touches the wrong function
[12:19] <chrisccoulson> (i keep getting asked about this patch btw)
[12:19] <chrisccoulson> and i don't think it's SRU worthy really
[12:19] <ricotz> but a patch for this problem is really needed
[12:20] <ricotz> is there another approach to fix this?
[12:22] <chrisccoulson> ricotz, see https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/491940/comments/11
[12:22] <chrisccoulson> i've mentioned this a number of time already, and the current patch still hasn't addressed it
[12:24] <ricotz> i see
[12:24] <ricotz> chrisccoulson, are you aware if this problem still exists using maverick?
[12:25] <chrisccoulson> yeah, i suspect it's still an issue in maverick
[12:27] <ricotz> ok, currently i am using this patch which does its job because without it is quite annoying
[12:27] <ricotz> thanks
[12:29] <chrisccoulson> ricotz, the patch doesn't work from the session dialog though (gnome-session-save), as that code path will never be executed
[12:29] <chrisccoulson> and that applies for anything else in gnome-session that might call the shutdown code
[12:30] <chrisccoulson> (i'm not sure if there is anything that does that though - i know clients can end the session, but i'm not sure if they can shutdown or not)
[12:32] <ricotz> chrisccoulson, i am using lucid with the maverick ltsp packages including this patched gnome-session, this makes it possible to use the session-indicator for shutdown/restart/logout
[12:33] <ricotz> chrisccoulson, i am not near these computers now
[13:15] <zul> morning
[13:16] <mkarnicki> Hi guys, I have a puzzle for you, but you can't use gcc/g++ to check that! Use your brains :)
[13:16] <mkarnicki> int a = 2; char b; b = 'A' + (a-- != 1) ? 0 : 1; // what is the value of a and b after running this
[13:16] <mkarnicki> Remember, don't use the compiler :)
[13:16] <G> zul: morning
[14:50] <cjwatson> kirkland: are you able to boot i386 generic-pae kernels in kvm at the moment?
[14:50] <cjwatson> (both host and guest are i386)
[14:50] <cjwatson> trying to figure out what might have regressed
[15:15] <diwic> Keybuk, or anyone else who is an upstart expert, is it possible to write an upstart job saying "start on (starting rc RUNLEVEL=[06]) and (no pulseaudio processes), i e, to make it start when *both* conditions are fulfilled? https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/592016/comments/20
[15:33] <Keybuk> diwic: no, it's not possible
[15:34] <Keybuk> for a start, you mean "started" rc
[15:34] <kadu> Hi =]
[15:36] <diwic> Keybuk, hmm, it says "starting" here, in /etc/init/alsa-mixer-save.conf, is that a bug then?
[15:38] <kadu> hi everyone
[15:38] <kadu> i want to getting started to help in development of ubuntu
[15:38] <kadu> how i can start?
[15:38] <fagan> kadu: thats in #ubuntu-app-devel
[15:38] <Keybuk> diwic: no, it's not a bug for alsa-mixer-save
[15:38] <Keybuk> read "man starting" and "man started"
[15:39] <ion> fagan: No
[15:39] <kadu> thx fagan.. sorry
[15:39] <kadu> i found this irc channel on ubuntu site... thx
[15:43] <bilalakhtar> Daviey: look at that stty / apache bug again, and see my comment
[15:43] <diwic> Keybuk, okay, I'll just write a pre-start script that waits for pulseaudio to terminate then
[15:44] <Keybuk> I do something similar
[15:44] <Keybuk> look at the plymouth-stop.conf
[15:44] <Keybuk> err, no, I don't think I mean that one
[15:45] <Keybuk> hmm, there is one in there somewhere which does a similar "lock out"
[15:45] <Keybuk> though maybe I never shipped it ;-)
[15:50] <manjo> cjwatson, I see the fix was commited 2 hrs ago, will it make it in todays server iso?
[15:51] <cjwatson> manjo: the server ISOs are built before I wake up in the morning
[15:51] <cjwatson> check the timestamps :)
[15:52] <cjwatson> nothing I do in a given work day will be there until the next day's server ISO build
[15:53] <bilalakhtar> robbiew: heh, I saw your comments on that apache bug
[15:53] <robbiew> :)
[15:53] <bilalakhtar> robbiew: The bug is not fixed yet, the only thing that has happened is that its workaround has been placed in the archive
[15:53] <manjo> cjwatson, ack
[15:53] <robbiew> bilalakhtar: ah, ok...but it's clearly not an upstart bug, right?
[15:54] <manjo> cjwatson, would be nice if you had the power to kick off the build :)
[15:54] <bilalakhtar> robbiew: ah no no
[15:54] <bilalakhtar> robbiew: The bug wasn't even concerning upstart
[15:54] <bilalakhtar> It was apache coming in between and resetting stty flags
[15:54] <bilalakhtar> But getting the workaround in means the reopening of bug #582963
[15:55] <cjwatson> manjo: I do, but it's usually better if I put energy into fixing more bugs rather than babysitting manual builds?
[15:55] <bilalakhtar> robbiew: Did you poke scott to look at it?
[15:55] <robbiew> bilalakhtar: yep ;)
[15:55] <manjo> cjwatson, :) yep
[15:55] <cjwatson> I normally only run manual builds around release times or when something has failed
[15:55] <robbiew> more like nudged
[15:55] <robbiew> heh
[15:55] <bilalakhtar> robbiew: tell him its fixed
[15:55] <robbiew> I did ;)
[15:55] <bilalakhtar> well I found the workaround after hours of digging
[15:56] <bilalakhtar> and if I knew zul was going to apply the workaround directly, then I wouldn't have waited for him to fix it!
[15:56] <bilalakhtar> robbiew: ^
[15:56] <robbiew> bilalakhtar: lol
[15:56] <Keybuk> bilalakhtar: apache should use plymouth to ask for the SSL passphrase, surely?
[15:56] <bilalakhtar> Keybuk: hey!
[15:56] <cjwatson> ttx: I'm looking at the lvm2 package, and trying to decide whether I want to ask for an FFE to pull in a new upstream version
[15:56] <bilalakhtar> Keybuk: yes it should
[15:57] <bilalakhtar> robbiew: Keybuk: I will be off
[15:57] <cjwatson> ttx: the main thing, really, is a fix for bug 621951 - I *think* I may be able to take that in isolation, though I'm not certain
[15:59] <cjwatson> ttx: there are a bunch of fixes listed in the upstream WHATS_NEW file, but all sorts of other stuff as well.  I feel bad about our lvm2 version being rather old, but at this point I'm leaning towards backporting just the udev rule patch and doing a proper job of it in natty, rather than risking breaking eucalyptus or something insanely complicated a few weeks from release.  Do you agree?
[15:59] <ttx> cjwatson: agreed.
[16:00] <ttx> lvm2 is something I'd rather touch in alphas
[16:01] <ttx> cjwatson: so if that fix can be isolated, I think that would be the way to go
[16:26] <SpamapS> ttx: I'm still a little bit confused as to what to do about the mysql kill -9 bug
[16:27] <SpamapS> ttx: we need to establish a standard place for admins to look when an upstart service doesn't stop immediately
[16:27] <ttx> SpamapS: link?
[16:27] <SpamapS> bug 620441
[16:29] <SpamapS> ttx: personally I think its fine to just wait 5 minutes and then kill -9 mysql
[16:30] <SpamapS> but the users of MyISAM tables definitely disagree
[16:30] <ttx> SpamapS: they say you shouldn't send SIGKILL... but if you shut down the process will be killed anyway
[16:30] <SpamapS> ttx: kill -9 corrupts myisam tables
[16:31] <SpamapS> if there are any recent writes .. the table is likely toast.. data will be lost
[16:31] <SpamapS> IMO, this is part of life with MyISAM
[16:31] <ttx> SpamapS: i suspect shutting down with the process still running is no better
[16:31] <ion> Perhaps people should use, you know, reliable databases. :-P
[16:31] <SpamapS> ttx: if you halt the box, yes, you'll still kill -9, but on upgrade, for instance, it will just fail to stop.
[16:31] <ttx> SpamapS: how did this work before the upstart conversion ?
[16:32] <SpamapS> ion: InnoDB is perfectly reliable.. and I agree, people should use it. MyISAM is a dinosaur and quite worthless. :-P
[16:32] <SpamapS> ttx: try for 20 seconds then fail.
[16:32] <SpamapS> ttx: from what I see, if pre-stop exits, no matter what the return code, the service gets stopped
[16:33] <ttx> SpamapS: any way we can replicate that ? At least nobody would be shouting "regression"
[16:33] <ttx> i see no solution that would please everyone
[16:33] <SpamapS> agreed
[16:33] <SpamapS> My thinking was to simply log the warning that mysql timed out waiting for shutdown and had to be forcibly killed
[16:34] <SpamapS> but that brings me to.. whats the best way to log things in upstart jobs.. to which nobody has replied
[16:36] <ttx> let's ping the experts
[16:36] <ttx> Keybuk, slangasek, cjwatson: ^
[16:36] <cjwatson> not I
[16:37] <SpamapS> ttx: also sent a message to ubuntu-devel that hasn't seen any responses
[16:39] <SpamapS> also.. if pre-stop causes a process to die, hopefully it doesn't get respawned.
[16:43] <jdstrand> Keybuk: hey. I'm the reporter of the 'stty sane'/SIGSTOP bug. I also reported bug #627055, which is where X seemingly gets a SIGSTOP out of nowhere (eg, when user's are typing)
[16:43] <jdstrand> Keybuk: it hits infrequently, but frequently enough that I have some users that have lost data as a result
[16:44] <jdstrand> Keybuk: so my question is, are there still issues with /dev/console on up to date lucid where a user's keyboard input could trigger a SIGSTOP?
[16:44] <jdstrand> uhm
[16:44] <jdstrand> ubottu got that wrong
[16:44] <SpamapS> ttx: I suppose the best thing to do now is to raise the kill timeout..
[16:45] <jdstrand> bug #627055
[16:45] <jdstrand> that's the one
[16:46] <ttx> SpamapS: right, that's an easy band-aid
[16:46] <cjwatson> oh, hey, that's interesting
[16:46] <cjwatson> so I requested that bug from ubottu on #ubuntu-meeting, and it didn't reply
[16:47] <cjwatson> or actually it sort of did
[16:47] <cjwatson> 16:28 <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/483001)
[16:47] <cjwatson> and that's the next one I asked for!
[16:47] <cjwatson> 16:32 <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/623609)
[16:47] <jdstrand> Keybuk: I might mention that the affected systems boot with 'quiet' but not 'splash', if that makes a difference
[16:47] <cjwatson> so the bug appears to be that when it hits "could not parse data", it sometimes gets its input and output out of sync?
[16:49] <SpamapS> ttx: or we can just wait forever in pre-stop.. but that brings me back to upgrades failing.
[16:49] <SpamapS> tho I guess the upgrdes would have failed w/ the old method too
[17:26] <slangasek> SpamapS: yeah, why are they using myisam tables? :)  logging in upstart jobs, hem, you can use logger for this sort of thing, there's nothing built into upstart that lets you do arbitrary logging
[17:28] <SpamapS> Right, I'm kind of looking for an upstart job writer's guide.
[17:32] <SpamapS> But really, I think the key is just to raise the kill timeout to 300. 5 minutes should be long enough for normal activities to cease and buffers to flush... and not too long for a normal restart/halt to wait
[17:38]  * ogra glares at https://edge.launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.35-903.11/+build/1951233
[17:38] <ogra> why the heck are we calling pkgstriptranslations in a kernel build ?
[17:39] <ogra> does it do anything beyond what it's name suggests ?
[17:42] <sladen> ogra: isn't the whole point that pkgbinarymangler is generic, you can just run it over any package and its component pieces will either just do the right thing, or do nothing at all
[17:43] <ogra> right, i just dont get what translations we are stripping from a kernel
[17:43] <ogra> i bet it couls save some buildd time to not call it
[17:43] <ogra> *could
[17:46] <sladen> ogra: mostly likely, none!  But other bits of pkgbinarymangler may be doing things
[17:46] <ogra> ah, so its only a sub-process
[17:47] <ogra> pkgbinarymangler in itself is likely needed for dbgsym
[17:49] <manjo> superm1, I can grab some lunch and be at your office ... when is a good time ?
[18:02] <manjo> superm1, let me know when I can swing by
[19:00] <ogra_cmpc> cjwatson, or kirkland, can one of you let linux-ti-omap4 out of NEW (caution, there is a new headers package that wants to go to universe)
[19:03] <apw> that _wants_ to go there but should not
[19:03] <ogra_cmpc> :)
[19:21] <dobey> if i want to get a change in for a package I don't already have upload rights for, what's the quickest way to that? i've already filed a bug and attached a debdiff for it :)
[19:23] <ScottK> dobey: Yes.  That or find someone who does that owes you a favor ....
[19:25] <geser> dobey: and also subscribed ubuntu-sponsors to the bug?
[19:25] <micahg> would someone be able to push banshee-community-extensions through new?
[19:27] <dobey> geser: i have now :)
[20:04] <superm1> manjo, i'm here irght now, so you can come by
[20:04] <manjo> superm1, will be around at 4?
[20:04] <superm1> manjo, that's fine
[20:04] <manjo> ok
[20:56] <tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
[21:48] <cjwatson> ogra_cmpc: done
[21:51] <ogra_cmpc> cjwatson, oh, thanks !
[22:42] <neeraj> When I am running debuild command, then my package is building with any error. Now when i tried to throw the build log in a file using debuild > log.txt, then its giving debuild: fatal error at line 1340:
[22:42] <neeraj> dpkg-buildpackage -rfakeroot -D -us -uc failed
[22:45]  * neeraj ??
[22:49]  * neeraj got gc. Wandering whether his ques was answered or not
[22:50] <Chipaca> neeraj: what happens if you debuild 2> err.txt ?
[22:54] <neeraj> Chipaca: debuild 2>err.txt created blank file. build process was successful
[23:12] <tkamppeter> OdyX, hi
[23:14] <neeraj> can I add new folder while creating patch using quilt?
[23:15] <OdyX> neeraj: afaik yes
[23:15] <neeraj> I mean till now I was just editing file using quilt
[23:16] <neeraj> hmm.. but I am unable to find any cmd on man http://linux.die.net/man/1/quilt :(
[23:17]  * neeraj I am able to create new file. edit automatically creates one if its not present
[23:18] <cjwatson> just make the directory and add the files inside it
[23:18] <cjwatson> you don't need to add the directory separately
[23:19] <neeraj> cjwatson: ok. thanks for the pointer. :)
[23:20] <cjwatson> neeraj: the only thing to note is that quilt won't remove the empty directories when you pop the patch that created them
[23:20] <cjwatson> this usually doesn't matter
[23:21] <neeraj> Actually I manually editied some file in various folder of one package.(which was formed by combining more than one package.) Now debdiff command is showing all changes, but new deb files are nt..
[23:29] <Riddell> cjwatson: how come kubuntu-mobile images successfully include plasma-mobile?  I thought there was an issue where it needed to be moved to main or launchpad have its cron changed
[23:37] <SpamapS> is there a way, with bzr-buildpackage, to get it to generate the deb src 3.0 quilt packages and commit them rather than commit changes to the source files?
[23:38] <SpamapS> err. I mean quilt patches
[23:46] <cjwatson> Riddell: Launchpad would need to have its cron job changed if kubuntu-mobile were split into a separate seed collection with the aim of leaving kubuntu-mobile in universe
[23:46] <cjwatson> Riddell: you might see from http://people.canonical.com/~ubuntu-archive/component-mismatches.txt that kubuntu-mobile and plasma-mobile are in the list of things to be promoted to main