[00:49] <cubias8719> hello. can anyone help me with compiz
[00:50] <slangasek> this is not a help channel; see #ubuntu for help with Ubuntu 7.10, or #ubuntu+1 for hardy
[00:50] <awalton__> or #compiz-fusion for compiz support.
[00:51] <cubias8719> thank you
[02:05] <nosrednaekim> is ubuntu doing the summer of code?
[02:06] <keescook> hunh, I am unable to branch the casper bzr repo...
[02:08] <Caesar> So where's a good place to discuss hardy installation failures?
[02:09] <jmg> ubuntu+1?
[02:10] <Caesar> So I can go there and see if someone'll sponsor a bugfix? or #ubuntu-bugs?
[02:14] <cody-somerville> Caesar, You'd file a bug and attach your bug fix and subscribe either ubuntu-universe-sponsors or ubuntu-main-sponsors depending on what part of the archive the package resides in.
[02:20] <crimsun_> keescook: I've documented it, yes, but it needs to be approved by $work.
[02:33] <keescook> crimsun_: ah! okay, thanks.  :)
[02:54] <TheMuso> keescook: What error do you get?
[03:12] <Hobbsee> hm.  hope there was nothing in main i wanted to add.
[03:14] <jmg> so
[03:14] <jmg> why are the alphas just called alpha?
[03:16] <slangasek> because "why are the alphas called alphas?" is an easier question to answer than "what's a 'tribe'?"
[03:19] <[reed]> slangasek: "bearing in mind that the Feature Freeze is also now in effect[3]" <-- except you don't have a [3] at the bottom of your mail ;)
[03:19] <slangasek> \o/
[03:19] <slangasek> it's always something, isn't it
[03:19] <slangasek> :)
[03:19] <[reed]> rly
[03:19] <[reed]> ;)
[03:19] <slangasek> I could send a followup entitled '[3]'
[03:22] <slangasek> Caesar: ah, bug #198110 was your installer bug?
[03:22] <ubotu> Launchpad bug 198110 in ubuntu-keyring "ubuntu-keyring doesn't install" [High,Triaged] https://launchpad.net/bugs/198110
[03:26] <inkynoo1> Anyone else's icons all disappear today? I'm getting  "Cannot open pixbuf loader module file '/usr/local/etc/gtk-2.0/gdk-pixbuf.loaders'" when I try to run most GTK programs too
[03:27] <somerville32> no
[03:27] <inkynoo1> hmmm
[03:31] <slangasek> Caesar: upload sponsored, cheers
[04:00] <mneptok> cmpc, eh?
[04:00] <mneptok> ogra: does that mean i get sane installtion methods in Hardy? ;)
[04:43] <Caesar> slangasek: thanks
[05:22] <TheMuso> 5~/c
[05:22] <LaserJock> hi TheMuso ;-)
[05:22] <TheMuso> Hey LaserJock.
[05:42] <ScottK> slangasek: Apparently soyuz has grown the ability to make sure that Main backports only get built from Main sources.  So my Postfix backports for Dapper/Edgy are depwait.
[05:42] <ScottK> slangasek: Any idea if there's a solution?
[05:43] <ScottK> Note for the record that the existing Postfix 2.4.5 backport in Dapper couldn't be there if this had always been the case.
[05:46] <slangasek> ScottK: hmm, we could move the postfix backport to the universe section? :)
[05:47] <ScottK> slangasek: I've really no idea.  I'm sure this is another "Feature".
[05:47] <ScottK> Because we wouldn't want to mix the unsupported backports from Main with unsupported backports from Universe.
[05:48] <slangasek> is there any reason /not/ to just move the postfix backport to universe?
[05:48] <lamont> slangasek: can different pockets have packages in different components?
[05:49] <slangasek> lamont: sure
[05:49] <lamont> what are they dep-wait on, I wonder?
[05:49] <ScottK> slangasek: I guess not.
[05:49]  * lamont is tired after a workout
[05:49] <ScottK> tinycbd
[05:49]  * lamont pukes
[05:49] <lamont> wasn't that main in dapper/edgy?
[05:49] <ScottK> Nope
[05:50] <ScottK> slangasek: If you can do that, please do.
[05:50] <lamont> yeah.  make it universe
[05:50]  * ScottK has quit thinking about these sorts of things as problems in launchpad.  They're just encouragement to work harder on NM.
[05:51] <slangasek> well, it looks like change-override.py, at least, is not accomodating
[06:11] <lamont> slangasek: alternatively, we could pull the semi-decent tinycdb back to dapper-backports/main... :=)
[06:11]  * lamont sleeps before he gets shot.
[06:13] <ScottK> lamont: If we did that we could probably avoid the FTBFS on Dapper AMD64, so that wouldn't be bad.
[06:15]  * milli wonders if lamont will clean up the puke
[06:16] <milli> ScottK: rails fix should make it good
[06:31] <GhotiPhud> hello
[06:31] <GhotiPhud> I'm looking for the latest version of the "screens and graphics" program
[06:32] <GhotiPhud> how would I get ahold of that?
[06:33] <ScottK> milli: I'll fix up rails tomorrow.  I need to get to bed.
[06:41] <pitti> Good morning
[06:42] <ScottK> Good morning pitti.
[06:46] <LaserJock> hi pitti
[06:47] <highvoltage> ahoy LaserJock
[06:48] <LaserJock> hi highvoltage
[06:49] <Fujitsu> It's a LaserJock!
[06:55] <LaserJock> hiya Fujitsu
[06:56] <GhotiPhud> hi
[06:56] <GhotiPhud> I want to get involved with ubuntu
[06:56] <GhotiPhud> don't really know where to start though
[06:58] <LaserJock> GhotiPhud: depends on what you're interested in. Have you read http://www.ubuntu.com/community/participate ?
[06:58] <GhotiPhud> yeah
[06:58] <GhotiPhud> I've just read that and a bunch of the links
[06:59] <GhotiPhud> I was just trying to get the "Screens and Graphics" program code
[06:59] <GhotiPhud> so I could see if I could get my tv-out to work with it
[07:00] <GhotiPhud> I've got it working with the cli
[07:00] <GhotiPhud> just can't make it work with that program
[07:01] <GhotiPhud> so I figured I'd take a look
[07:35] <stgraber> moin
[07:44] <jmg>  /part
[07:44] <jmg> :)
[08:48] <pitti> seb128: bonjour
[08:49] <pitti> seb128: good job with figuring out the brightness issue! I saw the patch on the upstream ML
[08:49] <pitti> seb128: I'll apply it to bzr head soon and upload a new version to my PPA
[08:49] <seb128> pitti: hello, thanks, credits goes to sjoerd who helped me too ;-)
[08:49] <seb128> pitti: thanks
[08:49] <pitti> seb128: ~ppa2 reverted some FDI changes which I thought weren't necessary any more with gvfs
[08:49] <seb128> pitti: we should have gpm mostly back to normal once we have this change
[08:50] <pitti> but now my internal partitions are back on the desktop
[08:50] <pitti> so I think gvfs didn't do any fixes at all, it was still hal
[08:50]  * pitti hugs sjoerd
[08:51] <seb128> pitti: what change was that?
[08:52] <pitti> seb128: setting volume.ignore for non-/media partitions
[08:54] <seb128> pitti: weird
[08:54] <seb128> pitti: http://paste.ubuntu.com/5250/
[08:55] <seb128> pitti: it should only display mounts under the user directory or media
[08:55] <pitti> hm
[08:55] <pitti> ah, right
[08:56] <seb128> pitti: ?
[08:56] <pitti> /dev/hdc4 on /mm type xfs (rw)
[08:56] <pitti> I get an icon for this one
[08:56] <seb128> your partitions are under media?
[08:56] <seb128> hum
[08:56] <pitti> seb128: yes, the other two are under /media, they are (invalidly) automounted
[08:56] <pitti> seb128: seems that gvfs/nautilus doesn't honor storage.automount_enabled_hint ?
[08:57] <pitti> since /etc/hal/fdi/policy/preferences.fdi disables automounting for those
[08:57] <pitti> seb128: /mm is in my fstab and mounted at boot; it's an internal partition
[09:00] <pitti> seb128: so, if it's supposed to work like that in gvfs, I'd rather fix it there than working around it in hal, WDYT?
[09:02] <pitti> seb128: is there an ubuntu bug # for the brightness issue?
[09:04] <seb128> pitti: I didn't look to the flood of new gpm bugs since we did the battery change, let me look
[09:04] <seb128> pitti: yes, agreed that was should rather fix gvfs than workaround
[09:04] <pitti> seb128: ok, nevermind, I can look myself
[09:04] <pitti> seb128: brightness patch works perfectly for me; I reported back to upstream, will commit it now
[09:04] <seb128> pitti: bug #191725
[09:04] <ubotu> Launchpad bug 191725 in gnome-power-manager "[Hardy] LCD Brightness Applet doesn't work properly" [Undecided,Confirmed] https://launchpad.net/bugs/191725
[09:05] <seb128> hum, maybe not
[09:06] <seb128> pitti: thanks, if you upload to your ppa I'll give it a try too
[09:06] <pitti> bug mangled
[09:09] <pitti> seb128: uploaded to ppa
[09:10]  * seb128 hugs pitti, you rock ;-)
[09:10]  * pitti hugs seb128
[09:10]  * Fujitsu was going to file a bug on that, and is glad he doesn't have to.
[09:11] <seb128> DOH
[09:11] <seb128> did ctrl alt backspace again by error
[09:12] <seb128> I blame ctrl-alt also being for workspace switching ;-)
[09:12] <Fujitsu> That always used to hit me too, several times a day, because I didn't release Ctrl+Alt quickly enough after workspace switching. DontZap works well.
[09:15] <pitti> mvo: hm, compiz doesn't save my session, instead I get a crash report on next login :(
[09:15] <zdzichuBG> heh, winkey+number works better for workspace switching
[09:15] <mvo> pitti: were does it crash? inside the session plugin?
[09:16] <pitti> mvo: just ??
[09:16] <pitti> mvo: I'll report it and let the retracers figure it out, ok?
[09:17]  * Amaranth hides
[09:17] <mvo> pitti: yeah, that is cool. thanks
[09:17]  * Fujitsu shoots Amaranth for something Compizy.
[09:17] <seb128> mvo: cool, the border issue is fixed in your new compiz as expected ;-)
[09:17]  * mvo spots Amaranth hidding in a corner
[09:17] <mvo> seb128: great
[09:21] <pitti> seb128: bug 198295, I'd appreciate if you could put your feedback there, too
[09:21] <ubotu> Launchpad bug 198295 in hal "FF exception request: update hal to git head" [Undecided,New] https://launchpad.net/bugs/198295
[09:21] <pitti> anyone else, if you fancy trying out my new hal version and giving feedback here ^, I'll appreciate
[09:22] <Fujitsu> pitti: Is it ~ppa3?
[09:22] <pitti> Fujitsu: yes
[09:23] <pitti> ah, still needs to be published
[09:23] <Fujitsu> pitti: I wgot that a couple of minutes back to test the brightness fix, but is there anything else to look out for?
[09:23] <Fujitsu> No, it was published 3 minutes ago on all archs.
[09:23] <seb128> Fujitsu: do you have a dell laptop?
[09:23] <pitti> Fujitsu: just whether it generally works for you and shows any regression
[09:23] <Fujitsu> seb128: Yes.
[09:23] <seb128> ok
[09:23] <seb128> because the change is dell specific
[09:23] <pitti> Fujitsu: wifi, suspend, removable drives, etc.
[09:29] <pitti> mvo: ah, seems mine was just a dup of bug 131679
[09:29] <ubotu> Launchpad bug 131679 in compiz "compiz.real crashed with SIGSEGV when attempting to unlock screen" [High,Confirmed] https://launchpad.net/bugs/131679
[09:30] <mvo> pitti: can you reproduce this crash or did this just happend out-of-the-blue?
[09:30] <mvo> pitti: its a nasty one, but we have currently no idea were it might come from and I was not able to reproduce it yet
[09:30] <seb128> brb, testing changes
[09:32] <Fujitsu> Yay, brightness works.
[09:33] <Fujitsu> Wireless power, however, still does not :(
[09:46] <pitti> Fujitsu: heh
[09:46] <pitti> next version
[09:46] <pitti> mvo: yes, I got it twice, I think
[09:47] <Fujitsu> pitti: dellWirelessCtl seems to not like my wireless :(
[09:49] <tjaalton> Fujitsu: the button doesn't turn the wireless on/off?
[09:50] <Fujitsu> tjaalton: The BIOS-provided hotkey does it, but hal complains every five seconds that dellWirelessCtl failed.
[09:51] <tjaalton> Fujitsu: oh, ok
[09:51] <Fujitsu> I presume it tries to switch the radio off or on depending on if I've disabled it in NM.
[10:28] <seb128> pitti:
 seb128: just a hunch, is there any way to disable what you do in ubuntu to have the process info just readable by root? maybe policykit is still not prepared to work fine with that. As far as I traced, the first time everything policykit works fine, for subsequent requests it doesn't
[10:28] <seb128> pitti: any idea about that?
[10:28] <pitti> seb128: we can disable it as a last resort, but maybe it'd be more helpful to fix this bug?
[10:29] <pitti> seb128: no idea off-hand, no; I guess something tries to read argv[0] twice, the second time after disabling ptrace()
[10:29] <pitti> and the result should be cached
[10:29] <pitti> but that's just a random blue sky idea
[10:29] <pitti> seb128: what's the recipe for reproducing?
[10:30] <seb128> pitti: the question was rather how to disable this process info thing
[10:30] <pitti> ah
[10:30] <seb128> pitti: the bug is that gst tools work only once
[10:31] <seb128> when you run them again they don't do any change
[10:31] <seb128> you can try users-admin, add an user, close
[10:31] <seb128> run it again and try to remove the user for example
[10:31] <pitti> removing debian/patches/02_noptrace.patch
[10:31] <seb128> it'll do nothing
[10:31] <pitti> hm, then it's not that patch
[10:32] <pitti> seb128: is there a bug # for it for assinging to me?
[10:32] <pitti> I'd like to do it a little later
[10:34] <seb128> pitti: don't bother for now, garnacho said he will have a look
[10:34] <pitti> ok :)
[10:34] <seb128> pitti: bug #188349 is about the issue
[10:34] <ubotu> Launchpad bug 188349 in gnome-system-tools "[Hardy] Unable to save manual network configurations using network-admin" [High,Confirmed] https://launchpad.net/bugs/188349
[10:45] <Amaranth> phew, pitti's compiz crash was not in the session plugin :)
[10:45] <Amaranth> of course i have no idea where it is actually happening...
[10:45] <pitti> Amaranth: no, indeed
[10:45] <pitti> but I got it first with the new compiz
[10:45] <pitti> and session saving doesn't work still, so I thought that at first
[10:46] <Amaranth> when it dies in the eventLoop that means something most likely went wrong some time ago and just got hit
[10:46] <Amaranth> PITA to debug
[11:06] <sjoerd> pitti: ugh ofcourse davidz is contemplating a release a few days after doing the git snapshot package :/
[11:09] <pitti> sjoerd: just read it, yes :)
[11:10] <pitti> sjoerd: but it won't cause a lot of additional work AFAICS
[11:10] <pitti> and who knows how long it'll take still
[11:10] <sjoerd> neh, we did all the work already
[11:10] <sjoerd> hopefully the dell laptop fix gets in
[11:11] <pitti> I tested that on mine, works great
[11:11] <pitti> I applied it to the git snapshot and uploaded to PPA
[11:11] <\sh> I wonder what is the difference while compiling code...wine compiled on the host works like a charm, but building via sbuild doesn't
[11:11]  * Fujitsu has no problems with pitti's ~ppa3.
[11:14] <ion_> Huh. I wonder how the ‘web’ got in there. deb http://archive.ubuntu.com/ubuntu hardy main restricted universe multiverse web
[11:22] <ion_> Could we get rsync 3.0.0 to hardy? (sid has it already)
[11:22]  * cjwatson mentions this thing called feature freeze
[11:22]  * \sh needs a buildd admin :)
[11:25] <ion_> cjwatson: To rephrase my question, does anyone think it’s worth a freeze exception? :-)
[11:25] <\sh> we have really a big problem right now with wine...
[11:25] <Fujitsu> \sh: Does normal sbuild give a working binary?
[11:25] <\sh> Fujitsu: that's my problem ...
[11:25] <Fujitsu> Is it just LP sbuild, or any sbuild at all?
[11:25] <\sh> Fujitsu: sbuild doesn't pbuilder does (according to scott ritchie)
[11:26] <\sh> Fujitsu: building wine on the host system..gives a running wine...and sbuild doesn't
[11:26] <\sh> Fujitsu: my sbuild gives no running wine package, as ubuntus sbuild, too
[11:26] <Fujitsu> That's not a buildd admin problem, then.
[11:27] <\sh> Fujitsu: well, we need to find the differences of a local source build and a build via sbuild
[11:27] <\sh> Fujitsu: what I'm doing now, I'm using a snapshot sbuild chroot and interactive build wine...let's see what's the outcome is..
[11:28] <\sh> Fujitsu: so now, any sbuild gives a crashing wine...
[11:29] <Mithrandir> \sh: yeah, blame poor sbuild.
[11:30] <\sh> Mithrandir: I don't blame sbuild...we need to find out what's the difference ... what does sbuild do what a normal source build doesn't do ;)
[11:31] <\sh> Mithrandir: and you agree with me, that pbuilder -> works , sbuild -> doesn't work is really a strange thing, yes? :)
[11:31] <Mithrandir> it's a bug in the package which picks up something from the build environment, then.
[11:32] <\sh> Mithrandir: and this we need to find out :)
[11:39] <ogra> yay
[11:39]  * ogra dances ... edubuntu addon works fine on non networked installs :) 
[11:39] <\sh> ogra: congrats :)
[11:40] <laga> nice :)
[11:42] <ogra> bah, i suck at kturtle :)
[11:48] <Riddell> pitti: could you give back kdeartwork-kde4, kdenetwork-kde4, kdeutils-kde4 ?
[11:49] <pitti> Riddell: done
[11:50] <Riddell> thanks
[12:06] <\sh> Mithrandir: FYI, manually build wine in snapshot schroot (the very same chroot which is used by sbuild) gives working binaries of wine...
[12:11] <Hobbsee> pitti: brightness issue?
[12:11] <pitti> Hobbsee: changing screen brightness on dell laptops
[12:12] <Hobbsee> pitti: oh, every few mins, back to the set brightness?  yeah, i was meaning to report that.
[12:12] <Hobbsee> pitti: did they manage to fix the "brightness thing comes up every few minutes, and sometimes corrupts the display, and won't go away again" too?
[12:12] <pitti> Hobbsee: no, actually it was about a broken g-p-m status icon when trying to change it
[12:13] <Hobbsee> oh.  damn.
[12:13] <pitti> Hobbsee: but maybe your problem is fixed now as well; please try my PPA version
[12:13] <Hobbsee> pitti: where is it?
[12:13] <pitti> it has literally ~ 100 bug fixes, I don't remember all of them
[12:13] <pitti> https://edge.launchpad.net/~pitti/+archive
[12:15] <Fujitsu> Hobbsee: It fixed the randomly corrupt brightness indicator for me too.
[12:17] <Hobbsee> Fujitsu: oh goody
[12:17] <Hobbsee> Fujitsu: do i have to do anything else after it installs and restarts hal?
[12:17] <Hobbsee> pitti: thanks
[12:17] <Fujitsu> Hobbsee: Nope.
[12:17] <Hobbsee> good
[12:18] <Fujitsu> Just press the brightness keys and watch it work magically.
[12:19] <Hobbsee> oh wow.  it even shows the correct things now
[12:19] <Fujitsu> Yep.
[12:19] <Hobbsee> way cool.  earth is supposedly going to blow up.
[12:20] <Fujitsu> Is there any reason that it doesn't use the nice translucent window that the volume control does?
[12:21] <zdzichuBG> noone coded it
[12:21] <Fujitsu> I would have thought that they would have used the same method to display it...
[12:26] <slytherin> asac: gnash plugin is not detected on hardy. The problem is there is no link in /usr/lib/firefox-addons/plugins to /etc/alternatives/firefox-flashplugin. But I don't think this is gnash specific.
[12:27] <ogra> slytherin, that should rather be xulrunner-addons, no ?
[12:27] <Hobbsee> pitti: wow, it really does seem to fix it
[12:28] <slytherin> ogra: I think so. But for some reason the link present /usr/lib/firefox/plugins is not working
[12:29] <zdzichuBG> Fujitsu: yeah, it simply needs copying code from gnome-settings-daemon into gnome-power-manager
[12:29] <slytherin> ogra: And /usr/lib/firefox-3.0b3/plugins is a symlink to /usr/lib/firefox-addons/plugins
[12:29] <ogra> ogra@ceron:~$ ls /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so
[12:29] <ogra> /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so
[12:29] <ogra> its there for me and works fine
[12:30] <ogra> and it properly points to /etc/alternatives/xulrunner-addons-flashplugin
[12:30] <Fujitsu> zdzichuBG: Ah, right, forgot they were generated by different apps.
[12:30] <ogra> which in turn points to /usr/lib/flashplugin-nonfree/libflashplayer.so
[12:31] <slytherin> ogra: Ok. So there is no /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so in case of gnash which is causing problem.
[12:33] <ogra> slytherin, aha
[12:34] <slytherin> ogra: I will file a bug against gnash
[12:34] <ogra> slytherin, that should be set by the postinst of gnash
[12:35] <ogra> i bet there are already update-alternative lines for the old location
[12:36] <slytherin> ogra: A bug is there already it also includes a patch (but no debdiff). bug #194379
[12:36] <ubotu> Launchpad bug 194379 in gnash "enable xulrunner 1.9/firefox 3.0" [High,Confirmed] https://launchpad.net/bugs/194379
[12:37] <asac> slytherin: yes flash upload will happen within a few days
[12:37] <slytherin> asac: Ok. SO will you also fix the bug I just mentioned in 0.8.2 packaging?
[12:41] <asac> yes
[12:41]  * asac lunch time
[12:42] <slytherin> asac: ok, thanks
[12:51] <StevenK> pitti: libmiracle0.2.4, libmlt0.2.4 and libvalerie0.2.4 only look to depend amongst themselves, so can all be NBS'd.
[12:53] <pitti> StevenK: great, thank you! removed
[12:54]  * Hobbsee removes yada, and kmos, too
[12:54]  * ScottK cheers
[12:54] <slytherin> pitti: Please tell me if I should log a bug for this. I am using b43 driver with appropriate firmware on my ibook. It works fine but jockey shows that the driver is 'Not Enabled' but it says it is 'In Use'.
[12:55] <pitti> slytherin: please do file a bug, yes; do 'jockey-gtk --list --debug 2>&1 | tee /tmp/jockey-debug.txt' and attach the log
[12:56] <slytherin> pitti: I will file a bug right now and will provide additional info tomorrow.
[12:56] <pitti> slytherin: there is already a bug about it, btw
[12:57] <pitti> slytherin: ah, nevermind, that was a different case (enabled, but not in use)
[12:58] <tjaalton> pitti: now that we have libxcb-enabled libx11 again should we default to sloppy locks like it was for a brief time during feisty? old java's fail currently (bug 87947)
[12:58] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Unknown,Fix released] https://launchpad.net/bugs/87947
[12:59] <pitti> not really my field of expertise, I'm afraid
[12:59] <pitti> tjaalton, bryce: ^ ?
[12:59] <tjaalton> yep, it's me ;)
[12:59]  * pitti hugs tjaalton
[13:00] <tjaalton> pitti: I'll ask bryce about it later, it should be safe to use sloppy locks by default
[13:05]  * tjaalton hugs pitti back for adding cmdline-options to jockey
[13:06] <pitti> :)
[13:06] <pitti> I'm currently at adding --check-composite
[13:06] <pitti> and next upload will enable it for fglrx, too
[13:06] <tjaalton> I can finally fix bug 54335 :)
[13:06] <ubotu> Launchpad bug 54335 in linux-restricted-modules-2.6.24 "fglrx should contain install instructions" [Low,Confirmed] https://launchpad.net/bugs/54335
[13:18] <ScottK> slangasek: Apparently republishing the postfix backport for Dapper into Universe wasn't enough to convince soyuz that tinycdb exists.
[13:24] <lamont> ScottK: does the log show it fetching  universe in the apt-get update?
[13:25]  * ScottK looks
[13:26] <ScottK> lamont: It shows that it does not.
[13:27] <lamont> then it didn't really go into universe. :(
[13:27] <ScottK> Launchpad says it is, but we all know Launchpad lies.
[13:28] <lamont> ScottK: you could always just re-upload postfix to dapper-backports with tinycdb-crack turned off..
[13:28] <cjwatson> 05:51 <slangasek> well, it looks like change-override.py, at least, is not accomodating
[13:28] <cjwatson> which sounds like there was a problem
[13:28] <lamont> yeha
[13:28] <lamont> yeah, even
[13:29] <ScottK> lamont: If there isn't a soyuz solution I'll do that, but I'd like to get this worked out.  Stuff moved from Universe to Main all the time and if this new 'feature' stays with us it will be a substantial complication for backports.
[13:51] <BenC> Ok, my two new packages got rejected with "None"
[13:51] <BenC> how am I supposed to know why if no one puts in a decent comment?
[13:52] <BenC> "If you don't understand why your files were rejected..."
[13:52] <BenC> I think that would be the case for everyone if that is the most common rejection reason ("None")
[13:54] <BenC> Riddell: ping
[13:56] <BenC> Riddell: is the XubuntuY convention supposed to be used for packages that are only in Ubuntu as well?
[13:56] <Riddell> BenC: yes unless it's certain that it won't ever be in debian (e.g. the linux packaging)
[13:57] <BenC> hmm, never had that enforced for new packages before...ok
[13:57] <ogra> but then you'd package native anyway
[13:57] <BenC> ogra: it has an upstream, it's just not a Debian sync
[13:57] <ogra> ah
[13:57] <BenC> Riddell: ok, is there anything else wrong? I don't want to reupload just to hit another reject
[13:57] <Riddell> BenC: everything else is fine
[13:58] <BenC> Riddell: ok, 2 minutes and they will be back in the queue
[14:02] <BenC> Riddell: upload completed for both with 0ubuntu1 revisions
[14:05] <miguillo> hello everybody
[14:06] <Riddell> BenC: groovy, accepted
[14:06] <BenC> Riddell: thanks!
[14:07] <Riddell> calc: new openoffice binary packages, main or universe?
[14:11] <miguillo> I'm trying to package tomcat6, is there a wnpp list for ubuntu? or i should apply to debian's one?
[14:14] <ScottK> miguillo: For Ubuntu you file a bug against Ubuntu and tag it 'needs-packaging' and then assign it to yourself.  Filing a Debian wnpp bug too is also good.
[14:15] <Bashtoni> Are the issues with the hardy installer and software RAID known?
[14:23] <cjwatson> Bashtoni: --verbose
[14:25] <Bashtoni> cjwatson: Gives me an error about being unable to remove files from the target
[14:26] <cjwatson> which CD exactly?
[14:26] <cjwatson> "hardy installer" is very vague
[14:26] <Bashtoni> cjwatson: Netinstall (PXE)
[14:26] <cjwatson> Bashtoni: bug 198106
[14:26] <ubotu> Launchpad bug 198106 in partman-target "Configure partitions for RAID1, received: The installer needs to remove operating system files from the install target, but was unable to do so." [Critical,Fix released] https://launchpad.net/bugs/198106
[14:27] <Bashtoni> Thanks :)
[14:27] <cjwatson> Bashtoni: I'd appreciate verification of that fix once it hits your mirror
[14:28] <Bashtoni> cjwatson: No problem, will do
[14:46] <zul> we are going to be doing a merge from debian that has a couple of bugfixes for samba do we need a ffe?
[15:18] <sabdfl> Riddell: is there a guide to moving to KDE from KDE3 on Hardy?
[15:18] <sabdfl> KDE4, sorry
[15:18] <Riddell> sabdfl: in gutsy or hardy?
[15:18] <sabdfl> hardy
[15:19] <sabdfl> i have a KDE3 desktop, want to try out KDE4 again
[15:19] <Riddell> sabdfl: just install kde4-core
[15:19] <sabdfl> ok, thanks
[15:19] <sabdfl> does that drop all the kde3 stuff?
[15:19] <Riddell> or kde4 for unadulterated full thing
[15:19] <Riddell> sabdfl: no, they install alongside
[15:19] <Riddell> just log out and select kde4 from the display manager
[15:19] <sabdfl> how do i make sure i get kde4 desktop environment on login?
[15:19] <sabdfl> ok
[15:20] <robertj> sabdfl get's pretty good tech-support ;)
[15:21] <laga> yeah. i wonder why.
[16:43] <propagandist> Should dpkg-reconfigure setup DPKG_MAINTSCRIPT_PACKAGE (so that dpkg-trigger calls work correctly)?
[16:44] <cjwatson> hmm
[16:44] <cjwatson> interesting question
[16:46]  * cjwatson asks the dpkg-trigger author elsewhere
[16:56] <cjwatson> propagandist: we think it should but it'll be a bit fiddly to do. Could you file a bug on debconf about it, please, to make sure it doesn't get forgotten?
[16:58] <ScottK> glatzor: I'm currently going through kdeguidance bugs and I see in Bug #93749 you said you had some displayconfig-gtk changes you were going to move to the backend.  I was wondering if you had done that (I don't have an easy way to test for this bug) or could point me at the right place to check for it in the backend?
[16:58] <ubotu> Launchpad bug 93749 in kde-guidance "[apport] GUI tools don't handle a missing xorg.conf file correctly" [Medium,In progress] https://launchpad.net/bugs/93749
[17:00] <propagandist> cjwatson: sure thing :o) already halfway there
[17:01] <Xteven> hi, I'm wondering what criterium is used to decide which packages are shown in gnome-app-install, and which aren't ?
[17:01] <glatzor> Xteven: the availability of a desktop file (menu entry)
[17:01] <Xteven> hmm
[17:02] <Xteven> is that information encoded in the Packages file of the repository somehow ?
[17:02] <glatzor> ScottK: one moment
[17:02] <ScottK> glatzor: Thanks.
[17:03] <glatzor> Xteven: what do you want to do?
[17:03] <glatzor> Xteven: /usr/share/app-install
[17:03] <Xteven> glatzor: I'm trying to get one of my packages to show up in the gnome-app-install interface :)
[17:06] <glatzor> Xteven: do you have got a custom distribution?
[17:07] <glatzor> Xteven: otherwise contact Canonical in the case of a proprietary software or try to get it into Universe if it is free
[17:07] <Xteven> no, the package I'm building contains a postinst script that configures a bunch of office printers in the building
[17:08] <calc> Riddell: main
[17:08] <Xteven> contacting canonical might be a bit overkill
[17:09] <glatzor> Xteven: take a look at the packages: app-install-data und app-install-data-partner
[17:09] <Xteven> ok, will do
[17:09] <Xteven> thx :)
[17:09] <glatzor> Xteven: basically you have to drop a desktop file to /usr/share/app-install and then run update-app-install in the postinst
[17:10] <glatzor> Xteven: but this discussion belongs to ubuntu-users
[17:11]  * Chipzz waves at Xteven :)
[17:12] <Xteven> hi Chipzz
[17:13] <Xteven> glatzor: running postinst is done at package installation, it doesn't put the package in the app-install listing before it is installed
[17:13] <Xteven> kindof odd :)
[17:13] <Chipzz> Xteven: you need a seperate package with the .desktop file in it
[17:14] <Chipzz> which I guess creates a circular loop :P
[17:14] <Xteven> if I understand correctly, the X-AppInstall-Package tag in a desktop file is somehow encoded into the repository information
[17:14] <Chipzz> Xteven: afaui, it's not
[17:14] <Chipzz> Xteven: gnome-app-install just looks at the files on the local system, nothing to do with a repository
[17:15] <Chipzz> Xteven: dpkg -L app-install-data
[17:15] <Xteven> so the list with installable applications (from gnome-app-install) is fixed ?
[17:15] <Chipzz> not exactly
[17:15] <Chipzz> it's just not determined from the repo, but from local information
[17:16] <Chipzz> do dpkg -L app-install-data
[17:16] <Chipzz> that has a lot of the desktop files that show up in gnome-app-install
[17:16] <Xteven> hm
[17:16] <Chipzz> Xteven: in your concrete case, I would make a kul-app-install package with some .desktop files in it
[17:17] <Xteven> so there is no way to get my package in there, unless I hijack app-install-data or app-install-data-commercial
[17:17] <Xteven> ok
[17:17] <Chipzz> like I said, they don't have to be in *that* package
[17:19] <Chipzz> Xteven: cfr /query ;)
[17:19] <glatzor> Xteven: doing system configuring by using packages is not the best approach at all
[17:19] <Xteven> what is the best approach ?
[17:20] <glatzor> Xteven: depends on your environment
[17:20] <Xteven> 100 computers spread out across the planet
[17:20] <Chipzz> glatzor: pretty big university (> 20.000 students, probably > 30.000 by now)
[17:21] <Chipzz> Xteven: I don't suppose you can force your users to install using a modified CD?
[17:21] <Xteven> no
[17:21] <slangasek> cjwatson: well, the output from change-override.py made me fearful that I'd kicked postfix to universe in dapper itself; I tried to set things back and now postfix in dapper-backports shows as being in universe, so I guess that's progress
[17:21] <Chipzz> glatzor: so custom cd is not really a solution
[17:21] <Xteven> no custom cd, no global policy stuff
[17:22] <Chipzz> thinking more about this, I have another idea
[17:22] <Chipzz> but I doubt if that's really feasable at all
[17:22] <glatzor> Xteven: have you already thought about landscape?
[17:22] <Xteven> nope, never even heard of it :)
[17:23] <Xteven> I see
[17:23] <Xteven> a central config system
[17:23] <Chipzz> I was thinking more along the lines of ubuntu providing some infrastructure for extra packages which only show up on certain mirrors
[17:23] <Chipzz> but that would be opening up a whole new can of worms
[17:24] <Xteven> I don't want to maintain other people's desktops, I just want to make it easier for them to install 15 printers on their system
[17:24] <Xteven> anyway, I have to go to class
[17:24] <Xteven> thx for the help and cya later
[17:24] <Chipzz> elmo: ping?
[17:27] <glatzor> ScottK: the basic idea is to ship a fallback xorg.conf which does not contain any configured devices
[17:28] <glatzor> ScottK: but that is in the end an evil hack.
[17:28] <glatzor> ScottK: it is a pity, but xorg does not provide a way to get a configuration file from the currently used devices/settings
[17:29] <ScottK> glatzor: Since displayconfig is pretty unmaintained at the moment, I'll take working evil hack over the theory of a pretty solution.
[17:29] <Chipzz> glatzor: btw, there's another use-case for what Xteven just mentioned
[17:29] <glatzor> ScottK: you should think about replacing it at all.
[17:29] <ScottK> glatzor: Above my pay grade.  I just volunteer here.
[17:29] <Chipzz> I know the situation a bit, since I went to the same college as Xteven is working at (was even a class-mate of Xteven ;))
[17:30] <glatzor> ScottK: me too
[17:30] <glatzor> :)
[17:31] <Chipzz> glatzor: for example, at that college, you have to login to the network to be able to reach the internet at all (except for a few local sites, among which a debian/ubuntu mirror)
[17:31] <tseliot> glatzor: did I miss something? Problems with Xorg?
[17:32] <glatzor> ScottK: is there any work on a randr configuration tool for kde?
[17:32] <ScottK> glatzor: I don't know.  Riddell would be the one to ask.
[17:32] <Chipzz> people have already written scripts to do that login, but it would be really easy if someone made that into a package, and that package could be included on the local mirror, and in some *-app-install package, so users just have to click it to install
[17:32] <Riddell> I don't know of any
[17:33] <Riddell> glatzor: what's the gtk tool?
[17:33] <ScottK> glatzor: I just hit a diplayconfig bug where it's crashing for me so I'm trying to round up any other easy fixes to go with that patch for after the alpha
[17:33] <tseliot> glatzor: Gustavo Boiko (Mandriva) wrote a GUI to RandR in C++
[17:33] <glatzor> Riddell: perhaps it would make sense to talk the fedora guys
[17:33] <tseliot> glatzor: a GUI in QT
[17:34] <ogra_cmpc> cjwatson: can you give me a hint ? i see the modes menu contents are defined in gfxboot.cfg, where does that come from ?
[17:34] <glatzor> Riddell: they store monitor specific data in a xml file in the users home folder
[17:34] <glatzor> tseliot: I left the xorg land, since I could not spend enough time to get the work done
[17:35] <ogra_cmpc> i dont see it in gfxboot-themes-ubuntu and there is no trace for anything relating to it in the cd buildscripts
[17:35] <cjwatson> ogra_cmpc: it's written by debian-cd
[17:35] <cjwatson> tools/boot/hardy/boot-*
[17:36] <ogra_cmpc> ah
[17:36] <ogra_cmpc> thanks
[17:36] <cjwatson> it was basically to avoid defining even more extensions in isolinux.cfg, which I realised caused errors to be spat out by isolinux itself
[17:36] <ScottK> lamont (or any buildd admin) Would you please do a giveback on postfix in dapper-backports and edgy-backports?
[17:36] <tseliot> glatzor: oh, sorry to read that :/
[17:36] <cjwatson> though it so happened that you mostly never saw them
[17:36] <ogra_cmpc> that whole gfxboot setup could need a diagram how the things play together
[17:36] <cjwatson> yeah, sorry :-/
[17:36] <ogra_cmpc> nah
[17:37] <ogra_cmpc> that was not what i meant :)
[17:37] <tseliot> Riddell: did you check KRandR?
[17:37] <ogra_cmpc> looks like a good intrepid project, i want to get more familiar with all that stuff anyway :)
[17:38] <Riddell> tseliot: I havn't looked into the issue at all
[17:40] <tseliot> Riddell: here's the git repository (if you're interested):
[17:40] <tseliot> http://git.mandriva.com/?p=projects/krandr.git
[17:45] <cjwatson> ogra_cmpc: somebody other than me certainly should
[17:46] <ogra_cmpc> yeah
[17:48] <Riddell> tseliot: interesting but I've no idea how to actually get at the code :)
[17:48] <Riddell> glatzor: what's the gtk xrandr tool?
[17:49] <glatzor> Riddell: sorry, bryce blogged about it recently. It is developed by RedHat's Søren Sandman
[17:49] <glatzor> Riddell: it will integrate into gnome-settings-daemon
[17:49] <twb> Is there an equivalent to qa.debian.org/developer.php for Ubuntu?
[17:50] <glatzor> Riddell: But since libxrandr is very very low level it would make a lot of sense to share some code
[17:50] <glatzor> Riddell: there is also some discussion about it on the gnome-cc list
[17:52] <Riddell> twb: launchpad.net/people (much broader of course)
[17:52] <bryce> Riddell: go to Screen Resolution in System > Preferences, or run gnome-display-settings from the command line
[17:53] <bryce> Riddell: most of the interesting bits are in gnome-desktop
[17:53] <twb> Riddell: well, I'm using it to compare the "health" of a bunch of packages.
[17:54] <bryce> Riddell: xrandrwrap.c in particular.  I see it uses some gtkisms but think it could be generalized for kde
[17:54] <Riddell> bryce: what needs apt-get installed?
[17:54] <twb> It's more useful than packages.d.o / packages.u.c because it also shows the uscan results
[17:55] <twb> And also because it tabulates a bunch of packages rather than just one at a time.
[17:55] <bryce> Riddell: gnome-desktop, gnome-control-center, and gnome-settings-daemon
[17:55] <Riddell> E: Couldn't find package gnome-desktop
[17:56] <bryce> hmm, the binary is libgnome-desktop[-2|-dev]
[17:56] <bryce> probably need gnome-desktop-data, although that may get pulled in automatically
[17:59] <keescook> allo
[17:59] <geser> Hi keescook
[17:59] <Riddell> bryce: I have gnome-control-center gnome-settings-daemon and libgnome-desktop-2 installed but no signs of gnome-display-settings
[17:59] <Riddell> bryce: ah, gnome-display-properties ?
[18:05] <Riddell> ScottK, glatzor, tselio1: looks like there is a kde 4 randr tool "kcmshell4 randr"
[18:05] <bryce> Riddell: ah sorry that's right
[18:05] <Riddell> it doesn't work, but then neither does gnome-display-properties :)
[18:06] <bryce> Riddell: got a screenshot?
[18:06] <ScottK> Riddell: Interesting.  Did we happen to package that already?
[18:06] <bryce> Riddell: you may want to doublecheck that gnome-settings-daemon is running
[18:08] <tselio1> Riddell: thanks, I'll have a look at it
[18:08] <tselio1> it looks like my URandR is the only one that works ;)
[18:08] <Riddell> bryce: http://kubuntu.org/~jriddell/tmp/kde-randr.png
[18:09] <Riddell> ScottK: yes, it's in kdebase-workspace-bin
[18:10] <Riddell> bryce: yerk, starting that had some interesting delayed effects.  can't gnome start its own daemons?
[18:10] <tselio1> Riddell: URandR -  http://albertomilone.com/wordpress/wp-content/uploads/2007/12/urandr1.png
[18:11] <bryce> Riddell: I'm not the gnome guru.  ;-)  But I did notice the daemon doesn't start up at install time, but it does on reboot.
[18:12] <Riddell> I spot potential for windows 95 jokes :)
[18:13] <tselio1> bryce: did you have a look at EnvyNG? mvo won't approve it unless he hears your opinion on this
[18:15] <tselio1> bryce: my bzr branch is http://bazaar.launchpad.net/~albertomilone/envy/envyng
[18:19] <bryce> tselio1: ok I'll take a look
[18:19] <tselio1> thanks
[18:21] <jdstrand> hi slangasek!
[18:21] <slangasek> jdstrand: moo
[18:22] <jdstrand> slangasek: do you remember that odd libtool issue with the gutsy openldp testing suite?
[18:22] <jdstrand> slangasek: did anything come of that?
[18:23] <jdstrand> I have in my notes:
[18:23] <jdstrand>  < slangasek> jdstrand: ok, from what I see, openldap is assuming a
[18:23] <jdstrand> libltdl that uses RTLD_GLOBAL; that's a bug in libltdl upstream that's fixed in
[18:23] <jdstrand> the Debian/Ubuntu package (using RTLD_GLOBAL causes namespace collisions in the
[18:23] <jdstrand> general case), so openldap's modules need to be fixed to not rely on this
[18:23] <slangasek> jdstrand: yes, upstream is fixing it; I think it's supposed to be fixed in 2.4.8 which I'm having a look at in the next couple of days
[18:24] <slangasek> basically, back_meta was relying on back_ldap in ways that it wasn't supposed to according to upstream's own policies
[18:24] <slangasek> so that's good, for once I needn't argue with them :)
[18:24] <jdstrand> slangasek: ok-- no rush, just curious.  (I hit this with a security update)
[18:24] <jdstrand> heheh-- that is good news indeed
[18:25] <jdstrand> slangasek: I might mention that test030-relay was also failing (the other two were test035-meta and test036-meta-concurrency)
[18:25] <jdstrand> I haven't looked into test030-relay to see if it uses back_meta...
[18:25] <slangasek> deos test030-relay use back_meta?
[18:25] <slangasek> ok :)
[18:25] <jdstrand> :)
[18:26] <jdstrand> slangasek: looks like it does, so no problems
[18:26] <slangasek> lamont: eew, since when is nsis i386/amd64 only? :P
[18:27] <slangasek> lamont: that's not right at all - mingw32 is built on all archs, so nsis should be as well
[18:28] <lamont> slangasek: maintainer requested
[18:29] <lamont> no maintainer support for anything other than i386/amd64.  including no support on kfreebsd-* :)
[18:29] <slangasek> lamont: but the maintainer's off his nut :-P
[18:29] <lamont> slangasek: well, that may well be.
[18:29] <lamont> just look at the package. :)
[18:29] <lamont> if it's a bad thing, we could just leave it blowing up on all the architectures...
[18:30]  * lamont is happy to revert it if that will make slangasek happier.
[18:30] <slangasek> lamont: well, it /doesn't/ blow up - the most recent version built on mipsel at the very least
 I'd rather not have to deal with any other arches, since this isn't very portable software
[18:31] <slangasek> it was portable enough before
[18:32] <slangasek> and at least in Debian, the maintainer doesn't have veto there... :)
[18:32] <ogra_cmpc> and in ubuntu we dont have maintainers :P
[18:32] <ogra_cmpc> only teams
[18:45] <nixternal> slangasek: can I get a give back on kpovmodeler-kde4 and rsibreak-kde4 please? they were uploaded with the kde4 packages earlier prior to libplasma being ready for their deps..thanks
[18:46] <slangasek> nixternal: I'm not a buildd admin
[18:47] <nixternal> hrmm, Riddell next? :p
[18:47] <Riddell> hmm, for some reason I thought you were
[18:47] <Riddell> nixternal: this lot https://edge.launchpad.net/~launchpad-buildd-admins/+members
[18:49] <nixternal> groovy, hey pitti ol' buddy ol' pal :)  Can I get a give back on kpovmodeler-kde4 and rsibreak-kde4 please?
[18:49] <nixternal> no rush, as kdebase-workspace is still pending on sparc anyways
[18:49] <cjwatson> ogra_cmpc: however, we share Packages-arch-specific with Debian
[19:58] <pitti> nixternal: hi! given-back
[20:11] <ogra_cmpc> pitti: how about making apport submit system language info as well ... for non english bug reports that could be quite helpful i imagine
[20:12] <ogra_cmpc> (not for hardy, just a general idea)
[20:27] <pitti> ogra_cmpc: how do you define 'system language'?
[20:27] <ogra_cmpc> $LANG
[20:28] <ogra_cmpc> or something similar
[20:28] <ogra_cmpc> $LANGUAGE
[20:29] <ogra_cmpc> would make guessing the right translation variant easier ...
[20:29] <pitti> ogra_cmpc: but it's already doing that?
[20:29] <pitti> ogra_cmpc: ProcEnviron: field
[20:29] <nixternal> pitti: thanks!
[20:30] <ogra_cmpc> pitti: well, look at bug #181462
[20:30] <ubotu> Launchpad bug 181462 in ubuntu "scheda video trident" [Undecided,Incomplete] https://launchpad.net/bugs/181462
[20:31] <pitti> ogra_cmpc: oh, I see; right, recent regression, I don't add the Proc* stuff for bug reports by default any more, just for crashes
[20:31] <ogra_cmpc> ah
[20:31] <pitti> ogra_cmpc: the idea was to filter out the fields with more personal data
[20:31] <ogra_cmpc> understood
[20:31] <pitti> but the latest version has a much better approach for that
[20:31] <pitti> ogra_cmpc: can yuo please file a bug for me?
[20:31] <ogra_cmpc> but i think that info makes perfect sense
[20:31] <pitti> ogra_cmpc: no problem to re-add it
[20:31] <ogra_cmpc> will do
[20:31] <pitti> agreed
[20:31] <pitti> removing ProcEnviron: wasn't really intended
[20:32] <pitti> for bugs I'm more concerned about exposing the command line, etc.
[20:32] <ogra_cmpc> (we could integrate google translate automatin via LP with that ;) )
[20:32] <pitti> ogra_cmpc: danke
[20:32] <ogra_cmpc> "click here to get the english version of the bug" :)
[20:34] <laga> .oO(.. "kein weltraum links vom gerät" -> "no space to the left of the device" -> "no space left on the device" ..)
[20:34] <ogra_cmpc> heh
[20:34] <ogra_cmpc> i think google improved a lot such translation errors are rather rare
[20:35] <laga> ogra_cmpc: they've recently switched to a new translation engine based on statistics
[20:35] <ogra_cmpc> ah
[20:35] <pitti> laga: *chuckle*
[20:35] <laga> i'm not sure how well that works, but i think there's a link now to tell them if something's broken
[20:36] <ogra_cmpc> the occurences where i needed google trans. it worked impressinlgy well
[20:37]  * laga wonders how to tell from /sys/block/ whether a device is a hard disk or a CD-ROM drive
[20:39] <mjg59> laga: Check whether bit 3 of capability is set
[20:39] <mjg59> laga: See include/linux/genhd.h
[20:40] <laga> thanks
[20:40] <ogra_cmpc> laga: the ltspfs cdpinger script has a good python implementation of the capability check
[20:41] <laga> python. exactly what i need.
[20:41] <ogra_cmpc> pitti: bug #198514 for you ...
[20:41] <ubotu> Launchpad bug 198514 in apport "please enable  ProcEnviron in apport reports" [Undecided,New] https://launchpad.net/bugs/198514
[20:42] <seb128> StevenK: could you have a look at the sponsor request for the new gimp version today?
[20:42] <pitti> ogra_cmpc: thanks, assigned
[20:56] <james_w> bryce: hi. I suspect https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/193560 is another xrandr/g-s-d bug. It has the helpful error "parse error".
[20:56] <ubotu> Launchpad bug 193560 in gnome-settings-daemon "[Hardy] gnome-settings-daemon not logged in when started" [Undecided,Confirmed]
[21:08] <ScottK> doko: I would appreciate your input on what we can/should do to resolved Bug 185418.
[21:08] <ubotu> Launchpad bug 185418 in zope3 "reports its version number in .egg-info as 0.0.0" [Undecided,New] https://launchpad.net/bugs/185418
[21:29] <mario_limonciell> bdmurray, ping
[21:30] <hunger> Is it no longer possible to do a CLI only install in hardy?
[21:30] <cjwatson> it certainly should be
[21:31] <cjwatson> should be on the F4 menu on the alternate install CD
[21:32] <bdmurray> mario_limonciell: howdy
[21:32] <cjwatson> hunger: ^--
[21:32] <mario_limonciell> hiya bdmurray.  in some debugging endeavors, i didn't find a lot of valuable prefabbed information on kdump.  I threw together a script that you guys might find useful to provide for triaging if you're interested
[21:33] <mario_limonciell> bdmurray, http://paste.ubuntu.com/5285/
[21:34] <hunger> cjwatson: Yeap, but I have real trouble installing a system without libx11.
[21:34] <tjaalton> james_w: can't be a dupe, since the changes were uploaded later than the bug was reported
[21:34] <cjwatson> hunger: libx11-6 is not in the console-only install in Hardy
[21:34] <hunger> cjwatson: And I have only ubuntu-minimal and a couple of console apps.
[21:35] <cjwatson> hunger: perhaps you are confusing it with x11-common, which is present due to console-setup
[21:35] <cjwatson> and, frankly, isn't something I'm concerned about
[21:35] <james_w> tjaalton: sorry, can't be a dupe of what?
[21:35] <cjwatson> sorry, I mean xkb-data, not x11-common - x11-common isn't needed in minimal any more
[21:36] <hunger> cjwatson: I'm upgrading from gutsy and that insists on libx11 due to console-kit due to dbus due to hal AFAICT.
[21:36] <tjaalton> james_w: of the gsd/xrandr bug
[21:36] <hunger> Dunno whether I can get rid of hal later on.
[21:36] <cjwatson> hunger: it's not part of a from-scratch hardy console install, that's all I can say. Be precise in your complaints!
[21:36] <cjwatson> and libx11 does not imply an X server, anyway, which is the real heavyweight thing
[21:36] <james_w> tjaalton: I realise that, I was just trying to give a heads up that it is another issue in the same area, as it may still be being worked on.
[21:37] <hunger> cjwatson: I'm updating a gutsy without libx11 and aptitude insists that libx11 is now required.
[21:37] <cjwatson> ah, hmm, perhaps there is something wrong with my apt cache
[21:37] <cjwatson> it's hardly a big deal, anyway. Like I say, libx11 doesn't pull in an X server.
[21:38] <hunger> cjwatson: Maybe some of my used-to-be-console only picked up some depends on X11 or something. I'll investigate after the upgrade.
[21:38] <bdmurray> mario_limonciell: thanks, I'm a bit swamped but will look at it later today
[21:39] <mario_limonciell> bdmurray, great.  hopefully it turns out to be helpful, it's been working great for me to catch some stuff :)
[21:39] <slangasek> cjwatson: <cough> nope, it just pulls in /usr/bin/X...
[21:39] <slangasek> which isn't an X server, just an suid-root wrapper
[21:39] <cjwatson> libx11-6 doesn't appear in seed expansions until you get as far out as desktop-common
[21:45] <Chipzz> there is ofcourse the pull-10-instead-of-one-brown-paperbags-over-my-head bug in libxpm
[21:46] <Chipzz> where the -nox version, despite its name, does depend on x11
[21:46] <Chipzz> :P
[21:49]  * ScottK head desk.
[21:50] <ScottK> slangasek: My apologies for messing up the freeze.  I just uploaded to the main repo instead of my PPA.
[21:50] <ScottK> slangasek: It's kdeguidance.
[21:51]  * ScottK goes to make a revision that reverts all that.
[21:52] <slangasek> heh
[21:53] <Chipzz> cjwatson: I wouldn't call it "hardly an issue" though
[21:54] <Chipzz> the presence of that library on a shell-server enables users to upload binaries linked against it, and run them
[21:54] <Chipzz> (which I guess could also be done if statically compile the app in question)
[22:05] <Amaranth> Jyaku: Are you a bot?
[22:05] <Jyaku> Amaranth: You are the sun shine we4ll shine together told you i4ll always be your friend.
[22:05] <Amaranth> *cough*
[22:05] <Amaranth> Just to warn you guys, Jyaku is a log bot from this annoying website we're trying to get rid of
[22:05] <Amaranth> But I don't have access in here :)
[22:07] <laga> who's "we"? i thought someone approved them for the ubuntu namespace
[22:08] <mneptok> that will be quite enough of that
[22:09] <ScottK> slangasek: New kdeguidance uploaded that except for an embarrasing debian/changelog entry is the same as the old one.
[22:09] <Amaranth> laga: Not those ones
[22:09] <Amaranth> laga: This is a new one who is hostile in emails about the situation, evading bans, and locking out the status of where the bots are on their website
[22:10] <laga> Amaranth: ah, even worse than the old one
[22:10] <Amaranth> it grabs links and reports who said then and when
[22:12] <laga> ah. quite close to spammers then
[22:37] <TheMuso> ScottK: woops. :p
[22:37] <ScottK> TheMuso: Yep.
[22:44] <crimsun_> \sh_away: RE 144356, someone needs to chase libflashsupport
[22:55] <cjwatson> Chipzz: for that last reason, I think "hardly an issue" is entirely fair. The presence of libx11-6 doesn't give any extra privileges anyway.
[23:04] <Chipzz> cjwatson: I tend to disagree. newbies can RTFM and type ./configure ; make ; make install and scp, but to link something statically requires more intimate knowledge
[23:05] <cjwatson> Chipzz: if it doesn't grant extra privileges, it's not a problem
[23:06] <cjwatson> I stand by my claim
[23:07] <Chipzz> I have seen this on servers, so it's a real problem. But lets agree to disagree :)
[23:07] <cjwatson> I have seen people typing 'cat' on servers too, but that's not a problem either
[23:08] <cjwatson> no extra privilege
[23:08] <Chipzz> the problem is the resources x apps tend to consume
[23:08] <cjwatson> use resource limiting if that bothers you
[23:09] <wasabi> latest update today has caused gnome-settings daemon to not start, and then gnome-session to close. just in the problem is more than me. :0
[23:09] <wasabi> don't suppose one of you broke it? eh eh eh?
[23:09] <Chipzz> ok, you got a point there I guess
[23:10] <wasabi> SIGSEGV in rw_screen_list_outputs().  fun!
[23:11] <james_w> wasabi: the latest upload of gnome-desktop may fix this. If not then a new upload of g-s will hopefully do so. (or was it g-settings-daemon?)
[23:14] <wasabi> ahh well, as long as it's well known
[23:14] <wasabi> how'd it happen in a feature freeze?
[23:15] <cjwatson> bryce's xrandr gui work was granted an explicit exception
[23:16] <wasabi> "oops!"
[23:16] <cjwatson> exceptions always come with risks
[23:16] <cjwatson> I don't regard it as an oops
[23:16] <wasabi> Me neither. I am just being sarcastic.
[23:16] <wasabi> I have no problems or complaints.
[23:17] <wasabi> Oh hey. Kick ass. This GUI thing is *awesome*
[23:17] <wasabi> This crash has made me aware of it.
[23:19] <wasabi> bryce: crazy suggestion. You draw boxes for each screen. Within the box you put the name of the display device. Within each box put the name of all display devices which receive a copy of the screen. Including clones. </random feature request>
[23:20] <wasabi> and allow dnd of the device outside of the screen either onto the surface itself to create another screen, or within an existing screen.
[23:21] <wasabi> Maybe use icons within the boxes instead of the device names themselves. So you can drag a projector from one screen to another to duplicate it's output.
[23:23] <wasabi> Or maybe an icon view of devices lined up, and you acn drag those onto the surface
[23:28] <doko> ScottK: a separate package should work, yes