[12:51] <Nafallo> xen moved to main? :-)
[01:26] <Kmos> Can I request a removal of package sgcontrol ? it doesn't have rdepends and it's removed at debian with reason: "RoM; obsolete, rdep of gconf/gnomevfs, has replacements"
[01:29] <Nafallo> ubuntu-desktop -> wvdial -> ppp; move wvdial to recommends? :-)
[01:34] <Kmos> https://iso.qa.stgraber.org/
[01:34] <Kmos> there isn't yet any iso
[01:36] <geser> Kmos: tribe-4 is due thursday
[01:38] <Kmos> geser: next week?
[01:39] <geser> this week
[01:40] <geser> try again thursday this week during the european day/evening
[01:40] <Kmos> :)
[01:41] <Kmos> it's already thursday here.. 00:40h - Portugal
[01:41] <Kmos> :)
[01:41] <geser> my calendar show only Wed Aug  8 01:41:29 CEST 2007
[01:42] <geser> that's over one day difference instead of the usual one hour
[01:43] <Kmos> :)
[01:45] <geser> Kmos: TZ="Portugal" date displays here Wed Aug  8 00:45:25 WEST 2007. So how can you already have thursday?
[01:47] <Kmos> geser: sorry.. i think today is wednesday
[01:47] <Kmos> lol
[01:47] <Kmos> my fault
[03:29] <calc> what does failed to upload status mean?
[03:30] <calc> https://launchpad.net/ubuntu/+source/openoffice.org/2.3.0~src680m224-1ubuntu1/+build/374232
[03:30] <calc> it appears to build fine but couldn't upload the resulting debs to the archive?!
[03:30] <StevenK> It means Soyuz tripped over it, and a member of -archive needs to fiddle it.
[03:31] <calc> ok
[03:31] <calc> any archive admins present?
[03:32] <Hobbsee> doubt it
[03:32] <Hobbsee> unless infinity happens to be around
[03:33] <calc> infinity: you awake?
[03:33] <calc> Hobbsee: btw your ooo 2.3 is in the archive more or less ;)
[03:33] <calc> it built on amd64, ia64 and is still building on the rest, no failures so far!
[03:33] <Hobbsee> calc: yay!  *hugs*
[03:33] <calc> i think turning off multithreaded build helped out
[03:34] <calc> makes it slower to build but at least its not failing
[03:34] <Hobbsee> calc: then we can have kubuntu cds with a working office
[03:34] <calc> Hobbsee: hopefully :)
[03:34] <calc> works on ubuntu in any case
[03:34] <calc> just switch to gnome if it doesn't work ;)
[03:35] <Hobbsee> bah.
[03:35] <calc> hehe
[03:35] <Hobbsee> calc: i cope with gnome in small doses.
[03:35] <StevenK> Very small doses? :-)
[03:35] <calc> i think maybe maintaining KDE made me dislike it ;)
[03:36] <Hobbsee> StevenK: exactly.  doing CD testing, etc, is enough :P
[03:47] <bddebian> Do we have a specific glibc maintainer?
[03:48] <calc> maybe seb128(?) he seems to know a lot about it anyway
[03:48] <calc> er thats glib nm
[03:48] <calc> bddebian: maybe doko in glibc case
[03:50] <bddebian> heh
[04:26] <calc> failed to upload on ppc also
[04:26] <calc> appears it may be failing to upload in general
[04:26] <calc> is the archive already frozen
[04:26] <calc> and/or would that cause the failed to upload messages to appear?
[04:27] <calc> 3 out of 5 worked so far though
[04:27] <calc> so i may have solved the weird random failure issue also
[05:16] <lhoerste> cjwatson_: is there something that automatically mounts drives in the ncurses installer?
[05:17] <lhoerste> or that tries to use a swap parititon
[06:02] <macogw> well, i suppose you're the ones most likely to be able to answer this, so i'm asking here.  does bcm43xx-fwcutter download only 1 set of firmware for anything using it, or does it somehow download different firmware depending on which bcm card it is?
[06:10] <macogw> ive looked at the orig.tar.gz for it and i dont see any URLs in any of the file except the README
[06:12] <LaserJock> macogw: looks like just one to me
[06:14] <macogw> in which file were you able to find the url?
[06:14] <macogw> i wasnt sure since there's about 20 different drivers and cards listed in fwcutter_list.h
[06:14] <LaserJock> if you get the whole source package, the .dsc .diff.gz and .orig.tar.gz and run dpkg-souce -x *.dsc
[06:15] <LaserJock> it's in the bcm43xx-fwcutter/debian/ directory
[06:15] <macogw> ok
[06:15] <LaserJock> install_bcm43xx_firmware.sh
[06:15] <LaserJock> at least that's what I'm guessing
[06:15] <macogw> i didnt realize it was just a debian thing and not part of it overall
[06:16] <macogw> though maybe rpm's would do it too and its just a matter of postinst scripts
[06:16] <macogw> thanks
[06:17] <sladen> Seveas: Launchpad memberships seem to be expiring again.
[06:19] <macogw> yeah, the url for the file is in that script, you're right, but i just looked and it's currently a 404 error page
[06:19] <LaserJock> well, that could be a problem
[06:26] <macogw> looking at that script, it seems all it does is copy the files to /lib/firmware, and i have them on my computer right now.  i can upload them.
[06:26] <calc> grr ooo 2.3 failed on sparc :\
[06:27] <calc> Hobbsee: wb
[06:28] <Hobbsee> heya calc
[06:28] <Hobbsee> yay, there's wifi at the uni!
[06:37] <StevenK> Morning pitti
[06:37] <pitti> Good morning
[06:38] <pitti> calc: still here?
[06:41] <calc> pitti: yes
[06:41] <pitti> calc: OO.o failed to upload
[06:41] <pitti> 02:18:26 WARNING        openoffice.org_2.3.0~src680m224-1ubuntu1_powerpc.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
[06:41] <pitti> calc: from your bzip2'ification
[06:41] <calc> ugh
[06:41] <pitti> calc: I agree that this check is largely obsolete nowadays, but it's quicker to fix OO.o, I think
[06:42] <calc> is that still required iirc everything past hoary has >= 1.10.24
[06:42] <calc> quicker to fix and upload a new version?
[06:42] <calc> and rebuild it on all arches?
[06:42] <calc> its done on all but i386 so far
[06:42] <pitti> there go ~ 10 hours of buildd time from now on
[06:42] <calc> why is that check still in there for the bzip2 stuff anywhere since that dpkg is long obsolete?
[06:43] <calc> s/anywhere/anyway/
[06:43] <pitti> calc: can you please prepare it anyway? I'll try to reach someone who could circumvent this
[06:43] <pitti> calc: but at this time of the day, the Soyuz guys are already asleep
[06:43] <pitti> infinity: you there?
[06:43] <calc> pitti: oh its blocking it from being added to the repo?
[06:44] <pitti> calc: yes
[06:44] <calc> gah
[06:45] <macogw> LaserJock: http://macoafi.googlepages.com/firmware.tar.gz i put the firmware there (i already had it installed, so just copied from /lib/firmware)
[06:45] <calc> i thought those types of checks were generally removed after an official release of the new dpkg
[06:46] <pitti> calc: yeah, just nobody did it, I guess
[06:46] <calc> official release with a new dpkg supporting some feature
[06:46] <calc> pitti: ah
[06:46] <pitti> calc: I asked infinity now, maybe we can do a cowboy fix
[06:46] <calc> ok
[06:46] <pitti> calc: I seriously hope that we don't need to rebuild
[06:46] <calc> yea
[06:47] <calc> the oldest still supported ubuntu release already has a much newer version of dpkg than needed so it should be removed from the checks
[06:47] <calc> but i'll work on getting it ready
[06:47] <calc> let me know if infinity can fix it and i'll stop on the work
[06:47] <pitti> calc: appreciated; I'll grep for the code now, and if we can cowboy it, I'll tell you
[06:48] <pitti> ah, I think I got it
[06:48] <calc> ok
[06:49] <calc> pitti: does it look to be able to workaround it?
[06:49] <pitti> calc: yes, absolutely
[06:49] <calc> and/or remove the check entirely
[06:49] <calc> ok great :)
[06:49] <pitti> calc: I'll leave the test in
[06:52] <mthaddon> anyone know if there's a way to get a list of packages you've specifically requested to be installed versus those that were installed as dependencies after the fact?
[06:58] <pitti> calc: I think I got it now
[07:03] <calc> pitti: ok thanks :)
[07:05] <calc> pitti: amd64 still shows as failed to upload does anything need to be done to get it uploaded?
[07:07] <pitti> calc: yeah, it's a bit weird
[07:07] <pitti> the other stuff isn't in accepted either
[07:07] <calc> oh
[07:08] <pitti> 04:58:08 DEBUG   Skipping 20070808-015000-374232-892251 -- does not match /20070808-015000-374232-892251
[07:08] <pitti> hm?
[07:09] <calc> weird
[07:10] <pitti> calc: ah, ppc build and -l10n is in NEW, silly me
[07:10] <calc> oh ok
[07:11] <doko> calc: you did drop the Pre-Depends :-(, uploads rejected ...
[07:12] <pitti> doko: https://bugs.launchpad.net/soyuz/+bug/131032
[07:12] <ubotu> Launchpad bug 131032 in soyuz "Please disable obsolete bzip2 dpkg Pre-Depends: check" [Undecided,New] 
[07:12] <pitti> doko: I just hacked Soyuz to swallow it
[07:13] <doko> ahh, ok
[07:15] <calc> doko: yea i dropped it because it was obsolete didn't know that soyuz was buggy until it rejected it
[07:15] <calc> doko: that feature is ~ 3 years old so shouldn't have triggered a rejection
[07:16] <calc> eg etch should have officially allowed bzip2 compression (not sure if it actually did or not)
[07:16] <calc> actually sarge to i think
[07:17] <infinity> calc: I'm still not sure soyuz is "buggy"... dak has exactly the same check.
[07:17] <infinity> calc: But I take the point that the check is becoming obsolete.
[07:17] <pitti> infinity: well, 'bug' is too much, but it's still obsolete IMHO
[07:17] <infinity> (Note that security updates of OOo will fail in the same way until we similarly "fix" jackass)
[07:18] <pitti> I don't object against having the pre-depends on the next upload
[07:18] <doko> calc: what did you drop else? ;-)
[07:18] <pitti> but I wanted those debs for the tribe now
[07:18] <calc> doko: i think that is all but i will be going back over the previous diff to make sure everything is merged in the next upload
[07:19] <calc> doko: i specifically dropped the dpkg depends though since it was obsolete and not needed even in the dapper case
[07:19] <calc> or rather shouldn't be needed anymore
[07:20] <infinity> Shouldn't be, but it doesn't hurt either.
[07:20] <calc> otherwise depends/conflicts/etc would grow huge if you can never prune them
[07:22] <calc> i'm not sure if its codified but if i remember correctly using dpkg features at least in debian was just required it be in an already released dist, eg the ~ versioning feature
[07:23] <calc> dak/soyuz doesn't reject on using ~ without a pre-depends does it?
[07:23] <infinity> pitti: I'll make sure to mangle our various katie installations to drop the check too.  I suspect it's correct to do so at this point.  Just sucks to have the issue forced. :)
[07:23] <Hobbsee> you know, it'd be really useful if the uni had total wifi, everywhere in it
[07:23] <calc> infinity: for the record i didn't know it would fail to get into the archive due to dropping the pre-depends
[07:23] <calc> infinity: so i didn't intentionally cause this mess, heh
[07:23] <infinity> calc: The reason for the pre-depends check in dak (and later soyuz) was specifically so the feature could be used without waiting for a release cycle.
[07:24] <calc> infinity: oh ok
[07:24] <calc> ah and just never removed after the release (hoary i guess)
[07:24] <infinity> (And, in the case of some dpkg features, you need to wait TWO release cycles...)
[07:24] <calc> infinity: oh i didn't know about that
[07:24] <doko> hmm, the sparc build did fail
[07:24] <infinity> Because otherwise, upgrades could fail.
[07:25] <infinity> Pre-Depends on a newer dpkg kinda makes that go away, so long as it's not a required/essential package that causes an upgrade loop with dpkg itself. :)
[07:25] <calc> infinity: for ubuntu wouldn't that be wait until the next LTS?
[07:25] <calc> infinity: we support upgrades from an LTS up to the next LTS right?
[07:26] <doko> dependency "cleanup" became a desease
[07:26] <doko> http://launchpadlibrarian.net/8732984/buildlog_ubuntu-gutsy-sparc.openoffice.org_2.3.0%7Esrc680m224-1ubuntu1_FAILEDTOBUILD.txt.gz
[07:26] <infinity> calc: That's undetermined right now.  During the gutsy+1 UDSing, I think I'll attend specifically to deliver my opinions on how we should be dealing with upgrade tactics.
[07:26] <calc> doko: sparc ICEd not sure if that is the only issue
[07:26] <doko> g++  -fmessage-length=0 -c -O2 -fno-strict-aliasing   -fno-stack-protector -fvisibility=hidden -I.  -I../../../unxlngs.pro/inc/func -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/offuh -I../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxlngs.pro/inc -I. -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro
[07:26] <doko> /inc/stl -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/external -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/unxlngs/inc -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/inc -I/build/buildd/openoffice
[07:26] <infinity> calc: Right now, there's a lot of hand-waving about upgrading from LTS to LTS, but I know that almost zero effort has been put into allowing it.
[07:26] <doko> .org-2.3.0~src680m224/ooo-build/build/src680-m224/res -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/stl -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/inc/Xp31 -INO_JAVA_HOME/include -INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include -I/usr/include     -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/buil
[07:26] <doko> d/src680-m224/solver/680/unxlngs.pro/inc/offuh -I. -I../../../res -I. -pipe  -g1 -Wreturn-type -Wno-ctor-dtor-privacy   -fPIC -DLINUX -DUNX -DVCL -DGCC -DC300 -DSPARC -DCVER=C300 -DNPTL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DSPARC -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.1.3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL
[07:26] <doko> -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DCUI -DSRC680=SRC680   -DSD_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_   -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o ../../../unxlngs.pro/slo/fupage.o /build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/sd/source/ui/func/fupage.cxx
[07:26] <infinity> doko: Ow.
[07:26] <doko> calc: there seem to be errors before the ice
[07:26] <calc> infinity: yea that could potentially take a LOT of work
[07:26] <Mithrandir> doko: dude, use a pastebin.
[07:27] <calc> doko: yea it seemed to attempt to compile some code lots of errors on that file and then ICE
[07:27] <doko> Mithrandir: just two lines ;)
[07:27] <Hobbsee> er, boot
[07:27] <doko> Hobbsee: you're a trainee? ;)
[07:27] <calc> doko: any ideas on why it would work on all archs but sparc?
[07:28] <infinity> calc: It will be a lot of work, but if we're starting with a stable toolchain, and a stable set of packages, and we're being conservative about the "bling" we try to put into gutsy+1, we could potentially have a lot of free developer resources to actually (gasp!) fix bugs, and test upgrade patchs.
[07:28] <infinity> s/patchs/paths/
[07:28] <Hobbsee> doko: i'm an op on almost all #*ubuntu* channels.
[07:28] <infinity> calc: Which is definitely a route I'd like to see us take.
[07:28] <Hobbsee> doko: i dont usually have to think about kicking for floods.
[07:28] <doko> no, get a recent chroot and the b-d's on faure
[07:28] <calc> infinity: hehe yea
[07:30] <StevenK> debian/rules:20: *** unterminated call to function `shell': missing `)'.  Stop.
[07:30] <StevenK> But it ends with a )! It does!
[07:30] <infinity> Bad quoting?
[07:31] <infinity> StevenK: Did you get my late night IRC notes about libnss-db?
[07:31] <StevenK> How does stuff need to be quoted in $(shell )?
[07:31] <calc> doko: i'm seeing stuff even like this:
[07:31] <calc> doko: /usr/include/c++/4.1.3/typeinfo:42: error: expected unqualified-id before string constant
[07:32] <infinity> StevenK: What's the current line that's breaking?
[07:32] <calc> doko: and lots of things like: /usr/include/c++/4.1.3/cwchar:70: error: expected unqualified-id before 'namespace'
[07:32] <StevenK> infinity: VAR_DB := $(shell echo | cpp -include paths.h -dD | grep '#define _PATH_VARDB')
[07:34] <StevenK> infinity: And I did, thank you. I've sorted out mostly everything, I think this is the last bit.
[07:34] <infinity> StevenK: It's the # it doesn't like.
[07:35] <StevenK> Ah, backwhack the #?
[07:35] <infinity> Should do.
[07:36] <infinity> StevenK: And if you are reusing that var later, remember to quote it.
[07:37] <infinity> StevenK: "echo $(VAR_DB)" will just echo nothing, "echo "$(VAR_DB)"" will work.
[07:37] <doko> calc: you did drop the ooo-build/desktop/po changes ... that means that people will start mis-translating the wrong translations again ...
[07:37] <infinity> (If you're using it in shell, that is)
[07:37] <StevenK> infinity: It's about to be munged further, it will end up being a path.
[07:37] <calc> doko: er where were the changes?
[07:38] <infinity> StevenK: awk '{print $2}' to the rescue!
[07:38] <calc> doko: they weren't in bzr or ooo-build afaict
[07:38] <infinity> (Because cut is for losers)
[07:38] <calc> doko: anything in ooo-build probably was dropped in that case
[07:38] <doko> calc: you did take notes during the sprint ...
[07:38] <calc> oh shit, yea i need to find those again :\
[07:38] <infinity> StevenK: Err, print $3, even. :)
[07:38] <StevenK> infinity: Actually, I'm using cut. :-)
[07:38] <doko> there was a reason I did ask for the package before an upload :-(
[07:38] <infinity> StevenK: Loser. :)
[07:38] <calc> doko: i don't recall you mentioning stuff under ooo-build though during that time, but i'll find my notes
[07:39] <StevenK> infinity: Bite me. :-)
[07:39] <calc> doko: i did port the other patches under patches/src680
[07:41] <calc> doko: ok found the notes
[07:41] <calc> doko: i have detailed notes for stuff in debian dir but nothing for ooo-build
[07:42] <calc> doko: is there an easy way to determine which svn revision was pulled from for the last upload you did so i can find what was changed for ubuntu?
[07:42] <doko> calc: no
[07:43] <calc> doko: hehehe, so er how do i find what was changed for ubuntu?
[07:43] <calc> if i can't find a base version to diff against its almost impossible to determine what was ubuntu specific changes
[07:43] <calc> unless you know in particular what they are
[07:59] <pitti> calc: publisher finished!
[07:59] <pitti> calc: -l10n and ooo amd64 are in the archive now
[07:59] <pitti> everyone with amd64, please test
[07:59] <calc> pitti: cool :)
[08:00] <StevenK> infinity: There are three /usr/share/locale/de/LC_MESSAGES/@GETTEXT_PACKAGE@.mo files in the resultant .deb, can we deal, or should I see what's installing them?
[08:00] <StevenK> infinity: Where de is de, nl and pl
[08:00] <StevenK> pitti: Actually, I now that Oo.o has built on powerpc, libgcj7-0 can be NBS'd. :-)
[08:01] <StevenK> s/I //
[08:01] <pitti> StevenK: finally :)
[08:01] <infinity> StevenK: That looks a bit messy to me.  And it may also confuse the bejesus out of pkgstriptranslations and/or the rosetta imports.
[08:01] <StevenK> pitti: And openoffice.org-gcj is also marked as NBS.
[08:02] <pitti> meh, that still needs some archive.u.c. mirroring, it seems
[08:02] <StevenK> infinity: Right, I daresay I can fix it by kicking po out of 'SUBDIRS = intl po src' in Makefile.in
[08:11] <calc> wrt the java stuff ooo 2.3 currently fails to build with java but i'm still working on getting that to work before release
[08:16] <infinity> StevenK: That won't drop pofiles completely?
[08:18] <infinity> Dear sejong, I hate you.  Love, Adam.
[08:18] <Hobbsee> infinity: i think you need to show it more forcefully than that
[08:19] <infinity> Hobbsee: I've forcefully rebooted it twice in the last two hours, what more does it want?
[08:20] <Mithrandir> infinity: more rough love, of course.
[08:20] <Hobbsee> infinity: an axe
[08:21] <pitti> hey Mithrandir
[08:21] <Mithrandir> hiya Martin
[08:22] <StevenK> infinity: .po files weren't installed anyway
[08:22] <StevenK> Dear yada, you suck, I hate you, and I want you to die. No Love, Steve
[08:22] <StevenK> Files in first .deb but not in second
[08:22] <StevenK> -rwxr-xr-x  root/root   DEBIAN/postinst
[08:23] <StevenK> infinity: I'm ready for you to look at libnss-db again.
[08:24] <StevenK> infinity: Do you have time again, and how do you want the source?
[08:25] <StevenK> pitti: Would a new libnss-db be accepted so that yada can be killed, or am I just dreaming?
[08:25] <StevenK> s/killed/demoted/
[08:25] <pitti> StevenK: I'll accept it after tribe4
[08:25] <Hobbsee> StevenK: i preferred it without the substitution
[08:26] <StevenK> Heh
[08:26] <StevenK> pitti: In which case, I may as well not upload it until after the freeze lifts anyway
[08:26] <pitti> StevenK: I thought infinity wanted to put it into Debian or so?
[08:27] <StevenK> Yeah, the Debian Maintainer is yada's upstream. "Here's this patch to change the build system. Enjoy"
[08:27] <pitti> StevenK: ooh, "oops" :)
[08:28] <StevenK> vorlon has a Unoffical release goal to remove yada for Lenny, but he hasn't discussed it with the maintainer ...
[08:30] <infinity> The Debian maintainer hasn't uploaded it for ages, I might try hijacking it and see what happens. :P
[08:30] <infinity> StevenK: The po files weren't installed at all?  That seems more like a bug than a feature...
[08:30] <pygi> morning
[08:30] <infinity> Unless they're useless.
[08:31] <StevenK> infinity: Doing a debdiff between the last upload and my debhelper package, doesn't show anything to do with po at all
[08:32] <infinity> StevenK: Fair enough.  I didn't mean it was YOUR bug, just perhaps a bug. :)
[08:32] <StevenK> Heh
[08:32] <infinity> dexter isn't known for his finesse.
[08:32] <StevenK> Or coding ability.
[08:33] <calc> wow i386 build takes forever, i think the buildd may be a bit slow, heh
[08:33] <infinity> It's not that slow..
[08:33] <calc> still going 11hr+ later
[08:34] <calc> amd64 took 5h50m
[08:34] <infinity> buildd@rothera:~$ cat /proc/cpuinfo | grep "^model name" ; free | grep ^Mem
[08:34] <infinity> model name      : Intel(R) Xeon(TM) CPU 2.80GHz
[08:34] <infinity> Mem:       2076480    1870292     206188          0     398692     942840
[08:34] <infinity> It could be beefier, but it's not crap.
[08:34] <pitti> asac: is there hope for bug 128360 or shall we postpone it?
[08:34] <ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
[08:35] <calc> infinity: hmm weird that is taking so long then
[08:35] <calc> pitti: heh thats my bug, i don't know asac's status on it right now though
[08:36] <StevenK> infinity: So, how shall I get the source to you?
[08:36] <calc> pitti: it probably can be postponed but it needs to be fixed before actual final release
[08:36] <infinity> StevenK: Mail worked last time.
[08:36] <pitti> calc: oh, btw, did you try OO.o on KDE without installing -gnome? (such as in bug 127944)
[08:36] <ubotu> Launchpad bug 127944 in openoffice.org "[gutsy] Open Office applications don't start " [High,Confirmed]  https://launchpad.net/bugs/127944
[08:36] <calc> pitti: something about ipw3945/wpa/nm causes it to not work at all for various people (not just me any more)
[08:36] <calc> pitti: not yet, i don't have a copy of kubuntu installed right now
[08:38] <calc> pitti: does removing the gnome/gtk packages cause it to fail or just if the kde ones are installed?
[08:39] <calc> hmm if it works when gnome/gtk is installed i am confused about the bug i though people claimed it didn't work at all, not just on kubuntu
[08:39] <pitti> calc: unknown, but I guess removing -gnome makes it crash
[08:39] <pitti> trying here
[08:40] <calc> someone running gnome said it failed on it as well
[08:40] <calc> 2.3 works on ubuntu for me, so i think it may be fixed
[08:40] <pitti> I just purged -gnome and -gtk, and now it's hanging at the splash screen
[08:40] <pitti> calc: ^ with 2.2.1 still
[08:40] <pitti> and 100% cpu
[08:41] <calc> ok i'll test on 2.3
[08:41] <calc> pitti: yea it was broken on 2.2.1 with the new glib upload
[08:42] <calc> pitti: glib changed something that apparently wasn't considered abi stable
[08:42] <calc> and broke lots of stuff not just ooo
[08:42] <calc> i'll see if it breaks when removing gtk/gnome for 2.3
[08:45] <calc> pitti: yea openoffice.org-gtk has to be installed for it to start
[08:46] <pitti> calc: erk, do we have that on Kubuntu? or is -kde enough?
[08:46] <pitti> calc: there should be a dependency then
[08:47] <infinity> Should be, but you can cheat and fix it in the seeds for the Tribe...
[08:47] <calc> pitti: it wasn't needed until apparently glib did something weird
[08:47] <infinity> -kde needs to depend on -gtk though, it would seem.
[08:47] <infinity> Oh, wait.  It fails on non-kde too?
[08:47] <calc> but glib apparently doesn't consider it a bug to break working programs, nsplugin is broken, acrobat, and several other things aiui
[08:48] <calc> infinity: yea if you remove openoffice.org-gtk it fails to start
[08:48] <infinity> Special.
[08:48] <calc> it worked, then new glib upload, now doesn't work anymore
[08:48] <calc> without any changes on ooo side
[08:48] <pitti> calc: so we need to put openoffice.org-gtk on the Kubuntu CDs?
[08:48] <Mithrandir> that doesn't mean the bug is in glib, it might just as well be other apps depending on undefined behaviour.
[08:49] <Mithrandir> pitti: that'll make the Kubuntu camp happy. :-P
[08:49] <infinity> Mithrandir: Longstanding undefined behaviour becomes a feature after a while.
[08:49] <calc> pitti: yea for now, that will pull in a lot of gtk/gnome stuff though i think :(
[08:49] <Mithrandir> infinity: so did the people who stuffed pointers into int claim too.
[08:51] <StevenK> infinity: Mail sent.
[08:52] <pitti> calc: wow, kubuntu already has libgtk
[08:53] <infinity> That's not a shock, really.
[08:53] <pitti> so that would leave gconf2 as additional depends
[08:53] <pitti> which in turn pulls in more stuff
[08:55] <pitti> gconf2 libgconf2-4 gconf2-common liborbit2 libidl0
[08:55] <pitti> calc: ^ extra dependencies of -gtk on Kubuntu CD
[08:55] <pitti> roughly one MB altogether
[08:56] <calc> ok
[08:56] <pitti> ok, *shrug*, I'll seed it for now
[08:56] <pitti> Riddell: ^
[08:56] <pitti> needs a -meta upload, though
[08:56] <pitti> *sigh*
[08:57] <infinity> meta sucks less than OOo.
[08:58] <infinity> And OOo is STILL building on i386 anyway...
[08:58] <pitti> yeah
[08:58] <infinity> I'll go stop the publisher now, before it starts.
[08:59] <pitti> infinity: it's on manual already
[08:59] <infinity> So it is. :)
[08:59] <pitti> I just ran q-b manually to get the tracker builds
[08:59] <pitti> waiting for the kubuntu-meta now, then I'll run it again
[08:59] <infinity> You're stopping b-s before you run q-b, right?
[08:59] <calc> looks to be something changed between gtk 2.11.5 and 2.11.6
[08:59] <pitti> yes
[09:00] <infinity> pitti: Using ~lp_buildd/bin/queue-builder.sh ?
[09:00] <pitti> infinity: yes, that's what cprov told me
[09:00] <infinity> (I should just make that also stop and start the sequencer, for great justice)
[09:00] <infinity> pitti: Oh, good, I didn't know cprov even knew that was there. :)
[09:00] <pitti> that worked fine so far
[09:01] <infinity> pitti: It was just my littl cronjob from back when q-b didn't run from b-s.
[09:05] <StevenK> infinity: Oh, one thing I forgot to mention in the mail is that the diff.gz no longer includes config.{guess,sub}
[09:07] <pitti> calc: can you please check installing -gtk and -kde and not -gnome?
[09:09] <pitti> calc: I updated #127944
[09:10] <pitti> wb calc
[09:11] <pitti> calc: can you please check installing -gtk and -kde and not -gnome?
[09:11] <pitti> calc: I updated #127944
[09:11] <pitti> so it seems that all the trouble of pushing 2.3 (and the associated risk) was in vain :/
[09:11] <calc> i hate Network Mangler :\
[09:11] <calc> it took my network down during upgrade
[09:12] <calc> pitti: its not really any more broken than it was before though, so does get more testing for new version
[09:12] <pitti> calc: right, but it's quite a risk to update a package like that a day before tribe release :)
[09:13] <calc> yea
[09:14] <infinity> pitti: Pushing it in before a Tribe makes more sense than doing it right after, IMO.  Tribe releases mean broader testing, and a new upstream version needs all the testing it can get.
[09:15] <calc> Riddell: here?
[09:15] <infinity> pitti: I know I'm going against the grain on this one, but I'm a fan of "if it builds and installs successfully, and doesn't appear to eat user data, we want to ship it for testing".
[09:15] <doko> pitti: please accept lcms, fixing build failure
[09:16] <pitti> infinity: as long as it works at all, I'm fine with it
[09:16] <pitti> infinity: I just fear if it doesn't at all for some weird reason
[09:16] <pitti> good morning sabdfl
[09:16] <infinity> pitti: That "weird reason" would be "because it's OpenOffice"..
[09:16] <sabdfl> moin moin
[09:16] <desrt> sabdfl; nice article
[09:16] <infinity> sabdfl: Mornin'.
[09:16] <sabdfl> desrt: ?
[09:16] <desrt> you were dugg very recently
[09:17] <sabdfl> ah
[09:17] <desrt> about novell shooting themselves in the foot
[09:17] <sabdfl> with a shotgun, imo
[09:17] <pitti> doko: done
[09:17] <desrt> yet lenovo is now shipping novell
[09:17] <desrt> funny world it is
[09:18] <pitti> desrt: I see nothign on planet.u.c.?
[09:18] <pitti> ah, digg
[09:18] <doko> pitti: does ooo-l10n get the same dpkg-predepends love?
[09:19] <pitti> doko: it had the same upload failure, yes
[09:20] <desrt> digg is the devil.  i made a blog post last night and it got dugg and now i have a million moronic comments on my blog that i'm not providing enough information for [random digg reader]  to understand my post
[09:20] <desrt> uh.. intended audience: planet gnome.  not digg.
[09:21] <pitti> calc: so, -gtk and -kde together works with 2.3? (without -gnome)
[09:21] <calc> is there any chance that upgrading network manager will one day not kill the network on the box?
[09:21] <calc> pitti: sec
[09:22] <pitti> calc: I think so
[09:22] <pitti> calc: asac already fixed the opposite problem (tearing down and restarting interfaces at startup)
[09:22] <calc> it appears it now shuts it down and doesn't bring it back up
[09:22] <calc> heh
[09:22] <calc> i had to restart it manually
[09:23] <calc> pitti: with gtk and kde it works on gnome
[09:23] <pitti> it seems that ooo grinds through all the translations, too
[09:23] <pitti> calc: great, thanks
[09:23] <pitti> calc: so let's hope that the workaround with seeding it to kubuntu works
[09:23] <pitti> hey mvo
[09:24] <calc> pitti: hmm i'll need to look into that again, i'm pretty sure i merged it properly from what was in 2.2.1 but maybe i missed something :\
[09:25] <calc> pitti: i sent email to Riddell and seb128 about the -gtk issue to see if they know any more about the problem and potential solution post tribe-4
[09:25] <calc> seb128: hi
[09:26] <seb128> Hi calc
[09:26] <pitti> seb128!
[09:26] <pitti> seb128: please don't kill me
[09:26] <mvo> hey pitti
[09:26] <pitti> seb128: I updated tracker without asking you tomorrow, since we are in a bit of a hurry
[09:26] <seb128> no, it's just my usual time to start working ;)
[09:26] <calc> seb128: any idea what caused the breakage in ooo and konqueror/nspluginview with gtk 2.11.6?
[09:26] <seb128> hey pitti mvo
[09:27] <calc> seb128: i'm guessing there is probably a patch out there somewhere to fix it already if i know what to look fo
[09:27] <calc> for
[09:27] <pitti> seb128: s/tomorrow/this morning/, bah *waking up*
[09:27] <seb128> calc: no, I though that was fixed with the new ooo?
[09:27] <seb128> pitti: sure, thanks
[09:27] <calc> seb128: i thought it was but didn't realize i had ooo-gtk installed at the time which allows it to work, somehow?
[09:27] <pitti> seb128: see last comment on bug 127944
[09:27] <ubotu> Launchpad bug 127944 in openoffice.org "[gutsy]  Open Office applications don't start " [High,Confirmed]  https://launchpad.net/bugs/127944
[09:28] <calc> seb128: apparently whatever causes the breakage if i install openoffice.org-gtk it starts up ok
[09:28] <seb128> I know that, I get the bug comments and I read most of my bug mails
[09:28] <calc> seb128: ok np
[09:29] <seb128> I didn't try to look at the bug though because you told me at the meeting that it fixed with ooo 2.3
[09:29] <seb128> will have a look
[09:29] <seb128> having a backtrace of the issue would be nice though
[09:30] <pitti> it's an eternal hang, not a crash, but I guess one could ^C it in gdb
[09:31] <seb128> there is http://bugzilla.gnome.org/show_bug.cgi?id=463773 upstream
[09:31] <ubotu> Gnome bug 463773 in gobject "Openoffice and flash run into a deadlock when used with KDE" [Critical,New] 
[09:31] <seb128> but no real activity on it
[09:33] <seb128> http://svn.gnome.org/viewcvs/glib/trunk/gobject/gtype.h?r1=5618&r2=5617&pathrev=5618 is the commit mentioned
[09:33] <seb128> http://svn.gnome.org/viewcvs/glib?view=revision&revision=5618
[09:34] <infinity> Man, glibc scares me...
[09:34] <infinity> What exactly is G_UNLIKELY?
[09:34] <desrt> infinity; static branch prediction hints
[09:35] <seb128> infinity: you mean "glib"? glibc is not the same one ;)
[09:35] <pitti> doesn't the kernel have those, too?
[09:35] <infinity> seb128: Err, finger auto-completion.
[09:35] <desrt> if (unlikely (condition)) emits assembly which tells the CPU to always branch-predict for the condition being false
[09:35] <infinity> seb128: I can't type "glib" without adding the "c" on the end.
[09:35] <infinity> seb128: Much like trying to type "apt-" without "get".
[09:36] <pitti> finally! that scary LongPointyStick is gone!
[09:36] <infinity> desrt: You could have stopped at "static branch prediction". :P
[09:36] <calc_> hmm my network connection died again
[09:36] <desrt> infinity; eh.  wasn't too much effort to type the rest :p
[09:36] <calc_> hopefully it isn't a sign of things to come from this new NM update
[09:37] <calc_> 02:33 < calc> hmm backtrace gives the usual stripped useless data :\
[09:38] <Hobbsee> pitti: you wish :)
[09:38] <seb128> hey Hobbsee
[09:38] <Hobbsee> hiya seb128!
[09:39] <calc__> network manager is spawn of the devil
[09:39] <infinity> calc__: A stripped backtrace is better than none.
[09:39] <calc__> (gdb) bt
[09:39] <calc__> #0  0xffffe410 in ?? ()
[09:39] <calc__> #1  0xbfb1c9c8 in ?? ()
[09:39] <calc__> #2  0x00000001 in ?? ()
[09:39] <calc__> #3  0x00000000 in ?? ()
[09:39] <calc__> or should i be doing something else?
[09:39] <calc_> 02:34 < calc> is there an easy way to get it to give an apport type dump that  can be retraced?
[09:39] <calc_> gar!
[09:39] <infinity> Oh, that's uglier than expected. :)
[09:40] <pitti> calc__: you need the debug symbol packages
[09:40] <calc__> hehe
[09:40] <calc__> pitti: is there one for 2.3 yet?
[09:40] <pitti> calc__: either install pkg-create-dbgsym and build them locally, or wait until the buildd is finished
[09:40] <calc__> pitti: ok
[09:40] <infinity> ... Or run the unstripped binaries from your build tree.
[09:40] <calc__> pitti: how do i grab the symbols after the buildd is done?
[09:40] <infinity> Which may be non-trivial for OOo, I admit.
[09:40] <pitti> calc__: deb http://people.ubuntu.com/~pitti/ddebs gutsy main
[09:40] <calc__> infinity: don't have them anymore
[09:41] <calc__> pitti: thanks
[09:41] <pitti> calc__: you also need the glib/gtk debug symbols, I figure
[09:41] <calc__> yea
[09:41] <infinity> The build's been exporting GSI and doing oo2po crap for hours. :/
[09:42] <pitti> calc__: that reminds me to write that "How to debug a crash with apport" howto :)
[09:42] <pitti> yeah, in vain
[09:42] <infinity> glib's symbols might be enough to divine what garbage it's being fed, actually.
[09:43] <pitti> calc__: try installing libc6-dbgsym libc6-i686-dbgsym libglib2.0-0-dbgsym libgtk2.0-0-dbgsym
[09:43] <pitti> calc__: and see if bt gets any better
[09:44] <ccheney> i'm not really still there
[09:44] <ccheney> nm really is screwing up my system bad
[09:45] <StevenK> [17:45]  < pitti> calc__: try installing libc6-dbgsym libc6-i686-dbgsym
[09:45] <StevenK>                  libglib2.0-0-dbgsym libgtk2.0-0-dbgsym
[09:45] <StevenK> [17:45]  < pitti> calc__: and see if bt gets any better
[09:45] <ccheney> hopefully a reboot will fix it
[09:45] <ccheney> "NM making your linux system more like Windows every day"
[09:46] <ccheney> StevenK: i'll take a look at that in the morning, its 2:45 here now and my desktop which is the system running gutsy has no network access currently after being abused by NM
[09:46] <ccheney> StevenK: thanks for pasting it for me to see though :)
[09:49] <ccheney> on my laptop i pretty much can never get a network connection on gutsy :\
[09:50] <pitti> ccheney: that's what we call 'dogfooding'
[09:51] <Hobbsee> ah, asac isnt here.
[09:51] <pitti> ccheney: only with pain like that we devs are actually encouraged to *fix* bugs :)
[09:51] <ccheney> pitti: heh, i wouldn't be able to get any work done if i tried using it outside a boot cd ;)
[09:51] <Hobbsee> NM with ipw3945 still doesnt seem to work on open networks, even with the new upload, at least here
[09:51] <ccheney> pitti: even several days of debugging didn't find a solution for the ipw3945/wpa/nm stack issue
[09:51] <pitti> Hobbsee: please followup on the bug then
[09:51] <ccheney> pitti: thats the one you bumped wrt asac
[09:51] <pitti> right
[09:51] <ccheney> Hobbsee: it doesn't work at all for me open or wpa
[09:51] <pitti> ccheney: (just making sure that it gets enough data to get fixed)
[09:52] <Hobbsee> pitti: i will.  i've only recently got home, and on a *gasp* <whisper> inferior OS </whisper>
[09:52] <ccheney> Hobbsee: if i kick it just right it will work but i can't get it to be reproducibly working
[09:52] <Hobbsee> heh
[09:52] <pitti> ccheney: is it any better to use good old /etc/network/interface and not using n-m?
[09:52] <_StefanS_> infinity: Do you know anything about that initiative with lpia and kde/qt ?
[09:52] <ccheney> pitti: no
[09:52] <Hobbsee> it works fine here with wpa.  just not unencrypted at the uni.
[09:52] <ccheney> pitti: it works on an open network for me if i use dhclient eth1
[09:52] <ccheney> is broken for me on both i386 and amd64
[09:52] <infinity> _StefanS_: You may need to be a bit more specific about what you mean by "that initiative"...
[09:53] <ccheney> i haven't tested the latest packages but i think it was last week or 2 weeks ago when i was working asac on it
[09:53] <pitti> ccheney: but wait
[09:53] <ccheney> Hobbsee: what is funny is from what i recall with the same cd it worked fine at the sprint
[09:53] <_StefanS_> infinity: well, all I got is a topic in #kubuntu-devel stating that if you're interested in helping with lpia and kde/qt you should say so :)
[09:53] <pitti> ccheney: if it doesn't even work with ifupdown and without n-m, then there's something more fundamental broken
[09:54] <pitti> ccheney: i. e. the kernel driver itself
[09:54] <ccheney> pitti: yea i think wpa's wext driver is broken personally
[09:54] <_StefanS_> infinity: so it got me kinda interested what it was all about :)
[09:54] <pitti> ccheney: for open network, ifupdown doesn't use wpasupplicant
[09:54] <ccheney> pitti: from what BenC told me the driver in the kernel is the same one that was in feisty which worked 100%
[09:54] <infinity> _StefanS_: I didn't set the topic. :)
[09:54] <ccheney> pitti: it does it you add the wpa-ssid foo to it
[09:54] <ccheney> pitti: from what i recall wireless-essid worked
[09:55] <Hobbsee> infinity: i think it's the adding lpia to the built arches, et
[09:55] <pitti> ccheney: ah, I see; and with plain 'essid' it works?
[09:55] <_StefanS_> infinity: probably Riddell did, but Hobbsee said you might know something about it :)
[09:55] <infinity> _StefanS_: But I imagine it's refering to the need to validate that source packages won't produce broken binaries when built on lpia.
[09:55] <ccheney> pitti: yea i think so, its been a while since i worked with it
[09:55] <pitti> ccheney: so iz wpasupplicant bug?
[09:55] <ccheney> pitti: most likely yes
[09:55] <pitti> now, that's a data point
[09:55] <infinity> _StefanS_: https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap/  <--- A few pointers at common problems to look for.
[09:55] <ccheney> and then on top NM is just a big mess and causes things to randomly break even for wired networks
[09:55] <pitti> ccheney: you can tryy by downgrading wpasupplicant to feisty
[09:55] <infinity> _StefanS_: If you keep a list of packages you've audited and give that Riddell, he may appreciate it.
[09:56] <_StefanS_> infinity: alright, thanks for the info
[09:56] <ccheney> pitti: i am going to when i have more time :)
[09:56] <pitti> ccheney: sure, just giving some triaging thoughts
[09:57] <_StefanS_> infinity: is the hardware even available yet?
[09:57] <ccheney> pitti: yea, from what i recall if i changed the wpa driver from wext to ipw it worked for an open network but gave ioctl errors since its not supposed to be used anymore (i think)
[09:57] <ccheney> pitti: or maybe not supported for ipw3945 i can't remember exactly
[09:57] <infinity> _StefanS_: Not so much, but any i686 machine can run "lpia" binaries.
[09:58] <_StefanS_> infinity: uhm ok
[09:58] <ccheney> pitti: it shows a lot of all 00's for AP bssid etc
[09:58] <ccheney> pitti: while trying to connect
[09:59] <_StefanS_> Hobbsee: is there any issues with nm ?
[09:59] <ccheney> _StefanS_: any... heh
[10:00] <_StefanS_> :)
[10:00] <ccheney> _StefanS_: the last update killed my network on my desktop
[10:00] <Hobbsee> _StefanS_: w.r.t?
[10:00] <_StefanS_> I know its far from perfect... remembering the LEAP patch I made a while back.. api is really screwed
[10:09] <doko> pitti: please accept valgrind (build on lpia)
[10:10] <pitti> not yet in queue, I'll try a bit later
[10:10] <cwillu> is there an #edubuntu-devel'ish thing?
[10:12] <highvoltage> cwillu: #edubuntu is for that
[10:12] <highvoltage> cwillu: well, #edubuntu is for everything edubuntu, atm
[10:12] <cwillu> k
[10:12] <cwillu> wondering if there's any interest in adding multiseat support
[10:14] <highvoltage> cwillu: there used to be a multiseat option in the debian-installer, I don't recall anyone using it before though
[10:15] <mvo> pitti: notification-daemon is uploaded too, yesterdays fix did not build
[10:16] <pitti> doko: still nothign in queue
[10:16] <pitti> mvo: ah, good
[10:16] <cwillu> weird, never noticed that before
[10:16] <cwillu> although I have a strange sense of deja-vue saying that
[10:23] <pitti> doko: oh, I accepted that one an hour ago already
[10:24] <doko> pitti: and mysql-dfsg-5.0 as well
[10:24] <pitti> that's the same category as mesa and qt...
[10:25] <doko> pitti: start one of them, so that you still have a free buildd
[10:28] <pitti> doko: that's not the reason; I don't want to change the current CDs any more than I have to
[10:34] <cwillu> hmm;  package multiseat is very hotplug'y
[10:39] <infinity> doko: Any idea how many iterations of this "exporting GSI file for language $i" thing there are in OOo?
[10:39] <infinity> doko: It's done 69 so far, and it's up to "tr"...
[10:41] <doko> infinity: until z :-)
[10:41] <doko> infinity, pitti: get a faster buildd or build on palmer
[10:41] <doko> be we are having this discussion for at least 12 months now ...
[10:42] <infinity> doko: Apparently, calc disabled the threaded build, so I'm not sure building on palmer would speed it up much.
[10:42] <doko> ohh no ...
[10:43] <doko> he didn't merge, he did take the debian package and did reapply *just some* things
[10:43] <infinity> No, he disabled it intentionally.  It apparently wouldn't build for him otherwise.
[10:43] <doko> not my problem
[10:43] <infinity> :)
[10:46] <pitti> good morning cjwatson
[10:47] <pitti> cjwatson: is this a reasonable time already for annoying you with tricky questions?
[10:47] <mvo> doko: what will python-central do nowdays when a local version of a python module is installed and it can not link the deb files to it? it used to error out, does it still do that?
[10:48] <doko> mvo: I didn't check for any serious python stuff for gutsy, sorry, so probably no change
[10:49] <mvo> doko: do you have a policy what to do with error like the one above? won't fix (users fault) or assign to python-central with some mechanism to make it fail more gracefully for the future?
[10:50] <doko> mvo: I can have a look how to fix it, but probably not for gutsy
[10:51] <mvo> doko: ok, I reassin with wishlist and subsribe myself, maybe I manage to get something done
[10:51] <sabdfl> i'm unable to connect to a WPA wifi network using Gutsy and an X60, is anyone around to suggest debugging tips?
[10:51] <pitti> seb128: is it just me, or did evince get painfully slow in gutsy for you as well?
[10:51] <doko> mvo: thanks
[10:52] <sabdfl> a T42 with IPW2200 is able to connect just fine
[10:52] <mvo> asac: ^----
[10:52] <seb128> pitti: using the ati driver?
[10:52] <pitti> seb128: nv here ATM
[10:52] <seb128> pitti: ok, so no
[10:52] <pitti> seb128: but I think it's the same with nvidia
[10:52] <seb128> should not
[10:52] <pitti> scrolling, switching windows, opening etc. takes some 5 seconds
[10:53] <pitti> in feisty it was basically instantaneous
[10:53] <highvoltage> sabdfl: are you using a ipw3945 wireless card? I've had a similar problem on gutsy earlier this week with a Lenovo T60, and the only thing that worked for me was rebooting (I modprobed -r the module and reloaded, and logged out and in again, but it didn't work)
[10:54] <seb128> pitti: the bug on ATI is due to XAA being slow I think
[10:54] <seb128> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=4320
[10:54] <ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned] 
[10:54] <sabdfl> highvoltage: rebooting didn't help in this case
[10:54] <sabdfl> i do think its a driver issue
[10:54] <seb128> pitti: you are the first to complain using a non-ati card :/
[10:54] <sabdfl> the wifi AP does see the mac address of my laptop, but the handshake doesn't complete
[10:55] <pitti> seb128: tracker it running here now \o/ it ate 130 MB of .cache/, but I/O during indexing was bearable, and it was pretty fast (half an hour for my entire ~ or so)
[10:55] <seb128> cool
[10:55] <seb128> pitti: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/122786 about evince slowness
[10:55] <ubotu> Launchpad bug 122786 in evince "[gutsy]  very hi cpu usage when scrolling pdf" [High,Triaged] 
[10:55] <mvo> it took 150min (then I switched the machine off) for me
[10:55] <mvo> aha! and now it is runing again (trackerd)
[10:55] <pitti> seb128: thanks
[10:56] <mvo> ~/.cache/tracker is "1,2G" ?!?
[10:57] <Fujitsu> Oh, neat, tracker just crashed while indexing.
[10:57] <mvo> seb128: can you think of a way to get rid of the ~/.cache/tracker when the package gets removed?
[10:58] <Nafallo> cjwatson: thanks :-)
[10:58] <seb128> mvo: no
[10:58] <pitti> mvo: packages munging ~ in maintainer scripts -> EBW
[10:58] <seb128> mvo: don't remove user configuration when they don't ask for?
[10:59] <pitti> mvo: you don't want that for shared home directories (multiple OS, network home)
[10:59] <mjg59> It took about 24 hours for me
[10:59] <mjg59> But now it's done, it's happily sitting there and taking no CPU
[10:59] <seb128> the way would be to write a "make space" tool
[10:59] <mjg59> Not even any wakeups
[10:59] <mvo> pitti: I know, but OTOH, having 1,2G of indexing data ....
[11:00] <mjg59> seb128: It'd be nice if the diskspace tool could tell you which applications were taking up space in ~
[11:00] <seb128> mvo: same issue for beagle, thumbnails, etc
[11:00] <infinity> mvo: That would be your domain.  update-* needs a way to drop hooks, so the next time I log in after removal, it can say "your syadmin as removed package-foo, and it wants to remove your .blah/whatever cache files, is that okay?"
[11:00] <infinity> mvo: But I suspect most of us would find that icky.
[11:00] <mvo> seb128: right, sure. this seems to be a bit much, no? it is a lot of data (and it did not even complete, I stoped it before)
[11:00] <seb128> mvo: still, I don't feel comfortable having the packaging system messing with user datas
[11:01] <mvo> infinity: that is entirely possible with the tools (and a very good idea)
[11:01] <seb128> what if you remove tracker to reinstall it?
[11:01] <mvo> seb128: sure, I think infinity came up with a nice idea, drop a interactive hook
[11:01] <seb128> I'm not sure that's a "very good idea"
[11:01] <mvo> seb128: drop a interactive hook thing on purge that gives the user the choice
[11:01] <infinity> I'd go so far as to call it "an idea", I'd prefer the adjectives be left out of it. :P
[11:01] <seb128> I would prefer a tool knowing about things usually take space
[11:02] <seb128> or maybe integration with baobab
[11:02] <mvo> seb128: the CleanupTool spec :) ? until that is implemented a noticiation seems to good compromise, I'm happy to add it myself
[11:02] <seb128> bah
[11:02] <pitti> what about automatic invalidation (IOW removal) when the data hasn't been updated for X days?
[11:02] <seb128> I feel we already have too many things popping up all over the place
[11:02] <mvo> I wouldn't argue over a couple of MB, but *1,2G*
[11:03] <infinity> It doesn't need to pop-up, I was just suggesting using the existing framework.
[11:03] <seb128> mvo: let's try to fix that in an elegant way?
[11:03] <infinity> A cleanup tool that has the same general hooks-on-purge makes just as much sense.
[11:03] <seb128> adding notifications is not the reply to everything
[11:03] <infinity> You get a list of "removed packages for which you have user data:", with a nice disk usage meter next to each.
[11:04] <seb128> I like this one ;)
[11:04] <seb128> and not only removed package
[11:04] <mvo> seb128: we have a framework for droping interactive user information on package interaction that is used e.g. in firefox to tell the user that he has to restart
[11:04] <seb128> we can list things like the thumbnail cache
[11:04] <seb128> mvo: yeah, and that "you need to reboot" who stayed in my panel the whole day yesterday is already annoying enough :p
[11:05] <mvo> thumbnail cache is 59mb for me (and I have a lot of fotos on my system)
[11:05] <mvo> seb128: easy, just reboot :P
[11:05] <seb128> 484M    .thumbnails
[11:05] <pitti> seb128: it would probably help already to teach programs to use ~/.cache consistently
[11:06] <pitti> it's much easier to handle that way for backup program exclusions, 'make space' tools, etc.
[11:06] <seb128> right
[11:06] <seb128> is .cache an xdg location or something like that?
[11:06] <seb128> or do you just suggest using it?
[11:06] <pitti> no idea
[11:07] <mvo> *shrug* I have no better solution short of writing the cleanup tool and that is unlikely for guttsy
[11:07] <pitti> but .config/ is some kind of 'common practice' at least (dunno about 'standard')
[11:07] <cjwatson> pitti: sure, have been up for a while, just quiet while catching up with stuff
[11:07] <cjwatson> you lot have been busy overnight
[11:07] <cjwatson> Nafallo: hmm?
[11:07] <pitti> mvo: I agree
[11:07] <Nafallo> cjwatson: wvdial :9-
[11:07] <pitti> mvo: if desktop session sees that your ~ is full, it could just invoke that tool
[11:07] <Nafallo> :-)
[11:07] <cjwatson> Nafallo: ah yes. seemed sensible
[11:08] <pitti> mvo: or we hook it into the existing g-v-m 'low space' test
[11:08] <mvo> pitti: yes, that would be really good
[11:08] <pitti> then we don't need to pop it up at package purge, but instead when it actually becomes relevant
[11:09] <pitti> cjwatson: so, this morning I looked into gfxboot{,-theme-ubuntu} and could not find where the actual menu entries and actions are defined; where does that happen? (I was looking into the reason for the broken "OEM" on desktop CDs)
[11:09] <mvo> I do not argue that point at all, a noticiation is bad, but as long as we do not have a CleanupTool the alternative it to just do nothing
[11:09] <cjwatson> pitti: http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
[11:09] <pitti> mvo: automatically getting that on most backup programs still sucks, of course
[11:09] <cjwatson> pitti: I already mentioned to you I'd fixed that last night ...?
[11:09] <cjwatson> or at least I thought I had
[11:09] <pitti> but with a common standard to use ~/.cache or so that could become a default in backup programs, too
[11:10] <mvo> absolutely
[11:10] <pitti> cjwatson: I didn't see that from you; thanks, you rock!
[11:10] <cjwatson> pitti: it was just pointing at /install/vmlinuz and /install/initrd.gz rather than /casper/...
[11:10] <cjwatson> annoying difference in the live CD layout
[11:12] <seb128> pitti: .config is an xdg location ;)
[11:12] <pitti> yay
[11:12] <pitti> seb128: oh, .config, right; does xdg define something like .cache?
[11:14] <seb128> pitti: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
[11:14] <seb128> "$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used."
[11:14] <pitti> seb128: I already had .cache in my backup exclusions, so some other package used it, too, at least
[11:14] <pitti> rock
[11:15] <Nafallo> pitti: thanks for closing some of my bugs on ubuntu-meta :-)
[11:15] <pitti> Nafallo: I didn't close any AFAIR?
[11:16] <Nafallo> bug #61620
[11:16] <ubotu> Launchpad bug 61620 in ubuntu-meta "ppp* in -standard might be better as Recommends" [Undecided,New]  https://launchpad.net/bugs/61620
[11:16] <Nafallo> for example :-)
[11:16] <pitti> Nafallo: credit goes to cjwatson :)
[11:16] <Nafallo> ah, oki :-)
[11:17] <Nafallo> cjwatson: thanks for that to then :-). I'll close some of them off.
[11:17] <pitti> closed, thanks
[11:17] <pitti> Depends: w3m is also questionable as long as it doesn't even work with Launchpad
[11:17] <cjwatson> heh, pitti and I clashed in closing that
[11:18] <cjwatson> w3m has many uses other than Launchpad
[11:18] <pitti> (arguably this should be fixed in LP, but it's long known and it didn't happen yet)
[11:18] <cjwatson> and w3m works fine with Launchpad anyway
[11:18] <cjwatson> I use it frequently
[11:18] <infinity> cjwatson: There's no internet outside of launchpad, you watch your tongue.
[11:18] <pitti> cjwatson: with authentication?
[11:18] <Nafallo> hmm. dosfstools is still in standard? :-)
[11:18] <cjwatson> pitti: yes
[11:18] <pitti> hm, not last time I tried it, weird
[11:18] <cjwatson> Nafallo: yes. I was less sure about that. also you're nagging :-P
[11:18] <Nafallo> I'm closing off bugs ;-)
[11:19] <infinity> pitti: The number one and two reasons to have a text-based browser installed by default are (1) setting up routers with web interfaces to use your web browser to (2) access google to find out why you have no X, and no firefox.
[11:19] <pitti> infinity: I don't question that
[11:20] <cjwatson> Nafallo: I suspect that in reality there are a lot more FAT filesystems out there than reiserfs filesystems ...
[11:20] <infinity> Launchpad sometimes having questionable browser support is something best brought up with them, really. :)
[11:21] <infinity> (I know that, for the longest time, it was crap in IE, but when I was forced to work in Windows, I just installed Firefox rather than file bugs, because I was lazy)
[11:21] <pitti> infinity: my concern is: (1) it still doesn't work with Launchpad (still tried it again, and I keep gettnig an "unsecure cookie thing blabla rejected", and (2) a Recommends: would be sufficient IMHO
[11:21] <pitti> I guess cjwatson has a more carefully written configuration which unbreaks LP
[11:21] <infinity> Could be the wildcard cookie.
[11:22] <infinity> That might actually be a w3m bug.
[11:22] <infinity> Or LP's doing wildcard cookies in very sketchy ways.
[11:22] <pitti> I tried three text browsers, and only one has worked with LP OOTB so far (not sure whether it was elinks or lynx)
[11:22] <pitti> I played around with that for apport reporting bugs on Xless servers
[11:23] <Nafallo> cjwatson: yes. and usbsticks often use it... I'll change the bug to mention reiserfs and close it off :-)
[11:23] <infinity> Hrm, "the cookie was rejected for security reasons", or something... Flashed by too quickly...
[11:23] <pitti> infinity: xactly (I couldn't read it properly either)
[11:23] <infinity> pitti: lynx tends to work with everything, it's just got the ugliest rendering of the three.
[11:23] <cjwatson> pitti: I've dropped telnet to Recommends, but there's a bug suggesting it should use telnet-ssl instead, which interoperates in both directions - any thoughts?
[11:23] <pitti> unfortunately, yes
[11:23] <cjwatson> even Win98 ships an SSL-capable telnet
[11:24] <infinity> cjwatson: I don't see how it hurts, since we ship libssl anyway, for other reasons.
[11:24] <cjwatson> telnet-ssl is in universe, though, so would need an MI$
[11:24] <cjwatson> MI
[11:24] <cjwatson> ARGH MIR
[11:24] <Nafallo> cjwatson: oh, btw. Nafallo Bjlevik now :-)
[11:25] <infinity> cjwatson: It's netkit code, do we really need an MIR to replace netkit-telnet with netkit-telnet-ssl?
[11:25] <Nafallo> for future reference :-)
[11:25] <infinity> cjwatson: Either way, it'd be a no-brainer MIR.
[11:25] <asac> sabdfl: what is X60? ipw3945?
[11:25] <cjwatson> Nafallo: legal name change?
[11:25] <cjwatson> it's so hard to keep track
[11:25] <pitti> cjwatson: we could demote netkit-telnet in exchange, though
[11:26] <sabdfl> asac: ipw3945
[11:26] <Nafallo> cjwatson: yepp :-). no problem, just a heads up :-)
[11:26] <cjwatson> pitti: let's do that after tribe-4 then, if you're happy
[11:26] <cjwatson> Nafallo: mkay, cool
[11:26] <pitti> cjwatson: I am, yes; especially since netcat is a "good enough" drop-in for telnet anyway :)
[11:26] <infinity> pitti: Am I fair in my assessment of "swapping one netkit telnet for the other netkit telnet is a MIR no-brainer"?
[11:27] <pitti> infinity: yes, you are (I'll still look on the packages.qa and bugs page, and CVEs)
[11:27] <asac> sabdfl: it worked for you before yesterdays upgrade?
[11:27] <pitti> but I doubt that it's much different from telnet's
[11:28] <infinity> pitti: Two different Debian maintainers for the two different netkit packages, but I'd be surprised if there were any real differences.
[11:29] <pitti> oh, ooo is at 'xh' now
[11:29] <pitti> still two Chinese variants to go, I think
[11:30] <Nafallo> hmm. alsa is still depend of minimal...
[11:32] <mvo_> pitti: if you look at the queue next time, could you please approve notification-daemon :) ?
[11:32] <cjwatson> Nafallo: yes, I don't trust recommends of minimal to work right
[11:32] <pitti> mvo_: yet another one?
[11:32] <cjwatson> minimal is a subtle seed, quick to anger
[11:32] <Nafallo> cjwatson: maybe a move to standard or desktop would suffice?
[11:32] <pitti> mvo_: I just beat it through publisher/queue-builder/ and all the manual stuff soyuz forces you to do nowadays
[11:32] <pitti> hey Keybuk
[11:32] <Keybuk> heyhey
[11:33] <pitti> mvo_: 0.3.7-1ubuntu5 just got built
[11:33] <mvo_> pitti: no, the one I uploaded this morning, I was just wondering that I did not get a accept mail
[11:33] <mvo_> pitti: cool!
[11:33] <iwj> Morning everyone.
[11:33] <pitti> hey iwj
[11:33] <asac> sabdfl: if you have latest network-manager (0.6.5-0ubuntu9) and it still fails to connect, then I would like to do some manual wpa-supplicant tests
[11:33] <iwj> Looks like they fixed my phone line.
[11:33] <pitti> iwj: so your network's back?
[11:33] <asac> iwj: welcome back
[11:33] <mvo_> hey Keybuk, iwj!
[11:34] <sabdfl> asac: i think it's a wpa problem, or a driver problem
[11:34] <cjwatson> Nafallo: no.
[11:34] <sabdfl> is there a way to debug that?
[11:34] <cjwatson> minimal: * alsa-base # needed for proper hardware detection (hotplug/blacklist.d, modprobe.d)
[11:34] <sabdfl> i'm not near the network now, it's a home network
[11:34] <cjwatson> needs to be installed early
[11:34] <asac> sabdfl: we tried to fix ipw3945 for wpa in network-manager ubuntu9 upload
[11:35] <asac> sabdfl: however there was a bad ubuntu8 upload just a few hours before ... in case you catched.
[11:35] <Nafallo> cjwatson: ouch :-/. so I'd guess that would need to dep-wait trusty recommends then :-)
[11:36] <ogra> mvo, ping
[11:36] <sabdfl> asac: ok, i'm up to date now, will try later
[11:36] <asac> sabdfl: thanks ... are you at millbank?
[11:36] <sabdfl> no, cape town
[11:36] <asac> ah ok.
[11:38] <mvo> ogra: pong (I'm leaving for some early lunch now, but I will be back in ~30min)
[11:39] <ogra> mvo, ok, seems apt fails on another error now while building an ltsp chroot
[11:40] <mvo> ogra: can you please give me the buildlog into a pastebin? I have a look
[11:41] <cjwatson> ogra: did you see my pointers on fixing the /cdrom problem?
[11:41] <ogra> buildlog: http://people.ubuntu.com/~ogra/syslog_tribe4
[11:41] <ogra> fix ? : http://people.debian.org/~terpstra/message/20070805.002437.f94fb48b.en.html
[11:41] <ogra> cjwatson, nope
[11:41] <infinity> pitti: The OOo build should be almost done... I think.
[11:41] <infinity> pitti: It's up to "zu" in the language list, at least...
[11:41] <mvo> ogra: thanks, checking
[11:41] <pitti> infinity: still grinding at zh_TW AFAICS
[11:41] <pitti> or that
[11:41] <pitti> infinity: do you have an idea what still comes after that?
[11:42] <mvo> ogra: that looks reasonable, I invetigate
[11:42] <mvo> ogra: but lunch first :)
[11:42] <ogra> cjwatson, but it seems http://people.debian.org/~terpstra/message/20070805.002437.f94fb48b.en.html is my prob
[11:42] <infinity> pitti: Nope, but I can't wait to find out!
[11:42] <ogra> mvo, thanks, didnt want to hold you up :)
[11:42] <cjwatson> ogra: but you aren't using copy:, are you?
[11:42] <ogra> cjwatson, i was guessing the file:/// protocol might
[11:42] <cjwatson> 22:01 <cjwatson> ogra: I'd recommend looking at the bit of base-installer/debian/postinst that writes out /target/etc/apt/apt.conf.d/00NoMountCDROM
[11:43] <cjwatson> 22:01 <cjwatson> ogra: I reckon your problem is that at some point apt unmounts /cdrom
[11:43] <cjwatson> 22:02 <cjwatson> ogra: if you do that same bit of configuration in the chroot you build for the duration of building it, it should stop things going haywire
[11:43] <cjwatson> 22:02 <cjwatson> ... probably
[11:43] <cjwatson> file: != copy:
[11:43] <ogra> k
[11:45] <cjwatson> sabdfl: what do you think of bug 109064?
[11:45] <ubotu> Launchpad bug 109064 in casper "Boot-up option 'Start or install Ubuntu' scares new users" [Medium,Confirmed]  https://launchpad.net/bugs/109064
[11:46] <sabdfl> interesting
[11:47] <sabdfl> cjwatson: how would you feel about just "Start Ubuntu" ?
[11:47] <sabdfl> then making sure that Ubiquity explains what it's about to do, which i think it does very well already
[11:47] <cjwatson> it would be fine with me - ISTR it was originally "or install" so that we could emphasise the new installation functionality
[11:47] <cjwatson> but it's possible we've made a big enough deal of that now :-)
[11:48] <cjwatson> I'm sure I'd get bugs either way; I sort of sympathise with the "this is scary" bit though
[11:51] <infinity> Noooooo.
[11:51] <infinity> pitti: dpkg-genchanges: failure: cannot open upload file ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translations.tar.gz for reading: No such file or directory
[11:51] <pitti> infinity: FTBFS?
[11:51] <pitti> ! ! ! *headdesk*
[11:51] <ubotu> Sorry, I don't know anything about headdesk* - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[11:52] <infinity> ubotu: Stay out of this.
[11:52] <infinity> pitti: Double-U.  Tee.  Eff.
[11:53] <infinity> pitti: Do we get to blame you, or calc?
[11:53] <infinity> pitti: (On the plus side, if it needs to be requeued, I'll make sure it ends up on palmer, and we'll see if that makes a speed difference)
[11:54] <pitti> +       $(MAKE) -f debian/rules -j$(shell expr $(AVAIL_CPUS) + 1) $(STAMP_DIR)/gsi-export-parallel
[11:54] <pitti> +       : # tell pkgstriptranslations that the translations are built
[11:54] <pitti> +       -ls -l ../$(PKGSOURCE)_*_translations.tar.gz
[11:54] <pitti> +       rm -f ../$(PKGSOURCE)_*_translations.tar.gz
[11:54] <pitti> ????
[11:54] <infinity> ... what?
[11:55] <infinity> That must be for -l10n...
[11:55] <pitti> gsi-export: target
[11:56] <pitti> binary-indep: $(GSI_EXPORT_STAMP) $(STAMP_DIR)/binary-indep
[11:56] <infinity> ls -l ../openoffice.org_*_translations.tar.gz
[11:56] <infinity> -rw-r--r-- 1 root root 36397 Aug  8 01:21 ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translati
[11:56] <infinity> ons.tar.gz
[11:56] <infinity> rm -f ../openoffice.org_*_translations.tar.gz
[11:56] <pitti> there
[11:56] <pitti> but WTF is it doing that?
[11:56] <pitti> doko: ^ still remember that?
[11:56] <mjg59> To spite you?
[11:57] <infinity> I'm afraid I don't grok the logic either...
[11:57] <pitti> infinity: look at rules, it seems it does gsi-export when building ooo, and not when building ooo-l10n
[11:57] <doko> it ensures that the tarballs are generated, after the translations are exported.
[11:57] <pitti> it seems it should do the deletion the other way round
[11:58] <doko> -l10n doesn't export anything
[11:58] <pitti> since the amd64 debs are already in the archive and are uninstallable due to -common, we have nailed 2.3 on our testicles now for tribe 4
[11:58] <infinity> pitti: A lovely mental image, thanks.
[11:59] <pitti> infinity: I think I'll just comment out the rm now and screw translation export for this round
[11:59] <infinity> doko: So, since we're calc-free, what needs fixing here?
[12:00] <doko> infinity, pitti: let me look
[12:00] <pitti> doko: chinstrap:~ccheney/incoming, btw
[12:00] <doko> pitti: a new one?
[12:01] <pitti> doko: no, the current one
[12:01] <cjwatson> bug 124825 is an interesting idea
[12:01] <ubotu> Launchpad bug 124825 in casper "Live-cd should notify the user of prolonged boot time" [Undecided,New]  https://launchpad.net/bugs/124825
[12:04] <doko> pitti: when does pkgstriptranslations run? apparently it currently does not run with dh_builddeb -i?
[12:04] <infinity> doko: It runs from "dpkg-deb -b"
[12:04] <pitti> it hasn't changed recently
[12:05] <infinity> doko: Which would be a fork of dh_builddeb, yes.
[12:05] <pitti> doko: it should run on -i, too
[12:05] <doko> : # tell pkgstriptranslations that the translations are built
[12:05] <doko> ls -l ../openoffice.org_*_translations.tar.gz
[12:05] <doko> -rw-r--r-- 1 root root 36397 Aug  8 01:21 ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translations.tar.gz
[12:06] <doko> it's correct, because the translations are not yet exported
[12:06] <doko> but it doesn't run for -i
[12:06] <infinity> Err, really, it just runs every time dpkg-deb is invoked.
[12:07] <doko> apparently it doesn't. after the removal of the wrong tarball, dh_builddeb -i is invoked
[12:11] <cjwatson> doko: apt-get source pkgbinarymangler - it doesn't check -i and it couldn't because that's a debhelper flag which isn't passed to dpkg-deb
[12:11] <cjwatson> all -i there controls is which binary packages have dpkg-deb run on them
[12:11] <infinity> Okay, I'm incredibly confused by this, though.
[12:11] <cjwatson> it could go wrong if the relevant binary package isn't Architecture: all
[12:11] <asac> doko: liborbit2-dev is not yet avail on lpia ... will try in a few hours again
[12:11] <pitti> NO_PKG_MANGLE=go-away
[12:11] <infinity> I see nowhere in my dpkg-deb wrapper, or in pkgstriptranslations, where it would exit silently without printing a message.
[12:12] <pitti> ^ from the build log
[12:12] <doko> pitti: I have a version ready for upload which just disables the gsi export
[12:12] <infinity> pitti: Even NO_PKG_MANGLE prints a warning from dpkg-deb, though.
[12:12] <cjwatson> setting NO_PKG_MANGLE would certainly make pkgstriptranslations not run
[12:12] <pitti> doko: ah, great; will that also disable the gsi build, to save some hours of buildd time?
[12:12] <pitti> cjwatson: but that shuold leave a message at least
[12:12] <doko> pitti: this is for the internal dpkg call, which should be fine
[12:12] <mvo> ogra: just read backlog, let me know if the fix from colin helped
[12:12] <doko> internal to the OOo build
[12:13] <pitti> doko: thanks a lot
[12:13] <doko> pitti: yes, but I would be glad to see the real problem with the gsi-export stuff ...
[12:13] <pitti> doko: so, if that also stops the lengthy 'localize' loop, it would be awesome; if not, *shrug&
[12:13] <doko> pitti: it does. one liner
[12:13] <pitti> doko: real problem> indeed, we need to fix that anyway
[12:14] <infinity> pitti: I'll admit to being incredibly confused at this point.
[12:15] <infinity> pitti: Can you seen anywhere in our codepath where it can exit (or run, for that matter) without printing to the log?
[12:15] <pitti> infinity: if it's not called with -b
[12:15] <pitti> as first argument
[12:15] <infinity> pitti: Well, okay, but then it won't build a deb either.
[12:15] <infinity> OH!
[12:15] <infinity> DUH.
[12:16] <infinity> -Zbzip2 -b
[12:16] <infinity> I'm retarded.
[12:16] <infinity> Fix on the way.
[12:16] <infinity> doko: Don't bother uploading.
[12:16] <doko> infinity: do you still have the build?
[12:16] <infinity> doko: I'll just requeue on palmer, so the GSI stuff goes faster.
[12:16] <pitti> infinity: could still be a net gain to upload doko's and skip the GSI build?
[12:17] <doko> infinity: you can make the gsi stuff even more faster
[12:17] <pitti> time is pressuring now
[12:17] <infinity> pitti: OOo-l10n built in 5 hours on palmer, which is essentially the same as OOo-i386...
[12:17] <pitti> infinity: wow, that's a difference; 5 hours sounds ok
[12:17] <doko> infinity, yes, but without doing the gsi export
[12:17] <pitti> ah, right
[12:17] <infinity> doko: Oh, so -i386 is still quite a bit slower?
[12:17] <infinity> Your call.
[12:18] <infinity> I'm fixing the mangler now, though.
[12:18] <infinity> Before I forget.
[12:18] <pitti> doko: please upload your version then
[12:18] <doko> gutsy chroots are non-functional
[12:18] <doko> on ronne
[12:19] <pitti> doko: you might succeed with a fakechroot
[12:19] <pitti> doko: ~pitti/bin/retracer-login-i386
[12:19] <pitti> doko: or put a debdiff somewhere, and I'll try
[12:19] <pitti> (or just tell me what to change)
[12:19] <doko> generating debdiff in feisty
[12:20] <infinity> In fact, the manpage led me to believe that -b|--build had to be the first argument.
[12:20] <pitti> doko: do you need to build the source on gutsy actually?
[12:20] <infinity> Hrmph.
[12:20] <doko> pitti: ronne:~doko/ooo/23/ooo.debdiff
[12:20] <infinity> Lying documentation, for the loss.
[12:21] <doko> pitti: ok to upload?
[12:22] <pitti> doko: oh, sure
[12:22] <pitti> doko: I thought I should build the source now, misunderstood
[12:23] <doko> uploaded
[12:24] <pitti> infinity: we still have 45 minutes (/me wishes build-from-accepted would actually work...)
[12:25] <pitti> c'mon, appear in the queue
[12:25] <infinity> pitti: It should work.  Run the queue-builder ASAP after it hits queue/DONE.
[12:25] <infinity> pitti: Don't bother with the publisher at all.
[12:26] <pitti> queue/DONE -> after 'q -Q unapproved accept openoffice'?
[12:26] <infinity> pitti: Yeah.  Oh.  Hrm.
[12:26] <pitti> there it is, accepted
[12:26] <infinity> The unaccept workflow may mess what that.
[12:26] <infinity> Did it go to accepted, or to done?
[12:26] <infinity> In normal operation, sources go straight to "done" now, but the unaccpted thing might put a kink in that.
[12:27] <pitti> 'done'?
[12:27] <infinity> unapproved, even.
[12:27] <pitti> infinity: in /srv/launchpad.net/builddmaster?
[12:27] <infinity> No, sources.
[12:27] <infinity> So, the actual done queue.
[12:27] <mjg59> jamiemcc: Tracker-search-tool doesn't do live updates?
[12:27] <pitti> infinity: that's above my head ATM, I'm afraid
[12:27] <infinity> pitti: I'm looking. :)
[12:28] <infinity> Damn.
[12:28] <jamiemcc> mjg59: what do you mean?
[12:28] <infinity> pitti: The unapproved/frozen workflow breaks build-unpublished-sources, so we'll need to publish. :/
[12:28] <pitti> 'k, publisher started
[12:29] <pitti> infinity: how very nice that this is basically the only use case where b-f-a is actually important :)
[12:29] <mjg59> jamiemcc: If I perform a search and get no hits, then create a file that matches the criteria, the search results don't get updated
[12:29] <mjg59> I need to trigger a new search
[12:29] <jamiemcc> mjg59: yes that meeds to wit for XESAM
[12:29] <jamiemcc> wait
[12:29] <jamiemcc> XESAM wil define live query updates
[12:30] <infinity> pitti: Of course, I still give 20-to-1 odds that we can remove the locking from queue-builder and run it in parallel with the publisher.
[12:30] <infinity> pitti: Feeling adventurous? ;)
[12:31] <pitti> infinity: I discussed that with cprov yesterday
[12:31] <infinity> pitti: (Note that the source in question has a publishing record already, since that's the first thing the publisher does... And that's all the queue-builder needs to make a queue entry)
[12:31] <pitti> infinity: and I still fail to see how that shared lock should prevent the 'fetch build dep' race that it was meant to avoid
[12:31] <pitti> infinity: right, I agree; if we could run q-b now, that would be awesome
[12:32] <ogra> cjwatson, mvo, i dont think its apt unmounting the CD... apparently i just cant see it ijside the chroot anymore
[12:32] <pitti> infinity: AFAICS, the worst that can happen is that the archive updates while a buildd apt-get updates and fetches b-deps, right?
[12:32] <infinity> pitti: The race is that packages will get un-dep-waited based on binaries that have publishing records, but aren't on-disk.
[12:32] <infinity> pitti: But, oh well, they just get auto-dep-waited again. :/
[12:32] <pitti> yep
[12:32] <pitti> it would be incredibly useful for times like this
[12:33] <ogra> i get the same error building a client chroot manually from CD even the cd is still mounted on the server
[12:33] <mvo_> ogra: so the issue went away magically?
[12:33] <ogra> no
[12:33] <mvo_> ogra: what do I have to run to reproduce it?
[12:33] <ogra> its just not apt's fault i think, somehow the mounting doesnt work as it used to
[12:33] <cjwatson> ogra: I mean unmounting /cdrom inside your chroot
[12:34] <cjwatson> which is equivalent to "can't see it inside the chroot any more"
[12:34] <ogra> cjwatson, it isnt even mounted
[12:34] <cjwatson> doesn't ltsp-client-builder bind-mount it?
[12:34] <cjwatson> it seemed to me from the code that it was supposed to
[12:35] <ogra> oh, hmm, figth
[12:35] <ogra> err right
[12:35] <ogra> the manage mirror plugin does that
[12:35] <cjwatson> and this is exactly why base-installer configures apt to turn off any auto-mounting/unmounting it might try to do
[12:36] <cjwatson> you seem to be sitting in the exact same use case, so I'd have thought the same code ought to work :)
[12:36] <cjwatson> (not that I've reproduced your problem - no Edubuntu images handy right now)
[12:37] <ogra> yeah, seems like the same issue
[12:37] <Enola_Gay> hi all
[12:38] <Enola_Gay> Is there any list which patches are already integrated of this Blueprint https://wiki.ubuntu.com/power-management-in-Ubuntu ?
[12:38] <Enola_Gay> Will there be a separate HPET kernel?
[12:41] <infinity> pitti: Fixed mangler incoming.
[12:42] <pitti> infinity: cheers
[12:42] <pitti> infinity: I guess it'll be built and in the archive before OO.o comes that far :)
[12:42] <infinity> pitti: Yeah, but the build won't magically update itself.
[12:42] <pitti> ah, true
[12:42] <pitti> anyway, shouldn't matter
[12:42] <infinity> (I could upgrade the chroot during the build, so we can make sure my fix worked. :))
[12:43] <pitti> 3v1l :)
[12:43] <infinity> Also, I'm very tempted to give this thing en epoch and start renumbering it... being at version "40" already is a bit odd. :)
[12:44] <pitti> infinity: can you please quickly answer on #soyuz?
[12:44] <cjwatson> versioning> works for partman
[12:45] <cjwatson> if your versions are really just a counter and there are no compatibility implications, then who cares ...
[12:45] <infinity> ugh, I hate eyeballing a debdiff when I've changed indenting...
[12:45] <infinity> Can you feed debdiff diff arguments, so it'll ignore whitespace?
[12:45] <cjwatson> with a few packages I've been bumping a minor (once, as in gfxboot-theme-ubuntu, or twice, as in ubiquity) for each Ubuntu release cycle as a reminder
[12:46] <cjwatson> infinity: it generally uses interdiff, and doesn't have the facility to pass extra options to it
[12:46] <cjwatson> interdiff does have a -b option, so you could just hack debdiff temporarily
[12:46] <infinity> cjwatson: Given the ubuntu-nativeness of it all, I would have preferred 6.06.0, 6.06.1, etc, and then 6.10.0 when we opened a new release, os some such.  Since the package really only exists in buildd chroots, it becomes obvious which version is used where.
[12:47] <cjwatson> yeah. same for livecd-rootfs
[12:47] <infinity> Point.
[12:47] <Enola_Gay> Are there any plans to ship the windows installer http://wubi-installer.org/index.php with Gutsy CDs?
[12:48] <pitti> infinity: is there a slow/fast buildd for amd64? (just to avoid another potential pitfall)
[12:48] <cjwatson> Enola_Gay: hoping to, yes
[12:48] <infinity> pitti: Nah, they're all the same.
[12:48] <infinity> Oh, crap.
[12:48] <cjwatson> Enola_Gay: working on the infrastructure for it
[12:48] <infinity> That's why I didn't want a new upload. :/
[12:48] <Enola_Gay> cjwatson: cool, thanks
[12:48] <infinity> Cause we have to build on *all* arches again.
[12:48] <infinity> Grr.
[12:49] <infinity> I guarantee palmer would build the last version faster than our slowest arch will build the new version.
[12:49] <infinity> Note, selecting patchutils for regex interdiff
[12:49] <infinity> Is that... New?
[12:49] <cjwatson> Package: patchutils
[12:49] <cjwatson> Provides: interdiff, extractdiff
[12:49] <mvo_> infinity: not new, I'm sure
[12:49] <cjwatson> isn't it just regular provides-following
[12:49] <cjwatson> ?
[12:50] <infinity> Yeah, apt didn't used to auto-install provides... I'm sure of it.
[12:50] <infinity> Maybe I'm on crack.
[12:50] <pitti> infinity: no pkgbinarymangler in the queue FYI
[12:50] <mvo_> usualy I remember the pain^Whacking on apt
[12:50] <infinity> (Note that when I use the term "new", I mean "since potato")
[12:50] <infinity> pitti: Yeah, I know.
[12:50] <Amaranth> iirc as long as only one thing provides it it just does it
[12:50] <Amaranth> otherwise it gives you a list and makes you hate it
[12:52] <infinity> pitti: Should be in the queue in 3 mins (on the :55 queue run)
[12:55] <ogra> cjwatson, doesnt help :/
[12:55] <infinity> Oh, FFS.
[12:56] <infinity> pitti: Don't accept it.
[12:56] <ogra> also i see it retrieving Release.gpg and Release .... then i get the "Hash Sum mismatch" error
[12:58] <mjg59> seb128: When you have a chance, could you possibly apply the patch from http://bugzilla.gnome.org/show_bug.cgi?id=370937 ? The gstreamer stuff is already in the archive
[12:58] <ubotu> Gnome bug 370937 in mixer "Exessive CPU Utilisation" [Minor,New] 
[12:58] <pitti> infinity: palmer grabbed OO.o, so you can un-MANUAL the others
[12:59] <infinity> pitti: Don't accept my upload.
[12:59] <infinity> pitti: I'm a retard.
[12:59] <pitti> infinity: right, I won't
[12:59] <pitti> (it's not in the queue anyway, so I can't reject)
[12:59] <infinity> ORIGINAL_ARGUMENTS=$@
[12:59] <infinity> [ much code to walk and destroy $@ ] 
[01:00] <infinity> dpkg-deb $@
[01:00] <infinity> \o/
[01:00] <pitti> heh
[01:01] <mvo_> ogra: I see some strange hashsum error here currently, I investigate, you can run apt with -o Debug::Hashes=true
[01:01] <ogra> will try to
[01:01] <pitti> infinity: rejected, to prevent myself from doing stupid things without looking
[01:03] <mvo_> ogra: add also -o Debug::pkgAcquire::Auth=true
[01:03] <ogra> eek
[01:03] <ogra> anything else ?
[01:04] <ogra> running
[01:04] <pitti> infinity: I love the buildd time of OO.o on ia64; can't we use the same stub package on the other arches? (would anyone notice the difference?)
[01:04] <infinity> I wouldn't notice the difference.
[01:04] <infinity> I think I use OOo about once a year.
[01:07] <ogra> mvo_, http://paste.ubuntu-nl.org/33017/
[01:07] <infinity> pitti: Alright, better one on the way.  One that kinda works, even.
[01:16] <mvo_> ogra: thanks, that looks good, checking it now
[01:30] <ogra> i'm sure now that zthe cdrom stays mounted btw
[01:30] <infinity> pitti: Feel free to approve the new mangler, I even tested it.  (shock and horror)
[01:31] <pitti> infinity: TESTED! don't spoil our development procedures
[01:31] <infinity> pitti: Sorry to disappoint.
[01:34] <Amaranth> OOo? Is that the thing in the Office menu I've never opened? :)
[01:34] <pitti> Amaranth: it's the thing that pops up when friends mail you some jokes in powerpoint format
[01:35] <Amaranth> Oh, right
[01:35] <Amaranth> It usually crashes shortly after, too
[01:45] <stgraber> pitti: I won't be around this afternoon, can you add the ISOs on the tracker when they are built ?
[01:47] <infinity> pitti: Or, should I just approve it myself? :P
[01:49] <ogra> mvo_, i wonder if its zlib's fault ... it seems to only happen with the .gz files
[01:49] <mvo_> ogra: oh? interessting
[01:50] <ogra> mvo_, well, guessing by the debug output :)
[01:52] <seb128> mjg59: I can do that, thanks for pointing it ;)
[01:54] <mjg59> seb128: Thanks!
[01:54] <seb128> np
[01:58] <Keybuk> seb128: so, err, I found out why my computer is slow by reading the Tribe 4 freeze announcement
[01:58] <Keybuk> is tracker supposed to be using all my CPU, I/O and memory?
[01:58] <jamiemcc> keybuk: no its the kernel's fault
[01:58] <mjg59> Keybuk: Some of the behaviour seems to be due to some change in 2.6.22
[01:59] <Keybuk> it's polling and getting SIGCHLD?
[01:59] <jamiemcc> keybuk: see:http://jamiemcc.livejournal.com/9520.html
[01:59] <mjg59> Keybuk: It has two child threads
[01:59] <pitti> stgraber: will do
[01:59] <pitti> infinity: I'll get to that (just want to eyeball the debdiff)
[01:59] <mjg59> They're the ones actually using the CPU
[02:00] <Keybuk> mjg59: what's the general cause?
[02:01] <pitti> infinity: nothing in queue, did you accept it already?
[02:01] <mjg59> Keybuk: Of what?
[02:02] <pitti> infinity: please flip rothera and vernadsky back on, I need some other builds
[02:02] <pitti> infinity: nevermind, I did it myself
[02:02] <Keybuk> mjg59: tracker slowness?  or is the change in behaviour that's broken it unknown?
[02:03] <mjg59> Keybuk: Unknown
[02:04] <mjg59> Once the indexing is completed, it's fine
[02:04] <Keybuk> interesting
[02:04] <Keybuk> the cpu usage seems to be all poll/eintr for sigchld ?
[02:04] <jamiemcc> indeixng is 5 x faster on feisty when indexing same files
[02:04] <mjg59> Keybuk: Have you straced the children?
[02:04] <Keybuk> no, just the parent; killed it before I knew there were children
[02:04] <pitti> jamiemcc: I think we don't explicitly disable tracker on the live system; but I hope that won't matter much because home is basically empty anyway?
[02:05] <mjg59> Keybuk: The CPU use is in the children
[02:05] <jamiemcc> pitti: hopefully
[02:05] <mjg59> Keybuk: You realise that thread CPU use will all be assigned to the parent now, right?
[02:05] <Amaranth> jamiemcc: the gentoo thing you link to in your blog can't be it
[02:06] <Amaranth> jamiemcc: because i still get really fast disk speeds with hdparm
[02:06] <jamiemcc> amaranth: you might be right
[02:06] <jamiemcc> but heavy disk io is a problem for these newer kernels
[02:07] <Amaranth> ubuntustudio-sounds |        0.5 | http://archive.ubuntu.com gutsy/main Packages
[02:07] <Amaranth> ubuntustudio-sounds |        0.5 | http://archive.ubuntu.com gutsy/universe Sources
[02:07] <tsmithe> is there an admin that can help me figure out that oddity?
[02:07] <Amaranth> anyone know what's up with that?
[02:07] <tsmithe> Amaranth, you just beat me to it :p
[02:07] <Amaranth> tsmithe: you take too long :)
[02:08] <tsmithe> i was waiting so as not to interrupt ;)
[02:11] <pitti> Amaranth, tsmithe: fixed, thanks for pointing out
[02:11] <pitti> (probably a mistake when binary-NEWing the packages)
[02:11] <tsmithe> thanks pitti; do you know how that happened?
[02:11] <tsmithe> ahh ok
[02:11] <Fujitsu> How is it possible for that to happen?
[02:11] <Fujitsu> Shouldn't there be some logic to forbid that?
[02:12] <pitti> Fujitsu: forgetting to override the component to universe when NEWing it
[02:13] <pitti> it appears on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
[02:13] <pitti> so sooner or later we'd have caught and fixed it anyway
[02:14] <tsmithe> why don't we just set the component in debian/control's Section?
[02:14] <Fujitsu> I could see how it was done, I just thought there would be some check in Soyuz to disallow it.
[02:14] <Fujitsu> tsmithe: Debian imports, mainly.
[02:14] <tsmithe> mmhmm
[02:15] <cjwatson> also components in Section tend to get out of sync as we move stuff around
[02:15] <pitti> tsmithe: that's possible
[02:15] <cjwatson> we decided way back before warty not to rely on that
[02:15] <pitti> tsmithe: just that nobody actually does it, and it's not consistent anyway
[02:15] <cjwatson> although as pitti says, component in Section will set the default for Soyuz queue processing
[02:16] <tsmithe> ok then, makes sense
[02:39] <infinity> cjwatson: Do we have an open soyuz bug, by any chance, about defaulting binary component overrides to match source components on NEW binaries?
[02:41] <Hobbsee> asac: yesterday's update of the network mangler doesnt fix the connecting to an open network, btw.  (ipw3945).  i believe that's part of what you were testing.
[02:41] <Hobbsee> (now that you appear to be here)
[02:41] <asac> yes i know
[02:41] <asac> should fix wpa
[02:41] <asac> Hobbsee: ^^
[02:42] <asac> Hobbsee: would be great if you can verify
[02:45] <cjwatson> infinity: yes
[02:45] <cjwatson> infinity: err. actually no, I don't think so. we have a similar one about selecting more appropriate defaults (component mapping).
[02:49] <ogra> mvo_, so do you have any idea ? i can apparently now reproduce it maunaully as well (chrooting and running apt-get install ltsp-client) it doesnt happen on networked installes
[02:50] <mvo_> ogra: not yet, sorry. what command do I have to run to reproduce it? will I need a edubuntu CD for this?
[02:51] <ogra> mvo_, yes you need an edubuntu CD ... mount it in /cdrom and run: sudo ltsp-build-client --mirror file:///cdrom --security-mirror none
[02:51] <ogra> thats what the udeb does as well ...
[02:52] <ogra> if it failed, you can bind mount /cdrom to /opt/ltsp/i386/cdrom, chroot, mount /proc and its reproducable on apt-get update
[02:52] <mvo_> ogra: gutsy-server I assume?
[02:52] <ogra> yep
[02:54] <AlinuxOS> asac, ping
[02:55] <highvoltage> Znarl: nice exit message :)
[02:55] <asac> AlinuxOS: just ask :)
[02:55] <mvo_> ogra: downloadin
[02:55] <ogra> mvo_, thanks :) ... i'm really lost without getting that fixed
[02:56] <mvo_> ogra: no worries, we get that fixed!
[02:56] <ogra> (especially since i have no clue whats wrong exactly)
[02:56] <AlinuxOS> asac, hello (& hello all) https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677 can we doo something ?
[02:56] <ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
[02:56] <ogra> well, it bothers me that i just did a base install and pkgsel before it happens in the install ... so it cant be the CD's fault
[02:57] <ogra> must be ltsp or chroot related
[02:57] <asac> AlinuxOS: we need someone to maintain that language upstream
[02:57] <asac> AlinuxOS: maybe ask carlos if we can do that in launchpad/rosetta through an ubuntu community efford
[02:58] <AlinuxOS> http://www.mozilla.com/en-US/firefox/all.html Georgian is in a main list.
[02:58] <AlinuxOS> main Beta list.
[02:58] <carlos> AlinuxOS, asac: We are finishing support in Launchpad for Mozilla xpi files
[02:59] <AlinuxOS> for Firefox 1.5 Georgian package was made by pitti.
[02:59] <AlinuxOS> Feisty - no Georgian mozilla support.
[02:59] <carlos> in the mean time, you need that an ubuntu developer handle that directly
[02:59] <AlinuxOS> Gusty - too.
[02:59] <asac> carlos: thought you are already at a beta stage :)
[03:00] <asac> carlos: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/
[03:00] <asac> is the xpi in that list?
[03:00] <carlos> I guess that's a question for AlinuxOS...
[03:00] <asac> carlos: sorry yeah AlinuxOS ^^
[03:01] <Hobbsee> asac: my WPA always works with nm.  *touch wood*.  always has since it was introduced.
[03:01] <asac> Hobbsee: on ipw3945?
[03:01] <Hobbsee> asac: yep.
[03:01] <Hobbsee> asac: well, since feisty, anyway
[03:01] <asac> Hobbsee: ok, so latest update did at least not break that for you :)
[03:02] <Hobbsee> asac: correct, i think.  i'd have to actually boot back into linux to double check, i dont remember quite when i did the update
[03:02] <Hobbsee> :)
[03:02] <AlinuxOS> asac, carlos http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/ Dear people, on this URL Georgian ka.xpi is present.
[03:03] <asac> AlinuxOS: please update the bug with a direct link to that xpi
[03:03] <asac> AlinuxOS: thanks
[03:03] <AlinuxOS> asac, against which package ?
[03:04] <AlinuxOS> asac, you mean here? https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
[03:04] <asac> AlinuxOS: mozilla-firefox-locale-all .. however we already have a bug ... please reassign it to that package and attach info to that bug
[03:04] <ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
[03:04] <asac> AlinuxOS: yes
[03:05] <Hobbsee> asac: i thought you'd done some messing with ipw3945, including open networks, which was why i asked.  incidently, it does show connected to the open network, but it clearly isnt (as it doesnt bring up the uni portal page)
[03:05] <asac> Hobbsee: i mainly did work on fixing ipw3945 for wpa ... as for lots of people it didn't work
[03:06] <asac> Hobbsee: i will take a look at open systems for the next release
[03:06] <Hobbsee> asac: yeah.  that surprises me though, that it works for some, and not others.
[03:06] <AlinuxOS> asac, should I attach ka.xpi file ? Or maybe direct link to ka.xpi: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/ka.xpi is enough?
[03:06] <asac> Hobbsee: indeed
[03:06] <asac> AlinuxOS: please the link
[03:06] <AlinuxOS> asac, ok thank you.
[03:07] <asac> AlinuxOS: i targetted it for tribe-5 now ... so we won't forget
[03:07] <TheMuso> If the notificatio area/applets area of the panel was accessible, and hense accessing nm, I would help test, as I have a notebook with wireless, a PCMCIA wireless card, and a mac mini with airport/Broadcom chipset needing fwcutter et al, and I would help test...
[03:08] <AlinuxOS> asac, thank you.
[03:10] <cjwatson> why no, mr. profiling tool, I don't believe you that ubiquity is only using 2.5MB of heap. It would be *nice* ...
[03:10] <StevenK> Hah
[03:14] <AlinuxOS> Since 2.18 version Dejavu fonts project has (finally) Georgian language support, but current Gusty package is Dejavu 2.17-2. I've even filed a bug dated(2007-07-01): https://bugs.launchpad.net/ubuntu/+source/language-pack-ka/+bug/123404
[03:14] <ubotu> Launchpad bug 123404 in language-pack-ka "language-pack-ka & and it's font dependency (ttf-bpg-georgian-fonts)" [Undecided,In progress] 
[03:17] <AlinuxOS> I've assigned that but to pitti but I'm not sure.
[03:18] <AlinuxOS> doko, ping
[03:19] <pitti> AlinuxOS: that doesn't have something to do with language-support; it needs to be packaged first
[03:20] <pitti> ttf-dejavu |     2.17-2 |         gutsy | source, all
[03:20] <pitti> AlinuxOS: ^ is it that font package? or a different font with the same name?
[03:21] <ogra> mvo_, hmm, running sha1sum on the Packages files gives me the right output (matching the apt debug output) for the Packages.gz the sha1 is different than what apt thinks it should be
[03:21] <mvo_> ogra: the CD is at 93%
[03:22] <AlinuxOS> pitti, no it's different ..but some fonts derive from ttf-bpg-georgian-fonts. bgp now collaborates with Dejavu project too.
[03:23] <AlinuxOS> Dejavu 2.18: added Georgian Mkhedruli to Sans, Serif and Mono, Asomtavruli to Sans and Serif (by Besarion Gugushvili)
[03:23] <pitti> AlinuxOS: http://changelogs.ubuntu.com/changelogs/pool/main/t/ttf-dejavu/ttf-dejavu_2.17-2/copyright says that this is the very same project
[03:23] <pitti> AlinuxOS: so it's a new version, but not a different project
[03:23] <AlinuxOS> pitti, maybe I misunderstood you...
[03:24] <AlinuxOS> 2.17 and 2.18 are are versions fro Dejavu project
[03:24] <AlinuxOS> since 2.18 there is Georgian support.
[03:24] <AlinuxOS> :)
[03:24] <AlinuxOS> surrent Dejavu font version is 2.19.
[03:25] <pitti> AlinuxOS: I updated the bug, please answer there
[03:26] <pitti> AlinuxOS: I subscribed ArneGoetje, too (our new i18n master)
[03:26] <AlinuxOS> ah, pitti I know him :)
[03:33] <pitti> Keybuk, Mithrandir: do you know why sysvinit appears in the "updated merges" instead of "new merges" list? it hasn't been merged for over a year, after all
[03:34] <pitti> Keybuk: I was specifically looking into dropping our 'multiuser' changes in favor of LSB headers
[03:34] <Mithrandir> pitti: might have been updated in Debian?
[03:34] <pitti> Mithrandir: I don't understand your question
[03:35] <pitti> I mean "s/new merges/outstanding merges/
[03:35] <Mithrandir> pitti: doesn't it go to "updated merges" if it has been updated in Debian?  Or am I confused?
[03:35] <pitti> Mithrandir: so, there have been tons of udpates to sysvinit in Debian in the last 14 months
[03:35] <StevenK> It goes into Updated Merges if it's been touched in Gutsy, I thought.
[03:35] <StevenK> (Which it has)
[03:35] <pitti> StevenK: aah, that would be it
[03:36] <pitti> I thought it would be more clever about that
[03:36] <mvo_> pitti: it would be cool to get this merged, but I noticed that some update-rc.d arguments might be incompatible in the newer version
[03:36] <AlinuxOS> pitti, done. thank you for attention!
[03:37] <Keybuk> pitti: updated just means that it's been *uploaded* to gutsy
[03:37] <Keybuk> not that the upload was actually a merge
[03:37] <pitti> mvo_: yeah, it needs to be treated with care, and we should leave our 'multiuser' hack for a while
[03:37] <mvo_> pitti: yep
[03:37] <pitti> but we should slowly move away from multiuser anyway
[03:37] <Keybuk> we should? why?
[03:38] <pitti> Keybuk: in favour of LSB headers in the init script (as suggested by Debian)
[03:38] <pitti> Default-Stop:      1
[03:38] <pitti> instead of the default "0 1 6"
[03:38] <Mithrandir> they're fugly, though. :-/
[03:38] <Keybuk> most of the LSB headers in our init scripts are wrong though
[03:38] <pitti> Keybuk: yeah, therefore the 'slowly'
[03:38] <Keybuk> it would be some work to make them right
[03:38] <pitti> Debian moves towards lsb headers now anyway
[03:39] <Keybuk> and investing time in init scripts seems pointless given we intend to deprecate them?
[03:39] <pitti> Keybuk: I agree, and I don't say that we should invest much effort into it
[03:39] <pitti> just that it would be nice to have the LSB header parsing, too, to drop delta with Debian
[03:40] <Keybuk> but we can't switch it on until we've fixed all the init scripts
[03:41] <pitti> well, at least made sure that the existing LSB headers have correct Default-{Start,Stop}, yes
[03:41] <pitti> it just crossed my eye and I wondered about the merge status, but now that I know what MoM considers as 'updated merge', it's clear to me now
[03:42] <Keybuk> I don't think we've merged sysvinit in quite a while anyway
[03:42] <Keybuk> (ie. a number of releases)
[03:43] <pitti> right, that's why I wondered why it appears in 'updated merges' :)
[03:46] <pitti> mhb: AYT?
[03:46] <mhb> pitti: sure
[03:54] <ogra> dendrobates, the three ldap related main inclusion reports need to be rewritten first (thats why i've putten them under: "These three need a proper rewrite of the report first" ;)) ... iwj refused to approve them in in this form ...
[03:54] <dendrobates> I asked pitti to look at one and he said it was fine.  So I thought they had been rewritten.
[03:55] <dendrobates> ogra:  What exactly needs to be done to them?  I'll do it today.
[03:55] <ogra> not by me ... and apprently i'm the last who changed the pages ...
[03:55] <ogra> there is a new template format afaik ...
[03:55] <pitti> ogra: looked good enough to me *shrug*
[03:56] <ogra> pitti, to me as well ...
[03:57] <ogra> dendrobates, if pitti is fine, all is good ;)
[03:58] <dendrobates> ogra: ok, thanks.
[03:59] <dendrobates> ogra: The server tean is doing quite a bit on the ldap auth front.  We need to discuss what impacts it might have on edubuntu.
[04:00] <ogra> dendrobates, a good one i suspect ;)
[04:01] <ogra> dendrobates, ltsp local apps and ltsp fat clients are both depending on a properly working ldap server setup
[04:01] <ogra> both are long awaited features in edubuntu and ltsp
[04:02] <dendrobates> ogra: we are tackling the client side first, just because of time.  I hope to do the server work in gutsy+1
[04:02] <pitti> ogra: ETA for OO.o is some three hours, afterwards the upload gates will be closed, and it'll take a very good reason to accept something; how does things look at your front?
[04:02] <ogra> yeah, thats fine
[04:03] <ogra> pitti, all broken
[04:03] <pitti> ogra: I didn't follow the md5sum issue
[04:03] <ogra> no fix in sight yet for the hash mistmatch ... (mvo is looking)
[04:03] <pitti> ogra: that is, uploads which affect ubuntu/kubuntu CDs; uploading ltsp is still fine, of course (at the price of delaying your CDs)
[04:04] <pitti> ogra: d'oh :/
[04:04] <ogra> pitti, i still have to sort size issues on the desktop CD ...
[04:04] <ogra> the hash crap kept me busy digging all day :(
[04:04] <mvo_> ogra: I think I have a patch, would you be able to test it?
[04:04] <ogra> mvo_, INDEED !!!
[04:05] <mvo_> ogra: you prefer a package or a diff? what arch do you need (if package)?
[04:05] <ogra> i386
[04:05] <mvo_> ogra: I'm currently runing it through my testsuit, if it survies that, I will send it to you and update my testsuit
[04:05] <ogra> yay, thanks a lot
[04:05] <ogra> what was/is it ?
[04:06] <ogra> it == the prob
[04:06] <mvo_> ogra: the file/copy method do not take hashes (that is ok) but the acquire code does not calculate it if it does not get it from the method anymore, that is a bug (and that used to be there before)
[04:07] <ogra> aha
[04:08] <mvo_> ogra: the way hashes are taken is not pretty (its better now than it was before IMHO) and this is one of the breakage caused by no clear reposponsiblity
[04:08] <pitti> mvo_: will that apt patch make me jump for joy (and from the balcony)?
[04:08] <ogra> so d-i is not using the file method apparently which is why it works until i get in ltsp build mode ...
[04:09] <mvo_> pitti: I hope not :(
[04:10] <mvo_> pitti: I would not want to see you jump from the balcony
[04:24] <mvo_> ogra: can you please try http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb (and friends)?
[04:24] <mvo_> ogra: this bug kills your edubuntu CDs, right?
[04:25] <mvo_> ogra: if the patch is good I need to clean it up a bit + add a test for this bug, but it should be ready failrly soon
[04:29] <gutsytester> In Gutsy there is a barrier of 1px at the top of the panel where i can not click on "applications places..". Is that a bug?
[04:30] <Ng> gutsytester: yes, bug 103306
[04:30] <ubotu> Launchpad bug 103306 in compiz "compiz eats mouse clicks at the border of the screen" [Medium,Triaged]  https://launchpad.net/bugs/103306
[04:31] <gutsytester> Ng, thank you
[04:32] <gutsytester> are the new default directories in $HOME used by any programs? e.g. there are no templates at all by default
[04:33] <Hobbsee> gutsytester: you may want #ubuntu+1
[04:33] <gutsytester> Hobbsee, oh, sorry
[04:34] <norsetto> is it intentional not to have libbluetooth2-dev in ubuntu?
[04:36] <mjg59> norsetto: libbluetooth-dev
[04:36] <norsetto> mjg59: exactly, so, its intentional?
[04:36] <geser> yes, the the normal naming scheme
[04:36] <cjwatson> norsetto: the same renaming happened in Debian
[04:37] <norsetto> why do we have libbluetooth2 then!? In debian they have libbluetooth2-dev in stable
[04:37] <cjwatson> bluez-libs (3.10-1) unstable; urgency=low
[04:37] <cjwatson>   * New upstream release
[04:37] <cjwatson>   * libbluetooth2-dev -> libbluetooth-dev transition to allow binNMUs
[04:37] <cjwatson>  -- Filippo Giunchedi <filippo@debian.org>  Wed, 23 May 2007 22:13:52 +0200
[04:37] <cjwatson> norsetto: -dev naming scheme isn't necessarily the same as runtime library naming scheme
[04:37] <norsetto> ok thanks, just wanted to make sure before proposing a merge (which could have been a sync if not for this)
[04:38] <cjwatson> it's not uncommon to drop the .so version from the -dev
[04:38] <cjwatson> norsetto: you're confused; this has nothing to do with whether the package is syncable
[04:38] <cjwatson> the change came from Debian
[04:38] <geser> norsetto: the lib packages have to soname (you want different version to be coinstallable) but not the -dev one (usually you want to build against the latest version)
[04:38] <cjwatson> for the remaining Ubuntu changes which need to be preserved, see recent changelog entries
[04:38] <norsetto> cjwatson: no, I not confused; the debian package has two dependancies on libbluetooth2-dev, which I need to change
[04:40] <norsetto> thanks for the help guys, you are wonderful :-)
[04:40] <mjg59> norsetto: Only if it's a versioned depend
[04:40] <mjg59> norsetto: It still provides: libbluetooth2-dev
[04:41] <norsetto> mjg59: not following you now; what do you mean?
[04:41] <cjwatson> nothing in Debian has any problematic dependencies on libbluetooth2-dev
[04:41] <mjg59> norsetto: libbluetooth-dev provides: libbluetooth2-dev
[04:41] <cjwatson> norsetto: look up virtual packages in Debian policy
[04:42] <norsetto> the package is gnokii; so if what you say is correct I don't need to change the dependancy, and its just a sync?
[04:43] <norsetto> I want to make sure, as we changed it already in the previous ubuntu version
[04:43] <cjwatson> norsetto: indeed; that change was unnecessary
[04:43] <norsetto> good!
[04:43] <mjg59> norsetto: Unless the dependency is versioned, there is no need to change it
[04:43] <cjwatson> norsetto: but if you are in doubt, you should check with the previous uploader
[04:43] <cjwatson> (who's on holiday)
[04:44] <norsetto> perfect guys; I hug you even more, i'll ask for a sync then
[04:44] <cjwatson> it is true that it is more elegant not to rely on the provides
[04:44] <norsetto> cjwatson: yeah, thats why I'm looking at it, he is back soon in any case
[04:55] <bddebian> Heya
[05:01] <_Nesshof_> I'm looking for gaps between the vanilla OpenOffice.org packaging and the packaging for ubuntu, is there anybody with some insight in this area ?
[05:03] <asac> pitti: when can i expect first test isos for tribe-4 ?
[05:04] <pitti> asac: help me pedal on palmer, so that OO.o builds faster :)
[05:04] <asac> pitti: my test-system would deserve a reinstall .. so I would use that chance to test them :)
[05:04] <pitti> asac: in about three to four hours, I hope
[05:04] <doko> _Nesshof_: what do you mean by gaps?
[05:04] <asac> ok that should be good enough
[05:04] <pitti> asac: I'm craving for them more than you do, believe me :)
[05:04] <asac> maybe i can order my dell laptop in the meantime :)
[05:05] <norsetto> _Nesshof_: you can look at the changelog; all changes are listed there
[05:05] <asac> hmm still broken dell.de/ubuntu
[05:05] <_Nesshof_> what is the repository for the changes ? is there a special reposity for ubuntu used ?
[05:05] <doko> _Nesshof_: Ubuntu uses ooo-build as a base, then adds it's own packaging modifications, best seen in debian/rules
[05:06] <doko> I assume you know the ooo-build repository, do you?
[05:06] <_Nesshof_> doko: yes
[05:07] <_Nesshof_> so it is a three stage build process, using vanilla ooo, ooo-build and spec. ubuntu patches ?
[05:07] <doko> ok, so you find the most recent other packaging details in the package itself (the .diff.gz is sufficient), see https://launchpad.net/ubuntu/+source/openoffice.org/2.3.0~src680m224-1ubuntu2
[05:07] <asac> doko: i am just curious how large is the patchset that has accumulated over time for ooo?
[05:07] <doko> asac: not more than 20MB compressed
[05:07] <asac> the full diff.gz ... or just patches?
[05:08] <doko> most of it are translations
[05:08] <asac> ah ok
[05:16] <doko> _Nesshof_: ubuntu specific patches are found in ooo-build as well
[05:24] <mvo_> pitti: we have a update for libcompizconfig0 that fixes a nasty crash, it would be cool if that could go in too
[05:24] <mvo_> ogra: any chance to test my patch ?
[05:24] <ogra> mvo_, sorry, was downstairs for some food, testing now
[05:27] <mvo_> ogra: no problem
[05:28] <ogra> mvo_, what beyond apt do i need ?
[05:28] <mikmor2> cjwatson: Good morning (for me).
[05:28] <mvo_> ogra: some compiz firefighting in the meantime, looks like everything I'm involed with is borken currently
[05:28] <mvo_> ogra: nothing I think
[05:28] <ogra> hmm, then it doesnt work ... updated apt behaves the same in the chroot
[05:29] <cjwatson> mikmor2: morning
[05:29] <mvo_> ogra: ok, give me some minutes
[05:30] <tkamppeter> pitti, ping
[05:58] <vprints> Bug #129749
[05:58] <ubotu> Launchpad bug 129749 in firefox ""Recently closed tabs" is always greyed-out" [Undecided,Confirmed]  https://launchpad.net/bugs/129749
[05:59] <vprints> https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/117648
[05:59] <ubotu> Launchpad bug 117648 in openoffice.org "[festy]  Writer crashes, document recovery attempt, after Insert->Indices and Tables->Bibliography" [High,Confirmed] 
[06:01] <Hobbsee> vprints: and...?
[06:01] <Hobbsee> vprints: and was it necessary to spam 2 channels with that?
[06:03] <vprints> Hobbsee, spam ?
[06:04] <Hobbsee> vprints: just dumping bugs into the development channel wont suddenly get them fixed, unless they're critical.  people dont just drop everything to fix a bug that someone mentions.  a bug tracker is for keeping track of bugs.
[06:06] <vprints> Ok, sorry then
[06:07] <Hobbsee> vprints: obviously, if everyone did that...it would get quite unruly
[06:08] <stgraber> pitti: How's tribe-4 going, do we have anything to test yet, or when will we ? (I have some people asking in #ubuntu-iso)
[06:09] <Hobbsee> stgraber: waiting on ooo again
[06:10] <stgraber> ok, thanks
[06:10] <geser> and ooo is still building
[06:11] <LaserJock> anybody know where pitti keeps lang pack sizes?
[06:11] <mvo_> ogra: could you please give this one a try? http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb
[06:12] <geser> pitti: could there be a problem with the new pkgbinarymangler? xpdf ftbfs on powerpc and sparc with "pkgmaintainermangler: Error: Unable to locate DEBIAN/control"
[06:14] <wasabi> Where did the Java 6 plugin package disapepar to?
[06:14] <wasabi> sun-java6-plugin seems to be gone... but the changelog mentions nothing. =/
[06:14] <geser> both build logs shows that pkgbinarymangler got updated to 40. i386, amd64 and i164 build successfully but the log doesn't mention that pkgbinarymangler got updated
[06:14] <wasabi> Oh, i see. N/m.
[06:14] <wasabi> 32 bit only. =.
[06:19] <Mithrandir> geser: it affects other packages too, so I'd say yes.
[06:19] <Mithrandir> pitti: ^^ moblin-image-creator ftbfs on i386 due to the same problem.
[06:20] <LaserJock> Mithrandir: do you happen to know a decent way to guess who much space lang packs will take on the LiveCDs?
[06:20] <LaserJock> *how
[06:20] <Mithrandir> LaserJock: unsure; I think we guesstimate based on .deb size.
[06:20] <LaserJock> Mithrandir: should they be roughly the same as .deb size?
[06:21] <Mithrandir> not too far off, at least.
[06:21] <Mithrandir> slightly smaller, I believe.
[06:21] <LaserJock> k, that's good enough
[06:21] <highvoltage> hmm.. perhaps it would be a good excercise for me to make a script that sums up the size of the langpacks
[06:22] <cjwatson> highvoltage: pitti has one such already
[06:22] <cjwatson> http://people.ubuntu.com/~pitti/scripts/langpacksize
[06:22] <highvoltage> cjwatson: aah
[06:23] <manchicken> I'm guessing someone already knows about the openoffice.org-core dependency issue?
[06:23] <highvoltage> LaserJock: well, there you have it
[06:23] <manchicken> Or, nevermind.  Hobbsee says I'm jumping the gun.
[06:25] <LaserJock> cjwatson: thanks
[06:42] <alex-weej> what package is strace in these days?
[06:43] <alex-weej> hm, nm, seems i have it
[06:43] <cjwatson> alex-weej: strace
[06:43] <lamont`> alex-weej: usually it's in the source and binary packages 'strace'.
[06:43] <lamont`> cjwatson: ^5
[06:43] <alex-weej> Evolution is going apeshit with CPU
[06:43] <alex-weej> in Gutsy
[06:44] <alex-weej> anyone have any ideas?
[06:44] <lamont`> alex-weej: still using mutt here...
[06:44] <cjwatson> oh my, https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview is out of date
[06:47] <pitti> ! openoffice has built!!!
[06:48] <Hobbsee> pitti: but will it publish and work?
[06:49] <pitti> Hobbsee: let's find out :)
[06:49] <Hobbsee> :D
[06:50] <pitti> ... as soon as my ssh to drescher actually continues to work
[06:51] <pitti> running
[06:51] <Hobbsee> hah.  let's hope yours works better than mine to the uni
[06:52] <Hobbsee> Sun Microsystems Inc.   SunOS 5.10       Generic Jul 2006
[06:52] <Hobbsee> interesting
[06:53] <Hobbsee> pity my normal .bashrc doesnt work, though
[06:53] <geser> pitti: luckily ooo started building before the buildds start using the broken pkgbinarymangler
[06:55] <Hobbsee> pitti: good luck, i need to head to bed.
[06:55] <geser> Hobbsee: you woke up again to see pitti bounce on the successful ooo build?
[06:56] <mvo_> ogra: forget my last msg please
[07:02] <pitti> mvo_: libcompizconfig> looking
[07:02] <pitti> hi tkamppeter
[07:02] <pitti> stgraber: OO.o is publishing, and apparently I need another cycle for compizconfig
[07:03] <pitti> stgraber: ETA still 2 hours then
[07:03] <pitti> geser: looking, infinity uploaded a new version recently
[07:05] <geser> pitti: that's the one causing the problem
[07:07] <pitti> seb128: is the gdm fix very important for the tribe?
[07:07] <seb128> pitti: nothing I've uploaded is important for the tribe or I would have pinged you ;)
[07:07] <pitti> seb128: ok, thanks; just checking
[07:07] <seb128> you're welcome
[07:08] <stgraber> pitti: ok, that's fine, let's hope they will be correctly working as we don't have much time ...
[07:08] <mvo_> pitti: there is also ogra apt problem pending .. :(
[07:09] <pitti> mvo_: yeah, but that can go in a bit later, while the ubuntu/kubuntu/xubuntu CDs are already building
[07:09] <mvo_> pitti: aha, ok
[07:13] <iwj> Are there any tribe 4 images for testing yet ?
[07:13] <pitti> iwj: working very hard to get some ASAP
[07:13] <iwj> IC  OK
[07:13] <pitti> iwj: OO.o spoiled the show this time :/
[07:14] <iwj> Fair enough.  So testing is postponed ?
[07:14] <iwj> Sounds very annoying.  Any way I can help ?
[07:14] <pitti> iwj: not any more; OO.o just built (after the second attempt), now it's being published
[07:15] <iwj> OK
[07:15] <pitti> iwj: once that happened, testing the OO.o upgrade and install would be *very* appreciated
[07:15] <tkamppeter> hi pitti, it seems that your AppArmor changes in the startup scripts for CUPS have caused bug 131065.
[07:15] <ubotu> Launchpad bug 131065 in cupsys "[Gutsy]  cupsys fails to upgrade" [Undecided,New]  https://launchpad.net/bugs/131065
[07:15] <iwj> pitti: Sure.
[07:15] <pitti> tkamppeter: later, please
[07:16] <mathiaz> tkamppeter: the bug report lacks more information.
[07:17] <pitti> oh *headdesk*, I see the pkgmaintainermangler problem
[07:17] <ogra> mvo_, to me it looks like apt ignores the .gz files completely while it processes the Packages files
[07:17] <calc> pitti: appears i386 failed at the very end of the build when it couldn't find one of the files it generated :(
[07:18] <pitti> calc: yeah, we noticed; doko did a quickfix and it's built now and being published
[07:18] <calc> pitti: cool, what was the problem with it?
[07:18] <pitti> calc: details later, currently working under pressure, sorry
[07:19] <calc> pitti: ok no problem
[07:19] <doko> calc: didn't investigate yet, you can reproduce it by installing the binary mangler
[07:19] <calc> doko: oh ok
[07:20] <pitti> doko: it should be fixed with the new pkgbinarymangler
[07:20] <pitti> doko: pkgstriptranslations stumbled over the bzip2 argument of dpkg-deb
[07:20] <pitti> doko: that was the reason why it didn't output anything for dh_builddeb -i
[07:20] <pitti> doko: it only checked $1 for -b
[07:22] <pitti> Mithrandir, geser: fix uploaded, I'll beat it through the buildds and give back your packages later
[07:22] <doko> calc: ok, so you can remove my workaround; couldn't check it in, the repo is out of date ;)
[07:22] <calc> doko: ok
[07:23] <pitti> doko: no, please don't check it in
[07:23] <pitti> calc: your package should actually build fine the next time
[07:23] <calc> pitti: thats what he just said :)
[07:23] <pitti> yeah, sorry
[07:23] <calc> pitti: np you are stressed to the max :)
[07:23] <calc> pitti: \o/
[07:25] <pitti> oh, crap, no, that doesn't work
[07:27] <pitti> openoffice.org | 2.3.0~src680m224-1ubuntu2 |         gutsy | source, amd64, i386
[07:27] <pitti> calc, iwj, anyone: ^ please give this an upgrade/install/quick functinoality test
[07:28] <hunger> pitti: aptitude does not like it here... conflicts with something.
[07:28] <pitti> hunger: --verbose, please?
[07:28] <pitti> hunger: here too, indices are not yet up to date
[07:29] <pitti> hunger: it seems that archive.u.c. still needs to catch up or so (publisher ended some three minutes ago)
[07:29] <hunger> pitti: OK, I'll recheck once it is updated.
[07:29] <calc> pitti: has it been pushed on the mirrors yet, i don't see it yet?
[07:31] <hunger> pitti: It is installable after another update.
[07:31] <pitti> calc: it just started to work here
[07:31] <pitti> dist-upgrade running
[07:31] <pitti> calc: wow, 22,1 additional MB after upgrade
[07:32] <pitti> calc: let's hope those compress well etc.
[07:32] <ogra> *shudder*
[07:32] <calc> pitti: the compressed size was the same wasn't it (or within a MB or two?)
[07:32] <pitti> ogra: I did a thorough deb size comparison this morning, and it shouldn't actually be too bad
[07:33] <pitti> unless it pulls in many more dependencies
[07:33] <calc> pitti: i don't think it should, probably less right now since some stuff is disabled due to being broken
[07:33] <mvo_> ogra: http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb <- that one if fine for me, please give it a go. but I'm confident in it :)
[07:33] <calc> i have a few MIRs i need to do to reduce the diff.gz size
[07:34] <pitti> mvo_: can you please put a diff somewhere?
[07:35] <pitti> ogra: I'll build a throwaway alternate here to see how it explodes
[07:35] <ogra> mvo_,
[07:35] <ogra> Failed to fetch file:///cdrom/dists/gutsy/main/binary-i386/Packages.gz  Hash Sum mismatch
[07:35] <ogra> Failed to fetch file:///cdrom/dists/gutsy/restricted/binary-i386/Packages.gz  Hash Sum mismatch
[07:35] <ogra> Reading package lists... Done
[07:35] <ogra> E: Some index files failed to download, they have been ignored, or old ones used instead.
[07:35] <ogra> root@laptop:/#
[07:35] <ogra> :(
[07:36] <geser> pitti: about the pkgmaintainermangler problem: is changing line 27 in the dpkg-deb wrapper from '/usr/bin/pkgmaintainermangler "$@"' to '/usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS' the right fix?
[07:37] <pitti> geser: right, that's what I did and uploaded
[07:37] <pitti> geser: I tested with Mithrandir's moblin-image-creator, worked
[07:37] <ogra> pitti, size wise i'm more worried about live ...
[07:37] <geser> me too :)
[07:37] <pitti> calc: right, I still get the hang here, without -gtk
[07:39] <pitti> geser: I wonder what keeps pkgbinarymangler from FTBFSing, though
[07:40] <mvo_> ogra: and that is the latest one? no proxies playing tricks with you?
[07:40] <calc> pitti: Riddell was able to find a bug report about the same issue on konqueror nspluginviewer on novell bugzilla, and i reduced the hang to which library has to be installed to cause it not to hang as well
[07:40] <ogra> mvo_, used wget ...
[07:40] <calc> /usr/lib/openoffice/program/libvclplug_gtk680li.so
[07:40] <geser> pitti: hopefully not the broken pkgmaintainermangler on the builds
[07:41] <pitti> geser: that's what I think, though
[07:41] <pitti> geser: however, I can work around it
[07:41] <alex-weej> someone please tell me that Compiz isn't on by default in Gutsy
[07:42] <Amaranth> alex-weej: it's on by default in gutsy
[07:42] <Amaranth> why?
[07:42] <alex-weej> it's horrible
[07:42] <Amaranth> ?
[07:42] <alex-weej> the genie minimise effect is pretty sickening
[07:42] <Amaranth> right, that's a bug
[07:42] <alex-weej> no
[07:42] <alex-weej> it's a patent issue
[07:43] <Amaranth> no, it's a bug
[07:43] <alex-weej> ok
[07:43] <Amaranth> upstream at one time agreed with us on defaults
[07:43] <ogra> mvo_, \o/
[07:43] <ogra> root@laptop:/# apt-get update
[07:43] <ogra> Ign file: gutsy/main Translation-de
[07:43] <ogra> Ign file: gutsy/restricted Translation-de
[07:43] <ogra> Hole:1 file: gutsy Release.gpg [189B] 
[07:43] <ogra> Hole:2 file: gutsy Release [1877B] 
[07:43] <ogra> Ign file: gutsy/main Packages
[07:43] <Amaranth> they changed them, we need to go back to the zoom animation
[07:43] <ogra> Ign file: gutsy/restricted Packages
[07:43] <ogra> Paketlisten werden gelesen... Fertig
[07:43] <ogra> root@laptop:/#
[07:43] <mvo_> ogra: oh, nice :) can you (just to be sure) rm /var/lib/apt/lists/*
[07:43] <mvo_> ogra: and see if it still works?
[07:43] <Amaranth> alex-weej: don't judge the whole thing on the minimize animation :)
[07:43] <ogra> mvo_, i had to to make it work at all
[07:44] <Amaranth> alex-weej: and it's only a patent issue if it doesn't wave :)
[07:44] <alex-weej> Amaranth: i have a good set of bugs on Launchpad that drive me up the wall about compiz
[07:44] <iwj> pitti: re oo.o -1ubuntu2> willdo.
[07:44] <mvo_> ogra: oh? does that mean that subsequent apt-get update errors?
[07:45] <ogra> mvo_, it didnt just fix itself ....
[07:45] <pitti> calc, iwj: all the apps start for me with -gtk installed
[07:45] <ogra> i had to remove the file
[07:45] <mvo_> ogra: it did or it "did not"?
[07:45] <alex-weej> we need to change the wording in the Appearance capplet. "No effects", "Normal effects" and "Extra effects" is very misleading. The fact of the matter is that this changes the Window manager, and currently affects a LOT more than just appearance.
[07:45] <calc> pitti: ok :)
[07:45] <ogra> mvo_, didn't
[07:45] <ogra> (not)
[07:45] <mvo_> hmm ...
[07:45] <mvo_> strange
[07:45] <Amaranth> alex-weej: no, it changes one or two of your pet behaviors
[07:45] <ogra> but it works at least
[07:46] <alex-weej> Amaranth: like being able to use 3D apps?
[07:46] <Amaranth> alex-weej: give me an example bug report
[07:46] <calc> alex-weej: does compiz still not snap to borders like metacity?
[07:46] <mvo_> pitti: http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4.debdiff
[07:46] <Amaranth> alex-weej: i'd have to have hardware that triggers that to figure out the problm
[07:46] <Amaranth> alex-weej: nvidia?
[07:46] <ogra> mvo_, for the current case thats fine
[07:46] <alex-weej> Amaranth: anything that ISN'T Nvidia, apparently.
[07:46] <alex-weej> Amaranth: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/96991
[07:46] <ubotu> Launchpad bug 96991 in xserver-xorg-video-ati "3D stuff breaks with Compiz" [Undecided,New] 
[07:47] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91780
[07:47] <Amaranth> alex-weej: i know that's not true, mvo_ has ati :)
[07:47] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91783
[07:47] <ubotu> Launchpad bug 91780 in compiz "Compiz's corner resize grabbers are difficult to get hold of" [Wishlist,New] 
[07:47] <ubotu> Launchpad bug 91783 in compiz "Compiz's default Human-glass look does not "work" visually" [Wishlist,New] 
[07:47] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91784
[07:47] <ubotu> Launchpad bug 91784 in compiz "Compiz's "show desktop" functionality differs to Metacity's" [Wishlist,Confirmed] 
[07:47] <Amaranth> !pastebin | alex-weej
[07:47] <ubotu> alex-weej: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[07:47] <ogra> debdiff shouldd have a --ignore-po-files switch
[07:47] <Amaranth> alex-weej: wishlist bugs
[07:47] <alex-weej> Amaranth: subjective.
[07:48] <alex-weej> i don't see why a user should be faced with differing behaviour of a show desktop button just because they "changed the appearance"
[07:48] <alex-weej> it's a usability issue
[07:48] <Amaranth> alex-weej: i like compiz's better :)
[07:48] <alex-weej> Amaranth: then make metacity's the same
[07:48] <Amaranth> metacity's behavior has always annoyed me
[07:48] <Amaranth> alex-weej: that i don't have control over
[07:48] <alex-weej> Amaranth: then tell the truth in the capplet. Make it a "change window manager" setting instead
[07:49] <alex-weej> the fact of the matter is it doesn't change some kind of abstract "enable 3D effects" setting, it changes the window manager
[07:49] <alex-weej> and only the window manager
[07:49] <Amaranth> which changes the behavior of a few small things
[07:50] <Amaranth> it mostly works the same
[07:50] <alex-weej> in any event the wording needs changing anyway. there's no info on what exactly "extra effects" does
[07:51] <calc> what does using 3d all the time do to laptop battery life, anyone tested that part yet?
[07:51] <Seveas> calc, bad things :)
[07:51] <Amaranth> alex-weej: that's just an incomplete implementation
[07:51] <Amaranth> calc: on my system it has basically no effect
[07:51] <Amaranth> but that's because nvidia power management sucks
[07:51] <calc> so thats another argument to have it disabled by default then
[07:51] <Seveas> yours is draining battery no matter what
[07:51] <alex-weej> and the use of radio buttons to do something as scary as changing the window manager (watch the screen blank and flicker as you change it) blows a bit. we use an apply button in the randr capplet for that.
[07:51] <Seveas> on my intel it's significant
[07:52] <Amaranth> it's a toggle button ;)
[07:52] <Amaranth> and it's mostly for turning it off now
[07:52] <iwj> My local mirror is absolutely chocker with oo.o versions.
[07:52] <calc> but somewhere normal users probably won't see it
[07:52] <alex-weej> Amaranth: of course, i'd love to get in and change the code and play about, but unfortunately i haven't quite figured out how to get into ubuntu yet.
[07:52] <calc> unless it is in the installer also
[07:53] <calc> upgrading from feisty -> gutsy and losing a lot battery life isn't exactly a nice thing to do to users
[07:53] <pitti> mvo_: ok, get it uploaded please
[07:53] <Amaranth> calc: they won't get compiz by default
[07:53] <mjg59> But they get bling
[07:53] <Amaranth> only new installs
[07:53] <calc> Amaranth: oh ok
[07:53] <mvo_> pitti: coming
[07:53] <Amaranth> that's how it's supposed to work anyway
[07:54] <calc> mjg59: and less features apparently
[07:54] <AlinuxOS> pitti, good evening, so it's ok for Arne, https://bugs.launchpad.net/ubuntu/+source/ttf-dejavu/+bug/123404
[07:54] <ubotu> Launchpad bug 123404 in language-pack-ka "language-pack-ka & and it's font dependency (ttf-bpg-georgian-fonts)" [Undecided,In progress] 
[07:54] <ogra> pitti, \o/
[07:54] <ogra> thanks !
[07:55] <Amaranth> calc:  we have that
[07:55] <hunger> pitti: ooo installed fine
[07:55] <pitti> ogra: wow, throwaway alternates are not oversized at all \o/
[07:55] <calc> Amaranth: was it buggy before, istr it not working exactly right
[07:55] <calc> Amaranth: maybe something to do with wobbly windows though
[07:55] <Amaranth> calc: we have snap without wobbly
[07:56] <calc> Amaranth: i can't test it on my desktop though since compiz doesn't work on it
[07:56] <calc> Amaranth: great :)
[07:56] <Amaranth> calc: doesn't work exactly like metacity but pretty close
[07:56] <ogra> pitti, alternate is fine for me since feisty i have plenty of space to move stuff to ... LaserJock and me are just fighting with the liveCD
[07:56] <pitti> ogra: building throwaway live now, to check
[07:57] <ogra> ah, i'll wait for these and hope foir a miracle
[07:59] <geser> pitti: upgraded ooo on amd64 without problems and it still starts
[07:59] <iwj> calc: Is oo.o supposed to save things in Documents rather than Desktop by default ?  That seems wrong to me.  (Still on 2.2.1-5ubuntu3; 2.3.0~src680m224-1ubuntu is downloading)
[07:59] <pitti> geser: yay, here too
[08:00] <calc> iwj: it tries to save to the user dir for me, must be a setting somewhere if it is different for you
[08:00] <iwj> I'm sure I haven't set any such setting.
[08:00] <iwj> I just typed `ooffice' at a shell prompt, new text document, type some text, save as and enter `foobar' as the filename.
[08:00] <pitti> iwj: that might be if you have -gnome installed? some gnome file dialog might respect the xdg-user-dirs
[08:00] <iwj> I have ubuntu-desktop installed.
[08:01] <pitti> iwj: yeah, that should give you openoffice.org-gnome
[08:01] <calc> oh yea i don't have -gnome installed right now
[08:01] <pitti> mvo_: I don't want to hurry you, but I need apt now
[08:01] <mvo_> pitti: its uploaded
[08:01] <pitti> @all: can I ask some of you guys to do a nightshift with me for ISO testing?
[08:02] <ogra> mvo_, that was awesome, many many thanks !
[08:02] <bdmurray> pitti: I could help but it won't be night for me. ;)
[08:02] <pitti> if anyone feels like it, the 20070808 ubuntu alternate should actually work; it's not supposed to be perfect (missing libcompizconfig and apt), but it should do
[08:02] <pitti> bdmurray: so much the better :)
[08:03] <calc> iwj: yea with -gnome it defaults to Documents the new document location for gnome 2.19/2.20
[08:03] <pitti> calc: that sounds right to me, though
[08:03] <calc> pitti: yea that's a feature not a bug
[08:04] <iwj> Seems like a way to let people lose their files to me :-).  But if you know about it that's fine, I'm not going to argue.
[08:04] <calc> without -gnome it defaults to your user dir not Desktop, which is probably what it defaulted to before gnome 2.19
[08:04] <bdmurray> maybe release noting it would be a good idea
[08:05] <calc> er i meant to say with -gnome installed prior to 2.19 it probably defaulted to Desktop
[08:05] <calc> gnome 2.19 added a lot of other dirs to the user dir
[08:05] <calc> documents/music/pictures/public/templates/videos
[08:06] <mathiaz> pitti: I can help doing some isotesting.
[08:06] <calc> btw is it a bug that documents and desktop appear twice in places menu?
[08:06] <calc> it looks like a bug in any case
[08:06] <bdmurray> calc: yes, it is known
[08:06] <calc> bdmurray: ok
[08:06] <pitti> mathiaz: that would be great
[08:06] <pitti> calc: there's an existing bug about tit
[08:06] <mathiaz> pitti: I'm already testing the server cd.
[08:06] <pitti> it, even
[08:07] <mathiaz> pitti: let me know what else I should test.
[08:07] <pitti> mathiaz: appreciated (just in case you find something truly weird), although it's not the candidate yet
[08:07] <iwj> pitti: I'm downloading the 20070808/gutsy-alternate-i386.iso now but it'll be a while.
[08:08] <iwj> Err, depending.
[08:08] <pitti> iwj: jigdo FTW :)
[08:08] <mathiaz> pitti: I'm testing the isos from yesterday (20070807) as there is none as of today.
[08:08] <iwj> My network was down so my rsync is less primed than it ought to be.
[08:08] <pitti> mathiaz: right, no final images yet
[08:08] <ijuz> many end users will still have the problem that per default the live cd doesn't load the ide-gerneric module
[08:08] <iwj> pitti: I have a file overwrite problem with oo.o 2.3.0~src680m224-1ubuntu2
[08:08] <mathiaz> pitti: ok. I'll wait for the final images then and test the server images.
[08:08] <ogra> pitti, to fix the liveCd issues on edubuntu we'd need a dep change in gcompris, is that ok ?
[08:08] <iwj>  trying to overwrite `/usr/lib/openoffice/program/gconfbe1.uno.so', which is also in package openoffice.org-gtk
[08:08] <pitti> iwj: downloading it now will make the final candidate CD download much faster, too
[08:09] <pitti> iwj: erk
[08:09] <pitti> iwj: that has to be fixed post-tribe, I'm afraid
[08:09] <stgraber> pitti: Can you add isos on the tracker when they are uploaded or do you prefer pinging me ?
[08:09] <ogra> pitti, moving tuxpaint to a gcopmpris recommends to be able to drop it from the live session
[08:09] <pitti> stgraber: I think I can
[08:09] <iwj> I'm doing  dpkg -iOB  though not apt here.
[08:09] <pitti> ogra: ok, please get it uploaded; that will delay your CDs slightly
[08:09] <ogra> slightly is fine :)
[08:10] <pitti> ogra: but that's ok, I can interleave it with the other iso builds and build edubuntu last
[08:11] <stgraber> pitti: are you also going to send a mail to testers (Send mail option in the admin ui) or shall I ? (would also be great to ask people wanting to test to join #ubuntu-iso so we can coordinate a bit for faster testing)
[08:11] <pitti> stgraber: yes, I'll do that once we have candidate CDs
[08:11] <pitti> stgraber: will you be around for a while in case of problems?
[08:11] <stgraber> sure
[08:12] <ogra> do live changes still need a meta rebuild ?
[08:12] <pitti> ogra: a publisher run
[08:12] <ogra> ok
[08:13] <pitti> ogra: please tell me when you changed something (publisher is currently running, so you have time0
[08:13] <ogra> edubuntu live seed is updated, but needs the gcompris fix to produce something unsable
[08:13] <pitti> ogra: ok, that's fine
[08:13] <ogra> LaserJock is on gcompris ...
[08:14] <pitti> ogra: when this publisher run is over, I'll start a new one for the fixed pkgbinarymangler
[08:14] <ogra> heh
[08:14] <pitti> that should update it
[08:14] <ogra> s/unsable/usable/ :)
[08:15] <LaserJock> pitti: ok, I've just dput new gcompris
[08:17] <iwj>  openoffice.org-l10n-en-gb conflicts with openoffice.org-core (<< 2.3.0~src680m224)
[08:17] <iwj>  openoffice.org-l10n-en-gb conflicts with openoffice.org-core (>= 2.3)
[08:18] <iwj> Ie upgrade is prohibited by the dependencies.  Thank apt.
[08:19] <pitti> iwj: uh?
[08:19] <pitti> iwj: that looks seriously broken
[08:20] <iwj> It's very common nowadays.
[08:20] <iwj> No-one notices because apt either forces it or removes something for a bit and then puts it back later.
[08:20] <pitti> iwj: ooh, I misread
[08:20] <pitti> Conflicts: openoffice.org-core (<< 2.3.0~src680m224), openoffice.org-core (>= 2.3.0~src680m224.1)
[08:21] <pitti> that's better and should at least install from scratch
[08:21] <pitti> iwj: if you see upgrade issues, please file a tribe-5 bug against OO, those are for calc
[08:21] <pitti> iwj: I'm afraid we are out of time to fix them for tribe4
[08:21] <iwj> Yes, I will, but only if I reproduce them with apt.
[08:21] <iwj> Indeed.
[08:22] <lamont`> pitti: I have a util-linux upload that I want to do right after tribe 4.  would you like me to upload that now and you just not approve it, or shall I wait until tribe 4 hits the street?
[08:22] <pitti> lamont`: go ahead and upload, that's fine
[08:23] <lamont`> pitti: tahnks
[08:24] <pitti> lamont`: right, the former
[08:24] <lamont`> pitti: util-linux 2.13, aka util-linux-ng, btw
[08:24] <pitti> lamont`: binaries go straight to accepted
[08:24] <lamont`> ah - that makes it make even more sense
[08:24] <lamont`> (doh)
[08:24] <pitti> lamont`: latest LP actually shows the queues, though (unapproved, new, etc.)
[08:24] <lamont`> oh, nice
[08:25] <pitti> https://launchpad.net/ubuntu/gutsy/+queue
[08:26] <pitti> hey, who approved qt4-x11?
[08:28] <pitti> thank goodness, pkgbinarymangler built now
[08:30] <LaserJock> pitti: did you approve gcompris?
[08:30] <geser> pitti: will you automatically give-back all FTBFS caused by it?
[08:30] <pitti> geser: not all, just the ones that come to my attentino
[08:31] <seb128> pitti: there is no dbgsym created for new uploads now then?
[08:31] <lamont`> pitti: uploaded util-linux, if it goes into tribe 4, it's your fault. :-)
[08:31] <pitti> seb128: why not?
[08:31] <lamont`> mind you, it should work.
[08:31] <seb128> pitti: "Build with NO_PKG_MANGLE", I'm just asking what it means ;)
[08:31] <pitti> seb128: building pkgbinarymangler *itself* without pkgbinarymangler active
[08:31] <seb128> ah, ok
[08:32] <pitti> seb128: since otherwise I could not build the fixed version which makes packages not FTBFS any more
[08:32] <pitti> yay recursive dependencies
[08:32] <geser> pitti: is xpdf (sparc and powerpc) on your give-back list already?
[08:32] <pitti> geser: yep
[08:32] <pitti> LaserJock: yes
[08:34] <pitti> http://cdimage.ubuntu.com/daily-live/20070808/ for interested testers (not the final candidates, just an intermediate release)
[08:35] <pitti> ogra: ^ those were the throwaway builds for size checking; they are quite small
[08:35] <pitti> ogra: OTOH I removed all langpacks just in case
[08:35] <ScottK> mvo_: Thank you for the apt fix (just got the bugmail) and being open to taking another look at it.
[08:36] <LaserJock> pitti: heh, we just took ours out to be like the cool kids over in Ubuntu ;-)
[08:43] <pitti> dendrobates: do you know anyone who could test the sparc server ISOs?
[08:45] <mvo_> pitti: hm, http://launchpadlibrarian.net/8738516/buildlog_ubuntu-gutsy-i386.apt_0.7.6ubuntu4_FAILEDTOBUILD.txt.gz
[08:45] <mvo_> pkgmaintainermangler: Error: Unable to locate DEBIAN/control
[08:45] <mvo_> dh_builddeb: command returned error code 256
[08:45] <mvo_> is that known?
[08:45] <pitti> mvo_: yeah, I know, I need to publish the fixed pkgbinarymangler
[08:45] <mvo_> aha, ok
[08:45] <pitti> mvo_: yeah; we managed to break all builds :/
[08:45] <pitti> including the fixed pkgbinarymangler, of course :)
[08:45] <mvo_> pitti: looks like this tribe is even worse than tribe-2 :/
[08:45] <mvo_> pitti: heh :)
[08:45] <pitti> mvo_: it's on my radar, I'll give it back as soon as 42 is in the archive
[08:45] <pitti> in about 50 minutes
[08:46] <mvo_> pitti: no worries
[08:54] <pitti> mathiaz, dendrobates, kees: http://cdimage.ubuntu.com/ubuntu-server/daily/20070808/ -> tribe4 server ISO candidates
[08:55] <mathiaz> pitti: ok. is isotesting setup correctly ?
[08:55] <mathiaz> pitti: I mean the iso testing tracker
[08:55] <pitti> mathiaz: not yet, will do now
[08:59] <pitti> stgraber: ok, so how do I add the first iso to the tracker?
[08:59] <stgraber> pitti: same way as you'd do for updated isos
[08:59] <pitti> stgraber: ah, just found it
[08:59] <stgraber> pitti: go to /addbuild, tick them, set version number and Add
[09:00] <pitti> mathiaz: added server CD to iso tester
[09:01] <mathiaz> pitti: excellent. Thanks. I'll start testing the server isos.
[11:04] (bryce/#ubuntu-devel) tepsipakki: there is a .diff.gz attached to the comment by Paul Drain on 2006-09-17; I assumed it was a patch but haven't looked at it
[11:04] (iwj/#ubuntu-devel) pitti: g-a-i died when I tried to play a media file from Examples/.
[11:05] (stgraber/#ubuntu-devel) pitti: we'll see how my small dedicated server handle that spam :) (only 256MB of ram for pgsql+mysql+apache+postfix+spam-assassin+courier+asterisk+openvpn)
[11:05] <tepsipakki> bryce: a ~200kb diff comparing the dapper ati-driver to upstream CVS :)
[11:05] <pitti> iwj: *sigh*
[11:05] <tepsipakki> or something like that
[11:05] <bryce> bleah.  ok nevermind :-)
[11:05] <pitti> iwj: at least not a blocker
[11:06] <pitti> wb ogra
[11:06] <stgraber> pitti: 3 greylisted, 1 blacklisted, 1 temporary failure, all the others have been sent successfully
[11:06] <Kopfgeldjaeger> hehe, will the universe-azureus ever work? :d
[11:08] <iwj> pitti: bug 131177 for the g-a-i crash
[11:08] <ubotu> Launchpad bug 131177 in gnome-app-install "gnome-app-install crashed with NameError in preRun()" [Undecided,New]  https://launchpad.net/bugs/131177
[11:08] <iwj> Strange, because LP offered me a potential dupe which was Fix Released 3 days ago ...
[11:09] <stgraber> pitti: Any idea when Edubuntu server will be ready ? (== Can I start testing something else ?)
[11:10] <pitti> stgraber: about 5 minutes, I'd say
[11:10] <stgraber> ok, so I'll wait for it
[11:10] <Kopfgeldjaeger> does the bcm43xx driver (installed with restricted-manager) work for anybody?
[11:10] <iwj> Has someone actually decided to include the search applet in the top right of the desktop and chosen the right searches to use ?
[11:10] <pitti> Kopfgeldjaeger: last time I checked (on my iBook), it did
[11:11] <pitti> iwj: 'that': yes; 'searches:' rather not
[11:11] <stgraber> Kopfgeldjaeger: works on a Powerbook G3 here
[11:11] <pitti> iwj: it doesn't have tracker enabled by default?
[11:11] <Kopfgeldjaeger> pitti: ok. then ill have to check it on my notebook (well, in case its my brother's) again... and remove ndiswrapper again... and cry again :'(  *g
[11:11] <iwj> A tracker ?
[11:12] <iwj> You mean it phones home somewhere ?
[11:12] <pitti> iwj: the desktop search
[11:12] <ijuz> bcm43xx may be a thing of... luck
[11:12] <iwj> It doesn't seem to be offering to search my desktop.  It lists Amazon, answers.com, CC, eBay, Google, Ubuntu package search, Wikipedia and Yahoo.
[11:12] <ijuz> (never worked for me really, i replaced it with a intel wlan card)
[11:13] <pitti> iwj: right, you need to explicitly enable the tracker plugin; that should have happened by default
[11:13] <pitti> seb128: ^
[11:13] <iwj> Should it ?
[11:13] <iwj> By `tracker plugin' do you mean it phones home ?
[11:13] <pitti> iwj: apt-cache show tracker
[11:13] <pitti> iwj: no, it's just the name of the tool that indexes your ~ and provides fast search
[11:13] <iwj> OIC
[11:13] <pitti> iwj: no remote homecalling :)
[11:13] <iwj> Good :-).
[11:14] <iwj> Just checking.  Sometimes upstreams do crazy things and they slip through ...
[11:14] <pitti> iwj: but since we enable tracker by default now, it makes kind of sense to use it in the deskbar applet
[11:14] <seb128> pitti: right, deskbar-applet doesn't make it easy to enable plugin automatically
[11:14] <Kopfgeldjaeger> just 	out of curiosity: does the ipw4965 driver support monitor mode?
[11:14] <seb128> pitti: I'll try to change the deskbar schemas to list the extra plugin, that should work if it's installed
[11:15] <pitti> seb128: merci, Monsieur
[11:15] <seb128> de rien ;)
[11:15] <pitti> seb128: too late for the tribe, though, and not a blocker
[11:15] <seb128> right, that's why I didn't bother doing it today
[11:16] <pitti> ogra, LaserJock, stgraber: http://cdimage.ubuntu.com/edubuntu/daily/20070808/
[11:16] <stgraber> pitti: great, just found my DVD+RW
[11:16] <iwj> pitti: bug 131182 for my complaints about this search feature (which are separate to the lack of the tracker)
[11:16] <ubotu> Launchpad bug 131182 in gnome-panel "search applet has inconsidered list of searches" [Undecided,New]  https://launchpad.net/bugs/131182
[11:17] <iwj> pitti: Should I milestone it for beta ?
[11:17] <pitti> LongPointyStick, Riddell, ScottK: kubuntu alternates up
[11:17] <pitti> iwj: tribe 5 would be appropriate, seb128 just said that it shouldn't be too hard
[11:17] <iwj> OK.  Should I file a separate bug about the lack of tracker ?
[11:18] <coNP> seb128: what is the problem with enabling plugins in deskbar?
[11:18] <pitti> iwj: I think 131182 is fine
[11:18] <iwj> OK
[11:18] <pitti> iwj: since tracker plugin is just one particular case of that (judging by the title)
[11:18] <seb128> coNP: there is no enable key, the enable plugins is a list, and there is no way for an another package to append things to schemas, they are only defaults you can set
[11:19] <mjg59> Amaranth: Ah. Textured video doesn't work with XAA and compositing.
[11:19] <coNP> seb128: does this hold for the new version as well?
[11:19] <seb128> coNP: ?
[11:19] <mjg59> So we either need to switch to EXA (risky at this point in the cycle) or disable compiz on Intel
[11:19] <seb128> coNP: yes, 2.19.6.1 still has a list for this key
[11:20] <coNP> Okay I guess I don't completely understand the problem. :)
[11:20] <seb128> coNP: what is not clear?
[11:21] <seb128> coNP: there is key = <lists>
[11:21] <Amaranth> mjg59: as so we're back to XAA sucking and EXA sucking more :/
[11:21] <pitti> coNP: e. g. we want to enable the deskbar tracker plugin by default, since we enable tracker itself by default
[11:21] <Amaranth> mjg59: basically we're ending up with compiz only on nvidia
[11:21] <seb128> coNP: the deskbar schemas set a default list
[11:21] <mjg59> Amaranth: Yes
[11:21] <pitti> coNP: oh, you know that already, ignore me
[11:21] <Amaranth> mjg59: and nvidia's drivers are rather shaky right now
[11:21] <coNP> pitti, seb128 yes
[11:21] <seb128> coNP: tracker has a plugin for deskbar, it needs to be added to this list to be enabled
[11:21] <Amaranth> mjg59: we've got a choice between leaving out all the 8xxx cards or having broken drivers for everyone else
[11:22] <seb128> coNP: or there is no append to a schemas option in gconf
[11:22] <seb128> you set a default value and that's about it
[11:22] <mjg59> Amaranth: I'm going to recommend that we bail on compiz by default
[11:22] <coNP> seb128: Okay. Thanks. Now I understand this :)
[11:22] <mjg59> The technology isn't ready yet
[11:22] <Amaranth> mjg59: I already said the same thing
[11:23] <Amaranth> We'll keep working on making it better on our end, hopefully the drivers will catch up
[11:23] <Amaranth> And maybe I should spend some time on libwnck again :)
[11:23] <seb128> Amaranth: could you try to get the workspaces switching shortcurts working? ;)
[11:24] <Amaranth> seb128: hehe
[11:24] <Kopfgeldjaeger> can i include a script into a deb file, the script should start automatically when installing the .deb file
[11:24] <Amaranth> Yay I've got a convert :)
[11:25] <pitti> gpocentek: Xubuntu alternates ready
[11:27] <pitti> crap, ubuntu amd64 live oversized
[11:29] <iwj> pitti: FYI 20070808 seems not to have any showstoppers for me unless you think the Places menu is one.  I think it's pretty visible, personally.
[11:29] <iwj> But it's not the beta so let it slide :-).
[11:30] <pitti> iwj: right; I'm afraid we cannot afford to fix this properly at this stage
[11:30] <iwj> I'll try out 20070808.1 too.  What changes should I concentrate on ?
[11:31] <pitti> iwj: fix in compiz crasher mainly; this also has a new apt, but that should behave
[11:31] <iwj> I didn't see the compiz crasher personally.
[11:31] <iwj> Or at least not just now :-).
[11:31] <pitti> iwj: oh, and f-spot shouldn't crash any more if you close it (but that shuold be fixed on 20070808 already)
[11:35] <pitti> iwj: 20070808.1 is oversized on amd64, I have to adjust and rebuild; new image just differs by the absence of German langpacks, so this could be tested already
[11:35] <Amaranth> *boggle*
[11:35] <Amaranth> did mvo's original libcompizconfig upload today break?
[11:36] <Amaranth> oh, that breakage
[11:40] <sistpoty> hi folks
[11:40] <pitti> hi sistpoty
[11:41] <sistpoty> hi pitti
[11:41] <ajmitch> hey sistpoty
[11:44] <LaserJock> pitti: Edubuntu Desktop up?
[11:44] <pitti> LaserJock: no, not yet; see iso tracker
[11:44] <pitti> LaserJock: server is there, though
[11:44] <LaserJock> pitti: great
[11:45] <pitti> LaserJock: kubuntu desktop is ready in ~ 10 minutes, edubuntu in ~ 50 minutes
[11:45] <LaserJock> pitti: excellent thanks
[11:45] <mathiaz> is it normal that universe is enabled by default on server installs ?
[11:46] <pitti> wow, that's the first time that rescue mode doesn't hang after exiting from the rescue shell; thanks cjwatson_!
[11:51] <mikmor2> cjwatson: hello
[11:51] <mikmor2> cjwatson: Are there any directories shared between ubiquity's target and the live FS during target-config?
[11:57] <RAOF> Amaranth: Surely we can upgrade nvidia-glx-new to the 100 series, and suggest everyone without a 8x00 series card uses the nvidia-glx drivers?
[11:58] <Amaranth> RAOF: "But it says -new, it must be better! Why is my system locking up all the time?"
[11:58] <pitti> Riddell, LongPointyStick, ScottK: kubuntu desktop ready for testing
[11:59] <RAOF> Amaranth: :(
[11:59] <sistpoty> RAOF: iirc debian uses different source packages for each driver series, would that be an approach for ubuntu as well? (/me is affected, so I'm asking *g*)
[11:59] <Amaranth> yeah, nvidia puts the driver version in the package name
[11:59] <Riddell> thanks pitti
[11:59] <pitti> sistpoty: in fact, the -legacy and -new was a hack of our's I think
[11:59] <Amaranth> err
[11:59] <pitti> sistpoty: and I seriously hope that we can unify it again
[11:59] <Amaranth> s/nvidia/debian/
[11:59] <sistpoty> pitti: ah, k
[11:59] <Amaranth> need more caffeine
[12:00] <pitti> BenC: do you think that's realistic? ^
[12:00] <mjg59> RAOF: Because every time we try to provide older drivers to people, they cry
[12:00] <BenC> pitti: what's that?
[12:01] <pitti> BenC: unifying nvidia-glx-*, as we discussed quickly before feisty
[12:01] <mjg59> (See us carrying three nvidia packages, when we only actually need two to support the same range of hardware)
[12:01] <pitti> BenC: i. e. selecting the right module on boot, based on our modalias maps
[12:01] <pitti> BenC: otherwise upgrade issues will only get worse in the future, I'm afraid
[12:01] <BenC> pitti: we already do that
[12:01] <sistpoty> mjg59: is that true? I thought there were regressions with the newer driver as well
[12:01] <sistpoty> s/driver/drivers/
[12:01] <pitti> BenC: oh?
[12:02] <BenC> pitti: problem is we can't install all of the userspace packages at once (the xorg/GL parts)
[12:02] <ajmitch> hello jono
[12:02] <pitti> BenC: yeah, that was the alternatives approach or so, right?
[12:02] <jono> hey ajmitch
[12:02] <BenC> pitti: right, and quite complex an approach it would be
[12:02] <pitti> BenC: s/bootup/package install, probably/
[12:03] <BenC> pitti: restricted-manager would be responsible for the update-alternatives invocation...but the complex part is that there are lots of differing files in each package that overlap
[12:03] <BenC> pitti: it scares me a lot :)
[12:03] <pitti> BenC: hm, not sure whether calling r-m on upgrades would work
[12:04] <pitti> BenC: me too, but with the current structure we only aggravated the upgrade problem
[12:04] <BenC> pitti: it could also be put into lrm init script
[12:04] <mjg59> sistpoty: ? I meant that last time around, we could just have dropped people back to the old legacy package
[12:04] <mjg59> But they wanted the latest drivers that supported their hardware, even if that meant an extra package
[12:04] <wasabi> Wonder if anybody is ever going to make GL go through an intermediate libGL layer.
[12:04] <wasabi> Like MS did... in 98.
[12:07] <sistpoty> mjg59: I'm not quite sure if it's that easy, as newer driver for old HW solved some issues (though that is only my impression and I don't know the real facts :P)
[12:08] <mathiaz> dendrobates: when testing the LAMP case, you'll get a '404 not found' when connecting the server.
[12:08] <mathiaz> dendrobates: it's already been report as bug 130625
[12:08] <ubotu> Launchpad bug 130625 in apache2 "Empty /etc/apache2/sites-enabled - Apache's default site not enabled on install" [Unknown,Fix committed]  https://launchpad.net/bugs/130625
[12:09] <dendrobates> mathiaz:I'm doing that now
[12:10] <pitti> mathiaz: eek
[12:10] <pitti> mathiaz: who can I assing this to?
[12:11] <mathiaz> pitti: assign what ? the universe/mutliverse by default ?
[12:11] <pitti> mathiaz: apache bug above
[12:12] <mathiaz> pitti: the apache bug has already been fixed in debian
[12:12] <mathiaz> pitti: I've filled a sync request this morning.
[12:12] <pitti> mathiaz: oh, we can sync? can you please mark this as a dup of the sync bug then?
[12:13] <pitti> dendrobates: do you think this is serious enough to get fixed for tribe4?
[12:13] <mathiaz> pitti: ok. Is this the standard way to do it ?