[12:14] <JanC> http://www.fosdem.org/2007/node/81
[12:23] <pitti> LongPointyStick, Riddell: any idea about bug #121456?
[12:23] <ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
[12:24] <pitti> LongPointyStick, Riddell: can you please set an assignee for this? Thank you
[12:32] <Kmos> Riddell: bug 104848
[12:32] <ubotu> Launchpad bug 104848 in hwdb-client "Bad english translation on hwdb-client" [Undecided,Confirmed]  https://launchpad.net/bugs/104848
[12:32] <Kmos> check this one
[12:32] <Kmos> i've attached a debdiff
[02:56] <keescook> realist: general public security discussions have been moved to the motu mailing list.  If you have a patch upstream won't take, that's a concern -- if it's a "real" problem, we should find a way to convince upstream why it's important.  If that's not possible, carrying the patch in Debian is next best, and finally Ubuntu.
[03:01] <LaserJock> anybody got a gutsy machine and are willing to do a quick application test for me?
[03:03] <sbalneav> LaserJock: I'm heading home in a few minutes, where my gutsy box is, what do you need?
[03:03] <LaserJock> I need an xaos test
[03:03] <LaserJock> just open it up and try to get to a help/tutorial
[03:04] <sbalneav> Gonna be around tonight?
[03:04] <LaserJock> yeah, later is fine
[03:04] <sbalneav> ok, I'll be home in less than an hour.
[03:04] <sbalneav> I'll do it for you then.
[03:04] <LaserJock> np
[03:04] <sbalneav> see you all later.
[03:05] <johanbr> LaserJock: Seems to work for me, with xaos version 3.2-4ubuntu1
[03:08] <LaserJock> johanbr: did you run xaos from the menu or command line?
[03:08] <johanbr> Command line
[03:10] <LaserJock> can you try it from the menu?
[03:11] <ajmitch> hi LaserJock
[03:13] <LaserJock> hi ajmitch
[03:18] <LaserJock> johanbr: did you get into the actual help or just the help menu?
[03:19] <johanbr> LaserJock: Oh, sorry I wasn't paying attention. I'll try it from the menu. And I used the help menu to get into one of the tutorials.
[03:22] <johanbr> LaserJock: It also works running from the menu, going into the help system. The only problem I noticed is that the window has some weird transparency when running under Xgl.
[03:23] <LaserJock> for some reason in Feisty ${prefix} wasn't getting expanded so it was looking for the help literally in "${prefix}/usr/share/"
[03:23] <LaserJock> johanbr: ah, is it really light?
[03:23] <johanbr> yes
[03:23] <LaserJock> there is a bug report about using xaos and beryl causing that
[03:24] <johanbr> Alright.
[03:25] <LaserJock> bug #109406 if you care to add to it
[03:25] <ubotu> Launchpad bug 109406 in xaos "beryl makes xaos impossible (almost ) to use" [Undecided,New]  https://launchpad.net/bugs/109406
[03:26] <LaserJock> johanbr: thank you very much for testing that
[03:26] <johanbr> You're welcome. Glad I could be of help. :)
[03:36] <lousygarua> how can i reopen a bug which was marked invalid? bug 121995
[03:36] <ubotu> Launchpad bug 121995 in Ubuntu "Ubuntu logo cropped on launchpad page entry" [Undecided,Invalid]  https://launchpad.net/bugs/121995
[03:36] <ScottK> lousygarua: Change the status to something other than invald.
[03:37] <lousygarua> ScottK: i don't have that kind of option. was it blocked by some kind of ultra administrator?
[03:37] <ajmitch> bugs are generally marked as invalid as a reason
[03:38] <ajmitch> in this case I'd presume from the title that the bug is in launchpad, not in ubuntu
[03:38] <lousygarua> ajmitch: not really in launchpad, it's more like a human-error they made
[03:38] <ajmitch> the first reply also says where to file the bug
[03:39] <lousygarua> ajmitch: it says "there", i have no idea where is it. i'd put it there in the first place coz it also seems not logical to me to file it under ubuntu
[03:39] <ScottK> lousygarua: Look at the bug again.
[03:40] <lousygarua> ScottK: launchpad... hmm.
[03:40] <LaserJock> hmm, interesting, I hadn't noticed that before
[03:40] <ScottK> Yep.  That's what the bug is in (and I see it too).
[03:40] <lousygarua> ScottK: well i still think it's a human-error and not a bug in launchpad but i'll file it there anyway
[03:40] <LaserJock> shouldn't it just be retargeted to Launchpad
[03:41] <ScottK> LaserJock: Maybe you know LP ju ju better than I do.  That's the best I could do...
[03:41] <LaserJock> lousygarua: but the bug is about something in launchpad, not in Ubuntu
[03:41] <lousygarua> LaserJock: they made it invalid so i guess the bug is dead
[03:41] <LaserJock> lousygarua: no it's not
[03:41] <LaserJock> lousygarua: they made that task invalid
[03:41] <ScottK> It's invaild in Ubuntu, but not Launchpad now.
[03:41] <ScottK> LaserJock: I just added the LP task.
[03:42] <lousygarua> ScottK: LaserJock: hmm so how do i add an affected package besides distribution and upstream?
[03:43] <LaserJock> those are the options
[03:43] <LaserJock> in this case I think upstream works
[03:43] <lousygarua> ScottK: LaserJock: hmm i think i'm stupid
[03:43] <LaserJock> lousygarua: I doubt it
[03:43] <LaserJock> it takes some getting used to
[03:44] <lousygarua> ScottK: LaserJock: oh well i'll just file it under launchpad and link to the invalid bug thing
[03:44] <lousygarua> ScottK: LaserJock: thanks
[03:44] <LaserJock> lousygarua: no, it's already taken care of
[03:44] <lousygarua> LaserJock: stealing my karma, are you?
[03:44] <LaserJock> ScottK just added a task against Launchpad, have another look
[03:44] <LaserJock> heh, no
[03:45] <LaserJock> I don't need to steal people's karma
[03:45] <ajmitch> you're a deity all by yourself without other peoples' karma
[03:45] <lousygarua> LaserJock: :) j/k
[03:45] <LaserJock> ajmitch: exactly ;-)
[03:46] <lousygarua> LaserJock: well, thanks again anyway
[03:49] <LaserJock> hi Hobbsee
[03:50] <Hobbsee> :)
[03:51] <ajmitch> Hobbsee!
[03:52] <Hobbsee> ajmitch!
[06:14] <fabbione_> morning guys
[06:17] <LaserJock> hi fabbione
[08:16] <dholbach> good morning
[08:17] <LaserJock> morning dholbach
[08:17] <dholbach> heya LaserJock
[08:23] <pygi> morning dholbach and LaserJock
[08:23] <dholbach> hi pygi
[08:26] <pitti> Good morning
[08:26] <fabbione> hey pitti
[08:26] <pitti> hi fabbione
[08:27] <pitti> fabbione: could you please do me a favour?
[08:27] <fabbione> pitti: i guess so
[08:27] <pitti> fabbione: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html has some sparc-isms; do you have a clean gutsy chroot with only 'main' enabled?
[08:27] <fabbione> pitti: i can make one for sure...
[08:27] <pitti> fabbione: and could you try to apt-get install those packages and see what we need to fix to make them installable?
[08:28] <fabbione> pitti: on it
[08:28] <pitti> fabbione: thank you
[08:28] <fabbione> no problem at all
[08:28] <pitti> fabbione: so, language-selector fails due to adept, and kubuntu-desktop due to language-selector (I hope there's no other reason)
[08:30] <pitti> fabbione: I guess it comes down to libept FTBFSing on sparc (http://launchpadlibrarian.net/8161201/buildlog_ubuntu-gutsy-sparc.libept_0.5.7_FAILEDTOBUILD.txt.gz)
[08:31] <fabbione> pitti: i am bootstrapping the chroot right now
[08:31] <fabbione> sorry this machine is not the fastest i have at the moment
[08:31] <pitti> fabbione: no problem, just thinking loud
[08:31] <fabbione> eheh ok
[08:32] <fabbione> pitti: ept_apt_version: ......Bus error
[08:32] <fabbione> ^^ non-64bit allignment memory access
[08:33] <pitti> hm, 0.4.7ubuntu2 still built on sparc
[08:33] <fabbione> it might build.. sure.. but not run
[08:34] <fabbione> gcc doesn't detect that at build time
[08:34] <pitti> fabbione: no, that's an old version; maybe it didn't have a test suite yet
[08:34] <fabbione> i will look into it.. it might be something totally unrelated that's crashing
[08:34] <pitti> so it's a runtime failure, but the test suite is run during build
[08:35] <fabbione> yeah it's all good
[08:35] <fabbione> i will at least pinpont what fails
[08:35] <fabbione> but i am not going to patch it...
[08:35] <fabbione> there is faure to do that
[08:35] <fabbione> how is ept maintainer anyway?
[08:35] <pitti> Maintainer: Enrico Zini<EMAIL_ADDRESS>[08:36] <fabbione> oh boys
[08:36] <fabbione> enrico: ping?
[08:36] <pitti> in Debian, it's still depwait on sparc
[08:44] <StevenK> pitti: I've been looking at merging the new version of ept.
[08:44] <pitti> StevenK: 'new version'? not from Debian then?
[08:44] <StevenK> pitti: Sorry, yes from Debian.
[08:45] <pitti> Burgundavia: I dont' see a new version in Debian
[08:45] <pitti> erm, StevenK ^
[08:45] <pitti> we synced 0.5.7
[08:45] <StevenK> Ah.
[08:45] <StevenK> I didn't know that bit.
[08:46] <pitti> Burgundavia: do you think the marketing team will have time for the tribe2 news wiki page? or shall I prepare for elaborating in the release notes?
[08:47] <Burgundavia> I will do it
[08:47] <pitti> Burgundavia: great, thank you
[08:48] <StevenK> pitti: In terms of stuff I'm qualified to talk about, 3 out of the 4 jasper rebuilds were uploaded last night, leaving rss-glx and graphicsmagick. rss-glx is waiting on the two MIRs, and graphicsmagick blows up fairly spectacularly during a test build.
[08:48] <Burgundavia> pitti: can you fire an email to -marketing?
[08:49] <pitti> ogra: edubuntu server/i386 is 14 MB oversized, btw
[08:49] <pitti> Burgundavia: hm, I did last Friday
[08:49] <pitti> two, actually
[08:50] <StevenK> Hurray, someone else filed a bug on packagesearch saying it doesn't work with the new libept.
[08:50] <pitti> https://lists.ubuntu.com/archives/ubuntu-marketing/2007-June/002085.html
[08:50] <Burgundavia> pitti: ok
[08:57] <fabbione> pitti:
[08:57] <fabbione>   debtags: Depends: libapt-pkg-libc6.4-6-3.53 but it is not installable
[08:57] <fabbione> E: Package libapt-pkg-libc6.4-6-3.53 has no installation candidate
[08:57] <fabbione> that would solve also adept
[08:58] <pitti> fabbione: ok, so that's really the only reason?
[08:58] <fabbione> seems like
[08:58] <StevenK> debtags and adept need a rebuild?
[08:58] <pitti> fabbione: ok, so it all comes down to the libept FTBFS
[08:58] <fabbione>   ltsp-client: Depends: usplash-theme-ubuntu but it is not installable
[08:58] <fabbione> pitti: checking the others
[08:58] <fabbione> E: Package usplash-theme-ubuntu has no installation candidate
[08:58] <fabbione> ?
[08:58] <pitti> StevenK: debtags is DEPWAIT for libept, it'll autorebuild once libept gets fixed
[08:58] <pitti> usplash-theme-ubuntu |       0.14 |         gutsy | source, amd64, i386, powerpc
[08:58] <StevenK> Ahhh
[08:59] <pitti> fabbione: apparently no usplash on sparc?
[08:59] <fabbione> pitti: but why?
[08:59] <fabbione> it used to build
[08:59] <pitti> latest version still does
[09:00] <fabbione> LP lost the binaries?
[09:00] <fabbione> ltspfsd -> ltsp-client
[09:00] <pitti> fabbione: usplash_0.5.2_sparc.deb is on drescher
[09:01] <fabbione> checking if it is here
[09:01] <StevenK> But usplash-theme-ubuntu is a seperate source package.
[09:01] <pitti> fabbione: it's not in PaS
[09:01] <fabbione> it's not in my local archive
[09:01] <fabbione> fabbione@gordian:/mirrors/ubuntu/pool/main/u/usplash-theme-ubuntu$ ls *.deb
[09:01] <fabbione> usplash-theme-ubuntu_0.14_amd64.deb  usplash-theme-ubuntu_0.6_amd64.deb
[09:01] <fabbione> usplash-theme-ubuntu_0.14_i386.deb   usplash-theme-ubuntu_0.6_i386.deb
[09:01] <Mithrandir> there's no build for u-t-u on sparc.
[09:01] <pitti> fabbione: so, drescher's Package.gz does have it
[09:02] <Mithrandir> that is, for the latest version
[09:02] <StevenK> Or powerpc
[09:03] <pitti> Package: usplash-theme-ubuntu
[09:03] <pitti> Architecture: i386 powerpc amd64
[09:03] <StevenK> usplash-theme-ubuntu-0.14% grep Arch debian/control
[09:03] <StevenK> Architecture: i386 powerpc amd64
[09:03] <pitti> that's explainable
[09:03] <StevenK> pitti: Bah! :-)
[09:03] <fabbione> somebody should fix that
[09:04] <fabbione> usplash works on sparc
[09:04] <fabbione> or used to
[09:04] <StevenK> I'm happy to upload 0.15 that sets Architecture to any
[09:04] <pitti> fabbione: will do
[09:04] <pygi> oh well, StevenK can do it :P
[09:04] <fabbione> oh well
[09:04] <pitti> StevenK: handing over to you then :)
[09:04] <fabbione> anybody can do it :)
[09:05] <pitti> fabbione: thanks for the investigations
[09:06] <fabbione> pitti: i am going to look into ept failure in a few minutes. i am debugging something worst atm
[09:18] <fabbione> pitti: libept building now
[09:19] <StevenK> pitti, fabbione: Just about to upload u-t-u with Arch: any
[09:20] <fabbione> StevenK: cool thanks
[09:24] <StevenK> pitti: gutenprint on gutsy_probs looks to be a rebuild, want me to handle it?
[09:28] <pitti> StevenK: I mailed Till, but if a rebuild really solves is, please go ahead
[09:28] <pitti> StevenK: I just uploaded a new version maybe four days ago, that's why I had some doubts
[09:29] <StevenK> Ah, okay. I'm just to leave to go home. I'll look in roughly an hour if Till hasn't already.
[09:35] <dholbach> StevenK: pitti: a rebuild fixes it
[09:36] <pitti> dholbach: thank you
[09:36] <fabbione> pitti: so the test suite executed manually works
[09:36] <fabbione> it BusHorror when executed from the script that does some crazy relink stuff
[09:37] <fabbione> tests summary: exceptions:4 failures:24 ok:49
[09:37] <fabbione> root@vultus5:~/libept-0.5.7# echo $?
[09:37] <fabbione> 0
[09:39] <pitti> fabbione: so it's just a test suite problem?
[09:39] <fabbione> pitti: seems so
[09:39] <pitti> fabbione: in that case, "./run-tests || [ `uname -m` = sparc ]  " might be an appropriate workaround until Debian fixes it :)
[09:40] <fabbione> pitti: i am ok with whatever solution you prefer
[09:40] <fabbione> this is C++ and some crazy gcc/ld stuff that i am not sure i want to start digging atm
[09:40] <fabbione> i am working on some more important and urgent stuff at the moment
[09:40] <fabbione> like SUN disk label corruption
[09:40] <pitti> running the test suite on the other arches is still good, but I'm fine with silencing it on sparc; enrico will encounter it on Debian anyway
[09:40] <fabbione> yeah
[09:41] <fabbione> worst case i can give sparc access to enrico
[09:41] <fabbione> that's not an issue
[09:41] <pitti> fabbione: maybe s/uname -m/dpkg --print-architecture/
[09:41] <fabbione> pitti: whatever you prefer :)
[09:41] <pitti> fabbione: could you do that workaround?
[09:42] <fabbione> pitti: perhaps we want to make it build1 instead of ubuntu1?
[09:42] <pitti> fabbione: well, it's a modification, so ubuntu1 is necessary AFAICS
[09:42] <pitti> ... so we should blame it all on Sebastien
[09:43] <fabbione> pitti: i agree...
[09:43] <pitti> oh, good morning seb128
[09:43] <seb128> hey pitti
[09:43] <fabbione> pitti: anyway i am on it since seb128 it's not even awake yet.. slacker
[09:43] <pitti> seb128: (just ignore us)
[09:43] <seb128> oh, people doing my job, cool
[09:43] <seb128> I can get some extra sleep then ;)
[09:45] <pitti> seb128: can we do something about downsizing gnome-user-guide? maybe using bzip2 will give us some space back?
[09:45] <pitti> we need to chop off 20 MB from the alternates somehow
[09:45] <seb128> didn't you do this previous cycle?
[09:45] <pitti> seb128: that was ubuntu-user-guide
[09:45] <seb128> ah
[09:45] <pitti> (or similar)
[09:45] <seb128> well, probably yes
[09:46] <seb128> I'll give it a try
[09:47] <superm1> Mithrandir, good morning, ping
[09:48] <pitti> seb128: just as a reminder, please don't forget the Pre-Depends: dpkg (>= 1.10.24)
[09:48] <seb128> pitti: right
[09:49] <superm1> ah pitti i wanted to ask you something too.  When composite by default goes live, how are things going to be handled about nvidia prop driver?  Is it going to be preinstalled with restricted manager just notifying immediately in the live env, or just the same as waiting until the reboot to activate them?
[09:49] <pitti> superm1: we won't enable binary drivers by default yet; ATM compiz will only be enabled on known-good drivers/cards
[09:49] <pitti> like intel
[09:49] <superm1> okay thats what i was thinking the case would be
[09:49] <pitti> other users will end up with metacity
[09:50] <superm1> pitti, is there any chance that restricted manager could ever get a text frontend so that it can easily be used in things like ubiquity though?
[09:51] <pitti> superm1: there is already --enable and --disable
[09:51] <pitti> superm1: I'm fine with implementing other stuff, whatever is necessary
[09:52] <superm1> pitti, doesn't that still use X though because it calls synaptic to do the package install?
[09:52] <pitti> superm1: right
[09:53] <pitti> but ubiquity does, too :)
[09:53] <pitti> (use X)
[09:53] <pitti> but we could teach it to work with apt-get, too, when there is no $DISPLAY
[09:54] <superm1> well reason i'm bringing any of this up, i was attempting to adapt it to the mythbuntu frontend that ubiquity will be getting, and i was wondering if a command line installer such as apt-get could be an option instead
[09:54] <superm1> because its already in a chroot at the point its getting installed
[09:55] <superm1> the other problem too though is displaying the license when no $DISPLAY is available.
[09:57] <pitti> seb128: hm, gnome-user-guide with bzip2 only saves 400 KB
[09:58] <pitti> darn
[09:58] <seb128> pitti: not worth doing it then
[10:02] <dholbach> pitti: do you know why libgnomedb is in main?
[10:03] <pitti> dholbach: not really, it seems to only depend on itself
[10:04] <dholbach> ok, we can throw it out then :)
[10:04] <dholbach> gtk-sharp is the last problem before we can move gda2 to universe
[10:04] <pitti> ah, build dep of glade, which was in main until recently
[10:04] <pitti> dholbach: gtk-sharp is in universe
[10:04] <dholbach> oh?
[10:04] <pitti> I wonder why anastacia doesn't show libgnomedb then
[10:05] <dholbach> oh great
[10:05] <pitti> supported: * libgnomedb2-bin
[10:05] <pitti> ah
[10:07] <pitti> dholbach: only libgda2 rdep left is planner
[10:07] <dholbach> I'll drop the build-dep, so we don't have the database exporter plugin until it is ported to gda3
[10:15] <fabbione> pitti: libept uploaded
[10:15] <pitti> fabbione: yay, thanks
[10:15] <fabbione> no problem
[10:16] <Fujitsu> pitti: Is apport meant to be giving useless bugs like #121710?
[10:16] <Fujitsu> bug #121710
[10:16] <ubotu> Launchpad bug 121710 in glabels "glabels crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/121710
[10:17] <pitti> Fujitsu: not meant to, of course, but it's due to bug 119267
[10:17] <ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Fix committed]  https://launchpad.net/bugs/119267
[10:17] <pitti> Fujitsu: when you encounter them, please just reject them
[10:17] <pitti> Fujitsu: well, 'invalid' in the new Malone world now
[10:18] <dholbach> pitti: planner uploaded
[10:18] <Fujitsu> pitti: Right, will do.
[10:18] <dholbach> pitti: once it has built, we can dump gda2
[10:18] <Fujitsu> Thanks.
[10:18] <pitti> dholbach: rock
[10:22] <pitti> oh, we ship python2.4 on the alternates; that seems like a good candiate for kicking
[10:22] <pitti> doko: ^ do we actually need that for anything?
[10:28] <Fujitsu> Is there any particular reason that the dist-upgrader error reporting doesn't give the version of the package?
[10:41] <Mithrandir> superm1: please don't just contentless ping me, it's useless; I respond if I'm around and not if I'm not.
[10:43] <pitti> bryce, seb128: do we really need both xfonts-75dpi and xfonts-100dpi by default?
[10:47] <dholbach> pitti: due to the fixed glib abi change, lots of g*mm packages have to be rebuilt - expect lots of uploads in a bit
[10:48] <StevenK> dholbach: If you need a hand, let me know.
[10:48] <Fujitsu> pitti: Is it coming back at any point in the foreseeable future?
[10:48] <StevenK> pitti: Oh, now I remember what I wanted to talk you about.
[10:48] <dholbach> thanks StevenK, I think I'll simply script
[10:48] <pitti> Fujitsu: I hope today, I'll poke cprov again
[10:49] <Fujitsu> I would have thought it was fairly urgent.
[10:49] <pitti> Fujitsu: the problem and solution are clear, it just needs rollout
[10:49] <Fujitsu> Ah.
[10:49] <pitti> Fujitsu: it is, absolutely; lack of -changes really sucks
[10:49] <StevenK> Are the mails that didn't hit there lost forever?
[10:49] <Fujitsu> I suspect they're easy to regenerate.
[10:50] <StevenK> pitti: Two or three (I haven't looked deeply) of the packages listed under universe for libwnck are Beryl or Beryl related. Are they going to be killed, or should I fix them?
[10:51] <Fujitsu> And is there any reason to keep desktop-effects around?
[10:51] <pitti> Fujitsu: d-e is in universe now
[10:51] <pitti> StevenK, mvo: dunno, can we remove the beryl packages for good? have they been merged completely?
[10:51] <Fujitsu> pitti: Right. As in, does it want to exist at all?
[10:52] <crimsun> pitti: does http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/gutsy/daily-20070625.log correspond to daily?
[10:52] <pitti> Fujitsu: I don't see much reason for it any more
[10:52] <pitti> crimsun: not sure what you mean exactly
[10:52] <Fujitsu> pitti: I presume it was demoted because the new Appearance tab replaces it... so it should probably cease to exist, along with all its lovely bugs.
[10:53] <crimsun> pitti: meaning are those the actual binary packages ending up on daily?  If so, I can cut ~2 MB from alt. for libasound2-plugins
[10:53] <gicmo> seb128: ALTER
[10:53] <seb128> gicmo: Alter!
[10:53] <pitti> crimsun: the ones mentioned in the logs, yes
[10:53] <pitti> mvo, seb128: do you see any reason to keep desktop-effects even in universe?
[10:53] <seb128> no
[10:54] <Fujitsu> Yay :)
[10:54] <crimsun> pitti: ok, I'll upload a new libasound2-plugins with the ffmpeg bit disabled to buy 2 MB more for alternate.
[10:54] <Fujitsu> Do we need a removal request bug?
[10:54] <StevenK> pitti: And I can name roughly 6 people who want to see Beryl dead. :-)
[10:54] <pitti> seb128: can gnome-control-center C/R/P: desktop-effects then, for clean upgrades?
[10:54] <pitti> Fujitsu: I'll do it now once we sort out the migration with seb128
[10:57] <seb128> pitti: they don't really conflicts, is using C,R,P correct?
[10:58] <pitti> seb128: right, they don't conflict file-wise, but this is the 'package a now provides the functionality of b, and b is obsolete' case, right?
[11:01] <pitti> lifeless: ship: * cvs [i386 amd64]     # RobertCollins
[11:01] <seb128> pitti: well, C,R,P doesn't provide an upgrade path, it just make gnome-control-center installed when you "apt-get install desktop-effects"
[11:01] <pitti> lifeless: would you be really worried if we moved this from ship to supported? :)
[11:01] <lifeless> DoIt
[11:01] <seb128> if it was not installed
[11:01] <pitti> lifeless: it would save us 1.6 MB from the CD
[11:02] <pitti> seb128: well, but for people who have control-center installed it would remove d-e on upgrade
[11:02] <seb128> right
[11:03] <pygi> hey seb128, how is it going?
[11:03] <seb128> hi pygi
[11:03] <pitti> does anyone know something else that we could kick off the alternate CDs?
[11:03] <seb128> good, slightly busy though
[11:04] <pitti> hm, we could kick nvidia-glx
[11:04] <pygi> seb128, k, then I'll bug about GB later on
[11:04] <lifeless> would it be evil for svn to suggest bzr-svn ?
[11:04] <Mithrandir> as long as it's a suggests, I don't see why
[11:05] <pitti> Mithrandir: do you see an imperative reason to keep nvidia-glx in ship?
[11:05] <thom> hrm, shouldn't bzr-svn Enhances: svn?
[11:05] <thom> and not touch svn
[11:05] <lifeless> thom: ah yes, true.
[11:05] <Fujitsu> thom: Has there actually been a use of Enhances before?
[11:05] <Mithrandir> thom: except nothing uses enhances, afaik
[11:06] <thom> Fujitsu: no idea. this seems like a good point to start, though
[11:06] <lifeless> nothing stops us doing both
[11:06] <shawarma> pitti: It's "ship" in the seeds that control what ends up on the alternate CD, right?
[11:06] <pygi> Fujitsu, probably, but neither apt or synaptic use it :P
[11:06] <lifeless> Enhances for correctness, suggests to make it work
[11:06] <pitti> shawarma: right, on top of ubuntu-desktop
[11:06] <Mithrandir> pitti: hardware support? :-P I think we should have it in ship.
[11:07] <pitti> Mithrandir: so we prefer nvidia over ati? :-)
[11:07] <Mithrandir> pitti: their driver is less bad, afaik
[11:07] <pitti> Mithrandir: AFAICS it would be one of the lesser evils for amputation candidates
[11:07] <Mithrandir> oh well
[11:08] <pitti> I'm not really sure what accounts for the 20 MB the alternates grew since tribe-1
[11:08] <pitti> I diffed the file lists, and there were no significant additiosn
[11:09] <pitti>  * mutt                # ThomMay; we need a basic mail client, this is the best-smallest
[11:09] <pitti> hmmm
[11:10] <seb128> pygi: GB?
[11:11] <thom> pitti: mutt is tiny!
[11:11] <pitti> thom: 1.3 MB
[11:11] <pygi> seb128, Gnomebaker
[11:11] <seb128> pygi: just ask
[11:11] <pitti> thom: well, 1.1, but it's a start
[11:11] <fabbione> pitti: what about checking file size of packages from tribe-1 cd and see if one of them exploded in -2 ?
[11:11] <pygi> seb128, it's not urgent, just do your work now
[11:11] <pitti> thom: it's my MUA as well, but we have to kick something
[11:11] <thom> true
[11:11] <fabbione> pitti: perhaps it's just a packaging error
[11:12] <pitti> fabbione: something like that, yes; last time it was ubuntu-docs
[11:12] <pitti> but that's not it
[11:12] <seb128> pygi: I'm almost busy all the time, you better ask now if you want something :p
[11:12] <shawarma> Do we really need an MTA on the alternate CD?
[11:12] <pitti> shawarma: we have evolution
[11:12] <pitti> oh, MTA
[11:12] <shawarma> MTA. not MUA
[11:13] <shawarma> Postfix is in ship.
[11:13] <pygi> seb128, don't want anything :) Just wanted to see what can we do about insane amount of bugs which GB has, and it's not maintained upstream right now for a long time AFAIK
[11:13] <pitti> shawarma: well, there is a server mode, but now that we have a server CD, I'm inclined to kick samba and postfix
[11:13] <fabbione> hmmm no we don't but make sure it won't kill it from the server cd
[11:13] <shawarma> We have a server CD and if someone wants an MTA, they probably have an internet connection..
[11:13] <pitti> shawarma: and server is now called 'CLI'
[11:13] <seb128> pygi: well, triage them or take over upstream ;)
[11:13] <pitti> fabbione: no, just from ship
[11:13] <shawarma> pitti: No, I think we should leave samba.
[11:13] <seb128> pygi: we can't remove it, it has an userbase
[11:14] <fabbione> IIRC there are a bunch of gnome stuff that use samba
[11:14] <pitti> shawarma: we have the client stuff anyway, why do we need the server on the alternate so urgently?
[11:14] <pygi> seb128, it's easy to triage, but we can't create too many patches --> imho, useless when brasero works pretty good. And "haha" on the b) option
[11:14] <pitti> fabbione: client only
[11:14] <pygi> seb128, yea, I understand that.
[11:14] <pygi> seb128, some time in the future (when we can get some sane replacement) I also want to move xfburn (main) to universe, because it's *broken* and *can't* burn a cd
[11:14] <shawarma> pitti: I think it's commonly used to share files, that's all.
[11:15] <pygi> but that's pending discussion with Jani
[11:15] <seb128> pygi: that's from xfce, I can't speak about this one
[11:15] <pygi> seb128, right, but about GB you can ^_^
[11:16] <seb128> well, it's being used so we can't remove it
[11:16] <seb128> and there is no better replacement anyway
[11:16] <shawarma> pitti: I'm not that passionate about it, I just don't think its removal be as easily justified as postfix'.
[11:16] <pitti> shawarma: I agree
[11:17] <pygi> seb128, how come? Brasero isn't better?
[11:17] <hunger> How can I stop that damn xdg-user-dirs from spamming my homedir with directories?
[11:17] <seb128> pygi: is brasero working?
[11:18] <pygi> seb128, what kind of question would that be? xD
[11:18] <seb128> pygi: I don't burn CDs out of nautilus-cd-burner, I didn't use gnomebacker nor brasero yet
[11:18] <pygi> seb128, do try. It uses libburn & libisofs
[11:18] <pygi> I made the packages, it gotta work :P
[11:19] <seb128> I had the impression that brasero was being actively worked but not stable and ready for mass usage yet
[11:19] <shawarma> hunger: See $HOME/.config/user-dirs.dirs
[11:19] <shawarma> hunger: Just set them all to point directly to your $HOME or whereever you want things to land.
[11:19] <pygi> seb128, do try, you'll change your opinion ;)
[11:19] <seb128> hunger: no need to be agressive
[11:19] <pygi> seb128, it doesn't however build on sparc and ppc, I'm after upstream for that
[11:19] <seb128> pygi: should we promote it to desktop and start shipping it on the CD then?
[11:20] <pygi> bugs that brasero has right now, and most of them I could solve:
[11:20] <pygi> https://bugs.launchpad.net/ubuntu/+source/brasero/
[11:21] <pygi> see bug: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/91043
[11:21] <ubotu> Launchpad bug 91043 in brasero "Install Brasero by default" [Wishlist,New]
[11:21] <pygi> for my opinion on shipping on cd & installing by default
[11:21] <hunger> seb128: Sorry. I have to appologize.
[11:21] <pygi> however yes, indeed ... in the future (be it for gutsy or a gutsy+1) we will have to push a gtk+ cdrecording application forward
[11:21] <hunger> shawarma: Thanks! and sorry for being so rude.
[11:22] <shawarma> hunger: Actually, I did not even notice the "that damn" part and then it wasn't so bad at all :)
[11:22] <seb128> pygi: well, "Brasero doesn't burn audio cd" for example is something which make me tell it's not ready
[11:22] <pitti> ah, evolution-common alone grew by 4 MB
[11:22] <pygi> seb128, as I said ... not yet :P
[11:22] <pygi> seb128, read my comment on that bug =)
[11:23] <pygi> it can't be pushed to main anyway as sparc and ppc don't build
[11:23] <pygi> and I have no intention to seriously overhaul upstream code to make it work
[11:23] <pygi> (might not be like that, but still ... it's still scsi issues, with new parts of the code introduced in 0.5.90)
[11:24] <pygi> seb128, we'll see, I know =)
[11:24] <pygi> patience ^_^
[11:24] <pygi> there are some new things in the works, let's see how it works out
[11:25] <seb128> right
[11:25] <doko> pitti: yes, for zope2.x
[11:25] <pitti> doko: I mean on the alternate CD; AFAICS that was only bzr, and I just fixed that
[11:26] <doko> pitti: python2.4 shouldn't land on any CD ...
[11:26] <pitti> doko: right; fixing bzr should save us some 3.5 MB
[11:27] <hunger> shawarma: I get pretty easily annoyed when my computer suddenly behaves differently:-(
[11:27] <doko> pitti: but we have to keep it in main
[11:27] <shawarma> hunger: If that's the case, you shouldn't be running Gutsy :)
[11:27] <pitti> doko: of course; I'm just worried about the CD overflow ATM
[11:27] <mvo_> pitti: beryl can go, its now all in compiz-fusion and its considered legacy now. desktop-effects can go too II think, the only reason we may want to keep it is e.g. for xubuntu
[11:28] <mvo_> pitti:  for people who do not want to install the gnome-control-center depends, but do want desktop-effects :)
[11:28] <pitti> mvo_: ok; I would be happy about a C/R/P: desktop-effects in gnome-control-center; I'll leave it in universe for now until the xubuntu guys say that they don't want it
[11:28] <mvo_> pitti: but then, someone needs to fix it a bit harder, its currently working but not great
[11:28] <Mithrandir> hm, why does ~/.config/user-dirs.locale claim nb_NO?  I haven't used that locale for years.
[11:29] <pitti> dholbach: libgtkmm-2.4 is new on the CDs (1.2 MB), hmm
[11:30] <ogra> pitti, yes, i noticed its oversized, the nbd breakage held me back from looking at it
[11:30] <mvo_> pitti: I'm not sure about the C/R/P, its technically correct, but g-c-c is installed on pretty much every ubuntu system anyway and people who do not have it (e.g. xubuntu) will probably not want it
[11:30] <pitti> dholbach: oh, gnome-system-monitor uses it now
[11:31] <pitti> mvo_: I actually intend that for automatically removing d-e on upgrades, when we remove the package from the archive
[11:31] <pitti> mvo_: i. e. g-c-c should c/r/p to d-e, not the other way round
[11:31] <seb128> pitti: uses what?
[11:31] <pitti> seb128: gnome-system-monitor uses gtkmm2.4 now
[11:31] <seb128> dholbach: BTW, gtkmm2.4 is b0rked, ABI change without soname change it looks like
[11:31] <seb128> pitti: right
[11:32] <seb128> pitti: upstream decided that C++ is good
[11:32] <dholbach> seb128: that was due to the glib change
[11:32] <dholbach> seb128: I'm doing a mass rebuild now
[11:32] <seb128> dholbach: new version didn't build since saturday?
[11:33] <seb128> dholbach: no need to do a mass rebuild, ask pitti to trigger rebuilds
[11:33] <dholbach> seb128: rebuilds of all packages that depend on the *mm stack
[11:33] <pitti> seb128: ?
[11:33] <dholbach> seb128: not rebuilds of ftbfs packages
[11:33] <seb128> ah
[11:33] <seb128> pitti: I though dholbach was needed a buildd retry
[11:33] <pitti> mvo_: ok, thanks; I'll kill beryl then for now
[11:33] <pitti> ah, ok
[11:33] <seb128> dholbach: all the packages which built with the broken version you mean?
[11:34] <dholbach> no, unfortunately all packages
[11:34] <crimsun> no, all packages.
[11:34] <pitti> now is the very best time to do intrusive stuff in the archive without getting caught by me :)
[11:34] <dholbach> pitti: hehe
[11:35] <iwj> Morning everyone.
[11:35] <seb128> dholbach: why?
[11:35] <pitti> hi iwj
[11:35] <seb128> dholbach: gnome-system-monitor works again since the new gtkmm update without a rebuild for example
[11:35] <dholbach> seb128: that's one of the few then - try workrave
[11:35] <dholbach> seb128: it didn't get uploaded during the new glib
[11:36] <dholbach> and it's what murrayc said
[11:36] <pitti> ogra: do we really need ltsp on the ubuntu alternates? in particular, ldm is really big and new since tribe-1
[11:36] <seb128> dholbach: so there is a mm stack breakage and rebuilding apps is not the way to go
[11:36] <seb128> that means the mm libs broke ABI
[11:36] <Fujitsu> workrave, paprefs... Anything in `apt-cache rdepends libgconfmm-2.6-1c2`
[11:36] <dholbach> seb128: it broke because of the glib change
[11:36] <dholbach> seb128: so there's nothing that broke in g*mm
[11:36] <seb128> glib changes have reverted
[11:36] <dholbach> no it was not reverted
[11:36] <seb128> it should be back to original state
[11:37] <dholbach> it got changed differently
[11:37] <ogra> pitti, big ?
[11:37] <pitti> ogra: 2.2 MB
[11:37] <ogra> i actually never checked the package size
[11:37] <pitti> ogra: ltsp-client and -server are tiny, I don't care, but ldm is heavy
[11:37] <ogra> pitti, ergh, right thats all the themes, we have kubuntu and xubuntu in now
[11:38] <ogra> pitti, i think we can drop it for one tribe ...
[11:38] <pitti> ogra: hm, ldm depends on ldm | sdm-terminal | x-display-manager, so gdm should work as a dependency as well
[11:38] <Fujitsu> pitti: ldm depends on itself?
[11:38] <seb128> dholbach:
[11:39] <pitti> ogra: I might just be able to blacklist ldm for ubuntu then :)
[11:39] <ogra> pitti, that breaks ltsp
[11:39] <pitti> ogra: huh?
[11:39] <ogra> drop it for tribe 2
[11:39] <ogra> i'll split out theme packages
[11:39] <pitti> ogra: if ltsp-client *only* works with ldm and not with gdm, then the dependencies are wrong
[11:39] <ogra> so you only need to ship the ubuntu theme
[11:39] <ogra> pitti, it breaks *our* setup
[11:40] <pitti> ogra: I mean "blacklist from getting on the ubuntu alternate CD", not "blacklist from getting anywyere"
[11:40] <ogra> well, its useless on any other CD
[11:40] <ogra> its not on the desktop CD
[11:41] <ogra> and it wont be of any use on the server CD unless we add desktop packages to it
[11:57] <pitti> ogra: argh
[11:58] <pitti> ogra: any chance to remove the libgl1-mesa-dri dependency from ltsp-client?
[11:58] <pitti> ogra: that's a recent addition, and pulls in that 14 MB package
[11:58] <pitti> ogra: if we fix that, we, by and large, fixed the overflow problem for this round
[11:59] <ogra> oki
[11:59] <pitti> ogra: do you really need it? or is maybe a Recommends: the right thing?
[11:59] <ogra> i have one other fix waiting as well ...
[12:00] <ogra> i dont think we need it at all
[12:00] <pitti> yay
[12:01] <ogra> pitti, i dont think we need it at all
[12:01] <pitti> ogra: I still got that
[12:01] <pitti> ogra: that would be awesome; should fix the edubuntu CD as well, I figure
[12:02] <ogra> lets drop it then, but give me 2h after the package built to do a test bootstrap ...
[12:02] <ogra> iirc ther e was a dependency problem thats why i added it ...
[12:03] <pitti> ogra: yup, no problem
[12:03] <pitti> ogra: we need new langpacks as well, so I might not even build another set of dailies today
[12:03] <ogra> good
[12:03] <pitti> hm, where's carlos today?
[12:03] <ogra> that gives me the necessary testing time
[12:07] <pitti> someone please upload something to test this :)
[12:09] <StevenK> Hrm. I don't think I have something ready to upload.
[12:09] <seb128> pitti: I uploaded something some minutes ago
[12:10] <pitti> StevenK: ah, gutenprint built everywhere, splendid
[12:10] <StevenK> pitti: That was dholbach's doing.
[12:10] <pitti> dholbach: thanks to you then :)
[12:11] <StevenK> But I said it first. :-P
[12:11] <ogra> pitti, oooh, that was a merge error, i had already dropped libgl1-mesa-dri before ...
[12:12] <ogra> timestamp: Tue 2007-06-05 14:23:24 +0200
[12:12] <ogra> message:
[12:12] <ogra>   drop uneccesary libgl1-mesa-dri from EARLY_PACKAGES, libgl1-mesa-glx replaces it
[12:12] <seb128> pitti: I just did an upload
[12:12] <ogra> :)
[12:12] <pitti> ogra: cool
[12:20] <pitti> mvo: what's the current word on bug #121456?
[12:20] <ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
[12:21] <pitti> yay -changes@!!
[12:21] <pitti> ogra: hm, I take it it was actually you and not mdz who uploaded ltsp? the From: is from Matt
[12:22] <pitti> gpg is from ogra at least
[12:22] <mvo> pitti: looking
[12:22] <ogra> pitti, he owns the maintainer field still
[12:22] <pitti> ogra: right, but From: should be from Changed-By:, not Maintainer:
[12:22] <ogra> yeah
[12:23] <pitti> ogra: has that always been like that?
[12:23] <ogra> nope
[12:23] <ogra> just now
[12:23] <seb128> pitti: you are a launchpad hacker now then? ;)
[12:23] <pitti> seb128: erm, no :)
[12:24] <pitti> heh, and seb128's totem upload is From: Ubuntu Desktop Team<EMAIL_ADDRESS>now
[12:24] <pitti> but that's better than nothing
[12:24] <ogra> fun :)
[12:25] <seb128> heh
[12:26] <mdz> ogra: I haven't touched the package in ages; maintainer should be updated
[12:27] <Fujitsu> pitti: It has been sending from Maintainer for some days now... I've seen a few rejected emails to various lists.
[12:28] <pitti> soyuz bug filed
[12:28] <pitti> https://bugs.launchpad.net/soyuz/+bug/122086 FYI
[12:28] <ubotu> Launchpad bug 122086 in soyuz "From: header in -changes@ mails are wrong" [Undecided,New]
[12:28] <Fujitsu> What broke everything?
[12:28] <Fujitsu> Thanks pitti.
[12:29] <ogra> mdz, oki, i'll update it in the next upload
[12:38] <pygi> morning sivang
[12:38] <sivang> hey pygi
[12:41] <sivang> anybody managed to talk / chat / etc to smurf  ?
[12:41] <pitti> asac: bug 119814 is marked for tribe-2, but I wouldn't call it a release blocker; do you plan a  firefox upload anyway for tribe-2 or shall we move this?
[12:41] <ubotu> Launchpad bug 119814 in firefox "/usr/share/doc/firefox/MPL missing in gutsy package" [Critical,Fix committed]  https://launchpad.net/bugs/119814
[12:42] <sivang> I need either him or someone else for some DNS changes for the ubuntu-il site
[12:42] <sivang> (I think the DNS the provides us services is somewhat related to the EU cluster of loco teams)
[12:43] <asac> pitti: i already prepared a cherry-picked upload that for tribe-2 that fixes 2 important issues and adds an apport hook :)
[12:43] <asac> pitti: one of the important issues is MPL
[12:43] <pitti> asac: yay apport hook
[12:43] <asac> pitti: so yes ... will upload as soon as i verified that the build is good
[12:43] <pitti> asac: I have this on my TODO list:
[12:43] <pygi> o no, apport again xD
[12:43] <asac> pitti: we have a pretty cool apport hook
[12:43] <pitti> add firefox apport hook to suppress crash reports when restart is
[12:43] <pitti> necessary, and to not file crashes with flash installed
[12:44] <asac> hilario wrote one that gathers lots of information from firefox profile
[12:44] <asac> about plugins/extensions
[12:44] <pitti> asac: sounds great
[12:44] <pitti> pygi: it's not yet enabled by default (kernel is still broken)
[12:44] <pygi> as long as it's not enabled xD
[12:44] <Fujitsu> sivang: #ubuntu-locoteams?
[12:44] <sivang> Fujitsu: why thank you
[12:44] <asac> pitti: hehe ... i think we should just refuse all crash reports .)
[12:45] <pitti> asac: I do like the idea of setting UnsupportableReason: when the flash plugin is installed
[12:45] <pitti> asac: did you implement this as well?
[12:45] <asac> pitti: i saw that you managed to auto-dupe a gnash crash ... when will auto-dupe detection be enabled for ffox?
[12:45] <pitti> asac: dupe detection is not restricted to particular packages
[12:46] <pitti> asac: it runs for all newly filed signal and Python crashes
[12:46] <asac> pitti: ah cool
[12:46] <asac> pitti: so can we turn crash submission on again?
[12:46] <pitti> asac: the macromedia flash plugin of course, not the gnash one
[12:46] <Fujitsu> Does it file them privately, retrace automatically, etc?
[12:46] <pitti> asac: no, due to bug 119267; we need a new kernel first
[12:46] <ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Fix committed]  https://launchpad.net/bugs/119267
[12:47] <asac> pitti: what is this Unsupportable feature about? ... adding a report called 'UnsupportableReason' ?
[12:47] <pitti> asac: also, I'd like to find some time to implement https://wiki.ubuntu.com/CrashReporting; we now have the LP infrastructure for that
[12:47] <pitti> asac: see /usr/share/doc/apport/package-hooks.txt
[12:47] <asac> pitti: will look thanks
[12:48] <pitti> asac: /usr/share/apport/package-hooks/usplash.py is an example for UnreportableReason:, that works similarly
[12:51] <asac> pitti: how RCritical do you consider the network-manager bugs ... i have looked into what latest merge did ... and Tonio_ apparently dropped lots of patches ... not only those that are now in patches-not-applied.
[12:52] <pitti> asac: if we can fix at least some of them, that would be nice
[12:52] <coNP> Hey, Mithrandir can you please have a look at my Openbox / Obconf packages?  (http://revu.tauware.de/details.py?upid=5589, http://revu.tauware.de/details.py?upid=5569)
[12:53] <pitti> asac: I don't have an internet connection after booting right now, and it breaks people's WEP/WPA with keyring (bug 121605)
[12:53] <ubotu> Launchpad bug 121605 in network-manager-applet "(gutsy]  segfault on joining secure network" [High,New]  https://launchpad.net/bugs/121605
[12:53] <pitti> asac: the patch which makes n-m ignore statically configured devices is really important IMHO
[12:53] <asac> pitti: i will resurrect as much patches as possible ... from what i see there should be hardly anything working at all
[12:53] <ogra> err, yes, thats somewhat essential for edubutu
[12:54] <asac> pitti: for instance 05-debian_backend.patch was completely dropped just because the first hunk was applied upstream
[12:54] <Mithrandir> coNP: no, sorry, I don't have the time for it right now.  I'm fine with you finding a MOTU and getting the upload through a regular sponsor
[12:54] <pitti> asac: right, it's pretty much back to the "I grab eeeeeverything" upstream state
[12:54] <pitti> asac: erk
[12:54] <pitti> Tooonioooo
[12:54] <coNP> Mithrandir: okay, thanks
[12:55] <pitti> asac: if you could look into that, it would be great; I don't dare to throw this at people
[12:55] <asac> pitti: yeah ... i will see how far i get ... i am now at resurrecting 13-rml-wpa-workarounds.patch
[12:56] <Fujitsu> seb128: Was that glib2.0 change fixing the *mm breakage? The changelog looks rather truncated.
[12:58] <seb128> Fujitsu: what is truncated?
[12:58] <Fujitsu>    * Update the serie
[12:58] <seb128> Fujitsu: the patch added to 2.13.5-0ubuntu2 fixes the ABI breakage
[12:58] <Fujitsu> That's all that's there.
[12:59] <seb128> right, the patch serie was not updated so the patch was not used
[12:59] <seb128> this upload makes the patch being applied
[01:09] <Keybuk> you mean "serial" or "series", right?
[01:10] <seb128> Keybuk: debian/patches/series
[01:10] <Fujitsu> Keybuk: 'tis what I presume.
[01:10] <Fujitsu> Aha, series. Not serie
[01:10] <seb128> serie, series
[01:10] <Fujitsu> series is the singular. I love English.
[01:11] <seb128> well, that's a typo
[01:11] <mvo_> seb128: what upload (sorry, missed the first bit got disconnected - but I have not given up hope *yet* that my connection might get fixed today)
[01:12] <seb128> I just wanted to upload the change, not to discuss the changelog entry on IRC for half an hour
[01:12] <seb128> shame that -changes is fixed :p
[01:12] <mvo_> lol
[01:12] <StevenK> Heh. Ask the Launchpad guys, they could unfix it. :-P
[01:12] <seb128> mvo_: glib2.0, I made a typo when writting "series" which seems to confuse Fujitsu ;)
[01:13] <Fujitsu> seb128: Well, I hadn't seen the previous change, so it seemed pretty random.
[01:13] <seb128> Fujitsu: read the changelog first, ping people on IRC then is usually a good way to do thing ;)
[01:13] <seb128> things
[01:14] <seb128> though I admit the changelog entry is not really verbose
[01:16] <seb128> mvo_: let me know when you try the new gnome-session if it activates compiz by default correctly for you
[01:17] <Keybuk> seb128: \o/
[01:17] <mvo_> seb128: its not in the archive yet, but when it is, I will
[01:17] <seb128> cool
[01:18] <seb128> k, lunch time then, bbl
[01:19] <pitti> mmm, lunch, me too
[01:21] <fabbione> pitti: libept did build fine all around... i guess we just need to wait the next update for gutsy_probs
[01:21] <fabbione> OR there is something more blowing up now
[01:24] <pygi> dholbach, should we get andvare packaged? :)
[01:25] <Keybuk> I think -changes has broken again
[01:25] <dholbach> pygi: you said in the blog comment, that you'd do it, no?
[01:25] <pygi> dholbach, right :)
[01:25] <dholbach> do it :)
[01:25] <pygi> understood sir :)
[01:26] <pygi> ergh, you're tracking me
[01:26] <pygi> bad sign :P
[01:26] <dholbach> no, not at all
[01:26] <dholbach> I just did a comment on that page too
[01:26] <pygi> I saw, yes :P
[01:27] <pygi> oki, well, this week then ^_^
[01:29] <awk> hello, just wondering out of intrest the situation with asterisk (bristuff) I see that on Feisty it's using version 1.2.16, and I know of BoF and DoS vulnerabilities with this version i'm wondering what way would I know if it has been patched or not?
[01:30] <awk> I do not know of any current patches for older version but yet only later releases to rectify this issue
[01:33] <Keybuk> mvo: animations plugin doesn't seem to be doing much
[01:33] <mvo> Keybuk: let me look at it
[01:35] <pygi> hey jsgotangco
[01:35] <jsgotangco> hi pygi
[01:36] <ogra> uhmm, desktop-effects is bound into a capplet now ?
[01:36] <ogra> so i cant have a desktop without the option ?
[01:36] <Keybuk> mvo: I get an "Error: Couldn't load plugin 'animation'" in xsession errors
[01:36] <Keybuk> ogra: ?
[01:37] <ogra> Keybuk, enabling desktop-effects breaks on 99% of thin clients ... before i could just remove the desktop-effects package to prevent them shooting both of their feet
[01:38] <Keybuk> ogra: compiz would be a huge performance improvement for thin clients that have 3D-capable hardware
[01:38] <ogra> but if the UI element is inside a capplet i cqant easily remove the optiojn
[01:38] <Keybuk> since window moves, desktop changes, etc. wouldn't result in network traffic
[01:38] <ogra> Keybuk, yes
[01:38] <ogra> we prove that in sevilla on the classmate
[01:38] <ogra> its awesome
[01:38] <Keybuk> I don't see why the option is a problem
[01:38] <ogra> but 99% of thin clients dont have 3D capable cards
[01:39] <ogra> or are not supported by our drivers out of the boox i.e. vfia
[01:39] <ogra> *via
[01:39] <Keybuk> I still don't see why the option is a problem
[01:39] <Keybuk> they'll click the button and nothing will happen
[01:39] <ogra> not if they log in on the server inbetween and enable it there
[01:39] <Keybuk> (it shouldn't be a button anyway)
[01:39] <ogra> (if the server has a capable card)
[01:40] <Keybuk> it's enabled by default
[01:40] <ogra> if you log in afterwards on a thin client the system just locks up
[01:41] <ogra> or if i enable it with a classmate as client and switch over to another one ....
[01:41] <Keybuk> shouldn't lock up at all; clicking the button will disable compiz, so metacity will be used immediatley
[01:41] <Keybuk> rather than being used after a hardware test
[01:41] <ogra> you cant click any button anymore
[01:41] <ogra> it locks up if it starts compiz at login
[01:42] <Keybuk> why does it lock up?
[01:42] <ogra> no idea
[01:42] <Keybuk> on what range of PCs?
[01:42] <ogra> i usually doont care about compiz
[01:42] <ogra> on all my clients i have
[01:42] <Keybuk> test tribe 2 on them
[01:42] <ogra> ~20 different models
[01:43] <ogra> i wwwwwwill
[01:43] <mjg59> So fix the bug
[01:43] <ogra> oops
[01:43] <mjg59> "This option breaks, so I would prefer to remove this option" isn't the development model we tend to follow :)
[01:43] <Keybuk> compiz is our default window manager
[01:43] <Keybuk> if it locks up on all your clients, you're going to have a dull release ;)
[01:44] <ogra> mjg59, for me the bug is that i asked on every conference we had to not enable any composite stuff by default and was always promised we wouldnt or at least have an oiption to prevent it ... sadly i didnt ask in sevilla again ad was to busy to grasp that you doomed me
[01:44] <ogra> s/you/the effects team/
[01:44] <mjg59> ogra: You're not doomed.
[01:44] <mjg59> Just fix the bug.
[01:44] <seb128> mvo: small bug, if you enable compiz and it fallbacks to metacity the desktop effects tab indicates that compiz is being used which is wrong
[01:45] <Keybuk> ogra: if there are bugs, please help fix them
[01:45] <ogra> i dont want to see an option to enable composite at all
[01:45] <Keybuk> ogra: it's an option to disable composite
[01:45] <mvo> ogra: it should not anymore, we added a bunch of additonal tests. if you could test that with current comiz I would appreciate that
[01:46] <seb128> ogra: the compiz wrapper makes test to know if compiz should be used or not, you could make it run metacity if LTSP_CLIENT is defined
[01:46] <ogra> mvo, i'll upgrade everything here as soon as i got the new ltsp packages to test
[01:46] <mvo> seb128: aha, ok. I will check that out
[01:46] <Keybuk> ogra: your argument if flawed
[01:46] <Keybuk> if compiz breaks on some hardware, we should fix that
[01:46] <mvo> ogra: great, please do that. as I said, the wrapper script should be much better about detecting
[01:46] <ogra> seb128, thats what i thought first, but then it wouldnt even be optional anymore ...
[01:46] <Keybuk> this is not a justification for removing the option to use, or not use, compositing
[01:47] <Keybuk> especially on something global like LTSP, given the massive performance improvements of *using* composite
[01:47] <Keybuk> compiz is *ideal* for LTSP, where the client hardware supports it
[01:47] <seb128> ogra: well, let's see how badly it breaks first, the wrapper only runs compiz now if all the required xorg options are detected as supported
[01:47] <ogra> i suspect more and more composite capable clients in the future but they are simply not there yet
[01:47] <ogra> so it should stay optional ...
[01:47] <seb128> ogra: it'll not run if your card doesn't do 3d, or has no composite, etc
[01:47] <Keybuk> ogra: where the client isn't capable, it should fallback to metacity automatically
[01:48] <ogra> Keybuk, i'll test that
[01:48] <Keybuk> ogra: where that doesn't work, it is a bug that should be fixed
[01:49] <ogra> oki
[01:49] <mvo> ogra: if you could test that before tribe-2, that would greatly appreciated :) sorry, I can't do that myself as I don't have e.g. a via based machine
[01:49] <ogra> its a charm on supported HW :)
[01:49] <ogra> mvo, yep, i have to do a lot of ltsp testing anyway, its on the list
[01:52] <seb128> grrr, apport bugs being b0rked due to linux
[01:52] <seb128> pitti: is a new linux package planned for tribe-2?
[01:52] <pitti> seb128: planned yes, it was promised for last weekend
[01:53] <seb128> ok, cool
[01:53] <pitti> fabbione: yeah, I already gave back debtags, and now http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html is clean
[01:53] <pitti> fabbione: thanks for your help
[01:53] <seb128> pitti: do you want me to change libgnome to force the dpi to 96?
[01:53] <pitti> seb128: I'm not sure about this any more
[01:53] <seb128> k
[01:54] <pitti> seb128: however, if DPI detection works correctly now, how come that the fonts are so small on 130 dpi? (last bug comment)
[01:54] <pitti> seb128: as I understood it, fonts should now be the same size on every DPI, shouldn't they?
[01:54] <seb128> I'm not sure, all that is pretty confusing
[01:54] <seb128> right
[01:55] <pitti> so if you think that there's still something broken, we can do the 'fix 96 dpi' hack for tribe, but that's certainly not the final solution
[01:56] <seb128> right
[01:56] <shawarma> https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/122090 is marked as a security issue. How can I get to see it?
[01:56] <seb128> I'll have an another look
[01:58] <shawarma> At 130 dpi fonts a likely to look smaller than people are used to.
[01:58] <mdz> shawarma: only the security team can see them (ubuntu-security)
[01:58] <shawarma> mdz: Ah, well. I suppose they'll fix it then :)
[01:58] <mdz> shawarma: kees and pitti
[01:58] <mdz> shawarma: in this case, it's not a security vulnerability, so they should unflag it when they review it
[01:58] <pitti> shawarma: I removed the private flag, you can see it now
[01:58] <shawarma> pitti: ta
[01:59] <mdz> pitti: you didn't remove the security flag, though I wouldn't classify this as a vulnerability
[01:59] <pitti> shawarma: to be precise, it's the private flag that confines the bug to the subscribers; security just triggers ubuntu-security subscription and is useful for searching
[01:59] <pitti> mdz: I left it because a non-functioning iptables is sort of security related
[02:00] <mdz> pitti: your call, but to me, sort-of doesn't count :-)
[02:00] <shawarma> pitti: Er.. Ok. I don't remember seeing two different check boxes..
[02:00] <mdz> if a bug in vi causes someone to mangle their firewall config and break their firewall, that isn't a security vulnerability either
[02:00] <pygi> haha
[02:02] <pitti> right, but if someone upgrades to gutsy and suddenly loses the firewall, possibly even without noticing, that's our fault, not the one from the admin using vi
[02:05] <shawarma> 13:56 < crummygummy_> I didn't reallise it but shorewall didn't work for a whole weekend. I figure thats reason enough to call it a  security problem.
[02:09] <seb128> Mithrandir: your comment about xdg-user-dirs is not really constructive, if you have documents not stored in random directories no default will ever suit you anyway
[02:09] <seb128> Mithrandir: the fileselector, libraries, etc have to point to one directory
[02:09] <Mithrandir> seb128: my point is the model is wrong.
[02:09] <seb128> well, there is no "model"
[02:10] <seb128> at the moment those applications open an hardcoded location
[02:10] <seb128> or your user directory
[02:10] <Mithrandir> sure there is, there's a model of storing all your images together, all your downloads together, etc.
[02:10] <seb128> xdg-user-dirs just allow you do customize that if you want
[02:10] <seb128> well, it's nothing new nor due to xdg-user-dirs
[02:10] <Mithrandir> and not working in that model is a pain.
[02:11] <Mithrandir> sure there is, since stuff could easily default to where you are currently working, for instance.
[02:11] <Mithrandir> seb128: and my point about not creating the directories until they are asked for still holds.
[02:12] <seb128> that's a chicken-egg problem
[02:12] <seb128> users don't know about Templates if they have no location for them
[02:12] <seb128> but we should not create the directory before they start using it
[02:13] <pitti> at least rmdir'ing the unused ones does the right thing
[02:14] <seb128> Mithrandir: and the locations don't mean your fileselector will not open on the current location
[02:14] <Rumba> how do i get a list of _all_ packages that are _marked_ as autoremovable (i.e. not just those ones that are _currently_ removable)?
[02:14] <seb128> but it means that the rhythmbox library option default to Music which you can customize
[02:14] <pitti> /home/martin/Videos was removed, reassigning VIDEOS to homedir
[02:14] <pitti> at least it doesn't keep creating the directories :)
[02:14] <seb128> and that you have a Video bookmark in the totem file selector
[02:15] <seb128> pitti: right, it's easy enough to remove them if you want
[02:15] <seb128> and it doesn't create them for existant users
[02:15] <pitti> seb128: it did create the directory for me
[02:15] <pitti> directories
[02:16] <pitti> just on upgrade, with existing user
[02:16] <seb128> hum, it didn't do it for me
[02:16] <seb128> it didn't add the bookmarks though, did it?
[02:16] <pitti> no, it didn't
[02:17] <seb128> oh, another topic
[02:17] <seb128> evolution can use bogofilter now
[02:17] <seb128> what people think about adding bogofilter to the default installation?
[02:18] <pitti> seb128: small enough
[02:19] <seb128> pitti: want to do it for tribe-2 or after that?
[02:19] <pitti> seb128: if it doesn't completely break evolution, we can do it today, but that requires another seed change and ubuntu-meta upload
[02:20] <seb128> it should not break anything but there is no hurry neither
[02:20] <pitti> seb128: it's not critical path in any way, so if you want, go ahead
[02:20] <seb128> k, doing it then
[02:20] <seb128> let's get some cool testing with tribe-2 ;)
[02:21] <pitti> critical path is still kernel, but if we don't get one today, we'll go with -6.13
[02:21] <Mithrandir> seb128: oh, and it doesn't respect the Desktop setting I've already done in Nautilus.
[02:21] <pitti> oh, indeed, it created another Desktop folder for me, too
[02:22] <seb128> Mithrandir: how so?
[02:22] <Mithrandir> seb128: my ~ is my Desktop, so it should have picked that up.
[02:22] <seb128> ah, right
[02:22] <seb128> where do you notice the bug?
[02:22] <seb128> app have special code to handle the desktop case
[02:22] <Mithrandir> I get a Desktop directory in ~ when I log in, which I used not to have
[02:23] <seb128> Mithrandir: please open a bug on xdg-user-dirs-gtk about this one
[02:24] <Rumba> how do i get a list of _all_ packages that are _marked_ as autoremovable (i.e. not just those ones that are _currently_ removable)?
[02:24] <seb128> Rumba: what do you mean "currently"?
[02:24] <seb128> apt-get autoremove
[02:24] <pygi> \
[02:24] <pitti> Rumba: question for mvo
[02:25] <pitti> seb128: that doesn't list all packages which are 'auto-installed'
[02:25] <seb128> ah, ok
[02:25] <seb128> I didn't understand the question
[02:27] <Rumba> seb128: there is a set of packages that are marked as auto-uninstallable (or auto-installed), a part of which are "currently" non-uninstallable (because they are needed by other packages). how do i get their list?
[02:27] <Rumba> mvo: you there?
[02:28] <Mithrandir> seb128: do you know why user-dirs.locale refers to locale I haven't used in years on this machine?
[02:28] <mvo> Rumba: you can setup a custom filter in synaptic to do this
[02:28] <Rumba> seb128: is my question clearer now?
[02:28] <pitti> mvo: compiz & friends are now in anastacia, because desktop-effects is not in desktop any more; they need to be seeded explicitly now, and put into desktop
[02:29] <mvo> Rumba: go to settings/filters, create a new one and select "automatic install" in the status tab
[02:29] <seb128> Rumba: yes
[02:29] <pitti> mvo: the current CDs don't even ship compiz any more because of that
[02:29] <StevenK> Does gnome-c-c deal and not show the Appearance tab if compiz and friends are not installed?
[02:29] <mvo> pitti: ok, will update the seeds now
[02:30] <Rumba> mvo: i already tried that.... :(
[02:30] <seb128> Mithrandir: what do you use for LC_MESSAGES?
[02:31] <Mithrandir> nb_NO.UTF-8
[02:31] <Mithrandir> the file refers to nb_NO
[02:31] <mvo> Rumba: and that does not work for you?
[02:32] <mvo> Rumba: works nicely for me here
[02:32] <seb128> Mithrandir: right, it strips UTF-8, the encoding is specific in  /etc/xdg/user-dirs.conf
[02:32] <seb128> Mithrandir: or ~/.config/users-dirs.conf
[02:33] <Rumba> mvo: so i checked "automatic install" (with or without "installed" at the same time) and i also see uninstalled packages in the custom filter
[02:33] <Mithrandir> seb128: so what would it say if I actually used nb_NO?
[02:33] <Treenaks> BenC: I think thinkgeek are selling a "voip phone" like the one I gave you now: http://www.thinkgeek.com/computing/avcards/8837/
[02:33] <Rumba> mvo: which boxes did you check?
[02:34] <mvo> Rumba: seeing uninstalled ones is ok, that is not a bug, more of a undesired side-effect. I have a patch ready for this, but it will do no harm
[02:34] <seb128> Mithrandir: I'm not sure that the non-UTF8 case is handled correctly, I'll have to check
[02:34] <seb128> Mithrandir: it should write that you use an ISO-8859-something encoding
[02:34] <seb128> not sure if it does, I didn't try
[02:35] <Rumba> mvo: now, is there any way to produce this exact list in the console?
[02:35] <Mithrandir> seb128: well, the nb_NO locale is latin1, so that's kinda implied by the locale.  Wouldn't it then be better to write out nb_NO.UTF-8 and have filename_encoding=locale in /etc/xdg/user-dirs.conf ?
[02:35] <Rumba> mvo: or, alternatively, is it possible to get a list of manually installed packages only?
[02:36] <pygi> hya Hobbsee
[02:36] <pygi> Hobbsee, closed like 6 k3b bugs more, but we've got some serious problems with that package :(
[02:37] <mvo> Rumba: the information is stored in /var/lib/apt/extended_states, you should be able to get it from there
[02:37] <Rumba> mvo: also, any idea why a "manually installed" checkbox isn't available for custom filters?
[02:37] <mvo> Rumba: what do you plan to do with it? is there some bug hiding somewhere that you chase?
[02:38] <pitti> mvo: will you do an ubuntu-meta upload? or shall I?
[02:38] <seb128> Mithrandir: I'm not sure if would be better, if the current way work .... I'll check with alex why he did it this way
[02:38] <BenC> Treenaks: ah, cool
[02:38] <mvo> Rumba: most likely because it was not written
[02:38] <Rumba> mvo: well, rather some feature missing
[02:38] <Rumba> mvo: read my last question for that
[02:38] <Mithrandir> seb128: not if you use legacy encodings.
[02:38] <mvo> pitti: I don't mind, but I haven't touched the seeds yet
[02:38] <Rumba> mvo: is it hard to write it?
[02:38] <mvo> Rumba: no
[02:38] <Hobbsee> hey all
[02:38] <Hobbsee> pygi: yay.  oh, how so?
[02:38] <seb128> Mithrandir: if the encoding is correctly specific what is the problem?
[02:39] <seb128> you just have to have the locale, encoding combinaison correctly set
[02:39] <pygi> Hobbsee, most patches in there don't work (i.e. broken or stuff) and I don't like the packaging
[02:39] <Mithrandir> seb128: it's not.  It just happens to be correct since I am the only user on this system.
[02:39] <Hobbsee> pygi: are these patches from us, or debian?
[02:39] <Hobbsee> mvo: please see the critical bug assigned to you, if you havent already done so.  it's blocking kubuntu tribe 2
[02:39] <Hobbsee> mvo: (adept breaking)
[02:40] <seb128> Mithrandir: well, you can have a ~/.config/users-dirs.conf with an encoding for your user
[02:40] <pygi> Hobbsee, it says "kubuntu", but they are almost 99% sure merged from debian packages
[02:40] <pygi> Hobbsee, that doesn't change the fact that they don't work :P
[02:40] <Rumba> mvo: COOL! and aptitude must use /var/lib/apt/extended_states too
[02:40] <pygi> Hobbsee, lemme forward you a mail I sent to tonio and sealne yesterday
[02:41] <pygi> Hobbsee, sent, please read ^_^
[02:41] <mvo> Rumba: that is not yet merged, but aptitude upstream said its ready, I will have a look very soon, but help is very welcome :) just check the latest debian packages or the darcs repository of apitutde
[02:42] <mvo> pitti: seed updated
[02:42] <Hobbsee> pygi: oh of cousre - but if they're debian's patches, then we should ensure that we tell them that they're stuffed.
[02:42] <mvo> Hobbsee: I have seen it, but haven't done anything about it yet
[02:42] <pygi> Hobbsee, sure, but read the mail ^_^
[02:42] <pitti> Hobbsee: congratulations!
[02:42] <Hobbsee> mvo: okay
[02:42] <Rumba> mvo: any chance we got it in gutsy if really ready, as they say?
[02:42] <Hobbsee> pitti: thanks.  all i learned about electronics was a) how much of it i dont understand, b) how much i hate it.
[02:43] <pitti> Hobbsee: red is blue and plus is minus
[02:43] <Hobbsee> pitti: of course.
[02:43] <Mithrandir> seb128: I think that's a wrong approach to the problem, but there are limits to how much I'm caring to discuss the problem.  I've fixed it for me and hopefully won't see more of it.
[02:43] <mvo> Rumba: yes, a very good chance
[02:43] <pygi> Hobbsee, there are patches to most of the problems that users encounter (read: most) but they just don't seem to work
[02:43] <seb128> Mithrandir: I keep it on my list of things to look at before gutsy
[02:43] <Hobbsee> pygi: bah.  just change it to cdbs
[02:44] <Hobbsee> pygi: right, yeah.
[02:44] <pygi> Hobbsee, I wanted to change entire package, yes :)
[02:44] <Hobbsee> pygi: it's a main package, so it's not going to get forgottena bout
[02:44] <pygi> Hobbsee, but dunno how much people will hate me, because we'd diverge from debian a lot then
[02:44] <Mithrandir> seb128: I'll be happy to give inputs on it if you want it, but it feels like I'm not coming across well, so I don't see a big point of it.
[02:44] <StevenK> It's still expensive to maintain a large diff.
[02:44] <seb128> Mithrandir: I didn't wrote the thing, it has been done by alex for FC7 and started being used by GNOME
[02:44] <pygi> Hobbsee, xfburn is main package as well, so it doesn't work :P
[02:44] <Mithrandir> seb128: oh sure, nothing personal. :-)
[02:44] <Hobbsee> pygi: i'd prefer a working package, rather than a small diff.
[02:44] <pygi> StevenK, true ... but if it gets us a nice and maintainable package ...
[02:45] <StevenK> There a tradeoff.
[02:45] <Hobbsee> pygi: if anything, we can just never sync it, and just take debian's patches.
[02:45] <StevenK> There is, sigh
[02:45] <fabbione> pitti: no problem at all
[02:45] <pygi> Hobbsee, that was my intention
[02:45] <Hobbsee> pygi: then again, maybe debian is open to changing their package
[02:45] <pygi> Hobbsee, that's less likely, but ...
[02:45] <Hobbsee> pygi: worht trying
[02:45] <Hobbsee> pygi: if they say "no" to our fork of the packaging, then thye cant really go "but they didnt tell us!"
[02:45] <pygi> Hobbsee, lemme see if they have 1.0.2
[02:45] <seb128> Mithrandir: that's not that "you are not coming across well", I just didn't look at the code much so I've no good reply on why the locale is stored this way yet ;)
[02:46] <seb128> Mithrandir: I agree that flooding the user dir with new directories is not nice
[02:46] <pygi> Hobbsee, if they have 1.0.2 lets sync debian packaging, and see what can we do out of it
[02:46] <Mithrandir> seb128: ok. :-)
[02:46] <pygi> if it still remains un-maintainable at that state, we could just "fork"
[02:46] <seb128> adding bookmarks and using it for default libraries location, etc should be fine though
[02:46] <pygi> Hobbsee, I completely took over brasero for ubuntu, debian packages are bad
[02:47] <StevenK> pygi: No bug reports in the Debian BTS about that?
[02:47] <pygi> StevenK, I'm gonna look over it now
[02:48] <seb128> mvo: are you going to merge your change to other seeds? ;)
[02:48] <seb128> mvo: just to know if I can be lazy and let you merge the bogofilter change as well :p
[02:49] <pygi> Hobbsee, no new upstream version in debian yet
[02:49] <pygi> StevenK, no reports in Debian BTS
[02:49] <pygi> which is weird
[02:49] <pitti> seb128: don't push too much stuff on mvo, he's still my slave for bug 121456 :)
[02:49] <ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
[02:49] <mvo> seb128: hm, I think only edubuntu would need merging for my compiz change, no?
[02:50] <seb128> mvo: you need to do merge on all seeds to keep them "uptodate"
[02:50] <StevenK> mvo: Heh
[02:50] <seb128> even if there is nothing to merge
[02:50] <pitti> mvo: it eventually needs to be merged to all seeds (resulting in empty changeset for kubuntu and xubuntu, of course)
[02:50] <pygi> StevenK, Hobbsee : lemme fetch the debian source package
[02:50] <Hobbsee> pygi: right.  cool
[02:50] <mvo> right, it used to be the derived distro people that did that (at least that was my understanding)
[02:50] <pygi> this k3b will make me insane :-D
[02:51] <Hobbsee> pygi: heh.  all burning makes you insane.
[02:51] <pygi> Hobbsee, not true
[02:51] <pygi> although it could be argued whetever I'm the right person to say that :P
[02:51] <Hobbsee> haha
[02:52] <Hobbsee> ah yes, i should do seed-stuff, now that exams are over.
[02:52] <seb128> mvo: if you update ubuntu-meta makes sure you have the bogofilter change also
[02:53] <pygi> Hobbsee, great, debian doesn't even have patches/
[02:53] <StevenK> pygi: I just did a rebuild of k3b. It scares me.
[02:53] <pygi> StevenK, ubuntu package? I knoow
[02:53] <pygi> know*
[02:54] <pygi> I'm trying to fix that mess :-/
[02:54] <StevenK> My mess?
[02:54] <StevenK> I didn't think I caused any.
[02:55] <mvo> Keybuk: animation plugin breakage should be fixed now (just uploaded)
[02:55] <pygi> StevenK, I didn't say it was your mess
[02:55] <pygi> StevenK, where did you saw me stating that? :P
[02:55] <Hobbsee> pygi: haha.  mess must be fixed, then.
[02:56] <pygi> Hobbsee, debian seems to ship 0 patches
[02:56] <Hobbsee> pygi: yummy.  then throw all of our bad ones out, and fix the package :)
[02:56] <pygi> we ship thousands, and most don't work
[02:56] <Hobbsee> excellent...
[02:56] <pygi> right, debian does use native packaging
[02:57] <pygi> they have patches in .diff.gz it seems
[02:57] <StevenK> That's native patching, not packaging.
[02:57] <pygi> yes, that one :P
[02:57] <StevenK> Native packaging involves no .diff.gz.
[02:57] <Hobbsee> where is bdmurray?
[02:57] <pygi> found one patch so far inside, and that one is working :)
[02:57] <pygi> StevenK, yea, sorry
[02:57] <pygi> StevenK, I messed up the naming ^_^
[02:58] <pygi> Hobbsee, debian also patched k3b source to look  for cdrskin
[02:58] <pygi> that's second patch I can find
[02:58] <Hobbsee> pygi: right
[03:00] <pygi> Hobbsee, yay, much less patching, and works better
[03:00] <pygi> rock on!
[03:00] <pygi> still not pretty packaging, and I don't like that way of patching but meh ...
[03:01] <Hobbsee> pygi: heh.  fix it :)
[03:01] <Hobbsee> pygi: if it's dodgy...
[03:01] <pygi> Hobbsee, but how? I can't do anything without tonio and sealne approval
[03:01] <pygi> they are the last folks who touched the package
[03:02] <pygi> and not sure how good is the idea to change entire package so late in the process
[03:02] <pygi> i.e. it can't be ready before tribe 3 at least
[03:02] <Hobbsee> pygi: there's no reason it needs to be done by herd 2.   i'm not sure what sealne will say, but i dont think tonio_ will mind.  especially if you're proposing to add a proper patch system, adn clena it up.  they're not stupid
[03:03] <pygi> Hobbsee, our (ubuntu) package has proper patch system, but packaging is mostly from debian (with minor improvements), and patches don't seem to work
[03:04] <Hobbsee> pygi: right
[03:04] <pygi> oh well, I'll just create a new package, so people can argue if they want
[03:04] <pygi> we can see about uploading it or not later
[03:04] <Hobbsee> i'd appreciate that, thanks
[03:04] <Hobbsee> pygi: poek me when you want someone to look it over, and sponsor
[03:05] <Mithrandir> pitti: any idea why there doesn't appear to be any xserver-xephyr debug symbols available?
[03:05] <pygi> Hobbsee, yes, after exams
[03:05] <Hobbsee> pygi: no problem
[03:06] <pygi> mmhm, I hate when we have to do such stuff, but oh well
[03:06] <pygi> we did it with brasero, we can do it with this as well
[03:06] <Hobbsee> :)
[03:07] <pygi> Hobbsee, for example you remember that normalize thingy, and that cdrecord suid thingy?
[03:07] <pygi> we have patches for both in the package. go figure
[03:07] <Hobbsee> pygi: heh.  oookay
[03:09] <mvo> Hobbsee: debtags breakage seems to be the reason for the error
[03:09] <mvo> Hobbsee: not the new apt
[03:10] <pygi> mvo, I thought we rebuilded proper debtags?
[03:10] <Hobbsee> mvo: yummy.
[03:10] <pygi> o well
[03:10] <Hobbsee> mvo: which seems to be a Riddell thing?
[03:10] <mvo> enrico: http://paste.ubuntu-nl.org/27118/ <- any idea what causes this? we get it when adept_manager is run
[03:11] <persia> Archive Admins: there is currently a discussion on<EMAIL_ADDRESS>about the xinetd license.  In summary, the COPYRIGHT file requires that authors of modified versions have their name noted in the COPYRIGHT file for distribution.  Is this a known dead issue, or should there be a patch to /COPYRIGHT in the packaging to comply with this requirement?
[03:11] <mvo> Hobbsee: well, it looks like the new debtags changed some bits, see http://paste.ubuntu-nl.org/27118/ for the error message
[03:12] <mvo> seb128, pitti: if a ubuntu-meta upload is still required, I can do that now
[03:12] <Hobbsee> mvo: right.  will poke Riddell over it.
[03:12] <pitti> mvo: please go ahead, thanks
[03:13] <mvo> Hobbsee: Riddell and enrico know best about debtags (especially enrico, he is the mastermind behind it :)
[03:13] <Riddell> well, I don't know all that much about it
[03:13] <Hobbsee> mvo: right.  i dont know enrico, but it doesnt look like he's around.
[03:13] <Riddell> mvo: how do you get that error?
[03:14] <mvo> Riddell: I used gdb and changed the exception thing so that it has no catch-all at the end
[03:14] <pitti> Mithrandir: hm, curious; it must have gotten lost in the cronjobs which fetch the dbgsyms from the buildds; way too often, rookery cannot connect to them, and I get cron mails
[03:14] <mvo> Riddell: lets wait a bit for the input of enrico
[03:15] <Riddell> mvo: gdb on adept or debtags?
[03:15] <Mithrandir> pitti: any way to recover or should I just build it myself?
[03:15] <pitti> Mithrandir: when it was built less than 7 days ago, I can recover
[03:16] <mvo> Riddell: gdb on adept_manager. I suspect strongly that the new debtags is incompatible with the old copy of the code in libaptfront that adept uses :/
[03:17] <Mithrandir> pitti: it wasn't.  Oh well, I'll just rebuild
[03:31] <mvo> pitti, cjwatson: ubuntu-meta gives me lots of removals from minimal (e.g. bash, bsdutils, ... full list at: http://paste.ubuntu-nl.org/27126/). is that expected? (generated with germinate 0.27)
[03:32] <pitti> mvo: minimal was recently split, there is essential now
[03:32] <pitti> mvo: erm, not essential, I mean 'required'
[03:33] <StevenK> pitti: So now there's eight seeds?
[03:33] <pitti> mvo: so I *think* those removals are ok, since they are bootstrapped and its hard to remove them anyway
[03:33] <pitti> mvo: cjwatson is not available today, btw
[03:33] <mvo> pitti: ok, happy to upload then
[03:38] <pitti> mvo: wait
[03:39] <pitti> mvo: please don't upload ubuntu1 versions, that looks weird
[03:41] <mvo> pitti: too late :(
[03:41] <pitti> bah
[03:42] <pitti> well, nevermind
[03:42] <pitti> BenC: just for coordinating tribe-2, is there an upload in the pipe now? if not, then we should just go with the current kernel, I figure
[03:44] <BenC> pitti: Not yet, but will be in a few hours
[03:44] <BenC> pitti: should have plenty of time
[03:45] <pitti> BenC: plenty of time> that only applies to the case of not having to do another upload to fix regressions :)
[03:46] <BenC> pitti: this upload is pretty tight, plus it fixes apport among other things :)
[03:46] <BenC> pitti: really need this in, unless we want tribe-2 to have the same kernel as tribe-1
[03:46] <pitti> BenC: tight> ah, just cherrypicks?
[03:46] <BenC> pitti: mostly just update to latest, -rc5
[03:47] <fabbione> we want rc5
[03:47] <fabbione> badly
[03:47] <pitti> I don't really want the current one for tribe2 either, but anything that isn't in the archive today can't make it
[03:50] <seb128> and we want apport working also
[03:51] <Hobbsee> pitti: that's dependent on your definition of today.
[03:59] <mvo> seb128: gnome-session change works nicely here for me :)
[03:59] <seb128> mvo: good ;)
[04:47] <BenC> pitti: 2.6.22-7.14 uploaded, so may need processing soon (ABI bump)
[04:47] <pitti> BenC: ah, thanks; I'll watch out for it
[04:49] <pitti> hey cjwatson_
[04:51] <sabdfl> hey pitti
[04:51] <Hobbsee> morning london-type people
[05:08] <tkamppeter> pitti, ping
[05:08] <pitti> hi tkamppeter
[05:08] <tkamppeter> hi pitti
[05:09] <tkamppeter> I have a problem with the Tribe 2 build of foo2zjs. It builds on all except 64-bit
[05:10] <tkamppeter> On 64-bit it breaks on groff segfaulting when trying to make a PDF of all man pages.
[05:10] <tkamppeter> Go to http://launchpadlibrarian.net/8186699/buildlog_ubuntu-gutsy-ia64.foo2zjs_20061224-3ubuntu1_FAILEDTOBUILD.txt.gz
[05:11] <tkamppeter> and search for "Segmentation Fault".
[05:12] <pitti> tkamppeter: that doesn't tell us why it segfaulted, so no idea
[05:12] <tkamppeter> What to do in such a case? The package has built on 64-bit before and it build on Debian. Therefore I do not want to exclude the manual.pdf from the package.
[05:13] <dholbach> best to try to reproduce the crash locally and debug it :-/
[05:15] <pitti> tkamppeter: I gave back the package on ia64, maybe it was just a temporary glitch (no reason to believe that, bug let's try :) )
[05:15] <pitti> tkamppeter: if it fails again, this needs to be examined on an actual ia64 machine
[05:15] <pitti> tkamppeter: for now, the world won't end if foo2zjs isn't current on an unsupported architecture :)
[05:20] <nxvl_> hi all
[05:20] <nxvl_> pitti: hi!
[05:23] <pitti> hi nxvl
[05:24] <pitti> dholbach: oh dear, rebuilding the world?
[05:24] <pitti> dholbach: I thought that was confined to gtkmm, not to everything linking to glib??
[05:25] <Hobbsee> pitti: just the world.   not the universe.
[05:25] <dholbach> pitti: no, not everything linking to glib
[05:25] <dholbach> pitti: but the ABI breakage was due to glib
[05:25] <seb128> pitti: only whatever has been built during the glib breakage needs to be rebuilt
[05:25] <dholbach> pitti: I rebuilt all the c++ packages that have been built since the broken glib
[05:26] <pitti> ok
[05:26] <seb128> pitti: the think is that dholbach did a round of non required rebuilds this morning when the glib fix was not working
[05:26] <seb128> so an another round is required to undo this one now ;)
[05:26] <pitti> I see; I didn't see the first wave, we didn't have -changes then yet
[05:30] <nxvl_> is there any way in launchpad to filter bugs/proyects by lenguage as in "programs writen in ruby"
[05:30] <tkamppeter> pitti, the 64-bit build of foo2zjs failed again. So there is a definitive bug.
[05:31] <BenC> anyone else start getting this with latest gutsy and vmware ws6:
[05:31] <BenC> /usr/lib/vmware/bin/vmware: symbol lookup error: /usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN4Glib9ValueBase4initEm
[05:32] <siretart> BenC: translation to c++: undefined symbol: Glib::ValueBase::init(unsigned long)
[05:32] <seb128> BenC: that should be fixed when the gtkmm stack is rebuilt
[05:33] <BenC> seb128: any idea when that will be or if I can get pre deb of it?
[05:33] <seb128> BenC: that's the rebuilds we were just speaking about
[05:33] <seb128> BenC: I think dholbach already uploaded the packages that need a rebuild
[05:33] <seb128> so like 1 hour
[05:33] <BenC> seb128: sweet, thanks
[05:34] <seb128> np
[05:37] <evand> seb128: can you take a look at 122141 when you have a chance?
[05:37] <seb128> bug #122141
[05:37] <ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [Undecided,New]  https://launchpad.net/bugs/122141
[05:39] <seb128> evand: having a small code example would be nice
[05:39] <evand> will do
[05:39] <seb128> thanks
[05:40] <seb128> does it happen every time?
[05:40] <evand> yeah
[05:40] <evand> with the feisty version as well
[05:41] <evand> it started recently, within a week or so
[05:41] <evand> (by feisty version I mean installing the feisty version in a gutsy environment, not using feisty's gtk)
[05:42] <seb128> evand: that's like due to http://bugzilla.gnome.org/show_bug.cgi?id=437281
[05:42] <ubotu> Gnome bug 437281 in gtk "gtk_button_set_image destroyes the old image" [Normal,Unconfirmed]
[05:43] <pitti> mdz, Keybuk: can one of you please ack the addition of ubuntu-core-dev to the ubuntu-crashes-main team, and ubuntu-dev to ubuntu-crashes-universe? this is for https://wiki.ubuntu.com/CrashReporting
[05:43] <seb128> evand: is that a tribe-2 ubiquity blocker?
[05:44] <Keybuk> pitti: that team won't be subscribed to any bugs, or report any bugs, etc.?
[05:44] <Keybuk> (or have any assigned to it?)
[05:44] <Keybuk> and s/ubuntu-dev/motu/
[05:44] <pitti> Keybuk: it will be subscribed to all crash bugs, but not get bug mail
[05:44] <evand> seb128: yeah, it wont start without it
[05:44] <Keybuk> pitti: why won't it get bug mail?
[05:45] <pitti> Keybuk: I set a bogus contact address<EMAIL_ADDRESS>[05:45] <mdz> pitti: we have<EMAIL_ADDRESS>for that
[05:45] <Keybuk> pitti: will that prevent members of that team getting bug mail?
[05:45] <pitti> Keybuk: according to BjornT, yes
[05:45] <Keybuk> (even if subscribed separately)
[05:45] <pitti> mdz: I'm happy to use that as well
[05:45] <Keybuk> afaik, this will prevent bug mail to any developer for these bugs
[05:45] <Keybuk> even if it's assigned to them, etc.
[05:45] <mdz> Keybuk: that's not my understanding
[05:46] <pitti> that would be weird
[05:46] <mdz> it's just used in place of (set of member email addresses) for mail to the team
[05:46] <pitti> it's just yet another subscriber to a bug
[05:46] <Keybuk> right, but malone dedups bug mails if you're a member of a team subscribed, no?
[05:47] <mvo_> pitti: if ubuntu-meta is in and compiz is on the CD again, could you roll images?
[05:47] <mvo_> I would love to do a test of it tonight on various machines
[05:47] <pitti> Keybuk: I'll try this out once the team is added, just to be sure
[05:47] <pitti> mvo_: I can do that, yes
[05:48] <mvo_> pitti: thanks, that would rock!
[05:48] <Keybuk> mvo_, infinity: why is compiz-fusion-plugins-main in dep-wait?
[05:48] <pitti> mvo_: erk, ubuntu-meta is in depwait
[05:48] <pitti> Missing Dependencies:  	germinate (>= 0.28)
[05:49] <pitti> mvo_: did you change that dependency?
[05:49] <mvo_> pitti: no, I did not
[05:49] <Keybuk> pitti: I'm seeing all sorts of strange "does not exist" reports from the buildd
[05:49] <Keybuk> none of them make sense
[05:49] <pitti> we only have germinate 0.27 in the archive
[05:49] <Keybuk> (that one may make sense :p)
[05:50] <mvo_> pitti: compiz-fusion-plugins is depwait on compiz-bcop (that one is not prompted to main yet it seems)
[05:50] <mvo_> ^--- Keybuk
 pitti: yes, other subscribers will get bug mail.  <= mdz, Keybuk; anyway, I'll test this thoroughly before I flip this switch
[05:50] <mvo_> pitti: this must be colins upload from saturday then, let me check that theory
[05:50] <Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/u/ubuntu-meta/ubuntu-meta_1.47.patch
[05:50] <Keybuk> ^ Colin changed the version
[05:51] <mvo_> unfortunately 0.28 is not in bzr too :/
[05:51] <mvo_> at least in the launchpad published branch
[05:51] <pitti> mvo_: 'upload from Saturday'?
[05:52] <Keybuk> pitti: 1.47, see url
[05:52] <pitti> ah, of ubuntu-meta, not germiante
[05:53] <pitti> argh, so it's probably on Colin's local laptop branch or so, and he's still travelling
[05:54] <Keybuk> has he escaped Edinburgh now?
[06:00] <pitti> mvo_: you reverted the ubuntu-minimal changes?
[06:00] <mvo_> pitti: yes
[06:00] <pitti> mvo_: to work around the germinate requirement?
[06:00] <mvo_> pitti: yes
[06:01] <pitti> Hobbsee: ^ FYI, I think that might affect kubuntu-meta, too
[06:01] <mvo_> pitti: but I did not change the b-d (didn't noticed that chnage)
[06:01] <pitti> mvo_: so if you upload again anyway, can you please un-ubuntu the version number?
[06:01] <ogra> mvo_, hmm, no compiy at all anzmore on thin clients, not even on the intel HW
[06:01] <Keybuk> dch -U is your friend :p
[06:02] <Riddell> pitti, Hobbsee: merging
[06:02] <Hobbsee> ok
[06:02] <pitti> Keybuk: right, but that needs to be put into germinate-update-metapackage
[06:02] <pitti> Riddell: merging what?
[06:02] <mvo_> ogra: ok, but no crashes/hangs too ?
[06:02] <Hobbsee> pitti: kubuntu seeds, i expect
[06:02] <ogra> mvo_, nope
[06:02] <Riddell> pitti: if there was a change to minimal?
[06:02] <pitti> Riddell: hm, they have been merged only some hours ago
[06:03] <pitti> Riddell: cjwatson split off 'required' from minimal
[06:03] <pitti> but removing those from the metapackages shuold be fine
[06:03] <ogra> mvo_, i'D like to find out why it stopped working though ... but that can happen after tribe2
[06:03] <pitti> after all, essential and prio: reuqired packages cannot easily be uninstalled anyway
[06:04] <pitti> bbl, dinner
[06:04] <mvo_> ogra: sure. if you could put the .xsession-errors file somewhere I can have a look. its quite verbose currently
[06:04] <nxvl_> again my irc client closes up :S
[06:04] <ogra> mvo_, well, i rather think its X
[06:04] <ogra> glxgears stopped working as well
[06:05] <nxvl_> is there any way in LP to filter programas, bugs or proyects by language? as in "bugs of apps writen in ruby"
[06:05] <superm1_> Mithrandir, i wanted to ping you about a few things stuck in NEW yet.
[06:06] <superm1_> Mithrandir, in edgy, mythtv (source) has been in it since 2007-05-03, and in gutsy libhdhomeun (source)
[06:06] <superm1_> er actually in edgy its a binary it looks like, because ppc and amd64 made it partly through
[06:10] <enrico> mvo_: I've read the backlog.  Oh, damn!  I changed the index file format and I totally forgot about adept
[06:10] <Keybuk> pitti: err, ok, I'm confused
[06:10] <Keybuk> you've made ubuntu-core-dev a member of ubuntu-crashes-main
[06:11] <Keybuk> didn't you want that the other way around?
[06:11] <Keybuk> oh, maybe not
[06:11] <Keybuk> I can't see how to allow that though
[06:11] <Keybuk> and you don't want ubuntu-dev, you want motu, no?
[06:12] <Hobbsee> er....where are the binaries for https://launchpad.net/ubuntu/+source/apt-setup/1:0.21ubuntu1 - it doesnt seem to be stuck in the NEW queue, but doesnt seem to be in the archive either.
[06:12] <pygi> Keybuk, isn't ubuntu-dev = ubuntu-motu or something? o.o
[06:13] <Hobbsee> pygi: no, ubuntu-dev == motu + core
[06:13] <pygi> right
[06:13] <Keybuk> ahh, maybe you do want ubuntu-dev then to include ubuntu-core-dev
[06:13] <Hobbsee> oh wait.  maybe it is just motu
[06:13] <Hobbsee> Keybuk: it does
[06:14] <Keybuk> pitti: why do you need me to do anything about it?  I can only approve new members to ubuntu-core-dev no?  you approve new members to ubuntu-crashes-main
[06:15] <mvo_> enrico: changed the format means that its very incompatible? so the easiest solbution for tribe-2 (thursday) maybe to revert back to the old debtags?
[06:16] <Keybuk> pitti: ah, found the "show pending invitations" thing, and done
[06:17] <Hobbsee> hooray, mail saying as such
[06:22] <Hobbsee> dude...what?
[06:22] <[PSyKo] > owned
[06:23] <gnomefreak> Hobbsee: +t maybe?
[06:23] <Hobbsee> [PSyKo] : that'd be your bot, wouldnt it?
[06:23] <[PSyKo] > Uuuuh
[06:23] <sladen> oh wow, what fun we're having
[06:23] <Hobbsee> sladen: of course :)
[06:24] <sladen> is it coincidence that SEOmoz just pinged out then?
[06:24] <Hobbsee> sladen: not sure.
[06:24] <SEOmoz> hi
[06:24] <SEOmoz> ?
[06:25] <Hobbsee> bah.  psyko, you're a moron
[06:25] <Hobbsee> why should i unban you, if you think that bringing bots in is an acceptible practice, just to emphasise that there's a +t functionality.
[06:25] <nxvl_> is there any way in LP to filter programas, bugs or proyects by language? as in "bugs of apps writen in ruby"
[06:26] <nxvl_> :(
[06:26] <Hobbsee> nxvl_: no idea
[06:26] <ScottK> nxvl_: For Python programs we have two teams for Main and Universe subscribed to all the Python programs.  I think that's the only approach that'd work right now.
[06:27] <SEOmoz> sladen, , what ?
[06:27] <persia> nxvl: Not at this time (packages do not have a language tag).
[06:27] <Hobbsee> sladen: i dont think SEOmoz is related.  the guy didnt get thrown off the network, anyway
[06:29] <nxvl_> ScottK: so in some way, i can only filter the python packages?
[06:30] <SEOmoz> well, if you are not sure of something just do not talk about in general, because that is not an ethical behavior. i would think that you blow down the gemel towers, and you do not have brain
[06:31] <ion_> hobbsee: !#ubuntu-ops?
[06:31] <Hobbsee> SEOmoz: it was a query, not an accusation.  calm down
[06:31] <Hobbsee> ion_: banforward
[06:31] <ScottK> nxvl_: Not exactly.  If you are a member of the teams you get bugmail on all the packages.  Dunno if you can do it or not, but if you can get LP to tell show bugs only from packages to which pythoneers is subcribed that'd give you all the Python package bugs in Man.
[06:31] <SEOmoz> Hobbsee, ok, just my point of view, sorry
[06:31] <ion_> hobbsee: Ah, ok. I wasnt familiar with that Freenode feature.
[06:32] <nxvl_> ScottK: ok i will see
[06:32] <Hobbsee> ion_: :) it's usfeul
[06:32] <ion_> hobbsee: Yeah
[06:32] <sladen> SEOmoz: don't worry, if you scroll up you'll see the /topic change.  We were wondering what the root of it was;  and looked at the other people that popped off the network when the +b ban was put in place
[06:32] <nxvl_> (and do something like that for ruby :P
[06:32] <Hobbsee> sladen: but a +b is not the same as a +k anyway
[06:32] <Hobbsee> i'm no staffer
[06:32] <enrico> mvo_: I think support for the new format can be easyly hacked into libapt-front at a cost of a small performance loss
[06:32] <ScottK> nxvl_: You'd have to establish a team and the grovel through all the packages to find the Ruby ones.
[06:32] <sladen> SEOmoz: eg. being banned and then magically popping up from another host.  (Though not in your case).
[06:33] <Riddell> enrico: what would need to be done for that?
[06:35] <LaserJock> nxvl_: actually, you might be interested in http://tiber.tauware.de/~lucas/versions/ruby.html
[06:36] <SEOmoz> i do not say about me, it could happens to another person and that is not correct anyway. So just think what you want, i just do not want to tell yes about that with my silence, and i dont mind of what you think, its nonsense, and because i did not do anything bad and im not a lamer, you can even have all the information by my ISP , i never did something bad, so, i dont care, but you still talking with nonsense, just because something is magic
[06:36] <SEOmoz> for you. well, what can i say if you believe that
[06:37] <ion_> seomoz: Nobody is blaming you for anything.
[06:37] <Hobbsee> SEOmoz: it was a simple question.  if you want to talk ops stuff, here is not the place.  these guys are not ops, in most cases.  #ubuntu-ops is that place.
[06:37] <Hobbsee> SEOmoz: "i wonder if" is not the same as an accusation
[06:38] <Hobbsee> if it were an accusation, then your complaints would be warranted.
[06:38] <enrico> Riddell: change the debtags index access code and the debtags serializer
[06:39] <SEOmoz> Hobbsee, ok, thats right, but if that person insists in talking about that i have to answer, i think, come on, if you analize what was said, you know what i wrote, the end for me, thanks anyway
[06:39] <enrico> Riddell: it should require me two or three hours of work
[06:39] <enrico> Riddell: I can't guarantee I can do it before thursday, though
[06:40] <Hobbsee> SEOmoz: he's not accusing you of anything...you're the one thinking that it's an accusal, where it isnt.  However, this is not the purpose of this channel - it's for ubuntu development
[06:40] <Riddell> enrico: it would be lovely if you could do that.  I can just upload an old libept/debtags in the mean time
[06:40] <enrico> Riddell: the new debtags index adds a string table and generates package IDs internally, so that it doesn't need to have the IDs in sync with libapt
[06:41] <nxvl_> LaserJock: that's a list of the packages in ruby for debian and ubuntu?
[06:41] <enrico> Riddell: but the result is that you have to look it up using package names and not numbers
[06:41] <nxvl_> nxvl: and his bugs
[06:41] <enrico> Riddell: wait until tomorrow morning: if  by tomorrow morning I haven't fixed it, revert
[06:42] <LaserJock> nxvl_: yep, lucas is a Debian maintainer for Ruby apps and also works in Ubuntu. If you are interested in Ruby he is a good person to talk too
[06:42] <nxvl_> LaserJock: i will write to him, thnx for the help :D
[06:43] <enrico> Riddell: OTOH, wrt adept, I have the feeling that either someone who is not mornfall adopts it and ports it to the new libept (helping me to add a few missing apt-related features in libept during the process), or it's going to die of bitrot
[06:43] <LaserJock> nxvl_: np
[06:44] <Riddell> enrico: yes, I agree there
[06:44] <Hobbsee> Riddell: which raises an interesting questoina bout what will happen then
[06:44] <enrico> Riddell: unfortunately, I've never programmed with QT
[06:45] <Riddell> enrico: it needs to be maintained/scrapped anyway due to need for KDE 4 port before long
[06:45] <Riddell> Hobbsee: re-writing in python is tempting
[06:46] <nxvl_> anothre think i don't really undestand, is, what are those tribes thing?
[06:46] <enrico> Riddell: this one libept should be easily portable to Python
[06:47] <pitti> mvo_: compiz-bcop promoted
[06:47] <mvo_> pitti: cool, thanks
[06:48] <ion_> gimp-resynthesizer probably needs a rebuild for the new gimp. Should i file a bug report, or is someone who takes care of that kind of stuff online and not busy? :-)
[06:49] <pitti> what is the difference between ubuntu-dev and motu again?
[06:50] <LaserJock> ubuntu-dev is motu+core-dev
[06:50] <pitti> mvo_: hm, so ubuntu-meta still needs to get published
[06:51] <LaserJock> nixternal: the Tribe releases are like alpha releases as we go along during the development cycle
[06:51] <pitti> mvo_: it won't make it into the archive before I leave to Taekwondo, so maybe Mithrandir can trigger images
[06:51] <nixternal> LaserJock: I know that
[06:51] <nixternal> ;p
[06:51] <pitti> mvo_: otherwise I'll trigger them at 23:00 CEST when I return
[06:51] <LaserJock> nxvl_: sorry ^^ was for you
[06:51] <nixternal> hehe
[06:51] <pitti> mvo_: but that's going to be a night shift for you then; maybe just test the dailies from tomorrow?
[06:52] <Hobbsee> heh.  this is where people from multiple TZ's would come in handy
[06:53] <mvo_> pitti: yeah, guess that is the best option (waiting for tomorrow)
[06:53] <pitti> Hobbsee: indeed :)
[06:54] <mvo_> looks like my network interface got swapped when updating to the latest ubuntu kernel. interessing
[06:57] <pitti> Riddell: with your current libept/debtags uploads, can we move bug 121456 to tribe-3? or does that address something else?
[06:57] <nxvl_> LaserJock: ok, thnx :D
[06:57] <ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
[06:57] <Hobbsee> pitti: should be fine, assuming the old lot works.
[06:58] <pitti> Hobbsee: ok; can you move this over, please, once it has been confirmed?
[06:58] <Hobbsee> pitti: will do
[06:58] <pitti> let's move it to tribe-3, so that we won't forget about this ugliness
[06:58] <Hobbsee> yeah
[06:58] <Hobbsee> see, i do sleep occasionally!
[06:59] <pitti> well (now + 8 hours) is perfectly sufficient :)
[06:59] <Hobbsee> hehe
[07:00] <calc> Hobbsee: wow you are +15 from me
[07:00] <Hobbsee> calc: yes...catch up! no pont living in the past
[07:00] <calc> so what is it like to live in tomorrow? ;)
[07:00] <Hobbsee> well, it means that my exams are over :)
[07:02] <pygi> good for you
[07:02] <pygi> I have too much of them
[07:02] <Hobbsee> :)
[07:04] <gpocentek> pitti: gnumeric was waiting for goffice B-D, does it need a manual intervention to start building?
[07:04] <pitti> gpocentek: no, it should happen automatically
[07:04] <gpocentek> ok,thanks
[07:09] <pygi> hey glatzor
[07:09] <glatzor> hey pygi
[07:14] <pitti> BenC: I bumped the buildd prios of the kernel, it's building on all arches now
[07:14] <BenC> pitti: thanks
[07:14] <BenC> should take 3 hours max on major 4 architectures
[07:14] <pitti> BenC: I'll NEW them after returning from Taekdonwo (in about 3.5 hours)
[07:15] <BenC> pitti: germans taking taekwondo...scarry :)
[07:20] <pitti> BenC: I guess you will still be there at that time for uploading lrm, backports-modules, and ubuntu-modules?
[07:23] <pitti> Riddell: btw, do you want to test strigi in herd-2?
[07:23] <pitti> Riddell: I thought you already promoted strigi, clucene, and xapian
[07:23] <pitti> but they are still in universe
[07:26] <BenC> pitti: yeah
[07:27] <pitti> evand: in case cjwatson does not come back in time, do you already know how to rebuild d-i against a new kernel ABI?
[07:27] <pitti> fabbione: ^ well, you know, right?
[07:27] <calc> BenC: i learned about HDA over the weekend, fun stuff, heh
[07:28] <BenC> calc: it's only fun if you like dozens of quirks for dozens of different codecs :)
[07:28] <BenC> and seems every new HDA audio chipset has a new quirk
[07:29] <BenC> you'd figure as popular as it is, they would do something interesting like being able to programatically pull the pinouts and stuff from the chip
[07:29] <calc> BenC: yea
[07:29] <BenC> just a few bytes of firmware, that's all I ask
[07:30] <evand> pitti: negative :(
[07:32] <pitti> evand: ok, no problem
[07:32] <calc> hmm was nothing
[07:51] <Hobbsee> if the world blows up, i didnt do it.
[08:04] <fabbione> pitti: yes i do
[08:04] <fabbione> evand: ^^
[08:06] <tkamppeter> pitti, I have solved the foo2zjs problem (biff)
[08:07] <fabbione> mdz: any specific reason why ubuntu-meta has ubuntu1 now?
[08:07] <tkamppeter> I simply ignore the error of manual.pdf not getting built and leave the package without manual.pdf if such an error happens. manual.pdf is a PDF with a copy of all man pages, not very important.
[08:08] <tkamppeter> pitti, and once doing a change on the package I have also updated to the current upstream version of foo2zjs.
[08:09] <fabbione> he is not here
[08:10] <evand> fabbione: ok, good
[08:19] <dmb> i have a couple of questions
[08:21] <mdz> fabbione: likely just that dch does it automatically now
[08:21] <fabbione> mdz: heh
[08:23] <dmb> how does the debian installer bootstrap the core utilities?
[08:23] <dmb> does it use debootstrap?
[08:31] <mdz> dmb: yes
[08:32] <dmb> mdz: awsom
[08:34] <dmb> is there a place where I can find development docs for ubuntu advanced installer?
[08:37] <pygi> dmb, it's mostly d-i
[08:37] <evand> dmb: https://wiki.ubuntu.com/InstallerDevelopment
[09:29] <mikmorg> Hello.
[09:29] <mikmorg> Could someone tell me what the canonical way is to determine if the current OS uses initrd, vs initramfs?
[09:40] <pygi> who wanna upload stuff? :)
[09:40] <pygi> ha fabbione! wake up pls ^_^
[09:46] <pygi> oh well, I'll just wait
[10:05] <pygi> seb128, you was lucky you weren't here :P
[10:05] <seb128> when?
[10:06] <pygi> just a few secs ago :)
[10:06] <pygi> Otherwise I'd have to bug you :)
[10:06] <pygi> But oh well ^^
[10:07] <seb128> what was the bug about? who is going to fix it? ;)
[10:07] <pygi> seb128, I fixed it, about brasero failing to build on sparc and ppc
[10:07] <pygi> I wanted a sponsor :)
[10:07] <seb128> ah, k
[10:07] <pygi> mr_pouit is supposed to handle that now :p
[10:08] <pygi> if I could just make him wake up :P
[10:08] <superm1_> does that mean I could bug seb128..... :)?
[10:09] <pygi> superm1, nop, I have some things in preparation for him :P
[10:09] <seb128> you can try, not sure it's going to work though
[10:09] <superm1_> seb128, i've got a few things that have been sitting in NEW for a while
[10:10] <superm1_> wanted to see if you could take a gander
[10:10] <seb128> a while being?
[10:10] <superm1_> well 05-01-07 on some stuff in edgy
[10:10] <seb128> edgy?
[10:10] <superm1_> (backports)
[10:10] <seb128> I don't do stable
[10:11] <seb128> did you subscribe ubuntu-archive?
[10:11] <seb128> I did a round of backport some days ago
[10:11] <superm1_> well the weird thing is the amd64 and ppc stuff cleared
[10:11] <superm1_> its just the i386 binaries that didn't
[10:11] <seb128> what package is that?
[10:11] <superm1_> mythtv
[10:12] <superm1_> http://launchpadlibrarian.net/7544963/mythtv_0.20-svn20070122-0.0ubuntu6%7Eedgy1_i386.changes
[10:12] <superm1_> that was the upload
[10:13] <seb128> do you think that edgy still has users? ;)
[10:13] <seb128> looking
[10:14] <superm1_> well this came to my attention because of a forums post from someone on edgy
[10:14] <superm1_> so maybe 1 or 2 .... :)
[10:21] <seb128> superm1_: mythtv i386 accepted
[10:23] <superm1_> great seb128 .  one more.
[10:23] <superm1_> in gutsy, libhdhomerun (source) was uploaded 2007-06-01 and there have been new source packages after it cleared
[10:23] <superm1_> so i wasnt sure if there was troubles with it or anything
[10:23] <ion_> amaranth: * debian/patches/01-animation-defaults.patch: - setup animation defaults as specified in the spec  what spec is that? :-)
[10:25] <seb128> ion_: https://wiki.ubuntu.com/CompositeByDefault
[10:25] <mikmorg> cjwatson: Hello
[10:25] <mikmorg> cjwatson: Are you online?
[10:25] <ion_> seb128: Ah, right. Thanks.
[10:26] <seb128> ion_: np
[10:27] <ion_> Yay, Emerald is going to be used.
[10:31] <seb128> superm1_: why all the libhdhomerun source files +x?
[10:32] <superm1_> they were distributed that way from what i remember
[10:32] <superm1_> in the upstream archive
[10:36] <seb128> superm1_: libhdhomerun accept now
[10:36] <superm1_> great seb128 thanks
[10:36] <seb128> you're welcome
[10:37] <ScottK> seb128: Riddell said I should ping you to discuss possible changes in the default gnupg config for Gutsy.  Would this be a good time to discuss it?
[10:38] <seb128> ScottK: not really no, I'm about to restart my session to test some compiz changes and it's starting being late, better tomorrow, though I'm not sure I'm the right guy to speak about those, I don't know a lot about gnupg
[10:38] <geser> ScottK: what will you change in gnupg?
[10:38] <ScottK> OK.  Any suggestions on who would be the best person to talk to?  We may need a change to support or S/MIME by default in Kmail goal.
[10:39] <ScottK> geser: Tell it to "use-agent"
[10:39] <ScottK> or/our S/MIME - oops
[10:39] <ScottK> seb128: ^^^?
[10:40] <seb128> ScottK: not sure, you can try cjwatson or Mithrandir or pitti or keescook
[10:40] <seb128> or Keybuk
[10:40] <ScottK> seb128: OK.  Thanks.
[10:40] <seb128> you're welcome
[10:41] <geser> ScottK: I've looked at but you would probably need gpgsm and gpg-agent moved from universe to main
[10:41] <geser> the source (gnupg2) is already in main
[10:42] <geser> gpgsm is already in main
[10:42] <ScottK> geser: I think they both are, but I may have missed it.  I've got a pending MIR for pinentry which is also needed.
[10:43] <geser> gnupg-agent is in universe but the source is already in main
[10:43] <ScottK> geser: You're right about agent.  Looks like another MIR I need to write.  Thanks for pointing that out.
[10:44] <geser> ScottK: have you tested what happens if the seahorse-agent and the gnupg-agent are both started?
[10:45] <ScottK> geser: I haven't (I use Kubuntu).  I gather it's not good?
[10:46] <geser> I don't know. I only remember that seahorse acts also as a gnupg-agent
[10:47] <ScottK> geser: I guess I'll add that to my list of things to look into.
[10:47] <geser> but that shouldn't stop the inclusion to main
[10:48] <ScottK> Yes.  The config issue is separate from promotion to main.
[11:14] <pitti> BenC: kernel ia64 NEWed as well (will be published in 80 minutes; I can get it down to 50 if necessary)
[11:14] <pitti> BenC: so the path is free for l-r-m/ubuntu-modules/backport-modules now
[11:31] <tkamppeter> pitti, I have solved the foo2zjs problem (biff)
[11:31] <tkamppeter> I simply ignore the error of manual.pdf not getting built and leave the package without manual.pdf if such an error happens. manual.pdf is a PDF with a copy of all man pages, not very important.
[11:31] <tkamppeter> pitti, and once doing a change on the package I have also updated to the current upstream version of foo2zjs.
[11:48] <pitti> tkamppeter: ah, good
[12:04] <pygi> pitti, you around for a sec?
[12:05] <pygi> (yes, I know it's very late)
[12:05] <pitti> one second is fine
[12:05] <pygi> build on ppc/sparc is behaving
[12:05] <pygi> http://launchpadlibrarian.net/8190074/buildlog_ubuntu-gutsy-powerpc.brasero_0.5.90-0ubuntu4_FAILEDTOBUILD.txt.gz
[12:05] <pygi> it complains about something I've solved by a patch
[12:06] <pygi> (at least I think)
[12:07] <pitti> pygi: did you check twice? :)
[12:08] <pygi> pitti, yes :P But might be that something else causes the problem now, although it's the same line
[12:08] <pygi> just checking again
[12:08] <pitti> Trying patch debian/patches/ubuntu_02_fix_sparc_ppc_build.patch at level 1 ... success.
[12:08] <pitti> looks good at least
[12:08] <pygi> might be that "uchar op_chge_event	:1" lacks ";" at the end :P
[12:08] <pygi> but that's ergh again upstream issue
[12:09] <enrico> Riddell: please wait until tomorrow evening (or wednesday morning, just to be on the safe side with timezones and local understandings of 'evening': tomorrow I'll be traveling by trains and planes, so I'll have time to hack
[12:09] <pygi> pitti, if I change that this sec, could you upload pls? ^_^
[12:09] <pitti> pygi: I can, please send me a debdiff
[12:09] <pygi> pitti, yay, thanks
[12:10] <pitti> pygi: (and a diff.gz/dsc/source.changes, please)
[12:11] <pitti> tkamppeter: erk @ perl -p -i -e 's/(install.*manual\.pdf)/-\1/' Makefile
[12:11] <pitti> tkamppeter: can you please re-do this change as a proper patch?
[12:11] <pitti> tkamppeter: otherwise this will keep changing the Makefile with every build, and it's very non-common practice