[12:33] <RAOF> terlmann: So, file a bug against an appropriate SDL lib then, particularly if you can reproduce it with more than just sauerbraten.
[12:33] <terlmann> That's just it
[12:33] <terlmann> it only happens in sauer
[12:33] <pwnguin> file a bug against sauer
[12:33] <pwnguin> and let someone reassign when they know what to file against
[12:33] <terlmann> And I do not know the lib mano. Just wanted to share an interesting(IMHO) bug
[12:33] <terlmann> that got here from debian
[12:34] <pwnguin> and upstream
[12:34] <RAOF> terlmann: You will, however, notice that the very first thing in all this advice is "file a bug".  IRC is not a bugtracker :)
[12:34] <terlmann> Not at all
[12:38] <pwnguin> im sure someone will file at launch
[12:38] <pwnguin> but its multiverse
[12:39] <pwnguin> and sdl
[04:34] <jdong> why, when I scroll up and down in evolution thru a list of e-mails, does my disk grind with each scroll
[04:34] <jdong> it actually produces a very cool sound effect for scrolling!
[04:34] <jdong> but umm... I am guessing that's not intended functionality
[04:36] <dobey> in 2.12?
[04:36] <dobey> which is bad
[04:37] <lifeless> ell
[04:37] <lifeless> well
[04:37] <lifeless> using 1Gb of ram is bad too
[04:38] <IntuitiveNipple> There is an issue whereby with Google Desktop search indexing active it'll slow Evolution to a crawl when you're navigating mail folders, due to disk activity too
[04:38] <jdong> in Gutsy
[04:38] <RAOF> lifeless: Can't evolution assume that the kernel can deal with memory allocation?
[04:38] <lifeless> RAOF: no
[04:38] <dobey> evo didn't use 1GB of ram for the message list
[04:39] <dobey> leaking is one thing. breaking cache and killing your hard disk, is another
[04:39] <lifeless> dobey: I'm sorry, you're right, its only using 407m at the moment
[04:39] <lifeless> dobey: for the message list
[04:39] <dobey> for only the message list?
[04:39] <dobey> i doubt it
[04:39] <lifeless> dobey: no windows open
[04:40] <dobey> you have no evolution windows open?
[04:40] <dobey> and evolution is running?
[04:40] <lifeless> only the message list window
[04:40] <dobey> that doesn't mean the message list is all that's eaten the ram
[04:40] <dobey> and is that RSS or VIRT?
[04:41] <lifeless> virt; rss is 262
[04:41] <lifeless> xorg and firefox are eating the rest
[04:41] <dobey> icon theme caches cause VIRT to be fairly high in gnome apps
[04:41] <dobey> RSS is what matters
[04:41] <lifeless> fair enough
[04:42] <lifeless> I've seen the rss significantly igher
[04:42] <dobey> and i think federico has been working on how to make the icon theme caching not cause VIRT to be so big
[04:42] <dobey> yes
[04:42] <dobey> but how long has evo been open? do you keep it open to auto-poll an imap server?
[04:42] <lifeless> a few days
[04:42] <lifeless> normally it would be open for a few weeks
[04:43] <dobey> right
[04:43] <dobey> and you use evo with imap presumably, with auto-check enabled?
[04:43] <lifeless> yes, via ssh
[04:43] <dobey> there are probably some fairly large leaks in that bit of the code
[04:44] <lifeless> I would hope so, because that offers the chance to fix things
[04:45] <lifeless> RAOF: the kernel is reasonably good at pushing unused pages out to disk
[04:45] <dobey> i would certainly look toward that code for leaks
[04:45] <RAOF> lifeless: I suppose that if evo is actually using those pages it's a problem.
[04:45] <lifeless> RAOF: but you pay a performance price twice-over to do this; if its not a static page (such as a library), then it has to be created, populated, and hang around long enough to get paged
[04:45] <dobey> anyway, pub calls
[04:46] <lifeless> dobey: enjoy
[04:46] <dobey> later
[04:46] <lifeless> RAOF: this page has just pushed something else out; either a cache page has been removed, causing disk IO to read it later, or another dirty page has been written and reused
[04:48] <lifeless> RAOF: secondly, if its not a really unneeded page then it will have to be paged back in
[04:48] <RAOF> lifeless: Right.
[04:48] <lifeless> *much* better to not use the page in the first place
[04:48] <lifeless> disk io is slow :)
[04:48] <jdong> I find it hard to believe, though, that scrolling up and down between 2 e-mails is enough to break cache on a 1GB RAM system
[04:48] <lifeless> jdong: blktrace is your friend
[04:48] <jdong> lol I'll investigate when it bugs me more :)
[04:49] <jdong> right now, I like the scrolly sound effect
[04:49] <jdong> it reminds me of MS Word 97 :D
[09:32] <desertc> Congratulations on the addition of the Linspire developers, Randy Linnell and Brian Thomason.
[10:10] <pitti> cjwatson_, slangasek: since we had no "OMGdeadkittens" feedback on the beta so far, I'd really like to thaw gutsy now. WDYT?
[10:11] <pitti> unapproved piles up and is starting to become a nuisance for further development and bug fixing
[10:11] <StevenK> pitti: OMG dead kittens. Or something. :-P
[10:11] <StevenK> pitti: If you thaw gutsy, does unapproved empty itself?
[10:11] <pitti> StevenK: no, that needs to be done manually
[10:12] <pitti> StevenK: if you want, we could combine this with a quick tutorial to operate the queue tool
[10:12] <StevenK> pitti: Just finishing off gimp, by the way
[10:12] <seb128> morning
[10:12] <seb128> hey pitti StevenK
[10:12] <StevenK> seb128: ^
[10:12] <pitti> StevenK: (unless you are heading to bed soon, of course; you certainly deserve it :) )
[10:12] <pitti> hey seb128
[10:12] <seb128> StevenK: cool
[10:12] <pitti> StevenK: erm, ignore me; that was meant for slangasek
[10:12] <pitti> StevenK: cool
[10:12] <StevenK> pitti: Yeah, I was wondering. :-)
[10:13] <slangasek> pitti: ah, if the stuff in unapproved stays where it is, that sounds good to me
[10:13] <pitti> StevenK: not enough tea, or something
[10:13] <StevenK> pitti: :-)
[10:13] <Mithrandir> I'd recommend emptying unapproved so we don't hold up development more; accepting stuff from unapproved is just like doing NEW
[10:13] <pitti> slangasek: well, we should flush it after gutsy thaws, but you could do one or two approvals manually just to see how it works
[10:13] <Lure> is usb disk detection on boot known issue?
[10:13] <slangasek> (c.f. 145326, a UVFe request that's already been uploaded to unapproved... :)
[10:14] <Mithrandir> pitti: have him do -proposed or something instead?
[10:14] <pitti> Mithrandir: well, five more minutes for one package certainly doesn't hurt
[10:14] <Mithrandir> since that's less time sensitive
[10:14] <StevenK> Okay, it passes the first test, it actually runs
[10:14] <Mithrandir> pitti: oh, if you're doing it now, that's fine, I was thinking if stuff's still locked up until Monday then it starts to hurt.
[10:15] <slangasek> pitti: in any case, yes, let's get gutsy thawed and then settle unapproved one way or another
[10:15] <pitti> oh, noes
[10:15] <pitti> slangasek: ok, can we do it right now?
[10:16] <slangasek> pitti: yes please
[10:17] <pitti> I asked IS for thawing
[10:29] <Hobbsee> sladen: ping
[10:29] <Hobbsee> mjg59: possibly ping as well
[10:33] <seb128> hey Hobbsee
[10:33] <Hobbsee> hiya seb128!
[10:35] <DktrKranz> could a buildd admin give back dasher package on amd64? thank you.
[10:36] <pitti> DktrKranz: dholbach already asked for that two hours ago; if it failed again, it's a real problem and I won't give it back
[10:36] <DktrKranz> please, forget about it....fixed
[10:36] <pitti> ah :)
[10:36] <DktrKranz> pitti, sorry for the confusion
[10:41] <pitti> delta: gutsy thawed, go wild!
[10:42] <Hobbsee> yay!
[10:46] <mvo> Hobbsee: do you want to have a look at bug #141628 ? I attached the patch against the kde screensaver that I posed yesterday
[10:46] <ubotu> Launchpad bug 141628 in compiz "Compiz w/ kde screensaver blanks 1/4 screen" [Low,Confirmed]  https://launchpad.net/bugs/141628
[10:48] <Hobbsee> mvo: what's that patch against?
[10:48] <mvo> Hobbsee: oh, sorry. kdescreensaver
[10:48] <Hobbsee> mvo: oh, kdebase.
[10:48] <Hobbsee>  /storage/devel/kde3.5.7/kdebase/kdebase-3.5.7/kdesktop/lock/lockprocess.cc
[10:48] <Hobbsee> mvo: can do.
[10:49] <mvo> Hobbsee: rock, thanks
[10:58] <Hobbsee> mvo: got any more patches for me?
[11:03] <mvo> Hobbsee: not currently
[11:03] <Hobbsee> mvo: OK
[11:10] <pwnguin> is there a format for those closes bug foo lines in changelogs i should be following?
[11:10] <soren> pwnguin: Yes
[11:10] <Hobbsee> LP: #foo
[11:11] <Hobbsee> vi with syntax highlighting will show you if you got it wrong
[11:11] <pwnguin> i should probably set editor away from nano then
[11:12] <Hobbsee> nano sucks.  yes, you would.
[11:12] <Hobbsee> er, should
[11:12] <Hobbsee> welcome to the world of *real* text editors.
[11:13] <pwnguin> nano's quite fine for small changes
[11:13] <RAOF> pwnguin: Google for "pretty emacs"
[11:13] <pwnguin> better than vi :P
[11:13] <pwnguin> heh
[11:13] <pwnguin> i dont need special fonts
[11:13] <pwnguin> plain emacs is good enough for me
[11:13] <RAOF> pwnguin: Yes.  You do.
[11:13] <pwnguin> lies
[11:13] <RAOF> pwnguin: You may not know it, but you desperately want XFont rendered emacs.
[11:14] <pwnguin> i just want emacs without a splash
[11:14] <Hobbsee> RAOF: xfont rendered emacs?
[11:14] <Hobbsee> RAOF: is there anything that i'm relaly missing by not using emacs, though?
[11:14] <pwnguin> carpal tunnel
[11:14] <Hobbsee> pwnguin: whether you choose vi or emacs, it's still better than vi.
[11:14] <RAOF> Hobbsee: emacs-snapshot, but with actual font rendering, rather than ugly ass stuff.
[11:14] <Hobbsee> er, nano
[11:14] <pwnguin> Hobbsee: yes
[11:14] <pwnguin> everything is better than vi
[11:14] <Hobbsee> RAOF: ah, right
[11:15] <pwnguin> RAOF: you must realize, i use monospace for irc
[11:16] <RAOF> pwnguin: So what?  I use monospace for everything in emacs.  It *still* looks amazingly better with actual font antialiasing, subpixel rendering, et al
[11:16] <pwnguin> at any rate
[11:16] <pwnguin> if its not a package i'll wait
[11:17] <RAOF> pwnguin: It is a package on a PPA.
[11:17] <RAOF> pwnguin: That's on my "Absolutely must be pushed into Hardy" pile.
[11:18] <pwnguin> RAOF: so i encountered a mysterious xset bug. it seems nvidia wont let me turn off the backlight with dpms, but nv will
[11:18] <RAOF> pwnguin: That's awesome.
[11:18] <pwnguin> nv ftw
[11:18] <RAOF> *nouveau* FTW
[11:18] <pwnguin> its possible im missing some xorg.conf setting in their massive pile of README
[11:19] <RAOF> pwnguin: NvEnableDPMSNoReally
[11:19] <pwnguin> heh
[11:20] <pwnguin> ok
[11:20] <pwnguin> billard-gl has two original maintainer entries
[11:21] <pwnguin> one of which is MOTU
[11:21] <pwnguin> is this expected behavior?
[11:21] <Hobbsee> yes - maintainer and original maintainer
[11:22] <pwnguin> no no
[11:22] <pwnguin> XSBC original maintainer
[11:22] <pwnguin> two entries
[11:22] <pwnguin> and then maintainer
[11:22] <pwnguin> which is also motu
[11:22] <Hobbsee> what does the OM field say?
[11:23] <pwnguin> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[11:23] <pwnguin> XSBC-Original-Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[11:23] <pwnguin> XSBC-Original-Maintainer: Thierry Reding <thierry@doppeltgemoppelt.de>
[11:23] <Hobbsee> did you use an update-maintainer script there?
[11:23] <pwnguin> thats straight from the archive
[11:23] <Hobbsee> you can delete the middle line there
[11:23] <soren> pwnguin: Someone ran "update-maintainer" on it while it was already done.
[11:23] <Hobbsee> soren: it shouldnt add twice, unless the script is wrong
[11:24] <soren> Hobbsee: Quite.
[11:24] <pwnguin> ok. well, im fixing another bug in that package, so i guess i'll take care of that while im there
[11:26] <pwnguin> RAOF: whats with emacs highlighting changelogs?
[11:27] <pwnguin> whats more hilarious about that is the changelog for the previous version:
[11:27] <pwnguin> * debian/control: Update maintainer fields according to debian- maintainer-field spec
[11:27] <pwnguin> and thats it
[11:28] <Hobbsee> pwnguin: who was the uploader?
[11:28] <pwnguin> heh
[11:28] <Hobbsee> well, the person in the changelog?
[11:28] <pwnguin> martin pitt
[11:28] <Hobbsee> pwnguin: ah - that's an automated script.
[11:29] <Hobbsee> i wonder why it thought that Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> was not right
[11:34] <glatzor> hello Hobbsee, could you please upload a svn snapshot of kde-guidance? I updated the MonitorsDB in the kde3 branch.
[11:34] <glatzor> Hobbsee: so the changelog entry would be: * Update monitor definitions - fixes LP: #113520 #113514
[11:37] <Riddell> glatzor: I can do that
[11:37] <glatzor> Riddell: thanks a lot.
[11:41] <jamesh> seb128: did you see my message about the ubuntulooks AMD64 crasher (with a workaround patch)?
[11:42] <seb128> jamesh: yes, it's on my list of "unread bug mails" (ie, things I've to look at)
[11:42] <jamesh> okay, cool.
[11:42] <jamesh> I've been running with it for most of the week with no ill effects or badly drawn progress bars :)
[11:43] <seb128> jamesh: ok, good to know, thanks ;)
[11:46] <seb128> jamesh: I just read your comment on the totem bug
[11:48] <jamesh> okay
[11:48] <seb128> jamesh: we used to build the package without xrandr, maybe we should do that again?
[11:48] <seb128> I thought we were still doing that bug looking at the build log it doesn't look like
[11:49] <jamesh> seb128: the Gnome bug sounds like they're using Xrandr 1.0 functions -- perhaps they behave subtly different with an Xrandr 1.2 capable server
[11:49] <jamesh> ?
[11:49] <seb128> not sure
[11:49] <seb128> bugzilla doesn't want to reply at the moment
[11:49] <seb128> so I've not read the upstream bug yet
[11:50] <seb128> but previous cycle we built the package without xrandr because the resolution change was really confusing users
[11:54] <TomaszD_> seb128, thanks for f-spot and bluez-gnome fixes!
[11:54] <seb128> TomaszD_: you are welcome
[11:56] <TomaszD_> seb128, when it comes to g-c-c, there is this improved desktop effects panel, but rosetta doesn't seem to include the updated template (it has the strings for the previous simplistic no effects/normal/extra switcher).
[11:57] <TomaszD_> is this something to be concerned about?
[11:57] <TomaszD_> or should I ask carlos
[11:57] <seb128> TomaszD_: ask carlos, looks like rosetta is busy, it might still be importing things
[11:57] <Mithrandir> seb128: about the gst bluetooth crasher, Marcel committed something to CVS today which is said to fix it.
[11:58] <TomaszD_> seb128, alright
[11:58] <Mithrandir> seb128: I'm going to talk with him about whether he'd prefer us to ship the gstreamer plugin or not.
[11:58] <carlos> TomaszD_: g-c-c is being imported right now
[11:58] <TomaszD_> carlos, right on, thanks
[11:58] <seb128> Mithrandir: we have a pretty easy testcase, "touch example.mp3 && totem example.mp3"
[11:59] <carlos> so expect to have the new strings in next hour or so (maybe earlier)
[11:59] <Mithrandir> seb128: indeed.
[11:59] <TomaszD_> carlos, btw my gnome-app-install import took 9 days and 8hrs :(
[11:59] <Mithrandir> seb128: I'm more thinking about general quality concerns.
[11:59] <TomaszD_> oh well, at least it went through
[12:00] <carlos> TomaszD_: I know, I already implemented a patch that will improve the import performance a bit, it's in our QA process
[12:00] <seb128> Mithrandir: otherwise an option to make everybody happy is to binary split the gst plugin (which makes sense to do anyway) and not seed it so it's not creating issue on the default installation
[12:00] <TomaszD_> :] 
[12:00] <carlos> TomaszD_: at least, we are again catching up and reducing import time that grow again to 9 days ...
[12:01] <TomaszD_> cool.
[12:02] <carlos> TomaszD_: danilo found another way to improve import performance, but that will take a bit more time to be deployed because we cannot do big changes so close to gutsy release
[12:03] <TomaszD_> carlos, tell me, when the language pack update finally reaches the archive, is the rosetta snaphot included in it up-to-date or is it being generated for such a long time that it takes a few days, thus when langpack reaches the users it is not actually very up-to-date
[12:03] <TomaszD_> ?
[12:03] <carlos> TomaszD_: the lang pack export is already exported from Launchpad
[12:03] <carlos> TomaszD_: pitti is preparing the .deb package already and should be ready today
[12:04] <carlos> TomaszD_: it has data from Tuesday-Wednesday
[12:04] <TomaszD_> ah
[12:04] <TomaszD_> ok
[12:04] <carlos> and sunday, we will do an update with all changes since Tuesday-Wednesday
[12:04] <carlos> at least that's the plan
[12:04] <TomaszD> and this would be one of the last updates right?
[12:04] <TomaszD> will there be more on the road to final gutsy?
[12:05] <carlos> every Sunday and Wednesday we should provide updates until final release when we will do another full export
[12:05] <TomaszD> cool, that's what I needed to know
[12:05] <TomaszD> thanks
[12:06] <carlos> pitti: just to be sure, that's the plan, right?
[12:23] <defcon_> yo
[12:23] <defcon_> there is a bug that has been with ubuntu for a few years that has never been fixed
[12:23] <defcon_> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/34902
[12:23] <ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed] 
[12:24] <defcon_> Gutsy beta didnt fix this issue
[12:24] <defcon_> the ralink drivers/rt73 dont work at all
[12:24] <defcon_> why even have the driver
[12:24] <saispo> same as bcm43xx
[12:24] <defcon_> you should just remove the driver because it doesnt work
[12:24] <defcon_> and say "ubuntu doesnt support ralink"
[12:25] <defcon_> ralink=thousands, maybe millions of people
[12:25] <Ng> I've seen some ralinks working fine - perhaps they changed the chipset at some point?
[12:25] <TomaszD> seb128, I'm afraid I have other intltool-related problems, neither nautilus nor nautilus-sendto build-depend on intltool, the templates aren't being updated
[12:26] <defcon_> yea, that is why we should keep the driver updated
[12:26] <defcon_> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=shortlog;h=rt2x00
[12:26] <TomaszD> this is rather serious :] 
[12:26] <defcon_> Ubuntu is using a old driver
[12:26] <defcon_> very old
[12:27] <defcon_> and I have a old card
[12:27] <TomaszD> I was wondering why do I have "Home folder" instead of Folder domowy, now I know why
[12:27] <carlos> seb128, pitti: Isn't there a way to add intltool build dependency to any package using the gnome rule that uses intltool?
[12:27] <defcon_> if I build my own driver im fine
[12:28] <defcon_> the problem is with the USB id's
[12:28] <defcon_> a hardware/driver conflict
[12:28] <defcon_> the new driver needs to be pushed through with ubuntu gutsy final
[12:30] <TomaszD> seb128, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/146244
[12:30] <ubotu> Launchpad bug 146244 in nautilus "Nautilus doesn't update the translation template, should build-depend on intltool" [Undecided,Confirmed] 
[12:30] <defcon_> the old drivers=flawed
[12:30] <cjwatson> defcon_: we get your point, you can stop repeating it at length now, thanks :)
[12:30] <cjwatson> defcon_: you need to talk to the kernel team, not #ubuntu-devel. I've reassigned the bug to a more appropriate package
[12:31] <defcon_> cjwatson, thankyou
[12:31] <TomaszD> seb128, https://bugs.launchpad.net/ubuntu/+source/nautilus-sendto/+bug/146247
[12:31] <ubotu> Launchpad bug 146247 in nautilus-sendto "nautilus-sendto should build-depend on intltool, doesn't update translation template [gutsy] " [Undecided,Confirmed] 
[12:41] <pitti> carlos: no, there isn't; auomatically changing debian/control during build is EBW
[12:42] <pitti> TomaszD, carlos: plan> right
[12:42] <TomaszD> ebw?
[12:43] <Hobbsee> evil, bad and wrong
[12:43] <pitti> 'evil, bad and wrong'
[12:43] <TomaszD> lol
[12:43] <TomaszD> :] 
[12:43] <carlos> pitti: I was thinking more on an indirect dependency, but I guess that means that packages not using the gnome rule would get such dependency too, which is not correct...
[12:43] <pitti> carlos: right, if there's a package common to all of those
[12:43] <TomaszD> I assume there was some sort of an infrastructure change, because there wouldn't be so many intltool buil-depend related problems otherwise
[12:51] <slytherin> dholbach: ping
[12:56] <pitti> TomaszD: maybe it was dropped from a fairly common gnome build dep, I don't kno9w
[01:00] <dholbach> slytherin: pong
[01:00] <seb128> carlos: no
[01:01] <slytherin> dholbach: I will be back in 5 minutes, drafting mail about theora.
[01:01] <seb128> TomaszD: please look for bugs before sending duplicates, the nautilus issue is known and Fix Commited
[01:01] <mjg59> Hobbsee: Hi
[01:01] <seb128> pitti: we could make cdbs Depends on intltool
[01:01] <dholbach> slytherin: how can I help you with that?
[01:02] <dholbach> seb128: good idea - I think that'd drop quite some diff (Build-Depends + stuff in debian/rules)
[01:03] <slytherin> dholbach: I have created packages by syncing to debian version. Unfortunately I am unable to upload it to my PPA due to the version I chose for previous packages I had created on my own. I hoped that you could help me with hosting the packages. :-D
[01:03] <dholbach> slytherin: why can't you use PPA?
[01:04] <Riddell> glatzor: new guidance uploaded
[01:05] <pitti> seb128: I thought about this, and I don't think it's too evil
[01:05] <pitti> seb128: after all, it ships langpacks.mk which needs it
[01:05] <slytherin> dholbach: The version I used for previous packages which I created on my own supersedes the version from debian. 1.0.beta1.dfsg-0ubuntu1 (mine) vs libtheora_1.0~beta1-1ubuntu1 (created from the package in debian). :-(
[01:06] <TomaszD> seb128, sorry I was looking, but didn't find it
[01:06] <dholbach> slytherin: ask in #launchpad to get that version removed and use 1.0~beta1-1ubuntu1~ppa1 for the next upload
[01:07] <slytherin> dholbach: Can I have all the necessary files hosted somewhere else just for the sake of discussion?
[01:08] <dholbach> slytherin: sure, if you don't want to wait on the LP folks helping you, just upload them somewhere
[01:09] <slytherin> dholbach: I want to initiate discussion today before I leave for home. :-)
[01:11] <dholbach> PPA is not a requirement for discussions
[01:16] <Hobbsee> mjg59: your'e the usual uploader of hotkey-setup - have you seen https://bugs.edge.launchpad.net/ubuntu/+source/hotkey-setup/+bug/140967 ?
[01:16] <ubotu> Launchpad bug 140967 in hotkey-setup "package hotkey-setup 0.1-17ubuntu19 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,Confirmed] 
[01:16] <Hobbsee> mjg59: looks like a few people are getting it, and it appears to be breaking upgrades
[01:17] <seb128> TomaszD: that's alright
[01:20] <slytherin> dholbach: sent message to ubuntu-devel-discuss list.
[01:20] <Hobbsee> mvo: one guy very happy with the upgrade manager, and the smooth upgrade, btw
[01:20] <Hobbsee> mvo: thought you might like to know
[01:24] <mjg59> Hobbsee: I honestly can't see why that would suddenly trigger now, but I'll look into it
[01:24] <Hobbsee> mjg59: great, thanks :)
[01:25] <mvo> Hobbsee: yeah, I'm very happy about this. I usually get the bad upgrade reports as bugs, so every one that worked fine warms my heart :)
[01:25] <seb128> TomaszD: also please don't assign bug to me, it's up to me to decide what I want to work on or not, subscribe is enough to let me know about a bug
[01:26] <mvo> no need to subscribe, seb128 reads all the bug mails anyway :P
[01:26] <TomaszD> seb128, alright.
[01:26] <seb128> dholbach: that will not allow to drop debian/rules changes, Depends are not magical ;)
[01:26] <Hobbsee> mvo: :D
[01:26] <TomaszD> mvo, I figured ;] 
[01:27] <dholbach> seb128: but we could add magic somewhere :)
[01:27] <\sh> pitti, keescook : Are you working on the off-by-one  buffer-overflow fix in openssl ? if not, I push a debdiff to LP
[01:27] <seb128> dholbach: we already did, gnome.mk call the langpack.mk
[01:28] <dholbach> seb128: maybe debhelper.mk should include it ;-)
[01:28] <seb128> dholbach: but for debian/rules done the hard way there is not a lot we can do magically
[01:28] <seb128> dholbach: we already cover the cdbs cases
[01:28] <dholbach> right
[01:28] <seb128> dholbach: kde and xfce also include it
[01:28] <pitti> \sh: I'm not, no idea about kees
[01:28] <pitti> \sh: thank you
[01:29] <seb128> dholbach: the Build-Depends is the common issue, there is very few packages that we patch to call intltool-update
[01:29] <\sh> pitti, ok...I'm pushing a debdiff with the inline fix (just a few lines in ssl/ssl_lib.c) checking dapper to feisty too
[01:29] <seb128> and those should ideally be converted to cdbs ;)
[01:29] <dholbach> yeah
[01:30] <dholbach> seb128: that reminds me of "if somebody CDBSes one of my packages there will an error in the archive"
[01:30] <pitti> "accident", I believe
[01:30] <dholbach> yeah, makes sense :)
[01:30] <pitti> dholbach: NO IDEA who could have said that :-P
[01:30] <thom> "ideally"
[01:30] <pitti> seb128++, though
[01:47] <dholbach> MOTU Q&A session in #ubuntu-classroom in 12 minutes
[02:00] <Kopfgeldjaeger> hi
[02:26] <seb128> carlos: the nautilus-sendto build log mention that the template is updated correctly, could you look if there is an isse on the rosetta side? ThomaszD opened bug #146247 about it
[02:26] <ubotu> Launchpad bug 146247 in nautilus-sendto "nautilus-sendto should build-depend on intltool, doesn't update translation template [gutsy] " [Medium,Incomplete]  https://launchpad.net/bugs/146247
[02:29] <\sh> pitti: please review bug 146269
[02:29] <ubotu> Launchpad bug 146269 in openssl "[openssl security]  OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [Undecided,New]  https://launchpad.net/bugs/146269
[02:29] <pitti> keescook: ^ forwarding to you
[02:30] <pitti> jdstrand: ^ or you
[02:30] <jdstrand> pitti: thanks
[02:38] <\sh> jdstrand, stop..found a mistake...in my patch...give me a sec
[02:38] <jdstrand> \sh: np
[02:41] <\sh> jdstrand, fixed debdiff attached
[02:41] <jdstrand> \sh: thanks!
[02:43] <\sh> jdstrand, do you want separate bug reports for dapper up to feisty? or should I attach the dapper/edgy/feisty debdiffs to this bug too?
[02:43] <pitti> \sh: at most, separate tasks; there should not be differnet bug reports
[02:43] <jdstrand> \sh to that one bug report would be easiest I think
[02:44] <pitti> hey sabdfl
[02:44] <seb128> Mithrandir: will you do a bluez-utils upload with this cvs patch today? We get several duplicates a day and that would be nice to fix that before the weekend ;)
[02:45] <carlos> seb128: sure, let me check it
[02:46] <seb128> carlos: thanks
[02:48] <carlos> seb128: there is already a template waiting to be imported. Did it change any string recently that was added with that last upload?
[02:49] <seb128> carlos: no
[02:49] <seb128> carlos: I've asked details on the bug, thanks for looking
[02:50] <carlos> seb128: confirmed, the .pot file we got was generated with the build so it should be up to date
[02:50] <carlos> seb128: ok
[02:51] <jykiv>  http://st-pitch.miniville.fr/sec
[02:51] -jykiv:#ubuntu-devel-  http://st-pitch.miniville.fr/sec
[02:51] <seb128> carlos: thanks
[02:52] <Mithrandir> seb128: sure
[02:52] <seb128> Mithrandir: thanks
[03:06] <carlos> Riddell, pitti: I would appreciate some input from you about this bug: https://bugs.launchpad.net/rosetta/+bug/146289
[03:06] <ubotu> Launchpad bug 146289 in kde-i18n "Translations for non main packages are discarded" [Undecided,New] 
[03:07] <pitti> will look in a bit
[03:07] <carlos> pitti: ok, thanks
[03:12] <seb128> hum
[03:12] <seb128> canonical network issues?
[03:12] <seb128> no, it's good again
[03:14] <sabdfl> howdy pitti et al
[03:15] <seb128> hey sabdfl
[03:20] <Mithrandir> seb128: fix confirmed and uploaded.
[03:20] <Hobbsee> hi sabdfl, Mithrandir
[03:20] <seb128> Mithrandir: you rock ;)
[03:20] <cjwatson> apparently it creates COW entries if you open a file O_RDWR even if you close it without making any changes
[03:21] <cjwatson> as it happens, modprobe does exactly this (it opens it read/write so that it can set a write lock)
[03:21] <cjwatson> bye-bye 3MB+ of memory
[03:21] <evand> yikes
[03:53] <asac> Riddell: which package contains the network-configuration for kde?
[03:54] <Riddell> asac: which network configuration?
[03:55] <asac> Riddell: ... the equivalent to network-admin
[03:55] <Hobbsee> asac: kde-guidance, iirc?
[03:55] <Riddell> asac: no
[03:55] <asac> Riddell: it appears not to disable the interface in /etc/network/interfaces if you disable the interface there
[03:55] <Hobbsee> or is it kcontrol?
[03:55] <Riddell> knetworkconf
[03:55] <asac> Riddell: so once you manually configured it you won't be able to make the device network-manager managed again.
[03:55] <siretart> cjwatson: what part of d-i writes the UUIDs to $target/etc/fstab?
[03:56] <asac> Riddell: could you plesae give it a quick shot and confirm that before i post a rc bug?
[03:56] <cjwatson> siretart: partman-target
[03:56] <siretart> thnx
[03:59] <bddebian> Heya
[04:03] <asac> Riddell: Hobbsee: bug 146216 ... if that isn't true, let me know :)
[04:03] <ubotu> Launchpad bug 146216 in knetworkconf "kde network administration doesn't disable interfaces in /etc/network/interfaces" [High,Confirmed]  https://launchpad.net/bugs/146216
[04:05] <asac> Riddell: i assigned the bug to jr (you?) for now
[04:05] <Riddell> asac: can do
[04:05] <Riddell> asac: can you explain more what "not properly disabled" means?
[04:06] <Riddell> would should it be like?
[04:08] <bddebian> OK classpath has been building on my machine for 12+ hours.  Even if it finishes do I dare throw that up on the archive?
[04:08] <\sh> bddebian, sure :)
[04:14] <StevenK> bddebian: You need to pedal faster!
[04:14] <pitti> bdmurray, keescook: in the light of https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions, how much and which kind of verification do we want to do for bug 140893? (and similar ones which will occur in the future)
[04:14] <ubotu> Launchpad bug 140893 in postgresql-8.2 "8.2.5/8.1.10 upstream microreleases available" [Undecided,Fix committed]  https://launchpad.net/bugs/140893
[04:15] <agoliveira> StevenK: You just mae my day with that :)
[04:15] <bddebian> StevenK: Aye, no kidding :-)
[04:15] <StevenK> agoliveira: :-)
[04:16] <asac> Riddell: the idea is that the interface is disabled ... which it isn't :)
[04:16] <asac> Riddell: e.g. comment the iface and option lines with  #
[04:17] <asac> Riddell: or just remove them ... network-admin does that right, but kde appears to do nothing if you disable and if you restart the configuration dialog its actually not disabled
[04:17] <Riddell> no, it's probably just ifdown
[04:18] <asac> Well ... that would be disconnect :) ... and not disable
[04:18] <Riddell> asac: has that changed recently?  I seem to remember network manager doing happy with the interface in /etc/network/interfaces as dhcp
[04:18] <asac> Riddell: yes
[04:19] <Riddell> asac: any reason for the change?
[04:19] <asac> Riddell: yes ... it doesn't work if you mix ifupdown and network-manager
[04:19] <superm1_> mvo ping
[04:20] <asac> Riddell: it works somehow, but it never does what you really want ...
[04:22] <Tonio_> asac: hey, as you're there I have a question about bug 123808
[04:22] <ubotu> Launchpad bug 123808 in network-manager-applet "NetworkManager Applet should not be started on LTSP Thin Clients" [Undecided,Invalid]  https://launchpad.net/bugs/123808
[04:22] <asac> Tonio_: yes ... the patch looks good ... who invalidated it?
[04:23] <Tonio_> asac: should we also consider patching knetworkmanager ?
[04:23] <asac> Tonio_: a right its valid for -applet
[04:23] <Tonio_> asac: I don't know who did
[04:23] <asac> Tonio_: i think its a tweak for edubuntu ... so ask ogra
[04:23] <asac> (who appears to be offline atm)
[04:23] <Riddell> mvo: does the dist upgrade tool install new recommends packages?
[04:24] <asac> Riddell: fwiw, bug 139403
[04:24] <ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Fix released]  https://launchpad.net/bugs/139403
[04:24] <Tonio_> asac: yes, that's not of any use for edubuntu, but for some reason someone would maybe want to use kubuntu over ltsp right ?
[04:24] <asac> Riddell: and there were a few mails on -devel on that
[04:24] <asac> Tonio_: yes ... makes sense imo
[04:24] <asac> Tonio_: but i am not sure if the env that is tested is something universal ... or an edubuntu hack
[04:25] <Tonio_> asac: okay there is no emergency since that's a very limited context, but I'll consider fixing this
[04:25] <asac> Tonio_: lets add the knetworkmanager target to the bug and ask ogra
[04:25] <Tonio_> asac: hum right, I'll ask ogra then
[04:25] <Riddell> asac: and gnome's network admin has two options, disconnect and disable?
[04:26] <asac> no ... network admin is only for setting up the interfaces ... not for starting/stopping them
[04:26] <asac> which shouldn't be done in an admin dialog anyways
[04:26] <mvo> Riddell: it should yes
[04:32] <asac> Tonio_: i added knetworkmanager to bug 123808 ... so maybe ask ogra in that bug
[04:32] <ubotu> Launchpad bug 123808 in network-manager-applet "NetworkManager Applet should not be started on LTSP Thin Clients" [Undecided,Invalid]  https://launchpad.net/bugs/123808
[04:33] <asac> (and maybe assign the knetworkmanager task to you)
[04:33] <Tonio_> asac: sure
[04:40] <asac> Tonio_: wanna help evaluate nm 0.7?
[04:41] <asac> i think we should start asap ... its a big shift an probably needs some thinking i order to integrate it perfectly in ubuntu ;)
[04:41] <Hobbsee> asac: is it released?  or your'e doing prework
[04:42] <asac> no ... its not released, but it will be ready for hardy ... i am sure.
[04:50] <stgraber> bdmurray, evand: You should now have access to /qapoll (https://iso.qa.stgraber.org/qapoll)
[04:52] <\sh> jdstrand, bug 146269 ready for review and upload for all supported ubuntu releases...thx :)
[04:52] <ubotu> Launchpad bug 146269 in openssl "[openssl security]  OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [Undecided,New]  https://launchpad.net/bugs/146269
[04:53] <jdstrand> \sh: thank you!
[04:53] <\sh> jdstrand, not for this :)
[04:54] <evand> thanks stgraber !
[05:07] <stgraber> evand: Propose bug isn't implemented yet though
[05:09] <wasabi> Bah. I'm sad I missed the meeting Ian is talking about =/
[05:11] <zul> wasabi: what meeting?
[05:12] <wasabi> iwj mentioned they talked about one click software installs during the desktop team meeting.
[05:12] <wasabi> Something I had a big interest in. Just didn't know anybody cared to talk about it. :0
[05:15] <iwj> wasabi: Don't worry about it.
[05:15] <iwj> The discussion in the meeting didn't really go anywhere.
[05:15] <iwj> It was all set to have us all arguing on IRC uselessly for ages so we decided to have the conversation on ubuntu-devel instead.
[05:16] <iwj> I don't think you've missed very much.
[05:16] <iwj> Do feel free to reply to my email posting.
[05:16] <wasabi> Ahh.
[05:16] <wasabi> I am drafting a message. Trying to think carefully. =)
[05:16] <wasabi> Which doesn't happen often to me.
[05:19] <janimo> pitti: hi, do language-support-xx packages need special treatment if they are being autogenerated? I'd like to add myspell-ro as a dep of language-support-ro and I am not sure if a regular upload would suffice
[05:20] <pitti> janimo: hey, long time no see
[05:20] <janimo> pitti: indeed :)
[05:20] <pitti> janimo: I'd prefer to do that with langpack-o-matic
[05:20] <pitti> otherwise the db there and packages will get out of sync
[05:20] <janimo> pitti: sure, should I file a bug in LP>
[05:20] <janimo> ?
[05:21] <pitti> janimo: I'll do it in a couple of minutes
[05:21] <janimo> pitti: ok, thanks
[05:27] <pitti> janimo: uploaded
[05:28] <janimo> pitti: thank you :)
[05:28] <pitti> np
[05:35] <pochu> pitti, jamiemcc: can we move the discussion here? It's hard to discuss the same thing in two different chans ;)
[05:35] <pitti> sure
[05:35] <jamiemcc> ok
[05:35] <pitti> I just wondered why tracker includes and builds a copy of o3read, and still Recommends: the external one
[05:36] <pitti> pochu: ./debian/tmp/usr/bin/o3totxt
[05:36] <pitti> pochu: seems that this is simply not installed
[05:36] <pochu> pitti: I've tried searching for odt files with tracker-search-tool, and it didn't work, but it is because trackerd is Indexing, so I'd have to wait to be sure whether it works or not.
[05:37] <pitti> however, *if* tracker ships its own o3read, then it shouldn't be in /usr/bin, otherwise it would conflict with the o3read package
[05:37] <pochu> Does o3read convert to txt?
[05:37] <pochu> yup it does
[05:37] <pitti> pochu: the package o3read has the o3totxt tool, too
[05:37] <pitti> (amongst o3tohtml and o3read)
[05:37] <jamiemcc> pochu: yes in combo with unzip
[05:38] <pitti> so, we generally prefer not to include cope copies, but use the external packages isntead
[05:38] <pitti> much easier for security maintenance, and much more obvious, too
[05:38] <jamiemcc> pitti: yes = I was sure we removed o3read
[05:39] <jamiemcc> pitti: does 03read work on latest opeoffice files (odt)?
[05:39] <jamiemcc> it works fine on feisty
[05:40] <pochu> jamiemcc: emilio@kiko:~/dev/deb/tracker/tracker-0.6.3/src/text-filters/ooo_converter$ ls
[05:40] <pochu> ChangeLog  Makefile.am  Makefile.in  o3read.c  o3read.h  o3totxt.c
[05:40] <pitti> jamiemcc: yes, at least for my small test fiel
[05:40] <pochu> jamiemcc: looks like you didn't ;-)
[05:40] <pitti> file, even
[05:41] <pitti> pochu: ok, so I'd prefer putting o3read into main and make it a tracker dependency
[05:41] <sladen> jamiemcc: how can I force trackerd to start  (having previous murdered it)
[05:41] <pitti> it's so tiny that a hard dependency doesn't hurt, and that will DTRT on upgrades
[05:41] <jamiemcc> sladen : reneable it in tracker-preferences
[05:42] <jamiemcc> and add it to session
[05:42] <jamiemcc> sladen: wait for 0.6.3 release though
[05:42] <pochu> pitti: ok
[05:42] <pochu> pitti, jamiemcc: o3read works fine here too (not a big odt file, but anyway...)
[05:43] <pochu> And with a big file too.
[05:43] <pitti> ok, MIR approved
[05:43] <sladen> (DTRT == Do The Right Thing)
[05:44] <sladen> jamiemcc: I don't want to wait, I want to carry on testing interactivity issues.  Only this time I can't pursuade it to foricebly start
[05:45] <jamiemcc> sladen: run it from command line : trackerd
[05:45] <pochu> pitti: ty. If you haven't uploaded tracker yet, can you wait so I can move it to Depends?
[05:45] <pochu> pitti: or add it yourself ;)
[05:45] <pitti> pochu: already done
[05:45] <pochu> great
[05:46] <sladen> jamiemcc: it's sitting there at a poll()
[05:46] <keescook> pitti, \sh: thanks for the heads-up; we'll get it published.
[05:46] <jamiemcc> sladen: trackerd --reindex
[05:47] <jamiemcc> sladen: ensure enable indexing and enable watching are enabled in prefs
[05:47] <sladen> jamiemcc: it still respects the 45second delay?
[05:47] <\sh> keescook, debdiffs are available for all actual releases...
[05:48] <jamiemcc> sladen: yes
[05:48] <keescook> pitti, bdmurray: isn't there an internal regression testing suite with postgresql?  I would argue that if it passes (and there are no ABI changes), that should be good for SRU?
[05:48] <pitti> pochu: ok, package prepared; how long have you tested this so far? it's running here now, but I want to have it sit here for a while and index
[05:48] <keescook> \sh: yes, thanks!  makes testing/publishing much easier!  :)
[05:48] <pitti> keescook, bdmurray: there is; both that, and the > 1000 postgresql-common tests which check the integration and the tools
[05:49] <pochu> pitti: ~ 2 days, and seems to work fine
[05:50] <pochu> appart of the Errors in tracker.log
[05:50] <sladen> jamiemcc: did 8 polls (files?) since then it did 3 more and it now back to doing nothing
[05:50] <keescook> pitti: that's more robust than a lot of things.  ;)
[05:50] <jamiemcc> pochu: do you still get those errors in log?
[05:50] <pochu> jamiemcc: 28 Sep 2007, 16:55:07:197 - ERROR: execution of prepared query CreateService failed due to constraint failed with return code 19
[05:51] <pochu> 28 Sep 2007, 16:55:07:217 - ERROR: CreateService uri is /home/emilio/dev/deb/decibel/decibel-audio-player_0.06-1.diff.gz
[05:51] <pochu> 28 Sep 2007, 16:55:07:217 - ERROR: could not get file id for /home/emilio/dev/deb/decibel/decibel-audio-player_0.06-1.diff.gz - unable to continue indexing this file
[05:51] <jamiemcc> sladen: wipe out $HOME/.local/share/tracker
[05:51] <jamiemcc> and restart with --reindex
[05:52] <jamiemcc> pochu: how many of those do you see roughly?
[05:52] <jamiemcc> pochu: with temp files you some times get that error as the file is quickly deleted
[05:53] <pochu> jamiemcc: there are also a lot of InsertWatch Error
[05:53] <jamiemcc> pochu: can you riun trackerd with -f in gdb and get me backtrace
[05:53] <pitti> ok, tracker 0.6.3 uploaded
[05:53] <pitti> jamiemcc: thanks a lot for that release
[05:53] <jamiemcc> pitti: thank you for applying
[05:54] <pochu> jamiemcc: sure, let's discuss this in #tracker, since it's a bit offtopic here
[05:54] <pochu> pitti: thanks!
[05:54] <jamiemcc> ok
[06:26] <mweichert> how do I properly set the $PYTHONPATH on ubuntu?
[06:26] <pitti> mweichert: for yourself -> ~/.bashrc, globally -> /etc/environment
[06:27] <pitti> (and yes, it's not #ubuntu-devel matter)
[06:27] <mweichert> pitti, but I don't want to override the PYTHONPATH... I want to append a directory to it
[06:28] <pitti> mweichert: PYTHONPATH="$PYTHONPATH:/foo"
[06:28] <mweichert> pitti, I'm not sure where to ask... I'm developing on ubuntu - I thought this would be the place
[06:28] <jamiemcc> seb128: patch here for tracker + gtk file dialog integration:
[06:28] <jamiemcc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443403
[06:28] <ubotu> Debian bug 443403 in libgtk2.0-0 "libgtk2.0-0: tracker support in gtk is broken" [Normal,Open] 
[06:28] <pitti> mweichert: rather #ubuntu
[06:28] <mweichert> pitti, hmm, but where does it get $PYTHONPATH from?
[06:28] <mweichert> pitti, if I do 'export' there is no PYTHONPATH variable
[06:29] <pitti> -> /query
[06:35] <sladen> jamiemcc: still not done anything since
[06:36] <jamiemcc> sladen: also try deleting your config file in $Home/.config/tracker
[06:47] <sladen> jamiemcc: [pid 26184]  fcntl64(825, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)   * 1000
[06:48] <jamiemcc> sladen: there will be erros in log if it cant open files
[06:48] <jamiemcc> sladen : log is in $Home/.local/share/tracker
[06:49] <seb128> jamiemcc: is that different of bug #132013?
[06:49] <ubotu> Launchpad bug 132013 in gtk+2.0 "gtk+ filechooser should use meta-tracker for searching" [Low,Fix released]  https://launchpad.net/bugs/132013
[06:50] <jamiemcc> seb128: yes its the same
[06:51] <seb128> jamiemcc: ok, already fixed then, pochu is going to close the tracker bug
[06:51] <jamiemcc> seb128: ok thx
[06:52] <pitti> bdmurray: re bug 140893, would you consider upstream and p-common test suite, as well as Stuart's and my tests sufficient for verification-done
[06:52] <ubotu> Launchpad bug 140893 in postgresql-8.2 "8.2.5/8.1.10 upstream microreleases available" [Undecided,Fix committed]  https://launchpad.net/bugs/140893
[06:52] <pochu> jamiemcc: I asked the same question on a different channel :p
[06:52] <pochu> jamiemcc: although you were first
[06:52] <pitti> bdmurray: ?
[06:53] <bdmurray> pitti: looking
[06:53] <pitti> bdmurray: it's one of those SRU microrelease exceptions packages
[06:54] <bdmurray> pitti: right, what was the url for the microexceptions again?
[06:54] <pitti> bdmurray: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[06:56] <bdmurray> pitti: yes, I would consider that sufficient
[06:57] <pitti> ok, thanks
[07:00] <engla> I've got a bug for gcc v4.1.2 from edgy. Is that worth reporting?
[07:02] <siretart> pitti: I just uploaded partman-target which should hopefully fix crypto on root from the installer side
[07:02] <pitti> siretart: !
[07:02] <pitti> you rock
[07:02] <pitti> siretart: I thought it was a bug in the initramfs script?
[07:02] <siretart> pitti: I therefore think it should be save again to promote partman-crypto to main again
[07:03] <siretart> pitti: no, the installer mustn't mangle UUIDs for crypto devices
[07:03] <siretart> it doesn't make sense, and just breaks the cryptoroot script
[07:03] <pitti> hm; that sounds more like a hack than a solution?
[07:03] <siretart> I think it is the right solution
[07:03] <pitti> hm, but don't the reasons why we switched to UUID in the first place also apply to crypto partitions?
[07:04] <siretart> after spending about 2h reading both partman-crypto and the cryptoroot-hook
[07:04] <siretart> pitti: I need to leave now
[07:05] <siretart> pitti: in short: partman-crypto creates 'pseudodevices' like that: /dev/mapper/*_crypt
[07:05] <pitti> right
[07:05] <siretart> pitti: I absolutely see no point in having them as UUID, since they are stable
[07:05] <pitti> siretart: ok, I'm sure you thought about this
[07:05] <siretart> cu later!
[07:06] <pitti> siretart: right, with LVM names this is nto necessary
[07:06] <pitti> siretart: see you, and thank you so much! *hug*
[07:06] <pitti> ogra: *melts*? is it so hot there? /me shivers from coldness
[07:07] <\sh> so...end of business+
[07:07] <ogra> pitti, 7pm, 30C and dark here
[07:07] <\sh> ogra, where are you? ,-)
[07:07] <ogra> \sh, cyprus
[07:07] <ogra> for 1.5 days
[07:08] <unggnu> hi all
[07:08] <\sh> ogra, -ENEID ,-)
[07:08] <pitti> mmm, Cyrpus; been there, wonderful island
[07:08] <ogra> \sh,  i dont think so  ... at least not ater trhat week ...
[07:08] <unggnu> mjg59, Hi, you are there?
[07:08] <ogra> and not with a flight that arrives at 3am ... after having nearly no sleep for some days
[07:09] <\sh> ogra, I'll greet your old home...I'm just on my way to belgium (belgische eifel) so I'll see Rohr passing by ;)
[07:09] <ogra> pitti, did you lts my g-p-m upload through today ?
[07:09] <ogra> \sh, -ENEID !!!!
[07:09] <mjg59> unggnu: Hi
[07:09] <ogra> s/lts/let
[07:09] <\sh> ogra, hehehe :)
[07:09] <unggnu> mjg59, Thanks, according to bug #136380 is there anything needed?
[07:09] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New]  https://launchpad.net/bugs/136380
[07:10] <ogra> \sh, i'd prefer to be there than here :)
[07:10] <\sh> ok guys....see you latest on monday again...
[07:10] <mjg59> unggnu: No
[07:10] <ogra> \sh, relax :)
[07:10] <mjg59> It just hasn't hit the top of my priorities yet
[07:10] <\sh> ogra, it gives me at least nice memories...the days at your old place :)
[07:10] <pitti> ogra: we flushed the unapproved queue, so if it was there, then 'yes'
[07:10] <ogra> :)
[07:10] <ogra> great
[07:10] <unggnu> mjg59, It is documented in the sony-laptop wiki and easy to test. But it is planned for Gutsy?
[07:10] <mjg59> Yes, it's planned for gutsy
[07:10] <ogra> there were the fixes for all the gconf defaults
[07:10] <unggnu> mjg59, Many thanks, sorry for bothering.
[07:11] <\sh> ogra, well, right now, it's not so good with relaxing...too many things to take care...combots is at its end...so I need a new job...
[07:11] <mjg59> unggnu: No problem
[07:11] <ogra> i somehow missed that all the g-p-m keys had submenus now
[07:11] <V-ille> Hi everybody.. anyone got a grasp about apt/dpkg upstream devel roadmap or some such? I have been thinking about a feature where packages could be installed by normal users.
[07:11] <ogra> err
[07:11] <ogra> subpaths :)
[07:11] <\sh> so...cu and don't break gutsy please ,-)
[07:11] <ogra> pfft
[07:11] <ogra> its still a development release :P
[07:12] <unggnu> Btw. don't know which one works on bug #127101 but the Patch seems to work.
[07:12] <ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [Unknown,In progress]  https://launchpad.net/bugs/127101
[07:13] <cjwatson> V-ille: it's not the first time it's been suggested, but AFAIK it's not on the roadmap and would require too many invasive changes to packages to be interesting. I suggest using GNU stow instead
[07:20] <V-ille> cjwatson: Yeah, stow probably does the job but apt-get would be nice. I don't know what kinda scheme has been thought before.
[07:20] <V-ille> cjwatson: I may be off the bat, but I thought that adding a per-user (and a per-user) package database with read-only access to sys pkg db would do the trick.
[07:21] <V-ille> cjwatson: The packages of course need to be relocatable and there's a ton of other issues to take care.
[07:21] <V-ille> cjwatson: per-user and a per-group, typo...
[07:25] <cjwatson> V-ille: relocatable packages would basically involve all the developers sitting down and doing nothing else for a couple of months but port packages, and would create a load of bugs at the end
[07:26] <cjwatson> our existing package format isn't remotely relocatable and there is a lot of intelligence in maintainer scripts
[07:26] <cjwatson> it's not something we're interested in doing, AFAIK
[07:27] <V-ille> cjwatson: Ok, it's just that this ability would have tons of uses, I have quite recently stumbled upon environments where that would be a real life-saver. Maybe one day. :)
[07:27] <cjwatson> there are a number of other ways you can solve the same problem
[07:27] <cjwatson> fakechroot is one of them
[07:28] <V-ille> cjwatson: Any pointers to more info?
[07:28] <cjwatson> and has the advantage of existing and being (relatively) non-invasive
[07:28] <cjwatson> fakechroot is a package ...
[07:29] <V-ille> cjwatson: That looks like a working solution, thanks a lot.
[07:31] <lamont> any thoughts on https://bugs.edge.launchpad.net/ubuntu/+source/console-tools/+bug/18575 ?
[07:31] <ubotu> Launchpad bug 18575 in console-tools "/etc/init.d/console-screen.sh Searches /etc/environment with wrong regexp." [Medium,Confirmed] 
[07:31] <lamont> what is console -screen.sh trying to do?
[07:32] <lamont> and should it just be matching the name, or anything that ends with the name?
[07:32] <lamont> hrm.. that's assigned to cjwatson...
[07:37] <slangasek> lamont: it's trying to set the locale in the environment using /etc/environment
[07:37] <slangasek> so the regexp is wrong
[07:37] <slangasek> because it should only be querying those exact variables
[07:39] <lamont> so for a package that uses dain-bramage system (dbs), what's the equivalent of "debian/rules patch"?
[07:41] <slangasek> "source.make", apparently
[07:44] <lamont>     [ "$ENV_FILE" ]  && CHARMAP=$(set -a && . "$ENV_FILE" && locale charmap)
[07:44] <lamont> already fixed in gutsy
[07:44] <slangasek> yes
[07:45] <slangasek> (not least of which by giving precedence to /etc/default/locale)
[07:45] <cjwatson> I just closed it :)
[07:45] <lamont> cjwatson: you beat me to it.
[07:45] <cjwatson> only delayed by bisecting uploads to find out exactly when it had been fixed
[07:46] <lamont> which makes console-tools another trigger-only upload.
[07:46] <lamont> cjwatson: overachiever! :-)
[07:46] <cjwatson> not like we really use console-screen.sh any more anyway
[07:47] <lamont> anyway, that gives us a shot at having hppa debootstrappable from ports.u.c
[07:47] <lamont> (in a day or so - the gcc builds aren't that quick on hppa - or anywhere else for that matter)
[08:06] <pochu> aptitude is installing recommended packages by default, but apt-get and gnome-app-install don't seem to. Aren't they doing it, or is there a setting anywhere I have disabled?
[08:09] <liw> pochu, apt-get got that feature in Debian just recently, I don't know (since I'm new to Ubuntu) whether it's incorporated into Ubuntu yet
[08:09] <Vegar> pochu: put APT::Install-Recommends "true"; in /etc/apt/apt.conf
[08:09] <Vegar> APT::Install-Recommends "true";
[08:09] <pochu> Vegar: the question is, is that enabled by default now?
[08:10] <Vegar> ah
[08:10] <slangasek> liw: well, ISTR mvo wrote it anyway. :)
[08:10] <liw> slangasek, yeah, but what with gutsy freezes and stuff it might still not be included :)
[08:13] <sladen> I thought that had already gone in
[08:13] <sladen> as part of moving lots of stuff from Depends: to Recommends:
[08:13] <sladen> so that things could be uninstalled without cause  *-desktop  to be uninstalled
[08:14] <mvo> pochu: its only enabled by default for metapackages (like ubuntu-desktop) currenty
[08:15] <mvo> pochu: the goal is to enable it by default globally, but that requires close coordination with debian
[08:16] <lamont> mvo: which, since sid now has that by default, means for hardy?
[08:17] <mvo> lamont: presumably, hardy is a lts so things may be different :)
[08:17] <lamont> right
[08:18] <lamont> I was thinking more since hardy would open up autosync with sid again (presumably - dapper did...), that we'd get that default change as well..
[08:20] <pochu> mvo: ok. I just thought it was already there, and it surprised me when it didn't work
[10:11] <stgraber> evand: the Propose my own part of qapoll is done, you can test it if you want
[10:12] <evand> stgraber: thanks, testing it now
[10:34] <bigon> hi, i'm trying to use pbuilder-dist to create a pbuilder chroot
[10:34] <bigon> pbuilder-dist gutsy create
[10:34] <bigon> and I get E: Type 'deb http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse' is not known on line 1 in source list /etc/apt/sources.list
[10:34] <bigon> at the end of the process
[10:35] <bigon> is it known
[10:35] <bigon> ?
[10:38] <stdin> bigon: take a look at https://wiki.ubuntu.com/PbuilderHowto
[10:39] <bigon> stdin: I have already a pbuilder running, I just want to test the pbuilder-dist ship with the ubuntu-dev-tools package
[10:40] <stdin> bigon: not sure if it's a bug or not, try looking on launchpad
[10:42] <ebrahim> Hi there! Why #kubuntu-devel is empty?!?!?!?
[10:44] <norsetto> ebrahim: don't know, ask in kubuntu-devel
[10:44] <ebrahim> lol
[10:45] <ebrahim> norsetto, thanks a lot!
[10:45] <norsetto> ebrahim: de nada
[10:45] <ebrahim> norsetto, no one is there!
[10:45] <norsetto> ebrahim: the buggers, no wonder we are still waiting for kde 4.0
[10:46] <ebrahim> norsetto, please explain more. What do you mean?
[10:46] <norsetto> ebrahim: don't mind me, I'm in bad-joke mode
[10:46] <ebrahim> norsetto, :D
[10:53] <cellofellow> hi
[10:56] <ebrahim> I was wondering if it is better to become an Ubuntu developer or a Debian one?!?
[11:04] <stgraber> evand: I have added a top-5 block
[11:44] <Riddell> ebrahim: you have not been on #kubuntu-devel
[11:44] <Riddell> you must have joined the wrong channel or on a wrong network
[11:45] <ebrahim> Riddell, right! I think it was my mistake! Thanks.
[11:50] <pwnguin> oh this is beautiful
[11:50] <pwnguin> http://www.getautomatix.com/forum/index.php?showtopic=1558&hl=gutsy
[11:51] <pwnguin> ""
[11:51] <pwnguin> "Automatix for Gutsy will NOT be backwards compatible with the previous versions. This will require the user to do a clean install for Gutsy or to run Automatix on Feisty and uninstall everything that Automatix has installed before the upgrade"
[11:52] <ion_> Hehe
[11:54] <pwnguin> it might be worthwhile for the dist-upgrader people (if they already havent) to contact automatix about doing this automatically
[11:55] <ion_> Im not sure anyone should spend any precious development time with anything regarding automatix. :-)
[11:55] <pwnguin> im not sure what purpose automatix has left
[11:56] <pwnguin> add/remove does quite well i think
[12:33] <Nafallo> could someone give back ekiga? it has it's damn opal now ;-)
[12:34] <pwnguin> cute