[12:36] <pkern> Ubuntu has CONFIG_SLUB=y set which breaks fglrx suspend/resume on 2.6.22... With CONFIG_SLAB=y it "works for me"(tm). Just if anyone cares... ;o)
[01:15] <superm1> pkern, out of curiousity what do each of those do, CONFIG_SLUB/SLAB
[01:17] <pkern> superm1: They are different allocators. SLUB was added in 2.6.22 in addition to the older SLAB.
[01:18] <pkern> superm1: See lwn.net or kerneltrap for details.
[01:19] <superm1> ah, i see
[01:22] <tck> hi peeps
[01:22] <tck> you may know better than me
[01:22] <tck> but what is the netbug command ?
[01:22] <tck>  netbug
[01:22] <tck> Send network configuration summary to [ENTER means kuznet@ms2.inr.ac.ru] 
[01:23] <tck>  ldd /sbin/netbug
[01:23] <tck>         not a dynamic executable
[01:23] <tck> 
[01:23] <tck> strings /sbin/netbug shows it collecting lots of info from /proc
[01:25] <ion_> Seems like it does exactly what it says it does.
[01:25] <ion_> Please read the topic.
[01:26] <tck> part of the iproute package i see
[02:01] <webben_> Are there any Ubuntu Forums developers or admins about? I wanted to ask a question about the CAPTCHA?
[02:01] <webben_> We really need to provide a way for blind and deafblind users to access the forums.
[02:02] <RAOF> webben_: You probably want #ubuntuforums, right?
[02:02] <webben_> ah, yes I probably do ... thanks :)
[02:22] <calc> gar, amd64 failed again
[02:39] <calc> i have a fix now for the amd64 can't build with java disabled issue :\
[02:40] <calc> i need to reinstall amd64 arch on my desktop so i can test on it locally
[02:40] <ajmitch> aren't you glad you can upload only source?
[02:40] <calc> probably could build ooo in under an hour on it
[02:40] <calc> ajmitch: heh saves on my bandwidth yep :)
[02:40] <calc> it would take years to upload with this piddly 64KB/s broadband here
[02:40] <kylem> eh? i doubt your desktop is that much faster than the buildds.
[02:41] <calc> ajmitch: the fun part is the java failure on amd64 was known for a while and the person who created the patch never applied it, its sitting in the bts
[02:41] <calc> kylem: ccache and bypasses the gsi part of the build
[02:41] <calc> kylem: i can build in under an hour on i386
[02:41] <kylem> cheater. ;-)
[02:41] <calc> it takes 8hr+ on the buildds
[02:42] <kylem> you know you can testbuild on ronne right?
[02:42] <kylem> and do ccache...
[02:42] <kylem> file an rt to get added ot the porter group
[02:43] <calc> getting all the right dependencies installed and sending patches to ronne is a pain since it has no direct network access (or seems like it anyway)
[02:43] <calc> the install part is due to having to submit rt's etc
[02:43] <calc> i'm going to reinstall my desktop when i have some downtime probably after the tribe5 release
[02:44] <calc> can't do it after tribe5 release after all :\
[02:45] <kylem> you can dput over scp into the dc
[02:45] <kylem> anyway
[03:00] <calc> kylem: got access to kill the i386 ooo build?
[03:00] <kylem> nope
[03:00] <kylem> infinity, ^-
[03:00] <calc> infinity: awake still?
[03:01] <calc> it fixes the java disable failure case
[03:01] <infinity> calc: Ugh, again?
[03:02] <calc> infinity: yea this time was due to lazy upstream didn't commit a fix when java is disabled it doesn't actually fully disable and the patch has been sitting around for a while :(
[03:03] <calc> nearly 2 weeks in the bts gar
[03:04] <calc> this should allow it to build except for sparc which ICEs
[03:04] <calc> infinity: kill sparc build also please
[03:12] <infinity> calc: I'll kill them all in a sec.
[03:12] <infinity> calc: Several things on the go at once, won't be a moment.
[03:20] <calc> infinity: no problem
[03:26] <infinity> calc: Err, I have no builds to kill.  Looks like they all finished.
[03:27] <infinity> except for i386, which I missed due to blindness.
[03:27] <infinity> (killing now)
[03:32] <calc> infinity: oh ok
[03:35] <Hobbsee> morning all
[03:36] <LaserJock> hi Hobbsee
[03:36] <bhale> hi LaserJock Hobbsee
[03:37] <LaserJock> i bhale
[03:37] <LaserJock> *hi
[03:37] <ajmitch> hello Hobbsee, LaserJock, bhale
[03:37] <bhale> hi aj
[03:38] <LaserJock> hi mitch ;-)
[03:38] <bhale> haha
[03:41] <calc> Hobbsee: hi :)
[03:55] <calc> infinity: can you approve 1ubuntu3
[03:55] <Hobbsee> morning calc
[03:56] <calc> Hobbsee: good morning
[03:56] <calc> Hobbsee: hmm maybe you could do it? do you have access to approve packages during freeze?
[03:56] <Hobbsee> calc: heh, no, i'm a mere core dev.
[03:56] <calc> Hobbsee: oh ok
[03:56] <calc> Hobbsee: i thought you were a RM as well :)
[03:56] <ajmitch> 'mere'. heh
[03:56] <Hobbsee> calc: i may be on the release team, but i dont have access inside the DC
[03:57] <calc> Hobbsee: ok
[03:57] <Hobbsee> calc: a RM, sure, but not the head one, and i still dont have access to the DC :P
[03:57] <calc> Hobbsee: oh ok
[03:57] <infinity> calc: I'd ask for a diff, but I don't want to know, do I?  I just want to be told that this one will work.
[03:57] <infinity> calc: So, please, tell me that.
[03:58] <Hobbsee> (for his first)
[03:58] <infinity> Hobbsee: He's had some help here and there. :)
[03:58] <StevenK> infinity: "Please tell me you tested it?" too?
[03:58] <Hobbsee> infinity: oh i realise that :)
[03:59] <infinity> calc: Accepted.  If it doesn't build, I'll expect your head on a platter of some sort.  With cheese and crackers, and maybe a nice pate.
[04:00] <LaserJock> ewww
[04:00] <Hobbsee> calc: do i want to know if you test built it?
[04:00] <StevenK> infinity: libnss-db!
[04:01] <infinity> Hobbsee: No one test builds OOo, they just attempt to determine if their patch will fix the last failure through careful code auditing, prayer, and blind guessing.
[04:01] <infinity> Mostly the latter two, a little less of the former.
[04:01] <calc> infinity: its this
[04:01] <calc> http://www.openoffice.org/nonav/issues/showattachment.cgi/47475/ooo-reportdesign.diff
[04:01] <Hobbsee> infinity: so *that's* why it never builds.  man, i can see why we wouldnt want to give him core dev :P
[04:01] <calc> hub created a patch ~ 11 days ago and never committed it
[04:02] <calc> infinity: he just put it in bts, heh
[04:02] <ajmitch> Hobbsee: it'd be funny if you were maintaining OOo
[04:02] <infinity> calc: Dude, WTF?
[04:02] <calc> Hobbsee: it only fails on non-i386 builds so no :\
[04:02] <Hobbsee> ajmitch: i'm not insane.
[04:02] <infinity> calc: How did no one catch that and fix it earlier?
[04:03] <calc> infinity: because usually java is enabled for OOo since it disables lots of stuff
[04:03] <calc> infinity: but current OOo is broken on amd64/powerpc with java enabled
[04:03] <infinity> Yeah, like the help system, but who needs help?
[04:03] <calc> infinity: at least on Ubuntu :\
[04:03] <calc> infinity: heh, i'm going to rebuild my machine to amd64 asap and try to debug the larger java broken issue but it won't be before tribe5
[04:03] <calc> infinity: tribe4 had java disabled for all
[04:04] <calc> infinity: it works on i386 now, but not amd64/powerpc :\
[04:04] <StevenK> calc: Dig up. I don't think you're helping.
[04:04] <Hobbsee> yes, but tribe 4 had ooo not even working on kubuntu, so if you're saying that's some form of success....
[04:04] <calc> Hobbsee: that was a bug/feature in glib/gtk
[04:04] <Hobbsee> hah.  feature.
[04:04] <calc> Hobbsee: it broke lots of other apps besides just OOo
[04:04] <Hobbsee> i'm well aware
[04:04] <calc> Hobbsee: like konqueror, acroread and several other things i don't recall at the moment (i don't use them)
[04:05] <Amaranth> it was people using private gtk+ api when they shouldn't have
[04:05] <calc> Hobbsee: aiui glib/gtk is doing a proper fix as well
[04:05] <Hobbsee> yay!
[04:05] <Amaranth> i didn't have to use that API to do my fake tooltips
[04:05] <calc> Amaranth: that wasn't the issue afaict
[04:05] <Hobbsee> Amaranth: sure, but you've forgotten the golden rule.  "always blame calc"
[04:05] <calc> Amaranth: for OOo it was a call to gdk_screen that caused the hang
[04:05] <Amaranth> Hobbsee: Good deal.
[04:05] <Amaranth> calc: ...
[04:05] <Amaranth> wow
[04:06] <calc> gdk_screen_get_font_options
[04:07] <calc> now it is called like:
[04:07] <calc> +    GdkScreen *pScreen = gdk_screen_get_default();
[04:07] <calc> +    if (const cairo_font_options_t *pOptions = pScreen ? gdk_screen_get_font_options(pScreen) : 0)
[04:07] <calc> to get around the hang
[04:07] <Amaranth> so the problem is not having a valid GdkScreen?
[04:07] <Amaranth> that just looks like a NULL check
[04:08] <calc> Amaranth: apparently in this case yes, not sure if it is the same on the other apps
[04:08] <Amaranth> well, notification-daemon broke around the same time and it was the tooltips issue
[04:08] <calc> perhaps they did something that broke it at a lower level that affected both things
[04:08] <Amaranth> pygtk too, that was embarrassing
[04:09] <calc> i was reading a report about gtk init not being thread safe as well which might cause some problems
[04:09] <Amaranth> held up the GNOME 2.19.6 or so release for quite some time
[04:09] <Amaranth> none of it is thread-safe if you don't initiate threads and grab the lock properly
[04:09] <calc> i might have misunderstood what i was reading in the bug report then
[04:10] <Amaranth> i'm kind of jealous there, the java guys replaced the default lock with a reentrant one and just wrap every gtk+ call in their binding so in java you can just use gtk+ in threads with no worries
[04:16] <Hobbsee> LaserJock: do you mean you expected XP to actually *work*?
[04:17] <LaserJock> well, kinda yeah
[04:21] <Hobbsee> calc: you assume you'll be alive by that point
[04:22] <StevenK> Yes. Since infinity is scary.
[04:22] <calc> heh
[04:22] <calc> i won't die until he sees me at UDS I'm sure ;)
[04:22] <calc> maybe he'll forget by then
[04:22] <Hobbsee> unless he comes and hunts you out.
[04:22] <StevenK> Which he might.
[04:23] <calc> I live in TX, we are hicks here ;)
[04:23] <calc> I'll send Dick Cheney after him ;)
[04:23] <calc> he's my daddy, lol
[04:23] <StevenK> "Sir? Why are trying bring 2 AK-47s into the country?" 'Revenge.' "Ah, fair enough then."
[04:23] <calc> isn't TX where everyone and their dog has a weapon?
[04:24] <calc> of course all I have easy access to is a balisong not much competition to a AK-47
[04:38] <calc> it seems the libcompress-zlib-perl issue is still on lpia
[04:39] <infinity> calc: Working on it.
[04:51] <ScottK> AK's are really over-rated anyway unless you need something that will work after you crawl through the mud.
[05:00] <calc> ScottK: its been raining a lot here lately that might be useful ;)
[05:00] <ScottK> I can see that.
[05:01] <ScottK> Generally speaking though, unless you've trained and are good under stress, area effect weapons like shotguns are better.  You only have to be approximately right.
[05:01] <ScottK> Or approximately wrong in your Daddy's case.
[05:03] <Amaranth> ScottK: But the AK-47 gives you 'spray and pray'
[05:04] <ScottK> Yes and it's stunningly easy to miss everything.
[05:13] <calc> is there some way to make debuild log print the current time at the beginning of each line?
[05:13] <calc> so that timing of builds can be more granularly examined?
[05:19] <infinity> calc: A bit vile, but you could do:
[05:19] <infinity> debuild | while read line; do echo "$(date +%H%M%S): $line"; done
[05:19] <infinity> Oh, wait, debuild logs by default, doesn't it?
[05:20] <infinity> Anyhow, make it spit to stdout (or use dpkd-buildpackage), and the above trick would work fine.
[05:25] <calc> infinity: yea just not with the time
[06:18] <calc> btw, i am testing a fix for the openoffice.org-l10n issue along with updating it to the latest openoffice.org debian dir
[06:19] <calc> i'll hopefully have it uploaded in a few hours after i have verified the build
[06:32] <calc> er yea so leave openoffice.org-l10n alone until i reupload it :)
[06:32] <calc> i'm not going to upload it until i know that it works and that openoffice.org works as well since it uses the same rules file
[06:33] <calc> that should be in less than 7hr
[06:35] <ScottK> Give the rest of us a chance to use the buildd's for a while.
[06:35] <calc> ScottK: yea and that too :)
[06:35] <StevenK> Heh. calc isn't so good at sharing.
[06:35] <calc> ScottK: l10n will only build on i386 so your mostly safe on that
[06:35] <ScottK> Well that's one I've been waiting on.
[06:36] <calc> its been building locally for about 2hr now so it should be done in another 3-4 i think
[06:36] <calc> then i'll wait until amd64/powerpc pass on oo.o before uploading to make sure there isn't any other issues
[06:37] <calc> if there is i will beat myself :\
[06:38] <ScottK> Murphy doesn't hate you.  Murphy is just Murphy.
[06:38] <calc> heh
[06:38] <ScottK> You're the one that took the OOO maintainer job.
[06:38] <ScottK> Who hates you ?
[06:38] <calc> so oo.o should be done around 11am UTC
[06:38] <calc> ScottK: hehe, apparently I do as well ;)
[06:38] <ajmitch> ScottK: probably the liquor cabinet ;)
[06:39] <calc> hmm yea i have some alcohol should have been drinking that
[06:39] <calc> maybe it would help me keep from screwing up uploads
[06:40] <ScottK> At the very least it would help with the caring.
[06:41] <ajmitch> it could produce some interesting changelog entries
[06:41] <StevenK> calc: Don't buy a new one, you berk.
[06:41] <ajmitch> surely ebay has a few
[06:41] <calc> even ebay was high for recent boxen
[06:41] <calc> in the 2-3K range for low end stuff
[06:41] <calc> like ultra 25
[06:42] <calc> an ultra 10 is cheap but it would take years to build on that
[06:42] <calc> i used to run Debian with KDE on one back ~ 2000
[06:43] <calc> iirc its roughly equal in speed to a celeron 400
[06:44] <ScottK> I know what you mean.  I've build kdepim on a PIII 700 w/ 256 MB of RAM and that was bad enough.
[06:45] <calc> yuck, yea
[06:45] <calc> i think the slowest box i compiled KDE on back when i maintained it was an athlon 1800 w/512MB
[06:45] <calc> i just let the buildds build it for sparc
[06:46] <calc> and i learned about using ccache with KDE, heh
[06:46] <ScottK> I think I'm off to bed.  Good night everyone.
[06:46] <calc> goodnight
[06:46] <calc> going to wake to check on the build in a few
[06:50] <ajmitch> night calc
[07:16] <pitti> Good morning
[07:16] <kylem> good morning pitti.
[07:16] <pitti> hey kylem
[07:17] <StevenK> Morning pitti
[07:20] <ajmitch> hey pitti
[07:53] <calc> pitti: good morning
[07:54] <calc> i mistakenly drank a large coke tonight at dinner ~ 7hr ago after having not drank any coke for a week or two
[07:54] <calc> now i'm wired :\
[07:54] <pitti> hey calc
[07:55] <calc> pitti: oh btw i have a couple MIRs if you get bored ;)
[07:55] <pitti> calc: are they necessary for tribe5?
[07:55] <calc> they can wait until after tribe5 though due to the freeze
[07:55] <calc> nah not needed for t5
[07:56] <pitti> calc: so no new OOo for t5?
[07:56] <calc> pitti: ones building right now
[07:56] <pitti> calc: I'll still try to process them this week
[07:56] <calc> pitti: if it works i'll be uploading another ooo-l10n as well
[07:57] <calc> pitti: but if they can be processed in time for t6 i'll use them for the t6 ooo upload
[08:00] <StevenK> pitti: Should -9- be NBS'd out, or do we need to wait for -meta uploads and the like?
[08:00] <pitti> StevenK: kernel is pretty screwed ATM, nothing to NBS yet
[08:00] <pitti> StevenK: we are on it
[08:00] <calc> pitti: oh btw kubuntu shouldn't need the ooo -gtk/-gnome deps once the ooo build finishes
[08:00] <StevenK> Fair enough, I can visually grep -v it out of the list. :-)
[08:01] <StevenK> pitti: The only thing that can be NBS'd out is libopenbabel1.
[08:16] <dholbach> good morning
[08:17] <LaserJock> hi dholbach
[08:17] <dholbach> hey LaserJock
[08:18] <dholbach> how are you doing?
[08:18] <LaserJock> doing ok
[08:18] <LaserJock> really busy, but that's normal
[08:30] <kagou> hi pitti
[08:31] <pitti> hey kagou
[08:31] <kagou> pitti, could you have a look at https://wiki.ubuntu.com/GutsyGibbon/Tribe5
[08:32] <pitti> kagou: in a bit
[08:32] <kagou> pitti, i'v added a section for printing but as my english is poor, i will appreciate that you review it
[08:32] <Hobbsee> pitti: kagou i'll check the english, i fyou want
[08:33] <pitti> kagou: my English is far from perfect either, but I'll review it, and maybe add some things to it, too; thanks for the initial text!
[08:33] <kagou> Hobbsee and pitti , nice thanks :)
[08:33] <Hobbsee> pitti: OK, you go first, then i'll review *both* of yours
[08:33] <pitti> Hobbsee: I'll ping you
[08:33] <Hobbsee> :)
[08:42] <pitti> kagou: do you mind if I make it a little less technical and more user-oriented?
[08:54] <pitti> Hobbsee, kagou: page updated
[08:55] <pitti> (the printing section only)
[08:56] <kagou> pitti, no problem. I just want to let the world ;) know the great improvement of printing under Gutsy :) Thanks
[08:57] <pitti> kagou: indeed, that was on my list to mention for the tribe, too
[08:57] <pitti> gutsy rocks! :)
[08:57] <kagou> Yes :)
[08:57] <pitti> just some more fiddling with the AppArmor profile
[08:57] <LaserJock> ugg, my printing got all screwed up with Gutsy
[08:57] <LaserJock> hopefully it's worked out now, I hope
[08:57] <kylem> pitti, do we have anything liek this? http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/
[09:07] <dholbach> http://daniel.holba.ch/sponsoring/ now has colors
[09:07] <pitti> kylem: not in GUI form, but aa-genprof is really useful
[09:14] <mdke> dholbach: I guess gnome-user-docs will have to wait until after tribe now right?
[09:14] <dholbach> mdke: sorry - I looked a bit into it yesterday, tried to find an optimal way to get it built and all that but got busy with other stuff
[09:15] <dholbach> mdke: I'll look into it today again and see that we find a nice way to get that done, so it will be easier for you to ask me or others to upload that package
[09:15] <mdke> dholbach: cool; what needs to be done to get it built? Isn't the existing build system ok?
[09:16] <dholbach> no
[09:16] <dholbach> there are files that need to get automatically generated to make it buildable
[09:16] <dholbach> as I said: I'll think of something clever
[09:16] <mdke> dholbach: as a result of our changes?
[09:16] <dholbach> no
[09:16] <dholbach> what's in SVN is only the raw files that are being changed
[09:17] <dholbach> ./autogen.sh && make dist       will roll a buildable tarball from that
[09:17] <mdke> dholbach: oh
[09:17] <dholbach> i've not yet decided on how to represent your changes to that, how to roll the tarball, or to do a native package, etc
[09:18] <mdke> dholbach: so the tarballs as released are different to the svn snapshot?
[09:19] <mdke> if so, it sounds like we should be working from the tarballs and importing them to bzr rather than from the svn snapshot
[09:19] <dholbach> mdke: svn export <...>/trunk; cd trunk; ./autogen.sh && make dist        will be called  gnome-user-docs-2.18.2.tar.gz  too, but in fact it will rather be something like  gnome-user-docs_2.18.2+svn20070822.orig.tar.gz
[09:19] <dholbach> mdke: does that make sense?
[09:20] <pitti> seb128: hey hey
[09:20] <dholbach> that'd be more manual work for you
[09:20] <dholbach> hey seb128
[09:20] <seb128> hello pitti dholbach
[09:20] <dholbach> mdke: I think that finding a clever automatic way is what we want
[09:20] <pitti> seb128: is it deliberate that the deskbar applet now opens a separate window, instead of one attached to the icon?
[09:20] <seb128> pitti: yes
[09:20] <Hobbsee> pitti: pinching wikilock
[09:20] <mdke> dholbach: ok, if you think so, then I'll follow you! Are there other packages that do it the same way?
[09:21] <seb128> pitti: they redesigned the UI as a SoC
[09:21] <dholbach> mdke: can't think of any atm - I'll look into it later today
[09:22] <pitti> seb128: a pity :/
[09:22] <mdke> dholbach: alright, thanks. If importing the gnome releases rather than svn is the Right Thing to do then please tell me so, because I don't mind doing that
[09:22] <dholbach> I'll let you know
[09:22] <mdke> dholbach: don't want to create work for you
[09:22] <seb128> pitti: why?
[09:22] <pitti> seb128: dunno, I liked the small window better
[09:22] <seb128> k, you are not the only one looking at bugs
[09:22] <seb128> let's see what they do
[09:24] <cjwatson> dholbach: while you're on http://daniel.holba.ch/sponsoring/, the only way to tell which list something is on at the moment is to hover over the "list link" - perhaps the whole thing could be split up by list?
[09:24] <dholbach> cjwatson: right - good idea - I'll do that later
[09:24] <Hobbsee> kagou: did you want me to add you as part of the people getting credit for who wrote the page?
[09:25] <cjwatson> dholbach: thanks
[09:26] <Hobbsee> pitti: </wiki lock>
[09:30] <pitti> Hobbsee: thanks
[09:35] <kagou> Hobbsee, yes. Thanks
[09:35] <pitti> StevenK: it is already; you mean 'anywhere'?
[09:37] <StevenK> pitti: I'm only teasing. :-)
[09:40] <seb128> pitti: do you know why system-config-printer Conflicts with gnome-cups-manager?
[09:41] <pitti> seb128: yes, I did that a while ago
[09:41] <pitti> seb128: it's nasty and hackish, but somehow we need to avoid two identical printer entries in the menu, and faciliate upgrades
[09:41] <pitti> seb128: (and two printer icons in the tray)
[09:41] <norsetto> is it just me, or #ubuntu-motu is dead?
[09:41] <norsetto> is just me.....
[09:41] <StevenK> It's just quiet. Deal.
[09:41] <seb128> pitti: shouldn't the update-manager deal with that?
[09:42] <seb128> pitti: that looks wrong to me to force users to remove one to try the other one
[09:42] <pitti> seb128: u-m should also do it ideally, but doesn't ATM
[09:42] <pitti> seb128: right, it's a bit evil
[09:43] <pitti> seb128: but as I said you'll get duplicate notifications, icons, etc. when you have both installed
[09:43] <seb128> pitti: right, but Conflicts are not meant to avoid having duplicate icons
[09:43] <seb128> that's a packaging system abuse ;)
[09:44] <pitti> seb128: I'm fine with removing the C/R again as soon as u-m cares about it
[09:44] <seb128> k, will talk to mvo about it then, thanks
[09:44] <pitti> seb128: I'll file a bug and milestone it for beta
[09:48] <pitti> seb128: task and comment added to bug 107766
[09:48] <seb128> pitti: thanks
[09:50] <Hobbsee> pitti: sweden.
[09:52] <Lutin> infinity: ping ?
[09:56] <norsetto> any idea when gobby will be moved to main?
[09:57] <LaserJock> I think it already has
[09:57] <LaserJock> Edubuntu is shipping it so I certainly hope it's in Main ;-)
[09:59] <norsetto> OK, last I have seen here was still marking it as universe: https://launchpad.net/ubuntu/+source/gobby/
[10:00] <cjwatson> last I checked that was intentional
[10:00] <cjwatson> LaserJock is mistaken, Edubuntu can't ship stuff in universe
[10:00] <Mithrandir> it's approved for main, but it needs libxml++2.6 in main first
[10:01] <cjwatson> I'd just found that out
[10:01] <norsetto> ok, reason for asking is that I've got an outstanding merge for it in bug 133689, which is now subscribed to u-u-s for sponsorship
[10:01] <cjwatson> personally I think it's messy to support, but we may be stuck with doing so anyway ...
[10:01] <cjwatson> gobby is one of those things that's the best of its genre but still terrible
[10:02] <Mithrandir> cjwatson: more like "least worst" than best, really.
[10:02] <Mithrandir> or least bad, probably
[10:03] <cjwatson> "least bad" is correct grammar
[10:03] <Mithrandir> indeed, I saw that about two seconds after I pressed enter
[10:03] <Mithrandir> sadly, multiplayer notepad doesn't have undo.
[10:06] <norsetto> so, what should I do with that merge, let it die a natural end, subscribe u-m-s/unsubscribe u-u-s, ask for a freeze exception (it already got an UVFe), bury it under two tons of ground?
[10:06] <cjwatson> it's in universe, u-u-s is fine ...?
[10:07] <cjwatson> it's been on the list for promotion to main at some point for about a year and a half, it may not necessarily happen immediately ;)
[10:09] <Hobbsee> Mithrandir: extend it so it does.
[10:10] <norsetto> Hobbsee: morning oh mistress of the universe!
[10:11] <Hobbsee> greetings, norsetto.  do you want to do my physics assignment for me/
[10:11] <norsetto> Hobbsee: about what?
[10:13] <asac> talking about main: we need apturl in main as well ...  ubufox depends on it for the new plugin install service.
[10:13] <Hobbsee> norsetto: electrostatics.
[10:13] <asac> do i need to do something formally or will this happen semi-automatically?
[10:13] <Mithrandir> asac: sounds like something that should not be a depends, but rather a recommends?
[10:14] <norsetto> Hobbsee: sure ;-)
[10:14] <cjwatson> Mithrandir: should be in main anyway
[10:14] <asac> hmm that would require new code (testing if apturl exists and if not don't show apt results) ... because if apturl is not installed the plugin install will not work
[10:14] <Hobbsee> bah.  why cant my computer get power over the wireless or something, so as not to require a cord?
[10:14] <Mithrandir> cjwatson: true dat.
[10:14] <Mithrandir> Hobbsee: it could, but staying close to it would not be advisable in that case.
[10:14] <cjwatson> asac: I asked pitti about that yesterday ...
[10:14] <seb128> Hobbsee: because getting power by wireless would probably not be good for you ;)
[10:15] <Hobbsee> hmmm....
[10:15] <cjwatson> asac: normally speaking it needs somebody to prod https://wiki.ubuntu.com/UbuntuMainInclusionQueue, and then get an authorised person to approve and promote it
[10:15] <pitti> asac: there still needs to be a MIR for it
[10:15] <Hobbsee> i'll risk it.
[10:15] <Mithrandir> seb128: can we make  pkg-config --variable=pyexecdir pygtk-2.0 give out a python 2.5 path?
[10:15] <cjwatson> Hobbsee: there are designs for wireless power around ...
[10:15] <asac> pitti: do we need MIR for our own development?
[10:15] <Hobbsee> neat!
[10:15] <pitti> cjwatson: something else than microwaves or ridiculously strong magnetic fields?
[10:16] <cjwatson> they're still kind of in the "article in scientific journal" stage rather than the "product on shelf" stage
[10:16] <cjwatson> pitti: last article I read was safe around humans, at any rate
[10:16] <seb128> Mithrandir: that looks like a good idea
[10:16] <pitti> even if it's still academic it would be interesting to see a method that doesn't make your watch stick on the emitter, or fries your brain
[10:17] <cjwatson> http://news.bbc.co.uk/1/hi/technology/6129460.stm
[10:17] <cjwatson> EM wave resonance
[10:18] <asac> pitti: i always understood that MIRs are needed to evaluate if we can provide support for packages ... which should be true for our own development imo.
[10:18] <cjwatson> asac: that's true, and our own development clearly gets a pass over a lot of that stuff, but they're still a useful record of why stuff ended up in main
[10:19] <cjwatson> "so, this thing we developed two years ago - what was it for exactly?"
[10:19] <cjwatson> you'd be surprised sometimes ;)
[10:19] <pitti> cjwatson: interesting, thanks for the link
[10:19] <asac> cjwatson: ok
[10:22] <norsetto> asac: thx for your comment in bug 107093, seems it is really HD related
[10:23] <asac> norsetto: strange thing is that there are others in the bug report that claim the same behaviour ;)
[10:24] <asac> norsetto: please drop that info to the bug ... i will then try to carefully review what is *really* left of those claims :)
[10:24] <norsetto> asac: well, maybe its not just that make/model, perhaps its IDE controller related
[10:24] <fabbione> doko_: ping?
[10:28] <kagou> is it possible for a perl hacker to have a look at Bug #130813 apt-mirror is used to save bandwidth for many users/groups/install party
[10:31] <norsetto> asac: interesting, on the bug there is another user with the same problem and same IDE controller
[10:33] <doko_> fabbione: pong
[10:33] <fabbione> doko_: mind to help me a second with a gcc-4.2 new warning? i don't understand it
[10:33] <fabbione> doko: rg_thread.c:71: warning: the address of resthread_list will always evaluate as true
[10:34] <doko> fabbione: taking the address of a variable always results in something != 0x0
[10:34] <fabbione> doko: that's from redhat-cluster-suite built on lpia but i can see the same on i386 gcc-4.2
[10:36] <asac> norsetto: so the IDE controller has general issues ... or it just a coincident because its a widely used one? have you tried to connect the same disk to your other controller?
[10:36] <fabbione> doko: ok.. so how should that look?
[10:37] <norsetto> asac: can't, the disk I'm using now is sata (being in a RAID actually)
[10:37] <doko> fabbione: didn't look at the code, but just remove it?
[10:38] <fabbione> doko: hem.. probably best to look at the code.. you can't remove it.
[10:38] <cjwatson> doesn't seem to me that the warning can easily be removed
[10:39] <norsetto> asac: by the way, I haven't got a single freeze since I was using konqueror for the feisty cycle, nor any other application. smart reports all clear
[10:39] <cjwatson> doko: (it's in a macro that tests its pointer argument; it happens that in this use of the macro the pointer argument given is &something)
[10:39] <fabbione> i can ask upstream to change...
[10:40] <fabbione> or better... i can commit a fix upstream.. i just don't know how to fix this
[10:41] <doko> looking ...
[10:41] <cjwatson> I'd use -Wno-address personally ;-)
[10:42] <fabbione> cjwatson: eheh
[10:42] <doko> probably better, the warning looks ok
[10:42] <fabbione> doko: we can fix the code if it's easier
[10:43] <doko> fabbione: either that or suppress the warning, gcc is always right ;)
[10:44] <cjwatson> __attribute__(__noreally__) ;-)
[10:44] <fabbione> ROFL
[10:48] <asac> pitti: i added apturl MIR to https://wiki.ubuntu.com/UbuntuMainInclusionQueue
[10:48] <pitti> asac: thanks will look at it ASAP
[10:52] <asac> pitti: thanks ... its needed on CD
[11:02] <cjwatson> iwj: if you need any more information on bug 134000, let me know today if possible; I'm holding off installing new packages for a bit to try to preserve state in case you need it
[11:07] <paran> kylem: I see that you added irqbalance to UbuntuMainInclusionQueue in may, will that make it into gutsy? I can't find any mailing list threads discussing it
[11:13] <paran> kylem: it would be great to have irqbalance in main. it really improves performance, especially when running scientific applications over many cores. I measured about 5% improvment in walltime on dual quad-core machines even without any significant irq load.
[11:39] <pitti> Tonio_: ok, obexftp approved and promoted
[11:39] <Tonio_> pitti: super
[11:40] <iwj> cjwatson: Thanks.  I'll be right with you.
[11:40] <asac> Tonio_: why did we go to wpasupplicant 0.6.0 (a development version) instead of 0.5.8 (latest stable) ?
[11:40] <asac> Tonio_: how did you find that 0.6.0 is better in general ... or did it just work better for you?
[11:41] <Tonio_> asac: I never worked on wpasupplicant....
[11:42] <wolfe> asac: I don't know if you noticed, but it is common to use latest ;)
[11:42] <wolfe> look at GNOME in example
[11:42] <asac> wolfe: welll we align our schedule with gnome ... so when we release it will be stable
[11:42] <Tonio_> asac: where did you find a log with my name in it ? :)
[11:42] <wolfe> asac: yeah :)
[11:42] <wolfe> when you release, maybe 0.6.0 will be stbale ;)
[11:42] <asac> Tonio_: just out of my head ... probably confused you ... sorry.
[11:43] <Tonio_> asac: hhe
[11:43] <Tonio_> hehe
[11:43] <asac> wolfe: the maybe is the problem here
[11:43] <pkern> pitti: Did you try to promote Gobby to main?
[11:43] <pitti> pkern: yes, I did, but I demoted it again due to libxml++2.5
[11:43] <pitti> 2.6 even
[11:44] <asac> Tonio_: ah it was siretart ...
[11:44] <asac> siretart: how did you find that 0.6.0 is better in general ... or did it just work better for you?
[11:44] <pkern> Ah so that's the reason. *cough* Now we did a native Avahi port to circumvent the demotion because of Howl...
[11:44] <pkern> pitti: Thanks.
[11:44] <pitti> pkern: it just needs a MIR for libxml++
[11:45] <pitti> pkern: (or the dependency removed, if that's possible and sensible to do, of course)
[11:45] <pitti> pkern: yay for native avahi support :)
[11:45] <dholbach> can it use libxml++2.6? that should be in main
[11:45] <pitti> libxml++2.6 | 2.18.2-0ubuntu1 | gutsy/universe | source
[11:46] <dholbach> ugh
[11:46] <pitti> dholbach: that's what it uses
[11:46] <asac> siretart: the question was about wpasupplicant :)
[11:47] <dholbach> pitti: ok :-/
[11:47] <pitti> it doesn't sound scary, but someone needs to review it for sanity and QA, etc.
[11:48] <iwj> cjwatson: I don't need any more information from your system, thanks.
[11:49] <iwj> This is in some sense operating as designed but the behaviour of apt is suboptimal.
[11:49] <iwj> I'm going to think about it a bit.
[11:50] <cjwatson> iwj: ok
[11:50] <cjwatson> thanks for the investigation
[11:51] <iwj> No, thank you.
[11:51] <pitti> asac: apturl approved
[11:51] <pitti> asac: and promoted
[11:54] <pkern> pitti: The requirements for main inclusion don't look too hard. I guess I could review it then.
[11:55] <pitti> pkern: please just make sure to use the proper template instead of copying&pasting from an existing report
[12:06] <Riddell> pitti: if you're in a main inclusion review mood, could you look at MainInclusionKvKbd?  the build failure iwj had should be fixed now
[12:07] <pitti> Riddell: ok
[12:11] <pitti> Riddell: did you test kvkbd for general "it works"?
[12:12] <pitti> Riddell: oh, that thing is still in NEW
[12:21] <pitti> Riddell: shouldn't it get at least some testing before we put it into main? or did you build and test it yourself?
[12:21] <pitti> Riddell: binary-NEWed now
[12:21] <siretart> asac: since I recently changed my hardware (from madwifi to ipw3945) I don't think I can reasonably say which version worked better for me. For my old atheros card, I couldn't find any regressions
[12:21] <asac> siretart: can you check how 0.5.8 works with ipw3945?
[12:21] <asac> siretart: i mean ... it can only get better ;) ... especially how wpasupplicant and nm work together
[12:21] <siretart> asac: network-manager and wpasupplicant and ipw3945 work reasonably well for me, apart from bug #124706
[12:21] <siretart> (which I consider RC, but I agree that YMMV, and I don't have the ressources to debug/fix that one)
[12:21] <Riddell> pitti: we tested it at UDS and while packaging
[12:22] <Riddell> and it does just work for us, heno looked at it briefly too
[12:22] <dholbach> cjwatson: hope you like it better now: http://daniel.holba.ch/sponsoring
[12:22] <pitti> Riddell: ok, cool
[12:22] <asac> siretart: we have so many issues with ipw3945 that I would really like to try if wpasupplicant plays better with nm
[12:22] <siretart> asac: I have seen the bugs, and I think that I'm affected by some of them as well
[12:22] <pitti> Riddell: ok, promoted then
[12:23] <Riddell> great, thanks
[12:23] <asac> siretart: i doubt that it will help as its probably more driver related, but since nm really gets shaky if unexpected things happen maybe it helps to use a stable version
[12:23] <siretart> asac: I could even imagine that some of the existing bugs are actually duplicates of bug #124706
[12:23] <asac> siretart: unfortunately i don't have ipw3945 :/ to test.
[12:23] <siretart> :(
[12:24] <asac> siretart: might be ... its pretty blurry for me what contributes to the current situation ... but its definitly bad
[12:24] <siretart> right
[12:24] <siretart> we could perhaps provide a test package of 0.5.8 in a ppa
[12:25] <asac> siretart: i have a source package here ... can you give it a shot and if you don't see any regressions we can try a bit more wide-spread testing in ppa?
[12:25] <cjwatson> dholbach: MUCH better, thanks!
[12:25] <siretart> asac: do you have a list of current ipw3945 bugs? perhaps there is even a tag for them yet?
[12:25] <dholbach> super
[12:26] <asac> siretart: i added [ipw3945]  to the title
[12:26] <asac> siretart: https://bugs.launchpad.net/ubuntu/+source/network-manager/?field.searchtext=ipw3945&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[12:28] <asac> siretart: maybe we can even try to upgrade the kernel module to latest upstream release (1.2.2) ... or 1.2.0 (the one we have in feisty)
[12:29] <siretart> asac: I think that is more probable to fix some of the issues. I cannot really imagine that an earlier version of wpasupplicant would fix things here
[12:29] <siretart> I'm currently on a buisness trip, so I won't be able to look at them before tomorrow :(
[12:29] <asac> siretart: 0.6.0 is development version 0.5.8 is stable
[12:29] <siretart> I know
[12:30] <siretart> there is only one upstream developer working on it, and the changes from the two versions aren't too far away
[12:30] <siretart> and jouni is a very careful programmer. that's why I have doubt that we gain much by downgrading the package
[12:31] <asac> siretart: cu
[12:32] <siretart> s/dinner/lunch/
[12:55] <Mithrandir> seb128: also, is there a reason why pygtk doesn't ship gtk/gtk-extrafuncs.defs?  It's included by gtk-base.defs
[01:00] <seb128> Mithrandir: no, that would be a bug
[01:01] <Mithrandir> seb128: want a bug about that and the pygtkexecdir bug we discussed?  I'd really like those two things fixed so I can get python-hildon into the archive.
[01:02] <seb128> Mithrandir: feel free to open a bug or do an upload to fix those as you prefer
[01:02] <pitti> carlos: btw, pkgbinarymangler has always stripped restricted packages (re our discussion about restricted-manager a while ago); don't you get tarballs?
[01:02] <Mithrandir> seb128: ok, I'll do the latter, then.
[01:03] <carlos> pitti: not yet, I still need to finish some changes on launchpad to stop discarding them...
[01:03] <pitti> carlos: right, but AFAICS there's nothing to do on my side, right?
[01:04] <carlos> pitti: right
[01:06] <calc> 1ubuntu3 fixed the amd64/powerpc java issue :)
[01:15] <ogra> is there any drop in replacement for libssl-dev build deps ?
[01:22] <soren> ogra: Well, gnutls has a compatibility layer of some sort, but I doubt it's very good. If it were, everyone would be using it instead of openssl. :)
[01:22] <tkamppeter> kagou, ping
[01:22] <soren> Open wifi in Singapore airport ftw!
[01:24] <ogra> soren, well, i'd like to get libflashsupport in but it links against libssl-dev (openssl license) and libpulse-dev (GPL) ...
[01:24] <ogra> i'll try the gnutls compatibily layer to get it in at all ...
[01:24] <ogra> soren, thanks for the hint
[01:25] <soren> ogra: Tat's not only a common problem, mbut also seems to be one that doesn't have an easy solution.
[01:25] <soren> http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-with-the-OpenSSL-library
[01:26] <soren> ogra: Good luck. :) I'd love to hear how it works out for you.
[01:26] <ogra> well, looks easy enough ... i'm not even sure ssl is needed at all for that thing to do waht i want (make flash work with pulse)
[01:26] <asac> siretart: the diff -u is 1M ... i won't consider that small :)
[01:26] <asac> siretart: the changes look rather intrusive
[01:28] <asac> siretart: i don't say that 0.6.0 is buggy ... my only fear is that NM is tuned to work with 0.5.x
[01:31] <cr3> is there any reason why there is no dvd for milestone releases, such as tribe releases for gutsy?
[01:33] <ogra> cr3, do you volunteer to test them every three weeks ?
[01:34] <cr3> ogra: how would the milestone dvd be different from the current dvd: http://cdimage.ubuntu.com/dvd/current/
[01:35] <ogra> cr3, lots more to test, more packages and install variants ...
[01:35] <ogra> beyond that indeed a lot more bandwith consumption for rsyncs since there is a lot more on them
[01:35] <cr3> ogra: to answer your question bluntly, I honestly don't have the time :(
[01:35] <ogra> its a matter of manpower and time
[01:35] <ogra> snap :)
[01:36] <cr3> ogra: could you suggest a workaround in order to get an accurate snapshot in time of a milestone release? I could run debmirror on the day of the release, but I'm not sure how accurate that might be
 hello, rt2x00 freeze , when nm-applet connect
 Linux proton 2.6.22-9-generic #1 SMP Fri Aug 3 00:50:37 GMT 2007 i686 GNU/Linux
 who have some info about this , or patch ?
[01:38] <ogra> cr3, well, the recent build that was tested for a milestone is usually listed at https://iso.qa.stgraber.org/isotesting/
[01:38] <termitor> (sorry for my blabla)
[01:38] <ogra> if make sure to get a DVD of the same build that should work
[01:39] <termitor> maybe https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/129183 ?
[01:39] <ogra> but note that the dailies are usually wiped after thee days
[02:07] <iwj> Riddell: You'll let us know when there are some tribe 5 images to test, right ?
[02:07] <iwj> Or if we can help some other way ...
[02:08] <Riddell> iwj: yes indeed, but still got openoffice compiling, linux modules and d-i to do
[02:08] <kagou> tkamppeter, pong
[02:08] <iwj> Riddell: Right.  Just checking I hadn't missed anything.  It's unnaturally quiet ...
[02:08] <iwj> Sorry to bother you.
[02:09] <siretart> asac: hm. i see your point. well, I can of course try to use 0.5.8 of wpasupplicant, but as said, the worst problem I'm facing is bug #124706, which is very unlikely to be dependent on the wpasupplicant release
[02:11] <cjwatson> iwj: the kernel slipped rather late
[02:11] <cjwatson> little collection of problems there
[02:13] <asac> siretart: can you please attach a more verbose debug/daemon log do that bug?
[02:13] <asac> siretart: ok out for (extended/appointment) lunch ... cu later
[02:15] <Kmos> current dist not found in meta-release file
[02:15] <Kmos> could not send the dbus Inhibit signal: org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.PowerManager was not provided by any .service files
[02:15] <Kmos> current dist not found in meta-release file
[02:15] <Kmos> this is normal on update-manager ?
[02:15] <Kmos> i run it in console
[02:16] <siretart> asac: there are several more verbose logs in the links mentioned in the bug, but if it helps you to have mine, sure!
[02:17] <glatzor> Kmos: no
[02:17] <Kmos> glatzor: you know if there is any bug about that yet ?
[02:18] <glatzor> Kmos: you are running feisty?
[02:18] <glatzor> Do you have uninstalled gnome-power-manager?
[02:19] <Kmos> glatzor: gutsy
[02:19] <Kmos> no, gnome-power-manager is installed
[02:19] <Kmos> i've the latest updates :)
[02:20] <Kmos> now i ru update-manager and it doesn't show that error again.. strange
[02:20] <Kmos> *run
[02:21] <infinity> Lutin: Pong?
[02:25] <kagou> tkamppeter_,  pong
[02:31] <\sh> hmmm...xorg pros...is the ati radeon RV100 (Radeon 7000/VE) meant to work with compiz?
[02:48] <\sh> gnarf...xinerama mode doesn't work anymore with a digital port and an analog port using oss radeon driver
[02:50] <ogra> oss radeon ? do they include sound support now ?
[02:50] <ogra> *g*
[02:50] <\sh> ;)
[02:50] <\sh> s/oss/OpenSource/
[02:51] <ogra> indeed
[02:54] <\sh> on feisty it still worked with this card....gnarf
[02:54] <\sh> but looks like that this problem is reproducable..on my t43 laptop with radeon m300 card the analog port doesn't work in xinerama mode, too
[03:03] <tkamppeter> kagou, I have seen your comments on the bug report. Means that scanning for SMB-shared printers works now, but the GUI to select from the results is broken.
[03:04] <kagou> tkamppeter, indeed
[03:04] <tkamppeter> kagou, I have observed the same problem: Only the first server has the little triangle and there I can actually select a printer, the following servers have no triangle and I cannot select a printer.
[03:05] <kagou> are you sure about the format for the printers dict
[03:05] <kagou> tkamppeter, yyou are right
[03:05] <tkamppeter> kagou, I have used the same format as the old function used.
[03:06] <kagou> i can select only printer that host have triangle
[03:07] <kagou> tkamppeter, others hots without triangle, show printer after double click but can not select thrm
[03:10] <tkamppeter> kagou, then it has exactly the same behavior for you.
[03:12] <kagou> tkamppeter, indeed
[03:15] <kagou> tkamppeter, i'v also re-opened Bug 128261 but it's less important (just because printer work)
[03:23] <kagou> tkamppeter, but in the same time Bug #128261 show us that parameters are not (may be) well passed to the widget
[03:26] <dholbach> mdke: if you merge from   http://bazaar.launchpad.net/~dholbach/gnome-user-docs/fixes  building will be easier. just install bzr-builddeb and run    bzr bd -S --native   and it will build you a shiny source package that even builds -- also it tells you how to best version the thing
[03:27] <dholbach> (still pushing the changes up)
[03:39] <Lutin> infinity: could you have a look at the loadlin build please ? I got a 'failed to upload' mail for i386, but it seems to be ok for amd64
[03:45] <alex-weej> seb128: sorry about the confusion with "tasks" vs. "also affects"... maybe i should take this up with the launchpad devs
[03:46] <asac> siretart: well ... would be great to have all needed info in that bug ... e.g. maybe pick the important stuff from the referenced ones
[03:47] <asac> siretart: but i can do it as well
[03:47] <seb128> alex-weej: that's ok, the idea is to list the places where the bug needs to be fixed, not every applications where you can notice it
[03:48] <alex-weej> seb128: i assume "tasks" was terminology that was in older versions of LP?
[03:48] <seb128> alex-weej: like we don't use "also affects" to add every GNOME applications to GTK bugs ;)
[03:48] <alex-weej> also i really want to ensure that the fix goes into gecko, not just specifically into Firefox
[03:48] <seb128> alex-weej: right, a bug can have different tasks, still accurate
[03:49] <seb128> alex-weej: what do you call "gecko"?
[03:49] <alex-weej> you can fix it in Firefox with dodgy JS extensions that do weird and wonderful things, that would close a firefox task but leave my original bug against ephy out in the cold :<
[03:49] <seb128> alex-weej: also affects xulrunner would be correct (if it happens using it)
[03:49] <alex-weej> well, i guess specifically i mean libgtkmozembed
[03:49] <seb128> alex-weej: well, if that's shipped in the firefox sources that's still a bug on this package
[03:50] <alex-weej> probably is
[03:50] <alex-weej> but as another case, the problem with font changes not being picked up by gtkmozembed
[03:51] <alex-weej> it has to be marked against firefox - and that sucks, i don't really care about firefox. gtkmozembed can have specific code to listen for changes to gtk settings and that closes the bug easily
[03:51] <seb128> alex-weej: well, gtkmozembed is firefox code
[03:51] <alex-weej> it doesn't fix firefox, but all i am concerned with is epiphany
[03:53] <seb128> alex-weej: right, be the bugs are assigned to the source to fix
[03:53] <seb128> alex-weej: if GTK+ has a bug which breaks epiphany the bug is on GTK
[03:54] <alex-weej> yeah i know
[03:54] <Hobbsee> you know, it's a darn pain when people are running gutsy, new to linux, because it's the only distro that actually supports their wireless with wpa.
[03:54] <mjg59> s/with wpa//
[03:54] <asac> siretart: now reading the references in that bug ... anyway, imo to ask for reasons why we want to use the stable version is not really the right way to look at this ... its the development we have to question here ... so if we don't know any benefit of the new version (e.g. support this and that new hardware) ... i would really vote to not stay on 0.6.0 (unless the wpasupplicant upstream says that it will certainly become stable for gutsy) ... mak
[03:54] <alex-weej> i'm just saying that when i file a GNOME integration bug against epiphany, and it gets changed as a bug against firefox, that annoys me because it means that the solution is more complicated, as firefox is not a GNOME application
[03:55] <alex-weej> but if that's the way we do it...
[03:56] <\sh> bryce, ping radeon dualhead/xinerama setup on gutsy...
[03:58] <siretart> asac: right, thats why we have the 0.6.0 release since early of the beginning of the gutsy cycle. I haven't heared about regressions in that version yet
[03:59] <siretart> asac: and from what I understand from you, it is rather a suspicion  which may or may not be true. I'll therefore test on my laptop with the earlier version tomorrow when I'm back home
[04:01] <infinity> Lutin: I'll track that down for you in a bit, after I'm back from lunch.  Thanks for the heads-up.
[04:07] <asac> siretart: as i said above ... my main concern is that nm is tuned for 0.5.x (and not that 0.6.0 itself is buggy) and might get confused by just slightly changed behaviour of wpasupplicant because it relies on the events wpasupplicant emits.
[04:07] <Lutin> infinity: thank you
[04:07] <j1mc> hi all.  xubuntu ISO's contain uninstallable ubufox binaries.  (i'm aware of current kernel issues, too.)  is the ubufox problem present across other ubuntu variants, too?  thanks.
[04:08] <asac> siretart: unfortunately all apps (nm,wpa,driver) got updated at once so we cannot track down where the regressions stem from ... but as a matter of fact lots of users complain about regressions ... i am just trying to track down which setup might bring us to a more stable behaviour.
[04:08] <Hobbsee> j1mc: it's not on the uninstallable list now.  do you have a reason for it broken on there?
[04:10] <j1mc> Hobbsee: it came up as uninstallable in the daily Xubuntu health check email.
[04:10] <j1mc> i can forward you some of the discussion i had with the packagers if it would help.
[04:10] <j1mc> i think it was dependent on a package being included in main.
[04:11] <Hobbsee> j1mc: looking
[04:13] <Hobbsee> j1mc: apturl isnt installable for some reason
[04:13] <Hobbsee> because it's in universe
[04:14] <Hobbsee> ubuntu, edubuntu, gobuntu desktops will also get this
[04:15] <j1mc> ok.  is it a problem regarding building the ISO's then?  i'm not sure how it will affect things.
[04:15] <Hobbsee> j1mc: ubufox is depending on a package in universe, so cant install.
[04:16] <Hobbsee> j1mc: getting it fixed.
[04:16] <j1mc> ok.  thanks.  :)
[04:18] <Hobbsee> j1mc: it's fixed.  waiting for mirrors to update
[04:18] <j1mc> thanks so much, Hobbsee
[04:18] <Hobbsee> :)
[04:18] <Hobbsee> j1mc: thank pitti, he fixed it.
[04:21] <j1mc> thanks, pitti!
[04:23] <pitti> :)
[04:23] <ogra> pitti, Q-funk added a MIR for mkelfimage ...
[04:34] <xhaker> howdy, pygi :)
[04:35] <pygi> hello xhaker
[04:35] <xhaker> I might need your help
[04:36] <pygi> xhaker, sure, shoot me a pm
[04:42] <pitti> carlos: just if someone asks: I disabled the daily PPA uploads for stable langpacks
[04:42] <pitti> carlos: PPAs seem to be in limbo ATM, and we don't strictly need the daily updates in the next two weeks
[04:42] <pitti> carlos: I'll migrate to the new PPAs when I return from honeymoon and the production PPAs settled
[04:43] <carlos> ok
[04:43] <dholbach> mdke: pushed up now
[04:43] <carlos> pitti: have you updated an updated version yesterday or today?
[04:43] <pitti> carlos: it should have gotten one on Sunday
[04:44] <pitti> carlos: I only do it on Sundays and Thursdays now
[04:44] <pitti> carlos: to not entirely kill the PPA buildd
[04:44] <pitti> bryce: do you have an opinion about https://wiki.ubuntu.com/MainInclusionReportXserverXorgVideoAmd ?
[04:45] <carlos> pitti: ok
[04:45] <carlos> pitti: thanks for letting me to know
[04:46] <pitti> carlos: gutsy uploads continue
[04:50] <pitti> ogra: did you ever actually try out mkelfimage?
[04:50] <ogra> pitti, on one device (i have oinly one working LinuxBios client here) sbalneav did some tests too i was told
[04:51] <sbalneav> pitti: I've done some testing.  I'll do some more in the next couple of days with some etherboot hw I have.
[04:51] <sbalneav> so far seems ok.
[04:51] <sbalneav> and allows linuxbios stuff to work.
[04:52] <ogra> it produces a bootable image for the device i tested it on....
[04:52] <ogra> which was the main scope of having it :)
[04:52] <ogra> i dont think you'll find many of these yet anyway :)
[04:53] <pitti> ogra: I'm just looking at the MIR and wonder what to do with it, and if it's supportable
[04:54] <ogra> well, it will be only used in the rare case where you need to build an etherboot image for LinuxBios driven devices ... its really "corner software"
[04:54] <ogra> i actually only know two devices
[04:55] <pitti> ogra: what was the other thing called like? mknbi or so?
[04:55] <ogra> right
[04:55] <ogra> thats using INT19 calls or something which LinuxBios doesnt support
[04:55] <pitti> is mkelfimage a replacement, or a supplement?
[04:56] <ogra> supplement
[04:57] <ogra> well, its not a module for mknbi or so but it fills a gap mknbi doesnt
[04:57] <pitti> sbalneav, ogra: would it be useful for you to have it in main now?
[04:57] <ogra> before beta at least
[04:57] <sbalneav> pitti: Sure.
[04:58] <ogra> the image build script nedds some lines of adjustment that need to happen before release, so having it in early enough for that small change would be fine
[04:58] <ogra> not urgently needed for tribe 5 or so
[04:58] <pitti> ogra: nope, I mean "in gutsy"
[04:58] <ogra> indeed
[04:58] <sbalneav> yes
[04:59] <ogra> pitti, having it wins us a potential OEM customer for canonical ;) http://www.artecgroup.com/thincan/
[05:00] <pitti> yay
[05:00] <ogra> so indeed :)
[05:01] <sbalneav> So, it's in?
[05:02] <ogra> not yet
[05:03] <ogra> heh
[05:03] <pitti> (that should last until I'm done with the review :-P)
[05:03] <sbalneav> Not pushy, just excited :)
[05:03] <sbalneav> I'm like a little kid, bouncing up and down in the back seat.  "Arewethereyet?Arewethereyet?"
[05:03] <ogra> pitti, btw, how long do we have the pleasure of your attendance here ? werent you supposed to be travelling already ?
[05:04] <ogra> (congrats btw)
[05:04] <sbalneav> Mmm, ice gream.
[05:04] <sbalneav> err cream
[05:04] <pitti> ogra: thanks! we leave Saturday, early morning
[05:04] <ogra> (and congrats to mrs. pitt asd well ;) )
[05:04] <ogra> *as
[05:04] <pitti> so it's pretty much a normal work week (well, modulo grabbing photos, and doing some post-wedding errands)
[05:09] <pitti> ogra, sbalneav: looks fine; approved and promoted
[05:09] <sbalneav> \o/
[05:10] <pitti> np
[05:10] <pitti> ogra: can you please seed it, so that it stays in main?
[05:10] <ogra> yup
[05:12] <ogra> adding it to edubuntu-server for now, i dont want to do an extra ltsp uplaod to get the new dep into ltsp-client now ...
[05:12] <\sh> cool...dual head setup works again with a complete new configuration....and even compiz works with it..but only on the first quarter of the two screens ;)
[05:15] <tkamppeter> kagou, ping
[05:33] <cjwatson> infinity: re our discussion about bootable flags yesterday - http://www.win.tue.nl/~aeb/partitions/partition_types.html#toc2.9 and feel your brain melt
[05:33] <Hobbsee> mmm...brains...
[05:41] <dholbach> TheMuso: there's a new orca and gnome-speech - do you want to do the honours?
[05:43] <Hobbsee> dholbach: likely asleep
[05:43] <dholbach> Hobbsee: he'll probably check when he gets back
[05:44] <Hobbsee> true
[05:55] <coNP> Do you know if gimp 2.4 will be included in Gutsy? I don't know its release cycle, is it bound to Gnome 2.20 or independent?
[05:55] <desrt> coNP; independent
[06:06] <Lutin> pitti: around ?
[06:07] <pitti> Lutin: yes, for some more minutes
[06:07] <bryce> pitti, yep, I support adding it to main.  I'd encouraged martin-eric to write up the MIR, and will add it to xorg-xserver-video-all once it's in
[06:07] <Lutin> pitti: could you reject libhandoff ? I requested the sync but it's not going to be used by anything in gutsy
[06:09] <pitti> bryce: I approved and promoted it; adding it to -all would be appreciated, because ATM there's nothing that holds it in main
[06:09] <pitti> Lutin: done (although we'll get it again for the autosync wave in gutsy+1)
[06:10] <bryce> pitti, excellent, will do
[06:11] <doko> calc: OOo dependency fun. known? or should we just wait for the -l10n build to finish? but I'm unable to install the packages without language packages as well
[06:11] <Lutin> pitti: yep, but it was rather useless for gutsy. thanks :). btw, any chance that you have at kdenlive (in NEW source) ? I'm leaving on saturday and won't have chance to upload it before the new packages freeze if there are issues
[06:11] <wasabi> somebody kindly tell me what the "official" plans for compiz are.
[06:11] <wasabi> The compiz package in gutsy seems to depend on fusion stuff....
[06:13] <pitti> Lutin: on my archive day on Friday perhaps, I need to leave now
[06:13] <Lutin> pitti: ok. thanks :)
[06:13] <Riddell> Lutin: it's seb128's archive day today
[06:14] <seb128> Lutin: I'll have a look to it later
[06:14] <Lutin> Riddell, seb128 : thanks :)
[06:18] <calc> doko: known and fixed i believe
[06:19] <calc> doko: what was the exact problem you sa
[06:19] <calc> doko: saw
[06:19] <doko> calc: wants to remove all ooo packages
[06:27] <calc> doko: yea i think that will be resolved when l10n is uploaded
[06:28] <calc> doko: which should be in 6-7hr
[06:28] <doko> calc: hmm, strange that I'm unable to just keep the files with removing the -l10n package
[06:29] <calc> hmm that is strange
[06:29] <doko> tried i386
[06:30] <doko> calc: or try to install from the archive
[06:30] <calc> doko: its installing from the archive for me, at least it claims to be
[06:30] <A20> BenC: Here?
[06:30] <calc> i'll do a second update after it finishes this round to see if it is missing anything
[06:31] <BenC> A20: yes
[06:32] <A20> BenC: great, i tryed to speak to you in private, but looks like my messages are blocked
[06:32] <calc> A20: ident to services
[06:33] <A20> BenC: i want try to work on project that you mentors
[06:33] <BenC> A20: driver-device-manager?
[06:34] <A20> yeah
[06:34] <BenC> A20: have at it :)
[06:35] <A20> BenC: Cesare Tirabassi forwarded mail with my background info to you
[06:35] <BenC> A20: I saw that
[06:35] <BenC> A20: not sure what you need from me, basically the project just needs to be done
[06:36] <A20> BenC: I'm newble here and maybe you can point me where to start
[06:36] <BenC> A20: the spec pretty much explains everything
[06:36] <BenC> if you have any specific questions from there, email them, please
[06:37] <calc> doko: which set of packages were you upgrading between?
[06:37] <doko> calc: never mind, had still an -l10n-en-za package
[06:37] <calc> doko: oh ok
[06:37] <doko> removing that one lets the install continue
[06:39] <A20> BenC: ok, I'll try to learn everything by myself
[06:40] <doko> calc: why do you remove the changelog entries from your previous uploads?
[06:41] <calc> doko: they are nearly duplicates each time i can keep them if needed, but the changelog entry is just the difference between Debian and Ubuntu packaging
[06:42] <calc> it would make for a very large changelog of course, but if i should keep it around i can
[06:42] <doko> calc: please keep them, we do have the packages available in launchpad, and it's difficult to see what really changes between uploads (and it's not the real changes)
[06:43] <calc> ok
[06:43] <cjwatson> please make it clear in changelogs that you're documenting the differences
[06:43] <cjwatson> the usual syntax is:
[06:43] <asac_the_2nd> calc: i think its ok to list differences between debian and ubuntu on first upload ... then on subsequent ubuntu uploads just document what changed
[06:43] <cjwatson>   * Resynchronise with Debian. Remaining changes:
[06:44] <cjwatson>      - blah
[06:44] <calc> asac_the_2nd: for each 1ubuntu1 release?
[06:44] <cjwatson> we have a policy saying you should do that, somewhere
[06:44] <calc> cjwatson: ah i forgot the resync line
[06:44] <cjwatson> calc: each merge with Debian, yes
[06:44] <cjwatson> and yes, discarding old changelog entries is generally a bad idea
[06:45] <cjwatson> even if they're identical sets of differences being documented, that's useful information
[06:45] <calc> cjwatson: the old changelog entries conflict on merge as well :\
[06:45] <cjwatson> correct
[06:45] <cjwatson> but that's trivial
[06:45] <cjwatson> deal with it :)
[06:46] <doko> epoch'd OOo sucessfully installed
[06:46] <calc> doko: ok
[06:47] <doko> calc: you did remove *all* ubuntu changelog entries, afaics
[06:47] <calc> doko: rather i didn't merge them, since there were lots of conflicts, i'll go back and eye debian vs ubuntu changelogs and merge them by hand
[06:48] <asac_the_2nd> doko: fwiw, my changelog entries have disappeared from java as well ;)
[06:48] <calc> doko: for 2.3 i started from debian repo and merged up all the ubuntu changes back into it
[06:48] <doko> asac_the_1/2nd: well, overlapping uploads
[06:48] <asac_the_2nd> yes i know ;)
[06:49] <cjwatson> calc: typically there's one conflict at the top and then a load of offsets
[06:50] <cjwatson> I usually just let patch do it and then apply the .rej by hand (which is usually very short)
[06:50] <calc> cjwatson: there are a lot more conflicts in ooo changelog due to pulling between debian releases (i guess?)
[06:50] <doko> calc: it's less error prone to merge the debian changes (just the new ones) into the ubuntu package, than the other way around. should be even easier with bzr
[06:50] <cjwatson> pulling between Debian releases should only make a difference to the immediate next merge
[06:51] <cjwatson> after that it should be all offsets unless the Debian maintainer edits history
[06:51] <calc> cjwatson: it appears it wasn't remerged properly afterwards, heh
[06:51] <calc> cjwatson: at least for the changelog
[06:51] <calc> but yea it should only take an hour or so to remerge all of debian/ubuntu history together properly
[06:52] <cjwatson> seriously, though, this is all relatively straightforward and it's important when trying to figure out what happened in the past
[06:52] <calc> and then it won't be an issue after that
[06:52] <cjwatson> it should take much less time if you base your work on an Ubuntu changelog from before dropping the changelog items
[06:52] <calc> cjwatson: i think what doko said may indicate the changelog was never fully merged from debian in the past
[06:53] <calc> i can get it merged no problem, i'll go ahead and start on it now so it will be in the next uploaded version of ooo
[06:54] <doko> calc: wrong, what do you mean by "fully merged"? if you pull from the debian archive between debian uploads, you don't get the "complete" changelog.
[06:54] <calc> doko: there are ubuntu changelog entries from before i maintained ooo that look like they rewrite the debian changelog in areas
[06:54] <calc> doko: when doing a diff between 2.2.1-5 and 2.2.1-5ubuntuX
[06:55] <calc> doko: so it appears that the debian changelog wasn't fully merged up with ubuntu when the merges were done
[06:55] <doko> calc: yes, that's what I mean. why don't you just keep the changelog as it was?
[06:56] <calc> cjwatson: so should the changelog reflect a merge of ubuntu with the debian sources or whatever happened in ubuntu with rewriting parts of the debian changelog...?
[06:56] <calc> i can easily just merge it fully and get it over with
[06:57] <lucas> somebody knows how to make mutt start epiphany instead of iceweasel when I open a text/html mail part?
[06:59] <ion_> People think this is an Ubuntu support channel all the time, but a Debian support channel as well? :-)
[06:59] <lucas> oops, wrong window :-)
[07:00] <cjwatson> calc: each Ubuntu upload should have a changelog entry, and that changelog entry should be preserved (except if the package is completely synced with Debian); when you merge from Debian, the Debian entries should end up above the previous Ubuntu entry, and then another Ubuntu entry should be inserted at the top documenting the fact of the merge, remaining changes, and (separately) any further changes made in that upload
[07:01] <cjwatson> calc: with the exception of syncs (which I doubt will happen for OOo), it's never correct to discard old Ubuntu changelog entries, and usually never to remove them. Just leave them as they were, even if they seem to duplicate something else.
[07:01] <cjwatson> calc: they might well duplicate nearby entries in the Debian changelog in the event that changes were backported to Ubuntu
[07:04] <calc> cjwatson: ok no problem, will fix them now
[07:46] <mdke> I've just tried to install bzr-builddeb on feisty but it won't let me, seems to be because I'm using the bzr from the bazaar-vcs.org/ feisty repository; is there anything I can do?
[07:48] <mdke> error is unmet dependencies as follows: bzr-builddeb: Depends: bzr (< 0.16~) but 0.90~rc1-1 is to be installed
[07:48] <pygi> mdke, you can probably ignore dependencies
[07:49] <pygi> (when installing)
[07:49] <mdke> pygi: that wouldn't cause any problems?
[07:49] <pygi> mdke, who knows, but you said you want to do something =)
[07:50] <pygi> bzr-builddeb might or might not work with new bzr
[07:51] <mdke> pygi: can I get a better bzr-builddeb package that will?
[07:51] <mdke> maybe the gutsy one?
[07:51] <pygi> mdke, well, afaik bzr will release tonight or tomorrow, so soon we'll get those packages in repos  ?
[07:51] <pygi> mdke, nop, gutsy still doesn't have the new bzr. It'll have once bzr is released
[07:52] <mdke> ok
[07:53] <mdke> thanks pygi
[07:53] <pygi> mdke, yw, wish I could be more helpful :-/
[07:56] <pygi> mdke, hm, you could try this: it says it dependency is 0.18 and above. Feisty package doesn't allow above.
[07:56] <pygi> mdke, http://packages.ubuntu.com/gutsy/devel/bzr-builddeb
[08:18] <mdke> pygi: neat, thanks
[08:28] <j1mc> hi all - will we be ISO testing today?  i know about kernel problems from earlier today, but haven't heard much in the way of updates since then.
[08:38] <Riddell> j1mc: yes, should be available soon
[08:39] <j1mc> Riddell: thank you.
[08:55] <ScottK> calc: OOO Writer starts for me now on Kubuntu.  I never tried the ooo-gtk work around on this computer.
[08:57] <calc> ScottK: cool :)
[08:57] <ScottK> I thought you might be at least slightly interested.
[08:57] <calc> yea, we can disable the workaround in kubuntu meta now :)
[08:59] <Riddell> calc: it's gone
[09:02] <ion_> benc: Theres a bug in nvidia_supported that causes it to output nothing with the new version of nvidia_new. This should fix it. http://heh.fi/tmp/nvidia_supported.diff
[09:04] <BenC> ion_: sweet, thanks
[09:06] <ion_> benc: How about making nvidia_new the highest priority driver in l-r-m debian/rules now, btw?
[09:06] <ion_> That is, move it before nvidia and nvidia_legacy when calling nvidia_supported.
[09:19] <BenC> ion_: Might do that
[09:19] <Riddell> heno, stgraber, anyone who wants to test tribe: kubuntu CDs are up
[09:20] <heno> Riddell: cool, thanks!
[09:25] <evand> uh oh, the manifest shows busybox-initramfs 1:1.1.3-5ubuntu3
[09:26] <Riddell> evand: is that bad?
[09:28] <evand> Riddell: it needs to have 1.1.3-5ubuntu4 otherwise the read-only filesystem wont be able to mount and when the installer gets to the copying files stage it will crash as it will have copied nothing (as /rofs is empty) and the steps that follow expect certain files to exist.
[09:28] <Riddell> evand: so we need a new build of ubiquity?
[09:28] <heno> Kubuntu CD test entries are up: https://iso.qa.stgraber.org/isotesting/build/All
[09:28] <evand> http://changelogs.ubuntu.com/changelogs/pool/main/b/busybox/busybox_1.1.3-5ubuntu4/changelog
[09:29] <evand> negative, we just need busybox-initramfs 1.1.3-5ubuntu4 on there
[09:30] <evand> I'm not sure why it's not using the most recent version as it seems to be using the most recent version of everything else
[09:34] <evand> actually, we need the newest version of ubiquity on there as well (1.5.11) as 1.5.10 wont work on kubuntu
[09:35] <cjwatson> evand: that would indicate that livefs builds are failing
[09:35] <evand> indeed, I just saw that
[09:35] <Riddell> The following packages have unmet dependencies: openoffice.org-l10n-en-gb: Conflicts: openoffice.org-core (>= 2.3.0~src680m224.1) but
[09:36] <Riddell> and calc has run off
[09:36] <evand> I thought we were only missing busybox at first
[09:36] <cjwatson> isn't ooo-l10n still building?
[09:37] <cjwatson> yes, it is
[09:37] <cjwatson> we need that
[09:37] <Riddell> oh, we do indeed
[09:38] <Riddell> I must have assumed it would be faster than openoffice itself
[09:40] <cjwatson> openoffice.org-l10n blocks on openoffice.org
[09:40] <Riddell> right
[09:40] <Riddell> well, another couple of hours to go then
[09:41] <Riddell> although xubuntu shouldn't be affected
[09:42] <j1mc> Riddell: so xubuntu should be ok to test now?
[09:42] <Riddell> j1mc: once its built
[10:02] <Riddell> j1mc: xubuntu CDs up
[10:02] <Riddell> bdmurray: ^^
[10:02] <j1mc> Thanks!!
[10:07] <ipx> Whats the difference between coding for linux and windows? Im having a class with c++ and i only use linux, how should i solve it? use vmware?
[10:08] <ScottK> ipx: ask nixternal.  He's dealing with that same problem.
[10:09] <ipx> nixternal: u got any clue?
[10:09] <davmor2> Riddell: Kubuntu dying :( on current image on my compaq laptop
[10:11] <nixternal> ipx: I use Linux for my C++, Java, and whatever other courses
[10:11] <ipx> nixternal: and how do you solve it?
[10:11] <ipx> cuz if you code it for windows (that the teacher wants it in) you cant see how it works in linux?
[10:12] <nixternal> most of the code in the school are platform independent...there are a few things that won't work in Linux that work with Microsoft, but googling usually helped me out
[10:12] <nixternal> well if you guys are doing C++ GUI, you probably will need to code in Windows
[10:12] <nixternal> if you are just doing simple command line programs using the STL, then yo can get away with Linux quite easily
[10:13] <Riddell> davmor2: desktop or alternate?
[10:13] <ipx> nixternal: aww thanks that helped me alot
[10:14] <nixternal> ipx: are you doing gui c++ work?
[10:14] <ipx> we're only programming in procedure, so its only a terminal
[10:14] <ipx> no :)
[10:14] <nixternal> ipx: then Linux all the way!
[10:14] <davmor2> desktop is there a way to track down the problem with any easy?
[10:14] <ipx> Now I see how it works. thanks! :D
[10:14] <nixternal> 99% of the time, my code compiled just fine in Visual Studio
[10:14] <nixternal> you will learn strcopy and what not are a little different in Linux
[10:15] <ipx> What development tool do you suggest? KDevelop?
[10:15] <Riddell> ipx: questions for #kubuntu and #ubuntu, and it all depends on what you want to do
[10:15] <nixternal> I just used emacs...but truthfully, vi, emacs, or if you are using KDE, then Kate all the way for this course
[10:16] <ipx> thanks
[10:16] <nixternal> no prob
[10:16] <ipx> Checking out emacs right now :)
[10:16] <davmor2> Riddell: Oh and check cd still tried to boot it
[10:17] <Riddell> davmor2: ok, I'll be making new images in a few hours which should fix the install problem
[10:20] <bdmurray> Riddell: I don't seem to have the proper access to the isotesting site anymore
[10:20] <davmor2> Riddell: Comes up with Fatal server error:  Caught signal 11.  Server aborting         when typing startx if that helps.
[10:20] <bdmurray> stgraber: ping
[10:21] <stgraber> bdmurray: pong
[10:22] <bdmurray> stgraber: heno gave me admin rights to iso.qa.stgraber.org but I think I lost them.  I don't see a link to add the xubuntu images
[10:23] <stgraber> bdmurray: indeed, you don't seem to have any admin right, wait a sec
[10:23] <stgraber> bdmurray: should be good now, just refresh
[10:23] <pygi> mdke, managed to do anything?
[10:23] <bdmurray> stgraber: great, thanks
[10:26] <bdmurray> Riddell: the xubuntu gutsy-alternate-i386 looks oversized
[10:37] <Riddell> huh?
[10:38] <Riddell> so it is
[10:38] <Riddell> j1mc: able to do anything about that?
[10:38] <Riddell> or might the xubuntu-desktop in unaccepted help?
[10:39] <Goliath23> hi
[10:39] <j1mc> Riddell: mr_pouit or jani monoses should be able to help
[10:39] <j1mc> hopefully?  :)
[10:39] <Riddell> or we can just not release the alternate CD for this tribe
[10:39] <Riddell> mr_pouit: got a preference?
[10:40] <Riddell> j1mc: is jani on irc?
[10:40] <j1mc> Riddell: xubuntu alternate install is probably installed as much or more than the live cd.
[10:40] <j1mc> jani isn't on IRC, no.
[10:40] <Goliath23> I just realised, that my "man 2 mmap" manpage is dated back to 2.6.9 kernel times (2004-12-08) .. and i'm using an up-to-date feisty. any idea why the old manpages are in there? (mmap() obviously changed since then in a significant detail (it can return void(0) as a valid pointer) caused me hours of confusion today..
[10:41] <mjg59> That's the latest version of the manpage?
[10:41] <Goliath23> I guess thats in "manpages-dev". shouldn't they be up-to date?
[10:41] <mjg59> As far as I know, it's always been wrong in that respect
[10:42] <Goliath23> mjg59: so it's normal, that the old manpages are installed?
[10:42] <mjg59> It's not an old manpage. It's the latest version of the manpage.
[10:42] <mjg59> The manpages are not generated from the kernel.
[10:44] <Goliath23> mjg59: but there is certanly a more current manpage around (someone in another channel pointed me to it) shouldn't it be in that package then? this one is 3 years old
[10:45] <Riddell> j1mc: I'll let through the new meta package and we can try with that
[10:47] <j1mc> Riddell: thanks, I'm contactig Jani and Lionel (mr_pouit) to let them know about it.
[10:48] <Goliath23> mjg59: manpages in ubuntu are version 2.39-1, in gentoo they are version 2.63 the other guy says.
[10:48] <mjg59> Goliath23: They're 2.62 in gutsy
[10:49] <mjg59> 2.39 dates from late 2006
[10:49] <Goliath23> who releases that versions?
[10:49] <mjg59> ftp://ftp.win.tue.nl/pub/linux-local/manpages/
[10:49] <cjwatson> we inherit manpages directly from what's packaged by Debian
[10:49] <cjwatson> (like many of our packages)
[10:50] <mjg59> It's possible that the other guy is looking at the posix manpages. We don't distribute them for copyright reasons.
[10:50] <Goliath23> kk
[10:50] <kylem> do we readd the posix manpages?
[10:50] <kylem> right.
[10:50] <cjwatson> kylem: they're in manpages-posix
[10:50] <cjwatson> (multiverse)
[10:50] <kylem> oh. that plae.
[10:50] <kylem> place
[10:50] <kylem> ;-)
[10:50] <cjwatson> current mmap(2) is dated 2006-12-04
[10:51] <cjwatson> Goliath23: you've always been supposed to check the return of mmap() against MAP_FAILED, FWIW
[10:51] <cjwatson> not any other value ...
[10:52] <cjwatson> how did you get mmap() to return (void*)0?
[10:52] <mjg59> cjwatson: Map with MEM_FIXED and a start address of 0
[10:52] <Goliath23> the code is on my office pc, I can't give you the code right now.
[10:53] <mjg59> cjwatson: Which is kind of handy for vm86 stuff
[10:53] <Goliath23> my program also had a bug because it was checking against != NULL
[10:54] <Goliath23> (which is because the functions abstract system specific SHMEM creation and on windows you do it like that.)
[10:54] <wolfe> ARGGGGGGGG
[10:54] <Goliath23> the outdated manpage stating that mmap() will never return 0 didn't make it easier to find the error :)
[10:54] <wolfe> python-fam needs to be patched to work against libfam-dev whatever is in the version right now
[10:55] <Goliath23> but you're right of course, you have to check against MAP_FAILED..
[10:55] <cjwatson> mjg59: wow, I'm amazed that doesn't segfault
[10:55] <mjg59> cjwatson: Having pages allocated at address 0 is valid enough
[10:56] <cjwatson> I am alternatively surprised that more weirdos don't do that as a crackheaded attempt at avoiding segfaults ;-)
[10:56] <mjg59> cjwatson: On Vax, reading 0 gives you 0
[10:56] <Goliath23> at least I know how to fix it tomorrow morning..
[10:56] <cjwatson> I know
[10:56] <mjg59> Lots of code was very broken in the 80s
[10:57] <elmo> things haven't changed
[10:57] <kylem> tbqh, whilst having things mapped at 0 is valid, it makes life pretty difficult
[11:02] <mr_pouit> Riddell: how much is the xubuntu-iso oversized?
[11:12] <mr_pouit> Riddell: if the new xubuntu-meta upload doesn't help, here is also a possible fix: evince-gtk is currently broken and push libgnome{2,ui} with it. A possible fix is attached to Bug #121871... maybe it'll be enough?
[11:12] <ubotu> Launchpad bug 121871 in evince "[gutsy]  evince-gtk depends on libgnome" [High,Confirmed]  https://launchpad.net/bugs/121871
[11:14] <benkong2> I know this is not for support but... Who handles the screen resolution package in ubuntu? I want to better understand why my resolution choices never change.
[11:17] <mdke> pygi: no, I found that it needs dependencies and gave up :)
[11:18] <bdmurray> benkong2: Do you mean what person or what package?
[11:25] <bdmurray> bryce: I'm booting the Kubuntu daily build and got an Xorg general protection
[11:25] <bryce> doh
[11:26] <bryce> "general protection"??
[11:26] <bryce> would you mind also turning on failsafe (sudo /etc/gdm/failsafeInstall) and see what happens?  I've not yet tested it with Kubuntu with a real failure situation
[11:27] <bdmurray> bryce: error message in dmesg and the last line in /var/log/Xorg.0.log is "Backtrace:"
[11:27] <calc> Riddell: yea ooo-l10n should be done in the next hour or two
[11:28] <bryce> hrm, just "Backtrace:"?  not too informative
[11:28] <bryce> did you also test the Tribe-4 Kubuntu cd on that same hardware?  Is it a new error?
[11:29] <bryce> also, does the Ubuntu daily have the same issue or does it boot ok?
[11:31] <bdmurray> bryce: Yes. Just Ubuntu Tribe4. Yes. Will download.
[11:33] <evand> wow, the new xubuntu artwork looks amazing
[11:37] <pygi> evand, any shots?
[11:37] <bdmurray> bryce: what do you mean by the failsafe install?
[11:38] <bryce> bdmurray: if you run that script it flips on Bulletproof-X
[11:38] <bdmurray> bryce: so boot normally and then run that?
[11:39] <bryce> if you've been able to install ubuntu, but X isn't working, run that and reboot or restart gdm.
[11:40] <bryce> s/ubuntu/kubuntu/
[11:40] <benkong2> bdmurray; sorry I mean the person and the package if possible
[11:40] <bryce> if it's failing on the live cd or during installation though, this won't help
[11:40] <bdmurray> bryce: right it is failing on the Live CD
[11:41] <bryce> ok nevermind then
[11:41] <bdmurray> benkong2: the package would Xorg
[11:41] <bdmurray> or groups of packages rather
[11:41] <bdmurray> bryce: What should I include in the bug report then?
[11:42] <bryce> the usual... xorg.conf, Xorg.0.log, lspci -nnvv
[11:42] <evand> pygi: http://evalicious.com/xubuntu.png - not sure how new the artwork is, it's been since early in the cycle that I used xubuntu
[11:43] <pygi> evand, thanks
[11:43] <benkong2> bdmurray; my problem is that in Ubuntu the Screen Resolution selection program offers no other choices no matter how I change xorg.conf
[11:49] <bdmurray> benkong2: hrm, there is a lot of information we would need to help you out
[11:50] <calc> anyone know why tracker is installed?
[11:50] <calc> it seems to be causing my system to go into 100% iowait
[11:50] <Riddell> it's default now in ubuntu
[11:50] <calc> Riddell: how often does it eat all cpu?
[11:51] <wolfe> what is tracker?
[11:51] <calc>  Tracker is an advanced framework for first class objects with associated
[11:51] <calc>  metadata and tags. It provides a one stop solution for all metadata, tags,
[11:51] <calc>  shared object databases, search tools and indexing.
[11:51] <Riddell> like strigi or beagle
[11:51] <calc> i'm guessing its whats eating all my cpu anyway
[11:51] <pygi> and is not so fun xD
[11:51] <Riddell> calc: dunno, I've never used it
[11:51] <wolfe> is it default with server too?
[11:51] <wolfe> and can it be turned off easily?
[11:51] <bdmurray> calc: you have 2 cpus don't you?
[11:52] <calc> bdmurray: yea still makes the system barely responsive
[11:52] <bdmurray> heh
[11:52] <wolfe> no offense, but I think there needs to be no tracker enabled by default
[11:52] <calc> looks like it finally finished
[11:52] <wolfe> pygi: how?
[11:52] <calc> cool 100% idle now i can do stuff again, heh
[11:52] <wolfe> well, I can see the majority of power users disabling it
[11:52] <evand> xubuntu installed fine \o/
[11:53] <pygi> wolfe, preferences, indexing preferences
[11:53] <wolfe> pygi: aha, ok.
[11:53] <ajmitch> calc: just purge it :)
[11:53] <calc> ajmitch: i wanted to make sure it is expected behavior so it doesn't kill our users when they install 7.10 in a couple months ;)
[11:54] <pygi> ajmitch, not smart, then he purges ubuntu-standard or ubuntu-desktop or whatever
[11:54] <ajmitch> pygi: rubbish, it's a recommends, not depends
[11:54] <davmor2> Riddell:  The Intel X driver is still screwing up the display in xubuntu desktop, which means it almost certainly will with ubuntu and kubuntu too.
[11:54] <calc> pygi: i could just equivs replace it or something
[11:54] <calc> ajmitch: doesn't recommends get auto-installed now, or will be soon if we merge up with debian?
[11:54] <calc> ajmitch: debian now installs recommends automatically
[11:55] <pygi> calc, they do get autoinstalled
[11:55] <pygi> from some time ago
[11:55] <ajmitch> calc: yes, which is why you got trakcer installed & can remove it safely
[11:55] <calc> ajmitch: ah ok :)
[11:55] <ajmitch> hopefully apt will remember that I didn't want tracker on the next ubuntu-desktop update :)
[11:57] <pygi> ajmitch, calc : sudo aptitude remove tracker
[11:57] <pygi> result:
[11:57] <pygi> Remove the following packages:
[11:57] <pygi> libdeskbar-tracker
[11:57] <pygi> tracker-search-tool
[11:57] <pygi> tracker-utils
[11:57] <pygi> ubuntu-desktop
[11:58] <calc> oh is that what puts up the little orange deskbar applet?
[11:58] <pygi> ajmitch, ^_^
[11:59] <Nafallo> calc: no, that's deskbar-applet :-)
[11:59] <ajmitch> pygi: yes, that's because aptitude wants to preserve recommends
[11:59] <ajmitch> pygi: it doesn't mean that you can't just remove it
[11:59] <pygi> heh
[12:02] <LaserJock> pffft, who uses aptitude ;-)
[12:03] <ajmitch> dselect ftw?
[12:03] <LaserJock> dpkg+wget?
[12:03] <Nafallo> LaserJock: I do on servers :-)
[12:04] <Nafallo> ipkg on some routers ;-)
[12:04] <ajmitch> LaserJock: you don't just edit the status & various other files by hand?
[12:04] <calc> Nafallo: so is there some sort of applet to use the tracker data?
[12:04] <LaserJock> who needs dependency resolution? It works fine for .rpms
[12:04] <Nafallo> calc: deskbar-applet has a plugin I've removed I think :-)
[12:05] <calc> Nafallo: heh
[12:05] <ajmitch> nice, icedtea is available for amd64
[12:05] <ajmitch> thanks doko :)
[12:05] <calc> oh i see it under accessories
[12:06] <Nafallo> icedtea?
[12:06] <doko> ajmitch: test it
[12:06] <Nafallo> calc: it's own tool, nautilus and deskbar-applet can use it I think.
[12:06] <doko> calc: you may want to give OOo a try with icedtea
[12:06] <ajmitch> doko: I will, I was just looking to see what was available
[12:08] <calc> doko: ok
[12:08] <calc> doko: is that packaged yet?
[12:09] <doko> calc: see ubuntu-devel-discuss
[12:09] <calc> doko: ah i see the message :)
[12:10] <calc> doko: is icedtea being packaged for debian as well?
[12:11] <bhale> ajmitch: whats that
[12:11] <doko> calc: you don't have to care about it ;-)
[12:12] <calc> doko: well for merge reasons it would be good ;)
[12:17] <Kopfgeldjaeger>  g n8
[12:23] <bdmurray> bryce: bug 134153 has been submitted
[12:23] <ubotu> Launchpad bug 134153 in xorg "[gutsy]  xorg failed to start on an Intel 945 using Kubuntu desktop CD daily build 20070822.1" [Undecided,New]  https://launchpad.net/bugs/134153
[12:23] <bryce> bdmurray: thx
[12:23] <bdmurray> let me know if you need anything else - I also ran xresprobe if that is useful
[12:24] <kylem> bdmurray, ack
[12:24] <kylem> bdmurray, fix forthcoming for it
[12:24] <kylem> bdmurray, discover-data bug.
[12:27] <ajmitch> bhale: icedtea is a temporary fork of sun's openjdk
[12:27] <bryce> kylem, can you give me any pointers on how to know when a given bug is discover-data?
[12:28] <kylem> well, it chose vesa instead of i810 or intel.
[12:28] <kylem> probably also a vesa bug since it didn't start, but feh.
[12:29] <bryce> gotcha
[12:29] <kylem> i really hoped we had time to replace that for gutsy but it's too late now.
[12:29] <bryce> follow up question - what's involved in fixing these kinds of bugs?  Is it usually just updating pci id tables, or more involved?
[12:29] <kylem> i think X driver pick-age is the only place discover is used these days.
[12:29] <mjg59> Well, vesa has got significantly worse recently
[12:30] <bryce> yeah
[12:30] <kylem> bryce, yes, discover-data has a big pci id database.
[12:30] <kylem> mjg59, vbios itym :P
[12:30] <kylem> vesa hasn't really change dmuch