[00:08] <seb128> Caesar, pawalls: doh, I'm not awake, the glib and gvfs I pointed before, it should not use a ! before the strcmp comparaison
[00:08] <pawalls> seb128, *nods*
[00:08] <seb128> Caesar, pawalls: could you remove the ! in the glib change and try again?
[00:09] <pawalls> seb128, That was what I was going to do :-P
[00:09] <pawalls> seb128, However I'm wrapped up with another bug at the moment. Was hoping to get to it within the next 30 mins.
[00:09] <seb128> pawalls: ok, it's 1am here so I'll not be around for a while but I'll try to wait a bit, I would like to know if that fixes the issue
[00:11] <pawalls> seb128, Ok.. give me just a second then.
[00:11] <seb128> pawalls: thanks!
[00:13] <infinity> Unpacking mktemp (from .../mktemp_1.5-5ubuntu1_i386.deb) ...
[00:13] <infinity> dpkg: error processing /var/cache/apt/archives/mktemp_1.5-5ubuntu1_i386.deb (--unpack):
[00:13] <infinity>  trying to overwrite `/bin/mktemp', which is also in package debianutils
[00:13]  * infinity boggles that this hasn't been fixed yet...
[00:14] <infinity> Wait..
[00:14] <infinity> slangasek: Dude, your changelog claims to have fixed the above bug, but I see no Replaces in the control info...
[00:17] <pawalls> seb128, FYI.. g_get_home_dir returns the exact entry from passwd, which (generally) doesn't have a '/' at the end.
[00:17] <infinity> slangasek: Another case of "write the changelog before the fix, get distracted, upload"? :)
[00:17] <slangasek> hmm, odd
[00:17] <pawalls> So if you had two users (pawalls and pawalls2 let's say), they one user would get the mounts of the other.
[00:18] <pawalls> seb128, My understanding based on looking at the glib code.
[00:18] <slangasek> infinity: well first of all, it hasn't "been fixed yet" because it was un-fixed post-etch in the Debian package
[00:18] <pawalls> so we might want to change that to "%s/", g_get_home_dir()
[00:18] <slangasek> as for how I missed it in the upload, ... no idea
[00:19] <seb128> pawalls: well, neither the mount_point nor the user directory should have it no?
[00:19] <pawalls> seb128, You're using 'has_prefix'
[00:19] <pawalls> Which means.. if someone mounted /home/pawalls2/something it would show up for pawalls
[00:19] <infinity> slangasek: Yeah, I know it was unfixed, I assumed mvo's upgrade testing would have caught it eons ago, that's all. :)
[00:19] <pawalls> Which is why the trailing / is important.
[00:20] <seb128> pawalls: ah, that's a good point
[00:20]  * pawalls nods.
[00:22] <infinity> ... and now all my postinst scripts are segfaulting.
[00:22] <pawalls> seb128, Of course it is ;-)
[00:28] <seb128> pawalls: so it's working better now?
[00:28] <pawalls> seb128, compiling.
[00:29] <seb128> ok
[00:41] <pawalls> seb128, Appears to have worked.. let me confirm on my other box so I can log completely out/into gnome
[00:42] <seb128> pawalls: excellent, thanks
[00:46] <slangasek> infinity: mktemp fixed some more
[00:48] <infinity> slangasek: "Slightly more fixed"? :)
[00:48] <infinity> slangasek: (Thanks!)
[00:49] <pawalls> seb128, Looks good.
[00:49] <pawalls> seb128, Thanks again.
[00:50] <pawalls> seb128, I do recommend also adding the '/' onto the end of that comparison though.
[00:50] <seb128> Caesar, pawalls: ok, so nothing weird about the config you are using, that was just a typo in the suggested changed ;-) Sorry for the extra rebuilds, etc
[00:50] <seb128> pawalls: thanks
[00:50] <pawalls> seb128, Yeah.. I wasn't really paying much attention earlier.
[00:51] <pawalls> seb128, I told Ceasar I would hack up a patch and then kinda drifted onto other things.
[00:51] <seb128> pawalls: http://bugzilla.gnome.org/show_bug.cgi?id=525866 btw
[00:51] <ubotu> Gnome bug 525866 in gio "the user directory should not be considered as a mount to display" [Normal,Unconfirmed]
[00:51] <seb128> pawalls: both issues are described there
[00:51] <seb128> pawalls: I'll get the fix in hardy tomorrow
[00:51] <pawalls> seb128, Great!
[00:52] <pawalls> seb128, Thanks again for your help.
[00:52] <seb128> pawalls: you are welcome! and thanks for pointing the issue and testing the change ;-)
[00:53] <seb128> enough for today
[00:53] <seb128> good night everybody, see you tomorrow
[01:45] <infinity> slangasek: I'll be your VERY BEST FRIEND, if you do NEW processing for LRM (I fiddled with queues to make sure it built everywhere, should be good to go)
[02:05]  * keescook slaps himself
[02:12] <slangasek> BFF-infinity: done
[03:33] <Khajavi> I want to install codeblock (C++ IDE)
[03:34] <Khajavi> dpkg -i libcodeblocks0_8.02-0ubuntu1_i386.deb
[03:34] <Khajavi> libcodeblocks0 depends on libwxgtk2.8-0 (>= 2.8.7); however:
[03:34] <Khajavi> what do I do?
[03:35] <Khajavi> :-X:-(
[03:42] <protonchris> Khajavi: try apt-get -f install
[03:44] <Khajavi> protonchris: this command didn't work
[04:38] <genii> Are there any plans to incorporate some incremental apt system? (zsync or similar)
[04:40] <genii> There seems someone made a start on it ~7.04    https://blueprints.launchpad.net/ubuntu/+spec/apt-sync  but it looks stalled
[04:45] <userone> best mobo for linux?
[04:46]  * RAOF fails to see how that's a question relating to the development of Ubuntu.
[04:51] <rhineheart_m> any plans to include webmin back to the repo since it has been maintained already?
[04:56] <LaserJock> rhineheart_m: I doubt it, we have ebox
[05:06] <rhineheart_m> LaserJock, but ebox has limited features.. and I guess it is still immature
[05:09] <pwnguin> so LP provides openID -- is it going to consume it?
[05:09] <LaserJock> pwnguin: "not at this time"
[05:10] <LaserJock> rhineheart_m: well, if webmin's getting maintained in Debian it might come back. We dropped it when Debian did
[05:11] <pwnguin> LaserJock: so now it's a game of which is the longer timeline "eventually" (as in, eventually we see LP being open sourced) or "not at this time"
[05:12] <LaserJock> pwnguin: I don't think it really matters either way
[05:12] <rhineheart_m> can you recommend the use of ISPConfig for ubuntu-server ed?
[05:13] <genii> rhineheart_m: I've set it up and used it under 6.06 but it was a headache to get operating correctly
[05:13] <LaserJock> the point of the openID stuff was to allow various things (like forums, wiki, Fridge) to authenticat using LP
[05:14] <pwnguin> what about QA?
[05:14] <rhineheart_m> genii, uhuh. really? but have you tried it with gutsy? or anybody here uses ISPConfig and has something to share too?
[05:16] <genii> rhineheart_m: I go from LTS to LTS so not bothering with 7.10 server. When 8.04 release comes I'll attempt it again if you want a review later
[05:16] <LaserJock> pwnguin: the Ubuntu QA sites?
[05:16] <rhineheart_m> genii, is that a server? are you using it for server?
[05:17] <genii> rhineheart_m: Yes
[05:18] <rhineheart_m> genii, is there something wrong with 7.10?
[05:18] <pwnguin> LaserJock: yea
[05:22] <genii> rhineheart_m: Probably not anything the matter with 7.10 server, just a matter of personal preference for me to stay with 6.06 until next LTS (8.04)
[05:23] <rhineheart_m> genii, okay.. I got you.. so the next stable LTS version of ubuntu is 8.04 (Hardy)... any idea when it will be made available?
[05:24] <genii> rhineheart_m: April 24 apparently
[05:24] <rhineheart_m> okay.. so I will wait for its release.. I am actually to try debian..
[05:28] <rhineheart_m> genii, have you tried debian/?
[05:29] <genii> rhineheart_m: Not on any of my personal boxes but I have to minimally deal with it on two servers
[05:33] <rhineheart_m> genii, are you hosing several domains in your box?
[05:34] <genii> rhineheart_m: There were previously 3 domains for those two machines, it's since been reduced to one
[05:35] <rhineheart_m> okay.. how do you manage multiple domains in one box?
[05:36] <genii> rhineheart_m: Primary and scondary DNS answering to those domain name lookups, virtual hosts in apache and postfix
[05:36] <LaserJock> pwnguin: yeah, I imagine that would be a big part to. Anything we can get an openID module/plugin for.
[05:37] <rhineheart_m> genii, okay.. I used actually webmin to do the task. I thought you're using something different..
[05:38] <genii> rhineheart_m: We ssh in and do everything in CLI
[05:40] <genii> Since we are drifting OT and there seems no answer to my original question I'll leave you all to be
[06:31] <dholbach> good morning
[06:55] <kagou> Good morning
[07:13] <warp10> Good morning
[07:34] <hunger> When will bzrzools become installable again? It always fails to install here (it keeps failing in "Preparing to replace bzrtools 1.0-1ubuntu3)
[07:35] <hunger> make that 1.2.0, not 1.0.
[07:37] <dholbach> bug 201978
[07:37] <ubotu> Launchpad bug 201978 in python-central "pycentral crashed with OSError in prepare()" [Medium,Triaged] https://launchpad.net/bugs/201978
[08:21] <kagou> hey seb128
[08:22] <seb128> lut kagou
[08:43] <tkamppeter> Riddell, ping
[09:00] <\sh> moins...
[09:00] <\sh> did anyone saw a break in d-i kernels and broadcom netextreme bcm5704 gbit nics on yesterdays daily (ubuntu-server flavour)
[09:01] <\sh> s/saw/see/
[09:01] <pitti> Good morning
[09:01] <ion_> Howdy
[09:01] <\sh> hey pitti
[09:03] <ogra_cmpc> hey pitti
[09:04] <\sh> ogra_cmpc, do you need somehow the debian-edu package?
[09:04] <ogra_cmpc> no
[09:06] <\sh> ogra_cmpc, well, it ftbfs on lpia and amd64...
[09:06] <\sh> ogra_cmpc, that's why I'm asking
[09:08] <ogra_cmpc> \sh, nothing to do with me, its the defaults for the debian-edu cd/distro
[09:14] <\sh> cjwatson, where can I find the udeb for the NIC drivers which are loaded from d-i during install? I thought they were under pool/main/l/linux/
[09:30] <pitti> calc: any chance to fix bug 114503 before you upload o-l10n?
[09:30] <ubotu> Launchpad bug 114503 in ubuntu-meta "language-support-* packages depend on Firefox, Thunderbird and Open Office Writer on Ubuntu and Kubuntu" [Undecided,Invalid] https://launchpad.net/bugs/114503
[09:30] <pitti> it's trivial, but serious
[09:30] <pitti> trivial to fix, I mean
[09:31] <mantiena-baltix> hello all
[09:31] <pitti> calc: ah, you uploaded already
[09:31] <mantiena-baltix> doko_: hi
[09:34] <dholbach> Keybuk: can you say a bit more about your "answer" in bug 211159? :)
[09:34] <ubotu> Launchpad bug 211159 in udev "prevent create_devices in postinst from failing" [Low,Won't fix] https://launchpad.net/bugs/211159
[09:35] <\sh> damn...looks like yesterdays iso of ubuntu-server is borked
[09:36] <Fujitsu> Why did this morning's upgrade throw me back to ubuntulooks, and apparently remove the option to go back to the much nicer Human/Murrine?
[09:37] <seb128> Fujitsu: because ubuntulooks looks better and the other themes were buggy
[09:37] <\sh> Fujitsu, that was announced...
[09:37] <seb128> Fujitsu: and it has been decided to roll back
[09:37] <seb128> though I agree that could have kept the corresponding gtkrc variants, didn't hurt
[09:37] <seb128> you need to ask to kwwii and mvo about that
[09:38] <Fujitsu> I knew the default was being changed, but I didn't think it'd remove the option.
[09:38] <Fujitsu> ubuntulooks looks a whole lot worse, IMO.
[09:38] <seb128> Fujitsu: that's a joke, right? the other theme had blue tooltips and some very visible bugs
[09:38] <Fujitsu> Erm? My tooltips were a pleasant orange.
[09:39] <seb128> I had blue at some places
[09:39] <seb128> that was not tooltips I think
[09:39] <seb128> but the nautilus bars at the top of the burn location for example
[09:39] <Fujitsu> Hmm, that was orange too.
[09:40] <dholbach> I didn't have anything in blue either
[09:40] <seb128> maybe you used an another theme than me
[09:40] <Keybuk> dholbach: ?
[09:40] <Keybuk> dholbach: vserver prevents the postinst from creating device nodes
[09:40] <seb128> anyway I'm not the one who decided
[09:40] <Keybuk> udev cannot work without those device nodes
[09:40] <Keybuk> therefore the postinst has to fail
[09:40] <seb128> and I think ubuntulooks looks better
[09:41] <Keybuk> ah
[09:41] <Keybuk> it looks like Launchpad rudely discarded my comment
[09:41] <pitti> mvo: lts-ubuntu> eww
[09:42] <dholbach> Keybuk: ok, thanks
[09:42] <mvo> pitti: yeah :(
[09:42] <pitti> mvo: does it get much better if removed packages get purged?
[09:43] <mvo> pitti: interessting questions, I can test that in a bit
[09:43] <Keybuk> dholbach: sometimes I think I put the comment under the add a comment bit, and then change the status
[09:43] <Keybuk> LP UI bug :-/
[09:44] <dholbach> Keybuk: np
[09:45] <Keybuk> dholbach: if postinst fails in create_devices, you won't have /dev/null, /dev/console and other useful things ;)
[09:46] <dholbach> Keybuk: I just purged udev - I just thought it'd be useful if udev didn't break in postinst - but I agree it's a special case where it probably doesn't make sense
[09:46] <mantiena-baltix> calc: hi, are you online ? I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy), maybe you already did this job ?
[09:46] <Keybuk> that would mask failures on legitimate systems, e.g. disk full
[09:46] <dholbach> *nod* fine with me
[09:47] <ogra_cmpc> Fujitsu, orange ? do you have edubuntu-artwork installed ? that uses orange and a dark red by default
[09:47] <Fujitsu> ogra_cmpc: It was the correct Ubuntu orange. No, I don't have it installed.
[09:47] <ogra_cmpc> ah, k
[09:50] <mantiena-baltix> doko_: or maybe you can tell me something about OOo 2.4 backport to Gutsy ?
[09:53] <doko_> mantiena-baltix: no, do you want to make one?
[09:56] <mantiena-baltix> doko_: I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy) now :) (firsty try was unsuccessful because of incorrect build-deps - mono-1.0-dev doesn't exist in gutsy). I'm wondering maybe someone already did this job and I don't need to backport openoffice 2.4 ?
[09:57] <doko_> mantiena-baltix: no, don't know of anybody who did it
[09:58] <\sh> cjwatson, it seems, something went wrong with the ubuntu-server daily cd building yesterday...
[09:59] <mantiena-baltix> doko_: ok, then I will replace mono-1.0-devel and mono-2.0-devel dependancies with ones from gutsy and try again :)
[10:03] <Ng> mjg59: I think that in conjunction with doing the network module unload on suspend, we should do an init.d/networking restart on resume, otherwise some things get very confused
[10:03] <Ng> mjg59: i.e. the manual network configurmatron sees no devices on resume without restarting networking
[10:08] <cjwatson> \sh: they are. nic-modules
[10:08] <cjwatson> \sh: I imagine it's just kernel version out of sync with d-i
[10:08] <cjwatson> happens
[10:09] <\sh> cjwatson, yep..looks like...
[10:09] <mantiena-baltix> doko_: btw, maybe you know when calc will be online ?
[10:10] <ogra_cmpc> mantiena-baltix, US timezone ... rather in your afternoon
[10:10] <\sh> cjwatson, the nic-modules packages are missing (well more then 3/4 of the packages in this dir are missing...) I think it was really the -14 upload which bugged ... coincidence
[10:10] <cjwatson> \sh: it's not buggy.
[10:11] <mantiena-baltix> ogra_cmpc: thanks
[10:11] <cjwatson> \sh: it's just that we haven't uploaded d-i to match it yet.
[10:11] <cjwatson> \sh: please don't file a bug about this - this always happens if we don't get the timing just right.
[10:13] <\sh> cjwatson, won't do that anyhow...that's why I was pinging you :)
[10:14] <cjwatson> \sh: I'll bring things back into sync today
[10:14] <\sh> cjwatson, ok..because right now, I'm unable to test the >2TB patch :)
[10:26] <Ivshti> Hi
[10:26] <Ivshti> Why dont we include graphical configuration tools in Ubuntu?
[10:26] <Ivshti> Like the tools in Mandrake/Mandriva?
[10:27] <Ivshti> I mean tools like drakconf, so the user can easly configure the system.
[10:27] <seb128> Ivshti: to configure what?
[10:28] <seb128> Ivshti: ubuntu has graphical configuration tools
[10:28] <ogra_cmpc> seb128, mandrake indeed, else it wouldnt be called drakconf :P
[10:28] <seb128> ogra_cmpc: ah, right ;-)
[10:28] <ogra_cmpc> Ivshti, what are you missing from the shipped tools ?
[10:29] <Ivshti> Test Mandriva and you will see
[10:29] <Ivshti> everything is in one control panel
[10:29] <pwnguin> well thats constructive., lets just take a break from the final strech in an LTS to install mandriva
[10:30] <seb128> Ivshti: that's not the question
[10:30] <Ivshti> you start drakeconf, and from there you can configure all the things, while in ubuntu you must search for the needed tool
[10:30] <seb128> Ivshti: the question is what option is lacking in the current ubuntu tools
[10:30] <mantiena-baltix> Ivshti: Ubuntu has control panel, just install gnome-main-menu package and add "Start" menu applet to your panel
[10:30] <seb128> Ivshti: that's a design decision, a zillion options in one dialog is not something easier to use
[10:31] <seb128> Ivshti: run gnome-control-center?
[10:31] <Ivshti> for example I want to resise a partition... In Mandrake/Mandriva I just start drakeconf (one way or another) and I click on "manage disk partitions"
[10:31] <Ivshti> in ubuntu I must search for Gparted
[10:31] <Ivshti> and what if I dont know what is Gparted :D
[10:31] <Ivshti> A user will search for "configure computer" or "configure partitions" or something like this
[10:32] <ogra_cmpc> so you are missing a partition editor in the default install, what else ?
[10:32] <seb128> Ivshti: it's called partition manager in the menu, it's as easy to search for it there than in a dialog which has zillion options
[10:32] <Ivshti> hmm, the control panel must be build-in
[10:32] <seb128> Ivshti: no thanks
[10:32] <Ivshti> sorry, It was "Gparted" in the version I've tested :D
[10:32] <mantiena-baltix> Ivshti: control panel is already build-in since Ubuntu 7.10
[10:32] <mantiena-baltix> Ivshti: which Ubuntu version you use ?
[10:33] <Ivshti> 7.10?!
[10:33] <Ivshti> No, I mean "7.10", I am 100 % sure
[10:33] <ogra_cmpc> mantiena-baltix, its not set as default, we disaabled it because it had usability issues vs the menu structure
[10:33] <Amaranth> mantiena-baltix: it is disabled
[10:33] <Ivshti> I will take a look next time I start Ubuntu
[10:33] <ogra_cmpc> (takes about three times as long to get to any option that way ... you have to wait until teh panel started and then search your optionn)
[10:34] <ogra_cmpc> Ivshti, alt+f2 and run gnome-control-center
[10:34] <Ivshti> Yes, of cource
[10:34] <Ivshti> I saw that
[10:35] <pwnguin> personally, i'd call the presence of keyring-manager in both prefs and administration a usability bug
[10:35] <Ivshti> (I am not running ubuntu, but I am runnning gnome)
[10:35] <Ivshti> thanks, a tip: just put this in the "System" Gnome menu
[10:36] <Amaranth> Ivshti: No
[10:36] <Amaranth> Read what was just said about that
[10:36] <mantiena-baltix> Ivshti: look at the contents of /etc/lsb-release file - Ubuntu version should be mentioned there
[10:36] <ogra_cmpc> Ivshti, we diliberately dont
[10:36] <ogra_cmpc> *deliberately
[10:36] <Amaranth> gnomecc also takes some time to load
[10:36] <ogra_cmpc> until the usability of such integrated stuff is on par with the meu system used curretly
[10:37] <ogra_cmpc> *meu
[10:37] <ogra_cmpc> gah
[10:37] <ogra_cmpc> *menu
[10:37] <Amaranth> i can view the menu and load the thing i want by the time gnomecc starts
[10:37] <ogra_cmpc> right
[10:37] <mantiena-baltix> Ivshti: you could report a wishlist bug about putting gnome-control-center launcher in the System menu
[10:37] <ogra_cmpc> mantiena-baltix, ugh
[10:38] <Amaranth> The main problem I have with it is that it pretends to be something special when it's really just a weird display of a menu
[10:38] <Ivshti> This gnome-control-center is very good.
[10:38] <ogra_cmpc> seb128, btw, what about movig baobab ad the printer thingie from accesoires to system tools as well if we keep system tools
[10:38] <seb128> ogra_cmpc: we are getting ride of system tools again I think
[10:38] <Ivshti> But how will one new user know about it
[10:39] <Amaranth> Ivshti: They won't, that's why it is hidden
[10:39] <seb128> ogra_cmpc: users reactions on the list show they prefer not having it in the default install
[10:39] <ogra_cmpc> seb128, ah, good ...
[10:39] <mantiena-baltix> ogra_cmpc: lots of users feels better when they have "control center" - why don't allow them to use  it ?
[10:39] <ogra_cmpc> yeah, understandable
[10:39] <Ivshti> And... that is a  very bad idea.
[10:39] <ogra_cmpc> mantiena-baltix, because itsd totally confusing :)
[10:39] <Amaranth> Ivshti: If you like it you can use it, don't force your choice on others
[10:40] <Amaranth> Ivshti: There are serious problems with it
[10:40] <Ivshti> okay
[10:40] <mantiena-baltix> Ivshti: I support you, so you could report a wishlist bug about putting gnome-control-center launcher in the System menu
[10:40] <Ivshti> And... here is the question... why dont the ubuntu developers put a tool like drakeconf
[10:41] <\sh> da pitti is blogging :) wow :)
[10:41] <Ivshti> Like gnome-control-center but without bugs
[10:41] <mantiena-baltix> Ivshti: some Linux distributions already uses this, for example Novell (Suse) Linux, Baltix Linux and others
[10:41] <ogra_cmpc> Ivshti, what bugs ?
[10:41] <Amaranth> As soon as it starts as fast as clicking the menu and does something more useful than the menu I'm all for it
[10:41] <Ivshti> I just want easyer ubuntu :D
[10:41] <seb128> Ivshti: because it's not better than what we have now
[10:41] <seb128> Ivshti: ubuntu is easy
[10:41] <pwnguin> Ivshti: because Ubuntu chooses to support upstream developers instead of starting yet another project?
[10:41] <Ivshti> yes, I know is easy
[10:41] <Amaranth> Right now the gnomecc is just a slower way to access the same thing the menu gives you
[10:42] <Ivshti> I've tryed Slackware, that means I know Ubuntu is easy (if you get the idea)
[10:42] <seb128> Ivshti: how hard is it to read labels in a menu rather than on an canvas?
[10:42] <seb128> Ivshti: gnome-control-center just lists the menu items in a grid
[10:43] <Ivshti> Yes, but it's litle bit better when all things are in one grid
[10:43] <seb128> no it's not
[10:43] <mantiena-baltix> Amaranth: gnomecc is slow for you, but lots of users feels better when they have "control center" - why don't allow them to use  it ?
[10:43] <Ivshti> because some tools are in the applications menu ;)
[10:43] <ogra_cmpc> Ivshti, beyond telling us we miss gparted in the default install and that gcc has bugs you didnt specify with any details you didnt really tell anything that could convince yet
[10:43] <seb128> you have to search in 2 dimensions
[10:43] <Amaranth> mantiena-baltix: you can enable it in alacarte
[10:43] <Silicium> hi
[10:43] <seb128> Ivshti: you don't want to remove all the menu and put 80 items in a canvas
[10:44] <Ivshti> Okay, you are right...
[10:44] <seb128> Ivshti: gnome-control-center doesn't list applications tools
[10:44] <mantiena-baltix> Amaranth: I already did this in Baltix distro :)
[10:44] <ogra_cmpc> Ivshti, if you can make convincing points i'm sure nobody would object changes, buut i didnt see anything that wo8uld convince me personally to do anything different to what ubuntu does atm
[10:44] <Ivshti> (But drakeconfig does list the applications tools)
[10:44] <seb128> Ivshti: so basically the gnome-control-center is an another view listing the same content as the system menu, not easier to use, just slower to load
[10:44] <Silicium> how i can change the font color of the ubuntu isolinux bootmenu? i dont want to hack the source if is possible
[10:45] <cjwatson> Silicium: which version?
[10:45] <Silicium> 8.04
[10:45] <ogra_cmpc> Ivshti, how about making a real comparison with pro and con lists and send that to the ubuntu-devel-discuss mailinglist ? :)
[10:45] <seb128> Ivshti:  you can use kubuntu it you want complicated interface listing zillion options
[10:45] <Amaranth> eep
[10:45] <pwnguin> zing!
[10:45]  * Amaranth hides
[10:45] <ogra_cmpc> seb128, !
[10:45] <Silicium> cjwatson: u 8.04 isolinux 3.53
[10:45] <mantiena-baltix> seb128: gnomecc is easier for newbies, because it has search entry, also it's easier for Windows OS users
[10:45] <ion_> Awesome bug. :-D gdm played the login sound, like, twenty times and then played the end of the sample again probably as many times.
[10:46] <cjwatson> Silicium: play with 'foreground' and 'background' in /isolinux/gfxboot.cfg
[10:46] <seb128> mantiena-baltix: I'm not convinced
[10:46] <cjwatson> Silicium: the names are actually sort of backwards, sorry
[10:46] <Silicium> there are any documentations about?
[10:46] <ogra_cmpc> ion_, it just wants to tell you its *really* there now
[10:46] <cjwatson> Silicium: afraid not, as far as I know
[10:46] <cjwatson> Silicium: Ubuntu uses 'background=0xB6875A', for example
[10:46] <ion_> ogra: Yeah, "why don't you login already?!?!!"
[10:46] <cjwatson> which is actually the foreground font colour *cough*
[10:46] <Silicium> so i use a Background splash.pcx
[10:47] <Silicium> and the font color is blue
[10:47] <cjwatson> right, so set background=
[10:47] <Amaranth> mantiena-baltix: That's the problem with most of the SLED stuff. It makes it somewhat easier for new users but doesn't grow with you as you become a more advanced user
[10:47] <mantiena-baltix> Ivshti: If you wanna to have some applications listed in gnome-control-center you could report a wishlist bug about that in launchpad or gnome bugzilla ;)
[10:47] <Silicium> cjwatson: ok
[10:47] <Silicium> cjwatson: i will try, thanks :)
[10:47] <pwnguin> ion:  cant get gdm to even let me log in. i wonder if it's just playing nothing twenty times
[10:48] <Amaranth> mantiena-baltix: With a menu a new user can scan it slowly reading for the thing they need, the more advanced user has muscle memory built up for where in the menu the thing they want is and just fly right to it
[10:48] <ogra_cmpc> pwnguin, do you use a facebrowser ? someone had probs here yesterday with that
[10:48] <mantiena-baltix> Amaranth:  you shouldn't tell this to me - I'm advanced user
[10:48] <pwnguin> ogra_cmpc: yea =/
[10:48] <Ivshti> Oh yes, is it legal to include wine in ubuntu?
[10:48] <ogra_cmpc> pwnguin, switch it off until its fixed then :)
[10:48] <mantiena-baltix> Ivshti: yes, why not ?
[10:48] <Ivshti> (Yeah, It's legal)
[10:48] <cjwatson> we aren't aware of legal problems with wine
[10:48] <Ivshti> But why dont you include it?
[10:48] <pwnguin> Ivshti: legal, but do you really want novices running random windows programs they find?
[10:49] <cjwatson> right, the biggest problem with wine is that it can end up being an automatic spyware vector if you're not careful
[10:49] <Lamego> Ivshti, because most people don't need it ?
[10:49] <mantiena-baltix> Ivshti: Baltix distro already includes wine in default CD ;)
[10:49] <Amaranth> Ivshti: Ubuntu is not a Windows replacement, it is a Windows alternative
[10:49] <pwnguin> or filing bugs against ubuntu when windows software doesn't work?
[10:49] <Ivshti> Hmm... windows programs can crash ubuntu too.
[10:49] <pwnguin> i mean, no offense to the wine people who work on ubuntu, but i imagine it'd be a hell of a triage load
[10:50] <Amaranth> Ivshti: I mean it isn't supposed to be a drop-in replacement for Windows, installing WINE by default would make it seem that way
[10:51] <Ivshti> Yeah, I know you are NOT trying to replace Windows...
[10:51] <seb128> mantiena-baltix: what do you remove from the baltix cd to ship wine?
[10:51] <Amaranth> probably mono stuff
[10:52] <Ivshti> And, when speaking about mono...
[10:52] <Ivshti> Why dont you include mono in Ubuntu
[10:52] <Amaranth> No
[10:52] <pwnguin> what?
[10:52] <Amaranth> Ivshti: f-spot and tomboy are installed by default
[10:52] <Ivshti> .NET replacement in uBuntu? Why not?
[10:52] <mantiena-baltix> Amaranth: btw, my view is slightly different from SLED - I think operating system should be easy to use for newbies and for advanced users. That's why Baltix has both ways to access system configuration - gnome-control-center and traditional System->Administration and System->Preferences menus ;)
[10:52] <pwnguin> Ivshti: do you actually run ubuntu?
[10:52] <Ivshti> That wont make Ubuntu to look like Windows replacement
[10:53] <Silicium> cjwatson: nope, does not work
[10:53] <Ivshti> Yes, of coure, I had it installed but... I've installed Mandriva
[10:53] <mantiena-baltix> seb128: you are asking what I removed from Ubuntu CD to have space for wine ?
[10:53] <Amaranth> trying to remember how long ago mono stuff was added
[10:53] <cjwatson> Silicium: it's what we do to make the text brown in Ubuntu menus, so I know it works
[10:53] <Amaranth> 6.10?
[10:53] <pwnguin> so right now, you cant check to see if your claims about what ubuntu does or doesn't do, etc, you can't actually check?
[10:53] <Silicium> so if u use the original isolinux.bin, i have the old ubuntu 6.x menu
[10:53] <ogra_cmpc> Amaranth, yeah, around that
[10:54] <Silicium> and in the 8.04 is the color also blue
[10:54] <cjwatson> "Ubuntu 6.x" isn't something that makes sense
[10:54] <seb128> mantiena-baltix: yes
[10:54] <cjwatson> the 6 is a year, not a series
[10:54] <ion_> Ok, audio is not the only problem. Ethernet doesn't work properly either. Dhcpdiscover goes out but it never gets the response, and there are errors about eth0 in dmesg.
[10:54] <cjwatson> Silicium: no, the Ubuntu boot menu has brownish text in 8.04
[10:54] <Ivshti> Ubuntu CD is... 695 MB... It has space for a litle bit more software
[10:54] <ion_> (After today's kernel upgrade)
[10:54] <pwnguin> hahaha
[10:54] <cjwatson> Ivshti: *we do include mono in Ubuntu".
[10:54] <Silicium> cjwatson: oO on my beta image not :D
[10:54] <pwnguin> oh poor seb
[10:54] <pitti> seb128: hm, seems your --language=python fix in apport now broke the pot, it does not have the glade strings any more
[10:55]  * ogra_cmpc wonders which CD Ivshti is looking at
[10:55] <Silicium> beta-server
[10:55] <pitti> seb128: what's the syntax again for setting a particular format for a POTFILES.in entry?
[10:55] <pwnguin> Ivshti: misstatement of the year
[10:55] <seb128> pitti: doh
[10:55] <cjwatson> Ivshti: the hard limit is 700MB, though
[10:55] <Ivshti> I am looking at 7.10!!
[10:55] <Ivshti> You have 5 MB space!
[10:55] <cjwatson> Ivshti: which we intend to use for more localisation
[10:55] <ogra_cmpc> which we would fill with translations
[10:55] <ogra_cmpc> snap :)
[10:55] <cjwatson> Silicium: oh, right, server is wrong
[10:55] <Silicium> .S
[10:56] <cjwatson> I'll fix that
[10:56] <Ivshti> At least for installed Macromedia Flash player! :D That's very, very important!!
[10:56] <Keybuk> if only stackable filesystems worked properly :-/
[10:56] <pwnguin> Ivshti: there's plenty of consternation every release about what does or doesn't make the cut for space concerns
[10:56] <Fujitsu> .......
[10:56] <Silicium> can i use the isolinux.bin from the desktop version to fix it for me?
[10:56] <cjwatson> Silicium: no, isolinux.bin is the same
[10:56] <Ivshti> NTFS in Ubuntu works perfectly, what is the problem about filesystems?
[10:56] <cjwatson> Silicium: I told you what to put in gfxboot.cfg already
[10:56] <cjwatson> background=0xB6875A
[10:56] <Silicium> cjwatson: ya, but does not work :)
[10:57] <pitti> seb128: if I drop the option from Makevars, a "cd po/; intltool-update -p --verbose" works fine, hm
[10:57] <cjwatson> Silicium: I am quite certain it does, because we use exactly that for Ubuntu (desktop)
[10:57] <seb128> pitti: how fine?
[10:57] <Amaranth> Ivshti: adobe's flash will never be installed by default, it is closed source
[10:57] <Silicium> cjwatson: i will try again
[10:57] <cjwatson> Silicium: I'm afraid you must be doing it wrong somehow. Perhaps you have DOS line endings?
[10:58] <pwnguin> Amaranth: how soon till gnash is in?
[10:58] <cjwatson> anyway, committed a fix for server
[10:58] <Silicium> noe, i have tried background=0x000000 (black) so no i try with exactly you line
[10:58] <Amaranth> pwnguin: i'm pulling for swfdec
[10:58] <cjwatson> I expect background=0x000000 would make all the text go black
[10:59] <cjwatson> like I say, the naming is unfortunately reversed
[10:59] <Silicium> you line does also not work :D
[10:59] <Silicium> mhm can you paste me the whole isolinux.cfg?
[10:59] <cjwatson> isolinux.cfg is not involved
[10:59] <Ivshti> Amaranth: Okay, but I think there is an open-source flash player. There are alot of flash players that have nothing to do with Adobe's flash player!
[10:59] <cjwatson> I said gfxboot.cfg
[10:59] <Silicium> ooh
[11:00] <Silicium> iam sorry
[11:00] <Amaranth> Ivshti: they are...not ready
[11:00] <Amaranth> to put it kindly
[11:00] <Amaranth> getting better all the time though, so i'm still hoping
[11:00] <pwnguin> fun
[11:00] <ion_> Ok, getting rid of kexec and rebooting fixed the problem. :-)
[11:00] <cjwatson> Ivshti: Keybuk was talking about something else with regard to stackable filesystems
[11:00] <cjwatson> not NTFS
[11:00] <pwnguin> ogra_cmpc: so how do i turn off facebrowser without running gdm?
[11:01] <mantiena-baltix> seb128: Ubuntu CD has lots of unneeded stuff, for example unneeded help files, look at bug #80978 for example
[11:01] <ubotu> Launchpad bug 80978 in baltix "[Suggest] Help *.deb packages for each languages" [Undecided,New] https://launchpad.net/bugs/80978
[11:01] <ogra_cmpc> pwnguin, use startx and sudo gdmsetup or so ...
[11:01] <pwnguin> ogra_cmpc: it just tells me that gdm is running.,
[11:02] <Lamego> mantiena-baltix, still those split languages files would need to be available on the Ubuntu cd
[11:04] <Amaranth> Lamego: well, no
[11:04] <mantiena-baltix> Lamego: not all - Ubuntu CD contains support for only most popular languages, while help files are shipper for all languages, even for not supported in CD
[11:04] <Silicium> is it works :DD
[11:04] <Silicium> cjwatson: thanks
[11:04] <pwnguin> ogra_cmpc: or rather, it tells me that gdm isnt running, then closes
[11:04] <Amaranth> but i doubt that would free up much space
[11:04] <pwnguin> which is... not helpful
[11:05] <ogra_cmpc> pwnguin, indeed
[11:05] <mantiena-baltix> Amaranth, Lamego: look how big is /usr/share/gnome/help folder in your system and you see
[11:05] <cjwatson> Silicium: great
[11:05] <ogra_cmpc> might be that you cant get around ediuting the config manually
[11:05] <pwnguin> nuts
[11:06] <ogra_cmpc> pwnguin, well, you are using unreleased software ....
[11:07] <mantiena-baltix> Amaranth, Lamego: in default edubuntu CD (which I currently use) help files uses 140 MB !
[11:07] <cjwatson> mantiena-baltix: I think we probably should look at doing something about it, but not for 8.04; getting it right (e.g. not inadvertently shipping systems without any help) will take a bit of effort
[11:07] <pwnguin> yea, its just annoying to have to dig into gdm.conf when ive not done that before, this close to release
[11:07] <cjwatson> mantiena-baltix: it compresses quite well, so it's not quite that bad
[11:08] <ogra_cmpc> mantiena-baltix, define "default edubuntu CD" :) edubuntu is an addon to ubuntu with hardy
[11:09] <Amaranth> ogra_cmpc: wait, what?
[11:09] <ogra_cmpc> (with about 200M spare space atm, so who cares about size :) )
[11:09]  * Amaranth missed that one
[11:09] <mantiena-baltix> cjwatson: only XML part of help files compesses well, but in /usr/share/gnome/help there are a lot of .png files, which doesn't compress at all
[11:09] <cjwatson> mantiena-baltix: they are often identical across languages, so in terms of a tarball containing all of them they do in fact compress rather well
[11:09] <mantiena-baltix> ogra_cmpc: I'm use Edubuntu 7.10 LiveCD now
[11:09] <ogra_cmpc> ah, k
[11:10] <mantiena-baltix> cjwatson: it's a pitty, but png files are different for several languages, like zh, jp or ko
[11:10] <cjwatson> mantiena-baltix: sure, I didn't say "always identical".
[11:10] <ogra_cmpc> Amaranth, we had the edu software on a separate cd anyway .... so it was cleverer to move over completely and put the core bits only edubuntu had (ltsp) inot ubuntu
[11:11] <cjwatson> and I said "compresses quite well" (i.e. significantly less than the 140 MB you cited), not "compresses brilliantly"
[11:11] <cjwatson> so please stop nitpicking :)
[11:11] <mantiena-baltix> cjwatson: :-P
[11:11] <ogra_cmpc> mantiena-baltix, the sad thing is that svg supports localization since years (2003 or so) and that still pngs are used
[11:12] <ogra_cmpc> but thats not in our hands and requires upstream to do the switch
[11:12] <mantiena-baltix> ogra_cmpc: I think png are used in help because most of them are screenshots
[11:13] <ogra_cmpc> with text on them ;)
[11:13] <ogra_cmpc> menus, toolbars ....
[11:13] <mantiena-baltix> ogra_cmpc: yea, but do you know a way how to make vectorized screenshot ? ;)
[11:13] <Amaranth> OS X screenshots are pdfs
[11:14] <pwnguin> cairo?
[11:14] <ogra_cmpc> that surely would requirre some thinking, but there are ways
[11:14] <pwnguin> Amaranth: are they bitmaps embedded in pdfs?
[11:14] <ogra_cmpc> even potracing a png can work ...
[11:14] <Amaranth> pwnguin: i don't think so, the display server uses something similar to pdf internally
[11:15] <Amaranth> btw, my help folder is 176M and compresses (bz2) to 65M
[11:15] <ogra_cmpc> mantiena-baltix, i didnt say its easy or straghtforward but the capabnility is there since ages, someone needs to write software to make use of it
[11:15]  * cjwatson uploads GRUB with EDD support; please let me know about any device ordering regressions
[11:16] <cjwatson> it won't activate unless you boot with edd=on, so I'm not too concerned about migrating people's menu.lst files
[11:16] <ogra_cmpc> what does it do ? alter the device.map ?
[11:17] <cjwatson> yes
[11:17] <mantiena-baltix> Amaranth: I quess you need only about 50 Mb of help files (quess you know not more than 5 languages :) )
[11:17] <cjwatson> well
[11:17] <cjwatson> it alters the way device.map is constructed if there is none
[11:17] <ogra_cmpc> ah
[11:17] <cjwatson> if device.map is already there, it won't do anything, so definitely no migration problem
[11:17] <ogra_cmpc> so it cant affect the existing one
[11:17] <cjwatson> right
[11:18] <mantiena-baltix> Amaranth: how big are OS X screenshots' ? I mean are they real vector PDF's or only bitmap inside PDF ?
[11:18] <Amaranth> *shrug*
[11:21] <pitti> mvo: http://people.ubuntu.com/~mvo/bzr/hwdb--mvo/po/POTFILES.in -- did those type: fields ever work for you? I just tried to use them in apport, but they seem to be entirely ignored
[11:21] <pitti> mvo: I just get some weird perl warnings
[11:22]  * ogra_cmpc guesses thats for old hwdb
[11:22] <pitti> right, it's ancient, but it's utterly hard to find a documentation about POTFILES.in format
[11:22] <pitti> /usr/bin/intltool-update still has code to process it AFAICS
[11:23] <cjwatson> Keybuk: it just occurred to me (again) that device.map has device names not UUIDs, and so can break on upgrade when devices get moved around; we should do something about that for 8.10
[11:23] <ogra_cmpc> ++
[11:23] <mvo> pitti: I think this stuff worked once, but I was struggling recently with it too and I think it stopped :/
[11:23] <pitti> meh
[11:23] <pitti> mvo: ok, thanks
[11:24] <seb128> we should get danilo to fix it
[11:24] <seb128> he's upstream for intltool
[11:36] <pitti>     foreach (@buf_potfiles) {
[11:36] <pitti>         s/^\[.*]\s*//;
[11:36] <pitti>     }
[11:36] <pitti> seb128: ^ no wonder that [...] doesn't do anything; WTF??
[11:36] <ion_> Heh
[11:37] <seb128> pitti: weird
[11:44] <cjwatson> pitti: what's weird?
[11:45] <pitti> seb128: hm, seems the main flaw is that it tries to put it all into just one xgettext call, which just doesn't work if you mix glade and python files
[11:45] <pitti> cjwatson: I'm trying to figure out why the [type: gettext/glade] etc. syntax does not work in POTFILES.in
[11:45] <cjwatson> pitti: I know, but I was wondering what specifically you were commenting on in the above code
[11:45] <pitti> cjwatson: that seems to be the bit which throws out all the [...] tags
[11:46] <cjwatson> oh, you mean the way it's explicitly stripped off, right :)
[11:46] <seb128> pitti: maybe ask danilo about the issue, as said he's upstream for intltool and might have an idea about the issue
[11:46] <pitti> right, I'll do that
[11:47] <seb128> cool
[11:47] <seb128> I already pinged him about that before doing the apport changes
[11:47] <seb128> that's him who suggested the change I did
[11:48] <phoenix_> About a month ago, I reported a bug, and alas I know I'm not the only one that reports bugs, but this one causes a kernel panic in the raid controller device driver - and I was wondering why the bug is still "undecided".... and I'm a little bit puzzled how bugs are being "decided" to be fixed...
[11:48] <cjwatson> phoenix_: that's the priority; don't stress too much about the priority; some people don't do all the paperwork
[11:49] <cjwatson> phoenix_: about kernel bugs, #ubuntu-kernel is the best place to ask
[11:50] <phoenix_> cjwatson: AFAICS I can't give any hints about the priority, I think that's something the being set by the person that does the triage...
[11:51] <phoenix_> cjwatson: thanks for the channel hint, I'll go ask them about it
[12:04] <pitti> seb128: ok, h4ck1sh, but works: http://bazaar.launchpad.net/~ubuntu-core-dev/apport/ubuntu/revision/1092
[12:13] <Silicium> cjwatson: how works the language selection in isolinux? in isolinux.cfg is the english version written but when i use "german" the menu entries goes german, where are saved the german version of the menu entrie?
[12:17] <davmor2> evand: ping
[12:18] <tkamppeter> Riddell, hi
[12:23] <emgent> heya
[12:28] <cjwatson> Silicium: they're in /isolinux/de.tr
[12:28] <cjwatson> Silicium: that's in a weird compiled format, though - the version in the gfxboot-theme-ubuntu source package is probably more comprehensible, though
[12:28] <cjwatson> s/, though$//
[12:32] <mantiena-baltix> doko_ , calc: maybe you know if I should set BUILD_JARS_NATIVE=n in OOo2.4 Gutsy backport ?
[12:34] <mantiena-baltix> doko_: in gutsy's (OOo 2.3) debian/rules file BUILD_JARS_NATIVE was set to 'n', while in OOo 2.4 from Hardy it's set to 'y'
[12:36] <Riddell> hi tkamppeter
[12:37] <Silicium> cjwatson: how i can create/compile that file?
[12:38] <Silicium> anyway
[12:39] <cjwatson> Silicium: build the gfxboot-theme-ubuntu source package in the usual way for Debian-format source packages
[12:40] <Silicium> ok
[12:40] <Silicium> thx
[12:43] <lool> soren: Hmm I wanted to have a look at ubuntu-vm-builder again, but I don't see the rewrite branch anymore and I don't see its merge in the trunk branch
[13:06] <twi_> ping on https://bugs.edge.launchpad.net/ubuntu/+source/elisa/+bug/201133 ?
[13:06] <ubotu> Launchpad bug 201133 in elisa "Elisa doesn't start" [Undecided,Confirmed]
[13:06] <twi_> it's quite trivial it's only a dep issue
[13:12] <Silicium> includes the actual beta desktop cd a live environment?
[13:13] <cjwatson> Silicium: yes, please try it
[13:17] <Silicium> cjwatson: thanks :)
[13:23] <Riddell> seb128: starting today's Ubuntu Desktop live CD I get "There was an error starting the GNOME Settings Daemon"
[13:23] <Keybuk> cjwatson: just been reading the glibc incident report
[13:23] <Keybuk> it occurs to me that we still haven't fixed the initramfs-tools bug that Mark ran into
[13:23] <Keybuk> which is also my fault, since I've known about that bug for about two years ;)
[13:25] <lamont> hrm... I suspect that hardy-alternate-ia64.iso needs some pruning... 741M is slightly larger than my largest CD-R media...
[13:26]  * lamont wonders if the daily-live dvd for ia64 (830MB) stands a chance of working, or if ia64/hppa should really just have server isos
[13:33] <cjwatson> Keybuk: could you add that to the report?
[13:35] <Riddell> pitti: bug 197819 can be fixed with making jockey use DEBIAN_PRIORITY to high, shall I change that in bzr?
[13:35] <ubotu> Launchpad bug 197819 in jockey "[Hardy]b43-fwcutter install script fails to fetch firmware in first run" [Undecided,Confirmed] https://launchpad.net/bugs/197819
[13:35] <pitti> Riddell: ooh
[13:35] <pitti> Riddell: but isn't that the default priority anyway?
[13:35] <Riddell> pitti: it's currently "critical"
[13:36] <pitti> Riddell: hm, still weird; the question should default to 'true'
[13:36] <cjwatson> debconf's default priority is high, for the record
[13:37] <pitti> cjwatson: right, jockey overrides it to critical, so that the question isn't askd
[13:37] <pitti> asked
[13:37] <cjwatson> ok
[13:37] <cjwatson> why do you say the question should default to true
[13:37] <cjwatson> ?
[13:37] <cjwatson> there's no Default in the .templates
[13:37] <pitti> cjwatson: that code is still from bcm43xx-fwcutter, where that was the case
[13:38] <cjwatson>         db_get bcm43xx-fwcutter/cut_firmware || true
[13:38] <cjwatson>         if [ "$RET" = "true" -o "$RET" = "false" ]; then
[13:38] <cjwatson>                 db_set b43-fwcutter/cut_firmware $RET
[13:38] <cjwatson> unrelated, but that's just bizarre code
[13:38] <cjwatson> "let's put it back, just in case cosmic rays hit it"
[13:38] <pitti> when I apt-get install b43-fwcutter, the dialog defaults to true at least
[13:38] <ion_> Hehe
[13:38] <cjwatson> that's probably chance
[13:39] <cjwatson> I don't think it's defined what happens
[13:39] <pitti> hah, indeed
[13:39] <pitti> sudo DEBIAN_PRIORITY=critical apt-get install b43-fwcutter
[13:39] <cjwatson> and also depends on whether you had previously purged b43-fwcutter or just removed it
[13:40] <pitti> Riddell: hm, then let's ask the debconf question; at least it's explicit then
[13:41] <cjwatson> I assume the reason it should be asked is that you might not have network access
[13:41] <cjwatson> BTW, I was wondering if we should promote b43-fwcutter to main and put it on the CD
[13:41] <pitti> which you need most of the time anyway to get b43-fwcutter itself
[13:42] <cjwatson> because you might be able to use it without network access if you have Mac OS installed
[13:42] <pitti> yeah, in that case it makes sense
[13:42] <seb128> Riddell: do you get it every time? does running gnome-settings-daemon manually does the same?
[13:42] <pitti> Size: 16418
[13:42] <cjwatson> (real case, this came up with a friend yesterday)
[13:42] <cjwatson> seems pretty much the same as ndiswrapper to me
[13:42] <Riddell> calc: today's livefs didn't get built with "The following packages have unmet dependencies:  openoffice.org-help-en-gb: Depends: openoffice.org-writer but it is not going to be installed" (curious since openoffice.org-writer is installed already)
[13:43] <Riddell> seb128: I'm afraid I've rebooted into other things
[13:43] <seb128> Riddell: ok, that's alright
[13:44] <seb128> Riddell: if there is an issue we will figure soon enough
[13:46] <Riddell> evand: recent live CDs won't launch ubiquity from the desktop icon, .xsession-errors has 'error: g_spawn_command_line_sync: Failed to execute child process "/usr/lib/ubiquity/bin/ubiquity kde_ui" (No such file or directory)'
[13:47] <Riddell> evand: strangely starting ubiquity on a command line works fine
[13:47] <pitti> Riddell: I'll upload a fix now, ok?
[13:47] <Riddell> pitti: sure
[13:47] <Riddell> pitti: what are you changing?
[13:47] <pitti> Riddell: I think I'll just drop the DEBIAN_PRIORITY setting altogether
[13:48] <Riddell> ok
[13:48] <pitti> Riddell: b43cutter is the only package so far where we actually wanted it, and now we don't any more
[13:48] <cjwatson> Riddell: that sounds like it genuinely is quoted
[13:49] <cjwatson> as in, the file "/usr/lib/ubiquity/bin/ubiquity kde_ui" does not exist
[13:49] <Riddell> ah hah
[13:50] <Riddell> command line "ubiquity" is fine but "ubiquity kde_ui" as used in the .desktop file gives me that error
[13:50] <cjwatson> hmm, I wonder if hal-lock changed
[13:50] <cjwatson> (see /usr/bin/ubiquity for why I'm wondering this)
[13:52] <mjg59> cjwatson: Hrm. I just tried to create a partition flagged as "dont_use" in ubiquity, got some CD access and now it's hung
[13:52] <mjg59> (yesterday's daily)
[13:52] <cjwatson> mjg59: yes, there's a bug about that
[13:52] <mjg59> cjwatson: It's, uh, running du?
[13:52] <cjwatson> er
[13:53] <cjwatson> bug 132611 is the one I know about
[13:53] <ubotu> Launchpad bug 132611 in ubiquity "Crash of installer when partitioning - "dont_use" filesystem" [Medium,Confirmed] https://launchpad.net/bugs/132611
[13:53] <mjg59> du -s --block-size=1 /rofs
[13:53] <cjwatson> it's probably looping through check.d
[13:53] <mjg59> Ah, yeah, that could be it
[13:54] <mjg59> Yes, pid count is rising rapidly
[13:54] <mjg59> Anything I can save you before starting again?
[13:54] <cjwatson> I bet "PartmanOptionError: partman-target/choose_method should have None (dont_use) option" is in /var/log/installer/debug?
[13:55] <mjg59> Yes
[13:55] <cjwatson> right, in that case no need
[13:55] <mjg59> That's the final line
[13:55] <mjg59> Cool
[13:55] <mjg59> Any workaround?
[13:55] <cjwatson> I'll see if we can figure out what's going on, sorry about that
[13:55] <mjg59> No problem
[13:56] <_MMA_> Not sure if I should ask here or in -devel but has anyone see the "Failed to mount /" issue on the resent Alt disks?
[13:56] <_MMA_> After partitioning that is.
[13:56] <cjwatson> I think you can create it outside ubiquity and then just delete any automatic mountpoint that gets added
[13:56] <mjg59> cjwatson: Hm. Doing sudo killall ubiquity results in me being launched into a full desktop session
[13:56] <cjwatson> mjg59: that's a sort of awkward not-sure-what-to-do thing
[13:56] <mjg59> I appreciate that this is not obviously a bug :)
[13:57] <pitti> Keybuk: if I wanted a command ("rm -f /media/.hal-mtab") to be executed on boot, but *not* on /etc/init.d/hal restart, could I write an upstart script for that?
[13:57] <cjwatson> at least in a desktop you can maybe do something about it
[13:57] <kagou> who does the update of language/translations packages ?
[13:57] <Keybuk> pitti: what about on runlevel changes?
[13:57] <pitti> kagou: me, and in the future, ArneGoetje
[13:57] <ion_> How about putting hal-mtab to a tmpfs?
[13:57] <pitti> Keybuk: preferably not
[13:58] <Keybuk> pitti: does it have to be in /media ?
[13:58] <pitti> ion_: I thought about moving it to /var/run/hal-mtab, but that requires a large upstream patch
[13:58] <Keybuk> pitti: isn't that precisely what /var/run is for?
[13:58] <pitti> Keybuk: right; currently pondering what's easier (remove on boot, or introduce a huge patch to hal to move it)
[13:58] <Keybuk> pitti: you could add it to bootmisc
[13:58] <ion_> ln -s? :-)
[13:59] <pitti> ^ which would go along with a postinst snippet to move it, and maybe a compatibiliyt symlink in /media in case other programs read hal-mtab as well
[13:59] <kagou> oh nice pitti, many changes are done (installer/kernel image) can you do a recent sync for these package, as this, next daily-iso will be a good piece for tests
[13:59] <pitti> kagou: they are automatically updated in hardy twice a week
[13:59] <kagou> oh sorry, i didn't know
[14:00] <pitti> Keybuk: in fact I faintly remember adding that code in the past to bootclean or bootmisc, but it's not ATM; might got droped in a merge, not sure
[14:00] <Keybuk> pitti: it could arguably just go in mtab.sh
[14:00] <Keybuk> since it's related
[14:00] <pitti> Keybuk: I just thought it would be cleaner to ship an upstart script for hal instead of cluttering other standard init scripts with hal stuff
[14:01] <seb128> Keybuk, pitti: meeting? ;-)
[14:01] <pitti> Keybuk: I can live with that :)
[14:01] <pitti> meeting, sure
[14:02] <Keybuk> clutter - meh, HAL is essential ;P
[14:03] <Keybuk> (and will be increasingly so as davidz increasingly merges it with udev)
[14:03] <Keybuk> pedro_: did you want to join #ubuntu-meeting for the desktop team meeting?
[14:04] <pedro_> Keybuk: going now
[14:04] <pedro_> thanks
[14:07] <lamont> Keybuk: does hal know it is? :)
[14:14] <cjwatson> mjg59: ok, apply http://paste.ubuntu.com/6426/ to /usr/lib/ubiquity/ubiquity/components/partman.py and restart the installer
[14:14] <cjwatson> the result is ugly (it should use translated text rather than 'dontuse') but at least it works
[14:28] <james_w> Amaranth: hi, I made some comments in bug 118936, do they make sense? Do you know of a good way we can fix this?
[14:29] <ubotu> Launchpad bug 118936 in alacarte "Alacarte does not recover deleted menu items" [High,Triaged] https://launchpad.net/bugs/118936
[14:36] <mjg59> cjwatson: Rebooted, I'm afraid :(
[14:39] <cjwatson> mjg59: ok, well it works in my tests, so committed
[14:40] <elmo> is anyone else getting messages from SANE on resume?
[14:42]  * ogra_cmpc wishes he could resume first place :P
[14:43] <ogra_cmpc> i'd appreciate any messages ... sane or not :P
[14:44] <mjg59> cjwatson: Do you know what the conclusion was about dealing with the usplash configuration?
[14:47] <cjwatson> mjg59: yeah, I need to arrange for xauth to be passed through when ubiquity reconfigures usplash
[14:47] <cjwatson> so usplash.postinst can get at the display
[14:47] <mjg59> cjwatson: Wurgh. I'm really not convinced that's the best way of doing this.
[14:47] <mjg59> I guess there are issues with getting ubiquity to write it, then?
[14:49] <cjwatson> mjg59: it's usually not good for ubiquity to have excessive package-specific code
[14:49] <cjwatson> much better for it to go in the package where at all possible
[14:49] <cjwatson> it's technically possible to do it in ubiquity, but I'd really rather not unless all other avenues have been exhausted
[14:50] <cjwatson> ubiquity ends up ridiculously big and unmaintainable, and there are problems when packages change their configuration file formats, as they have a habit of doing
[14:50] <mjg59> cjwatson: Hrm. Yeah.
[14:51] <cjwatson> I realise passing through DISPLAY and xauth is nasty as well, but
[14:51] <kirkland> james_w: ping
[14:51] <james_w> kirkland: hi
[14:52] <kirkland> james_w: hi, see https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/206198
[14:52] <ubotu> Launchpad bug 206198 in gnome-system-tools "network manager cannot authenticate" [Undecided,Confirmed]
[14:52] <kirkland> james_w: i noticed you were the last one to upload to it, i think there's a missing dependency, debdiff attached
[14:53] <james_w> kirkland: yeah, I don't think I touched anything that would cause that, but the analysis seems sane
[14:53] <james_w> seb128: what do you think? ^
[14:53] <kirkland> james_w: oh, yeah, sure, i'm not pointing the finger :-)
[14:53] <kirkland> james_w: i'm just remarking that you seem to be close enough to the package to sponsor the diff :-)
[14:53] <seb128> james_w: that I hate g-s-t, looking at the bug ;-)
[14:53] <james_w> seb128: :-)
[14:54] <james_w> kirkland: I can't sponsor I'm afraid, seb128 sponsored my fix.
[14:54] <seb128> hum
[14:54] <kirkland> james_w: ah, okay.  keescook pointed me to seb128 anyway :-P
[14:55] <seb128> I'm not sure policykit-gnome is really required
[14:55] <kirkland> seb128: i can't unlock network-admin with out it
[14:56] <seb128> kirkland: you could use the command line policykit interface to grant your rights and then run the tool no?
[14:58] <Silicium> i.e when i have installed fooapp.deb on my local machine, and then i create a live dist with remastersys, the foo application is on the image, or or only the base system?
[15:01] <kirkland> seb128: there's an "unlock" button at the bottom of the gui presented by network-admin.  how would the command line polkit-* help that?
[15:01] <seb128> kirkland: if you already have the credential it doesn't need to open the password dialog, it'll just unlock for you
[15:02] <james_w> so a recommends would be appropriate?
[15:02] <kirkland> james_w: i think there's already a recommends
[15:02] <seb128> well, I'm pondering since we don't install recommends
[15:02]  * seb128 looks at mvo
[15:02] <mvo> hu?
[15:02] <seb128> that's really mvo's fault then ;-)
[15:03] <mvo> not really, it was a joint fault of me and a missing seeds review
[15:03] <seb128> mvo: right, just teasing you, but not installing recommends is bad, it forces us to abuse depends or to have broken situations for users
[15:04] <kirkland> seb128: so to use the command line polkit-auth, at least some code would be required to acquire that credential if using the gui and not having policykit-gnome
[15:04] <seb128> kirkland: ?
[15:05] <seb128> kirkland: polkit-auth
[15:05] <kirkland> seb128: polkit-* ?  which one?
[15:05] <seb128> I don't understand your question
[15:06] <mvo> seb128: first thing I will upload in intrepid is a new apt
[15:06]  * seb128 hugs mvo
[15:06] <kirkland> seb128: here's the use case....
[15:06] <seb128> kirkland: I understand the usecase thanks
[15:06] <kirkland> seb128: install a very, very minimal xubuntu system
[15:06] <kirkland> seb128: click on networking
[15:06] <kirkland> seb128: click on unlock
[15:06] <kirkland> seb128: go boom
[15:07] <seb128> kirkland: I'm pointing that xubuntu should have a recommends on policykit-gnome as ubuntu-desktop do if it's required
[15:07] <\sh> woot...ubuntu certified for sun hardware, certified by sun...that's a big shot..
[15:08] <kirkland> seb128: ah, okay
[15:09] <seb128> kirkland: gnome-system-tools should recommends it too
[15:11] <kirkland> seb128: okay, i see it recommends gksu
[15:12] <seb128> yes, that's wrong, I though I changed it when I did other changes this week but I didn't clean the changes and forgot that one or something
[15:13] <kirkland> seb128: okay, you want another debdiff, or do you have it?
[15:13] <seb128> attach a debdiff to the bug and subscribe the sponsors
[15:14] <kirkland> seb128:  sponsors being...
[15:14] <kirkland> seb128: yourself?
[15:15] <kirkland> seb128: and move the policykit-gnome from Required to Recommends?
[15:15] <seb128> no
[15:15] <seb128> ubuntu-main-sponsors
[15:16] <kirkland> seb128: okay, and I'm moving policykit-gnome from Depends to Recommends, and removing gksu from Recommends?
[15:16] <seb128> kirkland: https://wiki.ubuntu.com/SponsorshipProcess
[15:16] <seb128> kirkland: right
[15:24] <james_w> does anyone have a dapper vm image anywhere that I could get a copy of?
[15:24] <kirkland> seb128: done.  thanks for your help.
[15:25] <seb128> kirkland: you are welcome, thank you for your work
[15:25] <james_w> or alternatively and help on installing a dapper kernel on hardy?
[15:25] <Keybuk> james_w: let me know if that works ;)
[15:25] <kirkland> james_w: /me shudders
[15:25] <james_w> it won't boot by default because it refuse to generate an initramfs
[15:25] <Keybuk> ahh
[15:25] <Keybuk> thought it might do that
[15:26] <james_w> I've tried stopping udev from preventing it, but the organisation of /lib/modules has apparently changed as well
[15:26] <kirkland> james_w: i have one, but it's 4G, and it'll be tuesday before you finish downloading it from me
[15:26] <Keybuk> what kernel did we ship with dapper?
[15:27] <james_w> .15
[15:27] <Keybuk> ah right
[15:27] <Keybuk> yeah
[15:27] <Keybuk> I really don't think the hardy udev can work on that
[15:27] <james_w> no, it requires .17 IIRC
[15:27] <Keybuk> uevent wasn't even introduced to .17 iirc
[15:27] <elmo> err?  doesn't that some implications for upgrades?
[15:27] <Keybuk> elmo: in the sense that you have to upgrade your kernel?
[15:28] <Keybuk> (from the supported one for the previous release, to the supported one for the current release)
[15:28] <elmo> Keybuk: well the current procedure doesn't upgrade it first
[15:28] <Keybuk> it doesn't have to upgrade it *first*
[15:28] <elmo> Keybuk: so you run hardy udev on dapper kernel, at least for whle
[15:28] <Keybuk> the important thing is to upgrade it before you reboot ;)
[15:28] <Keybuk> no you don't
[15:28] <Keybuk> udev's upgrade leaves the existing one running
[15:28] <elmo> ah, ok
[15:28] <Keybuk> one of the major ways we differ from Debian
[15:28] <cjwatson> the existing daemon, but presumably new rules files
[15:29] <cjwatson> any new uevent will go through those, right?
[15:29] <Keybuk> cjwatson: right, but that's generally ok
[15:29] <cjwatson> I thought there was some new syntax
[15:29] <Keybuk> the worst that happens is hotplugging breaks a little bit
[15:29] <Keybuk> but since you have a big "RESTART NOW!" thingy, that's ok :p
[15:30] <cjwatson> Riddell: could you (get somebody to) try out my changes in ubiquity r2600? You'd need to test the "Use as:" bit in both partition creation and partition editing
[15:30] <Keybuk> "I just upgraded from dapper to hardy, haven't rebooted yet, but now my digital camera doesn't work" ... "reboot then"
[15:30] <cjwatson> Riddell: the code is nasty at the moment because it isn't using a model/view design - I wasn't confident in doing that untested!
[15:30] <cjwatson> but should really be fixed at some point
[15:30] <kirkland> heno: ping
[15:31] <kirkland> heno: i see that you commented on https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/187403/
[15:31] <ubotu> Launchpad bug 187403 in hplip "hplip or dependencies/dependents should explicitly depend on foomatic-filters" [Undecided,Triaged]
[15:31] <Keybuk> I actually thought for a while about adding a udevcontrol command to tell it to stop reloading new rules
[15:31] <Riddell> cjwatson: let me look
[15:31] <Keybuk> but then everything that shipped a new udev rule would have to pre-depend on the new udev, etc.
[15:31] <Keybuk> that was messy
[15:31] <kirkland> heno: I think the same missing dependency needs to be added for hpijs.  looking for a sanity check......
[15:32] <heno> kirkland: looking
[15:34] <Riddell> cjwatson, evand: I tracked down the g_spawn issue to a difference in the way gksudo and kdesu parse arguments, kdesu really work with quotes.  one workaround is to include a single line shell script to launch hal-lock and have kdesu run that
[15:34] <heno> tkamppeter: will you update hpjis re bug 187403 ?
[15:34] <ubotu> Launchpad bug 187403 in hplip "hplip or dependencies/dependents should explicitly depend on foomatic-filters" [Undecided,Triaged] https://launchpad.net/bugs/187403
[15:34] <kirkland> heno: thanks, should I subscribe anyone else to this bug?
[15:35] <kirkland> heno: ie, i have a debdiff attached to it
[15:35] <heno> kirkland: no, Till is the maintainer, just add a hpjis task
[15:35] <kirkland> heno: ;-)  thanks
[15:35] <cjwatson> Riddell: shouldn't be necessary, we can control argument passing
[15:35] <cjwatson> Riddell: so what does kdesu need when called from the shell?
[15:37] <Riddell> cjwatson: I can't find a way to make it happy.  it either passes it as one file, or it splits everything up (in which case hal-lock just runs "ubiquity" which is mostly ok but will run the wrong frontend if the gtk one is installed)
[15:38] <Riddell> kdesu doesn't really work with quotes, is what I ment above
[15:47] <cjwatson> there aren't any quotes, though ...
[15:47] <cjwatson> oh, I think I see what you mean
[15:47] <cjwatson> that's awful
[15:47] <cjwatson> is kdesudo less badly broken?
[15:47] <cjwatson> (and/or usable here at all)
[15:48] <Riddell> cjwatson: our kdesu is kdesudo (it's a dpkg-divert) and we made it work in this way to match kdesu's ugly behaviour
[15:49] <cjwatson> does it work differently if called as kdesudo?
[15:49] <Riddell> cjwatson: no
[15:49] <cjwatson> that sounds like it might be a plan ...
[15:50] <cjwatson> adverbial commands shouldn't muck with spaces like that - that sort of shenanigans can end up being a security hole
[15:50] <cjwatson> and at the very least tends to cause knock-on bugs like this
[15:59] <emgent> heya people
[16:00] <cjwatson> Riddell: I'm looking at a workaround that doesn't involve yet another script, though
[16:00] <cjwatson> Riddell: (and instead involves self-execing)
[16:00] <cjwatson> anyway, phone ...
[16:03] <tkamppeter> heno, I will do so, hpijs contains a PPD generator now and this one generates foomatic-rip-based PPDs.
[16:04] <heno> tkamppeter: thanks
[16:04] <tkamppeter> Riddell, hi
[16:04] <cjwatson> Riddell: could you try http://paste.ubuntu.com/6429/ applied to /usr/bin/ubiquity? I don't have kdesudo installed here at the moment, but I think that will work
[16:10] <Riddell> cjwatson: yes, that works fine
[16:10] <cjwatson> great, will commit that
[16:11] <Riddell> tkamppeter: I'll add back hpijs-ppds to the Kubuntu CDs
[16:13] <tkamppeter> Riddell, thanks, and check whether the Hp inkjets really appear in the KDE Printing Manager, as in bug 209220 they say that the package was already installed and the printer still not listed.
[16:13] <ubotu> Launchpad bug 209220 in system-config-printer-kde "HP DeskJet 5550 not supported in Hardy" [High,New] https://launchpad.net/bugs/209220
[16:14] <Riddell> tkamppeter: ok.  a shame I wasn't able to fix it properly for this release, hopefully next time
[16:23] <Tonio_> cjwatson: I'll try to add a gksu cmdline compatibility layer for kdesudo in the future
[16:23] <Tonio_> cjwatson: probably a -g option or something
[16:23] <Tonio_> cjwatson: unfortunately we can't get rid of the kdesu compatibility by default in order not to break everything...
[16:41] <Keybuk> random QoTD: does anyone know who we can complain to about Google Calendar?
[16:43] <ogra_cmpc> Keybuk, ask leslie ?
[16:43] <Keybuk> I never seem to find her online
[16:45] <ogra_cmpc> she might have a googlemail account *g*
[16:45] <Keybuk> heh
[16:45] <Keybuk> I don't
[16:45] <Keybuk> tbh, I'm after immediate gratification with my problem :p
[16:45] <Keybuk> since it's fixed, or I stop using it entirely
[16:46] <Robot101> Keybuk: any XMPP account will do...
[16:46] <Keybuk> Robot101: ?
[16:47] <Robot101> to talk to people on google talk
[16:47] <Robot101> you don't need a gmail account
[16:47] <Keybuk> does anyone have an address for her?
[17:08] <keescook> Keybuk: have you looked much at process personality settings for upstart?  I think I might need to tweak one...
[17:08] <Keybuk> process personality?
[17:09] <keescook> ("man personality")  the kernel process personality bits: ADDR_NO_RANDOMIZE, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc
[17:10] <keescook> Keybuk: basically, i think, i have to prove it fully, but READ_IMPLIES_EXEC is set by default for process 1 on ia32.
[17:11] <keescook> as a result, until a setuid process is hit (like, say "sudo"), it stays active.
[17:11] <keescook> this causes mmap PROT_READ to get PROT_EXEC included.  and this causes AppArmor to think a process is requesting an executable region of memory.
[17:12] <keescook> AFAICT, READ_IMPLIES_EXEC is no longer needed (it was for old ELF binaries: http://lwn.net/Articles/94068/)
[17:13] <Keybuk> set by default _just_ for process 1?
[17:13] <keescook> well, it's passed from parent to child.
[17:13] <cjwatson> it's a legacy binary; you haven't built it since 12:15 this afternoon
[17:13] <Keybuk> cjwatson: damn, dude
[17:13] <keescook> the point being that we've see mmap PROT_EXEC at boot, but after we sudo to root, it's gone.
[17:14] <Keybuk> keescook: ?
[17:14] <Keybuk> pretend that this baffled look means you have to explain things to me ;)
[17:14] <keescook> Keybuk: I'm working on it.
[17:14] <keescook> :
[17:14] <keescook> er :)
[17:14] <keescook> Keybuk: rewinding -- we have been seeing issues with AppArmor profiles (only on ia32)
[17:15] <keescook> when we generated the profile originally, mmap-opening of regular files (with only PROT_READ) happen, and get flagged as "r" (read access)
[17:15] <keescook> on a reboot, that same process suddenly needs "m" (mmap with PROT_EXEC) access, so the service fails (usually)
[17:16] <asac> bryce: Option      "XAANoOffscreenPixmaps" "true" ... can we have that by default in hardy?
[17:16] <Keybuk> ok
[17:16] <Keybuk> just mmap?
[17:16] <Keybuk> or any kind of file access (like ld.so)
[17:16] <keescook> right.  this was a way to work around the addition of the non-executable memory stuff that was added to the kernel (see lwn URL above)
[17:17] <Keybuk> not sure I follow
[17:17] <Keybuk> the LWN link was a bit "since you know what I'm talking about" :)
[17:17] <keescook> it seems that old ELF didn't have a "mark this region as executable" flag.
[17:18] <keescook> oh, I didn't mean it that way, I meant it as "here's this thing I found that helped me understand"
[17:18] <mjg59> Keybuk: Where has my sub-pixel anti-aliasing gone?
[17:19] <keescook> to work around the need for the PROT_EXEC on hardware that didn't support the non-exec CPU bit, the kernel added READ_IMPLIES_EXEC, so that "old" mmap calls that were missing PROT_EXEC would get it added automatically.
[17:19] <mjg59> Keybuk: Metacity and gnomepanel seem to be managing it, gnome-terminal is greyscale
[17:19] <Keybuk> mjg59: didn't you want gnome-terminal to be greyscale?
[17:19] <mjg59> Keybuk: No?
[17:20] <Keybuk> s/greyscale/differently filtered/
[17:20] <mjg59> I wanted it not to have obvious colour fringing, which is rather different :)
[17:20] <Keybuk> ArneGoetje: changed fontconfig, xft or cairo recently?
[17:20] <Keybuk> keescook: I meant that the author clearly assumed readers knew what he was talking about
[17:21] <Keybuk> keescook: I see
[17:21] <Keybuk> so if you do mmap (PROT_READ) you automatically gain PROT_EXEC
[17:21] <keescook> if the READ_IMPLIES_EXEC personality bit is set, yes.
[17:21] <asac> bryce: thats for #182038
[17:21] <Keybuk> ok
[17:21] <keescook> and READ_IMPLIES_EXEC vanishes once you pass through a setuid process.  (like, sudo)
[17:22] <keescook> my understanding is that READ_IMPLIES_EXEC is totally unneeded for modern distros.
[17:22] <Keybuk> how does a process's personality work?
[17:22] <Keybuk> is a personality inherited from a parent?
[17:22] <Keybuk> is it initialised to a default on fork() or is it initialised on exec() ?
[17:22] <keescook> yes, though masked with a "is-it-setuid?" filter
[17:23] <keescook> exec, it seems
[17:23] <Keybuk> "yes" to a 3-choice question
[17:23] <Keybuk> ah
[17:23] <Keybuk> so when you exec(), the process gains a personality?
[17:23] <keescook> it just gets the parent personality
[17:23] <Keybuk> ?
[17:23] <Keybuk> that kinda just contradicts what you said <g> ?
[17:23] <Keybuk> personalities, iirc, were so you could run BSD binaries on Linux, right?
[17:24] <keescook> we're probably talking past eachother on some subtle symantic point.
[17:24] <keescook> no, I don't think so.
[17:24] <keescook> they're for various internal kernel thingies (see the top of /usr/include/linux/personality.h for the list)
[17:25] <Keybuk> yeah, and below that is the list of system types
[17:25]  * ogra_cmpc wonders if there is also a schizophrenia.h then
[17:25] <keescook> ah-ha!  okay, then that part is true.  (this is a relatively new area for me too...)
[17:26] <Keybuk> so what I'm trying to understand is
[17:26] <keescook> though I see none include READ_IMPLIES_EXEC.  :)
[17:26] <Keybuk> 1) is Upstart's personality wrong?
[17:26] <Keybuk> Upstart makes use of mmap(), so I could understand why this flags your apparmor profiler
[17:26] <Keybuk> I don't need EXEC, so I could do without it
[17:26] <keescook> 1) perhaps -- I'm suspecting so (it gets the kernel default, which includes READ_IMPLIES_EXEC on ia32 only)
[17:26] <Keybuk> that implies Upstart needs to call personality() which is a bit odd really
[17:27] <Keybuk> especially since this is working around people who didn't read the mmap() manpage properly
[17:27] <keescook> it's not a problem with upstart directly, it's that it's children (i.e. init.d services) get that personality flag too
[17:27] <Keybuk> right
[17:27] <Keybuk> so that's the next bit
[17:27] <Keybuk> 2) if I change Upstart's personality, is that change inherited by Upstart's children (ie. everything)
[17:27] <Keybuk> signal masks, settings, resources, etc. are *all* inherited
[17:27] <keescook> it's not a workaround for mis-use of mmap -- the kernel adds PROT_EXEC against the will of a process calling mmap if READ_IMPLIES_EXEC is in the personality.
[17:28] <keescook> 2) yes.
[17:28] <Keybuk> 3) when is the personality changed?
[17:28] <cjwatson> 2) but the linker will put it back if necessary, if I understood Kees' link correctly
[17:28] <keescook> It is my theory that upstart's personality on x86 is only READ_IMPLIES_EXEC, and 0 on amd64.
[17:28] <Keybuk> 3b) should Upstart support setting the personality in the job description
[17:28] <Keybuk> 3c) if Upstart sets the personality, is it pointless because the link-loader resets it
[17:29] <Keybuk> if so, how does the link-loader know what it should be? :p
[17:29] <keescook> 3) personality is changed either via a call to personality(), or during exec, with PER_CLEAR_ON_SETID is removed from the personality.  (currently (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE))
[17:29] <keescook> 3b) no clue, but this is one of the many reasons I wanted to discuss it before diving in any further.  :)
[17:30] <Keybuk> which all pretty much sums up with
[17:30] <Keybuk> - if the link loader sets the personality
[17:30] <keescook> 3c) what I want upstart to do is UNset READ_IMPLIES_EXEC.  the linker won't re-add that.
[17:30] <Keybuk> - what do we need to change to make Upstart have the right personality?
[17:30] <Keybuk> - why not just change the default in the kernel?
[17:30] <keescook> pers = personality(0xffffffff); pers |= ~READ_IMPLIES_EXEC; personality(pers);
[17:30] <Keybuk> &=
[17:31] <keescook> sorry, yes
[17:31] <Keybuk> yeah
[17:31] <keescook> getting kernel changes in this late is Hard(tm)
[17:31] <Keybuk> but if Upstart's personality is inherited by everything else
[17:31] <Keybuk> then that's basically the same
[17:32]  * lamont adds sync requests for bind9 (to make jdstrand happy) and postfix (to make scottk happy)
[17:32] <keescook> and the kernel vs upstart is the other main reason I wanted to discuss it with you.  :)
[17:32] <Keybuk> there's a lot of implications here I'd like to understand first
[17:32] <Keybuk> I tend to assume that deliberately overriding kernel defaults in userspace in ways that are hard to un-override is silly
[17:32] <Keybuk> if the kernel default is wrong, fix the kernel :p
[17:32] <Keybuk> (which is why I campaign against any modprobe options -- just change the default in the damned module)
[17:33] <keescook> heh
[17:33] <Keybuk> I guess I'm thinking:
[17:33] <Keybuk> If personalities are inherited from the parent, changing the personality in Upstart is identical to changing the default personality in the kernel
[17:34] <keescook> upstream kernel is notoriously conservative.  while I would agree this makes more sense to fix in the kernel, I'm trying to a) minimize the number of kernel changes, and b) make the change somewhere that if we've overlooked something, we can quickly and easily fix it
[17:34] <Keybuk> If personalities are set on exec by the link-loader, then we should fix the link-loader to not set that for binaries that don't need it (which may be as simple as rebuilding the binary, no?)
[17:34] <Keybuk> what's so bad about kernel changes?
[17:34] <Keybuk> the patch will be the same size no matter where it's applied <g>
[17:34] <elmo> Keybuk: people not using ubuntu kernel lose
[17:34] <keescook> :)
[17:34] <keescook> ah, there's that.
[17:34] <Keybuk> elmo: they probably lose anyway
[17:35] <Keybuk> they certainly don't deserve to win :p
[17:35] <cjwatson> (don't you have people using upstart on non-Ubuntu ...?)
[17:35] <elmo> Keybuk: err, I thought you wanted upstart to be used by non-Ubuntu folks?
[17:35] <keescook> nah -- upstream kernels boot okay.  the kernel team even advocates using them to test for driver issues, etc.
[17:35] <Keybuk> cjwatson, elmo: I don't see that this is a problem unique to Upstart?
[17:35] <ogra_cmpc> cjwatson, fedora uses it by default in the next release
[17:35] <Keybuk> it's not doing anything weird here, no?
[17:36] <cjwatson> Keybuk: FWIW (a) I haven't understood the problem enough to say where it should be fixed (b) I'm just saying that "fix it in the Ubuntu kernel, screw upstream" is wrong - I agree in general that fixing things in the kernel when they belong there is correct
[17:36] <cjwatson> does sysvinit have the same problem?
[17:36] <Keybuk> cjwatson: I don't mean "screw upstream", "push" would be abetter verb :p
[17:36] <cjwatson> heh
[17:36] <Keybuk> it worked with SELinux <g>
[17:36] <keescook> cjwatson: I haven't checked, but AppArmor upstream had mentioned they'd seen similar bugs, and he was going to check on it in SuSE
[17:37] <Keybuk> I finally got them to agree that initramfs was the right way to set the policy, not by patching init <g>
[17:37] <Keybuk> sysvinit itself doesn't use mmap()
[17:37] <Keybuk> Upstart does
[17:37] <Keybuk> but that should only affect that process, not its children
[17:37] <Keybuk> (since sysvinit doesn't change any personality flags)
[17:37] <cjwatson> unless the linker does magic, like the PT_GNU_STACK thing
[17:38] <Keybuk> like adding the flag if you use mmap? :p[
[17:38] <Keybuk> eww
[17:38] <keescook> it's just the passing of the personality READ_IMPLIES_EXEC bit to children that I care about.  none of our distro needs it (but until now it did no harm)
[17:39] <cjwatson> well, PT_GNU_STACK gets added if the toolchain thinks you need an executable stack. In theory this could be something similar. (I'm not saying it's PT_GNU_STACK BTW, it's just an analogy)
[17:41] <keescook> cjwatson: AFAIU, it's directly related to PT_GNU_STACK, actually.
[17:41] <keescook> kernel loader:
[17:41] <cjwatson> aha. but upstart does not seem to have the relevant ELF section
[17:41] <keescook>         if (elf_read_implies_exec(loc->elf_ex, executable_stack))
[17:41] <keescook>                 current->personality |= READ_IMPLIES_EXEC;
[17:41] <keescook> default:
[17:41] <keescook> ./include/linux/elf.h:# define elf_read_implies_exec(ex, have_pt_gnu_stack)     0
[17:41] <keescook> ia32:
[17:42] <keescook> ./arch/x86/ia32/ia32_binfmt.c:#define elf_read_implies_exec(ex, executable_stack)     (executable_stack != EXSTACK_DISABLE_X)
[17:43] <cjwatson> where does 'executable_stack' come from?
[17:43] <keescook> tracking it now, it's related to PT_GNU_STACK in fs/binfmt_elf.c
[17:43] <keescook> ./include/linux/binfmts.h:#define EXSTACK_DEFAULT   0   /* Whatever the arch defaults to */
[17:43] <Ng> tkamppeter: thanks for your reply about the Xerox and poppler
[17:43] <cjwatson> 'objdump -x /sbin/init | grep -i gnu' doesn't show it
[17:43] <keescook> ./fs/binfmt_elf.c:      int executable_stack = EXSTACK_DEFAULT;
[17:44] <keescook> then there's a chunk that looks for PT_GNU_STACK
[17:44] <Ng> tkamppeter: I'm curious if the distro team is aware of the apparent poppler madness :)
[17:44] <keescook> cjwatson: see line 774 of fs/binfmt_elf.c
[17:45] <Ng> which branch of distro is poppler under? desktop or platform?
[17:46] <Ng> specifically I care about bug #207776, which tkamppeter suggests is the result of broken postscript, and that it is by no means alone
[17:46] <ubotu> Launchpad bug 207776 in poppler "[hardy] printing some PDFs from evince is crashing our Xerox printer" [Undecided,New] https://launchpad.net/bugs/207776
[17:48] <keescook> hm, the more I follow the implies-exec code, the less sane I feel.
[17:50] <cjwatson> keescook: right, but only if there is such a section - I don't think there is here
[17:50] <cjwatson> unless it's in the initramfs
[17:50] <cjwatson> which execs upstart later
[17:51] <keescook> well, I'm really starting to scratch my head since it seems like this should get set for amd64 too
[17:51] <ArneGoetje> Keybuk: please define "recently" :P
[17:51] <keescook> instead of wasting everyone's time more, I'll go poke at this a bit more.  I feel like I have a better idea what to look for now.
[17:52] <seb128> Ng: does gs opens the ps correctly?
[17:54] <tkamppeter> Ng, Poppler needs really to be fixed. It does not only crash Xerox prnters with its PostScript, the output quality on printers which do not crash is very bad, a lot of unreadable small fonts.
[17:55] <elmo> seb128: yes, but it looks terrible
[17:55] <elmo> seb128: (but neither ghostscript nor the kernel crash, so we're one up on Xerox ;-)
[17:56]  * Ng adds the above question and answer to the bug
[17:57] <Keybuk> keescook: back
[17:57] <seb128> well, I would argue that the printer should not crash on incorrect ps or that cupsys should not send a broken ps to the printer
[17:57] <Keybuk> the kernel stuff certainly implies to me that personalities *aren't* inherited
[17:57] <seb128> but right, would be nice to fix
[17:57] <keescook> Keybuk: no problem, I'm still reading kernel code... well, they are, but the linker also sets some.
[17:57] <Ng> seb128: absolutely the printer should not crash, and I have asked xerox to make it so
[17:58] <keescook> i.e. if I set ADDR_NO_RANDOMIZE and exec cat /proc/self/maps, randomization is clearly disabled.
[17:58] <lamont> hrm... why is it that right after I minimize firefox 3.0, it unminimizes itself?
[17:59] <keescook> I'm still following the per-arch paths for elf_read_implies_exec.  the way I read it, everything should exec with READ_IMPLIES_EXEC, but since that's clearly not true, I'm scratching my head.
[17:59] <Keybuk> it's not copied in fork though?
[18:00] <seb128> Ng: thanks
[18:00] <keescook> I assume it's copied in fork, yes.  but then the loader does stuff to it on exec.
[18:01] <Keybuk> keescook: I don't see where
[18:02]  * Keybuk is reading copy_process()
[18:02] <keescook> Keybuk: I haven't looked at kernel code, I did that test experimentally.
[18:05] <Keybuk> ah, no, it is
[18:05] <Keybuk> personality is directly in task_struct, so it will be
[18:05] <Keybuk> ok, so personality is inherited unless otherwise overridden
[18:06]  * keescook boots a 32bit vm
[18:06] <Keybuk> on x86 READ_IMPLIES_EXEC is always removed
[18:06] <keescook> where do you see that?
[18:06] <Keybuk> set_personality_64bit()
[18:06] <Keybuk>         current->personality &= ~READ_IMPLIES_EXEC;
[18:06] <Keybuk> mmmm, hacky
[18:06] <keescook> hah
[18:06] <Keybuk> it just always masks it out when setting it ;)
[18:07] <keescook> durrr
[18:07] <keescook> the code says what it _should_ do is define the elf_read_implies_exec macro to '0'.  oh well.
[18:07] <keescook> that at least explains my confusion then.
[18:08] <Keybuk> ok
[18:08] <Keybuk> so the kernel can chose to _add_ the read_implies_exec flag
[18:08] <Keybuk> and it will inherit down to any other proces that removes it
[18:08] <Keybuk> it's never cleared by the kernel
[18:09]  * keescook beats head on wall.
[18:10] <keescook> 32bit doesn't have it set either.
[18:10] <keescook> (based on a call to personality())
[18:10] <Keybuk> ?
[18:11] <keescook> from the code I see in the kernel for binfmt_elf.c, it looks like READ_IMPLIES_EXEC gets set if PT_GNU_STACK is missing.
[18:11] <keescook> you found where it gets cleared for 64bit.
[18:12] <keescook> I don't see how it stays cleared for 32bit.
[18:12] <Keybuk> ?
[18:13] <Keybuk> it doesn't
[18:13] <keescook> when I call personality(0xffffffff) on 32bit, it comes back 0.  I would expect READ_IMPLIES_EXEC.
[18:14] <Keybuk> (gdb) p personality(0xffffffff)
[18:14] <Keybuk> $1 = 0
[18:14] <Keybuk> right]
[18:14] <keescook> I'm curious how that's possible, given the logic in binfmt_elf.c
[18:15] <Keybuk> #define elf_read_implies_exec(ex, executable_stack)     (executable_stack != EXSTACK_DISABLE_X)
[18:15] <Keybuk> so the read_implies_exec flag is added if executable_stack *is not* EXSTACK_DISABLE_X ?
[18:15] <keescook> right, and executable_stack == EXSTACK_DEFAULT
[18:16] <keescook> which != EXSTACK_DISABLE_X
[18:19] <keescook> aw, I can't ptrace init.  ;)
[18:20] <Keybuk> init=/bin/bash :)
[18:20] <keescook> but I can ptrace a child, and it does have it...
[18:20] <Keybuk> ok
[18:20] <Keybuk> so something is removing that personality()
[18:21] <keescook> right... *scratch head*
[18:21] <keescook> the PER_CLEAR_ON_SETID happens during exec for a setid process.
[18:21] <keescook> but it seems like non-setid children would get the flag back.
[18:22] <Keybuk> what sets that executable stack bit?
[18:22] <Keybuk> ie how would it get set to EXSTACK_DISABLE_X ?
[18:22] <keescook> afaict, via a PT_GNU_STACK entry with NX in it
[18:22] <mdz> pitti: I took advantage of the kernel update to test your fsck/usplash fix, and it worked fine this time (with /forcefsck)
[18:22] <jdstrand> lamont: \o/
[18:23] <keescook> sorry, PF_X
[18:23] <pitti> mdz: yay
[18:23] <Keybuk> keescook: what would one of those look like?
[18:23] <mdz> pitti: that is, usplash is still broken for me, but fsck displays progress bars correctly
[18:23] <pitti> mdz: I usually test with tune2fs -C 50 /dev/..., but force should work as well
[18:23] <mdz> so it was tested in the same case AFAICT
[18:23] <mdz> now to figure out why usplash is broken
[18:23] <pitti> mdz: broken in what way?
[18:23] <pitti> stopping prematurely?
[18:23] <keescook> Keybuk: going on what cjwatson showed, we'd see it in objdump -x
[18:23] <mdz> pitti: it only displays during initramfs
[18:24] <Keybuk>   GNU_HASH    0x4023c8
[18:24] <Keybuk> like that?
[18:24] <mdz> and seems to dispappear instantly when init starts
[18:24] <keescook> Keybuk: unsure, let me see what I can find.
[18:24] <Keybuk> quest scott% objdump -x /sbin/init | grep -i gnu
[18:24] <Keybuk>   GNU_HASH    0x400678
[18:24] <Keybuk>   3 .gnu.hash     00000038<PHONE_NUMBER>400678<PHONE_NUMBER>400678  00000678  2**3
[18:24] <Keybuk>   6 .gnu.version  000000c8<PHONE_NUMBER>40133e<PHONE_NUMBER>40133e  0000133e  2**1
[18:24] <Keybuk>   7 .gnu.version_r 00000030<PHONE_NUMBER>401408<PHONE_NUMBER>401408  00001408  2**3
[18:24] <Keybuk>  25 .gnu_debuglink 0000000c<PHONE_NUMBER>000000<PHONE_NUMBER>000000  0001b9d0  2**0
[18:25] <keescook> http://sourceware.org/ml/binutils/2003-05/msg00741.html
[18:25] <cjwatson> Keybuk: gnu.stack or gnu.attr, I believe
[18:25] <cjwatson> the sections above are (afaik) innocuous for this purpose
[18:25] <Keybuk> cjwatson: I don't see any binaries with that
[18:25] <mdz> I also noticed I was unable to ^C fsck; I'm pretty sure that used to work ages ago
[18:25] <Keybuk> do you have an example of one?
[18:25] <cjwatson> the names have gone through an iteration or two
[18:25] <mdz> Keybuk: did that change with upstart?
[18:25] <cjwatson> not offhand; maybe wine or mono?
[18:25] <Keybuk> mdz: yes
[18:26] <mdz> Keybuk: is it a bug?
[18:26] <cjwatson> it's a long time since I last looked at this
[18:26] <cjwatson> warty or thereabouts
[18:26] <Keybuk> mdz: it was kinda deliberate ;)
[18:26] <Keybuk> cjwatson: mono hasn't
[18:26] <mdz> Keybuk: I don't understand
[18:27] <Keybuk> mdz: there is an unexplained difference in behaviour between Upstart and sysvinit when it comes to the ownership of /dev/consoe
[18:27] <Keybuk> unexplained in that the code is identical, but produces different behaviour
[18:29] <bryce> asac, I'll see if that may have some side effects
[18:29] <ogra_cmpc> bryce, qfunk poked me about bug 211385
[18:29] <ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
[18:29] <Keybuk> mdz: if Upstart gives sys-rc "ownership" of the console, then X will crash
[18:30] <Keybuk> so "telinit 3" while running X becomes disasterous
[18:30] <bryce> ogra_cmpc: me too
[18:30] <ogra_cmpc> heh
[18:30] <Keybuk> the identical code in sysvinit appears to be fine
[18:30] <mdz> Keybuk: I don't see a bug open about it
[18:30] <Keybuk> so to work around that, we don't give sysv-rc ownership of the console, instead we just put output to it
[18:30] <ogra_cmpc> bryce, well, at least we'll always have his latest code that way :P
[18:30] <Keybuk> mdz: I find filing bugs and assigning them to myself slightly eerie
[18:31] <Keybuk> especially when I end up replying to my own comments
[18:31] <mdz> Keybuk: I find a bug report a good place to record my thinking about a bug so that it's around for reference
[18:31] <bryce> ogra_cmpc: do you have any issues with including it?
[18:31] <ogra_cmpc> mdz, usplash breakage -> is your /etc/usplash.conf ok ?
[18:31] <ogra_cmpc> bryce, not from my side, but i dont have the HW to test
[18:31] <pitti> doko_: a dapper->hardy install has /etc/skel/.bash_profile, a fresh hardy install doesn't; is that deliberate?
[18:31] <Keybuk> mdz: I use TODO lists for that
[18:31] <mdz> ogra_cmpc: 1600x1200
[18:32] <mdz> that's the same as my X session
[18:32] <Keybuk> trouble is, it's a damned annoying bug to play with
[18:32] <Keybuk> because the only way to test it is to repeatedly kill X :p
[18:32] <Keybuk> (which is usually where one is editing the code)
[18:32] <ogra_cmpc> mdz, ah, k, i recently saw it not working where someone had an empty file
[18:33] <bryce> ogra_cmpc: thanks
[18:33] <ogra_cmpc> Keybuk, thats what god lets grow virtual machines for :)
[18:33] <ogra_cmpc> (or soren ...)
[18:33] <Amaranth> i was gonna say screen plus vim/emacs (no wars here)
[18:34] <mdz> Keybuk: ok to copy your remarks to the bug I'm filing?
[18:35] <Keybuk> mdz: sure
[18:35] <doko_> pitti: yes, that's .profile now
[18:35] <pitti> doko_: ok, so that should be cleaned up on upgrade, I figure; I'll file a bug
[18:38] <doko_> pitti: really, not only if it's unmodified?
[18:38] <pitti> sure, only unmodified
[18:38] <pitti> otherwise it shuold be renamed in preinst, then the user will get a proper dpkg conffile prompt
[18:39] <doko_> ugly
[18:40] <mdz> the default usplash timeout is 15 seconds, yes?
[18:40] <mdz> it doesn't seem to be running for that long in total, much less between commands
[18:40]  * ogra_cmpc has systems where it runs 90sec
[18:43] <pitti> mdz: hm, hard to say; too many init scripts change the value
[18:43] <mdz> pitti: but I'm talking about initramfs
[18:43] <mdz> it's dead already when S01readahead is running
[18:44] <tjaalton> bryce, asac: it would break 2D performance
[18:44] <pitti> mdz: but yeah, the defautl is 15
[18:44] <mdz> but it's running before that
[18:44] <asac> tjaalton: for whom?
[18:44] <tjaalton> asac: those who don't run compiz
[18:44] <asac> tjaalton: for those that currently see black rectangles in firefox?
[18:45] <asac> tjaalton: yeah. i think only those that don't use compiz see black rectangles where images should be
[18:45] <Spads> and since ATI gets no more compiz...
[18:45] <asac> i think every ati user except those running EXA have black rectangles without that option
[18:46] <asac> but EXA wouldn't be hit by that i guess
[18:47] <mjg59> asac: Given that we didn't have that as default in gutsy, what's changed?
[18:47] <pitti> mvo: so, I reduced the dapper->hardy /etc diff to 173 KB
[18:47] <asac> mjg59: images are scaled by X
[18:47] <pitti> mvo: I'm through
[18:47] <bryce> asac, -ati only, or also -fglrx or -radeonhd?
[18:47] <asac> mjg59: at least thats what i understand (in cairo=
[18:47] <ogra_cmpc> mjg59, firefox not only scales fonts alone anymore
[18:47] <asac> bryce: fglrx as well
[18:48] <asac> bryce: i think everything that uses normal XAA code
[18:48] <keescook> Keybuk, cjwatson: we want readelf -l $EXEC | grep GNU_STACK not objdump.
[18:48] <pitti> mvo: http://people.ubuntu.com/~pitti/tmp/dapper-hardy-etc.diff FYI; those are the bits which need to be fixed, but I didn't report bugs for yet
[18:48] <keescook> actually, grep -A1
[18:48] <asac> ogra_cmpc: it also scaled images in the past (just not the complete website) ... the difference is that cairo lets X do all the ground work
[18:49] <ogra_cmpc> ah, i didnt know that
[18:49] <mjg59> Ah, ok
[18:49] <asac> we already have a hack because of that in cairo for this behaviour: http://people.ubuntu.com/~asac/corrupted1.png ... but i don't think that we can do something similar for normal images.
[18:49] <bryce> hmm, my main desktop is -ati w/ XAA and no compiz, running current Hardy, and I'm not seeing that issue
[18:50] <asac> bryce: really?
[18:50] <ogra_cmpc> i saw it for a while, but havent seen any non classmate desktop since weeks ... i can go checking though
[18:50] <asac> bryce: http://www.ubuntu.com/files/u3/desktop-tn.png
[18:50] <asac> if i zoom that image in and out
[18:51] <bryce> asac, ah yes
[18:51] <asac> you see it?
[18:51] <bryce> yep
[18:51] <asac> good ;)
[18:51] <mvo> pitti: thanks, I need to leave now, but will have a look later
[18:52] <bryce> asac, ok, so I can reproduce the behavior, but I don't think this has impacted my day-to-day use of the machine very much ;-)
[18:52] <asac> bryce: maybe you don't look closely
[18:52] <asac> bryce: http://www.ubuntu.com/products/WhatIsUbuntu/desktopedition
[18:53] <asac> the page has a black image for me (the one from above)
[18:54] <asac> and thats just one click from ubuntu.com away ;)
[18:54] <bryce> still, I don't think it's so serious that we should adopt a solution that isn't side-effect free
[18:54] <asac> bryce: well. its a serious blocker for sure. you see black images on every second page out there
[18:54] <asac> and performance looks not that bad ... in fact for me scrolling in ffox became faster now :)
[18:55] <asac> bryce: i'd really like to try this and see what the response is ... except of doing nothing
[18:55] <bryce> I've not seen that many black pages to be honest.  Maybe I overlooked them but I don't think so ;-)
[18:55] <tjaalton> there's a reason we have the patch from fedora that is more clever than this option.. if I only could remember it
[18:55] <asac> tjaalton: maybe the patch is what breaks it here?
[18:56] <tjaalton> asac: could be, but dropping it would mean no compiz
[18:56] <asac> bryce: you as me are probably not really the ones that care. but there are a lot of users that look more closely
[18:56] <tjaalton> the upstream bug is marked as a blocker for X.org 7.4, so there should be a solution soon
[18:56] <asac> i don't see those issues, but others are and if you cannot see the image you want to see you have a problem
[18:57] <asac> tjaalton: which upstream bug?
[18:57] <tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=13795
[18:57] <ubotu> Freedesktop bug 13795 in Acceleration/XAA "RenderComposite with XAA renders at wrong position if vertically scaled." [Critical,New]
[18:57] <tjaalton> the one that is attached to the bug :)
[18:57] <asac> tjaalton: can you prod around to see what the state is?
[18:58] <Keybuk> keescook: with the response being non-zero?
[18:58] <Keybuk> ie. we should expect GNU_STACK in the output, but with all zeros ?
[18:58] <Keybuk> (to mean not present)
[18:58] <keescook> Keybuk: IIUC, it's the "RWX" at the end.  "RW" is non-executable.  I'm totally baffled at the moment.
[18:58] <bryce> asac, the risk with these options is that sometimes flipping them on across the board can cause unexpected (sometimes major) issues on some chipsets
[18:58] <Keybuk> wing-commander scott% readelf -l /sbin/init | grep -A 1 GNU_STACK
[18:58] <Keybuk>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
[18:59] <keescook> sorry "E".  look at /usr/bin/gpg
[18:59] <tjaalton> asac: pinged ssp
[18:59] <asac> thx
[18:59] <Keybuk> so gpg means "won't get read implies exec" ?
[18:59] <keescook> right, I cannot understand how these processes have READ_IMPLIES_EXEC set.
[18:59] <Keybuk> or means "read implies exec" ?
[18:59] <keescook> gpg's means it WILL get read_implies_exec
[18:59] <Keybuk> ok
[19:00] <Keybuk> from this, it looks like Upstart *won't* get read_implies_exec
[19:00] <keescook> right!  *bang head on desk*
[19:00]  * Keybuk checks the shells ;)
[19:00] <asac> bryce: thats true, but we will never know if we don't enable that by default ;)
[19:00] <Keybuk> nope, no E there
[19:00] <Keybuk> that would have been an obvious answer
[19:00] <keescook> or things like acpid which I can gdb-attach to and see the r-i-e pers flag
[19:01] <keescook> yet the executable doesn't have "E" in gnu_stack.
[19:01] <asac> bryce: and from what i understand it removes logic that depends on chipset and does it in software with that option
[19:01] <Keybuk> (gdb) p personality(0xffffffff)
[19:01] <Keybuk> $1 = 4194304
[19:01] <Keybuk> ?
[19:02] <Keybuk> (gdb) printf "%x\n", personality(0xffffffff)
[19:02] <Keybuk> 400000
[19:02] <Keybuk> I see
[19:03] <keescook> Keybuk: however, the kernel doesn't _clear_ that flag.  it only ever sets it.
[19:03] <keescook> if GNU_STACK lacks "E", the kernel does _nothing_ to the flag.
[19:03] <Keybuk> (gdb) printf "%x\n", personality(0xffffffff)
[19:03] <Keybuk> [Switching to Thread 0xb7dd86b0 (LWP 8920)]
[19:03] <Keybuk> 400000
[19:04] <keescook> if GNU_STACK *has* E, the kernel *sets* it.
[19:04] <Keybuk> that was a sleep inf spawned from upstart
[19:04] <Keybuk> yes
[19:04] <Keybuk> which is pretty conclusive that upstart has flag
[19:04] <Keybuk> (while running)
[19:04] <keescook> so if the kernel spawns init with READ_IMPLIES_EXEC, upstart will have it.
[19:04] <Keybuk> indeed
[19:04] <keescook> okay.  I feel sane again.
[19:05] <Keybuk> wing-commander scott# readelf -l /usr/lib/klibc/bin/run-init | grep GNU_STACK
[19:05] <Keybuk>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
[19:05] <Keybuk> :-)
[19:05] <Keybuk> there's your E
[19:05] <keescook> \o/
[19:06] <Keybuk> looks like all of klibc has it
[19:06] <Keybuk> initramfs busybox *doesn't*
[19:06] <Keybuk> so it comes from the klibc run-init that runs /sbin/init (which doesn't)
[19:06] <keescook> okay, we need to fix that.  it's likely due to it have assembly routines that lack:
[19:06] <keescook> .section .note.GNU-stack, ""
[19:06] <keescook> in their .S
[19:07] <Keybuk> sweet
[19:07] <Keybuk> I'll leave that with you :)
[19:07] <Keybuk> I have to leave an hour ago <g>
[19:07] <keescook> okay, sounds good.  thanks for digging into this with me.
[19:07] <Keybuk> no worries
[19:29] <keescook> Keybuk: yay full circle.  klibc's author is hpa -- my fellow kernel.org admin.  *slap forehead*
[19:32] <slangasek> tjaalton: why is  bug #120834 marked as 'invalid' for xserver-xorg-video-intel?  this appears to be a driver-specific X server crash?
[19:32] <ubotu> Launchpad bug 120834 in mesa "intel gm965 freezes with 3d applications" [High,Confirmed] https://launchpad.net/bugs/120834
[19:33] <mantiena-baltix> calc: hi, are you online ?
[19:35] <tjaalton> slangasek: the dri driver is in mesa
[19:35] <tjaalton> *from
[19:35] <tjaalton> slangasek: btw, there's a mesa 7.0.3rc3 available ;)
[19:36] <tjaalton> we have rc2
[19:36] <tjaalton> +some fixes from the 7.0.3 branch
[19:37] <slangasek> needs to go through the process, of course...
[19:37] <calc> mantiena-baltix: yea
[19:37] <tjaalton> slangasek: sure
[19:39] <mantiena-baltix> calc: I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy), maybe you already did this job or maybe you already know someone, who are backporting ?
[19:39] <calc> mantiena-baltix: haven't done it and don't know anyone working on it
[19:40] <calc> mantiena-baltix: i still have lots of work to do on hardy's version in the next couple weeks
[19:40] <calc> mantiena-baltix: plus i will be gone for about 5 days to a conference
[19:40] <calc> mantiena-baltix: if you get it working if you want you can send me a debdiff and i will try to get the changes integrated
[19:43] <blueyed> pitti: can you release virtualbox-ose-modules from NEW, or is there a problem with it?
[19:43] <keescook> when did the dpkg FLAG changes go in?  I am nervous about klibc.  :P
[19:44] <infinity> keescook: Do a local test build and boot with it?
[19:44] <keescook> infinity: yup, going to shortly
[19:44] <infinity> keescook: It builds in a matter of seconds on fast hardware. :P
[19:45] <keescook> yeah, doing so now... was just wondering out "loud".  :P
[19:45] <mantiena-baltix> calc: I almost finished the backport - look at https://edge.launchpad.net/~mantas/+archive/+builds?build_text=&build_state=all
[19:46] <calc> 1:2.4.0-3baltix0 ?
[19:47] <calc> looks like the build segfault on i386
[19:47] <calc> in sbuild(?)
[19:48] <mantiena-baltix> calc: yes, there was only one problem with hsqlsb amd64 build (it seems we should backport java-gcj-compat-dev) and also there are i386 ppa builder problems :(
[19:48] <calc> ah ok
[19:48] <calc> yea and mono package split is what is affecting lpia
[19:48]  * calc notes backporting is fun :-\
[19:49] <infinity> Okay, update-grub(8) spawning ucf just seems terribly broken...
[19:53] <ogra_cmpc> hmm, why dont i have write access to devices i have mounted myself ... (or hal on behalf of me at least)
[19:53] <jdstrand> pitti, tkamppeter: I was just testing the cupsys package on hardy, and found that /usr/share/cups/enable_browsing and enable_sharing are missing.  I don't see in the changelog why this happened.  Is this intentional, and if so is there an alternative I can use?
[19:54] <lamont> infinity++
[19:54] <slangasek> why bother, infinity++ == infinity
[19:54] <lamont> meh.  let's just rename him aleph2
[19:54] <infinity> slangasek: Thus proving that the only thing more awesome than me is... Me?
[19:54] <slangasek> lamont: now you're thinking :-)
[19:55] <slangasek> infinity: it just means that you're immune to scalar math :)
[19:55] <ogra_cmpc> slangasek, that really depends who says it ... in a poetic way infinity++ is more :)
[19:55] <slangasek> ogra_cmpc: try it with IEEE fp math ;)
[19:55] <ogra_cmpc> :)
[19:55] <mantiena-baltix> calc: maybe you know how I could solve i386 builder bug ? cprov told me, that I should remove the stuff in [] from the B-d - then i386 builder has a chance to work.
[19:55] <infinity> slangasek: An odd immunity, to be sure, but I suppose things like chicken pox and the measels are passe.
[19:56] <infinity> mantiena-baltix: I'm looking into the bug later today, but it's not going to be a quick fix.  Your best bet is the pare down a bunch of the build-deps that you don't actually need, yes.
[19:57] <Mithrandir> lamont: renaming him aleph1 (or aleph2) would mean he was multiplied by himself.  I'm not sure I want to know about such things.
[19:57]  * infinity makes a note to put "immune to scalar math" on his resume.
[19:57] <lamont> Mithrandir: and there are anatomical challenges there
[19:57] <slangasek> haha
[19:57] <Mithrandir> lamont: LALALALALA
[19:58] <Mithrandir> lamont: I see your lips move, but I can't hear what you're saying.
[19:58] <lamont> Mithrandir: but if we made him aleph2, wouldn't that mean we'd cubed him?
[19:58]  * lamont thinks of bullion.
[19:58] <lamont> or would that be aleph3?
[19:59] <infinity> I'm not entirely sure what being cubed entails, but it doesn't sound pleasant.
[19:59] <lamont> slangasek: for giggles, do your next dput inside of a screen session on hardy, then figure out whether that's a dput bug or a screen bug...
[20:00] <slangasek> I think I may have had enough giggles for one workday
[20:00] <infinity> lamont: The suspense is killing me; what's it do?
[20:01] <lamont> Uploading to mmj (via ftp to archive.mmjgroup.com):
[20:01] <lamont>   postfix_2.5.1-2~gutsy1.dsc: done.
[20:01] <lamont>   postfix_2.5.1.orig.tar.gz: done.                                     postfix_2.5.1-2~gutsy1.diff.gz: done.                                             postfix
[20:01] <lamont> hrm.. that kinda cleaned up
[20:01] <lamont> the dsc is indented 2 chars, the orig.tar.gz, 2 chars, the diff.gz?  -9 chars
[20:02] <calc> mantiena-baltix: eh, that stuff is in the regular build so if that is causing the buildd to fails is really broken
[20:02] <calc> mantiena-baltix: er i mean the buildd is really broken
[20:02] <lamont> and the bottom of things says "... Succe\nfully uploadeded packages.\nNot running dinstall."
[20:03] <calc> mantiena-baltix: buildds have supported foo [arch] build-deps for 8yr+ (afaik)
[20:03] <lamont> calc: since forever, yeah
[20:03] <elmo> calc: that's not the point
[20:03] <calc> elmo: maybe i am missing something about the failure then?
[20:04] <elmo> calc: oo.o's build-depends are a ridiculous size and between that and all the arch conditionals, it causes either a bug in sbuild or a bug in perl itself to trigger and segfault
[20:04] <calc> elmo: ah
[20:04] <elmo> debian's been seeing this for a while now on various arches (arms/mips)
[20:04] <elmo> and now we're seeing it
[20:04] <calc> mantiena-baltix: well you could manually edit the control file (its generated) to remove the parts not needed in build-depends
[20:05] <calc> elmo: ah ok, i didn't know what he meant due to just removing the [] stuff
[20:05] <calc> elmo: a too long string issue?
[20:06] <calc> nice build-dep line is 6920 characters long
[20:06] <slangasek> an unknown issue that causes perl to segfault
[20:06] <mantiena-baltix> calc: btw, maybe you have a i386 gutsy system to build my backported ooo 2.4 ?
[20:06] <slangasek> also, perl segfaulting because a string is too long == perl isn't good for much anymore, is it? :)
[20:06] <calc> mantiena-baltix: nope, don't have a gutsy system here
[20:07] <lamont> calc: and the binaries line length crossed with the log file size is it's own form of painful
[20:07] <calc> mantiena-baltix: i have to make a chroot anytime i work with older releases
[20:07] <calc> lamont: yea build log is a bit huge :)
[20:07] <lamont> oo.o really needs to separate into more sensibly sized pieces...
[20:07] <lamont> I mean, it makes KDE's packages look small
[20:08] <lamont> and _they're_ rediculously large
[20:08] <calc> a large chunk of it is translations
[20:08] <calc> actually a very large chunk of it
[20:09] <calc> 87MB of the diff, plus 81MB of the orig
[20:09] <lamont> Build needed 15:22:23, 8080476k disk space
[20:09] <lamont> 42MB of log
[20:11] <calc> ah kde finally split up their i18n source package (it used to be fairly huge as well)
[20:11] <slangasek> lamont: well, yes - there's a reason we have precisely one person each in Debian and Ubuntu who ever dare to build the damn thing
[20:12] <lamont> yes.  and they still have a long way to go before they approach "sensibily packaged"
[20:12] <lamont> slangasek: I think more than one person each builds kde.... :)
[20:12] <slangasek> lamont: I meant OOo
[20:12] <lamont> geg
[20:12] <lamont> heh
[20:12]  * lamont glares at the keyboard
[20:12] <calc> hell OOo doesn't even follow the FHS
[20:12] <lamont> or rational build process design
[20:13] <slangasek> "hmm, let me think. I could spend 3 hours downloading the orig.tar.gz and 12 hours for each build iteration, or... I could let calc do it."
[20:13] <calc> or choice of language *cough*
[20:13] <slangasek> pythOOon
[20:13] <calc> lets write lots of a already bloated app in java, yipee :\
[20:13] <calc> especially when there is no free stable java available
[20:14] <slangasek> now don't say that, you'll only encourage them to think what they're doing with OOo will be reasonable once there *is* free stable java available :)
[20:14] <calc> 8 years after starting on OOo they may finally have a stable free java in the next year or so
[20:14] <calc> its still crazy but at least might stop crashing every few minutes
[20:15] <elmo> was my fstab meant to be converted to uuids?
[20:16] <ogra_cmpc> elmo, in edgy, yes
[20:16] <elmo> dapper -> hardy upgrade didn't
[20:16] <ogra_cmpc> ouch, sounds like a bug
[20:16] <elmo> it left me a nice fstab.pre-uuid file.  which err, is the same as fstab
[20:16] <slangasek> yes, there's a bug on that
[20:16] <elmo> \o/
[20:16] <slangasek> er, or maybe not, that detail wasn't present in the bug I saw described
[20:17] <elmo> slangasek: what package, if you know?
[20:17] <slangasek> elmo: I think that's 209347 though
[20:17] <slangasek> (from https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
[20:17] <slangasek> )
[20:18] <elmo> thanks
[20:19] <elmo> hmm, on second thoughts, I guess leaving the pre-uuid file around is probably considered a feature
[20:19] <LaserJock> yeah, that would be handy if stuff blows up
[20:19] <slangasek> maybe - but not switching to uuid is still a bug, and one that can render systems unbootable since dapper->hardy also crosses the libata transition
[20:20] <slangasek> (for many controllers, at least)
[20:20] <elmo> sure
[20:20] <lamont> slangasek: "transition" is such a pretty word for "cluster" :-)
[20:20] <elmo> I just don't use ATA in my servers ;-)
[20:20] <slangasek> heh :)
[20:20] <elmo> and whatever code that does this, loses the final newline on fstab </nitpick>
[20:25] <seb128> pawalls: around?
[20:25] <pawalls> seb128, yessir
[20:25] <pitti> jdstrand: it's intentional indeed, since we do not need them any more
[20:25] <pawalls> seb128, how can I help?
[20:25] <jdstrand> pitti: can you elaborate?
[20:26] <jdstrand> pitti: why not needed?
[20:26] <pitti> jdstrand: if you still need the functionality, you need to do the conf file changes yourself
[20:26] <pitti> jdstrand: system-config-printer and the cups webui do that in a much better way, without the need to restart the daemon, etc.
[20:26] <seb128> pawalls: have you seen the patch I attached upstream today for the glib issue?
[20:26] <seb128> pawalls: http://bugzilla.gnome.org/attachment.cgi?id=108556&action=view
[20:26] <jdstrand> pitti: ok-- but is there no use case for cli only?
[20:27] <jdstrand> (other than my testing script :)
[20:27] <seb128> pawalls: it's the same idea than yours done in an easier way (no need to duplicate string and your code doesn't leak the string)
[20:27] <pitti> jdstrand: they were not even in $PATH...
[20:27] <pitti> jdstrand: originally I wrote them as backend for a gnome-cups-manager patch
[20:27] <pawalls> seb128, Cool. Did you see what I mentioned about /.gvfs/ though?
[20:27] <seb128> pawalls: s/doesn't//
[20:27] <jdstrand> pitti: you thought a little thing like that would keep them from me?
[20:27] <pitti> but we don't use that any more
[20:27] <seb128> pawalls: right, looks to that now
[20:28] <pitti> jdstrand: :)
[20:28] <pawalls> seb128, Yeah.. I mentioned in a second comment that there would be memory leak with the g_strconcat unless you free it later :)
[20:28] <seb128> pawalls: could you try my variant to make sure it's ok? I've a package ready to upload to hardy using it
[20:28] <pitti> jdstrand: so, if you really need them back, I can add them again, but it's not an interface I want to keep forever, so I better wanted to drop them in hardy
[20:28] <pitti> jdstrand: of course you are welcome to copy them into the qa-test branch :)
[20:29] <jdstrand> pitti: yes, I was just thinking about that
[20:29] <pitti> blueyed: certainly no problem
[20:29] <jdstrand> pitti: ok thanks!
[20:29] <pawalls> seb128, Sure, I will give it a go.
[20:29] <seb128> pawalls: thanks
[20:29] <pawalls> seb128, I think the gvfs line can just be removed entirely
[20:29] <seb128> pawalls: which one?
[20:29] <seb128> ah .gvfs
[20:30] <pawalls> seb128, The one 4 lines above the one you patched.
[20:30] <seb128> right
[20:30] <pawalls> It's redundant and actually will show other users' mount on everyone's desktop
[20:30] <pitti> blueyed: done
[20:31] <blueyed> pitti: Thanks.. I was just wondering, because it was staying there the whole day, while other packages got processed.
[20:32] <Riddell> calc: Debian still insist on packaging kde l10n as one huge tar, I've always refused to do so
[20:35] <corevette> Who is the webmaster for Ubuntu.com?
[20:36]  * ogra_cmpc wonders if its gvfs's fault that he cant cheat update-manager anymore with loopmounting isos under /cdrom
[20:36] <ogra_cmpc> hrm
[20:37] <pawalls> seb128, building and will get back to you shortly.
[20:37] <seb128> pawalls: thanks
[20:39] <LaserJock> corevette: kinda depends on what you're looking for but https://launchpad.net/~ubuntu-website
[20:44] <calc> Riddell: oh
[20:46] <tkamppeter> jdstrand, the /usr/share/cups/enable_browsing and enable_sharing are intendedly removed as system-config-printer and CUPS do this job by themselves now. KDE Printing Manager is patched to use these tools. The patch has to be changed to use the cupsctl command.
[20:46] <calc> OOo source isn't that big ;-) 1.8G - OOH680_m12
[20:48] <jdstrand> tkamppeter: ah cupsctl-- didn't know about that
[20:48] <jdstrand> tkamppeter: so --[no-]share-printers is obviously for sharing, --[no-]remote-printers is for browsing?
[20:50] <jdstrand> (I'm thinking so...)
[20:50] <pawalls> seb128, Appears to work.
[20:51] <pawalls> seb128, I also tested with removing the if /.gvfs/ conditional and that also worked.
[20:52] <seb128> pawalls: well, .gvfs mounts should never be showed, so the if is wrong
[20:53] <pawalls> seb128, Ahh.. I see.
[20:53] <seb128> pawalls: but the g_unix_mount_is_system_internal (mount_entry) call before filter those out
[20:53] <pawalls> Maybe all dirs beginning with a "." shouldn't be shown?
[20:53] <pawalls> eg.. /home/$USER/.something
[20:53] <seb128> I think there is some discussions upstream about that
[20:53] <pawalls> Cool :)
[20:53] <pawalls> seb128, It actually affects us now, but it's not nearly as big a problem as the home itself being shown.
[20:54] <seb128> pawalls: you have automounts in the user directory too?
[20:54] <pawalls> seb128, :)
[20:54] <pawalls> seb128, snapshots
[20:54] <seb128> pawalls: an another way would be to ignore autofs
[20:54] <jdstrand> tkamppeter: thanks!
[20:54] <pawalls> seb128, *nods*
[20:55] <seb128> pawalls: do you think there is cases where autofs mounts should be displayed?
[20:55] <pawalls> seb128, Not sure how we'd do that though
[20:55] <pawalls> seb128, I can't think of any.
[20:55] <pawalls> seb128, But I'm not sure how you'd find out if it was mounted by autofs.
[20:55] <seb128> pawalls: what is the mtab line for a such mount?
[20:56] <seb128> anything mentioning autofs?
[20:56] <pawalls> seb128, Nothing in /etc/mtab or /proc/mounts makes it obvious.
[20:56] <seb128> hum, k
[20:56] <seb128> ok, one issue at time
[20:56] <seb128> I'll upload this fix for now
[20:56] <pawalls> seb128, Yeah
[20:56] <pawalls> seb128, This patch already makes it heaps better.. and also that we're not showing all directories in /home anymore.
[20:57] <pawalls> seb128, Whatever patch you made to restrict it to /media and /home/$USER really improved things significantly.
[20:57] <pawalls> seb128, Before that, the desktop was just completely unusable.
[20:57] <seb128> pawalls: well, the change is the function we are tweaking since yesterday ;-)
[20:57] <pawalls> seb128, Yep
[20:58] <seb128> I think the media thing is good enough
[20:58]  * pawalls nods.
[20:58] <seb128> we might want a way to let user not show mount in their directory too
[20:58] <ogra_cmpc> ++
[20:58] <seb128> ie, filtering those using .directory for example
[20:58] <pawalls> seb128, Yeah
[20:58] <seb128> but I think that's a less common usecase
[20:58] <pawalls> seb128, Perhaps just a gconf setting for manual blacklist?
[20:58] <seb128> not easy
[20:59] <seb128> glib is way under gconf in the stack
[20:59] <pawalls> glib doesn't depend on gconf I suppose.
[20:59] <pawalls> Yeah
[20:59] <pawalls> seb128, Anyway thanks again. What we have now is a great improvement.
[20:59] <seb128> pawalls: you are welcome!
[21:00] <ogra_cmpc> seb128, i think mounting in homedir is only relly annoying for developers ...
[21:00] <pawalls> seb128, And I'll try to sticking around on IRC in case you have any questions. Feel free to poke me whenever.
[21:00] <seb128> pawalls: ok, thanks
[21:00] <ogra_cmpc> (i found more than 280 nautilus windows one day after running unattended buildscripts in my home tht loop mount stuff)
[21:00] <elmo> how is there not a bug for this bash completion promptage?
[21:01] <ogra_cmpc> i guess general users might appreciate the feature
[21:01] <pawalls> ogra_cmpc, :)
[21:01] <seb128> ogra_cmpc: might still need some tweaking, for example loop mounts should be ignored
[21:01] <pawalls> seb128, I think the way it used to work is that all nfs mounts were ignored.
[21:02] <pawalls> seb128, Which is I suppose why it didn't affect us in Gutsy.
[21:02] <ogra_cmpc> seb128, well, at least as long as you need root anyway to mount it ... if you can mount them by doubleclicking an iso for example, the i'd disagree
[21:03] <ogra_cmpc> but i think that still defaults to fileroller if i'm not wrong
[21:03] <elmo> oh, there is, nm
[21:04] <seb128> pawalls: gnome-vfs seems to be something interesting
[21:04] <ogra_cmpc> ah, no, it defaults to n-c-b
[21:04] <seb128> pawalls: it looks if the device_path is starting by "(pid" and classify those as autofs apparently
[21:04] <Ibycus> hello, anyone here know where i would go to offer an opinion on ubuntu hardy ui?
[21:05] <seb128> pawalls: ups, not starting
[21:05]  * lamont will upgrade his laptop tonight and see if he can get more info for bug 210792
[21:05] <ubotu> Launchpad bug 210792 in consolekit "no sessions after logging in" [Undecided,New] https://launchpad.net/bugs/210792
[21:05] <seb128> pawalls: just if there is a (pid there
[21:05] <seb128> Ibycus: try the forum maybe?
[21:06] <Ibycus> seb128: ok, will do
[21:06] <Ibycus> seb128: a particular subboard?
[21:06] <seb128> Ibycus: no idea about that one
[21:06] <Ibycus> ill have a look
[21:09] <Ibycus> seb128: ill put it here: http://brainstorm.ubuntu.com/
[21:12] <cjwatson> Mithrandir: (aleph0)^2 is still aleph0 - to get a higher order, you need to raise something to the power of aleph0
[21:13] <pawalls> seb128, Ah.. interesting.
[21:13] <cjwatson> (number-theoretic pedantry 'r' us)
[21:15]  * slangasek grins
[21:16] <keescook> doko: are you around?  I'm trying to sort out some note.GNU-stack/GNU_STACK issues when linking.  I have an "E" GNU_STACK that I can't find the origin of...
[21:17] <keescook> (or anyone else...)
[21:17] <ion_> ℵ₀
[21:20] <slangasek> shouldn't that be ℵ⁰ ?
[21:20] <doko> keescook: sorry, have a conference call
[21:21] <keescook> doko: okay, no problem.
[21:22] <ion_> slangasek: Wikipedia doesn't seem to think so.
[21:22] <slangasek> ok
[21:24] <cjwatson> slangasek: it's usually subscripted, or at least was when I was studying number theory
[21:24] <cjwatson> presumably to avoid confusion with exponential notation
[21:25] <slangasek> fair 'nuff, it's been a long time for me so I suppose I was just misremembering :)
[21:26] <cjwatson> of course, what we *don't* know is whether 2^ℵ₀ == ℵ₁ ...
[21:27] <jdong> *grumble* ACPI mWhr discharge rates are estimated from mAh battery capacity decrease, isn't it...
[21:27] <jdong> stupid sanity
[21:43] <RAOF> cjwatson: Well, we do, kinda. We know 2^ℵ₀ == ℵ₁ is independent of ZFC :)
[21:51] <cjwatson> RAOF: I think that's an extremely weak form of "know". :-)
[21:54] <mdke> hi cjwatson, do you have a moment?
[21:55] <cjwatson> mdke: sure
[21:57] <ScottK> slangasek: I just uploaded the unforked version of SE Linux setools.  It will need to get looked at for binary New.  I'm pretty sure I did the transitional packages right, but ...
[21:57] <slangasek> ScottK: ok
[22:11] <calc> grr
[22:11] <calc> getting these icon themes working properly in OOo is pita :\
[22:23] <Riddell> calc: did you look at the issue with the livefs builds?
[22:25] <keescook> doko: I'm trying to understand the live cycle of .note.GNU-stack into GNU_STACK bits.
[22:25] <keescook> at what point does the GNU_STACK get set?
[22:27] <doko> keescook: tbh, I didn't look at this after making it the default for edgy(?)
[22:27] <keescook> doko: this isn't related to -fstack-protector
[22:27] <keescook> that's entirely a code-generation and libc issue
[22:28] <keescook> this is related to how gcc/as mark the GNU_STACK section.
[22:28] <keescook> (as executable or not)
[22:28] <bryce> hey kees, with latest hardy I notice xsane no longer detects my scanner, except when run as root
[22:28] <keescook> bryce: perhaps a udev rule is needed?
[22:28] <bryce> keescook: (which it didn't require on gutsy).  Is this some security thing?
[22:29] <keescook> bryce: nothing I did explicitly.
[22:29] <bryce> ok, strange
[22:29] <bryce> maybe xsane needs gksu now?  hmm
[22:29] <doko> .note.GNU-stack notes are emitted by the compiler, for assembly you have emit these yourself, for the rest, I'll have to look myself
[22:29] <keescook> bryce: check the ownership of the device nodes, etc compared to gutsy
[22:29] <bryce> unfortunately I no longer have gutsy around for checking
[22:29] <keescook> doko: right.  I'm now emitting these in klibc, but the final (shared) link still gains GNU_STACK with "E".
[22:30] <keescook> even though every component being linked in either has the note or doesn't have "E" in it's GNU_STACK.
[22:30] <calc> Riddell: it was just a ooo-l10n wasn't built until this morning issue
[22:30] <calc> Riddell: it wasn't installable on hardy yesterday either
[22:30] <calc> Riddell: at least i am 99% sure that was what the problem was with livefs
[22:30] <keescook> if you have a moment (it's quick to build), can you build klibc on i386 with this patch: http://launchpadlibrarian.net/13099228/klibc_1.5.7-4ubuntu2.debdiff
[22:30] <Riddell> calc: ah, sorted
[22:31] <keescook> doko: then I can show you what I've scratching my head about.  :)
[22:31] <keescook> s/I've/I'm/
[22:31]  * calc thinks he found why it doesn't fall back to the right theme properly
[22:31] <tedg> keescook: BTW, do you know somewhere I could post to ask more about that FF linker bug?  I'd like to figure it out, but I don't know where to go.
[22:32] <keescook> tedg: I don't.  My linker go-to guy is doko.  :)  Perhaps ask asac for pointers to devel channels/mailing lists?
[22:35] <asac> tedg: which FF bug?
[22:36] <tedg> asac: Sorry, not as much a bug, as I can't seem to link with the gnome-keyring plugin :(  https://launchpad.net/~ted-gould/+archive/+build/542813
[22:37] <asac> tedg: what are you trying to do ;)?
[22:37] <tedg> asac: It seems to be something with the linker.  If I link in "-lgnome-keyring" it fails, but "/usr/lib/libgnome-keyring.a" succeeds.
[22:37] <tedg> asac: Make all the authentication tokens for FF be in gnome-keyring.
[22:38] <kirkland`> evand: cjwatson: i'm curious if either of you guys have an opinion on https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/82351
[22:38] <doko> keescook: built, but I made the mistak to look at the current glibc build logs :-/
[22:38] <ubotu> Launchpad bug 82351 in partman-basicfilesystems "support for swap files" [Wishlist,Confirmed]
[22:38] <keescook> heh
[22:38] <asac> tedg: where is that gnome-keyring/ code from?
[22:38] <tedg> asac: Mozilla bugzilla.
[22:38] <keescook> doko: yeah, it builds, and it's certainly different (libklibc correctly lacks "E" in GNU_STACK)  the problem seems to be the utils, which strangely all still have "E"
[22:38]  * tedg tries to say that 10 times fast
[22:39] <kirkland`> evand: cjwatson: i assume it's not something worth pursuing in hardy, due to the fact that it's probably just a minor annoyance and the bug has gotten no attention ;-)  but is it something worth pursuing in Intrepid?
[22:39] <asac> tedg: bug id?
[22:40] <tedg> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=309807
[22:40] <ubotu> Mozilla bug 309807 in Password Manager "Integrate Password Manager with Gnome Keyring Manager" [Enhancement,New]
[22:41] <asac> tedg: 1st. try to apply that to xulrunner-1.9 instead of firefox
[22:42] <tedg> asac: Okay, what's the difference?
[22:45] <asac> tedg: not sure. everything is hidden nowadays ;)
[22:45] <asac> ++-4.2 -o GnomeKeyring.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h
[22:45] <asac> try to remove that business by hand and see if the link then succeeds
[22:45] <asac> the include of gcc_hidden.h i mean
[22:47] <asac> i currently don't understand why it doesn't see the symbols in libgnome-keyring because of that, but i guess its due to that mechansim
[22:47] <asac> tedg: why are you working on that now?
[22:49] <cjwatson> kirkland`: I've seen it, but it's a fair amount of work
[22:50] <kirkland`> cjwatson: okay, thanks, i was just curious
[22:50] <asac> tedg: https://bugzilla.mozilla.org/show_bug.cgi?id=309807#c4
[22:50] <ubotu> Mozilla bug 309807 in Password Manager "Integrate Password Manager with Gnome Keyring Manager" [Enhancement,New]
[22:50] <cjwatson> I've updated the bug
[22:50] <asac> tedg: that makes this solution unfeasible for prime-time (which is most likely the reason why nothing has landed and no review has been requested.
[22:50] <keescook> doko: any thoughts or things I should try?
[22:51] <tedg> asac: Working on proving out some ideas on getting Firefox and the desktop to work together.
[22:51] <asac> tedg: first start working with me ;)
[22:51] <tedg> asac: Yes, that is a problem.  I'll have to see if it is feasible to work around.
[22:52] <tedg> asac: Heh, I didn't mean to work around you.  I just thought this was going to be an easy "drop in and see if it works" type of thing....
[22:52] <asac> tedg: yeah, but it isn't.
[22:52] <asac> firefox 3 and gnome-keyring is only possible in an ugly fashion :)
[22:53] <asac> we thought about a solution for epiphany for that ... but now that they give up on gecko, there is no point to investigate further ;)
[22:53] <tedg> Well, the nice part is that the Webkit integration is already done.  So really they're ahead on it.
[22:53] <doko> keescook: please let me look at it tomorrow, I do have the build at least now
[22:53] <Riddell> tkamppeter: have you looked into backporting the libpaper patch change in ghostscript to 7.10?
[22:54] <asac> tedg: webkit + keyring integration?
[22:54] <asac> ok
[22:54] <calc> doko: ping
[22:54] <calc> doko: i have something for you to look at (small bit of code) to see if i am reading it correctly
[22:55] <keescook> doko: okay, cool -- thanks!
[22:55] <asac> tedg: we will land a gconf integration for proxy stuff in the next days
[22:55] <asac> tedg: i think we cannot do much more for hardy
[22:55] <asac> and for intrepid we can discuss at UDS.
[22:56] <asac> I am open to any new idea ;)
[23:01] <TheMuso> What is the default debconf priority for a dapper install supposed to be? High?
[23:02] <cjwatson> high, yes
[23:03] <TheMuso> cjwatson: Right, I'm trying to reproduce that libssl bug, with no luck so far...
[23:06] <tkamppeter> Riddell, no I did not come to this idea.
[23:12] <Ng> tjaalton: does the led-enabled iwl driver work ok for you?
[23:17] <seb128> Ng: I'm not sure your printer issue is a poppler one
[23:17] <Ng> seb128: oh?
[23:20] <seb128> Ng: pdftops in poppler-utils generates a ps which looks correct
[23:20] <seb128> Ng: using evince to print the ps is correct too but I've some fonts issues apparently
[23:21] <seb128> Ng: I think the way evince works is that it renders the pdf using poppler and then use gtk to print
[23:23] <Ng> seb128: ah, so it could be gtkprint?
[23:23] <seb128> Ng: yes
[23:23] <Ng> hmm
[23:23] <seb128> Ng: well, how do you try printing?
[23:24] <Ng> seb128: the PS files were produced with the Print To File printer in the evince print dialog
[23:24] <seb128> Ng: do printing to a ps and using lp on the ps crashes the printer?
[23:24] <seb128> s/do/does
[23:24] <Ng> seb128: afair feeding the hardy ps on the bugreport to lpr will crash the printer
[23:24] <seb128> Ng: could you try to pdftops the pdf and try to send this ps to the printer?
[23:25] <Ng> seb128: I will wait for a quiet time in the office tomorrow and test
[23:25] <seb128> Ng: ok, thanks
[23:27] <seb128> Ng: might be https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/151145
[23:27] <ubotu> Launchpad bug 151145 in gtk+2.0 "Evince print fails with Postscript driver" [Critical,Incomplete]
[23:31] <Riddell> cjwatson: tranlations on partition types works well