[01:37] <mikmor2> does modprobe -a get executed before the rc scripts get executed, i assume?
[02:12] <pedahzur> To whomever might be in charge of the installer and installer images;  Could you take a look at https://bugs.launchpad.net/ubuntu/+bug/130555  It is a real show-stopper for me at the moment.  Looking for feedback, as well as anything I can do to help further debug the prolem.
[02:12] <ubotu> Launchpad bug 130555 in Ubuntu "dapper boot.img is out of sync with installer cd" [Undecided,Confirmed] 
[02:14] <pedahzur> Or should I bug someone in #ubuntu-bugs?
[02:15] <mikmor2> If i were to do an update-rc.d within an rc script, would the effects take place during that run? Ie. is the script which runs the rc scripts going to cache the list of executed files before execution, and ignore any updates?
[02:18] <mikmor2> Maybe someone could point me to the program/script that calls the rc*.d scripts?
[02:18] <StevenK> pedahzur: Try http://us.archive.ubuntu.com/ubuntu/dists/dapper-updates/main/installer-i386/current/images/hd-media/boot.img.gz
[02:18] <StevenK> pedahzur: (Note the -updates in the URL)
[02:24] <pedahzur> StevenK: I will try that.  I didn't even think about looking in the updates.  Thank you!
[02:25] <pedahzur> You can reject that bug, or mark as fixed, if you want.  I'll reopen if that updated boot.img doesn't work.
[02:25] <StevenK> pedahzur: No problem.
[02:26] <StevenK> pedahzur: I can comment that I suggest you try -updates and we can take it from there, if you wish?
[02:27] <pedahzur> Sure.  It'll be a few days before I try.  I won't be back at the system until next weekend.
[02:29] <pedahzur> mikmor2: the script /usr/sbin/invoke-rc.d handles this.
[02:32] <mikmor2> cool.. it seems as long as the priority level isn't the same, it won't be cached.. thats good.
[02:42] <cjwatson> pedahzur: indeed, using dapper-updates is the right answer. I'll reject the bug now.
[02:43] <cjwatson> the image in /dists/dapper/ should still work fine if installing from the network or from original 6.06 CDs
[02:45] <cjwatson> mikmor2: /usr/sbin/invoke-rc.d is not hugely relevant here - /etc/init.d/rc is a better place to look for how things are invoked at boot
[02:45] <cjwatson> and it does collect the list of scripts to run in advance
[02:45] <pedahzur> cjwatson: Understood.  I didn't see anywhere that the boot.img gave me a chance to install from the network.  At least, I didn't get that far since it tried to load all it's network drivers from the CD.
[02:46] <pedahzur> cjwatson: Right!...I knew there was an "rc" script, I just couldn't find it for some reason.  I had forgotten it was in /etc/init.d
[02:47] <mikmor2> cjwatson: Yeah, i discovered that about an hour ago. thanks :)
[02:47] <cjwatson> pedahzur: ah, hd-media, sure - replace hd-media with netboot and you get one that can install from the network
[02:47] <mikmor2> cjwatson: For an update, 0.2-2 is soon to be available
[02:47] <mikmor2> aye guess not an hour..
[02:47] <mikmor2> heh
[02:48] <cjwatson> though hd-media is certainly a valid approach when boot.img and the ISO are in sync
[02:48] <mikmor2> been a long day :/
[02:48] <cjwatson> you're telling me, I've been working for I think 15 hours now
[02:48] <cjwatson> but I have finally got gutsy's syslinux and gfxboot to be friends
[02:48] <cjwatson> no, 16 hours. argh.
[02:49] <pedahzur> cjwatson: Sigh...now why didn't I see the boot.img under netboot...would have saved my self a lot of hassle. :)  That is, if netboot supports PPPOE.  At any rate, thanks for your help and pointers.  I'll know next time.
[02:50] <mikmor2> cjwatson: Ouch.. yeah, I remember talking to you at 3am
[02:51] <mikmor2> hmm.. i think my gui has a few aesthetic bugs
[02:51] <mikmor2> meh.
[02:51] <cjwatson> pedahzur: the installer doesn't really support pppoe in general yet - you can set it up after the install with pppoeconf
[02:52] <pedahzur> OK, so I still did need the hard drive/ISO installer.  But at least I know now how to get at what I need.  Thanks.
[02:54] <mikmor2> cjwatson: are there any plans to unify all of your image making scripts at some point?
[02:55] <cjwatson> mikmor2: it would be nice in theory but it's not on any roadmap at present
[02:57] <mikmor2> ah.. crap. I'm thinking using mercurial was a bad idea.. too young :/
[02:57] <mikmor2> The latest packaged mercurial version doesn't support symbolic links
[03:07] <mikmor2> \
[03:12] <alex_mayorga> Hello, I'm wondering if https://bugs.launchpad.net/bugs/121111 is ever in the map for Tribe 4
[03:12] <ubotu> Launchpad bug 121111 in linux-source-2.6.22 "Gutsy Tribe 3 CD don't load on Dell Inspiron 1501" [Medium,Triaged] 
[03:13] <alex_mayorga> I have the test system right here at my fingertips, FWIW
[03:17] <cjwatson> alex_mayorga: probably not tribe-4 at this point, sorry
[03:17] <cjwatson> we're freezing tomorrow and the kernel usually needs to land early
[03:18] <bddebian> Heya cjwatson
[03:18] <cjwatson> hi
[03:18] <alex_mayorga> cjwatson: so what can I contribute to get it fixed?
[03:19] <cjwatson> kylem: are you going to be around for a bit longer? if so, could you do new processing on gfxboot when it lands? it has a random new binary that can just be shoved into universe
[03:19] <cjwatson> alex_mayorga: I'm not a kernel hacker, sorry
[03:19] <cjwatson> if it's what I think it is, Ben and Tim have been spending a fair amount of time wrestling with it
[03:20] <alex_mayorga> just chiming in if they need any testing ;)
[03:20] <mjg59`> It's basically sorted upstream
[03:20] <mjg59> AMD are just crap
[03:21] <cjwatson> alex_mayorga: I think that's pretty clear from the bug :-)
[03:21] <bddebian> yep
[03:21] <bddebian> Hi mjg59
[03:24] <kylem> cjwatson, i'll be around for a while
[03:25] <cjwatson> thanks
[03:25] <alex_mayorga> #ubuntu-bugs
[04:10] <twb> Has anyone successfully netbooted the Feisty live cd?
[04:10] <twb> I'm getting "User not known to underlying authentication module."
[04:11] <reitblatt> twb: please use #ubuntu for support
[04:12] <twb> OK, sorry.
[04:13] <kylem> cjwatson, still around?
[05:07] <wasabi> eh is this tracker by default stuff fake or not
[05:08] <wasabi> oh, nope.
[05:08] <LaserJock> it's not fake
[05:08] <wasabi> bluh
[05:08] <LaserJock> heh
[05:09] <wasabi> it'd better not be a depend of ubuntu-desktop or i'll be angry. =)
[05:09] <ScottK> You'll be angry.
[05:12] <LaserJock> yeah, I haven't quite figured out how it's decided what goes in Depends and what goes in Recommends
[05:12] <ajmitch> wasabi: Recommends
[05:13] <wasabi> that's fine then
[05:13] <wasabi> i guess.
[05:13] <wasabi> i still fundamentally hate it. =/
[05:13] <wasabi> I think the entire concept of programs using it to STORE information is terribly flawed.
[05:14] <LaserJock> I don't need it, but it might be interesting to try out
[05:14] <wasabi> Simple indexor? Fine, I don't care. Storing actual data? That sucks.
[05:14] <LaserJock> I'm more interested in stringi
[05:16] <mjg59> Ok.
[05:16] <ajmitch> LaserJock: what's new?
[05:16] <mjg59> Why is trackerd running when I'm on battery?
[05:16] <LaserJock> mjg59: why wouldn't it?
[05:17] <wasabi> It has to run all the time, but it shouldn't ever do a full scan
[05:17] <mjg59> By running I mean causing lots of disk i/o
[05:17] <ajmitch> because battery life gets killed by disk seeks
[05:17] <wasabi> (it has to run to watch changes to prevent a full scan)
[05:17] <mjg59> Yeah, running is fine
[05:17] <wasabi> laptop mode should prevent it from seeking disk, no?
[05:17] <LaserJock> ajmitch: well, there is some GSoC with doing work on chemical indexing with stringi
[05:17] <mjg59> wasabi: No?
[05:17] <mjg59> (1) we don't enable laptop mode by default (the fact that it currently is is a bug)
[05:18] <mjg59> (2) laptop mode doesn't help avoid reads
[05:19] <wasabi> guess it's time to see how bad tracker sucks on NFS then
[05:19] <LaserJock> does anybody else have this in gutsy: rebooting causes first a re-login
[05:20] <mjg59> Also, why does it seem to store configuration in a flat file, rather than gconf?
[05:21] <wasabi> Where's it put it's dbs? ~? =/
[05:21] <mjg59> We've had this conversation. ~ is the right place.
[05:21] <wasabi> I was never satisfied with that conversation if I remember. :)
[05:23] <ScottK> Sorry.  Thought I was in MOTU.
[05:24] <ajmitch> nah, main doesn't have bugs
[05:25] <ScottK> Nope, sorry, package is in Main
[05:25] <LaserJock> darn
[05:29] <TheMuso> tracker?
[05:30] <RAOF> Beagle, written in C, which doesn't index quite as much stuff.
[05:30] <Amaranth> RAOF: What does beagle index that tracker doesn't?
[05:30] <RAOF> Web history?
[05:30] <Amaranth> The only thing I can think of is tomboy notes
[05:30] <Amaranth> Beagle indexes that?
[05:30] <RAOF> Yeah.
[05:31] <Amaranth> Heh
[05:31] <RAOF> With the firefox plugin.
[05:31] <Amaranth> Oh, screw that
[05:31] <RAOF> I'm not sure if anything loves epiphany, sadly.
[05:32] <Amaranth> I think beagle only does it because they had the dashboard cluepacket thing already :)
[05:33] <RAOF> Although tracker does do some stuff beagle doesn't.  It's got a dbus interface, for example.
[05:34] <StevenK> Oh great, more stuff that blows up/doesn't work when sbuild buggers up the running dbusd.
[05:35] <ajmitch> but dbus is great & wonderful & would never break
[05:35] <StevenK> And requires you reboot after an upgrade since upstream are dorks.
[05:37] <ajmitch> you make that sound like a bad thing
[05:43] <wolfe> need to install software? reboot
[05:44] <wolfe> need to change a setting in some special item, reboot
[05:44] <wolfe> sound familiar? Ubuntu has become Windows ;)
[05:44] <wolfe> *ducks*
[05:44] <ScottK> No need to duck now.  Only us peons here.
[05:45] <wolfe> =] 
[05:47] <LaserJock> I don't mind rebooting as long as it actually works and it's not for *everything*
[05:48] <LaserJock> I was on my Windows XP partition the other day, shesh, I can't even get into the thing before I"m rebooting like 3 times because of updates
[05:49] <StevenK> I don't mind that so much. What irritates the heck out of me is Windows popping up a message saying "Updates are installed. You need to reboot now.", and has a timer counting down 5 minutes. You click the Go Away button a few times, then you get distracted and the machine reboots anyway.
[05:51] <mikmor2> I am having the weirdest problem.. its like squashfs is rearranging my inodes..
[05:52] <wolfe> StevenK: I always set the computer policy to never reboot even for high security updates
[05:54] <StevenK> wolfe: I would, except I don't know where to do that. Besides the VMWare server that machine is on is down at the moment.
[05:55] <ScottK> Bug #130792 has a fix attached if any core-dev cares to upload it ...
[05:55] <ubotu> Launchpad bug 130792 in pygresql "python-pygresql requires libpq5 to work" [Medium,Confirmed]  https://launchpad.net/bugs/130792
[05:55] <StevenK> ScottK: SRU, or Gutsy?
[05:55] <ScottK> Gutsy
[05:55] <ScottK> Feisty has the same problem.
[05:55] <LaserJock> good grief, I *did* have to spill water all over my desk :(
[05:55] <ScottK> I can do a debdiff for that if you want it after Gutsy's fixed
[05:56] <StevenK> ScottK: Sounds fine, I just have to wait for my machine to polish off pdftk.
[05:56] <ScottK> K
[05:57] <wolfe> StevenK: open up mmc, file, add snapin, and find the Group Poliy Object editor
[05:57] <ScottK> StevenK: Nominated for Feisty, if you'd please accept it.
[05:58] <wolfe> you'll have to go under the computer tree, not the user, and find the update object
[06:00] <StevenK> ScottK: Accepted.
[06:01] <ScottK> Thanks.
[06:04] <StevenK> ScottK: Small niggling little concern. (LP :# 130792) -> (LP: #130792)
[06:05] <ScottK> Urgh.
[06:05] <ScottK> Want me to fix it?
[06:05] <StevenK> Yes please.
[06:05] <ScottK> The feisty-proposed debdiff I just attached to the bug has the same problem.
[06:06] <ScottK> Back in a flash.
[06:06] <StevenK> I was just about to say that...
[06:09] <ScottK> Done
[06:10] <ScottK> StevenK: Back over to you...
[06:10] <StevenK> ScottK: You've test built and installed for both Gutsy and Feisty?
[06:11] <ScottK> I test built for both.
[06:11] <ScottK> I installed for Feisty.
[06:11] <ScottK> Cause that's the machine it broke on me for.
[06:11] <StevenK> Does this bug also affect Debian?
[06:11] <ScottK> Yes and I linke the bug.
[06:11] <ScottK> linked
[06:11] <ScottK> even
[06:12] <StevenK> I see that. Sorry.
[06:12] <ScottK> No problem.
[06:12] <ScottK> Gutsy/Feisty have the same version currently.
[06:13] <StevenK> Right. The Maintainer for it is doko. I'm sure he'll upload a fix to Debian for this if you ask him nicely, and then you can request a sync.
[06:13] <LaserJock> awww crap
[06:14] <LaserJock> I suppose all the archive admins are asleep :/
[06:14] <StevenK> For the next 3 hours or so
[06:16] <infinity> We are?
[06:16] <ScottK> Well he's been sitting on a patch in Debian BTS for a while, so dunno how much of a rush he is for this in Debian.
[06:16] <mjg59> Hm.
[06:16] <mjg59> So.
[06:16] <mjg59> Tracker is still indexing my ~
[06:16] <infinity> LaserJock: What do you need an archive admin for?
[06:16] <mjg59> An hour after I logged in
[06:16] <mjg59> I'm not sold on this
[06:17] <infinity> mjg59: 30G of source trees?
[06:17] <infinity> mjg59: (That's what my home looks like...)
[06:17] <infinity> Well, and the porn.
[06:19] <StevenK> infinity: libnss-db!
[06:19] <LaserJock> well, my desktop-multiplier package got sent to NEW
[06:19] <LaserJock> but it was already NEW'd in dapper-updates
[06:20] <infinity> You had a NEW package in dapper-updates?
[06:21] <LaserJock> ... yes
[06:21] <LaserJock> Multiverse
[06:21] <infinity> I'm failing to see how that qualifies as an "update"...
[06:21] <LaserJock> it doesn't
[06:21] <LaserJock> but well, that's Canonical  ;-)
[06:21] <LaserJock> I just packaged the thing
[06:22] <StevenK> ScottK: Right, pdftk has let go. At this point, I'm rather inclined to ask doko about it.
[06:22] <ScottK> O.
[06:22] <ScottK> OK.
[06:23] <infinity> LaserJock: You realise it was FTBFS on all !i386?
[06:23] <LaserJock> infinity: it's i386 only
[06:23] <Burgundavia> infinity: dm is a binary package
[06:23] <Burgundavia> from my former employer, Userful
[06:23] <Burgundavia> ugh
[06:23] <infinity> Ahh.
[06:23] <infinity> LaserJock: Fair enough.
[06:23] <StevenK> infinity: Could I also beg you to let mlt out of binary NEW?
[06:23] <infinity> LaserJock: NEWed.
[06:24] <LaserJock> infinity: thank you kindly sir
[06:24] <Burgundavia> LaserJock: hopefully that will get them off your back
[06:24] <LaserJock> Burgundavia: haha, never!
[06:24] <StevenK> ScottK: Happy to upload the -proposed fix after Gutsy is sorted, or we have a plan for it.
[06:25] <ScottK> OK.
[06:25] <ScottK> I've done my bit, so up to you core-devs now...
[06:25] <LaserJock> infinity: I did set Architecture: i386 , that is the proper way to do it isn't it?
[06:26] <StevenK> LaserJock: The other bit is adding it to Packages-arch-specific, but you aren't able to do that.
[06:26] <LaserJock> StevenK: that's in the repo?
[06:26] <infinity> No.  It's in Debian CVS.
[06:26] <infinity> Me, lamont, and elmo maintain it.
[06:26] <LaserJock> I see
[06:27] <infinity> http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.695&root=dak&view=log
[06:29] <mjg59> infinity: Turns out to only be 20G
[06:30] <infinity> mjg59: That's still a crapload of source to index.
[06:30] <mjg59> Yeah
[06:31] <mjg59> I guess I can't really blame it too much
[06:31] <infinity> Developers aren't really average users in this sense. :)
[06:31] <infinity> (Though, surely it has a way to exclude directories?)
[06:31] <calc> mjg59: how is the amd64 vbetool stuff coming along?
[06:32] <mjg59> calc: Not had a chance to look
[06:32] <StevenK> Argh. My printer isn't configured on my server.
[06:32] <mjg59> Something very weird is happening
[06:32] <calc> mjg59: oh ok, np
[06:42] <infinity> StevenK: Is that just an SOVER bump?
[06:42] <calc> so new OOo that actually works will hopefully be uploaded in the next 6hr
[06:42] <calc> hmm i'll do the quick way to upload
[06:42] <infinity> It takes you 6 hours to upload OOo?
[06:43] <StevenK> infinity: mlt? Yup.
[06:43] <infinity> Someone send that man some bandwidth...
[06:43] <calc> infinity: ~ 2hr to build and probably 4hr to upload if i didn't wget the source, which i will do
[06:43] <calc> infinity: source of OOo 2.3 is ~ 260MB plus 21MB diff
[06:43] <calc> and my broadband upload is a bit crap
[06:44] <infinity> calc: Yeah, I know how big it is, I've had to upload it many times in the past.  Just that it didn't take me 4 hours. :P
[06:44] <infinity> (And I live in the third world, even...)
[06:45] <StevenK> No, worse. Melbourne.
[06:45] <infinity> I was referring to "Australia"...
[06:45] <StevenK> I wasn't. :-)
[06:45] <calc> infinity: i have 128kbps upload (i think) maybe more
[06:45] <infinity> Melbourne's the small gilmmering light at the end of this tunnel you call a country. :P
[06:45] <calc> infinity: i don't own the place i am currently living in so not really certain
[06:45] <infinity> calc: Ouch.  I'm at least at a megabit.
[06:45] <StevenK> No, the Yarra River is the asshole of Australia and Melbourne is 80km up it.
[06:45] <calc> it would definitely take over an hour to upload
[06:46] <calc> so i logged into the server and wget it at 500KB/s much better :)
[06:47] <infinity> StevenK: Oh yeah?  Well.  Well.  People in Sydney are big meanieheads!
[06:47] <StevenK> Oh, gah. Why do I think the reason CUPS can't authenticate me is that the cupsys user isn't a member of a shadow.
[06:47] <StevenK> infinity: :-D
[06:47] <infinity> StevenK: (And you lack culture, grit, and any sort of life there)
[06:47] <infinity> StevenK: mlt NEWed.
[06:48] <StevenK> infinity: Thanks. I like to think I'm at least a little cultured, since I follow the AFL.
[06:48] <infinity> *cough*
[06:48] <StevenK> Or something. :-)
[06:48] <infinity> Alright, so, AFL is Melbourne's most obviously poor contribution to the world.
[06:48] <StevenK> Hahaha
[06:49] <infinity> But there are lots of things here that just feel very "real" and such, in the same way that I feel in New York or London.
[06:49] <StevenK> More so than Sydney?
[06:49] <infinity> Sydney just made me feel like I was in a sterile 1960's future city, where people should all be wearing white and exchanging pleasantries.
[06:50] <StevenK> I really dislike the CBD of Sydney. I avoid it at all costs.
[06:51] <infinity> See, and Melbourne's CBD is quite interesting.
[06:51] <infinity> Like a very, very, very tiny Manhattan.
[06:52] <infinity> Sydney's CBD is "pretty", but it seems artificial.  Like no emotion went into the design of any of it, just architects trying to make sure people had a calm and pleasant afternoon.
[06:52] <StevenK> Sounds about right.
[06:53] <Burgundavia> a lot of cities are like that
[06:53] <infinity> And, to be fair, as a downtown by, I do tend to judge a city by its CBD.
[06:53] <infinity> s/by/boy/
[06:54] <Burgundavia> most CBDs got screwed up by the 60s/70s mad rush to concrete and large highways
[06:54] <infinity> Burgundavia: Nothing wrong with concrete and highways, as long as the grit and life of the area lives on.
[06:54] <Burgundavia> large highways destroy urban cores
[06:54] <Burgundavia> observe Seattle
[06:55] <infinity> LA is a better example.
[06:55] <Burgundavia> the waterfront is a tourist ghetto because of the Alaskan Way
[06:55] <infinity> Downtown Los Angeles is one of the worst places on earth.
[06:55] <Burgundavia> most Cali cities are like that
[06:55] <calc> LA is fun to drive in with no protected left turns
[06:55] <StevenK> infinity: Downtown LA is worse than Sydney? :-)
[06:55] <Burgundavia> precisely why I am shooting for a Masters in Urban Planning
[06:55] <infinity> StevenK: Differently so.
[06:55] <Burgundavia> time to fix all that
[06:56] <Burgundavia> no country on earth worships the cult of the automobile quite like the US
[06:56] <infinity> StevenK: Lots of the LA suburbs are kind Sydney-esque, but the actual city of Los Angeles was completely bypassed by several freeways, and it's become a dirty hole.
[06:56] <calc> i think the only really nice city i have been in the US has been cambridge/boston
[06:56] <infinity> StevenK: Lots of insurance companies and such still have headquarters there, but no one in their right mind works late, for fear of leaving the office after dark.
[06:57] <StevenK> Neat. :-/
[06:58] <infinity> In all the ways that Manhattan's dirt is almost charming and lends an air of vitality and life, LA's dirt is just scummy and scary.
[06:58] <infinity> The suburbs are all much nicer, but they have the Sydney "fake happy" feel about them.
[06:58] <ScottK> calc: Nice if you don't have to drive there.
[06:59] <calc> ScottK: actually has mass transit too, at least to some extent
[06:59] <calc> of course i have only been there once and didn't have to drive
[06:59] <ScottK> True.
[06:59] <ScottK> Boston drivers are deservedly notorious
[06:59] <ScottK> That's from someone who considers driving in downtown Manhattan "Fun".
[07:00] <infinity> Manhattan driving isn't too bad, until you get gridlocked with eight thousand taxis and for thousand delivery vans.
[07:00] <infinity> I have yet to understand why people drive private vehicles in Manhattan.
[07:00] <infinity> s/for/four/
[07:01] <infinity> (Well, except to get them OUT of Manhattan on vacation, which is why I was driving there)
[07:01] <infinity> In retrospect, I'd have been saner to rent a car outsidethe city and take a train to pick it up.
[07:04] <infinity> Melbourne driving is fun (hook turns!), but I don't own a car, cause the transit here is pretty decent, and I live 10 mins out from the CBD.
[07:05] <calc> houston is so spread out that even though the traffic isn't as bad it takes forever to get anywhere
[07:05] <infinity> (For the uninitiated, picture a wide turn -- left in America/Europe, or right in the UK/Australia -- and now picture doing it out of the far opposite lane.  That's a hook turn)
[07:05] <calc> they have all these useless things called trees around
[07:06] <calc> infinity: wouldn't that cause massive wrecks?
[07:07] <infinity> You'd think.  Mostly it just causes a lot of honking at timid people who refuse to perform the operation before the light turns red.
[07:07] <StevenK> Sounds like Sydney. The outskirts of suburbia in Sydney is Penrith which is over 55km from the CBD
[07:08] <StevenK> Oh, I'd like to see my mother do a hook turn, just once.
[07:09] <infinity> Zofia's mother actually burst into tears attempting one.
[07:09] <infinity> I find the Melbourne CBD fun to drive in.  Whenever I rent a car to go out of the city, I rent from a CBD dealer intentionally, just to have some fun.
[07:10] <ScottK> infinity: In the US, what you are calling Hook Turns are common in New Jersey.  Dunno what they call them.
[07:10] <ScottK> Ah.  I remember.
[07:10] <ScottK> Jug handle turns.
[07:10] <infinity> ScottK: Hrm, my Jersey experience is limited to Jersey City, but I didn't see any.
[07:10] <infinity> ScottK: Are there train tracks involved, or any other such "valid" excuse?
[07:10] <infinity> (In Melbourne, it's the trams that have led to this bizarre situation)
[07:10] <ScottK> Of course they have lots of "traffic circles" AKA roundabouts too.
[07:11] <ScottK> No, they just thought it would be a good idea to turn right all the time.
[07:11] <infinity> I like roundabouts.  Veru rapid traffic handling.  The only thing I don't like about them is my tendency to take them at 100+, and then wonder how soon I'll need to replace my tires.
[07:12] <infinity> ScottK: Err, you're misreading.  I'm talking about (from a North American perspective) turning LEFT from the far RIGHT HAND lane.
[07:12] <ScottK> Ah.
[07:12] <infinity> ScottK: So, cutting across two lanes of same-flow traffic before cutting across three lanes of oncoming.
[07:12] <ScottK> Nevermind then.
[07:12] <infinity> AKA: Insanity.
[07:12] <ScottK> No, we don't do that here.
[07:12] <ScottK> At least not legally.
[07:13] <StevenK> Heh
[07:13] <nixternal> ScottK: like DuPont Circle..that is fun to race around
[07:14] <ScottK> Argh.  To much traffic, too slow.
[07:14] <nixternal> not at 2am
[07:14] <ScottK> NYC in a rental car....
[07:14] <ScottK> True
[07:14] <nixternal> NYC in anything is nuts
[07:14] <nixternal> just like Chicago
[07:14] <nixternal> and LA
[07:14] <ScottK> No, I've driven all those places, NYC is different.
[07:15] <nixternal> ya, different != deadly :)
[07:15] <nixternal> Boston, the great dig, go around it if you can
[07:16] <realist> infinity: you live in Melbourne?
[07:17] <ScottK> Although I do remember being in Chicago and asking directions on the "L" and being told, "Don't go that way.  That way is South.  Go that way and you won't come back."
[07:17] <StevenK> Finally, two Ubuntu and one Windows machine talking to the printer.
[07:18] <StevenK> Bloody spawn of the devil things.
[07:19] <realist> infinity: do you live in Melbourne?
[07:20] <infinity> realist: Yes.
[07:22] <StevenK> infinity: Can we talk about libnss-db now as opposed to driving? :-)
[07:23] <realist> StevenK: I had to install proprietary printer drivers + a supplied CUPS (albeit GPL) wrapper to get my printer working
[07:23] <infinity> StevenK: We could, after I have lunch. :)
[07:23] <StevenK> infinity: Little late for lunch, isn't it?
[07:24] <realist> I feel somewhat 'unclean' from the experience
[07:24] <StevenK> realist: I had no problems on the machine the printer is connected to, or the Windows machine. It was my desktop that gave the trouble.
[07:24] <StevenK> Mostly because CUPS wouldn't tell me the IPP URI I had to use for the printer and I had to guess.
[07:25] <Mithrandir> morning
[07:26] <StevenK> Morning Mithrandir
[07:26] <realist> StevenK: ahhh. I had to manually specify the URI in my case.
[07:26] <StevenK> Mithrandir: How was your VAC?
[07:27] <Mithrandir> StevenK: good.  Horseback riding is fun, and my lower back seems to have untensioned itself quite a bit.
[07:30] <StevenK> !!!
[07:30] <infinity> StevenK: My timezones are out of whack.
[07:30] <StevenK> grep-dctrl is listed as NBS.
[07:31] <StevenK> infinity: You're set to Perth time?
[07:32] <infinity> StevenK: Somewhere in between Melbourne, London, and Hong Kong, with a touch of Hawaii.
[07:37] <realist> infinity: Which when all added is roughly Perth time ;-)
[07:42] <ScottK> Well that's going to generate 133,068 DNS PTR queries.  I wonder if my ISP will get annoyed....
[07:43] <StevenK> ScottK: What is?
[07:44] <ScottK> My program I just launced
[07:44] <ScottK> launched.
[07:44] <ScottK> I'm doing some statistical analysis for a client on anti-spam stuff
[07:44] <StevenK> That's a little ... excessive.
[07:44] <ScottK> And I needed a bunch of PTR records.
[07:45] <ScottK> Well there's over 5 million messages in the set, so that didn't seem so bad.
[07:45] <ScottK> I expect this one will have to run for a while.
[07:47] <ScottK> Now only 41,096 are unique IP addresses, so caching will help me some here.
[07:56] <ScottK> Good $TIME_OF_DAY.  I'm goint to bed.
[08:08] <mjg59> Tracker /still/ going
[08:09] <RAOF> Eh, mine's crashed :)
[08:09] <mjg59> Does it log anywhere?
[08:13] <mjg59> Why does trackerd have libthai stuff open all the time?
[08:13] <mjg59> It is a very odd application
[08:27] <LaserJock> mjg59: just write a blog post about it, then you'll totally be a forums hero ;-)
[08:28] <mjg59> Haha
[08:28] <calc> keescook: here?
[08:29] <Burgundavia> mjg59: http://www.getautomatix.com/forum/index.php?showtopic=1454
[08:30] <LaserJock> Burgundavia: some army we have ;-)
[08:30] <Burgundavia> heh
[08:30] <RAOF> I'm glad to hear cannonical has an army :)
[08:30] <LaserJock> and here I was working my butt of for nothing
[08:30] <LaserJock> *off
[08:32] <Burgundavia> RAOF: no, they secretly fund an orbital laser via GNOME which they "borrow" occasionally
[08:32] <LaserJock> hmm, that sounds fun
[08:33] <Burgundavia> all about the plausible deniablity, Canonical is
[08:36] <jsgotangco> heh
[08:36] <pitti> Good morning
[08:36] <Burgundavia> morning pitti
[08:37] <LaserJock> uh oh, is this tribe 4 freeze? :-)
[08:37] <StevenK> Morning pitti
[08:37] <pitti> hey guys
[08:37] <calc> pitti: hey
[08:37] <pitti> LaserJock: I'll check the current situation first :)
[08:37] <calc> pitti: got the stuff uploaded into my ~ccheney/incoming dir
[08:37] <StevenK> pitti: I have a whole bunch of stuff that can be NBS'd, shall I rattle it off? :-)
[08:37] <pitti> hi calc; oh, nightshift, too? :)
[08:37] <calc> pitti: yea been working to get it finished in time
[08:37] <pitti> StevenK: I can just look at the list
[08:38] <calc> pitti: just finished uploading it a few min ago
[08:38] <StevenK> pitti: They aren't zero sized since they all interdepend.
[08:38] <pitti> calc: wow! so, does new OO.o actually work now? :-)
[08:38] <pitti> StevenK: fire away :)
[08:39] <calc> pitti: i believe so, i tested the build a couple days ago, i haven't had time to finish the uploaded build locally to actually test it :\ but the one in gutsy is broken
[08:39] <calc> pitti: i should be able to test it within 2-3hr (when it finishes locally)
[08:39] <StevenK> pitti: libquicktime0 libmiracle0.2.2 libmlt0.2.2 libmlt0.2.2-data
[08:39] <ajmitch> morning pitti
[08:40] <calc> pitti: it fully built earlier today and i forgot to test it before accidentally rm
[08:40] <calc> pitti: rm'ing the debs :\
[08:40] <StevenK> pitti: Oh, and libvalerie0.2.2
[08:40] <pitti> calc: erk, too bad
[08:40] <StevenK> calc: Don't. Use rsync?
[08:40] <pitti> calc: but did you still have the built tree?
[08:40] <ajmitch> ouch
[08:40] <calc> pitti: so in the process of building it again
[08:40] <calc> pitti:  no :(
[08:40] <ajmitch> so it's a case of "it compiles, ship it"?
[08:41] <StevenK> pitti: If the i386 buildds catch up, libapache-mod-log-sql{,-{dbi,mysql}} should also be able to be killed after the publisher next runs.
[08:41] <calc> ajmitch: no i'm intending to stay up and verify its actually good, i did test it a couple days ago and it was good at that time, but i have made a few changes since then and the current version isn't tested as is yet
[08:41] <calc> should take less than 3hr to finish the build
[08:41] <ajmitch> calc: darn, I was going to ask pitti if I could do that to sneak f-spot in :)
[08:42] <pitti> ajmitch: we are not yet frozen, so if you don't break anything, go ahead :)
[08:42] <ajmitch> pitti: I've got to get it built first
[08:43] <pitti> (OTOH, its badly broken ATM anyway)
[08:43] <pitti> ajmitch: does that fix the crash when closing?
[08:43] <calc> i'm going to take a nap and come back in about 3hr should be built by then (2am here right now)
[08:43] <ajmitch> still at the 'merge stuff in & make sure it's in a buildable state' stage
[08:43] <Mithrandir> *sigh*; the worst thing about vacations, or rather, the end of vacations is the pile of email awaiting me when I get home.
[08:43] <pitti> ajmitch: good luck then!
[08:43] <pitti> hey Mithrandir
[08:43] <calc> ajmitch: merges are so much fun ;)
[08:43] <pitti> Mithrandir: *phear*
[08:44] <ajmitch> calc: well, it's merging a couple of bzr branches
[08:44] <calc> i disabled the multithreaded build so i'm actually building both ooo and ooo-l10n at the same time to speed things up a bit
[08:44] <Burgundavia> Mithrandir: I look forward to the giant pile after 4 weeks in SA
[08:44] <Mithrandir> Burgundavia: indeed.  This is only from Wednesday afternoon, so a little less than a week
[08:45] <calc> i think disabling the multithreaded build will probably solve the random ooo build failures and at the moment its completely broken anyway so had to be disabled
[08:45] <Mithrandir> and people keep cc-ing me on threads posted to mailing lists.
[08:46] <StevenK> Mithrandir: I don't get that problem since Cyrus does duplicate detection.
[08:46] <pitti> calc: right, I was just going to ask: we need -l10n, too
[08:46] <StevenK> Oh, a thank you e-mail for updating Kino in Gutsy.
[08:47] <calc> pitti: yea
[08:47] <StevenK> Mithrandir: Even if Cyrus is ... special.
[08:47] <Mithrandir> StevenK: and it's smart enough to know that "if this mail is sent to a list and Cc-ed (and sent to those other two lists)" it just elides it from your inbox, not the list boxes?  Or does it mark them as read there?
[08:47] <pitti> StevenK: removed
[08:47] <StevenK> pitti: Thanks
[08:47] <calc> pitti: ok well i'm off to bed for a bit, but i'll be back in about 3hr
[08:47] <pitti> calc: sleep well!
[08:47] <calc> if anyone needs me msg me and i will see it when i wake up
[08:47] <calc> have a great morning :)
[08:48] <StevenK> Mithrandir: I think hashes the mails as they come in, and discards messages that have been seen. Of course hashes expire out of the cache fairly quickly.
[08:48] <StevenK> I think it, even
[08:49] <Mithrandir> StevenK: but I don't want to expire them, I just want them to not be listed in my inbox.
[08:49] <ajmitch> StevenK: I do similar with procmail
[08:50] <StevenK> ajmitch: Using formail, right?
[08:51] <ajmitch> yes
[08:51] <ajmitch> seems to work well enough
[08:51] <realist> I think mutt handles duplicates sanely (via X-Follow-Up-To header, or some such)
[08:57] <StevenK> infinity: Surely you're back from lunch by now. :-)
[08:58] <realist> StevenK: perhaps they were _really_ hugry... I hear jet lag does that
[09:06] <pitti> hey sabdfl
[09:06] <sabdfl> howdy pitti
[09:09] <ajmitch> sigh, need batteries for the camera to test importing photos
[09:09] <RAOF> Yay!  It seems something in my home directory can deterministicly crash trackerd.  Let's turn the logging up to 11!
[09:12] <Burgundavia> sabdfl: are you free for a CC meeting this week? On the 12th I fly out for a 4 week vacation
[09:15] <StevenK> pitti: Looks like dctrl-tools no longer provides a grep-dctrl package. Changing {Build-,}Depends is simple. Can you eyeball the list at http://people.ubuntu.com/~ubuntu-archive/NBS/grep-dctrl and see if there is anything I should keep my hands off?
[09:16] <pitti> StevenK: please don't rebuild the installer bits right now (let's do that after tribe)
[09:16] <pitti> StevenK: the rest and universe bits are ok
[09:17] <pitti> StevenK: meh, I wish dctrl-tools would at least Provide: grep-dctrl; that would be sufficient
[09:17] <StevenK> pitti: It does.
[09:18] <pitti> oh, indeed; multiple-versoin apt-cache show output fooled me
[09:18] <pitti> StevenK: so, then it's fine to just remove it
[09:18] <pitti> StevenK: buildds will DTRT for that as a build dep
[09:18] <StevenK> And apt should as well.
[09:19] <StevenK> Debian should change most of them itself, and the changes can trickle down.
[09:19] <StevenK> pitti: Kill it at your leisure ...
[09:19] <ajmitch> yay, segfault on exit, makes me suspicious of other libs
[09:19] <pitti> ajmitch: I had that as well
[09:20] <ajmitch> I know, but this is with 0.4.0
[09:20] <ajmitch> so there's no change in that behaviour, but at least it's just irritating rather than data-munching
[09:27] <pitti> (just to stop doko from uploading yet another glibc :) )
[09:28] <ajmitch> heh
[09:28] <StevenK> Haha
[09:28] <pitti> the previous one is still building...
[09:29] <StevenK> pitti: But only on sparc.
[09:30] <pitti> and it'll still take some three hours
[09:30] <pitti> screw it, I'll build the server isos later then
[09:30] <StevenK> Heh
[09:33] <pitti> ah, glibc i386 is in accepted
[09:38] <asac> pitti: Waiting for approval: midbrowser 0.1.6a-0ubuntu1 (source) ... any chance?
[09:38] <pitti> asac: read the announcement; universe is not frozen :)
[09:38] <pitti> to match the email announcement
[09:39] <asac> pitti: hehe ... sorry ;) its early in the morning
[09:39] <asac> pitti: what would you think about https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x ?
[09:39] <pitti> asac: heh, I was just going to ask you about the status of the two n-m tribe4 bugs
[09:39] <asac> the two?
[09:39] <asac> which ones?
[09:40] <pitti> bug 121439 and bug 128360
[09:40] <ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
[09:40] <ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
[09:40] <asac> yeah i hope that a bunch of ipw3945 issues are gone
[09:41] <seb128> doh, already frozen :/
[09:41] <seb128> hey pitti
[09:41] <asac> however ... for open network ... with ipw3945 is still a problem
[09:41] <seb128> pitti: you are too quick to freeze ;)
[09:41] <pitti> seb128: <pitti> (just to stop doko from uploading yet another glibc :) )
[09:42] <seb128> erf
[09:42] <pitti> seb128: bug fixes are always welcome, don't worry
[09:42] <seb128> ok, good ;)
[09:44] <pitti> asac: looks good! did you get any feedback from ipw3945 users? (wrt. #121439)
[09:45] <pygi> hello
[09:47] <asac> pitti: i tested a lot with stgraber ... we fixed the ipw3945 wpa issue (for him)
[09:47] <pitti> cool
[09:47] <asac> pitti: however i would really like to get positive feedback from other chipsets
[09:48] <pitti> asac: just upload it now; we still have time to fix or revert patches if there's trouble
[09:48] <pitti> asac: please ask for testing the new version in the bug
[09:48] <mikmor2> asac: Is that bug only in gutsy?
[09:49] <asac> pitti: ok doing so now
[09:49] <pitti> seb128: can you reproduce bug 107109? mvo can't, and if you can't either, I'll just move that to tribe5 (it might not exist any more)
[09:49] <ubotu> Launchpad bug 107109 in compiz "No "New Login" for user with Desktop effects enabled" [High,Incomplete]  https://launchpad.net/bugs/107109
[09:49] <asac> mikmor2: yes and no
[09:49] <pitti> mvo: did you do the g-a-i db update?
[09:50] <seb128> pitti: the guy is running feisty, do you want me to test on 7.04?
[09:50] <mvo> pitti: not yet, but it is scheduled for today (I will do a apt upload now to fix a bug in apport install error reporting)
[09:50] <pitti> seb128: no, current gutsy
[09:50] <pitti> seb128: just concerned about the tribe4 bugs
[09:50] <mvo> hey carlos!
[09:51] <carlos> mvo: hey!
[09:51] <seb128> pitti: no such bug
[09:51] <seb128> pitti: we got no duplicate and the user is not using gutsy, not sure why it has been milestoned
[09:51] <pitti> seb128: you mean, it doesn't happen for you?
[09:52] <seb128> no bug, it works fine
[09:52] <stgraber> asac: did you find a way to fix Open Networks ?
[09:52] <pitti> seb128: cool; let's tentatively close it then
[09:53] <pitti> mvo, seb128: I didn't see bug 123078 since the last tribe any more, and this looks quite dead; I'm prone to close it, too, do you agree?
[09:53] <ubotu> Launchpad bug 123078 in gnome-session "System -> Quit takes a long time to appear" [Low,Incomplete]  https://launchpad.net/bugs/123078
[09:54] <mjg59> pitti: Isn't that just the GPM interface name change?
[09:54] <pitti> mjg59: depends
[09:54] <pitti> mjg59: it could either have been that renaming (in tribe2 AFAIR)
[09:54] <seb128> pitti: I think an user told me he had session issue and that has been fixed with some update, I would just close it as fixed and ask them to reopen if somebody still get the bug
[09:55] <pitti> mjg59: or it could be compiz failing to connect to the session, timing out after 60 seconds, in which case it blocked all the other desktop session apps from connecting
[09:55] <mjg59> Ah, I see
[09:55] <asac> stgraber: unfortunately not yet
[09:56] <pitti> seb128: I agree; kill it :)
[09:57] <mjg59> seb128: Tracker is currently... painful on laptops
[09:57] <seb128> mjg59: what it is doing?
[09:57] <mjg59> seb128: It'll happily index on battery
[09:57] <seb128> mjg59: you can open bugs on launchpad, upstream is subscribed to it
[09:57] <asac> pitti: network-manager_0.6.5-0ubuntu8_source.changes uploaded
[09:58] <seb128> ah, not nice, that was supposed to be fixed in 0.6
[09:58] <RAOF> That should be pretty easy to fix, really.
[09:58] <mjg59> seb128: Yeah, have done
[09:58] <seb128> good
[09:58] <mjg59> seb128: Is it deliberate that -desktop doesn't pull in the preferences?
[09:58] <mjg59> Or the search tool?
[09:58] <stgraber> asac: I also have another issue here which is like ipw3945 isn't scanning properly, once connected to a network it tends to hide all the others and sometimes only show the 2-3 strongest hiding my main network which is in another room. But this looks like an ipw3945 bug (same behaviour checking with iwlist eth1 scanning)
[09:59] <pitti> mvo: since you can reproduce bug 119341, can you please do bryce's test?
[09:59] <ubotu> Launchpad bug 119341 in xorg-server "glxinfo command causes Xorg to abort on Dimension E520" [Unknown,Confirmed]  https://launchpad.net/bugs/119341
[09:59] <seb128> mjg59: not really, I though about it yesterday but I think it's a bit later to change meta packages for the tribe now
[09:59] <mikmor2> asac: Do you mind me asking you the status of that bug (121439)?
[10:00] <asac> bug 121439
[10:00] <mvo> pitti: checking
[10:00] <ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
[10:00] <cjwatson> oops, I forgot to update cdimage to match the string change in gfxboot-theme-ubuntu
[10:00] <cjwatson> oh well, no disaster
[10:00] <asac> mikmor2: the upload i just did should allow you to connect to wpa networks
[10:00] <mjg59> seb128: Ah, ok. It just seemed kind of odd to have the daemon starting by default, but no way of using it :)
[10:00] <mikmor2> asac: ah, thats what I was waiting for. Thanks.
[10:01] <mikmor2> asac: Has anyone check it on the E1505?
[10:01] <seb128> mjg59: I'm going to rebuild nautilus to use
[10:01] <mjg59> Sweet
[10:01] <mjg59> seb128: The other weird thing is that its configuration seems to be a flat text file rather than in gconf - any idea about that?
[10:02] <mikmor2> asac: I don't see your fix..
[10:02] <stgraber> mikmor2: I tested it on :  Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) (8086:4222)
[10:03] <seb128> mjg59: no
[10:03] <mjg59> Fair enough
[10:03] <RAOF> mjg59: From my reading of the tracker ML, the author wants it to be DE neutral, so no gconf dependency.
[10:03] <mjg59> Hm. Irritating.
[10:04] <seb128> I'm busy enough with GNOME so I did really look at tracker
[10:04] <asac> mikmor2: i uploaded it a few minutes ago ... so might take a while
[10:04] <mikmor2> Ok. I have a 8086:4222 in front of me with a fresh install, which I would like to test it on.
[10:04] <pitti> mvo: is bug 129669 easy to fix? if you touch g-a-i anyway, this might be a good target; it's not a showstopper, though, so I drop the milestone
[10:04] <ubotu> Launchpad bug 129669 in gnome-app-install ""Show:" textbox has no text after program start" [Medium,Confirmed]  https://launchpad.net/bugs/129669
[10:04] <seb128> just got in seeded because we said we wanted to give it a try
[10:04] <mikmor2> great.
[10:04] <RAOF> Indeed.  Maybe we could point him in the compiz route, and have pluggable config backends :P
[10:04] <stgraber> mikmor2: running amd64 or i386 ?
[10:04] <seb128> s/did really/didn't really
[10:04] <mikmor2> stgraber: i386
[10:04] <stgraber> mikmor2: ok, so you'll need to wait a few hours :) my test packages are amd64
[10:05] <mikmor2> stgraber: for more information, http://linux.dell.com/wiki/index.php/Tech/Wireless/Intel_IPW3945 http://linux.dell.com/wiki/index.php/Clients/Products/Inspiron_1505n/lspci
[10:06] <stgraber> ok, I've the exact same chip in my HP laptop and WPA works fine (still issue with Open Networks)
[10:07] <mikmor2> Is there a quick recipe for that bug?
[10:08] <asac> stgraber: i made the deactivate in stage1 more aggressive ... maybe it helps in open networks
[10:08] <mvo> asac: when I'm in "manual configuration mode" in network manager it seem to tell the world (i.e. pidgin and epiphany) that I'm offline. is that a known issue?
[10:09] <asac> mvo: not in my mind-set ... though there might be a bug
[10:09] <stgraber> anyone knows why irssi tends to freeze inside of screen, it's becoming really annoying ? :) (always happen on irssi window change ...)
[10:09] <mvo> asac: you want me to report it? I think that this is a regression, it used to work some days/weeks ago
[10:10] <RAOF> stgraber: I use irssi in screen exclusively, and I haven't seen that at all.
[10:10] <asac> mvo: let me see if i can find a bug ... otherwise, yes.
[10:10] <stgraber> asac: oh, something else I noticed, "Connect to Other Wireless Networks" tends to crash nm-applet, after relaunching it it works just fine ...
[10:10] <pitti> mvo: right, that seems to have been unfixed
[10:11] <pitti> there was some manual_is_always_online.patch or so
[10:11] <asac> mvo: i don't see a bug for that
[10:11] <asac> pitti: let me look
[10:12] <stgraber> RAOF: I suspect it's due to the refresh it's doing while switching to another window as I've my terminal as fullscreen on 1680x1050 and it takes a while to refresh the window ...
[10:12] <stgraber> RAOF: I should try using it with a "standard" terminal size and see if that still happens ...
[10:12] <asac> pitti: we still have that patch
[10:13] <asac> pitti: http://pastebin.mozilla.org/182251
[10:14] <stgraber> pitti: any idea of when the first Tribe-4 candidate isos will be generated (so I switch current Milestone to Tribe-4 and hide Tribe-3 on iso.qa.stgraber.org) ?
[10:14] <pitti> seb128: bug 123080 seems to be real according to last comment
[10:14] <ubotu> Launchpad bug 123080 in gnome-screensaver "[gutsy]  booting after hibernation doesn't prompt for a password" [Medium,Confirmed]  https://launchpad.net/bugs/123080
[10:14] <pitti> stgraber: I think I will have ISOs that actually install in about two hours
[10:14] <seb128> pitti: do you get the issue?
[10:14] <stgraber> pitti: ok fine
[10:14] <pitti> stgraber: but they will definitively lack some stuff (like new OO.o and n-m), so these will not be final
[10:15] <pitti> stgraber: they should be shallowly tested for grave installer problems, though
[10:15] <pitti> stgraber: last ISOs didn't have ubiquity :)
[10:15] <StevenK> pitti: All of libapache-mod-log-sql libapache-mod-log-sql-dbi libapache-mod-log-sql-mysql python-syck can be NBS'd at your leisure.
[10:16] <pitti> StevenK: I already did some of them, removed the rest; thanks
[10:16] <RAOF> stgraber: I do the same thing, with the same resolution, and it doesn't happen :)
[10:16] <StevenK> pitti: Thanks.
[10:16] <stgraber> RAOF: lucky you :)
[10:18] <ogra_> hmm
[10:18] <pitti> mvo: apt looks good, accepted
[10:18] <mvo> pitti: thanks
[10:19] <mikmor2> /afk Ran home to nap for a few hours.
[10:19] <mikmor2> ..
[10:19] <pitti> seb128: hibernate doesn't work for me
[10:19] <pitti> seb128: I can dist-upgrade my laptop and check with suspend to RAM
[10:19] <seb128> pitti: let me try now
[10:20] <pitti> seb128: or, wait, i could switch to nv and test on my desktop
[10:20] <stgraber> pitti: the tracker now has mass-mailing support, so if you want to send a "start can now begin" messages to everyone registered on the website (or the ones having reported at least one result), feel free
[10:20] <mvo> seb128: I see 123080 here too (just if you need someone who can reproduce it)
[10:20] <ogra_> gah, why is kino uninstallable ...
[10:21] <StevenK> ogra_: I uploaded that, I'll look at it.
[10:21] <StevenK> ogra_: Is there a bug?
[10:21] <pitti> stgraber: cool
[10:21] <ogra_> StevenK, no, i just saw irt in the Cd report for edubuntu
[10:21] <ogra_> seems libquicktime's fault
[10:21] <pitti> stgraber: does that need an explicit 'Yes, I want to get spam' from the users?
[10:21] <ogra_> http://cdimage.ubuntu.com/edubuntu/daily/20070807/report.html
[10:22] <stgraber> pitti: not yet, that'll come with User Profile which isn't implemented yet
[10:22] <pitti> stgraber: ok, then I'll use it only for one image
[10:23] <ogra_> StevenK, looks likethat dep was introduced newly with the last merge
[10:23] <pitti> hi ogra_
[10:23] <seb128> mvo: gconftool-2 --get /apps/gnome-power-manager/lock/hibernate ?
[10:23] <StevenK> ogra_: Okay, I think it was pitti's fault, since libquicktime1 landed in universe after it was NEW'd.
[10:24] <stgraber> yes, just notice them that we are beginning testing, once the "I allow the website to flood me with mails" option will be there they'll receive e-mails for every new ISO posted matching their subscriptions
[10:24] <StevenK> ogra_: It's since been promoted.
[10:24] <pitti> ogra_: I am just about to create brand new images for all derivatives, BTW
[10:24] <ogra_> ok, seems i need a rebuild then
[10:24] <pitti> ogra_: are you ok with this? or still some blocker from your side?
[10:24] <pitti> ogra_: it won't be the last images anyway
[10:24] <ogra_> pitti, oh, thanks, sorry, didnt manage to get the udeb finished ...
[10:25] <ogra_> i'm fine :)
[10:25] <pitti> ogra_: we still need OO.o, apt, and n-m at least, but I want to have an ISO soon that actually boots and installs
[10:25] <ogra_> yeah
[10:25] <ogra_> i need to test ltsp builds
[10:26] <stgraber> ogra: is the 50% bug fixed now ? (building ltsp chroot)
[10:26] <ogra> StevenK, as i said, no :(
[10:27] <ogra> its my highest prio though
[10:27] <StevenK> ogra: You missed. stgraber is over there -->
[10:27] <ogra> lol
[10:27] <ogra> sorry :)
[10:27] <stgraber> ogra: oh, just received the bugmail now :) (target changed to Tribe-4)
[10:28] <stgraber> StevenK: IIRC that's not the first time :)
[10:29] <StevenK> stgraber: If it isn't you, it's ScottK. :-)
[10:30] <seb128> mvo: ?
[10:32] <mvo> seb128: the bug with the screensaver not coming up after suspsend that pitti told you about earlier
[10:32] <mvo> seb128: I see that one here too
[10:32] <seb128> mvo: <seb128> mvo: gconftool-2 --get /apps/gnome-power-manager/lock/hibernate ?
[10:32] <seb128> mvo: that was rather a "could you try that" ;)
[10:33] <mvo> seb128: both hibernate and suspend are set to "true"
[10:34] <seb128> ok
[10:34] <seb128> mvo: does it happen when using suspend?
[10:34] <seb128> I can't try hibernate, it shutdowns my laptop now
[10:34] <mvo> seb128: yes, I tested only suspend so far
[10:34] <seb128> mvo: does it happen without compiz?
[10:34] <mvo> seb128: yes
[10:34] <pitti> hi thekorn
[10:35] <thekorn> hey mvo, pitti
[10:35] <seb128> hi thekorn
[10:36] <thekorn> hi seb128
[10:37] <pitti> seb128: ah, we use rarian by default now?
[10:37] <pitti> seb128: we now have both rarian and scrollkeeper on the CDs
[10:37] <seb128> pitti: sort of, yelp uses rarian, I didn't replace scrollkeeper by rarian-compat though
[10:37] <pitti> seb128: will they bite each other?
[10:38] <seb128> pitti: no, scrollkeeper is not required, we just keep it because quite some package still call scrollkeeper-update and that sort of things
[10:38] <seb128> yelp uses rarian which does direct omf indexing
[10:38] <pitti> seb128: ah, so we'd replace it with r-c after the tribe
[10:38] <seb128> yes
[10:38] <seb128> we can do it now if you want
[10:38] <seb128> but I think it can wait after the tribe ;)
[10:39] <seb128> mvo: any error to .xsession-errors?
[10:39] <doko_> seb128, pitti: just in time before you got up this morning ;-)
[10:39] <pitti> seb128: I agree; I was just curious, if they don't conflict, that's fine
[10:39] <seb128> hey doko_
[10:41] <mvo> seb128: http://paste.ubuntu-nl.org/32890/ <- nothing that looks like screensaver
[10:42] <seb128> mvo: please stop gnome-screensaver and run it using --no-daemon --debug
[10:42] <seb128> mvo: that one should have indications ;)
[10:42] <mvo> seb128: ok, brb, I let the machine sleep now
[10:45] <cjwatson> pitti: if you have a little time, could I have approval in principle for bug 62986?
[10:45] <ubotu> Launchpad bug 62986 in debconf "debconf-apt-progress hangs sometimes on SMP systems due to racy debconf protocol handling" [High,In progress]  https://launchpad.net/bugs/62986
[10:45] <cjwatson> (SRU)
[10:45] <pitti> looking
[10:45] <pitti> ah, that one
[10:46] <pitti> cjwatson: thanks for preparing the test images for that
[10:47] <pitti> ogra: edubuntu server CDs are up; can you please give this a quick and shallow test?
[10:47] <pitti> ogra: question for now is "does it install at all?"
[10:47] <pitti> mvo: good morning, mvo's machine, how did you sleep?
[10:47] <seb128> pitti: I've just uploaded a new ubuntulooks revision making the new tooltips being yellow
[10:48] <mvo> seb128: http://people.ubuntu.com/~mvo/tmp/screensaver.log <- but that does not look very helpful
[10:48] <pitti> seb128: \o/
[10:48] <mvo> pitti: very good, thanks .)
[10:48] <mvo> seb128: cool!
[10:48] <seb128> pitti: that's a one line change, if you could accept it ;)
[10:48] <pitti> seb128: sure
[10:48] <seb128> mvo: that doesn't fix the notification bubble color though, dunno why :/
[10:48] <mvo> pitti: no network on wakeup though, had to do a manual ifup :/
[10:48] <cjwatson> pitti: yeah, it seemed like the best approach given that the bug isn't 100% reproducible
[10:49] <cjwatson> I really must get some SMP hardware at some point
[10:49] <seb128> mvo: weird :/
[10:49] <mvo> seb128: oh? crap. what name are the tooltips now? "tooltip" or "tooltips"? maybe I got that wrong in the daemon?
[10:49] <mvo> seb128:  maybe it has something to do with gnome-power-manager, I will investigate that a bit further
[10:50] <seb128> mvo: https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/129699
[10:50] <ubotu> Launchpad bug 129699 in ubuntulooks "New style tooltips are not themed correctly due to name change" [High,Triaged] 
[10:50] <seb128> mvo: that's the theme "workaround"
[10:51] <seb128> mvo: "gtk-tooltip" is the new naming
[10:51] <pitti> cjwatson: without having scrutinized the patch in detail, this looks promising to me; we'll test it for UP during the tribe4 release, and since it does not change the behaviour of existing dapper installations, the "breaks the world" potential is very low
[10:52] <pitti> cjwatson: I propose to upload this to dapper-proposed after the tribe 4 tests were successful, so that we can test both the new debconf in -proposed and the test isos in parallel
[10:53] <jamiemcc> Hi all - when is the cut off point for tribe 4?
[10:53] <jamiemcc> I want to release a new version of tracker late ron today
[10:53] <jamiemcc> with lots of bug fixes and a suspend index on battery
[10:53] <pitti> jamiemcc: is this a bugfix-only point release? or new features and all that?
[10:53] <jamiemcc> all bugfixes
[10:53] <jamiemcc> no new funxctionality
[10:54] <pitti> jamiemcc: then I should consider it; is there a diff somewhere?
[10:54] <jamiemcc> its not ready yet - later on today it will be
[10:54] <cjwatson> pitti: righto. Am I going to have to generate new ISOs, or can I just leave the existing ones there that I've already asked people to test?
[10:54] <jamiemcc> pitti: just like to know how much time I have?
[10:55] <cjwatson> I know they won't be quite binary-identical, but it's a script in an arch: all package so the risk seems low
[10:55] <pitti> cjwatson: no, the existing ones are fine
[10:55] <pitti> exactly
[10:55] <cjwatson> ok, great
[10:56] <pitti> jamiemcc: the current critical path is OO.o, which gives us a magnitude of 15 hours which we can use for modifications without further delaying the release
[10:56] <jamiemcc> pitti: ok great  will have something ready within about 12 hours
[10:56] <jamiemcc> will ping you when its done
[10:57] <pitti> jamiemcc: great, thank you
[11:01] <cjwatson> pitti: OO.o?
[11:01] <cjwatson> no recent uploads?
[11:01] <pitti> cjwatson: calc is building test packages on his box ATM, ETA some 2 hours
[11:01] <cjwatson> 2.3?
[11:01] <cjwatson> please say yes
[11:01] <pitti> cjwatson: he'll get up again when they are finished and test them
[11:01] <pitti> cjwatson: yes
[11:01] <cjwatson> fantastic
[11:01] <pitti> cjwatson: still, this mega-upgrade gives me the creeps, but *shrug* what else shall we do
[11:02] <pitti> on ubuntu the current packages just work, on kubuntu they are absolutely broken
[11:02] <cjwatson> we need it before uvf anyway ...
[11:02] <cjwatson> maybe this will build on powerpc ;)
[11:02] <cjwatson> (least of our concerns, I know)
[11:03] <pitti> cjwatson: well, it actually is
[11:03] <pitti> I'd finally like to see a ppc live CD :)
[11:03] <pitti> (but not with my RM hat, of course)
[11:03] <pitti> cjwatson: yeah, I think we just have to bite the bullet
[11:04] <pitti> calc: after OO.o has built, can you please give me a rough estimate by how many MBs the debs grew compared to the current gutsy version?
[11:04] <pitti> calc: I'd like to pre-adjust the seeds to make room for it to not waste a CD building cycle
[11:05] <stgraber> about PPC, I tried yesterday daily on a Powerbook G3, IDE didn't load, once at the debug prompt I loaded ide-generic and ide-cd, it detected the HDD but still no CD :(
[11:07] <pitti> stgraber: the daily hasn't been updated for ages on ppc
[11:08] <stgraber> hmm, so it was the "current" ISO :), I'll investigate a bit more when I'll have some spare time as it's weird I can make it to detect the HDD but not the CD-Rom
[11:09] <stgraber> I don't think there are two different IDE controlers in there
[11:09] <stgraber> and that's surely not S-ATA (G3 is hmmm very old :))
[11:12] <cjwatson> pitti: debconf uploaded to dapper-proposed for whenever you're ready for it
[11:13] <pitti> cjwatson: thanks; I'll keep it until after the tribe (just in case)
[11:13] <pitti> seb128: ooh, fusa on live system!
[11:13] <seb128> pitti: is that good or not? ;)
[11:14] <cjwatson> pitti: sure
[11:14] <pitti> seb128: shiny for showing off, for sure
[11:14] <seb128> :)
[11:14] <pitti> seb128: however, I have my doubts whether this functionality is common enough to waste so much panel space on it
[11:14] <pitti> seb128: this is a geek feature after all...
[11:14] <seb128> pitti: what panel space?
[11:15] <cjwatson> user switching is a geek feature?
[11:15] <seb128> pitti: well, this space is blank on the top panel anyway, there is no windows list
[11:15] <pitti> well, how often do you actually switch between several users while you are logged in/
[11:15] <pitti> ?
[11:15] <cjwatson> I suppose my wife and stepson are geekier than average, but ...
[11:15] <seb128> pitti: and I quite disagree about user switching
[11:15] <stgraber> pitti: it's by default on Mac OS, so not that much of a geek feature :)
[11:15] <seb128> pitti: people who use window seem to do it often yes
[11:15] <stgraber> pitti: and Windows users seem to be using that quite a lot (from what I've seen)
[11:16] <pitti> seb128: yeah, maybe; I just use to log out of my box and switch it of when I'm not sitting at it :)
[11:16] <pitti> stgraber: yeah, maybe
[11:16] <seb128> they have accounts for every people in the familly and switch between them
[11:16] <cjwatson> I think actually geeks are more likely to be diligent about logging out :)
[11:16] <seb128> pitti: yeah, look like you are the geek here :p
[11:16] <cjwatson> well, not sure, geeks might have more state on their desktop
[11:16] <stgraber> cjwatson: geek has its own laptop and doesn't want anybody else to use it :)
[11:16] <cjwatson> true :)
[11:17] <pitti> so on the live system it looks a bit weird since you cannot actually do anything with it
[11:17] <pitti> it would be cool to hide this by default if there is only one user
[11:17] <pitti> seb128: would that be feasible?
[11:17] <stgraber> pitti: +1
[11:18] <pitti> then the single-user case wouldn't get a confusing no-ob control, and the multiuser machines get the shinyness automagically
[11:18] <seb128> pitti: everything is possible, I would rather not spend efforts on that now, my TODO list is already exploding
[11:18] <pitti> seb128: oh, I mean "WDYT about the idea"; this interests me enough to have a look into it
[11:19] <pitti> seb128: I guess it's not hard to do, after all
[11:19] <stgraber> pitti: an hack would be to use a script to launch it, if there is >1 uid which is >=1000 launch it, otherwise don't
[11:19] <seb128> pitti: well, I think it's ok to have the username on the panel even if there is no other user to switch
[11:19] <seb128> it makes a consistent user experience
[11:19] <pitti> eek, my desktop just started to beep from somewhere of the CPU area
[11:19] <pitti> if I disconnect suddenly, please phone me for urgencies :)
[11:19] <seb128> and not having a label being there or not without any obvious clue for the user
[11:20] <pitti> stgraber: or just hide itself on startup in that case
[11:20] <seb128> well, I don't like "random" interface changes much
[11:20] <seb128> that usually confuse users
[11:20] <seb128> we will do nothing about the space anyway
[11:20] <StevenK> But unhide itself on adduser, or what?
[11:20] <pitti> seb128: well, and I don't like dead things
[11:20] <seb128> and that still give an indication of what session is used
[11:20] <mvo> pitti: could you please accept notification-daemon? fix for the window background
[11:20] <pitti> mvo: sure
[11:21] <seb128> pitti: it's not dead, it's "who is logged"
[11:21] <seb128> pitti: and you can right click on the applet to add users, though that's not very discoverable
[11:22] <pitti> seb128: ah, that's more useful indeed
[11:22] <pitti> right, I didn't notice yet
[11:27] <stgraber> asac: ping
[11:28] <asac> stgraber: pong
[11:28] <stgraber> asac: I just built manually the NM you uploaded to Gutsy and can't connect to WPA now (it try to disconnects when starting to connect, then get stuck like with Open Network)
[11:28] <stgraber> (First time I try with 41o)
[11:28] <asac> stgraber: ok disabling 41o helps?
[11:29] <stgraber> asac: http://paste.stgraber.org/2379
[11:29] <stgraber> asac: ok, rebuilding without 41o
[11:31] <cjwatson> pitti: can I consider your comment in bug 22220 to be SRU approval in advance?
[11:31] <ubotu> Launchpad bug 22220 in hw-detect "Correct modules for I2O-based raid are not loaded" [Medium,Confirmed]  https://launchpad.net/bugs/22220
[11:31] <stgraber> asac: as with Open Network I had to killall NetworkManager as there was no way to stop it
[11:31] <pitti> cjwatson: yes
[11:32] <asac> stgraber: well ... we already know that *feature* :)
[11:32] <cjwatson> pitti: the tribe-4 release notes should say that we have smooth usplash on shutdown now
[11:32] <stgraber> argh, another irssi freeze ...
[11:32] <asac> stgraber: so if reverting 41o helps I will revert it for tribe i guess
[11:32] <highvoltage> irssi freeze? whisch version?
[11:33] <asac> stgraber: the idea was to reset device cleanly instead of just parts ... but well :/
[11:33] <stgraber> highvoltage: feisty's
[11:33] <highvoltage> stgraber: ouch. I've never seen that though.
[11:33] <pitti> cjwatson: hm, the kernel task on 22220 is merely accidental?
[11:33] <stgraber> highvoltage: 0.8.10-2ubuntu1
[11:33] <cjwatson> pitti: sounds like it from your comment
[11:34] <cjwatson> pitti: if you have tasks open on multiple packages, then "nominate for release" adds tasks to all of them
[11:34] <cjwatson> which is rather unhelpful IMO
[11:34] <stgraber> highvoltage: when quickly changing window (using keyboard shortcuts) (using irssi+screen)
[11:34] <pitti> cjwatson: ah, right, 'nomitate for release' has the side effect of creating tasks for all packages
[11:34] <pitti> heh
[11:34] <cjwatson> right, so you then have to go and clobber them afterwards
[11:34] <cjwatson> I noticed that on cdrtools/cdrkit the other day, which irritated me
[11:35] <pitti> cjwatson: in that case /ubuntu/dapper/+source/foo/+bug shuold help
[11:35] <cjwatson> yeah, last I checked that did slightly different things to the db though
[11:35] <pitti> cjwatson: i. e. specifying the ubuntu release in the URL, and then click on 'needs fix here'
[11:35] <cjwatson> and we managed to get it to leave the db inconsistent at one point
[11:35] <cjwatson> so I tend to avoid that
[11:36] <cjwatson> but indeed, that has the right visual effect
[11:36] <stgraber> asac: works fine without 41o
[11:37] <norsetto> pitti: can I ask u a question about a possible archive problem?
[11:38] <Hobbsee> norsetto: (dont ask to ask, just ask)
[11:38] <norsetto> don't want to bugger him if he is busy .....
[11:39] <cjwatson> norsetto: so don't bug anyone in particular :) there are several archive adminns
[11:39] <cjwatson> admins
[11:39] <stgraber> asac: btw, it's the exact same issue I have with Open Networks so it'd be good to investigate if switching from a network to another doesn't trigger the same function or something like that
[11:39] <cjwatson> just ask it to the channel in general
[11:40] <norsetto> I'm having a dep problem in a compilation: java-gcj-compat fails to compile due to missing dep on gcj-4.2
[11:40] <norsetto> * Considering build-dep gcj-4.2 (>= 4.2.1-2)
[11:40] <norsetto> * Tried versions: 4.2.1-1ubuntu1j1
[11:41] <norsetto> and fails, but gcj-4.2 version in archive is 4.2.1-2 and 4.2.1-1ubuntu1j1 is the version for libgcj8-0 !?
[11:45] <cjwatson> norsetto: gcj-4.2 4.2.1-2ubuntu1 was only published relatively recently; is it possible that this build log is just a couple of days old?
[11:45] <norsetto> few minutes old
[11:46] <cjwatson> norsetto: is this a build on our buildds, or on your system?
[11:47] <norsetto> my system
[11:47] <cjwatson> norsetto: what mirror are you using?
[11:47] <norsetto> I think it.archive.ubuntu.com, let me check
[11:48] <cjwatson> norsetto: what tool is that that you're using to do the build?
[11:48] <norsetto> no, its archive.ubuntu.com
[11:48] <norsetto> pbuilder
[11:49] <cjwatson> norsetto: can I double-check that you've run 'pbuilder update' recently?
[11:49] <cjwatson> it looks like the local apt cache is just out of date
[11:50] <norsetto> I did it yesterday indeed, let me check
[11:50] <cjwatson> because pbuilder just does 'apt-cache show gcj-4.2' in the chroot to fish out available versions
[11:50] <cjwatson> do it again
[11:50] <cjwatson> yesterday, it.archive.ubuntu.com might not have had that new gcj-4.2 yet
[11:50] <pitti> norsetto: back; reading scrollback now
[11:50] <norsetto> yeah, I did an apt-cache unmet -i | grep Package
[11:51] <pitti> norsetto: you can always ask me, I just might not answer immediately
[11:51] <norsetto> thx pitty
[11:51] <cjwatson> apt-cache unmet would be in your main apt-cache, not in pbuilder's, unless you chrooted as well
[11:51] <norsetto> oppss: pitti :-)
[11:51] <norsetto> I did an apt-cache not chrooted and it showed the unmet dep
[11:52] <norsetto> apt-cache unmet -i | grep Package
[11:52] <norsetto> Package ia32-java-gcj-compat version 1.0.76-4ubuntu1 has an unmet dep:
[11:55] <calc> hi
[11:56] <cjwatson> norsetto: remember to 'sudo apt-get update' first
[11:56] <pitti> hi calc
[11:56] <norsetto> cjwatson: yes, I realised that now ... sorry for wasting your time colin
[11:56] <pitti> calc: are you actually able to think and walk now? :)
[11:57] <cjwatson> norsetto: not a problem, I'm not saying there's no problem, just that these are the things to make sure you've done first
[11:57] <mvo> seb128: will you make "tracker-search-tool" default too? or just tracker (the daemon)?
[11:57] <cjwatson> norsetto: lib32gcj8-dbg doesn't seem to exist, which would cause ia32-java-gcj-compat to be uninstallable
[11:57] <seb128> mvo: I think we should add the search tool to the default installation, what do you think?
[11:57] <cjwatson> norsetto: (that would be a bug)
[11:59] <norsetto> cjwatson: is there a log you can check or you tried to install it yourself?
[11:59] <calc> pitti: yea :)
[11:59] <mvo> seb128: ok, that is fine with me, I'm going over the list of stuff a desktop data updates now and noticed that this is new etc
[11:59] <pitti> calc: so, please tell me that it built
[11:59] <ogra> pitti, there is still something wrong with libquicktime1 it seems http://cdimage.ubuntu.com/edubuntu/daily/20070807.1/report.html
[12:00] <calc> pitti: ooo built the l10n stuff is still going here
[12:00] <pitti> ogra: hm, that's not on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[12:00] <pitti> ogra: any idea what's the reason?
[12:01] <ogra> not really, its in main proper
[12:01] <ogra> kino should just pull it in
[12:02] <calc> pitti: i'll brb going to test the regular debs
[12:02] <pitti> right, and kino is not installable because of libquicktime, and edubuntu-desktop because of kino
[12:02] <ogra> right
[12:02] <pitti> calc: can you test a non-English one later as well? just to see whether it works (and the help)?
[12:02] <ogra> strange
[12:03] <calc> pitti: ok
[12:03] <cjwatson> norsetto: I checked by hand with dpkg
[12:04] <cjwatson> norsetto: there's a log of uninstallables generated automatically for main/restricted, but not for universe/multiverse - takes too long to generate
[12:04] <pitti> ogra: hm, with just gutsy/main apt source I can install libquicktime1
[12:04] <ogra> yeah, me too
[12:04] <cjwatson> pitti: I tried investigating that same problem a while back and got nowhere, same as you, but I can try again ...
[12:05] <pitti> ogra: edubuntu live CDs are done, does it affect them as well?
[12:05] <ogra> live seems oversized
[12:05] <ogra> hrm
[12:05] <calc> pitti: ooo combined debs are 103731084 bytes, not sure about l10n yet
[12:06] <ogra> and the build logs at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/edubuntu/gutsy/ end on aug 1st :(
[12:06] <pitti> calc: for l10n I only need -en
[12:06] <pitti> calc: oh, wait, some more, sorry
[12:06] <pitti> calc: please see apt-cache show language-support-en | grep Depends
[12:07] <calc> pitti: ok
[12:08] <ogra> pitti, installing edubuntu-desktop in a blank chroot shows no probs either it seems (indeed i didnt wait until it got through the 480M but no dep probs here)
[12:08] <pitti> ogra: yeah, apt-get install should abort immediately on conflicts and such
[12:09] <ogra> right
[12:09] <ogra> seems it will be done in 30min, i'll let it run until we find anything else ...
[12:09] <cjwatson> oh
[12:09] <cjwatson> libquicktime1 depends on libavcodec1d which is blacklisted from CDs per a decision of the Technical Board
[12:09] <cjwatson> DDTT
[12:10] <pitti> aah
[12:10] <ogra> aha
[12:10] <ogra> we didnt have libquicktime0 deps in kino either
[12:10] <ogra> (in feisty)
[12:10] <ogra> i'll drop that
[12:11] <ogra> cjwatson, thanks for the pointer
[12:11] <cjwatson> no problem
[12:12] <cjwatson> libquicktime0 in feisty didn't depend on libavcodec
[12:12] <cjwatson> in addition to what you said
[12:12] <cjwatson> so that would be another option if feasible
[12:12] <cjwatson> well, at least the blacklist works, even if the output is gnomic :)
[12:13] <ogra> i dont think it builds against libquicktime0 but i'll try
[12:13] <cjwatson> I meant potentially rebuilding libquicktime1 not to depend on libavcodec
[12:13] <cjwatson> I don't know whether that's possible
[12:14] <ogra> ah
[12:14] <ogra> i'll test that after the tribe release ... for now dropping the dep should be fine
[12:15] <cjwatson> depends on whether it's more invasive to drop Quicktime support from kino, or to drop whatever libavcodec does for libquicktime, that's all
[12:16] <ogra> well, we never had quicktime support in our kino versiion
[12:17] <cjwatson> true
[12:35] <calc> ok OOo 2.3 debs (not l10n yet) have been verified and they work :)
[12:35] <asac> stgraber: any news?
[12:35] <calc> l10n is still compiling for me
[12:35] <Hobbsee> calc: \o/
[12:35] <stgraber> asac: works without 41o
[12:35] <asac> ok
[12:36] <stgraber> asac: with 41o it gets stuck doing the exact same thing that it does when connecting to open network
[12:37] <stgraber> asac: except that connecting to open network doesn't directly trigger the disconnect thing
[12:40] <asac> stgraber: what do you mean by "doesn't directly trigger the disconnect thing" ... you mean in open network case it doesn't run through the 41o code?
[12:43] <stgraber> I mean that this disconnect the 41o causes for the WPA is similar to the disconnect I have without using 41o but with Open Network
[12:43] <asac> stgraber: yeah ... i hoped it would shoot in the other direction
[12:43] <Kmos> asac: bug 80964 - this one isn't fixed already on v2.0.0.6 ?
[12:43] <ubotu> Launchpad bug 80964 in mozilla-thunderbird "MASTER mozilla-thunderbird crashed [@nsNSSCertificateDB::ImportCertsFromFile]  " [High,In progress]  https://launchpad.net/bugs/80964
[12:44] <asac> Kmos: no ... its fixed1.8.1.7
[12:44] <asac> ... so 2.0.0.7
[12:46] <Kmos> asac: ah ok =) thx
[12:51] <asac> pitti: nm 0.6.5-0ubuntu9 is waiting for approval
[12:52] <pitti> asac: what's the reason for disabling that patch?
[12:54] <ogra> pitti, uploading kino_1.1.0-3ubuntu2 with the dep removed ...
[12:54] <pitti> asac: ah, I read backscroll now
[12:54] <pitti> asac: accepted, thank you
[12:54] <pitti> ogra: ack
[01:03] <pitti> ogra: no upload from you
[01:03] <pitti> ogra: so it'll miss this publisher
[01:03] <ogra> Uploading to ubuntu (via ftp to upload.ubuntu.com):
[01:03] <ogra>   kino_1.1.0-3ubuntu2.dsc: done.
[01:03] <ogra>   kino_1.1.0.orig.tar.gz: done.
[01:03] <ogra>   kino_1.1.0-3ubuntu2.diff.gz: done.
[01:03] <ogra>   kino_1.1.0-3ubuntu2_source.changes: done.
[01:03] <ogra> Successfully uploaded packages.
[01:03] <pitti> ogra: too late to stop the current one, sorry; but I can start a new one immediately after
[01:03] <ogra> Not running dinstall.
[01:03] <asac> pitti: thanks
[01:04] <norsetto> bug 130838: could this be a a gutsy milestone one?
[01:04] <ubotu> Launchpad bug 130838 in Ubuntu "[gutsy]  lib32gcj8 libraries missing" [Undecided,New]  https://launchpad.net/bugs/130838
[01:04] <pitti> ogra: still nothing; did yuo get a reject mail?
[01:04] <pitti> orion2012: that package isn't built any more
[01:04] <pitti> erm, norsetto ^
[01:05] <ogra> pitti, not yet, no
[01:05] <pitti> norsetto: I'll answer in the bug
[01:05] <ogra> ogra@laptop:~/packages/kino-1.1.0$ ls -lh ../kino_1.1.0-3ubuntu2_source.upload
[01:05] <ogra> -rw-r--r-- 1 ogra ogra 286 2007-08-07 13:04 ../kino_1.1.0-3ubuntu2_source.upload
[01:05] <ogra> three mins ago ...
[01:06] <ogra> might take another two :)
[01:08] <pitti> doko: can you please have a look at bug 130838 and comment what should happen there?
[01:08] <ubotu> Launchpad bug 130838 in gcj-4.1 "[gutsy]  lib32gcj8 libraries missing" [Undecided,New]  https://launchpad.net/bugs/130838
[01:10] <pitti> hey, this silly thing ate my comment!
[01:11] <Kmos> REVU is down, I can upload ddclient new version 3.7.3 to upload.ubuntu.com ?
[01:13] <Fujitsu> Kmos: Sure, if you want to get a rejection message.
[01:14] <Kmos> Fujitsu: so, what I can do ?
[01:14] <Fujitsu> Kmos: I'm sure you can wait a few hours for REVU to reappear, or upload somewhere else.
[01:15] <Kmos> i can host in my machine if someone want to
[01:16] <norsetto> thx for the NBS link: bookmarked
[01:24] <ogra> pitti, got the "waiting for approval" mail now
[01:29] <sabdfl> pitti: i noticed that pmount is no longer a dependency of ubuntu-desktop. what's replaced it?
[01:29] <pitti> sabdfl: a hal backend and gnome-mount
[01:29] <sabdfl> ok to remove it?
[01:29] <pitti> sabdfl: i. e. gnome-mount collects the policy (umask etc.), and hal actually mounts it
[01:30] <pitti> sabdfl: yes, that's fine; we don't install it by default any more since feisty
[01:30] <sabdfl> ok thanks
[01:30] <pitti> ogra: accepted
[01:30] <ogra> thanks :)
[01:31] <Mithrandir> pitti: speaking of hal; we should really make it use /var/lib/hal/mtab rather than /media/.hal-mtab.
[01:31] <ogra> pitti, btw, how do i unmount as a user from commandline nowadays ?
[01:31] <Fujitsu> ogra: gnome-eject?
[01:32] <ogra> ah
[01:32] <pitti> ogra: gnome-umount or -eject, yes
[01:32] <Kmos> bug 112148
[01:32] <ubotu> Launchpad bug 112148 in linux-source-2.6.20 "kernel BUG at kernel/workqueue.c:323!" [Undecided,Confirmed]  https://launchpad.net/bugs/112148
[01:32] <ogra> i rarely unmount from commandline :)
[01:32] <Kmos> this one is already fixed on gutsy ?
[01:33] <Mithrandir> Kmos: given it doesn't say "Fix released"; no.
[01:33] <Kmos> Mithrandir: it's kernel 2.6.20, and maybe it's already fixed, not set at LP
[01:34] <Mithrandir> Kmos: then asking here doesn't help
[01:34] <ogra> beyond that, gutsy uses 2.6.22
[01:34] <\sh> Kmos: ask on #ubuntu-kernel and check vanilla if it's fixed there in 2.6.20.X where X>1
[01:35] <Kmos> \sh: :) ok
[01:36] <\sh> ogra: if it's in the vanilla 2.6.20 git patch-tree it could be fixed for feisty ;) and should already be fixed in 2.6.{21,22}.x
[01:37] <mvo> has anyone seen a build failure like http://paste.ubuntu-nl.org/32907/ recently?
[01:37] <TheMuso> Is there a gconf command that forces all changed settings to be saved to a user's .gconf directory?
[01:37] <TheMuso> as in, once you log out? SOmetimes they take a while to appear in the .gconf directory tree.
[01:38] <pygi> Hobbsee, around?
[01:38] <pygi> how come -archive team didn't get subscribed to the bug if request is fine? :)
[01:38] <pitti> doko: re 130838> I already said that lib32gcj-bc isn't built any more :) but what happens with lib32gcj7-dev?
[01:40] <Mithrandir> mvo: looks like @INTLTOOL_ICONV@ hasn't been replaced, for some reason.
[01:41] <mvo> Mithrandir: thanks, I investigate, that build just fine a couple of days ago
[01:42] <Mithrandir> mvo: is this on a buildd?
[01:42] <mvo> yes
[01:42] <mvo> but happens in pbuilder as well
[01:42] <pygi> Hobbsee, poke when you're here, thanks
[01:44] <TheMuso> Never mind, found the gconf setting I was looking for.
[01:44] <doko> pitti: coming with the next gcj-4.1 upload, already disabled in svn, but gcj-4.1 should be demoted anyway, after OOo is built
[01:44] <pitti> doko: ah, great
[01:45] <StevenK> doko, pitti: Do you think there is any point changing the ecj-bootstrap{,-gcj} depends so the two of them can be NBS'd?
[01:46] <StevenK> doko, pitti: All four of them are universe, so it will have no effect on the tribe.
[01:47] <doko> StevenK: no, they are not built anymore and should be removed (side note to pitti: packages not built anymore confuse people and should be removed more often)
[01:47] <pitti> doko: I know, but I don't remove them as long as they still have reverse dependencies in main
[01:47] <StevenK> doko: If they're removed, all four of the packages become uninstallable.
[01:47] <pitti> doko: I do removals daily :)
[01:48] <Kmos> pygi: the bug is already acked ?
[01:49] <pygi> Kmos, yes, but archive doesn't seem to be subscribed :)
[01:49] <pygi> lemme settle it with Hobbsee
[01:49] <pygi> when she's back
[01:49] <Kmos> pygi: so the MOTU forget it.. you can subscribe
[01:49] <Kmos> she does something like that to a sync i've request
[01:49] <pygi> Kmos, don't wanna do that ;) Have patience :)
[01:49] <Kmos> :)
[01:50] <Hobbsee> pygi: poke
[01:50] <pygi> Hobbsee, :)
[01:50] <Kmos> pygi: patience isn't good for my stress :))
[01:50] <pygi> Hobbsee, the bug where I requested libswfdec sync .. you acked, but didnt subscribe -archive team?
[01:50] <Hobbsee> pygi: probably because i forgot to do ti.
[01:50] <StevenK> doko, pitti: To be honest, it's a grand total of 10 minutes, but adds (admitedly, small) Ubuntu changes to three packages.
[01:50] <Hobbsee> pygi: please subscribe u-a then
[01:50] <pygi> Hobbsee, oki, will do ;)
[01:51] <pygi> Hobbsee, thanks
[01:51] <pygi> Hobbsee, I agree, because you gave back swfdec-mozilla without swfdec :)
[01:51] <pygi> subscribed
[01:51] <Hobbsee> pygi: a) i didnt give back anything and b)  i thought i requested 2 things with that block.
[01:52] <Hobbsee> (of givebacks)
[01:52] <pygi> Hobbsee, ok, you request give back :)
[01:54] <StevenK> pitti: libgcj8-0 can be NBS'd at your leisure.
[01:54] <pitti> yay
[01:56] <Hobbsee> pygi: you know, i could have sworn that i requested both swfdec and swfdec-mozilla to be given back.  weird.  maybe i really am going insane, then.
[01:56] <pygi> Hobbsee, don't worry, I'm covering you
[01:56] <Hobbsee> oh good
[01:56] <pitti> StevenK: killed (lib32gcj-bc too, it's uninstallable anyway)
[01:56] <StevenK> pitti: Shall I deal with ecj?
[01:56] <pitti> StevenK: I'd like to defer that question to doko
[01:57] <infinity> StevenK: What's wrong with ecj?  We just had an upload...
[01:58] <doko> StevenK: fix tomcat5.5, or look if it needs a sync
[01:59] <StevenK> infinity: Not ecj per se, there are four packages that depend on ecj packages that are no longer built by it.
[01:59] <infinity> StevenK: Ahh.
[02:00] <StevenK> infinity: Can I flutter my eyelashes at you now? *hint*
[02:00] <infinity> StevenK: If you want me to hurt you.
[02:01] <StevenK> infinity: Not particularly, you don't seem my type. :-P
[02:02] <StevenK> infinity: I'd just like to get yada out of main before tribe 4.
[02:02] <infinity> StevenK: A worthwhile goal.  Alright, I'll look at it tonight.
[02:02] <infinity> StevenK: Since doko's not abusing me today.
[02:02] <infinity> Hobbsee, Mithrandir : Stop flirting in public channels, it's distracting.
[02:03] <Hobbsee> infinity: yet.
[02:03] <StevenK> doko: Shall I fix kaffe too?
[02:03] <Hobbsee> ...
[02:04] <doko> StevenK: if you want, sure, and be prepared for the then coming debian merges
[02:05] <StevenK> doko: Happy to do so.
[02:06] <StevenK> Which leaves ikvm and eclipse
[02:07] <StevenK> ikvm needs a merge/sync from Debian anyway. And eclipse is a dog and I'd rather not touch it, but it's a one line patch.
[02:09] <Mithrandir> StevenK: I think you might end up with a very angry infinity that way.
[02:09] <Hobbsee> Mithrandir: as long as StevenK's hidden, he should be OK
[02:09] <StevenK> There's no might about it. :-P
[02:09] <StevenK> Fujitsu: I have means, and it doesn't involve a phone book.
[02:09] <Fujitsu> Hah.
[02:10] <Fujitsu> Aha.
[02:10] <StevenK> Well, not so secret. :-P
[02:10] <StevenK> Ew! kaffe uses DBS
[02:10] <StevenK> I washed my hands but the dirt isn't coming off!
[02:12] <Mithrandir> use some of that cleaning liquid you use for cleaning coffee makers?
[02:12] <tkamppeter> hi pitti
[02:14] <StevenK> Because ...
[02:15] <infinity> StevenK: Not sure if my phone number is current in ud-ldap...
[02:15] <StevenK> I think mine is, but only because it hasn't changed in 7 years.
[02:16] <norsetto> following bug 129742 the turkey package needs to be moved to multiverse; should I open a new bug asking for this?
[02:16] <ubotu> Launchpad bug 129742 in turkey "[ftbfs]  turkey ftbfs on gutsy" [Undecided,Confirmed]  https://launchpad.net/bugs/129742
[02:22] <infinity> norsetto: Telling users they have to change their alternatives to use the package seems a bit odd.  Is there no way to change it to call the sun jvm directly, regardless of alternatives configuration?
[02:23] <norsetto> infinity: I wouldn't do that
[02:23] <geser> pitti: will gutsy ship both emacs21 and emacs22 in main?
[02:23] <norsetto> infinity: what if the user wants to use whatver jvm they have installed? we shouldn force a particular one
[02:24] <infinity> norsetto: Err, what?
[02:24] <infinity> norsetto: You claim the package can't work with anything but the Sun JVM, right?
[02:24] <norsetto> infinity: but, if they want to use turkey, they know they have to use the sun one
[02:24] <infinity> norsetto: So, making the package call the SUn JVM directly makes more sense than forcing the user to mangle their alternatives.
[02:25] <infinity> norsetto: Look at this from a simpler POV.  If you have a shell script that relies on bash to run, you use #!/bin/bash, you don't tell the user to change his /bin/sh symlink from dash to bash.
[02:25] <norsetto> infinity: what do you mean making the package call sun jvm?
[02:25] <infinity> norsetto: ...
[02:25] <asac> stgraber: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[02:26] <infinity> norsetto: You wrote a README that states that to use the package, the user needs to change the "java" altrenative to point at the Sun JVM.  If the Sun JVM is the only java it will work with, you should make the package call the Sun JVM where it's insalled, not call the "java" alternative.  (See the '/bin/sh' example above to get my point)
[02:26] <norsetto> infinity: is it possible to force a java application to use a particular jvm?
[02:26] <geser> norsetto: add a small wrapper script (if none exists) to call turkey with sun-java (or how the binary is called) instead of /usr/bin/java
[02:27] <stgraber> asac: bzr getting
[02:27] <infinity> norsetto: I'm sure it is.  It's just an interpreter.
[02:28] <norsetto> infinity: I have to investigate this, right now I wouldn't know how to do it (geser might know though)
[02:30] <infinity> norsetto: It's just bad form to tell a user "to use my package, you MUST use this JVM for all the java apps on your machine" (or, you MUST use this shell, or whatever)
[02:30] <infinity> norsetto: If they have multiple JVMs installed, they might have a valid reason to prefer another for their day-to-day work. :)
[02:30] <norsetto> infinity: exactly my point
[02:31] <norsetto> infinity: I made wrappers like geser said for python and mono applications, but never seen them for java
[02:31] <norsetto> infinity: and didn find mention in the debian java policy docs
[02:32] <norsetto> infinity: so, just assumed they didn exist; you and geser are hinting that they exist; ok, let me investigate this
[02:32] <norsetto> infinity: if it is possible, I agree it the best way
[02:32] <infinity> norsetto: The "turkey" binary is a shell script that calls "exec java -jar /usr/lib/java/turkey.jar "$@""
[02:33] <infinity> norsetto: Changing that from "java" to /usr/lib/path-to-sun-crap/bin/java" should do the trick, no?
[02:33] <norsetto> infinity: I don know, its worth trying it out
[02:33] <cjwatson> (hint: the answer is yes ;-))
[02:35] <norsetto> infinity: assuming this works, what is the best way to move this to multiverse?
[02:36] <infinity> norsetto: When the next upload depends on stuff in multiverse, germinate will notice, and we might even remember to move it.
[02:36] <infinity> norsetto: Or, I could just move it.
[02:37] <infinity> norsetto: If you went with the former "waiting on it to be moved" option, though, a bug filed on the package "needs to move to multiverse", with ubuntu-archive subscribed, might help.
[02:37] <norsetto> infinity: I can do whatever is best for you guys
[02:38] <infinity> norsetto: I'll just move it now.  Get a fixed package in the archive though, please. :)
[02:38] <norsetto> infinity: sure will do, on my way .... thx
[02:41] <cjwatson> infinity: we don't have any automatic detection for should be in universe vs. multiverse, unfortunately
[02:41] <infinity> cjwatson: Oh.  We really should.
[02:41] <infinity> cjwatson: Too CPU intensive, or just don't bother?
[02:41] <cjwatson> bit of both
[02:42] <cjwatson> britney is definitely too CPU intensive
[02:42] <infinity> And I meant anastacia, not germinate, but whatever.  Not on full thrust right now.
[02:42] <cjwatson> germinate might be doable somehow if you could figure out how to express it
[02:42] <infinity> Or did we still never port anastacia to the new world order?
[02:42] <cjwatson> well, anastacia is basically a cunning germinate frontend ...
[02:42] <cjwatson> ported it to LP long ago
[02:42] <cjwatson> still uses germinate though
[02:42] <infinity> Yeah, kay.  Thought so...
[02:42] <infinity> Right.
[02:43] <cjwatson> well, um. if "uses Packages files" counts as "ported to LP".
[02:43] <cjwatson> I think it used to use the dak db
[02:43] <cjwatson> :qa
[02:43] <infinity> I wonder how painful it would be to just do it raw, against the lp_prod database.
[02:49] <infinity> norsetto: Moved.
[02:49] <norsetto> infinity: the patch in 129742 already went through I think. Will post a new patch to fix the script ok?
[02:49] <infinity> norsetto: Sure.
[02:49] <norsetto> infinity: okki dokki, thx for all
[02:55] <pitti> hi tkamppeter
[02:56] <stgraber> asac: no change with this patch
[02:57] <pitti> stgraber: you mean latest n-m upload doesn't make it work again?
[02:58] <tkamppeter> hi pitti
[02:58] <tkamppeter> I got SVN write access for system-config-printer now, and Tim Waugh accepted all my patches.
[02:59] <tkamppeter> So all my idiot-proofing/usability enhancements on s-cp are upstream now.
[02:59] <pitti> tkamppeter: great
[03:00] <stgraber> pitti: the branch you gave me half an hour ago
[03:00] <pitti> tkamppeter: so, although I still think that the UI is somewhat complicated, with the autoconfig magic many users don't need to touch it any more, and it actually works really well now
[03:00] <stgraber> pitti: .opennet
[03:00] <pitti> stgraber: ah, for the other bug
[03:00] <tkamppeter> pitt, the collaboration with Tim is very good, so I think now we can safely drop the gnome-cups-manager and replace it by system-config-printer.
[03:00] <stgraber> argh, I mean the branch asac gave me
[03:00] <pitti> tkamppeter: I tend to agree
[03:00] <pitti> stgraber: I figured :)
[03:01] <tkamppeter> pitti, I think it is no problem now to add a printer. User clicks "Add Printer", enters queue name, Next, then a list of printers appear and the user cannot do anything wrong, especially because if a printer is supported by HPLIP only the HPLIP version is shown.
[03:02] <asac> stgraber: do you see if nm tries to use wpa for opennet?
[03:02] <cjwatson> mvo: could you look at bug 130843? it looks to me like it's getting stuck inside its python-apt code
[03:02] <ubotu> Launchpad bug 130843 in ubiquity "desktop install hangs at 96%" [Critical,New]  https://launchpad.net/bugs/130843
[03:03] <tkamppeter> I even would like if you ditch gnome-cups-manager from Tribe 4 and replace it by system-config-printer, so that users test before feature freeze.
[03:03] <stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Device eth1 activation scheduled...
[03:03] <stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Activation (eth1) started...
[03:03] <Mithrandir> tkamppeter: that's a bit on the late side.
[03:03] <stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
[03:03] <stgraber> asac: that's all I got
[03:03] <stgraber> asac: and the "Aug  7 14:51:15 laptop NetworkManager: <info>  Activation (eth1): waiting for device to cancel activation.
[03:03] <mvo> cjwatson: looking
[03:03] <stgraber> when I try to make it switch back to LAN or another WLAN
[03:03] <pitti> tkamppeter: sorry, that won't happen
[03:04] <tkamppeter> Mithrandir, so better do the change the day after Tribe 4, post on all list to ask evereyone for an intensive Ubuntu-internal testing so that it is ready for Tribe 5?
[03:04] <pitti> tkamppeter: yes, that sounds good
[03:05] <StevenK> pitti, doko: Updated tomcat5.5 uploaded.
[03:05] <pitti> tkamppeter: then we still have some time for some UI improvements if we need to
[03:05] <tkamppeter> So I will report a bug against gnome-cups-manager milestoned to tribe 5 with priority high.
[03:06] <asac> stgraber: so you never get "Activation (%s) Stage 1 of 5 (Device Prepare) started..." ?
[03:08] <asac> stgraber: oh sorry
[03:08] <asac> stgraber: nevermind
[03:09] <alex-weej> anyone else experiencing trackerd just eating all your memory and then crashing? and to top it off apport claims to not have enough memory to report the bug.
[03:09] <pitti> alex-weej: apport-wise that sounds consistent, though
[03:09] <alex-weej> pitti: i don't expect apport to grow memory out of nothing :)
[03:10] <pitti> alex-weej: that would be a really cool feature, though!
[03:10] <alex-weej> yeah, maybe mark it for gutsy+1
[03:11] <Mithrandir> pitti: I'd probably call that feature mmap and assign a syscall for it, if I ever were to implement such a thing.
[03:12] <asac> stgraber: its strange ... cancel activation is only called when device gets fully deactivated ... but since 41o was dropped we don't do that anymore :/
[03:13] <asac> stgraber: ah ... now i read that you get the cancel activation message when you try to switch network ... ok.
[03:15] <stgraber> asac: yes, but it never managed to switch and NM got stuck at this point (killall NetworkManager to reset)
[03:16] <asac> thats strange
[03:16] <asac> stgraber: can you still tweak your device with iwconfig ?
[03:16] <asac> or is that locked too now?
[03:17] <stgraber> IIRC I can set some stuff with iwconfig but it will never associate
[03:19] <asac> and no output from nm?
[03:22] <stgraber> asac: just did another try, so no NM doesn't give any output beside : "Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... "
[03:22] <stgraber> I tried setting essid and bssid by hand with iwconfig and no success
[03:23] <stgraber> (iwconfig keeps saying unassociated)
[03:29] <pitti> stgraber: does 'iwconfig eth0 ap any' help?
[03:29] <pitti> stgraber: that sometimes helped for my card in the past
[03:29] <pitti> stgraber: at least for "AP: invalid"
[03:31] <stgraber> pitti: I just tried and no it doesn't (as it's already Not-Associated)
[03:37] <mvo> hm, while trying to reproduce #130843 my VM (256mb ram) locked itself hard :/
[03:38] <pitti> mvo, cjwatson: I just downgraded apt and python-apt to feisty on the live system, then the install actually worked
[03:38] <pitti> mvo, cjwatson: surprising, I had assumed it uses the chrooted apt
[03:39] <mvo> pitti: I'm checking the problem out currently, with more ram in the vm it seems to continue here
[03:39] <pitti> mvo: I use 768 MB usually, that's smooth enough
[03:40] <seb128> pitti: have you updated to the new glibc already?
[03:40] <pitti> seb128: on my desktop? yes
[03:41] <seb128> pitti: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/130852
[03:41] <ubotu> Launchpad bug 130852 in pidgin "[gutsy]  Pidgin 2.1.0 crashes on the freshly updated libc6" [Undecided,New] 
[03:41] <seb128> pitti: did you try running pidgin since?
[03:41] <seb128> (I'm doing the upgrade at the moment, didn't try yet)
[03:41] <pitti> seb128: yes, my session starts it by default, and it seems to work fine
[03:41] <coNP> You cannot talk to anyone.
[03:41] <coNP> At least I cannot.
[03:41] <seb128> ok, so it's not a "it's crashing for everybody"
[03:41] <seb128> coNP: oh?
[03:41] <pitti> coNP: let me try
[03:41] <coNP> It is crashing if you actually want to communicate I guess
[03:42] <seb128> might be a new tribe-4 issue if that's happening to everybody
[03:42] <coNP> I am not sure if it happens to everyone
[03:42] <pitti> coNP: I sent something to a friend of mine (ICQ), wiating for response
[03:45] <pitti> coNP, seb128: just got a response from a friend of mine, works well here
[03:45] <coNP> It is very good if it does not affect everyone :)
[03:46] <pitti> coNP: do you use ICQ? or jabber or something?
[03:46] <seb128> wasabi: what about opening bugs rather than mentionning it on IRC without any reason?
[03:46] <coNP> Now it works for me.
[03:46] <coNP> GMail/Jabber
[03:46] <geser> pitti: will gutsy ship both emacs21 and emacs22 in main?
[03:46] <coNP> Some MSN, maybe I try to contact one of them
[03:46] <pitti> geser: no, only 22 eventually, when the remaining reverse dependencies are settled
[03:47] <geser> pitti: so it's ok to sync request packages replacing emacs21 with emacs22 in depends?
[03:47] <coNP> pitti: Cool, it *works* as well.
[03:47] <pitti> geser: oh, please do so
[03:47] <pitti> coNP:  it's a kind of magic 
[03:48] <coNP> But it didn't, I guess it might be that it does not work for everyone, at some stage of updates.
[03:51] <asac> stgraber: and without nm?
[03:57] <cjwatson> why does deskbar-applet use 17MB of non-shared memory?
[04:04] <infinity> StevenK: Did libnss-db really need config.{sub,guess} updated in the diff.gz?
[04:08] <stgraber> asac: without NM I just iwconfig eth1 essid test
[04:08] <stgraber> asac: and the second after I'm associated
[04:09] <stgraber> asac: btw, I just had a strange behaviour, after an unsuccessful NM connect to "test", eth1 keeps being unassociated even when setting it with : iwconfig eth1 essid test
[04:09] <asac> stgraber: so do you see if wpa_supplicant is started?
[04:09] <stgraber> asac: looks like NM does something that makes the card unable to associate
[04:10] <asac> (when connecting to open net)
[04:10] <stgraber> I don't think it's but let me check
[04:11] <infinity> StevenK: A few things.  debian/copyright is boilerplate, it needs to have real content.  debian/patches/foo were gratuitously renamed from .patch to .dpatch ... dpatch can function with arbitrary extensions (can't it?), so keeping the filename in place would minimise the diff to "just adding dpatch headers"...
[04:15] <stgraber> asac: oh, this time was weird, I was able to do : wpa -> open -> wpa (which usually doesn't work), then the 3-4 next tries tried to connect with open but failed and fallback to wpa (which usually doesn't happen), then finally I had a usual freeze :)
[04:15] <stgraber> asac: so when NM freezes wpa_supplicant isn't running
[04:15] <stgraber> asac: (as It's stuck at Stage1)
[04:17] <asac> stgraber: did it ever work better?
[04:17] <asac> (in gutsy)
[04:18] <stgraber> asac: I usually don't connect to open network, but I'd say no
[04:18] <stgraber> asac: I never saw it working
[04:21] <cjwatson> pitti: I'm sitting here reading through an strace now trying to work out where all the file descriptors are going
[04:21] <cjwatson> pitti: I may be some time
[04:22] <cjwatson> I can see where it's hanging, just need to trace it back out
[04:22] <seb128> pitti: I've just uploaded a gnome-python-desktop revision fixing the -dbg build by adding Build-Depends, if you could accept it
[04:23] <pitti> seb128: sure (not that we would care, but *shrug*) :)
[04:23] <seb128> pitti: I do care because it breaks the build of other packages ;)
[04:25] <cjwatson> pitti: I have a suspicion that the dpkg logging work may be implicated
[04:26] <pitti> indeed, that's a new thing
[04:26] <pitti> seb128: ah, in the queue now; accepted
[04:26] <cjwatson> my suspicion is more based on the fact that that's where the debconf output is going that ubiquity is sitting waiting for
[04:26] <mvo> cjwatson: I'm looking at the code currently and it seem to me like it would be a good idea to clean it up a bit as some of the required functionality did move into python-apt nowdays
[04:26] <cjwatson> mvo: oh, quite possibly, it's just low on the list as it's so hairy
[04:27] <cjwatson> and I think it will still have to work in a somewhat different way due to its debconf interaction
[04:28] <mvo> cjwatson: right, is there a way to skip the steps before it starts installing? it may well be enough to disable the logging feature
[04:28] <cjwatson> you can't really skip that and retain a useful test, no
[04:30] <cjwatson> basic problem seems to be that apt is intercepting debconf protocol output and thinking it's terminal output
[04:30] <cr3> who should I speak to about either updating hwdb-client or replacing it?
[04:31] <cjwatson> cr3: ogra
[04:31] <mvo> cjwatson: but it does not write it to /target/var/log/apt/term.log?
[04:31] <mvo> cr3: I have a certain interesst in this as well
[04:32] <cr3> mvo: cool, I'll send an email to both of you
[04:32] <cjwatson> mvo: as it happens it hasn't (it may just not have flushed it), but that's entirely not the point
[04:34] <cjwatson> mvo: actually, it's worse than that, it's intercepting stdin from the ubiquity process that's doing apt<->debconf translation, apparently thinking it's dpkg output
[04:34] <pitti> doko: what will uname -m return on lpia?
[04:34] <pitti> doko: (that should probably go on https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap)
[04:36] <mvo> cjwatson: any output it intercepts should be written out verbatim again
[04:36] <cjwatson> mvo: to the wrong place
[04:36] <cjwatson> mvo: it writes it to the terminal, but not to its stdout
[04:37] <cjwatson> 12677 read(0, "1 OK\n", 256)            = 5
[04:37] <cjwatson> 12677 write(18, "1 OK\n", 5)             = 5
[04:37] <ijuz> i was just trying to install the 20070807.1 live-cd for i386 and it stuck at 96%, is there some way to see what made it to stop?
[04:38] <cjwatson> ijuz: we're just trying to work that out now
[04:38] <cjwatson> ijuz: you're not the only one
[04:38] <ijuz> ah, ok :)
[04:38] <elmo> mvo: <random>hey could you make apt depend on gpgv instead of gnupg someday?  I split the package out for that reason :)
[04:40] <pitti> infinity: what will uname -m return on lpia?
[04:40] <infinity> pitti: i686
[04:40] <pitti> hm, erk
[04:40] <infinity> pitti: But you really shouldn't be relying on uname for anything...
[04:40] <infinity> pitti: What's the context?
[04:40] <pitti> infinity: but we don't have libc6-i686 on lpia, right?
[04:40] <mvo> elmo: yes, also gnupg is needed for apt-key currently (but that might be changed) so gnupg will still be a recommends or something liek this
[04:40] <pitti> infinity: checking my first package for lpia compatibility (apport)
[04:40] <infinity> pitti: No, we don't, cause libc6 on lpia is i686-optimised already.
[04:41] <pitti> infinity: it would currently mean that you (1) cannot tell apart i386 and lpia crashes by tag, and (2) the setup script for a retracer will fail on lpia
[04:42] <infinity> pitti: But why is it using uname at all?
[04:42] <infinity> pitti: You can have an i386 system with an x86_64 uname, for instance.
[04:42] <cjwatson> mvo: I might see if I can figure out how to make ubiquity use different fds for debconf at that point to avoid this evil
[04:43] <pitti> infinity: to determine which retracer will process a crash
[04:43] <pitti> infinity: e. g. you cannot process an i386 core dump on a powerpc gdb
[04:43] <cjwatson> though that will involve a select loop
[04:43] <pitti> infinity: filing a bug will create a tag need-{i386,amd64,powerpc,sparc}-retrace
[04:44] <pitti> infinity: so crashes on lpia will be marked as i386
[04:44] <mvo> cjwatson: alternatively I can add a option for you that will skip this whole logging mess in libapt
[04:44] <pitti> infinity: you can still see the "PackageArchitecture: lpia" in the bug, so it doesn't matter that much
[04:44] <infinity> pitti: So, what happens in the case of an amd64 kernel with an i386 userspace?
[04:44] <infinity> pitti: (I know it's not a supported configuration, but...)
[04:44] <pitti> infinity: that will hit the amd64 retracers then
[04:45] <pitti> infinity: if the user can install something like ia32-libs, then the retracer shuold be able to as well
[04:45] <pitti> infinity: (I don't support third-party packages)
[04:45] <cjwatson> mvo: mm, I'm thinking very hard :)
[04:45] <infinity> pitti: I'm not talking ia32-libs, but rather an entire i386 userspace on an x86_64 kernel.
[04:47] <pitti> infinity: well, I guess I'll just convert it all to dpkg --print-architecture (which I already have, but I don't use that one for determining the tag)
[04:48] <infinity> pitti: --print-installation-architecture
[04:48] <pitti> infinity: uname is much more portable, though, so I used that; I have to look into that more deeply
[04:49] <infinity> pitti: The other option is to make apport arch:any, and hardcode the dpkg arch at build-time.
[04:49] <infinity> pitti: Saves you an expensive call to dpkg at runtime.
[04:50] <pitti> infinity: there are worse things than that call
[04:50] <pitti> infinity: and it'd make the retracer setup much more complicated
[04:50] <bddebian> Howdy
[04:50] <infinity> pitti: I don't doubt there are worse things. :)
[04:50] <pitti> infinity: ok, thanks for the heads-up
[04:50] <infinity> pitti: Like firing up python.
[04:51] <pitti> like gzipping a 300 MB core dump or calling gdb on it, or doing dpkg -S (-ish, I optimized that already)
[04:54] <cjwatson> mvo: I think a better answer is for me to have ubiquity invoke pm.DoInstall() </dev/null
[04:55] <pkl> nick pkl_
[05:01] <cjwatson> mvo,pitti: comments on http://people.ubuntu.com/~cjwatson/tmp/ubiquity.130843.diff? I'm testing it now.
[05:03] <bddebian> Wow, disappear for a couple of months and you get no love. :-)
[05:03] <pitti> cjwatson: ah, great! want me to test as well?
[05:04] <norsetto> mvo: did you get my email about justinwray?
[05:04] <cjwatson> pitti: sure, can't hurt
[05:04] <cjwatson> apply that to /usr/share/ubiquity/install.py
[05:04] <mvo> norsetto: yes, sorry, I'm badly behind with mail
[05:07] <Amaranth> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[05:07] <Amaranth> how can i make dpkg-source stfu?
[05:08] <Amaranth> i'm doing a build for my PPA but i don't want to change stuff :)
[05:08] <Amaranth> oh, this isn't -motu...
[05:08] <cjwatson> Amaranth: DEBEMAIL=<something not at ubuntu.com>
[05:08] <norsetto> mvo: np; I can imagine :-)
[05:08] <cjwatson> /usr/bin/dpkg-source is a Perl script, search for the error message in it and it's the first hit ...
[05:08] <Amaranth> oh, so the message is incorrect and it's reading my email in the changelog and not the version?
[05:09] <coNP> no, it uses debian/control
[05:09] <cjwatson> Amaranth: the message is correct, but changing DEBEMAIL downgrades the error to a warning so you can continue
[05:09] <Amaranth> right, which i didn't want to change
[05:09] <bddebian> pitti:  :-)
[05:09] <cjwatson> you can just change it temporarily in the environment
[05:09] <cjwatson> anyone without 'ubuntu' in DEBEMAIL is assumed not to care about our DebianMaintainerField spec
[05:12] <Amaranth> cjwatson: thanks, that made it shutup :)
[05:15] <pygi> who broke the n-m this time :-/
[05:16] <seb128> pygi: would be asac?
[05:16] <seb128> pitti: can you accept nautilus? it's built with tracker
[05:16] <seb128> pygi: what is broken?
[05:17] <pygi> seb128, it won't connect to my network
[05:17] <pygi> WPA2-PSK
[05:17] <asac> pygi: please send any complaints to devnull@jwsdot.com :)
[05:17] <asac> pygi: what chipset?
[05:17] <pygi> just fetching new updates
[05:17] <desrt> seb128; taking bets on if tracker remains fully-enabled in gutsy final?
[05:17] <seb128> desrt: no ;)
[05:17] <jamiemcc> desrt: should do if ioprio is sorted
[05:17] <seb128> desrt: any opinion on that?
[05:17] <asac> pygi: and more importantly ... which version of nm are you on atm?
[05:18] <seb128> desrt: let's have a look at user bug reports
[05:18] <doko> pitti: i686
[05:18] <desrt> seb128; let's just say that it's a very exciting time.
[05:18] <desrt> :)
[05:18] <seb128> ;)
[05:19] <pygi> asac, what did you get last?
 pygi: what chipset?
 just fetching new updates
 asac, ipw2200
[05:19] <pygi> I just upgraded, seems fixed
[05:20] <asac> ok so the dragon flew away?
[05:20] <Amaranth> ooh, it'd be really nice if i could use nm with WPA2 again :)
[05:20] <asac> pygi: ok then have fun :)
[05:20] <pygi> asac, thanks for the work ;)
[05:20] <asac> Amaranth: ipw3945?
[05:20] <Amaranth> asac: yeah
[05:20] <asac> Amaranth: if so give latest a try
[05:20] <asac> Amaranth: should work
[05:20] <Amaranth> alright
[05:20] <Amaranth> no more WEP!
[05:20] <asac> Amaranth: open network has problems ... but wpa is hopefully fixed now :)(
[05:21] <pygi> asac, ubuntu8 was a problem /me guesses =)
[05:21] <asac> yes ubuntu8 was a fun upload :)
[05:21] <geser> pitti: is it ok to request syncing rub1.8 (new upstream version) from Debian to drop the emacs21 dependency from ruby1.8-elisp?
[05:21] <asac> to wake up the crowd ;)
[05:21] <pygi> haha :)
[05:21] <desrt> seb128; k.  let me put it this way
[05:21] <pitti> geser: if it doesn't require a large transition otherwise, then yes; we are still before UVF
[05:22] <pitti> geser: and ruby has an extensive test suite and all that
[05:22] <desrt> seb128; if tracker remains fully-enabled in gutsy final then my respect for jamiemcc will increase quite a lot :)
[05:22] <jamiemcc> lol
[05:22] <desrt> since, no matter how you slice it this is gonna be a shitstorm :)
[05:22] <cjwatson> pitti: that ubiquity patch works for me
[05:23] <pitti> cjwatson: yay! mine is at 78%
[05:23] <mvo> cjwatson: I would like to create a testcase for DebconfInstallProgress to get some simplification going, I wonder if there is a way to pass it a fake debconf.Debconf() that just echos the communication ?
[05:23] <cjwatson> pitti: there's a bunch of non-uploaded stuff in ubiquity bzr, but I guess you'd prefer me to upload just that patch?
[05:23] <cjwatson> pitti: it's mostly mythbuntu
[05:23] <Amaranth> desrt: Well, we do have rather high standards :)
[05:23] <jamiemcc> desrt: I have a few months I hope to fix things!
[05:23] <Amaranth> desrt: That's why we didn't have either one before
[05:24] <cjwatson> mvo: sure, you just need to arrange to return something sensible
[05:24] <Amaranth> jamiemcc: Hey, I've actually been looking for you :)
[05:24] <pitti> cjwatson: does it affect the ubuntu/kubuntu behaviour at all?
[05:24] <jamiemcc> hi amaranth
[05:24] <asac> pygi: ok i added you to the list of dedicated ipw2200 testers for nm now :)
[05:24] <cjwatson> mvo: I think you actually have to have reads/writes in order to catch this problem though
[05:24] <ijuz> when you use the alternate CD at some point the installer shows you resolutions to choose from, what package is that? (because... when it appears my screen it just glibberish starting at this point)
[05:24] <asac> pygi: thanks for volunteering ;)
[05:24] <pitti> cjwatson: if so, then I'm hesitant now
[05:24] <pygi> asac, ergh!
[05:24] <cjwatson> mvo: because the problem here was that ubiquity wrote a debconf command, and then apt read the debconf reply before ubiquity had a chance to do so
[05:24] <pygi> asac, well, /me did work on packaging nm for dapper, but he's sure he didn't volunteer this time for testing
[05:25] <mvo> cjwatson: yes, my initial though was to create a fake-debconf class, but that would not have got this problem so it needs to be something more elaborate
[05:25] <cjwatson>   * Don't dump debug information to the console when using --automatic.
[05:25] <cjwatson>   * Get the user password straight from debconf in noninteractive mode.
[05:25] <cjwatson>   * Add partman-auto-loop.
[05:25] <Amaranth> jamiemcc: There is this project called timevault (guess what it does) but I don't have enough inotify watches for it and tracker, is there some way it can hook into tracker so it can do the snapshot thing when tracker is indexing?
[05:25] <cjwatson> pitti: those three could change behaviour, so I'm happy to postpone
[05:25] <cjwatson> mvo: just using debconf.Debconf() itself without a frontend running should do the job
[05:25] <jamiemcc> amaranth: possibly - doe sit just need notification?
[05:25] <cjwatson> mvo: it'll echo to stdout and read from stdin
[05:25] <pitti> cjwatson: thanks, that would be better, I think
[05:26] <cjwatson> mvo: and then either run that inside a test harness that pretends to be a frontend, or type at it
[05:27] <Amaranth> jamiemcc: right
[05:27] <mvo> cjwatson: that sounds good, I have a look now
[05:27] <Amaranth> jamiemcc: just needs to be notified when tracker sees a file change
[05:27] <jamiemcc> amaranth: then yes in the near future we could do so
[05:27] <jamiemcc> atm we dont expose signals but its easy to do
[05:27] <Amaranth> jamiemcc: since you also have some stuff to handle running out of inotify watches, right?
[05:27] <pygi> asac, o well
[05:27] <Amaranth> don't want to redo that again and again
[05:28] <jamiemcc> amaranth: we used to poll but scrapped that as it made peoples machines hot
[05:28] <jamiemcc> now we check on startup if files have changed
[05:28] <wasabi> Somebody refresh me on launchpad bug ettiquite. I have a critical bug that makes an important package in main completely not useful, it really must be fixed before next release. Critical, Milestone = ?
[05:28] <Amaranth> jamiemcc: Oh, so that's why it does a lot on every login :)
[05:28] <jamiemcc> well we have to get the directory tree
[05:29] <jamiemcc> so its not a lot really
[05:29] <pygi> wasabi, perhaps tribe4 if it can be fixed on time? You volunteer? :)
[05:29] <pygi> wasabi, what's the package?
[05:29] <wasabi> samba/winbind
[05:29] <jamiemcc> when a file changes the parent directory also changes its mod time
[05:29] <Amaranth> jamiemcc: But then if I never logout (say I have an uptime of 2 weeks) the index will be really out-of-date, no?
[05:29] <jamiemcc> so we only check directories
[05:29] <wasabi> Actually, I'm making sure the latest update didn't fix it just now.
[05:29] <wasabi> bug 118977
[05:29] <ubotu> Launchpad bug 118977 in samba "winbindd will not start do to invalid cache path" [Critical,New]  https://launchpad.net/bugs/118977
[05:29] <jamiemcc> amaranth: yes unless you increase inotify watches
[05:29] <Amaranth> jamiemcc: You could get notified when the screensaver is active and do the update then
[05:30] <wasabi> Nope, not fixed.
[05:30] <wasabi> So tribe-4 is the appropiate milestone?
[05:30] <jamiemcc> possibly - we plan on easing polling back it once we are happy it has no detrimental effect on performance
[05:30] <pitti> seb128: and that won't break the desktop, no? :)
[05:30] <Chipzz> jamiemcc = tracker upstream? :)
[05:30] <Amaranth> Chipzz: yep
[05:30] <seb128> pitti: should not ;)
[05:30] <jamiemcc> Chipzz: yes
[05:31] <Chipzz> jamiemcc: congrats on getting tracker in ubuntu :)
[05:31] <jamiemcc> lets hope we remain there :)
[05:31] <ion_> Yay for tracker 
[05:31] <Amaranth> It's funny, I actually never use it
[05:31] <pygi> wasabi, you should poke a folk who did couple last uploads and discuss
[05:31] <Amaranth> But I've kept it around for the last month or so
[05:32] <wasabi> soren: poke. =)
[05:32] <pygi> coNP, hehe :)
[05:32] <ogra> eeek
[05:32] <Chipzz> jamiemcc: at the very least it should get you a lot of testing and feedback ;)
[05:32] <Hobbsee> ogra!
[05:32] <Amaranth> coNP: It doesn't eat resources :)
[05:33] <jamiemcc> Chipzz: yeah
[05:33] <Chipzz> even if it ends up not being included
[05:33] <pitti> cjwatson: install succeeded here as well
[05:33] <Chipzz> and I guess testing and feedback is something you could use ;)
[05:33] <ogra> pitti, ltsp-client-builder fails on the edubuntu server CD :/ with a Packages.gz hash sum mistmatch ...
[05:33] <cjwatson> pitti: rock on
[05:33] <cjwatson> pitti: I'm just waiting for LP to create the branch for me
[05:33] <pitti> ogra: )#$*#@
[05:33] <jamiemcc> sure - I just hate it when kernel changes stuff and causes proplems in tracker
[05:33] <ogra> which is weird since the same pacakges file was just used to install the base and edubuntu-desktop
[05:34] <pitti> cjwatson: and I'm  waiting for the shiny new OO.o packages to actually show up in unapproved :)
[05:35] <Amaranth> jamiemcc: Where would I look in the tracker code to find how it manages to use only idle CPU?
[05:35] <jamiemcc> nice(19)
[05:35] <jamiemcc> ioprio
[05:35] <Amaranth> That's all it is?
[05:35] <Amaranth> Wow, CFS much be helping a lot then :)
[05:35] <jamiemcc> yes it depends on kjernel working
[05:35] <jamiemcc> thats what I fear
[05:36] <coNP> desrt: why? :)
[05:36] <jamiemcc> on feisty tracker 0.6 runs as smooth as a babies bottom
[05:36] <Amaranth> jamiemcc: you fear cfs? why?
[05:36] <j1mc> hi all.  when should we be starting testing the tribe 4 iso's?  today?
[05:36] <desrt> coNP; because you're an oft-neglected class
[05:36] <jamiemcc> amaranth: I fear any change that  may break tracker performance
[05:36] <coNP> desrt: lol, yea :D
[05:36] <jamiemcc> if it aint broke dont fix it
[05:36] <Amaranth> tracker here will use 99% CPU when my system is idle and smoothly scale back as other things use it
[05:37] <Mithrandir> jamiemcc: I've had problems that closing files sometimes seem to take a long time when trackerd is running.  Any idea what the cause might be?
[05:37] <jamiemcc> amaranth: yeah ok but ioprio is not working?
[05:37] <Amaranth> Although I'd rather it jump to the second core
[05:37] <Amaranth> jamiemcc: Oh, I dunno
[05:37] <jamiemcc> IOPRIO has changed interface in kernel from feisty to gutsy
[05:37] <Amaranth> jamiemcc: Time to start using gutsy :)
[05:37] <jamiemcc> which means tracker will slow disk access until I change it
[05:37] <jamiemcc> I need fiesty for work!
[05:37] <ion_> CFS?
[05:38] <jamiemcc> completley fair scheduler
[05:38] <ion_> Ah
[05:40] <Amaranth> jamiemcc: vmware?
[05:40] <jamiemcc> Amaranth: I have spare partition
[05:40] <j1mc> Mithrandir: are the 07-Aug-2007 images candidates for tribe 4 in need of testing, or will the tribe 4 candidates be released later.
[05:41] <Mithrandir> j1mc: I believe the plan is to release new ISOs tomorrow.  I think we're waiting for at least a new OOo
[05:41] <j1mc> thanks.
[05:41] <j1mc>  Mithrandir> j1mc: I believe the plan is to release new ISOs tomorrow.
[05:41] <j1mc>                     I think we're waiting for at least a new OOo
[05:41] <j1mc> sorry.  :(
[05:42] <cjwatson> j1mc: current ubiquity is hosed too, upload nearly ready to fix that
[05:43] <j1mc> thanks, cjwatson.  also, i haven't been getting my xubuntu cd daily health check messages the past few days.
[05:43] <pitti> 15:31:03 WARNING        openoffice.org_2.3.0~src680m224-1ubuntu1.dsc: invalid build-depends field; cannot be parsed by apt: Problem Parsing Dependency
[05:44] <Hobbsee> pitti: case sensitive, or a bigger problem than that?
[05:44] <ogra> hmm
[05:44] <pitti> Hobbsee: ah, I got it
[05:44] <cjwatson> j1mc: indeed, that's because we migrated to a new machine and mailx wasn't installed on it; that's fixed now
[05:44] <cjwatson> you should get them tomorrow
[05:44] <cjwatson> or in fact I can just run them now ...
[05:44] <pitti> ...  ppc64] , , transl...
[05:44] <ogra> cjwatson, did d-i change so i dont have access to the cdrom dir in /target anymore ?
[05:44] <j1mc> cjwatson: no worries.  thank you for letting me know.
[05:44] <cjwatson> ogra: no
[05:45] <cjwatson> ogra: at least not to my knowledge, and not recently
[05:45] <ogra> semms my ltsp build fails because /cdrom contains nothing in the target system
[05:45] <cjwatson> ogra: when does this code run?
[05:45] <cjwatson> ltsp-client-builder.postinst?
[05:45] <ogra> after all software was installed
[05:45] <ogra> right
[05:46] <ogra> last step before grub
[05:46] <cjwatson> you run it at the same installer-menu-item as pkgsel, actually
[05:46] <ogra> but note that i started it from the menu since i had to work around the kino breakage
[05:46] <cjwatson> oh, but you depend on pkgsel
[05:46] <cjwatson> ok
[05:47] <cjwatson> ogra: had you got the final install message by the time you went back to the menu?
[05:47] <ogra> nope
[05:47] <wasabi> Hey so has the available tools for running a local apt repository changed much lately? I used to use some python program..... um.... mini-dinstall, a few years ago.
[05:47] <cjwatson> ogra: the one that says "Installation is complete"
[05:47] <gabaug> can somebody point me to the discussion/blueprints/etc that led to the Tracker decision?
[05:47] <ogra> i had it fail in pkgsel ... went to console, installed libavcodec1d in /target and restarted pkgsel
[05:47] <thom> wasabi: not an awful lot
[05:47] <wasabi> I shall then use mini-dinstall again!
[05:47] <ogra> after that was done it went back to the menu
[05:48] <cjwatson> ogra: can I get hold of the syslog?
[05:48] <ogra> where i then ran the ltsp build
[05:48] <Amaranth> gabaug: I dunno, we talked about it in seville
[05:48] <ogra> yup
[05:50] <gabaug> Amaranth: is it going to be included and turned on in the default install?
[05:51] <Amaranth> gabaug: already is
[05:52] <gabaug> Amaranth: isn't there normally mailing list/wiki/blueprint discussion for such decisions?  from my very uninformed perspective, the decision seems quite opaque
[05:53] <Amaranth> gabaug: there was a blueprint, it was discussed in seville
[05:53] <Amaranth> gabaug: And it was really only a matter of time before one of the two got included
[05:53] <ogra> cjwatson, oh, crap i didnt properly unmount the disk after copying the syslog ... its lost :(
[05:54] <gabaug> Amaranth: can you help me find the blueprint?  I'm not terribly familiar with launchpad, and don't see it right away
[05:54] <pitti> seb128: hm, it seems that deskbar-applet doesn't actually have a module for tracker?
[05:55] <pitti> seb128: I tried it on a freshly installed sytem, and it only offers 'web search' to me
[05:55] <seb128> pitti: libdeskbar-tracker needs to be installed
[05:55] <pitti> ah
[05:56] <seb128> pitti: we should seed it
[05:56] <seb128> I already changed tracker to tracker-search-tools
[05:56] <seb128> in the seed
[05:56] <pitti> seb128: Size: 31868
[05:56] <pitti> \o/
[05:56] <pitti> that's tiny
[05:56] <pitti> seb128: hm, so if we show off that feature, we should do it properly
[05:56] <seb128> pitti: do you want to change that now or after the tribe?
[05:56] <pitti> seb128: and we have plenty of time due to OO.o
[05:56] <seb128> right
[05:56] <pitti> so please go ahead
[05:57] <seb128> I'm wondering if we should seed tracker-utils also
[05:57] <Amaranth> gabaug: I can't navigate launchpad either
[05:57] <ogra> pitti, can you trigger a new build for me, kino is there now
[05:57] <Amaranth> gabaug: But we had a discussion or two about it in seville, I remember that
[05:57] <pitti> ogra: is that useful for you? (ubiquity and OO.o are broken still)
[05:58] <pitti> ogra: if you want a server CD for a general 'succeeds with install' testing, no problem
[05:58] <Amaranth> gabaug: It was just a matter of one of them fixing the problems with compiling before we started using them :)
[05:58] <ogra> yes, i need to debug ltsp as well ... it helps if the install doesnt die before :)
[05:59] <gabaug> Amaranth: what problems with compiling were there?  hasn't beagle been packaged for several releases?
[05:59] <LaserJock> Riddell: desktop-multiplier was already NEW'd for dapper-updates, apparently soyuz thinks -updates counts as a place to NEW packages ;-)
[05:59] <Amaranth> gabaug: No, their effect on compiling
[05:59] <Amaranth> gabaug: Both of them used to make compiles go like 3x slower
[06:00] <LaserJock> Riddell: infinity NEW'd the source last night so I'm assuming you're talking about the binary?
[06:00] <Riddell> LaserJock: no, I'm talking about the source new in gutsy
[06:00] <pitti> ogra: building
[06:01] <ogra> pitti, thanks a lot
[06:01] <ogra> (i only need -server)
[06:01] <LaserJock> Riddell: ok, we yes, it is in dapper-updates, but it wasn't ever removed
[06:01] <Riddell> LaserJock: well it's not in gutsy now
[06:02] <Riddell> and launchpad doesn't have entries for it in anything other than dapper
[06:02] <LaserJock> right
[06:02] <LaserJock> I uploaded it once to dapper-updates
[06:02] <Riddell> and as I say, it's in gutsy New queue
[06:02] <LaserJock> still?
[06:02] <Hobbsee> Riddell: kdesudo is still in the NEW queue too, it loosk like :(
[06:03] <Riddell> Hobbsee: no it isn't
[06:04] <Riddell> LaserJock: it was only uploaded 17 hours ago
[06:04] <LaserJock> Riddell: yes, but infinity said he NEW'd it
[06:04] <Amaranth> So, anyone have an opinion on going back to xlib using xcb? :)
[06:04] <Riddell> LaserJock: you said he Newed it for dapper-updates
[06:04] <Hobbsee> Riddell: oh, that's right.  i only saw it in http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
[06:04] <Amaranth> What were the problems with it before and does anyone know if they've been fixed?
[06:04] <LaserJock> Riddell: no for gutsy
[06:05] <LaserJock> Riddell: it was NEW'd for dapper-updates over a year ago
[06:05] <Amaranth> bryce: Do you know anything about xcb-backed xlib?
[06:05] <Riddell> LaserJock: ok, so my question was why did it disappear and what has changed that it can now
[06:06] <Riddell> Hobbsee: it needs promoted to main, which needs the main inclusion report approved
[06:06] <LaserJock> Riddell: it didn't disappear. It was uploaded to dapper-updates, that's it, it was *supposed* to be in the archives
[06:06] <LaserJock> but of course NEW'ing to dapper-updates seems to have cause archive problems
[06:07] <LaserJock> I just uploaded a new upstream version and soyuz thinks it's never seen it before
[06:08] <Riddell> ok, so it was never in dapper, only dapper-updates?
[06:08] <LaserJock> yes
[06:08] <LaserJock> that's correct
[06:08] <Riddell> LaserJock: it seems to have failed to build anywhere but i386, has that been checked for with this upload? https://launchpad.net/ubuntu/+source/desktop-multiplier/2.2-3-0ubuntu1
[06:08] <LaserJock> Riddell: it is i386 only
[06:09] <LaserJock> it's shipping a binary app in it
[06:09] <highvoltage> hello LaserJock
[06:09] <LaserJock> hi highvoltage
[06:09] <Riddell> so it is, bit of a mis-information issue on soyuz there
[06:10] <LaserJock> Riddell: yeah, I did set Architecture: i386 in debian/control
[06:10] <seb128> pitti: I've commited the seed changes, if you want to do an ubuntu-meta update you can do it now
[06:10] <Hobbsee> Riddell: oh, right, i thought it had been. my error
[06:10] <pitti> ok
[06:11] <Hobbsee> Riddell: (the report done)
[06:11] <Hobbsee> (and approved)
[06:11] <Riddell> seb128: seed changes?  anything I should care about?
[06:12] <pitti> $ q -Q unapproved accept openoffice.org
[06:12] <pitti> \o/
[06:12] <seb128> Riddell: no, I already merged them to edubuntu and kubuntu
[06:12] <bryce> Amaranth: yes I've gotten the low-down from jcristau and timo about that
[06:12] <seb128> Riddell: adding tracker packages to ubuntu
[06:12] <Amaranth> bryce: So are we getting it again?
[06:12] <bryce> Amaranth: sounds like maybe during Gutsy+1 we can get it sorted out and reactivated
[06:12] <Amaranth> Oh
[06:13] <Amaranth> Well, hopefully compiz 0.5.2 is good enough to stick with for gutsy then :/
[06:13] <Amaranth> Because compiz in git is starting the conversion to xcb so we either have to hope davidr finishes quickly or use the xcb-backed xlib
[06:14] <LaserJock> Riddell: do you need anything more for desktop-multiplier?
[06:17] <Riddell> nope, accepted, sorry for the grilling
[06:18] <LaserJock> Riddell: no problem, it's a weird situation
[06:24] <pitti> cjwatson: would you know why ubuntu-meta update removed things like dselect, ppp, pppoeconf, or reiserfsprogs from standard? (all arches)
[06:24] <cjwatson> pitti: they got moved to recommends
[06:24] <cjwatson> random cleanup on my part
[06:24] <pitti> ah, heh, indeed
[06:24] <pitti> cjwatson: sorry for the noise
[06:24] <cjwatson> np
[06:25] <pitti> cjwatson: so, I have OO.o and new u-meta in the queue now; I can run a publisher and grab ubiquity later, or wait for it
[06:25] <pitti> depending on whether there's a package
[06:26] <cjwatson> pitti: give me about five minutes
[06:26] <cjwatson> I've got the package, am just checking it
[06:26] <pitti> cjwatson: no hurry, OO.o will take long enough to build
[06:28] <cjwatson> ok
[06:28] <cjwatson> yes, might as well get started on that
[06:28] <cjwatson> I'm uploading ubiquity 1.5.7 now
[06:33] <pitti> slomo_: can you please commit your recent avahi upload to the bzr?
[06:34] <pitti> slomo_: oh, sorry, that wasn't you
[06:42] <tkamppeter_> pitti, Mithrandir. I have reported bug 130903 now.
[06:42] <ubotu> Launchpad bug 130903 in system-config-printer "Replace gnome-cups-manager by system-config-printer" [High,Confirmed]  https://launchpad.net/bugs/130903
[06:44] <pitti> tkamppeter_: thanks; ah, already milestoned
[06:44] <tkamppeter_> pitti, this replacement will fix most of these ones: https://bugs.launchpad.net/ubuntu/+source/gnome-cups-manager/
[06:47] <tkamppeter_> pitti, should I also milestone bug 130298?
[06:47] <ubotu> Launchpad bug 130298 in libnotify "add_action() method does not work at all" [High,Confirmed]  https://launchpad.net/bugs/130298
[06:47] <pitti> tkamppeter_: if you want; is this known and worked on upstream?
[06:48] <pitti> tkamppeter_: it's not a trivial problem, after looking at it for 5 minutes
[06:49] <pitti> cjwatson: oh, desktop CD gfxboot has "OEM install" which just produces a weird dialog box
[06:49] <tkamppeter_> pitti, Fedora uses the same version of libnotify as we are using and under Fedora it works.
[06:50] <pitti> tkamppeter_: ok, might be worth looking at their patches then
[06:52] <pitti> ogra: oh, btw, your server CDs are ready (for some hours already; sorry, forgot to check)
[06:55] <tkamppeter_> pitti, neither we nor Fedora has patches on libnotify
[06:55] <pitti> tkamppeter_: hm, weird then.. /me blames gtk
[06:56] <pitti> tkamppeter_: then I guess a proper gdb session is in order...
[06:56] <tkamppeter_> pitti: Only difference between Fedora and us is that they have notify-python 0.1.0 and we have 0.1.1, perhaps a regression in 0.1.1?
[06:56] <pitti> tkamppeter_: as I wrote in the bug, it's not a bug in the python bindings; it's in libnotify itself
[06:57] <ion_> system-config-printer is nice, but it could use a bit of UI love. (0.7.71+-svn1371-0ubuntu1 here)
[06:58] <tkamppeter> Ion_, which kind? Do you mean a lot of icons and little pictures?
[06:58] <pitti> no, less elements preferably :)
[06:59] <ion_> Yeah, less elements. Also i really think it should make the first added printer the default printer automatically.
[06:59] <tkamppeter> Or something which one can easily implement without needing art workers?
[06:59] <pitti> ion_: I was just going to suggest that :)
[06:59] <tkamppeter> Yes, making the first added printer the default printer is easy to implement.
[07:00] <pitti> tkamppeter: btw, it still selected gdi instead of splix (hal-cups-utils autolove)
[07:00] <ion_> Also the dialog to choose a PPD is really confusing. I think its something that should be behind an Advanced... button.
[07:01] <ion_> A newbie has no idea whether she should choose somethingsomething-hpijs.ppd or somethingsomething-ljet4.ppd
[07:01] <pitti> automatically creating a printer name would be nice, too
[07:01] <tkamppeter> What do you think with "less elements"? Removing functionality?
[07:01] <ion_> pitti: Yeah
[07:01] <pitti> *first* selecting the detected printer, and *then* giving it a name,location etc. would be much easier
[07:01] <ion_> tkamppeter: Hiding functionality that only advanced users should see behind an Advanced... button or something equivalent.
[07:01] <pitti> tkamppeter: functionality should stay, but it should be hidden better, somehow
[07:01] <ion_> s/should/are likely to/
[07:02] <pitti> tkamppeter: ^ that touches more intricate UI changes, though
[07:02] <ion_> s/are likely to see/are likely to use/ :-)
[07:02] <tkamppeter> pitti, you?e right with that, I have also moved entering the printer name after selecting the printer in printerdrake.
[07:02] <pitti> tkamppeter: that's also what the webui and g-c-m does, and I think it's more logical
[07:03] <ion_> It would also be nice if the add printer dialog detected a parallel port printer automatically.
[07:03] <tkamppeter> Yes, we should have something like a "green mode", press the shutter button and get a correct picture.
[07:03] <pitti> that might be harder
[07:03] <pitti> tkamppeter: :)
[07:03] <ion_> pitti: From my dmesg: [   34.368000]  parport0: Printer, Hewlett-Packard HP LaserJet 1100
[07:03] <pitti> tkamppeter: I think that's pretty much covered with hal-cups-utils
[07:04] <mikmor2> can you use gfxboot with isolinux?
[07:05] <tkamppeter> In this mode the name input and driver selection page would be totally skipped and after closing the wizard the new printer is selected in the main window and there the "Options Installed" tab opened, so that the user does not forget to tell which accessories he has.
[07:06] <tkamppeter> pitti, does "lpinfo -l -v" show your parallel printer with make and model name? Does HAL show your parallel printer with make and model name?
[07:07] <pitti> tkamppeter: ion_ is here --->
[07:07] <cjwatson> pitti: oem> hmm
[07:07] <cjwatson> checking that out now
[07:07] <tkamppeter> pitti, what do you mean with that?
[07:07] <pitti> cjwatson: does ubiquity actually support OEM now? or shouldn't the entry appear in the first place?
[07:08] <pitti> tkamppeter: ion_ has the parallel printer, I don't :)
[07:08] <ion_> tkamppeter: Neither.
[07:08] <cjwatson> pitti: oh dear me that's odd
[07:08] <cjwatson> pitti: yes, it does, see the ubiquity-oem spec
[07:08] <pitti> kewl
[07:08] <tkamppeter> ion_, can you check the following:
[07:08] <ion_> tkamppeter: But something in the kernel does detect the make and model.
[07:09] <tkamppeter> Ion_: 1. Does "lpinfo -l -v" show your parallel printer with make and model?
[07:09] <ion_> tkamppeter: Neither lpinfo or HAL show it.
[07:10] <tkamppeter> ion_: 2. Does HAL report your parallel printer with make and model? Use hal-device-manager to check that.
[07:10] <cjwatson> pitti: ah, the problem is that it should point to /casper/vmlinuz on the live CD, not /install/vmlinuz. I'll fix that, thanks
[07:10] <cjwatson> (and /casper/initrd.gz)
[07:10] <tkamppeter> ion_, can you make sure the printer is turned on and connected and then do
[07:10] <ion_> Nothing in the /sys tree seems to know it either. (based on zargs -- /sys/**/*(.) -- grep LaserJet 2>/dev/null)
[07:10] <tkamppeter> sudo rmmod lp
[07:10] <tkamppeter> sudo rmmod ppdev
[07:11] <tkamppeter> sudo rmmod parport_pc
[07:11] <tkamppeter> sudo rmmod parport
[07:11] <tkamppeter> sudo modprobe lp ppdev
[07:11] <tkamppeter> and then repeat the two tests.
[07:14] <ion_> tkamppeter: ppdev wasnt loaded, the others were. Just by loading the ppdev module, lpinfo shows the printer correctly.
[07:16] <cjwatson> pitti: fixed in debian-cd on antimony; next rebuilds will be happier
[07:16] <tkamppeter> ion_, pitti, AFAIR the CUPS startup script should assure that ppdev is loaded.
[07:17] <tkamppeter> ion_ could you do the following test:
[07:17] <tkamppeter> Turn off your printer and do
[07:17] <tkamppeter> sudo rmmod ppdev
[07:17] <ion_> tkamppeter: After loading ppdev, s-c-printer also finds the printer automatically.
[07:17] <tkamppeter> sudo modprobe ppdev
[07:18] <tkamppeter> Does your printer disappear from lpinfo now?
[07:18] <tkamppeter> Than turn it on again and reload ppdev again. Does the printer reappear?
[07:20] <cjwatson> pitti: is it just me, or is the usplash progress bar skewed to the right with respect to the logo?
[07:20] <cjwatson> or is this a vmware artefact?
[07:21] <ion_> Printer off, rmmod ppdev, modprobe ppdev: lpinfo doesnt show it. Printer on: lpinfo shows it. rmmod ppdev, modprobe ppdev: lpinfo still shows it.
[07:22] <ion_> tkamppeter: From the cupsys init script:              -a -z "$(grep -e ' lp$' /proc/devices 2>/dev/null)" ] ; then
[07:22] <ion_> tkamppeter: That test fails.
[07:22] <ion_> tkamppeter: Thus ppdev doesnt get loaded.
[07:23] <tkamppeter> ion_, thanks, so we do not need to reload all the modules. Result from that is that we should reload the ppdev module when starting the add printer wizard, to discover parallel printers turned on after boot. This should be done via a SUID helper program, as s-c-p runs as non-root user.
[07:23] <ion_> tkamppeter: Even reloading ppdev doesnt seem to be necessary as long as its loaded on startup.
[07:24] <ion_> tkamppeter: The cupsys script just doesnt load it here.
[07:24] <pitti> cjwatson: no, happens everywhere I think
[07:24] <tkamppeter> pitti, can you see whether the cupsys startup script really takes care that ppdev gets automatically loaded on CUPS startup?
[07:24] <pitti> cjwatson: I pinged kwwii some days ago, no response so far
[07:24] <tkamppeter> ion_ report a cupsys bug on Launchpad.
[07:25] <pitti> tkamppeter: yes, it does
[07:25] <ion_> tkamppeter: Will do.
[07:26] <tkamppeter> _ion, now to HAL, does HAL report your parallel printer? Does it require to reload ppdev to update the state (test by turning on and off the printer)?
[07:27] <ogra> pitti, thanks ...
[07:27] <ion_> tkamppeter: HAL doesnt report it.
[07:28] <tkamppeter> _ion one other important thing: AFAIR loading ppdev at system startup only helps if the printer is turned on at system startup. If it is turned on later, a reload of ppdev is requirted. Can you check and confirm this?
[07:29] <ion_> ti202109 < ion_> Printer off, rmmod ppdev, modprobe ppdev: lpinfo doesnt show it. Printer on: lpinfo shows it. rmmod ppdev, modprobe ppdev: lpinfo still shows it.
[07:29] <tkamppeter> ion_, so HAL does not include the parallel ports in general?
[07:29] <ion_> Reloading ppdev wasnt required for lpinfo to show it after it was turned on.
[07:30] <ion_> tkamppeter: I dont know what HAL *should* do. It shows the port itself, but not the printer connected to it.
[07:30] <ion_>   pnp.description = 'ECP printer port'  (string)
[07:30] <ion_>   info.linux.driver = 'parport_pc'  (string)
[07:31] <tkamppeter> So ion_, then we do not need to modify s-c-p, as ppdev is automatically recognizing the parallel printer. This means that the parallel port got hot-pluggable under Linux.
[07:33] <tkamppeter> ion_, so we should perhaps report a bug against HAL, telling that with ppdev loaded a parallel printer gets automatically detected without any user interaction and so it is easy to implement that HAL can report a parallel printer and then an auto queue setup could be triggered.
[07:34] <ion_> tkamppeter: HAL probably would need to poll the parallel port every once in a while. There was no message in dmesg about the printer being turned on.
[07:34] <tkamppeter> ion_, would it be possible that HAL could do so?
[07:56] <pitti> re
[09:06] <mikmor2> hmm..
[09:06] <mikmor2> isn't dpkg strict about keeping the permissions of the files it installs the same as the original?
[09:07] <pitti> mikmor2: usually yes, except when there is a dpkg-statoverride for that file
[09:07] <pitti> mikmor2: or it is a conffile in /etc
[09:08] <LaserJock> there's also dh_fixperms that can mess around with permissions when building the .deb
[09:11] <pitti> mikmor2: what LaserJock said, that depends on your definiton of 'original'
[09:11] <pitti> mikmor2: 'original' == 'as in the .deb' or 'as in the built tree
[09:12] <mjg59> Ok, well tracker-search-tool seems to work pretty much as expected
[09:14] <pitti> doko: is "#if defined(i386)" (and friends) true on lpia?
[09:14] <pitti> doko: ^ that's from some i386 optimizations in zip, which should be built on lpia, too
[09:17] <mjg59> I suspect that we want an icon for trackerd to indicate that it's indexing your entire filesystem
[09:18] <ion_> Yeah, that would be good.
[09:18] <ion_> Also all tracker clients that use the file searching functionality should have a widget that says tracker is still indexing, the results might be incomplete when needed. :-)
[09:18] <pitti> mjg59: we already have that, it's called 'gnome-system-monitor' :-P
[09:18] <pygi> bla, bla, bla
[09:19] <pygi> ion_, tracker disabled :)
[09:19] <ion_> pitti: :-)
[09:19] <jamiemcc> pygi: I have found the problem for that
[09:19] <pygi> jamiemcc, hm? What are you talking about? :)
[09:19] <ion_> Oh, i only now realized ubuntu-desktop recommends tracker nowadays. Thats great.
[09:20] <mjg59> ion_: I've just filed that
[09:20] <mjg59> jamiemcc: Oh, right, hadn't noticed you were in here
[09:21] <jamiemcc> hi mjg59
[09:21] <mjg59> I've just thrown another couple of bugs at you
[09:21] <mjg59> (Thanks for the fast response to the battery throttling one)
[09:21] <jamiemcc> yeah that one is critical
[09:21] <jamiemcc> im doing it atm
[09:21] <mjg59> jamiemcc: One thing I noticed on reading the code - the BatteryThrottle option is read, but ->throttle (rather than battery_throttle) is set
[09:21] <mjg59> Of course, it's not used anywhere yet anyway :)
[09:22] <jamiemcc> we have partial code to support battery throttle but its not finished yet
[09:22] <ion_> I hope gutsy installing tracker by default is finally the thing that makes people add support for things like shared file tags with tracker as the backend to their software.
[09:22] <jamiemcc> anyway suspending indexing might be better
[09:23] <mjg59> jamiemcc: I suspect so. We really don't want any unnecessary disk access on battery
[09:23] <jamiemcc> ion_ we hope so too - im sure ubuntu would accept a nuatilus patch to use tracker tags
[09:23] <jamiemcc> mjg59: how much content did you index?
[09:23] <jamiemcc> do you have millions of emails and files?
[09:24] <mjg59> jamiemcc: About 20G in ~, about 30G in total
[09:24] <jamiemcc> oh no wonder
[09:24] <mjg59> It's also only a 1.8" drive
[09:24] <jamiemcc> you can set no watch dirs for stuff
[09:24] <jamiemcc> that does not require indexing
[09:24] <mjg59> I don't really mind it taking this long, but it would be nice for it to tell me what it's doing
[09:24] <mjg59> jamiemcc: What's the behaviour if I reboot during indexing?
[09:25] <ion_> The tray icon that tells tracker is indexing could also say that the indexing is suspended because the computer is running on battery, and it could have a context menu item that allows a user to toggle the suspend-on-battery feature.
[09:25] <jamiemcc> yeah thats something we will do - we have tracker-status command line tool for it
[09:25] <jamiemcc> mjg59: it should resume from where it left
[09:25] <wasabi> I don't know why I would want to know what tracker is doing.
[09:25] <mjg59> jamiemcc: At the moment tracker-status says "Watching"
[09:25] <wasabi> It should just do the right thing, regardless.
[09:26] <jamiemcc> we can display a msg in the status bar of tst
[09:26] <mjg59> wasabi: Because (a) it causes noticable disk i/o, and (b) it means that you won't get full results back
[09:26] <pitti> wasabi: augmenting search results with an indexing completeness would be useful, though
[09:26] <wasabi> I really think b) is something that should be told about at search time.
[09:26] <mjg59> jamiemcc: For the initial index, I suspect that a notification icon would be appropriate
[09:26] <jamiemcc> yeah
[09:26] <wasabi> That's how Vista does it... "This search may take awhile because blah blah blah is indexing your files."
[09:26] <wasabi> a) should just be fixed. ;)
[09:26] <jamiemcc> yeah its nopt a problem to do
[09:26] <mjg59> wasabi: Kind of hard to avoid disk i/o when you're reading every file
[09:27] <wasabi> Sure, but it should not interfere with anything (regardless of Linux's current inability to make it that way)
[09:27] <jamiemcc> atm gutsy kernel ioprio has changed interface so I need to mod tracker to use the new interface
[09:27] <mjg59> And kind of hard to make it unnoticable when it results in a bright green LED flashing at me, makes my lap noticably warmer and can be heard from across the room :)
[09:27] <jamiemcc> thern it wont slow down disk access
[09:28] <wasabi> Well, I'd say it shouldn't do a full disk index while on battery, ever, because it's on battery, and that's bad. But it should nicely inform the user of this, but only when teh user cares: when he's doing an actual search.
[09:28] <jamiemcc> wasabi: i agree
[09:29] <wasabi> "Search results may be incomplete, would you like to begin a full disk index now? This may reduce the life of your battery. Blah.
[09:29] <mjg59> wasabi: That's an orthogonal issue
[09:29] <wasabi> Well, if tracker provides other desktop services I'm not aware of, then sure.
[09:29] <ijuz> questions suck, it should better eat the battery
[09:29] <wasabi> But for now it's just searching, no?
[09:29] <mjg59> wasabi: It's pretty reasonable for people to ask what's causing so much disk access
[09:30] <wasabi> I agree, and we have tools for that.
[09:30] <mjg59> Such as?
[09:30] <wasabi> Gnome-system-monitor. =)
[09:31] <mjg59> wasabi: Doesn't tell me which applications are responsible for i/o
[09:31] <wasabi> It should.
[09:31] <mjg59> How?
[09:31] <ion_> A novice user would need to 0) realize she should use gnome-system-monitor and 1) have the knowledge what the trackerd entry on the top means.
[09:31] <jamiemcc> what would be nice is to have an applet which shows indexing and also gives you the option to pause
[09:31] <wasabi> A novice user isn't going to care that his disk might be spinning.
[09:31] <wasabi> My mom? Wouldn't care.
[09:32] <wasabi> My dad? Probably doesn't even know what a disk is.
[09:32] <mjg59> wasabi: Right now, my computer is clearly behaving differently to usual
[09:32] <wasabi> Because jamiemcc has not fixed the IOPRIO issue.
[09:32] <pitti> wasabi: my gf would complain about loud laptop all the time
[09:32] <mjg59> People do wonder about that sort of thing
[09:32] <mjg59> wasabi: No
[09:33] <mjg59> It's nothing to do with the ioprio issue
[09:34] <wasabi> Hmm. g-s-m needs some IO measurement, yeah.
[09:36] <wasabi> I guess this is a fight I can't win today. I just think we should reserve annoying popups for cases where the user either asks for an annoying pop up, or needs to take action.
[09:36] <wasabi> I guess then it just becomes a standard part of Ubuntu to have a notification icon pop up on your first logon, always, eh?
[09:37] <ion_> An icon in the tray isnt exactly a popup.
[09:37] <mjg59> We should notify the user when the system state is abnormal
[09:37] <wasabi> Logging into the system for the first time isn't abnormal. Heh.
[09:38] <jamiemcc> mjg59: libnotify is good for that
[09:38] <mjg59> Right, logging in for the first time isn't. That's why we don't do that.
[09:38] <hunger> jamiemcc: Where do you get the data from?
[09:38] <mjg59> However, if something is happening on the first login that /is/ abnormal, we should let the user know
[09:38] <jamiemcc> hunger: what data?
[09:38] <hunger> jamiemcc: I get a digest of the log-files by mail, that is not really feastable for a notification though.
[09:39] <hunger> jamiemcc: That something is going wrong. SMART failures, whatnot.
[09:39] <mjg59> hunger: That's kind of a separate issue
[09:39] <jamiemcc> I just mean send a notification when you log on for the first time and tracker does its initial indeixng
[09:39] <mjg59> Ideally hal would cope with that
[09:39] <ijuz> are the build dependencies brocken for somebody else too? (gutsy)
[09:40] <mjg59> It would be nice to put the smart data in hal, then it's sharable with other applications
[09:40] <wasabi> WWSJD  <--- what would steve jobs do
[09:40] <wasabi> hehe
[09:40] <hunger> Can I turn of tracker? This desktop indexing just eats up all my space.
[09:40] <jamiemcc> hunger: yes or you could tell iot to index a subset of your home dir
[09:41] <ion_> Indexing Preferences
[09:42] <ion_> Nice that tracker uses ~/.config/tracker now.
[09:42] <pitti> jamiemcc: ah, does it default to *not* index /usr and such?
[09:42] <mjg59> disk-usage-analyser ought to be able to assign usage to different applications
[09:42] <ion_> pitti: Yeah
[09:43] <pitti> great
[09:43] <jamiemcc> pitti: it only defaults to index home and usr/share/applications
[09:43] <pitti> jamiemcc: that's great
[09:43] <pitti> jamiemcc: what does it do with files like movies and music?
[09:43] <jamiemcc> it indexes them :)
[09:43] <jamiemcc> metadata only
[09:44] <pitti> jamiemcc: does it do some 'binary stuff' detection and ignores them?
[09:44] <pitti> jamiemcc: ah, good
[09:44] <jamiemcc> no we check mime type
[09:44] <mjg59> "1GB in use by Tracker, 200MB in use by Firefox, 20GB in use by unknown applications", that sort of thing
[09:44] <pitti> jamiemcc: rock
[09:46] <pitti> ok, I'm off for now; OO.o will build a while, so I might come back later, or tomorrow
[09:46] <jamiemcc> pitti: I will have an updated tracke rin a few hours
[09:46] <pitti> jamiemcc: great
[09:46] <ogra> pitti, if you find any traces of y nightly ltsp upload, please approve
[09:46] <pitti> jamiemcc: I think we can fit it in if the diff looks ok
[09:46] <ogra> s/y/a/
[09:46] <jamiemcc> great
[09:46] <ogra> :)
[09:47] <pitti> jamiemcc: can you please mail the diff between current gutsy version and the new one to pitti@ubuntu.com?
[09:47] <jamiemcc> sure
[09:47] <jamiemcc> it will be an official release too
[09:47] <jamiemcc> 0.6.1
[09:47] <pitti> jamiemcc: thanks a lot; then I can do it in the morning
[09:47] <jamiemcc> oh great more time to test
[09:47] <pitti> ogra: I'll do that in the morning or tonight; I guess ltsp builds fast
[09:48] <ogra> yeah
[09:48] <ogra> i'm not sure its broken yet :)
[09:48] <ion_> Depending on everyones definition of the morning. :-)
[09:48] <ogra> lets see how that running instal performs
[09:48] <pitti> ogra: please don't hesitate to phone or sms me if you need it urgently
[09:48] <ogra> i would love to have tomorrow to sort my liveCDs out though ... cross your fingers it works :)
[09:48] <pitti> ogra: OO.o! :)
[09:49] <ogra> pitti, its a good excuse to go to bed if youre not around later :)
[09:49] <pitti> ATM it makes more sense for me to get to bed and up again early than doing another nightshift
[09:49] <ogra> yeah
[09:50] <ogra> GAH !
[09:50] <ogra> it didnt :(
[09:55] <wasabi> hmm... still no way to create a passwordless keyring
[09:55] <ogra> cjwatson, in case you still want to take a look at the changelog of the failed ltsp build: http://people.ubuntu.com/~ogra/syslog_tribe4
[09:55] <calc> http://www.linuxtoday.com/infrastructure/2007080303226OPDT <- reminds me of my laptop
[09:56] <calc> i don't mind using XP, but Vista is horrendous
[09:56] <ogra> *gives
[10:00] <highvoltage> ogra: :(
[10:01] <EvanCarroll> I'm having a lot of problems with nagios2, I can't uninstall it, and I can't install it, I'm getting errors scripts going both ways
[10:01] <EvanCarroll> Is there anyway to say, install this as it stands and ignore the system's state.
[10:01] <EvanCarroll> dpkg --force-all -i does not work.
[10:03] <ion_> I might not be wrong if i were to guess that your problem is caused in the first place by breaking the system by using --force flags in the past.
[10:03] <pygi> meh, somebody broke evolution for me
[10:03] <pygi> so much things broken today xD
[10:04] <seb128> pygi: how?
[10:04] <EvanCarroll> no, I broke this by deleteing /etc/nagios2 and thinking a force-reinstall would work
[10:04] <EvanCarroll> but the faults in both the nagios2 maintainer and the faults in dpkg/deb are to much for this little ubuntu box to overcome.
[10:05] <ion_> From now on, think that force-anything will break your system. Also, this is not a support channel.
[10:05] <mikmor2> pitti: thanks for responding to me earlier.. was afk
[10:05] <pygi> seb128, it won't check mail at all
[10:05] <EvanCarroll> because the uninstall script requires a successfull /etc/init.d/nagios2 restart, and that requires a conf file, which I deleted.
[10:06] <pygi> I don't remember updating evolution tho, but I might be wrong
[10:06] <seb128> pygi: weird, maybe a server problem? otherwise try to evolution --force-shutdown, nobody else bugged about it and evolution didn't change for a week
[10:06] <pygi> seb128, yup, I'll check with some other server
[10:06] <EvanCarroll> ion_: i reiterate, the system was broke before the --force, which failed and didn't work as advertised.
[10:07] <EvanCarroll> the goal was to --reinstall, that didn't work, so i tried --force (with dpkg) which also didn't work for the same reason.
[10:11] <pygi> seb128, hm, it responded now
[10:11] <pygi> seem like extremely slow server
[10:11] <pygi> (took it like 8 or so minutes)
[10:19] <kdub433> when is gutsy coming out?
[10:19] <stdin> !gutst
[10:19] <ubotu> Sorry, I don't know anything about gutst - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[10:19] <coNP> !gutsy | kdub433
[10:19] <stdin> !gutsy
[10:19] <ubotu> kdub433: Gutsy Gibbon is the code name for the next release of Ubuntu (7.10) | (due October 2007) | It is development software, as such unstable, support _only_ in #ubuntu+1
[10:20] <stdin> 7.10  = 10/2007
[10:20] <kdub433> thanks
[10:24] <mikmor2> cjwatson: Have you considered making the "Skip" button in Ubiquity (while trying to connect with APT) available to click earlier?
[10:24] <mikmor2> The whole "configuring apt" runs for quite a while before it times out
[10:24] <doko> pitti: $ gcc -E -dM - < /dev/null | grep i386
[10:24] <doko> #define __i386 1
[10:24] <doko> #define i386 1
[10:24] <doko> #define __i386__ 1
[10:33] <calc> doko: if i send you the patches for ooo-build can you commit them for me?
[10:35] <doko> calc: sure
[10:35] <calc> doko: ok i'll email them to you
[10:36] <doko> calc: tomorrow morning, not now
[10:36] <calc> ok np
[10:36] <ijuz> doko: have you seen the dependency problem of libc6-dev ? seems to be a typo
[10:37] <calc> doko: ok sent to you, thanks :)
[10:38] <calc> doko: mention my name of course so i can apply to get direct access :)
[10:38] <Amaranth> what is ooo-build?
[10:38] <calc> Amaranth: linux dists build system for openoffice
[10:39] <calc> Amaranth: its hosted on svn.gnome.org
[10:39] <Amaranth> hey, i can commit to that ;)
[10:39] <Amaranth> doesn't openoffice have it's own build system?
[10:40] <calc> Amaranth: i don't know the full history of how ooo-build came to be but i think it was due to being hard to get stuff integrated upstream, doko probably knows more about that part than me
[10:51] <cjwatson> EvanCarroll: easiest way is usually to edit the maintainer script in /var/lib/dpkg/info/ and comment out the line that's failing and that you don't care about. dpkg --force-* has absolutely no effect on any of that so don't bother using it.
[10:51] <cjwatson> mikmor2: I'm not sure skip is the right answer there, possibly something else
[10:51] <cjwatson> I think it's doing more work than it should as well
[10:52] <mikmor2> cjwatson: yeah.. its not so bad if you're only installing like a human normally would.. but i've begun to "notice" it
[10:52] <mikmor2> heh
[11:01] <cjwatson> ogra: I'd recommend looking at the bit of base-installer/debian/postinst that writes out /target/etc/apt/apt.conf.d/00NoMountCDROM
[11:01] <cjwatson> ogra: I reckon your problem is that at some point apt unmounts /cdrom
[11:02] <cjwatson> ogra: if you do that same bit of configuration in the chroot you build for the duration of building it, it should stop things going haywire
[11:02] <cjwatson> ... probably
[11:05] <EvanCarroll> cjwatson: thanks for the tip, I've stored it away, I ended up hacking the init script to return a true value so i could reinstall it
[11:06] <cjwatson> EvanCarroll: that's valid too
[11:06] <EvanCarroll> cjwatson: i like perlbars convention, ./t/* for tests, if you want to skip them, just --force-install, and they get skipped.
[11:06] <EvanCarroll> not having a means to bypass these type of tests seems to take a lot of time when it stings, I'll try your way next time
[11:06] <cjwatson> maintainer scripts do enough potentially weird stuff that it's a bit worrying to provide a means to bypass them without reading them
[11:07] <EvanCarroll> you often want to just install the upstream and let dpkg make all of the assumption it can, that will often return your system to a stable state.
[11:07] <EvanCarroll> upstream being, whatever ubuntu's universe package is
[11:08] <EvanCarroll> my mental image of what is going on has always been something of this (what I'm trying to achive) remove the old files from the control of package manager, override them all with the new files, and in doing so retake ownership
[11:09] <EvanCarroll> I'm not sure if thats what I'm doing half of the time when I bash on my keyboard and make it work, but that is often what I'm trying to achive when I'm playing with --force
[11:10] <cjwatson> ok, but when people say --force-all is a bad idea they really mean it. It really has in real life been known to replace people's /sbin with a regular file.
[11:11] <EvanCarroll> if my system has to be borked, at least give me a story I can entertain people with. ;)
[11:11] <cjwatson> the dangerous options in --force-* are strictly for those who know how dpkg operates and need to extricate themselves from weird situations (that you don't normally get into)
[11:12] <cjwatson> it's best to work out what each one does before using it, and don't use it if it doesn't apply
[11:13] <cjwatson> --force-overwrite, --force-depends, and --force-confmiss are the only ones I've ever needed to use in eight years of running Debian/Ubuntu systems
[11:13] <cjwatson> (in very different situations)
[11:14] <EvanCarroll> I've been on deb for 7yrs, and I've always just used --force-all, but it has always been in panicked situations and never stung, and never worked that i can recall
[11:14] <EvanCarroll> and it has always been for the same reason
[11:14] <EvanCarroll> can't install, or uninstall
[11:14] <cjwatson> right, learn from that and stop using it please before we have to help you repair your system. :)
[11:14] <cjwatson> maintainer script problems (any error that talks about the {pre,post}-{installation,removal} script returning an error) are not subject to --force-*.
[11:15] <EvanCarroll> guess I should have been hacking /var/lib/dpkg/info, it always seems like the more hackish solution is in messing with the files rather than going through the UI
[11:15] <EvanCarroll> cjwatson: will make note, thanks
[11:15] <cjwatson> but there is no UI for this.
[11:15] <zerwas_> Can somebody explain me why Ubuntu is not using the graphical interface of GRUB with mouse support by default? I know many people who have no idea what to do when they see the GRUB menu
[11:15] <cjwatson> so it's not relevant which is more hackish, because only one option will actually work. :)
[11:16] <cjwatson> zerwas_: we configure the grub menu not to appear by default unless you're multi-booting ...
[11:16] <EvanCarroll> cjwatson: well said.
[11:16] <cjwatson> zerwas_: we don't use the graphical interface because (IIRC) we tried it at one point and it broke certain systems in subtle ways.
[11:16] <cjwatson> same as the reason we don't use grub on the CDs
[11:17] <zerwas_> cjwatson, ok, sounds evident
[11:17] <zerwas_> so a place for the GRUB devs to make it more stable
[11:18] <cjwatson> the GRUB developers are not interested in developing GRUB 1, for the most part
[11:18] <cjwatson> most of them only care about GRUB 2
[11:18] <cjwatson> but it's dubiously stable as yet
[11:20] <LaserJock> cjwatson: do you know if there's been any thought to shipping an Ubuntu grub splash image? not using it by default but having it there for the multi-booters?
[11:20] <ompaul> cjwatson, iirc (the now defunct) kanotix had grub on all disks, however kanotix although I liked it was always a bit more hackish than polish
[11:21] <cjwatson> ompaul: we tried it. it broke. nuff said.
[11:21] <wasabi> i'd vote for setting the grub timeout lower. =)
[11:22] <cjwatson> LaserJock: basically just not a priority because it isn't used by default, though I wouldn't object to it.
[11:22] <LaserJock> cjwatson: ok, makes sense. I only thought of it because of my GSoC student's project
[11:23] <cjwatson> wasabi: it's already a mere three seconds if you're single-booting, and some systems take some of that time to do a mode switch. I vehemently oppose lowering it beyond that
[11:23] <wasabi> Oh. Why?
[11:23] <wasabi> It works with a depressed key, even with a 0 timeout, no?
[11:23] <LaserJock> people might need to get to the memtest or "recovery" mode right?
[11:26] <ompaul> wasabi, the reaction time of a new user to press ESC with confidence has to be taken into consideration, and the aforementioned new user may need a prompt
[11:26] <ompaul> wasabi, onscreen prompt that is
[11:27] <wasabi> I guess. Most "new users" I know seem to deal with windows just fine, where only techs know to press F8. =)
[11:40] <zerwas_> ok so no chance to have a graphical boot (like OpenSUSE has) in the future. GRUB 2 is under development and will stay that for some time
[11:48] <cjwatson> wasabi: my parents are set up with Windows/Ubuntu dual-boot, and (at least until Windows ate itself with spyware) used both fairly regularly. They tend to read a screen they're presented with thoroughly before hitting buttons, and the 10-second timeout on the menu has often nearly expired before they move the cursor.
[11:48] <cjwatson> wasabi: as for ill-documented keys you need to hold down at boot, forget it
[12:05] <wasabi> cjwatson: I agree, for dual booters.