[00:06]  * slangasek wonders if anyone wants to fix hdf5 on armel
[00:11]  * persia looks at the log
[00:12] <persia> slangasek: Am I reading correctly that *sed* segfaulted?
[00:13] <slangasek> persia: it probably segfaulted when running ./H5detect, *after* running the sed to set LD_LIBRARY_PATH
[00:14] <persia> Hrm.  Do you have any input information that would help track down the issue?
[00:20] <slangasek> persia: no, all I know is that this is the root of all the build failure mails I'm getting the last two days :)
[00:20] <joaopinto> Keybuk, about the "/dev/somehwere" case, can't you just introduce a delay on mountall when there is an error ? to allow for plymouth to start before seding the prompt ?
[00:20] <persia> That's a charitable explanation that doesn't blame lamont and I for brute-force approaches.  Thanks :)
[00:21] <persia> Anyway, emulated build is running now.
[00:21] <joaopinto> Keybuk, I guess a few seconds delay when there is a mount error would not hurt :)
[00:22] <slangasek> joaopinto: hackish; we should just fix plymouth instead
[00:22] <joaopinto> slangasek, right, but right now a typo on fstab will render systems unbootable :P
[00:22] <persia> What should plymouth do in that case?  Isn't it not even running at that point?
[00:23] <slangasek> persia: no, plymouth is running before mountall
[00:23] <persia> Even when plymouth isn't in initramfs?
[00:23] <slangasek> the issue is that messages sent *to* plymouth by mountall, before plymouth show-splash is called, are lost
[00:23] <slangasek> yes - *plymouth* is running, only the splash screen isn't
[00:23] <persia> Aha.  I have an improved understanding.
[00:23] <slangasek> because the splash screen depends on video device -> udev -> virtual-filesystems -> mountall
[00:24] <joaopinto> how does the mountall <-> python protocol work ? mountalls waits for an answer to the S/M prompt ?
[00:24] <joaopinto> ops, s/python/plymouth
[00:25] <slangasek> it continues other processing, but has an event loop to check for an answer to that prompt
[00:26] <joaopinto> queuing the prompt until the splash is available is not an option ?
[00:27] <slangasek> of course it is; but that queuing should be done within plymouth
[00:27] <slangasek> because mountall doesn't know, and shouldn't know, when the splash is available
[00:27] <slangasek> hence - "we should just fix plymouth instead"
[00:27] <joaopinto> ok :)
[00:31] <rojanu> Everytime a user logs in title bars on apps are missing, they appear after I select normal from Visual effect.  I am using nVidia 195.36.15
[00:31] <rojanu> Any ideas how to fix it permanently?
[00:42] <slangasek> jdstrand, mdeslaur: what was your bug number for the "nouveau only gives 16-bit fb" issue?  I think bug #565936 is a duplicate
[00:48] <slangasek> tjaalton: reviewed xorg-server - sorry, this changeset is too large for this stage; can we just cherry-pick the xorg.conf.d part?  (that part makes sense to me to take, because it saves us having to carry config file clean-up code for 2 years)
[00:50] <slangasek> jdstrand, mdeslaur: found it, bug #554143
[00:51] <slangasek> oh, that was radeon, not nouveau, doh
[00:56] <slangasek> tjaalton: "drop 05-evdev.conf, this moved to the server" - should this have some sort of versioned depends or breaks somewhere, to ensure a smooth upgrade?
[01:01] <slangasek> tjaalton: given that there are no upgrade guards in here, and given that it's a move from /usr/lib to /usr/share (I thought it was a move from /etc/X11 to /usr/share - sorry for misunderstanding), I think this is pretty high-risk for the benefit - I'd like to see versioned relationships set here to ensure partial upgrades work smoothly, and once we *have* that, I think the motivation for getting this in before lucid final is diminished -
[01:01] <slangasek> ... probably just be deferred to maverick
[01:04] <slangasek> ArneGoetje, pitti: we're missing language-pack-gv-base, breaks DVD builds due to presence of language-pack-gnome-gv
[01:55] <ArneGoetje> slangasek: ok, will upload the -gv langpacks only
[01:56] <slangasek> ArneGoetje: ok, thanks - the other langpack changes you had were just roll-ups, not any particular bugfixes?
[01:57] <ArneGoetje> slangasek: I'm not sure if there are bugfixes inside, but I guess they can wait for the final export...
[01:57] <slangasek> alright; I believe that's best at this point
[01:58] <slangasek> ArneGoetje: though if the fix for bug #565180 is in your current export, language-pack-kde-de is probably a good one to have uploaded before final
[01:58] <slangasek> (if not, then we'll wait for the final export)
[01:59] <ArneGoetje> slangasek: if it's 'Fix Committed', then it's likely that fix is in this export
[02:02] <ArneGoetje> slangasek: however, as we have versioned dependencies in the langpacks, I will need to upload all -de langpacks
[02:02] <slangasek> ArneGoetje: that would be fine
[02:03] <ArneGoetje> slangasek: ok, will upload now
[02:05] <ArneGoetje> slangasek: hmm... -gv has not been translated enough, so there is no language-pack-gv-base... only the -gnome package exists... I guess we should block that one then.
[02:07] <ArneGoetje> slangasek: eh... that package is empty... hwo could that happen? So, please remove it from the archive.
[02:07] <slangasek> can do
[02:08] <slangasek> ArneGoetje: done
[02:08] <ArneGoetje> slangasek: thanks...
[02:11] <ArneGoetje> slangasek: -de uploaded
[02:11] <slangasek> thanks :)
[02:56] <psusi> cjwatson, you asked me to do some testing on the slow down caused by the dpkg sync changes... I have completed them.  Time to upgrade with packages already downloaded to disk going from a clean beta 2 install to current goes from 6m21s to 11m15s when switching from -ubuntu3 to -ubuntu4 of dpkg
[03:03] <chrisccoulson> oh, so dpkg _is_ slower now then
[03:03] <chrisccoulson> i thought i'd noticed that again
[03:03] <psusi> yea... -ubuntu4 apparently went back to syncing, but only after unpacking all files in a package... so not quite as bad, but still bad when upgrading many packages
[03:04] <chrisccoulson> i'm not sure if my issue is only with dpkg, but my laptop is unusable whilst installing/upgrading packages atm
[03:04] <chrisccoulson> the cursor freezes for some ~30s at a time
[03:05] <psusi> try downgrading to -ubuntu3?
[03:06] <chrisccoulson> i might do, but in the morning now
[03:06] <chrisccoulson> it's getting late ;)
[03:34] <persia> slangasek: I can't replicate the hdf5 build failure: it builds fine for me.  So unless you can find someone who *can* replicate it, I think you'll have issues getting the FTBFS cleared.
[03:34] <slangasek> persia: doh
[03:35] <slangasek> persia: well, thanks for looking
[03:35] <persia> http://paste.ubuntu.com/418278/ for the curious
[04:54] <slangasek> mdke: still "today" as an ETA? :)
[05:30] <tjaalton> slangasek: now that evdev.conf is shipped with the server it means that it's always available, meaning that mouse & kbd works even with partial upgrades
[05:31] <tjaalton> slangasek: the drivers {build-,}depend on the new xserver too
[05:31] <persia> tjaalton: But what happens if one *only* upgrades the server, and doesn't upgrade anything else?  Isn't there a conflict with the old version of the file?
[05:31] <tjaalton> persia: no, the old one is ignored
[05:31] <persia> And they are in different locations?
[05:31] <tjaalton> yes
[05:31] <slangasek> not a conflict, but everything except evdev gets ignored, yeah
[05:31] <persia> Hmm.
[05:34] <tjaalton> though it gets more hairy if the server version isnt' bumped
[05:34] <ccheney> slangasek: ok, sorry didn't see your message until now
[05:34] <persia> tjaalton: But don't the new drivers depend on the new server version?
[05:35] <tjaalton> persia: they would, but no point in getting them then
[05:35] <tjaalton> (bdeps on the new upstream version)
[05:36] <persia> Right, so really there's no combination of upgrades that dpkg will accept in which anything breaks?
[05:37] <tjaalton> well, the deps could be relaxed to match our xserver version, though that needs some of the packaging changes from xserver to support xinputver etc
[05:38] <tjaalton> with that in place, yes, nothing should break too horribly
[05:40] <tjaalton> slangasek: so just getting that xorg.conf.d patch means that either keep /usr/lib in the search path and ship the current drivers (ugly, but working), or migrate the drivers
[05:42] <slangasek> my concern is that there are a lot of packages to coordinate, and the change has fairly low impact on the user; but failing to get the packages all built in time for RC (due to any of a number of possible reasons, not limited to bugs in the packages) would have a *high* impact, because the out-of-date driver packages would be installing their files to the old search path
[05:43] <slangasek> that, plus the fact that partial upgrades are possible that would cause the user's devices (other than evdev) to stop working as intended
[05:43] <slangasek> the server could declare Breaks: on the old versions of the drivers to address this - but at this point, we're close enough to the time when we need to start ISO mastering that it's just too risky
[05:44] <slangasek> bryceh, apw: bug #566379 is a regression for an i855 user introduced when disabling KMS by default
[05:45] <slangasek> tjaalton: sorry - if I'd have been able to review this for you last night and gotten a new server upload done then, it would've been possible; now we're just out of time
[05:45] <slangasek> ccheney: no worries - it only took me two uploads to get it right ;)
[05:46] <slangasek> ccheney: but you may want to look at why OOo bzr was out-of-date wrt the packaging branch - I haven't committed my changes there for the two uploads because I thought you might want to investigate that first and get it in-sync
[05:46] <tjaalton> slangasek: alright
[06:24] <tjaalton> slangasek: hmm, actually re-adding /usr/lib/X11/xorg.conf.d to the search path should cover your concerns, but I'll rest my case :)
[07:03] <pitti> Good morning
[07:35] <mdke> slangasek: test build hadn't finished by the time I went to bed. Tested now and am uploading
[07:36] <slangasek> mdke: ack, thanks
[07:37] <mdke> slangasek: that's for ubuntu-docs. Will it be ok if gnome-user-docs follows this evening?
[07:38] <slangasek> mdke: that's rather late for inclusion on the RC images.  is there something I can do to help it get done sooner?
[07:41] <mdke> slangasek: I need to update the translations from Rosetta. I'll see what I can get done now but I would have thought that inclusion on RC isn't absolutely essential
[07:43] <slangasek> mdke: what's essential is to change as little as possible between RC and final; the standard checklist at https://wiki.ubuntu.com/ReleaseProcess calls for these packages to be uploaded prior to RC...
[07:44] <slangasek> mdke: if we *have* to pull it in post-RC, we will, but I'd certainly prefer to have it before
[07:45] <mdke> slangasek: ok, I'll give you a shout in 30 mins or so
[07:46] <slangasek> mdke: ok - if I can be of any help with the Rosetta importing, I'd be happy to do so
[07:46] <mdke> thanks. I've started it off now
[07:58] <baptistemm> heya
[07:59] <mdke> robert_ancell: legend, thanks
[07:59] <robert_ancell> mdke, np :)
[08:00] <joaopinto> good morning
[08:16] <mdke> slangasek: ok, I've pushed the changes to ~ubuntu-core-doc/gnome-user-docs/lucid and started a test build - will let you know how it goes
[08:16] <slangasek> mdke: cheers!
[08:22] <dholbach> good morning
[08:27] <joaopinto> slangasek, was discussing this with KeyBuck yesterday, imho the recovery mode should not trigger mountall, recovery mode was useless to troubleshoot the hang cause
[08:29] <joaopinto> mounting all configured systems is not a trivial operation, one of those that you might want to recover from
[08:32] <slangasek> joaopinto: that's a different level of recovery than the recovery mode menu we've used to date, though; the recovery menu requires /usr to be mounted, and that may be a separate fs
[08:33] <slangasek> joaopinto: I agree that this mountall bug makes it awkward, but it's not realistic to revisit such a fundamental design decision for lucid
[08:35] <joaopinto> ok, well, I am most used to UNIX single user modes for recovery, kernel loaded, root fs mounted, init started, and a shell
[08:35] <joaopinto> someone using a /usr on a different partition should know how to manually mount it :)
[08:36] <mdke> slangasek: ok, that's uploading now. Sorry I didn't get it done when I said I would
[08:36] <slangasek> mdke: 'sok, we're still in the game :)
[08:36] <slangasek> mdke: thanks for the quick turnaround this morning!
[08:44] <mdke> slangasek: :)
[08:47] <pitti> slangasek: I have two more keymap fixes for stuck keys for udev; however, these (and similar future fixes) require a slight reorganization (well, really just a renaming) of the maps files: http://people.canonical.com/~pitti/tmp/0003-keymap-Unite-laptop-models-needing-common-volume-key.patch - is that okay for you for lucid final? (two rules additions will go on top of that for two laptop models)
[08:48] <pitti> slangasek: (this will unfortunately produce some autoconf file noise)
[09:11] <mantiena> Hi all
[09:20] <slangasek> mvo: bug #566453> which part of this is the warning that you consider a bug?
[09:23] <mvo> slangasek: feel free to close if the warnings do not matter, it just appreard in the auto-install-tester log
[09:24] <mvo> slangasek: and user may be confused/scared by it, but its low priority anyway, just wanted to  record it for later
[09:25] <slangasek> mvo: would moving the update-alternatives call to the prerm fix the warning?
[09:26] <mvo> slangasek: I think it will,
[09:29] <slangasek> mvo: ok - could you comment that in the bug so we don't forget?
[09:29] <mvo> slangasek: will do, thanks
[09:33] <joaopinto> mvo, question about the motivation for the binary.changelog, is it possible for a source package to generate binaries with random versions ?
[09:33] <mvo> joaopinto: yes, take gcc-defaults as a example
[09:33] <mvo> joaopinto: there is a small number of packages that do that
[09:33] <mvo> joaopinto: but those tend to be important
[09:34] <pitti> james_w: I upload a new kerneloops with disabling it by default now
[09:35] <joaopinto> hum, I am puzzled how that plays with binary.changes files
[09:35] <joaopinto> because you have a single "Version:" field, which I suppose it's related to the binaries, not to the source
[09:37] <mvo> joaopinto: the version in the changelog refers to the source changelog
[09:37] <mvo> joaopinto: (if that is what you mean, not sure I understand the question)
[09:37] <pitti> mdke: we want to disable the "Report a bug" menu item for the final release (https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management); would that touch documentation?
[09:38] <joaopinto> mvo, right, I am trying to figure where do you relate a source version X, with a binary version Y, I mean at a control level, without relying on the Files list
[09:39] <james_w> pitti: thanks!
[09:39] <pitti> james_w: (I used lp:ubuntu/kerneloops, is that right?)
[09:39] <joaopinto> mvo, well, I will check gcc-defaults to save your time :)
[09:39] <james_w> pitti: yup
[09:39] <mvo> joaopinto: yeah, do that, its a good example, its justing substvars for it
[09:44] <joaopinto> anyone aware of an ext4 change that might result in a major performance hit on ext4 writes ? I mean from karmic to lucid
[09:44] <SwedeMike> joaopinto: the disk io scheduler was changed a bit., could affect that.
[09:45] <joaopinto> SwedeMike, hum I got such a penalty that I had to force barrier=0 on my ext mounts
[09:46] <joaopinto> a debootstrap was taking 10x more than it previosly did
[09:46] <SwedeMike> and you were running with barriers in karmic as well?
[09:46] <joaopinto> I didn't touched barriers there, actually I jut became aware of barriers after noticing this problem now
[09:47] <joaopinto> SwedeMike, was that changed early on the development cycle or a short time ago ?
[09:48] <SwedeMike> that was in 2.6.32 so should have been all the way in lucid
[09:48] <slangasek> seb128: libdbusmenu/indicator-messages> are there more uploads pending from this quarter?  It's only by luck that we haven't started RC ISO mastering yet
[09:49] <SwedeMike> joaopinto: http://lwn.net/Articles/352863/
[09:49] <directhex> joaopinto, dlr-languages does the binary-version-mangling trick
[09:49] <pitti> slangasek: from this quarter> if there's still room, http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=db57bdda04e20667f510262d045c2af6fe335931 falls under that category; it would make SRUing keymap fixes a bit easier, since these would avoid file renames
[09:50] <seb128> slangasek, no, that is the remaining issue I knew about from dxteam
[09:50] <SwedeMike> joaopinto: my bad, that wasnt io scheduler, that was cpu scheduler
[09:50] <seb128> slangasek, ted sent updates my way during the weekend
[09:51] <slangasek> seb128: yep - I see he even linked the branch; if I had been paying closer attention, perhaps I could've had those sponsored in before today :/
[09:51] <seb128> slangasek, you think they can still go in RC or better after RC now?
[09:52] <slangasek> seb128: before RC
[09:52] <slangasek> always before, if there's a choice ;)
[09:52] <seb128> ;-)
[09:53] <slangasek> pitti: udev> can you get that uploaded now, and I'll figure out what to do with it once it's there?
[09:53] <pitti> slangasek: yup
[09:54] <joaopinto> SwedeMike, thanks anyway :)
[09:55] <joaopinto> directhex, checking, tks
[10:03] <seb128> slangasek, pitti: if,when you review gir-repository consider the newer of the 2 uploads, the was a missing build-depends in the first one, the update drop the gtk gir since that's built by the gtk source now
[10:04] <slangasek> seb128: pre-emptively dropped the first one from the queue
[10:04] <seb128> slangasek, thanks
[10:08] <pitti> slangasek: udev uploaded and tested
[10:11] <pitti> slangasek: I'm going to look at the pm-utils suspend blacklisting now (bug 526354); but I want to test this carefully, so it might be for post-RC or for the next RC spin
[10:12] <slangasek> pitti: right, sounds good
[10:16] <jibel> mvo, could you please review and upload 565816 ? thanks
[10:27] <mvo> jibel: yes
[10:34] <mvo> jibel: thanks, merged and uploaded. there appears to be another small issue in the branch, when I double click on something uninstalled it gets marked for install, when I doulbe click again, it does not change status, I think that used to be different (i.e. double click again would unmark again)
[10:57] <pitti> slangasek: pm-utils uploaded (admittedly a nasty solution, but let's hope it only has to last for some two weeks)
[10:58] <mdz> ara: I think the "150" figure for Xubuntu testers is misleading, e.g. somehow I am a member of this team through some indirect membership :-)
[10:59] <ara> mdz, :)
[10:59] <ara> mdz, I sent the email to xubuntu-devel as well, it might be a better audience
[11:00] <james_w> by my reading emacs22 shouldn't be on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt as auctex has emacs23 | emacs 22 and it just seems to be depending on itself then. Can anyone see otherwise?
[11:02] <ara> mdz, found it. ubuntu core -> xubuntu devel -> xubuntu team -> xubuntu testers
[11:02] <slangasek> james_w: nope, that one I'd been skipping because I was pretty sure it was just an accounting problem
[11:02] <james_w> right
[11:02] <ara> mdz, lost in a chain of indirect membership
[11:03] <james_w> slangasek: any idea why we had an upload a few hours ago that LP seems to be attributing to katie?
[11:03] <slangasek> james_w: urk, no
[11:03] <ara> mdz, indirect membership are a bit useless in some cases; I would like to be able to use the Contact Team Members feature without spamming people not interested in testing Xubuntu
[11:03] <james_w> I can't see a bug for the sync either
[11:04] <james_w> slangasek: ah, it was a promotion a few hours ago, the sync was a while ago
[11:04] <mdz> ara: I agree, we get too much spam as a result of nested teams
[11:04] <slangasek> james_w: ah :)
[11:04] <mdz> in part because teams are (ab)used for ACL purposes
[11:04] <mantiena> cjwatson: hi, can you tell me if there are any plans to update ubiquity translations from launchpad before final lucid release? Yesterday O
[11:05] <ara> mdz, yes. I will file a wishlist bug against launchpad to have the opportunity to "Contact this team's DIRECT members"
[11:06] <mantiena> Yesterday I've fixed some important Lithuanian translations errors in ubiquity-debconf translation - our translation leader introduced some bugs 10 days ago :(
[11:06] <ara> mdz, sorry for the noise
[11:07] <mdz> ara, just remember to specify the problem, not only the proposed solution, since they may have a better idea for how to fix it :-)
[11:07] <ara> mdz, will do ;-)
[11:11] <mantiena-baltix> Maybe someone could tell me if Evan Dandrea will be here?
[11:12] <james_w> ccheney: openoffice.org-common depends on xfonts-mathml. Do you know if it needs ttf-lyx that the latter recommends?
[11:19] <Daviey> ScottK: bug #566497 is looking valid.. Fresh install of clamav didn't give me a logroate.d/*clam* file.. If it's being too verbose or not i don't know, but there isn't any way i can see it's being rotated.
[11:19] <cjwatson> mantiena-baltix: ev updated them yesterday
[11:19] <cjwatson> mantiena-baltix: isn't this the second release where we've had last-minute Lithuanian updates?
[11:20] <cjwatson> maybe I don't mean yesterday, looks like Friday - after the non-langpack deadline anyway
[11:23] <slangasek> IIRC it was gfxboot last time that needed a last-minute update, yeah
[11:29] <mantiena-baltix> cjwatson: yes, this is the second, last one was Ubuntu 9.04 ;)
[11:30] <cjwatson> mantiena-baltix: it's possible there'll be an upload after RC to cover installer bugs that come up from ISO testing, and in that event there'll probably be a translation update too
[11:30] <cjwatson> but I can't guarantee it
[11:31] <mantiena-baltix> cjwatson: our translation leader accidentally introduced some translation errors just 10 days ago - that's why nobody noticed and didn't fixed these errors :(
[11:33] <mantiena-baltix> some of these errors are just mistypes - for example "idegta" instead of "įdiegta", but in lithuanian word "idegta" means burned, while įdiegta"
[11:33] <mantiena-baltix> means installed
[11:35] <mantiena-baltix> So, currently Lithuanian users see this text in ubiquity "step 7": Your new operating system will now be burned with the following settings !!!
[11:38] <proppy> doko__: thanks a lot for #560135
[11:38] <joaopinto> mantiena-baltix, burned looks cool :D
[11:38] <ara> mdz, bug 566536
[11:38] <joaopinto> Ubuntu on fire :)
[11:42] <cjwatson> mantiena-baltix: well, sorry, but I can't help the timelines.  We'll do what we can if there's another opportunity, but if there isn't another opportunity then you may be stuck with it
[11:48] <ScottK> Daviey: OK.  Thanks.  I'll look into it.  There were some changes in how logging works in the last upload.
[11:56] <Daviey> ScottK: Yeah, i had a quick look.. pretty confusing how the logrotate file gets generated! :)
[11:56] <ScottK> Daviey: Can you join #debian-clamav on OFTC?
[11:56] <Daviey> ScottK: My initial thought is that $LogFile is NULL.
[11:58] <Daviey> ScottK: done
[13:03] <lool> doko__: Would it make sense to sync gcc-4.5 over to lucid?
[13:03] <doko__> lool: ??? late April joke ???
[13:08] <lool> doko__: Hmm no, in universe?
[13:09] <lool> doko__: I didn't find mcuh regression potential and thought this might be useful
[13:10] <doko__> lool: no, overwrites all shared libs
[13:10] <doko__> lool: use gcc-snapshot
[13:10] <lool> doko__: Ah, I thought gcc-defaults was masking all of that
[13:10] <lool> but indeed, does not
[13:10] <lool> doko__: So nm  :)
[13:10] <doko__> or the ubuntu-toolchain/test PPA
[13:11] <doko__> lool: but you can try to convince slangasek ;)
[13:11] <lool> tss :)
[13:30] <slangasek> pitti: bug #526354 - your pm-utils fix worked ;P
[13:31] <pitti> slangasek: right, that's what I meant with "ugly" :/
[13:31] <pitti> slangasek: hiding the option in the session menu would require code changes in upower unfortunately
[13:31]  * slangasek nods
[13:31] <pitti> it doesn't call pm-is-supported, but reads /sys/power/state and greps for "mem"; nothing in between to hook into :?
[13:31] <pitti> s/?/(/
[13:35] <dholbach> chrisccoulson: happy birthday! :)
[13:35] <chrisccoulson> thanks dholbach :)
[13:35] <pitti> chrisccoulson: ooh, happy birthday!
[13:36] <didrocks> happy birthday chrisccoulson
[13:36] <chrisccoulson> thanks everyone :)
[13:37] <seb128> chrisccoulson, happy birthday! ;-)
[13:42] <mvo> happy birthday chrisccoulson
[13:43] <nigelbabu> chrisccoulson, wow, birthday!  Happy Birthday!
[13:57] <slangasek> chrisccoulson: hi, james_w tells me you might know something about the problems with updating sugar-browse-activity to 0.88?
[13:57] <slangasek> chrisccoulson: oh, and happy birthday :)
[13:58] <chrisccoulson> slangasek - thanks :)
[13:58] <james_w> oh happy birthday chrisccoulson
[13:58] <chrisccoulson> yes, sugar-browse-activity needs python-xpcom, which isn't packaged anywhere yet
[14:51] <jhernandez> hi
[14:53] <jhernandez> anyone knows where and when is generated /etc/fstab during installation, and if it is a file from a template or it is generated on-the-fly??
[14:58] <seb128> slangasek, pitti: do you prefer small fixes to still go in the lucid queue for after RC approval or to be changed in SRU updates now?
[14:58] <slangasek> seb128: is "small" a measure of their impact, or their diff size? :)
[14:59] <smoser> slangasek, with keybuk not around, i will beg to you for a couple thoughts if you don't mind.
[14:59] <smoser> bug 565018
[14:59] <seb128> slangasek, things like the change on bug #475090
[15:00] <smoser> slangasek, can you come up with any reason as to why one (or more) jobs set to start on 'filesystems' would correctly start, but one would not
[15:01] <smoser> (this is hard to reproduce, somewhere like 2% maybe or less)
[15:02] <seb128> slangasek, or http://git.collabora.co.uk/?p=papyon.git;a=commitdiff;h=5f9e7e0da5a89b80190087022a633eca7f7f2d8e
[15:03] <seb128> slangasek, ie changes which are small in code change and limited risk but not fixing bugs which need to be fixed in lucid (ie things which can be sru-ed without issue)
[15:03] <smoser> but the log i captured shows no evidence of this job ever being started, and the debug output occurs at the very top of 'cloud-init-cfg' that is execed from the job
[15:03] <slangasek> seb128: I would say SRU for the first; I don't understand the impact of the second, but if you say it doesn't need to be fixed for final, Ithink SRU is best for that too
[15:04] <seb128> slangasek, the second will lead to a telepathy-butterfly crash when receiving some messages from buggy clients
[15:05] <seb128> slangasek, ok, I will start to put some sru material fixes in my upload queue and ping you if I've a fix which I think might be worth trying to get in lucid proper rather than a sru
[15:05] <seb128> slangasek, thanks
[15:16] <cjwatson> jhernandez: on the fly; the core is in partman-target
[15:16] <cjwatson> jhernandez: though there's a partial template involved
[15:16] <cjwatson> jhernandez: what do you want to know?
[15:16] <jhernandez> thx for your response cjwatson
[15:17] <jhernandez> ubiquity (or another package) creates a cdrom's line in fstab
[15:17] <cjwatson> not any more in lucid
[15:18] <jhernandez> i have pcs without cdrom
[15:18] <cjwatson> http://launchpadlibrarian.net/38682219/partman-target_64ubuntu5_64ubuntu6.diff.gz
[15:18] <slangasek> smoser: what job does the 'generating public/private rsa key pair'?
[15:19] <smoser> the job listed there.
[15:19] <smoser> cloud-config-ssh
[15:19] <slangasek> ok
[15:19] <smoser> (comment 4)
[15:19] <smoser> as far as I can tell, it just doesn't run
[15:19] <jhernandez> thz
[15:19] <jhernandez> thx, cjwatson
[15:20] <cjwatson> though I'm not aware that it ever created those on systems without CD drives; but it doesn't matter if it did, since that code is gone now
[15:20] <jhernandez> i have my answers in the link above
[15:20] <cjwatson> (i.e. I'm not going to debug it if it did create them on a system without a CD drive)
[15:21] <jhernandez> okok
[15:21] <jhernandez> lot of thanks
[15:21] <jhernandez> :P
[15:24] <slangasek> smoser: have you done the test with the upstart debugging turned on?
[15:24] <smoser> i've been trying to get one
[15:25] <smoser> as, yeah, i want that too
[15:26] <smoser> and my scripts had some bugs so they failed to catch console output the couple times when the other stars were alignged
[15:32] <ccheney> james_w: probably from what the description of xfonts-mathml itself says
[15:32] <ccheney> james_w: " You will also need to install the packages: otf-stix (STIX fonts) and ttf-lyx (TeX's Computer Modern fonts) to view MathML properly.
[15:33] <james_w> ccheney: yes, but it's talking about browsers, so I wondered if it was the same
[15:33] <ccheney> james_w: oh, hmm i'm not sure i can dig around some more and see
[15:33] <james_w> as it stands we have to promote the whole of lyx to satisfy it
[15:39] <ccheney> james_w: eh, why?
[15:39] <ccheney> james_w: ttf-lyx doesn't depend on anything other than defoma
[15:39] <james_w> ccheney: xfonts-mathml recommends ttf-lyx which is in the lyx source package
[15:40] <ccheney> there are lots of instances of binary packages that are split between main and universe, or did you mean it requires the source to be in main too?
[15:40] <slangasek> ccheney: yes, the source
[15:41] <ccheney> ok
[15:41] <slangasek> MIRs are done on a sourceful basis; so all the review for main-worthiness has to be done up front
[15:41] <ccheney> the person who filed the bug in debian seemed to indicate that probably xfonts-mathml is enough for OOo
[15:42] <ccheney> which is already in main so we can probably safely ignore the ttf-lyx
[15:45] <mvo> ccheney: hi, bad news. the OOo pre-depends are still causing some grief bug #566584 and bug #516727
[15:47] <ccheney> mvo: the pre-depends was already fixed back to the way it used to be, can we just fix apt already? :)
[15:49] <mvo> ccheney: well, that may not be feasible for -final, I would prefer a isolated workaround at this point than to change the apt ordering code
[15:50] <ccheney> mvo: if i understand what you wrote in that bug report i need to remove the apt workaround in OOo to make it work for libgstreamer0.10-0 but then it fails later in the same upgrade cycle on something else for similar reasons?
[15:51] <ccheney> oh nm i saw the add libxml2 to openoffice.org-evolution, not sure how i missed that
[15:51] <ccheney> but you said it still doesn't fix the upgrade?
[15:51] <mvo> ccheney: correct, I'm looking at it currently in a VM, but I have no real good idea yet. one obvious fix is to get rid of the pre-depends entirely, but as I understand _rene_ they are needed
[15:51] <ccheney> yea
[15:52] <mvo> ccheney: the other is to remove ooo-evolution, -emailmerge, -filter-binfilter on upgrade
[15:52] <ccheney> the pre-deps as they were before the apt workarounds were needed
[15:52] <mvo> and add them again afterwards
[15:52] <mvo> but all is very not-cool
[15:52] <ccheney> thats probably workable too but only would work assuming the people upgrading were following proper procedure :)
[15:53] <ccheney> sounds like apt's pre-depends resolver is totally broken
[15:54] <mvo> well, I would say "totally broken" given that it works as it is currently since a couple of year, but definietly broken when confronted with a pre-depdns line like the one from OOo
[15:55] <ccheney> well it was initially rather simple unless i misunderstand it
[15:55] <ccheney> just: openoffice.org-core (>= 1:3.1.0-2), debconf (>= 0.5) | debconf-2.0, procps
[15:55] <dholbach> ccheney: I'm sure mvo would love to see patches to fix it ;-)
[15:55] <ccheney> i guess the debconf part could have been complicated but it got confused on the openoffice.org-core part :)
[15:55] <ccheney> so is it an issue with versioned pre-depends?
[15:56] <ccheney> dholbach: hmm yea maybe i will have time to hack on it during maverick cycle
[15:56] <mvo> ccheney: right, its openoffice.org-core  that ships a long list of depends
[15:57] <mvo> ccheney: I don't think its the versionizing
[15:57]  * ccheney wonders if its an interaction with installing recommends by default
[15:58] <ccheney> mvo: i see something that might be causing it to be upset
[15:59] <cjwatson> the extensive Conflicts in OOo seem likely to cause difficulties
[15:59] <ccheney> mvo: the first depends in openoffice.org-common is: openoffice.org-style-default | openoffice.org-style  which has to be satisified by a virtual package
[16:00] <ccheney> cjwatson: oh
[16:01] <cjwatson> I haven't traced it, but that would be my first guess for any problem involving Pre-Depends when there isn't an obvious straightforward Pre-Depends loop
[16:01] <ccheney> cjwatson: ok
[16:02] <cjwatson> mvo is probably much further along than I am in tracing it so probably no point in me trying to figure out exactly where it is :)
[16:02] <mvo> cjwatson: :) its a nightmare
[16:03]  * ccheney hopes i can get some of those dropped by debian after the next debian release
[16:04] <ccheney> slangasek: should i go ahead and do the new upload with updated pre-depends on wait for arm to build?
[16:04] <ccheney> s/on/or/
[16:05] <slangasek> ccheney: no need to wait before uploading; is this expected to go in before RC though?
[16:06] <ccheney> slangasek: depends on if mvo thinks its important to make the RC for testing purposes I guess
[16:06] <ccheney> mvo: ^ ?
[16:09] <mvo> (on the phone atm, sorry)
[16:11] <highvoltage> slangasek: hi! I'm not sure if stgraber pinged you about it already, but if there's resources available for it could you fire up another edubuntu build?
[16:15] <slangasek> highvoltage: you two need to talk to each other more :)
[16:15] <slangasek> highvoltage: edubuntu DVD is currently spinning
[16:16] <highvoltage> slangasek: heh, thanks
[16:20] <stgraber> slangasek: going to be fixed soon, he'll be moving from a continent away from me to the same office and the desk next to mine ;) That should avoid that kind of issues ;)
[16:22] <slangasek> stgraber: hah :)
[16:35] <slangasek> ArneGoetje: ttf-takao* are all in main for you; you said language-support-fonts-ja should be changed to depend on them?
[16:43] <Damascene> hello, any progress on the desktop recording problem?
[16:44] <ArneGoetje> slangasek: yep
[16:44] <Damascene> https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/305286
[16:45] <popey> Damascene: have you seen the comments on the bug?
[16:45] <Damascene> yeah. have you seen me new one?
[16:46] <Damascene> *my
[16:46] <popey> Damascene: I suspect Reinhard is the only person who can do much about it
[16:46] <Damascene> is it right that record my desktop uses theora not ffmpeg?
[16:46] <popey> unless someone volunteers to do a bisect on all the changes in ffmpeg svn
[16:47] <popey> Damascene: rmd doesn't need ffmpeg
[16:47] <Damascene> I see. only the recent ffmpeg could fix the rmd bug by converting
[16:48] <popey> its not a bug in rmd
[16:48] <popey> its a bug in ffmpeg
[16:49] <slangasek> ivoks: why is bug #562832 only 'medium'?
[16:50] <Damascene> popey, if rmd doesn't use ffmpeg how come it's a bug in it?
[16:51] <popey> Damascene: its explained in the bug. rmd uses a newer version of the theora codec. the ffmpeg in ubuntu doesn't support those new features, but newer ffmpeg does. So it's a bug in the current version of ffmpeg shipped in ubuntu
[16:52] <Damascene> yes
[16:53] <popey> Damascene: however there are a _lot_ of changes between the version of ffmpeg in ubuntu and the version in upstream, and it's too late in the cycle for lucid to pull in a very new ffmpeg, so Reinhard has asked if someone could figure out the exact patch which fixes the problem
[16:53] <slangasek> ivoks: (if it's only medium, it seems like it should be moved to SRU; if it's really high - such as if it makes it impossible to use the driver at all - then we can push it and respin server)
[16:55] <Damascene> but that wont help with the youtube problem. google should fix their system
[16:56] <slangasek> Daviey, superm1: are we ok with a respin of mythbuntu RC candidates to take this mythplugins library fix?
[16:56] <superm1> slangasek, yes
[16:57] <slangasek> superm1: thanks, accepted
[17:05] <slangasek> bryceh, apw: bug #565415 is probably the same as bug #566379
[17:08] <bryceh> slangasek ok
[17:11] <ccheney> mvo: still on phone?
[17:27] <jibel> mvo, thanks looking at the double click thing.
[17:27] <ivoks> slangasek: it can be uploaded post release
[17:28] <slangasek> ivoks: well, it's currently in the upload queue; if it doesn't have a critical impact on the package, I'll reject that upload
[17:28] <ivoks> slangasek: driver is usable unless you install a package on kernel you won't be using
[17:29] <ivoks> slangasek: i wouldn't mind if it goes trough SRU, so it's your call
[17:29] <slangasek> ivoks: ok, rejecting from the freeze queue, thanks
[17:30] <ivoks> slangasek: np
[17:46] <mvo> jibel: thanks!
[17:48] <mvo> ccheney: so, given that we have no clear solution I don't think we can block RC for it, if anything I would upload a new update-manager that blacklists currentl openoffice.org-evolution until a workaround/fix is found
[17:48] <mvo> ccheney: uploading with a revert of the pre-dep changes will just break it in a different way
[17:52] <ccheney> mvo: ok
[17:52] <ccheney> slangasek: see ^ :)
[17:53] <slangasek> yeppers
[17:53] <ccheney> if any major problems show up wrt OOo feel free to call me if you can't reach me on irc :)
[17:54] <ccheney> i should be around on irc most of the time i awake though
[17:54] <slangasek> ok :)
[17:54] <mvo> I will investigate more when I'm back, but I need to leave for now
[17:55] <slangasek> highvoltage, stgraber: edubuntu up, posted
[17:55] <YokoZar> Is backslash special cased at all inside translations for .desktop files?
[17:58] <stgraber> slangasek: yeah !
[18:05] <hdon> my capslock light never turns on when i'm in a VT
[18:06] <hdon> also switching to a VT from X doesn't update my capslock/numlock/scrollock lights
[18:06] <cjwatson> yes, known casualty of fixing a different bug
[18:06] <hdon> D:
[18:07] <cjwatson> bug 425704
[18:07] <cjwatson> (esp. comment 6)
[18:13] <Daviey> pitti: Sorry for the delay with the mysql bug, i missed the bug update you did this morning.  Is it valid concern that those who are upgrading that explicitly installed 5.0 won't have an upgrade path?
[18:14] <ScottK> Daviey: In general people should have the unversioned metapackages installed so they should get upgraded.
[18:17] <Daviey> ScottK: I agree, but googling --> "apt-get install mysql-server-5.0" ubuntu <-- returns a non-trivial amount of results.
[18:18] <ScottK> Live by the Google, die by the Google.
[18:18] <Daviey> Live by Ubuntu mailing lists, die by ubuntu mailing lists
[18:18] <Daviey> https://lists.ubuntu.com/archives/ubuntu-users/2007-December/131313.html
[18:18] <ScottK> That too.
[18:30] <cjwatson> sbeattie: debug instructions in bug 558382 now; TIA
[18:31] <sbeattie> cjwatson: thanks. I've tried to recreate it, but am not having any luck reproducing it.
[18:32] <seb128> slangasek, pitti: if you have a chance to accept gtk2-engine-murrine before lucid please do it fixes a crasher collecting duplicates
[18:32] <cjwatson> I've seen other scattered reports so I don't think it's isolated
[18:32] <cjwatson> it may depend on exact partition sizes
[18:33] <cjwatson> but it's in my "a bit scared to release with this" category
[18:33]  * YokoZar didn't think it was possible for gedit to have an error on saving that causes you to lose most of your work
[19:14] <smoser> hggdh, ping when you're around
[19:14] <smoser> please
[19:19] <lool> kirkland: around?
[19:20] <lool> kirkland: my laptop is dying under kernel load, I suspect it might be ecryptfs related; is there a way to look at where memory is going?
[19:21]  * lool really needs to reboot now
[19:23] <lool> kirkland: So I suspect there's a resource leak somewhere; I'm unison-ing 1 GB of data every 5 minutes and after some days, my laptop grinds to a halt
[19:23] <lool> kirkland: I rebooted now thought
[21:14] <ccheney> in looking into why OOo didn't build on sparc it appears to not have built because glib2.0 didn't because someone blacklisted it or something similarly odd
[21:14] <ccheney> "no really, you do not get to build glib2.0 here."
[21:15] <ccheney> whats that mean?
[21:37] <mdke> pitti: sounds fine
[21:46] <seb128> slangasek, I just uploaded an openoffice.org-dictionaries update, resyncing a debian bug fix revision, let me know if that seems ok for lucid otherwise I will reupload with one one fix from there for the thesaurus install
[21:48] <ccheney> seb128: oh you pulled it in? i was just waiting for it to get mirrored by debian, thanks! :)
[21:49] <seb128> ccheney, why do you wait for it to be mirror when it's on incoming.debian.org? we can't sync anyway since we have changes!
[21:50] <ccheney> seb128: was going to use grab-merge to do it, i thought it wouldn't be more than an hour or so before i could run that
[21:50] <ccheney> iirc debian pulses a few times a day
[21:51] <seb128> ok, I looked at that because I had a discussion with the debian maintainer about my previous change there and he let me know there was some thesaurus breakage so I synced that change
[21:51] <seb128> let's see now if it slangasek thinks it's ok for lucid
[21:51] <ccheney> seb128: ok thanks
[21:51] <ccheney> seb128: look like the german fix in the new version is also useful, so hopefully we can just pull the whole thing
[21:52] <cjwatson> ccheney: lamont did that - glib2.0 builds have been killing the sparc buildds
[21:52] <cjwatson> (I don't know the details)
[21:52] <ccheney> cjwatson: ah ok
[21:52] <seb128> there is a bug about glib
[21:52] <seb128> the testsuite is taking the sparc builder down for some reason
[21:53] <ccheney> ok, thanks for the information
[22:00] <lamont> ccheney: the glib2.0 build was causing the buildd to crash, and the manner was such that it just moved to the next buildd and killed it.
[22:01] <lamont> and then people kept giving it back after I killed it with prejudice (rm -rf glib2.0-* mid build), so I raised it some more
[22:05] <cody-somerville> apachelogger, You and Alessandro forgot to update the bzr branch for the xscreensaver package.
[22:05] <ccheney> lamont: makes sense :)
[22:08] <apachelogger> cody-somerville: sync'd, thanks :)
[22:08] <lamont> ccheney: 'faure' is the machine you want to play on, fwiw
[22:08] <cody-somerville> apachelogger, thanks! :)
[22:08] <lamont> it was more the automated duck shoot that I was getting annoyed at
[23:42] <LLStarks> mdz, is the place to ask about ubuntu-release team decisions?
[23:44] <LLStarks> mark said the new ubuntu-sounds theme won't get into lucid unless you guys give the go ahead
[23:44] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/539169/comments/11
[23:44] <LLStarks> there's a new theme readdy to go
[23:57] <elleuca> another late minute bug for lucid: #566909
[23:57] <elleuca> https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/566909
[23:59] <TheMuso> LLStarks: Has Mark given the new theme the o
[23:59]  * TheMuso reads the bug