[00:02] <asac> "Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 i
[00:03] <slangasek> asac: URL?
[00:03] <asac> http://www.w3.org/TR/CSS21/syndata.html
[00:03] <asac> 4.3.2 Lengths
[00:03] <asac> slangasek: so scaling of pixel unit seems to be explicitly encouraged
[00:04] <asac> of course we dont know how far the user is away
[00:04] <slangasek> it says to scale it to account for viewing distances
[00:04] <slangasek> not to screw with it based on DPI
[00:04] <asac> so we scale blindly by dpi
[00:04] <YokoZar> and while we're talking about pixel values the latest updates from today seem to have made the DPI for my display even more wrong (pidgin fonts are even bigger now)
[00:04] <asac> slangasek: its a combination of distance and density from what i understand
[00:05] <slangasek> # pt: points — the points used by CSS 2.1 are equal to 1/72nd of an inch.
[00:05] <asac> so in theory we would need three profiles or somthing like:
[00:05] <asac> handheld, laptop, desktop
[00:05] <slangasek> the spec also says that, which is the correct definition of points
[00:06] <slangasek> pitti: is bug #27622 still 'in progress' somewhere?
[00:07] <slangasek> asac: yes, and I say that tampering with the definition of a pixel based on DPI is worse than doing nothing at all, because DPI is not correlated with viewing angle
[00:07] <asac> slangasek: yeah i agree. and maybe pt really does that
[00:07] <asac> but it looked like it doesnt ... could be relative of course
[00:08] <asac> i dont have a high dpi device here to compare the real size
[00:09] <asac> but px does definitly things based on dpi too ... not sure if thats all a bug or not ;). probably needs some discussion with the right folks
[01:19] <PerryArmstrong> ikonia; you there??
[01:21] <directhex> it's past 1am, so probably not
[01:21] <PerryArmstrong> it depends on the country where they stay...here its 7 am
[01:22] <directhex> yes, it does indeed depend on that.
[01:22] <PerryArmstrong> i just came here seing this IRC name in GSoC
[01:22] <directhex> and it's past 1am where he is
[01:22] <TheMuso> Considering the person in question has been idling at least 11 hours, I'd say they are not currently around at a guess.
[01:23] <PerryArmstrong> thank you directhex, TheMuso for the info
[01:23] <PerryArmstrong> any discussions on GSoc
[01:26] <PerryArmstrong> i am sarching for maria who is the mentor for ubuntu in GSoC
[01:50] <t3rm1n4l> how do i build cheese on ubuntu 9.04
[01:50] <t3rm1n4l> ?
[01:51] <t3rm1n4l> latest cheese sources require latest gnome
[01:51] <t3rm1n4l> which is latest than on 9.04
[03:29] <TheMuso> slangasek: new linux-ports uploaded, no ABI bump, based on the most recent jaunty kernel upload, with the only change being the config change mentioned which was done in jaunty mainline.
[04:25] <jdong> kees: out of curiousity, where would we fit in on http://www.awe.com/mark/blog/200801070918.html that chart?
[05:03] <slangasek> james_w: hrm, is bzr-builddeb known to be broken in jaunty right now?
[05:04] <slangasek> possibly only when the upstream tarball is missing
[05:04] <slangasek> hmm, nope, broken even if I grab it
[05:12] <james_w> slangasek: not known to me
[05:13] <maco> i used bzr builddeb today just fine
[05:15] <maco> slangasek: bug 345727 is problematic for people that use both gnome & kde.
[05:17] <maco> ScottK and i talked about it, and having seahorse-agent do what gpg-agent does and just put the skeleton file in place seemed like the right thing to do. there's a branch attached to fix it. is that something to bother you about for release?
[05:18] <maco> (that bug is why i used bzr builddeb :P)
[05:20] <slangasek> james_w: mmk, bug will be coming then
[05:21] <maco> (read today as: 2 hours ago)
[05:21] <james_w> slangasek: thanks
[05:27] <slangasek> maco: if by 'bother me about' you mean 'upload', sure? :)
[05:27] <maco> slangasek: email said release people need to give permission before uploads happen
[05:28] <maco> so i figured id ask you (release people) before bugging someone about uploading
[05:29] <slangasek> maco: yeah, I suppose the email does say that :)
[05:29] <slangasek> maco: permission granted
[05:29] <maco> ok thanks :)
[05:30] <slangasek> Hobbsee: how does having libavcodec51 installed break libavcodec52/libavformat52?
[05:31] <maco> oh i can answer that: "aptitude says so"
[05:31] <slangasek> heh
[05:32] <maco> aptitude full-upgrade says i have to remove libavcodec51 so libavformat52 can be installed and then brasero is not allowed to update once that occurs
[05:32] <slangasek> well, libavformat52 is marked Breaks: libavcodec51, and I don't understand that one either; but adding a conflicts besides seems like the wrong solution
[05:33] <slangasek> and you're sure that's not just the brasero/nautilus-cd-burner issue?
[05:33] <maco> oh if theyve got an issue of their own then that could explain those two
[05:34] <maco> when this apt process finishes, ill get it to spit out the "omg libavformat52 is gonna break things!" message again
[05:34] <james_w> slangasek: are you blocked on the bzr-builddeb bug?
[05:35] <slangasek> james_w: nah, I used debuild instead :-P
[05:35] <james_w> excellent
[05:35] <james_w> I shall stop torturing myself on this free wireless connection and deal with it when I return home
[05:35] <james_w> toodle pip
[05:35]  * slangasek waves
[06:07] <dholbach> good morning
[06:34] <maco> long update
[06:35] <maco> anyway...aptitude says "libavformat52: Breaks: libavcodec51 but 3:0.svn20080206-12ubuntu3 is installed.
[06:35] <maco> " and then offers to remove libavcodec51
[06:35] <slangasek> that's the right thing for it to do
[06:36] <maco> (the updater killed my net connection, no idea why it keeps doing that)
[06:36] <slangasek> and in fact, the latest ffmpeg-debian upload only causes libavcodec51 to be removed sooner
[06:37] <maco> maybe its just bcause of the brasero/nautilus but it gives a "score 270"
[06:38] <maco> presenting it as "unmet dependencies" seems like an odd way to deal with that
[06:38] <maco> i assume update-manager/do-release-upgrade would gloss over that?
[06:39] <slangasek> james_w: bug #345747 filed against the bzr-builddeb package
[06:39] <Hobbsee> slangasek: if i've got it wrong, feel free to kill that upload and upload whatever *is* the fix, and point me at it
[06:40] <maco> Hobbsee: i think he's saying its doing the right thing
[06:40] <maco> we just find it ugly
[06:40] <slangasek> maco: yes, 'unmet dependencies' is a bit odd; yes, update-manager would do something less odd
[06:40] <slangasek> Hobbsee: is what maco described above the issue that you were trying to fix?
[06:41] <Hobbsee> maco: oh, aptitude offers to remove it?  I don't recall you mentioning that earlier.
[06:41] <Hobbsee> slangasek: yes
[06:42] <maco> pretty sure i said that. quassel's going nuts trying to do a /lastlog though
[06:49] <maco> Hobbsee: ok your memory wins. i only saw & repeated the part of aptitude's spew that says it was going to not-update brasero
[06:49] <Hobbsee> maco: oh good.  So i'm not going *entirely* mad.
[06:53] <slangasek> I'll reject the upload then
[06:54] <Hobbsee> ok, cool
[06:58] <Hydrant> hey all... I want to install gcc 4.4 alongside everything else on my system.... how can I do that?
[07:16] <J-_> Just an idea: http://brainstorm.ubuntu.com/idea/18694/ </spam>
[07:16] <Hobbsee> J-_: no need to spam that here as well.  Besides, jaunty's in beta freeze by now.
[07:16] <Hobbsee> J-_: and looking at that, the answer will be "Mark says no", fwiw
[07:16] <J-_> Ah okay.
[07:17] <maco> yep
[07:17] <maco> though id love if we could alt+click or ctrl+click or something
[07:17] <maco> then it wouldnt interrupt using the window behind, which is the reason they're currently not clickable
[07:23] <crdlb> maco: but you can't accept one type of mouse input without accepting them all
[07:24] <maco> crdlb: what if it glowed when you held down the necessary modifier key?
[07:24] <maco> that'd add discoverability!
[09:03] <tkamppeter> pitti, hi
[09:03] <mvo> evand: I have a haning partman in front of me (bug #345785) - anything I can do to resurrect it or will I have to redo the partitioning and kill ubiquity (with todays daily)
[09:07] <evand> mvo: can you kill it, but also when you run the installer again, can you pass ubiquity the -d flag and then attach /var/log/installer/debug to that bug report?
[09:08] <mvo> evand: sure, I will do that. I'm not sure I will be able to reproduce it again, but I will try. I paritioned back and forth (I need a complicated layout to test my free space code :)
[09:09] <evand> ah, fingers crossed then :)
[09:17] <mvo> evand: *pff* now it works (I tried exactly the same steps)
[09:28] <evand> very odd
[09:30] <evand> mvo:  have you rebooted since?  If you haven't, is there a traceback anywhere in your /var/log/installer/debug?
[09:31] <crazybyte> evand, hi. may i take a few minutes of your time?
[09:31] <evand> crazybyte: sure
[09:31] <mvo> evand: I have not rebooted yet, but killed / restarted ubiquity (to run it with -d)
[09:31] <mvo> will that overwrite the log ?
[09:32] <mvo> evand: no Traceback, sorry
[09:32] <evand> mvo: no worries
[09:33] <crazybyte> evand, after a short discussion with janimo (i'm not sure that you know him but he recomended you) and browsering around I want to poke around and try to implement a grub-restore and some gui for grub as posted on brainstrom and janimo told me that i can ask you a bit about ubiquity
[09:35] <crazybyte> i want to familiarize myself with the code and also and i'm sure that i will came up with some questions for things that i don't really understand
[09:36] <evand> crazybyte: sure, why don't you jump in #ubuntu-installer and we can take it from there
[09:36] <crazybyte> ok
[09:36] <crazybyte> thank
[09:37] <crazybyte> i can't right now because i'm at work and trying to figure out the cause of some very ugly bug but if later i can i will gladly. is that possible?
[09:37] <crazybyte> evand, ^^^
[09:38] <evand> sure
[09:38] <evand> if email works better for you, mine is evand@ubuntu.com
[09:38] <crazybyte> ok
[09:39] <crazybyte> thank you
[09:39] <evand> anytime
[09:45] <pitti> slangasek: 27522 (wrong paper size) still on my list, just not very high-prio; but I'll get it done for jaunty
[10:12] <pitti> asac: do you agree to slangasek that bug 310999 should have the targetted tasks removed? or closed at all?
[10:31] <pitti> Riddell: do you have someone to work on bug 308060?
[10:31] <asac> pitti: yes. thought that was already done
[10:31] <asac> just wont fix it
[10:31] <pitti> asac: okay
[10:32] <pitti> asac: the floating task as well? or just the release tasks?
[10:32] <asac> pitti: you can keep the floating "nss" open. personally we wont do anything in the distro on our own
[10:32] <pitti> okay
[10:32] <asac> so either open or close
[10:32] <asac> i dont mind
[10:33] <pitti> okay, closing then
[10:33] <pitti> thanks!
[10:34] <pitti> Riddell: if not, and libmsn is too buggy/too unmaintained, is it possible to drop the dependency?
[10:36] <Riddell> pitti: it's not buggy or unmaintained, I'm working with upstream on a patch, he commented on that bug
[10:37] <pitti> Riddell: ah, thanks
[10:39] <pitti> Riddell: final harrassment from me from today, bug 339902 seems to be in discussion upstream, so we're just waiting for them?
[10:41] <Riddell> pitti: right, hopefully a fix will be in 4.2.2 out shortly after beta
[10:41] <pitti> great
[10:41]  * pitti is a bit concerned to see the desktop team's list of RC bugs grow instead of shrink
[10:42] <pitti> but that's just because less and less "critical" bugs are put into it, not because they don't get fixed (they do)
[10:42] <pitti> so, by and large, we're in good shape
[10:44]  * pitti -> off again
[10:59]  * cjwatson looks at his huge pile of build failure mails, sighs, and starts digging into ports uninstallability
[11:05] <cjwatson> libgnome given back on sparc ia64 hppa armel, which should clear up quite a bit of uninstallability
[11:09] <cjwatson> and libgnomekbd on hppa ia64
[11:15] <mdz> pitti: is there any simple way to query for bugs  where apport-collect was used (i.e. which were not reported originally using apport)?
[11:15] <mdz> pitti: I'm interested in seeing how much it's being used
[11:18] <cjwatson> infinity: phonon is going to need manual bootstrapping on hppa, assuming that the weird segfault in http://launchpadlibrarian.net/23279114/buildlog_ubuntu-jaunty-hppa.phonon_4%3A4.3.1-0ubuntu1_FAILEDTOBUILD.txt.gz doesn't happen again
[11:18] <cjwatson> infinity: phonon Build-Depends: libqt4-dev Depends: libqt4-webkit which is uninstallable because phonon is too old
[11:26] <BUGabundo> pitti: ping
[11:26] <BUGabundo> any know bug on jaunty's jokey and nvidia?
[11:27] <infinity> cjwatson: Fun.
[11:29] <infinity> cjwatson: Oh, if you're deeply interested in failures, you might want to get a jump on https://lists.ubuntu.com/archives/ubuntu-autotest/2009-March/thread.html before I start filing bugs today...
[11:33] <cjwatson> infinity: interested, but probably not interested enough to beat you to it
[11:37] <infinity> cjwatson: I'll note that doko's the only person actually subscribed to that list.
[11:37] <infinity> cjwatson: Might be nice to find some folks in your team who'd be keen on actually watching it?
[11:38] <cjwatson> infinity: hmm, yes - can you mail me+Robbie a reminder?
[11:39] <infinity> cjwatson: When I find myself a bit more awake, sure.
[11:39] <doko> infinity, cjwatson: I would assume that doing rebuild tests would include filing reports for the real failures?
[11:39] <cjwatson> doko: that was what I understood from infinity's comments above ...
[11:39] <infinity> doko: I try to get them all filed (or even fix the really trivial ones), but more eyes (and people beating me to it) wouldn't hurt, since it really is distro's domain.
[11:39] <doko> ahh, ok
[11:40] <cjwatson> infinity: do you tag the autotest bug reports somehow, BTW, or make them RC, or whatever?
[11:40] <infinity> cjwatson: I target them to the current release.
[11:40]  * cjwatson nods
[11:40] <cjwatson> that should be fine
[11:40] <infinity> cjwatson: And make them RC if it's a fatal, all-arches sort of failure, rather than a "gee, this doesn't work on PPC" thing.
[11:41] <doko> infinity: I take python-docutils, lxml and clientcookie
[11:42] <cjwatson> pychecker looks as if it just plain hasn't been updated for 2.6
[11:48] <cjwatson> ryanakca: your revision 34 in kdebindings looks wrong, and has caused python-kde4-dev to be uninstallable
[11:48] <cjwatson> +Conflicts: python-kde4 (<= 4:4.2.1-0ubuntu4)
[11:49] <cjwatson> ryanakca: shouldn't moving a file from one package to another normally be expressed using Replaces not Conflicts, anyway?
[11:56] <MacSlow> pitti, will it make sense to work on a patch (on the weekend) to fix these libgksu-glitches (http://people.ubuntu.com/~mmueller/libgksu-clearlooks.png http://people.ubuntu.com/~mmueller/libgksu-murrine.png) so GtkEntry-widgets will look like http://people.ubuntu.com/~mmueller/custom-app-clearlooks.png http://people.ubuntu.com/~mmueller/custom-app-murrine.png (note: just GtkEntry not the brushed metal bg)
[11:56] <MacSlow> pitti, will that be able to still make it to the repo?
[11:56] <MacSlow> pitti, if not I will just not do it and waste my spare time on that ... just wondering
[12:03] <mdz> my fonts just changed with the latest updates; is that expected?
[12:04] <ogra> mdz, where exactly ? i had some issues with firefox antialiasing that were fixed by a recent upload from asac
[12:04] <mdz> ogra: the application font (text in xchat, menus, etc.)
[12:05] <geser> infinity: your rebuild sbuild has that bug that the provided modules from the perl package are counted for versioned build dependencies, see https://lists.ubuntu.com/archives/ubuntu-autotest/2009-March/020856.html
[12:05] <ogra> hmmm, for me it turned out that there were some links from /etc/fonts/conf.avail/ to /etc/fonts/conf.d missing, but the latest upload should have fixed that, probably it causes other fallout
[12:05] <geser> doko: if you have time to review and sponsor: bug 345860
[12:11] <infinity> geser: Yeah.  Ignore that, I'll fix it...  Forgot to port the fix to that sbuild fork. :/
[12:16] <ogra> mdz, just finished an upgrade and my fonts stayed the same
[12:19] <asac> mdz: it depends on your dpi
[12:19] <mdz> it's a "thinner" looking font
[12:19] <asac> at least if you refer to font size
[12:20] <asac> mdz: ah ... yeah. thats a change in fontconfig ... before we shipped -medium while itshould have been -slight hinting
[12:20] <mdz> asac: should have been?
[12:20] <asac> mdz: yes. thats what we default for in gnome
[12:21] <asac> so now fontconfig and gnome agree
[12:23] <asac> mdz: the other change is that we use 13.333px for /desktop/gnome/interface/font_name ... before we had "10"; but that only makes a real difference on screens != 96 dpi
[12:24] <nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
[12:24] <asac> mdz: you can try to set that to "Sans 10" ... which is the value we used before
[12:36] <cjwatson> nightwish: wrong channel?
[12:38] <Hobbsee> cjwatson: or an /ame, presumably
[12:38] <Hobbsee> er, or similar
[12:43] <nightwish> cjwatson: hum?
[12:43] <cjwatson> 12:24 <nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
[12:43] <cody-somerville> cjwatson, I think nightwish means the IRC Server is going down
[12:44] <cjwatson> there is no one "this host" that everyone on this channel would be using
[12:44] <cjwatson> and there are better places for notices of IRC server outages than mentioning them in individual channels
[12:46] <nightwish> arrrgh sorry seems my irc client is buggy. this msg shouldn't go to people on freenode :/
[12:46] <ogra> cjwatson, pfft, thats just because you didnt pay attention to his index finger when he said "this host"
[13:26] <superdump> i think this may not be the right place to ask, but i was wondering whether the ffmpeg packages (ffmpeg, libav*, libswscale...) with the svn20090303 version name were taken from the 0.5 branch that we made or from trunk
[13:29] <ScottK> siretart: ^^^
[13:29] <superdump> oh, ok
[13:29] <superdump> if siretart did it, i already know :)
[13:29] <superdump> i didn't realise he managed ubuntu packages as well as debian
[13:29] <superdump> it's good to have him hanging out in our irc channel, then we know what's going on
[13:29] <superdump> thanks
[13:30] <ScottK> Ah.
[13:39] <cjwatson> lool: do you want an installer change to install libc6-vfp on armel?
[13:43] <cjwatson> lool: if so, can I have something suitable for around line 564 of http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/ubuntu/annotate/head%3A/hw-detect.sh ?
[13:44] <cjwatson> lool: alternatively, perhaps libc6-vfp should be seeded in minimal?
[13:48] <lool> cjwatson: I'm happy you noticed, I don't have to tell you about NEW-ing it and selecting it in the installer then   :-)
[13:49] <lool> cjwatson: It would be welcome to install it indeed; thanks for looking into that
[13:49] <pitti> mdz: apport-collect> not right now, I'm afraid; I guess I can make it add an apport-collect tag if that helps?
[13:50] <lool> cjwatson: Ok, will cook you something
[13:50] <cjwatson> lool: I think it's probably simplest to put it in minimal, so I'll just do that. After that the hw-detect change would only be necessary if Debian wanted to have the same thing
[13:51] <pitti> MacSlow: not sure what you are asking for?
[13:51] <lool> cjwatson: It will work if you pull it in minimal; perhaps we wont need that next cycle though if we build everything vfp, in which case we'll have to think of reverting it
[13:51] <cjwatson> right, but trivial
[13:51] <MacSlow> pitti, you saw the screenshots, right?
[13:51] <lool> Yes, just mentionning it for compleness
[13:51] <cjwatson> lool: (NEWed as well)
[13:51] <lool> thanks
[13:51] <pitti> MacSlow: I did, but my bling-untrained eye can't see what you mean
[13:52] <MacSlow> pitti, the nasty rectangle frame behind a GtkEntry-widget
[13:52] <pitti> MacSlow: since those are very different dialog
[13:52] <pitti> ss
[13:52] <MacSlow> pitti, just focus on the GtkEntry-widgets in each screenshot
[13:53] <pitti> MacSlow: oh, I see
[13:53] <pitti> MacSlow: that's such a minor detail, I personally consider that more like a bug fix
[13:53] <MacSlow> pitti, you should clearly see that the ones of libgksu have nasty "non-bg-cleared" frame
[13:53] <MacSlow> pitti, so it would be accepted?!
[13:53] <pitti> MacSlow: however, somehow you need to indicate which input field has the focus?
[13:53] <MacSlow> pitti, the focus-ring is not touched by this
[13:55] <pitti> MacSlow: looks fine to me
[13:55] <pitti> MacSlow: I mean, fixing this after beta
[13:55] <MacSlow> pitti, cool ok then
[13:55] <mdz> pitti: nah, I was just curious if we could infer from the existing data
[13:56] <pitti> mdz: in theory yes, but not with a simple LP search
[13:56] <pitti> mdz: such a bug would have a Dependencies.txt attachment added after several comments were already made
[13:56] <pitti> mdz: i. e. it can be told by looking at the activity log
[13:57] <pitti> mdz: I guess it's possible to craft a custom SQL query
[14:05]  * pitti hugs mvo
[14:13] <Riddell> jdstrand: there's a patch on bug 308060 now, can you check if that looks like it fixes the issue you had?
[14:14] <jdstrand> Riddell: sure
[14:28] <Bester_Penner_fo> please help with your clicks: http://change.pennergame.de/change_please/8610636/
[14:28] <Bester_Penner_fo> http://change.pennergame.de/change_please/8610636/
[14:29] <Bester_Penner_fo> please, it is important for me!!!!!!!!!!!!!!!
[14:29] <Bester_Penner_fo> http://change.pennergame.de/change_please/8610636/
[14:29] <superdump> :)
[14:29] <cjwatson> beat me to it
[14:29] <superdump> hehe
[14:29] <ion_> :-)
[14:30] <superdump> could still give him a ban in case he comes back
[14:30] <superdump> depends on your policies
[14:30] <liw> mvo, should Synaptic show the priority of a package, especially as modified by /etc/apt/preferences and pinning?
[14:30] <cjwatson> they usually morph before coming back
[14:30] <superdump> true
[14:30] <cjwatson> I'll wait and see
[14:35] <mvo> liw: it does not currently, but it would be nice to do it
[14:36] <liw> mvo, ack; #52158 was the context, but shouldn't require attention from you rightn ow
[14:37] <ScottK> cjwatson: I can confirm the powerpc gcc bug is fixed as another package that had the same ICE as qt4-x11 just built after I retried it.
[14:43] <cjwatson> ScottK: oh good, I didn't know there was another one. What was that?
[14:44] <ScottK> kde-style-skulpture
[14:44] <ScottK> I had it on my TODO to replicate you change for that package, but just retried it instead.
[14:57] <PecisDarbs> anyone ran into such bug in jaunty - put empty cd-rw in a drive and suddenly nautilus goes mad and trying to open itself for some 5 - 7 times, crashes, and tries again
[14:58] <PecisDarbs> [   92.577853] nautilus[3962]: segfault at a346008 ip b1da755d sp b65cffc0 error 4 in libbrasero-media.so.0.1.1[b1d97000+1e000]
[14:58] <PecisDarbs> uhhh ohhhh
[15:02] <liw> mvo, looking at #76740 - I can see in the glade file that several of the dialogs are indeed missing window titles; should I add them and send you a patch (or branch to merge, whichever is easier for you)? or is it too late to fix this in jaunty?
[15:05] <jdstrand> Riddell: assuming all the length calculations are correct, then yes it looks fine. Those calculations are a bit hairy to verify, but appear correct. I wonder if it would be easier/safer to error out if c2 is larger than c1?
[15:06] <jdstrand> Riddell: that said, if this is the patch upstream wants, I have no problems
[15:06] <Riddell> jdstrand: it's not by upstream, it's by one of us, hello agateau
[15:06] <Riddell> 15:05 < jdstrand> Riddell: assuming all the length calculations are correct, then yes it looks fine. Those calculations are a bit hairy to verify, but appear correct. I wonder if it would be easier/safer to error out if c2 is larger than c1?
[15:08] <agateau> hi
[15:08] <agateau> jdstrand: what do you mean with "easier/safer to error out if c2 is larger than c1?"
[15:09] <jdstrand> XMLSTR _tcscpy(XMLSTR c1, XMLCSTR c2)
[15:09] <agateau> if c2 is larger, c1 will only contains the amount of char it can hold
[15:09] <jdstrand> agateau: assuming the length calculation is correct
[15:10] <agateau> jdstrand: true
[15:10] <jdstrand> agateau: I'm not saying it isn't, I'm saying this code is a bit swirly and hard to verify :)
[15:10] <agateau> jdstrand: i see what you mean :)
[15:10] <jdstrand> agateau: not your additions, mind, just how it processes the string
[15:11] <agateau> I would have been more confident if there was some unit test
[15:11] <agateau> but I played a bit with msntest program
[15:11] <agateau> and I have been chatting with a friend (who was surprised to find me on msn again) for an hour now
[15:12] <jdstrand> agateau: so two things could be done-- you can simply write a '\0' at the end of the string, based on your length calculation or based on your calculation, error out
[15:12] <agateau> so at least it does not introduce immediate crash
[15:12] <agateau> jdstrand: my patch does write \0 at the end
[15:13] <jdstrand> agateau: yes, I mean before that (ie, not in _tcscpy())
[15:13] <jdstrand> then you could use strlen in tcscpy
[15:13] <mvo> liw: too late for jaunty, because of the UI freeze
[15:13] <jdstrand> agateau: that seems a bit weird though
[15:14] <agateau> jdstrand: oh, you mean write '\0' at the end of the source string?
[15:14] <jdstrand> agateau: yes
[15:14] <liw> mvo, ack, then I won't work on the patch
[15:14] <mvo> liw: but if you fix it in bzr or assign to you and tag later that would be cool
[15:14] <agateau> jdstrand: that would be less invasive indeed
[15:14] <liw> (now)
[15:14] <jdstrand> agateau: it should already be there, so there shouldn't be a problem with normal strings
[15:15]  * agateau looks at what it would imply
[15:17] <agateau> jdstrand: the thing is: it means one has to take care of every call to _tcscpy(), and missing one call won't cause a compile error
[15:17] <jdstrand> agateau: the other option is to not change _tcscpy at all and instead treat it like strcpy(), and error out if source is longer than dest, based on your calculations
[15:18] <jdstrand> agateau: well, you are doing that anyway, aren't you?
[15:18] <jdstrand> agateau: oh I see what you mean, bec you changed it, the compiler will blow up
[15:18] <agateau> jdstrand: yes
[15:18] <agateau> and I had to propagate the changes up to where i know the buffer size
[15:19] <apw> pitti on the apport thing, i guess my point was that it all depends if there is a 1:1 correspondance from the type to the dialog or from the type to the tags
[15:19] <apw> i was seeing the type as essentially the dialog to use, and would expect us to have more than one tag possible from that type
[15:19] <pitti> apw: to both actually (well, currently anyway, since I had no reason to do it in any other way)
[15:19] <apw> right its that way right now
[15:20] <jdstrand> agateau: if you are confident that the patch introduces no regressions, I feel ok with it. the length calculation doesn't seem like it should be grossly off (if at all) and a 1 char heap overflow with jaunty's gcc protections would be very hard to exploit
[15:20] <apw> but i was envisioning makeing the tag changable was the easiest way to fix it
[15:20] <pitti> apw: if you are happy with the dialogs, and it's just a matter of tags, then it's easy to add a "Tags" field to the report object, that launchpad.py appends to the standard tags
[15:21] <apw> i think the dialog had become changable dependant on the kernel error type anyhow
[15:21] <agateau> jdstrand: in my (limited) testing it worked ok
[15:21] <apw> we might want to say use Tags in preference to main tag or something
[15:21] <apw> though i think we already have Tags adding tags as it were
[15:22] <agateau> jdstrand: I am quite new to Ubuntu development, so I will let Riddell handle the rest
[15:22] <pitti> apw: ah, indeed
[15:22] <pitti> apw: gosh, seems apport grew too big for me to remember every impleemted detail :/
[15:23] <jdstrand> agateau: perhaps think about what we talked about for a bit, then decide how to proceed. I'll leave the regression testing in the capable hands of Riddell, you and the kde team
[15:23] <pitti> apw: so, apportcheckresume already adds that; shouldn't that suffice?
[15:23] <apw> pitti, right now we have apport-oops and resume always on suspend or hibernate bugs
[15:24] <apw> so we can tell them appart, i thought that someone other than
[15:24] <apw> us had an issue with it being -oops or something
[15:24] <agateau> jdstrand: yes, sounds wise
[15:24] <pitti> apw: seems this was a misunderstanding then; mdz might have looked at older reports which didn't tag themselves with "suspend" yet?
[15:25] <jdstrand> agateau: regarding all calls to tcscpy()-- keep in mind that tcscpy is only used by xmlParser.cpp, and libmsn just imported this file wholesale, so I think as long as you get everything in there, you would be fine.
[15:25] <jdstrand> agateau: if that is the route you choose
[15:26] <agateau> jdstrand: true
[15:30] <mdz> pitti: it is possible to tell them apart,  but it's not always convenient
[15:30] <tkamppeter> pitti, you are aware that the Apport hooks for printing do not capture the most important part due to permission issues? On all printing-related bugs I get CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log', ex: bug 345866
[15:30] <mdz> pitti/apw: you can get all of the suspend/resume bugs by looking for apport-kerneloops+suspend, but you can't get all of the non-suspend kerneloops bugs
[15:30] <mdz> (of which there will be many once kerneloops is working)
[15:31] <pitti> tkamppeter: right, that's a bug in cups; we need to make the log files readable for the adm gruop
[15:31] <apw> apport-kerneloops+resume
[15:32] <tkamppeter> pitti, will this get fixed for beta, as with the beta we will probably get many testers and bug reports.
[15:33] <pitti> tkamppeter: I'm not currently working on it (it doesn't even have a bug); -EOVERLOADED :(
[15:33] <pitti> tkamppeter: can you please file a LP bug for it, and assign it to me?
[15:34] <tkamppeter> pitti, which package
[15:34] <pitti> tkamppeter: cups
[15:36] <lool> cjwatson: I pushed libc6-vfp installation in hw-detect to lp:~ubuntu-core-dev/hw-detect/ubuntu happy if you can review it
[15:38] <mdz> slangasek: I have a pretty bad feeling about 328035
[15:38] <cjwatson> lool: thanks, looks fine aside from the "greq" typo :-) Fixed that
[15:38] <mdz> like it will turn out to be the heisenbug which resurfaces post-RC
[15:38] <cjwatson> lool: I don't think this needs to be uploaded pre-beta though
[15:38] <mdz> and be an obscure kernel race condition rather than an X driver bug
[15:38] <lool> Pff I suck
[15:39] <lool> cjwatson: Fixed; no certainly not needed pre beta
[15:39] <lool> oh no, you pushed
[15:40] <lool> err bzr is really confused
[15:40] <cjwatson> you need to use bound branches :)
[15:40] <lool> It's fixed in bzr though
[15:40] <cjwatson> I definitely beat you to it, bound branches wouldn't lie to me. P)
[15:40] <cjwatson> :)
[15:41] <tkamppeter> pitti, bug 345953
[15:41] <lool> What'ss weird is that I don't see your revision in my local log after a merge
[15:41] <cjwatson> you probably want to uncommit and pull again ...
[15:42] <lool> But I do stand corrected and that's a point in favor of bound branches for the future
[15:44] <pitti> lool: you can also rebase
[15:45] <lool> pitti: Yes, I was surprized that this actually works fine
[15:45] <lool> albeit I had this uncommit filed I added in a checkout once, but I'm not sure whether rebase or me broke it
[15:45] <slangasek> mdz: yes, plausible that it's a kernel race; but only varying the X driver version has so far made the crashes disappear for me
[15:46] <slangasek> pitti: acpi-fakekey: it will work in the specific case that the first keyboard device that acpi-fakekey tries to open is one that happens to have that hotkey in its keymap definition :-P
[15:47] <slangasek> pitti: so yes, that's roughly equivalent to "completely broken", but on the off chance that it's not equivalent in practice, I'd rather just leave the junk there until we have it replaced
[15:47] <pitti> slangasek: agreed
[15:47] <pitti> slangasek: I was just curious about the state
[15:48] <pitti> slangasek: a lot of those are hopefully obsolete with current kernels, but I don't know a good way to check which
[15:49] <slangasek> buying more laptops... :)
[15:57] <ScottK> Sending them to community developers for testing ....
[16:03] <MacSlow> pitti, how do I get qa-team membership as fast as possible
[16:04] <MacSlow> pitti, not being able to change the importance of bugs on the ubuntu-package of notify-osd is really hampering my triaging work
[16:05] <davmor2> MacSlow: have a word with bdmurray maybe
[16:06] <MacSlow> davmor2, yeah speaking with bdmurray  might be best
[16:07] <MacSlow> bdmurray, can I perhaps get change-permission to alter the importance of the ubuntu-package notify-osd?
[16:08] <MacSlow> bdmurray, I'm also the upstream lead and developer of this ... and having the ability to change importance-levels for this would speed up my bug-triaging work
[16:09] <MacSlow> bdmurray, seb128 always (rightfully) complains I'm not fast enough with commenting/triaging bugs filed on notify-osd (in ubuntu)
[16:09] <bdmurray> MacSlow: Are you familiar with apport crash reports and the private information that might be contained with in?  https://wiki.ubuntu.com/Apport
[16:09] <MacSlow> bdmurray, nope
[16:10] <bdmurray> MacSlow: As a member of Ubuntu Bug Control you'd be able to see private bug reports that are from apport crashes and may contain sensitive data
[16:11] <bdmurray> MacSlow: here's a better link https://wiki.ubuntu.com/Bugs/HowToTriage#Apport%20crash%20reports
[16:14] <bdmurray> MacSlow: so once you've familiarized yourself with that since you are an upstream developer I'd be happy to add you to the team
[16:16] <MacSlow> bdmurray, ok after the call I'll read that
[16:16] <calc> who should i contact to get my ppa quota bumped quickly? i hit the limit on my last OOo upload and it got rejected
[16:16] <cjwatson> calc: #launchpad
[16:17] <calc> cjwatson: ok
[16:19] <shaya> vlc seems very messed up on jaunty
[16:20] <shaya> none of the text in menus or dialogs displays correctly
[16:20] <shaya> qt issue?
[16:43] <directhex> shaya, when in doubt, blame qt/gtk bridge stuff
[16:58] <cjwatson> lool: armel uninstallables just dropped from 201 to 62 thanks to libgnome
[16:58] <cjwatson> I'll poke through a few other things I know about shortly
[16:59] <clarc> hi
[16:59] <clarc> would it be possible to put a new vlc version in hardy backports?
[17:08] <Lure> would just like to point to kernel panic with today update (something to look into before beta): bug 339423
[17:09] <lool> cjwatson: wee!
[17:10] <thiebaude> does anyone know when bug 304871 will be fixed?
[17:10] <mvo> Lure: could you please attach /var/log/apt/term.log (if you haven't alrady)?
[17:11] <Lure> mvo: done that, but I did not have any apt-get issue, so I suspect problem is elsewhere
[17:12]  * Lure thinks is it initramfs-tools or kubuntu-default-settings
[17:13] <\sh> bah.../me runs into bug #329403
[17:14] <maco> how long does apt-listchanges --apt $package usually take to run? i'm trying to figure out if this is "normal" or if i should go report a bug
[17:14] <cjwatson> thiebaude: it came up in the release meeting, but there's no known fix at present and upstream are not responsive
[17:14] <cjwatson> thiebaude: so it's being tracked at the highest level, but there's no ETA yet
[17:14] <thiebaude> ok, cjwatson thanks
[17:14] <DnaX> mpt: see this https://bugs.launchpad.net/emesene/+bug/345660
[17:15] <DnaX> update notify osd wiki page ;)
[17:15] <mpt> DnaX, thanks, I saw that this morning but I didn't link to it from the spec because our preferred solution would be for emesene to integrate with the messaging menu instead
[17:16] <\sh> cjwatson: looks like d-i + grub have some problems with /dev/cciss/ devices (intrepid wise)
[17:16] <mpt> DnaX, we don't have docs on how to do that yet, but tedg and/or dbarth in #ayatana may be able to help you out when they're there
[17:17] <cjwatson> \sh: file a bug
[17:17] <DnaX> mpt: can you explain better "messaging menu"?
[17:17] <\sh> cjwatson: someone did already bug #329403 I attached some more info files from /var/log/installer/
[17:17] <cjwatson> \sh: there are some known things that are fixed in jaunty, but I won't be able to tell whether your problem is one of them without checking
[17:18] <cjwatson> \sh: please do NOT attach additional information to existing installer bugs; instead, file a new bug
[17:18] <cjwatson> \sh: it is more work to untangle multiple issues from one bug than it is to mark duplicates
[17:18] <\sh> ok...I'll file a new one :)
[17:18] <mpt> DnaX, the menu that shows up in Jaunty when you're running Evolution and/or Pidgin, and has items for each person who's messaged you recently
[17:20] <mpt> DnaX, huh, from the screenshot on <http://dnax.netsons.org/rendere-emesene-compatibile-con-notify-osd> I see that the old notifications didn't let you reply etc anyway.
[17:20] <mpt> oh, I see
[17:20] <mpt> clicking anywhere on the bubble let you reply
[17:20] <mpt> so just removing that function would be a bit of a regression
[17:21] <johanbr> DnaX: http://bugzilla.gnome.org/show_bug.cgi?id=574744 has some information
[17:21] <DnaX> mpt: you say? uhm...
[17:22] <DnaX> i don't know how integrate emesene with fast-user-switch indicator...
[17:24] <\sh> cjwatson: bug #346001 ... error is already seen in grub-.log
[17:27] <cjwatson> the error in grub.log isn't interesting, didn't need that :-)
[17:27] <cjwatson> it's just a symptom
[17:28] <DnaX> mpt, johanbr: there is a python binding of libindicator?
[17:30] <cjwatson> \sh: oh, this is your system that thinks it's dmraid when it isn't
[17:31] <mpt> DnaX, I'm sorry I don't know the technical details, you'd need to chat with tedg or davidbarth when they're back on Monday (or post to the ubuntu-desktop@ mailing list)
[17:31] <johanbr> DnaX: kind of... https://bugs.launchpad.net/indicator-applet/+bug/343837
[17:31] <mpt> ah :-/
[17:32] <\sh> cjwatson: yes...but I got rid of it...now it's only the grub...and it fails also from cd
[17:32] <DnaX> johanbr: good...
[17:32] <cjwatson> \sh: you did, but grub-installer doesn't realise you did
[17:32] <\sh> cjwatson: oh...cool
[17:33] <cjwatson> I hate dmraid
[17:33] <DnaX> mpt: so... my patch can't be accepted?
[17:33] <\sh> cjwatson: any quick fix that I can try out?
[17:33] <cjwatson> \sh: wait
[17:33] <\sh> cjwatson: well, it's funny..because actually it's a raid but hardware raid ;)
[17:34] <cjwatson> \sh: yeah, but it has metadata on it that dmraid thinks belongs to it
[17:34] <cjwatson> apparently
[17:34] <cjwatson> \sh: this is a bug, of course
[17:35] <cjwatson> \sh: if you haven't already, please do file a bug on dmraid about the misdetection
[17:35] <\sh> cjwatson: I can move the bug I filed to partman-dmraid or dmraid?
[17:35] <mpt> DnaX, well it's a bit better than the status quo. :-) Not in Ubuntu for another week, unfortunately, because we're in beta freeze. But you could submit it upstream.
[17:36] <cjwatson> \sh: no, I already moved it to the proper place, which is grub-installer
[17:36] <DnaX> mpt: i've just submitted to upstrem ;)
[17:36] <cjwatson> \sh: the misdetection is a separate bug, which should be filed on dmraid and investigated
[17:36] <\sh> cjwatson: ok..I'll file another bug :)
[17:37] <DnaX> too later for jaunty? :(
[17:37] <cjwatson> \sh: do you need automatic installation support here?
[17:37] <\sh> cjwatson: yepp :)
[17:37] <cjwatson> \sh: netboot or CD or both?
[17:37] <\sh> cjwatson: netboot
[17:38] <cjwatson> bah, it'd have to be the hard one
[17:38] <mpt> DnaX, I don't know sorry. You could try proposing it for Jaunty and see what happens.
[17:38] <cjwatson> \sh: just 8.10?
[17:38] <\sh> cjwatson: jepp...or actually I could use jaunty too...
[17:39] <\sh> cjwatson: I just used 8.10 because of latest stable release...we need it for tomcat crap..and intrepid is the first one with a good tomcat6 packaging
[17:40] <cjwatson> \sh: well, I'll get it fixed in jaunty, but this should do it for intrepid, I think:
[17:40] <cjwatson> d-i partman/early_command string sed -i '/^if.*dmraid/s/; then/ \&\& false; then/' /usr/bin/grub-installer
[17:40] <cjwatson> \sh: actually it'd be nice to have confirmation of that before I shove this into jaunty :-)
[17:40] <cjwatson> (I'll use a slightly more sophisticated fix in jaunty that doesn't break dmraid, of course)
[17:41] <\sh> cjwatson: give me a couple of mins I'll put this in my preseed and come back to you
[17:42] <cjwatson> cool, thanks
[17:48] <\sh> cjwatson: ok..installing :)
[17:49] <\sh> cjwatson: btw...how can I disable apt-setup-udeb apt-setup/services-select multiselect security, which is set by default, and slows the preseed installation down, when there is no real internet connection...I tried to set it with an empty string, but it just waits there for security.ubuntu.com
[17:51] <eeejay> hey DnaX, need python bindiings for libindicate?
[17:51] <cjwatson> \sh: it must be something else that's waiting, then; setting that to empty does disable apt-setup's security generator
[17:51] <eeejay> DnaX: did you get hold of the bzr branch?
[17:52] <cjwatson> \sh: from your logs, it's a much earlier point
[17:53] <DnaX> eeejay: i'm not a python developer... but my knowledge is sufficient for a small patch :P
[17:53] <eeejay> DnaX: a small patch for what?
[17:53] <cjwatson> \sh: you could set apt-setup/security_host (and apt-setup/security_path if necessary) to a local mirror of -security, or at least to something that will fail quickly
[17:54] <DnaX> eeejay: Emesene
[17:54] <eeejay> DnaX: ah, cool.
[17:54] <DnaX> eeejay: bug #345660
[17:54] <DnaX> eeejay: however I will try bzr branch
[17:55] <\sh> cjwatson: it comes before the udeb loading...
[17:58] <LordKow> hey is it possible to get some pidgin 2.6.0 fixes backported to pidgin 2.5.5? it involves a memory leak.
[18:01] <cjwatson> \sh: right, the apt-setup/security_{host,path} hacks should take care of it
[18:01] <\sh> cjwatson: cool...ok..going into lab and checking installation
[18:04] <LordKow> bug 345774
[18:04] <LordKow> fix available from upstream, requires a backport from their current devel branch (2.6.0).
[18:11] <\sh> cjwatson: good news...that worked :)
[18:11] <cjwatson> great
[18:12] <cjwatson> I'll get a proper fix into grub-installer
[18:12] <\sh> cjwatson: cool :) and thanks for the quick fix :) now I can install some more machines in no time :)
[18:36] <DnaX> mpt: XD released https://bugs.launchpad.net/bugs/345660
[18:36] <\sh> cjwatson: btw...dmraid bug #346011 with reference to #346001
[18:36] <mpt> impressive
[18:37] <cjwatson> \sh: ok, thanks
[18:38] <\sh> cjwatson: anyways...thx a lot for the quick fix :) 10 new test servers installed in no time :)
[18:38] <\sh> and now...weekend time :)
[18:39] <cjwatson> good stuff
[19:01] <cjwatson> lool: ok, I think I've now done something about almost all the armel uninstallables, and at any rate all of the ones I expect you to care about
[19:01] <cjwatson> it'll take a few hours for all the builds to churn though
[19:04] <ScottK> cjwatson: Do you have any hints for easily figuring out why something is uninstallable on an arch one doesn't have access to?
[19:04] <cjwatson> ScottK: chdist
[19:04] <ScottK> cjwatson: Thanks.
[19:04] <cjwatson> it's great, once you have it set up you do 'chdist apt-get jaunty-armel install <foo>'
[19:04] <cjwatson> absolute godsend
[19:05] <ScottK> That sounds like what I've been looking for.
[19:05] <cjwatson> or even build-dep rather than install
[19:06] <ScottK> For build failures the logs are reasonably useful.  But for install failures, I hadn't found anything.
[19:06] <cjwatson> you still have to drill down in the usual way with apt-get, but it no longer takes an eternity of staring at the screen
[19:17] <siretart> superdump: in fact, the ubuntu ffmpeg packaging is even in the debian pkg-multimedia git, because that's easier fo rme
[19:27] <superdump> siretart: :)
[20:00] <slangasek> pitti: interested in your opinion on bug #345531; do you think that's something we should try to get into powerdevil+gpm for jaunty, or should we restore the acpi-support bits that act on the ACPI events instead of the key events?
[20:04] <shaya> has anyone tried to build vlc from source?
[20:04] <shaya> it tries to run itself in the installation and fails due to running as root
[20:04] <shaya> heck, not even root as rebuilding it in fakeroot
[20:07] <slangasek> shaya: seems to be up-to-date in the archive across 8 architectures?
[20:07] <shaya> then I don't know how you build it
[20:08] <shaya> fakeroot dpkg-buildpackage fails
[20:08] <slangasek> well, not like that at least
[20:08] <slangasek> 'dpkg-buildpackage' alone
[20:08] <infinity> shaya: dpkg-buildpackage -rfakeroot is what you want.
[20:08] <shaya> http://pastebin.com/m6634164d
[20:08] <slangasek> -rfakeroot is now the default
[20:08] <infinity> shaya: "fakeroot dpkg-buildpackage" does the whole process as (fake) root.  "dpkg-buildpackage -rfakeroot" only does clean and binary-* as (fake) root.
[20:09] <shaya> ok
[20:09] <shaya> makes sense I guess
[20:09] <shaya> I guess I need to get out of my old 90s methods :)
[20:11] <shaya> trying to figure out this
[20:11] <shaya> this is vlc for me
[20:11] <shaya> http://yucs.org/~spotter/vlc.png
[20:16] <slangasek> mvo: in this update-manager change to no longer account for space for initrd .bak files, won't that potentially bite us if the kernel is upgraded before initramfs-tools on dist-upgrade, or do you already account for ordering elsewhere?
[20:17] <slangasek> mvo: (the kernel package deps don't enforce this, for sure)
[20:44] <gnumm> hi
[20:44] <gnumm> are ubuntu package maintainer here?
[20:46] <dtchen> generally, yes, though you may find your question more succinctly addressed in #ubuntu-motu
[20:46] <gnumm> ok
[21:01] <Turl> hi
[21:01] <Turl> is the new splash screen final?
[21:02] <Turl> usplash, I mean
[21:04] <slangasek> to the best of my knowledge, it is
[21:04] <Turl> :S
[21:04] <Turl> it's completely unpretty
[21:27] <slangasek> superm1: do you know whether nvclock 0.8b4 would be appropriate to suck in from Debian for jaunty?  It appears there are some compatibility fixes there with newer hardware
[21:40] <kklimonda> anyone know what's going on with virtualenv ?
[21:41] <kklimonda> i can't get it to work in jaunty with python 2.6
[21:53] <lool> cjwatson: thanks a lot
[22:13] <calc> anyone know if bug 256058 is actually a bug?
[22:13] <calc> i can't tell if it is a hinting bug or an issue with stem width?
[22:14] <thiebaude> calc: a couple of people were talking about extra large font like 13.3
[22:15] <calc> thiebaude: this is a different issu
[22:15] <calc> thiebaude: http://launchpadlibrarian.net/21512305/bug256058.png
[22:16] <thiebaude> calc: i see what you mean
[22:16] <calc> http://launchpadlibrarian.net/16642799/openoffice_fonts.jpg is another example of it
[22:16] <thiebaude> it's different bug then what i was saying
[22:16] <calc> compared between gutsy and hardy
[22:16] <calc> i saw the 13.33 bug myself a few days ago
[22:17] <thiebaude> ok
[22:17] <RainCT> uhm.. isn't notify-osd supposed to pause the timer when the icon is above a bubble?
[22:18] <RainCT> ah, there's a bug about it
[22:44] <slangasek> mdke: do you have moderator access on ubuntu-doc?  you might want to let through the latest notice regarding a UI freeze exception :)
[23:04] <slangasek> kees: need an MIR opinion on nvclock
[23:04] <slangasek> (an initial impression)
[23:04] <kees> slangasek: #?
[23:05] <slangasek> kees: we have smartdimmer in main, which is an old fork of some code from nvclock that's pulled in by acpi-support; it's stale and doesn't work on current nvidia-based laptops
[23:05] <slangasek> kees: no bug yet
[23:05]  * kees fetches
[23:06] <slangasek> kees: so we can fix this bug by killing off the smartdimmer source package, merging the new upstream version of nvclock from Debian, building a new smartdimmer binary package, and yay
[23:06] <slangasek> nvclock is currently in universe, so y'all are the first stop :)
[23:06] <kees> right, reading through it now
[23:07] <kees> it has a pile of lintian warnings, but it is being maintained (updated Feb 20th).  Perhaps we could pull it before it goes into main?
[23:08] <slangasek> "pull it" --> "do the merge first"?
[23:08] <kees> yeah
[23:09] <kees> it'd be nice to clean up the lintian warnings too.
[23:09] <ilowe> where can I read about the build process for the official livecds?
[23:09] <slangasek> could do; requires two uploads instead of one then, since that implies not hijacking the smartdimmer binary initially
[23:09] <slangasek> but if that's you're preference, I'll get started there
[23:09] <ilowe> I found the Debian/Live project but I'm looking for the Ubuntu-specific stuff
[23:09] <kees> I think that would be a good way to go -- the more recent one closed several Debian-reported bugs.
[23:09] <kees> oh goody
[23:09] <kees>   * Update 01_fix_buffer_overflow dpatch.
[23:10] <kees> I was just going to say that the code looked a little scary
[23:10] <slangasek> :)
[23:11] <kees> in what context does this run?  as the user or as root?
[23:11] <slangasek> kees: rooty
[23:11] <slangasek> twiddling hardware, nom nom
[23:12] <slangasek> there's no unsanitized user input to it, though
[23:12] <slangasek> (when running as root)
[23:12] <kees> yeah, was trying to make that determination
[23:13] <slangasek> it's not suid, currently nothing /at all/ invokes it by default; cf. bug #345531, asking for the smartdimmer integration to be readded to acpi-support for jaunty
[23:14] <slangasek> yuck, why does that buffer_overflow patch take 122 lines to fix a single buffer overflow :P
[23:14] <kees> slangasek: yeah, I think if this got general packaging cleanups, I think it would be in a "supportable" shape.  I would +1 it after a merge, standards update, and misc fixes to get rid of the various lintian warnings.  they all look trivial, but annoying to have in main.
[23:15] <slangasek> ok
[23:15] <kees> slangasek: trailing white-space updates.  ftl
[23:26] <slangasek> kees: haha, the lintian warning about "menu-item-creates-new-section" refers to menu-policy 2.1, where nvclock-gtk is given as an example for one of the sections \o/
[23:27]  * kees holds his face
[23:32] <directhex> http://farm3.static.flickr.com/2373/2048486298_2a6444b4c2.jpg ?