[01:17] <jscinoz> hmm
[01:17] <jscinoz> are there an man-page editors? doing this manually is getting annoying >_<
[01:44] <RAOF> jscinoz: I've used docbook to man in the past, that wasn't too painful.
[01:45] <jscinoz> thanks
[01:46] <jscinoz> ill get it for future use, ended up doing these two manually >_<
[01:47] <jscinoz> hmm
[01:47] <jscinoz> I'm currently packaging for debian with the goal of getting my packages synced back to ubuntu for Intrepid, once my packages are in debian, what needs to be done to have them synced and ready for release with 8.10?
[01:48] <StevenK> jscinoz: Do the packages currently have Ubuntu changes?
[01:48] <jscinoz> nope, this is the first time they've been packaged for a distro
[01:48] <StevenK> jscinoz: Then they will get pulled in automatically when Intrepid opens
[01:49] <jscinoz> ah nice
[04:16] <saivann> Does someone knows what package should provide /etc/libuser.conf ? system-config-samba does not start because that file does not exist, even after installing libuser (bug #214959)
[04:16] <ubotu> Launchpad bug 214959 in system-config-samba "system-config-samba.py fails to start due to missing /etc/libuser.conf after apt-get installation" [Medium,Confirmed] https://launchpad.net/bugs/214959
[04:17] <saivann> Nevermind, this is libuser1 in gutsy, but I don't know why the file is not installed in Hardy
[05:46] <hyperair> does anybody know if bug #185854 will be fixed in ubuntu hardy's release?
[05:46] <ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
[05:47] <hyperair> as of now the sys->admin>network configuration is broken as it misses out "auto <iface>" in /etc/network/interfaces
[05:49] <hyperair> it seems it was declined for hardy by Pedro Villavicencioquite quite some time earlier.
[05:50] <hyperair> before the patch and debdiff were created
[06:10] <dholbach> good morning
[06:29] <hyperair> morning
[06:29] <hyperair> would you happen to know anything about Bug #185854
[06:29] <hyperair> the one where sys/admin/network is broken and "auto <iface>" is always missing from /etc/network/interfaces
[06:30] <dholbach> hyperair: I just asked somebody to take a look at it
[06:32] <hyperair> ah
[06:32] <hyperair> i noticed
[06:32] <hyperair> thanks
[06:48] <pitti> asac: hi (re translations ping)
[06:48] <pitti> Good morning
[07:00] <warp10> Good morning
[07:01] <pitti> hey warp10
[07:02] <warp10> heya pitti
[07:13] <emgent> morning
[07:16] <fabbione> morning guys
[07:27] <pitti> hey fabbione! how are things?
[07:28] <fabbione> pitti: hey dude.. pretty good thanks
[07:29] <fabbione> you?
[07:29] <pitti> fabbione: arrived back home safely, and I'm mostly over the jetlag
[07:29] <fabbione> pitti: from where/to where? :) i have no idea where have you been :)
[07:30] <pitti> fabbione: in Austin, Texas, for https://www.linux-foundation.org/events/collaboration
[07:30] <fabbione> oh yeah you mentioned that sorry
[07:30] <fabbione> i totally forgot
[07:32] <fabbione> pitti: was it good?
[07:33] <pitti> fabbione: yes, indeed it was; we got a lot of things actually done in our workgroup discussions (driver backports)
[07:33] <fabbione> nice
[07:42] <ether_c> er.. so if this isn't the channel for application development ON ubuntu, what is?
[07:45] <RAOF> ether_c: That depends on the application :).
[07:45] <RAOF> ether_c: There's nothing special about developing on Ubuntu, basically.
[07:45] <ether_c> I know.. it's just linux
[07:45] <ether_c> supposedly
[07:45] <ether_c> so I'm trying to learn how to use Xlibs
[07:45] <ether_c> I installed the xorg-dev stuff
[07:46] <ether_c> I included the Xlib.h library
[07:46] <ether_c> my program has basically one line
[07:46] <ether_c> display = XOpenDisplay(0);
[07:46] <ether_c> and I get "undefined reference to XOpenDisplay"
[07:47] <RAOF> ether_c: So, you're probably not linking to libX11.  Also, what part of "not for application development on Ubuntu" is not clear :)
[07:47] <RAOF> ether_c: You probably want #xorg, or at least they'd be able to point you in the right direction.
[07:47] <ether_c> oh, I just read the channel title
[07:48] <ether_c> "Development of Ubuntu (not support, not application development on Ubuntu)"
[07:48] <crevette> ubuntu-devel is related to developement projects around ubuntu (packaging, blueprint,...)
[07:58] <mdke> gdm has gone all big on me. I can't see the box to change my language, it's way off the bottom of the screen
[07:58] <mdke> is there any workaround?
[08:01] <mdke> (bugs 214704)
[08:01] <ubotu> Launchpad bug 214704 in gdm "GDM login screen too wide" [Undecided,Confirmed] https://launchpad.net/bugs/214704
[08:01] <pitti> Riddell, ogra: I just added b43-fwcutter to ubuntu's ship+ship-live; you might consider doing the same?
[08:46] <pitti> Keybuk: there?
[08:47] <pitti> Keybuk: I think http://gitweb.freedesktop.org/?p=hal-info.git;a=blob_plain;hb=HEAD;f=fdi/information/10freedesktop/10-usb-music-players.fdi should work alright, can you please confirm this? the fix looks small and logical
[08:48] <pitti> ^ or anyone else with an USB music player which is currently broken under Hardy
[08:49] <seb128> hey pitti
[08:49] <pitti> bonjour seb128
[08:50] <asac> pitti: we have a suboptimal situation. the first ffox update will introduce string changes ... and mozilla doesn't allow us to ship a glorified nightly of RC1.
[08:50] <pitti> seb128: btw, camera f-spot auto-opening is still broken :/
[08:50] <Hobbsee> asac: ack.
[08:50] <pitti> seb128: as a fallback we could always enalbe it in g-v-m again
[08:50] <asac> Hobbsee: ack what?
[08:50] <asac> :)
[08:50] <seb128> pitti: yeah, that's one of the few desktop bugs milestoned
[08:50] <asac> suboptimal?
[08:50] <Hobbsee> asac: not that kind of ack.
[08:50] <seb128> pitti: did you try to debug it?
[08:50] <pitti> asac: ugh
[08:50] <Hobbsee> asac: ack as in "oh no"
[08:50] <pitti> seb128: no, just noticed it yesterday when downloading my Austin photos
[08:51] <pitti> seb128: btw, does f-spot crash/hang for you as well when you try to close it?
[08:51] <seb128> pitti: yes
[08:51] <asac> pitti: so i ask you .... can we roll a lang update in sync with the first RC ... or can we bury the "translations in global langpacks" idea?
[08:51] <seb128> pitti: bug #199496
[08:51] <ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Confirmed] https://launchpad.net/bugs/199496
[08:51] <pitti> asac: we'll do post-release langpack updates anyway
[08:51] <seb128> pitti: 165 duplicates
[08:52] <pitti> asac: so as long as the only effect is "shows English strings" as opposed to "firefox crashes", that seems like a reasonable approach to me
[08:52] <asac> pitti: yes, this one is difference though. we have two options if we want to guarantee that users end up with a broken UI:
[08:52] <pitti> seb128: wow
[08:52] <pitti> asac: :) (for guaranteeing broken UIs we have a lot more options)
[08:52] <asac> pitti: 1. we make a tight maxVersion in the install.rdf of the language packs
[08:52] <pitti> hey cjwatson
[08:53] <asac> pitti: 2. we make tight dependencies on xulrunner-1.9 and firefox ...
[08:53] <asac> pitti: i guess option 2 is not an option, right?
[08:53] <pitti> asac: erm, dependencies in the langpacks?
[08:53] <pitti> no, that's not an option
[08:53] <pitti> we don't want to force people to install firefox
[08:53] <asac> pitti: option 1 would mean that users might have a non-translated interface until the update arrives
[08:54] <davmor2> quick query I did a fresh install of Ubuntu amd 64bit with disc date 20080411 there is no tracker/deskbar and when I plug a device in mp3 player/camera there is no app autostart is this deliberate or a bug?
[08:54] <asac> pitti: hmm ... we could use conflicts instead of depends ;)
[08:54] <pitti> asac: if we coordinate the update properly, that shouldn't hurt too much IMHO
[08:54] <asac> pitti: ok.
[08:54] <asac> pitti: then lets go for it and hide ;)
[08:54] <carlos> pitti, asac: I guess you already saw latest language pack with firefox translations included
[08:55] <pitti> carlos: I did (since it broke langpack-o-matic :) ); for now I just ignore them, until we have a script which processes them properly
[08:55] <carlos> pitti: did it?
[08:55] <carlos> pitti: I thought your scripts take care of the new content
[08:55] <pitti> carlos: nonstandard layout (which is goood, btw, to tell them apart properly)
[08:55] <asac> pitti: ill give you that script later today.
[08:56] <asac> as discussed ... installed on rookery
[08:56] <carlos> I see, ok
[09:08] <sabdfl> did we have a wiki issue over the weekend? is it addressed?
[09:09] <Hobbsee> i think it was more than a weekend, from memory?
[09:16] <davmor2> anyone quick query I did a fresh install of Ubuntu amd 64bit with disc date 20080411 there is no tracker/deskbar and when I plug a device in mp3 player/camera there is no app autostart is this deliberate or a bug?
[09:18] <YokoZar> sabdfl: Yeah the issue was almost a week ago I think
[09:25] <cjwatson> pitti: morning
[09:28] <pitti> sabdfl: I filed an RT a few hours ago
[09:29] <pitti> sabdfl: #30451 FYI
[09:53] <\sh> guys, I don't know if it's only me, but did somebody tried to add a new user via system->administration->users and groups ? the user will be created, but actually is not able to login into a new gnome session....
[09:54] <\sh> (hardy that is). I wonder if it's a flaw on my desktop or if it's repeatable
[09:54] <emgent> uhm
[09:54]  * emgent testing
[09:55] <Fujitsu> \sh: I used that to add a user for the first time, 4 days ago. Worked fine.
[09:55] <\sh> Fujitsu, hmm...
[09:56] <emgent> yes
[09:56] <emgent> work fine
[09:56] <\sh> Fujitsu, well, the creation worked without problems....I wonder what is happening, that gdm tells me, that the user is not able to login via gdm...
[09:57] <\sh> login in via ssh works, fine, too....just gdm failes
[09:57] <emgent> work in gdm too in my hardy box
[09:58] <Fujitsu> \sh: You must have restricted it in gdmsetup.
[09:59] <\sh> Fujitsu, how can this happen...strange...
[10:01]  * \sh has to recheck it this evening when he's back at home
[10:12] <sabdfl> thanks pitti
[10:18] <davmor2> mvo: ping
[10:18] <mvo> davmor2: pong
[10:19] <davmor2> mvo: dapper -> hardy died a death about 2/3's of the way through
[10:19] <davmor2> just tracking down the bug report I did for it
[10:19] <emgent> \sh: saw Bug #211350 and Bug #216813 ?
[10:19] <ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
[10:19] <ubotu> Launchpad bug 216813 in lighttpd "Lighttpd enables a login shell for user www-data" [Undecided,New] https://launchpad.net/bugs/216813
[10:22] <davmor2> mvo: bug 216326 I uploaded the relevant logs for you
[10:22] <ubotu> Launchpad bug 216326 in ubuntu "Dapper -> Hardy upgrade = Fail" [Undecided,New] https://launchpad.net/bugs/216326
[10:24] <emgent> www-data:x:33:33:www-data:/var/www:/bin/sh
[10:24] <emgent> uhm..
[10:25] <mvo> davmor2: thanks, that log looks good. could you also please attach /var/log/dist-upgrade/apt-term.log ?
[10:27] <cjwatson> mvo: I don't understand that log. It seems to be a file overwrite in xkeyboard-config/xkb-data, but xkb-data seems to have the proper Replaces
[10:30] <mvo> cjwatson: yeha, I need to see the terminal log to get a better idea about it
[10:33] <\sh> ember, yay...+1 for adduser ,->
[10:34] <\sh> grmpf
[10:35] <\sh> emgent, bug #211350 is a won't fix, because standard user/group for webserver  is www-data:www-data...self changed defaults can't be our problem...or actually we find a small fix which determines the used user/group and forget about chowning those files
[10:35] <ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
[10:41] <\sh> emgent, regarding the /bin/sh to www-data ...
[10:42] <\sh> emgent, I wonder if this is actually a lighty error, or a general bug somewhere
[10:42] <\sh> emgent, cause I have the same with apache somehow
[10:43] <\sh> emgent, at least all system accounts have /bin/sh :(
[10:43] <emgent> yes i saw now
[10:43] <emgent> :|
[10:44] <\sh> guys, what triggers the creation of new users (e.g. www-data/proxy/uucp etc.) and sets by default a /bin/sh shell for non-human-accounts?
[10:46] <Fujitsu> \sh: Wouldn't that be adduser being called in the postinst?
[10:46] <Fujitsu> I thought it should default to /bin/false...
[10:46] <\sh> Fujitsu, If I would find adduser,useradd somewhere in apache2-*/debian/ or whatever
[10:46] <Fujitsu> At least --system is meant to.
[10:47] <Fujitsu> Ah.
[10:47] <\sh> Fujitsu, yes...but proxy/uucp/list/news/irc/gnats/fetchmail all those accounts have /bin/sh
[10:47] <\sh> even lp
[10:47] <\sh> mail
[10:47] <emgent> ok people, i go away. see you later quickly.
[10:47] <\sh> etc.
[10:47] <Amaranth> that seems broken
[10:47] <\sh> bin and sys too :)
[10:47] <Fujitsu> They're created initially... not by the packages.
[10:48] <\sh> grmpf
[10:48] <Fujitsu> Everything created by postinsts is correctly /bin/false.
[10:48] <\sh> from shadow package or passwd?
[10:48] <Fujitsu> But those must be in a template somewhere.
[10:48] <Fujitsu> One of them.
[10:49] <Fujitsu> base-passwd seems to be i.
[10:49] <Fujitsu> *it
[10:50] <\sh> uh yeah
[10:50] <Fujitsu> william@irranat:~/MOTUing/base-passwd-3.5.16$ grep www-data passwd.master
[10:50] <Fujitsu> www-data:*:33:33:www-data:/var/www:/bin/sh
[10:50] <\sh> passwd.master in base-passwd is /bin/sh default
[10:51] <\sh> cjwatson, any reason for /bin/sh instead of /bin/false or something else in passwd.master? :)
[10:53] <laga> yay. suspend to ram works in hardy, suspend to disk works in hardy, it doesn't crash anymore when i close the lid.. now i like my hp 6510b even better. thanks :)
[10:56] <\sh> Fujitsu, anyways...I'm closing bug #216813 and reopen one for base-passwd
[10:56] <ubotu> Launchpad bug 216813 in lighttpd "Lighttpd enables a login shell for user www-data" [Undecided,New] https://launchpad.net/bugs/216813
[10:58] <emgent> back
[11:00] <cjwatson> \sh: there are a couple of Debian bugs about it; it does need to be changed to /bin/false eventually, but I want to be extremely careful not to break anything and I need to debconfise base-passwd first otherwise it'll cause terminal prompts. Please don't change it in Ubuntu.
[11:01] <\sh> cjwatson, na...I don't want to change anything until a reliable solution is in place :) bug #216813 is for the reminder :)
[11:01] <ubotu> Launchpad bug 216813 in base-passwd "Lighttpd enables a login shell for user www-data" [Medium,Confirmed] https://launchpad.net/bugs/216813
[11:01] <cjwatson> I want to make sure that somebody doesn't do a trigger-happy upload and break the world
[11:02] <\sh> cjwatson, /me <- no main rights...and I don't change those stuff after hard freeze :)
[11:03] <cjwatson> \sh: maintainer scripts at least used to use su to execute stuff as other users in various places; changing the shell to false will break anything that does that
[11:05] <\sh> cjwatson, well, regarding www-data e.g. this is an account which is set as chown parameter but I don't know any app which runs or execute scripts as www-data...I think we need to verify those settings and changing them when there is no need for /bin/sh by default
[11:05] <\sh> cyrus user is e.g. a different issue...
[11:05] <\sh> but this user is set when installing the package actually
[11:06] <\sh> (scripts == maintainer scripts ;))
[11:06] <cjwatson> there certainly used to be maintainer scripts that dropped to some of the other users in passwd.master that ought to be /bin/false
[11:06] <cjwatson> whether www-data specifically is one such user is not my immediate concern
[11:08] <MacSlow> I keep getting "svn: error while loading shared libraries: /usr/lib/libsvn_wc-1.so.1: unsupported version 0 of Verneed record" for some days now... I've no clue what's causing this or what a "verneed record" is. Anybody with some ideas?
[11:08] <\sh> cjwatson, something for the next release :)
[11:09] <emgent> :)
[11:09] <pitti> cjwatson: do you have an opinion about bug 211357? should we have IPv6 addresses by default in /etc/hosts?
[11:09] <ubotu> Launchpad bug 211357 in netbase "No IPv6 addresses in default /etc/hosts" [Medium,In progress] https://launchpad.net/bugs/211357
[11:10] <creAtion> MacSlow: How is the facebrowser going?
[11:11] <MacSlow> very slow as I'm mostly battleing with my nvidia-card, the driver, svn (see above) and compiz
[11:12] <Amaranth> aww, don't fight compiz
[11:12] <Amaranth> you have no chance of winning :P
[11:12] <creAtion> MacSlow: I remember seeing a video or screens about it a while ago and it looked pretty cool
[11:12] <MacSlow> Amaranth, it's more the nvidia-driver than compiz I think... it's working on intel :)
[11:12] <creAtion> MacSlow: is it something that might be in Ibiz?
[11:12] <MacSlow> creAtion, mockups of what I attempt to achive
[11:13] <Amaranth> intrepid, you mean?
[11:13] <creAtion> yeah :P
[11:13] <MacSlow> Amaranth, right now on nvidia I cannot start compiz via normal UI-tools
[11:14] <MacSlow> (read: avoiding the command-line)
[11:14] <creAtion> MacSlow: what ever happened to the object groupings thing you were working on e.g. moving photos around in groups etc
[11:14] <\sh> emgent, regarding bug #211350 if there is a simple solution to determine the user:group of the directories which the user changed, we can use it in postinst and change it to his/her user/group..but if it's not (easily) possible, -> won't fix, cause www-data:www-data is distri default
[11:14] <ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
[11:14] <Amaranth> MacSlow: I blame your code and/or the nvidia driver :)
[11:14]  * Amaranth runs
[11:14] <MacSlow> creAtion, lowfat... collecting dust as I don't find time to continue working on it :/
[11:15] <MacSlow> Amaranth, no... I'm not talking about any of my code.
[11:15] <MacSlow> just normal operation
[11:15] <ogra> pitti, ogra@osiris:~$ apt-cache rdepends ubuntu-desktop|grep edu
[11:15] <ogra>   edubuntu-desktop
[11:16] <ogra> pitti, no more sh and ship-live for me, only addon :)
[11:16] <creAtion> MacSlow: lowfat that's right ... interesting concept
[11:16] <ogra> s/sh/ship/
[11:16] <pitti> ogra: ah, I keep forgetting
[11:16] <MacSlow> creAtion, thanks
[11:16] <ogra> pitti, thanks for the ping though :)
[11:17] <tseliot> MacSlow: what's the model of your graphic card?
[11:18] <cjwatson> pitti: that's odd, it's supposed to be there
[11:18] <emgent> \sh: I suspected it :)
[11:18] <cjwatson> pitti: how was the install in question done?
[11:18] <pitti> cjwatson: ok; if it's supposed to be there, I'll look at it
[11:18] <pitti> cjwatson: it's from mvo's upgrade tester
[11:18] <cjwatson> pitti: I know, but what underlying installer does it use?
[11:18] <MacSlow> tseliot, tried GeForce 7900GT and 8800GTS... same issues
[11:18] <pitti> mvo: ^ see cjwatson's question?
[11:19] <mvo> cjwatson: the uprade tester uses the jeos-builder
[11:19] <cjwatson> both netcfg and ubiquity add those IPv6 entries automatically
[11:19] <cjwatson> then I claim a
[11:19] <cjwatson> jeos-builder bug
[11:19] <tseliot> MacSlow: what's the output of compiz?
[11:19] <cjwatson> s/automatically/unconditionally/
[11:19] <pitti> hm, my box is a reasonably fresh install
[11:19] <mvo> I can check it out later
[11:19] <pitti> and I have the entries, too
[11:20] <pitti> mvo: so it might be an artifact from the upgrade tester itself?
[11:20] <cjwatson> it is
[11:21] <cjwatson> like I say, jeos-builder bug
[11:21] <pitti> cjwatson: ok, thank you
[11:22] <\sh> emgent, I trust you, set the bug to whatever you think is ok :)
[11:26] <MacSlow> tseliot, "Error: Could not acquire compositing manager selection on screen 0 display :0.0", which is odd because it used to work and there's hardly any change I did to my system... it cretainly worked with compiz 0.7.x
[11:26] <emgent> \sh: hehehe :)
[11:29] <YokoZar> pitti: Could you upload a new version of ia32-libs for me that adds libasound2-plugins (bug #182731) ?
[11:29] <YokoZar> pitti: going through the debdiff/freeze exception process at this point would be difficult for ia32-libs :(
[11:30] <\sh> YokoZar, I think a spoken "yes, please do" from motu-release is enough ... motu-release can add the acks afterwards to the papers
[11:30] <pitti> YokoZar: please get approval from motu-release for that, though
[11:30] <pitti> YokoZar: right, debdiff is pretty pointless for ia32-libs
[11:31] <tseliot> MacSlow: can you try the solution suggested here? http://ubuntuforums.org/showthread.php?p=4691222
[11:42] <seb128> mr_pouit: bug-buddy displays wrong libexec paths, just for information
[11:43] <mr_pouit> seb128: ah, ok, thanks.
[11:48] <tseliot> MacSlow: did you get my last message before you disconnected?
[11:48] <MacSlow> tseliot, that hint was helpful... odd that the metacity-compositor was enabled here
[11:49] <tseliot> MacSlow: at least it's not a bug in Compiz ;)
[12:25] <munckfish> cjwatson: got a mo?
[12:25] <cjwatson> munckfish: yep
[12:26] <munckfish> cjwatson: sorry, I'm at work at the mo, I can look at kboot at lunch
[12:26] <munckfish> did you guys get any further idea what was going wrong?
[12:26] <cjwatson> my mails have the most recent information I have
[12:26] <cjwatson> Adam's in .au so probably hasn't seen them yet
[12:26] <cjwatson> err, no he's not, he's in .ca, sorry
[12:26] <cjwatson> but still
[12:27] <Keybuk> mvo: so, err, how did we manage to get two files owning the same conffile?
[12:27] <Keybuk> two packages, I should say
[12:28] <munckfish> cjwatson: ok understood
[12:28] <munckfish> cjwatson: I think we need to agree some sort of goal for this first Hardy release
[12:28] <munckfish> at the moment I'm guessing it would be get X working
[12:28] <munckfish> and no more
[12:29] <munckfish> I looked at the PS3 specific stuff in the repo
[12:29] <munckfish> I think most of it could be done with back ports
[12:29] <munckfish> what do you think?
[12:29] <munckfish> If we can't get X fixed, or if we discover some other complete show stopper
[12:29] <munckfish> would should we do then?
[12:30] <munckfish> delay PS3 on Hardy?
[12:30] <munckfish> or just not release it at all?
[12:30] <cjwatson> munckfish: not release it, and defer to 8.04.1
[12:30] <cjwatson> munckfish: this is a *nuclear option* and a bad idea
[12:31] <munckfish> cjwatson: I don't understand that sorry
[12:31] <munckfish> nuclear option?
[12:31] <cjwatson> last resort
[12:31] <munckfish> yes it would be a big shame
[12:31] <cjwatson> I agree that the best plan is to concentrate on what is absolutely required; don't worry about fripperies
[12:32] <munckfish> what about the back ports situ though?
[12:32] <cjwatson> forget about it for now
[12:32] <munckfish> right fare enough
[12:32] <munckfish> *fair
[12:32] <cjwatson> later, maybe, but it's not worth the distraction of considering it
[12:32] <munckfish> hmmm spelling
[12:32] <munckfish> yep
[12:32] <munckfish> ok
[12:32] <munckfish> well the X null pointer I have
[12:32] <munckfish> didn't get time to grab the trace
[12:33] <munckfish> but from what I remember
[12:33] <munckfish> it was in the some function called
[12:33] <munckfish> selectDriver or chooseDriver or similar
[12:33] <munckfish> I have the X log
[12:33] <munckfish> I'll open a LP report at lunchtime
[12:33] <munckfish> ps3fb did seem to be loaded in the kernel ok as far as I could see
[12:34] <\sh> you are talking about PS3 as in "sony" ? :)
[12:36] <munckfish> \sh: yes
[12:36] <\sh> munckfish, sounds like I need to convince my future wife to buy such a gadget then ;)
[12:37] <munckfish> \sh: it's a very very cool device
[12:37] <munckfish> I have a supercomputer in my lounge!
[12:37] <\sh> :))
[12:38] <munckfish> Our port project needs some care and attention though
[12:39] <munckfish> \sh: if you get one jump on<EMAIL_ADDRESS>to follow progress
[12:40] <\sh> munckfish, hmm...but still usable as "playstation"? or is it then my next generation build server/webserver? :)
[12:41] <munckfish> no still usable for games
[12:41] <munckfish> the only compromise is
[12:41] <munckfish> you can ever have 10GB for linux and the rest for sony
[12:41] <munckfish> or vice versa
[12:41] <munckfish> s/ever/only/
[12:43] <munckfish> and with only 256MB of RAM, I guess we could do some optimisation at some point along the way
[12:49] <munckfish> but the cell chip is cool, I can't wait to start exploring it's potential. Which is something I think the guys on #ps3dev are already quite far ahead on
[12:49] <munckfish> some of those guys are working on some interesting projects
[12:53] <mvo> Keybuk: I have no idea, I was wondering that too
[12:54] <ogra> hmm, do we have any xubuntu devs here apart from cody-sommerville ?
[12:55]  * ogra just discovered they might need some extra preseeding for ltsp on the cd to make it use universe packages ...
[12:56] <Keybuk> mvo: we just need to find another impossible thing, then we can dine at Millways
[12:57] <Keybuk> Q for the channel; does anyone running hardy *not* have two answers for: grep rcS-sulogin /var/lib/dpkg/info/*.conffiles ?
[12:58] <Ng> I see one
[12:58] <laga> Keybuk: one answer
[12:58] <seb128> Keybuk:
[12:58] <seb128> $ grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
[12:58] <seb128> /var/lib/dpkg/info/upstart-compat-sysv.conffiles:/etc/event.d/rcS-sulogin
[12:58] <seb128> $
[12:58] <Ng> upstart-compat-sysv
[12:58] <ion_> Ditto
[12:58] <Keybuk> Ng, seb128, laga, ion_: do you have friendly-recovery installed?
[12:58] <Ng> yes
[12:58] <seb128> yes
[12:59] <\sh> yes
[12:59] <Keybuk> Ng, seb128, laga, ion_: can you nopaste grep -e friendly-recovery -e upstart-compat-sysv /var/log/dpkg.log
[12:59] <laga> Keybuk: yes.
[12:59] <ion_> Huh, i don't have it installed, even though ubuntu-standard recommends it.
[12:59] <laga> http://www.pastebin.ca/984563
[12:59] <\sh> Keybuk, http://paste.ubuntu.com/6985/
[13:00] <Keybuk> \sh: one answer or two?
[13:00]  * Fujitsu has just one too.
[13:00] <\sh> Keybuk, one...
[13:00] <Ng> Keybuk: http://pastebin.com/f7f06fbe5
[13:02] <Keybuk> laga: ok, you have f-r bzr installed, you upgrade to compat-sysv 0.3.9-2, then friendly-recovery 0.1, then compat-sysv 0.3.9-2
[13:02] <Keybuk> \sh: you have the same
[13:02] <Keybuk> Ng: likewise
[13:03] <Keybuk> elmo: don't suppose you can run the same grep?
[13:03] <Keybuk> mvo: do you see one or two results on your machine?
[13:03] <cjwatson> Keybuk: one answer here, http://paste.ubuntu.com/6987/
[13:03] <ion_> keybuk: http://pastebin.com/f4aaf2546 Just installed friendly-recovery, the grep for rcS-sulogin still prints one entry.
[13:04] <Keybuk> just to prove I'm not going nuts:
[13:04] <mvo> Keybuk: just one
[13:04] <Keybuk> quest scott% grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
[13:04] <Keybuk> /var/lib/dpkg/info/friendly-recovery.conffiles:/etc/event.d/rcS-sulogin
[13:04] <Keybuk> /var/lib/dpkg/info/upstart-compat-sysv.conffiles:/etc/event.d/rcS-sulogin
[13:04] <Chipzz> Keybuk: just read your post on upstart couple of days ago... was wondering (but maybe this will be covered in a next post) if upstart also supports actions like 'reload'?
[13:04] <Keybuk> Chipzz: not yet
[13:04] <Chipzz> Keybuk: planned?
[13:04] <Keybuk> Chipzz: considered
[13:05] <Chipzz> Keybuk: would be *really* needed for apache I think
[13:05] <Chipzz> s/I think/imho/
[13:05] <Keybuk> cjwatson: you have the same sequence again
[13:05] <Keybuk> ftr, I see f-r bzr installed, then compat-sysv 0.3.9-**1**, then f-r upgraded to bzr
[13:06] <Keybuk> if I upgrade compat-sysv now, I get a conffile prompt
[13:06] <Keybuk> as did elmo
[13:06] <Chipzz> not having reload for apache would mean significantly longer delays + downtime when adding a site in apache
[13:06] <Chipzz> well, you can use apache2-ctrl, but...
[13:07] <Chipzz> that's ugly imho
[13:07] <ogra> cody-somerville, hey
[13:08] <cody-somerville> Hey ogasawara__
[13:08] <cody-somerville> erm
[13:08] <cody-somerville> Hey ogra
[13:08] <ogra> cody-somerville, coud you take a look at the last three comments on bug 214481 ?
[13:08] <ubotu> Launchpad bug 214481 in ltsp "[hardy] ltsp-build-client builds incomplete filesystem" [Undecided,Fix released] https://launchpad.net/bugs/214481
[13:08] <ogra> (not sure you still build ltsp on the alternate iso)
[13:08] <cody-somerville> ogra, certainly
[13:09] <Keybuk> ok, so channel-wide question -- does anyone else have *two* answers for grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
[13:09] <ogra> Keybuk, nope, but i'm only up to date with yesterday (no upgrades today yet)
[13:10] <Keybuk> ogra: I'm briefly theorising that it may be people who did a gutsy->hardy upgrade who have two
[13:10] <Keybuk> and people who followed who only have one
[13:10] <Keybuk> or it could simply be that people who have upstart 0.3.9-2 only have one
[13:10] <ogra> well, that laptop was installed last thursday
[13:10] <\sh> Keybuk, my amd64 is a gutsy -> hardy install .... but from early stages...
[13:10] <ogra> indeed with hardy directly
[13:10] <Ng> Keybuk: I have a PC at home which did gutsy->hardy and I haven't updated it for weeks, it has two matches for the grep
[13:10] <\sh> Keybuk, and the machine has only one answer to your grep
[13:11] <Keybuk> Ng: it has friendly-recovery bzr and upstart 0.3.9-1 installed?
[13:11] <Ng> Keybuk: yes
[13:11] <Keybuk> Ng: at least that's consistent then
[13:11] <\sh> Keybuk, so something went wrong between december and now ,-) (in december I upgraded to hardy)
[13:12] <Ng> I've not updated that machine since the end of february though
[13:12] <Keybuk> Ng: updating in the last few days seems to "resolve" the problem
[13:12] <Fujitsu> I reinstalled with Hardy beta, and have but one match.
[13:12] <Keybuk> but may give you a conffile prompt in the process
[13:12] <Fujitsu> I last upgraded last night.
[13:12] <Ng> Keybuk: I'm entirely happy to try that if you want?
[13:13] <Keybuk> Ng: not just yet, I'd like to capture lots of dpkg debug output in the process
[13:13] <\sh> Keybuk, but no f-r installed that is
[13:13] <Keybuk> so let me simulate in vmware first
[13:13] <Ng> Keybuk: sure
[13:15] <Mirv> mvo: could you perhaps put the fix for bug 216211 in, since the upstream translation was again broken when 0.7.4 was made?
[13:15] <ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
[13:15] <lamont> Keybuk: gutsy upgraded machine, 0.3.9-2, one copy. OTOH, still no ck-session-daemon
[13:15] <Mirv> there's a debdiff and .dsc (at PPA)
[13:16] <mvo> Mirv: thanks, does it have approval of the universe release team yet? IIRC its required to get a exception at this stage
[13:17] <Keybuk> mvo: oh, and I'm still getting that compiz-crashes-and-randomly-rearranges-workspaces bug ;-)
[13:17] <Keybuk> this time on nvidia
[13:18] <mvo> Keybuk: meh :/ what does the crashfile for this one look like?
[13:18] <Mirv> mvo: oh, good question. I tried to ask at #ubuntu-motu yesterday but I haven't gotten a reply. any other place/way to ask? of course, there was an exception for the compiz 0.7.4 in general.
[13:18] <Keybuk> mvo: no crash detected
[13:18] <Keybuk> screen freezes for a second, and then when it comes back, it's all rearranged
[13:18] <Keybuk> apport stays silent on the matter
[13:19] <Mirv> pitti: there would be the bug 204155 which was the other i18n bug you asked me to assign you to (but I couldn't). I doubt asac has time for that.
[13:19] <ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
[13:19] <mvo> Keybuk: does that mean that compiz keeps on running after the freeze?
[13:21] <tjaalton> Keybuk: http://bugs.opencompositing.org/show_bug.cgi?id=876 ?
[13:21] <ubotu> bugs.opencompositing.org bug 876 in -Unknown "windows change the workspace" [Normal,Unconfirmed]
[13:22] <Keybuk> mvo: I'm not sure, let me find out next time it happens
[13:22] <Keybuk> just tried to run compiz under gdb
[13:22] <Keybuk> that doesn't work so well
[13:22] <Keybuk> ;-)
[13:22] <Keybuk> tjaalton: no, not that
[13:22] <Keybuk> all of my windows move
[13:22] <Keybuk> all to different workspaces
[13:23]  * ogra pokes vbox ... damned thing, stop messing with my brightness settings ... grr
[13:24] <tjaalton> Keybuk: ok, I think they are related though.. the freeze and all
[13:24] <mvo> Keybuk: no :) only via ssh from a different machine
[13:26] <Mirv> (ok, now subscribe motu-release to the ccsm bug, too)
[13:38] <asac> Mirv: please commit to bzr branch in case you update nm-XXX
[13:38] <asac> :)
[13:38] <Mirv> asac: ok, I can do that.
[13:40] <ogra> asac, bug 185854, wasnt NM supposed to take over the bring up/tear down part for all interfaces now ?
[13:40] <ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
[13:43] <davmor2_away> ogra: whose the best person to speak to about LTSP?
[13:44] <ogra> davmor2_away, me
[13:44] <cody-somerville> davmor2_away, ogra was the one that asked me :P
[13:44] <ogra> heh
[13:44] <davmor2> oh
[13:45] <ogra> davmor2, you need to adjust the preseed value for ltsp-client-builder/build-client-opts
[13:45] <ogra> currently thats set to "--mirror file:///cdrom --security-mirror none --skipimage"
[13:45] <ogra> you need "--mirror file:///cdrom --security-mirror none --skipimage --components main,universe"
[13:46] <davmor2> ogra: I'll hand it over to stgraber he know more about it than me.
[13:46] <ogra> i'm just checking if i can apply a more general solution
[13:46] <asac> ogra: no
[13:46] <ogra> (inside ltsp ... so that preseed change wouldnt be required)
[13:46] <asac> ogra: same constrains as in gutsy
[13:47] <ogra> asac, ah, k then i misunderstood ...
[13:47] <asac> ogra: 0.7 was supposed to be the answer :)
[13:47] <ogra> was probably 0.7 we talked about :)
[13:47] <asac> but that doesn't exist ;)
[13:47] <ogra> snap
[13:47] <asac> right!
[14:01] <munckfish> cjwatson: I have a little time now, can we chat again about the kboot build fail
[14:01] <cjwatson> munckfish: sure
[14:01] <munckfish> ok
[14:01] <munckfish> So
[14:01] <munckfish> q1: uclibc
[14:02] <munckfish> do you still want to use glibc?
[14:02] <cjwatson> like I say, disregard the comment in my first mail. Whatever can be made to work in time.
[14:02] <munckfish> Ok, this is what I was wondering
[14:03] <munckfish> what of your first email should
[14:03] <munckfish> be disregarded
[14:03] <munckfish> I guess the answer is all of it then?
[14:03] <cjwatson> everything :-) I was under the wrong impression about where things were failing
[14:03] <munckfish> ok fine fine
[14:03] <cjwatson> the fact that it builds successfully on davis indicates that the source package isn't completely screwed
[14:04] <munckfish> ok so all we can do is wait for adam c
[14:04] <cjwatson> or employ more guesswork :-)
[14:05] <munckfish> ok I'll scan the build log while I'm eating anyway
[14:06] <cjwatson> seems to be something building either a 32-bit or a 64-bit object when it should be building the other
[14:07] <munckfish> right
[14:07] <cjwatson> which suggests maybe something in the kernel build looking at the current machine type, that isn't being overridden properly?
[14:07] <munckfish> I'm afraid I didn't look too deeply into the cross compilation stuff, cause after I removed the referecnes to the redhat cross compiler it built ok and run ok
[14:08] <cjwatson> yeah, I'd missed that patch when I sent my first mail
[14:08] <munckfish> I'll double check the way the kboot Makefile handles cross comp
[14:08] <munckfish> I think the way I did it was probably cheating anyway
[14:08] <munckfish> cause there was some logic in there
[14:08] <munckfish> to decide based on the host system architecture
[14:09] <munckfish> I just set CROSS_* variables to ""
[14:10] <Mirv> asac: ok, added a bazaar branch in the bug 204155 for the fix
[14:10] <ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
[14:11] <asac> Mirv: did you verify that its fixed?
[14:12] <asac> Mirv: ok now i see. why was it filed against applet?
[14:12] <Mirv> asac: yep, compiled with the modified debian directory with dpkg-buildpackage, and the translations were there
[14:12] <asac> oh ;)
[14:12] <asac> sorry ... ETOOMUCHTODO
[14:12] <asac> :)
[14:13] <asac> Mirv: will do a break and then do this merge stuff
[14:14] <asac> Mirv: i have a tarball with finishe translation for xulrunner and firefox
[14:14] <Mirv> asac: :) thanks, and hopefuly you will get some rest in.. less than two weeks
[14:14] <asac> Mirv: can you please install those and go through the broken accesskeys and fix those in launchpad?
[14:14] <asac> Mirv: i would love to to whitelist finish translation for launchpad export
[14:15] <Mirv> asac: ok, I can install those. I was wondering about the access keys translations.
[14:15] <asac> Mirv: yeah you will see :)
[14:15] <asac> Mirv: http://people.ubuntu.com/~asac/translations.tar.gz
[14:15] <asac> there should be a fi.tar.gz in
[14:15] <asac> its a complete file system so you need to extract it in /
[14:15] <asac> and then restart firefox
[14:15] <asac> it should be translated
[14:17] <Mirv> asac: whee, it works. and aaagh, I'll start fixing the access keys now :)
[14:18] <asac> Mirv: you understand how that goes?
[14:18] <asac> Mirv: if you want to do that accurately you can install the upstream .xpi and see how they are mapped
[14:18] <asac> Mirv: anyway. as long as all accesskeys have a matching letter in the word it hsould be fine (of course ther emight be clashes with other accesskeys in the same context/menu)
[14:19] <Mirv> asac: yes, in general, and I think I can manage it with these. I can give you a note when Finnish (fi) is fixed in Rosetta (both firefox and xulrunner)
[14:19] <asac> Mirv: if you know other translation folks that would like to be whitelisted for hardy, maybe point them tot the translation thing
[14:19] <Mirv> asac: ok, I'll note on #ubuntu-translators
[14:20] <asac> Mirv: yes, when i have a free minute ill blog how you can produce your own langpacks ... so translators can test
[14:20] <asac> Mirv: for now give me the updated .po file for xulrunner and firefox and i will recreate the tarball for you
[14:20] <Mirv> asac: ok.
[14:20] <asac> Mirv: but at best go through all accesskeys and check if they have a matchin letter
[14:21] <Mirv> asac: yes
[14:23] <asac> Mirv: rock
[14:23]  * cjwatson eyes the mailing list spam filter, having hit 'd' 185 times on the ubuntu-devel-announce moderation queue
[14:36] <munckfish> cjwatson: I'm trying to compare the architecture details of these systems we're compiling on
[14:36] <munckfish> cjwatson: do you think you could run this (http://paste.ubuntu-nl.org/63178/) on
[14:36] <munckfish> davis?
[14:37] <munckfish> the buildd (adare)?
[14:37] <ogra> infinity, ping ?
[14:37] <munckfish> cjwatson: is your PS3 handy? Could you run it on that too? If not I'll get the details on mine tonight
[14:40] <cjwatson> munckfish: I don't have shell access to the buildds
[14:41] <munckfish> cjwatson: I thought as much
[14:41] <munckfish> how can we most easily get this info do you think?
[14:41] <cjwatson> munckfish: needs Adam, like I said
[14:41] <munckfish> Ok I see
[14:41] <cjwatson> munckfish: http://paste.ubuntu.com/6991/
[14:41] <munckfish> he's the buildd admin is he?
[14:41] <cjwatson> yes
[14:42] <munckfish> cjwatson: thx for davis info
[14:58] <Mirv> mvo: ok the bug 216211 now has ack in the bug report from motu release
[14:58] <ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
[15:00] <jdong> mvo: btw, too late for Hardy, but what do you think about dist-upgrader being more aggressive about non-Ubuntu packages for next release cycle?
[15:01] <jdong> mvo: when I upgraded over the weekend some stale non-ABI compatible self-made lib packages from Gutsy caused everything GTK to segfault...
[15:01] <jdong> and pinning hardy to 9999 and removing all local/obsoletes fixed it
[15:01] <jdong> that might not be a terrible idea to suggest to the user in an upgrade, or offer as a safety mechanism users can choose later on (i.e. "remove all non-Ubuntu packages")
[15:04] <Mirv> asac: ok, firefox + xulrunner / Finnish should be fixed now in Rosetta. I downloaded the PO files from Rosetta and now that I received them, uploaded them at http://users.tkk.fi/~tajyrink/firefox_xulrunner_fi/
[15:05] <asac> Mirv: ok thanks
[15:05] <asac> let me check
[15:06] <Hobbsee> jdong: mutter, mutter, prevu and crack?
[15:06] <jdong> Hobbsee: yeah some of it is just aggressive personal backporting but it's not out of the question for the "average user" to have some non-Ubuntu-origin installed packages.
[15:07] <Hobbsee> and to use trevhino...
[15:07] <jdong> Hobbsee: and we already disable 3rd party sources, it's not much of a stretch to force "downgrade" to hardy and remove local/obsolete packages afterwards
[15:07] <jdong> for that matter, /usr/local/lib could be evil too
[15:08] <Hobbsee> jdong: that's what i was actually going to look at, somewhere along the line.  it seems i got sidetracked for hardy.
[15:09] <asac> Mirv: http://people.ubuntu.com/~asac/fi.tar.gz
[15:09] <jdong> Hobbsee: in the meantime, how about we set up a wiki page describing a procedure to force this downgrade manually before starting the upgrader?
[15:10] <Hobbsee> jdong: i don't intend to get stuck supporting user-made crack, sorry :)
[15:10]  * Hobbsee has enough to deal with, with work and freenode mess as it is.
[15:11] <jdong> Hobbsee: would you yell at me if I wrote such a wiki page? :)
[15:11] <Hobbsee> no
[15:11]  * jdong puts an item on his TODO list
[15:12] <Hobbsee> pitti: looks like you may want to read the riot act (kde-guidance)
[15:12] <Mirv> asac: works great! all the menus etc. I can see are now as it should be for fi. it's great to see Firefox properly localized!
[15:13] <Riddell> Hobbsee: hmm?
[15:14] <Hobbsee> Riddell: kde-guidance changelog
[15:14] <asac> Mirv: cool
[15:14] <asac> thanks
[15:15] <asac> will whitelist fi then :)
[15:15] <Mirv> asac: thanks a lot!
[15:17] <Hobbsee> Riddell: oh, so the patch is actually different now, and doesn't come from andreas, but actually comes from ScottK instead?
[15:17] <JohnPhys> Are there plans to include the fix to bug #195052 in hardy, even though hardy is now in final freeze?
[15:17] <ubotu> Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Undecided,Fix released] https://launchpad.net/bugs/195052
[15:17] <Riddell> Hobbsee: it's different yes
[15:18] <Hobbsee> Riddell: various of us must have misread the changelog (0ubuntu15) that said the patch had been changed, not just readded.
[15:19] <Keybuk> cjwatson: got a moment?
[15:21] <cjwatson> Keybuk: yep
[15:21] <Keybuk> so, dpkg
[15:22] <Keybuk> is package A contains a file, and package B contains a file
[15:22] <Keybuk> if you try and install package B, that should fail due to a conflict
[15:22] <Keybuk> right?
[15:22] <Keybuk> (file with same name)
[15:24] <munckfish> cjwatson: I have to get back to work now. But I did find this http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=193337
[15:24] <cjwatson> Keybuk: I'd have thunk so ...
[15:24] <munckfish> The guy has a 64 bit object, but the linker is 32 bit
[15:24] <Keybuk> ok
[15:24] <Keybuk> now if package A contains a conffile, and package B contains a conffile with the same name
[15:25] <Keybuk> and you try and install package B
[15:25] <Keybuk> should that not fail also?
[15:25] <munckfish> cjwatson: I have no idea what the problem is yet
[15:25] <cjwatson> Keybuk: I'd have thought it would fail even harder. That said I'm not sure of the semantics of Replaces+conffiles
[15:25] <munckfish> I just need more time
[15:25] <cjwatson> munckfish: right, the question is why
[15:25] <Keybuk> cjwatson: right
[15:25] <Keybuk> except it doesn't
[15:25] <munckfish> cjwatson: yes, right
[15:25] <Keybuk> what I'm seeing here is simple
[15:26] <Keybuk> upstart-compat-sysv.conffiles has rcS-sulogin
[15:26] <Keybuk> friendly-recovery.conffiles *also* has rcS-sulogin
[15:26] <Keybuk> installing friendly-recovery succeeds without warning
[15:26] <Keybuk> it does *not* Replace upstart-compat-sysv
[15:26] <Keybuk> dpkg simply allows it
[15:26] <Keybuk> so you end up with a conffile changing ownership (and two packages claiming it in their .conffiles)
[15:26] <Keybuk> now, both have upgrades
[15:26] <Keybuk> friendly-recovery's upgrade removes the conffile again
[15:26] <Keybuk> upstart's upgrade changes the conffile
[15:27] <Keybuk> depending which order you do this upgrade, you will either get
[15:27] <Keybuk> a) status quo, upstart owns its conffile and content is correct
[15:27] <Keybuk> b) conffile prompt
[15:29] <mvo> Keybuk: it might be even funnier, I think I have seen a file overwrite error under certain situations for this conffile (see bug #205911)
[15:29] <ubotu> Launchpad bug 205911 in friendly-recovery "friendly-recover (ubuntu-standard) conflicts with upstart-compat-sysv (ubuntu-minimal)" [Medium,Fix released] https://launchpad.net/bugs/205911
[15:34] <cjwatson> Keybuk: that's very unpleasant :-/
[15:38] <ogra> asac, did you notice there is a flash .115 that came out on th weekend ?
[15:40] <jdong> ogra: .115? you mean .124?
[15:40]  * jdong feels out of context
[15:40] <ogra> jdong, no, 125 :)
[15:41] <ogra> thanks for the heads up :)
[15:41] <jdong> ogra: there's ANOTHER new flash?
[15:41] <jdong> sheesh!
[15:44] <laga> it must be incredibly hard for adobe to post the change logs where i can find them
[15:45] <ogra> heh
[15:45] <ogra> http://justin.everett-church.com/index.php/2008/03/10/preparing-for-flash-player-9-april-2008-security-update/
[15:46] <ogra> he's talking about 115 btw ..
[15:48] <pitti> Mirv: I can have a look, but it won't be high priority
[15:48] <pitti> Mirv: I opened a ffox tab for it for now
[15:48] <asac> ogra: yet another flash updated. darn
[15:49] <ogra> asac, http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html and the restrictions dont really look good
[15:49] <pitti> Hobbsee: kde-guidance> what's up with it now?
[15:50] <ogra> asac, apparently it will break wit flash7 content
[15:50] <asac> ogra: great.
[15:50] <asac> thats really good news
[15:50] <asac> is that official or a regrssion?
[15:51] <ogra> well, i dont have any clue about flash content
[15:51] <tjaalton> I've got a new xorg pkg ready for upload.. fixes vmmouse handling and an upgrade issue (dapper -> hardy)
[15:51] <ogra> asac, from teh announcement: "You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means"
[15:51] <asac> ogra: would give gnash a new high if they really stop supporting flash 7 - but i can't believe they do :)
[15:52] <ogra> might be a corner case, not sure
[15:52] <pitti> Mirv: oh, that already has a patch? great; yes, if asac is ok with it, I can sponsor that
[15:52] <Hobbsee> pitti: just saw the newest changelog entry
[15:52] <pitti> Hobbsee: this time it was done right, I hope :)
[15:52] <ogra> asac, see the bulletpoints on the last link i posted
[15:52]  * pitti dist-upgrades and runs the jockey test suite, just to double-check
[15:52] <asac> Mirv: whats this about?
[15:53] <asac> pitti: ?
[15:53] <asac> if i acked in the bug then its certainly ok :)
[15:53] <asac> ogra: yeah ... i took a quick look. have no time for such amusement right now :(
[15:53] <pitti> asac: applying the 'set gettext domain' fix in bug 204155
[15:53] <ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
[15:53] <asac> ah yeah ... please push the branch to -core-dev if yo do that
[15:54] <asac> otherwise go ahead
[15:54] <asac> i would do it in next free minute
[15:55] <pitti> asac: I'll do it a bit later, too; first I need to fix a time bomb, maybe with seb128's help
[15:55] <asac> hehe :)
[15:55] <asac> bryce: did you read what i wrote yesterday?
[15:55] <pitti> Hobbsee: jockey is happy with guidance 0.8.0svn20080103-0ubuntu15
[15:55] <asac> about XaaNoOffscreenPixmaps?
[15:56] <Hobbsee> pitti: nice
[15:57] <seb128> pitti: what?
[15:57] <pitti> seb128: gnome bug 15430
[15:58] <seb128> too small number ;-)
[15:58] <pitti> argh, sorry
[15:58] <pitti> freedesktop bug 15430
[15:58] <ubotu> Freedesktop bug 15430 in GLib "ABI break if compiled against a recent libdbus" [Critical,Assigned] http://bugzilla.freedesktop.org/show_bug.cgi?id=15430
[15:58] <pitti> seb128: I will reproduce the problem now and verify the fix
[15:58] <pitti> seb128: and after that hand you a package for testing, if that's fine (just to make triple-sure)
[15:58] <seb128> ah ok
[15:59] <pitti> seb128: i. e. our current dbus-glib .debs are fine, but a mere rebuild breaks them
[15:59] <pitti> (thus "time bomb")
[15:59] <seb128> pitti: walters is on #ubuntu-desktop if you need to talk to him, he pinged me about that the other day to ask what dbus version has been used to do the current debian build
[15:59] <seb128> pitti: ok
[15:59] <tjaalton> pitti: as a member of the RT could you check http://users.tkk.fi/~tjaalton/dpkg/xorg.debdiff ? :)
[16:00] <tjaalton> pitti: the changes look big, but it's basically reverting to what we had in 10ubuntu7 (now we have CorePointer set so this actually works)
[16:01] <alex-weej_> seb128: trying to get to this nautilus hanging problem, you read my post about not being able to get GDB to send a SIGINT?
[16:02] <pitti> tjaalton: first and third points are straightforward, of course
[16:02] <pitti> tjaalton: what's the benefit of this dynamic detection instead of letting vmmouse do it, as right now?
[16:02] <seb128> alex-weej_: no
[16:03] <seb128> alex-weej_: that's weird
[16:03] <pitti> tjaalton: s/dynamic/one-time/ of course
[16:03] <alex-weej_> seb128: yeah. :/
[16:03] <tjaalton> pitti: only i386&amd64 have vmmouse :)
[16:03] <alex-weej_> seb128: maybe i could do it by a process of elimination, i'll try and nuke the nautilus extensions i'm using. if you can think of anything more efficient let me know!
[16:03] <pitti> tjaalton: ah, point :)
[16:04] <seb128> alex-weej_: which ones are installed?
[16:04] <seb128> alex-weej_: I might get the issue but my disks are fast enough to not notice the 1 second gap there
[16:04] <tjaalton> pitti: so ok to upload?
[16:04] <alex-weej_> seb128: it's an external seagate btw, takes about 5-10 seconds to spin up
[16:05] <alex-weej_> seb128: and just the stock installation + nautilus-open-terminal
[16:05] <pitti> tjaalton: hm, I don't have vmmouse_detect; are you sure that this is spelt correctly? or another dependency is missing?
[16:05] <pitti> tjaalton: oh, or is that only in vmware tools?
[16:06] <tjaalton> pitti: it's from mdetect
[16:06] <tjaalton> soren: actually, could you patch your dexconf to test this ^^
[16:07] <tjaalton> or someone with a kvm setup
[16:09] <pitti> tjaalton: ah, right, I have it removed, but not purged (for some reason; I never manually remove packages, just purge)
[16:10] <pitti> tjaalton: the logic looks reasonably defensive, so I'm ok with it
[16:10] <tjaalton> pitti: ok cool
[16:11] <soren> For it to work, we need the mdetect I uploaded a few hours ago, too.
[16:12] <pitti> seb128: do you have some minutes to rebuild and install http://incoming.debian.org/dbus-glib_0.74-2.dsc and test it for a bit? I'll do that on amd64 here
[16:12] <seb128> pitti: sure
[16:12]  * pitti hugs seb128
[16:12]  * seb128 hugs pitti
[16:12] <tjaalton> soren: ah right :)
[16:12] <tjaalton> bbl ->
[16:13] <soren> tjaalton: Under KVM, that is. VMWare does "interesting" things to make it work without my patch.
[16:14] <soren> tjaalton: By "interesting" I mean "rather evil".
[16:19] <jdstrand> pitti: hi!
[16:19] <jdstrand> pitti: I was curious on your thoughts on dapper -> hardy cupsys upgrades wrt apparmor
[16:20] <jdstrand> pitti: in https://wiki.ubuntu.com/ApparmorProfileMigration we put apparmor in complain mode for dapper -> hardy, so as not to break anything
[16:21] <jdstrand> pitti: OTOH for standard desktop upgrade, there would be no problem, but I can envision potential problems for specialized cupsys servers
[16:31] <pitti> jdstrand: what's the problem with the upgrade?
[16:31] <pitti> jdstrand: oh, you mean if someone installed a-p on dapper and then upgrades?
[16:31] <jdstrand> pitti: oh no-- nothing specific. I am thinking hypothetically
[16:31] <pitti> jdstrand: did that have a different profile file name?
[16:32] <pitti> jdstrand: ending up in complain mode under hardy would be bad
[16:32] <jdstrand> pitti: no, I mean apparmor isn't available on dapper, so they could change the configs at will, then update to hardy and apparmor breaks their configuration
[16:32] <pitti> since we dropped our derooting patch, and the profile is our only way to reasonably confine it
[16:32] <pitti> jdstrand: hm; that's outside of our powers, I think
[16:32] <pitti> dpkg's conffile magic should hopefully catch that
[16:32] <seb128> pitti: seems to work fine on my laptop
[16:32] <pitti> seb128: merci
[16:32] <seb128> de rien ;-)
[16:35] <jdstrand> pitti: I'm not a cups guru, but my feeling is people would need to do something really exotic with their dapper configuration for the apparmor profile to break things-- would you agree?
[16:35] <pitti> jdstrand: they could have configured stuff which prevents new features (read: backends) in hardy from working properly, or at all
[16:36] <pitti> jdstrand: but really, if they went that far, my gut feeling is that they should read the conffile debdiff, or dmesg for the error messages
[16:36] <pitti> (or not care about the new features)
[16:37] <jdstrand> jdstrand: ok.  this seemed a little bit different than the other servers that now have enforcing profiles (named, mysqld and slapd), but I at least wanted to talk about it with you. I agree, esp wrt the derooting patch, it needs to be enforcing
[16:38]  * pitti chuckles while watching jdstrand talk to himself
[16:38] <jdstrand> oh heh
[16:38] <jdstrand> pitti: ^ :P
[16:38] <pitti> 'safer printing'
[16:39] <pitti> seb128: ok, that dbus-glib patch looks obviously correct to me, too
[16:49] <seb128> pitti: right
[16:49] <pitti> seb128: I'll sync it now, and take the bullets
[16:49] <seb128> pitti: ok, I'll keep an eye on bugs and let you know if I spot something
[16:54] <Keybuk> FUCK YOU HPLIP
[16:54] <Keybuk> </stress release>
[16:55]  * pitti hands Keybuk a piece of chocolate
[16:55]  * ion_ hands Keybuk a piece of whiskey
[16:56]  * Hobbsee steals the chocolate from pitti
[16:57] <pitti> tsk
[16:57]  * Hobbsee needs chocolate!
[16:57]  * tedg hands Keybuk an HP printer, baseball bat and the instructions from Office Space
[16:57] <pitti> Hobbsee: go and give Keybuk some other relaxation then, like a neck massage :)
[16:57] <Hobbsee> pitti: he'd probably throw me thru the nearest window or something.
[16:58] <Keybuk> tedg: it's not the printer, it's worked fine in previous ubuntu releases for ages
[16:58] <Hobbsee> pitti: or decide to snap me into little pieces.
[16:58] <Keybuk> it's hardy
[16:59] <tedg> Anger need no rational object to take itself out on :)
[16:59] <tedg> I would have to say though, in general, while I love that HP is supporting their devices under Linux, I don't like HPLIP.
[17:01] <Keybuk> I'm not 100% sure it's HPLIP
[17:01] <Keybuk> since I've now configured the printer to print direct
[17:01] <Keybuk> there's less OMGTHESKYISFALLING in syslog, but there's still no more printing
[17:01] <Hobbsee> why do you want to print anyway?
[17:01] <Hobbsee> it seems like a terribly overrated idea.
[17:02] <seb128> stop wasting paper!
[17:02] <Hobbsee> exactly.
[17:03]  * Hobbsee thinks of the next hissy fit her coworker will do, when next put with the idea that she has to use a computer, with a mouse, and grins
[17:04] <Hobbsee> seb128: thanks for giving me something amusing to go to sleep to.
[17:08] <infinity> ogra: Pong?
[17:12] <ogra> infinity, are you the guy to ask about disabling ports of edubuntu ?
[17:13] <ogra> in the supported arches we dont build alternate and desktop anymore, i noticed ports.u.c still has it
[17:13] <cjwatson> surely that's a cdimage thing not ports.u.c?
[17:13] <ogra> err ...
[17:13]  * ogra slaps forehead
[17:13] <ogra> indeed
[17:14] <infinity> Yeah...
[17:14] <cjwatson> just needs unlinked, I'll do that
[17:14] <ogra> thanks :)
[17:14] <cjwatson> cdimage carries over all images by default, so when we stop building anything somebody needs to unlink by hand
[17:15]  * ogra notes for next time
[17:15] <cjwatson> done, modulo mirror propagation
[17:21] <thekorn> dholbach, hi, is it save to remove some bugs from my 5-a-day file,
[17:22] <thekorn> or will this mess up the stats page
[17:23] <dholbach> thekorn: should be safe
[17:25] <thekorn> dholbach, ok, I will remove some of my entries which does not make any sense
[17:25] <dholbach> thekorn: rock on :)
[17:25] <dholbach> thekorn: I wanted to leave the honours to you :)
[17:25] <cjwatson> infinity: did you see my mail about ps3-kboot weirdness?
[17:26] <infinity> cjwatson: I'm in the process of getting my mailserver back online (latest hardy kernel seems to have asploded it), so I'll get to reading email in a few mins. :/
[17:27] <cjwatson> infinity: short version is that it builds on davis but chucks link errors on the buildd
[17:29] <infinity> cjwatson: linux32 madness?
[17:32] <cjwatson> infinity: hmm, could be
[17:35] <infinity> cjwatson: On powerpc, I invoke sbuild with "linux32 sbuild ...", so trying the davis build with linux32 would be nice.
[17:35] <infinity> cjwatson: Given the 64 versus 32 linking error, I'm guessing that's the issue.
[17:37] <infinity> cjwatson: If that doesn't allow you to reproduce it, let me know, and I'll delve deeper.
[17:37] <cjwatson> yep, just trying it on davis now
[17:37] <_MMA_> cjwatson: Thanx for the language pack preseed tweak. Works great.
[17:38] <cjwatson> _MMA_: cool
[17:51] <bryce> asac, sorry I was afk for the weekend
[17:52] <asac> bryce: please read ;)
[17:52] <asac> and upload :)
[17:53] <asac> bryce: http://paste.ubuntu.com/7018/
[17:53] <asac> those are the relevant bits
[17:54] <bryce> thanks
[17:55] <asac> bryce: i can get you more context from cairo channel if you really need to ... in short: not disabling offscreen pixmaps is indeed a very bad idea for xaa ... so we should definitly do that.
[17:58] <bryce> asac, thanks I'd appreciate additional context you can dig up (so I can more deeply understand the fix)
[17:59] <asac> bryce: there is nothing to understand
[17:59] <asac> bryce: offscreenpixmaps need to be turned off
[17:59] <asac> they are bogus ;)
[17:59] <asac> bryce: read the line in the paste:
[18:00] <asac> 22:11 < cworth> vlad_: Not with XAANoOffscreenPixmaps=True, there's not. That fixes  performance and  quality bugs.
[18:00] <asac> bryce: you said that doing this would hurt performance, but it actually doesn't ... he said that trying to optimize in xaa is never a good thing
[18:03] <asac> bryce: this is the discussion tha tfollowed after i asked to confirm that performance improves if you disable this optimization:
[18:03] <asac> bryce: http://paste.ubuntu.com/7020/
[18:04] <asac> bryce: so performance is better
[18:04] <asac> bryce: and there are less bugs because you don't depend on hardware specifics anymore
[18:04] <asac> win-win
[18:05] <asac> bryce: and fedora has it off everywhere by default too. so we are rather alone - no doubt thats one of the reason why these things don't get fixed
[18:06] <asac> bryce: firefox will backout the hack they had to disable parts of xrender
[18:07] <asac> bryce: so if we don't take it, then firefox upstream users will get http://people.ubuntu.com/~asac/corrupted1.png
[18:07] <asac> on every repeat-reflect tiled background in ubuntu
[18:07] <asac> (not that i search for more reasons :))
[18:07] <infinity> cjwatson: Should I assume from the radio silence that you reproduced the failure and are now working on working around it?
[18:08] <cjwatson> infinity: I'd actually forgotten about that window; but unfortunately (?), it seems to be happily building under linux32 too
[18:08] <cjwatson> certainly no early failure
[18:08] <infinity> cjwatson: Damn.
[18:09] <infinity> cjwatson: Kay, can you file a ticket then, so I don't lose it in the recesses of my rebuild-addled mind, and I'll poke it later?
[18:10] <jdong> bryce: is texturedvideo usable on the gma950 or is it awful slow?
[18:12] <bryce> jdong: I've heard fairly mixed reviews, although a lot of the remaining issues sound like they might just be corner cases / config issues
[18:14] <jdong> bryce: sounds like something I should try :D
[18:15] <bryce> asac, do you have a pointer to the redhat patch?  I can try packaging it up today
[18:16] <jdong> bryce: well it works but is very CPU intensive
[18:18] <jdong> bryce: does that mean I'm doing something wrong or is that a limitation of my hardware?
[18:18] <asac> bryce: in the paste
[18:18] <asac> there is a checkout command
[18:19] <asac> bryce: 22:12 < otaylor> $ cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs get  xorg-x11-server     look at devel/xserver-1.5.0-xaa-sucks.patch
[18:19] <bryce> thanks
[18:19] <asac> np
[18:20] <bryce> heh, cvs... quaint
[18:20] <alex-weej> fedora still use cvs!?
[18:20] <jdong> bryce: seems like while fullscreen and unredirected TV works great but windowed it's CPU-heavy. At least it doesn't hang like overlay for me
[18:22] <bryce> asac: ok patch looks safe and good.
[18:23] <seanh> If I want to start developing a Python CGI script on Ubuntu, can anyone point me to instructions on how to get going? I know Python, what I need to know is what packages to install and where to put my CGI scripts in order to be able to test them locally on Ubuntu
[18:24] <bryce> jdong: sounds like it's doing software acceleration or something.  I don't know enough about texturedvideo's design/implementation to know why it would be cpu intensive, but it's still sort of new-ish so it doesn't surprise me
[18:24] <asac> bryce: thanks a lot. can we get that into RC1 so we get feedback ?
[18:24] <bryce> jdong: there may be some settings required to push it into hardware accel mode
[18:25] <bryce> asac, I think so.  Should be simple to integrate
[18:25] <asac> bryce: thanks!
[18:26]  * asac hugs bryce
[18:26] <bryce> asac: the thing to watch for is that upstream's comments are all generalizations - "in general we feel this to be better", but the bugs will come from those people not in the general case ;-)
[18:27] <cjwatson> infinity: RT#30463, thanks
[18:28] <bryce> asac: however we've been making "deprecation noises" about XAA for a while anyway
[18:28] <asac> bryce: right. but i'd say that putting more into software is usually a safe thing (without being X matinainer of course)
[18:28] <bryce> I just hope it affects performance only, and doesn't render systems unusable (they hate that)
[18:29] <cjwatson> james_w: your last grub-installer patch seems like it'll re-encrypt anything passed with grub-installer/password-crypted. Shouldn't the md5crypt call be in the else branch?
[18:29] <bryce> yep probably so.  Different code paths though, so different bug risks.  But that software code is probably been heavily tested.
[18:29] <cjwatson> james_w: (if you agree, I'll just make that change, no need to repost)
[18:35] <slangasek> james_w: how thoroughly has the change for bug #136837 been tested prior to upload?  I guess this patch isn't committed upstream yet
[18:35] <ubotu> Launchpad bug 136837 in gnome-applets "Mixer applet randomly decides to consider my sound card to be "muted" when changing volume" [Low,Triaged] https://launchpad.net/bugs/136837
[18:36] <slangasek> james_w: and I don't understand your comments between 136837 and 215086 - one seems to say that fixing 136837 will /cause/ the problem in 215086, the other says it may /fix/ the problem in 215086...?
[18:41] <LaserJock> slangasek: would this pass your scrutiny: http://launchpadlibrarian.net/13404149/seahorse-hkp-source.c.diff ?
[18:42] <slangasek> LaserJock: +hexfpr[2] = 0; <-- gratuitous :)
[18:42] <slangasek> LaserJock: it /looks/ correct now.  have you verified that there are no memory leaks introduced here?
[18:43] <LaserJock> I haven't yet
[18:43] <LaserJock> not sure how to test that actually, but I can find out
[18:47] <zul> slangasek: hi http://pastebin.ca/984952 for nagios-plugins (fixes a long standing bug)
[18:50] <kirkland> Keybuk: don't shoot me, but what would you think of adding a couple of commented lines to /etc/inittab that points to the "runlevel" manpage or other documentation (URL?) for experienced RH/SUSE/Debian/UNIX users looking for their accustomed runlevel stuff?  (We just answered that question again in #ubuntu-server)
[18:50] <slangasek> zul: errm. why does fixing a segfault require pulling in a complete base64 implementation?
[18:50] <zul> slangasek: because it was taken from their SVN
[18:50] <slangasek> ah
[18:50] <zul> and their base64 stuff was horribly broken
[18:51] <slangasek> zul: ok, go for it then
[18:51] <zul> slangasek: thanks
[18:55] <infinity> cjwatson: Other than the general urgency of "RC in 3 days, release in 10", is the ps3-kboot something you need done ASAP, or "in a day or two'?
[18:56] <james_w> cjwatson: yes, you're right, thanks for catching it.
[18:56] <james_w> slangasek: I've tested it here, and it is used in Fedora and Mandriva. Unfortunately there's been no comment on it upstream.
[18:57] <james_w> slangasek: it may in fact be unrelated to the other bug, I was just going on what the Mandriva guy said in the upstream bug report. I don't have an appropriate setup to test that part.
[18:57] <slangasek> james_w: ok, accepting then
[18:57] <slangasek> james_w: right, I was just confused as to *what* the expected effect on the other bug would be, since your comments in the two bugs seemed to contradict each other
[18:58] <james_w> I tried to work with one of the gstreamer devs to get a fix for the second bug, but he didn't confirm that the patch worked.
[18:59] <james_w> slangasek: sorry for the confusion, the second bug is a typo, it should read "make this happen", rather than "make this work".
[19:12] <cjwatson> infinity: well, it *is* ports, but the problem is that the current ps3-kboot is utterly buggered because they changed the boot protocol
[19:12] <infinity> cjwatson: Spiffy.  I'll try to make time for it pre-RC.
[19:22] <siretart>
[19:29] <MarLaw> Hi people, I'm interested in contributing to ubuntu, I'm checking out MOTU and the process, I also heard that I can find a mentor to introduce me a bit, do you have more info on that ?
[19:30] <james_w> MarLaw: there is
[19:30] <james_w> a #ubuntu-motu channel for MOTU
[19:30] <MarLaw> thanks james_w
[19:31] <mario_limonciell> slangasek, would you mind releasing the last mythtv upload so it squeezes onto our RC disk?
[19:32] <slangasek> mario_limonciell: done, ya rotten queue jumper :)
[19:32] <laga> mario_limonciell: did you upload mythplugins too?
[19:32] <mario_limonciell> slangasek, thanks
[19:32] <mario_limonciell> laga, no i haven't tested your the diff
[19:33] <munckfish> cjwatson: I'm off home now, will you be around later so I can depress you with stupid questions if needed? ;)
[19:33] <laga> mario_limonciell: "your the diff"? i guess i forgot to post that ;)
[19:34] <siretart>
[19:34] <mario_limonciell> laga, i'll test it this evening to verify
[19:35] <laga> great. i'll test the alternate disk
[19:35] <slangasek> munckfish: hi, should bug #146230 have been marked as fixed with the upload of ps3-kboot 1.6-1?
[19:35] <ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
[19:36] <munckfish> slangasek: umm, if it had built successfully on the buildd yes
[19:36] <munckfish> it builds fine everywhere else
[19:36] <munckfish> just not on there
[19:36] <munckfish> colin and I were looking into it earlier today
[19:37] <munckfish> I will do best to resolve it later
[19:37] <slangasek> munckfish: well - the bug requesting the update could be closed, though? :)
[19:37] <slangasek> or if you prefer to close it by hand when the build is fixed, that's ok
[19:37] <munckfish> slangasek: ok I see
[19:37] <munckfish> so it can be closed now
[19:37] <munckfish> fine
[19:37] <munckfish> I can see to it later
[19:38] <munckfish> (if I have the reqd LP permissions)
[19:39] <munckfish> ok, I'm away home. Hopefully back online in an hour or so. Bye all!
[19:39] <slangasek> zul: why is nut uploaded with a ~ppa version number...?
[19:40] <slangasek> zul: I'm guessing that went to the wrong upload target?
[19:41] <zul> slangasek: yep I was just about to talk to you about that one
[19:41] <slangasek> ok, rejected ;)
[19:41] <zul> slangasek: this was the actual debdiff for that one http://pastebin.ca/985021 (it fixes a regression in nut)
[19:42] <slangasek> yes, I'd seen that in the queue, looks ok
[19:42] <zul> slangasek: thanks..
[20:02] <cody-somerville> Gah. I hate it when someone unassigns a bug I've assigned to myself to some team like ubuntu-desktopbugs when the bug is waiting on *me* to do something.
[20:15] <doko> slangasek: updated versions: http://people.ubuntu.com/~doko/tmp/bash-completion.debdiff http://people.ubuntu.com/~doko/tmp/bash.debdiff
[20:18] <laga> i'm wondering how i can make tasksel come up on the alternate disk. is it enough to remove the tasksel preseed entries? (i'd try it, but remastering the disk takes a lot of time)
[20:28] <mok0> Is it necessary to request a sync for new packages in Sid, or will they be sync'ed automatically for ibex?
[20:29] <Mithrandir> they'll be synced "automatically"
[20:29] <mok0> Mithrandir: ok, thx
[20:29] <Mithrandir> ("automatically" because it's a manual process, but it's typically run about daily up until import freeze)
[20:29] <cjwatson> laga: correct, removing the tasksel preseed entries will do it assuming that there's more than one task on the disk
[20:30] <laga> cjwatson: yay. great.
[20:33] <doko> infinity, slangasek: how serious are the failed builds from yesterday's autobuildtst? i.e. mutt failed due to a missing links package for example, but apparently succeeded to build on the normal buildd
[20:37] <infinity> doko: I'll be going through logs and filing in a bit.
[20:37] <infinity> doko: But that sounds like a "real" failure to me...
[20:38] <doko> infinity: why? elinks is in main and provides links
[20:38] <doko> thought our sbuild can handle this ...
[20:39] <infinity> doko: Oh, I didn't understand what you were saying until I read the log.
[20:39] <infinity> doko: It's possible sbuild on the autotest machines is out of sync with sbuild in LP... I'll have to check that before I find out why that failed.
[20:40] <infinity> doko: Actually, hrm.  It didn't succeed on LP due to sbuild at all.  sbuild called "apt-get install links", it's apt-get that DTRT.
[20:40] <doko> ok, thanks.
[20:40] <laga> slangasek: can you please merge r1298 from http://bazaar.launchpad.net/%7Emythbuntu/debian-cd/mythbuntu-debiancd/ ?
[20:41] <infinity> doko: And there's the bug.  elinks in main no longer Provides links.
[20:41] <infinity> doko: So, yes, there's a bug.
[20:41] <infinity> doko: Whether the bug is "no links in main for mutt to build-dep on" or "elinks doesn't provide links anymore", the failure is real.
[20:42] <doko> ok
[20:43] <doko> slangasek: should we delay fixing these build failures until after the RC?
[20:44] <infinity> RC isn't for a few days, I'm sure we can push some fixes out.
[21:01] <bigon> is soyuz accepting binnary packages?
[21:02] <infinity> bigon: As in binary uploads from buildds?
[21:03] <bigon> as binary pkg build from developpers (it's to fix the openhackware FTBFS, the pkg must be builded on ppc)
[21:03] <Mithrandir> bigon: no.
[21:03] <infinity> bigon: No, we don't accept binary uploads.
[21:04] <bigon> so how can this kind of FTBFS be fixed?
[21:05] <seb128> why couldn't it build on the buildds?
[21:05] <cjwatson> arch all => built on i386, I imagine
[21:05] <cjwatson> the traditional answer is to offer infinity beer to build it for you
[21:07] <Amaranth> someone has been trying to figure out how to fix openfirmware for like 2 years now :P
[21:07] <Amaranth> either they keep fixing it and it keeps breaking or they gave up
[21:11] <bigon> and a lp admin using his magical power? (only as workaround in the first time)
[21:12] <infinity> cjwatson: That answer was shot down by infinity due to the fact that it would have to be done for every upload. :/
[21:12] <infinity> bigon: Have you looked at how "palo" cheats in this regard?
[21:14] <infinity> bigon: (It compiles in the clean target, iff the host arch is hppa, and the source package is always built on an hppa developer's machine before upload)
[21:14] <infinity> bigon: Not ideal, but... Beats begging me to build manually on every upload.
[21:14] <cjwatson> infinity: ah :-/
[21:14] <bryce> slangasek: fix for 8.04 milestoned bug #182038 has package xorg-server 2:1.4.1~git20080131-1ubuntu8 queued for approval
[21:14] <cjwatson> infinity: !
[21:15] <cjwatson> infinity: uploading binaries by the back door?
[21:15] <infinity> cjwatson: Did we just learn something we didn't want to know? :)
[21:15] <cjwatson> what did you say again?
[21:15] <infinity> I SAID NOTHING.
[21:15] <infinity> Move along.
[21:17] <kees> archive admins: when you get a chance, can you manual-shove "refpolicy" (universe), please?
[21:21] <bdmurray> slangasek: have you seen bug 216209?
[21:21] <ubotu> Launchpad bug 216209 in pam "package libpam-modules <IP_ADDRESS>-5ubuntu5 failed to install/upgrade:  (Hardy)" [Undecided,New] https://launchpad.net/bugs/216209
[21:22] <yosch> cjwatson: hi, when you have a spare minute could you please take a look at bug 180011 ? It's for the new package with source, new license and trademark updates to ubuntu-title. Thanks.
[21:22] <ubotu> Launchpad bug 180011 in ttf-ubuntu-title "Lack of SFD source file breaks LGPL license and makes file unredistributable!" [High,In progress] https://launchpad.net/bugs/180011
[21:23] <bigon> infinity: the openhackware is quite stable (the version in the archive is 2 years old)
[21:23] <yosch> cjwatson: I subscribed motu-release
[21:25] <cjwatson> yosch: I don't mean to be bureaucratic, but since I'm deep in something else right now and will take an hour or so to get round to this, it might be quicker to hunt in #ubuntu-motu for an uploader first; it has my approval in principle though
[21:26] <infinity> bigon: If it's really that stable, I can do a manual build for now.  I'm filing a soyuz bug to see if maybe we can get some arch:all affinity granularity for bizarre cases like this.
[21:27] <yosch> cjwatson: no problem. I'll patiently wait for someone in #ubuntu-motu. cheers.
[21:28] <bigon> infinity: I just see that debian has a -3 revision, maybe uploading this revision first?
[21:28]  * bigon hides
[21:29] <slangasek> doko: well, in general build failures should be fixed for release, but they don't have to be fixed before RC - nor do they /have/ to be deferred until after RC
[21:30] <infinity> bigon: Get it approved by an MOTU release manager, get it uploaded, and get the source in the archive, then we'll talk.
[21:31] <infinity> bigon: I really don't want to do this manual build more than once. :/
[21:32] <infinity> bigon: Oh, I see we ship it unmodified.  Well, get it approved as an FFe, then, and get it synced.
[21:32] <slangasek> bdmurray: hadn't seen that, no... is there a standard incantation to get actual upgrade logs out of the submitter, since apport apparently doesn't attach this?
[21:32] <infinity> bigon: Err, freeze exception in general, even.
[21:32] <slangasek> bdmurray: eh, " ErrorMessage: package libpam-modules is already installed and configured" <-- huh?
[21:33] <bdmurray> slangasek: I'm not certain about that bug anymore.  I thought it might be related to my failure to upgrade from gutsy to hardy due to libpam0g.
[21:36] <slangasek> bdmurray: well, not that I can see
[21:41] <bdmurray> slangasek: bug 217435 is what I ran into today
[21:41] <ubotu> Launchpad bug 217435 in pam "Internal Error, Could not perform immediate configuration (2) on libpam0g" [Undecided,New] https://launchpad.net/bugs/217435
[21:42] <mvo> bdmurray: that bug you mentioned with pam looks like update-manager is reporting it wrongly, it seems its all a duplicate of #215293
[21:42] <mvo> bdmurray: mhhh, maybe not, but the /var/log/apt/term.log should give us a clue
[21:42] <slangasek> right, I was going to say, I don't see how this can be a pam bug
[21:48] <slangasek> laga: mythbuntu debian-cd merged
[22:14] <bdmurray> slangasek: When you get a chance could you look at 217435?
[22:17] <slangasek> bdmurray: can you provide the term.log mvo mentioned?  This is really an apt problem, not a pam problem anyway
[22:18] <bdmurray> slangasek: Sure, I thought he was talking about that other bug report.
[22:19] <slangasek> oh, maybe he was
[22:19] <bdmurray> Actually I've provided everything that existed in '/var/log/dist-upgrade/' and '/var/log/apt/term.log' only contains information about package upgrades.
[22:22] <soren> Hm... I need to find the appropriate ifdef's for only compiling certain things on i386 and amd64. Now, I *could* just look in some code that does it already, but where is that actually documented?
[22:23] <slangasek> bdmurray: ok, well, either way, 217435 is not a pam bug (the pam package relationships have been correct and stable since before gutsy), and there's not enough info in that bug report to diagnose the cause of the failure...
[22:24] <slangasek> bdmurray: but "could not perform immediate configuration", AIUI, normally means that apt had a problem resolving the pre-dependencies of the Essential package set
[22:24] <alex-weej> pulseaudio is default in hardy right? are we using the pulse ALSA plugin for ALSA apps?
[22:25] <alex-weej> if so, i've some bugs to file (my system is an upgrade so i don't know what the default setup is)
[22:26] <bdmurray> slangasek: okay, I'll reassign to update-manager then
[22:34] <Riddell> doko: you uploaded scim-qtimm to fix a build failture, but it seems to be built https://edge.launchpad.net/ubuntu/hardy/+source/scim-qtimm/0.9.4-2ubuntu2
[22:35] <slangasek> Riddell: it's probably a build failure that showed up in infinity's autotestbuild run
[22:35] <Riddell> ah
[22:35] <slangasek> or autobuildtest, or whichever way 'round that goes :)
[22:44] <doko> Riddell: was last rebuilt in gutsy, now dpkg doesn't like duplicate attributes in control files
[23:02] <slangasek> Amaranth: y'know, it makes me uneasy to see that the solution for a buffer overflow is to make a bigger buffer... :)
[23:03] <slangasek> Amaranth: oh, you didn't upload this
[23:03] <slangasek> mvo: ^^
[23:03] <Amaranth> eh?
[23:03] <Amaranth> what package is that? :)
[23:03] <slangasek> Amaranth: sorry, I was reading the wrong line in the compiz debdiff :)
[23:03] <Amaranth> i can't upload anything to main :P
[23:03] <slangasek> well, no, but it might've been sponsored :)
[23:05] <wasabi> somebody i have an ubuntu box which allows any and all passwords for any users on the console.
[23:05] <wasabi> grrrr.
[23:05] <wasabi> s/somebody/somehow/
[23:05] <wasabi> silly pam, no cookie for you
[23:05] <slangasek> curious
[23:06] <mvo> slangasek: right, this comes directly from upstream (and they are pretty clueful) - but if you feel uneasy I can clarify tomorrow
[23:06] <munckfish> infinity: hi have you got a minute?
[23:07] <slangasek> mvo: I've accepted it, it can't be a regression vs. what there is now - but it doesn't look like a very correct fix to me, since if it overflowed once, that means there's code elsewhere that makes hard-coded assumptions about the buffer size that should still be fixed
[23:09] <Amaranth> slangasek: we make some assumptions like that in bunches of places in compiz
[23:10] <megabyte405> Can I get someone to review the AbiWord 2.6 upload?
[23:10] <slangasek> slomo: fwiw, bug #199496 didn't get closed on package accept because the bug was only assigned to gtk-sharp2 (which didn't close the bug), not gnome-sharp2 (which did)
[23:10] <ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Confirmed] https://launchpad.net/bugs/199496
[23:10] <slangasek> slomo: I think the best thing to do in this case would have been to have a task for each package, and close it in both changelogs?
[23:10] <slangasek> megabyte405: is wv sorted?
[23:10] <slangasek> Amaranth: that's... bad
[23:10] <megabyte405> slangasek: at least verbally, yeah - sunday night pitti said that it would be fine since it was in main until gutsy anyway
[23:11] <Amaranth> slangasek: but it's fast :P
[23:11] <Amaranth> although i think in most cases we don't use any outside input to fill the buffer so if it overflows we've broken something ourselves
[23:12] <slangasek> Amaranth: not faster than using sizeof() to get compile-time integer math on your buffers to be sure that nothing can overflow it...
[23:12] <Amaranth> which bug is he trying to fix? i'm a bit out of the loop here
[23:12] <slangasek> Amaranth: buffer overflow in gaussian blur with radius > 12
[23:12] <Amaranth> ah
[23:13] <slangasek> no bug number mentioned in the changelog, IIRC (it's no longer in front of me)
[23:13] <mvo> Amaranth: maniac pointed me to the patch today
[23:13] <infinity> munckfish: Possibly, what's the minute being used for? :)
[23:13] <Amaranth> although blur is general is pretty broken so i doubt that's a huge issue :P
[23:13] <Amaranth> it only works on nvidia cards, afaik
[23:14] <munckfish> Hi, I'm trying to solve a build fail on adare - ps3-kboot
[23:14] <slangasek> Amaranth: anyway, checking your bounds is surely going to be faster than continuing to write memory past the end of the buffer ;)
[23:14] <munckfish> It builds fine on ps3, colin watsons 'davis' machine
[23:14] <cjwatson> (not my machine, it's a powerpc box in the Canonical DC)
[23:14] <munckfish> but failed on adare
[23:15] <munckfish> cjwatson: hi thx for clarifying
[23:15] <munckfish> infinity:
[23:15] <munckfish> infinity: could you run a script on adare so I can see what certain build vars would end up as? http://paste.ubuntu-nl.org/63186/
[23:15] <munckfish> Or could you tell me what they'd end up as?
[23:16] <cjwatson> slangasek: I dunno, the kernel might be able to optimise it if the memory after the end of the buffer is mmapped from /dev/zero :-P
[23:16] <slangasek> heh
[23:16] <infinity> munckfish: I can in a sec... I'm just in the middle of something.
[23:16] <cjwatson> or indeed /dev/null, er, meh
[23:16] <munckfish> infinity: thx
[23:16] <slangasek> cjwatson: I'm pretty sure the kernel trap would be more expensive still :-)
[23:17] <cjwatson> spoil my fun, why don't you
[23:18] <slangasek> mvo: I totally don't understand the debdiff for bug #216822; the bug report talks about amd64, and your change in the package is s/i386/powerpc/...?
[23:18] <ubotu> Launchpad bug 216822 in gnome-app-install "Can't install ardour2 from add/remove programs in latest hardy build" [Low,Fix committed] https://launchpad.net/bugs/216822
[23:21] <mvo> slangasek: amd64 was not listed, that makes the package appear in the list but it is shown with a remark that it is not avilalbe on the given architecure - this is to avoid a situation were people search for software and wonder why we don't have it. we tell them that we have it but can't provide it for their arch for some reason. the problem here is that the ardour desktop file had a incorrect architecure field
[23:22] <mvo> slangasek: (well, two incorrects even - its available on all arches, so the fields are bogus)
[23:22] <slangasek> mvo: so how does putting "powerpc" there help anything?
[23:24] <mvo> slangasek: my debdiff for the ardour.desktop file looks like this: http://paste.ubuntu.com/7052/
[23:25] <mvo> slangasek: do you see something different?
[23:26] <slangasek> mvo: only when I'm not looking at it properly
[23:26] <slangasek> mvo: I thought it was -/+, not -/-; thanks for your patience :-)
[23:26] <infinity> munckfish:
[23:26] <infinity> Hostname: adare
[23:26] <infinity> GCC dumpmachine: powerpc-linux-gnu
[23:26] <infinity> kboot HOST_ARCH: powerpc
[23:26] <infinity> Uname -a: Linux adare 2.6.15-28-powerpc64-smp #1 SMP Thu May 10 10:05:07 UTC 2007 ppc GNU/Linux
[23:26] <mvo> slangasek: no problem :) thanks for your review!
[23:28] <munckfish> infinity: thx v much!
[23:33] <infinity> munckfish: Do I even want to know why ps3-kboot ships with its own linux source tree? :)
[23:34] <cjwatson> infinity: Ben gave the OK for that for this release - we don't have time to build it from our kernel :-/
[23:34] <munckfish> infinity: the bootloader for PS3 needs USB, and Bluetooth support so it runs it's own compact kernel
[23:34] <cjwatson> infinity: it's just a bootloader, so security implications are minimal
[23:34] <munckfish> infinity: networking disabled etc
[23:35] <infinity> Scary...
[23:35] <munckfish> infinity: would you have any idea
[23:35] <munckfish> why we get "ld: Relocatable linking with relocations from format elf64-powerpc (init/do_mounts.o) to format elf32-powerpc (init/mounts.o) is not supported"
[23:35] <munckfish> on adare but nowhere else?
[23:35] <infinity> I'm doing a test build on adare right now...
[23:35] <munckfish> I'm currently needling thru makefiles trying to work it out
[23:35] <munckfish> infinity: oh cool thx
[23:36] <infinity> Oh, good, it fails without sbuild in the equation.  That makes it definitely Not My Bug.
[23:36] <slangasek> munckfish: what does the build log show as to how it's built?  Do you see each of those object files being built in the build log?
[23:36] <munckfish> As far as I can see the kernel makefile is passed exactly the same stuff on all the machines we've built on so far
[23:36] <munckfish> slangasek: yes
[23:37] <munckfish> it doesn't get very far
[23:37] <infinity> munckfish: For reproducibility's sake, I'm using a debootstrap --variant=buildd chroot, upgraded to latest hardy, /proc and /dev/pts mounted, then "linux32 chroot test-chroot", installing build-deps, and building.
[23:37] <munckfish> the first time it tries to link it fails
[23:37] <infinity> slangasek: The log is rather opaque, it's the kernel make filter.
[23:37] <slangasek> meh
[23:37] <slangasek> try a test build with V=1?
[23:38] <munckfish> V=1?
[23:38] <munckfish> oh verbose i c
[23:38] <slangasek> to tell the kernel make rules to be verbose
[23:38] <slangasek> and show you what they're really doing
[23:39] <munckfish> Yeah I'd like to see that
[23:39] <infinity> slangasek: will a kernel make being run from dpkg-buildpackage pick it up if exported in the shell, or do I need to get to mangling debian/rules in this thing?
[23:40] <slangasek> I have no idea
[23:40] <infinity> Also, a build system that doesn't involve unpacking linux.tar.bz2 would make me less sad.
[23:40] <slangasek> heh
[23:40] <munckfish> infinity: me too
[23:40] <munckfish> there's a lot of untidyness
[23:40] <munckfish> but i left out everything not reqd to just get it to build
[23:40] <munckfish> apologies
[23:40] <munckfish> these things can be addressed in subsequent updates
[23:43] <munckfish> infinity: the call to the build the kernel happens in {source dir}/kboot-11/Makefile line 645 if that helps, trouble is that's the 3rd
[23:43] <munckfish> nested Makefile by the time we've called rules as well
[23:50] <munckfish> cjwatson: this error, it's saying that a 64bit linker isn't available right? Well 'davis' isn't 64 bit so where's it gonna be coming from on that machine?
[23:50] <munckfish> Are we likely just missing another build-dep?
[23:51] <munckfish> but then I used pbuilder with the bare minimum
[23:51] <munckfish> :(
[23:52] <cjwatson> munckfish: davis is running a 64-bit kernel, as it happens ...
[23:53] <cjwatson> I doubt magic cross-linkers would be used automatically though
[23:53] <munckfish> duh stupid me yes it's in that report you made for me earlier
[23:53] <munckfish> (munckfish needs sleep)
[23:53] <munckfish> so that's exactly the same setup
[23:53] <munckfish> :(
[23:54] <infinity> munckfish: As soon as this "hahaha, bzi2 forever!" build system is done failing again, I'll toss a verbose log your way.
[23:54] <infinity> munckfish: Which may or may not be enlightening.
[23:55] <munckfish> infinity: thx, I guess you're referring to the backup upstream makes of the kernel source before patching
[23:55] <infinity> munckfish: http://people.ubuntu.com/~adconrad/ps3-kboot-verbose.log
[23:56] <munckfish> infinity: thx, I'll go analyse it
[23:56] <infinity> "ld -m elf64ppc -m elf32ppclinux ..." looks pretty special to me.
[23:57] <munckfish> yep
[23:58] <munckfish> I just spotted that