[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.
[23:00] <tedg> Yeah, I've just given up counting.
[23:00] <maco> ah! AFK meeting....late...bah
[23:00] <maco> bye


[06:53] <uber> I need some testers for a Debian package I've built for the latest release of DocFetcher. It was a little tricky. Its available for only amd64 right now. You can install the .deb package from http://uberstudent.net/pool/main/d/docfetcher/
[07:07] <vibhav> topic
[07:07] <vibhav> oops
[12:00] <alo21> hi everybody... can I start importing package to 13.10?
[12:34] <geser> alo21: the auto-import seems to be running already
[12:35] <alo21> geser, so I can start working on merge (if needed)
[12:36] <geser> yes
[12:39] <alo21> thanks
[12:42] <jtaylor> I'd wait with merging for a bit
[12:42] <jtaylor> debian will unfreeze soon so you may have to merge again
[12:44] <geser> is it kind of certain that Debian will release the next weekend? or did it got moved?
[12:45] <jtaylor> I think its still on track
[12:46] <alo21> jtaylor, ou...OK, I will wait... and which repository do I consider? main, universe or multiverse?
[12:46] <jtaylor> whatever you want to work on
[12:47] <alo21> perfect
[12:47] <jtaylor> just tell the merge owner before you start
[12:53] <alo21> yea... sure. As you told, is better if I start next week
[13:27] <jtaylor> can someine in raring please install libjs-mathjax and pastebin: dpkg -S MathJax.js
[13:30] <geser> would a raring pbuilder work too?
[13:31] <jtaylor> probably not
[13:31] <jtaylor> one of the listed files is missing on my system and I'm very sure I didn't delete it by hand
[13:32] <jtaylor> but regular files should not disappear during upgrades, must be something I did then
[13:39] <mapreri> jtaylor: if you need it: http://paste.ubuntu.com/5622640/
[13:40] <jtaylor> mapreri: do both files exist?
[13:40] <mapreri> umh... nope
[13:41] <jtaylor> the second one is missing?
[13:41] <mapreri> only the first, libjs-mathjax: /usr/share/javascript/mathjax/unpacked/MathJax.js
[13:41] <mapreri> jtaylor: yes
[13:41] <jtaylor> ok so its not just me
[13:41] <jtaylor> how can a non symlink file disappear on upgrade?
[13:43] <mapreri> jtaylor: in a "clean" saucy installation both the files exist
[13:43] <jtaylor> yes on a clean install its fine, it will also reappear if you --reinstall
[13:43] <jtaylor> so it must be an upgrade issue
[13:45] <mapreri> jtaylor: is a bug existing against it? and how do you find it??? (i don't use this package, i don't know why I installed it...)
[13:46] <jtaylor> one of my packages depends on it
[13:46] <jtaylor> one sort of failed because the file was missing
[14:10] <jtaylor> hm I can't reproduce it :/
[14:14] <mapreri> like every evil bug! ;)
[17:57] <Laney> debfx: nice backports work!
[18:09]  * iulian might consider doing some backports triaging when he's got more free time on his hands.
[18:09] <Laney> w00t
[18:31] <debfx> Laney: thanks


[02:53] <mup> PR operator#937 opened: Explicitly add all public ops.X names to __all__ in __init__.py <Created by benhoyt> <https://github.com/canonical/operator/pull/937>
[05:13] <mup> PR operator#938 opened: Lock docs dependencies; build docs with recent Sphinx version <Created by benhoyt> <https://github.com/canonical/operator/pull/938>
[08:05] <mup> Issue operator#939 opened: consider adding `get_ingress_address` and/or `get_bind_address` shortcuts to `model.Unit` <Created by PietroPasotti> <https://github.com/canonical/operator/issues/939>


[01:54] <DF__> some one here??
[12:55] <mzanetti> can we have apps that are written with angularjs/ionic?
[12:58] <mzanetti> trying to build/port an app for ubuntu, but could use some help getting started with that stuff
[13:25] <SturmFlut> mzanetti: In theory you can just take https://github.com/Sturmflut/ubuntu-html5-template.git , copy the content to the "www" folder and it should run.
[13:25] <mzanetti> requires some building with gulp it seems
[13:25] <SturmFlut> mzanetti: Do you have a pointer to the project?
[13:25] <mzanetti> SturmFlut, git@github.com:guh/guh-mobileapp.git
[13:27] <mzanetti> SturmFlut, ok. one step further... I managed to build it (at least it says finished)
[13:27] <mzanetti> let's see if I can run that index.html somehow
[13:27] <SturmFlut> mzanetti: Bargh, why do people have to wrap whole JavaScript build systems around their stuff
[13:27] <mzanetti> no clue
[13:28] <mzanetti> dunno... this seems to use some platform integration stuff. maybe that requires it
[13:30] <SturmFlut> No, it's just "cool" to build everything on node.js
[13:33] <mzanetti> SturmFlut, do you have some idea about the cordova things?
[13:37] <SturmFlut> mzanetti: No, not a bit. I only know that Oxide supports the Cordova APIs
[13:37] <mzanetti> ok. will find out
[13:51] <popey> mzanetti: i have built stuff using gulp and deployed as an html5 app on ubuntu
[13:52] <popey> once you get past all the npm and gulp nonsense
[13:53] <popey> SturmFlut: should merge that :)
[13:53] <mzanetti> popey, hey!
[13:53] <mzanetti> popey, yes, I'm past that
[13:53] <mzanetti> I've added the cordova ppa and did successfully platform add ubuntu
[13:53] <mzanetti> now trying to build. it complains about not finding my click chroots
[13:55] <popey> uh
[13:55] <mzanetti> hmm... click doesn't seem to be aware of them indeed, even though they work in qtcreator... anyhow, creating one with that cordova tool now
[13:55] <mzanetti> or not :D
[13:57] <mzanetti> popey, "cordova build --device" is still the correct thing to do, right?
[13:58] <popey> no idea
[13:58] <popey> never built a cordova thing
[14:04] <mzanetti> so close :)
[14:04] <mzanetti> I have a click, but it seems only white when I start it
[14:18] <SturmFlut> mzanetti: Any log output? Maybe an AppArmor permission is missing?
[14:18] <mzanetti> currently fiddling with that, yeah
[14:18] <mzanetti> log is not too helpful, but last line is a permission denied...
[14:18] <mzanetti> but it seems to generate the apparmor file... so need to patch some files
[14:21] <mzanetti> SturmFlut, this is all I get: http://paste.ubuntu.com/11821020/
[14:21] <mzanetti> now running it unconfined
[14:21] <mzanetti> still everything white
[14:23] <mzanetti> hmm... can't spot an obvious error
[14:23] <mzanetti> need to stop for today tho
[14:41] <SturmFlut> mzanetti: Looks like a case for #oxide :/
[14:42] <ja_> hello
[14:44] <ja_> i try to use ubuntu-sdk with qml project
[14:45] <ja_> but when i have this error: errors while reading typeinfo files ...
[14:45] <ja_> and i can open desing section
[16:19] <DF__> hi some one here??
[16:21] <popey> DF__: sure
[20:44] <elijah> hola
[20:45] <elijah> I am trying to build an AppIndicator for Ubuntu 14.04, I found documentation for 13.10 but not 14.04
[20:45] <elijah> http://developer.ubuntu.com/api/devel/ubuntu-13.10/python/AppIndicator3-0.1.html
[20:45] <elijah> Does this apply for 14.04 too?
[20:45] <elijah> When I do help('appindicator') I get " /usr/lib/python2.7/dist-packages/appindicator/__init__.py"
[20:46] <elijah> But don't know if that means the appindictor version on my system is 2.7 or not
[21:50] <elijah> This here shows me a 0.1 and a 3-0.1 - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libappindicator/trusty-updates/files/head:/src/
[21:50] <elijah> Which I gather the 3-0.1 is for GTK3+
[21:50] <elijah> But I am not sure how to declare which one to do with a import appindicator or how to see what one is being included


[08:46] <Kamping_Kaiser> pschulz01, evening
[08:47] <Kalamansi> afternoon here guys
[08:47] <Kalamansi> using ubuntu 7.10 desktop
[08:49] <Kamping_Kaiser> for everyones background: Kalamansi is after help setting up a gateway to do content filtering, and block p2p traffic
[08:50] <Kamping_Kaiser> Kalamansi, your technical questions from pm, i'll answer them here.
[08:50] <Kamping_Kaiser> to setup dansguardian for a basic setup, follow these steps https://wiki.ubuntu.com/EdubuntuProxy
[08:50] <Kamping_Kaiser> once you have the basic setup, you/we can change it to make it work for you better
[08:51] <Kalamansi> ok im on it. done downloading it
[08:52] <Kalamansi> but i am not using edbuntu... im using ubuntu...is it okay?or conflict?
[08:52] <Kamping_Kaiser> it all works the same
[08:52] <pschulz01> Kamping_Kaiser: Evening..
[08:52] <Kamping_Kaiser> pschulz01, hope you had a great last 3-4 days ;)
[08:53] <pschulz01> Kamping_Kaiser: Someone is being quiet at the moment :-)
[08:53] <Kamping_Kaiser> hehe. :)
[08:54] <pschulz01> Anyone here using dspam?
[08:54] <Kalamansi> Kamping_Kaiser : is it okay to use ubuntu 7.10 desktop with x window (for my server)? im not good in typos by hand scripting
[08:54] <Kamping_Kaiser> Kalamansi, you can do if you want. for a 'real' server you would avoid x, but for a home/learning sedtup its ok (just i dont know how you configure a server via a gui :))
[08:56] <Kalamansi> Kamping_Kaiser :  while after installing this dansguardian and squid i will plug off the monitor and just leave the tower cpu.
[08:56] <pschulz01> Kamping_Kaiser: Any problems with the kernel/scheduler in desktop do you think?
[08:57] <Kamping_Kaiser> pschulz01, not for a simple gateway, which is what it sounds like (s?)hes trying.
[08:57] <Kalamansi> Kamping_Kaiser : Is it ok?my server is pentium dual core 3.00ghz, 1gb ram, 256 videocard, azus p5pe? is it okay for server?
[08:57] <Kalamansi> Kamping_Kaiser : handling 40 units winxp home workstations ?
[08:58] <Kamping_Kaiser> Kalamansi, its obscenely overpowered, otherwise no problem ;)
[08:58] <pschulz01> Kamping_Kaiser: I'm running a server on a AMD P200+ (old old old)
[08:58] <Kamping_Kaiser> pschulz01, i'm running a server on a sun sparc of unknown speed.
[08:58] <pschulz01> s/Kamping_Kaiser/Kalamansi/
[08:58] <Kamping_Kaiser> Cpu0Bogo        : 540.49
[08:58] <Kamping_Kaiser> :)
[08:59] <Kalamansi> Kamping_Kaiser :  in this section sudo iptables -t nat -A OUTPUT -p tcp -d ! <IP_ADDRESS>/<IP_ADDRESS> --match owner --gid-owner users -j REDIRECT --to-ports 8080 -- do i need to use this <IP_ADDRESS> instead of <IP_ADDRESS>? because my modem is setup to <IP_ADDRESS> .....
[08:59] <Kalamansi> pschulz01: with x server? (your old server)
[09:00]  * Kamping_Kaiser wishes he could remember the real link for setting up a filtering proxy
[09:00] <Kamping_Kaiser> Kalamansi, what is your native language?
[09:01] <Kamping_Kaiser> http://www.debian-administration.org/articles/23  http://www.squid-cache.org/mail-archive/squid-users/200504/0575.html and more advanced : http://www.debian-administration.org/articles/187
[09:02] <Kalamansi> Kamping_Kaiser : filipino - tagalog, visayan, ilonggo and english (philippines, davao city)
[09:02] <Kamping_Kaiser> hm. not sure if theres ubuntu channels for those.
[09:02]  * Kamping_Kaiser considers aquireing food (but i'm not hungry :/)
[09:06] <Kamping_Kaiser> i'm heading to the hawtins :)
[09:07] <Kamping_Kaiser> Kalamansi, good luck with your problem - read those links and have a play around. i'm sure someone here can help. remember that today is probably a bad day - xmas just finished in most of the world. tomorrow or the day after may be better. see you all!
[09:08] <Kalamansi> Kamping_Kaiser : do you have links for advance guide?dansguardian and iptables..thanks
[09:09] <Kamping_Kaiser> !iptables
[09:09] <ubotu> Ubuntu, like any other linux distribution, has firewall capabilities built-in. The firewall is managed using the 'iptables' command (see https://help.ubuntu.com/community/IptablesHowTo), or GUI applications such as Firestarter (Gnome) or Guarddog (KDE).
[09:09] <Kamping_Kaiser> Kalamansi, ^^ look at that link
[09:09] <Kamping_Kaiser> Kalamansi, ask in #dansguardian about a dansguardian link :)
[09:11] <Kalamansi> ok do you have 24 hours tutorials there?pdf?hehehe
[09:17] <Kalamansi> Kamping_Kaiser : is it ok to run firestarter and dansguardian?
[09:18] <pschulz01> Kamping_Kaiser: Were you aware of any of the following problems with dspam? https://bugs.launchpad.net/bugs/+bugs?field.searchtext=dspam&search=Search+Bug+Reports&field.scope=all&field.scope.target=
[09:20] <pschulz01> Hmm... https://bugs.launchpad.net/ubuntu/+source/dspam/+bug/141413
[09:20] <ubotu> Launchpad bug 141413 in dspam "dspam-webfrontend.conf has wrong group" [Undecided,New]
[09:21] <Kalamansi>  pschulz01: im not sure really what to run tho..which one is more secure firestarter or dansguardian?
[14:38] <kbrooks> Can ubuntu-server be installed with no CD?
[14:59] <dthacker> kbrooks: a network install is available, I have not tried it.
[15:05] <lamont> I discovered this week that the network install defaults to server.  most nice
[15:05] <lamont> well, at least on some platforms.
[15:08] <zylmak> good morning, what is the command to see the right over a file or folder?
[15:26] <zylmak> hello i have problem setting up apache
[15:26] <zylmak> especialy  the cgi
[15:45] <zylmak> does anyone know ho to setup apache2?
[18:19] <h4x0r7h1s> I have a server on Edgy I'm moving to Gutsy
[18:19] <h4x0r7h1s> it has Apache2 with ssl
[18:20] <h4x0r7h1s> the Edgy version works well; the Gutsy one gives the error in firefox:  ssl_error_rx_record_too_long
[18:22] <h4x0r7h1s> hrm
[19:18] <spiekey> hey!
[19:19] <spiekey> How do i get my network card driver into the initrd image? I need it to boot via lan
[23:55] <Centaur5> My thin clients can boot into the login screen but they don't authenticate.  I don't see any error messages in syslog and I've tried deleting the ltsp installation, running build-client again, and update-sshkeys. Are there more diagnostic steps I can do?


[21:18] <mup> Issue operator#858 closed: [juju secrets] Secret created with existing label does not throw an error <Created by hemanthnakkina> <Closed by benhoyt> <https://github.com/canonical/operator/issues/858>
[21:18] <mup> PR operator#856 closed: Reinstate reversion of add_relation_unit ValueError to warning <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/856>
[22:03] <mup> PR operator#859 opened: Bring 1.5-maintenance branch up to date <Created by benhoyt> <https://github.com/canonical/operator/pull/859>
[23:22] <mup> PR operator#860 opened: Fix logging in can_connect, add tests; remove pebble.Error methods <Created by benhoyt> <https://github.com/canonical/operator/pull/860>


[19:42] <ochosi> Unit193, bluesabre: as we already ship xfdesktop 4.13.3 this patch would be quite important to include: https://git.xfce.org/xfce/xfdesktop/commit/?id=2d9a081c0ff88cb2c2061beb345d1eb8ec3c070b
[19:42] <ochosi> unfortunately otherwise the icon positioning will be messed up for people who use custom placement
[19:42] <ochosi> mea culpa


[00:14] <d1n0saur> hello all
[01:27] <Quantos> Hi, I'm running KUbuntu 18.04 and I would like to know how to reduce the length of time that it takes to log off or shutdown
[01:27] <Quantos> I have it set to start with a new session each time
[02:19] <DarwinElf> in Slackware, Konsole does great, letting me use a default profile.  In Kubuntu, Konsole doesn't, ignoring that I've set a default profile... it loads a non-profile Konsole session each time.  How do I get it to enforce using my setting of a default profile?
[03:08] <Perdellian> valorie: nah, I gave it a break last night
[03:08] <Perdellian> I think my /boot might've been larger before, come to think of it
[03:14] <valorie> so there is bootchart
[03:14] <valorie> which I don't know how to use, but that's what the developers use to make things quicker
[03:15] <valorie> DarwinElf: sounds like a bug!
[03:15] <valorie> the easy way to file one is `ubuntu-bug konsole` in the commandline
[03:15] <Perdellian> so, sanity check... after doing 'cryptsetup luksOpen /dev/sda5 computername-crypt', I should be able to see all my LVM stuff in that, right?
[03:15] <valorie> Perdellian: sorry, haven't a clue about that
[03:15] <Perdellian> {p,l,v}scan and {p,l,v}display do nothing
[03:15] <Perdellian> show nothing, that is
[03:16] <Perdellian> (and yes, running with sudo
[03:16] <Perdellian> )
[03:17] <valorie> hopefully someone who knows hops in
[03:22] <DarwinElf> ok
[03:32]  * Perdellian wonders if they should just find another live image and try from there
[04:05] <Quantos> Okay, I just upgraded Plasma and the slow shutdown is fixed
[04:05] <Quantos> So ignore my previous
[05:16] <valorie> good to hear!
[11:05] <MarcWeber> I tried apt-get update & upgrade but the update gui still says there are apps to be updated and firefox is still old.
[11:06] <MarcWeber> The system wasn't updated for 2 years, I had to copy paste sources.list from recent installation.
[11:06] <MarcWeber> So what is making the difference ?
[11:22] <MarcWeber> I was missing dist-upgrade ..
[12:20] <hateball> MarcWeber: yea you will need dist-upgrade (or apt full-upgrade) for version upgrades
[12:23] <BluesKaj> Howdy all
[12:25] <lordievader> Good afternoon
[12:27] <chrisrc1111> hello. i have a strange problem with sharing folders via samba. i can access some folders (security = user), but not others. in the latter case the log says "_servicenumber: couldn't find chris ...
[12:58] <jubo2> Hi valorie. My friend just phoned me up and said his Kubuntu just started working again. The he used to have was that the login screen did not show up: only a blinking text cursor in the top-lefthand-side and the mouse cursor. I asked him if he did anything.. such as 'sudo apt upgrade', but he told me no. This was really weird that (apparently) the SDDM broke by itself and now fixed by itself. Thank you very much for your help and info on the issue!
[12:59] <jubo2> Another Kubuntu back to operational (just a little weird not knowing how it broke nor how it got fixed)
[13:18] <jubo2> Reboot for upgrades. BBIAB
[14:26] <steve12345> are there any methods to disable right click activating menu items as an option or config file
[14:27] <steve12345> it's an accessibility issue for me
[14:29] <steve12345> https://i.imgur.com/kDoavPJ.png
[14:29] <steve12345> fresh install of kubuntu 18.10
[14:29] <steve12345> the mouse menu is weird
[14:34] <hateball> steve12345: I am not sure I understand
[14:34] <hateball> ah
[14:35] <steve12345> the screenshot is a secondary issue
[14:35] <hateball> you mean you rightclick to bring up a context menu, and then another rightclick activates the hilighted menu item
[14:35] <steve12345> well actually a single right click can open a context menu, and then activate a menu item
[14:35] <steve12345> in the up action of the click
[14:36] <steve12345> there are a few people online in my searching for a solution to this behavior confirming it
[14:36] <steve12345> in google
[14:36] <steve12345> it must be how I and those people use their mice
[14:37] <steve12345> it happens to me on kde plasma 4 all the time
[14:38] <hateball> well plasma 4 is kinda dead, but that is another issue
[14:38] <hateball> the same thing however happens in plasma 5 as well
[14:38] <steve12345> wooops
[14:38] <steve12345> I mean plasma 5
[14:38] <steve12345> too many version numbers in my head
[14:39] <steve12345> is there a hack or workaround
[14:44] <steve12345> back
[14:44] <steve12345> had to reboot
[18:48] <skeledrew_> Hello. I have a dependency issue with apt that I'm hoping to get some help with. I am trying to create a portable setup for Kodi but I'm getting `kodi-bin:amd64 Depends on libegl1-x11:amd64 < none @un H > can't be satisfied!` Installing libegl-mesa, which contains that lib, doesn't work. Here's a complete run of the command: https://pastebin.com/mM2ZAYAX. Running Kubuntu 18.04. If anyone has ideas how to fix this and similar issue
[19:06] <acheronuk> skeledrew_: 2:17.6+git20171114.2125-final-0trusty
[19:06] <acheronuk> so you have a PPA for trusty enabled, or some left over conflicting packages from one
[19:08] <skeledrew_> acheronuk yes I'm using trusty as I have a similar issue using bionic, but with more things broken IIRC. I'll revert and try again to get that particular output
[19:09] <acheronuk> skeledrew_: well, if the packages are from an unsupported PPA we may be limited to what we can suggest
[19:20] <skeledrew_> acheronuk: I have the same issue when using Bionic: https://pastebin.com/4jfFxxms. I appended the contents of sources.list. Unfortunately I may not be able to do anything about the trusty source as it is included by the tool I'm using (AppImage creator)
[19:28] <acheronuk> what is the output of 'apt-cache policy libegl1 libegl-mesa0'
[19:54] <skeledrew_> acheronuk: https://pastebin.com/88PU3LbG
[19:56] <skeledrew_> Also if it helps, this is the tool I'm using: https://github.com/AppImage/AppImages/blob/master/pkg2appimage
[19:58] <jubo2> y0. My friend's SDDM broke again (after it had fixed itself with no action taken on part of the user). Looking at my own machine the /var/log/sddm.log is an empty file. Where can I find the relevant log?
[19:59] <jubo2> He got the same system as me, Kubuntu 18.04.1
[20:08] <acheronuk> skeledrew_: you have a package installed, or in a repo that wants to install it, that depends on older versions of mesa and libegl than are in the ubuntu-updates
[20:12] <acheronuk> in a clean and updated bionic VM, kodi from that PPA has no conflict. so it is something extra you have I guess
[20:16] <skeledrew_> acheronuk: how can I go about checking and fixing this? The only packages which should be installed are software-properties-common and kodi (for Kodi), and libcurl-slim and gnutls-patched (for pkg2appimage) along with their dependencies
[20:18] <acheronuk> one way is by sequentially listing the packages on an apt command
[20:18] <skeledrew_> I'm also running on a clean system (the other apps which I'm using have also been portablized), and I'm pretty sure Kodi will install fine with sudo, but that's what I'm trying to avoid in the first place
[20:19] <acheronuk> e.g: do 'apt-get install kodi software-properties-common'
[20:19] <acheronuk> see what is says can't be installed
[20:19] <acheronuk> add that to the apt line, and try again
[20:19] <acheronuk> and repeat
[20:20] <acheronuk> usually that eventually spits out a comprehensible reason
[20:21] <skeledrew_> I can't run it directly like that without using root. Is there a way to sandbox the operation if I use sudo?
[20:24] <skeledrew_> acheronuk: Adding to the generated apt-get command however gives `E: Package 'libegl1-x11' has no installation candidate`
[20:29] <acheronuk> libegl1-x11 is a virtual package that used to be provided by mesa on trusty, but does not exist on amd64 architecture on bionic
[20:30] <skeledrew_> Is there a way to determine how exactly it is resolved for Kodi?
[20:46] <acheronuk> difficult as 'apt-cache rdepends' does not pick up virtual packages
[20:47] <jubo2> Ok. Situation solved by moving the /etc/sddm.conf into safe keeping and regenerating sane defaults with 'sddm --example-config > /etc/sddm.conf'. My friend is young and not very attentive so I'm pretty sure he broke the conf by doing something he didn't understand. Infuriating that he wouldn't admit to it. But happy end. Another Kubuntu back up and operational! :D :D
[20:56] <skeledrew_> acheronuk thanks for the guidance. I was able to get the dependencies to resolve properly by rolling back to trusty with only `deb http://archive.ubuntu.com/ubuntu/ trusty main restricted universe multiverse` as added source and getting a single missing dependency from http://mirrors.kernel.org/ubuntu/pool/main/m/mesa/libgbm1_10.1.0-4ubuntu5_amd64.deb
[20:57] <acheronuk> skeledrew_: great. :)
[20:58] <skeledrew_> Now I only need to patch the bins to make the paths relative `bin/kodi: 170: bin/kodi: /usr/lib/x86_64-linux-gnu/kodi/kodi.bin: not found`
[22:20] <denza242> what's the recommended tool for making a liveusb
[22:23] <Perdellian> I used dd_rescue
[22:23] <Perdellian> less tetchy than using dd itself
[22:39] <genii> denza242: Since the ISO images are hybrid, you can just dd them directly to the USB stick
[22:41] <genii> Perdellian: The possible problem using ddrescue instead of regular dd is that ddrescue will continue going if it hits errors, so if the image is corrupt, or the area it's trying to write to is corrupt, you won't know
[23:19] <denza242> is 18.10 fairly stable?
[23:20] <jacky> yeah
[23:20] <jacky> I use it on my personal/work laptops!
[23:44] <valorie> denza242: using it right now
[23:44] <valorie> in fact, since the beta
[23:44] <valorie> zero problems


[11:50] <bony> how to reduce the file size of a ogv file?
[11:51] <bony> i have a 1GB file the resolution of the video is 720p. It dosn't matter if i loose some quality of the video
[23:14] <Guest7473> are you able to write notation with rosegarden?
[23:45] <dean_> does anyone know why I can't hear midi files being played when I run them through rosegarden? I have jack running and I know jack is working
[23:53] <Pablo1> Hi dean, you need a external synth (hardware or software) or a dssi plugin (this is, a synth plugin)
[23:54] <Pablo1> Rosegarden does not make sounds by itself
[23:55] <Pablo1> The easiest way is by means of a dssi plugin. Right click on the midi track and select synth plugin.
[23:56] <Pablo1> Then you have to add the synth plugin. You will see a button: No synth (or similar), press it and load a plugin
[23:57] <Pablo1> You might have some installed, hexter, for example.