[00:23] <Ampelbein> hi. i get a FTBFS for xserver-xorg-input-aiptek, buildlog: http://www.warperbbs.de/melting/readfile.php?file=andreas/xserver-xorg-input-aiptek_1.1.1-1build2_i386.build.gz , error: http://paste.ubuntu.com/141051/
[00:25] <TheMuso> Ampelbein: at a glance, you are missing a build dependency of some sort.
[00:25] <TheMuso> Ampelbein: apt-file could help you track down the file you want, and the package its in.
[00:25] <Ampelbein> TheMuso: just seen: http://launchpadlibrarian.net/24381721/buildlog_ubuntu-jaunty-i386.xserver-xorg-input-aiptek_1%3A1.1.1-1build2_FAILEDTOBUILD.txt.gz thats the official build
[00:26] <Ampelbein> should i open a bug for this?
[00:26] <TheMuso> Ampelbein: not sure yet, let me think...
[00:28] <TheMuso> Ampelbein: I think a bug is only needed if you have a diff to fix it, but others may think differently.
[00:29] <Ampelbein> TheMuso: i also think that's why those packages are not installable anymore. we changed xserver-xorg version and the old, compiled packages, conflict with those versions.
[00:29] <TheMuso> right
[00:29] <Ampelbein> see bug #351076
[00:30] <Ampelbein> TheMuso: i'll be looking for the file and provide a diff
[00:30] <bryce> Ampelbein: thanks
[00:30] <bryce> Ampelbein: this bug was discussed on ubuntu-x@ earlier today.
[00:31] <Ampelbein> bryce: oh, sorry. didn't see that
[00:31] <Ampelbein> just joined half an hour ago
 sbeattie: there are a few input drivers that won't build against xserver 1.6. on my list of things to fix..
[00:32] <bryce> sorry, s/ubuntu-x@/#ubuntu-x/
[01:09] <LaserJock> kees: around?
[01:17] <kees> LaserJock: in and out, trying to get a ppc machine booted
[01:53] <Ampelbein> bryce: i think i found the issue, at least for the aiptek-driver, must look for the other drivers too.
[01:53] <bryce> Ampelbein: excellent
[01:54] <Ampelbein> it seems that since ABI-Version 3 some function calls became obsolete
[01:54] <Ampelbein> and of course the filename changed from xf86Version.h to xorgVersion.h
[01:55] <Ampelbein> i will attach a patch for someone experienced to review though
[02:01] <Ampelbein> bryce: can you give me some assistance? got the following warning from dpkg-shlibdeps :http://paste.ubuntu.com/141095/
[02:02] <Ampelbein> shouldn't shlibdeps check the "depends" and get the symbols from the libraries needed?
[02:02] <bryce> not sure
[02:03] <bryce> but Xfree, Xrealloc, xf86Msg, etc. are all extraordinarily standard calls that haven't moved or anything
[02:04] <bryce> Ampelbein: you might compare how linking is done in this driver with a working driver.  maybe it's doing things in a wrong order or something
[02:05] <Ampelbein> ok, will do that
[02:22] <Ampelbein> bryce: a dependency was missing. but this could not have resulted in an actual error as those dependencies are installed with xorg anyway. but i added them nonetheless.
[02:24] <bryce> ok
[02:26] <Ampelbein> bryce: now a package-naming question: currently the package is named 1.1.1-1build2, should i name 1.1.1-1build3 or rather 1.1.1-1ubuntu1, since this is a change not in debian yet?
[02:26] <bryce> 1.1.1-1ubuntu1
[02:27] <Ampelbein> thank you very much for helping!
[02:32] <YokoZar> Ampelbein: regarding missing dependencies: does the package list ${shlibs:Depends} on its depends line?
[02:32] <Ampelbein> YokoZar: yes, it does
[02:33] <YokoZar> hmm, ok then.  I'm still trying to figure out the cases where that misses things
[02:36] <bryce> Ampelbein: and thanks for investigating the problem!
[02:51] <Ampelbein> bryce: bug #352083
[02:51] <Ampelbein> could you look over it and see if what i've done is ok?
[02:51] <bryce> sure
[02:52] <Ampelbein> i'm a bit unsure because i usually use quilt or cdbs to add patches. here i added quilt, but before there was no patchsystem used.
[02:52] <Ampelbein> so there are many changes not reflected.
[02:55] <bryce> Ampelbein: yes this looks perfect, thanks for adding a patch system, that's the correct way to do it
[02:56] <bryce> Ampelbein: this looks good to me, do you feel it to be ready for upload?  I can sponsor for you if so.
[02:57] <Ampelbein> bryce: don't know. the driver builds fine, but i don't have an aiptek handy to test if it works correctly
[02:57] <bryce> hmm
[02:57] <bryce> I tried pbuildering it but got an error
[02:57] <Ampelbein> whuups.
[02:57] <Ampelbein> my bad
[02:57] <infinity> bryce: Your posted debdiff can't possibly be correct.  It doesn't include any debian/* changes for quilt.
[02:58] <bryce> let me doublecheck that the patch is applying
[02:58] <Ampelbein> i forgot
[02:58] <Ampelbein> debian/rules not changed
[02:58] <bryce> infinity: aha right
[02:59] <infinity> bryce: Also, sort of ironic that you told him that was the right way to do it.  I tend to rey to discourage people from forking packaging from Debian (unless you intend to push the quiltiness back up to XSF) just to maintain a 3-line patch...
[02:59] <bryce> Ampelbein: do you want to post a new debdiff with that added or shall I?
[02:59] <Ampelbein> i will do that
[03:00] <infinity> bryce: A 3-line inline diff is so much easier to merge than a bunch of extra goo in debian/*
[03:00] <bryce> infinity: tjaalton is going to incorporate the fixes for this and other input drivers that are failing to build and put into debian
[03:00] <infinity> s/tend to rey/tend to try/
[03:01] <Ampelbein> so shouldn't i use a patchsystem for that?
[03:01] <infinity> bryce: Kay.  If all the debian/* changes are going upstream too, I retract my objection.  I just spent too much time over too many years merging massive changesets that boiled down to "I wanted to fix a 5-character string, and I added 15 lines to debian/* to do it"
[03:02] <Ampelbein> infinity: i'm sorry. i'm fairly new to this. just updated ubuntu-desktop-packages so far.
[03:02] <infinity> Ampelbein: Don't apologize.  It's more of a religious thing than a strict policy. :)
[03:02] <bryce> infinity: in this case the fix Ampelbein is adding is already upstream at freedesktop.org, so he's essentially backporting it for us
[03:02] <infinity> Ampelbein: And if the people who will be dealing with this (bryce and tjaalton) think it's good, it's good.
[03:03] <bryce> infinity: when debian has a newer version incorporated, we can probably just sync.  But meantime this will enable others to test the driver
[03:03] <infinity> bryce: Yeah.  My usual argument is just that it makes merging with Debian a bit tougher.  More chance for conflicts in control/rules/etc.
[03:03] <bryce> infinity: what Ampelbein is doing is good
[03:03] <infinity> bryce: But, not my domain, so I defer to you and tjaalton.
[03:04] <bryce> infinity: we're well accustomed to patch systems appearing and disappearing as needed for patch backports, so it's all good
[03:08] <Ampelbein> bryce: correct patch added.
[03:10] <Ampelbein> note to self: alaways run "debuild -S -sd" after changing something
[03:10] <bryce> :-)
[03:11] <Ampelbein> oh, you wanted a debdiff.
[03:11] <Ampelbein> wait a second
[03:14] <Ampelbein> debdiff attached
[03:14] <bryce> awesome, pbuildering
[03:15] <bryce> builds
[03:15] <Superdweeb> hey guiz, I know this is a stupid, irrelevant, non-development question but..when we implement it,will plymouth work with a mobile radeon 7500?
[03:15] <Ampelbein> i didn't figure out how to get rid of the missing symbols though. but they are in ALL previous builds
[03:16] <Ampelbein> the missing dependency wasn't missing after all ;-)
[03:16] <bryce> Ampelbein: ok looks good.  I added a mention of the rules changes in the changelog but otherwise looks good to go
[03:16] <bryce> Ampelbein: upload sponsored, thanks :-)
[03:16] <Ampelbein> damn. forgot that. ok then, will look at the other xserver-xorg-input-* packages tomorrow
[03:17] <Ampelbein> it's 04:16AM here.
[03:17] <Ampelbein> have to work at 10, so 4 hours sleep have to be enough ;-)
[03:18] <Ampelbein> bryce: thanks for all the help. and hanks infinity for the different view on the patch-things
[03:18] <Ampelbein> s/hanks/thanks.
[03:19] <bryce> night Ampelbein
[03:19] <Ampelbein> cu all.
[04:32] <lfaraone> A
[05:02] <YokoZar> Quick question: are the patch tagging guidelines at https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines just comments manually inserted to the top of a debdiff, or are they meant to go into the patch file inside the package itself?
[05:04] <YokoZar> Nevermind it's almost surely the latter
[05:07] <ScottK> YokoZar: It is the latter.
[05:13] <YokoZar> So, I've added two patches to the main sponsorship queue, but in return I've cleared two things from the universe queue ;)
[05:23] <Superdweeb> Does that mean...
[05:23] <Superdweeb> You've..
[05:23] <Superdweeb> OMG.
[05:23] <Superdweeb> ZERO ENTROPY>
[05:23] <Superdweeb> WORK DONE FOR NOTHING
[05:23] <Superdweeb> ERROR IN MAIN DATABANKS.
[05:37] <LordKow> is nautilus-actions not being maintained anymore upstream? i took a look at nautilus-act in GNOME's bugtracker and none of them are confirmed but all revolve around bug 341035
[05:38] <LordKow> i shouldn't say all of them. but a few of them.
[05:44] <LordKow> heh yea the nautilus actions websites have not seen updates for at least a couple years.
[05:50] <LordKow> oh it's a universe package, nm :-)
[06:26] <dholbach> good morning
[06:30] <fabrice_sp__> Hey dholbach!
[06:30] <fabrice_sp__> good morning
[06:32] <dholbach> hi fabrice_sp!
[06:49] <pitti> Good morning
[06:55] <dholbach> hum, why is pinentry-gtk2 suddenly installed on my machine? and gnupg-agent and gnupg and gnupg2, shouldn't gnupg and seahose be enough?
[06:56] <dholbach> (just discovered when I had an ugly text box coming up for entering my gpg key)
[07:00] <TheMuso> dholbach: So thats why the GPG signing dialog box changed. :)
[07:00]  * TheMuso didn't really consider it, thought it was a change in gpg-agent or whatever got used.
[07:00] <dholbach> TheMuso: I have no idea which upgrade pulled it in, but purging pinentry-gtk2 and gnupg-agent "fixed it for me"
[07:01] <dholbach> still somewhat surprised about it and gnupg{,2} being around
[07:05] <fabrice_sp> Hi pitti, it seems you uploaded the debdiff in Bug #338553, without changing what you put in your comment. Is it normal?
[07:27] <pitti> fabrice_sp: sorry, what do you mean?
[07:28] <pitti> dholbach: oh, I wondered about that yesterday
[07:28] <dholbach> pitti: I didn't narrow down how that happenede
[07:30] <pitti> dholbach: gnupg2 recommends gnupg-agent
[07:31] <dholbach> pitti: do you know why we have the two gnupgs?
[07:31] <pitti> dholbach: we have had them for ages
[07:31] <pitti> primarily for kde
[07:32] <dholbach> but both installed?
[07:32] <pitti> purging gnupg2 would purge ecryptfs-utils and seahorse, hmm
[07:33] <pitti> a-haa
[07:33] <pitti> Package: libgpgme11
[07:33] <pitti> Depends: libc6 (>= 2.8), libgpg-error0 (>= 1.4), libpth20 (>= 2.0.7), gnupg (>= 1.4.6-2), gnupg2 (>= 2.0.4)
[07:33] <pitti> that should be an |, I guess
[07:33] <pitti> also, why is a program a dependency of a library in the first place..
[07:35] <pitti> I filed bug 352180
[07:36] <pitti> slangasek: ^ that's responsible for at least 1.3 MB CD space
[07:36] <slangasek> ah, cool
[07:37] <pitti> a-ha
[07:37] <pitti> http://launchpadlibrarian.net/24055413/gpgme1.0_1.1.8-2ubuntu1_1.1.8-2ubuntu2.diff.gz
[07:37] <pitti> recent ubuntu specific change
[07:37] <cody-somerville> pitti, depmod is failing to run with the new kernel (2.6.28-11.38) but apport says its not generating a report because "the error message indicates its a followup error from a previous failure".
[07:41] <cody-somerville> pitti, Now its saying "No apport report written because MaxReports is reached already"
[07:41] <pitti> cody-somerville: can you please ping mvo about it? that's from libapt
[07:41] <cody-somerville> Okay.
[07:41] <dholbach> can an ubuntu-release member follow up on bug 351591?
[07:45] <pitti> dholbach: done, but what's to be done on it from a release hat?
[07:45] <dholbach> pitti: I thought it needs an ACK at this point, no?
[07:46] <pitti> dholbach: only freeze violations
[07:46] <dholbach> ok
[07:55] <pitti> dholbach: new gpgme uploaded; thanks for pointing out
[07:55]  * pitti tosses more CD space to slangasek
[07:55]  * dholbach hugs pitti
[07:55] <dholbach> WOOHOO!
[07:56]  * pitti hugs dholbach
[08:00] <pitti> tkamppeter_: rejected foo2zjs from intrepid-proposed, no bug number in changelog
[08:09] <tjaalton> nxvl: did you see my comment about aterm and the removal of /usr/bin/aterm?
[08:15] <tkamppeter> pitti, sorry, will re-upload. Bug number for you to see the report already now: bug 351630
[08:16] <tkamppeter> pitti, new version uploaded.
[08:19] <ebroder> pitti: For bug 348865 the real symptoms are from the packages I listed that build-dep on libgsasl7-dev. Any chance that rebuilds of those could be uploaded to -proposed?
[08:20] <ebroder> (the msmtp in -backports is what caused us to notice the bug initially)
[08:20] <dholbach> can somebody moderate my mail on u-d-a?
[08:21] <pitti> tkamppeter: is that fixed in jaunty already?
[08:21] <pitti> dholbach: looking
[08:21] <dholbach> thanks pitti
[08:21] <pitti> dholbach: the "МАССОВАЯ РЕКЛАМА"?
[08:21] <dholbach> pitti: errrrrr, no :)
[08:21] <pitti> the Реkлама для Вашей фирмы then?
[08:21] <dholbach> pitti: no
[08:21]  * pitti wonders why for some months we get 99% russian spam
[08:21] <dholbach> pitti: something with Packaging Training? :)
[08:22] <pitti> for those who don't speak Russian, that means "Advertisement for your company"
[08:22] <pitti> at least you can't claim that they don't mark their spam appropriately
[08:22] <pitti> dholbach: nudged
[08:22] <dholbach> pitti: gracias!
[08:23] <pitti> dholbach: de nada
[08:23] <pitti> ebroder: once the -proposed version is in?
[08:24] <pitti> ebroder: sure, if that's necessary, please explain in the bug and add tasks for the packages which need rebuilds; feel free to upload them already, we can accept them once the gsasl SRU is built and published
[08:24] <tkamppeter> pitti, yes, it is fixed in Jaunty. Should I mark the main task of bug 351630 as "Fix Released" then?
[08:24] <pitti> tkamppeter: yes, please
[08:25] <pitti> tkamppeter: rejecting again; there's still no bug number in the changelog
[08:25] <tkamppeter> pitti, bug updated.
[08:25] <ebroder> pitti: I'll open the necessary bugs, but I'm not MOTU so I can't target or upload. Who should I subscribe to the bugs to get them dealt with?
[08:25] <pitti> ebroder: motu-sru should already be subscribed, should be fine
[08:25] <ebroder> Ok
[08:26] <tkamppeter> pitti, in the notification I got there is a "(LP: #351630)", so I perhaps should send you the package by personal mail?
[08:27] <tkamppeter> bug 351630
[08:27] <pitti> tkamppeter: perhaps you accidentally uploaded the previous package again?
[08:27] <tkamppeter> pitti, I will retry and after that report a bug in LP.
[08:27] <pitti> tkamppeter: please look at the source.changes before uploading
[08:27] <pitti> it should have the (LP: #12345) in it
[08:28] <tkamppeter> pitti, it is exactly that.
[08:28] <pitti> tkamppeter: ah, hang on
[08:28] <tkamppeter> I have even verified the bug number with Ubotto
[08:28] <pitti> tkamppeter: do you still have an .upload file around?
[08:29] <tkamppeter> Yes.
[08:29] <pitti> you need to delete this, otherwise dput will do nothing
[08:29] <tkamppeter> I had done dput -f
[08:29] <tkamppeter> and it showed that it uploaded files
[08:30] <pitti> hmm
[08:30] <pitti> let's just try it again then
[08:30] <tkamppeter> I can simply raise the version number as a workaround for the LP bug
[08:30] <pitti> tkamppeter: no, don't
[08:31] <pitti> tkamppeter: ignore me
[08:31] <mdke> seb128: around?
[08:31] <pitti> I see the correct upload now
[08:31] <tkamppeter> It always says
[08:31] <tkamppeter> OK
[08:31] <seb128> mdke: hi
[08:32] <mdke> seb128: hi! I tried that fix for brasero and it works, but the debdiff is contaminated for some reason by the pot file for the help. I've attached it to bug 264314 anyway, let me know if you know why that has happened
[08:33] <seb128> mdke: clean targets are buggy you probably did build clean and rebuild in the same directory
[08:33] <seb128> mdke: you can edit the debdiff by hand or remove the template manually if you want
[08:33] <mdke> seb128: aha. Ok, let me try
[08:37] <mdke> seb128: ok, revised debdiff posted to the bug
[08:37] <mdke> thanks
[08:37] <seb128> mdke: thank you
[08:38] <seb128> mdke: subscribe the sponsor team if you didn't, I will have a look later
[08:38] <mdke> seb128: done
[08:49] <slangasek> pitti: oh - I forgot that en is the only language with language-support on the CD... that means splitting gnome-user-guide buys us even more space than I thought, too :)
[08:50] <directhex> yay, space
[08:52] <pitti> slangasek: hehe
[08:52] <pitti> even with the current dailies we have an impressive 11 MB (i386)/7 MB (amd64) free
[08:52] <pitti> add another 1.3 for the gnupg2 fix
[08:52] <pitti> yay
[08:53]  * slangasek preemptively adds more langpacks in :)
[08:54] <directhex> now just free up another 100 meg, and we're sorted for OpenJDK!
[08:56] <Hobbsee> but didn't you know we have to add a whole bunch of otehr default wallpapers on?  apparently that's just *so* important, according to the bug about it...
[08:56] <Mithrandir> Hobbsee: heh
[08:56] <directhex> Hobbsee, well, whatever happened to monthly naked wallpapers, what's what i want to know!
[08:57] <Hobbsee> directhex: they got moved to your friendly neighbourhood porn site, filtered by the Australian Minister for Censorship.
[08:58] <directhex> Hobbsee, i thought only dissident thought was on the censorship ministry's filter list
[08:58] <Hobbsee> directhex: that too.  There's a whole bunch of stuff on there that shouldn't be, it appears, from wikileaks
[08:59] <directhex> is that the same ministry for censorship that feels the best way to protect children from violent videogames is to outright refuse to classify 18-rated games as 18+, and instead release them as 15+?
[08:59] <seb128> pitti, slangasek: can we get a list of what language packs are on the CDs now and what else we could get with how much space?
[08:59] <Hobbsee> directhex: i'm not sure.
[08:59] <RAOF> They do refuse 18+ games, yes.  I'm not sure it's the same department.
[09:00] <slangasek> seb128: 'grep Languages ship live'?
[09:00] <slangasek> (for the first part)
[09:00] <seb128> slangasek: right, thanks ;-)
[09:01] <slangasek> still a short list, but looking better
[09:01] <slangasek> knowing what we can get with more space will have to wait for another CD run with pitti's latest space-saving changes
[09:02] <seb128> ok
[09:02] <slangasek> French is safe on i386 desktop, anyway. :)  Still not on amd64 desktop yet
[09:09] <ebroder> What causes...apt? dkpg? I guess I'm not sure which...to display the changelog entry and send mail to root@localhost?
[09:24] <pitti> bryce: *wiping off a tear* Jesse Barnes' -intel patch turned my X from "several problems" into "work of perfection"
[09:24] <seb128> pitti: what patch?
[09:25] <seb128> pitti: does it fix intel crashing when closing an another session?
[09:25] <pitti> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=19304#c41
[09:25] <pitti> seb128: I didn't have that problem
[09:25] <pitti> seb128: but I don't think so
[09:25] <seb128> ok
[09:25] <pitti> seb128: that patch fixes flickering in glxgears, and pipe underruns
[09:26] <pitti> seb128: I did several guest sessions etc. yesterday, no crashes for me
[09:26] <pitti> and so far it didn't freeze after suspend yet
[09:26] <seb128> lucky you
[09:27] <seb128> I can't use my laptop to do any user switching since jaunty
[09:27] <seb128> it crashes on session closing with exa
[09:27] <seb128> and on session opening with uxa
[09:28] <pitti> bryce: apparently the "fix pipe underrun" patch I previously applied was more like a hack (static watermark levels), current one computes them dynamically
[09:28] <pitti> seb128: is that bug upstream?
[09:28] <pitti> I get quite a good responsiveness from them
[09:29] <seb128> pitti: no, it's on https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/348428 but I will upstream it today if they don't
[09:30] <seb128> I've added stacktrace for the exa and uxa crashes there
[09:34] <UBN2> why does python suck so much compared to all other languages???
[09:47] <pitti> bah, shouldn't have said this too loudly, X hung again after suspend
[09:48] <Hobbsee> it wanted to catch you out again...
[09:49] <pitti> bah, not having suspend sucks
[09:50] <pitti> especially on planes and conferences
[09:52] <directhex> pitti, weren't you paying attention? jaunty boots so awesomely fast, you don't NEED suspend!
[09:52] <pitti> seb128: just read the bug (also the upstream one, which is linked now); I don't get that, no
[09:52] <pitti> directhex: now, if only we had session saving..
[09:52] <seb128> pitti: ok
[09:52] <directhex> pitti, still broken on jaunty?
[09:52] <pitti> directhex: and "switch on" to "desktop" is still 2 minutes on my machine
[09:52] <seb128> pitti: we have on logout ;-)
[09:53] <pitti> seb128: session _saving_?
[09:53] <pitti> I'm still starting my gsession.sh script after logging in
[09:53] <pitti> but that only does half of the job
[09:53] <hyperair> directhex: when you can boot in 3 seconds, tell me again that i don't need suspend
[09:53] <directhex> hyperair, try BeOS ;)
[09:53] <hyperair> that's not ubuntu
[09:53] <seb128> pitti: yes
[09:53] <hyperair> i want ubuntu damnit
[09:54] <jamesh> pitti: thanks for landing that hal-info patch for me.
[09:54] <pitti> jamesh: you're welcome
[09:54] <jamesh> now we just need portable media players running UME
[09:55] <RicardoPerez> pitti: ping
[09:55] <pitti> RicardoPerez: http://err.no/personal/blog/2006/Oct/10
[09:56] <RicardoPerez> pitti: oh, sorry, you are right :)
[09:56] <RicardoPerez> pitti: bug #348225 seems not to be solved for me. translations are still inside .desktop files
[09:57] <pitti> RicardoPerez: hm, worked on a local build
[09:57] <pitti> RicardoPerez: I assume the buildd chroots have an outdated pkgbinarymangler then
[09:57] <RicardoPerez> pitti: can I help in some way in order to fix it?
[09:58] <pitti> RicardoPerez: can you please reopen the synaptic/s-c-p tasks and say so?
[09:58] <RicardoPerez> pitti: right, they're already open
[09:58] <pitti> infinity, lamont: it seems our buildd chroots have an outdated pkgbinarymangler; can you please upgrade them to version 57?
[10:01] <infinity> pitti: They autoupgrade on build...
[10:02] <pitti> that's what I thought as well..
[10:02] <infinity> pitti: That said, there's no mangler upgrade being done in recent builds, so it's up-to-date in the chroots...
[10:04] <infinity> pitti: Or not... *blink*
[10:04] <pitti> weird, I looked at the synaptic build log, and there's no trace of the new code
[10:05] <infinity> Oh, FFS.
[10:05] <infinity> pitti: Someone demoted it to universe...
[10:05] <infinity> pitti: On main builds, the chroots only have main in sources.list, so no upgrade.
[10:06] <infinity> pitti: Why on earth was pkgbinarymangler demoted?
[10:06] <pitti> WTH?
[10:06] <pitti> infinity: I have no idea
[10:06]  * pitti promotes
[10:06] <pitti> infinity: perhaps it appeared in component-mismatches, and someone was too eager with cleaning it up
[10:06] <RicardoPerez> I see pkgbinarymangler in universe, too
[10:06]  * pitti seeds
[10:08] <pitti> infinity: so once that's in main again, the chroots will upgrade them automatically?
[10:08] <infinity> pitti: Yup.
[10:08] <pitti> infinity: ok, thanks!
[10:08] <infinity> pitti: I'll freshen them during my work hours tomorrow anyway, but the auto-upgrading should work once it's republished to main.
[10:09] <infinity> Oh how I long for audit trails in soyuz, so I could tell WHO demoted it back in February. :/
[10:10] <RicardoPerez> Thanks a lot to anybody helping to fix this bug :)
[10:11] <RicardoPerez> pitti: can I disturb you with another "fixed" bug, not fixed really?
[10:11] <pitti> RicardoPerez: sure
[10:12] <RicardoPerez> pitti: bug #207677, I still can't see the "System policy prevents modifying the configuration" message translated when I click on any Unlock button.
[10:17] <pitti> RicardoPerez: I got your bug mail from that, will follow up soon
[10:17] <RicardoPerez> pitti: Thanks very much! I stay tuned
[10:18] <RicardoPerez> see you all, thanks again, and bye!
[10:29] <directhex> time to do-release-upgrade
[10:30] <directhex> for the 7th time since it was installed with hoary
[10:56] <directhex> i DO with jaunty upgrades didn't sever network connectivity early on in the package installation
[10:57] <directhex> wish
[11:13] <cjwatson> ebroder: you have apt-listchanges installed, and configured to behave that way
[11:16] <pitti> http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html
[11:16] <pitti> I broke the 200 mark!
[11:19] <cjwatson> damn you
[11:19] <directhex> i have 10. 10 is loads!
[11:19] <cjwatson> we're 21 short of intrepid
[11:20]  * pitti throws the gauntlet to cjwatson
[11:21] <pitti> cjwatson: still weird, I had expected that we'd fix much more in jaunty :(
[11:21] <pitti> cjwatson: intrepid, is that including SRUs?
[11:21] <pitti> the kernel SRUs alone probably account for something like 70 bug reports
[11:21] <cjwatson> I'm not sure but I guess so
[11:21] <cjwatson> much more> yes :(
[11:21] <cjwatson> we still have a couple of weeks
[11:27] <pitti> bryce: I just updated 339091 with some new investigations, and linked to a kernel bug; is it even possible that the kernel DRM regression in 2.6.29rc6 is responsible for this? IOW, did we pull the DRM bits from head into our kernel?
[11:29] <tjaalton> pitti: it's possible
[11:30] <pitti> tjaalton: ah, thanks; I updated the kernel, fd.o, and LP bug with my findings
[11:31] <tjaalton> pitti: there were a few commits that were pulled from upstream, but they didn't solve vblank so it was disabled again in the DRI driver (mesa)
[11:31] <tjaalton> but the kernel commits remained
[11:31] <pitti> tjaalton: you mean the "trying to get vblank count for disabled pipe 1"? or the "Unknown parameter 6" thingies?
[11:34] <tjaalton> pitti: I don't know if they are related
[11:36] <ogra> is anyone objecting if i add armel to the list of arches in desktop for openoffice
[11:36]  * ogra slaps forhead several times for that silly oversight
[11:36] <ogra> (and indeed i need to upload -meta)
[11:39] <tjaalton> pitti: hm, the patches are from the intel stable patchset for the kernel, so removing them now might cause other problems
[11:39] <pitti> tjaalton: oh, I'm not suggesting we should ditch them; perhaps upstream can fix them
[11:39] <tjaalton> pitti: but you could try mesa 7.4 from my ppa, it seems to solve at least some of my problems
[11:39] <tjaalton> pitti: yeah, that should be the right approach :)
[11:39] <pitti> tjaalton: oh, sure
[11:40] <tjaalton> and we didn't pull any patches that weren't either in .29 or drm-next
[11:40] <pitti> tjaalton: I know, but someone else confirmed that the regression happened between 2.6.29rc5 and rc6
[11:40] <pitti> in fact, it was the original reporter of http://bugzilla.kernel.org/show_bug.cgi?id=12778
[11:40] <tjaalton> I did propose a couple of patches related to vblank, but decided to disable it instead, since upstream couldn't decide how to fix it properly
[11:41] <tjaalton> yeah I saw that
[11:41] <tjaalton> maybe reassign it to jbarnes?
[11:42] <pitti> I don't think I'm eligible to assign bugs in bz.kernel.org..
[11:42] <tjaalton> hmm ok
[11:42] <tjaalton> but try the new mesa first
[11:43] <pitti> trying your mesa now
[11:43] <tjaalton> thanks
[11:43] <pitti> thanks to you
[11:46] <cjwatson> ogra: no objection here
[11:47] <ogra> ok, already running ./update :)
[12:25] <firefly2442> I'm looking for an online gettext translation system.  The Launchpad Rosetta project looks great but isn't Launchpad still closed source?  Are there any plans to spin Rosetta off into a separate standalone application?  Thanks.
[12:25] <dholbach> firefly2442: try asking in #launchpad - launchpad including rosetta will be open-source in July (I think)
[12:33] <firefly2442> yep, by July - https://dev.launchpad.net/OpenSourcing
[12:35] <mdz> lool,ogra: with the latest jaunty UNR, I'm seeing gnome-do pop up unexpectedly on login.  this wasn't happening before.  are you already aware of it?
[12:42] <ogra> mdz, i personally wasnt (StevenK cares for UNR)
[12:44] <StevenK> mdz: Oh. I seeded it, but it popping up on login is unintended
[12:45] <ogra> StevenK, does it actually need to be installed ? sounds like something that could go into ship
[12:45] <StevenK> ogra: I'd like it seeded ...
[12:46] <StevenK> Which is why it was, actually.
[12:46] <ogra> ah
[12:49] <cjwatson> TheMuso: does Ara's latest comment in bug 301755 represent a new bug, or a recurrence of the same bug?
[12:53] <lool> mdz: never seen that
[12:53] <StevenK> lool: I seeded gnome-do early my afternoon
[12:54] <lool> StevenK: Shall we defer its addition to karmic?
[12:54] <lool> StevenK: or is this something the upstream UNR folks care a lot about?
[12:56] <StevenK> lool: It's something *I* care about
[12:57] <directhex> Do?
[12:58] <StevenK> directhex: Do is Good
[12:58] <directhex> StevenK, what have you seeded it onto?
[12:59] <StevenK> directhex: ubuntu-netbook-remix
[12:59] <directhex> oh, coolness!
[13:00] <directhex> so how long before dell are shipping netbooks with Do by default? :p
[13:19] <directhex> does the ubuntu buildd support packages in piped build-deps?
[13:19] <directhex> i.e. does "debianfoo | ubuntufoo" work, or does it have that dreadful debian "ignore everything after the pipe" issue
[13:23] <cjwatson> we use the first alternative that's installable
[13:25] <directhex> okay, good. and i'm not misremembering that debian uses only the first alternative, am i?
[13:28] <cjwatson> directhex: I believe that's still correct, and it certainly used to be the case
[13:28] <directhex> okay, cool, i can use that to work around a marginally borked transition and still allow syncing
[13:30] <directhex> cjwatson, oh, who's on the desktop team & organising things for UDS?
[13:31] <cjwatson> directhex: my guess would be rickspencer3 (when online)
[13:31] <cjwatson> directhex: or ask pitti
[13:34] <mpt> asac, was it you who mentioned that most of the bugs reported against gnome-power-manager are actually kernel problems?
[13:35] <asac> mpt: i dont think so
[13:35] <asac> i probably said that about networkmanager bugs ;)
[13:35] <mpt> ah, maybe :-)
[13:36] <mpt> Well, it looks like a similar thing is happening with notify-osd
[13:36] <asac> mpt: bugs due to graphics driver issues`
[13:36] <asac> ?
[13:36] <asac> about metacity + compositing? or compiz?
[13:37] <mpt> No, but now that people are paying attention to the notification bubbles, they're reporting bugs about silly bubbles, and those bugs are actually in gnome-mount or pidgin-libnotify or network-manager or something else
[13:37] <seb128> mpt: yeah there is lot of component in those cases
[13:38] <StevenK> asac: Oh! I had a silly question why the NM icon for UNR Jaunty is the blue bars, where as Jaunty -desktop uses green curvyness?
[13:38] <asac> StevenK: green curvyness? do you use a green monitor ;)?
[13:38] <asac> StevenK: seriously. i guess you use a custom theme in jaunty?
[13:39] <StevenK> asac: Oh, the NM icon is dictated by the icon theme?
[13:39] <asac> StevenK: they honur icon themes, yes. most don't overload the signal strength one, but you can just do it
[13:40] <StevenK> asac: The green one I've seen is shiny, but the default one is pretty good too
[13:41] <asac> StevenK: can you give me a screenshot of the green?
[13:41] <asac> i always want to see new ideas
[13:42] <StevenK> asac: I'll get one, the laptop is friends and is packed up
[13:42] <StevenK> a friends, sigh
[13:42] <asac> StevenK: ok. thanks!
[13:48] <jtholmes> are there any strong efforts to move to  cdebconf?
[13:49] <cjwatson> jtholmes: back-burner but not strong. Why?
[13:49] <mdz> StevenK: it's reproducible 2/2 attempts here
[13:49] <StevenK> mdz: Yup. I need to figure out how to silence it.
[13:49] <mdz> StevenK: is there an urgent need to add a new app to the default install three weeks before release?
[13:50] <jtholmes> cjwatson, just wondered as i was poking around in debconf and found out about cdebconf
[13:50] <StevenK> mdz: It's a nice to have only
[13:51] <cjwatson> jtholmes: both of them are reasonably actively maintained in different ways. There's a long-term goal to switch to cdebconf but it's unlikely to be especially soon.
[13:51] <jtholmes> cjwatson, yes too much cross dependency in the whole debconf area
[13:52] <jtholmes> to move soon
[13:54] <cjwatson> jtholmes: not really, almost all the dependencies have been fixed
[13:54] <jtholmes> cjwatson, i know you are one of the main players in ubuntu wonder if you could look at bug 352348 and give me an idea where in debconf the problem is and i will attempt to fix it
[13:54] <cjwatson> jtholmes: the blocking issues are missing features in cdebconf itself
[13:55] <cjwatson> jtholmes: nowhere in debconf at all
[13:55] <jtholmes> then where
[13:55] <cjwatson> jtholmes: ubiquity
[13:56] <jtholmes> yes but doesnt the button text come from debconf template file?
[13:56] <jtholmes> in qbiquity
[13:56] <cjwatson> sure, but that's like asking where in the C compiler is the bug in a C program :-)
[13:57] <jtholmes> ok i will poke around in the installer some more and see if i can locate the issue
[13:57] <cjwatson> no need really, it's a typo
[13:57] <cjwatson> that was supposed to be ubiquity/imported/yes rather than ubiquity/text/yes
[13:58] <cjwatson> jtholmes: fixed in my tree, thanks for the heads-up
[13:59] <jtholmes> cjwatson, where did you fix it what file?
[13:59] <jtholmes> file name
[13:59] <cjwatson> ubiquity/components/usersetup.py
[14:00] <jtholmes> thanks need to know more about installer
[14:00] <james_w> StevenK: /apps/gnome-do/preferences/core-preferences/QuietStart or -q in the autostart .desktop file should do it
[14:01]  * lamont is reminded yet again part of why he hates {c,}dbs.
[14:02] <lamont> wtf is the 'unpack and patch the source' target again?
[14:02]  * lamont goes grepping
[14:02] <cjwatson> jtholmes: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3152
[14:02] <cjwatson> lamont: cdbs or dbs. which?
[14:02] <lamont> cjwatson: well, actually looking at two packages, they use one each
[14:02] <jtholmes> cjwatson, thanks
[14:02] <lamont> though for my use, debian/rules build + ctl-C does the trick
[14:03] <cjwatson> lamont: policy nowadays recommends 'debian/rules patch' so try that first (and also recommends debian/README.source). Older packages may not implement that yet
[14:03] <lamont> yeah - patch is no such target in both coreutils and libnss-ldap
[14:05] <sistpoty|work> lamont: cdbs should be apply-patches (I guess at least)
[14:05] <lamont> sistpoty|work: yep
[14:05] <lamont> ta
[14:05] <sistpoty|work> np ;)
[14:06] <cjwatson> somebody should fix cdbs to comply with policy
[14:07] <cjwatson> actually, simple-patchsys already does
[14:07] <cjwatson> simple-patchsys.mk:patch: apply-patches
[14:07] <sistpoty|work> heh, just saw this as well
[14:08] <cjwatson> as do dpatch.mk and patchsys-quilt.mk
[14:08] <cjwatson> tarball.mk doesn't. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485069
[14:23] <nxvl> tjaalton: which bug?
[14:24] <tjaalton> nxvl: debian bug 518962
[14:24] <tjaalton> nxvl: removing it was wrong
[14:25] <nxvl> tjaalton: no it wasn't
[14:25] <tjaalton> nxvl: please explain
[14:25] <tjaalton> aterm never shipped /usr/bin/aterm
[14:25] <tjaalton> but aterm-xterm
[14:27] <nxvl> tjaalton: there is still a call to update-alternatives, there was just one that was wrong
[14:27] <tjaalton> nxvl: no, /usr/bin/aterm was correctly handled by aterm or aterm-ml
[14:27] <nxvl> tjaalton: and it was breaking the debian policy
[14:27] <tjaalton> how so?
[14:28] <nxvl> tjaalton: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509667#10
[14:31] <tjaalton> not relevant, since aterm (or any other package for that matter) doesn't ship a binary called /usr/bin/aterm
[14:31] <tjaalton> that u-a was just mistakenly copied from aterm
[14:31] <tjaalton> and makes no sense in terminator AIUI, but there was no reason to remove it from aterm
[14:32] <hyperair> pitti: i got a whole bunch of emails from rosetta regarding messed up .po files from nautilus-share. what should i do about it?
[14:32] <hyperair> We were unable to import your translations because you did not update
[14:32] <hyperair> the time stamp in its header to state when you added your translations.
[14:33] <cjwatson> hyperair: nothing, it's an LP bug
[14:33] <hyperair> ah i see
[14:39] <tjaalton> nxvl: so, the change should be reverted
[14:39] <nxvl> tjaalton: feel free to do so
[14:39] <freinhard> hi!
[14:40] <freinhard> is someone working on language-suppport-translations-* round?
[14:41] <tjaalton> nxvl: ok, although I can't fix it in debian
[14:41] <cjwatson> freinhard: ArneGoetje
[14:41] <nxvl> tjaalton: me neither, i'm not a DD
[14:41] <tjaalton> nxvl: and the package is orphaned ;)
[14:42] <nxvl> yup
[14:42] <freinhard> ArneGoetje: just did a update on kubuntu and wondered why i got some new gnome dependencies: does gnome-user-guide-* need to be in language-support-translations?
[14:43] <ArneGoetje> freinhard: which language?
[14:43] <rgreening> ArneGoetje: all
[14:43] <rgreening> -en, -de, ...
[14:43] <ArneGoetje> that should be a mistake
[14:43] <freinhard> ArneGoetje: germa
[14:43] <rgreening> yay
[14:44] <cjwatson> ArneGoetje: hmm. how else are we going to get the appropriate version of the GNOME user guide installed?
[14:44] <ArneGoetje> let me take a look
[14:44] <rgreening> ArneGoetje: looks like "Ubuntu automatic language-pack builder" added it
[14:44] <cjwatson> except perhaps by adding it to language-pack-gnome-foo, but I don't think that's appropriate
[14:44] <cjwatson> we don't have gnome and kde variants of language-support-*
[14:44] <ArneGoetje> cjwatson: well, the gnome-user-guide should definetely not go to kubuntu, don't you think?
[14:44] <rgreening> thanks freinhard for pointing this out.
[14:45] <freinhard> rgreening, ArneGoetje at least the ChangeLog states that the lang-pack builder is the bad guy
[14:45] <rgreening> exactly. Should be "|" with something to make it not a requirement.
[14:45] <cjwatson> ArneGoetje: sure, but that doesn't help to make sure that Ubuntu carries on working properly too
[14:45] <cjwatson> certainly gnome-user-guide-* could have |-deps on language-support-translations-foo
[14:45] <cjwatson> that's a hack but we've used the same hack elsewhere
[14:46] <cjwatson> slangasek: could you look at bug 352034?
[14:46] <rgreening> the issue here is that adding this as is, will impact the CD/DVD size for Kubuntu and other non-gnome desktops
[14:46] <rgreening> we are already having to lzma compress parts of KDE to fit.
[14:47] <cjwatson> rgreening: we understand the issue
[14:47] <rgreening> cool :P
[14:47] <cjwatson> hmm, the |-deps won't help here since the package is big in itself
[14:47] <cjwatson> the problem is that right now we have no particularly good mechanism for this
[14:47] <cjwatson> getting into a situation where we are trading off CD space between Ubuntu and Kubuntu is not really going to help anyone :-)
[14:48] <rgreening> cjwatson: the other issue is gnome user guide en provides no benefit to non gnome desktops and is a waste or resources
[14:49] <cjwatson> rgreening: you can stop beating the dead horse :-)
[14:49] <rgreening> It's not dead jim...
[14:49] <rgreening> :)
[14:49] <cjwatson> actually, gnome-user-guide-en is very small in itself
[14:49] <cjwatson> Size: 42874
[14:50] <ArneGoetje> cjwatson: is the gnome-user-guide a requirement on the desktop, or optional (suggests)?
[14:50] <rgreening> but it has additional deps
[14:50] <cjwatson> rgreening: yes I understand that
[14:50] <cjwatson> that's why I said "in itself"
[14:50] <rgreening> ah. k. got it. I'll just lurk :P
[14:51] <cjwatson> ArneGoetje: it's a recommendation (i.e. removable), but it does need to be present in Ubuntu installations
[14:51] <cjwatson> the language split was to save space on Ubuntu CDs by allowing us to control which translations are present
[14:52] <ArneGoetje> cjwatson: can we add a suggests to language-pack-gnome-foo for this?
[14:52] <cjwatson> ArneGoetje: to what end? the installer will ignore that
[14:52] <cjwatson> ArneGoetje,slangasek: what do you think about moving the gnome-user-guide-LL dependency from language-support-translations-LL to language-pack-gnome-LL?
[14:52] <ArneGoetje> cjwatson: and recommends?
[14:53] <cjwatson> ArneGoetje: recommends would be fine I think, but why bother, it might as well be depends
[14:53] <cjwatson> oh, recommends would make it removable
[14:53] <ArneGoetje> cjwatson: if it should be removable?
[14:53] <cjwatson> I think it's fine in language-pack-gnome-LL on the grounds that it was previously part of the desktop anyway
[14:53] <cjwatson> so yes, I think that's probably the right answer here
[14:54] <rgreening> awesome
[14:54] <cjwatson> it's suboptimal because really that stuff ought to be in language-support-*
[14:54] <rgreening> you guys rock
[14:54] <cjwatson> but we can't make that flavour-specific
[14:54] <cjwatson> so this might bloat up the Ubuntu CD a bit again
[14:54] <cjwatson> I'm not sure how much
[14:54] <ArneGoetje> cjwatson: does it need to be on the CD?
[14:55] <cjwatson> ArneGoetje: the only way to make it not on the CD is to put it in language-support-*
[14:56] <cjwatson> actually, it is false that this will have a significant effect on CD size for Kubuntu
[14:56] <cjwatson> the only language-support-* that's on the Kubuntu CD is language-support-en
[14:56] <cjwatson> so that's only 1.5MB or so
[14:56] <ArneGoetje> cjwatson: how does the language-pack-gnome-LL package get pulled by the installer? I know we have some code in language-selector to pull those depending on the flavor, because we don't have depends.
[14:56] <cjwatson> oh, hang on, gnome-user-guide pulls in scrollkeeper and yelp. bah
[14:57] <cjwatson> ArneGoetje: language-pack-gnome-LL is selected per-flavour by preseeding, yes. There is no such mechanism for language-support-LL.
[14:57] <freinhard> cjwatson: jupp, that's why i got concerned
[14:58] <ArneGoetje> cjwatson: can we just add the gnome-user-guide-LL to that?
[14:58] <cjwatson> ArneGoetje: isn't that what we were both suggesting above? :-)
[14:58] <ArneGoetje> cjwatson: ah, you were talking about the pre-seeding... I though a recommends to the package...
[14:58] <cjwatson> so the other approach would be to make the gnome-user-guide-LL packages depend on gnome-user-guide | language-support-translations-LL; that would still mean that Kubuntu users would get gnome-user-guide-LL (i.e. just the translations) installed if they ran the language selector post-installation, but they wouldn't get gnome-user-guide, scrollkeeper, yelp, etc.
[14:58] <cjwatson> ArneGoetje: we were both talking about a recommends
[14:59] <freinhard> all in all, should add ~30MB
[14:59] <cjwatson> ArneGoetje: you asked how the installer selected language-pack-gnome-LL, and that's done by preseeding. This is orthogonal
[14:59] <ArneGoetje> cjwatson: I was actually thinking to hack lp-o-matic to add the recommends to the l-p-gnome-LL package...
[14:59] <cjwatson> ArneGoetje: yes, that's exactly what I was suggesting too ...
[15:00]  * cjwatson feels there is not a little bit of confusion here
[15:00] <cjwatson> freinhard: with |-deps on language-support-translations-LL, it would be a megabyte or so at most, actually. I agree that the current situation is a problem
[15:01] <cjwatson> but, since we were already including gnome-user-guide in the stock Ubuntu desktop, I think a recommends from language-pack-gnome-LL is fine in this particular instance
[15:01] <cjwatson> we may need to revisit that in the future
[15:01] <ArneGoetje> cjwatson: ok, never mind. :)
[15:01] <cjwatson> I sort of feel we ought to use special fields in the Packages file for all of this, rather than having a zillion metapackages
[15:02] <ArneGoetje> cjwatson: +1
[15:02] <cjwatson> Package: gnome-user-guide-fr Language: fr/translations/gnome, or something better-designed
[15:04] <cjwatson> ArneGoetje: but yeah, in the meantime, can you make that langpack-o-matic adjustment to move gnome-user-guide-LL from l-s-t-* to l-p-gnome-*?
[15:06] <ArneGoetje> cjwatson: yes, I will ask pitti about that.
[15:07] <tkamppeter> pitti, I have problems with bug 348316 and its duplicates. Seems that the USB stack of the current kernel has lost compatibility with the CUPS USB backend.
[15:08] <\sh> guys, what was the magic for cdbs to tell cdbs "please add DEB_CONFIGURE_EXTRA_FLAGS=..." only when on arch != i386?
[15:09] <tkamppeter> pitti, seems that half of the users get their printers detected but print jobs put the USB backend into an infinite loop (jobs never reach "Stopped" state or disappear).
[15:09] <cody-somerville> \sh, you could conditionally declare DEB_CONFIGURE_EXTRA_FLAGS, no?
[15:09] <\sh> cody-somerville: you mean standard make ifdef?
[15:10] <\sh> yes..the easy way ,-)
[15:10] <cody-somerville> ;)
[15:13] <\sh> fixing google-perftools
[15:14] <cjwatson> slangasek: (never mind, I gave Mario a suggested workaround which I think should work)
[15:25] <pitti> hyperair: I usually ignore them
[15:26] <pitti> tkamppeter: hm, weird; I just upgraded my wife's computer to current jaunty, maybe I can reproduce it there
[15:32] <metellius> what are the chances that someone important actually decides the current 2.6.x intel drivers are too unstable and actually pull in 2.7 for a stable and smooth desktop, in time for jaunty?
[15:33] <jdong> I'm no X developer, but looking at the release schedule, zero?
[15:35] <\sh> pitti: any clue on http://launchpadlibrarian.net/24382167/buildlog_ubuntu-jaunty-amd64.im-sdk_12.3.91-6.3ubuntu1_FAILEDTOBUILD.txt.gz ? telling dh_strip to not build ddeb packages?
[15:35] <hyperair> pitti: heh. alright then =p
[15:35] <seb128> metellius: because 2.7 is the magical solution to all bugs? ;-)
[15:36] <seb128> metellius: new version usually bring fixes and other issues and required testing it's not that easy
[15:42] <hyperair> there's a 2.7?
[15:42] <hyperair> does it fix all the performance regressions?
[15:43] <pitti> tkamppeter: ah, saw your mail; did you try the new usb backend from 1.4?
[15:49] <metellius> hyperair: there's an RC, and it stabilized uxa completely for me
[15:49] <hyperair> metellius: really? cool!
[15:49] <hyperair> metellius: you compiled?
[15:49] <metellius> nope, got it from xorg-edgers
[15:49] <hyperair> aah i see
[15:49] <hyperair> cool
[15:49] <hyperair> i should try it out
[15:50] <metellius> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ jaun#ty main restricted universe multiverse
[15:50] <hyperair> yes yes i know
[15:50] <hyperair> s/#//
[15:50] <metellius> indeed
[15:50] <hyperair> mmhmm
[15:50] <hyperair> but i don't have a live system at the moment
[15:50] <hyperair> my cdrw's gone
[15:50] <hyperair> won't get detected
[15:50] <metellius> i'm so happy right now
[15:50] <metellius> it all just works
[15:50] <hyperair> hahah
[15:51] <hyperair> i'm more interested in knowing whether it fixes performance regressions
[15:51] <hyperair> UXA didn't really fix the regressions for me
[15:51] <hyperair> with 2.6
[15:51] <hyperair> i was getting framerates around 20FPS (intrepid gets 60FPS) for a game
[15:52] <hyperair> it's playable, but everything moves so slowly
[15:54] <metellius> I don't dare start up a game right now, I need to enjoy the smooth desktop before I let a possible crash bring down the ride
[15:55] <pitti> tkamppeter: yes, happens for my samsung as well on jaunty
[16:00] <pitti> tkamppeter: I'll take the bug and look into it ASAP
[16:06] <radix> cjwatson: ping, do you have a moment to follow up on the discussion last week about inheriting environment variables and file descriptors in landscape-client?
[16:06] <cjwatson> radix: sure
[16:06] <radix> (about debconf)
[16:06] <radix> cjwatson: okay, cool. so I've got it deleting DEBIAN_ and DEBCONF_ environment variables to avoid propagating those to further package installation processes, but I'm wondering about the file descriptor stuff you mentioned
[16:07] <radix> cjwatson: you said that debconf opens some file descriptors which might be propagating to the child processes of the postinst script
[16:07] <radix> (i think)
[16:08] <radix> cjwatson: but I'm wondering if that's true. do you know how that file descriptor is being opened? it looks  like bash makes sure most file descriptors are not passed on to child processes, but some -- for example those created with "exec 7< whatever.txt", do get propagated
[16:08] <cjwatson> /usr/share/debconf/confmodule opens fd 3 for communication from the "confmodule" (e.g. landscape-client.postinst) to the debconf frontend
[16:08] <cjwatson> it is created using 'exec 3>&1'
[16:08] <radix> oh, look at that :)
[16:09] <cjwatson> I'm pretty sure that it isn't close-on-exec; I don't think a number of things would work if it were
[16:09] <radix> hrmph. it's too bad that FD isn't cloexec.
[16:09] <radix> ah
[16:09] <cjwatson> yes, it is a bit inconvenient
[16:09] <cjwatson> but really, it's good practice for daemons to close stray file descriptors on startup
[16:09] <radix> yeah
[16:09] <radix> it's just that figuring out how to do that with our existing daemonization code is becoming a bit difficult to do in time for jaunty :)
[16:10] <cjwatson> frex, Stevens recommends it (APUE p.417)
[16:10] <radix> cjwatson: do you know if there's a bashism or perhaps some tiny C wrapper program that can do that for me?
[16:10] <abentley> superm1: I've just filed bug #352452, the fruit of a rather frustrating evening and morning.  If you have any questions, I'm happy to answer them.
[16:10] <radix> like, "run-without-fds ./program"?
[16:11] <cjwatson> radix: not in that form, but if it's just fd 3, then you could start landscape-client with 3>&-
[16:11] <radix> hmm
[16:11] <radix> yeah, that doesn't sound too scalable :)
[16:11] <cjwatson> it's not, but there may not actually be all that many fds involved
[16:11] <cjwatson> (don't use exec here, btw, just put that redirection on the line where landscape-client is invoked
[16:11] <cjwatson> )
[16:12] <radix> right
[16:12] <radix> well, I'll consider that. I'll also give another bash at implement proper FD closing in landscape-client
[16:12] <cjwatson> in principle, it's possible for somebody to use cdebconf, which opens a different set of fds
[16:12] <cjwatson> but not really in practice right now
[16:13] <radix> cjwatson: okay, I've learned what I wanted to know. Thanks very much for your help!
[16:13] <cjwatson> you could look at /proc/$(pidof landscape-client)/fd to see whether which stray fds it has open
[16:14] <radix> it'd be nice if I could determine whether a FD was inherited or opened in the current process, but I guess that's impossible
[16:14] <pitti> tjaalton: FYI, with your mesa I also got a hang a bit after resuming, it just completely messes up screen
[16:15] <radix> the landscape-client startup code is a bit poorly factored; it opens some important FDs *before* daemonizing, apparently
[16:16] <superm1> abentley, there isn't any easy way to fix that since AMD provides replacement dri and glx libraries
[16:17] <abentley> superm1: Does disabling fglrx in "Hardware Drivers" remove those packages?
[16:17] <tjaalton> pitti: go intel..
[16:17] <cjwatson> radix: you could probably close inherited fds before that, and before daemonising
[16:18] <cjwatson> radix: after all you've already forked once
[16:18] <cjwatson> it's not perfect but it would do for this purpose, wouldn't it?
[16:18] <radix> hmm, probably
[16:18] <radix> the main problem we have is that we try to report certain errors synchronously, I think
[16:18] <cjwatson> radix: doesn't help with the "where do stdin/out/err go?" problem of course, but perhaps you already deal with that in some other way
[16:19] <radix> so there's a significant amount of code that happens before daemonization
[16:29] <abentley> superm1: My strong impression was that it does not, and I would never have hit up the X logs and apt if just disabling fglrx in "Hardware Drivers" (jockey?) had worked.
[16:36] <lool> Is there some niver way than "`eval echo \\\$$c`" to get the value of a var named c in shell?
[16:36] <lool> Sorry, of a var named $c
[16:38] <\sh> holiday time...cu later :)
[16:38] <pitti> tkamppeter: argh no, seems I have a completely different bug
[16:38] <sistpoty|work> lool: as in... just $c?
[16:39] <lool> sistpoty|work: No, rather ${$c} but that doesn't work
[16:39] <cjwatson> lool: ${!c} but that's a bashism
[16:39] <cjwatson> there's no nicer portable way
[16:39] <lool> so eval ... hmm
[16:39] <lool> cjwatson: thanks
[16:41] <cjwatson> well, you can cut down on the backslashes
[16:41] <cjwatson> "$(eval echo "\$$c")"
[16:42] <lool> Right
[16:42] <lool> I was at eval echo "\$`echo $c`"
[16:42] <lool> which was just an useless use of `echo ` :)
[16:45]  * Keybuk has a *weird* Python issue
[16:45] <Keybuk> after upgrading from intrepid -> jaunty, nothing pythonic works until I dpkg-reconfigure it
[16:46] <jdong> is that related to that python bug in the topic? </stupid wrong suggestion>
[16:46] <Keybuk> I don't think so
[16:47] <superm1> pitti, does disable fglrx in hardware drivers remove xorg-driver-fglrx and friends?
[16:47] <superm1> or is it 'supposed to'?  i think to abentley's point above it should
[16:48] <pitti> superm1: yes, it's supposed to
[16:48] <superm1> abentley, well was that on intrepid or jaunty?  pitti when did it start doing it?
[16:48] <pitti> superm1: it never did *not* do it
[16:49] <pitti> superm1: what's the "& friends" part about?
[16:49] <pitti> superm1: removing the driver will only remove xorg-driver-fglrx
[16:49] <pitti> oh, and fglrx-kernel-source
[16:49] <pitti> should it kill something else, too?
[16:50] <superm1> no, i think that's sufficient.  i'm just a bit perplexed how abentley hit this then if he tried to disable it in hardware drivers
[16:50] <james_w> Keybuk: I've been seeing parts of that. "pycentral pkginstall foo" is the critical missing bit it seems
[16:50] <Keybuk> james_w: it's missing from every single package then
[16:50] <james_w> not for me
[16:50] <Keybuk> because I can replicate it by picking on just about everything
[16:50] <Keybuk> >>> import fstab
[16:50] <Keybuk> Traceback (most recent call last):
[16:50] <Keybuk>   File "<stdin>", line 1, in <module>
[16:50] <Keybuk> ImportError: No module named fstab
[16:51] <james_w> python-zopeinterface and python-twisted-core on two machines for me
[16:54] <Keybuk> cjwatson: any thoughts?
[16:56] <mvo> Keybuk: that sounds like something for doko
[16:56] <mvo> Keybuk: but if you mail the logs to me /var/log/dist-upgrade/* I can have a look
[16:56] <Keybuk> mvo: I didn't use the dist-upgrader
[16:57] <mvo> Keybuk: apt-get dist-upgrade? it should have /var/log/apt/term.log
[16:57] <mvo> but then our python tools tend to not write out a lot of useful output :/
[16:58] <Keybuk> mvo: yeah, can't see *anything* in that
[16:58] <tkamppeter> pitti, I did not try the new backend yet. Could you try it?
[16:58] <Keybuk> interestingly, none of the apparently affected packages were upgraded in the dist-upgrade
[16:58] <pitti> tkamppeter: as I said, I can't reproduce it, but I can test it, of course
[16:58] <pitti> tkamppeter: that's the one from 1.4?
[16:58] <Keybuk> oh, no, python-tz and python-openid both were - and they're both broken now
[17:00] <Keybuk> mvo: the dist-upgrader sadly never seems to work on my desktop
[17:00] <Keybuk> I install too many bits from PPAs, and by-hand backports from jaunty, and stuff :p
[17:00] <mvo> Keybuk: in what way does it not work?
[17:00] <mvo> Keybuk: oh, ok
[17:00] <Keybuk> mvo: this time it wanted to uninstall just about every package included ubuntu-minimal <g>
[17:01] <mvo> Keybuk: *urgh* if you still have the logs of that (in /var/log/dist-upgrade/) then please mail it to me, it should not do that
[17:01] <Keybuk> mvo: looking at why, it's perfectly reasonable that it wanted to do that
[17:01] <Keybuk> I had a custom one installed that conflicted a few things :p
[17:01]  * Keybuk has later version of upstart on here, which has different packages
[17:03] <Stskeeps> ~
[17:03] <Stskeeps> (ignore)
[17:05] <cjwatson> Keybuk: did the new python package get configured?
[17:06] <cjwatson> Keybuk: I think that currently it calls the rtupdate hooks, which are what are supposed to symlink modules around for the new version
[17:15] <Ng> is there any particular disadvantage in defaulting to having lots of loop devices available? we seem to default to 8, the maximum the loop module will create is 256
[17:16] <njpatel> (asking here in case it's a ubuntu thing) my compiz-enabled desktop switches workspaces whenever I scroll on an empty part of a gtkwindow i.e. the status area of the nautilus window
[17:16] <njpatel> i can't remember this being the case in intrepid, and it's really annoying
[17:17] <davidm> pitti, I ran the killall gnome-settings-daemon and got 3 I could not kill should I still try running the extra command??
[17:18] <cjwatson> Ng: does making lots of them available cause all the device nodes to be created at boot?
[17:18] <cjwatson> Ng: in any case I thought that nowadays new device nodes got autocreated somehow (I forget how)
[17:19] <Ng> cjwatson: if I reload the module with max_loop=256 I immediately get 256 /dev/loopN devices
[17:20] <Ng> I was just playing with something that uses a lot of loops and it complained that it couldn't get any more, but I'm doing horrible kernel mismatching (jaunty userspace, hardy kernel), so maybe that is preventing any automagic creation
[17:23] <Ng> cjwatson: hrm, even with jaunty at both ends of the chain I don't see loop auto-creation (tested with for i in $(seq 1 10) ; do mkdir /tmp/lala$i ; sudo mount -o loop ubuntu-9.04-beta-desktop-i386.iso /tmp/lala$i ; done)
[17:24] <davidm> pitti, bug updated
[17:25] <pitti> davidm: yes, please; do you have so many other running user sessions?
[17:25] <pitti> davidm: thanks
[17:26] <davidm> pitti, I have my user logged on "davidm" and guest and I ran the bit's in guest.  Though I'm happy to log out of guest and only work in the "davidm" instance.
[17:27] <cjwatson> Ng: problem with max_loop=256 then is that it will have a noticeable effect on boot time. We saw this with tty devices too
[17:27] <cjwatson> Ng: I forget how device creation is supposed to happen, I thought losetup did it
[17:28] <pitti> davidm: if you do "ps ux|grep gnome-settings", do you have a running daemon?
[17:28] <pitti> davidm: either you have one which is unkillable, or you have none, and there's a d-bus problem
[17:29] <pitti> davidm: I have a meeting in 2, so I'll continue the Q&A tomorrow
[17:29] <davidm> I have 4
[17:29] <seb128> pitti: what is the issue?
[17:29] <davidm> See screenshot attached to bug
[17:29] <pitti> seb128: bug 352362
[17:30] <pitti> davidm: all running as you?
[17:30] <cjwatson> Ng: at any rate, if you create the device nodes manually, it should work
[17:30] <davidm> yes
[17:31] <davidm> all as davidm according to ps ux
[17:31] <davidm> I can attach another screenshot if you like
[17:32] <Ng> cjwatson: ok
[17:32] <Keybuk> cjwatson: dpkg --configure -a does nothing
[17:32] <davidm> pitti,  Now have 3
[17:32] <davidm> Attaching a screen shot from davidm
[17:33] <pitti> davidm: screenshot> ps ux output should do
[17:34] <davidm> pitti, attached to bug now
[17:38] <pitti> davidm: will you be in SF next week, @LF summit?
[17:39] <abentley> superm1: I think at that point dpkg hadn't completed.  I was dumb enough to run the installer in a vnc server.
[17:40] <superm1> abentley, okay well then for the common case - that someone removes it from jockey it does the right thing
[17:40] <davidm> pitti, Yes I will be arriving on Sunday night
[17:41] <davidm> I'll be at celf and LF summit
[17:41] <abentley> superm1: No, I couldn't get to jockey initially.  Only after I'd apt-get-remove-purged the video driver could I even try jockey.
[17:41] <pitti> davidm: rock, I'll see you there; if I don't figure it out tomorrow, I can hack on your machine as a last resort?
[17:41] <davidm> I can carry my HD and laptop so you can indeed hack.
[17:41] <abentley> superm1: Sorry to change my story.  It was late...
[17:42] <davidm> I'm going to go out a buy a new HD so I can get working on my presentation for CELF that I have to present.
[17:42] <pitti> ArneGoetje: you have an 855?
[17:42] <pitti> bryce: ^
[17:42] <pitti> ArneGoetje: I read in the bug report that uxa and some other xorg.conf option would make it work
[17:42] <superm1> abentley, okay well still things are working as expected currently then.  I don't believe there is any way to make the experience better since AMD is requiring their own libdri and libglx
[17:43] <ArneGoetje> pitti: I do
[17:43] <ArneGoetje> pitti: and I'm running uxa
[17:43] <pitti> davidm: urgh, 3 g-s-d's is certainly wrong
[17:44] <abentley> superm1: Well, there are heroic measures-- if fglrx is installed, remove it on upgrade, try reinstalling it, and if it doesn't work fall back to the OS drivers.
[17:45] <abentley> superm1: Even just removing it and telling the user they can try reinstalling it would be better, because bulletproof X would at least give them VESA.
[17:45] <davidm> Yes, I gather that, I have no idea how that happens, it's only from the upgrade, everything is working correctly from the liveCD beta, which is really confusing to me.
[17:46] <pitti> ArneGoetje: nice
[17:47] <pitti> bryce: ScottK said that i865 "just works", and if we could make the 855 use uxa, and disable dri on the 845, we'd at least have a non-breaking upgrade; is that possible?
[17:47] <ArneGoetje> pitti: no other config options set, just uxa.
[17:47] <bryce> pitti: one of the big problems I'm having trying to get 304871 closed is that the original reporter does not respond
[17:47] <pitti> bryce: well, if we have some other people with similar hw which can reproduce the bug and test the fix, that should be good enough?
[17:47] <bryce> so through the bug there have been multiple solutions proposed, some of which solve the issue for certain people, but not others.  The original reporter never responds, so we never know if one of them would solve his problem.
[17:48] <pitti> in that context, the original reporter is proably not "more" special than the other responders with the same chipset?
[17:48] <bryce> pitti: so the point we're at now is chasing the lowest common denominator, which is looking like "nuke them all from orbit and let God sort them out"
[17:48] <pitti> heh
[17:48] <bryce> i.e. disable all features on 8xx
[17:48] <pitti> bryce: with xx == {45,55}?
[17:49] <bryce> which obviously is a poor solution, and is going to generate all manner of regression reports later
[17:49] <pitti> or do you have reports about 865 failures as well?
[17:49] <bryce> 865 too
[17:49] <pitti> ugh
[17:49] <pablo__> is ppp_generic module missing in jaunty ? i googled about, and i got this http://archives.free.net.ph/message/20081226.221035.2367e95e.de.html
[17:49] <bryce> the problem is that given 3 people with 845, we get 3 completely different results
[17:50] <pablo__> i need it to use a kernel firmware to connect ppp
[17:50] <pitti> bryce: that's as diverse with 855 as well?
[17:50] <cjwatson> pablo__: it's built into the kernel - you don't need a module
[17:50] <bryce> pitti: apparently.
[17:52] <bryce> pitti: normally, if this wasn't a targeted bug, I'd close the bug as expired since we've not heard from the original reporter, and ask others to file new bugs.
[17:52] <pablo__> [cjwatson] i do not know very much, but i had a script that used that before. may be it was needed before
[17:52] <Ng> bryce: fwiw I didn't see that bug on a thinkpad X40 (855GM)
[17:52] <pablo__> well, im sure it was
[17:52] <cjwatson> pablo__: yes, it used to be
[17:52] <Ng> bryce: but afaics there is quite some variation between machines with seemingly identical intel graphics chips
[17:52] <pablo__> i realized when i got an error message
[17:52] <pablo__> [cjwatson] i try to know why my connection script does not work
[17:53] <pablo__> i can connect without some workarrounds
[17:53] <pitti> bryce: given how tangled it became, it's probably a good idea to split it up by hardware category anyway?
[17:53] <pablo__> i have a usb connection
[17:54] <bryce> Ng: yeah 855 seems in better shape; it's 845/865 where we have more reporters of this particular problem
[18:00] <allquixotic> Does anyone know if you need to sign up for the packaging training sessions or whether you can just join the channel at the right time?
[18:06] <hyperair> allquixotic: just join
[18:07] <hyperair> allquixotic: or read the logs
[18:11] <allquixotic> hyperair: Thanks :)
[18:11] <hyperair> allquixotic: np
[18:16] <bryce> pitti: okay.  The bug was opened against 845 originally, whereas all recent comments of "still problems" are from 865 users
[18:16] <bryce> pitti: there are also some 855 users who say the issue is fixed by use of the Legacy3D option (for which we have a patch)
[18:17] <bryce> pitti: so I think I'll put my patch in as the fix for 845, and split out the 865 and 855 issues to separate bugs.
[18:17] <bryce> then we can finally get this one closed
[18:27] <cjwatson> Caesar: what do you think of bug 74164?
[18:28] <cjwatson> Caesar: oh, hmm, that's Debian bug 407667, so it looks unintentional that this is missing
[18:29] <telexicon> whats up with this lintian warning whenever i build a package: debian-changelog-file-is-a-symlink ?
[18:31] <cjwatson> telexicon: ... well, apparently your debian/changelog file is a symlink :-)
[18:31] <cjwatson> it should be an ordinary file
[18:31] <telexicon> cjwatson, well yeah i got that part :p but i didnt make it a symlink
[18:31] <telexicon> its a multibinary from one source package and it symlinks the docs to the main dependency
[18:31] <cjwatson> run lintian-info and copy and paste the line from lintian's output into it
[18:31] <telexicon> CDBS does it automatically
[18:32] <Laney> yeah, that's an ubuntu CDBS change
[18:32] <Laney> for space-saving reasons - you can ignore it
[18:32] <cjwatson> oh, that. well, it isn't your bug directly so you can ignore it. I think perhaps we ought not to do that for the changelog file though
[18:32] <cjwatson> not sure
[18:33] <telexicon> what about, not symlinking copyright and changelog
[18:33] <telexicon> and then symlinking everything else
[18:33] <cjwatson> you could do that in your package
[18:33] <cjwatson> I'm not sure why cdbs doesn't do that, but cdbs does not stop you controlling the contents of your own package
[18:34] <telexicon> yeah thats true, id just have to go look all that up
[18:34] <cjwatson> actually, it would be better if cdbs symlinked the directories rather than the individual files, but IIRC there was some reason why that was problematic
[18:34] <telexicon> cjwatson, yeah thats even what lintian suggests
[18:58] <LordKow> i cant help but notice that http://brainstorm.ubuntu.com/idea/64/ pk ideas were set for jaunty but obviously are not happening.
[19:06] <telexicon> is the goal to have all the packages use cdbs?
[19:08] <Mithrandir> no
[19:13] <blueyed> pitti: virtualbox-ose for amd64 on Hardy is still in the NEW queue: https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=
[19:13] <jtholmes> cjwatson, i made the change to usersetup.py in my release and it worked fine thanks for the info BTW always to glad to help out
[19:14] <directhex> pitti, are you arranging desktop related things at UDS?
[19:36] <lool> cjwatson: Just a note that I'm pushing glibc_2.9-4ubuntu5.dsc which I've put up for review; it's the same as you reviewed earlier + a release commit
[19:36] <lool> cjwatson: NCommander and myself tested; it would first segfault for NCommander, but he had unrelated issues on the system, his reinstalled system would work, and it worked fine on my babbage
[20:16] <BUGabundo> anyone else working on bug 304871 ?
[20:19] <YokoZar> http://www.yelp.com/biz/ubuntu-restaurant-and-yoga-studio-napa
[20:20] <mvo> pitti: just fyi, I saw corrupted attachments for apport reported bugs for bug #352134 and #350866
[20:22] <BUGabundo> can any one tell me how to use DRI ?
[20:23] <cody-somerville> Folks in #ubuntu probably can :)
[20:25] <BUGabundo> cody-somerville: never mind! i re-read the bug and copied a xorg from there
[20:36] <slangasek> calc: what's the plan for OpenOffice.org on sparc?  Are you going to try lowering the optimization level as cjwatson suggested, or are we going to drop it?
[20:36] <slangasek> calc: if the first, that should happen very soon; if the latter, I'd prefer it happen soon anyway so I can get the stale deps off the component-mismatches report :)
[20:38] <slangasek> calc: ah, actually, the most recent OOo failure on sparc is just a plain old syntax error in the code, somehow...
[20:44] <calc> slangasek: hmm, looking
[20:46] <calc> slangasek: yea it was the previous upload that ICEd apparently, but the log is no longer available for it
[20:47] <slangasek> right - but now we have a syntax bug, surely that's easier to fix? :)
[20:47] <calc> probably once that is fixed it will just ICE again but i will look at it
[20:47] <calc> it pretty much NEVER builds on sparc regardless of what is done :\
[20:47] <calc> at one point i just had it disabled entirely on sparc but i apparently lost that on merge
[20:48] <calc> i will check it out for my next upload
[20:50] <slangasek> calc: ok, cool.  is the next upload scheduled?
[20:50] <calc> should be in a few days
[20:50] <calc> i'm waiting until at least the next LP rollout to fix an issue that caused the ppc build to fail
[20:51] <calc> aiui that is tomorrow
[20:51] <slangasek> ok
[20:53] <slangasek> pitti: bug #345531 needs some more attention from someone well-versed in hal
[20:53] <slangasek> (subscribed you)
[21:17] <cjwatson> jtholmes: cool, thanks
[21:17] <cjwatson> lool: thanks, pulled
[21:23] <awe> brianchidester: one more favor to ask..
[21:23] <brianchidester> awe:  go for it
[21:24] <awe> ( just realized i'm in the wrong room )...doh
[21:24] <brianchidester> awe: haha
[21:38] <jtholmes> cjwatson, sure i actually want to get a little more involved but have to learn where things r first
[21:43] <BUGabundo> seb128: bug 352681
[21:43] <BUGabundo> some guys on +1 just found out that files are not being shown on the trash applet
[21:44] <BUGabundo> for a sec i though they were being really deleted
[21:44] <BUGabundo> but no... they are on .local/share/Trash
[21:46] <seb128> BUGabundo: that's the directory the trash shows
[21:47] <jtholmes> cjwatson, i plan to join the QA meeting tomorrow, i really want to talk about a more structured regression testing environment so we can hopefully reduce bugs up front
[21:47] <BUGabundo> seb128: yes, but the trash applet, after clicked is Empty
[21:47] <BUGabundo> and even the applet is not updated with the Full icon
[21:47] <seb128> BUGabundo: what about the trash location in nautilus?
[21:47] <BUGabundo> it wont open
[21:48] <BUGabundo> when typed in nautilus trash:///
[21:48] <seb128> your installation is screwed
[21:48] <BUGabundo> liveusb
[21:48] <BUGabundo> from today
[21:48] <BUGabundo> and 2 days ago
[21:48] <BUGabundo> not my system
[21:48] <seb128> could be liveusb specific
[21:48] <BUGabundo> not me to 1st complain
[21:48] <seb128> obviously that works on a normal system
[21:48] <seb128> we would have noticed otherwise
[21:48] <BUGabundo> maco is now debuging with other users on +1
[21:48] <BUGabundo> maco: cn u confirm?
[21:48] <seb128> well it's easy, gvfsd-trash is a gvfs backend
[21:48] <seb128> gvfs-ls trash:
[21:48] <maco> huh?
[21:48] <maco> oh
[21:49] <maco> seb128: soemone with an installed system first reported it
[21:49] <BUGabundo> and i just tested on 2 dailys images
[21:49] <seb128> gvfs-ls trash:
[21:49] <seb128> run that
[21:49] <maco> BUGabundo's just the reproducer
[21:49] <seb128> what does it list
[21:50] <BUGabundo> nothing
[21:50] <BUGabundo> but theres a folder in /home/ubuntu/.local/share/Trash/files/ef
[21:53] <maco> mine is not empty, but my nautilus is also not at the latest version
[21:53] <maco> perhaps its the most recent nautilus update?
[21:53] <BUGabundo> i dont know
[21:53] <BUGabundo> seb128 will now that better
[21:54] <BUGabundo> my system is broken (wont reach gdm) so i cant test tehre
[21:54] <BUGabundo> just running liveusb to test some stuff and installing a new test machice
[21:54] <BUGabundo> well dinner time for me
[21:54] <BUGabundo> i'll look at it tomorrow
[21:57] <seb128> maco: iit's working fine on all my boxes and we got no bug until now
[21:59] <maco> seb128: im installing updates to see if the workingness of my system changes after updates
[22:02] <maco> seb128: empathy doesnt use the indicator applet yet, right?
[22:02] <seb128> no
[22:04] <johanbr> maco: https://bugs.launchpad.net/bugs/340180
[22:05] <maco> i'm trying to make a list of apps that dont have indicator applet support but should
[22:06] <seb128> all the IRC and IM clients ;-)
[22:06] <seb128> and email clients
[22:06] <seb128> only evolution and pidgin use it now
[22:06] <maco> er..shouldnt that bug be on "Empathy (Ubuntu)" not just "Empathy"?
[22:06] <maco> Ryan added it to Gwibber
[22:07] <seb128> depend if you wish that upstream add that feature or it to be added by ubuntu
[22:07] <maco> dont think that's packaged yet though
[22:07] <maco> i thought since it's an ubuntu-specific experiment, it would go in the Ubuntu package
[22:07] <seb128> it could
[22:07] <seb128> you can open an ubuntu task for sure
[22:25] <tedg> maco: Liferea too.
[22:30] <maco> tedg: for the "52 million unread items" messages?
[22:30] <tedg> maco: I practice RSS-zero ;)
[22:53] <tedg> maco: Also, atleast for mail, we've been doing an "unviewed" count instead of "unread."  Kinda like how the liferea status icon works now.
[22:54] <maco> tedg: i havent logged into gnome in a week or two, so i'm missing some context
[22:56] <tedg> maco: Basically for Evolution we're showing the count of messages that you have gotten since the last time your read an e-mail in Evolution.
[22:57] <maco> instead of the total?
[22:57] <tedg> maco: Correct.  Figuring that most people don't do inbox-zero, so if we required it, we'd have no users :)
[22:58] <maco> hehe
[22:59] <maco> yeah im always going "ok..i had 235 last time i looked...i think...so i got....127 new?"
[23:00] <tedg> Yeah, I've just given up counting.
[23:00] <maco> ah! AFK meeting....late...bah
[23:00] <maco> bye