[00:06] * slangasek wonders if anyone wants to fix hdf5 on armel [00:11] * persia looks at the log [00:12] slangasek: Am I reading correctly that *sed* segfaulted? [00:13] persia: it probably segfaulted when running ./H5detect, *after* running the sed to set LD_LIBRARY_PATH [00:14] Hrm. Do you have any input information that would help track down the issue? [00:20] 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] 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] That's a charitable explanation that doesn't blame lamont and I for brute-force approaches. Thanks :) [00:21] Anyway, emulated build is running now. [00:21] Keybuk, I guess a few seconds delay when there is a mount error would not hurt :) [00:22] joaopinto: hackish; we should just fix plymouth instead [00:22] slangasek, right, but right now a typo on fstab will render systems unbootable :P [00:22] What should plymouth do in that case? Isn't it not even running at that point? [00:23] persia: no, plymouth is running before mountall [00:23] Even when plymouth isn't in initramfs? [00:23] the issue is that messages sent *to* plymouth by mountall, before plymouth show-splash is called, are lost [00:23] yes - *plymouth* is running, only the splash screen isn't [00:23] Aha. I have an improved understanding. [00:23] because the splash screen depends on video device -> udev -> virtual-filesystems -> mountall [00:24] how does the mountall <-> python protocol work ? mountalls waits for an answer to the S/M prompt ? [00:24] ops, s/python/plymouth [00:25] it continues other processing, but has an event loop to check for an answer to that prompt [00:26] queuing the prompt until the splash is available is not an option ? [00:27] of course it is; but that queuing should be done within plymouth [00:27] because mountall doesn't know, and shouldn't know, when the splash is available [00:27] hence - "we should just fix plymouth instead" [00:27] ok :) [00:31] 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] Any ideas how to fix it permanently? [00:42] jdstrand, mdeslaur: what was your bug number for the "nouveau only gives 16-bit fb" issue? I think bug #565936 is a duplicate [00:42] Launchpad bug 565936 in plymouth "Plymouth text theme appears when booting Lucid CD, doesn't fill the screen" [Undecided,Incomplete] https://launchpad.net/bugs/565936 [00:48] 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] jdstrand, mdeslaur: found it, bug #554143 [00:50] Launchpad bug 554143 in plymouth "text logo theme used instead of graphical with radeon 7500 (single video output, pseudocolor fb)" [Medium,Triaged] https://launchpad.net/bugs/554143 [00:51] oh, that was radeon, not nouveau, doh [00:56] 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] 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] ... probably just be deferred to maverick [01:04] ArneGoetje, pitti: we're missing language-pack-gv-base, breaks DVD builds due to presence of language-pack-gnome-gv [01:55] slangasek: ok, will upload the -gv langpacks only [01:56] ArneGoetje: ok, thanks - the other langpack changes you had were just roll-ups, not any particular bugfixes? [01:57] slangasek: I'm not sure if there are bugfixes inside, but I guess they can wait for the final export... [01:57] alright; I believe that's best at this point [01:58] 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] Launchpad bug 565180 in language-pack-kde-de "Translation error in Launchpad changes (KMail/kdepim)" [High,Fix committed] https://launchpad.net/bugs/565180 [01:58] (if not, then we'll wait for the final export) [01:59] slangasek: if it's 'Fix Committed', then it's likely that fix is in this export [02:02] slangasek: however, as we have versioned dependencies in the langpacks, I will need to upload all -de langpacks [02:02] ArneGoetje: that would be fine [02:03] slangasek: ok, will upload now [02:05] 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] slangasek: eh... that package is empty... hwo could that happen? So, please remove it from the archive. [02:07] can do [02:08] ArneGoetje: done [02:08] slangasek: thanks... [02:11] slangasek: -de uploaded [02:11] thanks :) === dyfet` is now known as dyfet [02:56] 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] oh, so dpkg _is_ slower now then [03:03] i thought i'd noticed that again [03:03] 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] i'm not sure if my issue is only with dpkg, but my laptop is unusable whilst installing/upgrading packages atm [03:04] the cursor freezes for some ~30s at a time [03:05] try downgrading to -ubuntu3? [03:06] i might do, but in the morning now [03:06] it's getting late ;) [03:34] 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] persia: doh [03:35] persia: well, thanks for looking [03:35] http://paste.ubuntu.com/418278/ for the curious === oubiwann` is now known as oubiwann [04:54] mdke: still "today" as an ETA? :) [05:30] 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] slangasek: the drivers {build-,}depend on the new xserver too [05:31] 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] persia: no, the old one is ignored [05:31] And they are in different locations? [05:31] yes [05:31] not a conflict, but everything except evdev gets ignored, yeah [05:31] Hmm. [05:34] though it gets more hairy if the server version isnt' bumped [05:34] slangasek: ok, sorry didn't see your message until now [05:34] tjaalton: But don't the new drivers depend on the new server version? [05:35] persia: they would, but no point in getting them then [05:35] (bdeps on the new upstream version) [05:36] Right, so really there's no combination of upgrades that dpkg will accept in which anything breaks? [05:37] 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] with that in place, yes, nothing should break too horribly [05:40] 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] 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] 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] 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] bryceh, apw: bug #566379 is a regression for an i855 user introduced when disabling KMS by default [05:44] Launchpad bug 566379 in linux "Cannot boot past Plymouth with kernel 2.6.32-21 in normal mode" [High,New] https://launchpad.net/bugs/566379 [05:45] 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] ccheney: no worries - it only took me two uploads to get it right ;) [05:46] 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] slangasek: alright [06:24] 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] Good morning === almaisan-away is now known as almaisan === almaisan is now known as al-maisan === raof is now known as RAOF [07:35] slangasek: test build hadn't finished by the time I went to bed. Tested now and am uploading [07:36] mdke: ack, thanks [07:37] slangasek: that's for ubuntu-docs. Will it be ok if gnome-user-docs follows this evening? [07:38] 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] 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] 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] mdke: if we *have* to pull it in post-RC, we will, but I'd certainly prefer to have it before [07:45] slangasek: ok, I'll give you a shout in 30 mins or so [07:46] mdke: ok - if I can be of any help with the Rosetta importing, I'd be happy to do so [07:46] thanks. I've started it off now [07:58] heya [07:59] robert_ancell: legend, thanks [07:59] mdke, np :) [08:00] good morning [08:16] 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] mdke: cheers! [08:22] good morning [08:27] 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] mounting all configured systems is not a trivial operation, one of those that you might want to recover from [08:32] 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] 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] 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] someone using a /usr on a different partition should know how to manually mount it :) [08:36] slangasek: ok, that's uploading now. Sorry I didn't get it done when I said I would [08:36] mdke: 'sok, we're still in the game :) [08:36] mdke: thanks for the quick turnaround this morning! [08:44] slangasek: :) [08:47] 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] slangasek: (this will unfortunately produce some autoconf file noise) [09:11] Hi all [09:20] mvo: bug #566453> which part of this is the warning that you consider a bug? [09:20] Launchpad bug 566453 in plymouth "plymouth-theme-fade-in warns on removal" [Undecided,New] https://launchpad.net/bugs/566453 [09:23] slangasek: feel free to close if the warnings do not matter, it just appreard in the auto-install-tester log [09:24] slangasek: and user may be confused/scared by it, but its low priority anyway, just wanted to record it for later [09:25] mvo: would moving the update-alternatives call to the prerm fix the warning? [09:26] slangasek: I think it will, [09:29] mvo: ok - could you comment that in the bug so we don't forget? [09:29] slangasek: will do, thanks [09:33] mvo, question about the motivation for the binary.changelog, is it possible for a source package to generate binaries with random versions ? [09:33] joaopinto: yes, take gcc-defaults as a example [09:33] joaopinto: there is a small number of packages that do that [09:33] joaopinto: but those tend to be important [09:34] james_w: I upload a new kerneloops with disabling it by default now [09:35] hum, I am puzzled how that plays with binary.changes files [09:35] because you have a single "Version:" field, which I suppose it's related to the binaries, not to the source [09:37] joaopinto: the version in the changelog refers to the source changelog [09:37] joaopinto: (if that is what you mean, not sure I understand the question) [09:37] 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] 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] pitti: thanks! [09:39] james_w: (I used lp:ubuntu/kerneloops, is that right?) [09:39] mvo, well, I will check gcc-defaults to save your time :) [09:39] pitti: yup [09:39] joaopinto: yeah, do that, its a good example, its justing substvars for it [09:44] anyone aware of an ext4 change that might result in a major performance hit on ext4 writes ? I mean from karmic to lucid === akher0n is now known as akheron [09:44] joaopinto: the disk io scheduler was changed a bit., could affect that. [09:45] SwedeMike, hum I got such a penalty that I had to force barrier=0 on my ext mounts [09:46] a debootstrap was taking 10x more than it previosly did [09:46] and you were running with barriers in karmic as well? [09:46] I didn't touched barriers there, actually I jut became aware of barriers after noticing this problem now [09:47] SwedeMike, was that changed early on the development cycle or a short time ago ? [09:48] that was in 2.6.32 so should have been all the way in lucid [09:48] 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] joaopinto: http://lwn.net/Articles/352863/ [09:49] joaopinto, dlr-languages does the binary-version-mangling trick [09:49] 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] slangasek, no, that is the remaining issue I knew about from dxteam [09:50] joaopinto: my bad, that wasnt io scheduler, that was cpu scheduler [09:50] slangasek, ted sent updates my way during the weekend [09:51] 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] slangasek, you think they can still go in RC or better after RC now? [09:52] seb128: before RC [09:52] always before, if there's a choice ;) [09:52] ;-) [09:53] pitti: udev> can you get that uploaded now, and I'll figure out what to do with it once it's there? [09:53] slangasek: yup [09:54] SwedeMike, thanks anyway :) [09:55] directhex, checking, tks [10:03] 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] seb128: pre-emptively dropped the first one from the queue [10:04] slangasek, thanks [10:08] slangasek: udev uploaded and tested [10:11] 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:11] Launchpad bug 526354 in pm-utils "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,In progress] https://launchpad.net/bugs/526354 [10:12] pitti: right, sounds good [10:16] mvo, could you please review and upload 565816 ? thanks [10:27] jibel: yes [10:34] 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] slangasek: pm-utils uploaded (admittedly a nasty solution, but let's hope it only has to last for some two weeks) [10:58] 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] mdz, :) [10:59] mdz, I sent the email to xubuntu-devel as well, it might be a better audience [11:00] 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] mdz, found it. ubuntu core -> xubuntu devel -> xubuntu team -> xubuntu testers [11:02] james_w: nope, that one I'd been skipping because I was pretty sure it was just an accounting problem [11:02] right [11:02] mdz, lost in a chain of indirect membership [11:03] slangasek: any idea why we had an upload a few hours ago that LP seems to be attributing to katie? [11:03] james_w: urk, no [11:03] 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] I can't see a bug for the sync either [11:04] slangasek: ah, it was a promotion a few hours ago, the sync was a while ago [11:04] ara: I agree, we get too much spam as a result of nested teams [11:04] james_w: ah :) [11:04] in part because teams are (ab)used for ACL purposes [11:04] 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] mdz, yes. I will file a wishlist bug against launchpad to have the opportunity to "Contact this team's DIRECT members" [11:06] Yesterday I've fixed some important Lithuanian translations errors in ubiquity-debconf translation - our translation leader introduced some bugs 10 days ago :( [11:06] mdz, sorry for the noise [11:07] 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] mdz, will do ;-) === mantiena is now known as mantiena-baltix [11:11] Maybe someone could tell me if Evan Dandrea will be here? [11:12] ccheney: openoffice.org-common depends on xfonts-mathml. Do you know if it needs ttf-lyx that the latter recommends? [11:19] 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] Launchpad bug 566497 in clamav "logging waaaaaaaay to much (7gb too much)" [Undecided,Incomplete] https://launchpad.net/bugs/566497 [11:19] mantiena-baltix: ev updated them yesterday [11:19] mantiena-baltix: isn't this the second release where we've had last-minute Lithuanian updates? [11:20] maybe I don't mean yesterday, looks like Friday - after the non-langpack deadline anyway [11:23] IIRC it was gfxboot last time that needed a last-minute update, yeah [11:29] cjwatson: yes, this is the second, last one was Ubuntu 9.04 ;) [11:30] 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] but I can't guarantee it [11:31] 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] some of these errors are just mistypes - for example "idegta" instead of "įdiegta", but in lithuanian word "idegta" means burned, while įdiegta" [11:33] means installed [11:35] 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] doko__: thanks a lot for #560135 [11:38] mantiena-baltix, burned looks cool :D [11:38] mdz, bug 566536 [11:38] Launchpad bug 566536 in launchpad-registry "Contact this team's members shouldn't spam indirect members" [Undecided,New] https://launchpad.net/bugs/566536 [11:38] Ubuntu on fire :) [11:42] 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] Daviey: OK. Thanks. I'll look into it. There were some changes in how logging works in the last upload. [11:56] ScottK: Yeah, i had a quick look.. pretty confusing how the logrotate file gets generated! :) [11:56] Daviey: Can you join #debian-clamav on OFTC? [11:56] ScottK: My initial thought is that $LogFile is NULL. [11:58] ScottK: done [13:03] doko__: Would it make sense to sync gcc-4.5 over to lucid? [13:03] lool: ??? late April joke ??? [13:08] doko__: Hmm no, in universe? [13:09] doko__: I didn't find mcuh regression potential and thought this might be useful [13:10] lool: no, overwrites all shared libs [13:10] lool: use gcc-snapshot [13:10] doko__: Ah, I thought gcc-defaults was masking all of that [13:10] but indeed, does not [13:10] doko__: So nm :) [13:10] or the ubuntu-toolchain/test PPA [13:11] lool: but you can try to convince slangasek ;) [13:11] tss :) === \vish is now known as vish [13:30] pitti: bug #526354 - your pm-utils fix worked ;P [13:30] Launchpad bug 526354 in linux "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,In progress] https://launchpad.net/bugs/526354 [13:31] slangasek: right, that's what I meant with "ugly" :/ [13:31] slangasek: hiding the option in the session menu would require code changes in upower unfortunately [13:31] * slangasek nods [13:31] it doesn't call pm-is-supported, but reads /sys/power/state and greps for "mem"; nothing in between to hook into :? [13:31] s/?/(/ [13:35] chrisccoulson: happy birthday! :) [13:35] thanks dholbach :) [13:35] chrisccoulson: ooh, happy birthday! [13:36] happy birthday chrisccoulson [13:36] thanks everyone :) [13:37] chrisccoulson, happy birthday! ;-) [13:42] happy birthday chrisccoulson [13:43] chrisccoulson, wow, birthday! Happy Birthday! === radoe_ is now known as radoe [13:57] chrisccoulson: hi, james_w tells me you might know something about the problems with updating sugar-browse-activity to 0.88? [13:57] chrisccoulson: oh, and happy birthday :) [13:58] slangasek - thanks :) [13:58] oh happy birthday chrisccoulson [13:58] yes, sugar-browse-activity needs python-xpcom, which isn't packaged anywhere yet === kirkland` is now known as kirkland === cjohnston is now known as cjohnston|uds === cjohnston|uds is now known as cjohnston [14:51] hi [14:53] 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] 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] seb128: is "small" a measure of their impact, or their diff size? :) [14:59] slangasek, with keybuk not around, i will beg to you for a couple thoughts if you don't mind. [14:59] bug 565018 [14:59] Launchpad bug 565018 in cloud-init "instance is not reachable via ssh" [Undecided,New] https://launchpad.net/bugs/565018 [14:59] slangasek, things like the change on bug #475090 [14:59] Launchpad bug 475090 in gdm "Karmic, Lucid: /etc/gdm/Xsession fails to source ~/.xsessionrc or apply ~/.Xresources" [Medium,Triaged] https://launchpad.net/bugs/475090 [15:00] 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] (this is hard to reproduce, somewhere like 2% maybe or less) [15:02] slangasek, or http://git.collabora.co.uk/?p=papyon.git;a=commitdiff;h=5f9e7e0da5a89b80190087022a633eca7f7f2d8e [15:03] 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] 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] 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] slangasek, the second will lead to a telepathy-butterfly crash when receiving some messages from buggy clients [15:05] 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] slangasek, thanks [15:16] jhernandez: on the fly; the core is in partman-target [15:16] jhernandez: though there's a partial template involved [15:16] jhernandez: what do you want to know? [15:16] thx for your response cjwatson [15:17] ubiquity (or another package) creates a cdrom's line in fstab [15:17] not any more in lucid [15:18] i have pcs without cdrom [15:18] http://launchpadlibrarian.net/38682219/partman-target_64ubuntu5_64ubuntu6.diff.gz [15:18] smoser: what job does the 'generating public/private rsa key pair'? [15:19] the job listed there. [15:19] cloud-config-ssh [15:19] ok [15:19] (comment 4) [15:19] as far as I can tell, it just doesn't run [15:19] thz [15:19] thx, cjwatson [15:20] 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] i have my answers in the link above [15:20] (i.e. I'm not going to debug it if it did create them on a system without a CD drive) [15:21] okok [15:21] lot of thanks [15:21] :P [15:24] smoser: have you done the test with the upstart debugging turned on? [15:24] i've been trying to get one [15:25] as, yeah, i want that too [15:26] and my scripts had some bugs so they failed to catch console output the couple times when the other stars were alignged [15:32] james_w: probably from what the description of xfonts-mathml itself says [15:32] 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] ccheney: yes, but it's talking about browsers, so I wondered if it was the same [15:33] james_w: oh, hmm i'm not sure i can dig around some more and see [15:33] as it stands we have to promote the whole of lyx to satisfy it [15:39] james_w: eh, why? [15:39] james_w: ttf-lyx doesn't depend on anything other than defoma [15:39] ccheney: xfonts-mathml recommends ttf-lyx which is in the lyx source package [15:40] 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] ccheney: yes, the source [15:41] ok [15:41] MIRs are done on a sourceful basis; so all the review for main-worthiness has to be done up front [15:41] the person who filed the bug in debian seemed to indicate that probably xfonts-mathml is enough for OOo [15:42] which is already in main so we can probably safely ignore the ttf-lyx === deryck is now known as deryck[lunch] [15:45] ccheney: hi, bad news. the OOo pre-depends are still causing some grief bug #566584 and bug #516727 [15:45] Launchpad bug 566584 in apt "unpack/configure order violation triggered by OOo pre-depends" [Undecided,Confirmed] https://launchpad.net/bugs/566584 [15:46] Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Confirmed] https://launchpad.net/bugs/516727 [15:47] mvo: the pre-depends was already fixed back to the way it used to be, can we just fix apt already? :) [15:49] 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] 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] oh nm i saw the add libxml2 to openoffice.org-evolution, not sure how i missed that [15:51] but you said it still doesn't fix the upgrade? [15:51] 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] yea [15:52] ccheney: the other is to remove ooo-evolution, -emailmerge, -filter-binfilter on upgrade [15:52] the pre-deps as they were before the apt workarounds were needed [15:52] and add them again afterwards [15:52] but all is very not-cool [15:52] thats probably workable too but only would work assuming the people upgrading were following proper procedure :) [15:53] sounds like apt's pre-depends resolver is totally broken [15:54] 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] well it was initially rather simple unless i misunderstand it [15:55] just: openoffice.org-core (>= 1:3.1.0-2), debconf (>= 0.5) | debconf-2.0, procps [15:55] ccheney: I'm sure mvo would love to see patches to fix it ;-) [15:55] i guess the debconf part could have been complicated but it got confused on the openoffice.org-core part :) [15:55] so is it an issue with versioned pre-depends? [15:56] dholbach: hmm yea maybe i will have time to hack on it during maverick cycle [15:56] ccheney: right, its openoffice.org-core that ships a long list of depends [15:57] ccheney: I don't think its the versionizing [15:57] * ccheney wonders if its an interaction with installing recommends by default [15:58] mvo: i see something that might be causing it to be upset [15:59] the extensive Conflicts in OOo seem likely to cause difficulties [15:59] 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] cjwatson: oh [16:01] 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] cjwatson: ok [16:02] 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] cjwatson: :) its a nightmare [16:03] * ccheney hopes i can get some of those dropped by debian after the next debian release [16:04] slangasek: should i go ahead and do the new upload with updated pre-depends on wait for arm to build? [16:04] s/on/or/ [16:05] ccheney: no need to wait before uploading; is this expected to go in before RC though? [16:06] slangasek: depends on if mvo thinks its important to make the RC for testing purposes I guess [16:06] mvo: ^ ? [16:09] (on the phone atm, sorry) [16:11] 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] highvoltage: you two need to talk to each other more :) [16:15] highvoltage: edubuntu DVD is currently spinning [16:16] slangasek: heh, thanks [16:20] 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] stgraber: hah :) [16:35] ArneGoetje: ttf-takao* are all in main for you; you said language-support-fonts-ja should be changed to depend on them? [16:43] hello, any progress on the desktop recording problem? === deryck[lunch] is now known as deryck [16:44] slangasek: yep [16:44] https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/305286 [16:44] Launchpad bug 305286 in ffmpeg "fails to playback ogv produced by recordmydesktop" [Medium,Confirmed] [16:45] Damascene: have you seen the comments on the bug? [16:45] yeah. have you seen me new one? [16:46] *my [16:46] Damascene: I suspect Reinhard is the only person who can do much about it [16:46] is it right that record my desktop uses theora not ffmpeg? [16:46] unless someone volunteers to do a bisect on all the changes in ffmpeg svn [16:47] Damascene: rmd doesn't need ffmpeg [16:47] I see. only the recent ffmpeg could fix the rmd bug by converting [16:48] its not a bug in rmd [16:48] its a bug in ffmpeg [16:49] ivoks: why is bug #562832 only 'medium'? [16:49] Launchpad bug 562832 in drbd8 "module drbd8 update kernel from 2.6.32-16 to 2.6.32-20" [Medium,In progress] https://launchpad.net/bugs/562832 [16:50] popey, if rmd doesn't use ffmpeg how come it's a bug in it? [16:51] 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] yes [16:53] 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] 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) === jldugger is now known as pwnguin [16:55] but that wont help with the youtube problem. google should fix their system [16:56] Daviey, superm1: are we ok with a respin of mythbuntu RC candidates to take this mythplugins library fix? [16:56] slangasek, yes [16:57] superm1: thanks, accepted [17:05] bryceh, apw: bug #565415 is probably the same as bug #566379 [17:05] Launchpad bug 565415 in xserver-xorg-video-intel "Can't boot after latest kernel image and plymouth update" [Undecided,New] https://launchpad.net/bugs/565415 [17:05] Launchpad bug 566379 in linux "[i855] X doesn't start with kernel 2.6.32-21 unless passing i915.modeset=1" [High,Triaged] https://launchpad.net/bugs/566379 [17:08] slangasek ok [17:11] mvo: still on phone? === beuno is now known as beuno-lunch [17:27] mvo, thanks looking at the double click thing. [17:27]