[01:24] <wasabi> iwj: Curious about the state of mdadm in the initramfs. I'm personally have some issues (won't work) on feisty with it. Fixed them up by removing most of the code in local-top/mdadm and replacing it with a procedure that always does a full scan to build a config file, and assembles everything. Do you have any plans with regards to this?
[01:36] <owh> I'm trying to fix a bug in gphpedit. I think that the problem is that a parameter being passed is defined as a gint, but expected to be a glong. There are over 300 parameters to check. I'm using dpkg-buildpackage -rfakeroot -uc -b to build the package. How do I get the compiler to tell me of these mismatches?
[01:37] <Burgundavia> owh: try in -motu
[01:37] <owh> Heh, I just came from ubuntu-bugs, but I'll ask. Tah.
[03:34] <Viper550> hello!
[03:36] <jsgotangco> Viper550: wow long time no see
[03:36] <Viper550> Unfortunately, I'm not using any Linux anymore, the hard drive in one of my older computers died, and we had to use my Linux hard drive to get it back up and running
[03:39] <Viper550> Speaking of getting things back up and running, I heard Dell has Ubuntu now. It's old news, but still
[03:40] <Viper550> You know how most newer systems have those recovery partitions and all that jazz?
[03:44] <jsgotangco> yes
[03:45] <jsgotangco> even the dells with ubuntu have those
[03:45] <Viper550> really?
[03:46] <Viper550> But, how does it work? Is it a *ironically* Norton Ghost image or something?
[03:47] <jsgotangco> not sure can't remember, it has does files though
[03:47] <jsgotangco> s/does/dos
[03:48] <Viper550> But, anyway, here's my idea: we should code a system recovery system, a full-featured recovery for Linux system builders, open-source
[07:13] <pitti> Good morning
[07:32] <Hobbsee> hi all
[08:18] <pygi> morning
[08:44] <pitti> Hobbsee: was bug 108870 verified now?
[08:44] <ubotu> Launchpad bug 108870 in kubuntu-default-settings "[Feisty regression]  install two or more debian files with right click on them and install doesn't work" [Low,Fix committed]  https://launchpad.net/bugs/108870
[08:44] <Hobbsee> pitti: not yet.
[08:45] <pitti> Hobbsee: so I assign this to you if you don't mind?
[08:45] <Hobbsee> pitti: herd 2's...when?
[08:45] <Hobbsee> no, that's fine
[08:45] <Hobbsee> oh, and breakfast
[08:46] <pitti> great, so all tribe-2 bugs have assignees now
[08:46] <pitti> Hobbsee: June 28th
[08:46] <Hobbsee> i dont consider kubuntu-team to be an assignee
[08:46] <Hobbsee> right
[08:46] <pitti> Hobbsee: sorry, June 19th
[08:46] <Hobbsee> what???
[08:46] <Hobbsee> oh fudge, i thought it was later
[08:46] <pitti> no, bogus
[08:46] <Hobbsee> okay, will look when i get home.
[08:46] <pitti> June 28th is right
[08:46] <Hobbsee> good.
[08:47] <pitti> July 19th was tribe-3 already
[08:47] <Hobbsee> hehe
[08:47] <Hobbsee> clearly
[08:47] <shawarma> In theory, if someone were to upload a package with this copyright/license (last three lines): http://search.cpan.org/src/CFRANKS/Perl6-Junction-1.30000/README    What would happen?
[08:47] <shawarma> Good morning, by the way :)
[08:48] <pygi> shawarma, I do believe however that you're supposed to add COPYING and stuff then
[08:48] <shawarma> pygi: It's mostly to do with the "All rights reserved" bit.
[08:49] <pygi> shawarma, meh, yea, he claims authorship rights
[08:49] <pygi> every author claims that
[08:49] <pygi> whetever you have that written or not
[08:49] <pygi> (/me has law, had his exam few days ago :P)
[08:51] <Hobbsee> haha
[08:51] <Hobbsee> poor pygi 
[08:51] <pygi> Hobbsee, I'll pass with A even :P
[08:51] <Hobbsee> woo!
[08:51] <Hobbsee> do the rest of my exams then.
[08:51] <pygi> Hobbsee, nah, I'll fail some :P
[08:51] <pygi> Like informatics :p
[08:51] <shawarma> pygi: I see. I was under the impression that that particular statement Conflicts: GPL..
[08:51] <pygi> Hobbsee, but I'll get A from organization :p
[08:51] <pygi> shawarma, IMHO it doesn't.
[08:51] <Hobbsee> heh
[08:51] <pygi> shawarma, I do however think that the package must have COPYING and stuff, otherwise you need to add it
[08:51] <pygi> shawarma, is perl under gpl?
[08:51] <shawarma> pygi: Hm. Yes, I see what you mean.
[08:52] <pygi> shawarma, if possible, just mail the author and tell hjm to remove the line. But what we're talking here are authorship rights, and GPL grants other types of rights:
[08:52] <pygi> material ones, which would be: distribute, say about it (advocate), reproduce (use, whatever), and modify
[08:53] <shawarma> pygi: Ok. Interesting.
[08:53] <pygi> shawarma, what licence is perl?
[08:54] <pygi> Hobbsee, which exams do you have left?
[08:54] <shawarma> pygi: See /usr/share/doc/perl/copyright :)
[08:54] <shawarma> pygi: It's GPL-1 and Artistic.
[08:54] <shawarma> pygi: AFAIR
[08:55] <pygi> GPL1 or later, and Artistic
[08:55] <pygi> got it ^_^
[08:57] <Hobbsee> pygi: maths, electronics
[08:57] <pygi> Hobbsee, I can pass the second one for you ^_^
[08:57] <Hobbsee> oh good
[08:57] <pygi> with pretty good grade I think as well =)
[08:57] <pygi> math I have as well
[09:01] <pygi> shawarma, any more questions? :)
[09:01] <pygi> hey Zdra 
[09:02] <shawarma> pygi: I just took a peek at some existing packages. libtext-format-perl, for instance, has a "all rights reserved" bit in there, and also does not contain a COPYING nor LICENCE file.
[09:02] <Zdra> hello pygi
[09:02] <pygi> shawarma, I really think *every* package has to have that
[09:02] <pygi> shawarma, it isn't connected to that particular bits
[09:03] <shawarma> pygi: I know. I'm just saying. :)
[09:03] <shawarma> pitti: Archive admin question for you:
[09:03] <shawarma> 08:47 < shawarma> In theory, if someone were to upload a package with this copyright/license (last three lines):  http://search.cpan.org/src/CFRANKS/Perl6-Junction-1.30000/README    What would happen?
[09:04] <shawarma> pitti: Also, the package (like many other perl packages, it seems) does not have a LICENSE or COPYING file or anything to that effect.
[09:05] <pygi> Zdra, If I manage to get around this segfault I'll show you something ^_^
[09:15] <pitti> shawarma: that's indeed invalid, and I reject such pacakges
[09:16] <pitti> shawarma: there must be a verbatim copyright text in the orig.tar.gz, and debian/copyright must either point to common-licenses, or also have a verbatim copy, or at least have a pointer to perl's installed copyright file
[09:16] <Zdra> pygi: I'm curious :)
[09:17] <pygi> shawarma, told ya ^_^
[09:20] <lifeless> have a good weekend
[09:20] <pygi> lifeless, same ^_^
[09:26] <pitti> mvo: erk, why does gksu rely on the password prompt for determining whether the password was wrong; shouldn't it be enough to look for 'Sorry, try again.'?
[09:28] <mvo> pitti: it probably should
[09:33] <shawarma> pitti: Ok, thanks.
[09:35] <mvo> pitti: is there a bug open for this already?
[09:36] <pygi> mvo, he's gone :P
[09:36] <dholbach> good morning
[09:36] <pygi> hey daniel
[09:36] <dholbach> hey Mario
[09:53] <pitti> hi Tonio_ 
[09:53] <pitti> Tonio_: do you know how kdesu works? I just found out that it never forgets my password (bug 88580)
[09:53] <ubotu> Launchpad bug 88580 in kdebase "kdesu accept any password" [Critical,Confirmed]  https://launchpad.net/bugs/88580
[09:54] <Tonio_> pitti: yes, kdesu is a mess
[09:54] <pitti> I already grepped my ~ and /tmp, and cannot find my password; where the heck is it stored?
[09:54] <Tonio_> pitti: in fact it doesn't remember the password so asks for it everytime
[09:54] <pitti> Tonio_: well, it asks every time, but it accepts any password
[09:54] <Tonio_> but if you already gave the good password a few minutes ago, a bad password will be accepted
[09:55] <pitti> Tonio_: but if I quit the desktop session, kill -15 -1, and log in again, it should be gone for good
[09:55] <pitti> and it isn't
[09:55] <Tonio_> pitti: I wouldn't consider this a security issue as a bad password is accepted when it shouldn't ask for a password
[09:55] <Tonio_> pitti: here is the point : http://www.launchpad.net/kdesudo
[09:56] <pitti> Tonio_: right, but the point is, it should ask for a password if I never entered it at all
[09:56] <Tonio_> pitti: a project I and other guys are working on to replace kdesu for gutsy
[09:56] <pitti> and after sudo -K and everything
[09:56] <Tonio_> pitti: that works better but needs improvement to replace kdesu fully (kcontrol etc...)
[09:56] <Tonio_> pitti: if we succeed, there is a plan to make a class for kdelibs to make it to work correctly with sudo
[09:56] <shawarma> pitti: Perhaps kdesu doesn't use sudo as a backend, but implements it itself?
[09:57] <Tonio_> pitti: but that'll take time..... kdesu is very complex, there is no easy way to fix it, except replace the code
[09:57] <Tonio_> pitti: so the current plan is to replace kdesu in gutsy, hope we succeed
[09:58] <Tonio_> pitti: kdesudo already works correctly, just has problems when called within a kcm module, since it misses a few command line options
[09:58] <pitti> Tonio_: ah, I see, I still had a sudo stamp for it, so sorry for panicking; that apparently survives logout
[09:59] <Tonio_> pitti: well yes, the way kdesu works with sudo is a bit hackish....
[09:59] <Tonio_> pitti: if you're interested in kdesudo, I'd appreciate your opinion reguarding the code concerning the security, as it'll have to go through the MIR process :)
[10:00] <pitti> at least I'm calmed down now again, seems it doesn't store my password anywhere :)
[10:00] <Tonio_> pitti: hehe :)
[10:00] <Tonio_> pitti: kdesu doesn't, indeed
[10:00] <Tonio_> it just asks for your passwords, then calls for sudo that doesn't require your password, so the bad password succeeds
[10:01] <Tonio_> evil isn't it ? ;)
[10:03] <Tonio_> pitti: btw kedsu will of course fail with any kind of custom sudoers file, for example if you want to give a simple user a "nopasswd" access to one command only
[10:03] <Tonio_> pitti: that's one of the many problems we have with it...
[10:04] <Tonio_> Lure: hey ;)
[10:04] <Tonio_> Lure: you know c++ right ? ;)
[10:06] <Lure> Tonio_: right
[10:07] <shawarma> pitti: It's amazing. I've pulled out 10 lib*-perl packages at random to see how they've done their COPYING or LICENSE or whatever they'd felt like calling it.. *None* of them had one.
[10:08] <shawarma> pitti: It seems libgnome2-perl has one, but that's only GPL-2 (not the usual "same terms as perl itself").
[10:08] <Tonio_> Lure: we need people to help on the kdesudo part, which is important for gutsy :)
[10:08] <Tonio_> Lure: interested joining the team ?
[10:09] <Lure> Tonio_: I can look into this, but has very limited time in next couple of weeks
[10:09] <Tonio_> Lure: sure :)
[10:09] <Tonio_> Lure: well it is pretty advanced now, the currently point is to add all the command line options kdesu has, to make the replacement easy
[10:10] <Tonio_> Lure: you should joint the team on the launchpad project page :)
[10:10] <Lure> Tonio_: can you write down in e-mail what is there and what is to be done?
[10:10] <Tonio_> Lure: will do thanks
[10:11] <pitti> shawarma: yeah, that stuff is a mess; I wonder how all that passed Debian NEW
[10:12] <shawarma> pitti: No idea. 
[10:19] <Mirv> mdke_: hi, what about ubuntu-docs updates for Ubuntu 7.04? (https://lists.ubuntu.com/archives/ubuntu-translators/2007-March/001039.html)
[10:20] <Mirv> ("we will ensure that we do translation updates during the life of Ubuntu 7.04)
[10:21] <pitti> mvo: hm, I just looked into libgsku, doesn't seem to be that easy; do you know that code?
[10:21] <mvo> pitti: a bit
[10:22] <pitti> mvo: I'd like to upload http://people.ubuntu.com/~pitti/tmp/sudo.8556.debdiff, but that currently breaks gksu (it doesn't notice wrong passwords and just exists)
[10:23] <mvo> pitti: out of curiosity, does it work when you give it a message without a space in it?
[10:24] <pitti> mvo: oh, I don't know, let me try
[10:25] <pitti> mvo: hmm, there's a g_strsplit() in the su handler, but not in the sudo one
[10:26] <pitti> mvo: indeed, that works
[10:26] <pitti> mvo: [sudo] _password_for_martin:  -> that works
[10:26] <pitti> mvo: [sudo]  password for martin:  -> breaks
[10:29] <mvo> pitti: I do not have the code in front of me currently, but I do remember that there is a lot of parsing and ugliness. I wish there was a simple protocol to talk to sudo
[10:30] <mvo> pitti: the trouble is that the current approach does e.g. not work with callange-response authentication methods in gksu
[10:32] <cjwatson> pitti: err, practically every perl module in existence has that boilerplate licence statement
[10:32] <cjwatson> pitti: are you going to reject several hundred packages from the archive?
[10:33] <cjwatson> pitti: it's entirely standard and well-understood in the Perl world
[10:33] <pitti> cjwatson: not from the archive of course, but I do reject such packages from NEW
[10:33] <cjwatson> shawarma: I would accept that provided that debian/copyright clarifies
[10:33] <cjwatson> that is standard practice
[10:33] <shawarma> cjwatson: Remind me to upload on you archive-admin day, then :)
[10:33] <pitti> cjwatson: we essentially distribute orig.tar.gz's without any license at all
[10:33] <cjwatson> pitti: we really don't, it's completely clear
[10:33] <cjwatson> "under the same terms as Perl itself" is a licence
[10:33] <pitti> 'the perl license' is not a license, and it's not even a fully qualified pointer to a license
[10:34] <cjwatson> it may be a licence by reference, but it is a licence
[10:34] <cjwatson> it says that if the licensing of Perl changes then the licensing of this package does too *shrug*
[10:34] <pitti> it's not even clear that it is "perl, the programming language" instead of "perl, the hackish scirpt that pitti distributes on his homepage
[10:34] <cjwatson> oh, come on
[10:34] <pitti> cjwatson: right, but we are talking legalese here...
[10:34] <shawarma> It's quite amazing. Out of 122 packages whose README has "same terms as" somewhere in it, only 10 packages have either a COPYING or LICENSE file.
[10:35] <cjwatson> it's totally obvious in the field, and I claim that any judge would agree with me
[10:35] <cjwatson> legalese does not have to be code
[10:35] <pitti> cjwatson: with common sense I agree to you, but with common sense we wouldn't need to be so picky about all the source new checking
[10:35] <pitti> cjwatson: so, of course I won't make a fuss about all the existing perl modules
[10:35] <cjwatson> we have so many examples of this that it should be grandfathered anyway
[10:35] <pitti> cjwatson: but there has been stuff in source new which was similar and refered to less prominent projects
[10:36] <pitti> and for new Ubuntu specific packages I just don't accept it
[10:36] <cjwatson> if you go and ask a Perl module upstream to change this they'll look at you like you were insane
[10:36] <cjwatson> because it is *not* *unclear*
[10:36] <cjwatson> I agree it needs to be clarified in debian/copyright, but really, that's all it should take
[10:37] <pitti> cjwatson: IMHO debian/copyright is much less important
[10:37] <pitti> we need to have a license for distributing the tar.gz; a pointer to perl in debian/copyright is fine since within a distro we know what perl is
[10:38] <cjwatson> within the IT industry we know what perl is
[10:38] <cjwatson> I think it is specious to claim otherwise, honestly
[10:38] <pitti> cjwatson: I already said that I won't make a fuss about perl
[10:38] <cjwatson> particularly since there is no other consistent referent; it is obvious that the software is designed to work with Perl, the programming language
[10:38] <pitti> but I did reject stuff that refered to less common projects and which was ubuntu specific
[10:55] <pitti> zakame: xmms2 FTBFSed on amd64, can you please have a look? I let it sit in the NEW queue for now
[11:06] <Tonio_> seb128: ping ?
[11:07] <seb128> Tonio_: hi
[11:07] <Tonio_> seb128: hi ;)
[11:08] <Tonio_> seb128: I'm attempting to package nm 0.6.5, we need it for kubuntu/knetworkmanager
[11:08] <pitti> Tonio_: great!
[11:08] <Tonio_> seb128: the gnome applet has been splitted from the source code, which means new package, revu process etc...
[11:08] <seb128> Tonio_: I'm happy to do it
[11:08] <Tonio_> seb128, pitti: is the complete process required, cause that'll take a lot of time to get the new package in
[11:09] <seb128> Riddell: I don't, I've no account there and I don't intend to create one
[11:09] <Riddell> although I can NEW it now :)
[11:09] <pitti> Tonio_: *shrug* for my sake just upload it, and we'll review it in NEW
[11:09] <seb128> I get dholbach usually to add comments for me there :p
[11:09] <seb128> well
[11:09] <Tonio_> pitti: okay
[11:09] <ogra> does anyone know from the top of his head where i can adjust the keepalive time for tcpd ?
[11:09] <seb128> don't upload a n-m which drops the applet before packaging the new one
[11:10] <pitti> Tonio_: as long as it's a standard /usr/share/cdbs/1/class/gnome.mk package without much fuss and works, it shouldn't be too bad
[11:10] <Tonio_> seb128: of course, I'm not that stupid hehe ;)
[11:10] <Tonio_> I'll upload them at the same time
[11:10] <Tonio_> probably with the new knetworkmanager too
[11:10] <Tonio_> pitti: okay same process than with kde packaging in fact
[11:10] <pitti> seb128: why, the deb won't disappear automatically
[11:11] <Tonio_> pitti: the applet might not be compatible, 0.6.5 is a major change
[11:11] <pitti> Tonio_: ^ you can upload them independenty *as long* as they do not break the nm-applet <-> n-m daemon ABI
[11:11] <seb128> pitti: does the old applet work with the new version?
[11:11] <pitti> Tonio_: right, that's what I was aiming at
[11:11] <pitti> seb128: nevermind, see above
[11:11] <seb128> right
[11:11] <Tonio_> seb128: adunno at the moment
[11:11] <Tonio_> seb128: what I know is that the new applet won't work with the old backend
[11:12] <pitti> Tonio_: ok, so please uplaod the new gnome pkg first, with a strict enough dependency to network-manager
[11:12] <Tonio_> but as ascending and descending compatiblity are not the same problem, that might work, indeed
[11:12] <Tonio_> pitti: okay
[11:12] <pitti> if old applet works with new daemon, that's good
[11:13] <Tonio_> pitti: well I may have the new daemon package available soon, I might ping here for people to test
[11:13] <pitti> I'm glad to help with testing
[11:13] <seb128> I can do testing as well
[11:13] <Tonio_> great, thanks ;) I'll test the kde part
[11:14] <Tonio_> it's also important to test the vpn plugins....
[11:14] <Tonio_> I don't have any sisco router to test vpnc, but I can test the openvpn part
[11:14] <pitti> can't help with that, sorry
[11:15] <seb128> me neither
[11:17] <shawarma> cjwatson: The error message says that g_thread_init should be called before *any* other glib call..
[11:17] <cjwatson> am I supposed to add gobject.threads_init() to the top of my program?
[11:18] <cjwatson> shawarma: it does, but the documentation says "Before you use a thread related function in GLib"
[11:18] <pitti> that's what I see for gksu as well
[11:18] <pitti> but it seems to only be a warning and relevant if you use it at all
[11:18] <shawarma> seb128: You seemed to know somethings about that? (the g_thread_init error thing)
[11:19] <cjwatson> pitti: well, ubiquity's segfaulting, which is kinda hard for a python program, so *something's* wrong :)
[11:19] <pitti> cjwatson: some gtk library probably uses it?
[11:19] <slomo> cjwatson: even import gtk; or import pygtk; will call glib functions so you can't call it as first glib function in python
[11:19] <shawarma> slomo: Then *they* should call it.
[11:19] <seb128> there is some discussions upstream
[11:19] <seb128> http://bugzilla.gnome.org/show_bug.cgi?id=331853
[11:19] <ubotu> Gnome bug 331853 in general "Handle using gslice before g_thread_init() better" [Normal,Reopened]  
[11:19] <slomo> shawarma: see the comments on the upstream bugreport and the list discussion :)
[11:19] <seb128> you can call g_thread_init() as a workaround for now
[11:20] <seb128> http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00005.html also
[11:21] <cjwatson> so, that's from January and reportedly breaking our installer in June, so I need to consider whether a workaround is available
[11:23] <seb128> cjwatson: yeah, we just upgraded to glib 2.13 some weeks ago
[11:23] <seb128> call g_thread_init() at the start of your program to fix it
[11:36] <cjwatson> seb128: sadly, http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00035.html indicates that I cannot, because I call setlocale at various points through the program
[11:36] <pkern> Any Ubuntu sysadmin in here, familiar with the Sobby instance Ubuntu hosts?
[11:36] <cjwatson> though I guess if I never *create* threads ...
[11:38] <Tonio_> seb128: there is a fixed kio-umountwrapper waiting for you in new, if you have a moment
[11:38] <Tonio_> seb128: we need a MIR fo this for kubuntu, so it'd be nice to have people testing this in universe a bit before ^^
[11:38] <blackskad> cjwatson: don't you create a new thread every time you call gtk.main? (just a guess...)
[11:39] <seb128> Tonio_: will look into it
[11:39] <Riddell> pkern: #canonical-sysadmin
[11:40] <pkern> Riddell: Thanks.
[11:40] <Tonio_> seb128: many thanks
[11:40] <seb128> you're welcome
[11:42] <cjwatson> blackskad: my understanding may be lacking, but I didn't think so. For example, the documentation of g_main_depth says "The main loop recursion level in the current thread" which implies that main loop recursion doesn't create threads
[11:43] <pygi> cjwatson, it shouldn't
[11:51] <cjwatson> slomo: 'import gobject; gobject.threads_init(); import pygtk' would be fine though, wouldn't it?
[11:52] <slomo> cjwatson: no idea
[11:53] <cjwatson> slomo: actually, pygtk is fine; look at the module, it doesn't import gtik
[11:53] <cjwatson> gtk
[11:57] <seb128> cjwatson: do you use gnome-vfs or something that could make use of it like gtk fileselector?
[11:57] <seb128> because it's multi-threaded
[11:58] <seb128> cjwatson: I'm not sure that setlocale is really a problem
[11:58] <pitti> seb128: bug 106350 was handled in an SRU, but the gutsy task is still open; can that be closed?
[11:58] <ubotu> Launchpad bug 106350 in metacity "Metacity crash corrupts future Gnome sessions" [High,Confirmed]  https://launchpad.net/bugs/106350
[12:00] <seb128> pitti: closed
[12:00] <pitti> seb128: likewise for bug 107484
[12:00] <ubotu> Launchpad bug 107484 in control-center "Launch Music Player should be mapped to KEY_MEDIA (0xed in X)" [Low,Confirmed]  https://launchpad.net/bugs/107484
[12:01] <pitti> siretart: can bug 104332 be closed in gutsy? (I think so, but I'd like to make sure)
[12:01] <ubotu> Launchpad bug 104332 in rdesktop "Segmentation Fault (core dumped)" [Undecided,Fix committed]  https://launchpad.net/bugs/104332
[12:02] <pitti> siretart: it was fixed in an SRU for feisty already
[12:02] <seb128> pitti: closed as well
[12:02] <pitti> thanks Seb!
[12:02] <seb128> you're welcome
[12:02] <pygi> seb128, you're getting a lot of thanks today :p
[12:03] <seb128> ;)
[12:05] <Tonio_> pitti, seb128: http://tonio.homelinux.org/temp
[12:05] <pygi> seb128, mhm, let me ask you one question, so you can earn one more :)
[12:05] <Tonio_> pitti: new NM packages, untested, so if you want to check the old applet compatibility..... it's there
[12:05] <pygi> seb128, how sane is it to patch brasero so we'd update language pack for baltix folks?
[12:05] <seb128> pygi: what do you mean?
[12:06] <pygi> seb128, well, baltix folks contacted me that translation to lithuanian (fix my spelling pls!) is a bit broken, and wondered whetever I could introduce a patch in the package
[12:06] <seb128> Tonio_: no new kio-umountwrapper in the queue
[12:06] <pygi> jdong, poke
[12:09] <Tonio_> seb128: hu ? pitti removed the old ones yesterday
[12:09] <seb128> the only one in the queue is 7 days old
[12:09] <ompaul> orga got a momemnt?
[12:09] <pitti>   225218 | S- | kio-umountwrapper    | 0.3-0ubuntu1         | seven days
[12:09] <ompaul> moment even 
[12:09] <pitti> Tonio_: that's the most recent one
[12:09] <Tonio_> seb128: okay can you drop that all ? I'll upload the new one after that
[12:09] <pitti> Tonio_: done
[12:09] <seb128> no need to drop anything you can just upload
[12:10] <Tonio_> pitti: maybe my yesterday's upload didn't reach NEW
[12:11] <Tonio_> seb128: uploaded, should be in NEW
[12:13] <seb128> Tonio_: no
[12:13] <pitti> not yet, in 2 minutes
[12:13] <pitti> (packages are accepted every five minutes)
[12:13] <Tonio_> oki
[12:13] <pitti> seb128: xdg-user-dirs binary-NEWed
[12:13] <seb128> pitti: danke
[12:13] <seb128> pitti: you will get a MIR for it soon ;)
[12:16] <shawarma> ompaul: You may have more luck if you also spell "ogra" correctly :)
[12:17] <ompaul> shawarma: there is that ;-) there is always that 
[12:17] <ompaul> ogra got a momemnt?
[12:17] <ompaul> hahaa
[12:24] <cjwatson> seb128: gnome-vfs> no
[12:29] <seb128> Tonio_: kio-umountwrapper accepted
[12:30] <cjwatson> pitti: bug 114296 is an interesting point. Does restricted-manager write out a list of the packages it installs anywhere?
[12:30] <ubotu> Launchpad bug 114296 in ubiquity "running restricted-manager before installation can break system" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114296
[12:31] <cjwatson> note that ubiquity copies the live session's xorg.conf to the installed system
[12:32] <pitti> cjwatson: right, I was just going to ask you about that
[12:32] <pitti> ATM it doesn't write out a list, it has those hardcoded in the per-module handlers
[12:34] <pitti> cjwatson: if we want to make this work, I could add a small script that prints out that list
[12:34] <pitti> cjwatson: it's easy to write, it's just hackish and doesn't fit into the main restricted-manager binary
[12:34] <Tonio_> seb128: super, merci !
[12:35] <seb128> de rien
[12:35] <pitti> cjwatson: right, or just put the list of installed packages in some log file if you prefer that
[12:35] <cjwatson> pitti: maybe something that prints out the list of packages that would need to be installed in order to fit the current configuration (disclaimer: I have never looked at restricted-manager)
[12:35] <cjwatson> pitti: a log file could be trickier if restricted-manager were run multiple times
[12:36] <pitti> cjwatson: right, let's call it 'status file'
[12:36] <pitti> cjwatson: but that's specific to X.org drivers anyway, right?
[12:36] <pitti> since we don't copy other files, such as installed firmware bits
[12:37] <cjwatson> no, though we should carry over the list of packages you requested in restricted-manager anyway
[12:37] <cjwatson> and what we copy now isn't necessarily exactly what we ought to copy ...
[12:37] <cjwatson> pitti: I've created a bug task on r-m
[12:38] <pitti> cjwatson: ATM, writing the list of installed packages is identical to list of installed X.org driver packages, but that will change soon
[12:39] <pitti> an interesting use case is e. g. installing the vmware guest tools into a running live system in vmware
[12:39] <pitti> (we don't have them yet, but that was the idea)
[12:39] <pitti> cjwatson: so, that's easy to maintain as well, just a different function in the code
[12:39] <pitti> cjwatson: something like /var/cache/restricted-manager/installed-packages ?
[12:43] <pitti> cjwatson: bug updated and milestoned
[12:47] <cjwatson> pitti: in fact, there's an even neater option
[12:48] <cjwatson> pitti: restricted-manager could ship a hook script in /usr/lib/ubiquity/target-config/ that just does whatever's necessary
[12:48] <pitti> cjwatson: indeed
[12:48] <cjwatson> pitti: it can call 'apt-install <package>' (note: *not* a typo for 'apt-get install') to ensure that <package> remains installed
[12:48] <cjwatson> or is installed off the CD
[12:49] <pitti> cjwatson: I like that, avoids special-casing ubiquity for r-m
[12:49] <cjwatson> yeah, and avoids needing to create another interface
[12:49] <pitti> cjwatson: files in there are just executables? or are there any other form requirements?
[12:50] <pitti> cjwatson: i. e. could it be a Python script? 
[12:51] <cjwatson> pitti: arbitrary executables; you can query the debconf database, but please don't use INPUT or GO; it doesn't check exit code at the moment, but please exit 0 on success obviously
[12:51] <pitti> right, no need for debconf for me
[12:51] <cjwatson> oh and since it's connected to debconf please don't output stuff to stdout
[12:51] <pitti> good point, thanks
[12:51] <ompaul> 3
[12:51] <cjwatson> stderr is fine and will end up in syslog
[12:52] <cjwatson> I'll update the bug
[12:52] <pitti> (already doing so)
[12:52] <cjwatson> pitti: go ahead then, please reject the ubiquity task
[12:53] <pitti> done; I think I noted everything important
[12:53] <pitti> cjwatson: apt-install is just in $PATH in the context of those scripts?
[12:55] <cjwatson> pitti: yeah
[12:55] <cjwatson> it's in /usr/lib/ubiquity/compat but that's an internal detail
[12:56] <siretart> pitti: oh, you're right. closing it now!
[12:56] <dholbach> doko: do you have any idea about  http://daniel.holba.ch/temp/glom.ftbfs ?
[12:56] <pitti> siretart: thanks
[12:57] <cjwatson> pitti: note that it won't be able to install packages from the network, though
[12:57] <cjwatson> just stuff on the livefs or on the apt archive on the CD
[12:57] <StevenK> % grep -c '[12:57] <StevenK> 540
[12:57] <pitti> cjwatson: hm, good point; I just call synaptics ATM
[12:58] <shawarma> StevenK: Which package?
[12:58] <pitti> cjwatson: however, it shouldn't matter, I think; you cannot activate e. g. fglrx on the live system for the same reason
[12:58] <dholbach> StevenK: what's the problem with the patch?
[12:58] <pitti> cjwatson: I'll look at that
[12:59] <StevenK> shawarma: cyrus-imapd-2.2
[12:59] <StevenK> dholbach: It's from a MoM-merge. Evidently, Debian changed it again.
[01:00] <dholbach> StevenK: if those patches break, it's usually a matter of     rm debian/patches/99-update-autoconf.dpatch; cdbs-edit-patch 99-update-autoconf ... autoconf; rm -r autom4te.cache ... - so not that bad, no?
[01:00] <StevenK> dholbach: I think this patch actually updates configure.in as well, so it gets a little painful.
[01:01] <dholbach> hrm
[01:01] <dholbach> that's why we usually split those patches
[01:02] <StevenK> Actually, it doesn't. Excellent.
[01:04] <pitti> mvo!
[01:04] <pitti> mvo: can you please upload a new compizconfig-settings-manager with Arch: s/any/all/?
[01:05] <mvo> pitti: *cough* sure
[01:05] <pitti> mvo: 'k, rejecting the current one then; it's fine otherwise
[01:05] <pitti> mvo: (so please reuse the version number)
[01:08] <mvo_> pitti: thanks, new version uploaded
[01:10] <pitti> mvo_: it doesn't, usually that's a horribly broken debian/rules clean
[01:10] <pitti> I saw packages which need some five minutes to clean just because they think they need to run configure for that
[01:11] <StevenK> pitti: I'm over here. :-P Yeah, I found it. clean-patched depends on configure for some screwed reason.
[01:11] <pitti> whoops, sorry :)
[01:31] <doko> dholbach: not at first sight
[01:45] <shawarma> Um, how does the new ifrenaming stuff work? I've a machine whose only interface comes up as eth1, but since we don't use /etc/iftab anymore, I'm a bit lost.
[01:46] <fabbione> shawarma: /etc/udev/rules.d
[01:46] <fabbione> grap there for the mac address
[01:46] <fabbione> there are autogenerated rules for that
[01:46] <shawarma> fabbione: Aw, crap.
[01:46] <shawarma> fabbione: Thanks, though!
[01:47] <fabbione> it's funny to see udev fighting with itself when you have 2 interfaces with the same mac address :)
[01:48] <shawarma> Ok, so now I get how it figures out which interface should have which name. How does it actually do it? ifrename is missing, it seems.
[01:50] <fabbione> shawarma: apt-get source udev ?
[01:50] <fabbione> it's probably naturally coded in there rather than using yet another external program
[01:51] <shawarma> Ok, so if I'm too lazy to reboot, my only hope is to reload the driver and have udev detect it again?
[01:51] <fabbione> that will do
[01:51] <fabbione> rmmod modprobe will do
[01:52] <shawarma> Only problem is that the driver is not a module (it's inside user-mode-linux).
[01:52] <shawarma> Oh, well.
[02:23] <shawarma> asac: I'm not getting any video on youtube with the gnash plugin?
[02:23] <asac> shawarma: does gnash start?
[02:23] <shawarma> asac: I got sound?
[02:24] <asac> oh ... happens on any video?
[02:24] <shawarma> Um... havent' tested all of them :) But all that I've tested, yes.
[02:24] <asac> you have a link so i can verify that it works here?
[02:24] <shawarma> For a split second, I see a grey area that seems to have the correct size, but then it disappears.
[02:25] <shawarma> http://www.youtube.com/watch?v=nYM__s3R5q0
[02:25] <asac> oh you even don't see a grey area? .. no 'flash' area at all?
[02:25] <shawarma> asac: No, just white.
[02:26] <shawarma> asac: It's been a week or so since I did a full upgrade, could that mean anything?
[02:26] <asac> hmm ... usually not, but i am unsure what latest gtk brought so maybe try
[02:27] <shawarma> asac: Will do.
[02:29] <asac> shawarma: do opengl apps otherwise work for you?
[02:30] <shawarma> asac: glxgears work like a charm
[02:31] <asac> and mplayer with opengl as well?
[02:31] <sn0> shawarma there was a new ver of gnash, just incase you aren't aware
[02:31] <shawarma> asac: Yup.
[02:31] <sn0> http://www.miriamruiz.es/weblog/?p=68 fyi
[02:31] <asac> asw: 
[02:31] <asac> ups
[02:32] <sn0> it mentions the gstreamer packages required for youtube browsing
[02:32] <shawarma> sn0: Yes, I believe that's what asac packaged?
[02:32] <asac> sn0: i think shawarma is testing my upload :)
[02:32] <sn0> oh my apologies then :-)
[02:32] <asac> yes my upload superseeds that one
[02:32] <sn0> thanks for the upload asac 
[02:32] <asac> i uploaded to debian the same without easy-codec feature
[02:33] <asac> but i think it will be in NEW until after debconf
[02:33] <shawarma> asac: Just a sec... which version of the plugin am I supposed to be looking at?
[02:33] <asac> shawarma: what do you get on console?
[02:34] <asac> 0.8.0... something
[02:34] <asac> shawarma: if you didn't install today then ;)
[02:34] <asac> ...
[02:34] <shawarma> 0.8.0~cvs20070611.1016-1ubuntu2 ?
[02:34] <asac> yes
[02:34] <asac> thats the one
[02:36] <shawarma> asac: Nothing on the console..
[02:36] <asac> nothing?
[02:36] <asac> thats wierd
[02:36] <asac> you sure that you use gnash in firefox? take a close look at about:plugins
[02:37] <shawarma> It's gnash alright.
[02:37] <shawarma> asac: Hm... gimme a sec.
[02:37] <sn0> must try this new gnash also, would be nice to get rid of adobe 
[02:38] <asac> sn0: its actually better than i expected
[02:38] <asac> :)
[02:38] <shawarma> asac: Uargh..  Just updated gstreamer packages. Now I get huge amounts of alsa stuff.
[02:39] <sn0> \o>
[02:39] <asac> shawarma: oh ... maybe thats my bad
[02:39] <shawarma> asac: Uh!
[02:39] <shawarma> asac: It works.
[02:39] <asac> naturally 
[02:39] <shawarma> asac: :-P
[02:39] <asac> please try easy-codec as in mail
[02:39] <asac> :)
[02:40] <shawarma> asac: Updating gstreamer and rebooting firefox helped.
[02:40] <sn0> how is the cpu usage with it shawarma / asac ?
[02:40] <shawarma> asac: Wtf?!??
[02:40] <shawarma> asac: Um.. Now it's back to adobe? How did that happen?
[02:43] <shawarma> asac: Um.. It works now. I must be an idiot.
[02:43] <shawarma> asac: Is the preference option in the menu supposed to bring anything up?
[02:44] <xxxxx1> anyone here have experience with ia64?
[02:45] <xxxxx1> the buildd log of my package on ia64 fails due to -m64 not being recognized.
[02:50] <asac> shawarma: yes, the menu appears to be not bound to any action (except Quit)
[02:51] <shawarma> asac: Alright.
[02:51] <shawarma> asac: Well, it seems to work on youtube now, at least. Break.com seems to not be so grand, though.
[03:05] <pitti> whoops, shit; I forgot NOMAILS for the autosync run
[03:05] <pitti> sorry for the bug spam
[03:05] <pitti> s/bug/-changes/
[03:05] <StevenK> pitti: Just out of interest, did the autosync pull across Linda?
[03:06] <pitti> StevenK: just flushed, can't say any more, but you'll see it on -changes
[03:06] <pitti>   17 N   15.06.07 15:03 Ubuntu Installer  Accepted linda 0.3.25 (source)
[03:06] <StevenK> Yay
[03:06] <StevenK> Thanks.
[03:07] <Hobbsee> hiya pitti 
[03:07] <Hobbsee> pitti: NOMAILS?
[03:07] <Hobbsee> who gets mails for it anyway?
[03:07] <pitti> Hobbsee: to not send mails to -changes for autosyncs
[03:07] <Hobbsee> ahhh
[03:07] <seb128> pitti: did you sync purple-plugin-pack on Debian?
[03:07] <pitti> seb128: yes?
[03:08] <seb128> k, just weird to have it under dholbach's name when it should be autosynced
[03:08] <pitti> seb128: he requested the sync in a bug
[03:08] <pitti> seb128: maybe it was too new for the last autosync run
[03:09] <seb128> I know about the bug; I've ignored it waiting for the next autosync run ;)
[03:09] <seb128> I'm wondering if anybody does new package synced while Tollef is not there though
[03:09] <seb128> s/synced/syncing
[03:12] <soc> hi
[03:12] <soc> does someone know where the xserver-xorg-video-avivo driver is?
[03:13] <mjg59> soc: FTBFS. I'm looking into it.
[03:14] <Tonio_> pitti, seb128: just a bit of polishing/documentation concerning the patches and nm 0.6.5 should be available
[03:14] <soc> ah thx
[03:14] <seb128> rock on
[03:14] <soc> i would be really really happy to throw this frglrx crap out ...
[03:16] <soc> is there somewhere a page with server logs to see why the avivo build failed?
[03:16] <soc> is there already a decision on how avivo will be used among radeon and fglrx?
[03:16] <pitti> soc: https://launchpad.net/ubuntu/+source/xserver-xorg-video-avivo/0.0.1-0ubuntu2, click on the architecture
[03:17] <StevenK> Looks like a missing Build-Depends on autotools-dev.
[03:18] <soc> configure: error: cannot run /bin/bash ./config.sub ...
[03:18] <soc> mhh
[03:18] <soc> or maybe a bash/dash incompatibility?
[03:18] <mjg59> StevenK: config.sub is not a symlink
[03:18] <soc> mh no, it seems to use bash explicitely ...
[03:19] <StevenK> mjg59: Actually, the build rm -f config.{guess,sub} and then ./configure tries to execute config.sub
[03:19] <mjg59> Oh, so it does
[03:19] <mjg59> How the hell did that build in my chroot?
[03:19] <Hobbsee> chroot on crack.
[03:20] <StevenK> That's between you and your chroot. :-P
[03:20] <mjg59> It was a fresh pbuilder
[03:20] <Hobbsee> pbuilder on crack, then.
[03:22] <soc> when can we expect a corrected upload?
[03:22] <soc> someone on it?
[03:22] <mjg59> About 5 minutes?
[03:23] <soc> ok cool
[03:23] <soc> thx
[03:23] <soc> how do these build servers work?
[03:24] <soc> how much time does elapse between upload and build?
[03:24] <pitti> soc: source needs to get published first, which happens every hour
[03:24] <soc> ah ok
[03:25] <pitti> soc: everything that is uploaded until :00 gets published at :35
[03:25] <soc> so in 35 minutes?
[03:25] <soc> ah ok
[03:25] <pitti> no, build will start in ~ 1 hour
[03:25] <cjwatson> soc: that's when the source gets published, and then at minimum another hour to build and publish the resulting build
[03:25] <soc> ah ok
[03:26] <soc> is there a specific reason that it doesn't gt published immediately?
[03:26] <StevenK> cjwatson: Got a tick for a PM?
[03:27] <cjwatson> StevenK: sure
[03:29] <soc> ok thanks to everyone for the information
[03:30] <mjg59> Ok, uploaded
[03:30] <mjg59> Should be fine now
[03:30] <soc> thx mjg59
[03:31] <soc> is it necessary to update the xserver to 1.3 to install avivo?
[03:33] <soc> i had to pin 1.3 because the fglrx driver don't work
[03:33] <soc> s/don't/doesn't
[03:34] <mjg59> I don't think we use any 1.3 API
[03:34] <mjg59> But it's been built against 1.3, so it's possible
[03:34] <sabdfl> hey Hobbsee
[03:34] <Hobbsee> :)
[03:34] <sabdfl> hi mjg59
[03:34] <soc> ok thanks
[03:34] <soc> another question:
[03:34] <mjg59> Also, if you have an X1650 or later this isn't going to work yet
[03:34] <mjg59> The init code still doesn't handle them fully
[03:34] <soc> which driver will be used for ipw3945?
[03:35] <soc> ok, i have a x1400
[03:35] <soc> i'll report back
[03:35] <mjg59> soc: If it's stable enough, iwlwifi
[03:35] <soc> after i installed avivo
[03:35] <soc> ok, that sound sgood
[03:35] <mjg59> Right now it's still about as stable as a drunk one legged man on a ship
[03:35] <soc> parts of dscape were already introduced in feisty, ewren't they?
[03:35] <Hobbsee> mjg59: iwlwifi?
[03:35] <soc> ah ok
[03:36] <soc> is iwlwifi currently used?
[03:36] <mjg59> Hobbsee: Yeah
[03:36] <soc> because my wireless doesn't work anymore :-)
[03:36] <mjg59> soc: Not sure, I haven't checked yet
[03:36] <mjg59> Quite possibly
[03:36] <StevenK> mjg59: During a storm? :-)
[03:36] <mjg59> Since it's hit mainline
[03:36] <mjg59> Hobbsee: Oh, sorry - intel wireless lan driver
[03:37] <mjg59> 3945 and 4965 support
[03:37] <Hobbsee> oh right.  
[03:37] <Hobbsee> neat.  a free one, presumalyb?
[03:37] <mjg59> Yes
[03:37] <Hobbsee> woo!  :)
[03:37] <mjg59> ipw3945 needs the non-free daemon and doesn't drive 4965
[03:37] <soc> without binary userspace regulator ...
[03:37] <Hobbsee> yep
[03:37] <mjg59> On the other hand, it works - something that iwlwifi doesn't handle so well
[03:38] <soc> hope it will be stable, so we can remove the ipw3945 driver
[03:38] <soc> what about 2200/2100? are there any plans yet?
[03:39] <soc> e. g. to port them to the new api or is this not a top priority as long as it works?
[03:40] <mjg59> soc: There's no real reason to port them to the new API
[03:40] <mjg59> They'll need to be ported to the new config API at some stage, but that's about it
[03:41] <soc> ah ok
[03:54] <soc> what about building packages with dh_make?
[03:54] <soc> is this different?
[03:54] <soc> sorry, wrong window ...
[04:00] <lool> Mithrandir: Heya; I see you did some bluez-utils updates; does the org.bluez.serial.Manager DBus interface work for you in newer versions?  Can you list devices with obex:/// in nautilus?
[04:01] <Hobbsee> lool: he's on leave
[04:02] <lool> Oh
[04:02] <lool> Ok, thanks
[04:02] <dholbach> lool: did you pair your phone with your machine?
[04:03] <dholbach> lool: did you restart nautilus?
[04:03] <dholbach> lool: which bluez-utils version do you have?
[04:08] <lool> dholbach: The phone works with obex://[]  urls
[04:08] <lool> dholbach: I have bluez-utils 3.11-0ubuntu1
[04:08] <Tonio_> seb128: http://tonio.homelinux.org/temp
[04:08] <dholbach> lool: hum, what's the problem?
[04:09] <Tonio_> seb128: all n-m 0.6.5 is there, a few patches not applied, documented in the changelog
[04:09] <lool> dholbach: obex:/// is empty and the test case python script for serial devices doesn't work for me
[04:09] <Tonio_> seb128: I'd like someone to confirm it basically works before uploading ;)
[04:09] <lool> Looking at the code, I don't understand how it's ever going to really start a subservice, but well
[04:09] <Tonio_> if someone here wants to help on testing....... I don't have or use gnome so.....
[04:10] <lool> dholbach: I've read http://blogs.gnome.org/jamesh/2007/06/11/obexftp-changes/ and expected obex:/// to work, but well
[04:10] <seb128> Tonio_: I'll look in a moment
[04:10] <dholbach> lool: hrm, best to ask jamesh
[04:10] <Tonio_> seb128: great, thanks
[04:10] <lool> dholbach: Does it work for you?
[04:11] <dholbach> lool: yes
[04:11] <lool> dholbach: I thought it might be some discrepancies between phones
[04:11] <dholbach> I tried before I uploaded gnome-obex-vfsftp
[04:11] <dholbach> might be
[04:11] <lool> The rest of gnome-vfs-obexftp works for me
[04:11] <jwendell> hi, dholbach 
[04:11] <dholbach> hi jwendell
[04:12] <jwendell> dholbach, a doubt: is there any way to get php4 back to feisty?
[04:12] <jwendell> (i guess no)
[04:12] <dholbach> jwendell: it's not supported any more and we're happy to not have it in - if we'd get it back people would expect it to be supported in some way
[04:12] <dholbach> jwendell: but I'm far from being an php expert
[04:13] <jwendell> dholbach, i'm asking it in order to know what to do with bug 102343
[04:13] <ubotu> Launchpad bug 102343 in kdemultimedia "mixer cannot be found" [Undecided,Rejected]  https://launchpad.net/bugs/102343
[04:13] <jwendell> oh
[04:13] <jwendell> bug 102843
[04:13] <ubotu> Launchpad bug 102843 in Ubuntu "php4 feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102843
[04:14] <dholbach> jwendell: best to reject with a friendly reply saying that we don't want to pretend to support it
[04:14] <jwendell> dholbach, yeah, thanks
[04:15] <dholbach> thank YOU
[04:59] <pygi> Zdra: poke
[04:59] <Zdra> pygi: pong
[04:59] <pygi> Zdra: got a little time?
[04:59] <Zdra> pygi: yes
[04:59] <pygi> Zdra: add (mario dot danic at gmail dot com) and try talking to me
[04:59] <pygi> jabber protocol
[05:01] <Zdra> pygi: ok 3sec
[05:02] <Zdra> pygi: done
[05:02] <pygi> Zdra: got your request, but since I can't authorize you (just yet), start the talk :)
[05:11] <jetscreamer> so what kind of questions do i get to ask in here
[05:11] <jetscreamer> :)
[05:13] <hunger> jetscreamer: Not stupid stuff like those you just asked... only philosophical questions on the essence of ubuntu are allowed here;-)
[05:13] <jetscreamer> wasn't stupid, just ignorant
[05:14] <hunger> jetscreamer: Maybe... I'm not a native speaker.
[05:14] <jetscreamer> ah
[05:15] <jetscreamer> so i can complain about how i think something should be done another way, but not ask how to do something, right? :)
[05:16] <Hobbsee> jetscreamer: you can do both
[05:16] <Hobbsee> jetscreamer: howeve,r the former will probably be ignored, unless it's sensible, and the relevant devloper happens to be watching
[05:16] <hunger> jetscreamer: That is basically what I try to do... I usually end up asking how to do something that recently changed though.
[05:18] <jetscreamer> oh ok. i thought i wasn't supposed to ask how to do 
[05:18] <jetscreamer> thanks
[05:19] <hunger> jetscreamer: You aren't.
[05:19] <hunger> jetscreamer: But people are friendly... 
[05:24] <Hobbsee> jetscreamer: you arent supposed to ask to ask, you're supposed to ask whatever.
[05:24] <Hobbsee> but i'ts development of ubuntu, not about ubuntu, and universe stuff goes to #ubuntu-motu, as the topic says.
[05:24] <Hobbsee> #ubuntu for general support questions, although you probably get away with teh odd one in here.  maybe.
[05:25] <jetscreamer> i don't have any questions atm, much... just wondering where to ask them. 
[05:26] <jetscreamer> like ... "wtf is this locales!!!"
[05:26] <jetscreamer> :)
[05:26] <Hobbsee> heh
[05:26] <Hobbsee> which can usually be answered witha  google search, or an apt-cache show <packagename>
[05:26] <Hobbsee> jetscreamer: usually people will tell you how to find an answer, rather than giving it to you
[05:27] <Hobbsee> jetscreamer: the whole thinig about giving a man a fish, vs teaching him to fish.
[05:28] <jetscreamer> Hobbsee: the ubuntu locales package differs from the debian one. i want to remove all locales except for en_us* .  
[05:28] <jetscreamer> then there's this belocs-locales thing
[05:28] <jetscreamer> anyway
[05:28] <jetscreamer> me neither
[05:28] <jetscreamer> no biggie though
[05:55] <stgraber> Riddell: About miniracer, pitti sent me a mail to have more information about those files as well, they basically are the output of GtkRadiant a level editor (mapping tool as they say), the .pak is the standard archive file for Quake 1 / Quake 2 engine and contains .bsp and some other level information file. You can find a .tar.gz with all the tools and file required to generate them.
[05:58] <Riddell> stgraber: so the .bsp files are opened and saved by GtkRadiant?
[06:00] <stgraber> Riddell: A bit different, you can get a .map back from the .bsp, the .bsp is a .map + lighting and rendering settings
[06:01] <stgraber> Riddell: the .map is also provided in the mapping tools .tar.gz
[06:01] <stgraber> Riddell: Seems to work the same way with all Quake-based games ...
[06:06] <Riddell> stgraber: I don't see any .tar.gz in the miniracer sources
[06:07] <stgraber> they have done a separate one
[06:07] <stgraber> http://prdownloads.sourceforge.net/miniracer/miniracer-tools-1.0.2.tar.gz?download
[06:07] <stgraber> "Mapping tools and sources" they say
[06:09] <Riddell> stgraber: so the .map is the source to the .bsp?
[06:10] <Riddell> what's the source to the .pak?
[06:15] <stgraber> Riddell: there aren't any source, it's just an archive containing .wav, .tga and other textures
[06:17] <stgraber> Riddell: but they should have put a copy of its content in a seperate archive, opening .pak doesn't seem to be easy at all 
[06:22] <Riddell> stgraber: I'll reject this then, you need to upload it with a new .orig.tar.gz that contains the .maps for the .bsp's and whatever the preferred modifiable form of the .pak is
[06:42] <cjwatson_> ok, I hope nobody minds, but I'm going to promote celementtree back to main, as bzr needs it again; it was in main in edgy so I assume this is ok
[06:46] <stgraber> Riddell: ok, in such a case is it ok to alter the original .tar.gz as taken from their website ? and how should I put the .map and others sources file as there are no command line tool to build them (gtkRadiant is a gui) ?
[06:48] <Riddell> stgraber: yes, i think you have no choice but to alter the .orig
[06:49] <Riddell> stgraber: mkdir sources and copy the files in, add a README.Debian file describing which files are needed and where to get them upstream
[06:49] <Riddell> stgraber: you can also add a rule in debian/rules to do it automatically if possible so it's easier to repear in future
[06:51] <stgraber> ok, will do that when I have some time
[07:19] <jwendell> Hi, folks
[07:20] <jwendell> which software cares about hotkeys on laptops?
[07:20] <jwendell> i mean, when i press Fn+FX, which program is run?
[07:23] <mjg59> Ubuntu, Kubuntu or Xubuntu?
[07:23] <jwendell> ubuntu
[07:24] <jwendell> seb128, any idea?
[07:24] <jwendell> i'm asking because bug 104155
[07:24] <ubotu> Launchpad bug 104155 in linux-source-2.6.20 "[regression]  Fn+F10 (eject) doesn't work on feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104155
[07:24] <jwendell> which seems not related to kernel
[07:25] <mjg59> jwendell: gnome-settings-daemon
[07:26] <jwendell> mjg59, do you have any clue about that bug?
[07:26] <mjg59> No
[07:27] <mjg59> But gnome-settings-daemon is the right package
[07:27] <seb128> not sure
[07:27] <seb128> depends if it generates the right keycode
[07:28] <jwendell> seb128, it's generating the right keycode
[07:28] <jwendell> the eject icon appears on the screen
[07:28] <seb128> does "eject -T" works?
[07:28] <jwendell> but it only ejects if there is no media mounted
[07:29] <jwendell> seb128, yep, it works
[07:29] <seb128> weird
[07:30] <seb128> gnome-settings-daemon only call "eject -T"
[07:30] <seb128> works fine on my desktop
[07:30] <jwendell> seb128, it worked fine on my desktop too, in edgy
[07:30] <seb128> it works fine with gutsy here
[07:30] <seb128> and I doubt this code changed between edgy and feisty
[07:33] <seb128> jwendell: do you have a /apps/gnome_settings_daemon/eject_command key?
[07:33] <jwendell> seb128, no!
[07:33] <seb128> if not it should just call "eject"
[07:33] <seb128> k, so it calls eject
[07:33] <seb128> no need
[07:33] <seb128> if it's not set it uses eject
[07:33] <jwendell> hmmm
[07:33] <jwendell> eject or eject -T
[07:34] <jwendell> ?
[07:34] <seb128> eject
[07:34] <seb128> looks like the "-T" is a recent gutsy change
[07:35] <jwendell> seb128, ah, just 'eject' fails
[07:35] <seb128> k
[07:35] <seb128> so it's not a bug with gnome-settings-daemon
[07:36] <seb128> or you can consider it as a bug fixed in gutsy if "eject -T" is working
[07:36] <jwendell> wendell@wendell-laptop:~$ LANG=C eject
[07:36] <jwendell> umount: /media/Ubuntu 7.04 i386 is not in the fstab (and you are not root)
[07:36] <jwendell> eject: unmount of `/media/Ubuntu 7.04 i386' failed
[07:36] <afflux> can someone check if bug 119968 is a bug or a feature?
[07:36] <ubotu> Launchpad bug 119968 in quodlibet-plugins "Notify plugin stacks up balloons if you press forward repeatedly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119968
[07:36] <jwendell> seb128, ok, i'll close the bug
[07:36] <jwendell> (i'm the reporter :))
[07:37] <seb128> afflux: I would say none of those
[07:37] <seb128> it's not really a bug, it displays the different events
[07:37] <seb128> and it's not a feature
[07:38] <seb128> there was a similar bug on rhythmbox
[07:38] <seb128> might a wishlist for notification-daemon
[07:38] <jwendell> seb128, thanks for point out "
[07:38] <jwendell> !
[07:39] <seb128> you're welcome
[07:40] <afflux> seb128: okay. could you change it to affect only the notification-daemon and set it to wishlist? I can't ;)
[07:44] <seb128> afflux: I've marked it duplicate of bug #108702
[07:44] <ubotu> Launchpad bug 108702 in notification-daemon "multiple notification bubbles overlap" [Wishlist,Confirmed]  https://launchpad.net/bugs/108702
[07:44] <afflux> oh, didn't see that one. thank you.
[07:44] <seb128> you're welcome
[07:52] <wereHamster> what is the reason to not add /usr/local/li to the default search path?
[07:54] <wereHamster> it causes major PITA for users who try to compile/install software from sources and follow the usual './configure && make && sudo make install' guide
[07:56] <Treenaks> wereHamster: /usr/local/li ?
[07:56] <wereHamster> it would make sense if build-essential added that path to /etc/ld.so.conf
[07:56] <Treenaks> wereHamster: ah lib.
[07:56] <wereHamster> /usr/local/lib, please use common sense :(
[07:56] <wereHamster> I'm a bit upset, so excuse me if I'm ruse :-/
[07:56] <wereHamster> rude
[07:56] <Treenaks> wereHamster: well, I know programs that install in /usr/local/{program name}
[07:57] <Treenaks> wereHamster: and I can imagine some program called 'li'
[07:57] <Treenaks> but anyway, I have no idea, sorry
[07:58] <wereHamster> almost all packages have default prefix /usr/local, which means libraries usually get installed into /usr/local/lib
[08:02] <cjwatson> I think what happened is that it got removed eons ago in response to a bug that happened due to /usr/local/lib not existing at all (http://lists.debian.org/debian-devel/1997/03/msg00559.html)
[08:02] <cjwatson> and then subsequent glibc maintainers found the entry in the changelog saying that it was removed but with no explanation, and were thus reluctant to add it back
[08:02] <cjwatson> (AFAICT from the mailing list history, anyway)
[08:02] <cjwatson> we should probably bring it up again with Debian
[08:04] <cjwatson> see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395177
[08:04] <ubotu> Debian bug 395177 in libc6 "libc6: default library search path is inconsistent with gcc" [Normal,Open]  
[08:05] <cjwatson> I don't think I'd want to do this just in Ubuntu, though - it would be quite a fundamental change that could easily cause surprise
[08:06] <cjwatson> BTW, build-essential would be a most inappropriate place for this to be done, given that that package purely exists for informational purposes
[08:07] <alex-weej> how do i patch an ubuntu package?
[08:08] <cjwatson> alex-weej: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[08:10] <wereHamster> cjwatson, having /usr/local/lib there by default works on gentoo
[08:11] <alex-weej> cjwatson: thanks
[08:14] <wereHamster> bug 120608
[08:14] <ubotu> Launchpad bug 120608 in Ubuntu "Add /usr/local/lib to ld search path" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120608
[08:16] <wereHamster> .. now at least we have a bug to track that 'issue' :)
[08:36] <jwendell> wereHamster, sorry, but isn't enough to add that dir to /etc/ld.so.conf ?
[08:37] <wereHamster> it is, but systems usually have it already there
[08:41] <pygi> hello folks
[08:45] <wereHamster> ubuntu just makes it harder for users to compile packages from sources, but that's sometimes necessary
[08:46] <pygi> wereHamster, it's easy
[08:46] <pygi> wereHamster, given you know what you're doing
[08:46] <pygi> I compile stuff all the time
[08:53] <bryyce> I would like to work on updating the ati fglrx binary driver in restricted modules, however I haven't done packaging for binary drivers yet, nor run across docs on it, so am a little unsure about the procedure.  If anyone has pointers or tips, I'd appreciate it.
[08:55] <mjg59> bryyce: Just take a look at how l-r-m works
[08:55] <mjg59> Check it out of kernel.ubuntu.com
[09:00] <bryyce> hmm, I don't see linux-restricted-modules listed there
[09:00] <bryyce> would it be ubuntu/ubuntu-gutsy-lrm.git maybe?
[09:04] <wereHamster> pygi, you know, I don't doubt that, but here it's not about me or you or any of the other developer, it's about making it easy for users that don't know their system that well
[09:04] <pygi> wereHamster, those should not compile then :)
[09:04] <pygi> as compiling brings some problems
[09:04] <pygi> when you don't know what you're doing
[09:05] <wereHamster> should not compile? make a ubuntu package out of my project then ;)
[09:05] <jwendell> wereHamster, if you are a developer and wants to make your customer's life easier, just build a package for them
[09:06] <wereHamster> I don't have ubuntu, and no intention installing tons of different distros only to make packages
[09:06] <pygi> wereHamster, what software do you want to see packaged?
[09:07] <wereHamster> seom and yukon, both have a bug requesting to be packaged
[09:12] <wereHamster> btw, the search in launchpad is broken, there's a bug with the title '/usr/local/lib is not properly supported' and yet searching '/usr/local/lib' won't list that bug
[09:12] <pochu> wereHamster: in which language are they written?
[09:13] <pochu> wereHamster: file a bug ;)
[09:13] <wereHamster> C and a tiny little bit in assembler
[09:16] <pygi> wereHamster, gimme bug numbers pls
[09:16] <SoftIce> hello is this the right channel to query a status on a faulty package?
[09:16] <pygi> (if it's something interesting, perhaps you might even get the packages)
[09:16] <SoftIce> seg faulting..
[09:16] <pygi> SoftIce, what's broken? :)
[09:16] <pygi> which package?
[09:17] <SoftIce> util-vserver in feisty, i can grab the package from debian etch and it works perfectly if i install it manually.
[09:17] <SoftIce> all versions down work but not the version in feisty.
[09:17] <SoftIce> very broken, right down to not even detecting capabilities in the kernel.
[09:18] <pygi> wereHamster, so bugs? :)
[09:18] <pygi> SoftIce, not familiar with that package, sorry
[09:19] <SoftIce> is it possible to find out who maintains that package so i can let them know? or wont it get fixed untill the release of gusty ?
[09:19] <pygi> I can get it for you
[09:19] <pygi> sec
[09:20] <wereHamster> pygi, one second.. creating other bugs
[09:20] <pygi> SoftIce, meh, nobody actually touched that package. It was auto-synced from debian
[09:21] <SoftIce> strange, what version does it get synced from
[09:21] <pochu> pygi: bug 117236
[09:21] <ubotu> Launchpad bug 117236 in Ubuntu "[needs-packaging]  seom" [Wishlist,Confirmed]  https://launchpad.net/bugs/117236
[09:21] <SoftIce> etch ?
[09:21] <pygi> SoftIce, unstable
[09:21] <pochu> (I was looking at it :)
[09:22] <SoftIce> unstable, hrm, unstable uses the same version as etch so strange it wasn't pulled from a stable release
[09:22] <pygi> pochu, what's that seom about? :)
[09:22] <SoftIce> wonder how they broke the package in debian unstable as its the same version as eth
[09:23] <pochu> pygi: a library for yukon :p
[09:23] <pygi> pochu, do we have list of deps?
[09:23] <pochu> and yukon is a library which uses seom :p
[09:23] <pochu> pygi: I don't think so...
[09:23] <pygi> meh, bad then :P
[09:24] <wereHamster> pygi, yukon doesn't have a bug, seom: 117236
[09:24] <SoftIce> i really hope we get a vserver kernel in gusty 
[09:24] <xtknight> GUTsy!
[09:24] <xtknight> :)
[09:24] <SoftIce> oh :)
[09:24] <SoftIce> why not call it sharka zulu
[09:25] <pygi> wereHamster, won't do, no time to track deps right now =)
[09:26] <wereHamster> 'track deps'?
[09:27] <pygi> btw. building a package != ./configure ; make ; sudo make install
[09:28] <wereHamster> I know, I wanted to say that the package doesn't require any magic or such, it's a simple library
[09:28] <wereHamster> no extra post-install rules etc
[09:28] <wasabi> Is there any udev mechanism to serialize script execution, or do I need to implement my own lock?
[09:29] <wasabi> Actually... maybe this belongs in watershed.
[09:30] <pygi> wereHamster, track deps = get what it uses, get all the -dev packages for that, etc, etc
[09:30] <SoftIce> i've had to disable udev to illiminate millions of vm-liniar or should I say device-mapper errors
[09:30] <SoftIce> it doesn't like something to do with my patches, i have to look at the diff and see if there isn't some errors with it
[09:35] <wereHamster> pygi, make, gcc, yasm>=0.5, libdl.so, libpthread.so, libX11.so, libGL.so, install, rm, uname, libXv.so
[09:36] <pygi> that isn't list of deps :P
[09:36] <pygi> but meh
[09:36] <pygi> nevermind
[09:37] <wereHamster> That's all I can tell you, I'm not running ubuntu nor do I know how ubuntu packages work
[09:37] <pygi> ok
[10:02] <Kmos> asac: any news about thunderbird v2.0.0.4 for feisty ? as security update
[10:02] <Kmos> http://www.mozilla.org/projects/security/known-vulnerabilities.html#thunderbird2.0.0.4
[10:03] <Kmos> ups, for gutsy, feisty has 1.5
[10:03] <keescook> Kmos: waiting on asac for an upload, should be soon.
[10:03] <Kmos> keescook: nice
[10:04] <dmb> is there a new maintainers guide for ubuntu?
[10:04] <dmb> for a package?
[10:04] <dmb> or does one usually get it submitted to debian-unstable first and then it floats here?
[10:10] <evand> dmb: take a look at the MOTU documentation on the wiki (https://wiki.ubuntu.com/MOTU/Contributing) and seek assistance in #ubuntu-motu.
[10:46] <Riddell> please test new network manager  deb http://tonio.homelinux.org/repo/ gutsy main
[10:49] <giskard> what's new?
[11:05] <Mithrandir> lool: yes, it works for devices I have paired with already.  Not others.
[11:18] <darwin81> Is it planned to include GNASH by default in Gutsy and include official flash as an option?
[11:19] <geser> darwin81: what I've heard is that you need the last snapshots to play some flash files
[11:23] <Bassetts> hi, can someone help me out with the hotkey-setup .hk config files?
[11:23] <darwin81> geser : Gnash 0.8.0, the latest official release, is good enough to play YouTube videos and I think that would be enough for a lot of people. Plus it's not just a philosophical Free Software problem, the official Flash is causing Firefox to crash a lot.
[11:24] <beuno> geser: it's in debian's NEW queue right now
[11:25] <Bassetts> i need to add another key to the lenovo.hk file, can anyone help?
[11:40] <Bassetts> can someone help me out with hotkey-setup