[12:13] <tkamppeter> pitti, will do so and reupload under the same file names.
[12:14] <pitti> tkamppeter: thanks
[12:16] <pygi> pitti, sending now
[12:18] <pygi> pitti, you got it, thanks once again
[12:18] <pygi> ergh, upstream!
[12:18] <tkamppeter> pitti, foo2zjs source files on my server are replaced now.
[12:18] <pygi> if this won't work, I'll just bug upstream
[12:19] <pygi> this scsi stuff has big endian problems
[12:21] <pitti> tkamppeter: hmm, file date is still 15:18
[12:21] <pitti> s/date/time/
[12:21] <enrico> Riddell: tomorrow == tuesday
[12:22] <Riddell> enrico: great
[12:23] <tkamppeter> pitti, can you click on "Reload"?
[12:23] <tkamppeter> pitti, and note that the server is on the west coast of the US.
[12:23] <pitti> tkamppeter: ah, heh
[12:25] <pitti> tkamppeter: fine, uploading
[12:25] <pitti> BenC: \o/ test-apport kernel passes
[12:25] <BenC> pitti: sweet
[12:25] <BenC> pitti: lum, ldm, lrm and linux-meta being prepared
[12:26] <pitti> ldm?
[12:26] <pitti> lbm?
[12:26] <tkamppeter> Thanks pitti, so the Tribe 2 users will get some more ugly winprinters supported.
[12:26] <pitti> tkamppeter: heh
[12:26] <pygi> pitti, got it?
[12:27] <pitti> pygi: ah, got it now
[12:27] <tkamppeter> Rick Richardson is not very distro friendly, but he is very effective in decoding winprinter protocols.
[12:27] <pygi> pitti, k, great
[12:28] <pitti> pygi: your changelogs should be a bit more concrete, btw
[12:28] <pitti> pygi: 'create patch', 'improve patch' is not very useful for readers
[12:28] <pygi> pitti, got it, sorry about that
[12:28] <pygi> will improve in the future
[12:28] <pygi> :)
[12:28] <pitti> pygi: also, the debdiff you sent is for some feisty package
[12:29] <pygi> ergh!
[12:29] <pitti> pygi: ah, you need to s/feisty/gutsy/
[12:29] <pygi> yes
[12:29] <pitti> pygi: don't worry, I do it now
[12:29] <pygi> meh :-/
[12:29] <pitti> easier than another email round trpi
[12:29] <pygi> pitti, very sorry
[12:29] <pygi> guess I need some sleep, k3b ate me a lot today
[12:30] <pitti> pygi: uploaded
[12:30] <pygi> pitti, thanks, hope it'll work
[12:31] <pygi> if not I'll request point release from upstream or something
[12:33] <pitti> tkamppeter: uploaded
[12:33] <pitti> ah, I told that already
[12:34] <tkamppeter> pitti, thanks.
[12:38] <pygi> bdmurray, you know ... you should accept me in -qa really :p
[12:43] <Rumba> mvo: i found a bug: i uninstalled some packages in synaptic but they are still shown as "Auto-Installed: 1" in /var/lib/extended_states! (not sure if "Auto-Installed: 0" packages are still shown, but i don't see why not, so i won't test that.)
[12:55] <pitti> Riddell: still around by chance?
[12:57] <Riddell> hi pitti 
[12:58] <Riddell> I don't smell that much!
[12:58] <pygi> Riddell, hehe
[01:00] <pitti> Riddell: can you please test the English and French KDE langpacks on "deb http://people.ubuntu.com/~pitti/langpacks/daily/gutsy/ ./"?
[01:00] <Riddell> ok
[01:01] <pygi> pitti, working with upstream now in case this fials
[01:01] <pitti> Riddell: thanks; German and English Gnome ones look good here
[01:05] <Riddell> pitti: french and english language packs good here
[01:05] <Riddell> (in KDE)
[01:06] <pitti> Riddell: great, thanks; I'll upload the lot then
[01:21] <pygi> s/fials/fails*
[01:21] <pygi> ergh
[03:03] <calc> have a question if i add more uid's to my gpg key and send them to the mit keyserver do they propagate to launchpad eventually?
[03:04] <crimsun> that is the hope, though I always upload to keyserver.ubuntu.com directly.
[03:04] <pygi> crimsun, they do propagate
[03:05] <pygi> ergh, 3:05AM
[03:05] <calc> crimsun: does it take a while for the web interface to update?
[03:05] <crimsun> yes, although I've experienced problems with the propagation in the previous release cycles
[03:05] <pygi> calc, some time, yes
[03:05] <pygi> crimsun, true
[03:05] <crimsun> it should not take two and a half weeks to propagate
[03:05] <pygi> haha, true
[03:06] <pygi> usually it's few hours
[03:06] <calc> ah its there now, i sent it directly to k.u.c
[04:43] <wasabi> hmm. i remember some talk (4 years ago) about buffered dpkg postinst scripts.
[04:43] <wasabi> what ever happened to that?
[04:43] <wasabi> (executing update-initramfs once)
[04:44] <LaserJock> I thought iwj did some work on that
[04:44] <LaserJock> but I could be wrong
[04:46] <Hobbsee> hiya
[04:46] <wasabi> hiya
[04:48] <RAOF> That was dpkg triggers, right?
[04:49] <wasabi> i forget.
[04:49] <wasabi> It was a long time ago. I just know update-initramfs just ran 4 times in a row on my system. ;)
[04:49] <LaserJock> try TeX or emacs packages ;-)
[04:49] <RAOF> Heh.
[04:50] <wasabi> http://lists.debian.org/debian-dpkg/2007/01/msg00047.html
[04:50] <wasabi> Oh that's recent.
[04:50] <wasabi> By Debian's time schedule anyways.
[04:55] <RAOF> Yeah, that's what I was thinking of.
[04:56] <TheMuso> Update-initramfs/doc caching/etc running only once would be great, especially on older machines.
[05:14] <bryce> has tribe2 frozen?  I have some new xorg bits to upload if there's still time
[05:15] <StevenK> bryce: I don't think it has yet.
[05:16] <Hobbsee> bryce: it hasnt frozen yet
[05:16] <crimsun> bryce: the topic is normally updated when it is; I'm guessing you have ~3 hrs
[05:16] <Hobbsee> bryce: pitti hasnt woken up yet, and i cant freeze it
[05:16] <Hobbsee> no distro team meeting to link it to, this time around
[05:17] <bryce> crimsun: thanks
[05:19] <bryce> ok 3 hrs is a bit tight, I'll wait 'til later to get them in
[05:20] <bryce> hmm, maybe I can at least get the new mesa in, that's fairly important
[05:21] <StevenK> bryce: If you want/need a hand, I'm happy to help.
[05:21] <bryce> thanks, I would! 
[05:21] <StevenK> Okay, point me at stuff, and I'll try. :-)
[05:22] <Hobbsee> bryce: try - if it's not accepted, it can sit in the unapproved.
[05:22] <bryce> ok here are the mesa packages:  http://people.ubuntu.com/~bryce/Uploads/
[05:23] <bryce> unfortunately I wasn't able to get some people to test it out, which I was hoping for since it's a major version number jump.  However, the packaging was quite straightforward and the changes are fairly modest (mostly bugfixes)
[05:24] <StevenK> bryce: Build, test and install?
[05:24] <Hobbsee> bryce: what's the difference?
[05:24] <StevenK> Er, I can't test it, actually.
[05:26] <bryce> hmm
[05:26] <Hobbsee> bryce: looking
[05:28] <Hobbsee> erk....
[05:28] <ajmitch> hm?
[05:28] <Hobbsee> bryce: http://rafb.net/p/9Kf55S64.html
[05:28] <ajmitch> suddenly lost any 3d functionality? :)
[05:28] <Hobbsee> no, no
[05:29] <bryce> o_O
[05:29] <ajmitch> ah, no libgl1-mesa-swx11-i686 package exists?
[05:30] <Hobbsee> only for -1ubuntu1
[05:31] <bryce> here are the debs that are created by this mesa package:
[05:31] <bryce> libgl1-mesa-dev_7.0.0-0ubuntu1_all.deb         libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> libgl1-mesa-dri_7.0.0-0ubuntu1_i386.deb        libglu1-mesa_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> libgl1-mesa-dri-dbg_7.0.0-0ubuntu1_i386.deb    libglu1-mesa-dev_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> libgl1-mesa-glx_7.0.0-0ubuntu1_i386.deb        libosmesa6_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> libgl1-mesa-glx-dbg_7.0.0-0ubuntu1_i386.deb    libosmesa6-dev_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> libgl1-mesa-swx11_7.0.0-0ubuntu1_i386.deb      mesa-common-dev_7.0.0-0ubuntu1_all.deb
[05:31] <bryce> libgl1-mesa-swx11-dbg_7.0.0-0ubuntu1_i386.deb  mesa-swx11-source_7.0.0-0ubuntu1_all.deb
[05:31] <bryce> libgl1-mesa-swx11-dev_7.0.0-0ubuntu1_i386.deb  mesa-utils_7.0.0-0ubuntu1_i386.deb
[05:31] <bryce> I'm iffy on the order of installation though
[05:32] <Hobbsee> bryce: mesa-utils seems to be what's depending on libgl1-mesa-swx11-i686
[05:32] <StevenK> Those libgl packages aren't on people.u.c, though
[05:36] <calc> sorry for the really stupid question but where are the cd images of ubuntu for 6.06 6.10, they aren't on cdimage.ubuntu.com afaict
[05:36] <calc> cdimage only holds dvd images, imagine that ;)
[05:36] <StevenK> cacaupt: releases.u.c
[05:37] <StevenK> Er, calc: ^
[05:37] <calc> ah thanks :)
[05:39] <dmb> using the advanced installer, is there a way to make a graphical installer just like it is on the livecd?
[05:45] <calc> Hobbsee: i don't think reminding people about that helps things, heh
[05:46] <Hobbsee> calc: hmm?  oh.  right.  *shrugs*
[05:46] <fabbione> morning
[05:46] <ajmitch> calc: what, that the MC is obliged to approve you?
[05:46] <ajmitch> morning fabbione 
[05:46] <calc> ajmitch: yea
[05:47] <calc> ajmitch: even if it is true its not in good taste
[05:47] <calc> Hobbsee: btw your myspace page is sick
[05:47] <Hobbsee> calc: *grin*
[05:47] <Hobbsee> calc: but it's a lovely background!
[05:47] <calc> Hobbsee: it could cause seizures ;)
[05:47] <Hobbsee> calc: the rationale for it is on the page
[05:48] <ajmitch> causing seizures?
[05:48] <calc> i forgot the url
[05:48] <StevenK> It has, I daresay.
[05:48] <ajmitch> "I wanted to see how many people were epileptic"
[05:48] <Hobbsee> www.myspace.com/creamier_oak
[05:48] <calc> ah yea
[05:48] <Hobbsee> calc: it's just there to prove that myspace is evil.
[05:48] <Hobbsee> haha
[05:50] <wasabi> that background is terrible.
[05:50] <Hobbsee> calc: some of my friends from another online community demanded that i get one.  so i did, secretly, and hyped it up enough that they all went crazy seraching for it.  and then found it, and went "arrrrrghhhh!!!!"
[05:50] <Hobbsee> it's a *lovely* background!
[05:50] <calc> i love it, one ups the html blink tag ;)
[05:50] <Hobbsee> ness is right.
[05:50] <bryce> Hobbsee: I posted a README listing the order of .debs I installed, and some test results
[05:50] <Hobbsee> The longer you look at it, the less it bothers you... seriously!
[05:50] <calc> my gf's reaction was ugh, heh
[05:50] <bryce> I'm not super familiar with mesa so am not 100% sure I have everything configured right, but it seems to work 
[05:51] <Hobbsee> haha
[05:51] <Hobbsee> i like the reactiosn of "OMG, MY EYES!!!  MY EYES!!!" and similar
[05:51] <calc> yea that is what she said too :)
[05:51] <Hobbsee> i should really have put a counter on there - just to see how many people's eyes have been burned by it
[05:51] <Hobbsee> calc: pft.  you must be in au
[05:52] <calc> Hobbsee: need lots of bandwidth for this ooo stuff :)
[05:52] <ajmitch> Hobbsee: if he were in .au he'd be at 64Kbps by now
[05:52] <StevenK> If he was lucky,
[05:52] <calc> i had 128Kbps in 1998, lol
[05:52] <Hobbsee> hehe
[05:54] <calc> hmm i have to be up in 9hr for the CC meeting, ugh
[05:56] <Hobbsee> awww
[05:57] <Hobbsee> calc: that's still ages away
[05:58] <ccm> *moan*
[05:58] <ccm> hug day, today?
[05:59] <calc> Hobbsee: but i've been up for like 16hr already :P
[05:59] <Hobbsee> hehe
[05:59] <calc> Hobbsee: i think i am going to finish up the security stuff tomorrow
[05:59] <calc> these downloads won't be done for another 1.5hr in any case
[06:00] <StevenK> Do you have an edgy build environment?
[06:00] <calc> StevenK: yea, but its just a chroot not a full runtime environment to test in
[06:00] <StevenK> Hence the ISO downloading. *nods*
[06:00] <calc> yea
[06:01] <Hobbsee> bryce: er...where did you put that readme?
[06:01] <calc> i wrote some scripts to do chroot builds for any release of debian/ubuntu with ccache setup, etc
[06:01] <bryce> oops, sorry, it's here:  http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0/README
[06:02] <Hobbsee> bryce: even at http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0/ there arent all the libgl bits
[06:03] <desrt> for some reason i have an open /query window with [LongPointyStick] 
[06:04] <bryce> ah, true, hang on let me upload all of them
[06:09] <Hobbsee> bryce: therea re more?
[06:09] <Hobbsee> dpkg: dependency problems prevent configuration of libgl1-mesa-dev:
[06:09] <Hobbsee>  libgl1-mesa-dev depends on libgl1-mesa-glx (>= 7.0.0-0ubuntu1); however:
[06:09] <Hobbsee>   Version of libgl1-mesa-glx on system is 6.5.3-1ubuntu1.
[06:09] <Hobbsee>  libgl1-mesa-dev depends on libgl1-mesa-dri (>= 7.0.0-0ubuntu1); however:
[06:09] <Hobbsee>   Version of libgl1-mesa-dri on system is 6.5.3-1ubuntu1.
[06:12] <bryce> Hobbsee: yeah sorry there's about 16 debs total.  I'm uploading.  The DRI ones will take a bit of time to get uploaded but I'll do them last.
[06:13] <Hobbsee> bryce: ah right, so it's unfinished.  no problem, i understand really well about slow uploads
[06:15] <wasabi> Hmm. A bit frightening to see ntfsresize in top while upgrading ubuntu.
[06:16] <Amaranth> Hobbsee: isn't your upspeed slower than dialup?
[06:16] <Hobbsee> Amaranth: not exactly sure.
[06:16] <Amaranth> someone was telling me that
[06:16] <Amaranth> maybe it wasn't you
[06:16] <Hobbsee> i think it uploads at up to 64K, or 128K
[06:17] <Hobbsee> i think ours is 128K
[06:17] <ajmitch> ouch
[06:17] <Amaranth> i only get 512
[06:17] <Hobbsee> it's a bit nasty, yes.
[06:17] <hansin321> I have a triple-boot system, and would like to upgrade my Feisty install to Gusty Tribe/Testing to help find bugs etc.  Can I do this via a dist-upgrade command or do I need to do a fresh install from CD?  Thanks.
[06:17] <hansin321> Gutsy*
[06:17] <Hobbsee> that's why i'll usually try to transfer to a US host, or not build on thsi machine
[06:18] <Hobbsee> hansin321: #ubuntu+1 - you can do either.
[06:18] <Hobbsee> hansin321: there's cds to test in hte next day or so, though
[06:19] <hansin321> Hobbsee: Ok, thanks.  I'll move to that channel for this.
[06:20] <wasabi> heh. initramfs being generated for the 11th time now
[06:21] <Hobbsee> hansin321: so, if you want to wait for a day or so, and test out a cd for us, that would be supercool
[06:21] <StevenK> wasabi: I am so looking forward to that being fixed.
[06:24] <hansin321> Hobbsee: Ok, so it would be better for you guys to have me do a fresh install.  Do you think I would be relatively safe in regards to my other partions?  My plan was to remove those from my current fstab then update.  But I suppose I can choose in the installer to not mount these.
[06:25] <hansin321> I would be more than happy to help out with testing an install.
[06:25] <wasabi> Why would one do a fresh install of Ubuntu?
[06:25] <Hobbsee> hansin321: well, it's a test cd - so backups are good.  ie, the tests are done to check that the cd doesnt kill your dog.
[06:25] <wasabi> I think massive file system corruption is hte only reason I can think of . ;)
[06:25] <Hobbsee> or your hard drive, or whatever...
[06:25] <Hobbsee> wasabi: i found stacks of cruft from my edgy --> feisty + beryl --> gutsy install.
[06:26] <wasabi> ... so fix them.
[06:26] <wasabi> They're all just files or packages.
[06:26] <wasabi> There is no registry. :)
[06:26] <wasabi> I've been running the same install ... since woody.
[06:26] <wasabi> And I'm on gutsy. ;)
[06:26] <wasabi> And yes, I mean Woody. The Debian release.
[06:27] <Fujitsu> Impressive.
[06:27] <hansin321> When there is a major architectual change between versions (not just package upgrades, but a major change).  How does the upgrade process know how to apply these?
[06:27] <Hobbsee> wasabi: and i wanted to download a cd, so then i could rsync it
[06:27] <wasabi> hansin321: Every thing on the system is in a package.
[06:27] <wasabi> Everything.
[06:27] <wasabi> There is nothing outside of them.
[06:27] <wasabi> Except for your own documents, anyways.
[06:28] <desrt> wasabi; -almost- true
[06:28] <wasabi> What have I missed? :_)
[06:28] <desrt> wasabi; the installer is responsible for some stuff
[06:28] <wasabi> heh. dpkg comes in a package last I checked. =)
[06:28] <desrt> desrt@moonpix:~$ dpkg -S /etc/fstab
[06:28] <desrt> dpkg: /etc/fstab not found.
[06:28] <desrt> for example...
[06:28] <wasabi> oh that's true.
[06:28] <Fujitsu> Not much stuff, but a fair bit.
[06:28] <Fujitsu> Like that.
[06:28] <wasabi> fstab, initial passwd entry.
[06:28] <Fujitsu> Enough to be painful to do manually, as I found.
[06:28] <hansin321> wasabi: So if there is a new package to a system (or one that is not longer needed), say Upstart vs. old init system, is there some sort of metapackage that indicates what MUST be istalled (since for example there was now Upstart in the previous version)?
[06:29] <wasabi> I've reformatted my file system 3 times... switched hard disks and complete machines too.
[06:29] <wasabi> I usually jsut tar up my / and untar it on the new system.
[06:29] <Hobbsee> hansin321: yes
[06:29] <bryce> Hobbsee: ok .debs are up.  
[06:29] <wasabi> hansin321: Unless there's a bug, yes, that's how it works.
[06:29] <Hobbsee> bryce: woot :)
[06:29] <wasabi> hansin321: upstart declares that it conflicts and replaces with the old init system. And it is programmed to handle that transition.
[06:30] <bryce> there's one dri-dbg deb left to upload, but you won't need that, and it'll take 30 min to upload
[06:30] <hansin321> Thanks.  I had wondered about that in the past.
[06:30] <wasabi> Any failure to take a upgrade path into account is a bug.
[06:30] <wasabi> So, you should file a bug on it. :)
[06:30] <wasabi> And desrt is right. There are a slight few files. fstab... ... resolv.conf technically.
[06:31] <wasabi> hmm what do I usually do when debootstrapping.
[06:31] <wasabi> I think that's actually about it.
[06:31] <Fujitsu> hostname as well.
[06:31] <wasabi> oh yeah, /etc/hostname
[06:31] <Fujitsu> /etc/network/interfaces, if you're counting resolv.conf.
[06:31] <wasabi> oh yes yes 
[06:32] <wasabi> Anyways, every few years I run a little script that scans for files on my system taht AREN"T in a package, and I identify and delete them. ;)
[06:32] <Hobbsee> wasabi: that'd help.  
[06:32] <Fujitsu> And the special stuff in /var on the root partition which took me ages to work out. I wondered why lo wasn't coming up on boot :(
[06:32] <wasabi> dpkg -S is your friend.
[06:32] <wasabi> There's not much in /var except some directories themselves which need to be created.
[06:33] <wasabi> Like var itself.
[06:33] <wasabi> actually I guess lock and run are done by scripts now too, since they're tmpfs
[06:33] <StevenK> wasabi: Ignore things like /home?
[06:33] <wasabi> StevenK: yeah.
[06:34] <Fujitsu> wasabi: /var/{lock,run} need to be on the root filesystem, not a mounted /var, or things explode on bootup.
[06:34] <wasabi> Oh really?
[06:34] <StevenK> But /var/{lock,run} are tmpfs'es
[06:34] <Fujitsu> Otherwise network interfaces can't come up, and various other things.
[06:34] <Fujitsu> StevenK: But the mountpoints need to exist.
[06:34] <wasabi> I basically just grab every file on the system, filter out the obvious paths, /home, my few custom directories, some bits of var, then run them all through dpkg -S. Sort the output and figure out what I should nuke.
[06:34] <wasabi> debfoster is nice too.
[06:34] <StevenK> Fujitsu: That just involves directories existing in /var.
[06:35] <Fujitsu> StevenK: I guess my statement was ambiguous. I meant the directories.
[06:36] <wasabi> Anyways, unix is nice like that. There's no magic. Everything is a file. If you break something, you can just fix it.
[06:36] <wasabi> s/unix/linux/
[06:36] <wasabi> And in doing so, learn how it works.
[06:38] <Hobbsee> bryce: er...i think you've broken this
[06:38] <Hobbsee> sarah@LongPointyStick:~/Desktop$ sudo dpkg -i libgl1-mesa-swx11*.deb
[06:38] <Hobbsee> dpkg: regarding libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb containing libgl1-mesa-swx11-i686, pre-dependency problem:
[06:38] <Hobbsee>  libgl1-mesa-swx11-i686 pre-depends on libgl1-mesa-swx11
[06:38] <Hobbsee>   libgl1-mesa-swx11 is not installed.
[06:39] <Hobbsee> dpkg: error processing libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb (--install):
[06:39] <Hobbsee>  pre-dependency problem - not installing libgl1-mesa-swx11-i686
[06:39] <Hobbsee> Errors were encountered while processing:
[06:39] <Hobbsee>  libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb
[06:39] <kylem> probably me who broke it.
[06:39] <StevenK> Hobbsee: Does libgl1-mesa-swx11_*deb exist?
[06:40] <Hobbsee> oh, wait.  dammit.
[06:40] <Hobbsee> thought i got them all.  missed one
[06:40] <bryce> hrm
[06:40] <Hobbsee> dpkg: regarding libgl1-mesa-swx11_7.0.0-0ubuntu1_i386.deb containing libgl1-mesa-swx11:
[06:40] <Hobbsee>  libgl1-mesa-swx11 conflicts with libgl1
[06:41] <kylem> oh. wait. i did mesa 6.5.3, not mesa 7.0.0
[06:41] <kylem> nevermind me.
[06:41] <Hobbsee> oh wait, that one is right
[06:42] <bryce> I had to do apt-get -f install a few times to force everything in there (and there was one package I could never get installed)
[06:42] <Hobbsee>  libgl1-mesa-swx11 conflicts with libgl1
[06:42] <Hobbsee>   libgl1-mesa-glx provides libgl1 and is unpacked but not configured.
[06:42] <ajmitch> sounds like a painful upgrade path
[06:42] <bryce> I assume there's a correct installation order I just fumbled though
[06:42] <ajmitch> can apt-get/aptitude sort out a sane upgrade if you create a repository for it?
[06:42] <StevenK> bryce: I'm having second thoughts. :-)
[06:43] <Hobbsee> bryce: it appears you have 2 packages providing libgl1
[06:44] <Hobbsee> bryce: which means they conflict each other, and it all dies.
[06:44] <StevenK> Maybe only one of them should be installed?
[06:44] <bryce> yeah I assume you would install only one set or the other
[06:45] <Hobbsee> bryce: then you should have conflicts of one set against the other, surely?
[06:45] <bryce> hrm, ok well back to the drawing board.  thanks for giving it a shot
[06:46] <Hobbsee> bryce: which one do i want, btw?
[06:46] <Hobbsee> intel 945
[06:46] <Hobbsee> bryce: what you *should* do is upload it to a repo somewhere, so that apt can deal with the breakage, adn test it that way - then the predepends stuff is covered.
[06:48] <StevenK> Or run dpkg-scanpackages on that directory.
[06:48] <StevenK> bryce: If you want to do that, I can type out a comand line for it.
[06:48] <bryce> ok
[06:49] <StevenK> dpkg-scanpackages . /dev/null | tee Packages | gzip -9c > Packages.gz
[06:50] <StevenK> Then the deb line is "deb http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0 ./"
[06:50] <bryce>  ** Packages in archive but missing from override file: **
[06:50] <bryce>   libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-dri-dbg libgl1-mesa-glx
[06:50] <bryce>   libgl1-mesa-glx-dbg libgl1-mesa-swx11 libgl1-mesa-swx11-dbg libgl1-
[06:50] <bryce>   mesa-swx11-dev libgl1-mesa-swx11-i686 libglu1-mesa libglu1-mesa-dev
[06:50] <bryce>   libosmesa6 libosmesa6-dev mesa-common-dev mesa-swx11-source mesa-
[06:50] <bryce>   utils
[06:50] <bryce> is that normal?
[06:50] <StevenK> Yes.
[06:51] <Hobbsee> bryce: could you tell me which lot i want, please?
[06:51] <StevenK> Because /dev/null in that argument list is what dpkg-scanpackages wants for the override file. :-)
[06:52] <Hobbsee> bryce: swx11 or glx?
[06:52] <bryce> Hobbsee: I don't know.  I installed swc11 on my -nv box
[06:52] <Hobbsee> you're supposed to know, arent you?
[06:52] <Hobbsee> bryce: you're supposed to know everything X, dammit!  :P
[06:53] <bryce> yeah... :-(
[06:53] <bryce> StevenK, ok Packages.gz uploaded
[06:53] <StevenK> bryce: Way cool.
[06:53] <ajmitch> you can't have a pony!
[06:53] <StevenK> Hobbsee: Add that deb line to apt sources and wave apt-get install, say swx11 over it?
[06:54] <Hobbsee> oh wait.  i didnt have swx11 installed before.  
[06:54] <mjg59> swx11 is the software rasteriser, IIRC
[06:54] <StevenK> In that case, choose glx
[06:54] <mjg59> You probably don't want it
[06:54] <Hobbsee> bryce:  mesa-utils depends on libgl1-mesa-swx11-i686; however: - surely that needs a swx11 | glx?
[06:55] <Hobbsee> mjg59: thanks.
[06:55] <Hobbsee> @pony kylem 
[06:57] <Hobbsee> hrm.  it appears i dont want to throw out libglu1-mesa
[06:57] <StevenK> bryce: I'll try and see if apt will upgrade in a chroot.
[06:57] <Hobbsee> nor mesa-utils
[06:59] <Hobbsee> bryce: afaics, the libglu1-mesa and mesa-utils depending on swx11 only, and not either that or glx, and the lack of conflict between libgl1-mesa-swx11 and libgl1-mesa-glx seem the only problems.  the rest looks fine.
[07:00] <Hobbsee> of course, whether it'll work with the other dependancy, i have no idea :)
[07:00] <bryce> ok
[07:07] <Hobbsee> morning dholbach!
[07:07] <dholbach> good morning
[07:07] <dholbach> hiya Hobbsee
[07:08] <bryce> nite all, thanks for the help, sorry it didn't work out.
[07:08] <Hobbsee> bryce: oh drat.  if you're going to bed, then my system will probably stay in limbo :P
[07:09] <dholbach> night bryce - whatever it was - good luck getting it fixed tomorrow!
[07:10] <Hobbsee> dholbach: X fun
[07:10] <bryce> Hobbsee: oh, thought you said it finally worked?  I must be getting tired
[07:11] <Hobbsee> bryce: no, i still cant install mesa-utils nor libglu1-mesa
[07:11] <Hobbsee> bryce: due to the swx11 dependancy, not a swx11 
[07:11] <Hobbsee> bryce: due to the swx11 dependancy, not a glx | swx11 dependancy
[07:12] <Hobbsee> nor can i remove them, as various other stuff depends on them - like, kdesktop
[07:12] <bryce> have you tried doing apt-get -f install ?
[07:12] <Hobbsee> bryce: of course.
[07:13] <Hobbsee> bryce: it wont work unless i remove all the -glx stuff, and add all the swx11 stuff, which mjg59 suggested that i didtn really want to do
[07:13] <persia> Hobbsee: Try force installing the previous versions.
[07:13] <bryce> hrm, this is sounding beyond my dpkg-fu
[07:14] <Hobbsee> bryce: i can probably fix it from here, actually - but have no place to upload it, etc.
[07:14] <Hobbsee> as in, fix the dpkg foo, then you can build it.
[07:14] <Hobbsee> or tell you how to
[07:14] <Hobbsee> persia: i'm trying to avoid doing that - but i will, if i have to shut down this machine before bryce fixes the problem
[07:17] <TheMuso> dholbach: Heya. Thanks for the gnome-mag upload.
[07:19] <Hobbsee> StevenK: do i need only a conflicts, or a conflicts/replaces?
[07:19] <StevenK> Hobbsee: More information, sorry?
[07:20] <Hobbsee> StevenK: on the -swx11 / -glx
[07:20] <Hobbsee> StevenK: as in, they're not coinstallable - but the user should be able to choose between whichever they want
[07:20] <dholbach> TheMuso: anytime :)
[07:20] <crimsun> they should be Conflicts.
[07:20] <crimsun> neither C & R the other
[07:21] <ccm> just wondering if i drop a mail for the guys of http://linuxmint.com/ suggesting them to use launchpad and freenode
[07:21] <crimsun> ccm: a friendly suggestion?  Wouldn't hurt, I think.
[07:22] <ccm> yes friendly of course
[07:22] <ccm> no flame :)=
[07:22] <ccm> "hey, bastards, you should %&$! use launchpad"!
[07:22] <ccm> :)
[07:23] <Hobbsee> zomg wtf is going on here?
[07:23] <Hobbsee> i *knew* i didnt want to touch X.
[07:24] <StevenK> Heh
[07:24] <Hobbsee> wait, no, it's not that crackful - it's just me reading it wrong
[07:24] <Hobbsee> hi sabdfl 
[07:25] <StevenK> Hobbsee: Cute.
[07:25] <Hobbsee> hehe
[07:25] <sabdfl> hey Hobbsee
[07:25] <Hobbsee> it's not, thank goodness.
[07:27] <StevenK> mesa-utils's Depends is only ${shlibs:Depends} ?
[07:27] <Hobbsee> yep
[07:27] <Hobbsee> which picks up libgl1, which seems to only be found from -swx11
[07:28] <StevenK> Then it's getting libgl1-mesa-swx11-i686 because it links against it.
[07:28] <Hobbsee> StevenK: where does it link against it, sorry?
[07:29] <StevenK> One of the binaries in mesa-utils links against a shared library in libgl1-mesa-swx11-i686.
[07:30] <StevenK> Which is probably libGL directly, just thinking about it.
[07:30] <StevenK> Which means the shlibs.local is wrong.
[07:31] <Hobbsee> riiight.
[07:31] <StevenK> Interesting. libgl1-mesa-swx11-i686 doesn't provide shlibs.
[07:32] <Hobbsee> libgl1-mesa-swx11.shlibs does, though
[07:32] <StevenK> Yes, but it's .shlibs looks correct.
[07:32] <Hobbsee> (why cant the second half of the bug be as easy to fix as the first?)
[07:33] <StevenK> dpkg-shlibdeps is using libgl1-mesa-swx11-i686 for some reason, we just need to figure out what.
[07:34] <Hobbsee> when you find out, do tell how :)
[07:35] <Hobbsee> StevenK: current source, with the first half fixed, is in /home/sarah/mesa/mesa-7.0.0/debian
[07:35] <Hobbsee> on liquified
[07:37] <StevenK> If you dpkg-source -b that directory, I can grab it and sbuild it.
[07:37] <StevenK> In ~sarah/mesa, dpkg-source -b mesa-7.0.0
[07:39] <Hobbsee> StevenK: source, presumably?
[07:40] <StevenK> Sorry?
[07:40] <Hobbsee> StevenK: ie, you want the source package built, so you can throw it at sbuild?
[07:41] <StevenK> Hobbsee: Actually, I don't, since I want to keep the build environment.
[07:41] <StevenK> Hobbsee: It's building now.
[07:41] <Hobbsee> cool
[07:41] <StevenK> dpkg-source -b is the first thing pdebuild does.
[07:42] <Hobbsee> so it seems
[07:48] <calc> ScottK: sistpoty sent me a link to interesting irc log :)
[08:03] <dholbach> can somebody please give back gtkmm2.4?
[08:04] <dholbach> infinity2: ^
[08:30] <dholbach> Mithrandir: already awake?
[08:31] <dholbach> if so, it'd be nice if you'd use your super powahs to give back gtkmm2.4 :)
[08:36] <Hobbsee> bryce: your build was on crack.
[08:39] <Mithrandir> dholbach: hiya
[08:40] <dholbach> hey amitk
[08:40] <dholbach> how's it going?
[08:40] <Hobbsee> morning Mithrandir, dholbach 
[08:41] <dholbach> Hobbsee: I've been here for a while already :-)
[08:41] <Hobbsee> dholbach: i realise that :)
[08:41] <dholbach> hehe
[08:41] <TheMuso> dholbach: Heya. Thanks for the gnome-mag upload.
[08:41] <dholbach> TheMuso: anytime :-)
[08:42] <dholbach> I see... you all want to make me crazy with dj-vu experiences :)
[08:42] <amitk> morning dholbach
[08:43] <Amaranth> morning dholbach ;)
[08:43] <Hobbsee> dholbach: hrm?
[08:45] <ajmitch> Hobbsee: you haven't broken it all then?
[08:46] <Hobbsee> right.  X doesnt break.
[08:46] <Hobbsee> ajmitch: correct.
[08:46] <Hobbsee> ajmitch: i added the conflicts, and the other problem seemed to be due to a frankenstinean build.
[08:47] <Amaranth> Lack of pbuilder
[08:49] <Hobbsee> dunno
[08:49] <ajmitch> right before tribe-2 freeze?
[08:49] <desrt> my X breaks :(
[08:50] <Hobbsee> ajmitch: that's why i'm pondering, rather than doign.  bryce says it's a new upstream, mostly bug fixes.  he hasnt had people test it, apart from him and me testing it here
[08:50] <Hobbsee> although his still had broken bits, so i dont know how his got tested
[08:51] <crimsun> I'd side with his original CFT.
[08:51] <crimsun> post-Tribe 2 upload)
[08:51] <Hobbsee> crimsun: CFT?
[08:51] <StevenK> Call For testers
[08:51] <Hobbsee> right
[08:51] <Hobbsee> as in, here is the repo, please test it
[08:51] <StevenK> Hobbsee: Right.
[08:51] <Hobbsee> ajmitch: i'm one of the release people, it appears.  i just dont touch X normally :P
[08:52] <Hobbsee> but i'd be happy for it to wait until post-tribe 2
[08:52] <ajmitch> exactly, you get to decide
[08:52] <Hobbsee> tfheen: it wasnt reiser, was it?
[08:52] <dholbach> tfheen: urg :/
[08:53] <tfheen> Hobbsee: no, ext3.
[08:53] <Hobbsee> bah.
[08:53] <tfheen> it's a largish one, though
[08:53] <StevenK> How large?
[08:54] <tfheen> 2.5TB
[08:54] <StevenK> Ah ha
[08:54] <StevenK> My largest is only (... only) 740Gb
[08:55] <TheMuso> tfheen: Please tell me that that was in a RAID setup.
[08:56] <tfheen> TheMuso: yes, it is.
[08:56] <TheMuso> phew
[08:56] <StevenK> On top of how many disks? 8?
[08:56] <tfheen> none of the devices have failed, though
[08:56] <tfheen> yeah, 8 + hotspare
[08:58] <infinity2> dholbach: Done.
[08:59] <dholbach> infinity: thanks a lot - once it has built, a lot of other *mm stuff will build again
[09:00] <pitti> Good morning
[09:01] <Hobbsee> morning pitti!
[09:02] <Hobbsee> :)
[09:02] <StevenK> pitti: Morning!
[09:04] <pitti> hi StevenK 
[09:13] <dholbach> somebody please give back gconfmm2.6 and gnome-vfsmm2.6 too 
[09:14] <pitti> dholbach: done
[09:15] <fabbione> pitti:  i saw you got the installer in... good good
[09:15] <pitti> fabbione: erm, I didn't?
[09:15] <fabbione> pitti: i also explained to evand how to make it
[09:15] <fabbione> pitti: well he did it for you :)
[09:15] <pitti> cool
[09:16] <pitti> except that it FTBFSed everywhere
[09:16] <fabbione> pitti: but it's worth checking with cjwatson_ again before publishing images. i dunno if he had changes in the queue. i could only do the ABI bump
[09:16] <fabbione> uh?
[09:16] <fabbione> let me check
[09:16] <fabbione> oh iu think we need ubuntu-modules
[09:17] <fabbione> E: Couldn't find package ubuntu-modules-2.6.22-7-generic-di
[09:17] <fabbione> yes
[09:17] <fabbione> that's it
[09:17] <fabbione> pitti: just give it back once ubuntu-modules are built
[09:17] <fabbione> i forgot about this change when mentioning upload timing to evand
[09:17] <pitti> still building, yes, I just bumped their priority
[09:17] <pitti> fabbione: yep, good
[09:17] <fabbione> my bad sorry
[09:18] <pitti> fabbione: NP, I rather have the source published already :)
[09:18] <fabbione> ehhe
[09:18] <pitti> fabbione: did you change the seeds for this already, too?
[09:19] <fabbione> no
[09:19] <fabbione> it was late in the evening
[09:19] <pitti> fabbione: ok, I'll do it, I need to touch them now anyway
[09:19] <fabbione> ok
[09:19] <pitti> so, I need to figure out now how to do an ABI bump of linux-backports-modules
[09:20] <fabbione> do we need that?
[09:20] <fabbione> AFAIK it's just a var in debian/rules
[09:20] <pitti> fabbione: well, not really, I just don't like stuff in Maintainer: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com>
[09:21] <pitti> erk
[09:21] <pitti> http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[09:21] <pitti> sorry
[09:21] <fabbione> ehhe
[09:21] <fabbione> pitti: do you want me to look at it?
[09:21] <pitti> fabbione: if you want to, sure
[09:21] <fabbione> no i don't but i would it for you :)
[09:22] <fabbione> pitti: linux-backports-modules-geric comes from linux-meta
[09:23] <fabbione> well all of them
[09:23] <pitti> fabbione: right, linux-backports-modules-2.6.22 doesn't even exist yet
[09:23] <fabbione> so i guess as soon as you new linux-meta it will work
[09:23] <pitti> fabbione: no, meta just depends on the -2.6.22-7 packages
[09:24] <pitti> linux-backports-modules-2.6.20 | 2.6.20-15.10 |        feisty | source
[09:24] <pitti> that's the corresponding source for gutsy
[09:24] <fabbione> oh ok
[09:24] <fabbione> hmm
[09:24] <pitti> fabbione: but, we can leave that to the kernel team, too, it's just a nice-to-have
[09:24] <fabbione> ok we don't need it for tribe-2 anyway
[09:39] <pitti> ogra: do you actually want compiz in the desktop seed for edubuntu?
[09:40] <LaserJock> heh, he got compiz working on a Intel ClassmatePC running as a thinclient at Sevilla
[09:40] <LaserJock> that was kinda nifty
[09:40] <pitti> ogra: I merged that change from the seeds now; if you don't want it, can you please throw it out?
[09:42] <pitti> fabbione: all seeds changed for new d-i kernel
[09:46] <pitti> hey mvo
[09:46] <mvo> hey pitti
[09:46] <StevenK> Yay!
[09:47] <LaserJock> hmm, already
[09:47] <LaserJock> I guess it is already almost 1:00am tuesday here
[09:48] <pitti> LaserJock: almost 10:00 am here, and I'd rather have an overview about what goes in now
[09:56] <fabbione> pitti: coolness
[10:08] <stgraber> morning
[10:17] <dholbach> somebody also give back  libgdamm3.0  - it should build now
[10:20] <tfheen> backgegebt.
[10:21] <dholbach> hehehe :)
[10:21] <dholbach> backgegeben would be wrong too, but maybe a bit more right ;-)
[10:29] <ogra> pitti, as long as you dont drop metacity all is fine ... i have no composite support at all in ltsp atm, dunno why but i suspect its an X issue
[10:29] <ogra> so having compiz wont do any harm i tested that
[10:32] <Keybuk> ogra: we need metacity for those without 3D cards, it won't be dropped
[10:33] <seb128_> Keybuk: can we not use the animations for compiz? ;)
[10:33] <ogra> Keybuk, yes, i was expecting that :)
[10:33] <seb128_> those are really crack
[10:35] <Keybuk> seb128: why not?  the subtle ones look really nice
[10:35] <seb128> the current ones are not subtle
[10:35] <seb128> the zoom thing when opening or closing a window is really intrusive
[10:36] <Keybuk> zoom thing?
[10:36] <ogra> if you minimize/maximize
[10:36] <seb128> it does fade in and out with the window shrinking or expending
[10:36] <Keybuk> we can fiddle with animations later
[10:36] <Keybuk> Mark will almost certainly want to be highly involved in that process
[10:37] <seb128> we can't use the GNOME menu atm because the "zoom out and show workspaces" kick in as soon as you go in the corner
[10:37] <Keybuk> that's a bug then, we shouldn't have any active corners enabled by default
[10:37] <Keybuk> prefs are easy to tweak - just ask mvo
[10:37] <seb128> mvo: ^ we can disable that then ;)
[10:37] <mvo> sure
[10:38] <seb128> Keybuk: yeah, but he said to have you to validate the change first to know disable things which should be enabled
[10:38] <seb128> that's why I'm asking what we can disable ;)
[10:38] <Keybuk> things like that, we can disable
[10:38] <Keybuk> animations we should leave on for now
[10:38] <seb128> good
[10:38] <seb128> can we disable the bouncing when maximising a window?
[10:39] <seb128> it's not smooth at all on my box and looks ugly
[10:39] <Keybuk> leave things like that for now, and we'll worry about them later
[10:39] <seb128> ok
[10:40] <Keybuk> what animation setting causes the bounce?  have you fiddled in ccsm to get something more to your liking?
[10:40] <StevenK> I thought that caused by wobbly windows?
[10:41] <Keybuk> so it is
[10:41] <Keybuk> mvo: wobbly should be disabled by default, no?
[10:41] <mvo> Keybuk: yes, that is disabled by default
[10:41] <Keybuk> it's on for seb because he's played in the past?
[10:41] <seb128> I've no wobble
[10:41] <Keybuk> btw, what does the "enable extra animations" checkbox do?
[10:41] <seb128> and I've no ccsm installed
[10:42] <seb128> hum, let me try with a new user
[10:42] <Fujitsu> Keybuk: It enables wobbliness at least, AFAIK.
[10:43] <jtmoulia> ls
[10:44] <ogra> "[: 99: ==: unexpected operator"
[10:44] <mvo> seb128: on the livecd I have no wobble on maximize
[10:44] <ogra> is anyone else seeing that in his .xsession-errors ?
[10:44] <mvo> ogra: me
[10:44] <ogra> hmm
[10:44] <ogra> the Xsession.d scripts look ok
[10:44] <mvo> ogra: I suspect gnome-volume-manager (but that is just a theory)
[10:44] <seb128> mvo: do we have an uptodate desktopCD to try?
[10:44] <mvo> maybe the name compiz wrapper
[10:45] <mvo> seb128: yes, currently daily
[10:45] <mvo> seb128: interesstingly the worksspace seems to work very nicely on it too
[10:46] <seb128> mvo: well, there is no user setting to respect
[10:46] <mvo> still, 4 workspaces, nicely displayed in the panel applet. I like that 
[10:47] <seb128> ;)
[10:47] <seb128> nicely?
[10:47] <seb128> there is separators displayed between them?
[10:47] <mvo> no seperator
[10:47] <Keybuk> s/workspaces/viewports/ no?
[10:47] <mvo> indeed
[10:49] <seb128> I'm downloading the CD
[10:49] <seb128> I'll try if totem works with it
[10:49] <seb128> it doesn't on my desktop
[10:49] <seb128> the video are is not refreshed
[10:50] <seb128> area
[10:50] <pitti> ogra: that depends on what mvo did with the auto-enabling of compiz, I figure :) but since it checks whether X supports it, it should be fine
[10:51] <ogra> yeah
[10:51] <pitti> mvo: how does compiz things look like?
[10:51] <ogra> it didnt do any harm on an up to date system here
[10:55] <pitti> asac: how bad does n-m look? can we at least get the debian_backend patch?
[10:55] <Keybuk> N-M is convinced I'm on a wired network
[10:55] <Keybuk> which is nice, since there's no network cable plugged in
[10:56] <mvo> pitti: not bad currently, I tested in on a nvidia machine just now and it correctly loads metacity with "nv" and can be enabled with the apperance-capplet and restricted-manager (still some UI glitches, but nothing really serious). next is ati r300 and ati r500 on the list to test
[10:56] <pitti> N-M regularly tears down all my interfaces on boot
[10:56] <Amaranth> it also doesn't work with wpa
[10:56] <tfheen> NM makes it just about impossible for me to log in, since I don't have networking when I boot the machine..
[10:56] <tfheen> this doesn't go too well with Kerberos
[10:57] <pitti> Riddell: does adept work now with the reverted debtags/libept? if so, can we move bug 121456 to tribe3?
[10:57] <ubotu> Launchpad bug 121456 in adept "Adept couldn't open debtags database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
[10:57] <Keybuk> tfheen: NM doesn't handle your use case; let's just focus on the regressions from feisty please
[10:57] <tfheen> Keybuk: uh, it worked fine in feisty.
[10:57] <Keybuk> ok, that's interesting then :)
[10:57] <tfheen> if it hadn't, I wouldn't have had NM installed.
[10:58] <StevenK> libept | 0.5.7ubuntu1really0.4.7ubuntu2 ... whoa!
[10:58] <tfheen> it seems like the default policy doesn't hit, and it doesn't enable eth1
[10:58] <Rumba> mvo: i found a bug: i uninstalled some packages in synaptic but they are still shown as "Auto-Installed: 1" in /var/lib/extended_states! (not sure if "Auto-Installed: 0" packages are still shown, but i don't see why not, so i won't test that.)
[10:58] <StevenK> What was so offensive about libept 0.5.7?
[10:58] <Rumba> mvo: are you familiar to this issue?
[10:58] <pitti> StevenK: doesn't work with the current debtags, it needs porting
[10:58] <StevenK> Ahhh
[10:58] <pitti> StevenK: well, debtags needs to be ported to new libept, that is
[10:59] <pitti> fabbione: bug 119057 wasn't mentioned in the -7 changelog; was that fixed upstream?
[10:59] <ubotu> Launchpad bug 119057 in linux-source-2.6.22 "[SPARC]  not all PCI resources are initialized" [Critical,Fix committed]  https://launchpad.net/bugs/119057
[10:59] <fabbione> pitti: yes it's fixed in -7
[11:00] <asac> pitti: i managed to reapply almost all patches .... no idea how to test all those features, but from how the patches apply now it looks good
[11:00] <pitti> asac: can you put the source somewhere? I'm happy to give it some testing, maybe tfheen as well
[11:00] <asac> pitti: bzr
[11:00] <Fujitsu> Amaranth: I'm using WPA fine, and I upgraded about 20 minutes ago. nm-applet does segfault if I let it use the keyring, though.
[11:00] <asac> pitti: wait a second
[11:01] <mvo> Rumba: that is known and harmless because when they are installed next the state will be corrected (if that is needed). it clutters the file though and I plan to fix it for gutsy
[11:01] <pitti> asac: ah, orig.tar.gz plus bzr? or do you maintian the entire code in bzr now?
[11:01] <fabbione> pitti:    * [SPARC64] : Handle PCI bridges without 'ranges' property.
[11:01] <asac> https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
[11:01] <fabbione> pitti: (from the changelog)
[11:01] <asac> pitti: its all in
[11:01] <Amaranth> Fujitsu: well, i guess it might have something to do with the fact that my laptop is broken but it works with wpa_supplicant
[11:01] <asac> pitti: if you wnt orig i can push it somewhere
[11:01] <pitti> asac: ah, cool
[11:01] <pitti> asac: nevermind, bzr is fine
[11:01] <asac> pitti: applet is coming in a minute
[11:01] <asac> will push it there as well
[11:02] <seb128> pitti: can we enable apport by default now?
[11:02] <pitti> asac: but when building the source package, you'll still use the upstream orig.tar.gz?
[11:02] <pitti> seb128: we could, we just don't yet have the privacy thing
[11:02] <Rumba> mvo: can/will you fix it upstream?
[11:03] <pitti> seb128: I didn't manage to finish that yesterday
[11:03] <mvo> Rumba: yes, that is my plan
[11:03] <pitti> seb128: hm, if we want that, let me upload a new one with some bug fixes
[11:03] <seb128> pitti: having crach stacktrace now would be nice, upstream freeze is coming
[11:03] <pitti> seb128: right, ok; let's flip the privacy thing on post-tribe then
[11:03] <asac> pitti: yes ... i use tarballs/ directory
[11:03] <Rumba> mvo: oh, and do you plan to add a "_manually_ installed" checkbox in synaptic's custom filters?
[11:04] <seb128> thanks
[11:04] <mvo> Rumba: not at this time, but I would be happy about a patch :)
[11:04] <pitti> mvo: do you plan to upload update-notifier? if not, I would like to flip apport on and upload
[11:04] <Rumba> :)
[11:04] <mvo> pitti: go ahead
[11:05] <asac> pitti: ok for applet tarball: http://people.ubuntu.com/~asac/network-manager-applet_0.6.5.orig.tar.gz
[11:05] <asac> pitti: debian only bzr here: https://code.launchpad.net/~ubuntu-core-dev/network-manager/gnome.ubuntu.0.6.x
[11:06] <Rumba> mvo: so let me get this clear: you are a dev of synaptic or aptitude?
[11:06] <pitti> tfheen: ^ can you give this some testing as well?
[11:06] <pitti> asac: it works for you so far?
[11:07] <Rumba> mvo: i mean, is it synaptic or is it aptitude that you are a dev of?
[11:07] <mvo> Rumba: I maintain apt and synaptic. aptitude is done by daniel burrows
[11:07] <asac> pitti: can't really tell because my vm license has expired and my other system is currently installing.
[11:07] <asac> ... gutsy
[11:08] <tfheen> asac: my problems does not have anything to do with the applet, they're in the core code.
[11:08] <tfheen> (since the applet hasn't started at gdm time)
[11:08] <asac> tfheen: i redid the merge for core code
[11:08] <tfheen> asac: where is it, then?
[11:08] <asac> read 20 lines above :)
[11:08] <pitti> tfheen: <asac> https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
[11:08] <asac> wait a second
[11:09] <Keybuk> tfheen: tbh, I'm not sure why NM ever brought the network interface up before login
[11:09] <Keybuk> tfheen it was never supposed to, or deliberately patched to do that
[11:09] <Keybuk> tfheen: you may have been relying on a bug
[11:09] <tfheen> Keybuk: it didn't, but it failed to kill dhclient.
[11:09] <stgraber> Who is the secretary for this afternoon CC ? It used to be Seveas but I understood it's taken a month off
[11:10] <stgraber> s/it's/he's/
[11:10] <pitti> asac: why does the -core package build-depend on libpanel-applet2-dev? I thought the core should be gtk free?
[11:10] <asac> tfheen: Keybuk tonio dropped debian_backend and lots of other patches during 0.6.5 merge ... so current version should be more or less completely broken 
[11:10] <asac> pitti: probably left over ... can fix it.
[11:10] <Keybuk> asac: yes, I saw that
[11:11] <asac> pitti: i concentrated to reapply all patches for now
[11:11] <pitti> asac: are you ready for enabling apport on tribe-2, too?
[11:12] <asac> i am fine with it ... at best we can figure a way out how my precious helper hjmf can still process crash reports :)
[11:13] <asac> actually i want crash reports yesterday
[11:15] <mvo> hm, it looks like libgl1-mesa-dri is missing from the livecd
[11:15] <pitti> mvo: we deliberately kicked it
[11:15] <pitti> mvo: it's 14 MB and we didn't have it before
[11:15] <pitti> well, from alternate at least
[11:15] <mvo> its kind of essential to get compiz working
[11:16] <Amaranth> yeah....
[11:16] <Amaranth> or 3d of any kind
[11:16] <ogra> ah, thats why i didnt get compiz going on ltsp ... indeed :)
[11:16] <pitti> mvo: hm, then something should have a dependency on it, and we need to kick off 14 MB of stuff from the CDs
[11:17] <ogra> libgl1-mesa-glx has a replaces though
[11:17] <ogra> Replaces: libgl1, libgl1-mesa-dri (<< 6.4.0)
[11:17] <ogra> Conflicts: libgl1, libgl1-mesa-dri (<< 6.4.0)
[11:20] <pitti> asac: did you change anything in the API of network-manager? the applet currently b-deps on network-manager-dev (>= 0.6.5), i. e. will also build against the current n-m in the archive
[11:21] <pitti> asac: if there is no API change, that's fine, then we can get it published faster, but it should be double-checked
[11:22] <asac> pitti: i started with tonios debinization
[11:22] <Amaranth> pitti: the problem is compiz can work with libgl1-mesa-dri, nvidia-glx, or any sort of driver that does 3d + xgl
[11:22] <Amaranth> i suppose compiz could do an OR depend on those three
[11:22] <ogra> what about libgl1-mesa-glx ?
[11:23] <Amaranth>  This package does not include the modules themselves: these can be found
[11:23] <Amaranth>  in the libgl1-mesa-dri package.
[11:23] <asac> pitti: so ... i have to verify ... but i hope that we don't change api in nm at all ... do we?
[11:23] <pitti> Amaranth, mvo: ok, then we need to put it into desktop-recommends
[11:23] <pitti> asac: I don't know
[11:23] <pitti> anyway, let me reboot for testing new kernel and n-m
[11:23] <Amaranth> ogra: and libgl1-mesa-dri is 6.5.3
[11:24] <Amaranth> that's an old replaces
[11:24] <ogra> ah, right
[11:24] <ogra> and -dri depends on -glx
[11:24] <ogra> ok
[11:24] <Amaranth> right, they were split
[11:24] <ogra> where do we get 14M ???
[11:24] <Amaranth> :/
[11:25] <Amaranth> kick tomboy and fspot out? ;)
[11:25] <seb128> Amaranth: edubuntu already does no?
[11:25] <ogra> yes
[11:25] <ogra> edubuntu isnt the problem :)
[11:25] <Amaranth> oh, this is for edubuntu?
[11:25] <ogra> i can easily drop a language
[11:25] <Amaranth> i thought we were talking about ubuntu desktop
[11:25] <ogra> the prob is ubuntu atm
[11:26] <ogra> and the livefses
[11:26] <seb128> Amaranth: no way to drop those from the ubuntu desktop
[11:27] <Amaranth> what was added to suddenly make this not fit?
[11:27] <Keybuk> Amaranth: we've been at 100% for a few releases now
[11:27] <Amaranth> right but this was on the CD before
[11:28] <dholbach> i386 gtkmm2.4 build faster!
[11:28] <Keybuk> so every time we add something, something else needs to be taken awy
[11:29] <Keybuk> openoffice probably swelled another few megabytes, etc.
[11:29] <Amaranth> ah yes, the beast
[11:30] <Amaranth> I don't even know what goes on the CD so I wouldn't know what to remove
[11:31] <seb128> dholbach: faster than what?
[11:31] <Amaranth> obvious choice would be a language pack but i think you already dropped all those
[11:31] <Keybuk> there's still half a dozen language packs
[11:31] <dholbach> seb128: just faster, so I can ask for give-backs of all the other *mm stuff, so everything's good again :-)
[11:31] <asac> pitti: back?
[11:31] <pitti> asac: yes
[11:31] <seb128> Amaranth: some depends have been added I think, like gnome-system-monitor uses gtkmm now
[11:31] <pitti> asac: well, it sucks a tad less
[11:32] <pitti> asac: it didn't touch eth1 any more (my static interface)
[11:32] <Amaranth> ah, right, GNOME decided C++ bindings could be used in desktop modules
[11:32] <asac> pitti: hmm
[11:32] <seb128> dholbach: faster is compared to something, you are faster than ... before, something else, etc ;)
[11:32] <pitti> asac: but it still tears down eth0 (standard auto/dchp) and doesn't connect to it at start
[11:32] <Amaranth> and C++ is bloated
[11:32] <Keybuk> at some point, we are just going to have to bite the bullet, and accept that we don't fit on a single CD anymore
[11:32] <pitti> asac: when I log in, it just says 'manual configuration', so I have to sudo ifdown/ifup; I cannot even click
[11:32] <Amaranth> Keybuk: hopefully that can be a year from now
[11:33] <Keybuk> Amaranth: why a year?  I've been arguing for DVD-as-default-image for a year already :p
[11:33] <dholbach> we had gtkmm on there before
[11:33] <seb128> let's switch to 7z ;)
[11:33] <Amaranth> 7z would help a lot too
[11:33] <seb128> dholbach: on the CD?
[11:33] <Amaranth> it'd give us that year :)
[11:33] <pitti> Keybuk: there's still quite a bit of air (lzma for alternates, better squashfs for desktop), I think
[11:33] <seb128> dholbach: why?
[11:33] <Amaranth> Keybuk: well, computers made in 2003 didn't all have DVD drives
[11:33] <asac> pitti: does this behaviour remind you of something (e.g. was that tackled once with a patch?) 
[11:34] <Amaranth> Keybuk: it'd be nice if a 4 year old computer could use our stuff
[11:34] <pitti> Amaranth: one of Ubuntu's key goals is good i18n support; we cannot just drop *all* langpacks to fit new crack, we have to get rid of old crack, too
[11:34] <dholbach> seb128: hm, maybe not - I thought of inkscape and workrave - they're both in supported though
[11:34] <pitti> asac: not really, I'm not intimately familiar with the patches
[11:34] <dholbach> pitti: did you drop gnomedb and gda2 already?
[11:34] <Amaranth> don't we still have gphoto along side f-spot?
[11:34] <pitti> asac: and I never saw that one
[11:34] <seb128> dholbach: ah, gparted
[11:34] <dholbach> ah right, gparted too
[11:35] <dholbach> :-)
[11:35] <Amaranth> gthumb, rather
[11:35] <pitti> asac: it has always torn down my eth0 from /etc/init.d/networking, but at least it brought it up again on login
[11:35] <seb128> Amaranth: yes, not the same usecase
[11:35] <pitti> Amaranth: yes, we have; eog, gthumb, f-spot
[11:35] <seb128> Amaranth: f-spot works fine when you want to handle your photos based on exif tag
[11:35] <Amaranth> eog makes sense, it's one of those 'spatial' things
[11:36] <seb128> but some people classify by hand and want gthumb to browse the directories
[11:36] <asac> pitti: do you have logs?
[11:36] <pitti> asac: TBH, at this point I'm even inclined to roll back to the feisty versions
[11:36] <Amaranth> i mean, it's just "here is your photo" and not "here is my app with your photo in it"
[11:36] <seb128> eog is a simple viewer
[11:36] <ogra> Amaranth, edubuntu has gthumb we never had space for mono
[11:36] <bhale> f-spot --view does directories now, no?
[11:36] <seb128> ogra: you have 2 CDs now though, no? ;)
[11:36] <seb128> bhale: it's not good enough atm
[11:36] <seb128> bhale: the idea is there but it still sucks
[11:36] <Treenaks> seb128: eog has a nice multi-picture mode too now
[11:36] <asac> pitti: ... can we do that?
[11:37] <ogra> seb128, yeah, all mono stuff is on the second one since feisty :)
[11:37] <Amaranth> f-spot --view seems to be an eog replacement
[11:37] <asac> pitti: e.g. without going for epoch and other hacks :)
[11:37] <pitti> asac: 0.6.5+really0.6.4foo :)
[11:37] <ogra> seb128, and i still only have one livecd
[11:37] <asac> pitti: oh :)
[11:37] <Amaranth> yeah, eog is getting pretty powerful
[11:37] <Amaranth> i'd say it's a nice replacement for gthumb
[11:37] <seb128> asac, pitti: are you downgrading to nm 0.6.4?!
[11:38] <pitti> asac: logs> very helpful :/
[11:38] <bhale> seb128: it seems pretty nice to me, but i was never an eog user. sorry
[11:38] <pitti> Jun 26 11:26:01 localhost NetworkManager: <info>  Now managing wired Ethernet (802.3) device 'eth0'. 
[11:38] <pitti> Jun 26 11:26:01 localhost NetworkManager: <info>  Deactivating device eth0. 
[11:38] <Amaranth> err, feisty didn't have the separate tarball for the applet
[11:38] <pitti> Amaranth: so what? the binary name is the same
[11:38] <Amaranth> anyway, on the photo thing, we have 3 applications that overlap all over each other
[11:39] <Amaranth> one of them can go away
[11:39] <bhale> gthumb should go first imo
[11:39] <Amaranth> which one, i particularly care but gthumb is the one getting squeezed in the middle
[11:39] <asac> pitti: lets see if i somehow get this virtualbox thing going
[11:39] <Amaranth> err, don't particularly care
[11:40] <bhale> gthumb looks a lot like nautilus with some extra buttons/menus
[11:40] <Amaranth> yeah, even nautilus is squeezing out gthumb
[11:40] <seb128> bhale: it seems to work better than previous time I tried it
[11:40] <pitti> Amaranth: photo import is the only important thing of gthumb
[11:40] <Amaranth> it's just begging to be killed off
[11:40] <ogra> bhale, make mono small enough to fit on the edubuntu livecd, then i can drop gthumb :)
[11:40] <bhale> seb128: i like the sidebar with previews
[11:41] <bhale> ogra: heh, oh.
[11:41] <Amaranth> pitti: we have nothing else that can do photo import?
[11:41] <seb128> bhale: eog has that too ;)
[11:41] <seb128> I thing we should drop gthumb
[11:41] <Keybuk> pitti: isn't f-spot the default photo import tool anyway?
[11:41] <Amaranth> no
[11:41] <seb128> Keybuk: no
[11:41] <pitti> Amaranth: f-spot's still sucked hard the last time I tried it
[11:41] <Amaranth> gthumb offers to import my photos
[11:41] <pitti> Keybuk: not yet
[11:41] <Amaranth> then i close it and point f-spot at the mounted sd card
[11:41] <Keybuk> odd, it is for me; and I don't remember changing that
[11:42] <dholbach> does f-spot have something to get rid of 24697246 of duplicates in the mean time?
[11:42] <Amaranth> eh?
[11:42] <bhale> no, its on the roadmap
[11:42] <bhale> Amaranth: he doesnt empty his camera, keeps importing over and over
[11:42] <dholbach> or I import from ~/my_pictures
[11:43] <Amaranth> bhale: wouldn't the camera get full? :)
[11:43] <dholbach> because I had them copied on another machine already
[11:43] <Amaranth> btw, not even iPhoto handles that case well
[11:43] <Treenaks> I never understood this 'import into database' thing.. just like rhythmbox..
[11:43] <dholbach> that's why I like gthumb, it doesn't get in my way
[11:43] <dholbach> I can just take a look at my sorted pictures
[11:43] <Treenaks> Something always happens, it gets out of sync.. the database breaks..
[11:44] <Ng> f-spot is so much better than gthumb, but you have to work with its way of doing things
[11:44] <ogra> err
[11:44] <ogra> f-spot
[11:44] <Ng> in that gthumb is really simple and stupid and f-spot is a photo manager :)
[11:44] <dholbach> oh, f-spot just crashed, hrm ... well
[11:44] <Amaranth> i thought we were supposed to pick the 'best' app as a default instead of offering them all :)
[11:44] <Fujitsu> F-Spot's default configuration of storing metadata in its own DB is just deranged, however.
[11:45] <Keybuk> Amaranth: it gets difficult to pick the best when developers prefer different ones
[11:45] <Ng> Fujitsu: it stores metadata in EXIF tags afaics, all of my comments from it are in the photos themselves
[11:45] <Fujitsu> Ng: It has an option to, but that wasn't the default when I last tried.
[11:45] <Amaranth> Keybuk: Needs a vote or something :)
[11:45] <seb128> dholbach: what do you have with gthumb than eog doesn't have (out of photos import that can be done with f-spot even if you don't use it)?
[11:45] <ogra> Amaranth, apart from what Keybuk said, its a technical issue, mono doesnt fint on the edubuntu liveCd 
[11:45] <Ng> Fujitsu: *shrug* WFM since edgy
[11:45] <Amaranth> ogra: right, but i'm talking about ubuntu :)
[11:45] <Keybuk> Amaranth: technical board is the body to resolve disputes
[11:45] <ogra> Amaranth, so we have to resort to either no photo app or gthumb there
[11:46] <pitti> asac: so, if this works on a default install with just one eth, we should just take your version, but if it doesn't even auto-connect there, we should revert
[11:46] <ccm> *giggle* I thought hug day is today and wondered why nobody is hugging around
[11:46] <ccm> thank you Fujitsu ;)
[11:46] <seb128> ccm: hug day is tomorrow :)
[11:47] <ccm> seb128: i should check my calender more often
[11:47] <dholbach> seb128: just small features I know my sister uses - like photo web album, small effects like red-eye-removal and color adjustment
[11:47] <ogra> ccm, feel free to hug in advance though :)
[11:47] <seb128> dholbach: k, you really want to use f-spot then :p
[11:47] <pitti> asac: it might really just be the two dhclients fighting each other; hell, we should really fix bug 90267
[11:47] <ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
[11:48] <dholbach> I don't - I don't like the 'management' thing about it - it doesn't work for me - if you remove it from main, I'm happy to use eog
[11:48] <seb128> dholbach: you know about f-spot --view, right?
[11:49] <dholbach> seb128: does the 'folder' thing on the left hand side work for you?
[11:49] <ogra> pitti, so any idea where we get the 14M from now ?
[11:49] <seb128> dholbach: no
[11:49] <dholbach> for me neither
[11:49] <seb128> but opening a folder with it from nautilus should work fine ;)
[11:49] <pitti> ogra: for getting -dri in? no, not really
[11:49] <asac> pitti: so you are struck by bug 90267 ... but you haven't been before?
[11:49] <ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
[11:50] <dholbach> I'll keep trying to use it every now and then
[11:50] <pitti> asac: I have always seen that
[11:50] <seb128> cool
[11:50] <dholbach> but until now I don't feel it makes my life a better place
[11:50] <seb128> dholbach: if there is bugs we should try to fix them rather than relying on an another software as a workaround
[11:50] <pitti> asac: however, so far n-m daemon tore down eth0, and then nm-applet brought it up again
[11:50] <ogra> pitti, i think i still have some langs to drop from the server CD but no idea what to do about live
[11:50] <carlos> pitti: I guess gutsy language pack was correct, wasn't it?
[11:50] <Amaranth> without -dri you might as well remove compiz, it's just taking up space doing nothing
[11:50] <pitti> asac: but now nm-applet starts with a 'only manual configuration' state and doesn't bring up anything
[11:50] <asac> pitti: ah ok ... so applet might be the problem for you
[11:50] <dholbach> seb128: for me gthumb is not a workaround, it's the software I use
[11:51] <pitti> carlos: worked fine so far; seb128, how do the current langpacks look for you?
[11:51] <pitti> asac: it's in the daemon, I think
[11:51] <asac> pitti: did you use the new applet?
[11:51] <dholbach> and my sister won't type in 'f-spot --view'
[11:51] <pitti> asac: the applet itself is really harmless
[11:51] <Keybuk> dholbach: removing it from the CD doesn't prevent you from continuing to use it
[11:51] <pitti> asac: yes, of course; bzr head
[11:51] <dholbach> Keybuk: sure not
[11:52] <ogra> dholbach, you could use the edubuntu addon cd as well its on there ;)
[11:52] <mvo> pitti: I will change the seed to recommend libgl1-mesa-dri in ubuntu-desktop and make compiz a recommend  as well (currently its a depend). ok with you?
[11:52] <pitti> mvo: no, it's not
[11:53] <carlos> ok
[11:53] <pitti> mvo: you have to drop 14 MB of stuff in exchange
[11:53] <pitti> mvo: well, 6 MB on i386 and 10 MB on amd64
[11:53] <dholbach> infinity gave back gtkmm2.4 3 hours ago - shouldn't if have built on i386 already?
[11:53] <pitti> dholbach: let me look
[11:53] <dholbach> s/if/it
[11:53] <mvo> pitti: that is installed size? or package size?
[11:54] <pitti> mvo: package size
[11:54] <pitti> mvo: (roughly)
[11:54] <pitti> dholbach: I bumped the build score
[11:54] <dholbach> thanks a lot pitti
[11:54] <pitti> dholbach: the i386 buildds are *still* busy with langpacks (gosh, I uploaded them 11 hours ago)
[11:54] <seb128> dholbach: it's not about f-spot making your life better, it's about not having too much duplication when the CD needs space
[11:55] <dholbach> seb128: I'm not going to stop you 
[11:55] <seb128> pitti: there is new gutsy languagepack availables? I didn't update yet this morning
[11:55] <ajmitch> seb128: so which one sucks less?
[11:55] <ogra> pitti, we should restrict the translation teams to not translate so much :P
[11:55] <seb128> ajmitch: I think we should have eog and f-spot on the CD
[11:56] <pitti> seb128: yes, in the archive
[11:56] <seb128> ajmitch: eog as a simple viewer and an image browser and f-spot has a photo manager
[11:57] <seb128> pitti: I've to go out to buy some food now, I'll test in 20 minutes if that's ok with you
[11:57] <pitti> seb128: sure
[11:57] <seb128> k, bbl then ;)
[11:57] <pitti> dholbach: building now
[11:57] <Amaranth> well, gthumb gives us about 1M
[12:07] <ogra> 1
[12:08] <siretart> 2
[12:08] <axxo> 3
[12:09] <ogra> heh
[12:16] <pygi> fabbione, poke?
[12:16] <fabbione> yeah?
[12:16] <pygi> fabbione, got a sec with your sparc?
[12:16] <fabbione> yup
[12:17] <pygi> fabbione, thanks, will send you mail
[12:17] <fabbione> ok
[12:18] <pygi> fabbione, sent
[12:18] <fabbione> got it
[12:18] <pitti> ogra: can we easily drop rss-glx and xscreensaver-gl? or will something freak out when we remove it?
[12:18] <pygi> great
[12:19] <fabbione> i assume that's against what's in the archive.. right?
[12:19] <pygi> fabbione, ergh ... yes, but the package failed to build ofcourse
[12:19] <fabbione> i could guess that ... :)
[12:19] <pygi> hehe
[12:20] <pitti> Keybuk: are you ok with me dropping the rss-glx and xscreensaver-gl from desktop? 4.9 MB together
[12:20] <Ng> win 42
[12:20] <Ng> bah
[12:22] <fabbione> pygi: building
[12:22] <pygi> fabbione, great, fingers crossed that so it works =)
[12:24] <pitti> cjwatson: do you know whether we can drop one of ttf-kochi-{mincho,gothic}? Both are Japanese fonts, and both are huge
[12:24] <pitti> cjwatson: same question for ttf-arphic-{ukai,uming}; dropping one of them would basically solve the libgl1-mesa-dri problem
[12:26] <cjwatson> my memory is that mincho and gothic are like roman and italic
[12:26] <cjwatson> or something like that
[12:27] <persia> Rather Serif / Sans-Serif (for gothic/mincho)
[12:27] <cjwatson> ah
[12:27] <cjwatson> I knew it was something like that
[12:27] <cjwatson> if you're going to drop one, it would be better to drop both
[12:28] <cjwatson> (and make sure language-support-whatever depends on them)
[12:28] <pitti> yeah, I would do the latter anyway, of course, but still a bit nasty to drop the fonts completely?
[12:29] <cjwatson> all choices for finding 14MB of space are nasty
[12:29] <cjwatson> and will make some people unhappy
[12:30] <cjwatson> on pure number-of-speakers criteria kochi is probably the rational choice
[12:30] <pitti> that'll give us 8.4 MB
[12:31] <minghua_> pitti: uming/ukai difference is more like serif/script, rather than serif/sans-serif
[12:31] <minghua_> pitti: IMO ukai can be safely dropped.  But probably it's just me.
[12:31] <ogra> pitti, fine with me, to sad i dont ship either in edubuntu 
[12:31] <pitti> minghua_: does the desktop reasonably work without one of them? and the other one is pulled with language-support-zh?
[12:32] <ogra> ouch
[12:32] <ogra> debootsrap failed here
[12:32] <cjwatson> ogra: details?
[12:32] <minghua_> pitti: desktop definitely works fine without -ukai, and IMO lang-s-zh shouldn't pull in -ukai
[12:32] <ogra> cant mount proc
[12:33] <minghua_> pitti: on the other hand, without -uming the Chinese desktop would be rather ugly
[12:33] <pitti> minghua_: so -ukai is the 'script' variant? not really for day-to-day desktop texts?
[12:33] <ogra> (i'm installing to a usb drive, but that shouldnt matter, should it?)
[12:33] <minghua_> pitti: again, just my personal opinion
[12:33] <pitti> minghua_: thanks a lot; that's much better than everything I could have figured out :)
[12:33] <cjwatson> ogra: you're in the best position to debug it
[12:33] <minghua_> pitti: you can still use it for day-to-day desktop, it's not like "zapf" script, just that more people will be comfortable with -uming
[12:34] <minghua_> pitti: if it is decided to drop -ukai, I suggest an announcement (to ubuntu-zh list, perhaps)
[12:35] <pitti> minghua_: I'll add it to language-support-zh then at least
[12:36] <cjwatson> I did test it with both Debian and Ubuntu before uploading 1.0.0
[12:36] <ogra> Jun 26 18:19:21 debootstrap: chroot: 
[12:36] <ogra> Jun 26 18:19:21 debootstrap: cannot execute mount
[12:36] <ogra> Jun 26 18:19:21 debootstrap: : No such file or directory
[12:40] <cjwatson> look further up in the log and see if mount didn't get extracted for some reason
[12:42] <ogra> well, it mounts the disks above
[12:42] <ogra> Jun 26 18:18:15 kernel: [  296.776000]  EXT3-fs: mounted filesystem with ordered data mode.
[12:42] <ogra> Jun 26 18:18:15 50mounted-tests: debug: mounted as ext3 filesystem
[12:42] <ogra> Jun 26 18:18:15 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10freedos
[12:42] <minghua_> so which package is going to use the space left by ttf-arphic-ukai?  libgl-mesa-dri?
[12:42] <cjwatson> ogra: that is not done in the chroot
[12:43] <pitti> minghua_: right
[12:43] <cjwatson> ogra: i.e. different mount binary
[12:43] <ogra> ah, right
[12:43] <ogra> but there is nothing above
[12:43] <seb128> pitti: there is no -base language pack updates available
[12:43] <ogra> Jun 26 18:18:36 main-menu[3053] : INFO: Falling back to the package description for console-setup-udeb 
[12:43] <ogra> Jun 26 18:18:36 main-menu[3053] : INFO: Menu item 'base-installer' selected 
[12:43] <ogra> Jun 26 18:18:37 apt-install: Queueing package console-setup for later installation
[12:43] <ogra> Jun 26 18:19:21 debootstrap: chroot: 
[12:43] <ogra> Jun 26 18:19:21 debootstrap: cannot execute mount
[12:43] <ogra> 9
[12:43] <ogra> oops
[12:43] <ogra> thats how the log looks like
[12:43] <seb128> pitti: and language-pack-fr and language-pack-gnome-fr are empty
[12:44] <pitti> seb128: that's fine, it's a fresh -base update
[12:44] <seb128> pitti: well, there is no -base update available
[12:44] <cjwatson> ogra: there should be a debootstrap.log around somewhere
[12:44] <seb128> pitti: 
[12:44] <seb128> *** 1:7.10+20070603 0
[12:44] <seb128>         500 http://archive.ubuntu.com gutsy/main Packages
[12:44] <seb128>         100 /var/lib/dpkg/status
[12:44] <seb128> [seb128 : ~] $ 
[12:44] <cjwatson> perhaps in /target/debootstrap/
[12:44] <pitti> seb128: right, it's not built yet
[12:44] <ogra> http://people.ubuntu.com/~ogra/tribe2-syslog
[12:45] <ogra> i'll get the deboostrap one as well, one moment
[12:45] <seb128> pitti: k, I'll test when they will be available then
[12:45] <pitti> seb128: I wonder why it takes so long; in previous times, new langpacks were built in three hours or so
[12:45] <seb128> https://launchpad.net/ubuntu/+source/language-pack-gnome-fr-base/1:7.10+20070625/+build/353138
[12:45] <seb128> "took two minutes"
[12:46] <seb128> just waiting to get it published now then
[12:46] <pitti> right
[12:46] <seb128> not sure why the buildd were busy
[12:46] <pitti> seb128: well, we had a kernel update, too
[12:46] <seb128> I suspect it's because dholbach rebuilt twice the gtkmm world
[12:46] <pitti> and that :)
[12:47] <ogra> cjwatson, nothing in /target ... :/
[12:47] <ogra> cjwatson, seems it didnt run at all
[12:47] <cjwatson> it may have been moved elsewhere, e.g. /var/log
[12:47] <cjwatson> please hunt around
[12:47] <ogra> cjwatson, i have a pile of packages in /target/var/cache... but no /bin or anything yet
[12:49] <ogra> only cdrom deboostrap etc lost+found media and var in /target
[12:49] <cjwatson> might be /target/var/log/bootstrap.log
[12:49] <cjwatson> ogra: /target/debootstrap/debootstrap.log?
[12:49] <ogra> nope
[12:49] <cjwatson> neither of those?
[12:50] <ogra> nope
[12:50] <cjwatson> what is in /target/debootstrap ?
[12:50] <ogra> debpaths
[12:50] <ogra> nothing else
[12:50] <ogra> unless its hidden
[12:50] <cjwatson> can you apply some initiative and look around?
[12:50] <ogra> nothing hidden either
[12:50] <ogra> there is no log in /target, i promise
[12:50] <cjwatson> it is very difficult to do this at a distance, and your replies are pretty brief
[12:51] <pitti> ogra: hm, so do you want libgl1-mesa-dri back in edubuntu as well? I'm just merging seed changes
[12:52] <ogra> pitti, i think i'll wait until tribe3 no idea where to get 14M on the liveCD that quickly
[12:52] <pitti> ogra: ok
[12:52] <cjwatson> debootstrap works fine in a normal system here
[12:52] <ogra> yeah, i built a, ltsp client yesterday as well
[12:53] <cjwatson> I saw somebody else complaining over the last week about debootstrap breaking, but I'm not sure if that was before or after debootstrap 1.0.0
[12:54] <ogra> well, the error i see on console one is definately right, there is no /target/proc yet
[12:54] <cjwatson> ogra: what's the context of this breakage? i.e. what CD image?
[12:54] <ogra> i'll try to run it manually, lets see where it goes
[12:54] <cjwatson> it's usually not wise to debug the most recent error
[12:54] <ogra> cjwatson, current daily edubuntu server iso
[12:54] <cjwatson> you need to find the first error and debug that
[12:54] <ogra> indeed
[12:56] <cjwatson> the symptoms are consistent with debootstrap bailing out for some reason before managing to extract required packages
[12:56] <ogra> yeah
[12:56] <cjwatson> (/proc is part of base-files)
[12:56] <ogra> my manual run stops after validating zlib
[12:56] <cjwatson> stops in what way?
[12:57] <ogra> i'll -x it
[12:57] <ogra> W: Failure trying to run: chroot /target mount -t proc proc /proc
[12:57] <ogra> last line after Validating zlib1g
[12:57] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/jessica.txt eek, I need to fix that script
[12:58] <cjwatson> no Extracting?
[12:58] <ogra> nope
[12:58] <ogra> and a good load additional deps are found as well
[12:58] <ogra> the list is usually shorter
[12:58] <cjwatson> hmm, I wonder
[12:59] <ogra> base-files is in there btw
[12:59] <cjwatson> I bet debian-cd's Priority generation is broken
[12:59] <ogra> hmm
[12:59] <ogra> all packages are in there now that i look closer
[12:59] <cjwatson> sounds like fallout from the required/minimal split; if so, my fault
[01:00] <ogra> strange that it works in non installer mode
[01:00] <cjwatson> not at all
[01:02] <pitti> I'm just rebuilding *-meta for seed changes; shall I hold off?
[01:02] <cjwatson> pitti: no, go ahead
[01:02] <pitti> i. e. will fixing that require seed/meta changes in any way?
[01:02] <pitti> ok, thanks
[01:02] <cjwatson> purely a cdimage bug
[01:11] <StevenK> Hrm, because I touched ipvsadm last, I'm somehow qualified to answer questions about it...
[01:11] <pitti> BenC, kylem: I cleaned some kernel bugs from https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=469, but I'm not sure whether -7 fixes any of the remaining ones; can you please have a look?
[01:16] <pitti> asac: does n-m get you connected if you just have one ethernet interface with the standard dhcp configuration?
[01:16] <StevenK> pitti: Is archive-cruft-checker fixed? Or should I look at fixing bugs instead?
[01:16] <pitti> asac: I currently collect the last sources which need to go to the candidate CD images
[01:16] <pitti> StevenK: it's fixed now
[01:16] <pitti> StevenK: let me clean up some cruft and then regenerate the lists
[01:17] <StevenK> pitti: Ah, thanks.
[01:17] <pochu> pitti: for bug 121441 (which is milestoned for tribe-2), syncing 5.0.41a-1 from debian will fix it.
[01:17] <ubotu> Launchpad bug 121441 in mysql-dfsg-5.0 "Mysql man pages are non-free" [Critical,In progress]  https://launchpad.net/bugs/121441
[01:17] <pitti> pochu: oh, cool
[01:17] <pochu> Since you have sync-powers... ;)
[01:18] <ogra> pochu, so was a doc package split out ? 
[01:18] <ogra> i know mathiaz wanted to work on it to not loose the manpage
[01:18] <pitti> no, manpages removed
[01:18] <pochu> ogra: no, they removed it from the tarball.
[01:18] <pochu>    * Removed all manpages from the source (therefore the "41a") as they
[01:18] <pochu>      are not licensed under the GPL and redistribution is not permitted
[01:18] <pochu>      (thanks to Mathias Gug). Closes: #430018
[01:19] <ogra> ah, ok, he said he wanted to keep it in multiverse
[01:19] <pitti> ogra: that needs a separate source package anyway
[01:19] <mjg59> ogra: Can't do that if there's no permission to redistribute
[01:20] <pitti> mjg59: redistribution is fine
[01:20] <pitti> mjg59: but not modification
[01:20] <pitti> (AFAIUI)
[01:20] <tfheen> pitti: "fine".  If you distribute it with the mysql binaries
[01:20] <tfheen> at least from my skimming of the licence
[01:20] <Fujitsu> Binaries and manpages have to be on the same medium, it seems.
[01:21] <Fujitsu> If they really wanted to, I'm sure they could say another component violated that.
[01:22] <asac> pitti: i will test asap (a few hours) ... i still have to install gutsy ... backup is still running.
[01:24] <cjwatson> pitti: just waiting for bzr to configure in this upgrade pass before I can get the cdimage thing fixed
[01:26] <pitti> tfheen: how does asac's n-m perform for you? any better?
[01:26] <pitti> pochu: synced, thanks for pointing out
[01:27] <tfheen> pitti: oh, sorry, I completely forgot, I'll test now.
[01:27] <pitti> tfheen: with my two network cards, it's a tad less broken, but not nearly as smooth as feisty
[01:30] <fabbione> now i see why my ipv6 address is gone again
[01:30] <pochu> pitti: cool
[01:31] <pitti> (RC bugs)-- :)
[01:31] <fabbione> BZZZT
[01:31] <fabbione>   * Dropped obsolete
[01:31] <fabbione>     20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch
[01:31] <pitti> fabbione: please check asac's bzr branch
[01:33] <fabbione> asac: where is your branch?
[01:33] <pitti> fabbione: http://bazaar.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x/
[01:35] <asac> fabbione: use the applet branch as well
[01:36] <asac> fabbione: https://code.launchpad.net/~ubuntu-core-dev/network-manager/gnome.ubuntu.0.6.x
[01:36] <fabbione> asac: do you have i386 packages anywhere?
[01:36] <asac> fabbione: orig is here: http://people.ubuntu.com/~asac/network-manager-applet_0.6.5.orig.tar.gz
[01:36] <asac> fabbione: no i only have amd64
[01:36] <asac> atm
[01:36] <fabbione> ok
[01:37] <seb128> pitti: any reason the base package stop shipping gdebi.mo
[01:38] <pitti> seb128: hm, no idea
[01:38] <fabbione> asac: do you know why Tonio did kill all these patches?
[01:38] <fabbione> (specially without a reason)
[01:39] <seb128> fabbione: he moved some patches to an another directory because he doesn't know n-m well enough to rewrite them and they didn't apply to the new code
[01:39] <seb128> fabbione: 
[01:39] <seb128> $ ls network-manager-0.6.5/debian/patches-non-applied
[01:39] <seb128> 19_interfaces_can_have_more_than_one_instance.patch          21_manual_means_always_online.diff
[01:39] <seb128> 20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch
[01:40] <cjwatson> pitti: CDs should be happier now if you rebuild them
[01:40] <fabbione> seb128: ok
[01:40] <fabbione> seb128: thanks
[01:40] <seb128> np
[01:40] <seb128> fabbione: he was supposed to ping you and Keybuk about them ...
[01:41] <asac> fabbione: yes i know
[01:41] <fabbione> seb128: he didn't.... but ok
[01:41] <asac> fabbione: he drops patches if the any hunk fails
[01:41] <fabbione> asac: building your branch... btw.. i don't really need the applet to test if it works. i just need to get NM to ignore my ipv6 interfaces
[01:41] <asac> fabbione: that patch should be back in
[01:42] <fabbione> asac: ok... but as core-dev that's not exactly the kind of behaviour i like to see because it introduces a lot of regressions between releases
[01:42] <asac> fabbione: for instance debian_backend patch ... the first hunk was applied upstream ... thus tonio dropped the complete patch without looking if the rest works
[01:42] <fabbione> asac: yeah it is.. i am building and testing..
[01:42] <fabbione> i need to reboot to complete the test
[01:42] <asac> ... and that lead to followup problems with other patches that diden't apply anymore
[01:42] <asac> so the card-house broke :)
[01:43] <cjwatson> asking for help when you get stuck is one of the behaviours we try to test for (and ask about) in core-dev applicants, so somebody should have a quiet word and remind him of it
[01:44] <cjwatson> of course everyone makes mistakes once in a while
[01:44] <asac> yes ... i think the mistake was really not to ask for help 
[01:44] <fabbione> yeps.... it's not a tragedy...
[01:44] <fabbione> brb.. testing
[01:47] <pitti> seb128: can you please file a tribe-3 bug about that? against language-pack-fr, and assign it to me?
[01:48] <seb128> pitti: sure
[01:48] <pitti> cjwatson: thanks, good timing; I wanted to trigger new ones after that publisher run
[01:49] <pitti> ogra: untouched> that works(-ish) with asac's branch again, but *not* with the version in the archive
[01:50] <ogra> pitti, well i havent tried it at all yet ...  i'll drop it from desktop and keep it in live i think if it makes probs ...
[01:50] <ogra> its still only tribe2 we're building here
[01:50] <pitti> ogra: what about that nbd bug? do you want to release tribe-2 at all?
[01:51] <ogra> we fixed it 
[01:51] <pitti> ah, cool
[01:51] <ogra> it turned out to be easier than i thought
[01:51] <ogra> upstream already took the patch :)
[01:51] <pitti> ogra: I'll build new images soonish; they won't be final yet, but I need them for verifying compiz stuff and sizes
[01:51] <pitti> ogra: and they should fix the debootstrap issue
[01:52] <ogra> pitti, i need them toi verify ltsp builds :)
[01:53] <ogra> the new mksquashfs stuff is still untested in d-i 
[01:53] <pitti> fine
[01:53] <ogra> and will be very unresponsive ... 
[01:54] <pitti> ?
[01:54] <ogra> pitti, the installer part doesnt tell you it runs mksquashfs ... and squashing up the chroot csn take 10 mins
[01:54] <ogra> *can
[01:54] <pitti> ah, ok
[01:55] <ogra> so it will look very odd to users
[01:58] <seb128> pitti: the english language pack has no gdebi neither, so it's not specific to the -fr languagepack
[01:58] <seb128> pitti: bug #122277 BTW
[01:58] <ubotu> Launchpad bug 122277 in language-pack-fr-base "gutsy language pack doesn't ship the gdebi translation" [Undecided,New]  https://launchpad.net/bugs/122277
[01:58] <pitti> seb128: right, probably a bug in langpack-o-matic, or it hasn't been part of the rosetta export; I'll have a look later
[01:58] <pitti> seb128: thanks; as long as it's milestoned and assigned to me, I'll get to it no matter what the source package is
[01:58] <seb128> k
[02:00] <EtienneG> pitti, re #120659, that's perfectly ok with me as I was just going to sit on it until fixed in upstream (hopefully next release)
[02:01] <EtienneG> so I do not mind at all
[02:01] <pitti> EtienneG: ok; I needed it quickly to kick out python2.4
[02:02] <sladen> afternoon in Europe, or evening in Asia?
[02:04] <Keybuk> oops, got a bit punchy with the shutdown dialog there
[02:04] <Keybuk> I only meant to logout the experimental user session I had
[02:05] <pitti> heh, so I'm not the only one who occasionally hits the wrong button :)
[02:05] <pitti> too many choices
[02:05] <Keybuk> not only that, but *should* shutdown work if there are other users still logged in?
[02:05] <ogra> the debian-gtk-gnome list is just discussing that :)
[02:09] <pitti> StevenK: http://people.ubuntu.com/~pitti/tmp/cruft/ updated
[02:09] <StevenK> pitti: Ah, thanks.
[02:10] <mpt> A simpler shutdown alert would have room for a warning about other people being logged in
[02:11] <StevenK> pitti: Ah, I like that page much better now that I've refreshed it. :-)
[02:11] <cjwatson> even leaving that aside, there should be room in the one that's there; at worst some icons might need to be shrunk
[02:11] <pitti> StevenK: heh
[02:13] <mpt> cjwatson, true, I misstated the problem
[02:14] <mpt> A simpler shutdown/restart alert would know that you were about to choose an option that would inconvenience other logged-in people
[02:14] <mpt> and therefore be able to warn you
[02:14] <asac> pitti: -granparadiso are still in queue?
[02:14] <pitti> asac: I newed it last night
[02:14] <mpt> as opposed to an alert that also contains actions like Lock and Log Out that are safe for other users
[02:14] <asac> pitti: they are still there :)
[02:14] <mpt> s/alert/dialog/
[02:14] <asac> pitti: https://launchpad.net/ubuntu/gutsy/+queue?start=20
[02:15] <pitti> asac: hm, weird
[02:15] <asac> i noticed because forum users complained ;)
[02:15] <pitti> accepted now
[02:16] <pitti> Hobbsee!
[02:16] <asac> pitti: thx
[02:18] <Hobbsee> pitti!
[02:18] <Hobbsee> hiya ajmitch 
[02:19] <dholbach> somebody please give back gconfmm2.6
[02:20] <pitti> dholbach: again?
[02:20] <pitti> dholbach: odne
[02:20] <pitti> done, too
[02:21] <dholbach> thanks pitti
[02:30] <fabbione> asac: your branch looks good here
[02:30] <pitti> fabbione: \o/
[02:30] <asac> cool :)
[02:31] <asac> fabbione: i hope that my backup finishes in 10 min so i can finally get a gutsy install on a real system :/
[02:31] <asac> why the hell do hard-disks always fill up with a ridiculous amount of data?
[02:32] <cjwatson> sigh, qemu in a chroot on an under-memoried machine over ssh X forwarding is not the fastest thing ever
[02:32] <asac> cjwatson: hehe :) ... i tried to build netbsd kernel once in qemu
[02:32] <asac> but gave up
[02:32] <fabbione> asac: stop the torrents :)
[02:34] <asac> fabbione: can you try if the applet works somehow as well?
[02:34] <asac> fabbione: what kind of network setup do you have btw?
[02:34] <fabbione> asac: one thing at a time
[02:34] <tfheen> asac: "complex" would probably be the first letter of describing fabbione's setup. :-P
[02:35] <fabbione> tfheen: ahahha no no
[02:35] <fabbione> asac: this machine is one and only one wired ethernet card.. dhcp ipv4 and static ipv6
[02:35] <fabbione> asac: problem is that nm doesn't know how to handle ipv6 at all
[02:36] <fabbione> asac: so it needs to ignore the interfaces with such setup, and that's what my patch does
[02:43] <pitti> mvo: http://cdimage.ubuntu.com/daily/current/ -> nice shot, fits precisely :)
[02:43] <pitti> mvo: can you give this a quick test wrt. compiz?
[02:43] <asac> tfheen: could you test nm?
[02:43] <StevenK> pitti: I think archive-cruft-checker is telling lies.
[02:43] <mvo> pitti: rsyncing
[02:43] <pitti> StevenK: is it?
[02:43] <fabbione> asac: ok.. i installed the applet package.. how do i kick the applet?
[02:44] <asac> kick? 
[02:44] <asac> restart?
[02:44] <StevenK> pitti: libk3b2 is listed in libflac++5, but I've uploaded a rebuild and the build logs show the package depending on libflac++6
[02:44] <StevenK> rmadison shows the right version in the archive.
[02:44] <pitti> hmm
[02:45] <pitti> StevenK: might not yet have been published
[02:45] <pitti> (at the time I ran it)
[02:45] <tfheen> asac: it seems to do the right thing here
[02:45] <StevenK> pitti: I don't think so, I uploaded it 2 days ago.
[02:45] <asac> tfheen: what stup?
[02:45] <asac> setup
[02:45] <pitti> hm
[02:45] <fabbione> asac: yeah whatever.. make it appear or what do you need me to check
[02:45] <asac> kilall nm-applet
[02:46] <asac> then start nm-applet --sm-disable 
[02:46] <StevenK> steven@infected:/srv/mirror/ubuntu/pool/main/k/k3b$ dpkg -I libk3b2_1.0.1-1ubuntu2_amd64.deb | grep Depends | cut -d, -f11-12
[02:46] <StevenK>  libflac++6, libflac8
[02:46] <StevenK> pitti: ^
[02:47] <pitti> StevenK: hm, then just ignore it for now; I'll investigate later
[02:47] <fabbione> asac: looks ok
[02:47] <StevenK> pitti: Aye, doing so.
[02:48] <asac> fabbione: thanks a lot
[02:48] <pitti> yay, vmware 6 native amd64
[02:48] <fabbione> no problem
[02:49] <StevenK> pitti: Same thing with audacity.
[02:50] <ogra> gah
[02:50] <ogra> 1M oversized ...
[02:50] <doko> pitti: would you be ok with gcc-4.X uploads to introduce lpia support and fix some libstdc++ locale regressions?
[02:50] <pitti> ogra: ? http://cdimage.ubuntu.com/edubuntu/daily/20070626/ seems fine?
[02:51] <ogra> 20070626.1 ?
[02:51] <ogra> :)
[02:51] <StevenK> ogra: Kill the ISO9660 lead-in? Like you need it anyway. :-P
[02:51] <ogra> heh
[02:51] <pitti> ogra: ah, right, sorry
[02:51] <pygi> StevenK, don't you touch ECMA standards :)
[02:51] <StevenK> pygi: :-P
[02:51] <ogra> StevenK, well, i personally use DVD-RW for testing so it doesnt really matter for me ... 
[02:51] <pitti> doko: hm, that'll take ages to build
[02:51] <ogra> but our users might care :)
[02:51] <StevenK> Heh
[02:52] <pitti> asac: so, did you hear anything bad about your branch? if not, then about *now* is the right time to upload them :)
[02:54] <TheMuso> Is documentation being put together about tribe 2 yet? If so, I would like to add a small accessibility/speech tidbit.
[02:55] <pitti> TheMuso: it's supposed to get on https://wiki.ubuntu.com/GutsyGibbon/Tribe2; Corey wanted to work on it, but hasn't yet
[02:55] <TheMuso> pitti: Ok.
[02:56] <TheMuso> I'll send him an email.
[02:56] <pitti> TheMuso: appreciated, cheers
[02:56] <asac> pitti: ok ... i will upload then :)
[02:57] <pitti> asac: please :)
[03:01] <StevenK> pitti: :-P
[03:01] <StevenK> Er, pygi 
[03:01] <StevenK> Sorry, pitti 
[03:01] <pitti> StevenK: I don't feel terribly annoyed when getting an erroneous smiley :)
[03:02] <StevenK> pitti: I didn't think so, but still. :-)
[03:02] <StevenK> FlacCodecPlugin.cpp:46: error: cannot allocate an object of abstract type 'FlacEncoder' because the following virtual functions are pure within 'FlacEncoder'
[03:02] <asac> pitti: network-manager pushed ... i wait a bit with applet as i tightened applet build-depends
[03:03] <pitti> asac: if b-deps are correct, please upload it now
[03:03] <asac> k
[03:03] <pitti> asac: or, rather, please upload it now and make sure the build deps are correct :)
[03:03] <Fujitsu> How would that be failing on just !i386?
[03:04] <asac> pitti: done ... build-deps should be ok now (e.g. network-manager-dev >= 0.6.5-0ubuntu3)
[03:05] <pitti> asac: I'll drive the publisher manually again to speed this up, I guess
[03:07] <mvo> holly cow, I got a noticiation from alsa that something changed and I need to refresh my presets on a terminal
[03:08] <mvo> that message is really cryptic
[03:08] <mvo> and why would I want to change my default sound card if I have only one?
[03:10] <thom> speaking of cryptic errors, apt has some really good ones
[03:11] <Keybuk> the best bit about apt's errors is that they're not pastable on IRC
[03:11] <Hobbsee> Keybuk: um, why not?
[03:11] <StevenK> mvo: Just in case you want to change it for a better one? :-)
[03:11] <Keybuk> Hobbsee: they begin "E:" or "W:"
[03:11] <thom> if you have dodgy nick expansion, no
[03:11] <thom> mvo__: hah
[03:12] <Hobbsee> Keybuk: ahhh
[03:12] <Keybuk> Hobbsee: so they become EtienneG: or Watersevenub: ... :p
[03:12] <Hobbsee> Keybuk: only if you have a crappy client :P
[03:12] <mvo__> lol
[03:12] <Hobbsee> xchat.  exactly.
[03:12] <StevenK> E: foo
[03:12] <StevenK> Ah ha
[03:12] <Watersevenub> Keybuk, hey! :-p
[03:12] <thom> W: Bizarre Error - File size is not what the server reported 3678 1839
[03:12] <Keybuk> Hobbsee: xchat requires you press tab, so it doesn't count for me :p
[03:12] <Hobbsee> irssi and konversation handle it correctly
[03:12] <evand> It makes me feel needed.
[03:12] <thom> is my current favourite
[03:13] <thom> _which_ file?
[03:13] <Keybuk> evand: careful, someone might give you more work to do :p
[03:13] <evand> haha
[03:13] <StevenK> thom: Heheh. You have to guess, which is part of the fun.
[03:13] <simira> Hobbsee: ++!
[03:13] <Keybuk> yay management
[03:13] <Hobbsee> Keybuk: having to press tab is a good thing
[03:13] <Hobbsee> hey simira!
[03:13] <Hobbsee> Keybuk: that works too :)
[03:13] <mvo__> thom: *cough* yes *cough*
[03:14] <simira> :)
[03:14] <thom> mind you, i know why i get lots of them from apt-transport-https now, so i might actually fix it soon
[03:15] <StevenK> thom: Neat non-HTTPS assumptions in the code?
[03:15] <thom> nah, seems like it's a missing callback
[03:25] <seb128> ogra: about bug #121447, is having "about ubuntu" on edubuntu really a problem?
[03:25] <ubotu> Launchpad bug 121447 in gnome-panel "Both About Ubuntu and About Edubuntu show up in menu" [Undecided,New]  https://launchpad.net/bugs/121447
[03:25] <ogra> seb128, well, it would be nice to have them with different icons 
[03:25] <seb128> ogra: I'm not sure than installing edubuntu-docs on Ubuntu should make "about ubuntu" be not listed
[03:25] <ogra> i'm fine with having them both, but they both show the edubuntu icon indeed
[03:26] <ogra> since they are hardcoded to use the distributor-icon
[03:26] <seb128> hum
[03:26] <seb128> we should change the about-ubuntu to always use an ubuntu icon then
[03:26] <seb128> and about-edubuntu to always use the edubuntu icon
[03:26] <ogra> probably
[03:26] <ogra> the would indeed need new icons
[03:26] <pitti> mvo: fuck, libgl1-mesa-dri isn't on the fresh Ubuntu live; apparently it missed one more publisher run to refresh germinate
[03:27] <ogra> or do we have the logo anywhere else ?
[03:27] <ogra> pitti, rebuilt the livefs ?
[03:27] <pitti> ogra: yeah, sure
[03:28] <seb128> ogra: we should add icons
[03:28] <pitti> mvo: the alternate has it, though, so testing that should be fine for now
[03:28] <ogra> seb128, yeah
[03:28] <ogra> lets look into that after tribe2
[03:28] <seb128> k
[03:29] <mvo> pitti: rsyncing
[03:31] <Hobbsee> mvo: how much is it actually pulling down when you're rsyncing?
[03:32] <Hobbsee> mvo: should it be ~600mb, from going to tribe 1 to current?
[03:32] <mvo> Hobbsee: its usually much smaller, even when feisty is used as the starting point
[03:32] <Hobbsee> rsync -zhhP rsync://cdimage.ubuntu.com/cdi                                                          mage/kubuntu/daily-live/current/gutsy-desktop-i386.iso kubuntu-gutsy-desktop-i38                                                          6.iso
[03:32] <Hobbsee> gutsy-desktop-i386.iso
[03:32] <Hobbsee>      249.65M  37%  103.07kB/s    1:10:07
[03:32] <pitti> Hobbsee: it was some 30 MB for me, since jigdo scanned /var/cache/apt/archives/ :)
[03:32] <Hobbsee> that looks odd.
[03:33] <pitti> Hobbsee: ah, -desktop
[03:33] <asac> pitti: both wait for approval
[03:33] <asac> pitti: according to mail
[03:33] <asac> pitti: nm ... received accepted
[03:33] <pitti> asac: I accepted them already, waiting for the publisher to finish, so that I can start another publisher run
[03:33] <Hobbsee> pitti: as in, rsync doesnt work for desktop?
[03:33] <pitti> Hobbsee: no, jigdo doesn't
[03:33] <Hobbsee> ahh
[03:33] <Hobbsee> right
[03:34] <StevenK> I wish there was a way to jigdo -desktop images.
[03:34] <pitti> StevenK: in theory you can, but since it is, by and large, one large file and a bit of plumbing, it doesn't make much sense
[03:35] <StevenK> Yes.
[03:35] <Hobbsee> rather, only parts of it
[03:36] <pitti> Hobbsee: no, that'll be rsynced
[03:36] <Hobbsee> good
[03:36] <Hobbsee> that's what i thought....but looking at this...
[03:37] <pitti> Hobbsee: might just be a part which changed heavily
[03:37] <Hobbsee> pitti: indeed.
[03:37] <Hobbsee> pitti: good thing it's the 26th, then
[03:37] <StevenK> That's a point.
[03:38] <StevenK> Hmph. Not even half way
[03:38] <Hobbsee> lucky you.
[03:40] <pitti> hi heno
[03:40] <heno> Hi pitti
[03:41] <pitti> heno: btw, the current set of images should at least boot and install; they are still missing a fixed network-manager and the lives are missing libgl1-mesa-dri, but for an initial test they should be good
[03:42] <heno> pitti: ok, I'll start posting Tribe-2 in the tracker and solicit testing help
[03:42] <Hobbsee> :)
[03:43] <pygi> o no, Hobbsee is back :P
[03:43] <Hobbsee> pygi: indeed.  cue lots of DOOM!!!!!!!!!11
[03:43] <pygi> Hobbsee, not on me :)
[03:43] <Hobbsee> i dont know about that...
[03:44] <pygi> you do
[03:44] <pygi> I don't think so
[03:45] <Hobbsee> pity
[03:45] <calc> Hobbsee: good luck with that, heh
[03:46] <Hobbsee> yes......
[03:46] <calc> Hobbsee: i want to do something similar with OOo but i think KDE has even more bugs than that
[03:46] <Hobbsee> calc: looks like you may not get your membership today, either
[03:46] <calc> Hobbsee: hmm?
[03:46] <Hobbsee> calc: with them taking so long
[03:46] <calc> Hobbsee: heh perhaps, serbia took > 30m
[03:47] <Hobbsee> calc: indeed.  i wish taht wasnt normal for CC meetings
[03:47] <calc> they should just +1 brazil already, heh
[03:48] <Hobbsee> i thought they were going to do Loco's elsewhere, so tehy didnt block the rest of the CC.  
[03:48] <Hobbsee> weird.
[03:49] <elkbuntu> Hobbsee, you note how we dont have jono's input on the irc council... similar reason i believe
[03:49] <cjwatson> pitti: you might be running into that bug where the task overrides don't get refreshed unless there's something to publish
[03:49] <cjwatson> (which we haven't fixed yet)
[03:49] <cjwatson> pitti: publishing some random universe package from the queue usually works around it, if you have one handy
[03:50] <Hobbsee> elkbuntu: ah great.  i love how one person can block absolutely everything.  for weeks.
[03:50] <StevenK> I think I uploaded one.
[03:50] <StevenK> Oh, I did, ufraw.
[03:50] <elkbuntu> Hobbsee, the problem is that he is only one person
[03:50] <pygi> calc, you going for member today?
[03:50] <elkbuntu> and planes dont have internet
[03:50] <Hobbsee> elkbuntu: this is true.  and travelling a lot
[03:50] <StevenK> pitti: ^
[03:51] <pitti> cjwatson: I'm currently publishing network-manager etc. anyway, so it should work
[03:51] <Hobbsee> pitti: i'm rsync-illiterate, it only downloaded 166.46M, at final count
[03:51] <pitti> cjwatson: it's the same trap I ran into before when trying to downsize the edubuntu images for tribe-1, I think
[03:52] <calc> pygi: if there is time in the meeting, yea
[03:55] <ogra> bah
[03:55] <pitti> cjwatson: I guess we'll move bug 120107 to tribe-3?
[03:55] <ubotu> Launchpad bug 120107 in debian-installer "[gutsy]  Ubuntu Live CD memory requirements need updating" [Low,Confirmed]  https://launchpad.net/bugs/120107
[03:55] <pitti> mvo: I move bug 121770 to tribe3, FYI
[03:55] <ubotu> Launchpad bug 121770 in apt "apt-source should ignore X-Vcs-Browser" [Low,Confirmed]  https://launchpad.net/bugs/121770
[03:55] <ScottK> keescook: Are you around and do you have a few minutes for a discussion about gnupg configuration?
[03:55] <ogra> then i noticed the display was just off 
[03:55] <ogra> sigh
[03:56] <pitti> mvo: in fact, I'll drop the milestone altogether, it's not really tied to release-criticalness
[03:56] <pitti> ogra: lol
[03:56] <keescook> ScottK: I'm here, but I'm not an gnupg expert; what's up?
[03:57] <cjwatson> pitti: unless you want me to do it now
[03:57] <mvo> pitti: ok
[03:57] <ScottK> keescook: OK.  I trying to find the right person to discuss the idea of having gnupg use gpg-agent by default.  It would clear up a bunch of trouble (along with other stuff I'm doing) with both PGP and S/MIME in kmail.
[03:57] <pitti> cjwatson: I'd rather have it later, I try to avoid any further uploads to the archive now
[03:57] <pitti> well, for things that affect CDs, that is
[03:57] <keescook> by default?  hmm.  I'm not sure if it's ready for that -- I had a ton of problems with it myself.
[03:57] <pitti> hi keescook
[03:58] <ScottK> keescook: Really.
[03:58] <keescook> ScottK: yeah, but it could be that I don't know what I'm doing.
[03:58] <keescook> ScottK: are there any ubuntu-specific docs about it?
[03:58] <ScottK> keescook: OK.  Well it's necessary for both S/MIME signing/encryption and PGP in kmail.
[03:58] <keescook> a good first step might be documenting how it all fits together
[03:59] <keescook> i.e. a wiki page with "here are the steps to make it work"
[03:59] <ScottK> Right
[03:59] <pitti> mvo: hmm, not good. standard amd64/alternate vmware install, and I cannot login; It quickly starts the session, then kills and restarts X
[03:59] <keescook> and from there, if it seems extensible, we can try to move to have it be the default configuration.
[03:59] <ScottK> Part of the Gutsy plan for KDE is to have S/MIME by default and I know it's needed for that.
[04:00] <cjwatson> pitti: ok
[04:00] <ScottK> I haven't figured a clean way to have gnupg use gpg-agent if and only if kmail is installed.
[04:00] <ScottK> keescook: Thanks.  I'll work on writing something up.
[04:00] <keescook> ScottK: cool!  I'm looking forward to it; I'd use it myself.  :)
[04:01] <mvo> pitti: I know, I'm currently debugging it
[04:01] <mvo> pitti: happens only in vmware it seems
[04:01] <pitti> mvo: checking for texture_from_bitmap: fail / then it tries again with indirect rendering, checks, and kills X
[04:01] <Fujitsu> Isn't S/MIME completely separate from OpenGPG?
[04:02] <Fujitsu> *OpenPGP
[04:02] <pitti> mvo: same on the live system
[04:02] <ScottK> Fujitsu: Technically, yes, but it's all managed by different bits of gnupg programs (gpgsm for S/MIME).
[04:02] <mvo> pitti: another oddity (at least on the live system) is that /proc/$foo/maps is not readable
[04:03] <pitti> mvo: that's deliberate on the new kernel
[04:03] <pitti> keescook: ^ right?
[04:03] <pitti> you need to ptrace a process before you can read maps
[04:03] <mvo> pitti: oh? that is bad for me(tm) as it seems to be the only reliable way test what driver X is currently using
[04:03] <keescook> mvo, pitti: maps is unreadable, yes.  ptrace, however, is not needed.
[04:04] <keescook> mvo: can you explain the situation?
[04:04] <pitti> mvo: ah, nice trick; I'm still looking for a way in restricted-manager to determine the currently running X driver
[04:04] <pitti> mvo: for manual checks you can look into /var/log/Xorg.0.log
[04:05] <keescook> mvo: basically "maps" is treated like "mem" now, but without the ptracing requirement
[04:05] <mvo> keescook: essentially there is a bug with vga, vesa driver that makes glxinfo kill the session when glxinfo is called (most likely on vmware driver too). so to work around this I check /proc/`pidof X`/maps 
[04:05] <mvo> if that no longer works, that would explain the breakage
[04:05] <mvo> pitti: yes, but that one is hard to parse :/
[04:05] <keescook> and the process doing that is not running as root?
[04:06] <mvo> keescook: yes, its the compiz wrapper script that run as the regular user
[04:06] <mjg59> mvo: I suspect we ought to fix those drivers :)
[04:06] <pitti> keescook: weird: -r--r--r-- 1 root root 0 2007-06-26 16:06 /proc/1/maps is world readable, but cat'ing it as user fails
[04:06] <keescook> mvo: hm, I wonder if we can work around this by having X spit out the needed info to a file in /var/run or similar?
[04:06] <mvo> mjg59: indeed
[04:07] <pitti> keescook: this new restriction should be reflected in the permissions (440)
[04:07] <keescook> pitti: correct; it's an in-kernel check.
[04:07] <pitti> current driver in var/run> yay, me too!
[04:07] <keescook> pitti: i cannot be reflected in the perms -- I had a very long discussion about this on lkml.
[04:07] <pitti> keescook: hm, if only the owner can read it, what's worse with 440 instead of the current 444?
[04:08] <keescook> to disable it system-wide,   echo "0" > /proc/sys/kernel/maps_protect
[04:08] <keescook> pitti: setuid programs won't be able to read their own maps file.
[04:08] <pitti> mvo: ah, so it's glxinfo that causes the X crash; makes sense then
[04:08] <pitti> mvo: I'll try with keescook's workaround
[04:09] <mvo> https://bugs.launchpad.net/xorg-server/+bug/119341
[04:09] <ubotu> Launchpad bug 119341 in xorg-server "glxinfo command causes Xorg to abort on Dimension E520" [Unknown,Confirmed]  
[04:09] <keescook> the setting is coming from procps (/etc/sysctl.conf)
[04:09] <mvo> there seems to be multiple reports about the breakage
[04:10] <mvo> pitti: vmware (the driver) is not yet blacklisted so just enabling maps again may not help
[04:10] <heno> [04:10] <mvo> keescook: what is the thing that needs to be protected? the exact memory location? if so, could we get a mode where we see what is mapped but not where?
[04:10] <mjg59> Hm.
[04:10] <mjg59> Ok, it segfaults rather than aborting
[04:11] <pitti> mvo: yes, the idea is to hide the addresses, to avoid circumventing address randomization
[04:11] <pitti> mvo: merely showing the loaded libraries is fine AFAICS
[04:11] <pitti> keescook: ^ do you agree?
[04:11] <keescook> mvo: this was also discussed, it's also considered a privacy leak (i.e. I can see what files someone else has mapped, not just libraries)
[04:11] <pitti> mvo: not something we could fix for tribe-2, though :/
[04:12] <mjg59> mvo: Does running /any/ GL app cause the crash, or is it just glxinfo?
[04:12] <keescook> pitti: generally, yes, but since mmap'd files are not easily distinguishable from mmap'd libraries, there's no good way to handle it.
[04:12] <keescook> there were people on lkml who actually wanted the reverse too
[04:12] <mvo> mjg59: not sure, I can check that, but I need to change my x-session for this
[04:12] <keescook> i.e. don't show file names, just show mappings.
[04:12] <mjg59> mvo: It'd be a good sanity check
[04:13] <pitti> mvo: indeed, that didn't help
[04:13] <pitti> mvo: is the blacklist somewhere in ASCII, where I could add vmware in-place?
[04:15] <pitti> mvo: ah, so if I s/vmware/vesa/ in xorg.conf and disable maps protection it works
[04:16] <pitti> seb128, mvo: the session splash screen stays around forever for me; did you see that already?
[04:16] <mvo> pitti, keescook: what kernel upload enabled maps protection?
[04:17] <seb128> pitti: only when using compiz?
[04:17] <keescook> mvo: the very first 2.6.22
[04:17] <seb128> pitti: does clicking on it make it go away?
[04:17] <keescook> well, that one contained it, but the procps upload enabled it
[04:17] <pitti> seb128: yes
[04:17] <keescook> mvo: 10 May 2007  procps (1:3.2.7-3ubuntu3) gutsy
[04:17] <bryce> hi
[04:18] <seb128> that's usually due to software not registering correctly
[04:18] <seb128> it goes away after a minute or so, there is a timeout
[04:18] <pitti> hm, and the shutdown menu doesn't appear when I use the menu entry
[04:18] <pitti> hey bryce
[04:19] <keescook> bryce: do you know of a reliable way to detect the current X.org driver without reading the /proc/$(pidof X)/maps file or the logs?
[04:19] <seb128> pitti: usually same reason, session management waiting on a buggy app
[04:19] <pitti> seb128: do you get that, too? (I just did a normal alternate vmware install)
[04:19] <seb128> no
[04:19] <seb128> and we got no recent bug about it
[04:19] <pitti> hm, I'll boot the live CD on my real hw to test this
[04:19] <seb128> might also been due to lo not correctly configured
[04:20] <bryce> keescook: I talked with the xorg folks about that, and unfortunately no, the only ways are maps / smaps, or reading the xorg log
[04:20] <keescook> mvo: sorry about the breakage.  :(  I tried to get the maps change in as early as possible in gutsy.
[04:20] <pitti> seb128: lo is fine
[04:21] <ogra> pitti, seb128 we have these lo probs often ... shouldnt we just hardcode it anywhere ?
[04:21] <ulaas> does gutsy have issues with network manager?
[04:21] <pitti> ulaas: lots
[04:21] <keescook> bryce: okay.  Sounds like we'll need some kind of X wrapper to spit out the needed info then.
[04:21] <pitti> ogra: but that wasn't it this time
[04:21] <ulaas> pitti, cool
[04:21] <pitti> ulaas: cool, rather
[04:21] <ogra> pitti, well *this time* :)
[04:22] <bryce> keescook: can you explain the issue?  skimming the backlog sounds like something about the kernel randomizing the maps now?
[04:22] <ulaas> pitti, knowing that its not me is cool
[04:22] <seb128> ogra: what do you want to hardcode?
[04:22] <ogra> seb128, lo creation and setup
[04:22] <seb128> ah
[04:22] <ogra> i have seen users taht deleted /e/n/i because they thought it wouldnt be needed with NM
[04:22] <ogra> for example ...
[04:23] <ogra> so just hardcoiding it would be a safer way imho 
[04:23] <keescook> bryce: the issue is that mvo's compiz wrapper needs to know which driver is being used by X so it can know if it's on the blacklist or not.  it was using /proc/$(pidof X)/maps to find this info, but with recent privacy/security changes maps files from other user's processes are not readable.
[04:23] <ogra> we need it anyway all the time
[04:23] <keescook> bryce: since compiz is running as a regular user, and X is running as root, the maps file is not readable.
[04:24] <keescook> besides totally disabling maps protection system-wide, I was suggesting that some root-running tool tied to X should spit out the driver it is using to some file in /var/run or a similar location.
[04:24] <pitti> mvo, bryce: would grep -q /usr/lib/xorg/modules/drivers/${BLACKLISTED_DRIVER}_drv /var/log/Xorg.0.log be an acceptable workaround for tribe-2?
[04:25] <iwj> Phew, IBM have agreed my laptop (which broke at Debconf) is under warranty and they'll fix it.
[04:25] <pitti> mvo: or simply parsing it out of xorg.conf?
[04:25] <iwj> But I have to hurry and send it to them so as to have it at the sprint.
[04:26] <bryce> I like the idea of some root-level tool generating the driver list
[04:26] <pitti> mvo: i. e. egrep -q "Driver[[:space:] ] *\"${BLACKLISTED_DRIVER}\"" /etc/X11/xorg.conf ?
[04:26] <mvo> pitti: there may be a alternative xorg.conf in use (also that coudl be figured out with xsset )
[04:26] <bryce> btw, this driver info is also going to be needed for bulletproof-x and maybe other things
[04:27] <Hobbsee> morning bryce 
[04:27] <bryce> hi Hobbsee
[04:27] <pitti> mvo: hm, but parsing the log? it doesn't need to be a 100% accurate for tribe-2, I guess
[04:27] <dholbach> could somebody give back gparted and inkscape please?
[04:27] <keescook> grep -q /usr/lib/xorg/modules/drivers/+${BLACKLISTED_DRIVER}_drv /var/log/Xorg.0.log
[04:27] <Hobbsee> bryce: fixed packages are at www.wedontsleep.org/~sarah/mesa, btw
[04:28] <pitti> dholbach: yes
[04:28] <bryce> Hobbsee: ah thanks
[04:28] <dholbach> thanks pitti
[04:28] <keescook> there are extra /'s in my log, for some reason: (II) Loading /usr/lib/xorg/modules/drivers//nv_drv.so
[04:28] <johanbr> What about X servers not on display 0 ?
[04:28] <pitti> dholbach: done
[04:29] <pitti> johanbr: that falls under the 'not 100% accurate' clause, I think
[04:29] <Hobbsee> bryce: dunno what you built with, but a rebuild fixed the mesa-utils, and libgl stuff
[04:29] <bryce> it would be ideal if the solution did not require use of Xorg.0.log since for bulletproof-x we want to know the driver *before* xorg starts up
[04:29] <pitti> eventually something like an easy xset call is necessary which gets the driver from the X it runs under
[04:29] <bryce> Hobbsee: I used pbuilder; what did you use?
[04:30] <mvo> I will prepare something that does not rely on maps and see how well that goes
[04:30] <Hobbsee> bryce: pbuilder.
[04:30] <Hobbsee> bryce: but yours came up with weird shlibdeps.  *shrugs*
[04:30] <Hobbsee> bryce: added the conflict too, so it should be all installable - but i iddnt test the swx11* stuff
[04:33] <pitti>   233792 | S- | libcompizconfig      | 0.0+git20070626-0ubu | eight minutes
[04:33] <pitti> mvo: ^ do we want that?
[04:33] <bryce> Hobbsee: thanks, too bad it didn't make the tribe2 freeze.  I'll review and work on getting it uploaded
[04:33] <Hobbsee> bryce: well, i did consider shoving it...
[04:34] <pitti> mvo: the 'do not bind top-left edge to expo plugin' was something you cared about, right?
[04:34] <mvo> pitti: yes, it makes seb128 happy
[04:34] <seb128> pitti: it fixes compiz conflictings with the GNOME menu
[04:34] <StevenK> bryce: I'm worried about the mesa-utils shlibs your build showed. Do you mind trying to rebuild and seeing if the same broken shlibs are used?
[04:35] <pitti> asac: http://launchpadlibrarian.net/8198306/buildlog_ubuntu-gutsy-i386.network-manager_0.6.5-0ubuntu3_FAILEDTOBUILD.txt.gz
[04:36] <pitti> asac: seems it needs an iproute2 build dep; can you please fix that quickly?
[04:36] <bryce> StevenK: sure, what did you do to determine the shlibs were broken?
[04:37] <asac> pitti: yes
[04:37] <pitti> asac: hm, tonio already did that in -0ubuntu2, but he added iproute, not iproute2
[04:38] <pitti> asac: hm, weird; WTH?
[04:38] <StevenK> bryce: A dpkg -I of mesa-utils didn't correspond to any of the shlibs in debian/*.shlibs
[04:38] <StevenK> bryce: (dpkg -I is "print control information for specified .deb)
[04:39] <pitti> asac: that didn't happen at my local build
[04:39] <bryce> ok thanks
[04:39] <StevenK> bryce: dpkg-shlibdeps can slip up, but it's rare, so I'm quite curious.
[04:40] <pitti> asac: it checks for /sbin/ip
[04:40] <pitti> asac: which is in iproute *boggle*
[04:41] <asac> yeah ... i have added iproute
[04:42] <pitti> asac: the build log doesn't mention installing it
[04:42] <ogra> cjwatson, ah, that base install looks a lot more familiar :)
[04:42] <pitti> asac: hm, indeed 0.6.5-0ubuntu3 dropped it
[04:42] <pitti> asac: it seems it is in bzr, but not in the package
[04:42] <asac> pitti: its in bzr?
[04:42] <asac> no 
[04:42] <dholbach> also please give back libglademm2.4 libgnomecanvasmm2.6 hardware-monitor libgtksourceviewmm
[04:43] <cjwatson> ogra: good stuff
[04:43] <asac> pitti: i will upload now.
[04:43] <pitti> asac: ah, crap, it's only a binary depends, no b-dep
[04:43] <pitti> asac: please; thanks
[04:43] <asac> yeah ;)
[04:44] <pitti> asac: 50 seconds until next uploader run :)
[04:44] <asac> ok its up
[04:45] <asac> did it get this run?
[04:45] <evand> pitti: The version of ubiquity on the current CDs crashes due to bug #122141.  I've added a small workaround for the time being and released 1.5.4, which cjwatson will upload.
[04:45] <ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [High,Triaged]  https://launchpad.net/bugs/122141
[04:45] <asac> i have a phone conference in 15 min. so if there are problems i cannot fix it till about 1800 Europe/Berlin
[04:45] <asac> pitti: ^^^
[04:46] <asac> cool :)
[04:46] <pitti> evand: fine for me; can it be uploaded right now? I'm about to run the publisher
[04:47] <evand> cjwatson?
[04:48] <keescook> evand: is it online somewhere where someone else can sponsor it from?
[04:48] <cjwatson> give me a minute
[04:48] <mvo> pitti: whatever it is that kills the login in vmware, its not compiz releated it seems. I changed gconf and linked metacity to compiz and the login still fails 
[04:49] <cjwatson> it's in progress
[04:49] <pitti> mvo: weird
[04:49] <dholbach> also please give back libglademm2.4 libgnomecanvasmm2.6 hardware-monitor libgtksourceviewmm
[04:49] <mvo> indeed
[04:49] <pitti> mvo: disabling maps and changing driver to vesa worked
[04:49] <mvo> especially since I do not see it on real hardware
[04:49] <pitti> dholbach: yep
[04:49] <dholbach> thanks
[04:49] <ogra> mvo, remove the pieces from /etc/xdg/autostart one by one ;)
[04:49] <mvo> maybe its vmware driver releated (vmware X driver)
[04:50] <cjwatson> oh, whee, there's a bunch of other stuff in 1.5.4 that wasn't uploaded pre-freeze
[04:50] <cjwatson> pitti: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.4_source.changes <- your call
[04:51] <pitti> cjwatson: the bug fixes look good, have the .ui/.glade file moves been tested?
[04:51] <evand> yes
[04:52] <evand> well, I've tested it lightly
[04:52] <mvo> ogra: switching from vmware -> vesa in xorg fixed it
[04:52] <cjwatson> .glade is just source rearrangement, .ui actually affects the binaries
[04:52] <ogra> mvo, oh
[04:52] <cjwatson> oh, well, Mario's glade rearrangements affect the binaries of course
[04:52] <pitti> evand: i. e. someone actually ran an Ubuntu and Kubuntu install with it?
[04:52] <pygi> cjwatson, what about me? o.O
[04:53] <mvo> bryce: current X vmware driver seems to break under vmware. have you seen this too? happens on the current gutsy livecd for me
[04:53] <cjwatson> pygi: the other Mario
[04:53] <pygi> cjwatson, oki
[04:53] <bryce> mvo, I heard there were problems with the vmware mouse driver, but not the video driver
[04:54] <evand> pitti: I can run through the former really quick, to test all of 1.5.4.  But prior to now I've only tested the glade changes and crash fix.
[04:54] <pitti> evand: ok, so you think the glade changes themselves don't break?
[04:54] <evand> I'm certain of it
[04:55] <pitti> evand: we'll still have time to do another upload if we need (we are blocked on the compiz fixes anyway)
[04:55] <bryce> mvo, is there a bug in on it?  I'll take a look at it once I have a suitable vmware environment set up
[04:55] <pitti> evand: ok, so let's give this a try
[04:55] <pitti> cjwatson: please upload then
[04:55] <evand> pitti: ok, I'll continue testing just to be safe
[04:55] <pitti> evand: thanks, appreciated; it's easier to reupload ubiquity before building new live images
[04:56] <mvo> bryce: not yet, I can report one now
[04:56] <bryce> cool thanks
[04:57] <cjwatson> the partial fix for bug 95619 is pretty important to have in anyway
[04:57] <ubotu> Launchpad bug 95619 in ubiquity "Feisty-Beta installer: mountpoint change needs partition size change!" [Undecided,Confirmed]  https://launchpad.net/bugs/95619
[04:57] <cjwatson> sorry, I'd forgotten we hadn't uploaded that earlier
[04:59] <cjwatson> evand,pitti: uploaded
[04:59] <pitti> heno: xubuntu CDs are 26, not 26.1
[04:59] <pitti> dholbach: oh, btw, I gave back that bunch
[04:59] <pitti> cjwatson: cheers
[05:00] <heno> pitti: ok, will fix
[05:00] <dholbach> pitti: thanks a lot
[05:07] <wasabi> So... I remember some talk, years ago, about delivering diff's of .deb files.
[05:08] <wasabi> Instead of the full deb itself. Did that go anywhere?
[05:09] <ion_> I grabbed the bzr tree, intending to do something with it, but never got around to it. :-(
[05:10] <wasabi> Oddly enough a simple xdelta between two package versions seems to do pretty good.
[05:10] <persia> wasabi: There are works in progress, but nothing is complete yet.  http://sianka.free.fr/ is the most mature of which I am aware, but not necessarily the best.
[05:10] <robertj> wasabi: I think there was some experimental work done on a dpkg fork that support that and some alternate compression types at the dpkg level
[05:10] <wasabi> Wonder why such a construct can't be nothing more than a little apt patch.
[05:10] <wasabi> "oh, I have a package in /var/cache? And tehre's a diff from that to X, grab that, apply, continue as normal"
[05:10] <ion_> wasabi: IIRC it uses zsync. I could remember incorrectly, though.
[05:11] <ion_> wasabi: Perhaps zsync was actually used for both control.tar.gz and data.tar.gz separately, or something like that.
[05:11] <wasabi> Oh, apt-torrent is interesting too.
[05:12] <wasabi> I think a consistantly ordered .tar.gz seems to do a xdelta just fine.
[05:12] <wasabi> And since .ar is just a container, I don't see why xdelta isn't good enough.
[05:12] <ion_> I think mvo was developing the stuff i pulled from bzr.
[05:12] <wasabi> apt-torrent is really neat though. That's a completely different angle however.
[05:13] <pitti> I'll go offline for some minutes to test the current live CD on real HW; brb
[05:13] <wasabi> ahh, take that back, xdelta does suck.
[05:13] <persia> wasabi: It's partially an archive size issue - does one keep differences to the latest version, or for several previous versions?  Alternately, if can be an archive CPU issue, if differences are calculated at request time.
[05:14] <wasabi> Weird because I got great results on one 
[05:14] <wasabi> persia, how big is the full archive?
[05:15] <elmo> 174Gb
[05:15] <mvo> wasabi: zsync is working, try http://people.ubuntu.com/~mvo/bzr/apt-sync--mvo/ - but there is currently no archive hosting the .aptsync files
[05:15] <wasabi> 174GB is... nothing.
[05:15] <wasabi> I mean, it was, 5 years ago.
[05:15] <wasabi> But now a 500GB HD is $100.
[05:15] <elmo> that's silly
[05:16] <pygi> wasabi, yup, true
[05:16] <wasabi> I have 8 sitting right here. Want a few? haha
[05:16] <elmo> a 500GB HD for a server is not $100 and that doesn't take into account limitations like physical size, existing RAID setups, etc.
[05:16] <pygi> elkbuntu, right, SCSI stuff =)
[05:16] <ion_> persia: With zsync, the archives only need to have the latest versions of the packages.
[05:16] <wasabi> Hmm. I built my high storage raid out of SATA
[05:16] <wasabi> SCSI for performance. High storage out of SATA.
[05:16] <wasabi> Works great.
[05:16] <elmo> good for you - mirrors, rather sensibly, don't
[05:17] <wasabi> Drives die more, but they cost 4th as much.
[05:17] <elkbuntu> pygi, eh?
[05:17] <pygi> elkbuntu, ups, sorry :)
[05:17] <elmo> you're also assuming that these mirrors are only mirroring ubuntu, which 90% of the time, they're not
[05:17] <wasabi> That is true. You are considering the mirrors themselves.
[05:17] <wasabi> I forget the distribution network of mirrors that are involved. It's not just one server.
[05:17] <wasabi> And you don't own or control most of them.
[05:18] <elmo> we don't own 99.99% of them
[05:18] <elmo> and Ubuntu is entirely reliant on it's network of mirrors to get the software to it's users - not even Canonical could support the bandwidth required to support all Ubuntu users without mirrors
[05:19] <wasabi> Well, it'd be an interesting experiment, maybe to set up the diff infrastructure, get a server going, and see what the real conditions are.
[05:19] <persia> ion_: Nifty.  Thanks for the pointer.
[05:20] <wasabi> There's no doubt I alone am responsible for many gigs of needless transfer from the mirrso.
[05:20] <wasabi> Since I update gutsy daily.
[05:22] <ion_> Well, i dont consider it needless, since you probably report and fix bugs just like most of us who upgrade gutsy periodically.
[05:23] <wasabi> I mean in terms of actual changes I'm downloading.
[05:23] <ion_> (Or did you mean needless transfer as the amount of data transfered would be lot less if apt-sync were used?)
[05:24] <wasabi> It's not often more than a single line of code changed and an entry to changelog.
[05:24] <wasabi> And boom, 30MB firefox download.
[05:24] <ion_> Yeah
[05:24] <ion_> Indeed.
[05:25] <cjwatson> not to take away your hyperbole, but:
[05:25] <cjwatson> Package: firefox
[05:25] <cjwatson> Size: 10277218
[05:25] <cjwatson> I think a factor-3 overstatement is a bit much ;)
[05:26] <ion_> :-)
[05:27] <wasabi> firefox-dbg.
[05:27] <wasabi> Size: 49845600
[05:28] <wasabi> Probably my fault for having debug symbols, but still.
[05:28] <bryce> ok, this xorg tester needs to make sure he's ctrl-alt-bksp'ing on the right test machine.... doh
[05:28] <wasabi> I last updated two days ago. apt tells me I need to download 214MB of archives.
[05:28] <wasabi> Hmm. 4 days ago.
[05:28] <wasabi> Still. That's just me.
[05:29] <cjwatson> I think in some ways Ubuntu is more liable to this than Debian
[05:29] <cjwatson> because we work more across the distribution than package-at-a-time, you get more smaller uploads
[05:29] <wasabi> Yeah.
[05:29] <cjwatson> smaller as in fewer-changes
[05:29] <cjwatson> also due to tighter schedules and faster archive cycles
[05:30] <pitti> mvo: darn, the amd64 live just hangs for me when starting the desktop session
[05:31] <cjwatson> Hobbsee: hmm? that was an objective comment, no hatred implied
[05:31] <Hobbsee> cjwatson: no, not here, sorry.
[05:31] <cjwatson> ah
[05:31] <pitti> mvo: and I cannot tell why, switching consoles works, but I cannot run any command
[05:31] <Riddell> PriceChild: has anyone spoken to you about gizmod licencing?
[05:31] <mvo> pitti: could you please try to edit /usr/share/compizconfig/globals.xml and search for "expo" and disable the "autoenable" bit?
[05:31] <ion_> Hehe, Remove bigiron target, see if anyone complains
[05:31] <mvo> pitti: what do you see  ? only a colored background? or a desktop with icons etc?
[05:31] <pitti> mvo: when? on the live CD?
[05:32] <pitti> mvo: color background, white stripes where the panels will go, and a mouse pointer
[05:32] <wasabi> Has anybody actually taken a look and come up with any figure about how much actual real data changes in the distro on a weekly or other basis?
[05:32] <wasabi> If optimal diffs were in place, etc.
[05:33] <mvo> pitti: go to the console on the live-cd, edit the file and kill gdm and start it again. I wonder if that helps
[05:33] <pitti> mvo: well, but as I said, I cannot run any commands; they just hang
[05:34] <mvo> pitti: I have seen that here on my regular session too and I *think* its releated to the expo plugin
[05:34] <pitti> mvo: I probably need to be very quick or so
[05:34] <pitti> mvo: just for planning and having a fallback: what would we need to do to entirely disable compiz-by-default for tribe-2?
[05:34] <mvo> pitti: oh, yes. I had that before and was suspecting a bad burn :/
[05:35] <mvo> pitti: revert the last gnome-session upload should be enough
[05:35] <pitti> mvo: ok; I think we should do this tonight when everything else fails, so that we have testable CDs tomorrow
[05:36] <mvo> unfortunately we have quite a few problems currently
[05:37] <pitti> mvo: ok, I'll try to disable the expo plugin before it hangs X; bbl
[05:38] <seb128> pitti: you are the only one to have an hanging CD atm though, no?
[05:38] <pitti> mvo: ^ didn't you have that, too?
 pitti: oh, yes. I had that before and was suspecting a bad burn :/
[05:38] <mvo> yes, I had that
[05:38] <mvo> no commands
[05:38] <seb128> "had"
[05:38] <seb128> is it fixed now?
[05:38] <mvo> and I had a hang on login but commands worked fine
[05:38] <mvo> no
[05:38] <mvo> I suspected a bad burn
[05:39] <mvo> but no commands anymore sounds a bit like a kernel issue IMO
[05:39] <seb128> right
[05:40] <pitti> mvo: yeah, probably some 'X driver goes crazy blocks everything else'
[05:41] <zul> w/in 12
[05:41] <pitti> mvo: ok, trying; brb
[05:41] <ogra> yay, mksquashfs seems to work in d-i mode :)
[05:42] <ogra> even the percentage output looks horrible in the syslog output
[05:42] <ogra> pkl_, is there any way to quiten that ? ^^^^
[05:43] <pkl_> yes, add the -no-progress option to mksquashfs.
[05:43] <ogra> ah, cool, thanks 
[05:43] <ogra> i'll add that in the next ltsp upload
[05:44] <ogra> squashfs via nbd is a really cool thing :)
[05:45] <cjwatson> or process the progress output somehow into debconf progress commands
[05:45] <cjwatson> I don't know if there's a version of the output that's sufficiently machine-readable to allow that
[05:46] <pkl_> ogra: yes, I'm interested in what the performance is like over nbd.
[05:47] <ogra> a lot better than plain uncompressed nfs indeed
[05:47] <ogra> but i dotn have numbers yet
[05:48] <ogra> i'll make up some comparisons for the release notes for ltsp 
[05:48] <pkl_> ogra: nbd appears to be more reliable than Squashfs loopback mounted on an exported NFS filesystem.  I've noticed some issues where loopback appears to timeout getting backs off NFS.
[05:49] <pkl_> s/backs/blocks/
[05:49] <ogra> well, i cant tell, since we need a unionfs on top which just breaks over nfs
[05:50] <pkl_> even Squashfs loopback mounted on a file, which is in an NFS mounted filesystem?
[05:51] <ogra> hmm, never tried that
[05:51] <ion_> Hehe, i got ten separate sorry, foo closed unexpectedly reports for old crashes from apport. compiz, beryl, zsh-beta, xfce-terminal, firefox, f-spot and some others. :-)
[05:52] <pkl_> ogra:  I wouldn't, that's where I've read about the above issues.
[05:52] <ogra> sh
[05:52] <ogra> err
[05:52] <ogra> ah
[05:52] <ogra> well, i'm happy as it is now ... :) its the fastes ltsp ever :)
[05:53] <pkl_> ogra: do you use the readahead module in ltsp?
[05:54] <ogra> nope
[05:56] <wasabi> I seriously doubt I'm supposed to see this:
[05:56] <wasabi> New Advanced Linux Sound Architecture (ALSA) configuration presets have been added.  Please execute the asoundconf(1) set-default-card macro in a Terminal now to refresh your user's configuration presets.
[05:56] <cjwatson> mvo commented on that earlier too
[05:57] <wasabi> Doesn't somebody have to go out of their way to add messages to that?
[05:58] <pkl_> ogra: OK.  Just thinking about ways to reduce network latency on start-up.  The liveCD uses the readahead module, but it probably doesn't do much for network latency.
[05:58] <ogra> afaik the liveCD disables readahead
[05:58] <ion_> - user-must-execute-asoundconf-set-default-card.update-notifier: Add this update-notifier hook so that the user is informed that he/she needs to execute the asoundconf(1) set-default-card macro, because new ALSA configuration presets have been added (LP: #120691).
[05:59] <ion_> It would be nice if ubugtu reacted to that format, too. Please give the URL for bug #120691 for the lazy ones among us, thank you.
[05:59] <ubotu> Launchpad bug 120691 in alsa-lib "heaps of ALSA warnings in console" [Medium,Fix released]  https://launchpad.net/bugs/120691
[05:59] <ion_> Oh, it was ubotu. :-)
[06:00] <cjwatson> wasabi: if by "out of their way" you mean "run echo in a postinst", I suppose so
[06:01] <pitti> mvo: ok, the reason for the hang was simply that the live CD tried to start compiz for me
[06:01] <pkl_> ogra: hmm, really? I thought the readahead module was added to read the initial list of files off CD-ROM into page cache.  Maybe it is disabled due to RAM limits... 
[06:01] <pitti> mvo: after disabling the kernel maps protection, it worked; I got metacity and a working desktop
[06:01] <ogra> pkl_, i think we had kernel oopses with that in the past
[06:01] <pitti> mvo: that's fine, nv is known not to work with composite
[06:02] <mvo> pitti: ok, good to hear. I'm preparing a new compiz upload
[06:02] <pitti> seb128: live system detects 68 DPI for me, which is why fonts are so tiny
[06:02] <pitti> seb128: after I manually set it to 86, fonts looked fine again
[06:02] <mvo> pitti: can I get the output of glxinfo from a "nv" system on some pastebin please?
[06:02] <pitti> seb128: so DPI detection still seems to be broken at times
[06:02] <ogra> ogra@laptop:~/packages/casper-1.91$ grep readahead scripts/casper-bottom/25configure_init
[06:02] <mvo> pitti: and can you please accept my current gnome-session upload?
[06:02] <ogra> # Disable readahead since it doesn't play well with squashfs + unionfs
[06:02] <ogra> if [ -e /root/sbin/readahead-list ] ; then
[06:02] <ogra>     chmod -x /root/sbin/readahead-list
[06:02] <ogra> pkl_, ^^^^
[06:02] <pitti> mvo: I can, I need to restart X for that again; do you need nvidia as well?
[06:03] <pitti> mvo: what does it do?
[06:03] <mvo> pitti: for now only nv
[06:03] <mvo> pitti: it fixes the way compiz is called and unbreaks runing the session in vmware
[06:03] <pkl_> ogra: OK.  I was thinking about adding some readahead support in Squashfs.  This should work a lot better than the readhead module, and should also be good for ltsp.
[06:03] <pitti> ah, yay
[06:03] <cjwatson> wasabi: it's only hard if you're also using debconf (but even then echoing to stderr would do the job)
[06:03] <ogra> pitti, apart from oversizedness and 20min unresponsiveness the edubuntu i386 server CD installs fine
[06:04] <ogra> pkl_, sounds great :)
[06:05] <pitti> mvo: ok, accepted; I wait with the next publisher run until ubiquity and network-manager finished building (shouldn't take long)
[06:05] <pitti> ogra: cool
[06:05] <pkl_> ogra: Good :)  If/when I finish it (it's one of my TODO things, I'll ask you about doing some tests on ltsp....
[06:05] <mvo> pitti: I will most likely need at least one other upload to fix the compiz wrapper
[06:05] <pitti> seb128: so, it seems that bug 118745 is still an issue; do you get a similar effect on the live system?
[06:05] <ubotu> Launchpad bug 118745 in libgnome "default desktop/panel menu font sizes too small" [Medium,In progress]  https://launchpad.net/bugs/118745
[06:06] <pitti> mvo: yeah, for fixing the running driver detection?
[06:06] <pitti> mvo: what will you use, grepping the Xorg.0.log?
[06:06] <evand> pitti: tested ubiquity 1.5.4 installs for kubuntu and ubuntu, both worked.
[06:06] <ogra> pkl_, appreciated, thanks :)
[06:06] <wasabi> cjwatson, translations are not considered?
[06:06] <pkl_> ogra: np
[06:07] <pitti> evand: yay
[06:07] <mvo> pitti: yes, will grep the Xorg.$nr.log file
[06:09] <bryce> mvo, will you be doing greps foreach video driver?  The Xorg.0.log does not appear to specifically highlight "this is the video driver" apart from other drivers
[06:10] <cjwatson> wasabi: no
[06:10] <ogra> hmm
[06:10] <mvo> bryce: but it will not load e.g. vesa and radeon at the same time, right?
[06:10] <ogra> the NM applet looks weird here
[06:10] <ogra> its flashing
[06:10] <cjwatson> wasabi: not typically, anyway. One or two maintainer scripts might bother to use the gettext shell command but it's not been common practice. Maintainer scripts that need translated messages typically use debconf nowadays.
[06:11] <ogra> ah, if i click on manual configuration it suddenly does autoconfig ...
[06:11] <bryce> mvo, right
[06:12] <bryce> mvo, btw I wrote a perl script to parse the xorg.0.log to extract driver and other info.  I don't know if you care to do it in perl, but I'd be happy to share if so.
[06:13] <mvo> bryce: perl is not exactly my favorite language, but if you make it part of the xorg packages somehow (and if you also use "xset q" to find out what logfile is current used) and I will be a happy user of it
[06:13] <bryce> okie doke
[06:13] <pitti> bryce: would it be very hard to invent a new xset call that reads the current video driver directly from X?
[06:14] <pitti> bryce: especially with multiple running X servers it's a pain to figure out the corresponding log file etc.
[06:14] <bryce> pitti: it's on my todo list to look into, but I don't know at this point
[06:14] <pitti> bryce: right, I just mean, wouldn't this make more sense in the long term?
[06:15] <bryce> yes, the grep-driver-from-log approach seems very hackish to me.  But if we need something right now, and can't use maps, then it doesn't give many options
[06:15] <pitti> right, I fully agree about a quick tribe-2 solution
[06:15] <mvo> I think I have something that is good enough(tm) in the compiz wrapper script for now (hackish but ...)
[06:16] <pitti> mvo: erk, I launched the publisher 10 seconds ago :)
[06:16] <mvo> if someone could post a glxinfo output from the "nv" driver to a pastebin, that would be appreciated
[06:16] <mvo> pitti: no problem I have some other tasks on my list
[06:16] <mvo> like why the splash screen keeps staying on top etc
[06:16] <pitti> mvo: right, I'll do that now; we have 35 minutes now, no reason to upload earlier
[06:16] <bryce> pitti: I did this xlogparser script primarily for xorg testing purposes, so I can automate verification of drivers loaded, check their versions, etc.
[06:17] <mvo> bryce: is it available somewhere to look at?
[06:18] <ogra> oh crap
[06:18] <ogra> mksquashfs compresses the mounted CD inside teh chroot eeek ...
[06:18] <bryce> mvo, one sec
[06:19] <bryce> http://people.ubuntu.com/~bryce/scripts/xlogparse - note the docs aren't finished yet
[06:20] <mvo> bryce: thanks!
[06:20] <bryce> you run it like "xlogparse /var/log/Xorg.0.log [--modules|--driver|--summary] "
[06:21] <bryce> er, you run it like "xlogparse /var/log/Xorg.0.log [--modules|--drivers|--summary] "
[06:22] <ogra> mrrm ...
[06:23] <pitti> mvo: http://people.ubuntu.com/~pitti/tmp/
[06:23] <pitti> mvo: glxinfo.nvidia.txt and glxinfo.nv.txt  
[06:24] <pitti> seb128: so, I'm really unsure again about bug 118745; is a wrong DPI detection X' fault?
[06:24] <ubotu> Launchpad bug 118745 in libgnome "default desktop/panel menu font sizes too small" [Medium,In progress]  https://launchpad.net/bugs/118745
[06:24] <mvo> pitti: great, thanks!
[06:25] <pygi> cypherbios, poke
[06:25] <cypherbios> hi pygi
[06:26] <pygi> cypherbios, I see you haven't updated your site for 0.2 yet :)
[06:26] <pygi> (the sf one ^_^)
[06:26] <pygi> cypherbios, but I rather wanted to talk about the way how you record packages to cd/dvd
[06:26] <cypherbios> pygi: It isn't released yet
[06:26] <cypherbios> pygi: sure. shoot
[06:27] <pygi> cypherbios, you use wodim/growisofs right now, true?
[06:27] <cypherbios> pygi: actually mkisofs/genisofs to create the iso image
[06:27] <cypherbios> *genisoimage
[06:27] <pygi> cypherbios, right, and what about burning?
[06:27] <pitti> kylem: what's the status of those two discover-data tribe-2 bugs?
[06:28] <kylem> ?
[06:28] <cypherbios> pygi: aptoncd dont burn the image, gust call the preferred application to do so
[06:28] <pitti> kylem: bug 119362 and bug 119370
[06:28] <ubotu> Launchpad bug 119362 in discover-data "Unknown Intel graphics controller on Intel D63578-200 motherboard" [Undecided,New]  https://launchpad.net/bugs/119362
[06:28] <ubotu> Launchpad bug 119370 in discover-data "Intel Xorg driver not detected when installing Gutsy Tribe-1 on an Intel GMCHB0ICHB0 motherboard" [Undecided,In progress]  https://launchpad.net/bugs/119370
[06:28] <pygi> cypherbios, ok, got it
[06:28] <kylem> sigh.
[06:28] <cypherbios> pygi: it checks the available applications and them offer the user a combo to choose what he wants to use
[06:28] <kylem> i need less to do.
[06:29] <pygi> cypherbios, would you be interested in replacing mkisofs/genisofs?
[06:29] <cypherbios> pygi: replacing by what?
[06:29] <pygi> cypherbios, by a library called libisofs
[06:29] <kylem> pitti, clearly i utterly failed at fixing this for tribe2. will upload today.
[06:29] <cypherbios> pygi: I heard about.
[06:29] <pygi> cypherbios, we would have to write bindings ... but there are a lot of benefits in the long term
[06:30] <pitti> kylem: if they aren't crucial for some customer or important machines, then 'move off to tribe-3' is a valid answer :)
[06:30] <kylem> yeah. that's fine.
[06:30] <kylem> neither appear targetted at tribe2.
[06:30] <pitti> kylem: I didn't milestone them, so someone must have had a reason
[06:30] <cypherbios> pygi: benefits like what?
[06:31] <pitti> the are
[06:31] <pitti> Keybuk: s/the/they/
[06:31] <kylem> whoever has a reason can hire me a minion. :)
[06:31] <pygi> cypherbios, like active upstream and support, proper  handling of errors and such? ^_^
[06:31] <pitti> kylem: ok, so tribe3?
[06:32] <cypherbios> pygi: sounds like a good reason :)
[06:32] <kylem> pitti, yeah.
[06:32] <kylem> no sense delaying the tribe cd over it when they'll be another in 3 weeks.
[06:32] <pygi> cypherbios, ^^
[06:32] <cypherbios> pygi: does it has python bindings ?
[06:32] <pygi> cypherbios, nop, not yet
[06:33] <pitti> asac: are you the official n-m bitch^Wmaintainer now? do you think you can take on bug 90267? or rather not?
[06:33] <ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
[06:33] <cypherbios> pygi: mkisofs works fine, I dont have any problems with it. But if you are telling me libisofs would work better...
[06:33] <pygi> cypherbios, we'd have to work on those
[06:33] <pitti> asac: I milestone this for tribe-3; this is one of the n-m bugs that suck and break most and should be relatively easy to fix
[06:34] <pygi> cypherbios, right, I believe for operations you need it, it works fine
[06:34] <asac> pitti: i am still a student for nm ... but yes :/
[06:34] <pitti> asac: well, let's look into it together after tribe-2, shall we?
[06:35] <pitti> asac: maybe two n-m amateurs can do something about it :)
[06:35] <asac> pitti: sure ... would be a pleasure
[06:35] <asac> pitti: your comment sounds professional though :)
[06:35] <cypherbios> pygi: command = ['mkisofs','-iso-level', '4' ,'-pad', '-l','-r', '-J', '-joliet-long', '-v', '-V', 'APTonCD', '-hide-rr-moved', '-o', finalDestiny.replace(' ','\ '),  destination.replace(' ','\ ')] 
[06:35] <asac> pitti: like you know exactly where to hook this in :)
[06:36] <pitti> asac: well, I have an idea *what* do do, but not yet *where*
[06:36] <pygi> cypherbios, right :)
[06:36] <cypherbios> pygi: if libisofs is capable to do it and give me back the progress (%) is enough
[06:36] <pitti> asac: right now, n-m starts off with shutting down everything and initializing all devices to 'down'
[06:36] <pitti> asac: we have to make it use ifconfig (or an ioctl) to check whether an interface is up, and initialize its internal world model accordingly
[06:36] <pygi> cypherbios, it should be able, but we'd have to check ofcourse
[06:36] <asac> pitti: have you verified this in code?
[06:36] <asac> pitti: or is it just something someone told you?
[06:37] <asac> (at uds)
[06:37] <pitti> asac: not in the code, but that's its obvious behaviour
[06:37] <pygi> cypherbios, but hey, don't listen to me. If you really think this works, I'm fine with you using it.
[06:37] <pitti> asac: hm, wasn't it me who proposed that? :)
[06:37] <asac> pitti: no idea ... i have not been in the bof :)
[06:38] <cypherbios> pygi: heheh, it's fine. actually we don't have reasons to do that, but if you want to test something I'd be glad to help you testing
[06:38] <asac> pitti: what kind of hardware setup do i need to test all stuff ... i assume at least two network cards and a wifi stick, right?
[06:38] <pitti> asac: an unencrypted and a wep/wpa network are very helpful, too
[06:38] <Riddell> doko: I'm afraid I need to reject simdmath since it has no licence file
[06:38] <pitti> asac: I have two eth (one dhcp, one static) and one unencrypted wifi here
[06:39] <pitti> asac: i. e. desktop with two eth, laptop with one eth and one wifi
[06:39] <cypherbios> pygi: you are behind brasero too, aren't you?
[06:39] <Burgundavia> asac: if you want to test the NM crasher bug, you need a wifi connection with WPA/WEP and use gnome-keyring
[06:39] <ScottK> Riddell: Would you have a moment to kick python-fam (1.1.1-2.1ubuntu1) out the door.  I just uploaded it for Gutsy.  Lack of it uploaded to Gutsy is currently blocking a Feisty SRU.
[06:40] <asac> Burgundavia: huh?
[06:40] <Riddell> ScottK: new source or binary?  in universe?
[06:40] <pygi> cypherbios, I want to: a)get python bindings b)get people use them c)test and exterminate possible bugs :)
[06:40] <pygi> cypherbios, kindof, but not really
[06:40] <Burgundavia> asac: there is an NM crasher bug that kind of makes it useless currently, as the applet dies if it contacts gnome-keyring
[06:40] <pygi> not a developer
[06:40] <ScottK> Riddell: New source in universe.
[06:40] <pygi> cypherbios, not a developer
[06:40] <cypherbios> pygi: but a packager?
[06:40] <asac> Burgundavia: version?
[06:40] <pygi> cypherbios, yup
[06:41] <cypherbios> pygi: :)
[06:41] <pygi> cypherbios, I did however help here and there in the past
[06:41] <pygi> past being like two years or so :P
[06:41] <Burgundavia> asac: 0.6.5-0ubuntu2 (the last version before yours just went up)
[06:41] <cypherbios> pygi: aptoncd offers the option to burn the iso using brasero (as well nautilus-cd-burner and k3b)
[06:41] <pygi> cypherbios, libburnia is more important these days
[06:42] <asac> Burgundavia: ok is there a bug?
[06:42] <pygi> cypherbios, I have strong reasons to believe that genisoimage will completely stop it's development in the future (however there'll be a replacement, but developers will be advised to use libisofs)
[06:42] <Burgundavia> yep, just a sec
[06:42] <Riddell> ScottK: it's not in NEW, we already have python-fam in the archive
[06:43] <Burgundavia> asac: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/121605
[06:43] <ubotu> Launchpad bug 121605 in network-manager-applet "[gutsy]  segfault on joining secure network" [High,New]  
[06:43] <ScottK> Riddell: Right, but I got a waiting approval message I assume because the archive (Main) is frozen for Tribe 2.
[06:44] <doko> Riddell: please keep it in the queue
[06:44] <doko> pitti: gcc-4.1 and gcc-4.2 uploaded
[06:44] <asac> Burgundavia: can you get a reasonable backtrace?
[06:45] <pygi> cypherbios, alive? :)
[06:45] <Riddell> doko: what for?
[06:45] <asac> Burgundavia: ok ... maybe the one attached is good enough
[06:45] <cypherbios> pygi: sorry, was on the telephone
[06:46] <pitti> bdmurray, Burgundavia, asac: hm, are bug 121654, bug 121605 and bug 121228 in fact all duplicates?
[06:46] <ubotu> Launchpad bug 121654 in network-manager "[gutsy]  nm-applet core dumps" [Medium,Confirmed]  https://launchpad.net/bugs/121654
[06:46] <ubotu> Launchpad bug 121605 in network-manager-applet "[gutsy]  segfault on joining secure network" [High,New]  https://launchpad.net/bugs/121605
[06:46] <ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [Undecided,Confirmed]  https://launchpad.net/bugs/121228
[06:46] <cjwatson> heno: would you update https://wiki.ubuntu.com/ReleaseValidationProcess to match the current ISO test tracker, please?
[06:46] <cypherbios> pygi: mkisofs seems to be discontinued already
[06:46] <bdmurray> pitti: it seems possible
[06:46] <cypherbios> pygi: as it's just a link for genisoimage
[06:47] <heno> cjwatson: will do
[06:47] <bdmurray> bug 121228 didn't seem very "clean" to me
[06:47] <ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [Undecided,Confirmed]  https://launchpad.net/bugs/121228
[06:47] <pygi> cypherbios, mkisofs  is being developed, but not packaged anymore for debian distros (and most other)
[06:48] <pygi> cypherbios, but as I said (read again :P) I was telling you about genisoimage :)
[06:48] <Riddell> ScottK: done
[06:48] <pitti> bdmurray: 121654 and 121228 have the very same workaround and characteristics at least
[06:49] <Burgundavia> pitti: I would say so
[06:49] <cypherbios> pygi: does libisofs has a binary to create a iso image already?
[06:49] <asac> Burgundavia: are new packages already on archives?
[06:49] <asac> Burgundavia: if so please test if crash still exists
[06:49] <Burgundavia> asac: let me check
[06:49] <pygi> cypherbios, just a tiny little test one
[06:50] <Burgundavia> asac: not yet, afaics
[06:50] <ScottK> Riddell: Thank you.
[06:51] <pygi> cypherbios, well, I bugged too much already
[06:51] <pygi> sorry :)
[06:52] <cypherbios> pygi: what applications are using libisofs already?
[06:52] <cypherbios> pygi: not at all
[06:52] <pygi> cypherbios, just brasero and a I know of two that are being developed for some uni's 
[06:52] <Burgundavia> pitti: it looks like 121228 has a good detailed description of the problem. I will mark stuff dupicate of that bug, if that works for you
[06:52] <pitti> Burgundavia: it does, I'm already at it
[06:53] <asac> Burgundavia: result=GNOME_KEYRING_RESULT_OK, found_list=0x0
[06:53] <asac> --> crash
[06:53] <asac> hmmm gnome keyring bug?
[06:53] <Burgundavia> looks like it
[06:53] <Burgundavia> 121228 reporter was using vanilla nm
[06:53] <asac> or completely trashed process
[06:54] <asac> bug 121228
[06:54] <ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Confirmed]  https://launchpad.net/bugs/121228
[06:54] <pitti> Burgundavia: done
[06:55] <asac> pitti: for me it looks like a gnome keyring bug
[06:55] <asac> i mean it returns result OK ... but found_list = 0x0
[06:55] <pitti> asac: well, but the attached patch with checking for NULL makes sense to me
[06:55] <asac> why? ... i mean why RESULT_OK + found_list == 0x0
[06:55] <pitti> asac: still a bug, of course
[06:55] <asac> its a cure for the crash, but this should never happen
[06:56] <pitti> asac: just defensiveness
[06:56] <asac> hmmm ... better add an assertion then
[06:56] <pygi> cypherbios, tbh I'd also wonder who was this guy, what he wants out of me ... and why does he want me to do a lot of work (i.e. writing bindings, testing, etc), using experimental tech and such stuff when this works just fine
[06:56] <pygi> cypherbios, so I understand where you're coming from :P
[06:56] <pitti> asac: can you please add a gnome-keyring task then?
[06:56] <asac> yes ... we should get a trace that has symbolized gnome-keyring as well
[06:57] <asac> maybe nm already sends stupid stuff in :)
[06:57] <pitti> asac: heh, GIGO :)
[06:57] <pitti> asac: we have apport in tribe-2 now, so that might help
[06:57] <pygi> o no
[06:57] <pygi> :P
[06:57] <asac> pitti: then lets wait a till friday :)
[06:58] <asac> pitti: we should have plenty of crashes then
[06:58] <cypherbios> pygi: hehehe :)
[06:58] <pitti> asac: and hope for the best wrt. automatic dup detection :)
[06:58] <pitti> mvo: publisher is finished, so we can crank another run; what's the word in the compiz world?
[06:58] <asac> pitti: good test :) ... any idea how we can keep this bug report still the MASTER?
[06:59] <pitti> asac: hm, not without gross hacking
[06:59] <cypherbios> pygi: I'll not touch in something that is working fine, but if it would improve in some way we can consider to think about ;)
[06:59] <asac> maybe we can just upload a crash report from some dupe to it?
[06:59] <pitti> asac: TBH it seems easier to transfer the relevant information to the first apport than to attach core dump, packaging info etc. to the current but
[06:59] <pitti> s/t$/g/
[07:00] <pygi> cypherbios, it would surely help you in the future
[07:00] <pygi> so consider it an investment in the future
[07:00] <asac> pitti: hmm ... ok ... maybe Burgundavia can attach a crash report to that bug?
[07:00] <pitti> asac: you have to do manual attachments; LP currently doesn't allow us to augment an existing report with a blob
[07:00] <asac> ah ok
[07:00] <Burgundavia> asac: do I need a debug package of g-keyring?
[07:01] <asac> then ... lets wait and migrate the info
[07:01] <cypherbios> pygi: if libisofs has a python binding I probably would use it to replace mkisofs
[07:01] <asac> Burgundavia: if you want to provide a better backtrace, then yes
[07:01] <asac> install the dbgsym package
[07:01] <pitti> asac: so, of course you can attach CoreDump.gz, Dependencies.txt etc. manually and fix the description to contain the other fields, but that's harder I think
[07:01] <asac> pitti: agree.
[07:01] <Burgundavia> ok, just a sec
[07:01] <pitti> mvo: wb
[07:01] <asac> pitti: do you still provide dbgsym packages for public?
[07:01] <pygi> cypherbios, help me write those :)
[07:01] <pitti> asac: of course
[07:02] <pitti> mvo: publisher is finished, so we can crank another run; what's the word in the compiz world?
[07:02] <Burgundavia> pitti: are those still on your people.u.c page?
[07:03] <pitti> Burgundavia: yes, it hasn't ever changed
[07:03] <cypherbios> pygi: I'd really appreciate but I don't think I can. actually I don't have enough time even to do my own stuffs
[07:04] <alex-weej_> does anyone know if NATs have any way of communicating with local peers that the WAN connection is up?
[07:04] <pygi> cypherbios, aha :)
[07:05] <alex-weej_> NetworkManager's "online" notification is a little misleading in home NAT situations
[07:05] <pitti> BenC: you (likely) milestoned bug 119052 for tribe-2; shall it be postponed for tribe3? or is there an existing fix?
[07:05] <ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
[07:06] <Burgundavia> pitti: your dbgsym package for keyring is out of date
[07:06] <ScottK> alex-weej_: No, you really can't do that with NAT.  NM is telling you your box is on the network.  There really isn't much else it can do.
[07:06] <Burgundavia> asac: do you want me to wait for your latest package to hit the archives? I am still running the 0ubuntu2 stuff
[07:07] <BenC> pitti: yeah
[07:07] <pitti> Burgundavia: they should have been published by now
[07:07] <alex-weej_> ScottK: OK, in that case I think applications should be programmed with this in mind. Too many Ubuntu apps are throwing a wobbler when you're "online" but you're not "on the Internet".
[07:08] <pitti> BenC: 'yeah' for what? :)
[07:08] <asac> Burgundavia: they are already build ... should not take that long till they get distributed
[07:08] <Burgundavia> asac: just got them now
[07:08] <BenC> pitti: bug 119052 -> tribe-3
[07:08] <ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
[07:08] <pitti> BenC: 'k
[07:09] <pitti> BenC: https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=469 has three kernel bugs left; are any of them fixed in -7?
[07:12] <jdstrand> seb128: what do you think of the workaround patch for https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/27014 ?
[07:12] <ubotu> Launchpad bug 27014 in evolution "evolution bug, "Summary and folder mismatch, even after a sync"" [High,Confirmed]  
[07:13] <iwj> Hmm.  Is 1401563c85a6cf45a8464a1444e1b339 *gutsy-alternate-i386.iso  known not to work ?
[07:14] <pitti> iwj: which timestamp is that? does it abourt with a mount /proc bug?
[07:14] <iwj> Tue Jun 26 12:26:03 UTC 2007
[07:14] <asac> Burgundavia: still see it?
[07:14] <iwj> I don't think so.
[07:15] <iwj> I'm just trying again paying better attention.
[07:15] <pitti> iwj: hm, I installed the amd64 alternate, and it just failed to log into the session
[07:15] <pitti> iwj: what is it for you?
[07:15] <iwj> It got as far as letting me log in and then it presents that login progress screen.
[07:15] <iwj> After that disappears I just get a blank beige backdrop.
[07:16] <pitti> iwj: ah, that's again mvo's compiz magic; I *think* that's fixed with the new gnome-session
[07:17] <BenC> pitti: closed 2, deferred 1
[07:17] <mvo> iwj: that is real HW? or vmware?
[07:17] <pitti> BenC: that's a good ratio :) cheers
[07:18] <geser> BenC: Hi, any idea when bug #114855 will get fixed? I assume it won't make it for tribe-2.
[07:18] <ubotu> Launchpad bug 114855 in linux-ubuntu-modules-2.6.22 "prism54 and other wlan drivers missing in kernel 2.6.22" [High,In progress]  https://launchpad.net/bugs/114855
[07:19] <iwj> mvo: Real hardware.
[07:19] <mvo> iwj: could you please go to a console and strace compiz.real ?
[07:20] <iwj> SIGSEGV
[07:20] <iwj> (run as me from a normal tty session, with the X thing still hung)
[07:22] <pitti> asac: can you please have a quick look at bug 121439?
[07:22] <ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Confirmed]  https://launchpad.net/bugs/121439
[07:22] <Hobbsee> night all
[07:23] <keescook> pitti: whoops, sorry, I knee-jerk uploaded some fixes for apparmor -- it can be ignored until after the freeze
[07:23] <iwj> mvo: Yes, whatever I do it segfaults.
[07:23] <pitti> keescook: no problem at all, it's universe
[07:24] <pitti> keescook: also, it's never a problem to just upload stuff; I ignore the packages which don't look relevant
[07:24] <mvo> iwj: can you please strace the runing (hanging one)?
[07:24] <iwj> OIC
[07:25] <iwj> All this VC switching has made X go strange.
[07:26] <asac> pitti: its hard to say if this issue was caused by upstream upgrade or caused by dropp of patches. 
[07:26] <pitti> asac: ok, so tribe3/needsinfo/tryagainwithlatestversion?
[07:27] <asac> pitti: sure ... maybe its just gone
[07:27] <pitti> asac: it looks a bit hw specific, since it should work in general, right?
[07:27] <asac> pitti: for now we can just hope
[07:27] <enrico> Riddell: I made it with the porting!
[07:27] <enrico> Riddell: adept works without the old libtagcoll
[07:27] <pitti> asac: I'll test again with the latest packages on my ibook (open wifi as well here), whether it's generally broken
[07:27] <enrico> Riddell: apt-front uses libept for all the debtags things
[07:27] <enrico> Riddell: so it uses the new index
[07:27] <asac> pitti: thanks
[07:27] <enrico> Riddell: it's *done*!
[07:28] <enrico> Riddell: I'll now proceed to committing and uploading into Debina
[07:28] <asac> do you have ipw driver?
[07:28] <enrico> Debian, even
[07:28] <asac> pitti: ^^`
[07:28] <pitti> asac: no, bcm43xx
[07:28] <enrico> pitti: according to backlog, the above might be interesting for you as well
[07:29] <pitti> enrico: cool! so we'll merge/sync right after tribe2
[07:29] <iwj> mvo: futex(0xb7d8d120, FUTEX_WAIT, 2, NULL ...
[07:30] <mvo> iwj: could you please edit /usr/share/compizconfig/global.xml and go to "expo" and remove the "autoenabled" bit there? and see if that helps?
[07:31] <mvo> iwj: then please run "gconftool --recursive-unset /apps/compiz " and you will have to reboot after that 
[07:33] <mvo> pitti: new compiz uploaded, that should fix some more issues
[07:34] <pitti> mvo: are there any known ones left that we must fix?
[07:34] <iwj> mvo: deleted that autoenabled, killed the stuck compiz, C-A-B'd the X server, and logged in again and now it's fine.
[07:34] <ogra> pitti, i'll need one fix for ltsp (just testing taht one) and one -meta upload for edubuntu (to drop one langpack)
[07:34] <agoliveira> pitti: It starts X but freezes right after. I can't update becuse I was trying the live CD :)
[07:35] <iwj> mvo: That gconftool rune produces a hideous warning from GLib about g_thread_init not being called early enough.
[07:35] <mvo> pitti: nv detection was not good enough
[07:35] <pitti> agoliveira: ok, sounds pretty much like the bug mvo is about to fix
[07:35] <mvo> iwj: please reboot, just killing the xserver is not enough
[07:35] <iwj> Doing so.
[07:35] <mvo> and don't ask me why it is not, I have no idea
[07:35] <iwj> That is, I'm doing the things you told me to do in the order you told me to do them.
[07:36] <pitti> ogra: ok; publisher is still running ATM, so I'll wait some minutes to collect mvo's and your packages
[07:36] <ogra> pitti, i have to test that first
[07:36] <iwj> mvo: editing that file and restarting the X server was enough to make it WFM but I'm carrying on with your instructions.
[07:36] <mvo> agoliveira: could you please do the same? reboot and see if that behaviour persists? if it does, removing the expo plugin from the autoenable list, reboot and see if that fixes it?
[07:36] <ogra> pitti, its a bug with teh installer i'm waiting for it to finish, dont wait for me for that one
[07:36] <mvo> agoliveira: details are some lines back in the buffer for iwj
[07:37] <pitti> ogra: ok; right, it only affects the edubuntu CDs, it's not blocking the other ones
[07:37] <mvo> iwj: right, that is what I meant. killing the session and login in again seems to cure the problem regardless what is done
[07:37] <ogra> pitti, if you dropped ltsp it wont 
[07:37] <pitti> ogra: shall I do an edubuntu-meta upload for you? did you already change the seeds?
[07:37] <ogra> i didnt yet
[07:37] <pitti> ogra: I didn't drop ltsp; you told me it was important and shiny and such
[07:37] <ogra> i thought about dropping xhosa for now, that should give me the 1M i need
[07:37] <iwj> mvo: OIC
[07:38] <ogra> pitti, well, you dropped ldm, didnt you ? 
[07:38] <pitti> ogra: no, you asked me not to
[07:38] <pitti> ogra: Xhose gnome+kde+base is 670 kB
[07:38] <ogra> pitti, i said drop it for tribe2 and i'll sort the theme stuff until tribe3
[07:38] <pitti> ogra: we have the space now
[07:38] <ogra> ok
[07:39] <pitti> ogra: so dropping Xhosa might not be sufficient
[07:39] <ogra> well, but since you dont use the installer part for ltsp in ubuntu i dont think thats to critical 
[07:39] <mvo> iwj, agoliveira: I will do a quick dinner break now, but I will read scrollback
[07:39] <iwj> mvo: OK
[07:39] <iwj> mvo: Just logging in now ...
[07:40] <iwj> mvo: ... Seems to work.
[07:40] <mvo> iwj: ok, cool. thanks a lot for testing!
[07:41] <Burgundavia> pitti: regarding retracing
[07:42] <pitti> mvo: new git snapshot? did you review the changes?
[07:43] <Burgundavia> pitti: I don't seem to be able to get a coredump
[07:43] <Burgundavia> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/122364
[07:43] <ubotu> Launchpad bug 122364 in network-manager-applet "nm-applet crashed with SIGSEGV" [Undecided,New]  
[07:43] <pitti> Burgundavia: do you run kernel -7?
[07:43] <pitti> Burgundavia: -6 is broken with apport
[07:44] <Burgundavia> nope
[07:44] <asac> maybe the coredump has been embargoed?
[07:44] <Burgundavia> could be
[07:44] <pitti> asac: that's not possible with attachments
[07:45] <iwj> mvo: NP, thanks for fixing it for me :-).
[07:45] <asac> interesting ... Burgundavia you looked at the crash file right?
[07:45] <Burgundavia> I did
[07:45] <asac> there was a CoreDump: field, right?
[07:45] <Burgundavia> there is
[07:45] <iwj> Now I should report (a) the X server and (b) compiz.real SIGSEGV.
[07:45] <pitti> Burgundavia: Linux corey-laptop 2.6.22-6-generic
[07:46] <pitti> Burgundavia: please upgrade to kerenl 2.6.22-7 and try again
[07:46] <Burgundavia> ahh, right, ok
[07:46] <pitti> Burgundavia: you can reject this bug, it's pretty useless
[07:46] <asac> Burgundavia: reboot i reject :)
[07:46] <Burgundavia> just got to pull down the latest kernel
[07:46] <pitti> Burgundavia: it says 'CoreDump:' which means it is zero byte
[07:46] <agoliveira> mvo: I tried other times and the freezes is random tough it just appears after X starts. I'm checking the backlog while trying to boot in safe mode to see what happens.
[07:46] <pitti> Burgundavia: thanks, sorry for the trouble
[07:46] <Burgundavia> no worries
[07:47] <Burgundavia> now we hope NM doesn't spontaneously fail halfway through my download
[07:48] <seb128> jdstrand: I don't know the evolution code good enough to have an opinion
[07:48] <ogra> pitti, i'll drop Czech then :)
[07:48] <ogra> -cs seems to be big enough to gain soemthing
[07:48] <jdstrand> seb128: well, frankly neither do I, but all it does is comment out a line when evo starts up to keep it from getting mail on startup
[07:49] <ddaa> Hello
[07:49] <pitti> ogra: 4.82 MB
[07:49] <pitti> ogra: (gnome+kde)
[07:49] <ddaa> Can someone please triage https://bugs.launchpad.net/ubuntu/+source/neon26/+bug/96700
[07:49] <ogra> yeah
[07:49] <ubotu> Launchpad bug 96700 in neon26 "neon-config --la-file points to non-existent file" [Undecided,New]  
[07:49] <jdstrand> seb128: I have been using it for months with no problems, and have re-compiled evo for my users since then.  Works well.
[07:49] <ddaa> reported on March 27th and confirmed by two independent users since then.
[07:50] <jdstrand> seb128: it is not a fix-- but will be good enough for end users until upstream fixes it (won't be in the next release)
[07:50] <agoliveira> Gahhh... rebooting the live cd gives me a core dump.
[07:51] <jdstrand> seb128: it will of course get mail automatically after however many minutes the user specified, it just doesn't do it on startup.
[07:53] <geser> shawarma: pbuilder build-depends on rootstrap which isn't in Ubuntu.
[07:53] <pitti> asac: current n-m works good enough on my laptop (with the usual warts we have for ages)
[07:54] <shawarma> geser: hard b-d?
[07:54] <asac> pitti: good
[07:54] <shawarma> geser: Or conditional? (I'm to lazy to check)
[07:54] <shawarma> :p
[07:55] <pitti> asac: ok, I mangled bug 121439
[07:55] <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
[07:55] <geser> shawarma: only for i386 and amd64
[07:55] <shawarma> geser: Oh, those.
[07:56] <geser> shawarma: but i386 builds also all packages so there is no build of the last version
[07:56] <geser> shawarma: pbuilder-uml needs it
[07:56] <shawarma> geser: I wonder why... It sounds more like a runtime dep..
[07:57] <asac> pitti: thanks
[07:58] <jdstrand> seb128: I would propose it go into dapper-updates too-- maybe I am too close to the bug to have perspective, but it is extrememly annoying and many are turning away from evo, from what I can tell.
[07:58] <geser> shawarma: there are two bugs about it: bug #122340 and bug #106949
[07:58] <ubotu> Launchpad bug 122340 in pbuilder "[gutsy]  pbuilder (0.169ubuntu1) b-depends on virtual package rootstrap" [Undecided,New]  https://launchpad.net/bugs/122340
[07:58] <ubotu> Launchpad bug 106949 in pbuilder "pbuilder-uml (0.161ubuntu2) depends on rootstrap(>= 0.3.9-1) and user-mode-linux which are notr installable in feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/106949
[07:59] <jdstrand> seb128: the patch I attached in launchpad can be dropped into debian/patches on dapper (probably others too)
[08:00] <shawarma> geser: Hmm... I wonder why I didn't get a mail about it not building properly..
[08:00] <geser> it's in dep-wait
[08:00] <geser> you get no mail for dep-wait (even if it sits there for months)
[08:00] <shawarma> We're supposed to notice that on our own? Evil.
[08:01] <agoliveira> mvo: Just to update, rebooting does not do any good, it still freezes at random times, aways after X starts so it looks very much like what you told me before. Can't do anything on it tough as I'm running the live CD and, despite I'm able to switch to a console, any command I do just freezes.
[08:01] <pitti> keescook: btw, I just noticed that firefox forgot all but one of my stock replies again
[08:01] <keescook> pitti: I wish I could reproduce this!
[08:01] <pitti> agoliveira: there's something
[08:01] <shawarma> geser: I'll look into it soon-ish.
[08:01] <ogra> meh, why does my germinate break on -meta updates :/
[08:02] <geser> pitti: do you know if there is a notification if packages are sitting for a long time in dep-wait?
[08:02] <ogra> oh, its outdated
[08:02] <shawarma> pitti: Can we have rootstrap pulled in from Debian, please?
[08:02] <pitti> agoliveira: while the live CD boots, switch to VT2 and wait until you get a login; then execute 'sudo killall gdm' repeatedly until you actually kill it
[08:02] <keescook> pitti: is there anything special about your .mozilla directory or your firefox extensions?
[08:02] <pitti> geser: you should get an FTBFS mail, don't you?
[08:02] <keescook> pitti: neither bdmurray nor I have seen this :(
[08:02] <pitti> agoliveira: then you can modify your system and manually start gdm again with sudo /etc/init.d/gdm restart
[08:02] <geser> pitti: also for packages which are in dep-wait?
[08:03] <pitti> keescook: I have some other scripts, maybe they fight each other or so
[08:03] <pitti> geser: I'm not sure
[08:03] <agoliveira> pitti: Anything I try to esxecute just does nothing, the console just stops responding too.
[08:04] <pitti> agoliveira: right, but that only happens after gdm started up
[08:04] <shawarma> pitti: I expect it's on the sync blacklist because it depends on user-mode-linux which used to be in the blacklist as well..
[08:04] <pitti> agoliveira: that's why you have to immediately kill it
[08:04] <cjwatson> ogra: you need germinate 0.28 and you need to add 'required' to the seeds: line in update.cfg
[08:04] <agoliveira> pitti: Oh, ok. Got it. Let me try.
[08:04] <shawarma> Aw, heck.. Uml is in universe.
[08:04] <cjwatson> ogra: I can fix it up for you now if you like; I have another change to make anyway
[08:04] <pitti> shawarma: can you please mail me about it?
[08:04] <shawarma> pitti: Sure.
[08:04] <pitti> shawarma: sure, it would land in universe
[08:04] <ogra> cjwatson, yes please
[08:04] <geser> shawarma: you would need to get rootstrap in main as it is a b-d of pbuilder (main)
[08:04] <shawarma> pitti: Right, I just want it to fulfill a pbuilder b-d, but that's not going to fly..
[08:05] <shawarma> geser: Precisely. Hence my "aw, heck" :)
[08:05] <Burgundavia> pitti: alright got a core dump. Can I just cut it out of the crash report and attach it to 121228 and tag it for retracing?
[08:06] <pitti> Bur...
[08:06] <shawarma> *G*
[08:06] <pitti> Burgundavia: just file the bug as it is, it'll get autoretraced and everything
[08:07] <pitti> Burgundavia: cutting the core dump alone is not sufficient
[08:07] <Burgundavia> pitti: alright got a core dump. Can I just cut it out of the crash report and attach it to 121228 and tag it for retracing?
[08:07] <Burgundavia> pitti: or is there a way to tell apport to send a specific report?
[08:07] <Burgundavia> ok
[08:07] <Burgundavia> the apport auto thingy has not yet triggered, so I wondered if I could run it manually
[08:07] <pitti> Burgundavia: no, unfortunately Malone doesn't (yet?) allow us to send additional info to an existing bug
[08:07] <pitti> Burgundavia: oh, right, I need to enable it again, sorry
[08:08] <asac> 
[08:09] <Burgundavia> sorry, lost anything you said
[08:09] <asac> pitti: ok for single eth card dhcp network manager works
[08:09] <Burgundavia> bloody NM is dying on me now
 Burgundavia: no, unfortunately Malone doesn't (yet?) allow us to send additional info to an existing bug
 Burgundavia: oh, right, I need to enable it again, sorry
[08:10] <pitti> * pitti does
[08:10] <pitti> Burgundavia: ^
[08:10] <asac> however desktop effects prevents me from resizing any window :)
[08:10] <Burgundavia> pitti: ok
[08:10] <Burgundavia> pitti: can I just send you the crash file? are you able to deal with it?
[08:10] <pitti> Burgundavia: it's in a bug now?
[08:11] <pitti> Burgundavia: just tell me the number, I'll supervise the auto-retracer
[08:11] <Burgundavia> I can file a bug and attach the raw, unbroken out crash report
[08:11] <geser> shawarma: looks like you have only the option do disable the pbuilder-uml package so you can remove the rootstrap b-d
[08:11] <pitti> Burgundavia: no, please don't, they are a pain; why not just let apport file the crash?
[08:11] <asac> pitti: look bug 122350 ... it has been filed with -7 but still has not core
[08:11] <ubotu> Launchpad bug 122350 in firefox "firefox-bin crashed with SIGSEGV" [Undecided,Incomplete]  https://launchpad.net/bugs/122350
[08:14] <pitti> asac: hm, weird; it works again with -7 here on my two machines
[08:14] <ogra> gar gar gar
[08:15] <asac> pitti: interesting ... maybe his system is messy because apport hook data from firefox is missing as well.
[08:15] <agoliveira> pitti: Well, done what you said. I was able to start gdm and everything seens to be working but the installer. It crashes badly. I already sent the automated crash report. Perhaps you wanted anything else?
[08:16] <Burgundavia> pitti: ok, finally got apport to cooperate
[08:16] <pitti> agoliveira: oh, so you worked around the X hang (compiz bug)?
[08:16] <agoliveira> pitti: Yes, diasbling the expo plugin seens to do the trick.
[08:16] <pitti> agoliveira: installer is evand's area
[08:16] <pitti> mvo: <agoliveira> pitti: Yes, diasbling the expo plugin seens to do the trick. -> did you already fix that?
[08:17] <agoliveira> pitti: Ok, let me poke him ;)
[08:17] <pitti> agoliveira: hm, the currently pending compiz upload doesn't disable it, but it might be in a different package
[08:17] <pitti> agoliveira: I guess we have to wait until he gets back from dinner
[08:17] <Burgundavia> pitti, asac: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/122385
[08:17] <ubotu> Launchpad bug 122385 in network-manager-applet "nm-applet crashed with SIGSEGV in nmi_dbus_get_network_key_callback()" [Undecided,New]  
[08:17] <pitti> speaking of that, I could use some dinner, too; I skipped breakfast and lunch already
[08:18] <Amaranth> agoliveira: what was the problem?
[08:18] <agoliveira> pitti: Go for it.
[08:18] <Burgundavia> pitti: I have to run, can you make certain that is what you need?
[08:18] <Amaranth> expo is one of the major features we want compiz for :)
[08:18] <pitti> Burgundavia: retracer will get to it soon, I'll check it
[08:18] <Burgundavia> ok, rocking
[08:19] <agoliveira> Amaranth: I was testing Tribe 2 in my macbook. Expo freezes the live cd badly. After disabling it I was able to make it run nicelly except for the installing that's crashing all the way.
[08:19] <agoliveira> Right now I have it running and all the programs I tested - but installer - worked fine.
[08:20] <pitti> agoliveira: wrt installer
[08:20] <Amaranth> does the installer work if you disable compiz? :)
[08:20] <asac> Burgundavia: when you see retracer results, ping me please
[08:20] <pitti> agoliveira: can you please dist-upgrade ubiquity on the live CD and try again?
[08:20] <mvo> pitti: no, I wanted to be sure that this is actually the reason first I prepare a upload now
[08:20] <Burgundavia> asac: will the retracer email me?
[08:20] <Amaranth> Burgundavia: yes
[08:20] <pitti> Burgundavia: yes
[08:20] <asac> Burgundavia: should be a bugmail
[08:20] <Burgundavia> wow, so many people so sure :)
[08:21] <shawarma> geser: /Win 5
[08:21] <pitti> Burgundavia: retracer is grinding through a pretty large backlog
[08:21] <cjwatson> agoliveira: what pitti said; the most recent version fixes a commonly-occurring crash
[08:21] <Burgundavia> been using Ubuntu so long, I am not used to these new-fangled "au-to-mated" things
[08:21] <shawarma> geser: um.. no.
[08:21] <mvo> agoliveira: so after rebooting the expo plugin you managed to reboot/login a couple of times without hangs? 
[08:21] <Amaranth> mvo: should have my computer fixed in about a week, then i can go back to helping make compiz rock :)
[08:21] <pitti> mvo: reboot> bad on a live CD :)
[08:21] <mvo> pitti: good point .)
[08:22] <agoliveira> Amaranth: No, it does not work at all. I'll try to dist-upgrade as sugegsted.
[08:22] <pitti> mvo: I kept hammering 'sudo killall gdm' like mad on VT2 while booting, that works
[08:22] <Amaranth> pitti: why not just stop the gdm service?
[08:22] <pitti> Burgundavia: yay, it's getting to it
[08:22] <Amaranth> or does it freeze when X loads?
[08:22] <pitti> Amaranth: because it will start in the init sequence
[08:22] <Amaranth> if it does, i fail to see how anything in compiz is responsible :)
[08:22] <Amaranth> oh, right, auto-login
[08:23] <pitti> Amaranth: gdm is not the problem, but live system has autologin and thus autocompiz
[08:23] <agoliveira> agoliveira: No, I just did it once. Didn't enable the plugin again.
[08:23] <pitti> asac, Burgundavia: retrace is there
[08:23] <asac> pitti: bon appetit now
[08:23] <asac> pitti: hurry
[08:23] <asac> :)
[08:24] <Amaranth> apport's dupe checker doesn't seem to work very well with python
[08:24] <pitti> Amaranth: hm, I just saw one case where it worked
[08:24] <pitti> Amaranth: if it doesn't, plesae file a bug against apport
[08:24] <sladen> pitti: surely just letting all the autodetection fail and then capping the result between two bounds (eg. 96dpi and 200dpi) for sanity checking would do it
[08:24] <pitti> Amaranth: NB that it only works for bugs which have been filed *after* June 22(ish)
[08:24] <Burgundavia> asac: that what you need for a traceback?
[08:25] <Amaranth> pitti: well, bug 122311 is pretty obviously a dupe of bug 84060
[08:25] <ubotu> Launchpad bug 122311 in alacarte "alacarte crashed with AttributeError in __getPath()" [Undecided,New]  https://launchpad.net/bugs/122311
[08:25] <ubotu> Launchpad bug 84060 in alacarte "[apport]  alacarte crashed with AttributeError in __getPath()" [Low,Confirmed]  https://launchpad.net/bugs/84060
[08:25] <asac> Burgundavia: unfortunately it appears to be completely asynchronous ... so we don't see how network-manager invoked keyring
[08:25] <Amaranth> or do both bugs need to be newer than june 22?
[08:25] <pitti> Amaranth: 84060 was filed too early
[08:25] <pitti> Amaranth: right
[08:26] <pitti> Amaranth: the first new bug initializes the dup database, the next one will match then
[08:26] <Amaranth> lame, all alacarte bugs filed are going to be dupes of older bugs
[08:26] <Burgundavia> asac: ugh. I am going to be gone for a few hours, but if you want me to get a trace off anything else, fire me an email
[08:26] <pitti> Amaranth: I cannot search the entire Malone every time, I have to use a local db
[08:26] <asac> Burgundavia: can you merge this bug to the original bug please
[08:26] <Amaranth> you couldn't search entire malone once? :)
[08:26] <asac> Burgundavia: and drop hint that there is a retrace in the bug XXXX
[08:26] <Burgundavia> will do
[08:26] <Amaranth> i mean, to create your index
[08:26] <asac> Burgundavia: gratias
[08:27] <pitti> Amaranth: that would take ages
[08:27] <pitti> Amaranth: I can still do it, but I didn't yet
[08:27] <evand> agoliveira: let me know if dist-upgrading doesn't fix the installer crashing.
[08:28] <agoliveira> evand: actually a dist-upgrading just froze the machine :(
[08:28] <pitti> asac: we should keep bug 122385 unduped (will become the apport master bug for this) and just link it to #121228 with a comment; or transfer the useful info from 121288 to the new one; what do you prefer?
[08:28] <ubotu> Launchpad bug 122385 in network-manager-applet "nm-applet crashed with SIGSEGV in nmi_dbus_get_network_key_callback()" [Undecided,New]  https://launchpad.net/bugs/122385
[08:28] <evand> agoliveira: it should be suitible to just apt-get install ubiquity
[08:29] <pitti> evand: not ubiquity-frontend-gtk?
[08:29] <asac> pitti: right ... i will add that info for now
[08:29] <pitti> evand: wasn't it a fix in some GTK buttons, after all?
[08:29] <agoliveira> evand: Yeah, something like that just stroke me...
[08:29] <agoliveira> I'll start over.
[08:29] <Burgundavia> asac: done and I left a note on the other 4 sigsev nm bugs asking them if they are using g-keyring and wpa/wep to see if it is the same crash
[08:30] <evand> pitti: good point
[08:33] <thom> fnar, apt's source makes me cry
[08:34] <shawarma> ubiquity fails to start in my amd64 vmware on today's daily livecd.. Known issue?
[08:34] <pitti> shawarma: please try apt-get install ubiquity-frontend-gtk and try again
[08:35] <shawarma> pitti: Go to dinner!
[08:36] <cjwatson> pitti: 'apt-get install ubiquity' forces newer versions of everything; you don't want them getting out of sync anyway
[08:37] <shawarma> cjwatson: noted.
[08:37] <cjwatson> the virtual dependencies on ubiquity-frontend-1.5.4 etc. should mean picking any one of the binaries is equivalent, though
[08:38] <agoliveira> evand, pitti: Ok, if,  in sequence, I kill gdm after compiz kicks in, just upgrade ubiquity-frontend-gtk and start gdm, it works. I'll try to install now and may God have mercy on my soul ;)
[08:38] <agoliveira> s/after/before
[08:39] <evand> agoliveira: best of luck
[08:45] <mvo> agoliveira: do you still have the session with the hanging compiz? one of the upstream guys is interessted in the strace and I can currently not reproduce it for some reason
[08:47] <freepenguin> hello everybody
[08:47] <agoliveira> mvo: If I boot the live CD it hangs. Disabling expo plugin it works. I just can't install now because the manual partition hangs as well :-(
[08:47] <mvo> agoliveira: I see :/
[08:49] <robertj> shawarma: can you take a look at https://bugs.launchpad.net/ubuntu/+source/pam/+bug/116846 ?
[08:49] <ubotu> Launchpad bug 116846 in pam "patch to add directory inclusion for pam config file" [Undecided,New]  
[08:49] <seb128> jdstrand: not that many users get this bug, I didn't get it here in months (years?) of evolution use 
[08:50] <seb128> jdstrand: I'm not going to do a stable upload with a workaround, it's either a real fix or no change, if you can trigger the bug easily the best is to try to work with upstream which doesn't know how to trigger it
[08:50] <shawarma> robertj: I'm aware. I discussed it with pitti already. We decided to postpone it until we've had a wider discussion of it.
[08:51] <shawarma> robertj: The attendance of the bof at uds was.. not very impressive :)
[08:51] <robertj> later = post-gutsy?
[08:52] <jdstrand> seb128: I have submitted all this to upstream, and they claim to be working on a proper fix, but it won't be for a while (can't remember the url offhand).
[08:53] <seb128> jdstrand: I'm subscribed to the bug, I'm reading comments there
[08:53] <cjwatson> I talked briefly with vorlon at debconf about PAM maintenance
[08:53] <seb128> jdstrand: it's not easy for them to work on because they don't get the bug apparently and nobody determined what to do to trigger it
[08:53] <jdstrand> seb128: it happens with a lot of mail on a slowish drive (eg laptop)-- if the download of email completes before the indexes-- boom.
[08:53] <cjwatson> he basically said "I've got plenty of offers of help, but ultimately I need to sit down for a couple of days and go through both all the scary Debian patches and all the scary upstream changes"
[08:54] <evand> agoliveira: manual partitioning isn't working for you?
[08:54] <jdstrand> seb128: right. well, thought I'd go to you to see if you want to include it-- guess I'll keep my own evo packages for my users...
[08:54] <seb128> jdstrand: I would rather not use a workaround
[08:55] <robertj> cjwatson: so does the spec need to be retargeted?
[08:55] <jdstrand> seb128: I understand.  It actually was based on the default evo 1.4 behavior, which was how I found the workaround in the first place.
[08:56] <agoliveira> evand: No. It freezes when I select the partition I want to use as /
[08:56] <jdstrand> seb128: the patch is available for people to use if desired, so that's fine.  Seems odd so many of my users hit it though...
[08:57] <seb128> you might have something specific in your configs
[08:57] <seb128> my laptop disk is not that fast
[08:57] <seb128> and I never run into the problem with it I think
[08:58] <agoliveira> evand: BTW, it worked nicelly on Tribe 1.
[08:58] <jdstrand> seb128: I have a ton of filters-- maybe that's it.  shrug
[08:58] <jdstrand> seb128: http://www.go-evolution.org/Camel.Local is the link I was talking about with discussion of the real fix.
[08:59] <RainCT> Hi, is any REVU admin there?
[08:59] <jdstrand> seb128: could be mine and my users slowish connection.  agin, shrug
[08:59] <jdstrand> seb128: I am basically happy-- I can use the workaround, just thought I'd spread the love.  :)
[09:01] <cjwatson> robertj: I just meant PAM maintenance in general in terms of upgrading to current upstream
[09:01] <cjwatson> since people were asking about that
[09:01] <cjwatson> agoliveira: if you could start the installer with 'ubiquity --debug', reproduce the hang, and attach /var/log/syslog, /var/log/partman, and /var/log/installer/debug to a new bug report, that ought to help
[09:02] <agoliveira> cjwatson: Sure, I'll try.
[09:02] <robertj> cjwatson: ahh
[09:06] <agoliveira> cjwatson: Now it worked flawlessly. Go figure.. I'll try again from scratch.
[09:10] <cjwatson> agoliveira: heh, always the way
[09:16] <keescook> cjwatson: PAM> yeah, heard the same from vorlon.  Since I'm in no rush, I don't think it's a big deal.  it'd be nice if we get it in before gutsy freezes, though, just so we can work out any bugs prior to gutsy+1.
[09:16] <ogra> pitti, testing done: http://people.ubuntu.com/~ogra/19to20.debdiff (sorry for the .po and autoconf noise, cant avoid it on bzr export with that tree)
[09:17] <ogra> cjwatson, did you mean you wanted ot fix edubuntu-meta's update.cfg before ? or did i misunderstand ? 
[09:19] <shawarma> Slightly off topic: What is "VMWare paravirtual kernel support"?
[09:19] <shawarma> Do I want it?
[09:20] <agoliveira> cjwatson: believe or not, it just worked now (it's already copying the files) but I have a this crazy idea that it may be related to the crazy partition scheme I have in this HD because I have NTFS, AFS and EFI on it (macbook with tripple boot).
[09:21] <pitti> agoliveira: thanks for the (painful) testing; it seems that the next CD images should be good for you then :)
[09:21] <agoliveira> pitti: Glad to help. I just hope I have a usable notebook to take with me to the sprint in July ;)
[09:22] <pitti> ogra: please go ahead and upload ltsp
[09:22] <agoliveira> I'll finish the instalation to see if any more quirks show up.
[09:22] <ogra> pitti, oki
[09:23] <pitti> ogra: is the new edubuntu-meta ready as well? I don't see it in the queue 
[09:23] <pitti> ogra: I'd like to get mvo's and your two fixes into the queue now and run the publisher, then we can finally respin CDs
[09:23] <ogra> no, it doesnt work 
[09:23] <ogra> i added required to the update.cgf seeds line but it still fails
[09:24] <pitti> ogra: oh, ./update fails?
[09:24] <pitti> ogra: do you have the current germinate?
[09:24] <seb128> pitti: are standalone applications, ie: rhythmbox also frozen?
[09:24] <Riddell> enrico: you are a genius
[09:24] <ogra> yep
[09:24] <Riddell> enrico: many thanks
[09:24] <ogra> 0.28 as cjwatson said
[09:24] <pitti> seb128: everything is frozen by default; if there's an upload with innocent fixes, please ping me
[09:25] <pitti> seb128: rhythmbox            | 0.11.1-0ubuntu1      | 4 hours 50 minutes <= that one?
[09:25] <pitti> seb128: new upstream version, hmmmmmm
[09:25] <seb128> pitti: well, new rhythmbox should not break the worl has would be cool
[09:25] <seb128> world
[09:25] <seb128> but that's your call
[09:25] <seb128> yes, that one ;)
[09:25] <pitti> seb128: does it fix any OMGponies bug?
[09:26] <seb128> no
[09:26] <seb128> it fixes some regular bugs
[09:26] <pitti> we currently have so many troubles that I'd rather avoid introducing more 
[09:26] <pitti> seb128: let's postpone it then, people can still upgrade their tribe installation afterwards
[09:26] <seb128> k
[09:27] <pitti> seb128: I listened to RB the entire day, worked fine *evil grin*
[09:27] <seb128> I'm ready to close the "new version available" bugs we will get in the next bugs then :p
[09:27] <seb128> good ;)
[09:27] <pitti> ogra: what's the exact problem? I recently updated kubuntu and ubuntu seeds with the same change, worked fine
[09:27] <seb128> I like the new rhythmbox icons on gutsy ;)
[09:28] <pitti> indeed, me too
[09:28] <ogra> Traceback (most recent call last):
[09:28] <ogra>   File "/usr/bin/germinate-update-metapackage", line 209, in <module>
[09:28] <ogra>     list(seed_inherit[seed_name] ))
[09:28] <ogra>   File "/usr/lib/germinate/Germinate/germinator.py", line 443, in plantSeed
[09:28] <ogra>     if self.alreadySeeded(seedname, pkg):
[09:28] <ogra>   File "/usr/lib/germinate/Germinate/germinator.py", line 335, in alreadySeeded
[09:28] <ogra>     if (pkg in self.seed[seed]  or
[09:28] <ogra> KeyError: 'required'
[09:28] <pitti> ogra: ah, very same bug that we had with kubuntu and ubuntu
[09:28] <pitti> ogra: seeds: required minimal standard desktop
[09:29] <pitti> ogra: NB that 'required' has to come first
[09:29] <ogra> ah, k
[09:31] <mvo> pitti: testing the expo fix as we speak, should be ready in ~5-10min
[09:31] <pitti> mvo: so you have an actual fix now instead of disabling it? neat
[09:33] <mvo> pitti: I hope, works for me, but it was random before for me, so I can not gurantee anything (but even disabling expo would not have guranteed anything as it is just the most likely cause of the hang juding from the diff between 0622-0625)
[09:33] <mvo> its just very very hard to debug
[09:33] <pitti> mvo: iwj and agoliveira got it too, no?
[09:38] <agoliveira> pitti: I was able to finish the instalation but didn't try to enable compiz if this is what you're talking about.
[09:38] <pitti> agoliveira: (CC: mvo) I think the hang only occured if compiz tried to enable it self
[09:38] <mvo> pitti: compiz-fusion-plugins-main uploaded with the fix for the expo thing 
[09:38] <mvo> well, the 80-95% fix
[09:39] <mvo> lets hope for the best
[09:39] <pitti> mvo: what's the 20 to 5%?
[09:39] <mvo> pitti: that is the remaining uncertaintiy
[09:39] <pitti> mvo: ah, 'k
[09:39] <mvo> but I'm confident
[09:39] <mvo> :)
[09:39] <pitti> mvo: so, let's get new images out ASAP for more testing then
[09:40] <agoliveira> mvo: heisenberg principle? :)
[09:40] <mvo> agoliveira: heh :-D
[09:40] <mvo> pitti: yep
[09:41] <mvo> pitti: the new image should fix the nv issue you have seen as well 
[09:44] <pitti> -       es->expoMode = !es->expoMode;
[09:44] <pitti> +       es->expoMode = !es->expoMode;   
[09:44] <pitti> ah, the three trailing spaces :)
[09:45] <pitti> mvo: ok, the real diff looks unintelligible, but small enough, thanks
[09:45] <agoliveira> Hmmm... from time to time the icon "thingy" that shows the current LCD brightness pops. Did anyone see this?
[09:46] <pitti> ogra: better now?
[09:47] <ogra> yes, i'm just checking
[09:47] <okaratas> hello
[09:47] <ogra> i'm not sure all deps of compiz are fulfilled currently, might be that i'm oversized again
[09:48] <ogra> that merge wasnt in yet
[09:49] <ogra> pitti, uploaded, should hit the queue in a sec
[09:50] <pitti> ogra: ok, accepted; now I'll sort out the publisher problem with the soyuz guys, then we are in the game again
[09:50] <pitti> ogra: thanks
[09:52] <ogra> ok
[09:52] <ogra> the -meta upload wouldnt have been necessary for ship anyway iirc
[09:52] <ogra> (i dropped the lang from ship)
[10:18] <lionel> pitti: could you please give back gobby on i386, sparc and powerpc. It should build now. Thanks!
[10:19] <pitti> lionel: done
[10:20] <lionel> pitti: great, thanks!
[10:23] <ogra> crimsun, you somehow missed to merge my esd samplesize patch from our current pulseaudio package
[10:23] <pitti> lionel: did you include StevenK's 0.11-1ubuntu3 fixes of ufraw in your upload?
[10:23] <pitti> lionel: there were 2 versions in unapproved at the same time
[10:23] <lionel> I've seen. Yes, I've included StevenK fixes
[10:23] <ogra> crimsun, its half the size of what it needs to be to play the login sound over network ... (funnily the logout sound is small enough)
[10:23] <pitti> lionel: good, thanks
[10:23] <lionel> np :)
[10:31] <crimsun> ogra: please upload.  I'm certain I tested, but I do have multiple unpacked source trees here, so I'll write a hook to test more thoroughly.
[10:31] <crimsun> ogra: sorry for the inconvenience.
[10:43] <lifeless> anyone interested in a huge evolution memory footprint?>
[10:45] <seb128> no
[10:45] <seb128> or maybe upstream
[10:46] <seb128> the desktop team basically send evolution bugs upstream anyway
[10:47] <lifeless> yah
[10:47] <lifeless> I'm asking up streamish nw
[10:47] <lifeless> *now*
[10:53] <pitti> StevenK: can you please use the current MIR template for openal and freealut? they are very thin ATM (no bugs research, etc.)
[10:58] <pitti> zul: FYI, the binary/NEW packages xen-hypervisor-3.1-amd64 and libxen3.1-dev (on amd64) are still empty
[10:59] <pitti> zul: I leave them in the queue for now
[10:59] <crimsun> Has there been discussion regarding whether login graphical environment sounds should be muted by default on new gutsy installs?
[10:59] <crimsun> The impetus for the above question is bug 122417.
[10:59] <ubotu> Launchpad bug 122417 in alsa-utils "[Gutsy]  Volume is too high in new install on HP Pavilion dv8220" [Wishlist,Triaged]  https://launchpad.net/bugs/122417
[10:59] <cjwatson> ogra: whoops, sorry, I forgot to do edubuntu-meta earlier
[11:00] <cjwatson> I'll go through everything after tribe-2 and make sure it's all consistent
[11:00] <cjwatson> all *-meta I mean
[11:00] <seb128> pitti: are some dbgsym known to be not available on gutsy?
[11:00] <pitti> seb128: not deliberately
[11:01] <pitti> seb128: some might get dropped if rookery cannot connect to LP
[11:01] <pitti> seb128: I can rescue stuff from the last seven days
[11:01] <seb128> #122009 indicates thant vino-dbgsym is not available
[11:01] <pitti> seb128: well, just let me re-fetch the stuff from the last week and rebuild the incices
[11:01] <pitti> seb128: in five minutes, when I got the last publisher run started
[11:01] <seb128> k
[11:02] <seb128> pitti: don't bother too much, that can wait after tribe-2
[11:03] <gnomefreak> pitti: we dont need your repo for -dbgsym packages anymore as of gutsy?
[11:04] <pitti> gnomefreak: erm, why not? the apport retracer relies on it
[11:04] <gnomefreak> oh ok
[11:04] <pitti> gnomefreak: well, 'we' in the sense of bug triagers, right
[11:04] <gnomefreak> ok ty
[11:05] <heno> seb128, pitti, evand: stgraber attached some apport logs to bug 122141 (gtk bug crashing ubiquity) I've milestoned it
[11:05] <ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [High,Confirmed]  https://launchpad.net/bugs/122141
[11:05] <pitti> heno: I thought that's the bug evand circumvented in the latest ubiquity?
[11:06] <pitti> evand: can you please have a look and duplicate it if appropriate?
[11:06] <heno> pitti: that's from 20070626.1
[11:06] <pitti> heno: right, we have a new one since then
[11:06] <heno> should the fix be there?
[11:06] <seb128> heno: bug is workarounded and known upstream and has a testcase
[11:06] <pitti> heno: apt-get install ubiquity on the live system
[11:06] <pitti> heno: FYI, I just started another publisher run
[11:07] <pitti> heno: after that we should finally have the necessary bits together for new CD images
[11:07] <heno> stgraber: ^
[11:07] <pitti> heno: quite a lot of compiz/ubiquity/network-manager fixes
[11:07] <evand> pitti: will do
[11:07] <stgraber> heno: good
[11:07] <heno> pitti: ok, cool
[11:07] <seb128> heno: I've removed the milestone, it's already workarounded in ubiquity
[11:07] <heno> seb128: sure, thanks
[11:08] <pitti> seb128: doesn't it affect other pygtk apps?
[11:08] <seb128> pitti: it affects any GTK+ app using set_image on a button apparently
[11:08] <evand> set_image on a button when using glade
[11:08] <pitti> seb128: that sounds pretty important?
[11:08] <seb128> pitti: but we didn't get other complain about it so I guess there is no other desktop application doing it
[11:09] <pitti> seb128: hm, funny :)
[11:09] <seb128> pitti: well, most apps use stock icons
[11:09] <seb128> I think it can be fixed after tribe-2
[11:09] <pitti> seb128: right; I mean tribe3
[11:10] <seb128> it'll be fixed quickly most likely
[11:10] <pitti> true that
[11:10] <seb128> feel free to milestone it if you prefer
[11:10] <seb128> it's high importance so it'll stay on my list of things to get fixed quickly
[11:12] <pitti> seb128, gnomefreak: I re-fetched all ddebs from June 18th until today; that's everything we can rescue
[11:13] <pitti> rebuilding indices now
[11:13] <gnomefreak> pitti: ok using your repo is no problem i just wasnt sure if it was needed
[11:13] <pitti> gnomefreak: the common way nowadays is to have apport file bugs and let the auto-retracer do its job
[11:13] <seb128> pitti: thank you
[11:14] <gnomefreak> pitti: ok cool thank you.
[11:22] <pitti> !usn | pitti
[11:22] <seb128> pitti: wrong window? ;)
[11:22] <pitti> seb128: no, testing ompaul's new factoid
[11:23] <seb128> ah
[11:23] <pitti> but it replied with a strange PM
[11:23] <ompaul> !usn > pitti
 ompaul wants you to know: usn is Please see http://www.ubuntu.com/usn for information about Ubuntu security updates.
[11:23] <ompaul> did that work better
[11:23] <pitti> ompaul: why isn't that pasted into the channel any more?
[11:23] <pitti> !ask | ompaul
[11:24] <ompaul> !usn | pitti 
[11:24] <pitti> hm, that still worked a few days back
[11:24] <ompaul> hmm 
[11:24] <ubotu> ompaul: Don't ask to ask a question. Just ask your question :)
[11:24] <ubotu> pitti: usn is Please see http://www.ubuntu.com/usn for information about Ubuntu security updates.
[11:24] <pitti> aaah
[11:24] <ompaul> the lagging interweb
[11:24] <pitti> what did we do different this time?
[11:24] <ompaul>  | from me to you 
[11:25] <ompaul> the > was send a message
[11:25] <ompaul> | is public
[11:25] <pitti> "!recursion is !recursion"; "!recursion | ubotu"
[11:25] <mc44> pitti: ubotu is too smart for that :)
[11:26] <pitti> I quoted it to not make it pick that up
[11:26] <mc44> it wouldn't work anyway
[11:36] <pitti> yay, publisher finally finished
[11:41] <doko> pitti: gcc-4.2 built; please accept gcc-4.1
[11:41] <pitti> doko: that won't break our default compiler? :)
[11:42] <doko> pitti: no, I did build the package locally on i386 without regressions
[11:43] <pitti> doko: is 4.1 necessary for lpia, too?
[11:44] <doko> pitti: yes; well, not if we make 4.2 the default for lpia from the start
[11:44] <pitti> doko: I'm just afraid of 'we need to fix package foo quickly; oops, FTBFSes with current gcc nwo' type of thing
[11:47] <pitti> doko: ah, looks harmless enough; accepting
[11:47] <tfheen> doko: I'm happy to make 4.2 default for lpia from the beginning if you think that's sane
[11:47] <doko> pitti: but just using gcc-4.2 as the lpia default, would require a gcc-defaults upload 
[11:48] <doko> tfheen: I was still unable to switch a i386 chroot to lpia, with our changes to dpkg and gcc-4.1
[11:48] <tfheen> doko: ok; your call
[11:48] <tfheen> I'm off to bed.
[11:49] <lifeless> noight
[11:49] <pitti> mvo, heno, *: new ubuntu alternates are up, please test
[11:49] <heno> pitti: will do
[11:50] <mvo> pitti: rsyncing
[11:51] <pitti> mvo: organic multivitamine juice, dude! :)
[11:51] <pitti> mvo: "Bioborn Multi-Frucht - 6 Frchte plus Mhre" keeps me alive here
[11:52] <mvo> haha
[11:52] <tarzeau> what would be the easiest way to get all changelogs of all packages of gutsy?
[11:52] <mvo> that sounds way too healthy for me
[11:52] <mvo> tarzeau: try changelogs.ubuntu.com
[11:52] <pitti> tarzeau: you can look them all up on changelogs.ubuntu.com
[11:52] <tarzeau> thanks
[11:53] <pitti> heno: how long do you estimate will you be still online for today?
[11:54] <heno> pitti: had planned another hour, can be longer if needed
[11:54] <pitti> heno: I build new images for all derivatives now (live+alternate), can you update the tracker? all images + 0.1
[11:54] <heno> pitti: sure, ETA?
[11:54] <heno> pitti: with the build script output we talked about it would happen automagically ;)
[11:55] <tarzeau> could i get http://changelogs.ubuntu.com/changelogs/pool/ by rsync?
[11:55] <tarzeau> or would someone create a tarball of it all?
[11:55] <pitti> heno: should be fine; I'll give the ubuntu live a quick test to see that all the n-m/compiz madness is good now
[11:55] <pitti> heno: hm, 3 hours for the last live, I think (xubuntu)
[11:55] <pitti> heno: maybe 35 minutes for ubuntu live
[11:56] <pitti> heno: yeah :/
[11:57] <pitti> heno: hm, it's a bit tricky to foresee which images will end up as 26.2 and which as 27
[11:57] <heno> pitti: ok, we may have some tracker admins in #ubuntu-iso
[11:58] <heno> pitti: right, just have to look at cdimage.u.c
[11:58] <tarzeau> is it okay to http mirror http://changelogs.ubuntu.com/changelogs/pool/ (i plan to do this weekly, maybe more). but it'll cause pretty much load on the webserver. i'd prefer a tarball or rsync... no chance?
[11:58] <pitti> LongPointyStick, Riddell, *: new kubuntu alternates up for testing
[11:59] <pitti> hi Burgundavia 
[11:59] <pitti> Burgundavia: btw, do you have time for the tribe2 wiki page or do you need help with that?
[12:11] <pitti> ogra, heno, LaserJock: new edubuntu alternates up (20070626.2), please test; no oversizedness any more \o/