[01:49] <RAOF> I've put a debdiff up for bug #152505 - I've subscribed u-m-s  u-m-s, and the patcbh is trivial, but it might be an idea to work out why th e pointer is NULL in my case.
[01:49] <ubotu> Launchpad bug 152505 in gdm "gdmgreeter segfaults when XRandR is not available" [High,New]  https://launchpad.net/bugs/152505
[02:08] <ccheney> anyone notice weird spacing issues in firefox on pages
[02:08] <ccheney> sometimes words that should have spaces between them don't but when you highlight the word the space appears and the words more or less reflow
[02:16] <minghua> calc: AFAIK that bug has existed forever.
[04:04] <baked> hey, sorry to bother you w/ a simple question like this. I am having trouble with bug #106418, but it says its fixed.  I wanted to try the latest kernel, is there a way to install the latest kernel from dev through apt-get?
[04:05] <baked> sorry
[04:05] <baked> guess i should go to ubuntu+1 for gutsy stuff
[04:06] <jdong> baked: do you mean installing a gutsy kernel in feisty?
[04:06] <baked> well, i upgraded, but i was having the same problem w/ feisty
[04:06] <persia> baked: #ubuntu+1 is a good place for gutsy quasi-support.  #ubuntu-bugs is a good place for bug discussion.  (not to interrupt the conversation currently underway)
[04:07] <baked> i know the problem has to do with the uuid not coming back the same, although i have not gotten a change to just change grub to boot off the drives instead of the uuid location
[04:07] <baked> im kind of lost since its marked fixed
[04:07] <baked> but i know how that goes
[04:11] <mpt> Datacenter's fallen over?
[04:11] <mpt> I can't contact launchpad.net, canonical.com, or ubuntu.com
[04:12] <albertito> mpt: the three work here
[04:13] <kylem> mpt, i just dropped off of internal irc...
[04:14] <lifeless> dc seems awol
[04:14] <lifeless> as mpt is saying :)
[04:14] <mpt> I know what this means
[04:14] <mpt> LUNCH TIME
[04:14] <baked> well, can anyone anser the second half of my question as to install a dev kernel from apt?
[04:15] <baked> answer*
[04:15] <ScottK> baked: Are you running Gutsy?
[04:15] <baked> yea, i know to ask in the other channel
[04:15] <baked> but im not getting any help there, i just want to know if i can test something to see if the bug is fixed in something other then 2.6.22-14
[04:16] <ScottK> The odds of your getting help go way down when you decline to answer questions asked by someone who might be trying to help you.
[04:16] <baked> im sure there are daily builds or soemthing, i just can't figure out how / where thye are
[04:16] <baked> i understand scott, and as i answers, 'yea
[04:16] <baked> '
[04:16] <baked> i am using gutsy
[04:16] <baked> answered*
[04:17] <baked> sorry for the confusing response
[04:17] <ScottK> If the kernel has been built and released, you're running Gutsy, and your system is fully updated, you've got all there is.
[04:17] <baked> no daily builds or anything?
[04:17] <jdong> ScottK: are there any newer kernels that plan ot go into Gutsy at this point?
[04:18] <jdong> I'm pretty sure we're set in stone in that dept, right?
[04:18] <baked> wow, well a fixed bug is not fixed in that build :(
[04:18] <ScottK> There is one being built right now.
[04:18] <mjg59> No
[04:18] <jdong> oh hah, maybe I should check teh queue before opening my mouth.
[04:19] <baked> so there is no daily repo i can update from?
[04:19] <ScottK> jdong: Tough to do with the datacenter sitting in a black hole.
[04:19] <jdong> ScottK: indeed it is :D
[04:19] <ScottK> baked: When you run Gutsy, that's what you are doing.
[04:19] <mjg59> There's nothing relevant in gutsy
[04:19] <baked> ok
[04:19] <mjg59> baked: That specific bug was fixed. You have another bug with similar symptoms.
[04:19] <baked> no, i have that exact bug
[04:20] <baked> exact symptoms at least
[04:20] <ScottK> baked: mjg59 generally knows what he's talking about.
[04:20] <baked> its just hit or miss with booting right now
[04:20] <mjg59> No, you have a different bug with similar symptoms
[04:20] <mjg59> That bug was an issue with the amd driver
[04:21] <baked> well, i have looked this up a lot.  there are a lot of bugs in the system that are all related to the bug i said
[04:21] <baked> yea, i have nvidia mobo.  the bug was happening with fiesty as well
[04:21] <mjg59> Yes. It's a different bug.
[04:21] <baked> everything that people say in that bug report are exactly what i am expeierencing
[04:21] <mjg59> 106418 was fixed. Yours hasn't been.
[04:21] <baked> so is there a bug with the same issue on another driver?
[04:22] <mjg59> I can't tell right now, launchpad is inaccessible
[04:22] <mjg59> However, if it's not working for you with the current kernel in gutsy, then I'm afraid it's not going to be fixed before gutsy
[04:23] <baked> well sheit
[04:23] <baked> only thing left is to take out all these uuid's and boot off the parition itself
[04:23] <baked> sweet!
[04:24] <baked> is there a bug # with nvidia already?
[04:24] <baked> do you need any info from me to submit a bug / find one that I'm not seeing?
[04:25] <mjg59> If you can boot with explicit partition names but not with uuids, then it's *certainly* nothing to do with 106418
[04:25] <Burgundavia> ah crap, bloody dc being awol
[04:26] <mjg59> Anyway. I need to be in the lab in six hours.
[04:29] <ScottK> Data center is back for me.
[05:17] <slangasek> persia: which fixes?
[05:17] <ScottK> slangasek: They're all waiting to be accepted now.
[05:18] <persia> slangasek: duplicity, esniper, paketto, papaya, polyxmass-doc, quark, secvpn, and sqlfairy.  They've been pushed to unapproved since my earlier query.
[05:19] <sn0n> anyone else having problems with wine and sound??
[05:21] <slangasek> only when I drink too much of it
[05:21] <mjg59> slangasek: I've uploaded a gdm fix for 152505
[07:47] <pitti> Good morning
[07:48] <pitti> good morning slangasek
[07:55] <dholbach> good morning
[07:55] <pitti> hey dholbach
[07:55] <dholbach> hey pitti
[08:04] <bryce> hi guys
[08:05] <bryce> is there still time for additions to gutsy?  I have a fix for 127101 that is well tested, root-caused, passed upstream, verified, etc. and good to go
[08:05] <bryce> sorry I didn't get it in earlier; been at a customer site, but that gave plenty of extra time for testing
[08:05] <pitti> bryce: hi; yes, see slangasek's mail: fixes should be in by today 1200 UTC
[08:05] <bryce> cool
[08:06] <bryce> I may have one or two others; I need to check that they've gotten adequate testing
[08:07] <pitti> bryce: bug 151647 is milestoned for final; do you have an idea whether it'll get fixed?
[08:07] <ubotu> Launchpad bug 151647 in displayconfig-gtk "Cannot configure projector connected to laptop with Intel i915 (driver "i810") using displayconfig-gtk" [High,Confirmed]  https://launchpad.net/bugs/151647
[08:07] <bryce> huh, hadn't seen that one, didn't realize it got milestoned
[08:07] <pitti> well, it might have been done inappropriately
[08:07] <pitti> that's why I'm asking
[08:09] <bryce> ah, the reporter set it as milestoned
[08:10] <bryce> hmm, generally I don't like it when the reporter confirms their own bug and sets the priority and milestone for it
[08:11] <bryce> I don't mind it if they also propose a patch of course ;-)
[08:11] <pitti> bryce: so it's not a grave bug and it should be unmilestoned?
[08:11] <pitti> (it sounds like it, but checking; I just spotted it on the list)
[08:11] <bryce> pitti, right, it's not going to get fixed before 1200 utc
[08:11] <pitti> and there are probably also worse things to do by then
[08:12] <pitti> well, better things, worse bugs
[08:12] <bryce> I'm pretty certain this is a dupe of two other bugs we already know about
[08:13] <bryce> at this point, I have to restrict my focus not only to worse bugs, but to bugs that also have patches that have received sufficient testing that they're ready for upload
[08:40] <pitti> bryce: I unmilestoned above bug FYI
[08:43] <bryce> pitti: thanks
[08:49] <mdke> dholbach: around?
[08:50] <carlos> pitti: did I talk with you about the problem with kdevelop translations?
[08:50] <dholbach> mdke: yes
[08:50] <mdke> dholbach: good morning :)
[08:50] <dholbach> hi mdke
[08:50] <mdke> dholbach: I wanted to have a quick word about that ubuntu-docs upload
[08:51] <mdke> dholbach: bug 144796, my debdiff was different to yours, I don't know why
[08:51] <ubotu> Launchpad bug 144796 in ubuntu-docs ""Glossary of Windows terms" link doesn't work" [Medium,Confirmed]  https://launchpad.net/bugs/144796
[08:51] <dholbach> mdke: if you say that it's OK to upload the version that I checked out on friday, that's fine with me
[08:52] <mdke> i'm concerned about your debdiff, I don't think we should upload without figuring out what is up with that
[08:53] <dholbach> mdke: I'll do the following again: get the archive version and the svn version and re-try
[08:53] <mdke> dholbach: appreciate it. if you could compare the resulting debdiff with mine (attached to the bug) that would be great
[08:54] <dholbach> it'll either be your or my debdiff again, I think
[08:54] <pitti> carlos: not that I remember
[08:54] <mdke> fingers crossed :)
[08:55] <mdke> dholbach: the other thing was that it would be quite nice to do a gnome-user-docs upload; there are translation updates only, but quite important ones
[08:55] <carlos> pitti: kdevelop translations are in main (kde-i18n-*), but the template is in universe (kdevelop) so the .mo files are not installed as in other universe packages neither is part of language packs
[08:55] <carlos> pitti: I guess there are a couple of those in universe too
[08:55] <carlos> with the same problem
[08:56] <dholbach> hey lloydinho_!
[08:57] <soren> lloydinho_: Hey! Long time!
[08:57] <dholbach> how's it going?
[08:57] <lloydinho_> hey dholbach!
[08:57] <pitti> hi lloydinho_, how is it going?
[08:58] <lloydinho_> things are good. I've graduated
[08:58] <dholbach> rock on! :-)
[08:58] <lloydinho_> so now I'm looking for work instead. :-)
[08:58] <pitti> carlos: hm; I guess there is an existing special case for that in Rosetta already? I. e. not having the .po and .pot in the same package?
[08:58] <carlos> pitti: yeah
[08:58] <pitti> carlos: I don't think we can solve this with just component mangling; we can't promote everything to main
[08:59] <carlos> pitti: I only see two options
[08:59] <pitti> carlos: does Rosetta know which domains are affected by this/
[08:59] <pitti> ?
[09:00] <pitti> i. e. the one it imports from kde-i18n, but never get output?
[09:00] <carlos> pitti: 1. add a 'blacklist' to kde-i18n-* packages where you don't remove the .mo files in that blacklist
[09:01] <lloydinho_> oh, by the way. Soren: Congratulations, I hear you've got a job at Canonical now :-))
[09:01] <soren> lloydinho_: \o/ Yeah, since late May.
[09:01] <carlos> pitti: 2. Add a way to allow some universe packages translations and include them in main language packs
[09:01] <soren> lloydinho_: It's rocking!
[09:02] <carlos> pitti: we could get some information like that
[09:02] <dholbach> mdke: working on it
[09:02] <mdke> dholbach: thank you so much
[09:02] <pitti> carlos: 2 is more appealing IMHO
[09:02] <carlos> pitti: isn't that a problem that we include universe translations?
[09:03] <lloydinho_> soren:  Cool! I would have thought so, too! :-)
[09:03] <carlos> pitti: 2. is not a big problem for us because we need it anyway for packages that motu agreed on deploy the translations manually
[09:03] <carlos> pitti: well, there is a third option... implement the spec to add translation updates for Universe ....
[09:04] <carlos> pitti: but I guess that's more something to discuss at UDS
[09:04] <tbf> of course there are some traps, but could be a big timesafer when your link is slow in general - or as it happend to me suddenly drops from 180k to 50k
[09:04] <pitti> carlos: right, let's
[09:04] <carlos> pitti: as a workaround, I'm going to add the template manually, that will include the translations as part of next language pack update
[09:05] <carlos> pitti: btw, which package should I use for bugs in language packs packages that are global to all languages?
[09:05] <dholbach> mdke: uploading gnome-user-docs
[09:05] <carlos> pitti: do you have any metapackage I could use for it?
[09:05] <mdke> dholbach: thanks
[09:07] <pitti> carlos: please use the langpack-o-matic product
[09:08] <carlos> pitti: ok
[09:08] <pitti> https://bugs.launchpad.net/langpack-o-matic
[09:15] <dholbach> mdke: http://daniel.holba.ch/temp/docs.debdiff
[09:16] <mdke> dholbach: is it me, or is that even worse than the first one?
[09:16] <mdke> do you think these are permissions changing? how could our debdiffs be different if we are building the same package?
[09:16] <dholbach> mdke: that's the same as I posted before
[09:17] <dholbach> mdke: no I don't think it's permissions that change - do you build it on gutsy? with pbuilder?
[09:17] <dholbach> mdke: did you compare against the archive version?
[09:17] <mdke> dholbach: yes, no and yes
[09:18] <mdke> it really worries me because those are important files, and nothing has changed (in the source) to make them move
[09:18] <mdke> I think the cause must be in the symlink script somewhere though, because there are a lot of symlinks in there
[09:18] <dholbach> it seems there's always an instance of each of those important files around
[09:19] <mdke> yes, and symlinks to them in other places
[09:19] <dholbach> it just appears in different places (.3 vs .4) and if it's a symlink or the file itself
[09:20] <dholbach> mdke: it looks OK to me - I just can't tell you why it happens
[09:21] <mdke> dholbach: can you put the binary up and I'll give it a quick test; I suspect it's fine, as you say
[09:23] <dholbach> mdke: http://daniel.holba.ch/temp/
[09:24] <mdke> thanks
[09:24] <Burgundavia> well, I am off to bed
[09:24] <mdke> morning sabdfl
[09:25] <dholbach> hi sabdfl, asac
[09:27] <mdke> dholbach: I suspect what is happening is the symlink script is finding the same file installed in more than one place, and is choosing the opposite location to install and symlink from the one it chose in the last version...
[09:27] <mdke> nice motu pants btw
[09:27] <dholbach> haha :)
[09:28] <asac> hi dholbach  :)
[09:29] <sabdfl> howdy mdke, dholbach, how is everyone today?
[09:29] <dholbach> sabdfl: very good - how are you?
[09:30] <mdke> not bad thanks, for a Monday
[09:30] <dholbach> hehe :)
[09:32] <mdke> dholbach: the package works fine as far as I can see
[09:32] <dholbach> mdke: OK good
[09:32] <dholbach> mdke: I'll upload it then
[09:35] <mdke> dholbach: thanks, sorry for all the hassle you've had over that one
[09:36] <mdke> pitti: please could you email me if you need anything further to approve gnome-user-docs and ubuntu-docs packages which Daniel is uploading now, I have to disappear from irc now
[09:37] <pitti> mdke: will do
[09:37] <dholbach> mdke: don't worry
[09:37] <dholbach> have a nice day
[09:37] <rulus> hmm, seems like fglrx breaks suspend.. bug 140766
[09:37] <ubotu> Launchpad bug 140766 in linux-ubuntu-modules-2.6.22 "Suspend not working on Inspiron 6400 (gutsy)" [Undecided,New]  https://launchpad.net/bugs/140766
[09:38] <bryce> would someone be able to do two uploads for me?  http://people.ubuntu.com/~bryce/Uploads/
[09:38] <rulus> any chance fixing this for gutsy?
[09:38] <mdke> dholbach: you too
[09:38] <bryce> these fix two release critical bugs (127101 and 127008), and one other critical bug
[09:38] <dholbach> bryce: can do
[09:39] <bryce> dholbach: thanks
[09:39] <dholbach> hey Hobbsee
[09:40] <Hobbsee> hiya dholbach
[09:41] <dholbach> bryce: uploaded
[09:43] <bryce> dholbach: thanks
[10:11] <pitti> ah, so if all else fails, I found a first workaround for bug 64408; trying harder to actually fix it properly, though
[10:11] <ubotu> Launchpad bug 64408 in usplash-theme-ubuntu ""Urgent" text is poorly readable due to low contrast (blue on black)" [Medium,Confirmed]  https://launchpad.net/bugs/64408
[10:22] <ogra> slangasek, the g-p-m fix was for bug 150777 (there might be more that arent dulplicated ...)
[10:22] <ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,Confirmed]  https://launchpad.net/bugs/150777
[10:23] <ogra> pitti, ^^
[10:48] <sladen> pitti: from a through the code, the int used for fgcolour/bgcolour of text is expected for be in the native form (so 8bit for a 8bit  display, 24bits for a truelcolour)
[10:48] <sladen> pitti: so I suspect that the background "happens" to work as palette zero "happens" to be also 0x000000
[10:49] <pitti> slangasek: I'm currently debugging it
[10:49] <pitti> slangasek: I noticed that using gl_setpixelrgb() works, where as gl_setpixel() doesn't
[10:49] <pitti> erm, sladen ^, sorry
[10:50] <pitti> sladen: I think I just found a bug with passing the palette, digging further
[10:54] <pitti> sladen: a-ha; the libsvga palette is never initialized in the first place
[10:54] <pitti> slangasek: bpp is 16, and usplash_svga_set_palette() only calls gl_setpalettecolors() if bpp==8
[10:55] <sladen> interestingly, the blt is doing the indirection correctly
[10:55] <slangasek> ogra: I don't understand how this patch addresses the issue raised in that bug; the submitter's concern seems to be about having multiple controls that have to be changed to affect the behavior, not about what the default is?
[10:56] <pitti> slangasek: ooh
[10:56] <pitti> sladen, I mean
[10:56] <pitti> sladen: it seems that usplash is *actually* using 16 bpp?
[10:56] <ogra> slangasek, it fixes the locking by default for lid closing (which is a regression wrt feisty)
[10:57] <pitti> sladen: in this case, calling gl_setpixel with a palette index is utter bogus in the first place?
[10:57] <ogra> slangasek, the options the initial reporter changed have no effect oin that
[10:57] <pitti> sladen: it should rather get the rgb value from the image's palette and call gl_setpixelrgb then
[10:57] <ogra> slangasek, and the discussion that starts to the end of the bug is rather offtopic there (thats why i suggested a discussion)
[10:57] <ogra> (on the ML)
[10:58] <sladen> imbrandon: I suspect the orange is coming from  hex(0x1f << 11 | 0x38 << 5)  == 0xff00
[10:59] <sladen> pitti: ^
[10:59] <pitti> sladen: -theme-ubuntu wants palette index 117, which is actually that orangeish tone, so that might be
[11:00] <slangasek> ogra: it's a behavior change from feisty, but I don't see that it's a regression; locking on lid close seems an obviously correct default to me :)
[11:00] <slangasek> and again, it's not even the issue the submitter asked about
[11:00] <ogra> slangasek, a) i wouldnt like to change it withoiut prior discussion b) it exposes another bug where g-p-m interprets ac plughging as lid action
[11:01] <sladen> pitti: another question is /why/ a 16-bit mode is being chosen
[11:01] <slangasek> ogra: but hasn't the current behavior now been the default for most of the gutsy cycle?  AFAICS, this upload /is/ changing it without prior discussion
[11:01] <ogra> (and c) i dont want to have to login every 10 mins on conbferences where i open/clise my lid quite often :P)
[11:02] <ogra> slangasek, no it hasnt
[11:02] <sladen> pitti: one way to prove this is to use an image with pixels that are 1/256th different in value.  Then screenshot the result from virtual box on a 24-bit display
[11:02] <ogra> upstreamm changed all gconf paths very late in the cycle
[11:02] <pitti>                 mode = vga_setmode(svgalib_mode);
[11:02] <pitti> [...] 
[11:02] <sladen> pitti: if the two pixels have been rounded in value, then it's running on a the 16bit mode
[11:02] <pitti>                         if (mode != svgalib_mode)
[11:02] <pitti>                                 bpp = 16;
[11:02] <pitti>                         else
[11:02] <pitti>                                 bpp = 8;
[11:02] <pitti>                         return mode;
[11:03] <bryce> slangasek, pitti:  I don't know if you've had a chance to review my two uploads, but if so, note we have an update for 127008 (xresprobe_0.4.24ubuntu8)
[11:03] <pitti> it's trying to set mode 11, and does set mode 21
[11:03] <ogra> slangasek, there were none of our custom options applied for quite some time
[11:03] <pitti> bryce: slangasek is doing reviews ATM, I don't want to disrupt his workflow unless he asks me to
[11:03] <bryce> alrighty
[11:04] <slangasek> pitti: feel free to take xresprobe so I can get to bed sooner :)
[11:04] <ogra> slangasek, anyaway, either we go with screen locking on every brightness change and AC plugging (plus locking on lid close) or we get that patch in
[11:04] <pitti> slangasek: taking then
[11:04] <davmor2> bryce: bug 151311 with you on that one no point fixing one card to break others :)
[11:04] <ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DPI in kubuntu incorrect on xorg-video-driver-intel" [High,In progress]  https://launchpad.net/bugs/151311
[11:04] <slangasek> ogra: um, ok; where's /that/ bug then, that's clearly not bug #150777 and is also not mentioned in the changelog of the upload
[11:04] <ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,Confirmed]  https://launchpad.net/bugs/150777
[11:05] <pitti> bryce: ah, makes sense; accepting
[11:06] <bryce> davmor2: yeah.  Also, that's the type of fix that's fine to roll out later if it's critical enough; the xresprobe fixes however kick in at install time so are more important to get on the CD.
[11:06] <davmor2> bryce: will it be listed as a know bug though?  In which case we could still use your temp fix for people who have issues
[11:07] <pitti> slangasek: taking ubuntu-meta, too
[11:07] <slangasek> pitti: cheers
[11:07] <bryce> davmor2: not sure - that's only going to be an issue for kubuntu (and xubuntu maybe?) as far as I know, so probably should be listed only on those release notes.  Would you mind checking into that?  Meanwhile this next week I'll look into a stronger fix.
[11:07] <ogra> slangasek, i'll open one if you need it i discovered it during RC testing and didnt file it yet
[11:08] <pitti> slangasek: and ubuntu-docs, if you don't mind
[11:08] <ogra> (the stuff with the AC plugging/brightness changes i mean)
[11:08] <mjg59> ogra: I don't see screen locking on brightness changes
[11:08] <slangasek> ogra: it should be opened regardless so that the relevant folks can look at the root issue, yes
[11:09] <ogra> mjg59, with the latest g-p-m ?
[11:09] <slangasek> likewise, I don't get any screenlocking here on brightness changes
[11:09] <ogra> mjg59, how about AC unpliggin
[11:09] <ogra> *unplugging
[11:09] <slangasek> I do get screenlocking when I close the lid, and I most definitely want that and am surprised that anyone wouldn't :)
[11:09] <ogra> slangasek, well, we never had it on
[11:09] <mjg59> ogra: Nope
[11:10] <mjg59> All seems to work fine here
[11:10] <ogra> i'm not opposed to switch, but want a say from the right folks
[11:10] <slangasek> ogra: by a conscious modification of the upstream policy, you're saying, rather than just as a result of what upstream was doing?
[11:10] <sladen> pitti: where were you getting the  mode 21 from, from the stderr output?
[11:10] <pitti> sladen: yes, I added a few fprintf()s :)
[11:11] <ogra> slangasek, we always had our own gconf defaults for g-p-m ... mainly for lock policy which was decided in edgy and surely could need some makeover
[11:11] <davmor2> bryce: np I will be test most of the distros over the next couple of days so I will report to the bug exactly which distro's are effected.  If memory server though the login screens of all the desktops are effected until your patch is applied, and only ub/edu are fixed at this point.
[11:11] <ogra> same goes for gnoime-screensaver
[11:12] <slangasek> I see that 2.20 was uploaded mid-September, so it appears the current behavior was the behavior present in beta and RC, and no one else has complained; so either way, final will be a "regression" against one of RC or feisty
[11:12] <bryce> davmor2: cool thanks
[11:13] <ogra> slangasek, well, if neither mjg59 nor you see anything like i see i'm suspecting there is something wrong on my side (even i tested on two different laptops)
[11:14] <sladen> pitti: so mode-selecting loop tries to find the first that is "big enough"  then the setting loop counts backwards and finds the biggest that actually succeeds.
[11:15] <ogra> i'm not happy leaving lock on lid close on, but thats not as bad as having the lock in your face on state changes ....
[11:15] <ogra> so reject please ...
[11:16] <slangasek> ogra: are you sure? :)  It's not my place to be setting policy for this stuff either; if the pre-existing policy was to not lock on lid close, I'm willing to accept if you tell me that's the right thing here
[11:16] <pitti> sladen: ok, I got a patch now \o/
[11:19] <ogra> slangasek, well, its the right thing *imho* but the patch was mainly driven by the sideeffects it fixed in my view ...
[11:20] <ogra> i usually care more for the experience of users that upgrade their stable release than about changes for testers so i try to keep the releases in sync ...
[11:20] <pitti> sladen: I'll apply http://paste.ubuntu.com/928/ now to fix the usplash text color, unless you have an objection or another idea?
[11:21] <bryce> pitti, there is also an uploaded xserver-xorg-video-intel_2.1.1-0ubuntu9 that I think is still pending review.  The bug report is huge, but the fix fairly modest; I'd love seeing it approved before I head to bed.
[11:21] <pitti> sladen: I think this fix is correct anyway; it might be another bug that we don't use 8bpp, but that's independent then
[11:21] <pitti> bryce: ok, I'll check it
[11:21] <slangasek> ogra: sure, and that's persuasive to me.  I still think not locking on lid close is a wrong default, but I'm happy to argue that for hardy :)
[11:21] <slangasek> so - accepted
[11:21] <ogra> slangasek, the discussion on ubuntu-devel-discuss has started ;)
[11:22] <slangasek> hmm, maybe I should subscribe then
[11:22] <ogra> i'm fine to use whatever gets decided (i know how to change my personal settings so for me it doesnt matter ... it does for my mother though)
[11:23] <sladen> pitti: patch looks sane to cover for the moment
[11:23] <ogra> imho passwords are the worst usabilty experience you can give a user so i like to avoid prompts for them where i can :)
[11:23] <sladen> pitti: and the 16-bit individual setpixels explain why it's slow
[11:24] <ogra> (while still keeping security at a moderate level indeed)
[11:24] <pitti> sladen: right; that's harder and more intrusive to fix, though (not to mention that it needs a lot of testing, etc.)
[11:24] <ogra> slangasek, thanks :)
[11:24] <slangasek> ogra: I think having my data compromised because my laptop didn't lock properly is a worse user experience. ;)
[11:26] <ogra> slangasek, ah, well, i'm fine to hit the lock screen button i have in my panel for that :) its one click more and i doint have to type my bassword on every relocation ...
[11:26] <slangasek> right, give me a lock screen button by default then >:)
[11:26] <ogra> but thats as subjective as it can be :)
[11:28] <ogra> we had one for ages ... but when it moved to the logout dialog it was decided that we only need it once so the default panel item was dropped
[11:34] <bryce> 'night
[11:34] <pitti> bryce: looking ATM, but looks good so far
[11:34] <bryce> cool, I'll check back in the morning.
[11:34] <pitti> accepting
[11:35] <pitti> bryce: please do test it properly, though, since this bears the potential for hw regression, etc.
[11:44] <seb128> pitti: did you read the tracker bugfixes mail? Do you think there is anything there worthwhile for gutsy now?
[11:44] <pitti> seb128: I saw it, but no time yet to read the patch; did you?
[11:45] <pitti> seb128: if there are important and simple patches, we can still shove it in; but anything that's not 100% foolproof should be moved to SRU
[11:47] <seb128> pitti: there is several fixes and quite some code lines changed, I don't think it makes sense to accept the whole, I'll look if there is some small fixes we would like to use now
[11:48] <pitti> seb128: thanks
[11:48] <pitti> seb128: if some patches fix initial db building, it's worth taking a look at least
[11:49] <pitti> seb128: simple crashes etc. could be fixed in a SRU (stuff that doesn't corrupt the DB), if they are nontrivial
[11:49] <pitti> likewise optimization stuff
[11:50] <MacSlow> mvo, is there a bug-entry regarding the behaviour of the custom-effects-level radio-button and the properties-button for ccsm in the "Visual Effects"-tab in gnome-control-center?
[11:51] <MacSlow> just asking for the changelog
[11:51] <mvo> MacSlow: I don't think so, feel free to create one
[11:51] <MacSlow> mvo, I assume that's the prefered procedure?
[11:51] <mvo> MacSlow: yes, at this point at least
[11:52] <mvo> MacSlow: not during normal development of course (when we are not in sub-zero -final preparations)
[11:52] <MacSlow> mvo, feels a bit odd though... creating a bug-entry for something that's just getting fixed by yourself.
[11:56] <Riddell> bryce: so that intel issue davmor2 has isn't being fixed?
[12:34] <mjg59> sladen: pitti : The reason for preferring 16-bit is that some modern cards don't seem to support the clut registers in 8-bit vesa modes any more
[12:34] <pitti> mjg59: ah, so that's actually deliberate; then it seems to me that all is well now?
[12:35] <pitti> well, we might consider using a brighter color for urgent text, but the orange isn't too bad IMHO
[12:35] <ogra> seb128, any idea about bug 152577 ? i have no clue why its doing that ...
[12:35] <ubotu> Launchpad bug 152577 in gdm "call to gdmflexiserver in /etc/gdm/PreSession/Default causes gtk setuid warning" [Medium,Confirmed]  https://launchpad.net/bugs/152577
[12:35] <ogra> its not accessing any suid program and isnt suid itself either
[12:42] <mjg59> 16 bit is definitely deliberate, yes
[12:42] <mjg59> As long as you're getting orange rather than blue now, it all sounds good
[12:43] <pitti> mjg59: yep; I fixed usplash to take the actual color set in the theme, instead of a (pretty much) random one
[12:44] <mjg59> pitti: Ha. Where was it doing that?
[12:45] <pitti> mjg59: http://codebrowse.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/revision/167
[12:45] <mjg59> Ah, I see
[12:51] <StevenK> pitti: If you have a sec, NBS looks like some -12 packages are still hanging around, along with virtualbox-ose-modules-*-13-*
[12:55] <seb128> ogra: that's nothing new and a duplicate
[12:56] <seb128> ogra: gtk doesn't like to run as setuid, gdmflexiserver used to not call gtk_init but it doesn't now
[12:56] <seb128> ogra: is that an issue for you out of the warnings?
[12:57] <ogra> seb128, not at all
[12:58] <ogra> i just saw several users complaining on the weekend and looked into
[12:58] <ogra> it
[12:58] <pitti> StevenK: will do
[12:58] <seb128> why do they complain?
[12:58] <ogra> because they see errors in their logs :)
[12:58] <seb128> that's nothing new and should not be user visible
[12:58] <seb128> bah
[12:58] <ogra> well, its short before release, users look at such stuff :)
[12:59] <seb128> they should better look at what doesn't work ;)
[12:59] <ogra> what i doint get is that gdmflexiserver isnt setuid at all here
[01:00] <ogra> so i dont understand why gtk complains
[01:00] <seb128> ogra: gdm is running as root and the code is doing setuid() calls
[01:01] <ogra> ah
[01:01] <ogra> now it all falls into place :)
[01:04] <soren> You're out of order, xresprobe! https://edge.launchpad.net/ubuntu/+source/xresprobe  :)
[01:05] <pitti> StevenK: done, thanks for the ping
[01:05] <StevenK> pitti: No problem.
[01:05] <StevenK> pitti: I just remember you saying we shouldn't release with NBS stuff.
[01:05] <pitti> right
[01:05] <StevenK> ... so maybe that should be added to the Release page on the wiki ...
[01:06] <StevenK> If I could remember its title.
[01:06] <pitti> https://wiki.ubuntu.com/ReleaseChecklist ?
[01:07] <StevenK> Hrm. There was one I was reading last night.
[01:08] <Hobbsee> StevenK: was that ReleaseCandidateChecklist?
[01:08] <pitti> StevenK: maybe https://wiki.ubuntu.com/ReleaseCandidateProcess or https://wiki.ubuntu.com/ReleaseProcess ?
[01:08] <StevenK> I think the last one.
[01:08] <Hobbsee> StevenK: it could be the non-sanitized canonical versions, too, perhaps?
[01:08] <StevenK> Yeah, ReleaseProcess is it
[01:08] <pitti> Hobbsee: they are gone (entirely moved)
[01:09] <Hobbsee> oh nice!
[01:09] <ogra> "non-sanitized canonical"
[01:09] <Hobbsee> i thought they were just copied
[01:09] <ogra> hey, we're not *that* insane
[01:10] <StevenK> pitti: Hrm. I don't feel entirely comfortable editing ReleaseProcess, do you think a note in Release minus 1 day would be okay?
[01:11] <Hobbsee> ogra: you sure? there was talk of it needing to be sanitized before it could be made public.
[01:11] <pitti> StevenK: oh, please do add it there (to release - 3 days or so
[01:14] <StevenK> pitti: Done.
[01:14] <StevenK> Well, done when wiki.u.c comes back to me. :-)
[01:16] <Keybuk> hah, what a surprise ... "we tested your line, and can't find any problem" ... and it's magically working again
[01:16] <Keybuk> (well, ish; 12s lag)
[01:16] <StevenK> Keybuk: Sounds like Telstra.
[01:16] <StevenK> Keybuk: You're sure you haven't moved over here? :-P
[01:17] <TheMuso> Is the archive frozen yet, including for universe?
[01:18] <mjg59> We've been frozen for some time
[01:18] <mjg59> Uploads may still get in at the release team's discretion
[01:18] <TheMuso> right. nvm then
[01:22] <RicardoPerez> seb128: hi! i'm the user with the "Loading" bug
[01:22] <RicardoPerez> seb128: and yes, i'm using the Human theme, which it's the default one in Gutsy, don't it?
[01:27] <seb128> RicardoPerez: right
[01:27] <seb128> RicardoPerez: I've no idea what's creating the issue for you then
[01:27] <RicardoPerez> seb128: there's a difference between my configuration and the one for a new user, but I don't know what is...
[01:31] <RicardoPerez> seb128: is there any other dot file that I can remove aside from the .gtkrc*?
[01:43] <seb128> RicardoPerez: you can try moving things around until finding what creates the issue, could be a local font or configuration also
[01:51] <Keybuk> wow, that solves that bug
[01:51] <seb128> Keybuk: ?
[01:51] <Keybuk> for ages, I've been shutting the lid of my laptop, unplugging it, bringing it downstairs, and then plugging it in again and opening it up to find that it has suspended
[01:52] <Keybuk> which baffled me because my on ac power setting was to just blank screen
[01:52] <Keybuk> of course, it went to battery while the lid is shut ... but g-p-m isn't checking for the lid shut event, it's checking for the "lid is shut and on battery" state
[01:52] <Keybuk> so suspends while I'm walking down the stairs
[02:00] <ogra> sigh ... todays upgrade takes ages ...
[02:01] <ogra> hmm, might be because oo.o comes down the drain ...
[02:01] <StevenK> ogra: oo.o clogs it? :-P
[02:02] <ogra> yeah :)
[02:06] <RicardoPerez> seb128: it's a .gconf problem
[02:06] <Hobbsee> ogra: news at 11.
[02:06] <RicardoPerez> seb128: I move my .gconf dir away, and now the problem is gone
[02:07] <seb128> RicardoPerez: fonts and themes are configured there
[02:07] <seb128> RicardoPerez: you should move it back because there is evolution account settings, etc there
[02:07] <RicardoPerez> seb128: yes... now I'm using 10 pt. fonts, instead of my preferred 11 pt. fonts
[02:07] <seb128> RicardoPerez: I doubt the font size is creating that issue
[02:08] <RicardoPerez> seb128: mmmm... maybe I try to deep into the .gconf dir?
[02:08] <seb128> RicardoPerez: yes
[02:08] <RicardoPerez> seb128: ok, i'll try :) thanks :)
[02:08] <seb128> RicardoPerez: you're welcome
[02:12] <StevenK> pitti, slangasek: Will you hate me if I upload virtualbox-ose-modules in a few minutes?
[02:13] <Hobbsee> StevenK: no
[02:13] <Hobbsee> StevenK: mine's still later
[02:13] <pitti> StevenK: no, fine for me; I'm mostly concerned about packages going on the CDs
[02:14] <Hobbsee> pitti: i warn you now, i have one of them
[02:16] <StevenK> pitti: Okay, I'll ping you when I've thrown it up (!), if you don't mind.
[02:16] <pitti> please
[02:17] <StevenK> Just testing the thing.
[02:20] <RicardoPerez> seb128: the problem was in the .gconf/desktop/gnome/font_rendering subdir
[02:20] <RicardoPerez> seb128: I removed it and now the problem is gone
[02:20] <seb128> RicardoPerez: ah ok
[02:21] <seb128> RicardoPerez: so it's due to the font configuration (antialiasing, etc)
[02:21] <RicardoPerez> seb128: yes :)
[02:21] <seb128> RicardoPerez: what option did you use?
[02:22] <RicardoPerez> Subpixel - VRGB
[02:22] <StevenK> pitti: Sigh. And another virtualbox-ose upload.
[02:23] <RicardoPerez> seb128: maybe I must to tag the bugreport as "invalid"?
[02:35] <StevenK> pitti: virtualbox-ose{,-modules} uploaded.
[02:35] <pitti> checking
[02:36] <pitti> StevenK: so the modules packages have a Provides: virtualbox-ose-modules?
[02:36] <pitti> StevenK: but Recommends: sounds fine to me; after all, people might prefer building it from upstream for whatever reason?
[02:37] <StevenK> pitti: Yes, they do. However, people are still filing bugs saying it needs to be Depends. :-(
[02:37] <pitti> hm, *shrug*
[02:37] <pitti> eww @ killall -q VBoxSVC; no pid file?
[02:38] <pitti> oh, this is the application?
[02:39] <StevenK> Yup
[02:39] <pitti> StevenK: shouldn't this kill disappear altogether?
[02:39] <pitti> StevenK: if you uninstall -modules from a chroot, this would kill your outside app, etc.
[02:39] <ogra> especially it shouldnt use killall, no ?
[02:39] <pitti> that too
[02:40] <StevenK> Hrm.
[02:42] <StevenK> Let's see. We don't really need to stop it since you're going to reboot anyway, and removing the module and killing Virtualbox on upgrades is BAD
[02:42] <pitti> StevenK: I still think the depends: is a bit overenthusiastic; people who run an upstream kernel etc. can't install it, and aptitude/synaptic etc. install recommends by default, right?
[02:42] <pitti> right
[02:42] <StevenK> pitti: Reject -modules, I'll upload a new 5 with an empty stop
[02:43] <pitti> done
[02:43] <StevenK> pitti: I've been told Synaptic doesn't do Recommends by default
[02:43] <pitti> mvo: ^ oh, I thought all packaging tools do now, except apt-get?
[02:43] <Hobbsee> StevenK: synaptic behaves like apt, yes.
[02:44] <Hobbsee> as does adept
[02:44] <pitti> hmm
[02:45] <Hobbsee> pitti: dunno where you got that info from - afaik, only aptitude does for all packages.
[02:45] <pitti> hm, I have operated under false assumptions in the last few releases then
[02:45] <pitti> ogra: right, but the default matters
[02:46] <ogra> pitti, well, the default nerver installed recommends in apt ...
[02:46] <Hobbsee> ogra: --enable-recommends
[02:46] <pitti> right
[02:46] <mvo> pitti: sorry, the default behavior for apt (and synaptic/adept) is currently to only install recommends for secrion: metapcakges
[02:46] <pitti> but I thought synaptic/aptitude/etc. did
[02:46] <mvo> metapackages even
[02:46] <pitti> aah
[02:46] <mvo> pitti: yes, for metapackages, but not for others. but this is changeing soon in debian
[02:46] <StevenK> And virtualbox-ose is no metapackage
[02:47] <StevenK> pitti: Changed -modules uploaded
[02:48] <StevenK> Doh!
[02:48] <pitti> StevenK: ok, then let's do that depends: thing
[02:48] <StevenK> I left my WoW character on the boat long enough that I've done a round trip
[02:48] <StevenK> pitti: Right.
[02:52] <pitti> StevenK: much better, thnaks
[02:53] <StevenK> pitti: Great
[02:59] <pitti> our buildd farm is KDE'ed and OO.o'ed, so no new uploads please
[03:00] <ogra> pitti, eclipse is broken i heard :P
[03:01] <ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [Undecided,New]  https://launchpad.net/bugs/152113
[03:04] <pitti> Spads: smells like the first Gutsy SRU (as well as all other stables, of course) :)
[03:05] <pitti> uh, that looks weird
[03:07] <Spads> pitti: so everyone's clock is wrong until then?
[03:11] <pitti> Spads: I'll try to do dapper/edgy/feisty ASAP
[03:11] <Spads> pitti: thanks
[03:12] <pitti> thanks for the reminder
[03:12] <mvo> iwj: could you please have a look at bug #152813 ? it seems like dpkg is complaining about libpam-runtime not configured yet, however it seems to be configured a few lines above (in the log)
[03:12] <ubotu> Launchpad bug 152813 in update-manager "Update from Feisty to Gusty fails in multiple packages" [Undecided,New]  https://launchpad.net/bugs/152813
[03:13] <Hobbsee> we're referring to our tribes, etc as alpha releases now?
[03:14] <Hobbsee> i dont remember what mdz said
[03:14] <liw> Hobbsee, that's what I was told, at least from gutsy+1 onward
[03:14] <Hobbsee> ah yes, we do.  yay for keeping email.
[03:15] <liw> a filter rule for automatic archiving + easy and fastish searching in Evolution made my life *so* much better a few years ago
[03:15] <mdz> Hobbsee: yes
[03:16] <Hobbsee> mdz: thanks
[03:20] <pitti> Keybuk: can you please approve the dapper task in bug 152113? (yay LP inconsistencies)
[03:20] <ubotu> Launchpad bug 152113 in tzdata "Brazilian DST date change needs upgrade to 2007h" [High,In progress]  https://launchpad.net/bugs/152113
[03:22] <pitti> doko: darn, OO.o/sparc FTBFSed
[03:22] <Kopfgeldjaeger> hi
[03:22] <pitti> doko: gcc ICE :(
[03:23] <Keybuk> pitti: done
[03:23] <pitti> Keybuk: thanks
[03:23] <doko> pitti: I'll give it back, ok?
[03:24] <pitti> doko: why should that help? it already built on artigas?
[03:25] <doko> pitti: do you have a btter idea? give it back on sejong? I can build it on a t1000, but that won't help us here ...
[03:25] <pitti> doko: I don't know how to fix it, but it has failed with an ICE on the buildds often enough to exclude the chance of a random glitch
[03:26] <pitti> doko: binary uploads FTW :)
[03:27] <doko> pitti: make it reproducible ... I'll ask for the b-d's on faure
[03:28] <Hobbsee> !lts
[03:28] <ubotu> LTS means Long Term Support. LTS versions of Ubuntu will be supported for 3 years on the desktop, and 5 years on the server.
[03:28] <Hobbsee> long term.  right.
[03:29] <bddebian> Heya
[03:43] <soren> Hobbsee: hm?
[03:44] <Hobbsee> soren: hm w.r.t. what?
[03:44] <soren> "long term.  right."
[03:44] <soren> My jedi senses detect sarcasm.
[03:45] <Hobbsee> soren: i wasnt sure if it was long term, or l<something else, which i've now forgotten> term.
[03:45] <Hobbsee> and thought i should get it right, for this.
[03:46] <soren> Hobbsee: Oh, ok.
[03:46] <soren> Hi, mathiaz!
[03:46] <mathiaz> hi soren
[03:47] <mathiaz> soren: did you get a chance to sponsor my dovecot upload ?
[03:47] <soren> mathiaz: No, I'm afraid I didn't.
[03:48] <mathiaz> soren: Is it too late to get it for release ?
[03:48] <Hobbsee> mathiaz: archive isnt frozen yet, but will be RSN.
[03:49] <soren> mathiaz: Easy answer: yes. Slightly more difficult answer (for you): If you sweet talk an rm to allow it, I'll be happy to upload.
[03:50] <Hobbsee> chocolate accepted.
[03:50] <Hobbsee> bribes accepted.
[03:50] <persia> Hobbsee: How much?  I want to upload aolserver4.
[03:51] <Hobbsee> persia: more than you can afford, if it contains the string "aol"
[03:51] <soren> aolserver... Is that as evil as it sounds?
[03:51] <persia> soren: Yes.
[03:51] <soren> Thought so.
[03:51] <zul> soren: worse
[03:51] <Hobbsee> *much* more.
[03:51] <zul> it eats newborns
[03:51] <persia> Hobbsee: But it fixes a FTBFS, and allows removal of libssl0.9.7.
[03:51] <mathiaz> hum... It fixes some postinst issues - dovecot is not restarted when installing the imapd or pop3d package, but is configured properly.
[03:52] <mathiaz> soren: everything is on http://people.ubuntu.com/~mathiaz/packages/
[03:52] <Hobbsee> persia: oh ewww, it's already in here.
[03:52] <persia> Hobbsee: Yep.  And the ldconfig trigger switch broke it :)
[03:52] <Hobbsee> persia: do i want the diff?
[03:52] <persia> Hobbsee: http://launchpadlibrarian.net/10008813/aolserver4_4.5.0-10ubuntu2.debdiff
[03:52] <Chipzz> ogra: here?
[03:53] <Hobbsee> persia: bonus points if you do the removal request
[03:53] <persia> Removal of which?
[03:53] <Hobbsee> aol*
[03:53] <Hobbsee> persia: looks fine.
[03:53] <Hobbsee> hang on, hwo does that FTBFS?
[03:53] <Hobbsee> that's a postinst?  how does that fail to build?
[03:54] <soren> Hobbsee: You're confusing mathiaz and persia now..
[03:54] <mathiaz> Hobbsee, pitti: any chance to get my dovecot upload/request accepted ?
[03:54] <mathiaz> Hobbsee, pitti: soren had a look at it on friday and agreed to upload it if allowed.
[03:54] <Hobbsee> soren: am i?
[03:54] <pitti> mathiaz: see above; buildds are currently clogged, so it'll take a while; I'm happy to review it, though
[03:55] <mathiaz> pitti: it'S on http://people.ubuntu.com/~mathiaz/packages/
[03:55] <pitti> mathiaz: please put a debdiff there, too
[03:55] <persia> Hobbsee: It breaks the aolserver4-nsimap build: http://launchpadlibrarian.net/8094737/buildlog_ubuntu-gutsy-amd64.aolserver4-nsimap_3.2.3-1_FAILEDTOBUILD.txt.gz
[03:55] <mathiaz> pitti: yes. That's what I'm preparing right now.
[03:56] <soren> Hobbsee: Yes. Mathiaz is the one speaking about postinst.
[03:56] <Hobbsee> persia: oh yes, i see.  ack'd.
[03:56] <Hobbsee> soren: the debdiff for persia's mainly contains a postinst.
[03:56] <Hobbsee> soren: that, and a changelog entry
[03:57] <soren> Hobbsee: Oh.
[03:57] <soren> Hobbsee: My bad.
[03:57] <Hobbsee> soren: :)
[03:57] <Hobbsee> soren: i didnt think i was going mad
[03:57] <persia> Hobbsee: Thanks.  sent.
[03:57] <StevenK> Hobbsee: But you are. So there.
[03:57] <StevenK> Ouch!
[04:00] <mathiaz> pitti: http://people.ubuntu.com/~mathiaz/packages/dovecot_1.0.5-1ubuntu2.debdiff
[04:03] <pitti> mathiaz: looks good; if you tested all cases, please go ahead and get it uploaded
[04:03] <mathiaz> soren: ^^
[04:03] <mathiaz> pitti: thanks.
[04:03] <StevenK> Oh, grumble.
[04:03] <soren> done
[04:04] <soren> Thanks!
[04:04] <StevenK> pitti: One more, with feeling. -modules didn't contain a #DEBHELPER# in the postinst.
[04:05] <pitti> persia: if you are touching aolserver4 anyway, any chance you could include a fix for http://launchpadlibrarian.net/7541603/buildlog_ubuntu-gutsy-amd64.aolserver4-nsimap_3.1-3build3_FAILEDTOBUILD.txt.gz ?
[04:06] <persia> pitti: The upload for aolserver4 fixes that for me.  It just needs to build first, and then aolserver4-nsimap can build, and then libssl0.9.7 can be purged.
[04:06] <pitti> persia: ah, great; cjwatson proposed to fix the prctl() call
 arg2 to prctl is an unsigned long but prctl is varargs; perhaps:
 -    if (prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) < 0) {
 +    if (prctl(PR_SET_DUMPABLE, 1L, 0L, 0L, 0L) < 0) {
[04:06] <persia> pitti: That is probably a better long-term solution.  For now, I just overrode the ldconfig trigger processing to let the libraries be loaded.
[04:07] <persia> In Debian, they split the package into aolserver4-core (the libraries) and aolserver4 (the daemon), so it will be slightly more sane for hardy.
[04:07] <pitti> persia: why 'long-term'? if that fixes it as well, it seems more adequate to me than hacking around the problem and hoping that it works? (I might have misunderstood the problem, of course)
[04:08] <pitti> persia: ah, not instlaling the server as a build-dep in the first place? I agree, that's better
[04:09] <persia> pitti: Two different issues.  One is that the daemon can't run because it can't find it's libraries.  The other that the daemon isn't written to be portable.
[04:09] <persia> (unless we're looking at different FTBFS's)
[04:10] <persia> Nevermind.  We might be looking at different issues.  I wonder why it worked the way it did for me (or is stderr just odd in the LP output?)
[04:11] <pitti> persia: no, it's the very same you should see in the build log and on your screen
[04:11] <pitti> persia: the one at my URL only happens on amd64
[04:11] <pitti> due to sizeof(long int) != sizeof(int)
[04:11] <persia> pitti: I'm using an AMD64 for this :)
[04:11] <pitti> ok
[04:12] <pitti> persia: so, if that FTBFS was on our radar and this upload fixes it, all is well; I just thought I'd check before building it twice :)
[04:12] <StevenK> pitti: -modules 6 uploaded, review at your leisure.
[04:13] <persia> pitti: I'm glad you checked.  I'm seeing http://paste.ubuntu-nl.org/40704/ in a local build log, which matches the Debian report, but shows some extra characters when compared to the LP report.
[04:14] <mvo> mathiaz: hello! I got this here http://paste.ubuntu.com/934/ during a server upgrade test. the release-upgrader overwrites invoke-rc.d failure to be not fatal, but with a regular upgrade, people will get bitten by this. could you please check?
[04:14] <mvo> mathiaz: I'm happy to provide full logs+typescript
[04:14] <soren> pitti: Oh, thanks for doing the linux-meta stuff for -virtual. It slipped my mind somehow.
[04:15] <pitti> soren: you're welcome
[04:15] <mathiaz> mvo: I'll have a look a bit later. Is it urgent ?
[04:15] <Hobbsee> mvo: a question for the dist-upgrader - if the line in the sources list cant be read, why does the updater not comment it out and go on, rather than bailing out with an error?
[04:15] <mvo> mathiaz: no, just FYI (shouldn't be a big issue for all who use the release-upgrader)
[04:15] <ogra> Chipzz, ?
[04:16] <soren> mvo: What is your upgrade test stuff running on?
[04:17] <mvo> Hobbsee: because its silly. seriously, because the line may be important, if e.g. the user accidently put "debx http://country.a.u.c/ubuntu universe", then this may lead to a disabled universe. I agree that the error is pretty bad though
[04:18] <mvo> soren: it runs in a VM somewhere in the DC, I don't even know, I do not have direct access. but this particular problem I found during some mnual testing
[04:18] <Hobbsee> mvo: i'm surprised that the lines for their normal archives dont get added though.  what happens in the case where i'm onlyusing a pacificnet mirror, and nothing with archive.ubuntu.com in it?
[04:18] <soren> mvo: Oh, ok.
[04:18] <soren> mathiaz: Ah, I think I see what's going on.
[04:19] <mvo> Hobbsee: if it is a mirror that it knows, it will be happy. it has a mirror list from LP
[04:19] <soren> mathiaz: After upgrading the new kernel is installed, but not running, so we can't load the apparmour modules.
[04:19] <Hobbsee> mvo: my pacificnet mirror is not picked up.
[04:19] <mvo> Hobbsee: is there a particular bug you are refering to?
[04:19] <mathiaz> soren: yes.
[04:19] <soren> mathiaz: Because they don't exist for the running kernel.
[04:19] <Hobbsee> mvo: it's not listed on the official lot of mirrors
[04:20] <mathiaz> soren: it should be taken care of in the postinst script.
[04:20] <Hobbsee> mvo: just something i saw a few days back, and thought looked odd - but i'm unconvinced about the mirror checking anwyay (and mean to file a bug abotu it)
[04:20] <mvo> Hobbsee: hrm, what should happen in this case is, that it should ask you about it. something like "I can't find a mirror, I'm desperate, should I add one for you or just go ahead"
[04:20] <Hobbsee> mvo: that'd be good.
[04:20] <mathiaz> soren: in apparmor.postinst: invoke-rc.d apparmor start || true
[04:20] <mvo> Hobbsee: that is the behavior that it *should* have (unless there is a bug of course)
[04:21] <Hobbsee> mvo: (our au.archive.ubuntu.com absolutely *sucks*, so most people dont use it)
[04:21] <soren> mathiaz: How would that fix anything?
[04:21] <Hobbsee> mvo: ah right.  i have both lots enabled, so i dont come up against it
[04:21] <mathiaz> soren: the package upgrade won't fail.
[04:21] <mathiaz> soren: you still get the warning messages, but the upgrade won't fail.
[04:21] <soren> mathiaz: Ah, right. (/me is trying to do many things at once, apparantly)
[04:22] <mvo> Hobbsee: I'm happy to talk to you about improving the mirror handling, but if its not a bug, I would prefer doing that post-release (or at UDS) :)
[04:22] <mvo> upgrade-not-fail++
[04:22] <mvo> maintainer-script-failure: BAD
[04:22] <Hobbsee> mvo: i wont be at boston.  in the next one, though...
[04:22] <Hobbsee> mvo: i will if i get sponsored
[04:23] <mvo> Hobbsee: oh, a shame :/
[04:23] <persia> pitti: I've just done some more testing, and the version I uploaded isn't generating any strange characters on installation, and appears to work successfully.
[04:23] <mathiaz> mvo: we've already seen this situation and it's taken care of in the postinst scripts. An apt-get upgrade won'T fail either.
[04:23] <pitti> persia: cool, thanks
[04:23] <Hobbsee> mvo: i turned it down due to uni - i'm doing a fairly complex subject on electrodynamics, and not really liking it.  so, if i go, i'd probably fail the subject.
[04:24] <mvo> mathiaz: aha, great!
[04:24] <pitti> persia: accepted then; I'll give back nsimap after it built and is in the archive (that'll take a while, though)
[04:24] <mvo> mathiaz: aha, I see it now, good
[04:24] <persia> pitti: Thanks.  I'll take a peek in my morning (~7 hours).
[04:24] <Hobbsee> mvo: which is, of course, bad, as i want to finish uni at some point in the reasonably near future :P
[04:25] <iwj> mvo: There's definitely something strange there.
[04:25] <iwj> mvo: But the log seems corrupted.
[04:25] <iwj> It's almost like there are two copies of dpkg running at once.
[04:29] <dholbach> why was the apt-listchanges 2.74ubuntu4 rejected?
[04:29] <dholbach> ... upload ...
[04:29] <ivoks> seb128: when you have time, take a look at #152107
[04:36] <mvo> iwj: I will request /var/log/dpkg.log from the user
[04:37] <iwj> mvo: It's very weird.
[04:38] <iwj> You've got nothing that could remove the dpkg lock, have you ?
[04:38] <mvo> iwj: no, I can not think of anything
[04:39] <iwj> Is this term.log collected by u-m via a pty arrangement ?
[04:39] <iwj> Another possibility is that something there is mangling it, eg processing data twice.
[04:40] <mvo> iwj: this one is not, its done via vte signals, the next version will use the native libapt pty mangling stuff
[04:40] <mvo> iwj: yeah; I was thinking the same (broken logging)
[04:40] <iwj> vte signals ?
[04:40] <seb128> bug #152107
[04:40] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
[04:40] <mvo> iwj: vte is the gnome/gtk terminal widget
[04:40] <seb128> ivoks: I've read it
[04:40] <iwj> Although if the log is broken that just means we don't understand what dpkg did and why, not that there is no bug in dpkg.
[04:40] <iwj> mvo: Ah.
[04:40] <mvo> iwj: it sends "content-changed" signals to the application
[04:40] <seb128> ivoks: that's nothing new and not something we will change before gutsy now
[04:41] <iwj> mvo: Ghgggg.
[04:41] <mvo> iwj: yeah :/
[04:41] <mvo> iwj: dpkg.log should give us the details hopefully
[04:42] <iwj> Well, it'll tell us something hopefully :-)
[04:42] <ivoks> seb128: ok
[05:36] <tkamppeter> seb128, ping
[05:36] <seb128> tkamppeter: hi
[05:37] <tkamppeter> I have a problem, I want to fix 152107 with a tiny patch so that users can admin printers easily
[05:37] <tkamppeter> seb128 I have tried
[05:37] <tkamppeter> --- gnome-system-tools-2.20.0~/src/users/privileges-table.c     2007-09-14 10:25:27.000000000 +0100
[05:37] <tkamppeter> +++ gnome-system-tools-2.20.0/src/users/privileges-table.c      2007-10-15 16:32:38.000000000 +0100
[05:37] <tkamppeter> @@ -54,6 +54,7 @@
[05:37] <tkamppeter>         { "dip", N_("Connect to Internet using a modem") },
[05:37] <tkamppeter>         { "fax", N_("Send and receive faxes") },
[05:37] <tkamppeter>         { "floppy", N_("Use floppy drives") },
[05:37] <tkamppeter> +       { "lpadmin", N_("Administer printers") },
[05:38] <tkamppeter>         { "plugdev", N_("Access external storage devices automatically") },
[05:38] <tkamppeter>         { "scanner", N_("Use scanners") },
[05:38] <tkamppeter>         { "tape", N_("Use tape drives") },
[05:38] <seb128> tkamppeter: it's too late to get such changes to gutsy now
[05:38] <tkamppeter> but this does not let the entry "Administer printers" apper
[05:38] <tkamppeter> ar in the GUI.
[05:38] <Mithrandir> tkamppeter: gutsy-updates.
[05:39] <seb128> no
[05:39] <seb128> new strings to stable is not a good idea
[05:39] <Mithrandir> that's a point too
[05:40] <tkamppeter> seb128, so better forget about it completely for now and help people 1 by 1 in private if they report printer admin access problems?
[05:40] <seb128> tkamppeter: yes
[05:41] <tkamppeter> seb128 perhaps better suggest this change on the user manager upstream, so they get 6 months to integrate it correctly, translate, and test it so that it gets grabbed by Hardy.
[05:42] <seb128> tkamppeter: what is the issue exactly? the admin tools run under gksu anyway no?
[05:42] <seb128> tkamppeter: and users should already be added to lpadmin
[05:42] <pitti> seb128: not additional users you create
[05:42] <seb128> the desktop and admin profiles list lpadmin
[05:42] <seb128> pitti: why not?
[05:43] <seb128> pitti: /etc/gnome-system-tools/users/profiles has those
[05:43] <pitti> ah, so it's only an UI issue, not a missing functionality?
[05:43] <tkamppeter> seb128, printing is special. The printer tool does not run under gksu, as CUPS provides non-root admin for users in lpadmin group.
[05:43] <pitti> well, it *can* run under gksu, of course :)
[05:43] <seb128> tkamppeter: well, if the config tool was not working somebody would have noticed for sure
[05:43] <ivoks> pitti: but then one can't set up options per user
[05:44] <ivoks> seb128: that was the bug i told you
[05:44] <ivoks> users-admin doesn't work.
[05:44] <tkamppeter> the users-admion tool has a bug ignoring the "lpadmin" in the group list of /etc/gnome-system-tools/users/profiles. It adds the new user to all groups but lpadmin -> bug 152107
[05:44] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
[05:44] <ivoks> create new admin user, it doesn't add user in lpadmin group - new admin can't manage printers
[05:45] <seb128> ivoks: so it would be nice to debug it
[05:45] <tkamppeter> For me it seems that users-admin has somewhere a list of groups with which it deals and all other groups it simply ignores.
[05:45] <seb128> ivoks: I'm sorry but people tell me about hundred of bugs so it's going to take me some time to get there, but patches are welcome ;)
[05:45] <ivoks> seb128: i was debugin, but you said it's done for gutsy :)
[05:45] <seb128> ivoks: did I?
[05:46] <seb128> ivoks: I said it's too late for gutsy rather
[05:46] <tkamppeter> So "lpadmin" needs to be added to the secret list of groups in users-admin, so that users-admin adds users to it, both by means of the profiles or the privileges tab.
[05:46] <ivoks> yeah
[05:46] <seb128> tkamppeter: looks correct
[05:46] <ivoks> that's what i tought, but maybe didn't write it clearly
[05:48] <tkamppeter> seb128, if one patches this "secret list" in users-admin the adding of users to "lpadmin" via profile will work. In addition one could patch users-admin to add users to both "admin" and "lpadmin" if one checks "Administer the system". This way one can fix bug 152107 without adding strings.
[05:48] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
[05:48] <seb128> tkamppeter: right
[05:50] <seb128> jamiemcc: the patch you sent to fix the crasher is not valid
[05:50] <seb128> jamiemcc: "**** malformed patch at line 24: @@ -537,11 +574,21 @@"
[05:50] <jamiemcc> seb128: is it malformed?
[05:50] <seb128> jamiemcc: yes
[05:50] <tkamppeter> seb128, how much are you knowledgeable about the gnome-system-tools? Could you fix this for Gutsy or at least for Gutsy-Updates?
[05:50] <jamiemcc> seb128: yeah I did a cut and paste job - will ifx now
[05:50] <seb128> jamiemcc: thanks
[05:50] <ivoks> seb128: note that new admin should also be in netdev and powerdev
[05:50] <tkamppeter> seb128, this is probably a very small patch.
[05:51] <seb128> tkamppeter: not that much, and I could do a patch but as said it's getting late and I'm not the one approving uploads
[05:51] <ivoks> (yeah, working on a patch) :)
[05:51] <seb128> ivoks: what is netdev and powerdev?
[05:51] <tkamppeter> Someone approving uploads here?
[05:51] <pitti> o/
[05:51] <seb128> tkamppeter: pitti does
[05:52] <Hobbsee> tkamppeter: release team is
[05:52] <ivoks> seb128: powerdev is for UPS's, IIRC
[05:53] <tkamppeter> pitti, can you approve an upload of gnome-system-tools? A tiny patch to make it handling the group membership management of admins correctly for Ubuntu.
[05:53] <pitti> tkamppeter: I can review and approve, but not actually do the patch/uploading
[05:53] <tkamppeter> Hobbsee, thanks, I meant people here on the IRC to get quick reaction.
[05:53] <pitti> tkamppeter: besides, it's getting late; uploads were supposed to be done by 1200 UTC today
[05:54] <pitti> tkamppeter: but TBH this is perfectly valid for -updates
[05:54] <Hobbsee> tkamppeter: tab completion is your friend, if you know who's there
[05:54] <pitti> tkamppeter: this bug does not impede the installation at all
[05:54] <ivoks> this can go into -updates
[05:54] <pitti> tkamppeter: but having a bug report with a patch available would be great, of course (for an SRU)
[05:55] <jamiemcc> seb128: delete line 23 of the patch and it should work
[05:56] <tkamppeter> seb128, ivoks, then prepare the patch for -updates. If it drops in by auto-updates a week after release or so no one will notice that there is something wrong.
[05:59] <seb128> jamiemcc: that works, thanks
[05:59] <jamiemcc> seb128: gtr thx
[05:59] <seb128> tkamppeter: right
[05:59] <tkamppeter> seb128, ivoks, re-milestoned bug 152107 to "gutsy-updates".
[05:59] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
[06:00] <seb128> tkamppeter: thanks
[06:19] <tkamppeter> seb128, ivoks, I have added a longer comment to bug 152107 with suggestions what needs to get fixed and also suggesting it as an urgent SRU.
[06:19] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed]  https://launchpad.net/bugs/152107
[06:27] <asac> ogra: bug 137598 -> patch: http://launchpadlibrarian.net/9690288/gpm-backlight.c.diff ... did you ever take a look?
[06:27] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
[09:02] <mvo> slangasek: what are the chances to fix a resource leak in libapt at this point (dpkgpm.cc)? chances to go in or should I get it into -updates?
[09:02] <slangasek> mvo: -updates please
[09:03] <bryce> mvo, where is the compiz blacklist stored on the filesystem?
[09:03] <mvo> slangasek: leaks on fd per configure/unpack run so it would be kind of cool to have it :/
[09:03] <mvo> bryce: in /usr/bin/compiz
[09:03] <bryce> thanks
[09:04] <mvo> bryce: we should probably put that into a seperate file in /usr/share/ something for hardy
[09:04] <bryce> yeah, or /etc/ something
[09:04] <slangasek> mvo: is this a regression vs. feisty?
[09:05] <mvo> slangasek: yes
[09:05] <mvo> slangasek: give me a sec, I add the diff
[09:05] <slangasek> mvo: ah.  so it's not been a problem so far, but when users try to upgrade from gutsy to hardy it will be?
[09:06] <mvo> slangasek: yes, also we will be able to work around it by enforcing a upgrade prerequist (special backport that is only used during the upgrade)
[09:08] <albertito> does anyone know if the bash bug 149527 (reported 10 days ago) is going to be fixed by the time of the release, or will it have to wait?
[09:08] <ubotu> Launchpad bug 149527 in bash ".profile not sourced anymore" [High,New]  https://launchpad.net/bugs/149527
[09:09] <slangasek> mvo: right, though upgrade prerequisites are IMHO best avoided where possible
[09:09] <slangasek> mvo: if you have the fix ready to upload right now, I can at least consider it since I still have to argue with seeds a bit
[09:25] <lamego> albertito, I was unable to reproduce the bug
[09:41] <mdke> dendrobates: ping?
[09:43] <dendrobates> mdke: hey
[09:46] <mdke> damn, phone
[09:52] <soren> I've just booted the RC livecd on a system with an nvidia graphics card. Isn't the restricted-manager supposed to show up?
[09:53] <mdke> dendrobates: hiya; I saw an entry for "server-documentation" on scott's schedule for the conference. I just wanted to check that you were aware of the ubuntu-serverguide package and find out if you need any help about who works on it and so on
[09:53] <stgraber> soren: Why would you want the restricted-manager to show up on a livecd ?
[09:54] <soren> stgraber: To let me know that I need evil stuff to use the hardware?
[09:54] <albertito> lamego: using gusty's bash?
[09:54] <stgraber> soren: as restricted-manager suggests to reboot after installing a restricted driver and you can't reboot a livecd
[09:54] <stgraber> soren: it'll at first boot
[09:54] <albertito> lamego: and the testcase I provided in the last comment?
[09:54] <dendrobates> mdke: I am aware of it.  We would like to be more involved with it and help keep it up to date.
[09:54] <lamego> albertito, yes
[09:54] <soren> stgraber: Not all hardware needs a reboot.
[09:55] <dendrobates> mdke: That is one of the things we plan to discuss at UDS.
[09:55] <soren> stgraber: e.g. winmodems.
[09:55] <albertito> lamego: how did you try? did you used "source bash-bug.sh"?
[09:55] <mdke> dendrobates: more input from you guys would be tremendous
[09:55] <albertito> lamego: somebody else on this channel confirmed it as well the other day (I don't remember the name :S)
[09:55] <lamego> unset ok; echo $ok; source .ok ; echo $ok
[09:55] <mdke> dendrobates: so if you want information about processes or whatever just give me a shout
[09:55] <lamego> this was my test, with ok=1 on .ok, the output was 1 :)
[09:56] <dendrobates> mdke: Thanks, I will.
[09:56] <albertito> lamego: but the readonly thing makes the difference
[09:56] <mdke> dendrobates: I'm hoping that the team will move to bzr shortly which will make contribution a bit easier
[09:56] <lamego> what readonly thing ?
[09:57] <stgraber> soren: well, then the restricted-manager should show up only if a piece of hardware that can be enabled without rebooting (nor restarting X) and hide all the others (we don't want someone to turn on the nvidia X driver on the livecd). Seems a bit hard to implement just for install time, doesn't it ?
[09:57] <albertito> lamego: the testcase I provided set the variable as read only, like bash-completion does
[09:58] <Mithrandir> hm, can we blacklist ubuntu-desktop from apport autofiling bugs?  They're not really useful, I think..
[09:58] <lamego> albertito, the bug report was about "source not working", what does that to do with a readonly variable ? :)
[09:58] <soren> stgraber: Possibly. anyhowm if it's not supposed to show up, that's good enough for me. I just wanted to know if it was a bug.
[09:59] <cjwatson> soren: restricted-manager is disabled on the live CD. (Ask pitti.)
[09:59] <soren> cjwatson: Fair enough.
[10:00] <albertito> lamego: have you read the last comment? it's not just "source" that doesn't work. It does work, but has a subtle difference when the sourced file fails. The last comment provides a testcase, explains why it happens, and what bash patch in ubuntu11 causes the bug
[10:00] <albertito> lamego: the bug shows up because sourcing your .bashrc doesn't work anymore, if you source bash-completion inside your bashrc (which is quite common)
[10:00] <cjwatson> soren: actually, I misremember, Riddell did it
[10:01] <cjwatson> soren: it's rather beneficial though since it means we save about 20MB of memory by being able to avoid linking fglrx and nvidia* on the live CD
[10:01] <cjwatson> in the live session at boot, I mean
[10:01] <albertito> lamego: it's not sourcing in general, the issue is the (very very common) interaction between bashrc and bash-comlpletion
[10:01] <lamego> ok, I didn't read the last comment careful, my test cased was based on the bug title
[10:02] <lamego> albertito, to be honest, i never used shell read only variables :)
[10:02] <albertito> lamego: yeah, the title is the "common symptom", but it's not actually where the bug is
[10:02] <soren> cjwatson: Right. I was just thinking it'd be nice to know on the livecd that the installed system would need restricted stuff.
[10:02] <soren> anyhow, I've got to run..
[10:02] <albertito> lamego: neither did I, but bash-completion does it by default, and the bash patch changes the behaviour and breaks it
[10:04] <albertito> lamego: and while it's not completely critical, many people are used to source their bashrc, and it won't work
[10:04] <lamego> lamego@lamego-desktop:~$ source bash_bug.sh
[10:04] <lamego> 1
[10:04] <lamego> bash: ROVAR: readonly variable
[10:04] <lamego> lamego@lamego-desktop:~$
[10:04] <albertito> (if they have bash_completion enabled, which is normal these days)
[10:04] <lamego> it reports the error, and stops, what is wrong about that behavior, besides it changed ?
[10:05] <albertito> lamego: let's say you source bash_completion at the beginning of your bashrc, which is quite normal
[10:05] <albertito> lamego: the way it worked before was that bash_completion complained about the ro variable, but kept on going. So the source succeeeded, and so did the rest of your bashrc
[10:06] <lamego> albertito, if that is the case, I need to fix my .bashrc to follow the new behavior
[10:06] <albertito> lamego: now, source bash_completion fails after it tries to set the ro variable, and instead of continuing, it stops. It also stops the bashrc sourcing, so the rest of your bashrc is not ran
[10:06] <albertito> lamego: no, because the bug is in bash_completion
[10:06] <albertito> lamego: bash_completion _depends_ on the behaviour that trying to set a ro variable will _not_ halt the sourcing
[10:07] <albertito> lamego: so either you remove the patch and keep the old behaviour, or you should fix bash_completion not to use ro variables (or use some other trick to avoid setting them)
[10:07] <lamego> albertito, I must be missing something I do have an . /etc/bash_completion on my .bashrc which is the stock one
[10:08] <albertito> lamego: yes, as most people do, because it's the stock one
[10:08] <lamego> and I do have custom code on .bashrc after the bash completation line
[10:08] <lamego> and that code gets sourced
[10:09] <albertito> lamego: well, in gutsy's bash, if you touch something in your .bashrc after sourcing bash completion, and do "source .bashrc", it won't run because it halts in sourcing /etc/bash_completion
[10:09] <albertito> lamego: it rans well the first time because the ro variable doesn't exist. The following invocations (ie. you changed your bashrc and want the current shell to source it) fail
[10:09] <albertito> (s/rans/runs!)
[10:10] <lamego> ok, you are correct
[10:10] <albertito> lamego: the problem is inside /etc/bash_completion and the way it handles the read only variables, it depends on the old behaviour
[10:10] <lamego> ok, I am convinced, sorry :P
[10:11] <albertito> lamego: np, thanks for taking the time to test this =)
[10:11] <lamego> people will just relogin,  but well, it is a bug :P
[10:12] <lamego> albertito, it is kind of late to fix non critical bugs, i think :P
[10:12] <albertito> lamego: I guess, I was just curious
[10:18] <jdong> hmm, I seem to have a suspend regression on today's updates
[10:18] <jdong> I suspect the new kernel
[10:18] <jdong> Macbook core 2 duo, Intel GMA950
[10:18] <jdong> resume just is a black screen
[10:19] <jdong> maybe it's the new -intel, but I've used bryce's -0ubuntu9 unofficial package before without a problem
[10:21] <jdong> turned off vbesave and turned on double console switch, and I'm alive this time
[10:22] <bryce> yeah, that unofficial -0ubuntu9 is identical to what I uploaded last night, so if it worked fine before, then it's not likely to be the source of a problem that started today
[10:25] <jdong> ok, turning off vbesave and turning on double_vt_switch has been successful for me over 5 cycles
[10:26] <jdong> if vbesave is on, then the screen doesn't wake on resume...
[10:26] <jdong> if double console switch is off, then all the VT's are lost on resume
[10:34] <mathiaz> keescook: I'd like to make some apparmor profiles changes (not for release though). How should we handled the split gutsy/hardy from the bzr point of view ?
[10:35] <keescook> mathiaz: if we ever SRU gutsy, we can just branch from the current version.
[10:35] <mathiaz> keescook: should we create a bzr branch for gutsy and keep developping in the ubuntu branch for hardy ?
[10:35] <keescook> mathiaz: IOW, hardy is just the normal branch, and we keep moving.
[10:35] <keescook> mathiaz: I don't see a reason to explicitly create the gutsy branch until we need it, though.
[10:36] <jdong> keescook: would it hurt to have that landmark?
[10:36] <jdong> i.e. if someone else were to want to try to create a SRU it's more convenient
[10:37] <mathiaz> keescook: true. we can always go back in the changelog and branch from that bzr revision.
[10:37] <keescook> jdong: sure, that's true.
[10:37] <keescook> jdong: let me push one right now.
[10:37] <Riddell> mertiki: very strange, I'm sure I uploaded that.  done so now but I don't know if the release dudes will want it in this late
[10:37] <jdong> cool
[10:38] <jdong> keescook: unrelated apparmor question... does apparmor have a way to explicitly deny/reduce access to a specific path? i.e. if I want users to have access to all files BUT foo
[10:38] <keescook> jdong: I think you can do overlapping rules?  I haven't tried.  like:
[10:38] <keescook>   /path/to/okay/stuff/*  r,
[10:38] <keescook> er
[10:39] <keescook> maybe not.  how do you drop perms?
[10:39] <jdong> that's what I'm wondering
[10:39] <mathiaz> keescook: good question...
[10:39] <keescook> I was going to say something like  /path/to/okay/stuff/exceptthis -r
[10:39] <keescook> but I don't think "-r" exists.  ;)
[10:39] <jdong> that would be a nice feature of apparmor.... if there's a way to specify no access
[10:39] <keescook> jdong, mathiaz: I'm pushing http://bazaar.launchpad.net/~ubuntu-core-dev/apparmor/ubuntu-gutsy/   now
[10:40] <keescook> it'll probably take a while.  ;)
[10:40] <mathiaz> keescook: great !
[10:40] <mathiaz> keescook: yes. I confirm...
[10:40] <jdong> hehe
[10:40] <Nafallo> keescook: ubuntu-hardy? ;-)
[10:40] <keescook> Nafallo: nah, we'll keep the -hardy work in just plain ubuntu/
[10:40] <mathiaz> jdong: denying access would go against the idea of apparmor, which is to deny by default, and then grant specific access.
[10:41] <Nafallo> keescook: ah, kewl :-)
[10:41] <jdong> mathiaz: that's what I figured. It's a shame tough, because in some cases the inverse workflow would express what I want to do more easily
[10:42] <mertiki> Riddell : You think so? Same if it's a fix?
[10:48] <mertiki> Riddell : Because if Gutsy is released without that patch.. Qt3 apps will be very ugly..
[11:10] <tkamppeter> Can anyone block the user etos@bk.ru  from posting on the Launchpad? See bug 147800. He has spammed a lot of LP bugs this way.
[11:10] <ubotu> Launchpad bug 147800 in cupsys "[Gutsy]  : bluetooth printing was working but is not (at the beginning of september)." [High,Confirmed]  https://launchpad.net/bugs/147800
[11:22] <ScottK> Adri2000: Give me the short version of why they should and I'll see what I can do.
[11:23] <Adri2000> ScottK: it fixes my mistake in the previous upload which breaks the upgrade path
[11:23] <ScottK> OK.
[11:24] <ScottK> Adri2000: Looks like it's been accepted already.
[11:24] <Adri2000> I still see it at http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/audacious-plugins_1.3.5-3ubuntu4.dsc
[11:25] <Adri2000> and it doesn't show up on https://lists.ubuntu.com/archives/gutsy-changes/2007-October/date.html (there is only ubuntu3)
[11:30] <ScottK> Publisher is on manual.  It won't show until after the next publisher run.
[11:32] <Adri2000> ok.
[11:35] <cjwatson> publisher> ... which is in progress
[11:35] <ScottK> Adri2000: Did you get any rejection mail?
[11:37] <ScottK> Adri2000: My bad.  It was rejected. I'm asking to see if we can get it in?
[11:38] <Adri2000> ScottK: argh. no I got nothing as I'm not the uploader. TheMuso is.
[11:40] <ScottK> Adri2000: Looks like you need to work on your first Gutsy SRU. ;-)
[11:41] <ScottK> Adri2000: The goal is to have gutsy-updates ready on release day, so it could be pretty painless.
[11:41] <Fujitsu> Is gutsy-proposed etc. not available pre-release?
[11:43] <ScottK> No.  They have to freeze the archive to copy it to dak for -security and -updates.
[11:43] <ScottK> Actually dunno about -proposed.
[11:44] <ScottK> If I understand this stuff correctly.
[11:44] <Adri2000> ScottK: you're sure it's too late? :(
[11:44] <Fujitsu> dak only does -security. -updates and -proposed are already existing.
[11:44] <ScottK> Adri2000: Yes.  RM said no.
[11:44] <ScottK> OK.
[11:45] <ScottK> Adri2000: Upload it to -proposed and we'll see what we can do to get it published.