[12:02] <iBalo> Hmm... so i finally took a firmware .deb from Kanotix, so i think it must be at least beer-free
[12:02] <Kamion> Riddell: the gconf stuff attempts to stop gnome-volume-manager from popping up "helpful" nautilus windows when the installer is busy mounting partitions
[12:03] <Kamion> Riddell: kbd_chooser.py is in espresso-keyboard-setup, in the archive. espresso depends on it ...
[12:03] <Kamion> doko_: I took hppa and sparc out of my anastacia run because the fact that neither had built anything for weeks was rendering anastacia output difficult to deal with. I'll put them back in once they've caught up.
[12:04] <Kamion> Seveas: pings are better with content :)
[12:04] <Seveas> hehe
[12:04] <Seveas> would https://launchpad.net/distros/ubuntu/+bug/33438 be something I should subscribe you to?
[12:04] <Ubugtu> malone bug 33438 in Ubuntu "use sha1sum instead of md5sum" [Wishlist,Unconfirmed]  
[12:04] <Seveas> (still trying to improve the triaging)
[12:05] <iBalo> BTW, if the firmware is downloadable at linuxtv.org, could there be a problem in adding it to the repos?
[12:06] <Burgwork> iBalo, yes, possible
[12:07] <Burgwork> iBalo, just because somebody can distribute it doesn't mean Ubuntu can
[12:07] <Burgwork> observe Skype and Java
[12:08] <Diablo-D3> just because somebody can distribute it doesnt mean anyone cares.
[12:08] <Diablo-D3> observe bittorrent
[12:08] <Burgwork> Diablo-D3, bittorrent is a very useful tool for saving bandwidth
[12:08] <Diablo-D3> hrm, wouldnt that be interesting: illegal driver warez.
[12:08] <ohoel> is not distributing dapper flights to mirrors intentional?
[12:09] <iBalo> ok, i see... then this would be a case for uni-/multiverse... Maybe  i should just write up a Howto to make it easier for people to tackle the problem 
[12:09] <Burgwork> ohoel, dapper is not stable, so some mirrors may choose not to carry it
[12:09] <Burgwork> iBalo, multiverse means we can distribute it. If it is a hardware driver, there is a case for restricted
[12:10] <Kamion> Seveas: in some universe in which I believe that the md5sums.txt on the CD images has any cryptographical significance whatsoever
[12:10] <Seveas> Kamion, right, thought so already 
[12:10] <Kamion> I'll close it, there's a good reason why it's md5sum
[12:11] <Kamion> oh, hang on, he's not talking about md5sums.txt, he's talking about MD5SUMS
[12:11] <Kamion> ok, that's a not entirely illegitimate comment and should be assigned to me; I'll do that
[12:35] <iBalo> i just spent the last couple of minutes searching tfw for the firmware licensing policy of the Terratec/KNC-one DVB-cards. Can't find nothing... would it be helpful if I email them (I'm one of their customers, huh?) if there' s a problem in redistributing the firmware?  
[12:35] <iBalo> i just spent the last couple of minutes searching tfw for the firmware licensing policy of the Terratec/KNC-one DVB-cards. Can't find nothing... would it be helpful if I email them (I'm one of their customers, huh?) if there' s a problem in redistributing the firmware?  
[12:36] <Burgwork> iBalo, please don't double post
[12:36] <Burgwork> iBalo, I would try. Mention what you want to do. You might not end up speaking to someone with enough authority, however
[12:36] <Burgwork> iBalo, in any case, file a bug about it
[12:37] <iBalo> Ooops, sorry, had over 10 seconds dalay, wasn't aware i posted already
[12:37] <Burgwork> iBalo, ok, np
[12:39] <doko_> Mithrandir: how could a missing /etc/environment be regenerated?
[12:42] <Seveas> touch /etc/environment
[12:42] <Seveas> (doesn't dpkg-reconfigure locales create it?)
[01:20] <_lemsx1_> anybody knows why in gnome-terminal every character you type, the cursor seems to go from the beginning of the line up to the char that you are typing?
[01:20] <_lemsx1_> if i ssh into a remote box it doesn't happen
[01:21] <_lemsx1_> and with the same .inputrc .bash* files in different computers, some do that and others don't
[01:47] <jdub> BUENOS DIAS, AMANTES DE LA LIBERTAD!
[01:48] <_lemsx1_> lol
[01:52] <tenco> anyone here who knows python-gst?
[01:59] <sladen> tenco: try #farsight
[01:59] <tenco> farsight? ok.
[02:02] <tenco> sladen: no answer... :-(
[02:02] <tseng> tenco: patience can get you far, sometimes
[02:03] <tenco> tseng: perhaps i should wait a few and sleep in between. its already damn late here...
[02:03] <tenco> ... a few hours...
[02:04] <sladen> tenco: that's a good idea, somebody will have replied by the morning
[02:05] <sladen> tenco: and rather than asking ''does any know...'', actually ask the question.  ''I'm trying to do XXX, YYY but I get the error ZZZ.  Here's my code so far  http://....''
[02:43] <Kyral> uhhh
[02:43] <Kyral> why is OpenOffice getting yoinked?
[02:43] <jdub> Kyral: don't dist-upgrade
[02:45] <Kyral> Not like I need OO, was just wondering lol
[02:46] <jdub> it's a temporary package conflict 
[02:46] <Kyral> ah
[02:46] <Kyral> thats what I thought
[02:46] <jdub> if you avoid dist-upgrading, you'll miss most of that kind of mess
[02:46] <Kyral> actually I have been meaning to remove OpenOffice1....
[02:47] <Kyral> jdub: Why would I want to avoid it? I'm testing Dapper for a reason :D
[02:48] <Kyral> with everything that breaks, a new lesson is learned :D
[02:51] <jdub> because upgrade gets you where you want to go without the temporary package relationship glitches
[02:51] <jdub> it's worth looking at dist-upgrade output, but tracking with upgrade
[02:51] <Kyral> ahh
[04:21] <Burgundavia> infinity: does this mean we are going to be offiicially supporting sparc for dapper+1?
[04:21] <Mez> whats up with thunderbird atm
[04:21] <infinity> Mez: That's next on my list after sorting sparc.
[04:21] <infinity> Mez: Though, "what's up", in what sense?
[04:21] <Mez> so you know about not being able to reply to anything ?
[04:21] <infinity> Burgundavia: Not sure, that's up to sabdfl and others.  I just make it go.
[04:22] <infinity> Mez: Err, no?  It works great for me...
[04:22] <Burgundavia> infinity: ah, ok
[04:22] <Mez> er well it says it cant reply for me
[04:22] <infinity> Mez: What's it do?
[04:22] <Mez> "an error occured while creating a message composition window - please try again later"
[04:23] <infinity> Mez: Do you have doko's broken GTK installed, by any chance?
[04:23] <Mez> infinity - i have the one from his website
[04:23] <Mez> but it was working before that
[04:23] <Mez> though a new gtk+ is being downloaded now
[04:24] <infinity> Mez: Well, tbird hasn't changed, so if it's suddenly started hating you, I'd blame a library.
[04:25] <infinity> Mez: A full update, then quitting and restarting tbird (or even rebooting) might make it like you again.
[04:25] <Mez> "downloaded size: 1 Mb - installed size - 56k"
[04:25] <Mez> o_O
[04:25] <Mez> infinity - doingnfull upgrade now
[04:25] <Mez> tried rebooting too
[04:28] <Mez> nope
[04:28] <Mez> still broked
[04:29] <Mez> stat64("/home/mez/.mozilla-thunderbird/init.d/S*", 0x7fbc4484) = -1 ENOENT (No such file or directory)
[04:30] <Mez> moving my .mozilla-thunderbird folder works though
[04:30] <Mez> hmmles
[04:31] <Mez> I cant be arsed
[04:31] <Mez> I'm going to bed
[04:31] <Mez> night all
[05:19] <OgMaciel> Seveas: u around
[06:18] <Mithrandir> doko_: you can't.  It's not a conffile
[06:27] <carlk> today there is no xchat-gnome or xchat in dapper.
[06:27] <carlk> indended or should I bug it?
[06:37] <Burgundavia> carlk: xchat-gnome was removed, but xchat was not added back
[06:38] <jdub> Burgundavia: unlikely we'll ship a gui irc client in the desktop seed
[06:38] <Burgundavia> jdub: hmm, that is interesting
[06:39] <Burgundavia> shall we debate that on ubuntu-desktop? (I disagree with the decision)
[06:40] <whiprush> jdub: hey, have you had a chance to look at the ff1.5/css thing on fridge at all?
[06:42] <jdub> whiprush: not yet, will check it this arvo or monday
[06:42] <whiprush> cooh
[06:43] <whiprush> jdub: also, know if anyone got a better vid of your talk at fosdem? the one linked from lwn has horrible sound. :-/
[06:43] <jdub> Burgundavia: there's already a basic irc client in gaim, and xchat doesn't fit the GCF goal of the desktop seed (very small audience that cares about irc)
[06:43] <jdub> whiprush: no, that was pretty much it i think
[06:43] <Lathiat> i dunno.. irc is pretty popular
[06:43] <Lathiat> especially to get help with linux...
[06:43] <Lathiat> #ubuntu is a riot?
[06:43] <Lathiat> and my non geek friends use irc
[06:44] <Lathiat> whats GCF?
[06:44] <jdub> greatest common factor
[06:44] <jdub> Lathiat: compare irc to im - not even remotely favourable to irc :)
[06:44] <Lathiat> jdub: irc and im fill different voids
[06:44] <Burgundavia> jdub: hmm, forgot about gaim doing irc
[06:44] <jdub> Lathiat: sure, and irc is a very very niche player
[06:44] <Lathiat> gaims irc is very.. unfitting
[06:45] <jdub> i'd support this even if gaim didn't do irc
[06:45] <whiprush> people who want irc get irrsi anyway. :p
[06:45] <carlk> I think #ubuntu does quite a bit for support, which IM does not
[06:45] <Burgundavia> jdub: anyway we can get gaim to be able to be able get into #ubuntu quickly?
[06:45] <jdub> hold on
[06:46] <jdub> you guys are looking at this in a very odd way
[06:46] <jdub> why do we want to push more people towards #ubuntu?
[06:46] <ajmitch> jdub: why do we want to discourage users from it?
[06:46] <jdub> ajmitch: we're not
[06:46] <whiprush> ximian tried the irc help thing a few years back, that so didn't work.
[06:47] <carlk> i think it is good to have the kind of support that #ubuntu provides avalible 
[06:47] <jdub> carlk: it is still available
[06:47] <ajmitch> jdub: if you do remove an irc client, make sure the firefox start page doesn't point there
[06:47] <jdub> ajmitch: unrelated bug
[06:47] <jdub> definitely not a rationale for shipping an irc client
[06:48] <jdub> Lathiat: even if gaim didn't have an irc module, i'd support removing xchat
[06:48] <ajmitch> Lathiat: the argument is that no irc client should be shipped (gaim doesn't count)
[06:48] <Lathiat> jdub: why?
[06:48] <jdub> Lathiat: because irc isn't a high priority at all for the 99%
[06:48] <carlk> jdub: i think it is a good rational for shipping an IRC client - but what you or I probably isn;t as importatnt as some figures
[06:49] <Lathiat> jdub: got any actual evidence on that?
[06:49] <ajmitch> jdub: you could argue that python-* packages aren't important to the 99% either
[06:49] <jdub> Lathiat: absolutely - compare usage of im and irc
[06:49] <jdub> ajmitch: sure, but we're shipping them for other reasons
[06:49] <Lathiat> sure, i guess im is used more
[06:49] <jdub> Lathiat: it is wildly uncommon
[06:50] <carlk> I think more important than just usage is the support - xchat will provide more support than IM (but this doens' t mean we should drop IM)
[06:50] <Lathiat> just because its "not as common as im" != "wildly uncommon" ?
[06:50] <jdub> Lathiat: i'm not putting those ideas in opposition
[06:51] <Lathiat> jdub: i asked why its uncommon, you said compare usage to im
[06:51] <jdub> carlk: i don't believe that irc support is the most useful thing for the vast majority of our users
[06:51] <Lathiat> s/why/figures
[06:51] <Lathiat> jdub: have you ever sat in #ubuntu ?
[06:51] <jdub> Lathiat: to think about it, yes.
[06:51] <Burgundavia> jdub: I am also mildly concerned about the way this is being done
[06:52] <Burgundavia> jdub: this strikes me as the kind of thing you ask about or spec and then do
[06:52] <jdub> Lathiat: think about the greatest common factor, think about where irc fits in - really, it doesn't.
[06:52] <Lathiat> what exactly is the
[06:52] <Lathiat> "greatest common factor
[06:53] <jdub> what we ship in the desktop seed is stuff that will most likely be of use to the broadest cross-section of user profiles
[06:53] <Lathiat> jdub:  is it going to be on the cd?
[06:53] <Lathiat> or not shipped at all?
[06:53] <jdub> in main, probably not shipped at all (given the way the CD works now)
[06:54] <Burgundavia> Lathiat: in this case, software that the majority of the users that install Ubuntu are going to use or need
[06:54] <Lathiat> well, i think its a bad idea, its not like the software is in the way, and its not largely uncommon in my experience, perhaps thats different to yours
[06:55] <jdub> Lathiat: i don't think we can posit that irc is of interest to the greatest common factor of our potential users (or necessarily something we want to push to them)
[06:55] <jdub> everything we put in the desktop seed is inherently 'in the way'
[06:55] <jdub> so we need to think very carefully about it
[06:58] <jdub> dude, this is not about simplification
[06:58] <jdub> it's about appropriateness
[06:58] <Lathiat> jdub: its related
[06:58] <jdub> xchat is right there waiting for you
[06:58] <jdub> ok, i'll be blunt
[06:58] <jdub> if we're going to unfuck the world
[06:58] <jdub> and take software freedom to real people
[06:59] <jdub> we have to make Hard Choices
[06:59] <jdub> many of which are related to realising that we do not define our most important end user profile
[06:59] <fangorious> anyone know the difference between the regular install and the server install kernel boot options on the flight4 install cd?
[06:59] <jdub> irc is so amazingly irrelevant even within the general IT community
[06:59] <Burgundavia> jdub: I think I agree with you, but the concern about how the decision was made is still there
[07:00] <Lathiat> fangorious: regular install installs gnome, server install is very cut down, basic packages
[07:00] <fangorious> Lathiat: more basic than that. when you boot the cd, and select one or the other, what differences are there in the kernel options to boot the installer?
[07:01] <Lathiat> fangorious: oh kernel options.. i suspcet it just passes "server" or something that d-i picks up and acts on appropriately?
[07:01] <fangorious> Lathiat: If I boot the server install, I get the installer. If I boot the regular install, I get an I/O error that the ramdisk image couldn't be found
[07:01] <Lathiat> fangorious: interesting
[07:01] <LaserJock> jdub: how is the most important end user profile defined for you?
[07:01] <fangorious> I have the same error on the live cd, but there's no server install option there
[07:01] <Lathiat> known bug? bad cd?
[07:02] <fangorious> definitely not a bad cd. I've downloaded the image like 4 times, burned it at different speeds on 3 machines, used different cds ...
[07:02] <fangorious> only has trouble on this one laptop
[07:03] <Lathiat> best course of action would be to file a bug?
[07:03] <jdub> LaserJock: "not IT expert or interested" (i'm being facetious - there are a lot)
[07:03] <fangorious> yeah, just wanted to check
[07:03] <whiprush> or the ubuntu kernel list.
[07:03] <fangorious> whiprush: i'll check that out too
[07:04] <LaserJock> jdub: I'm interested in how these things are defined or quantified
[07:05] <LaserJock> jdub: I haven't been around the open source or linux development community very long so I'm interested in how a distro's target audience, etc. are defined/chosen/evaluated
[07:05] <Burgundavia> LaserJock: did you read the piece by jwilliams in the latest gnome journal about identifying target audiences?
[07:06] <LaserJock> Burgundavia: no, I'll check it out
[07:06] <Burgundavia> LaserJock: currently, they pretty much aren't
[07:06] <Burgundavia> it is very adhoc, with no real market analysis
[07:06] <jdub> Burgundavia: that's not true
[07:09] <Burgundavia> jdub: there is a prety stark dividing line between community and "corporate backed" distros at that point
[07:10] <fangorious> what package would I use in malone to file a bug against the install/live CDs?
[07:11] <infinity> fangorious: Depends on the bug.
[07:11] <fangorious> infinity: the default kernel gives an I/O error that the ramdisk can't be found, the server install kernel boots
[07:11] <infinity> fangorious: Probably a bad burn, if I had to guess.
[07:12] <fangorious> infinity: i'm just generically saying kernel, I'm not sure if that's right
[07:12] <fangorious> infinity: definitely not, i've downloaded and burned it 8-10 times on 3 machines, at different speeds, with different cds
[07:15] <fangorious> infinity: so any idea what package to file against?
[07:16] <infinity> fangorious: Is this with a daily build, a flight release, or a stable release?
[07:16] <fangorious> flight 4
[07:16] <infinity> Oh, then I'm pretty sure the image is just fine.
[07:16] <infinity> You can file the bug on "linux-source-2.6.15", there may be something particularly goofy about your hardware, but it's a bit suspsicious that the server kernel works.
[07:18] <fangorious> cool, bug 33513 filed.
[07:18] <Ubugtu> malone bug 33513 in linux-source-2.6.15 "Default install CD kernel won't boot on HP nw8240" [Normal,Unconfirmed]  http://launchpad.net/bugs/33513
[07:18] <fangorious> hey, that's really neat
[07:20] <LaserJock> jdub: so will there be any app in main that will handle a irc:// URL? does gaim, do you know off hand?
[07:21] <viviersf> erm, can any1 explain why openoffice2 wants to be removed, by doing a dist-upgrade on dapper ?
[07:24] <carlk> is there some way that FF can apt-get install xchat the first time an irc:// link is clicked?
[07:33] <pitti> Good morning
[07:36] <viviersf> lo pitti 
[07:47] <corey_> salut marilize
[07:47] <marilize> corey_ :  hello mr Burger :)
[07:49] <carlk> I got a stat:  !ubotu seen = there are 18383 seen entries
[07:50] <carlk> I wonder how many of those wouldn't have joined if they had to install a client 
[08:10] <viviersf> doko_, PING
[09:37] <dholbach> good morning
[09:41] <corey_> morning
[09:42] <Kagou> hi
[09:49] <pitti> infinity: we don't have http://sourceforge.net/projects/phplib/ packaged anywhere, right? at least I couldn't find it
[09:51] <hunger> Would it be possible to run symlinks -dr /usr/share/man occassionally?
[09:52] <hunger> Uninstalling debs leaves lots of symlinks there at times. Would be nice to clean up occassionally.
[09:52] <pitti> right, that's responsible for all these cron.daily emails 
[09:53] <pitti> hunger: however, eventually the packages themselves should get fixes
[09:53] <pitti> s/s$/d/
[09:54] <hunger> pitti: Currently that is openoffice.org. leaves ooimpress.1.gz et al.
[09:55] <hunger> pitti: It would be cool if there was a test facility for uploaded script that checks that they leave the system with the same set of files after an install/purge cycle.
[09:55] <hunger> s/script/debs/
[09:55] <pitti> hunger: that's indeed what Diziet is working on ATM :)
[09:55] <pitti> AutomatedTesting
[09:55] <hunger> IIRC. debian has something like that...
[09:56] <pitti> hunger: yes, piuparts
[09:56] <hunger> pitti: That's why I like ubuntu:-)
[09:56] <zakame> hi all
[09:56] <pitti> hi zakame 
[09:56] <zakame> hello pitti :)
[09:56] <hunger> pitti: Whenever I get an idea somebody of you great guys is already working on it:-)
[09:59] <Kagou> hi seb128 
[10:01] <seb128> lu Kagou
[10:05] <pitti> infinity: can you please give-back gnome-netstatus gnome-pilot gnopernicus gok gnome-python-extras rhythmbox vino xchat-gnome (temporary libgnomevfs-common breakage, fixed now)
[10:06] <seb128> hu
[10:06] <seb128> you uploaded all that stuff in the hour where it was broken? :)
[10:06] <pitti> seb128: apparently, that's what I meant with 'good timing' :)
[10:07] <pitti> seb128: first the .desktop changes, now gnutls transition, I silently became the 0wner of all gnome packages :-P
[10:08] <seb128> pitti: yeah :)
[10:08] <seb128> pitti: want some thousand bugs going with it? :p
[10:08] <pitti> seb128: I don't want to spoil your Karma
[10:09] <seb128> pitti: is http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt updated?
[10:09] <seb128> works fine with xchat-gnome :)
[10:09] <pitti> seb128: should, its generated daily at 0600 UTC
[10:10] <seb128> pitti: 
[10:10] <seb128> alacarte (0.8-0ubuntu4) dapper; urgency=low
[10:10] <seb128>   * debian/rules: Build a .pot
[10:10] <seb128>  -- Sebastien Bacher <seb128@canonical.com>  Wed,  1 Mar 2006 16:53:55 +0100
[10:10] <seb128> 2 days ago
[10:10] <seb128> it has built
[10:10] <seb128> and the log has still:
[10:10] <seb128> [10:10] <seb128> wftl: alacarte_0.8-0ubuntu3: 1 domains, but 0 pot files
[10:10] <seb128> 
[10:10] <seb128> one example
[10:10] <seb128> there is no change on all the stuff we fixed with dholbach
[10:11] <pitti> seb128: hm, no buildd tarball any more in ~lamont
[10:11] <pitti> ENOTHINGTOIMPORT
[10:11] <pitti> carlos, infinity: did the sbuild hack for exporting translation tarballs go away?
[10:12] <seb128> iz lamont bog
[10:12] <pitti> seb128: when was this uploaded?
[10:12] <pitti> yesterday?
[10:12] <seb128> 2 days ago
[10:13] <seb128> "Wed,  1 Mar 2006 16:53:55 +0100"
[10:13] <pitti> ok, so built on vernadsky
[10:13] <seb128> alacarte is a small package, I'm probably uploaded like a few minutes after that
[10:13] <carlos> pitti: ?
[10:14] <carlos> pitti: I don't know any details about sbuild
[10:14] <pitti> infinity: so, the latest ~buildd/translations directory on buildds (checked ross and vernadsky) is 20060225
[10:15] <pitti> after that, no tarballs are available any more
[10:15] <seb128> I blame infinity
[10:15] <pitti> so it seems that the switch to direct rosetta import made that sbuild hack become ineffective
[10:15] <pitti> or it was deliberately removed
[10:15] <pitti> so, iz not lamont bug
[10:16] <carlos> pitti: anyway, the files should be available from librarian....
[10:16] <carlos> pitti: just like any other upload
[10:16] <pitti> carlos: how do I get this? https://launchpad.net/+builds/+build/172016 -> .changes file shows the .changes, but no symlinks
[10:17] <pitti> and 'resulting binaries' just shows the .deb, not the translation tarball
[10:18] <Mithrandir> ogra_: the "gnome-screensaver locks every five minutes after you resume from suspend" bug is getting _really_ annoying.
[10:25] <carlos> pitti: I think that should be a question for celso
[10:25] <carlos> pitti: the files are stored and available so I guess it's a matter of setting that as links
[11:27] <mvo> ping ogra_
[11:37] <fabbione> seb128: ping?
[11:37] <seb128> fabbione: pong
[11:37] <fabbione> seb128: thanks for adding xauth as Depends for xvfb, but it's not enough
[11:38] <fabbione> i am going to upload another package now
[11:38] <fabbione> it needs xfonts-base too
[11:38] <fabbione> or it will fail to run later
[11:38] <seb128> ah, ups, thank you
[11:38] <fabbione> no problem dude :)
[11:38] <seb128> I just noticed the xauth because it was breaking pygtk build
[11:38] <fabbione> yeah
[11:38] <seb128> but since buildd retry and logs are a mess atm
[11:38] <fabbione> or if you want you can upload.. i am in holidays :)
[11:38] <seb128> I didn't notice if it was building after that
[11:39] <seb128> fabbione: I'll upload
[11:39] <fabbione> ok :)
[11:39] <fabbione> xfonts-base <-
[11:39] <seb128> xfonts-base is enough or I should look if it chockes on something else after that?
[11:39] <fabbione> thanks
[11:39] <seb128> np
[11:39] <fabbione> you need to be 100% sure to build on a machine that is not running X and in a clean chroot
[11:39] <fabbione> s/is/has
[11:39] <fabbione> and yes.. checking if it chokes is a good idea
[12:06] <Kinnison> Can I assume the gnome breakages are fixed now?
[12:06] <Kinnison> I.E. the ones which cause gnome programs to ftbfs
[12:08] <dholbach> Kinnison: if you refer to gconf* in various postinst scripts, then yes
[12:08] <Kinnison> cool
[12:08] <Kinnison> infinity: are you around?
[12:18] <Kinnison> If anyone needs builds resetting because of that breakage then please /msg me the url to the source release
[12:28] <MikeS> BenC: Are you around? I'm told you're the person to talk to about ubuntu kernels. I've been having some Weird Problems with valgrind, they turn out to be because of some part of the ubuntu kernel configuration, wanted to ask some questions about it...
[12:28] <ogra_> Mithrandir, please file it then
[12:28] <ogra_> mvo, pong
[12:29] <Mithrandir> ogra_: uh, it was discussed here two days ago, I assumed you knew about it.
[12:29] <ogra_> Mithrandir, i asked you to file it two days ago ;)
[12:29] <ogra_> i cant reproduce it at all here
[12:29] <Mithrandir> is there any particular piece of information you want?
[12:30] <ogra_> just a plain description for now would be fine 
[12:32] <Mithrandir> https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/33539 ; enjo
[12:32] <Ubugtu> malone bug 33539 in gnome-screensaver "doesn't seem to detect activity after resuming from suspend" [Normal,Unconfirmed]  
[12:32] <Mithrandir> +y
[12:34] <ogra_> Mithrandir, thanks :)
[12:35] <Mithrandir> it's an utterly useless description if you can't reproduce it, though
[12:42] <segfault> man, this new gnome-power-manager notification is really annoying
[12:43] <Treenaks> segfault: uh.. it only notifies if you battery is about to go empty -- or if your AC state changes, right?
[12:43] <pitti> segfault: which, that it tells you that you plugged in an AC adapter?
[12:43] <StevenK> Or unplugged it
[12:43] <pitti> (which is fairly pointless, right)
[12:43] <segfault> i'm using it plugged in, and it keeps notifying me that my battery is now charged
[12:43] <segfault> and repeats over and over
[12:44] <Kinnison> segfault: yeah, known bug
[12:44] <janimo> pitti, any difference between binary-predeb and post-install as the rule which adds gettext domain to .desktop files?
[12:44] <segfault> oh, sorry then
[12:44] <janimo> and hi :)
[12:44] <Kinnison> segfault: if I could get it to manifest on my laptop I'd stand a chance of fixing it
[12:44] <pitti> hi janimo 
[12:44] <Kinnison> segfault: can you please make a gpm trace?
[12:45] <Kinnison> segfault: Do you know how?
[12:45] <pitti> janimo: yes, it caught a few corner cases (some packages don't work with install/::
[12:45] <janimo> pitti, so you recommend using that since it is more robust?
[12:45] <segfault> kinnison: strace gnome-power-manager?
[12:45] <pitti> janimo: yes
[12:45] <janimo> I have helpers who package some xfce plugins and would like to tell them if that's the case
[12:45] <janimo> ok, thanks
[12:46] <pitti> janimo: IIRC the problem was that some package installed debian/mycustom.desktop over an upstream installed one
[12:46] <Kinnison> segfault: no
[12:46] <pitti> janimo: so that our cdbs rule didn't catch that
[12:46] <janimo> pitti, but if it is not done as part of a cdbs rule but on a per package base and is tested then it's ok?
[12:46] <janimo> s/base/basis/
[12:46] <pitti> janimo: oh, of course
[12:47] <janimo> ok, I'll let it the way they changed than
[12:47] <janimo> I was afraid to not be something related to dpkg voodoo and cornercases
[12:47] <pitti> janimo: btw, for such stuff it would really be nice to have a xfce.mk
[12:47] <janimo> as opposed to packaging problems
[12:47] <pitti> janimo: or just use gnome.mk for the time being
[12:47] <janimo> pitti, yes it is the first compelling reason to have an xfce class
[12:48] <janimo> pitti, and the most important are .desktop files for apps that show up in the menu right?
[12:48] <janimo> since there are desktop files for panel plugins too
[12:48] <pitti> janimo: right
[12:48] <janimo> but those are only read by xfce panel
[12:48] <pitti> janimo: and building a POT file, almost even more important
[12:48] <janimo> having the apps transtalted (thunar, xfce4-terminal, mousepad) actually helps gnome as well
[12:49] <janimo> pitti, you mean add to the per package POT file if it does not contain the strings in .desktop?
[12:50] <Kamion> BenC: linux-source-2.6.15 binaries accepted
[12:50] <Treenaks> \o/
[12:50] <janimo> do those strings in .desktop have _ in front just as in C code?
[12:50] <hunger> What? New kernel binaries again?
[12:50] <hunger> Damn, I just actually rebooted my server to have the last update finally take effect;-)
[12:51] <pitti> janimo: generally, update the POT file so that it's always current (even if you change strings in patches, etc)
[12:51] <pitti> janimo: an up to date POT is crucial for translations
[12:51] <pitti> janimo: and many packages don't build a pot at all, which is even worse
[12:51] <janimo> pitti, right. So actually just adding the line to .desktop is not enough if somehting is missing from .pot ?
[12:52] <pitti> janimo: yes, potentially
[12:52] <janimo> and some .desktop files have some strings translations embedded, how does that come in to the picture
[12:52] <pitti> janimo: but these two don't have much in common
[12:52] <janimo> are those fallbacks?
[12:52] <pitti> janimo: yes, gnome upstream doesn't use gettext for translating .desktop
[12:52] <janimo> xfce uses intltool
[12:53] <pitti> no, I mean at runtime
[12:53] <pitti> intltool is for merging .po translations into .desktop files
[12:53] <pitti> at build time
[12:54] <janimo> aha
[12:54] <janimo> ok, I have to read more gettext docs to be able to ask smarter questions
[12:54] <janimo> will get back with the progress
[12:54] <pitti> http://wiki.ubuntu.com/LangpacksDesktopfiles might help a bit
[12:55] <janimo> read that
[12:55] <janimo> but I am reading through info gettext for all the details
[12:55] <sabdfl> mjg59: how's that mactel box looking?
[12:57] <Treenaks> sabdfl: ( http://mjg59.livejournal.com/58934.html ? :))
[12:57] <mjg59> sabdfl: A little bit of kernel work to do
[12:57] <Kamion> oh, speaking of, I wanted to prod the seeds for mactel
[12:57] <mjg59> I've got some problems with interrupt routing, but other than that things are good. Small amount of installer work needed (elilo needs to be added), and then we're good.
[12:58] <Kamion> mjg59: could you send me /proc/cpuinfo from that box?
[12:58] <sabdfl> so good for dapper?
[12:58] <Kamion> I'd like to teach the installer that i386/Mac is a different subarchitecture
[12:58] <mjg59> Kamion: cpuinfo is, uh, not "interesting"
[12:58] <mjg59> Also, no dmi data
[12:59] <Kamion> mjg59: any other way to tell?
[12:59] <mjg59> Kamion: Not that I've worked out yet
[12:59] <Kamion> mjg59: that's going to be nasty
[12:59] <Kamion> mjg59: the installer needs to not offer elilo on normal i386 systems
[12:59] <StevenK> lspci doesn't show a stack full of Apple stuff?
[12:59] <mjg59> Kamion: Well, /sys/firmware/efi exists
[12:59] <Kamion> that'll do
[01:00] <Kamion> sabdfl: CD images will be "interesting"
[01:00] <Treenaks> Kamion: more & more non-apple will have EFI after Vista releases
[01:00] <Kamion> oh, fair point I guess
[01:00] <Treenaks> + machines
[01:00] <mjg59> Treenaks: And they'll quite possibly want elilo as well...
[01:00] <Treenaks> mjg59: true, but they won't be macs :)
[01:00] <mjg59> Yeah, it's the elilo thing that's the distinction
[01:00] <Kamion> yeah, makes it not a subarchitecture but gives me a valid isinstallable test for elilo
[01:00] <mjg59> Though they're more likely to ship with BIOS compatibility
[01:01] <Treenaks> mjg59: for a while at least
[01:01] <Kamion> sabdfl: the Mactel doesn't boot normal ISO9660 images; but I have a strong hypothesis that they'll boot the ISO9660/HFS+ hybrid images that we currently use on powerpc
[01:01] <Kamion> sabdfl: my current plan is to create separate -i386-mac.iso images for dapper, and merge that back into -i386.iso after dapper when I'm not so worried about breaking shit
[01:02] <mjg59> Kamion: Yeah, it'll boot HFS stuff with a blessed efi binary
[01:03] <Kamion> mjg59: I'm trying to figure out how to do this test without breaking ia64 2.4 installs in Debian
[01:03] <mjg59> Kamion: Ah. Heh.
[01:04] <Kamion> mjg59: does /sys/firmware/efi require any kernel modules to be loaded before it exists?
[01:04] <mjg59> Kamion: No
[01:04] <Kamion> mjg59: and is there any /proc equivalent?
[01:04] <mjg59> I'd guess so, but I'm not enthused about trying to boot a 2.4 kernel on this
[01:04] <Kamion> I'll trawl kernel source
[01:07] <Kamion> possibly /proc/efi
[01:08] <sladen> Kamion: presumbly the HFS+ view onto the system only needs to extend to elilo, the kernel and initramfs; after that point Linux running and can see the iso9660
[01:08] <Kamion> sladen: true, but I think from the debian-cd point of view it's easier to just hybridise the whole thing
[01:08] <Kamion> since mkisofs supports that
[01:09] <sladen> Kamion: I was worrying about space;  just adding elilo and a small HFS+ view should add <1MB to the CD
[01:09] <segfault> :)
[01:10] <Kamion> sladen: I can always use -hide-hfs to hide pool/ from the HFS view, I guess
[01:10] <Kamion> I imagine that would get rid of most of whatever extra space is taken by HFS metadata (although surely that isn't all *that* much anyway)
[01:22] <BenC> Kamion: re -17, thanks
[01:29] <Kamion> BenC: will you do l-r-m and linux-meta?
[01:29] <BenC> yeah, doing it now
[01:38] <doko_> infinity: could you have a look at #32869, nvidia-drivers?
[01:45] <Kinnison> Kamion: see you in 45
[01:51] <Kamion> Kinnison: ok
[01:58] <Mez> aw great 
[01:58] <Mez> I seem to have lost all my f**king email
[01:59] <freeflying> Kamion: hi
[02:02] <Mez> thats not good
[02:02] <Mez> not goodat all
[02:02] <pitti> Mez: how did you manage that?
[02:03] <pitti> some evo bug or sth?
[02:03] <Mez> pitti: thunderbird was playing up - so i moved my .mozilla-thunderbirdfolder
[02:04] <Mez> i tried movingit back and it deleted everything in it
[02:04] <pitti> with rm -r ?
[02:04] <Mez> when i next ran thunderbird
[02:04] <Mez> mez@lethargy % mv ~/.moz-tb-bak ~/.mozilla-thunderbird
[02:05] <pitti> Mez: and you are sure that it's not in ~/.mozilla-thunderbird/.moz-tb-bak now? :)
[02:05] <Mez> mez@lethargy % ls ~/.mozilla-thunderbird                       /home/mez 12:59
[02:05] <Mez> appreg  lavoky4t.default  profiles.ini
[02:06] <Mez> pitti: whats annoyed me most is that all my mail filters have gone so I've got to set them all up again for all the mailing lists
[02:09] <torkel> Mez: it's a dot-file so you will have to do ls -a 
[02:09] <Mez> torkel thankyou
[02:09] <torkel> Mez: found it?
[02:10] <Mez> yes
[02:10] <Mez> now lets see if I can write mail
[02:10] <Mez> ok
[02:11] <Mez> now it just wont select the right profile
[02:11] <Mez> nope
[02:11] <Mez> I still cant write email
[02:13] <Mez> argh
[02:13] <Mez> wtf is going on
[02:16] <BenC> Kamion: ping!
[02:16] <Mez> IT's something in my profile
[02:16] <mjg59> Kamion: Oh - something I've only just noticed. I picked "British English" for my keyboard, which is obviously wrong (since it's a Mac)
[02:16] <mjg59> How we work that out, I'm not sure
[02:20] <Kamion> BenC: yo
[02:21] <Kamion> mjg59: keyboard architecture handling is a mess
[02:21] <freeflying> Kamion: how about scim-pinyin's UVF
[02:21] <mjg59> Hngh!
[02:21] <Kamion> freeflying: I'll look at it later today
[02:21] <mjg59>                     If (_OSI ("Linux"))
[02:21] <mjg59>                     {
[02:21] <mjg59>                         Store (0x03E8, OSYS)
[02:21] <mjg59>                     }
[02:21] <mjg59> That's from the imac's ACPi tables
[02:21] <mjg59> Oh wow
[02:21] <mjg59> There's a reference to XP in here too
[02:22] <jdub> heh
[02:23] <jdub> mjg59: so, nice taste in wine. another reason for me to stop avoiding the desireable mac mini?
[02:23] <mjg59> jdub: Kernel isn't quite happy yet
[02:30] <BenC> Kamion: nm
[02:33] <Mez> argh
[02:39] <infinity> doko_: I'll try to reproduce that on my girlfriend's machine on Monday.  I've subscribed to the bug.
[02:40] <infinity> pitti: Still around?
[02:46] <pitti> infinity: yes
[02:49] <infinity> pitti: A) Those packages were just given-back, B) Not sure what's up with the translations publishing, can you ping me via email (it's really late Friday night and I'm a bit tipsy), C) I wouldn't be surprised if phplib shows up bundled in some larger PHP applications.. Pick some telltale filenames from phplib upstream and grep Contents-*.gz
[03:13] <sabdfl> ogra: what's the status on the hardware database?
[03:14] <ogra> not much improvement there, we have >200000 datasets but i still havent gotten around to write a proper SQL backend
[03:15] <doko> seb128: do you call the new copy/paste behaviour in gnome-terminal fixed? now, copy/paste *only* works using the menu, no x selection anymore :-(
[03:15] <ogra> i thought about approaching the LP team for it at some point so we can have it prepared to be integrated later 
[03:16] <dholbach> seb128: which version do you use?
[03:16] <seb128> doko: what do you mean?
[03:16] <infinity> doko: X primary works for me.
[03:16] <seb128> dholbach: uptodate
[03:16] <infinity> doko: With both middle-mouse and Shift-Insert.
[03:16] <dholbach> seb128: oops
[03:16] <seb128> dholbach: but you want to speak to doko:)
[03:16] <dholbach> doko: which version do you use?
[03:16] <dholbach> seb128: yeah, i do
[03:16] <doko> 2.13.91-0ubuntu1
[03:17] <dholbach> doko: and which vte?
[03:17] <doko> can you stop hugging and start working? ;-P
[03:17] <seb128> libvte4 is the package
[03:17] <doko> 1:0.11.20-0ubuntu1
[03:17] <ogra> sabdfl, its not off my list, but i have prioritized ltsp, edubuntu and gnome-screensaver currently, want me to change that ?
[03:17] <dholbach> doko: and you restarted gnome-terminal since one of the last updates? ;)
[03:17] <sabdfl> ogra: no
[03:18] <sabdfl> besides, prio's should be cleared by mdz
[03:18] <setuid> I need to build the _exact_ same kernel that I'm running on Breezy, from source, because /lib/modules/2.6.12-10-686/ doesn't have a full build tree of modules required for building third-party modules. How can I do this without breaking my running kernel (which includes modules in /lib/modules/volatile, like fglrx) 
[03:19] <Treenaks> setuid: uh.. install linux-headers-`uname -r`
[03:19] <infinity> setuid: Erm, for building third party modules, you want linux-headers-`uname -r`
[03:19] <doko> dholbach: hmm ... why should this affect the running process?
[03:19] <Treenaks> setuid: you _should_ be able to build modules
[03:19] <setuid> I did, that doesn't fix it 
[03:19] <Treenaks> setuid: then your module is broken
[03:19] <setuid> That's why I'm here asking ;)( 
[03:19] <dholbach> doko: i just wanted to be sure the new libvte is used
[03:19] <setuid> hrm, weird... just a mom. 
[03:19] <dholbach> doko: the fix was in 0.11.19
[03:20] <doko> dholbach: ok, will restart soon ...
[03:20] <infinity> setuid: Unless you have some bizarre module that wants to statically link another (which is just plain WRONG), you don't need modules to build modules, just headers to build against.
[03:20] <setuid> infinity: Nope, its just a replacement for ibm_acpi with the newer verison
[03:21] <infinity> setuid: And is it a complete build dir meant to build out-of-tree, or just something you're meant to dump in the kernel source tree?
[03:21] <setuid> Ah, the default kernel changed the acpi path
[03:21] <setuid> So third party modules will not work 
[03:21] <infinity> setuid: If the latter, either make it the former, or build a whole kernel (yay)
[03:22] <setuid> I can't build a whole new kernel, as much as I'd like to... (I *HATE* running distro kernels, they never work right), but I need fglrx, and that doesn't build agaisnt anything
[03:22] <setuid> root@angst:/lib/modules/2.6.12-10-686 # ls -l acpi/ibm_acpi.ko kernel/drivers/acpi/ibm_acpi.ko 
[03:22] <setuid> -rw-r--r--  1 root root 40740 Mar  3 09:20 acpi/ibm_acpi.ko
[03:22] <setuid> -rw-r--r--  1 root root 24084 Feb 13 07:46 kernel/drivers/acpi/ibm_acpi.ko
[03:22] <setuid> where the heck does kernel/drivers/acpi/ibm_acpi.ko come from? That's not right. 
[03:22] <infinity> That's perectly right.
[03:22] <setuid> I've inserted ibm_acpi into no less than 30 kernels on other machines, without any issues, now Breezy changes the path? 
[03:23] <infinity> Out-of-tree modules own the top-level namespace, everything distributed with a kernel is under kernel/
[03:23] <setuid> Then that differs from the upstream kernel.org source 
[03:23] <setuid> So Breezy changed it 
[03:24] <infinity> No, really, it's in sync with upstream.
[03:24] <setuid> If I build a clean kernel from kernel.org, unpatched, and build the ibm_acpi module externally agaisnt that kernel, it goes into where it should, /lib/modules/`uname -r`/acpi/
[03:24] <setuid> Nope, definitely not in sync with upstream
[03:24] <infinity> Yes, you just said the magic word "externally"
[03:24] <infinity> If built internally, it's kernel/*
[03:24] <setuid> Right, _externally_, with upstream kernel sources, it does into ./acpi, and there *IS* no other one 
[03:24] <setuid> sigh
[03:25] <setuid> Ok, let me try this a different way... 
[03:25] <infinity> setuid: Also, please take this to #ubuntu-kernel (yes, I should have shunted it there earlier)
[03:25] <setuid> I need to build a kernel, I need that kernel to include the fglrx driver (or else I can't run X, X will immediately hard-lock any Thinkpad released in the last 3-4 years if you let it load gdm or X with Breezy or Dapper)
[03:26] <setuid> Ok, I'll trundle over there. I know how to build kernels, I wrote the HOWTO on it... just not when things are changed under the hood with distros requiring third-party modules. 
[03:26] <infinity> setuid: I'm running a Thinkpad T43 (7 months old?) with dapper (and previously breezy) and no fglrx.
[03:26] <infinity> setuid: Please don't make such sweeping statements.
[03:26] <infinity> setuid: Heck, half of Canonical owns Thinkpads. :)
[03:26] <setuid> infinity: I have a T42p here, and if I load dapper with the radeon/ati driver, it immediately hard-locks. 
[03:27] <setuid> There are about 200 users on dri-users who have repeatedly reported this 
[03:27] <setuid> I am one of them
[03:27] <setuid> Its been an issue since the r300 cutover on 7/24 of 2005
[03:27] <setuid> That's the last version of r300/X/Xorg that works without lockups
[03:28] <infinity> One some machines, at any rate.
[03:28] <infinity> But I digress.
[03:28] <infinity> So you need fglrx.  Right.
[03:28] <setuid> Anything with a Radeon/ATI chip, yes. 
[03:28] <infinity> (Mine has an ATI X300)
[03:28] <setuid> Well, here's the problem... fglrx locks the machine up when you resume from suspend, but it doesn't lock the machine when you need to run X
[03:28] <infinity> (Making breezy/dapper both stable on my laptop has always been a personal release goal, and was always met)
[03:28] <setuid> So I either have to shut down, instead of suspend, or I don't run X
[03:29] <infinity> Yes, fglrx has always had resume issues.
[03:29] <setuid> There are some binary patches that have come out in the last 2 days that I haven't tried yet. 
[03:29] <torkel> setuid: the radeon driver works for me on my T40p
[03:29] <setuid> With 3D? 
[03:29] <setuid> 2D works great, at 67fps
[03:29] <setuid> (on my T42p
[03:29] <setuid> ) 
[03:29] <infinity> "Need to run X" != 3D.
[03:30] <setuid> infinity: Right, but there is no other way, including commenting out the DRI section of xorg.conf
[03:30] <torkel> setuid: I usually don't do 3D
[03:30] <setuid> Unless I rename the module in the tree 
[03:30] <setuid> dri, glx, radeon, etc. 
[03:30] <infinity> Or remove libgl-mesa-dri
[03:30] <setuid> Which removes about 80 other basic packages
[03:30] <infinity> Or don't load the glx module in xorg.conf
[03:31] <setuid> Nope, even with commenting out glx, it hard-locks
[03:31] <janimo> infinity, so you X300 works fine just no DRI with radeon driver?
[03:31] <setuid> You have to comment that out, the DRI section, and remove the physical module from disk
[03:31] <infinity> (I'm also pretty sure there's a driver option like "DisableDRI", but don't recall what it is)
[03:31] <infinity> janimo: I have DRI, works fine with it on.
[03:31] <setuid> Trust me, I've been through this... for 8+ months now
[03:31] <infinity> janimo: I'm clearly the only one in the world.
[03:31] <janimo> infinity: even resuming from hibernate?
[03:31] <setuid> You're one of a minority, yes. 
[03:31] <infinity> janimo: Yes.
[03:31] <janimo> it works here to just act funny on resume
[03:32] <janimo> that's promising anyway
[03:34] <setuid> janimo: Are you using vbetool? 
[03:34] <janimo> seyuid, dunno, default dapper
[03:34] <setuid> In your hibernate script, do you call vbetool on suspend and resume? 
[03:34] <janimo> lemme check
[03:35] <janimo> but I did not touch any script so if it's there it's the default
[03:35] <setuid> infinity: lspci -v -v | grep ATI 
[03:35] <setuid> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2]  (rev 80) (prog-if 00 [VGA] )
[03:35] <setuid> ^ that's what I have
[03:35] <pitti> carlos: could you please do me a quick favor? can you connect your iPod with firewire and pastebin me the lshal output?
[03:36] <setuid> pitti: ipods do firewire? When did that happen? My 4G and 5G are both usb-only
[03:36] <mjg59> infinity: Suspend fails for DanielS with DRI enabled
[03:36] <janimo> setuid, yes vbetool is called because POST_VIDEO is set to true
[03:36] <mjg59> On a T43
[03:36] <pitti> setuid: carlos' has :)
[03:36] <setuid> pitti: ah, hacked on, gotcha
[03:36] <mjg59> So there seems to be some unhappiness
[03:37] <janimo> mjg59, any idea what happens if the harddrive of laptop spins down after a few secs of inactivity
[03:37] <janimo> or as I work it looks like it spins up down every 20 sec or so
[03:37] <mjg59> No
[03:37] <janimo> after unplugiing and repluggind the cable
[03:37] <infinity> mjg59: Oh, I don't doubt it... But he also doesn't hardlock when X starts.
[03:37] <janimo> before that is fine
[03:37] <mjg59> infinity: Indeed
[03:40] <mjg59> setuid: ibm_acpi has been upstream since 2.6.10 or so. If built in an upstream kernel (rather than externally), it will end up in precisely the same location as Ubuntu puts it.
[03:42] <setuid> mjg59: 2.6.12-10 ships with 0.8, 0.11 has been current for many moons now... 
[03:42] <setuid> And 0.11 + my full-speed patch allows me to keep my T42 cool enough to use
[03:43] <mjg59> setuid: You're missing the point.
[03:43] <setuid> ...and allows me to use all of the keys
[03:43] <mjg59> setuid: We have not changed the install location of the driver. 
[03:43] <mjg59> It is installed precisely where the kernel build system puts i
[03:43] <mjg59> t
[03:43] <setuid> mjg59: The point is, if I build a kernel from source, with ibm_acpi as a module (internal to the kernel tree), then _replace_ that kernel module with an externally-built one, it _replaces_ the one in the kernel tree, it does not add a second one in a different location. Never has. 
[03:43] <mjg59> setuid: No, really, it does.
[03:44] <mjg59> Drivers that are built in the kernel source end up in /lib/modules/foo/kernel/whatever
[03:44] <mjg59> Drivers that are built outside do not
[03:44] <setuid> I guess these 30 systems are running on pixie dust then, because none of them exhibit the behavior you're describing
[03:44] <mjg59> If you build the ibm_acpi that is in the kernel source, it will install to kernel/drivers/acpi/
[03:45] <mjg59> That's what kbuild *does*
[03:45] <setuid> Right
[03:45] <mjg59> And we build ibm_acpi in the kernel source, which is why it ends up in kernel/drivers/acpi
[03:45] <mjg59> If you build it externally, the external build system has no idea to put it there. So it doesn't.
[03:45] <mjg59> So it gets installed in a different location.
[03:46] <mjg59> That's perfectly normal
[03:46] <setuid> If that's true, why does an in-kernel module take precendence over a third-party module in the kernel module tree when both are present? That behavior (if valid) should be reversed. 
[03:46] <mjg59> I've no idea. That's a module-init-tools issue.
[03:47] <mjg59> As far as I know, it's upstream behaviour
[03:47] <setuid> True
[03:47] <mjg59> keybuk would know for sure
[03:47] <setuid> T'would be nice to build these kernels with /proc/kconfig support, instead of /boot/config-x.y.z
[03:48] <mjg59> Why? One takes up memory, the other takes up disk space...
[03:48] <setuid> You're already wasting a truckload of memory by building support for every module in the kernel into the kernel's namespace
[03:48] <setuid> What's another 1k 
[03:48] <mjg59> What's the use case?
[03:49] <setuid> embedded systems
[03:49] <mjg59> If you're building your own kernels, it's a simple switch. If you're using the distro kernels, the config file is guaranteed to match
[03:49] <mjg59> Our kernels are not suited for embedded systems, really
[03:49] <setuid> Actually, the config file does _not_ match (and the kernel source package stamped with the same version as the running kernel also does not match) 
[03:50] <mjg59> No, really, it does
[03:50] <mjg59> It's copied into the package during the build
[03:50] <setuid> Example: 2.6.12-10-686, which I'm running, has a config file which builds as SMP (its UP), and the kernel source has a Makefile which specifies 2.6.12-386
[03:50] <setuid> So I have to change the config, change the Makefile, and rebuild 
[03:50] <mjg59> Which kernel source package? What you get with apt-get source?
[03:51] <setuid> I only point to official breezy repos, and yes, it was fetched with apt-get source foo
[03:51] <mjg59> What you get with apt-get source foo is the unconfigured source
[03:51] <setuid> apt-get source linux-headers-2.6.12-10-686 linux-image-2.6.12-10-686 linux-restricted-modules-2.6.12-10-686
[03:51] <mjg59> The configs are in debian/configs/
[03:52] <mjg59> The extraversion stuff is passed in as a makefile variable from the build scripts
[03:52] <setuid> So the config for my running kernel, which is in /boot/config-x.y.z, is not the same as that which built the running kernel? 
[03:52] <setuid> That's odd. 
[03:52] <mjg59> It is the same
[03:52] <setuid> No, that's my point, is it NOT the same. 
[03:52] <setuid> The config, found in /boot/ for my _running_ kernel, specifies SMP
[03:52] <setuid> The kernel which is running, is NOT SMP
[03:52] <setuid> The kernel source also does not add the proper stamp when the config from /boot/ is copied into the kernel tree
[03:53] <mjg59> This does not match any reality I can currently test
[03:53] <mjg59> setuid: It does if you build it with the package build system
[03:53] <setuid> debuild? 
[03:53] <setuid> Nope
[03:53] <mjg59> Yes
[03:53] <setuid> sigh
[03:53] <mjg59> No, really, it does.
[03:53] <setuid> I went through this the other night, after waiting about 6 hours for dozens of unnecessary kernels to build first
[03:53] <mjg59> I can't tell what's going wrong for you, but I have a sufficiently large number of kernels built here to know that that's how it happens.
[03:54] <mjg59> But if you're not interested in actually discussing it with someone who knows significantly more about our kernel build system than you, then I'm afraid I have better things to be doing right now.
[03:55] <setuid> I'm interested to hear what you changed from the standard kernel build process, so I can undo that when I build kernels
[03:55] <setuid> I need to build a kernel that matches the _exact_ kernel I'm running, with a current compiler. 
[03:56] <mjg59> Very little. The EXTRAVERSION field is populated by the rules file, based on the versions in the control file (which is autogenerated from the changelog version, IIRC)
[03:56] <mjg59> Other than that, it's all made as normal and then copied into a package (including the config file that was just used for the build)
[03:56] <setuid> Ok, so why is EXTRAVERSION set to 386 when I build with a config that comes from my -686 version? 
[03:56] <mjg59> How did you trigger the make?
[03:56] <setuid> debuild
[03:57] <mjg59> That will generate around 5 different kernel packages
[03:57] <mjg59> One for each in debian/configs/i386/
[03:57] <setuid> Right
[03:57] <setuid> And the top-level Makefile is set to -386, not -686
[03:57] <mjg59> The EXTRAVERSION will be set based on the ABI version and the string in debian/configs/
[03:57] <mjg59> No, the top-level Makefile is not set
[03:57] <setuid> and include/linux/versions.h also correlates with that
[03:57] <setuid> ..for my arch
[03:58] <mjg59> The only place where EXTRAVERSION is set is as a variable passed in from the rules
[03:58] <mjg59> When it reads debian/configs/i386/686, it will be set to -10-686 (or whatever)
[03:58] <setuid> Ok, what package/packages am I supposed to install, that will give me the _exact tree_ of source that build the kernel I'm _currently_ running? 
[03:59] <setuid> s/that build/that built/
[03:59] <mjg59> The source you get from apt-get source is identical
[03:59] <mjg59> If you then debuild in there, it'll build 5 or so kernels, one of which will be identical to your running one
[03:59] <setuid> So linux-source-2.6.12-2.6.12 then? 
[03:59] <mjg59> Yes
[03:59] <setuid> And that knows I'm at a -10? 
[04:00] <mjg59> If it's the -10 version, yes
[04:00] <mjg59> (you can see in the changelog)
[04:00] <setuid> linux-source-2.6.12 (2.6.12-10.28) breezy-security; urgency=low
[04:00] <mjg59> Yup
[04:01] <setuid> Ok, so I just copied /boot/config-2.6.12-10-686 into there, and debuild will build me a package that matches my currently-running kernel? 
[04:01] <mjg59> No
[04:01] <mjg59> Because it'll be overwritten by debian/configs/i386/whatever for each build
[04:01] <mjg59> But the 686 one in there should be identical to your config-2.6.12
[04:02] <setuid> Ok, so I should copy debian/config/i386/686 to .config? 
[04:02] <mjg59> Not if you're going to use debuild, no
[04:02] <mjg59> But if you just use make bzImage, then yes
[04:02] <setuid> If I have no top-level .config, and run debuild, I get a 2.6.10-386 SMP kernel
[04:03] <setuid> er, 2.6.12
[04:03] <setuid> Not a 2.6.12-10-686 UP kernel
[04:03] <mjg59> It should build more than one kernel
[04:03] <setuid> It does, 1 for each arch
[04:03] <mjg59> Uh. What do you mean by each arch?
[04:03] <setuid> AMD, K7, i386, etc. 
[04:03] <mjg59> Right
[04:04] <mjg59> There should be a 386 and a 686 one
[04:04] <setuid> I'll let it complete and see what happens... the other night (on dapper) when I tried this, it _only_ built the 386 ones, 686 wasn't even an option. 
[04:05] <setuid> Unless I hacked the Makefile and .config to force it, and built it myself
[04:05] <setuid> mjg59: How would I take this same process (and maybe I should be in #ubuntu-kernel) and build a non-supplied kernel (like 2.6.16-rc6) as a package with all of the same deps and tangles? 
[04:06] <mjg59> setuid: Grab the 2.6.15 git tree, copy the debian directory into your 2.6.16 tree, edit the changelog so the version is sensible, build
[04:07] <setuid> So debian/changelog is parsed at build time? 
[04:07] <mjg59> Yup
[04:07] <mjg59> It's pretty standard to have one canonical source of version numbers
[04:09] <setuid> You mean the external git tree, not the debian one? 
[04:13] <mjg59> setuid: The one on kernel.org
[04:13] <setuid> Right, ok
[04:14] <mjg59> Or grab a 2.6.15 source package from dapper
[04:14] <setuid> And copy the ./debian from the kernel source provided by the dapper/breezy package into that tree, gotcha. 
[04:14] <setuid> Makes it nice and self-contained
[04:16] <Riddell> Kamion: espresso-frontend-kde ready for merge, new bzr archive to get round the deleted gtkui.py thing http://kubuntu.org/~jriddell/espresso/ubuntu/
[04:16] <Riddell> Kamion: can I upload that to the archives?
[04:21] <carlos> pitti: I cannot do that as the computer with the firewire has MacOSX instead of Linux
[04:23] <Kamion> Riddell: I'd rather merge it first
[04:23] <Kamion> Riddell: but cool, thanks!
[04:23] <Kamion> (I'm working on espresso pretty much permanently, and often have changes beyond the current release)
[04:25] <Riddell> Kamion: are you likely to upload it today?  I'd like to send out an e-mail to interested people that it's available before I go away for the weekend
[04:30] <trappist> dist-upgrade wants to remove openoffice.org and kubuntu-desktop and not replace them?
[04:31] <Kamion> Riddell: yeah, should do
[04:33] <Kamion> Riddell: I'll change a couple of things - you won't be able to import espresso.emap in the KDE frontend because it actually lives in espresso-frontend-gtk
[04:33] <Kamion> Riddell: but I can handle that
[04:34] <Kamion> Riddell: spacing in customize_installer is b0rken
[04:36] <trappist> oh, openoffice.org2-* depends on pyhon-uno, which depends on openoffice.org-core which conflicts with openoffice.org2-core.  so openoffice.org2 appears to be uninstallable.
[04:50] <mdke> trappist, only if you dist-upgrade
[04:50] <mdke> i think
[04:50] <trappist> mdke: yes
[05:10] <doko> seb128: isn't glitz part of gnome? wondering, why it's not yet in main ...
[05:11] <seb128> doko: no
[05:11] <seb128> it's a freedesktop stuff I think
[05:11] <seb128> and nothing from GNOME has a Depends on it
[05:12] <doko> seb128: are there any known problems which would hinder inclusion in main?
[05:12] <seb128> no
[05:12] <seb128> not by my
[05:12] <seb128> do we need it to main?
[05:13] <doko> o libglitz-glx1 libglitz-glx1-dev                                     {glitz}
[05:13] <doko>    [Reverse-Depends: libglitz-glx1-dev] 
[05:13] <doko>    [Reverse-Build-Depends: openoffice.org] 
[05:13] <ogra> thats XGL 
[05:14] <trappist> Xgl is also in universe, isn't it?
[05:14] <ogra> and very very young ... 
[05:31] <stockh0lm> do you guys ship the madwifi driver on the cd?
[05:32] <stockh0lm> i have a wlan card that is supposed to work with madwifi but it tires to use the acx_pci module
[05:32] <bag> Anyone knows where to find spezific ubuntu patches? Such as the new logout menu?
[05:32] <stockh0lm> (it == the installer)
[05:32] <trappist> stockh0lm: apt-cache says it's part of linux-restricted-modules
[05:33] <kent> stockh0lm: you know about #ubuntu.se right?
[05:33] <stockh0lm> kent: no, never heared of it. 
[05:33] <stockh0lm> do they speak german there?
[05:33] <mdke> swedish, one hopes
[05:33] <kent> stockh0lm: swedish,   it looked like you are  swede..  :)
[05:34] <stockh0lm> kent: i only live in sweden (c:
[05:34] <kent> stockh0lm: oh, sorry then.  :)
[05:34] <stockh0lm> where is jeff, this is a support question (c:
[05:35] <mdke> stockholm, you can try #ubuntu
[05:35] <stockholm> yes, will do
[05:42] <stockholm> no good.
[05:43] <siretart> 17:33:00 < nobse> http://www.braincells.com/debian/images/future_of_gnome.png
[05:48] <Kamion> Riddell: ok, uploading
[05:51] <stockholm> so how can i install a package (linux-restricted-modules) before the network autodetection of the d-i run?
[05:57] <pitti> Kamion: can you please demote libpng3 sources to universe?
[05:58] <pitti> must ... clean .. up ... archive :)
[05:58] <trappist> pitti: how can I get involved in the firewall spec (I saw your name on it), or does the guy who got the bounty have exclusive access?
[05:58] <pitti> hey JaneW 
[05:58] <pitti> trappist: Carsten has the bounty
[05:58] <pitti> trappist: if you want to help him, he'll certainly appreciate :)
[05:58] <pitti> trappist: you should contact him via email
[05:58] <trappist> pitti: that's what I was looking for, thanks
[05:59] <trappist> any room for input on the spec itself?
[06:00] <pitti> I have to leave for supermarket for a bit, but feel free to mail carsten and me about it :)
[06:01] <trappist> will do, thanks
[06:03] <mdke> mako, ping?
[06:12] <mdke> mako, when you get this, can you moderate my post to -news just now? grazie mille
[06:21] <Diziet> OK, I give up.  What's normally responsible for running ifup on eth0 ?
[06:22] <Diziet> Oh, I see, I don't have netbase installed.
[06:22] <Diziet> Thank you for being a cardboard IRC channel.
[06:22] <mdke> haha
[06:23] <seb128> Diziet: udev I would say
[06:23] <seb128> Diziet: /etc/udev/rules.d/85-ifupdown.rules
[06:30] <Kamion> pitti: done, although it'll be a while before it takes effect since we have archive problems at the moment
[06:32] <pitti> Kamion: thanks
[06:32] <mjg59> W00t.
[06:32] <mjg59> Now I just need to get the CD drive working again.
[06:45] <pitti> hi zyga, how are you?
[06:45] <zyga> pitti: hi, fine :)
[06:45] <zyga> thanks :)
[06:46] <zyga> I got wifi working yesterday and now I'm enjoying the weekend on my bed
[06:46] <pitti> heh
[06:47] <zyga> ndiswrapper unfortunatly but it'll get better over the years
[06:59] <dholbach> have a nice evening
[07:01] <mdz> ogra: is the hwdb server still running on your personal machine, or is it at the DC now?
[07:02] <ogra> mdz, still on my machine 
[07:02] <ogra> but its a brandnew server and i have backups up to 180000 datasets 
[07:02] <ogra> (we have ~200000 currently)
[07:09] <mako> mdke: it's away :)
[07:13] <theCore> Is it normal, that I feel Dapper UI take me for an incomptent, while the installer take me for an expert?
[07:15] <theCore> is it a reason why the System menu is locked?
[07:16] <theCore> (btw, sorry if my question seem like "trolling" )
[07:16] <trappist> theCore: the installer is mostly inherited from debian, which imho suffers from the attitude that a good barrier to entry will keep out the unwanted noobs
[07:17] <Kamion> that's simply a false description of d-i's development approach
[07:17] <Kamion> I'm sorry but as a d-i developer I think I'm qualified to say that that has never been an attitude taken by d-i developers
[07:18] <Kamion> and looking at the massive improvement of d-i over boot-floppies that's borne out by evidence
[07:18] <theCore> I saw I few thing in the installer, that could be abstracted easily
[07:19] <trappist> Kamion: I'm basing my opinion on what you'll hear from the debian community when you mention making something more user-friendly, and I suspect their desires tend to percolate up to the developers
[07:19] <theCore> like in the network config, why bother people with the network devices names, like eth0 or ath0 ? 
[07:20] <mjg59> trappist: Oddly enough, no...
[07:20] <Kamion> trappist: *shrug* I'm afraid you're wrong here as far as the developers who are actually doing the work; many of the more vocal members of the Debian community are entirely unrepresentative
[07:20] <Kamion> theCore: it's basically noise (read as "blah") by people who don't know what they are, but if you *do* know then it's invaluable
[07:21] <trappist> Kamion: that's entirely believable.  it's those vocal members who drove me into the arms of ubuntu.
[07:22] <trappist> at any rate I always got the impression that the debian installer is just the way they like it.
[07:22] <Kamion> trappist: some of the vocal members of the Ubuntu community are just as bad, to be honest
[07:22] <Kamion> we've just had less time to pick up the more eccentric folks here ;-)
[07:23] <Kamion> trappist: nah, look at the graphical installer development for example
[07:23] <Kamion> there's loads still to do on d-i
[07:23] <trappist> Kamion: every community has its trolls and idiots and zealots, but I haven't seen so much of that here.
[07:23] <trappist> haven't seen the graphical one.  but having come (almost) originally from mandrake, I know installers can be a LOT more user friendly.
[07:24] <Kamion> d-i is just operating under some constraints (many self-imposed of course, but they are well-thought-out for the most part) that mean it's taken a while to get there
[07:24] <theCore> what is the UI freeze deadline ?
[07:25] <Kamion> and remember that espresso is a derivative work of d-i
[07:25] <Kamion> theCore: http://wiki.ubuntu.com/DapperReleaseSchedule
[07:25] <trappist> well they don't have the same target audience as ubuntu I guess, so that's reasonable.
[07:25] <theCore> thanks Kamion
[07:26] <Kamion> it's also been important to make the code maintainable by a relatively large and fluid developer community and to make it easy to port to all the architectures Debian supports
[07:26] <Kamion> which has been a godsend in Ubuntu, as we haven't had to do much porting work
[07:27] <Kamion> and it's not that hard for developers to come in and fix just one piece, once they've got an idea of the general design - that's not the case of the other more monolithic installers I've looked at
[07:27] <Kamion> installers that are primarily maintained by just a couple of people in a company obviously don't have to deal with the large-development-community aspect
[07:28] <trappist> I dunno if you've looked at mandrake's installer (I haven't in a while) but it fits that description nicely.  The pieces are tools written in perl available in the installed OS that have a gui wrapper but fall back nicely to ncurses or even cli if necessary.
[07:29] <Kamion> no, I haven't looked at Mandrake, that's true
[07:29] <trappist> don't get me wrong, I left mandrake for a reason, but I sure did like the installer.
[07:29] <Kamion> sounds like a not dissimilar design, we'll probably get there or thereabouts
[07:31] <Kamion> we have the capability to add frontend-specific plugins now, which will help a lot once people get the hang of writing them
[07:31] <mdz> ogra: is there a sysadmin ticket open for moving it to the DC?
[07:31] <ogra> mdz, nope 
[07:40] <Treenaks> pitti: if /dev/sdx1 mounts as /media/-1/ -- would a reboot help? :)
[07:43] <theCore> oh yeah I almost forgot, why do I have 8 floppy drives?
[07:44] <^ap^> hi mans
[07:44] <^ap^> need help
[07:45] <Kamion> theCore: installer bug, need to track that one down ..
[07:46] <Treenaks> theCore: because you do? :P
[07:46] <Kamion> in fact, I'll have a look now, it's like the most frequently reported installer bug at the moment I think
[07:46] <theCore> Treenaks: I don't even have one
[07:47] <LaserJock> "OMG, when I installed Ubuntu it gave me new floppy drives! I wonder if they could give me some more RAM next time" ;-)
[07:47] <Cyorxamp> Lo, is anyone here a fundamental part of the ubuntu project - got a cosmic idea for ya (anyone who says !anyone will be severely insulted)
[07:56] <Cyorxamp> WHAT do people think of this suggestion??? http://paste.ubuntu-nl.org/9684
[07:58] <Treenaks> Cyorxamp: I just post my working Monitor sections on my blog :)
[07:59] <CarlFK> Cyorxamp: wiki isn't a good database server for that 
[07:59] <CarlFK> Cyorxamp: there is allready someting like it, but it just collects data. someone needs to build a UI to get the data back out
[07:59] <Cyorxamp> but does this idea have merit?
[08:00] <CarlFK> "yes"
[08:00] <Cyorxamp> hmm, why the quotes?
[08:00] <CarlFK>  the impmemtaion you describe is poor
[08:00] <Cyorxamp> so what do you think would be a better way?
[08:00] <Kamion> people have mentioned the hwdb to you a few times already
[08:01] <CarlFK> build a UI to the existing database 
[08:01] <Cyorxamp> but the wiki idea is so easy
[08:01] <Cyorxamp> if a UI is such a good idea why hasn't someone done it yet
[08:01] <CarlFK> Cyorxamp: not once it gets big enough to be useful
[08:01] <Cyorxamp> if the wiki idea got superseeded by something later, fine
[08:02] <CarlFK> Cyorxamp: are you volunteering to built the UI?
[08:02] <trappist> you're talking about using a wiki as a database.  storing things like this in something designed to hold it isn't a bad idea, and can be made pretty useful with a ui.
[08:02] <Cyorxamp> which doesn't exist
[08:03] <Cyorxamp> people keep saying there is a script, and something called hwdb etc... but at the end of the day a newb can't understand that
[08:03] <CarlFK> Cyorxamp: are you volunteering to built the UI?
[08:03] <Kamion> theCore: oh, heh, the installer lists 8 floppy drives in /etc/fstab because udev helpfully creates 8 device nodes in /dev/floppy/
[08:03] <Kamion> Cyorxamp: that's why it's on the menus for them, "Hardware Database" or something along those lines
[08:04] <Cyorxamp> CarlFK, hey I only know a bit of Java, VB and I am only now learning C, C++, GTK+   - i wouldn't know where to begin
[08:04] <theCore> Kamion: so it is easy to fix
[08:04] <CarlFK> "that's why" ;)
[08:04] <Kamion> theCore: well, not sure, still investigating
[08:05] <Cyorxamp> CarlFK - your saying theres a lack of developers with the knowledge needed to make a UI?
[08:05] <Kamion> theCore: it's always a mistake to declare that something is easy to fix before investigating it :)
[08:05] <Kamion> Cyorxamp: s/knowledge/time/
[08:05] <CarlFK> Cyorxamp: correct
[08:05] <Kamion> no, not correct
[08:05] <Cyorxamp> well the whole reaosn I am jumping on the C,C++,GTK+ band wagon is to get away from the very Vista,C# friendly atmosphere at my uni
[08:05] <Kamion> there's a lack of developers with time
[08:06] <ogra> Kamion, thanks foe -docs !
[08:06] <ogra> *for
[08:06] <Kamion> ogra: no problem
[08:06] <Cyorxamp> so yeah - when I have the knowledge I will contrib as much as I can
[08:06] <theCore> Kamion: at least, I can fix it manually
[08:06] <Cyorxamp> but this idea is EASY and needs NO programming skill!
[08:06] <Cyorxamp> and could help looooads of people
[08:06] <CarlFK> Cyorxamp: no, a wiki page will turn into a big mess
[08:06] <Cyorxamp> not ONE page lol
[08:07] <Cyorxamp> a page per model of 'thing' (whether monitor/card)
[08:07] <CarlFK> Cyorxamp: a bunch of wiki page will turn into a big mess
[08:07] <Kamion> theCore: fixing it manually is trivial, rip the stray lines out of /etc/fstab
[08:07] <theCore> Kamion: already done
[08:07] <Kamion> the thing is, nobody will actually ever look at these wiki pages, because it's too painful
[08:07] <Cyorxamp> CarlFK - whats that 'Hardware Database' thing thats supposed to be in my menu then?
[08:08] <Cyorxamp> is that a GUI to a database?
[08:08] <Kamion> so it lures people into believing that something is being done when it isn't
[08:08] <bag> Anyone knows where to find spezific ubuntu patches? Such as the new logout menu?
[08:09] <CarlFK> Cyorxamp: start here: https://wiki.ubuntu.com/HardwareDatabase  
[08:09] <ogra> Cyorxamp, in fact there is no database yet, there is a collection of 200000 datasets on http://hwdb.ubuntu.com/
[08:10] <ogra> the app you start from the menu is the data collection tool ...
[08:10] <theCore> Wouldn't be a better to make a GUI editor for xorg.conf?
[08:10] <CarlFK> orga - that "is" a database ;)  
[08:10] <Cyorxamp> how on earth is 3770236f086536d10237452f01b9cabc supposed to help?
[08:10] <Cyorxamp> this is a nightmare
[08:10] <Kamion> theCore: not really, much better to have it go away
[08:10] <ogra> whats missing is a SQL backend that makes the adta searchable ... and a web frontend or gui app 
[08:10] <Burgwork> theCore, why play with system-config X in RH
[08:11] <ogra> Cyorxamp, that will disappear once there is a DB 
[08:11] <Cyorxamp> ok CarlFK - how about an SQL database for someone to access using a program on ubuntu
[08:11] <Cyorxamp> look up your settings for a device
[08:11] <Cyorxamp> maybe it will even give you the code you need for certain config files
[08:12] <ogra> Cyorxamp, currently it helps if you can give that ID in a bug report, the developer can download the adtaset and look at the HW data
[08:12] <CarlFK> Cyorxamp:  that would be the "front end' that needs to be built
[08:12] <Cyorxamp> CarlFK - so your saying the 'thing to connect to' already exists? if so where?
[08:12] <CarlFK> anyone know how the data behind http://hwdb.ubuntu.com is stored?
[08:12] <ogra> Cyorxamp, nope, the *data* exists 
[08:13] <ogra> CarlFK, xml files bz2 compressed
[08:13] <CarlFK> pretty sure it is in a MySql db unless my memory is failing 
[08:13] <CarlFK> oh...
[08:13] <Cyorxamp> CarlFK - is each 'entry' in that database a different piece of hardware?
[08:13] <ogra> nope
[08:13] <LaserJock> Cyorxamp: click on a few ;-)
[08:14] <Cyorxamp> but they are whole computers
[08:14] <CarlFK> orga - has anyone proposed a db schema? (table structures)
[08:14] <ogra> Cyorxamp, each dataset is a uniqe PC out there, yes
[08:14] <Cyorxamp> that doesn't help in the slightest
[08:14] <ogra> CarlFK, feel free to design one ;)
[08:14] <Cyorxamp> i'm on about storing the kinds of settings that you would find in a manual
[08:14] <CarlFK> ogra: i just might... was hoping someone had started
[08:14] <Cyorxamp> I don't see what that hwdb is going to achieve
[08:15] <theCore> ogra, are you sure there is no duplicate entries ?
[08:15] <Kamion> Cyorxamp: we don't want to have a big repository of settings
[08:15] <Kamion> Cyorxamp: we want the OS to do it automatically
[08:15] <Cyorxamp> Kamion - why on earth not
[08:15] <Kamion> the point of the hwdb is to let us collect information in order to incorporate it into the OS
[08:15] <CarlFK> Cyorxamp: come back in a few days...I may have what you want ;)
[08:15] <ogra> Cyorxamp, a complete collection of hardware ubuntu runs on.... the settings used to drive that hardware ... a ressource for bugtracking ... etc
[08:15] <Cyorxamp> that makes sense but the initial data the OS needs to be stored some place
[08:16] <Kamion> xorg already automatically deals with a wide range of hardware; bugs linked to the hwdb allow us to track the cases where it doesn't, and hopefully fix them
[08:16] <Cyorxamp> ogra - yeah it makes sense in terms of 'scenarios' for bug help
[08:16] <Cyorxamp> not really same thing
[08:16] <Kamion> a big repository of settings will just mean that everyone relies on that and nobody submits bugs
[08:16] <Kamion> because the repository of settings is the place to go
[08:16] <Cyorxamp> it makes a whole lot more sense
[08:16] <Kamion> "just work" > "look it up"
[08:17] <Cyorxamp> yes it is and the OS should 'just work'  -  damn right!
[08:17] <Cyorxamp> but it can't know everything
[08:17] <Kamion> why not? :-)
[08:17] <ogra> but "look it up" can be a way of making something "just work" ;)
[08:17] <Cyorxamp> yeah
[08:17] <ogra> so we'll probably once aggregate a DB file we shipp for determining settings we cant detect ....
[08:17] <trappist> Kamion: it can, but it doesn't, and "it *should* just work" < "let's find a solution"
[08:18] <ogra> and base for such data shall be hwdb
[08:18] <Cyorxamp> Kamion not to mention I don't see how the data from hwnd can be intergrated to do something useful on a new build of ubuntu to get it to 'just work'
[08:18] <Cyorxamp> *hwdb
[08:18] <Cyorxamp> lol you can tell I have used hwnd in VB alot  :P
[08:18] <CarlFK> ogra: can I get a full entry?
[08:19] <ogra> from the hdwb ? 
[08:19] <Kamion> Cyorxamp: it has to come along with bug reports, of course
[08:19] <Kamion> trappist: sure, but bug reports are a whole lot more helpful in terms of making it work *permanently* rather than enshrining a hack
[08:19] <CarlFK> ogra: "does not show more then some basic data"
[08:19] <ogra> CarlFK, just wget one ;)
[08:19] <Cyorxamp> Kamion - sure but in terms of getting ubuntu to understand that is inside the pc - it's not easily mergable... you'd have to find manufacturer settings anyway
[08:19] <ogra> CarlFK, wget http://hwdb.ubuntu.com/40d275ec209d70a7576b569ab17e9999.xml.bz2
[08:19] <CarlFK> bingo - thanks
[08:20] <ogra> CarlFK, gives you the dataset of my ibook :)
[08:20] <Cyorxamp> thats the whole database?
[08:20] <Cyorxamp> or just one entry?
[08:20] <ogra> just replace the id with what you need
[08:20] <CarlFK> Cyorxamp: just one
[08:20] <ogra> thats one entry
[08:21] <Cyorxamp> CarlFK - i'm getting a few people in other channels asking me if I am doing a project on this and they want to help
[08:21] <Cyorxamp> I certainly do if your up to something here :P
[08:22] <trappist> Kamion: there will always be hardware that doesn't work out of the box that someone has gotten to work, whose fix shouldn't require patching and repackaging software, if it's just a settings issue.
[08:23] <trappist> someone will file a bug, and it will eventually get fixed, but as a user it's nice to not have to wait, potentially for another release of the distro
[08:23] <Cyorxamp> every 6 months :(
[08:24] <Cyorxamp> which granted is much better than some.... but still
[08:24] <LaserJock> trappist: yeah, but it is much less likely to *ever* get fixed if people don't file bugs, etc.
[08:24] <CarlFK> Cyorxamp: watch ... somewhere.... um... im looking at this... i need some time... hours?  um... yeah.
[08:25] <Cyorxamp> CarlFK - well anything you need a hand with just say... want contact details or u think ur ok?
[08:25] <trappist> LaserJock: I can see where you're coming from, but surely you don't want to stick people with non-working hardware unnecessarily, to coax bug reports out of them
[08:25] <CarlFK> Cyorxamp: 
[08:25] <CarlFK> Cyorxamp: email?
[08:25] <Cyorxamp> pm...
[08:26] <Kamion> trappist: I'd be happy to see the information in a database somewhere, provided that it's in a form helpful to those who are responsible for fixing the bugs
[08:26] <Kamion> if it's not in a helpful form, those responsible for fixing the bugs are less likely to look at it, but since "something" exists there'll be little impetus to set up something that really works
[08:27] <Kamion> so I think setting up the first thing that comes to mind without checking with the people responsible for fixing the bugs is actually going to be a net negative
[08:28] <trappist> I for one would file a bug if something failed to work out of the box, but worked after using some other solution.  I'd feel *better* about filing the bug because I could include a solution.
[08:28] <LaserJock> trappist: sure, but a lot of people (most I think) are going to be "Hmm, well that fixed it" and not do anything about it.
[08:29] <mdke> mako, thanks very much
[08:31] <trappist> LaserJock: maybe I'm just a karma whore.  but I think plenty of users are into the whole community thing and are happy for such an easy way to make a real contribution.
[08:31] <LaserJock> I mean from my own personal experience, most people just search the forums for the setting they need and move on
[08:32] <LaserJock> trappist: sure, that is what they get to do with the hwdb
[08:36] <theCore> why XScreensaver has been changed for the GMOME one?
[08:37] <trappist> hrm.  seems there IS a front-end.  tab-completion shows hwdb-gui and hwdb-send.
[08:37] <trappist> theCore: there's a massive thread on the ml that I keep trying to ignore on that subject
[08:37] <theCore> trappist: thanks for the info
[08:38] <Burgwork> Kamion, was the guadelinex UbuntuExpress funded by SoC>
[08:38] <Kamion> trappist: hwdb-gui is the client
[08:39] <trappist> yeah
[08:39] <Kamion> Burgwork: don't think so
[08:39] <Kamion> I might be wrong of course
[08:40] <Burgwork> Kamion, nope is wasn't
[08:41] <theCore> trappist: you are right, that thread is MASSIVE 
[08:45] <Kamion> ogra: -rw-r--r-- root/root     72574 2006-02-23 13:11:33 ./usr/share/edubuntu-docs/software/software/EdubuntuSoftwareBook.html
[08:45] <ogra> oops
[08:45] <Kamion> ogra: that looks like a mistake (software/software, likewise tech/tech)
[08:45] <ogra> thanks 
[09:12] <CarlFK> ogra: do you have any xslt files for the xml?  like to make it all attribute 
[09:13] <ogra> nope
[09:15] <CarlFK> to save me from asking.. have anything that might help me with anything? ;)
[09:17] <ogra> there is a bzr branch of hwdb-client under http://people.ubuntu.com/~ogra/bzr-archive/hwdb-client/
[09:17] <ogra> but apart from that there is only the data and two cgi scripts for the web interface
[09:17] <mdz> ogra: please open a ticket about it; that should be a production service
[09:17] <ogra> ok
[09:19] <CarlFK> the cgi scripts probably have what I need - have them handy?
[09:19] <Cyorxamp> If I don't want to use the bog standard 'ati' driver - and use something better... what can I use given i have a Rage 128 Pro Ultra !?
[09:22] <ogra> CarlFK, the cgi scripts are a handfull of bzgrep wrappers in python, spitting out html
[09:23] <CarlFK> k - I think i follow ;)
[10:27] <MrFaber> hi all
[10:27] <Treenaks> hmm.. NetworkManager 0.6 -- and no way to get it into dapper? (it has wpa support with the latest kernel; might need a newer wpasupplicant too)
[10:28] <MrFaber> Sorry that I ask this way but I and some others have problems with the module-assistant in dapper and it seems quite serious
[10:28] <MrFaber> loop-aes and other modules can't be build and it hasn't been fixed for a long time so I am afraid that the final has still the problem
[10:28] <MrFaber> I have made a bug report some time ago https://launchpad.net/distros/ubuntu/+source/loop-aes-source/+bug/30230
[10:28] <Ubugtu> malone bug 30230 in loop-aes-source "loop-aes module can't be created in Dapper Drake" [Normal,Unconfirmed]  
[10:29] <Treenaks> MrFaber: loop-aes? why not use LUKS and/or other dm-crypt methods?
[10:29] <MrFaber> but it is still unconfirmed
[10:29] <MrFaber> Treenaks, because security but other modules can't be build too
[10:29] <MrFaber> that's why I post it here
[10:29] <MrFaber> loop-aes in Breezy works fine
[10:29] <Treenaks> uh... dm-crypt is more secure than loop afaik.. because loop can destroy your FS afaik
[10:30] <MrFaber> they have the same error with nvidia or fglrx
[10:30] <MrFaber> Treenaks, loop-aes is older than dm-crypt and I haven'T any problems with it until now
[10:30] <MrFaber> I use it for more than one year
[10:30] <Treenaks> MrFaber: dm-crypt reads cryptoloop (older) disks fine
[10:31] <Treenaks> MrFaber: but LUKS is really an improvement
[10:31] <MrFaber> And I like it to change key without repartitionate
[10:31] <Treenaks> MrFaber: that's what LUKS provides for you
[10:31] <MrFaber> Treenaks, loop-aes=cryptoloop
[10:31] <MrFaber> sorry !=
[10:31] <mjr> afaik dm-crypt does not read loop-aes multi-key disks fine
[10:31] <mjr> indeed
[10:31] <MrFaber> mjr, you are right
[10:31] <Treenaks> sounds idiotic.. multiple approaches for 1 thing
[10:31] <MrFaber> Anyone knows something about the module assistant bug?
[10:32] <mjr> and, it seems to me that luks doesn't quite have the paranoia that loop-aes does
[10:32] <MrFaber> mjr, if you are so paranoia to use disk encryption you shouldn't use dm-crypt imho :)
[10:32] <mjr> (the race conditions notwithstanding)
[10:33] <Treenaks> mjr: the race conditions can be quite annoying if they eat your files
[10:33] <mjr> Treenaks, that is not under disbute
[10:33] <MrFaber> Treenaks, I have five partitions in use with loop-aes
[10:33] <mjr> pute
[10:34] <MrFaber> Treenaks, and never lost a file even on shutdown after useing ext3
[10:34] <Treenaks> MrFaber: that still does not prove that there are no races :)
[10:34] <MrFaber> Treenaks, if you use XFS you can't blame loop-aes on real shutdown
[10:34] <MrFaber> Treenaks, loop-aes is much older than dm-crypt so it should be more stable
[10:34] <mjr> what is under dispute is that dm-crypt provides the same level of confidentiality as loop-aes
[10:35] <MrFaber> mjr, if you don't use ECB
[10:35] <MrFaber> dm-crypt at first has only supported ECB
[10:35] <MrFaber> but this is not the problem
[10:35] <MrFaber> the problem is the module assistant imho :)
[10:36] <MrFaber> Can anyone confirm this bug in dapper?
[10:36] <trappist> I can't build it either, but I don't have a full kernel source tree to build against
[10:36] <MrFaber> Treenaks, it is not my bug
[10:36] <Treenaks> MrFaber: stop whining here then
[10:36] <MrFaber> Treenaks, it is dappers bug
[10:36] <MrFaber> Treenaks, and most of my points for loop-aes are facts
[10:36] <MrFaber> Treenaks, do you feel powerful?
[10:37] <MrFaber> I am just here to reporting a bug and you come me with dm-crypt
[10:37] <MrFaber> use what you want
[10:37] <Treenaks> MrFaber: Please go & reed the Ubuntu Code of Conduct. kthxbye.
[10:37] <MrFaber> Other people has the same problem with module assistant while building nvidia and fglrx
[10:37] <MrFaber> which has nothing to do with encryption
[10:38] <MrFaber> *have
[10:38] <trappist> Treenaks: please consider doing that yourself.  he's asking about a bug and you're calling it idiotic that there's more than one way to do something.
[10:38] <MrFaber> I think that this is a serious bug otherwise I haven't point it out here
[10:38] <Treenaks> trappist: I'm suggesting the better supported alternative (in dapper), which doesn't require module building, which avoids the bug. i.e. a workaround.
[10:39] <mjr> Treenaks, ...and forces the old loop-aes users to re-encrypt their filesystems
[10:39] <Treenaks> *headdesk*
[10:39] <trappist> I think that's at best a semi-constructive response to a bug report
[10:39] <MrFaber> Please check the module assistant.
[10:39] <MrFaber> Thanks
[10:39] <MrFaber> Goodbye
[10:41] <Pygi> dholbach: ping
[11:57] <Mez> mdz: ping