[01:07] <funkyHat> Is it necessary for apt to run "Updating fontconfig cache for /usr/share/fonts/..." so many times during installation of fonts? Or would it be possible/preferable to have that queued up until the end, like some other things are?
[01:13] <ScottK> That would take someone implementing a dpkg trigger for it.
=== micahg1 is now known as micahg
[01:15] <Laney> which is not necessarily a hard task with file triggers
[01:15] <ScottK> Just takes someone to do it.
[01:16] <Laney> someone... who cares about such a problem...
[01:16]  * Laney peers at funkyHat 
[01:16] <ScottK> Laney: Exactly.
[01:17] <funkyHat> Problem is I've now installed all the fonts in the world, so I won't have anything to test it with ⡈(
[01:17] <funkyHat> ;P
[01:17] <Laney> we have chroots for this ;)
[01:18] <funkyHat> I knew that excuse wouldn't work!
[01:19]  * sebner throws a virtual machine at funkyHat 
[01:20]  * funkyHat puts it on the pile in the corner
[01:26] <funkyHat> Looking at the dpkg triggers page it looks like every font package is going to need changing to use triggers
[01:27] <ScottK> Probably a change best coordinated through the Debian fonts packaging team
[01:27] <ScottK> (I don't recall its exact name)
[01:28] <funkyHat> Yeah
[01:28] <funkyHat> Was going to say probably best if this is dealt with with Debian's packages
[01:29] <ScottK> Someone should probably go talk to them about it.
[01:29]  * ScottK wonders who might be a candidate?
[01:29] <RAOF> If there's a dh_font or somesuch it'd probably only take a change to fontconfig + a rebuild for all the font packages.
[01:30] <funkyHat> ScottK: I'm having a look through their mailing lists to see if it's already been discussed
[01:30] <ScottK> Excellent
[01:37] <funkyHat> Yep, fixed in fontconfig 2.8.0-2 it seems ⡈)
[01:53] <ScottK> Looks like fontconfig is in serious need of a merge from Debian.
[01:57] <funkyHat> ScottK: bug 490326
[01:57] <ubottu> Launchpad bug 490326 in fontconfig "Please merge fontconfig 2.8.0-2 from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/490326
[01:57] <funkyHat> It's been "in progress" for 5 days
[01:58] <ScottK> The package was last merged during Intrepid development, so it wouldn't suprise me if it was complex.
[01:59] <funkyHat> Oh but there's a bzr branch uploaded, perhaps waiting for review?
[03:17] <Some_Person> Can anyone tell me if the package ``human-theme'' conflicts with ``gtk2-engines-ubuntulooks'' in lucid?
=== vorian is now known as buttercup
=== buttercup is now known as vorian
=== asac_ is now known as asac
[04:08] <Some_Person> Is anyone here?
[04:09] <xnox> yes
[04:09] <Some_Person> I want to know why nobody has fixed an easy as heck bug involving human-theme and gtk2-engines-ubuntulooks
[04:09] <Some_Person> It's been around since Intrepid's release
[04:10] <xnox> I did actually quish a comple of human-theme bugs
[04:10] <Some_Person> https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/285417
[04:10] <ubottu> Ubuntu bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed]
[04:10] <xnox> but it's no longer default
[04:10] <xnox> we use humanity now
[04:10] <Some_Person> I fixed the bug myself for karmic in my PPA and could easily do the same for lucid
[04:11] <Some_Person> Yes, but some themes still use ubuntulooks, and when you try to install that engine, human-theme has to go for no good reason
[04:11] <Some_Person> For example, blubuntu in the repos
[04:13] <Some_Person> I'm puzzled as to why this hasn't been fixed
[04:14] <xnox> Looks valid to me
[04:14] <ScottK> Then you haven't looked at the mountain of bugs open Launchpad and done a realistic assemement of the priority of problems like this.
[04:14] <xnox> My guess there was a lot of shouting in the bug report
[04:15] <Some_Person> I understand that, but shouldn't older ones be tackled first? Especially trivial ones like this one where the fix is extremely easy?
[04:15] <xnox> my suggestion would be to branch lp:ubuntu/packages both of them
[04:15] <xnox> commit your fixes and push it back to lp:~user/ubuntu/ludic/package/my-fixes
[04:15] <ScottK> Some_Person: If you have the fix, you could attach a debdiff to the bug and subscribe the relevant sponsorship team to the bug.
[04:16] <xnox> and then seek sponsors from the sponsors team
[04:16] <ScottK> Either way works
[04:16] <Some_Person> I have the fix for karmic and I can almost certainly make one for lucid too
[04:17] <xnox> And the reason why it wasn't fixed is because it's no longer in the default install and this really doesn't cut it for the Strable Release Update
[04:17] <xnox> you can still installing by removing those packages ;-)
[04:18] <Some_Person> Yes, but it makes no sense to have to needlessly remove human-theme
[04:19] <xnox> do a fix against lucid attach it to the bug, _explain_ nicely in one or two sentences what this fix is about and subscribe ~ubuntu-universe-sponsors
[04:19] <xnox> works for me ;-) I get either a quick comment from sponsor what's wrong, or I get email from LaunchPad saying it got uploaded ;-)
[04:24] <Some_Person> One question, when I make the debdiff, should the Maintainer field in the control file be me or what?
[04:28] <ScottK> Some_Person: What's there now?
[04:28] <Some_Person> the original one that's in karmic ("Sebastien Bacher <seb128@canonical.com>")
[04:29] <Some_Person> actually, sorry, i'm wrong
[04:29] <Some_Person> my name is actually in there
[04:31] <xnox> Some_Person: keep the maintainer name the same
[04:31] <Some_Person> ok, i'll change it back then
[04:31] <xnox> just add "[ Your Name ]" in debian/changelog
[04:31] <xnox> and then underneath your changes
[04:31] <xnox> and don't forget to bump release version
[04:31] <xnox> eg. dch -i
[04:43] <Some_Person> Is what I did here OK? https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/285417
[04:43] <ubottu> Ubuntu bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed]
[04:43] <Some_Person> last post
[04:46] <Some_Person> (actually, the same debdiff should work for lucid too)
[04:47] <ScottK> The debdiff in the bug should be for lucid
[04:47] <xnox> Some_Person: Wah =)
[04:47] <xnox> now that one is quite ugly
[04:47] <xnox> no need to move the folder
[04:47] <xnox> and no need to patch configure
[04:48] <xnox> just use appropriate *.install files and configure options to define new package-name prefix
[04:49] <Some_Person> I moved the folder to keep Human-ubuntulooks as a separate theme (just in case anyone wants it, though it shouldn't be necessary). And patching configure makes it look for the stuff in the renamed folder
=== micahg1 is now known as micahg
[04:51] <Some_Person> Anyway, what's the chance that a fix for this will be implemented in lucid?
[04:55] <ScottK> Assuming you have a good patch, pretty good.
[04:55] <Some_Person> Well, it works for me in Karmic (that's what my PPA uses)
[04:59] <Some_Person> do i need to change the bug's status or anything?
[04:59] <xnox> subscribe ~ubuntu-universe-sponsors team
[04:59] <xnox> don't change statur
[05:01] <Some_Person> ok
[05:01] <Some_Person> thanks
[05:01] <xnox> your welcome
=== archis_ is now known as archis
[07:06] <xnox> attached debdiff & branch to fix bug #285417 with two lines. Note fixes upgrade Hardy -> Lucid
[07:06] <ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
[07:06] <xnox> please sponsor =)
[07:08] <dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930
[07:08] <ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
[07:09] <dupondje> can somebody give it a look ? :)
[07:16] <dholbach> good morning
[07:26] <pitti> Good morning
[07:26] <dholbach> hey pitti
[07:29] <pitti> slangasek: ubuntuone spec responsibility> hm, their team lead? it wasn't an integration spec, but an upstream development one
[07:29] <pitti> asac: I mailed you about the missing ude-2d spec
[07:29] <pitti> hey dholbach, had a nice weekend?
[07:29] <slangasek> pitti: oh - then should the spec not have been accepted for Lucid, maybe?
[07:30] <dholbach> pitti: I did, although it involved a lot of recovery from a long night out :)
[07:31] <pitti> slangasek: good question; I suppose they still want to align to the lucid development cycle, but it should perhaps not be an ubuntu spec
[07:31] <dholbach> pitti: how was yours?
[07:31] <pitti> dholbach: great, we went skiing again, and I caught up sleep from last week's sprint :)
[07:31] <pitti> dholbach: went DJing again?
[07:33] <dholbach> pitti: no, I was out in a bar with my brother and sister and a couple of friends, I guess we should have stopped after the first bar :)
[07:33] <dholbach> pitti: but more DJing is definitely on the agenda for 2010
[07:33] <dholbach> pitti: ahh... the Paris sprint... did you get a lot of stuff done?
[07:34] <pitti> dholbach: yes, went quite well; we packaged new netbook stuff, built a demo CD, and got some boot speed work done; but a major point was transferring our knowledge to didrocks
[07:35] <dholbach> nice!
=== tkamppeter_ is now known as tkamppeter
[07:56] <didrocks> good morning
[08:04] <dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930
[08:04] <dupondje> can somebody give it a look ? :)
[08:04] <ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
[08:31] <pitti> slangasek: would you mind if I enable all the dailies again?
[08:33] <pitti> slangasek: i. e. is there a particular reason not to?
=== sabdfl1 is now known as sabdfl
[09:29] <asac> ok
[09:30] <asac> pitti: cool. nw we see fore3ign in the chart ;) ... nice.
[09:31] <pitti> asac: I sent details about that to the platform list yesterday
[09:31] <asac> yep. checking mails ;)
=== cking_ is now known as cking
[10:55] <apw> pitti, my burndown charts have jumped (in the new system) and i seem to have a bunch of duplicates ... aware?
[10:55] <pitti> apw: jiboumans just reported the same (duplicates)
[10:56] <apw> happend about 3 days back i'd say
[10:56] <pitti> apw: the jumps are partially due to the dupes (will fix) and due to adding back WIs from persons which are not in your team, but hare WIs assigned for your team
[10:56] <pitti> apw: hm, I only committed the latter change yesterday
[10:56] <pitti> but that affects all history (it just changes the queries, not the data collection)
[10:56] <mvo> cjwatson: if you don't mind I will do the uploads for bug #505887 today (busybox and sysvinit)
[10:56] <ubottu> Launchpad bug 505887 in sysvinit "Provide static-sh alias name and ship busybox-static by default" [Undecided,New] https://launchpad.net/bugs/505887
[10:57] <apw> pitti, ahh, ok then timing means nothing
[10:57] <pitti> apw: i. e. for the "don't ignore foreign WIs" the jump should have happened from day 1 in the charts
[10:58] <pitti> (the light-red/light-green parts)
[10:58] <apw> http://macaroni.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
[10:58] <apw> if you look at mine, its just the last four days
[10:59] <pitti> apw: does anything in 'status by spec' look unreasonable?
[10:59] <pitti> done/postponed didn't change, just todo (team)
[11:00] <pitti> apw: might just be the duplicate queries, though
[11:00] <pitti> apw: let's check this out again once I fixed that
[11:00] <pitti> currently I'm still working on improvements for jiboumans
[11:01] <jiboumans> pitti++ and don't be afraid to tell me to do some of this stuff :)
[11:03] <pitti> I just radically simplified the parsing of the blueprint HTML and made it much easier to maintain/debug
[11:03] <tseliot> pitti, slangasek: is there a way to edit this page? I only need to replace "sudo nvidia-config" with "sudo nvidia-xconfig"
[11:03] <pitti> jiboumans: if you could port your "expected progress/color coding" to the new branch, I'd appreciate
[11:03] <tseliot> http://www.ubuntu.com/testing/lucid/alpha2#Known%20issues
[11:04] <pitti> tseliot: needs to be done by a webmaster; newz2000 is my usual contact point
[11:04] <tseliot> pitti: ok, thanks
[11:09] <pitti> jiboumans: ok, just pushed the changes for this TODO:
[11:09] <pitti> - pull spec info: definition, drafter, approver, wiki link, milestone target
[11:10] <pitti> jiboumans: I added automatic DB migration code, so in the 1203 UTC run the DB should get migrated, and should pick up all the extra spec info
[11:14] <jiboumans> pitti++ awesome. i'll check it then and i'll happily port the code
[11:15] <apw> pitti, soz got bit by a suspend bug
[11:19] <pitti> apw: soz?
[11:20] <apw> pitti, soz == short sorry
[11:20] <pitti> ah
[11:21] <pitti> jiboumans: so the extended json and expected progress are on your plate now, right? is there any other addition you want me to work on?
[11:22] <jiboumans> pitti: ehm, don't have our full conversation in my head right now. if all the stuff's in the db, the JSON stuff's straight forward
[11:22] <pitti> jiboumans: I need to do some bug fixing now (for the duplication), and finish the cleanups, but wanted to check with you wheter there's something left for me from our email exchange
[11:22] <jiboumans> and we'll hold off the 2 graphs/extended tables to see if the current solution works
[11:23] <pitti> jiboumans: right, json is by and large just adding what you want; it's a simple "build a dict of stuff you want to see"
=== dholbach_ is now known as dholbach
[11:23] <pitti> jiboumans: *nod*
[11:23] <pitti> jiboumans: I did the "extended spec tables" (drafter/definition/wiki link/etc.)
[11:23] <jiboumans> ah, the arbitrary meta: stuff
[11:23] <jiboumans> that's one for CFT right now i think
[11:24] <jiboumans> perhaps a nice sprint hackathon :)
[11:24] <jiboumans> pitti: on that list would also be a community-tracker; specs accepted for lucid but not driven by a canonical employee
[11:25] <pitti> jiboumans: I see; they appear on all-*.html, but you want noteam*.html?
[11:27] <jiboumans> pitti: they do? i don't see them.. perhaps we're not talking about the same thing.. i mean specs like: https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-asterisk-integration
[11:28] <pitti> jiboumans: right; they ought to be on all.html (and things like all-lucid-alpha-2.html)
[11:28] <pitti> (they are)
[11:29] <jiboumans> pitti: ah, right.. can you match them to the team by using /server-lucid|lucid-server/ and have them show up in the usual reports too? server-alpha3, beta-1, etc?
[11:29] <pitti> I don't have spec name patterns right now
[11:30] <pitti> so this would be a thing for the todo list
[11:30] <pitti> jiboumans: would you mind filing a bug about it, so that we can keep these requests in lp?
[11:30] <jiboumans> pitti: no problem at all
[11:33] <jiboumans> pitti: done with #509094
[11:34] <tseliot> YokoZar: can we talk about bug #506435 and bug #506437?
[11:34] <ubottu> Launchpad bug 506435 in ia32-libs "ia32-libs should install libGL.so* in /usr/lib32/mesa" [Medium,Triaged] https://launchpad.net/bugs/506435
[11:34] <ubottu> Launchpad bug 506437 in ia32-libs "ia32-libs should be updated with the libraries from Mesa 7.7" [Medium,Triaged] https://launchpad.net/bugs/506437
[11:35] <YokoZar> tseliot: What about theM?
[11:35] <tseliot> YokoZar: shall I take care of those bugs?
[11:36] <YokoZar> I'm not completely sure what the plan is for ia32-libs at the moment (how it's being phased out, or even if that's still happening in Lucid)
[11:36] <tseliot> pitti: ^^
[11:37] <pitti> no idea about ia32-libs, I'm afraid
[11:37] <tseliot> YokoZar: I guess its removal was postponed (as multiarch support for dpkg was postponed too)
[11:37] <YokoZar> slangasek might know
[11:38] <tseliot> ok
[11:39] <tseliot> YokoZar: ok, so if the package remains, I'll fix those bugs. Deal?
[11:39] <YokoZar> but yeah, the long and short of it is: if multiarch dpkg is gonna happen in some form, updating ia32-libs to do anything other than remove packages should be the last thing you do (instead making proper multiarch packages would be a better use of time)
[11:39] <tseliot> yes, of course
[11:39] <YokoZar> but if it's not gonna happen in Lucid, then we're stuck doing the same thing as in Karmic and will need to kludge ia32-libs further.  So that includes putting things in the right directories ;)
[11:39]  * tseliot nods
[11:40] <tjaalton> it's not happening for lucid
[11:40] <YokoZar> Is it happening in Debian?
[11:40] <tjaalton> no
[11:41] <tjaalton> not yet anyway
[11:42] <tseliot> ok, I guess I'll have to mess with the fetch-and-build script and hope that things go well, then
[12:02] <dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930 => could somebody get a look @ this? Its annoying issue
[12:02] <ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
=== MacSlow is now known as MacSlow|lunch
[12:25] <cjwatson> mvo: I'm OK with that busybox patch (except you seem to have a stray .pc/.version in the patch); please go ahead
[12:30] <d1b> hi i have a question.
[12:31] <d1b> firefox on ubuntu has been modified. i am trying to determine why  https://student1.mq.edu.au doesn't work. i have checked all certs in /etc/ssl/ and i find none with an expiry date of 2004. the cert should be valid but it is being flagged as not.
[12:32] <d1b> on normal firefox it is valid and is shown as signed with the verisgn level 3 cert.
[12:32] <d1b> i am not sure this is correct place to raise this issue.
[12:32] <babbio> i need to compile a vanilla kernel on ubuntu....how to do that?
[12:32] <babbio> some docs??? thanku
[12:32] <d1b> babbio: this is not #ubuntu
[12:33] <babbio> this is ubuntu-devel....and i'm taling of kernel compiling....so i thought this the correct place
[12:33] <babbio> sorry
[12:33] <d1b> https://help.ubuntu.com/community/Kernel/Compile
[12:34] <d1b> babbio: essentially make a config then make-kpkg clean && make-kpkg --initrd kernel_image iirc.
[12:34] <babbio> i already read that documentation....but does not talk about vanilla kernels
[12:34] <d1b> babbio: see what i just said.
[12:35] <d1b> insert make oldconfig infront probably.
[12:36] <babbio> ok thank u
[12:37] <mvo> cjwatson: thanks, I fix that and upload
[12:43] <cjwatson> mvo: I'd been hoping to work out if there's anything that can be done about the fact that busybox Conflicts: busybox-static
[12:44] <cjwatson> mvo: it might be wise to change live-initramfs' dependency to allow either
[12:51] <mvo> cjwatson: I can change live-initramfs in that way too
=== gnarl is now known as smb
=== MacSlow|lunch is now known as MacSlow
=== yofel_ is now known as yofel
[13:15] <pitti> apw, jiboumans: dupes in WI tracker fixed
[13:16] <jiboumans> pitti++
[13:16] <pitti> yay for too complex SQL queries :/
[13:41] <pitti> slangasek: I enabled the CD cronjobs again; I suppose it was just an oversight
[13:53] <tkamppeter> pitti, hi
[13:55] <pitti> hey tkamppeter
[13:57] <tkamppeter> pitti, it is about bug #369850
[13:57] <ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
[13:58] <tkamppeter> people complain that with recent Ubuntu versions they cannot use parallel printers and in the bug report it is told that loading the parport_pc kernel module solves the problem.
[13:58] <tkamppeter> Semms that the presence of a parallel port or plugging a printer to it does not auto-load the module.
[13:59] <tkamppeter> pitti, should the startup script of CUPS load this module? Or do need the udev rules for the parallel port get a correction (load parport_pc in addition)?
[14:05] <pitti> tkamppeter: which udev rule do you mean? if that can be fixed, it'd be much much better than loading it in the init script
[14:06] <pitti> (this should really only be done after a large discussion)
[14:07] <tkamppeter> pitti, I do not know which udev rule, but what loads the modules lp, parport, and ppdev (they are all loaded on my laptop which does not have a parallel port)?
[14:08] <pitti> tkamppeter: cups' init script already loads lp and ppdev
[14:08] <pitti> and ppdev depends on parport
[14:09] <tkamppeter> pitti, so then CUPS' init script should also load parport_pc. How could that get overlooked?
[14:09] <pitti> I don't know, I don't have a parport printer (or a port, for that matter)
[14:09] <pitti> anyway, cups' init script _should_ not modprobe anything at all
[14:10] <pitti> it means that all the parport code gets loaded for everyone, even on machines where you don't need it
[14:10] <pitti> tkamppeter: perhaps in the past parport_pc was a dependency of lp or ppdev?
[14:10] <ion> lp is also in the default /etc/modules for some reason.
[14:10] <pitti> ion: the reason is that it cannot be autodetected by the kernel right now
[14:11] <tkamppeter> pitti, from the bug report we know that parport_pc is needed, and so parport_pc should be loaded by the same mechanism which loads also the other parallel port kernel modules.
[14:11] <tkamppeter> So perhaps we should load them all via /etc/modules, but then we have the same problem as with CUPS, the modules get also loaded on machines without parport.
[14:12] <pitti> tkamppeter: I'd first ask for an udev dump to check whether we can load it in an udev rule
[14:12] <pitti> depending on whether the system has a parallel port in the first place
[14:12] <pitti> then we can also drop the other modprobes in cups
[14:14] <tkamppeter> pitti, can you ask on bug 369850? Or tell me exactly which command the user should execute? He should execute it once wioth printer turned on and once with printer turned off.
[14:14] <ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04 or 9.10" [High,Confirmed] https://launchpad.net/bugs/369850
[14:14] <pitti> tkamppeter: will do
[14:45] <cody-somerville> pitti, The developer of xfce4-power-manager mentioned to me that he doesn't want to merge in his devicekit branch and do a release because he heard that they're planning to rename devicekit. Have you heard anything about this?
[14:48] <pitti> cody-somerville: devicekit-power will be renamed to upower at some point
[14:48] <pitti> cody-somerville: but the migration to that is a simple sed
[14:49] <chrisccoulson> pitti - have you seen hughsie's recent e-mail to desktop-devel?
[14:49] <pitti> chrisccoulson: no, I'm not on that list
[14:49] <chrisccoulson> "I'm intending to keep the devkit-power-gobject library API and ABI stable at least for a few months, and ship a new library side-by-side to allow applications to port during their development cycle, and not to cause pain to the distros."
[14:49] <chrisccoulson> so, he's planning to rename the D-Bus interface, but keep the library API stable for a little while
[14:50] <chrisccoulson> so, it will only break applications that use the D-Bus interface directly
[14:51] <pitti> right
[14:51] <pitti> but hopefully that won't be too many
[14:51] <pitti> chrisccoulson: ah, actually I did get it; apparently CC'ed to devkit-devel@
[14:52] <chrisccoulson> pitti - ah, yeah, he sent it to devkit-devel and not desktop-devel
[14:52] <chrisccoulson> i forgot that i'm subscribed to the former
[15:01] <d1b> re my question before, please ignore it. while the behaviour of firefox in ubuntu differs from normal firefox, the site provided incorrect CA information.
=== stefanlsd_ is now known as stefanlsd
[15:14] <tkamppeter> pitti, OK, thanks.
[15:14] <cody-somerville> chrisccoulson, pitti: xfce4-power-manager does use the dbus interface. Aliov also says " Richard told me that the daemon, even moving it to upower, will bit change a lot, i'm just waiting if this is the case, then xfpm's devkit-power is almost ready.".
[15:14] <cody-somerville> chrisccoulson, pitti: How are other folks mitigating this issue?
[15:20] <pitti> cody-somerville: like g-p-m? they'll just be updated along, I figure
[15:20] <cjwatson> zul: at some point could you please set packages you upload to have their Maintainer as ubuntu-devel-discuss@lists.ubuntu.com rather than ubuntu-devel@lists.ubuntu.com?  The effect of the latter is that ubuntu-reviews gets a mail in its moderation queue every time you upload something
[15:23] <zul> cjwatson: sure
[15:38] <apw> pitti, something is sick with the current lucid.db ...
[15:38] <apw> sqlite> select count(*) from work_items where milestone='milestone';
[15:38] <apw> 324
[15:38] <pitti> eww
[15:40] <pitti> apw: I'll look into it, thanks
[15:40] <pitti> apw: I still have a backup from this morning (with the old format 1), which doesn't have this problem
[15:41] <apw> pitti, dunno if its relevant but when i tried to use the db with older code it was whining about ambigious milestone
[15:41] <pitti> apw: fun, since it's a foreign key to milestones, and "milestone" is not in milestones
[15:42] <pitti> apw: the ambiguity was fixed in r100 and r102, do you have those?
[15:42] <apw> yeah do now, just wondered if there was a connection, sounds like not
[16:15] <siretart`> someone with live-cd wisdom might want to take a look at crimsun's last comment in bug #203158. isn't the plan to remove libsdl from the live cd completly?
[16:15] <ubottu> Launchpad bug 203158 in pulseaudio "libsdl1.2debian-pulseaudio must be installed as default by libsdl1.2debian" [Undecided,Invalid] https://launchpad.net/bugs/203158
[16:20] <alkisg> siretart`: how did you confirm that -all was indeed using pulseaudio?
[16:20] <alkisg> I tried with a remote thin client, and I didn't get any sound with libsdl1.2debian-all, unless I set that env var.
[16:21] <alkisg> I did that test the day I posted the reply, I don't know if anything has changed since.
[16:21] <crimsun> siretart`: removing sdl would mean removing theora, too
[16:22] <siretart`> crimsun: oh, I see
[16:22] <siretart`> alkisg: I installed it, started kobodl and confirmed it is named by name in the pulseaudio mixer.
[16:32] <pitti> apw: 'milestone' problem tracked down and fixed; I added an assertion now that the value is a valid one; thanks for spotting!
[16:32]  * pitti resets the DB to the good state from this morning
[16:33] <apw> pitti, yay!
[16:40] <siretart`> pitti: it seems lool is not around, do you have some minutes to press the magic buttons to finish the libvdpau MIR? that's bug #506788
[16:40] <ubottu> Launchpad bug 506788 in libvdpau "[MIR] libvdpau" [High,In progress] https://launchpad.net/bugs/506788
=== blackxored is now known as Guest15704
[16:42] <pitti> siretart`: I don't see vdpau on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[16:42] <pitti> uh, it's currently in multiverse
[16:43] <siretart`> err, I am absolutely sure that I've seen it this morning...
[16:43] <pitti> anyway, promoting
[16:43]  * siretart` hugs pitti
[16:43] <pitti> you're welcome
[16:44] <siretart`> this will enable ffmpeg to build and start a (small) transition
[16:44] <siretart`> no worries, just a shlibs bump
[17:03] <geser> seb128: just curious, did you got any feedback from soyuz people what caused the OOPS when you tried syncing libxcb on friday?
[17:03] <seb128> no
[17:03] <seb128> or I did read the backlog and they didn't highligh me, let me check
=== ^^robertj is now known as ^robertj
=== BenC1 is now known as BenC
[17:33] <didrocks> ScottK: apparently, you forgot to use the ~ubuntu-core-dev branch for cdbs for your last commit
[17:33] <ScottK> didrocks: No doubt.
[17:33] <didrocks> ScottK: I'll merge it first and then add my changes
[17:33] <ScottK> OK.
[17:34] <ScottK> Sorry about that.
[17:35] <didrocks> ScottK: no pb :)
[17:39] <siretart`> uh, I need to be identified to join #ubuntu-motu? what's up there?
[17:40] <ScottK> siretart`: It's a defense mechanism against all the spam attacks going on.
[17:40] <siretart`> oh, I see
=== BenC2 is now known as BenC
=== njpatel_ is now known as njpatel|away
=== dpm is now known as dpm-afk
=== BenC2 is now known as BenC
=== alkisg1 is now known as alkisg
[19:52] <Burn> hello, I've got problems with my ATI 5750 and Ubuntu Linux 64bit, my screen turns grey after 5 to 10 minutes while I'm running the official 9.12 drivers
[19:52] <Burn> has somebody seen the same behavior?
[19:53] <ScottK> Burn: You probably want #ubuntu+1
[19:53] <Burn> ScottK: ok, will take a look there
[19:53] <Burn> ScottK: in fact no, it should work on Karmic
[19:54] <ScottK> If you're running Karmic, then #ubuntu
[19:55] <Burn> hmm, ok
[19:55] <Burn> thx
[19:58] <sladen> mdeslaur: traditionally Debian/Ubuntu security notices have given a one-sentence or one-paragraph to covering what the software with the security issue does.
[19:59] <sladen> mdeslaur: both of today's USNs for pidgin and libthai just dived straight into the security issue without providing the high-level context
[20:00] <mdeslaur> sladen: Debian does that. Ubuntu has never done that. It's something we're looking to improve soon.
[20:01] <sladen> mdeslaur: would it to be possible to to return to including a short summary "libthai is..."
[20:02] <mdeslaur> sladen: yes, we already have plans for that. See: https://wiki.ubuntu.com/SecurityTeam/Specifications/USNSpec and https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-usn-format
[20:03] <kees> sladen: you're saying that USN-885-1 and USN-887-1 have a different layout?
[20:04] <sladen> mdeslaur: reading back to earlier USNs (http://www.ubuntu.com/usn/), I might (politely) agree to disagree;  eg. "...xpdf, a viewer for PDF files".
[20:04] <kees> sladen: ubuntu has never had the software summary (but we plan to)
[20:04] <sladen> mdeslaur: it's certainly not as consistent as Debian, I'll agree with that
[20:04] <mdeslaur> sladen: which USN are you looking at that has that info?
[20:04] <sladen> kees: "never" is a very strong word, just disproved above(?)
[20:05] <kees> sladen: where?
[20:05] <sladen> http://www.ubuntu.com/usn/usn-2-1
[20:06] <kees> sladen: heh, well, alright.  "Since 2005, Ubuntu has never..."  ;)
[20:07] <kees> but anyway, we've got plans to make a distinct section that only describes the software, separate from vulnerability descriptions.
[20:07] <sladen> kees: I mainly noticed on this occasion, because I went  "wtf is libthai?"
[20:08] <kees> heh.  :)
[20:09] <sladen> fwiw, http://www.ubuntu.com/usn/usn-72-1  "The package "perl-suid" provides a wrapper around perl which allows to use setuid-root perl scripts"
[20:10] <maco> wow that seems like a rather unnecessary description
[20:11] <sladen> maco: ...perhaps, but if the inclusive introductary language (with a high-level description) helps to get a security update applied where it might be ignored, then it's a result
[20:13] <sladen> kees mdeslaur: thanks for the confirmation that it's "in the works"
[20:13] <kees> sladen: "no USN written by me, jdstrand, or mdeslaur ...."  :)  while it shows my name on that one, it's just because I rebuilt the USN history.  I think these early USNs were still being written "freehand" by pitti, and there was no templating system in place yet.
[20:13]  * kees nods
[20:14] <mdeslaur> thanks for your comment sladen, it's much appreciated
[20:15] <barry> ScottK: did you see this: https://code.edge.launchpad.net/~barry/ubuntu/lucid/distribute/sync-to-sid/+merge/17425
[20:15] <ScottK> barry: I did not. Looking
[20:17] <ScottK> barry: The trick is that as a sponsor, I need to see the diff from the current Debian package and the packaging diffs from the current Ubuntu package.  I'm not sure how to do that.
[20:18] <barry> me neither :/  maybe using some combination of commands that you outlined in your recent udd message?
[20:18] <barry> ScottK: i could try to generate though
[20:19] <ScottK> Not sure.  Probably.  Am busy with $WORK at the moment, but if merge proposals are going to be useful pages for merges from Debian, I think it needs to be available.
[20:20] <barry> good point,  that means the auto-generated diff isn't enough.  okay, let me see what i can do.  go back to $WORK :)
[20:50] <cjwatson> ScottK: since you need to check out the Ubuntu branch anyway, you can use the bzr diff --old command in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[20:50] <cjwatson> you'd just do 'bzr merge lp:~barry/ubuntu/lucid/distribute/sync-to-sid' instead of merge-package
[20:51] <ScottK> cjwatson: True.  It'd be nice to see the diffs on the merge proposal as a lot of them that's all it needs to send them back for more work.
[20:51] <barry> or approve them <wink>
[20:52] <barry> cjwatson, ScottK that's essentially what i did.  i merged lp:debian/sid/distribute and lp:ubuntu/lucid/distribute locally, then did the bzr diff --old commands and pastebin'd them.  those are linked in mp comments
[20:53] <ScottK> Ah.
[20:53]  * ScottK looks again
[20:54] <ScottK> barry: Why did you add python2.5-dev to the build-depends?
[20:56] <barry> ScottK: which diff are you looking at?  i didn't think i did
[20:57] <barry> ScottK: ah, diff against sid
[20:57] <ScottK> Yes
[20:57] <barry> ScottK: i guess that's coming from the ubuntu package. it wasn't a change i made explicitly
[20:58] <ScottK> Since Python 2.5 isn't a supported Python in Lucid, I'm reasonably certain we don't need it.
[20:58] <barry> i should remove that then
[20:58] <ScottK> It looks like there are a few other places that have extra 2.5's in them
[20:59] <ScottK> Specifically pyvers in debian/rules
[21:00] <barry> ScottK: i guess i should remove the "PYVERS := 2.4 2.5" line?
[21:00] <lool> jdstrand: Re: FORWARD rules for vms/libvirt in ufw -- actually libvirt already manages to add its rules for the dnsmasq virbr0 already
[21:01] <lool> So at least that seems to work out of the box; probably not for other networks though
[21:01] <ScottK> barry: Yes.
[21:01] <barry> ScottK: k, will do
=== cyphermox_ is now known as cyphermox
[21:28] <slangasek> pitti: CD cronjobs> yes, sorry
[21:43] <RainCT> Argh. Can some archive admin please reject espeak-gui?
[21:44] <sebner> RainCT: ho ho ho. ~ppa1 :P
[21:45] <RainCT> sebner: Yeah. Why isn't there an autoreject for anything containing "~ppa"? :(
[21:46] <geser> file a bug
[21:46] <sebner> RainCT: because ~ppa is for PPAs and people should be aware of that :P
[21:46] <sebner> huhu geser :)
[21:53] <barry> ScottK: i'm looking at the distribute package and i can't see where debian/python-distribute.debhelper.log or debian/python-distribute.substvars are even needed.  the latter is referenced in rules, but commented out.  is there something i'm missing or can i just rm those files?
[21:54] <ScottK> barry: The debhelper logs are autogenerated cruft and can be ignored/removed.
[21:54] <ScottK> Same thing with substvars.
[21:55] <ScottK> I'd leave them though to miminze the diff.
[21:56] <barry> ScottK: okay.  i'll revert the changes to the .substvars file to reduce diff clutter
[23:16] <fagan> Anyone free to talk about hardy to lucid upgrades?
[23:17] <fagan> Its nothing bad trust me :)
[23:21] <fagan> Ah ill talk about it tomorrow
[23:22] <fagan> brb restarting