[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.    :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.   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<EMAIL_ADDRESS>[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