[12:37] <Kopfgeldjaeger> Gute Nacht (verdammt, schon so spt?)
[12:40] <Riddell> doko_: do you have an opinion on bug 134994?
[12:40] <ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,New]  https://launchpad.net/bugs/134994
[12:40] <alex-weej> does Ubuntu have an application naming policy (e.g. for Desktop Entry files)?
[12:40] <Utnubu> hi all
[12:41] <cjwatson> alex-weej: delegated to desktop environments which generally do
[12:41] <cjwatson> the GNOME HIG at least does, I believe
[12:41] <alex-weej> cjwatson: ok, but they're not exactly compatible with other upstreams
[12:41] <cjwatson> that's as may be, but no policy would be
[12:41] <alex-weej> cjwatson: i'm thinking we should have one, and patch our packages to be consistent
[12:42] <Utnubu> Since compiz is enabled per default in Gutsy or at least everything is ready for it why compizconfig-settings-manager isn't installed per default?
[12:42] <cjwatson> alex-weej: so a different incompatible policy? I'm sure that would be excellent and really justify the work ;-)
[12:42] <alex-weej> it seems that some applications are just "Name" ("Qalculate!"), others are "Generic Name" ("Text Editor")
[12:42] <alex-weej> and in many cases they're not even the right name
[12:42] <alex-weej> for example we're calling Impress "OpenOffice.org Presentation"
[12:42] <alex-weej> when it starts up, it's called OpenOffice.org Impress everywhere
[12:43] <alex-weej> same with Text Editor and gedit
[12:43] <alex-weej> (that's one upstream not even eating their own dog food)
[12:43] <Riddell> alex-weej: I think the gnome packagers edit some names to make them more generic
[12:43] <Riddell> which is the wrong way to do it in my opinion, it should just use GenericName if that's what they want
[12:43] <alex-weej> cjwatson: it would confuse users less. I don't know why we had to rename OpenOffice components.
[12:43] <alex-weej> Riddell: (agreed, fwiw)
[12:44] <cjwatson> OpenOffice.org Presentation seems more consistent with http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-names to me
[12:44] <cjwatson> likewise Text Editor
[12:45] <alex-weej> cjwatson: but that's not what it's called... it's called Impress - i'd say changing the name of upstream programs isn't doing anyone any favours
[12:45] <cjwatson> you asked if there was a policy; I answered you ...
[12:45] <alex-weej> cjwatson: i'm justifying the need for our own
[12:45] <alex-weej> as we are the ones who have to mix everything together and call it a product
[12:46] <mjg59> The policy is, where possible, to provide applications with a menu entry along the lines of (specific name) (generic name)
[12:46] <cjwatson> not to disagree with the fact that we're integrators, but I think where desktop entries are concerned the desktop environment upstreams also have some experience as integrators
[12:46] <mjg59> So you get OpenOffice Presentation or Epiphany Web Browser
[12:47] <cjwatson> I think Impress is a particularly poor choice of application to try to make a point about here
[12:47] <alex-weej> the problem is that it's "OpenOffice.org Impress Presentation Editor"
[12:47] <mjg59> Not in any real sense, no
[12:47] <cjwatson> OpenOffice.org is a perfectly sufficient brand on its own and Presentation is a lot clearer in the menu entry than Impress
[12:48] <alex-weej> cjwatson: so we need to change a OOo strings to read "OpenOffice.org Presentation"
[12:48] <alex-weej> and that raises confusion for ex-Windows users
[12:48] <alex-weej> who are used to using Impress for creating "powerpoints"(!)
[12:48] <cjwatson> that sounds like a lot more work for much less benefit
[12:48] <alex-weej> at least it's consistent with itself
[12:49] <cjwatson> the menu entry is the first point of entry
[12:49] <cjwatson> anyway, bed
[12:49] <mjg59> alex-weej: No. The idea that the menu entry is the real name of the program is incorrect.
[12:49] <alex-weej> Name=OpenOffice.org Impress;GenericName=Presentation Editor
[12:49] <Amaranth> gnome-menus doesn't support GenericName :)
[12:49] <alex-weej> mjg59: desktop entry files aren't menu entries
[12:49] <mjg59> alex-weej: THe menu entry provides enough information for you to know what the program is, and also what specific instance of that class of programs it is
[12:49] <alex-weej> mjg59: desktop entry files describe applications
[12:50] <cjwatson> http://standards.freedesktop.org/desktop-entry-spec/latest/ "how it appears in menus, etc."
[12:50] <SwellJoe> Anyone have a pointer to an example of running "apt-ftparchive release" that doesn't lead to a zero-sized "Release" entry in the Release file (and an error when using the resulting repo)?
[12:50] <Amaranth> alex-weej: desktop entry files tell you what the application is and what it does
[12:50] <mjg59> alex-weej: Providing the full title of the application provides no benefit to our users. Nor does changing the name of a program to be the same as its menu entry.
[12:50] <Amaranth> alex-weej: so OpenOffice.org Presentation fits fine
[12:50] <Amaranth> so does Text Editor
[12:50] <alex-weej> but when I install Foo Text Editor
[12:50] <Amaranth> no matter what the application says it is
[12:51] <alex-weej> and i have the choice of Text Editor and Foo Text Editor, it just looks stupid
[12:51] <mjg59> That's an argument for names which are entirely generic to include a specifier
[12:51] <Amaranth> alex-weej: well it would be GNOME Text Editor but since that would end up with you seeing GNOME everywhere it's stripped off
[12:51] <mjg59> Not an argument for changing OpenOffice Presentation to OpenOffice Impress
[12:51] <alex-weej> Amaranth: no, it's Name=GEdit;GenericName=Text Editor
[12:52] <alex-weej> mjg59: right, it's two separate arguments about cleaning up the same messy
[12:52] <alex-weej> *mess
[12:52] <Amaranth> alex-weej: No it's not
[12:52] <Amaranth> it's Name=Text Editor
[12:52] <alex-weej> Amaranth: i was speaking hypothetically
[12:52] <Amaranth> alex-weej: gnome-menus does not support GenericName
[12:53] <alex-weej> then that's too bad
[12:53] <Amaranth> and it's a bit of a compatibility break if you change it now
[12:53] <Amaranth> because lots of apps would have to be changed
[12:53] <alex-weej> what are we going to break compatibility with? the current mess?
[12:53] <Amaranth> Yes
[12:53] <mjg59> Sigh.
[12:53] <Amaranth> Although I wouldn't call it a mess
[12:53] <mjg59> This conversation is not aiding Ubuntu development.
[12:53] <Amaranth> It is not
[12:54] <mjg59> If you have a concrete proposal, write it up.
[12:54] <Amaranth> alex-weej: #gnome-hackers :)
[12:54] <alex-weej> Epiphany has a name, "Epiphany". Totem has a name "Totem", Impress has a name "Impress"
[12:54] <mjg59> But you're not going to convince the development team by having an argument on IRC at a time when most of them are in bed
[01:35] <halcyonCorsair> hi, can anyone tell me how limits are dealt with in ubuntu/debian? (ie. limits.conf?)
[03:26] <ion_> stevenk, doko: Since you have rebuilt openoffice.org-voikko previously to regenerate dependencies, id like to bring bug #135426 to your attention. Thanks.
[03:26] <ubotu> Launchpad bug 135426 in openoffice.org-voikko "Needs a rebuild" [Undecided,New]  https://launchpad.net/bugs/135426
[03:30] <qid> anyone know where I can get the wireless tools packages for gutsy 7.10? I'm attempting to follow the suggested workaround here: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214/comments/48
[03:30] <ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
[03:31] <StevenK> ion_: Another rebuild? Oh, duh, OO.o 2.3
[03:33] <StevenK> ion_: I shall do that in the next little while.
[03:33] <ion_> openoffice.org-voikko depends on openoffice.org-core (>= 2.3.0~src680m224) and openoffice.org-core is being upgraded from 2.3.0~src680m224-1ubuntu2 to 1:2.3.0~oog680m1-1ubuntu3
[03:33] <ion_> Thanks
[03:36] <StevenK> ion_: openoffice.org-voikko 2.0.1-1build3 uploaded
[03:37] <ion_> Yay
[04:42] <ctkroeker> does the new screen gui support setting up dual monitors set up on dual video cards? i.e. an onboard SIS and a cheapo nvidia...
[05:08] <moquist> Can I get away with using bash for the postinst in a package intended for main?
[05:08] <moquist> (instead of sh)
[05:11] <sbalneav> moquist: Don't think so, but, if yo need help converting bashisms to dashisms, I'm your man :)
[05:12] <mneptok> moquist: dash was chosen for sh for a reason. the clock moves in one direction. :)
[05:12] <moquist> sbalneav: if [ $(wc -l <<<"$o") != 1 ] ; then
[05:12] <moquist> sbalneav: But I may just change several things, so that line may just go away.
[05:14] <sbalneav> if [ $(echo "$o" | wc -l) != 1 ] ; then...
[05:16] <moquist> sbalneav: I'm making things way too hard on myself. :)
[05:18] <kirkland> mneptok: I'm curious of the reason...  is dash statically linked or something?  simpler?  faster?
[05:18] <RAOF> Simpler & faster.
[05:19] <sbalneav> Posix Compliant.
[05:36] <Hobbsee> bah.  i thought i was almost going to get lucky
[05:37] <Hobbsee> it looked like the open network was going to connect with the mangler, and ipw394
[05:37] <Hobbsee> 5
[06:06] <sbalneav> Anyone got a feisty box handy?
[06:06] <sbalneav> check this out:
[06:06] <sbalneav> start up dash
[06:07] <sbalneav> echo foo bar baz | if read I J K; then echo i: $I; echo j: $J; echo k: $K; fi
[06:07] <sbalneav> segfault!
[06:11] <nixternal> sbalneav: works for me
[06:11] <nixternal> but then again, that is with bash :)
[06:11] <nixternal> works in dash for me as well
[06:11] <StevenK> Neat!
[06:12] <StevenK> k: baz
[06:12] <StevenK> zsh: segmentation fault (core dumped)  dash
[06:12] <sbalneav> gutsy or feisty?
[06:12] <nixternal> gutsy
[06:12] <sbalneav> It works for me in gutsy, but not feisty.
[06:12] <sbalneav> Hence, the reason why I asked if anyone had a handy feisty :)
[06:12] <stdin> works on my feisty box
[06:13] <sbalneav> In bash, or dash?
[06:13] <stdin> bash
[06:13] <stdin> and dash
[06:13] <sbalneav> We've got 3 people who that segfaults with in dash on feisty.
[06:13] <nixternal> oh, what is feisty :p
[06:13] <nixternal> I haven't used Feisty since umm, it released :)
[06:13] <sbalneav> What's out there right now.
[06:15] <StevenK> Does it segfault in Gutsy?
[06:15] <sbalneav> No.
[06:16] <sbalneav> Not for me at least.
[06:16] <StevenK> Does for me.
[06:16] <StevenK> Maybe it's an AMD64 ism
[06:16] <sbalneav> It's something.
[06:16] <sbalneav> It's weeeeiiiird is what it is :)
[06:16] <StevenK> Doesn't segfault in 32 bit.
[06:17] <sbalneav> moquist bumped into it.
[06:18] <moquist> I wonder if it's something in my environment.
[06:19] <sbalneav> Well, even if it is, segfaulting wouldn't be the preferred way to handle it :)
[07:16] <StevenK> doko__: Ping, what are your thoughts about bug 134994?
[07:16] <ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,New]  https://launchpad.net/bugs/134994
[09:53] <lucas> a lot of packages (21) fail to build in universe because libxext-dev was dropped from the depends of libx11-dev
[09:53] <lucas> the change hasn't hit debian unstable yet, so there's no fix to pick in debian
[09:54] <fabbione> lucas: it probably means that you need to fix those 21 packages to Build-Dep on libxext-dev if they need that library
[09:55] <lucas> we could fix those 21 packages, and then sync them during the gutsy+1 cycle, or we could re-add that dep for gutsy, and wait until debian fixes its packages (which will happen during the gutsy+1 cycle)
[09:55] <lucas> re-adding the dep seems harmless. it was dropped because of #366676
[09:56] <lucas> (I talked with julien cristau, and he plans to push that change to unstable, not revert it)
[09:57] <fabbione> lucas: well there is a fix in there by breaking a loop in the build dep
[09:57] <fabbione> lucas: not that it really matters were we are now
[09:58] <fabbione> but either fix the 21 packages or revert that change is kind of harmless
[09:58] <fabbione> i would personally prefer to fix the packages.. clean and proper solution
[10:03] <lucas> ok
[10:25] <seb128> Riddell: could we update bluez-gnome (bug #134462)?
[10:25] <ubotu> Launchpad bug 134462 in bluez-gnome "[UVFe]  Please review merge of bluez-gnome (0.13-1) from Debian unstable (main) (was: Can you upgrade bluez-gnome to 0.13 version in gutsy because of the lot of bugfixes and better translations)" [Wishlist,Incomplete]  https://launchpad.net/bugs/134462
[10:48] <atlas95> hello
[10:49] <atlas95> i want little help in C, how to define a char in C please?
[10:50] <atlas95> for exemple: long myVar="blabla"
[10:50] <atlas95> don't work
[10:50] <atlas95> and char="blabla" don't work too
[10:50] <atlas95> i'm newbie
[10:55] <seb128> atlas95: that's not the right channel to learn C
[10:55] <atlas95> yes sorry :)
[10:56] <atlas95> what is the goood?
[10:56] <atlas95> Cnewbie is empty
[10:56] <seb128> no idea
[10:56] <coNP> atlas95: ##c maybe
[10:56] <seb128> but you can find C tutorials on google easily
[10:56] <atlas95> only 440 users on ##c
[10:56] <atlas95> :p
[10:57] <atlas95> thanks ;)
[11:07] <Riddell> seb128: which of the changes are you wanting to get from the new version?
[11:08] <seb128> Riddell: lot of bug fixes
[11:09] <Riddell> seb128: http://launchpadlibrarian.net/8999403/diffstat.txt only lists three, is there a more complete changelog?
[11:11] <seb128> Riddell: I'll ask the people who wanted the update to add details
[11:11] <seb128> http://launchpadlibrarian.net/8999404/changelog.diff
[11:11] <seb128> that's the upstream changelog
[11:12] <Riddell> seb128: do you have people testing it?
[11:12] <seb128> no
[11:13] <seb128> I was expected getting an approval easily
[11:13] <seb128> I'll ask them if they tested it, etc
[11:13] <Riddell> seb128: I'm happy to approve it but only if there's people to test it :)
[11:13] <seb128> we need a proper UVF exception procedure for main
[11:14] <Riddell> seb128: well, this is it (properly you should subscribe ubuntu-archive, but I'm fine with IRC too if I'm not busy)
[11:15] <Kmos> or subscribe ubuntu-release
[11:15] <Kmos> for others (simple users)
[11:15] <Riddell> err, aye, that's what I ment
[11:15] <Riddell> too many hats
[11:17] <seb128> Riddell: the new gnome-bluez is in Debian for almost a month if you consider that as some testing ;)
[11:18] <Riddell> seems like a fair criteria
[11:18] <Riddell> seb128: go ahead
[11:18] <seb128> Riddell: thanks
[11:22] <Kmos> Riddell: bug 132405
[11:22] <ubotu> Launchpad bug 132405 in xterm "Please sync xterm (229-1) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/132405
[11:22] <Kmos> Riddell: i've answered you
[11:24] <tepsipakki> who is holding the archive hat today?
[11:24] <tepsipakki> um, archive _admin_ hat ..
[11:26] <tepsipakki> but 133793
[11:26] <tepsipakki> f***, bug 133793
[11:26] <ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Incomplete]  https://launchpad.net/bugs/133793
[11:26] <Riddell> tepsipakki: seb128
[11:26] <tepsipakki> Riddell: thanks
[11:26] <tepsipakki> seb128: ^^
[11:27] <seb128> tepsipakki: "Incomplete", doesn't look good for you
[11:27] <Riddell> Kmos: is xterm.log.html a changelog?
[11:27] <tepsipakki> seb128: right, I can change that :)
[11:27] <Riddell> Kmos: yes, it seems to be, please include the latest changes entry in the bug
[11:28] <seb128> tepsipakki: I'll do the sync
[11:28] <Riddell> bryce: do you have an opinion on bug 132405?
[11:28] <ubotu> Launchpad bug 132405 in xterm "Please sync xterm (229-1) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/132405
[11:28] <tepsipakki> seb128: excellent, thanks
[11:29] <Kmos> Riddell: the xterm doesn't have any changelog
[11:30] <Riddell> Kmos: so what is xterm.log.html?
[11:30] <Kmos> Riddell: i found another bug on LP about xterm that will fix with 229-1, i've commented there
[11:30] <Kmos> Riddell: hmm.. let's check that
[11:32] <Riddell> Kmos: err, it removes the .desktop file?  how is someone ment to run it then?
[11:33] <tepsipakki> those were added upstream not too long ago
[11:33] <tepsipakki> +by
[11:33] <seb128> xterm .desktop?
[11:33] <tepsipakki> uyes
[11:33] <seb128> those need to use a NoDisplay=true
[11:33] <tepsipakki> damnit, I can't type today..
[11:33] <Riddell> seb128: why?
[11:33] <seb128> because they are not nice creating a system tools category on the default desktop
[11:34] <tepsipakki> seb128: they were removed by debian
[11:34] <seb128> Riddell: because we install xterm for whatever reason and it's not nice to have 3 terminal emulator in the default installation
[11:34] <Riddell> seb128: if it's a problem having it in the default desktop, why not remove it from the seed?
[11:34] <seb128> Riddell: I except we have it by default because it's part of the basic debug tools
[11:35] <seb128> like the debug login is running Xorg with an xterm
[11:35] <Kmos> Riddell: done
[11:35] <\sh> Riddell, you don't want to remove xterm from the seeds..xterm is default and should be installed by default
[11:35] <seb128> s/except/expect
[11:37] <Riddell> \sh: is default for what?
[11:37] <cjwatson> xterm is used by the failsafe session
[11:37] <cjwatson> oh, seb said that
[11:38] <cjwatson> I think moving it to Accessories would be better than removing it, though
[11:38] <\sh> Riddell, default for every X installation I know, and it shouldn't be removed from the default install of Ubuntu...and the facts from seb and cjwatson, which are important too
[11:38] <cjwatson> gnome-terminal lives there (as does pterm, though that's incidental :-))
[11:38] <seb128> cjwatson: we would have gnome-terminal, xterm, uxterm there
[11:38] <cjwatson> seb128: yes
[11:38] <seb128> cjwatson: that start being a bit much terminal emulators wise to my taste
[11:39] <iwj> ion_: Hmm.  In theory, yes, triggers could improve that.  But the structure of the way the initramfs's are added and removed would have to be changed and I think we may be a bit late in the release cycle for that change.
[11:42] <Kmos> anyone wants to sync bzr-gtk ? v0.90.0 from debian is out
[11:42] <Kmos> gutsy has 0.18.0
[11:42] <Kmos> :)
[11:43] <cjwatson> not until bzr 0.90 is also in gutsy
[11:43] <cjwatson> and I think we should possibly wait for a non-release-candidate there
[11:45] <Riddell> "adapt xterm.menu to the new menu structure" do we use the new menu structure?
[11:47] <Kmos> Riddell: nop
[11:49] <Riddell> so that should probably be changed for any sync?
[11:50] <Kmos> Riddell: but it still works in gutsy.. even with new menu structure
[11:50] <Kmos> in the new package
[11:50] <Riddell> ok, magic
[11:50] <geser> Riddell: doesn't this only affect the Debian menu which Ubuntu doesn't use?
[11:51] <tepsipakki> I bet there are other packages in gutsy already which have made that change
[11:51] <cjwatson> Kmos: you say "fixes many bugs" but the changelog lists two changes. What is your definition of "many"?
[11:51] <Kmos> tepsipakki: yep, a lot of them
[11:51] <Kmos> cjwatson: you check the changelog from xterm ?
[11:51] <cjwatson> Kmos: yes
[11:51] <Kmos> cjwatson: i'm refering to them also
[11:52] <cjwatson> the upstream changelog is what I'm talking about
[11:52] <cjwatson> * override locale in minstall.sh; change in patch #226 does not work in UTF-8 locale (report by Zdenek Sekera).
[11:52] <cjwatson> * undo an incorrect fix for a memory leak in (Debian #435858).
[11:52] <cjwatson> that's not "many bugs"
[11:52] <ubotu> Debian bug 435858 in xterm "xterm: crashes on non-existent wide bold font" [Normal,Fixed]  http://bugs.debian.org/435858
[11:52] <Kmos> cjwatson: open http://invisible-island.net/xterm/xterm.log.html
[11:52] <Kmos> and click on patch #226 and #209
[11:52] <cjwatson> stop telling me to do that. I already did.
[11:53] <Kmos> :)
[11:53] <tepsipakki> Kmos: those are only links to previous releases
[11:53] <cjwatson> why are the contents of patches #226 and #209 relevant? we already have those
[11:53] <cjwatson> the changelog is indicating that it fixes problems in those patches
[11:53] <cjwatson> we already have everything up to patch #228
[11:54] <Kmos> cjwatson: and two LP bugs..
[11:54] <cjwatson> this is still not "many". you were exaggerating the importance and I'm calling you on it.
[11:55] <Kmos> cjwatson: i understand.. but english in not my primary language :) many.. a few ones =)
[11:55] <Kmos> two =)
[11:55] <cjwatson> ah, that defence
[11:55] <cjwatson> I assume you will know in future and not exaggerate two-change upstream releases using the word "many" then?
[11:56] <cjwatson> the default behaviour after UVF is not to accept new upstream releases
[11:57] <Kmos> cjwatson: yes i know.. I just won't ask for any =) I've already told hobbsee
[11:57] <Kmos> that's better for ubuntu, lol
[11:58] <cjwatson> but you just did ask
[11:58] <cjwatson> though admittedly that bug dates from before UVF
[11:58] <Kmos> yeah, it's 2007-08-14
[11:59] <Kmos> but I've done all procedures like UVFe
[11:59] <Kmos> like i've done for rdiff-backup that's approved yesterday
[12:02] <Kmos> bug 129572
[12:02] <ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129572
[12:02] <Kmos> this one stopped after first ack from hobbsee
[12:02] <Kmos> days agoo
[12:37] <Kmos> seb128: thx for the sync
[12:38] <seb128> Kmos: you're welcome
[12:39] <soren> cjwatson: Is the installation-guide kept in svn or bzr or something somewhere?
[12:43] <soren> cjwatson: Or do you just use the debian svn and apply a patch each time?
[12:44] <cjwatson> soren: the latter
[12:45] <soren> cjwatson: Alright. Thanks.
[12:45] <cjwatson> it's just a source package at the moment. if I ever manage to get a bzr import of it then I'll move to that
[12:45] <cjwatson> oh, hey, what do you know
[12:45] <soren> cjwatson: https://code.launchpad.net/~vcs-imports/installation-guide/trunk
[12:45] <cjwatson> yeah, I just found that too :)
[12:45] <soren> :)
[12:45] <cjwatson> I'll migrate to that at some point then, but please let me do it as I have all the history
[12:46] <soren> Sure, sure.
[12:47] <soren> cjwatson: You wouldn't happen to know if there's a PDF version of it somewhere, would you?
[12:52] <doko> Riddell: looks ok to me
[12:54] <Riddell> doko: thanks
[12:55] <ogra> iwj, would you mind to take a look at the libxml++2.6 MIR to unblock gobby (was added as new dep in the latest release)
[12:55] <iwj> ogra: Sure.
[12:55] <ogra> thanks :)
[12:58] <cjwatson> soren: yes, in installation-guide-$ARCH.deb
[12:59] <soren> cjwatson: Oh, so it is!
[12:59] <soren> I thought it needed not-quite-free stuff to build the pdf's.
[01:02] <StevenK> doko: Ping, what are your thoughts about bug 134994?
[01:02] <ubotu> Launchpad bug 134994 in python-central "UVF Exception for python-central" [Undecided,Confirmed]  https://launchpad.net/bugs/134994
[01:03] <soren> https://wiki.ubuntu.com/DocumentationTeam/BuildingDocumentation/PDF suggests this is the case..
[01:12] <MinuteElectron> Hi may I make a suggestion?
[01:13] <somerville32> MinuteElectron: Sure.
[01:14] <MinuteElectron> On the installer can you make it so when you press up on the top option of the main menu it goes to the bottom. It seams trivial but I install often and it gets rather tedious and I nearly always make the mistake.
[01:14] <cjwatson> could you file a bug on https://blueprints.launchpad.net/ubuntu/+source/cdebconf/+filebug for that, please?
[01:14] <cjwatson> sounds reasonable to me
[01:15] <MinuteElectron> ok
[01:15] <MinuteElectron> thanks
[01:15] <cjwatson> though it would mean that you couldn't just hold down up-arrow for a while to get to the top
[01:18] <MinuteElectron> done
[01:18] <MinuteElectron> #135543
[01:18] <MinuteElectron> thank you
[01:19] <cjwatson> soren: we clearly manage it ;-)
[01:20] <iwj> We're conducting a campaign against .la files, right ?
[01:34] <Kopfgeldjaeger> hi
[01:34] <ogra> thats what they all say ...
[01:37] <Chipzz> Kmos: hobbsee already told you quite extensively why she didn't reply on your powertop sync request any more yesterday; why do you bring it up again then?
[01:37] <Kmos> Chipzz: because if she doesn't want, maybe someone else want to.
[01:38] <Chipzz> Kmos: also, sync requests are NOT about finding as many packages as possible that have a new version in debian or upstream, and requesting a sync request for all of them just for the sake of it
[01:38] <Chipzz> and you have also been told that
[01:39] <Kmos> Chipzz: yeah.. but as you can see isn't about to find many packages possible. it's about credibility
[01:39] <Chipzz> almost sounds like you don't get what a sync request is
[01:39] <Kmos> Chipzz: but for that, I won't ask for any syncs anymore
[01:39] <Kmos> just want the ones i've waiting done for gutsy
[01:39] <Kmos> like the powertop that still an RC in gutsy
[01:40] <Chipzz> Kmos: maybe your credibility is related to the number and quality of the sync requests you file?
[01:40] <Kmos> 1.8 is the final
[01:40] <Kmos> Chipzz: don't think so.. you can check all of them =)
[01:40] <Kmos> it's about the number
[01:40] <Kmos> quantity :)
[01:41] <Chipzz> a sync request is about synchronizing it because it actually has a concrete use; ie it fixes one (or more) bugs we care about
[01:42] <Chipzz> and care about means "not just some random bug"
[01:42] <Kmos> yeah, I know
[01:43] <Chipzz> the idea is to actually get packages stable in preparation for a release; that means, no new features, and be carefull about what bugs they fix
[01:43] <Chipzz> because every change can introduce a new bug
[01:43] <Chipzz> so the bugfix for a minor bug may very well introduce one or more more severe bugs
[01:44] <Fujitsu> This is what cherrypicking is for.
[01:46] <Kmos> Chipzz: yep, I know that.. I'm also a developer :)
[01:47] <Chipzz> Kmos: then *why* do you show so little intelligence and common sense?
[01:47] <Chipzz> for example in filing these sync requests?
[01:47] <Chipzz> I'm guessing that's why people get mad at you
[01:47] <Kmos> Chipzz: have you checked the sync requests i asked for ?
[01:48] <Kmos> Chipzz: maybe it's that, and that's because I won't file sync requests
[01:48] <Kmos> anymore
[01:48] <Chipzz> Kmos: quite frankly I don't need to if I see Hobbsee's comments
[01:49] <Kmos> Chipzz: if you think that, that's your problem
[01:49] <Kmos> *like that
[01:49] <Chipzz> Kmos: my guess is people get mad at you because despite the fact that they've explained several things to you several times, you just don't seem to get the general idea and spirit behind it
[01:50] <Chipzz> Kmos: I'm not calling you dumb, I'm just saying that you should try to understand why what you're doing is wrong, and learn from that
[01:51] <Chipzz> but the last part (learning from that) is what's missing apparently, and that's why people get mad at you
[01:51] <Kmos> I always be criticized from whatever I do, so I choose not to contribute directly to ubuntu, even file sync requests
[01:51] <Kmos> i don't want hobbsee to be mad, and motu people.. they're the best, so do their job.. i'll participe from now on getdeb.net
[01:52] <Chipzz> Kmos: no you won't; but have you understood what I'm trying to say?
[01:52] <infinity> Kmos: The -release team works as a team, we back each other up.  If one of us turns down a UVF exception, please don't make an end-run around them and ask another.
[01:52] <Kmos> with my packages and with people really needs
[01:52] <Kmos> Chipzz: yes.
[01:52] <infinity> Kmos: We're not divorced parents you can play off each other to satisfy your whims.  Hobbsee's decision is just as final as anyone else's on the team.
[01:53] <Kmos> I think another one has sent an e-mail to devel mailing list about me..
[01:53] <Chipzz> Kmos: what you seem to lack is not intelligence, just an understanding about what things like a release process are
[01:53] <Kmos> infinity: so what's hobbsee decision ?
[01:53] <infinity> Kmos: In my scrollback, I saw mention of her turning down one of your requests, and you asking someone else instead "in case they might want it".  Don't do that.
[01:54] <infinity> Kmos: It just wastes our time to have multiple team members going over the same requests over and over again until you get your desired result.
[01:54] <Kmos> infinity: she told me she won't process my requests. so I need someone else to do it
[01:54] <Chipzz> infinity: 13:37 < Chipzz> Kmos: hobbsee already told you quite extensively why she didn't reply on your powertop sync request any more yesterday; why do you bring it up again then?
[01:54] <Chipzz> infinity: ;)
[01:54] <Chipzz> oh
[01:54] <Kmos> these are my final requests, i won't ask for more anymore
[01:54] <Chipzz> at leet-o-clock even :)
[02:32] <mantiena-baltix_> who is responsible for kernel bugs ? there is big problem because 7.04 (feisty) CD doesn't  start on lots of new laptops. based on Intel santarosa platform
[02:32] <mantiena-baltix_> look at bug #126653 for example
[02:32] <ubotu> Launchpad bug 126653 in linux-source-2.6.20 "Feisty kernel cannot detect CD/DVD (SCSI based)" [Undecided,New]  https://launchpad.net/bugs/126653
[02:33] <StevenK> Why do I have this feeling it's SATA based, as opposed to SCSI?
[02:33] <cjwatson> mantiena-baltix_: the kernel team. #ubuntu-kernel
[02:33] <mantiena-baltix_> it's interesting, that older and newer Ubuntu versions, also. it seems, feisty kernels (from Ubuntu 7.04 beta) detects cdrom fine
[02:34] <mantiena-baltix_> cjwatson, thanks, should I repeat my post there ?
[02:34] <mantiena-baltix_> StevenK, I also think, that it's SATA :)
[02:36] <cjwatson> mantiena-baltix_: it'd be more useful than here, at any rate
[02:43] <Hobbsee> oops, sabdfl flooded due to the waves.
[02:43] <xxxxx1> hey sabdfl
[02:44] <Hobbsee> sabdfl: when waves are made, please dont flood, or drown.  it's really quite inconvenient.
[02:49] <somerville32> 8.04 seems like such a "mature" number, <g>
[02:50] <highvoltage> somerville32: it's almost 9.0! we can compete with old red hat versions!
[02:51] <somerville32> I was hoping for Hungry Hippo myself
[02:52] <\sh> as jdub wrote...it's pr0n ,-)
[02:52] <StevenK> The urban dictionary is ... not exactly authoritative.
[02:53] <Hobbsee> StevenK: that was a example
[02:53] <ogra> somerville32, seems everybody was
[02:54] <StevenK> Hobbsee: Point.
[02:55] <\sh> ogra: what's the best german translation for Hardy Heron, abgehrteter Reiher oder Khner Reiher?
[02:55] <somerville32> The Urban Dictionary tells me that Heron is slang for a number of things
[02:56] <ogra> \sh, robuster reihern
[02:56] <ogra> err
[02:56] <ogra> -n indeed :)
[02:56] <Hobbsee> the first thing i think of is the hardy heroin users that develop the release.
[02:56] <somerville32> Is Ubuntu 8.04 "a girl that club hops every thursday , friday and saturday night to see how many numbers she can get or how many guys she can make out with or how many free drinks she can get per night"?
[02:56] <ogra> Hobbsee, no, its handy heroin we provide to our ubuntu addicts ;)
[02:57] <\sh> ogra, we should file a bug at dict.leo.org ,-) robust is not known...but zhlebig :)
[02:57] <Hobbsee> ogra: ah right.
[02:57] <somerville32> haha
[02:57] <Hobbsee> somerville32: maliciously so, so goes and trashes any windows installs at the same time.
[02:59] <Hobbsee> ogra: there's the potential for so many drug jokes to be made here.  what fun.
[02:59] <cjwatson> somerville32: and once upon a time 5.10 seemed so unimaginably far away ...
[02:59] <somerville32> lol
[02:59] <mjg59> cjwatson: Once upon a time 4.10 seemed implausible
[02:59] <Hobbsee> cjwatson: yes, we know you're old :)
[03:00] <cjwatson> Hobbsee: heh
[03:00] <StevenK> It might just be easier to prepend a heredoc, sigh
[03:01] <Hobbsee> cjwatson: oh wait.  i shouldnt say that kind of thing around you, because you could bash me up.
[03:01] <cjwatson> er. could but won't
[03:01] <Hobbsee> cjwatson: oh good.  so i'm safe!
[03:01] <mjg59> Hobbsee: Colin's got a good 6 months of Ubuntu time over me
[03:01] <cjwatson> mjg59 is a sprightly youngster
[03:02] <cjwatson> mjg59: is that actually true? you were around in Oxford
[03:02] <mjg59> "So this guy who's been to space just rang me up and offered me a job"
[03:02] <StevenK> What does that make me then, having joined during Dapper?
[03:02] <mjg59> cjwatson: Oh, hm. 4 months? When did you join?
[03:02] <cjwatson> mjg59: spoke to Mark in Feb, actually joined in May
[03:02] <\sh> StevenK, a young padavan ,-)
[03:03] <mjg59> cjwatson: Ah, that would explain it. 3 months or so, then.
[03:03] <thom> you're both sprightly youngsters, really ;-)
[03:03] <cjwatson> maybe March, not sure
[03:03] <StevenK> \sh: You need to learn to spell. Or something.
[03:03] <thom> get orf my laaaand!
[03:04] <Hobbsee> bah.  crazy old man :P
[03:04] <\sh> StevenK, padavan -> a young jedi knight
[03:04] <Hobbsee> thom: just dont tell me all your money is in the freezer.
[03:04] <\sh> StevenK, oh sorry...s/v/w/
[03:04] <StevenK> \sh: It's a padawan, surely?
[03:05] <StevenK> thom: I used to be sprightlier. :-(
[03:07] <Hobbsee> that'll do.
[03:08] <\sh> Hobbsee, no taste...believe me :)
[03:09] <Hobbsee> drat
[03:10] <StevenK> Hum.
[03:13] <StevenK> Hurray for sponge!
[03:18] <Hobbsee> lamont: why?
[03:18] <Hobbsee> hiya mdz_
[03:18] <seb128> lamont: what were you saying about shared-mime-info?
[03:18] <lamont> it looks like I'm not subscribed as 'lamont.jones@u.c', so my first message evah to the ml was blocked for moderation
[03:18] <mdz_> morning
[03:18] <lamont> seb128: that libxml2 sucks
[03:18] <seb128> lamont: in what way? ;)
[03:19] <lamont> seb128: root cause came down to zlib1g diverting to 64-bit, pointer-returning functions but not defining them --> segv in libxml2 --> update-mime-info SEGV during install of shared-mime-info
[03:20] <seb128> lamont: oh, not good
[03:20] <lamont> of course, it'd be nice if libgnomevfs2-common was _removable_ in that situation, instead of barfing in postrm
[03:20] <lamont> seb128: yeah - I'm going to hack over sbuild on the ia64 buildd to ftbfs the package in those cases.
[03:21] <lamont> Hobbsee: does that mean that you're a moderator for u-users?
[03:21] <lamont> morning mdz_
[03:21] <Hobbsee> lamont: i am not.  i am for a few other lists, but not that one.
[03:21] <iwj> I have a MIR which I want to approve except that the -dev .deb contains a .la file.  Is that an approval-critical bug ?
[03:21] <Hobbsee> (kubuntu-devel, kubuntu-users, ubuntu-universe-sponsors, ubuntu-devel)
[03:22] <iwj> (I don't know what a .la is but I remember some people whose identities I've forgotten telling me they were EBW somehow and we were trying to get rid of them.)
[03:22] <Riddell> iwj: we have loads of libraries with .la files
[03:22] <iwj> Riddell: So we don't mind a new one ?
[03:22] <seb128> iwj: .la are fine, they are used for static builds (though not required on linux nowadays)
[03:22] <Riddell> iwj: can't imagine so
[03:23] <iwj> OK, I must have misunderstood.
[03:23] <siretart> iwj: speaking of MIRs, do you have news on the cryptsetup MIR?
[03:23] <seb128> iwj: we try to get ride of them since they often bring issues (like when you drop a depends from a lib you need to rebuild all the packages shipping a .la to reflect that)
[03:24] <lamont> iwj: .la files are how you wind up with horribly long build-depends lists that don't need to be that way other than for .la files.
[03:24] <iwj> seb128: Right.
[03:24] <iwj> Hmm.
[03:24] <lamont> nothing in the gnome universe should have them.
[03:24] <iwj> But is it an approval-critical bug if it does ?
[03:24] <lamont> and seb128 said it better
[03:25] <seb128> iwj: no, shipping them is not a bug
[03:25] <seb128> we just try to get ride of them to make things easier
[03:25] <iwj> siretart: No, I don't have any news but let me see the status.  (In general, feel free to chase me for MIRs.)
[03:25] <iwj> seb128: OK
[03:25] <StevenK> Damn it, find, *why* does -ctime have to be * 24 hours
[03:25] <lamont> well, if the package changes at a later date to not use a lib that it does today, and delivered a .la file, then that droppage will require a rebuild of everything that build-depends that package and delivers a .la file.   recursively
[03:25] <cjwatson> StevenK: does -cmin help?
[03:26] <StevenK> *blink* Didn't know that one.
[03:26] <cjwatson> still a stupid granularity but might be better
[03:26] <iwj> siretart: It's under `reviewed packages that need work' in the queue.  Looking at the review now.
[03:26] <StevenK> cjwatson: Indeed, thanks muchly
[03:27] <iwj> siretart: Seems nothing much has changed since my last review.
[03:27] <seb128> bah, apt sucks at describing why a package is not installable
[03:27] <siretart> ogra: I think you have been filing the mir. are you still working on it?
[03:28] <seb128> iwj: bug #135519, do you think those bugs could have an apt debug log or something like that?
[03:28] <ubotu> Launchpad bug 135519 in compiz "autopkgtest gutsy compiz amd64: erroneous package!" [High,New]  https://launchpad.net/bugs/135519
[03:28] <seb128> iwj: the bug has been opened on compiz but the issue is libcompizconfig0 not being installable and there is no detail (I think that's a transitional issue, mvo uploaded a new stack with Breaks use today)
[03:28] <iwj> seb128: I could probably organise that.  How would I acquire one ?
[03:29] <seb128> iwj: probably by setting Debug::pkgProblemResolver to true in the apt configuration
[03:29] <iwj> seb128: Right, if it's just a transitional problem feel free to close the bug with `this is fixed now we think'.
[03:30] <seb128> iwj: is there a way to determine that the bug is a "package not installable" and do a new try with this one set in this case?
[03:30] <iwj> The tester can't really tell if uninstallability is just transient or not.
[03:30] <iwj> I think it would be better just to turn on the debugging in general.
[03:30] <seb128> mvo: ^ what do you think?
[03:30] <iwj> Or to capture it and suck it out.
[03:30] <iwj> I mean, suck it out if the installation fails.
[03:31] <seb128> right, that would be nice
[03:32] <mvo> iwj: you could use some sort of greylisting, if the install fails, record that and then try again in ~4h (or some other value). if it fails then still, file a bug
[03:34] <seb128> mvo: would it be possible to make apt smarter about displaying errors?
[03:34] <seb128> it display package is not installable because <list of depends not installable>
[03:34] <seb128> but doesn't mention where is the issue in the list of depends
[03:34] <seb128> and what prevents it to be installed
[03:34] <mvo> seb128: probably
[03:35] <soren> I need a bit of assistance with some licensing stuff. There's a bug about enabling some additional modules in the php5 build. The two modules in question are readline and gmp. readline is GPL, while gmp is LGPL.
[03:35] <seb128> you usually have to apt-get install each of them to figure the bug
[03:35] <mvo> at least for simple cases
[03:35] <mvo> sometimes apt does not that itself ;)
[03:35] <soren> IIRC the php license is considered gpl-incompatible, so php5-readline would require an exception from the libreadline copyright holder, correct?
[03:35] <iwj> I've c&p the first bit of this irc conversation as bug 135581.
[03:35] <ubotu> Launchpad bug 135581 in autopkgtest "autopkgtest should provide apt debug log" [Undecided,New]  https://launchpad.net/bugs/135581
[03:35] <soren> What about gmp?
[03:36] <seb128> iwj: thanks
[03:37] <llllllllllllllll> bryce it's me lucky_lucas, I have to add something to the ati / compiz freezing problem
[03:37] <iwj> mvo: If you have some idea how I should improve this I'm all ears.
[03:37] <llllllllllllllll> I tried compiz on antoher pc with nvidia and it hangs too
[03:37] <iwj> mvo: Failing that I'll just make something up ...
[03:37] <superm1_> one of the archive admins got a sec?  I needed someone to release an update to an SRU that was release to -proposed a few days ago from the manual queue?
[03:37] <llllllllllllllll> seems to be a trouble in  X aiglx or compiz
[03:38] <seb128> superm1_: what do you mean?
[03:38] <superm1_> seb128, i got a mail from ubuntu-installer saying the distro release manager has to release them
[03:38] <mvo> iwj: the only idea I have is this greylisting, the disadvantage is that you have to carry around the state somewhere
[03:38] <superm1_> seb128, it was to feisty-proposed and edgy-proposed
[03:39] <iwj> mvo: No, I mean for getting more debug output.
[03:39] <seb128> superm1_: your description is not clear. They have been accepted to proposed yet or are you asking for that?
[03:39] <mvo> llllllllllllllll: what bugnumber is that?
[03:39] <iwj> mvo: Greylisting is an answer to transient problems, surely ?
[03:39] <mvo> iwj: yes, that is what I mean
[03:39] <seb128> mvo: there is 2 things, transient bugs and real bugs not having enough details
[03:40] <iwj> The question seb128 was asking was how to get more detail about the problem.
[03:40] <superm1_> seb128, sorry, the SRU was accepted to proposed a few days ago, but there were a few problems encountered with it, so I have a follow up for proposed in the queue right now
[03:40] <llllllllllllllll> mvo 134578
[03:40] <seb128> superm1_: use launchpad, subscribe ubuntu-sru, wait for approval, etc as described on the wiki
[03:40] <mvo> iwj: debug output> pkgProblemResolver=true and  Debug::pkgDepCache::AutoInstall=true
[03:40] <llllllllllllllll> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
[03:40] <superm1_> seb128, its a universe sru
[03:40] <ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,New] 
[03:40] <mvo> bug  134578
[03:40] <mvo> bug # 134578
[03:40] <mvo> bug #134578
[03:40] <seb128> superm1_: so ask on #ubuntu-motu was the procedure is
[03:41] <iwj> mvo: And that'll go where ?  Can I get it to go a separate file ?
[03:41] <mvo> seb128: yes, missed that
[03:41] <superm1_> seb128, as previously, the point in the procedure is that the archive admin needs to release it at this point, per the wiki
[03:41] <mvo> iwj: stderr, I could look into a redirect thing if you want
[03:41] <seb128> superm1_: so open a bug on launchpad and subscribe the ubuntu-archive team and wait for a team member to process it
[03:41] <superm1_> okay seb128 .  Thanks
[03:42] <seb128> you're welcome
[03:42] <iwj> If it could be sent into a file and there was a way to tell whether to dump the file into the log, that would be very nice.
[03:42] <seb128> superm1_: I looked at ubuntu-archive bugs this morning and there was nothing about that
[03:42] <iwj> I mean, the exit status or something would have to say whether it was a dependency problem.
[03:42] <superm1_> seb128, previously Riddell had just acked it without looking for a bug about it, so it wasn't apparent that i needed to file a bug to make it happen.
[03:43] <mvo> iwj: I made a note about this, I check it out
[03:43] <seb128> superm1_: well, pings on IRC don't scale
[03:43] <seb128> superm1_: that's not a replacement for a bug ;)
[03:44] <iwj> mvo: Thanks.
[03:45] <iwj> mvo: (I tried  apt-get -o pkgProblemResolver=true install some stuff  and it didn't seem to produce any output.  Obviously I'm doing it wrong.)
[03:46] <iwj> Ah, -o Debug::pkgProblemResolver=true
[03:46] <ogra> siretart, well, i was pondering encrypted swap by default for ltsp, but there has beeen no further work on it due to time constraints
[03:46] <mvo> iwj: apt-get install 4g8 -o Debug::pkgDepCache::AutoInstall=true -o pkgProblemResolver=true
[03:47] <lamont> mvo: 4g8 has install issues, or it's just a conveniently short package name?
[03:47] <Riddell> seb128, superm1: subscribe motu-sru
[03:48] <iwj> That seems very good actually.
[03:48] <seb128> iwj: Debug::pkgProblemResolver=true
[03:48] <iwj> I'll just add that option to all of my apt settings.
[03:48] <\sh> hmm...I made a bug fix today for 4g8
[03:48] <iwj> Debug::pkgProblemResolver=true I mean.
[03:48] <mvo> lamont: its a) short b) top in the synaptic list where I usually look for good examples. I also like "2vcard" and "3ddesktop" :)
[03:48] <lamont> ok
[03:48] <iwj> ogra: libxml++2.6 approved BTW
[03:49] <lamont> mvo: it's also what my management would consider malware.
[03:49] <iwj> mvo: Thanks, I think I don't need anything more from you about this.
[03:49] <lamont> and yes, I packaged it
[03:49] <ogra> iwj, yay, pkern will love you :)
[03:49] <ogra> (and edubuntu too :))
[03:49] <mvo> lamont: I never actually looked what it is, I noticed that you maintain it :)
[03:49] <mvo> iwj: cool, even better. thanks
[03:49] <lamont> mvo: you feed it a pair of IPs and MACs.  it inserts you in the middle
[03:50] <StevenK> lamont: That's *EVIL*
[03:50] <mvo> lamont: that is useful!
[03:50] <lamont> network problem diagnosis made simpler
[03:50] <lamont> arp cache poisoning for the win
[03:50] <ion_> That program would probably be illegal in Germany. :-)
[03:50] <StevenK> It's a MITM attack, used for diagnosis. Ouch.
[03:50] <lamont> OTOH, I haven't actually made it _work_ yet...
[03:50] <cjwatson> as usual, there's sometimes a fine line between malware and useful sysadmin tools
[03:50] <\sh> ion_, whaaaa
[03:50] <lamont> cjwatson: exactly
[03:51] <lamont> mind you, telnet and gcc both meet the definition of 'malware' as written in the company policy here...
[03:51] <\sh> ion_, I have it on my laptop
[03:51] <StevenK> lamont: Ouch.
[03:51] <StevenK> lamont: Even cat? :-P
[03:51] <lamont> "any software that could be used to evaluate vulnerabilities in another computer"
[03:51] <StevenK> netcat!
[03:51] <lamont> so I guess a web browser would count too
[03:52] <lamont> StevenK: certainly
[03:52] <ion_> sh: Youre a criminal. ;-)
[03:52] <StevenK> nmap, most definitely
[03:52] <ion_> sh: Dont tell me you also have nmap!
[03:52] <\sh> ion_, I need nmap for our datacenter security ,-)
[03:52] <StevenK> lamont: Oh, so you do. :-)
[03:53] <lamont> StevenK: when I pointed out the stupidity of the policy, they granted me an exception from it.
[03:53] <StevenK> Heh
[03:53] <lamont> they much prefer possession rules to intent-based rules
[03:53] <StevenK> "I can't do my work, since any web browswer is against company policy."
[03:54] <lamont> to which their response is of course, that they'll determine on a case-by-case basis what is and is not malware.
[03:55] <lamont> which just means that if they want to fire someone, that's one more excuse they can use...
[03:56] <ion_> sh: Judging from your initial response, you werent familiar with the law. If thats true, please take a look at http://www.google.com/search?q=germany+law+nmap
[03:56] <siretart> ogra: too bad. we were discussing installation on crypted filesystems in sevilla, and that time we expected cryptsetup to be in main for gutsy so that we can have partman-crypto tested in the installer :/
[03:57] <\sh> ion_, I know everything about this law :)
[03:57] <ion_> sh: Alright, sorry then.
[03:57] <\sh> ion_, I'm one of those stupids who have to live with those stupid politicians ;)
[03:57] <ogra> siretart, feel free to fix it ... i'm way to busy with other stuff
[03:58] <ogra> you have my full support to get it to main :)
[03:58] <siretart> until when are MIRs processed?
[03:58] <StevenK> xfish.c:183: warning: incompatible implicit declaration of built-in function 'strncpy'
[03:59] <ogra> siretart, no idea, beta freeze ?
[04:04] <pkern> ogra: libxml++2.6's main inclusion was approved, so Gobby could go in. But I would need a UVF exception for bug #114023 (sobby)...
[04:05] <ogra> pkern, yeah, lots and lots of thganks for doing the MIR :)
[04:05] <ogra> why does sobby need an UVF ?
[04:05] <pkern> ogra: I guess I would also need one for sobby to go in?
[04:05] <ogra> s/UVF/UVFe/ ?
[04:05] <Hobbsee> oh, wait, there's 1.
[04:06] <pkern> ogra: New configuration file option to support session files in it (only change upstream). Canonical sysadmins requested that some time ago. (OTOH they used an unsupported broken init script which caused the data loss...)
[04:07] <iwj> siretart: You might consult the release team about whether this needs or gets a freeze exception.
[04:07] <iwj> siretart: If you can tidy up the package and the MIR report then personally I don't see why we shouldn't promote the package.
[04:08] <cjwatson> cryptsetup? it's late, but I'd be inclined to take it
[04:09] <cjwatson> the relevant feature is partman crypto support, which we've been putting off forever
[04:09] <pkern> ogra: Well, it would be a sync from Debian w/o an Ubuntu change.
[04:09] <cjwatson> cryptsetup can clearly be promoted without that though, and my inclination would be to shove in partman-crypto ...
[04:09] <siretart> I'm too busy this week for this. I'd need to defer that until next week
[04:09] <ogra> cjwatson, iirc there was a lot of work to do for usplash integration (but thats some time ago, i didnt look since)
[04:09] <siretart> It would be really great if someone else could take over it, if it makes sense at all to work on it for gutsy
[04:09] <cjwatson> I haven't looked at it
[04:10] <Hobbsee> ubotu: ping
[04:10] <cjwatson> but I would really like cryptsetup to move on rather than continually stalling because it isn't the right time in the release process or whatever
[04:10] <siretart> ogra: seveas told me at sevilla that he had work for it in the pipe in usplash. ATM it just tells usplash to exit when prompting for a password
[04:10] <cjwatson> Seveas hasn't done anything to usplash since UDS AFAIK
[04:10] <siretart> oh :(
[04:10] <ogra> siretart, yeah, thats not nice
[04:11] <ubotu> host not found
[04:11] <pkern> Poor ubotu.
[04:11] <ogra> heh
[04:11] <cjwatson> ubotu: learn to check your arguments
[04:11] <Hobbsee> cjwatson: some morons just bot attacked #ubuntu again, so ubotu fell off the planet.
[04:11] <cjwatson> sure, I meant that it's clearly just doing "ping ''" or something when told 'ping'
[04:12] <Hobbsee> it's just a factoid, i'ts not an actual ping
[04:13] <cjwatson> wouldn't a factoid be "ping is host not found" or similar?
[04:13] <cjwatson> ubotu: ping www.ubuntu.com
[04:13] <Hobbsee> cjwatson: sure, if the <reply> tag isnt used
[04:13] <cjwatson> hmm, apparently not
[04:13] <Hobbsee> !no ping is pong
[04:13] <ubotu> I'll remember that Hobbsee
[04:13] <Hobbsee> !ping
[04:13] <ubotu> ping is pong
[04:13] <Hobbsee> !no ping is <reply> pong
[04:13] <cjwatson> ah, I see
[04:14] <pkern> Doesn't ubotu reply on "bug #NNNNNN" requests stated by anyone in the channel?
[04:14] <cjwatson> pkern: yes
[04:14] <pkern> cjwatson: I did one and it didn't answer but a long time later "host not found".
[04:14] <ogra> bug 1
[04:14] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[04:14] <ogra> works
[04:14] <Hobbsee> pkern: yes, the bot sometimes lags under excessive load
[04:14] <Hobbsee> !no ping is <reply> pong
[04:14] <ubotu> I'll remember that Hobbsee
[04:14] <Hobbsee> !ping
[04:14] <ubotu> pong
[04:14] <pkern> bug #121653
[04:14] <ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Undecided,Confirmed]  https://launchpad.net/bugs/121653
[04:14] <Hobbsee> cjwatson: there you go, like  ^
[04:14] <pkern> Yep, now it works. \:
[04:15] <pkern> ogra: It didn't earlier.
[04:15] <ogra> it has its days ... :)
[04:15] <Hobbsee> yeah, well, it doesnt help when stupid morons try to flood it off freenode.
[04:15] <ogra> that as well
[04:16] <Hobbsee> ogra: it basically depends on seveas' connection.
[04:16] <pkern> ogra: So what I need to do for an UVFe? Just debdiffing the versions and subscribe someone special?
[04:16] <Hobbsee> !uvfe
[04:16] <ubotu> Sorry, I don't know anything about uvfe - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[04:16] <Hobbsee> !uvf
[04:16] <ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[04:16] <Hobbsee> !uvfe is <alias> uvf
[04:16] <mvo> !4g8
[04:16] <ubotu> Sorry, I don't know anything about 4g8 - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[04:16] <Hobbsee> !uvfe is <alias> uvf
[04:17] <ogra> mvo, ?
[04:17] <Hobbsee> stupid bot, stop lagging
[04:17] <ogra> mvo, does your daughter *already* reach the keyboard ?
[04:17] <StevenK> Riddell: Thank you for the rubber stamp.
[04:17] <Hobbsee> !uvfe is <alias> uvf
[04:17] <pkern> Hobbsee: So I need a new bug for it. Fine.
[04:18] <Hobbsee> damned bot.  replies in one channel, but nto another.
[04:18] <mvo> ogra: I was just curious if it would do something apt-cache-ish
[04:18] <Hobbsee> or aliases are broken
[04:18] <ogra> hehe
[04:18] <Hobbsee> mvo: !info 4g8 gutsy(defaults to feisty)
[04:18] <Hobbsee> mvo: when it's not half dead.
[04:18] <sladen> cjwatson: gerard moved onto other things after the feature freeze came.  I can enquire how far the partman crypto stuff got.  usplash password asking was one of the issues he mentioned, and there was a second issues somewhere  (aswell as needing the promotion to main)
[04:19] <mvo> thekorn: "bughelper -p apt -T apt 'E:Dynamic MMap ran out of room,' dup" gives me a error here, is that known?
[04:19] <dholbach> mvo: yes, broken since the new LP layout - the API-breaking version will fix it
[04:19] <Hobbsee> good morning dholbach
[04:19] <ogra> pkern, you removed the comment from the gobby MIR in the queue but didnt move the entry to the other section
[04:19] <pkern> ogra: It's approved but not promoted?
[04:20] <dholbach> mvo: but I'm on a sprint, so I'm not going to break py-lp-bugs and bughelper without being able to test it properly from here
[04:20] <dholbach> hi Hobbsee
[04:20] <ogra> pkern, right
[04:20] <ogra> pkern, oh, sorry ... my fault
[04:20] <pkern> ogra: I struggle with Ubuntu's procedures sometimes, but this one should be right I think. (Although net6 and obby should be listed there, too.)
[04:21] <ogra> they will be pulled in as deps anyway tough
[04:21] <Hobbsee> https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/135584 yay, stupid bugs.
[04:21] <ubotu> Launchpad bug 135584 in ubuntulooks "default theme in Ubuntu is a huge mistake " [Undecided,New] 
[04:21] <mvo> dholbach: sure
[04:22] <dholbach> mvo: I'll do that next week - or thekorn can tell you which branches to use
[04:25] <cjwatson> sladen: who is gerard?
[04:25] <soren> iwj: What's depisok?
[04:26] <iwj> A function in dpkg/depcon.c
[04:26] <iwj> Err, dpkg/src/depcon.c I mean.
[04:26] <soren> Ah, ok.
[04:26] <sladen> cjwatson: the guy I had here working on ubiquity/usplash/partman crypto
[04:27] <soren> iwj: I thought it was supposed to make sense to us mere mortals. :)
[04:27] <sladen> cjwatson: I think (well, hope) he spoke/interacted with you
[04:27] <ion_> hobbsee: Heh, the Human theme is one of the few themes i actually like. :-)
[04:27] <cjwatson> sladen: I don't recall that
[04:28] <cjwatson> sladen: unless it was a sufficiently different name that it failed to register
[04:28] <Hobbsee> ion_: actually, what i should write in that bug report is "then switch to another flavour of ubuntu, like kubuntu or edubuntu"
[04:28] <iwj> soren: Err.  I could explain the implications but they're a bit complicated.  Mainly there are some circumstances now where if you force apt, or drive dpkg by hand, you'll get packages deconfigured as they ought to have been where previously they weren't.
[04:29] <sladen> cjwatson: I'll enquire
[04:30] <pkern> ogra: UVFe request submitted. *cough*
[04:31] <pkern> If there wasn't that graphical splash screen I would already have Ubuntu installed under KVM. *cough*
[04:31] <sladen> cjwatson: https://code.launchpad.net/~glledo/ubiquity/ubiquity-crypto  I don't know what state it's in
[04:31] <cjwatson> oh, glledo
[04:32] <cjwatson> yes, he did speak to me, haven't had much of a chance to review yet though since it's dependent on the lower layers working first
[04:34] <sladen> cjwatson: the status of the bits and pieces needed is at:  http://codebrowse.launchpad.net/~glledo/ubiquity/ubiquity-crypto/annotate/gerard.lledo%40gmail.com-20070828150527-vd3gtds6li3loxw6?file_id=readme.partmancrypto-20070726090920-tyt6yud2781kc0c6-1
[04:35] <sladen> meh.  the delights of distributed RCS
[04:37] <soren> iwj: I see. The changelog just made me curious. :)
[04:37] <cjwatson> sladen: right, what I mean is that a lot of that gets to go away once it's in main and properly seeded and stuff
[04:37] <iwj> Yay, now I have _two simultaneous glibc builds_ going.
[04:37] <iwj> I suppose they'll be done by tomorrow morning ...
[04:39] <bddebian> Heya
[04:48] <Hobbsee> Chipzz: i told kmos about his ddclient sync, not the powertop one
[04:48] <Hobbsee> Chipzz: the powertop one seems to have been forgotten about, by others of the motu-uvf team.
[04:49] <StevenK> What's the bug number? I'll look now.
[04:49] <Hobbsee> Kmos: you keep saying you wont ask for any more sync requests, but you never seem to action that.
[04:49] <Hobbsee> StevenK: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/129572
[04:49] <ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete] 
[04:49] <Hobbsee> StevenK: last time i checked, it had no changes, but LP has screwed with the panels.
[04:49] <StevenK> Hobbsee: Thank ye
[04:51] <StevenK> Hobbsee: zul_ ACK'd 1 minute ago
[04:52] <Hobbsee> ah, neat.
[04:52] <StevenK> Kicked to Confirmed
[04:52] <Hobbsee> StevenK: can you check that u-a is subscribed, etc, etc, etc?
[04:52] <Hobbsee> as required?
[04:52] <Hobbsee> great, thanks :)
[04:53] <StevenK> Hobbsee: All done.
[04:53] <Hobbsee> infinity: FYI, what Kmos is talking about is universe, nto main.  but the same applies (particularly as i'm on both teams)
[04:55] <Hobbsee> Kmos: i said i wont process that one, nor others from you at this point in UVF, because i've got no confidence in any of them, due to the contradictions.  That is not hating you, that is simply stating the facts as they stand - i have other things that i want to see happen, and the teams have got the rest of the bugs to deal with too.
[05:11] <sladen> iwj: what's preventing cryptsetup promotion to main?
[05:12] <sladen> iwj: security issues, usplash passphrase integration?
[05:13] <iwj> sladen: Oh, just some minor problems.  No showstoppers, but the package (and the MIR report) are just in need of a bit of tidying up.
[05:16] <iwj> sladen: Perhaps I ought to just fix it up myself.
[05:17] <iwj> I don't really want to fix up every broken MIR but I'm quite keen on this package and it seems to be languishing.
[05:18] <iwj> How alarming.
[05:18] <sladen> iwj: given the nature of this package, it is one that I /would/ rather was fixed up directly, if you're willing to
[05:18] <iwj> Sure.
[05:18] <iwj> My glibcs are still building :-).
[05:31] <iwj> OMG it's statically linked against libgcrypt, libgpg-error, libnsl.
[05:31] <sabdfl> asac: am now in a spot with both wired and broken wpa networks
[05:31] <sabdfl> would you like me to help debug this?
[05:32] <dobey> hi sabdfl
[05:32] <iwj> siretart: Are you using cryptsetup yourself ?  For the root fs ?
[05:32] <iwj> sladen: ^
[05:34] <\sh> hmmm...one question to our firefox gurus...any reason why we have a package for the adblock plugin , but not for adblock plus? is there a reason behind this decision?
[05:34] <sabdfl> hey dobey
[05:34] <sladen> iwj: not on /this/ machine.  But have done on the test installs
[05:35] <Hobbsee> \sh: out of curiousity, do we actually install any filter with that, and if so, which one?
[05:35] <iwj> sladen: OK, good.  I might ask you to test a package before I upload it.  I don't have a suitable setup here and it would save time if I got to break yours instead :-).
[05:35] <\sh> Hobbsee, well, that was my problem..I thought it's adblock plus with the filter abos...but it's just plain...
[05:35] <Hobbsee> \sh: abos?
[05:35] <dobey> sabdfl: how's it going?
[05:35] <sabdfl> good thanks dobey
[05:36] <\sh> Hobbsee, nope...I meant subscription ;) damn DEnglish sometimes ,-)
[05:36] <Hobbsee> \sh: ahhhh...
[05:36] <Hobbsee> \sh: means my german should improve.  one day...
[05:37] <iwj> OIC.  "# cannot depend on libraries in /usr !"
[05:38] <sladen> iwj: remember this is going to need to run from initramfs before / even exists
[05:38] <asac> sabdfl: yes ... let me switch context ...
[05:38] <siretart> iwj: I'm using it for my home partition
[05:39] <asac> sabdfl: i think what i wanted to test was to use wpa_supplicant manually ... e.g. not through wpa_supplicant.conf
[05:39] <iwj> sladen: Yes, in some setups.
[05:39] <iwj> siretart: Hmm.
[05:39] <siretart> iwj: I've been bitten enough with my previous installation been root on lvm
[05:39] <soren> I'm packaging a piece of software whose only code file is a python script installed in /usr/bin/.. IIUIC, the python packaging policy only says what to do about modules and extensions and this is neither.. Should I just leave it like this or am I required to modulify it and provide a wrapper script, etc.. ?
[05:39] <iwj> siretart: As you say.
[05:39] <asac> sabdfl: because thats the way network-manager uses wpa supplicant
[05:39] <siretart> iwj: it was just too painfully racy, so that I came to the conclusion that its not worth the efford to do it with ubuntu. sadly :(
[05:40] <asac> (and is not doing very much otherwise in wpa case)
[05:40] <siretart> iwj: but for home partitions and crypted usb sticks/disks, it's great!
[05:41] <iwj> I expect it will substantially bloat your initramfs.  You don't have any problems with that then ?
[05:41] <sabdfl> asac: that's fine
[05:42] <asac> sabdfl: wait a second i will outline the steps, e.g. commands
[05:42] <sladen> soren: you can put the python program straight into  /usr/bin  ;  see 'lsb-release' for such an example 'all' python package
[05:42] <siretart> well, it will drag in libssl and cryptsetup. I don't see big problems for that, at least not on i386 and amd64
[05:42] <geser> is there some tool to check if the depends of a deb file can be fulfilled from the archive?
[05:42] <iwj> siretart: Mmmm.
[05:43] <soren> sladen: Wicked. Thanks.
[05:43] <siretart> I have to admit that I don't know if a big initramfs size affects silo or palo
[05:43] <iwj> ATM it statically links against those but I think that's really bad.
[05:43] <iwj> But if I change that then anyone whose /usr needs cryptsetup will lose.
[05:43] <soren> sladen: So... I don't even have to mess about with python-{central,support} or anything?
[05:43] <ogra> siretart, libssl ??
[05:43] <sladen> soren: apt-get source lsb-release
[05:43] <soren> sladen: Clever you.
[05:43] <iwj> ogra: No, libgcrypto.
[05:44] <ogra> ah
[05:44] <iwj> Err, libgcrypt.
[05:44] <ogra> well, something with sane licensing :)
[05:46] <sladen> iwj: if you get suitably annoyed by looking at the package, you could probably knock up a better, alternative over the weekend
[05:46] <siretart> err, sorry, nothing of that. I mixed it with wpasupplicant
[05:46] <iwj> siretart: So how bad do you think it would be if I were to break anyone with /usr as a separate encrypted filesystem.
[05:46] <iwj> sladen: I think I'd just have the same the problem as this package is trying to solve.
[05:47] <soren> sladen: I'm not entirely sure what the semantics of XS-Python-Version: current is as opposed to XS-Python-Version: all..
[05:47] <iwj> I think I understand now why it was done this way but I don't like it.
[05:47] <iwj> From a security support POV static linking is really bad.
[05:47] <siretart> iwj: I'd expect it to just work, though we'd need to test it first
[05:47] <soren> sladen: If I belive my package will work with whatever is current, that's the same as saying "it should work with all of them", isn't it?
[05:47] <iwj> siretart: No, if I make the change I have in mind it will break.
[05:48] <siretart> iwj: the current plan is to redisign the integration of cryptsetup's initscripts
[05:48] <iwj> But only if /usr is a separate encrypted filesystem.
[05:48] <iwj> We're not redesigning anything at this stage, surely ?
[05:48] <iwj> I'm hoping to fix this up well enough for it to go in main.
[05:48] <siretart> no, not for gutsy. maybe for hardy
[05:48] <cjwatson> redesign => not gutsy, I'd have thought
[05:48] <iwj> Right.
[05:48] <siretart> with 'redesign', I mean cryptsetup <-> udev integration
[05:49] <iwj> siretart: So my question is: how many people have (a) separate /usr AND (b) cryptsetup AND (c) encrypted /usr ?
[05:49] <siretart> it would involve crafting some kind of 'passphrase cryptsetup agent'
[05:49] <iwj> siretart: I don't want to think about that right now :-).
[05:49] <siretart> :)
[05:49] <cjwatson> soren: XS-Python-Version: current => only include support for whatever the current version is, require trivial rebuild at some point when that changes; XS-Python-Version: all => include support for all currently supported versions
[05:49] <soren> iwj: The issue is the same with an encrypted root filesystem, isn't it?
[05:49] <iwj> soren: No, because the initramfs tools will automatically pick up all of the needed libraries.
[05:50] <ion_> siretart: Someone should implement libwhat and what-UIs. ;-)
[05:50] <siretart> I wouldn't expect many users having seperate crypted /usr. If we encounter it makes problems, we could easily prevent it in the installer
[05:50] <siretart> we don't support conversion of filesystems to crypted anyway
[05:50] <iwj> soren: (I think.  I mean, we ought to test that but I don't anticipate a problem.)
[05:50] <cjwatson> soren: that's a summary, but http://wiki.debian.org/DebianPython/NewPolicy and search for XS-Python-Version
[05:50] <soren> iwj: Oh, clever. Why doesn't this work with an encrypted /usr then? At initramfs generation time, it's not encrypted, I suspect?
[05:50] <iwj> siretart: My worry is that if I just make this binary dynamically linked I will make those machines unbootable if they exist already.
[05:50] <iwj> soren: At initramfs generation it's mounted.
[05:51] <cjwatson> you could make the initramfs deal with mounting /usr too in that case ;-)
[05:51] <iwj> cjwatson: That had occurred to me :-).
[05:51] <soren> iwj: Yes, that's what I meant.
[05:51] <siretart> iwj: there are already feisty users which managed to boot with crypted root without too much trouble, according to malone
[05:51] <ogra> encrypted /usr ? :)
[05:51] <iwj> siretart: No, no, listen to me very carefully.
[05:51] <siretart> iwj: TBH, I don't really see the point of an crypted /usr
[05:51] <iwj> The problem I plan to create is ONLY if /usr is separate AND it is encrypted.
[05:51] <sladen> iwj: ignore the /usr issue.  think the encrypted / issue through
[05:52] <iwj> If it's part of an encrypted /, it should be fine.
[05:52] <iwj> sladen: Right.
[05:52] <iwj> Good.
[05:52] <soren> iwj: So.. When it's mounted, the initramfs tools will grab the libs and put them into the initramfs ?
[05:52] <iwj> That's what I was hoping to hear.
[05:52] <iwj> soren: Right.
[05:52] <siretart> ah, right
[05:52] <soren> iwj: And how do you intend to break this? :)
[05:52] <iwj> soren: I don't.
[05:52] <sladen> iwj: how did you mount it ?...
[05:52] <soren> sladen: magic
[05:52] <sladen> chicken.  egg.
[05:52] <iwj> sladen: Well, if it was encrypted / then all is well because the last initramfs mounted it.
[05:52] <asac> sabdfl: http://pastebin.mozilla.org/190473
[05:52] <iwj> If it's separate encrypted /usr then you lose.
[05:53] <iwj> ATM that works because cryptsetup is statically linked and doesn't need anything from /usr.
[05:53] <siretart> cryptsetup is statically linked? not on my machine..
[05:53] <siretart> it doesn't link to anything in /usr, though
[05:54] <iwj> siretart: It's partially statically linked.
[05:54] <siretart> aah, and that's what you want to change
[05:54] <siretart> right?
[05:54] <iwj> siretart: Right.
[05:54] <siretart> iwj: why?
[05:54] <cjwatson> soren: the initramfs tools do that automatically assuming you use copy_exec
[05:55] <cjwatson> iwj: (and so you could happily dynamically link the copy in the initramfs)
[05:55] <soren> cjwatson: Right, got that. What I'm not getting is why this doesn't work if /usr is encrypted..
[05:55] <iwj> siretart: Because static linking is EBW.  In particular, it makes security support a PITA.
[05:55] <iwj> cjwatson: Right.
[05:55] <cjwatson> soren: because the initramfs isn't responsible for mounting /usr; that's the one in /
[05:55] <soren> cjwatson: Ah.
[05:55] <cjwatson> iwj: though actually, that would only work if all the library packages triggered an initramfs update
[05:55] <soren> Yes, of course.
[05:56] <cjwatson> otherwise you would effectively need to upgrade cryptsetup or otherwise trigger update-initramfs anyway
[05:56] <iwj> cjwatson: Uh ?  The initramfs is generated all in one go.
[05:56] <siretart> iwj: I see. well, as said, I don't expect many (of any!) user to just encrypt /usr. And we can prevent them doing so by some magic in the installer(s)
[05:56] <iwj> After you get the new cryptsetup, next time mkinitramfs runs it will pick up all of the new libraries.
[05:56] <cjwatson> iwj: the security support problem is that if we upload say libgpg-error in a security update then the cryptsetup binary doesn't get updated automatically
[05:57] <soren> iwj: How is this more secure than linking it statically?
[05:57] <cjwatson> iwj: an upgrade containing only libgpg-error will not automatically run mkinitramfs
[05:57] <iwj> siretart: I'm less worried about new installs.  After all, "new install with pathological configuration doesn't boot" is a lot less bad than "my existing install doesn't boot".
[05:57] <cjwatson> iwj: thus it's essentially the same problem unless libgpg-error triggers an initramfs update
[05:57] <iwj> cjwatson: I don't see the problem.  The old initramfs is still fine, surely.
[05:57] <cjwatson> iwj: it's fine but it still contains the buggy libgpg-error
[05:58] <asac> sabdfl: after doing that, you should see in the wpa supplicant shell that it successfully authenticates ... and a message in wpa_cli shell that you successfully associated
[05:58] <iwj> soren: If (eg) there's a bug in libgpg-error, we don't want to have to rebuild cryptsetup (and fourteen other packages).
[05:58] <cjwatson> the ideal situation is one in which uploading libgpg-error fixes up the initramfs too
[05:58] <iwj> cjwatson: OIC.  We could issue the security fix for libgpg-error with a call to trigger initramfs generation.
[05:58] <siretart> iwj: aah, now I understand what you are worrying about. well, we haven't cared much for this kind of users (installing random packages from universe) in the past
[05:58] <soren> iwj: You argued that statically linked binaries were a security problem because we'd need to rebuild them to get security updates. If you still have the borken versions in the initramfs it doesn't help much, does it?
[05:58] <cjwatson> my point exactly
[05:58] <siretart> I hold network-manager in breezy I think as example
[05:58] <cjwatson> but only necessary when cryptsetup is installed
[05:59] <cjwatson> so it's a bit messy
[05:59] <iwj> cjwatson:   if test -f ... yada
[05:59] <iwj> Or cryptsetup could do it.
[05:59] <asac> sabdfl: for instance i see http://pastebin.mozilla.org/190474 i wpa_cli shell
[05:59] <iwj> interest /usr/lib/libgpg-error.so.0
[05:59] <cjwatson> cryptsetup can only do it if it can be triggered by any of its dependent ... what you said
[05:59] <iwj> and then on activation say  dpkg-trigger update-initramfs  :-)
[06:00] <iwj> The whole initramfs arrangements are a bit shonky really.
[06:00] <soren> iwj: I'm not entirely sure how your new dpkg trigger system works, but would it be possible for copy_exec to make a list of files that should trigger a new initramfs?
[06:00] <iwj> soren: No.
[06:00] <soren> winkle: ok
[06:00] <soren> whoops
[06:00] <iwj> Lists of trigger interests are supposed to be static.
[06:00] <soren> iwj: ok
[06:01] <Chipzz> soren: but that doesn't matter anyway, seriously
[06:01] <cjwatson> one could generate a trigger interest list using ldd in cryptsetup's build process
[06:01] <sladen> iwj: but the regeneration only needs to happen /if/ something causes libgpg-error to be copied into the initramfs.  Is it is the utility causing libgpg to be pulled in that should somehow mark the hook to update-initramfs;  whether that's possible with the current hooks, I don't know.
[06:01] <soren> Chipzz: Why?
[06:01] <cjwatson> it's really just shlibdeps on steroids
[06:01] <Chipzz> having an outdated version in the initramfs would require your system to be unbootable to be exploitable
[06:01] <Chipzz> because
[06:01] <iwj> sladen: There's no machinery for that kind of thing right now.
[06:01] <Chipzz> from the moment you pivot_root
[06:01] <Chipzz> they're gone
[06:01] <iwj> Chipzz: Very good point.
[06:02] <cjwatson> assuming that there's no way to nobble the filesystem such that the version in the initramfs will do something crazy
[06:02] <Chipzz> so in reality you got bigger problems (like a fscking *broken* system) to worry about than some *hypotethically* exploitable program
[06:02] <soren> Chipzz: We don't pivot_root anymore, actually :)
[06:02] <iwj> cjwatson: Yes, but our root mounting arrangements are already hopelessly weak against anyone who can introduce block devices with hostile contents.
[06:02] <cjwatson> Chipzz: (pivot_root is dead, long live run-init)
[06:02] <cjwatson> iwj: mm
[06:03] <Chipzz> but the binaries are still gone, right?
[06:03] <iwj> (Big bug that but no way am I going to try to have that battle against the entire universe.)
[06:03] <cjwatson> Chipzz: my concern is really more that we end up with mystically broken systems whose bugs go away when you run update-initramfs
[06:03] <soren> Chipzz: Yes, but your root file system is still mounted using them.
[06:03] <iwj> So I think the conclusion is I can dynamically link this without trouble.
[06:03] <cjwatson> due perhaps to bugs that aren't security holes
[06:03] <sladen> we should replace UUID with PKI shared UUIDs
[06:03] <Chipzz> soren: which does not matter since they can't be invoked by a user anyway
[06:03] <iwj> sladen: Yay, openssl in the initramfs.
[06:04] <Chipzz> the way they're invoked is very controlled and very limited
[06:04] <cjwatson> Chipzz: cryptsetup may not suffer much from this but I have real bug reports that are examples of this problem so don't tell me it's not a problem
[06:04] <sladen> as at the moment the / UUID is a shared secret that allows a race-condition for taking over boot :)
[06:04] <Chipzz> cjwatson: there is a difference between "broken" and "exploitable"
[06:04] <soren> Chipzz: You're making assumptions about not-yet-discovered vulnerabilites. :)
[06:04] <cjwatson> Chipzz: I don't care. I'm talking purely about the initramfs updating arrangements which aren't sensitive to that distinction.
[06:05] <cjwatson> logically the initramfs should be updated whenever the source of anything copied into it is changed
[06:05] <iwj> sladen: Things are much worse if you use lvm.
[06:05] <cjwatson> we do not at present have the ability to do that in all cases
[06:05] <iwj> cjwatson: I think we need a dynamic trigger interests feature.
[06:05] <cjwatson> cryptsetup's linkage stuff is just a special case of that
[06:06] <Chipzz> btw
[06:06] <cjwatson> iwj: tools to help build the trigger interests at package build time might help
[06:06] <Chipzz> statically linking only pulls in the functions which are effectively used
[06:06] <iwj> cjwatson: *shudder* but yes.
[06:06] <cjwatson> iwj: like I say, shlibdeps ...
[06:06] <Chipzz> so part of a lib may be broken/exploitable, and still not affect statically linked programs
[06:06] <cjwatson> seems near enough the same thing :)
[06:07] <Chipzz> cjwatson: care to point me to some bugreports? I'm actually interested in some of these cases ;)
[06:07] <soren> Chipzz: "We're probably not vulnerable" is rarely a sensible approach to security.
[06:07] <iwj> Chipzz: Also true but of course when the vuln in the lib is found the security guys have to go madly haring round trying to figure out what's vulnerable.
[06:07] <Chipzz> not that I have enough knowledge to fix them, just curious
[06:07] <cjwatson> Chipzz: comments near the end of bug 131961
[06:07] <ubotu> Launchpad bug 131961 in busybox "Segfaults during boot (from mount)" [High,Fix released]  https://launchpad.net/bugs/131961
[06:08] <cjwatson> unfortunately I forget exactly what broke when I tried to make busybox-initramfs call update-initramfs
[06:08] <cjwatson> I think it was something to do with initramfs-tools not necessarily being configured yet since it depends on busybox-initramfs, so it might be able to go away with triggers
[06:09] <Chipzz> soren: really, things like cryptsetup would only exercise certain codepaths of broken libs, and I figure in controlled ways
[06:09] <Chipzz> and it's hard to replace those binaries with ones that would actually exploit the problem
[06:09] <cjwatson> iwj: could I just have busybox-initramfs call 'dpkg-trigger --no-await update-initramfs' if dpkg-trigger is available?
[06:10] <Chipzz> cjwatson: oh, heh, busybox... now *that* is an example of uncontrolable code paths ;)
[06:10] <Chipzz> by it's very nature even :)
[06:12] <iwj> cjwatson: Yes.
[06:12] <Chipzz> cjwatson: one could argue about the sanity of the way busybox is written I guess ;)
[06:14] <iwj> Anyway, I'm off to catch my train to go climbing now.  If anyone has any more to add feel free, and I'll catch up on the log tomorrow.
[06:16] <bryce> Riddell, 132405 - xterm sync - you may have already sync'd it.  It looks extremely minor to me, having only two bug fixes neither of which seem terribly critical.
[06:17] <Riddell> bryce: ok
[06:17] <iwj> TTFN all.
[06:18] <bryce> Riddell, btw fyi, I have been organizing the backport fixes from xserver 1.3.99 to our 1.3.0 here:  https://wiki.ubuntu.com/X/Fixes_to_Backport
[06:21] <sabdfl> asac: i have to head to the "other office" in 10
[06:21] <sabdfl> can we have a stab at NM now?
[06:21] <asac> sabdfl: what do you mean by "stab" ?
[06:21] <sabdfl> well. you tell me what to type. i type it and tell you what i see ;-)
[06:22] <asac> sabdfl: i posted above?
[06:22] <sabdfl> right now i've switched to "manual config" and it works fine
[06:22] <sabdfl> ah
[06:22] <asac> yes ... what is important that we see that wpa_cli works the way i posted
[06:23] <asac> sabdfl: if the wpa_cli doesn't receive the associated events, then network-manager doesn't see them and doesn't try to get an ip
[06:26] <pkern> "Is the system clock set to UTC?" is a bogus question in the installer when the current system clock content is now shown to the user... *cough*
[06:27] <pkern> s/now/not/
[06:27] <ogra> pkern, thats onyl done by d-i
[06:27] <ogra> *only
[06:28] <ogra> ubiquity doesnt asjk that question anymore
[06:28] <pkern> ogra: Correct, I am currently trying to install a minimal gutsy tribe...
[06:28] <ogra> ah
[06:29] <soren> pkern: https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/68861
[06:29] <ubotu> Launchpad bug 68861 in clock-setup "edgy text mode installer: show the current time when asking about system clock being in utc" [Wishlist,Confirmed] 
[06:29] <cjwatson> ogra: (which is in itself a bug)
[06:30] <pkern> soren: Thanks.
[06:30] <ogra> cjwatson, indeed...
[06:31] <cjwatson> clock-setup has NTP support in d-i trunk so I'm hoping this will get a lot better for networked users in hardy
[06:35] <cjwatson> Riddell: do you know whether KDE uses pmi to decide whether to offer suspend/hibernate?
[06:36] <Riddell> cjwatson: it uses HAL
[06:36] <Riddell> although power manager may fall back to some other method if HAL isn't running
[06:37] <mjg59> Riddell: HAL will always claim that suspend and hibernated are supported with our kernels
[06:38] <Riddell> mjg59: why?
[06:39] <cjwatson> mjg59: would there be a problem with making it use pmi?
[06:39] <mjg59> Riddell: Because hal just tests whether the kernel provides the functionality, not whether any sort of policy forbids it
[06:39] <cjwatson> mjg59: in this crazy loop-mount-from-NTFS case it would be really useful to be able to nobble pmi to say that suspend and hibernate aren't supported
[06:40] <mjg59> cjwatson: Doubt it, but I'm not familiar with the code
[06:40] <cjwatson> I thought policy was allowed in hal
[06:41] <mjg59> cjwatson: It's allowed, but nothing does it
[06:42] <cjwatson> mjg59: would there be another place where pmi integration would be better?
[06:42] <mjg59> On boot we could probably check the status with pmi or whatever, and then set the keys in hal
[06:42] <Riddell> mjg59: so does gnome-power-manager use pmi to check if it's available?
[06:42] <cjwatson> Riddell: not any more
[06:42] <mjg59> I've no clue. I really haven't checked this code lately.
[06:42] <cjwatson> mjg59: we can't just call it each time it's queried?
[06:43] <cjwatson> Riddell: ogra took that out in the gutsy cycle
[06:43] <mjg59> cjwatson: No
[06:43] <cjwatson> blast
[06:43] <mjg59> hal is a status repository
[06:43] <mjg59> It updates information as events happen, it doesn't generate the data on request
[06:49] <cjwatson> hmm, hal queries something called /usr/bin/pm-is-supported already, which we don't have
[06:49] <cjwatson> oh, yes we do, it's in pm-utils in universe
[06:51] <cjwatson> hmm. so that looks much better than what we have but it does all kinds of stuff and I don't fancy making the call myself
[06:51] <cjwatson> I think I'll just patch hal to ask pmi if pm-is-supported isn't there
[06:51] <mjg59> I was looking at moving over from acpi-support to pm-utils
[06:51] <mjg59> But mdz thought we were too close to FF at the time
[06:51] <cjwatson> yeah
[06:52] <ion_> pm-is-supported seems to give the expected results on my hardware. Would be nice to have HAL query it by default.
[06:53] <cjwatson> ion_: it already does.
[06:53] <cjwatson> ion_: but we don't install pm-is-supported by default so I'm going to make it use pmi as a fallback, which we do install by default.
[06:53] <cjwatson> (for now)
[06:53] <ion_> I meant having HAL query it by default in the default installation, that is having it installed alongside HAL by default. :-)
[06:53] <ion_> Alright
[06:53] <mjg59> ion_: We can't.
[06:54] <mjg59> pm-utils would break a lot of stuff right now.
[06:54] <ion_> Ok
[07:07] <calc> mjg59: any news about the amd64 vbetool?
[07:08] <mjg59> calc: Nope. Your bug is still weird.
[07:09] <calc> mjg59: ok heh
[07:09] <mjg59> I'll probably get some work done on it during XDS
[07:10] <cjwatson> mjg59: aside from being obvious clone-and-hack, does http://people.ubuntu.com/~cjwatson/tmp/90_pmi.patch look vaguely reasonable?
[07:10] <cjwatson> I haven't tried it yet ...
[07:13] <mjg59> cjwatson: Yeah, looks basically sane
[07:13] <ion_> Interestingly, pmi says my hardware supports suspend and hibernate, pm-utils say it only supports hibernate. Suspend doesnt work on my computer, but i havent investigated the reason  it might simply be the nvidia proprietary driver.
[07:13] <cjwatson> I'll leave a changelog note saying it can go away once pm-utils is in place
[07:14] <mjg59> Should bcm43xx-fwcutter be promoted?
[07:15] <mjg59> Given that restricted-manager bails with a weird error otherwise
[07:15] <cjwatson> it's kind of crazy and relies on URLs which keeps  changing
[07:15] <cjwatson> s/s  / /
[07:15] <cjwatson> but nothing else provides the same functionality
[07:15] <mjg59> cjwatson: In that case, it might be better to leave it out of r-m?
[07:15] <calc> could it request a url which redirects to the current one?
[07:16] <mjg59> calc: Awkward copyright issues
[07:16] <cjwatson> I think (a) it probably ought to be promoted to restricted (b) r-m should cope with it being absent
[07:16] <mjg59> cjwatson: It copes to the extent of "The software source for the package is not enabled"
[07:16] <mjg59> Which makes sense to me, but probably not to most :)
[07:16] <calc> mjg59: hmm then download a file that it parses which contains the current url to the files, that would get around the linking issue (maybe?)
[07:17] <mjg59> It'd also be nice if it warned that it needed network access
[07:22] <elmo> hmm, I have a crash report on the live cd
[07:31] <kagou> \o/ sz
[07:34] <zasf> mjg59: i did the hack wich prompts "The software source for the package is not enabled"
[07:35] <zasf> I understand it is meaningless to the most
[07:35] <zasf> but you can't know wich repo belongs to if you that repo is not enabled
[07:37] <zasf> I wonder how command-not-found behaves if user tries to execute a command
[07:37] <zasf> for wich needed repo is not enabled
[07:38] <pygi> easy :P
[07:38] <pygi> it tells you to enable the repo :p
[07:38] <zasf> hehe but wich one?
[07:38] <pygi> well, depending on the app you're trying to execute?
[07:38] <zasf> :P
[07:39] <pygi> it has it's data source, you know =)
[07:39] <zasf> ah, ok :)
[07:39] <Lamego> /usr/share/command-not-found/programs.d/
[07:39] <zasf> isn't repositories data duplicated?
[07:39] <pygi> now I'll do ":P" :P
[07:40] <zasf> so r-m could be smart enough to read that dir
[07:41] <zasf> find out wich repo is needed and prompt "why don't you open 'software sources' and enable XX repo"?
[07:42] <Lamego> couldn't it be even smarter ? "Do you want to enable the repository XPTO containing this software?"
[07:42] <mjg59> Though it would also be nice if it pointed out that you'll need network access
[07:42] <mjg59> Right now it says "Enable firmware", not "Download and enable firmware"
[07:46] <milian> is k3b currently not working?
[07:46] <zasf> mjg59: that's because bcm43xx-fwcutter is not in main
[07:46] <cjwatson> zasf: (main or restricted)
[07:46] <milian> i.e. is this known: :-[ WRITE@LBA=10h failed with SK=5h/ASC=21h/ACQ=02h] : Invalid argument
[07:47] <milian> :-( write failed: Invalid argument
[07:47] <milian> or should I file a bug report?
[07:47] <zasf> if user has no other internet access rather than wireless.. he has no chance
[07:50] <mjg59> zasf: No, it *needs* network access - there's no other way for it to get the firmware
[07:51] <zasf> mjg59: he can also cut it from local (win partition or driver cd)
[07:51] <mjg59> zasf: Not through restricted-manager
[07:51] <mjg59> Or can they?
[07:51] <zasf> mjg59: they can
[07:52] <mjg59> zasf: restricted-manager will search their hard drive?
[07:52] <zasf> no
[07:52] <zasf> user can point where fw is
[07:52] <zasf> trough a 'browse' button
[07:52] <mjg59> Ok
[07:52] <mjg59> cjwatson: In that case, fwcutter probably ought to be in ship
[07:53] <ogra> zasf, where would that browse button be ? i dont see it here
[07:54] <zasf> i'll upload a screenshot shortly
[07:54] <ogra> and no option to select any location for anything here
[07:54] <pkern> mkinitramfs takes forever on qemu proper *cough*
[07:54] <ogra> oh, you are talking about a future version ?
[07:54] <zasf> gutsy's version
[07:55] <ogra> zasf, using that here
[07:55] <ion_> pkern: It takes forever on real hardware. :-)
[07:56] <ogra> checking the broadcom firmware checkbox only gives me a dialog asking if i want to enable it ... then it pops up gdebi and installs fwcutter
[07:56] <pkern> ion_: Hm... well I devote a core to that qemu emulation. But then I guess it took forever the last time, too, so probably I just need to wait another half an hour...
[07:56] <zasf> kate.homeunix.net/~matteo/Screenshot-restricted-manager.png
[07:56] <ogra> zasf, and how do i get to that window ?
[07:57] <ogra> oh !
[07:57] <zasf> ogra: enable fw..
[07:57] <ogra> it comes *after* gdebi ran
[07:57] <ogra> and after the gdebi win was closed ...
[07:57] <zasf> what did you use gdebi for?
[07:58] <ogra> i didnt, r-m calls it to install fwcutter
[07:58] <zasf> k
[07:58] <ogra> which i didnt have
[07:58] <zasf> it calls synaptic
[07:58] <ogra> well, similar ui :)
[07:58] <zasf> :) yes
[07:59] <zasf> there are still problems (LP #135000), but it works
[07:59] <ubotu> Launchpad bug 135000 in restricted-manager "unresponsive at broadcom firmware installation" [Undecided,In progress]  https://launchpad.net/bugs/135000
[08:00] <ogra> well, fwcutter should definately get seeded (even installed by default imho) to avoid the synaptic stuff ...
[08:01] <sbalneav> ogra: Did you update nbd-client, or nbd-server?
[08:01] <ogra> sbalneav, ? its the same source ?
[08:02] <ogra> i just applied your patch
[08:02] <zasf> mjg59 ogra pygi Lamego: thanks for your suggestions, I'll see if I can improve r-m a bit
[08:02] <zasf> I gotta go now, see you later
[08:02] <ogra> and checked that the manpage ended up in my testbuilt binary
[08:02] <sbalneav> right, same source, but two different packages, it splits into nbd-client, and nbd-server.
[08:02] <sbalneav> the patch was for nbd-server
[08:02] <ogra> yeah
[08:03] <ogra> ogra@laptop:~/packages/nbd-2.9.6$ dpkg -c /var/cache/pbuilder/result/nbd-server_2.9.6-1ubuntu3_i386.deb |grep man|grep gz
[08:03] <ogra> -rw-r--r-- root/root      4010 2007-08-29 17:41 ./usr/share/man/man5/nbd-server.5.gz
[08:03] <ogra> -rw-r--r-- root/root      2824 2007-08-29 17:41 ./usr/share/man/man1/nbd-server.1.gz
[08:03] <sbalneav> ah, ok
[08:03] <ogra> all fine here
[08:03] <sbalneav> I just saw an update for nbd-client come down.
[08:03] <sbalneav> server hasn't updated yet, I guess
[08:03] <ogra> yeah, as i said, same source package
[08:03] <sbalneav> oh, wait, no, mine wouldn't :)
[08:03] <ogra> both should be updated at the same time
[08:04] <sbalneav> I've GOT the new one installed :)
[08:04] <sbalneav> durrrr
[08:04] <ogra> right, you have the patch in your binary already :)
[08:04] <calc> iwj: got another MIR for you if you have time... libwpg :)
[08:05] <pkern> ion_: Hm, there are currently two mkinitramfs currently concurrently.
[08:08] <pkern> ion_: http://durotan.0x539.de/~pkern/two-mkinitramfs.png
[08:57] <dilomo> hi
[09:04] <pkern> Is Ubuntu's boot prompt *after the installation* graphical (i.e. is a pixmap used in grub)?
[09:05] <LaserJock> pkern: after installation of what?
[09:05] <pkern> LaserJock: Gutsy Tribe fwiw
[09:05] <LaserJock> no, I don't believe so
[09:05] <pkern> LaserJock: Fine, thanks.
[09:06] <LaserJock> the idea is to keep grub as out of the way as possible
[09:06] <LaserJock> that's why the menu isn't show by default
[09:06] <pkern> LaserJock: Ah, nice.
[09:06] <LaserJock> I mentored a Google Summer of Code student working on a grub config gui
[09:07] <dilomo> and what is the progress bar like?
[09:07] <LaserJock> perhaps when that gets integrated then it'll be easier to do
[09:08] <pkern> Yep, no graphics... yay.
[09:15] <_MMA_> I have GIMP crashing on 2 machines if I resize a image. Should I post this as a bug? http://paste.ubuntu-nl.org/35583
[09:16] <ion_> mma: Try running G_SLICE=always-malloc gimp. Ive had some crashing problems with it and that seems to be a workaround. I havent got around to investigating and reporting the problem yet.
[09:18] <LaserJock> I was doing some research last night and gnumeric wouldn't start up at all
[09:18] <LaserJock> fun crazy gutsy gibbon
[09:19] <_MMA_> ion_: Yeah. Thats works. :( Shame though.
[09:19] <ion_> mma: If you report it, please mention the bug ID to me, ill subscribe to it.
[09:20] <ion_> (Perhaps its reported already, i havent even checked that.)
[09:25] <_MMA_> ion_: Ok Well best I can do is post the pastebin. Is that fine for now?
[09:27] <ion_> mma: Its probably easiest to post a bug report with apport.
[09:32] <_MMA_> ion_: Bug 135650
[09:32] <ubotu> Launchpad bug 135650 in gimp "GIMP crashes when trying to resize an image." [Undecided,New]  https://launchpad.net/bugs/135650
[09:33] <ion_> Thanks
[09:34] <_MMA_> np
[09:48] <Mithrandir> hm, anybody know what runs the stuff in /etc/xdg/autostart when the session starts?
[09:49] <ion_> xfce4-session :-)
[09:49] <jwendell> Mithrandir, gnome-session ?
[09:49] <ion_> In gnome, probably gnome-session.
[09:49] <Mithrandir> well, whenyou're not using xfce4-session or gnome-session?
[09:49] <Mithrandir> like, when  you're using startx and just a window manager.
[09:50] <ogra> is it started then ?
[09:53] <Mithrandir> hm, is there a tool to "execute" .desktop files, then?
[09:53] <ion_> mithrandir: xdg-open
[09:53] <LaserJock> that works on .desktops?
[09:54] <ion_> Seems to.
[09:54] <Mithrandir> ion_: ah, thanks a lot, I'll try that.
[09:55] <ogra> well, doesnt that need an url ?
[09:55] <ion_> ogra: It accepts plain file paths as well.
[10:01] <alex-weej> cohoba is unmaintained upstream and has died a death. what's the procedure for dropping support for it in Ubuntu?
[10:05] <dholbach> alex-weej: file a bug report, subscribe 'ubuntu-archive' to it
[10:05] <alex-weej> ok
[10:07] <ion_> Is it just me, or has it already been removed from the archive?
[10:08] <Mithrandir> ion_: except it didn't work.
[10:08] <ion_> mithrandir: Strange. Here it works.
[10:10] <Mithrandir> can you look in your mailcap file and see if there's anything referencing it?
[10:19] <Mithrandir> even on my desktop, it just opens it in a text editor.
[10:19] <Mithrandir> that's hardly useful. :-P
[10:21] <ion_> mithrandir: Ah, xdg-open uses open_xfce(), which calls exo-open, which DTRT with .desktop files.
[10:21] <ion_> mithrandir: If youre running gnome, it does something else.
[10:22] <Mithrandir> ah, ok.
[10:22] <Mithrandir> so there might not be any utility which DTRT with .desktop files
[10:23] <ogra> Mithrandir, proably in the xdg-utils package
[10:25] <ion_> mvo: I noticed a way to detect an Xfce environment from xdg-opens code: xprop -root _DT_SAVE_MODE | grep ' = "xfce4"$' >/dev/null 2>&1
[10:25] <ion_> mvo: Perhaps thats helpful with the compiz launcher.
[10:26] <ion_> They could just use xprop -root _DT_SAVE_MODE | grep -q ' = "xfce4"$' though :-)
[10:31] <alex-weej> Amaranth: yo
[10:31] <alex-weej> https://bugs.launchpad.net/bugs/91783
[10:31] <ubotu> Launchpad bug 91783 in compiz "Compiz's default Human-glass look does not "work" visually" [Wishlist,New] 
[10:32] <Amaranth> dude
[10:32] <Amaranth> haven't we gone over this before?
[10:42] <sladen> BenC: did CONFIG_BLK_DEV_IO_TRACE get dropped at some point?
[10:43] <BenC> sladen: Not that I'm aware of
[10:44] <sladen> BenC: I was wondering why I couldn't blktrace;  one mention I found was that it worked <feisty
[10:45] <sladen> oh there's a bug #118303  open
[10:45] <ubotu> Launchpad bug 118303 in linux-source-2.6.22 "CONFIG_BLK_DEV_IO_TRACE is not enabled preventing blktrace from working" [Unknown,Fix committed]  https://launchpad.net/bugs/118303
[10:49] <BenC> sladen: it should be fixed in gutsy
[10:49] <BenC> wont be in feisty
[10:52] <alex-weej> Amaranth: i was just giving you the bug ID...
[11:09] <sladen> BenC: the "Fix Commited" is for the Debian BTS report, not the Ubuntu one;  is it also now fixed in Gutsy?
[11:10] <BenC> sladen: doesn't appear so
[11:19] <geser> doko: have you time to look at the gnupginterface debdiff in bug #36733?
[11:19] <ubotu> Launchpad bug 36733 in adonthell "package includes *.py[co]  files" [Medium,Confirmed]  https://launchpad.net/bugs/36733
[11:22] <doko> geser: well, that should be triaval, could you have a look yourself?
[11:22] <geser> doko: I provided it, I need now a main sponsor for it
[11:23] <BenC> sladen: enabled and pushed for next upload
[11:23] <sladen> BenC: woo, thank you
[11:24] <superm1> infinity, cprov it would appear that promethium (xen-amd64) is freezing again on the same build: https://launchpad.net/+builds/promethium
[11:26] <doko> geser: uploaded
[11:27] <geser> doko: thanks
[11:36] <cprov> superm1: garr ...
[11:42] <superm1> cprov, don't worry about sorting it out right now, you guys have more pressing issues to get the launch going :)
[11:43] <cprov> superm1: I let it stuck so infinity can debug the problem (he should show up soon)
[11:43] <superm1> okay sounds good
[12:05] <bigon> Is there any way to get the ubuntu developer keyring?