[00:02] "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] asac: URL? [00:03] http://www.w3.org/TR/CSS21/syndata.html [00:03] 4.3.2 Lengths [00:03] slangasek: so scaling of pixel unit seems to be explicitly encouraged [00:04] of course we dont know how far the user is away [00:04] it says to scale it to account for viewing distances [00:04] not to screw with it based on DPI [00:04] so we scale blindly by dpi [00:04] 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] slangasek: its a combination of distance and density from what i understand [00:05] # pt: points — the points used by CSS 2.1 are equal to 1/72nd of an inch. [00:05] so in theory we would need three profiles or somthing like: [00:05] handheld, laptop, desktop [00:05] the spec also says that, which is the correct definition of points [00:06] pitti: is bug #27622 still 'in progress' somewhere? [00:06] Launchpad bug 27622 in langpack-locales "Paper Size is wrong for locale es_CO (A4 -> Letter)" [Medium,In progress] https://launchpad.net/bugs/27622 === jdong__ is now known as jdong === lifeless_ is now known as lifeless [00:07] 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] slangasek: yeah i agree. and maybe pt really does that [00:07] but it looked like it doesnt ... could be relative of course [00:08] i dont have a high dpi device here to compare the real size [00:09] 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 === TheMuso_ is now known as TheMuso === pgraner-errands is now known as pgraner [01:19] ikonia; you there?? [01:21] it's past 1am, so probably not [01:21] it depends on the country where they stay...here its 7 am [01:22] yes, it does indeed depend on that. [01:22] i just came here seing this IRC name in GSoC [01:22] and it's past 1am where he is [01:22] 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] thank you directhex, TheMuso for the info [01:23] any discussions on GSoc [01:26] i am sarching for maria who is the mentor for ubuntu in GSoC === ampelbein is now known as Ampelbein [01:50] how do i build cheese on ubuntu 9.04 [01:50] ? [01:51] latest cheese sources require latest gnome [01:51] which is latest than on 9.04 === nhandler_ is now known as nhandler === Snova_ is now known as Snova [03:29] 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. === Ampelbein is now known as ampelbein [04:25] kees: out of curiousity, where would we fit in on http://www.awe.com/mark/blog/200801070918.html that chart? [05:03] james_w: hrm, is bzr-builddeb known to be broken in jaunty right now? [05:04] possibly only when the upstream tarball is missing [05:04] hmm, nope, broken even if I grab it [05:12] slangasek: not known to me [05:13] i used bzr builddeb today just fine [05:15] slangasek: bug 345727 is problematic for people that use both gnome & kde. [05:15] Launchpad bug 345727 in seahorse-plugins "Seahorse-agent writes an empty ~/.gnupg/gpg.conf on first run, breaking email signing in KDE" [Medium,In progress] https://launchpad.net/bugs/345727 [05:17] 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] (that bug is why i used bzr builddeb :P) [05:20] james_w: mmk, bug will be coming then [05:21] (read today as: 2 hours ago) [05:21] slangasek: thanks [05:27] maco: if by 'bother me about' you mean 'upload', sure? :) [05:27] slangasek: email said release people need to give permission before uploads happen [05:28] so i figured id ask you (release people) before bugging someone about uploading [05:29] maco: yeah, I suppose the email does say that :) [05:29] maco: permission granted [05:29] ok thanks :) [05:30] Hobbsee: how does having libavcodec51 installed break libavcodec52/libavformat52? [05:31] oh i can answer that: "aptitude says so" [05:31] heh [05:32] 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] 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] and you're sure that's not just the brasero/nautilus-cd-burner issue? [05:33] oh if theyve got an issue of their own then that could explain those two [05:34] when this apt process finishes, ill get it to spit out the "omg libavformat52 is gonna break things!" message again [05:34] slangasek: are you blocked on the bzr-builddeb bug? [05:35] james_w: nah, I used debuild instead :-P [05:35] excellent [05:35] I shall stop torturing myself on this free wireless connection and deal with it when I return home [05:35] toodle pip [05:35] * slangasek waves === foxbuntu` is now known as foxbuntu [06:07] good morning [06:34] long update [06:35] anyway...aptitude says "libavformat52: Breaks: libavcodec51 but 3:0.svn20080206-12ubuntu3 is installed. [06:35] " and then offers to remove libavcodec51 [06:35] that's the right thing for it to do [06:36] (the updater killed my net connection, no idea why it keeps doing that) [06:36] and in fact, the latest ffmpeg-debian upload only causes libavcodec51 to be removed sooner [06:37] maybe its just bcause of the brasero/nautilus but it gives a "score 270" [06:38] presenting it as "unmet dependencies" seems like an odd way to deal with that [06:38] i assume update-manager/do-release-upgrade would gloss over that? [06:39] james_w: bug #345747 filed against the bzr-builddeb package [06:39] Launchpad bug 345747 in bzr-builddeb "backtrace when running bzr bd --source" [Undecided,New] https://launchpad.net/bugs/345747 [06:39] 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] Hobbsee: i think he's saying its doing the right thing [06:40] we just find it ugly [06:40] maco: yes, 'unmet dependencies' is a bit odd; yes, update-manager would do something less odd [06:40] Hobbsee: is what maco described above the issue that you were trying to fix? [06:41] maco: oh, aptitude offers to remove it? I don't recall you mentioning that earlier. [06:41] slangasek: yes [06:42] pretty sure i said that. quassel's going nuts trying to do a /lastlog though [06:49] 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] maco: oh good. So i'm not going *entirely* mad. [06:53] I'll reject the upload then [06:54] ok, cool [06:58] hey all... I want to install gcc 4.4 alongside everything else on my system.... how can I do that? [07:16] Just an idea: http://brainstorm.ubuntu.com/idea/18694/ [07:16] J-_: no need to spam that here as well. Besides, jaunty's in beta freeze by now. [07:16] J-_: and looking at that, the answer will be "Mark says no", fwiw [07:16] Ah okay. [07:17] yep [07:17] though id love if we could alt+click or ctrl+click or something [07:17] then it wouldnt interrupt using the window behind, which is the reason they're currently not clickable [07:23] maco: but you can't accept one type of mouse input without accepting them all [07:24] crdlb: what if it glowed when you held down the necessary modifier key? [07:24] that'd add discoverability! === tkamppeter_ is now known as tkamppeter [09:03] pitti, hi [09:03] 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:03] Launchpad bug 345785 in ubiquity "hangs in advanced partitioner" [Undecided,New] https://launchpad.net/bugs/345785 [09:07] 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] 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] ah, fingers crossed then :) [09:17] evand: *pff* now it works (I tried exactly the same steps) [09:28] very odd [09:30] mvo: have you rebooted since? If you haven't, is there a traceback anywhere in your /var/log/installer/debug? [09:31] evand, hi. may i take a few minutes of your time? [09:31] crazybyte: sure [09:31] evand: I have not rebooted yet, but killed / restarted ubiquity (to run it with -d) [09:31] will that overwrite the log ? [09:32] evand: no Traceback, sorry [09:32] mvo: no worries [09:33] 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] 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] crazybyte: sure, why don't you jump in #ubuntu-installer and we can take it from there [09:36] ok [09:36] thank [09:37] 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] evand, ^^^ [09:38] sure [09:38] if email works better for you, mine is evand@ubuntu.com [09:38] ok [09:39] thank you [09:39] anytime [09:45] slangasek: 27522 (wrong paper size) still on my list, just not very high-prio; but I'll get it done for jaunty === azeem_ is now known as azeem [10:12] asac: do you agree to slangasek that bug 310999 should have the targetted tasks removed? or closed at all? [10:12] Launchpad bug 310999 in nss "comodo seen issuing certificates unwisely" [Unknown,Confirmed] https://launchpad.net/bugs/310999 [10:31] Riddell: do you have someone to work on bug 308060? [10:31] Launchpad bug 308060 in libmsn "Include libmsn in main" [Medium,Confirmed] https://launchpad.net/bugs/308060 [10:31] pitti: yes. thought that was already done [10:31] just wont fix it [10:31] asac: okay [10:32] asac: the floating task as well? or just the release tasks? [10:32] pitti: you can keep the floating "nss" open. personally we wont do anything in the distro on our own [10:32] okay [10:32] so either open or close [10:32] i dont mind [10:33] okay, closing then [10:33] thanks! [10:34] Riddell: if not, and libmsn is too buggy/too unmaintained, is it possible to drop the dependency? [10:36] pitti: it's not buggy or unmaintained, I'm working with upstream on a patch, he commented on that bug [10:37] Riddell: ah, thanks [10:39] Riddell: final harrassment from me from today, bug 339902 seems to be in discussion upstream, so we're just waiting for them? [10:39] Launchpad bug 339902 in notify-osd "notifications visible through the screensaver" [High,Invalid] https://launchpad.net/bugs/339902 [10:41] pitti: right, hopefully a fix will be in 4.2.2 out shortly after beta [10:41] great [10:41] * pitti is a bit concerned to see the desktop team's list of RC bugs grow instead of shrink [10:42] 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] 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] libgnome given back on sparc ia64 hppa armel, which should clear up quite a bit of uninstallability [11:09] and libgnomekbd on hppa ia64 [11:15] 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] pitti: I'm interested in seeing how much it's being used [11:18] 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] infinity: phonon Build-Depends: libqt4-dev Depends: libqt4-webkit which is uninstallable because phonon is too old [11:26] pitti: ping [11:26] any know bug on jaunty's jokey and nvidia? [11:27] cjwatson: Fun. [11:29] 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] infinity: interested, but probably not interested enough to beat you to it [11:37] cjwatson: I'll note that doko's the only person actually subscribed to that list. [11:37] cjwatson: Might be nice to find some folks in your team who'd be keen on actually watching it? [11:38] infinity: hmm, yes - can you mail me+Robbie a reminder? [11:39] cjwatson: When I find myself a bit more awake, sure. [11:39] infinity, cjwatson: I would assume that doing rebuild tests would include filing reports for the real failures? [11:39] doko: that was what I understood from infinity's comments above ... [11:39] 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] ahh, ok [11:40] infinity: do you tag the autotest bug reports somehow, BTW, or make them RC, or whatever? [11:40] cjwatson: I target them to the current release. [11:40] * cjwatson nods [11:40] that should be fine [11:40] 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] infinity: I take python-docutils, lxml and clientcookie [11:42] pychecker looks as if it just plain hasn't been updated for 2.6 [11:48] ryanakca: your revision 34 in kdebindings looks wrong, and has caused python-kde4-dev to be uninstallable [11:48] +Conflicts: python-kde4 (<= 4:4.2.1-0ubuntu4) [11:49] ryanakca: shouldn't moving a file from one package to another normally be expressed using Replaces not Conflicts, anyway? [11:56] 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] pitti, will that be able to still make it to the repo? [11:56] pitti, if not I will just not do it and waste my spare time on that ... just wondering [12:03] my fonts just changed with the latest updates; is that expected? [12:04] mdz, where exactly ? i had some issues with firefox antialiasing that were fixed by a recent upload from asac [12:04] ogra: the application font (text in xchat, menus, etc.) [12:05] 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] 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] doko: if you have time to review and sponsor: bug 345860 [12:05] Launchpad bug 345860 in nevow "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/345860 [12:11] geser: Yeah. Ignore that, I'll fix it... Forgot to port the fix to that sbuild fork. :/ [12:16] mdz, just finished an upgrade and my fonts stayed the same [12:19] mdz: it depends on your dpi [12:19] it's a "thinner" looking font [12:19] at least if you refer to font size [12:20] mdz: ah ... yeah. thats a change in fontconfig ... before we shipped -medium while itshould have been -slight hinting [12:20] asac: should have been? [12:20] mdz: yes. thats what we default for in gnome [12:21] so now fontconfig and gnome agree === mcasadevall is now known as NCommander [12:23] 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] 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] mdz: you can try to set that to "Sans 10" ... which is the value we used before [12:36] nightwish: wrong channel? [12:38] cjwatson: or an /ame, presumably [12:38] er, or similar [12:43] cjwatson: hum? [12:43] 12:24 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] cjwatson, I think nightwish means the IRC Server is going down [12:44] there is no one "this host" that everyone on this channel would be using [12:44] and there are better places for notices of IRC server outages than mentioning them in individual channels [12:46] arrrgh sorry seems my irc client is buggy. this msg shouldn't go to people on freenode :/ [12:46] cjwatson, pfft, thats just because you didnt pay attention to his index finger when he said "this host" [13:26] 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] siretart: ^^^ [13:29] oh, ok [13:29] if siretart did it, i already know :) [13:29] i didn't realise he managed ubuntu packages as well as debian [13:29] it's good to have him hanging out in our irc channel, then we know what's going on [13:29] thanks [13:30] Ah. [13:39] lool: do you want an installer change to install libc6-vfp on armel? [13:43] 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] lool: alternatively, perhaps libc6-vfp should be seeded in minimal? === ampelbein is now known as Ampelbein [13:48] 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] cjwatson: It would be welcome to install it indeed; thanks for looking into that [13:49] 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] cjwatson: Ok, will cook you something [13:50] 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] MacSlow: not sure what you are asking for? [13:51] 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] right, but trivial [13:51] pitti, you saw the screenshots, right? [13:51] Yes, just mentionning it for compleness [13:51] lool: (NEWed as well) [13:51] thanks [13:51] MacSlow: I did, but my bling-untrained eye can't see what you mean [13:52] pitti, the nasty rectangle frame behind a GtkEntry-widget [13:52] MacSlow: since those are very different dialog [13:52] ss [13:52] pitti, just focus on the GtkEntry-widgets in each screenshot [13:53] MacSlow: oh, I see [13:53] MacSlow: that's such a minor detail, I personally consider that more like a bug fix [13:53] pitti, you should clearly see that the ones of libgksu have nasty "non-bg-cleared" frame [13:53] pitti, so it would be accepted?! [13:53] MacSlow: however, somehow you need to indicate which input field has the focus? [13:53] pitti, the focus-ring is not touched by this [13:55] MacSlow: looks fine to me [13:55] MacSlow: I mean, fixing this after beta [13:55] pitti, cool ok then [13:55] pitti: nah, I was just curious if we could infer from the existing data [13:56] mdz: in theory yes, but not with a simple LP search [13:56] mdz: such a bug would have a Dependencies.txt attachment added after several comments were already made [13:56] mdz: i. e. it can be told by looking at the activity log [13:57] mdz: I guess it's possible to craft a custom SQL query === Ampelbein is now known as ampelbein === ampelbein is now known as goodkarma [14:05] * pitti hugs mvo === goodkarma is now known as Ampelbein [14:13] jdstrand: there's a patch on bug 308060 now, can you check if that looks like it fixes the issue you had? [14:13] Launchpad bug 308060 in libmsn "Include libmsn in main" [Medium,Confirmed] https://launchpad.net/bugs/308060 [14:14] Riddell: sure [14:28] please help with your clicks: http://change.pennergame.de/change_please/8610636/ [14:28] http://change.pennergame.de/change_please/8610636/ [14:29] please, it is important for me!!!!!!!!!!!!!!! [14:29] http://change.pennergame.de/change_please/8610636/ [14:29] :) [14:29] beat me to it [14:29] hehe [14:29] :-) [14:30] could still give him a ban in case he comes back [14:30] depends on your policies [14:30] mvo, should Synaptic show the priority of a package, especially as modified by /etc/apt/preferences and pinning? [14:30] they usually morph before coming back [14:30] true [14:30] I'll wait and see [14:35] liw: it does not currently, but it would be nice to do it [14:36] mvo, ack; #52158 was the context, but shouldn't require attention from you rightn ow [14:37] 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] ScottK: oh good, I didn't know there was another one. What was that? [14:44] kde-style-skulpture [14:44] I had it on my TODO to replicate you change for that package, but just retried it instead. [14:57] 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] [ 92.577853] nautilus[3962]: segfault at a346008 ip b1da755d sp b65cffc0 error 4 in libbrasero-media.so.0.1.1[b1d97000+1e000] [14:58] uhhh ohhhh [15:02] 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] 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] Riddell: that said, if this is the patch upstream wants, I have no problems [15:06] jdstrand: it's not by upstream, it's by one of us, hello agateau [15:06] 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] hi [15:08] jdstrand: what do you mean with "easier/safer to error out if c2 is larger than c1?" [15:09] XMLSTR _tcscpy(XMLSTR c1, XMLCSTR c2) [15:09] if c2 is larger, c1 will only contains the amount of char it can hold [15:09] agateau: assuming the length calculation is correct [15:10] jdstrand: true [15:10] agateau: I'm not saying it isn't, I'm saying this code is a bit swirly and hard to verify :) [15:10] jdstrand: i see what you mean :) [15:10] agateau: not your additions, mind, just how it processes the string [15:11] I would have been more confident if there was some unit test [15:11] but I played a bit with msntest program [15:11] and I have been chatting with a friend (who was surprised to find me on msn again) for an hour now [15:12] 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] so at least it does not introduce immediate crash [15:12] jdstrand: my patch does write \0 at the end [15:13] agateau: yes, I mean before that (ie, not in _tcscpy()) [15:13] then you could use strlen in tcscpy [15:13] liw: too late for jaunty, because of the UI freeze [15:13] agateau: that seems a bit weird though [15:14] jdstrand: oh, you mean write '\0' at the end of the source string? [15:14] agateau: yes [15:14] mvo, ack, then I won't work on the patch [15:14] liw: but if you fix it in bzr or assign to you and tag later that would be cool [15:14] jdstrand: that would be less invasive indeed [15:14] (now) [15:14] 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] 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] 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] agateau: well, you are doing that anyway, aren't you? [15:18] agateau: oh I see what you mean, bec you changed it, the compiler will blow up [15:18] jdstrand: yes [15:18] and I had to propagate the changes up to where i know the buffer size [15:19] 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] 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] apw: to both actually (well, currently anyway, since I had no reason to do it in any other way) [15:19] right its that way right now [15:20] 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] but i was envisioning makeing the tag changable was the easiest way to fix it [15:20] 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] i think the dialog had become changable dependant on the kernel error type anyhow [15:21] jdstrand: in my (limited) testing it worked ok === Ampelbein is now known as ampelbein [15:21] we might want to say use Tags in preference to main tag or something [15:21] though i think we already have Tags adding tags as it were [15:22] jdstrand: I am quite new to Ubuntu development, so I will let Riddell handle the rest [15:22] apw: ah, indeed [15:22] apw: gosh, seems apport grew too big for me to remember every impleemted detail :/ [15:23] 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] apw: so, apportcheckresume already adds that; shouldn't that suffice? [15:23] pitti, right now we have apport-oops and resume always on suspend or hibernate bugs [15:24] so we can tell them appart, i thought that someone other than [15:24] us had an issue with it being -oops or something [15:24] jdstrand: yes, sounds wise [15:24] apw: seems this was a misunderstanding then; mdz might have looked at older reports which didn't tag themselves with "suspend" yet? [15:25] 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] agateau: if that is the route you choose [15:26] jdstrand: true [15:30] pitti: it is possible to tell them apart, but it's not always convenient [15:30] 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] Launchpad bug 345866 in foomatic-db "Insufficient quoting of filenames" [Undecided,New] https://launchpad.net/bugs/345866 [15:30] 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] (of which there will be many once kerneloops is working) [15:31] tkamppeter: right, that's a bug in cups; we need to make the log files readable for the adm gruop [15:31] apport-kerneloops+resume [15:32] pitti, will this get fixed for beta, as with the beta we will probably get many testers and bug reports. [15:33] tkamppeter: I'm not currently working on it (it doesn't even have a bug); -EOVERLOADED :( [15:33] tkamppeter: can you please file a LP bug for it, and assign it to me? [15:34] pitti, which package [15:34] tkamppeter: cups [15:36] 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] slangasek: I have a pretty bad feeling about 328035 [15:38] lool: thanks, looks fine aside from the "greq" typo :-) Fixed that [15:38] like it will turn out to be the heisenbug which resurfaces post-RC [15:38] lool: I don't think this needs to be uploaded pre-beta though [15:38] and be an obscure kernel race condition rather than an X driver bug [15:38] Pff I suck [15:39] cjwatson: Fixed; no certainly not needed pre beta [15:39] oh no, you pushed [15:40] err bzr is really confused [15:40] you need to use bound branches :) [15:40] It's fixed in bzr though [15:40] I definitely beat you to it, bound branches wouldn't lie to me. P) [15:40] :) [15:41] pitti, bug 345953 [15:41] Launchpad bug 345953 in cups "Apport hook for printing does not capture CUPS error_log: Permission Denied" [High,Triaged] https://launchpad.net/bugs/345953 [15:41] What'ss weird is that I don't see your revision in my local log after a merge [15:41] you probably want to uncommit and pull again ... [15:42] But I do stand corrected and that's a point in favor of bound branches for the future [15:44] lool: you can also rebase [15:45] pitti: Yes, I was surprized that this actually works fine [15:45] 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] 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] 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] 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] slangasek: agreed [15:47] slangasek: I was just curious about the state [15:48] slangasek: a lot of those are hopefully obsolete with current kernels, but I don't know a good way to check which [15:49] buying more laptops... :) [15:57] Sending them to community developers for testing .... [16:03] pitti, how do I get qa-team membership as fast as possible [16:04] 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] MacSlow: have a word with bdmurray maybe [16:06] davmor2, yeah speaking with bdmurray might be best [16:07] bdmurray, can I perhaps get change-permission to alter the importance of the ubuntu-package notify-osd? [16:08] 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] bdmurray, seb128 always (rightfully) complains I'm not fast enough with commenting/triaging bugs filed on notify-osd (in ubuntu) [16:09] 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] bdmurray, nope [16:10] 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] MacSlow: here's a better link https://wiki.ubuntu.com/Bugs/HowToTriage#Apport%20crash%20reports [16:14] 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] bdmurray, ok after the call I'll read that [16:16]