[00:45] <TheMuso> crimsun: Is the alsa-driver merge/bzr branch in an uploadable state?
[00:50] <lifeless> ~
[03:32] <superm1> slangasek, how come the current 8.04.1 dailies aren't including the latest kernel images?
[03:32] <superm1> (I've got some hardware that will only boot on the later kernels)
[03:43] <slangasek> superm1: where "dailies" == "live CD", I assume?
[03:44] <slangasek> if so, it's because the livecd build scripts regressed since the last dapper point release; should be resolved with tomorrow's dailies, but I'm still waiting for confirmation from the buildd end that everything's sorted
[03:44] <persia> Are there 8.10 dailies yet?  (with the expectation that they usually fail)
[03:46] <slangasek> of a sort; e.g., http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/xubuntu/latest/livecd-20080610-i386.out
[03:47] <superm1> slangasek, yeah dailies == live cd.
[03:47] <persia> Oh excellent.  Thanks!
[03:50] <crimsun> TheMuso: yes.
[03:50] <TheMuso> crimsun: Did you want it uploaded any time soon, or do you have more to do on it?
[03:51] <mneptok> persia: there's no libc, but that shouldn't matter much.
[03:51] <crimsun> TheMuso: it's fine as is; I no longer have commit access to that branch anyhow.  I'll be making further changes in my own.
[03:52] <persia> mneptok: I wasn't looking for something that worked, only something to understand where we were.  Now I know.
[03:52] <TheMuso> crimsun: Oh right.
[03:52] <mneptok> persia: you sound like the Vista release manager
[03:52] <mneptok> (all apologies to slangasek)
[03:53] <persia> mneptok: My possible resemblance to such mythical creatures is one of the many reasons I'm not part of the release team :)
[03:55] <TheMuso> crimsun: Ok, so short of something I should wait for, I guess I should get it uploaded then.
[07:42] <dholbach> good morning
[07:42] <Hobbsee> dholbach!
[07:42] <dholbach> hi Hobbsee
[07:43] <ion_> Hi
[07:43] <dholbach> hi ion_
[08:13] <dholbach> hey mvo, hey seb128
[08:15] <seb128> hello dholbach
[08:18] <mvo> hey dholbach, hey seb128
[08:18] <mvo> good monring MacSlow
[08:21] <MacSlow> mvo, Mahlzeit
[08:21] <MacSlow> *yawn*
[08:22] <seb128> hey hey mvo
[08:23] <MacSlow> yo seb128, dholbach
[08:23] <seb128> hello MacSlow
[08:24] <seb128> dholbach: no need to add comments now when you subscribe somebody to a bug, just for information ;-)
[08:24] <seb128> "You have been subscribed to a public bug by Daniel Holbach (dholbach)"
[08:24] <seb128> launchpad already send the bug description using that comment
[08:37]  * pwnguin wonders what Moins means
[08:41] <Hobbsee> pwnguin: short version of morning?
[08:41] <Hobbsee> (slang, iirc)
[08:42] <slangasek> northern German slang for morning
[08:44] <Hobbsee> oh, so it's german?  right.
[08:46] <stgraber> morning
[08:47] <asac> moin moin ;)
[08:51] <davmor2> asac: adding wiki inference this time in the morning to be banned as bad taste ;)
[08:52] <asac> haha
[08:55] <dholbach> hi seb128
[08:55] <pwnguin> well, i kinda thought it was something like that, but i thought i'd google it
[08:56] <dholbach> seb128: I scripted that in the meantime - I thought it was friendlier to say "xyz: can you please take a look at it?" :)
[08:56] <seb128> dholbach: ok, makes sense, that was just in case you had a doubt on whether the launchpad bug was fixed now ;-)
[08:56] <dholbach> right :)
[08:56] <dholbach> thanks seb128
[08:57]  * seb128 hugs dholbach
[08:57]  * dholbach hugs seb128 back
[08:57] <\sh> slangasek: the right term in nothern slang (e.g. hamburger platt) is "moin moin"..."moins" means a bit more : "Good morning, dude, how are you this morning?" or in real new world order german slang "hey alder, was geht!" ;)
[08:58] <pwnguin> man
[08:58] <pwnguin> "hamburger platt" just makes me hungry for a plate of hamburgers
[09:00] <\sh> lol
[09:06] <xnv> Is there a general trick to fix the issue of the dev files not being installed where other dev files expect them to be. For instance, glib.h is installed to ../glib-2.0/glib.h, but when I source a library that depends on it, it's expecting it in ../glib.h.
[09:15] <\sh> xnv: setting correct -I lines ... I though glib worked via pkgconfig...so when you use pkgconfig it should catch the right include dir
[09:17] <xnv> \sh: In this case I'm using gsf and virtually all source code I find uses #include <gsf/gsf.h>. However, that's file not found for me.
[09:17] <xnv> \sh: Adding -lgsf doesn't fix that
[09:17] <\sh> -I <-- I as in INCLUDE ;)
[09:18] <\sh> not -l as in library ;)
[09:18] <xnv> \sh: Oh, so I need to do -I/usr/include/whatever for every dependency?
[09:20] <siretart> xnv: try `pkg-config --cflags glib-2.0`
[09:22] <xnv> siretart: So I have to use all of those?
[09:22] <\sh> xnv: libgsf-1-dev installs a /usr/lib/pkgconfig/libgsf-1.pc which is used by pkgconfig...so if you use pkgconfig (example was given by siretart) you should always catch the correct include paths, library paths etc.
[09:23] <siretart> at least if upstream didn't make a mistake here (which happens from time to time)
[09:23] <xnv> OK, it compiles. Thanks guys. I guess I just wasn't expecting my compile command to be longer than the code itself. :-)
[09:24] <siretart> xnv: your compile command doesn't need to be longer. just calculate your CFLAGS correctly in the makefile
[09:25] <xnv> siretart: Hehe, I know. This was a simple enough test that I didn't bother with the makefile though. :-)
[09:25] <xnv> Guess that was a bad idea
[09:26] <siretart> "gcc `pkg-config --cflags --libs libgsf-1` foo.c " should do it as well. which is rather short as well
[09:40] <pitti> Good morning
[09:40] <seb128> hey hey pitti
[09:40] <pitti> seb128: Bonjour, Monsieur? Comment vas-tu? (was that right?)
[09:45] <Hobbsee> pitti!
[09:59] <Keybuk> is "unbekannt" German for "unknown" ?
[09:59] <siretart> indeed
[10:00] <pitti> Keybuk: yes
[10:00] <Keybuk> aha
[10:00] <Keybuk> that explains it then
[10:00] <Keybuk> according to aki-aki, someone with the profile name "unbekannt" followed me all the way from the station to Millbank ;)  but if it's just what it calls unknown people ... I need not get paranoid :p
[10:02] <seb128> pitti: bien merci, et toi? ;-) (oui c'est correct)
[10:02] <pitti> seb128: moi bien!
[10:03] <tjaalton> oo.o-voikko needs to be rebuilt for hardy-proposed, since currently h-p is unusable for Finns (would delete packages). what versioning should be used, just increment buildN?
[10:03] <pitti> Keybuk: ah, Mr. Arno Nym?
[10:03] <pitti> tjaalton: it's currently build2, thus build3 is fine
[10:03] <tjaalton> pitti: roger, so ok for me to upload?
[10:03] <Keybuk> pitti: Arno Nym?
[10:04] <slangasek> moi, je vais ainsi: <dance>
[10:04] <pitti> tjaalton: sure, go ahead; please open a SRU bug and include it in the changelog, thogh (for testing feedback)
[10:04] <tjaalton> pitti: there alread is bug 236248, is that enough?
[10:04] <pitti> Keybuk: common malapropism for "anonym" that looks like a real name
[10:04] <pitti> tjaalton: yes, that's fine
[10:04] <tjaalton> pitti: cool, thanks
[10:05] <pitti> tjaalton: as long as the source.changes has a referenced LP: #1234, all is well
[10:05] <pitti> I'm just strict with rejecting SRUs with no bug # at all
[10:05] <laga> heh. i noticed. :)
[10:07] <Keybuk> pitti: Ah. Mr A. Nonymous
[10:08] <tjaalton> pitti: sounds reasonable. uploaded
[10:11] <\sh> pitti: shame...that my stupid pc here doesn't have an usable usb 2.0 port for the dvb-t stick :(
[10:12] <ogra> Keybuk, are you sure that wasnt RMS with his foiled oyster card so he couldnt be identified ?
[10:31] <pitti> TheMuso, \sh, ScottK, DktrKranz: (CC: tseliot): can you please have a look at bug 239115? WDYT about similar updates in the future?
[10:36] <\sh> pitti: Added preliminary support for X.Org server 1.5. if it's giving us no regression in hardy, fine with me...
[10:37] <pitti> tseliot: ^ ?
[10:37] <DktrKranz> ... and given that we want to support new hardware in LTS releases, I guess it's ok
[10:38] <tseliot> ok, great
[10:38] <tseliot> ﻿pitti: anything you would like me to add?
[10:38] <tseliot> on this topic, I mean
[10:38] <pitti> tseliot: fine for me now
[10:39] <tseliot> ﻿\sh: no regressions here ;)
[10:39] <\sh> tseliot: ok :) I can't test it, no nvidia here :)
[10:40] <tseliot> ok then
[10:40] <\sh> actually, I trust pitti a lot in this case...he worked with alberto to push this thingy in...when I remember correctly
[10:40]  * \sh kicks pykde4
[10:41] <tseliot> ﻿\sh: right ;)
[10:41] <\sh> tseliot: ah...;) now I got your nick <-> name right ;)
[10:42] <\sh> tseliot: btw...good work :)
[10:42] <tseliot> ﻿\sh: thanks. The best is yet to come on Intrepid though :-)
[10:42] <\sh> tseliot: yeah...fix ATI !
[10:44] <tseliot> \sh: that's a task which I will leave to superm1 aka mariolimonciell. I will maintain the Nvidia driver only (together with tjaalton)
[10:44] <tseliot> this is for Intrepid though.
[10:45] <tseliot> I'll deal with the ATI driver on Hardy through envyng.
[10:46] <tseliot> \sh: ATI users won't be left alone ;)
[10:46] <pitti> tseliot: huh, why did it land in NEW>..
[10:47] <tseliot> pitti: ???
[10:47] <pitti> tseliot: ooh, I see
[10:47] <pitti> tseliot: because it's NEW in hardy-proposed
[10:47] <pitti> it isn't in hardy final
[10:47] <tseliot> ok then
[11:13] <dholbach> hi thekorn
[11:13] <thekorn> hi dholbach
[11:17] <Laney> Good morning everyone
[12:58] <Mez> BenC, do you know if there's a fix anywhere in ubuntu for the "adjust brightness hardlocks laptop when using intel chipset for video"
[13:16] <ScottK> Mez: Do you have a bug?  I've got intel chipset and have never had that problem.
[13:17] <Mez> ScottK, it's somewhere in the bug tracker... only started happening with me yesterday. Replaced machine - same thing again.
[13:17] <Mez> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/65027
[13:17] <Mez> alsi now getting device descriptor read/8 error -110
[13:17] <ScottK> Ah.  I'm running Hardy, so no wonder.
[13:18]  * Mez is getting the issue in hardy
[13:19]  * ogra has never had that prob and uses various different intel chipsets over here 
[13:19] <ScottK> Mez: Exactly which Intel video?
[13:19] <ogra> i would blame the broken i810 driver (which shouldnt be used anymore anyway)
[13:20] <Mez> Intel Mobile GM965/GL960 Integrated Graphics controller rev 3
[13:21] <Mez> and it's using /usr/lib/xorg/modules/drivers//intel_drv.so
[13:21] <broonie> I've got what sounds like the same issue with the 945 on Hardy.
[13:22] <broonie> Worked fine with all the releases up until Hardy.
[13:22] <ScottK> Hmmm.  I've got 945 and don't seem to have it.
[13:22] <ScottK> broonie: Which driver are you using?
[13:22] <ogra> 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
[13:22] <ogra> same here
[13:22]  * Mez sighs
[13:22] <broonie> i810_drv
[13:22] <ogra> no probs at all since i installed it
[13:23] <Mez> and for some f**ked up reason... I'm not picking up wireless anymore
[13:23] <ScottK> broonie: Same here.
[13:23] <broonie> This is a Dell D420 laptop.
[13:23] <ScottK> Mine is D430
[13:23] <wgrant> One really shouldn't be using i810 nowadays...
[13:23]  * Mez is getting annoyed at these issues. I thought it was a hardware issue... so I wen and replaced the laptop. This is worse, and makes ubuntu unusable.
[13:24] <broonie> Mine might be a generic resume problem, but it *looks* like video.
[13:24] <ogra> wgrant, there are circumstances where you cant avoid it ... but i generally agree :)
[13:24] <ScottK> Of course I see an update to the driver waiting for me in hardy-updates.
[13:24] <wgrant> ogra: Like?
[13:24]  * ScottK tries it.
[13:25] <ScottK> wgrant: One is that i810 supports xinerama, which, unfortunately, is all that displayconfig supports (so in Kubuntu we are stuck with).
[13:25] <ogra> wgrant, like situations where you need a panning mode instead of multiple display support, i810 still uses old xrandr setup instead of the new one where Virtual is interpreted differently
[13:25] <wgrant> ScottK: Oh dear. I guess this is where a CLI is useful.
[13:25] <Hobbsee> ScottK: wfm on hardy, too
[13:25] <ScottK> wgrant: Yes.
[13:25] <Hobbsee> er, intrepid
[13:25] <Hobbsee> same chipset
[13:26]  * Mez sighs. Mine is not on a resume.. it's ANY time
[13:26] <wgrant> ogra: I think I heard something about that being on the roadmap for RandR 1.3. Or something like that.
[13:26] <ScottK> wgrant: That would take me having a display projector and enough time to make sure it works (e.g. not in the middle of a meeting).
[13:27] <wgrant> Or beating various Kubuntu devs with a stick until they write a RandR 1.2 GUI, I guess.
[13:27] <ogra> wgrant, wll, last time i touched the issue i was told its mutually exclusive ... you either have multi display or pannong
[13:27] <ogra> *panning
[13:27] <ScottK> wgrant: We have one for KDE4.
[13:28] <wgrant> ScottK: Oh good.
[13:28] <ScottK> wgrant: Just getting displayconfig not to catch on fire and burn to the ground on a daily basis was a major accomplishment for Hardy.
[13:28] <wgrant> ScottK: Surely it would have been better and easier to port the GNOME tool to KDE?
[13:29] <ScottK> wgrant: No.  The gnome tool was written with no consideration of providing a different front end.
[13:30] <wgrant> ScottK: Ah. Well, I guess that's RandR's job.
[13:33] <ScottK> JFTR, it wasn't bryce that did it that way either.
[13:36]  * tseliot thinks that RandR GUIs should be written in Python with a backend which could be shared between KDE and GNOME
[13:37] <wgrant> What more backend can be shared than RandR itself?
[13:38] <tseliot> wgrant: writing RandR bindings for Python (RandR is written in C) which could then be used in a Python program that should do most of the work for the 2 GUIs
[13:38] <ogra> wgrant, a python module that doesnt force you to use exec and system or something similar weird in python sctipts would be a good start :)
[13:39] <ogra> ah, tseliot beats me :)
[13:39] <wgrant> ogra: There's no RandR lib?
[13:39] <ogra> not for python
[13:39] <tseliot> ogra: not yet ;)
[13:39] <tseliot> I would like to do it myself in the future
[13:40] <wgrant> One could always right the frontends in something that isn't Python.
[13:41] <ScottK> The KDE4 Xrandr tool is not in Python, if that makes you feel any better.
[13:42] <ogra> if you have one generalized backend used by differen frontends it makes maintenance a lot easier
[13:42] <ogra> the thing is that python is just convenient for such a setup
[13:43] <tseliot> ogra: right
[13:51] <mvo> tseliot: do you know about python-xrandr ? this is a ctypes implementation of xrandr in python
[13:51] <mvo> tseliot: it only lifes in bzr currently, but its not ideal because xrandr needs a lot of setup code etc
[13:51] <tseliot> ﻿mvo: sure, the one made by glatzor and you
[13:52] <mvo> tseliot: best would be to refactor code in xrandr.c to libxrandr that would hide the nasty bits
[13:53] <tseliot> mvo: the problem is that I'm still learning C, therefore I don't know when I'll be able to do this
[13:53] <tseliot> mvo: BTW did you have the time to review my xorg parser?
[13:54] <mvo> still not :( - but its on my list for this week
[13:54] <tseliot> ok
[14:37] <Riddell> jdstrand, kees: any ETA for commenting on the MIRs that pitti asked for an opinion on?
[14:45] <jdstrand> Riddell: what are the bug numbers?
[14:46] <Riddell> https://bugs.edge.launchpad.net/ubuntu/+source/openbabel/+bug/236051
[14:46] <Riddell> https://bugs.edge.launchpad.net/ubuntu/+source/chmlib/+bug/236113
[14:49] <jdstrand> ok, found them in my mail
[14:49] <jdstrand> Riddell, kees: I have several things that I need to push out, so I couldn't look at them until next week.
[14:50] <jdstrand> Riddell: I'm sure kees will respond when he comes online, but we'll coordinate it between us
[14:51] <Riddell> pitti: any ETA for the newer MIRs?  qca, qscintilla and libzip?
[14:52] <pitti> would Friday be ok? will do it together with archive bits
[14:53] <Riddell> not for alpha 1, but I don't suppose that's likely to happen
[14:54] <pitti> not tomorrow anyway, due to LP outage
[14:54] <pitti> Riddell: if it's critical for a1, I'll try tomorrow (or you can try to blackmail doko to do it earlier :-P)
[14:55] <doko> blackmail? depends ...
[14:59] <Riddell> pitti: no more than the other ones which jdstrand won't be doing in time either
[15:03] <tseliot> superm1: these dependencies don't seem to be enough for DKMS: make, dkms, linux-libc-dev, linux-headers. It looks like libc6-dev is required too. (this happens to me on Intrepid)
[15:06] <pitti> tseliot: hm, libc-dev for a kmod?
[15:06] <pitti> that sounds weird
[15:07] <tseliot> ﻿pitti: yes, I can show you the error which I get without that package
[15:07] <pitti> please, I'm interested
[15:11] <tseliot> pitti: here's the content of my make.log in /var/lib/dkms/173.14.05/build/ : http://pastebin.ubuntu.com/19344/
[15:14] <tseliot> ﻿pitti: DKMS no longer complains after I install libc6-dev
[15:16] <superm1> tseliot, are you sure it's not just wanting gcc?  It does seem odd that libc6-dev is all that it needs?  When you install libc6-dev, does it grab dependencies too?
[15:16] <tseliot> ﻿superm1: gcc is already installed. And no, it doesn't grab any dependency
[15:17] <superm1> then nvidia's build system must be looking for it for some reason or another i suppose
[15:17] <superm1> that's a bit unfortunate
[15:18] <tseliot> ﻿superm1: one more dependency, I know...
[15:19] <tseliot> ﻿superm1: the packages are almost finished, they need some testing. I can send you an email if you want to help testing.
[15:21] <superm1> well the intrepid CDs weren't generating
[15:21] <superm1> so testing them ends up a little difficult
[15:21] <tseliot> ﻿superm1: they should work on hardy too
[15:22] <superm1> okay well then go ahead and fire me an email with a PPA to grab them from or similar to mario_limonciello<at>dell.com and i'll give them a shot later today
[15:24] <tseliot> superm1: ok, I'll do it ASAP
[15:24] <kees> Riddell: hello!  I don't see it in email, where was it sent?
[15:27] <kees> jdstrand: you said you found the MIR review requests in your mail?  what're the subjects?
[15:28] <jdstrand> kees: main inclusion ...
[15:29] <cjwatson> superm1: intrepid CDs probably won't work yet, generated or not
[15:29] <jdstrand> kees: they went in my subscribed folder (ie to the folder where ubuntu-security team bug mail goes)
[15:29] <cjwatson> at least not for installation
[15:29] <kees> jdstrand: ah, found it in bug email.
[15:29] <cjwatson> I have some more stuff to upload before that'll be workable
[15:37] <pitti> tseliot: re; looking
[15:37] <pitti> tseliot: oh, I see; that's a configure test
[15:37] <pitti> tseliot: is that really dkms? It looks like the makefile/configure from the driver you are DKMSifying
[15:38] <tseliot> ﻿pitti: yes, right
[15:38] <tseliot> pitti: it's the NVIDIA driver
[15:39] <superm1> cjwatson, how much do you plan on slipping on the alpha then?
[15:39] <cjwatson> superm1: don't know at present, it's on the platform team agenda for tonight
[15:39] <cjwatson> I was unexpectedly off for a week, which didn't help
[15:39] <superm1> tseliot, what pitti is saying is that you can possibly just compile the kernel modules rather than having to run the whole make/configure
[15:40] <superm1> cjwatson, ah.  i hope all is well.
[15:43] <tseliot> ﻿superm1: mmm...
[15:47] <kirkland> pitti: did the auto sync with debian happen yet?
[15:48] <pitti> kirkland: I actually did a run this morning, but it seems that ftp.uk. is out of date
[15:48] <kirkland> pitti: i could use a sync of ecryptfs-utils
[15:49] <pitti> kirkland: I'll do a manual sync then, if it's urgent (download Debian pacakge and dput it)
[15:49] <kirkland> pitti: i don't have upload priv's....  where would I dput it?  REVU?
[15:50] <pitti> kirkland: I'll do it, don't worry
[15:50] <kirkland> pitti: okay, just for clarification, where were you suggesting I dput it?
[15:50] <pitti> kirkland: no, I said I'll do a manual sync
[15:50] <pitti> kirkland: sorry for the delay; I usually don't pay too much attention to which apcakges are autosynced
[15:51] <kirkland> pitti: okay, thanks, sorry to nag
[15:55] <pitti> kirkland: ok, fake-synced
[15:57] <kirkland> pitti: thanks.
[16:00] <tjaalton> pitti: hey, I noticed your post about vdr. aren't the packages in hardy fresh enough?-)
[16:00] <pitti> tjaalton: haven't tried them myself TBH; admittedly it was just hearsay
[16:01] <tjaalton> hardy has the latest stable version, and maintaining the devel-series is a pain since the ABI keeps changing, and plugins should be rebuilt every time that happens (basically for every upstream devel-release)
[16:02] <tjaalton> e-tobi does have a lot of plugins, and I used to use it for my setup, but most of the plugins are pretty bad or dead
[16:03] <tjaalton> so for hardy we (Ng and me) decided to pull some of the more useful ones that debian didn't have
[16:09] <tjaalton> pitti: anyway, he's more than welcome to join the team ;)
[16:11] <DktrKranz> any sponsor for main around to review bug 226783?
[16:15] <luisbg> is there a way to see all the tree of dependencies a package has? like what you can see as dependencies in packages.ubuntu.com, but with also the dependencies of the dependencies
[16:15] <pitti> kirkland: hm, it FTBFSed
[16:17] <pitti> kirkland: ah, bug in libopencryptoki-dev
[16:19] <luisbg> sorry for the above question, should be asked in  #-motu, will talk about it there
[16:26] <_Schattenboxer_> hi
[16:26] <_Schattenboxer_>   wie gehts euch  spackos
[16:26] <_Schattenboxer_>    ihr hurensöhne
[16:26] <_Schattenboxer_>   hr scheis penners
[16:26] <_Schattenboxer_> i
[16:26] <ogra> Hobbsee, ?
[16:26] <_Schattenboxer_>   ausländer
[16:27] <_Schattenboxer_>  kanacken seid ihr
[16:27] <_Schattenboxer_>   sches  ausländer ausrotten muss man euch
[16:27] <\sh> it's nice that he's annoyed...looks like he needs ubuntu in general...
[16:27] <sistpoty|work> !ops
[16:28] <jpds> Hobbsee: ^
[16:28] <ogra> sistpoty|work, well, i didnt want to go that far :)
[16:28] <sistpoty|work> ogra: heh, sorry... but ubotu is so convenient there :)
[16:28] <ogra> yeah
[16:42] <kirkland> pitti: okay, cool, thanks for trying, i'll have a look
[17:28]  * cjwatson attempts to produce a busybox merge that actually lets the system boot
[17:38] <zul> slangasek: ping
[17:47] <james_w> kees: hi. I'm trying to prepare a fix for insight, but it doesn't build on intrepid, due to the embedded copy of gdb not compiling with "-D_FORTIFY_SOURCE=2" (I assume)
[17:48] <james_w> kees: looking in the CVS of gdb the unchecked fgets line is still present, so I'm wondering how gdb itself builds on intrepid.
[17:49] <rubikcube> hi, any idea with respect to which point I wasn't specific enough here? https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/238634
[17:53] <Kopfgeldjaeger> what's a good way using gettext with python? at the moment i compile the files by hand, but i guess i can do that with a debian/rules file
[17:55] <kees> james_w: embedded gdb!?
[17:56] <kees> james_w: that should be removed, I imagine.
[17:56] <james_w> kees: yup, fraid so.
[17:56] <kees> james_w: as for gdb, it probably doesn't -- I bet it was built before the options went in.
[17:57] <kees> james_w: can you rip gdb out of the insight builds?  that's gross.  :P
[17:57] <james_w> kees: ah, sorry, I got confused by lp, they updates in intrepid were pocket copies from hardy-updates
[17:57] <persia> rubikcube: You'd get a better response to queries about bugs in #ubuntu-bugs.
[17:58] <rubikcube> persia: thanks, didn't know about that channel... *quick check* hmm, shouldv've read /topic till the end :-)
[17:59] <james_w> kees: I'd rather not, I just wanted to do an SRU for a simple debian/rules fix. I'm not even sure why it wants to embed it.
[18:01] <kees> james_w: SRU? in that case you're compiling under hardy though, right?
[18:01] <james_w> yeah, but the rules state that it should be fixed in Intrepid first.
[18:02] <kees> james_w: oooh, right yes yes.
[18:03] <ScottK> It doesn't need to be an identical fix though.  You can rip apart then intrepid package all you need to and then just use the minimal change for the SRU.
[18:06] <persia> The goal of the rule is only to make sure that we don't leave a bug unfixed when doing an SRU.  Alternate solutions are encouraged for a wide variety of special classes of bugs.
[19:02] <pitti> seb128: is intrepid a good time to get rid of scrollkeeper? scrollkeeper-update is mad...
[19:04] <laga> will intrepid be using upstart more, eg for gdm?
[19:04] <pitti> seb128: also, I suppose bug 214903 is fixed in intrepid?
[19:05] <ramvi> Hi, what file do I change to change the default applets in the gnome panel when creating a new user?
[19:11] <pwnguin> wait, we can get rid of scrollkeeper?
[19:12] <pitti> pwnguin: I thought rarian was the successor?
[19:12] <pwnguin> ive no idea
[19:12] <pwnguin> but i like the idea of no more scrollkeeper-update
[19:29] <ramvi> ﻿﻿Hi, what file do I change to change the default applets in the gnome panel when creating a new user?
[19:34] <emgent> heya
[19:42] <seb128> pitti: yes and yes
[19:44] <Mithrandir> is it just for me that in current hardy (with updates and all), opening firefox always open the "welcome to ubuntu" page, in addition to the saved pages?
[20:43] <lukehasnoname> echo "hello"
[20:44] <calc> can someone process ooo and ooo-l10n for hardy-proposed (when it shows up) in a few min
[20:46] <psypointer> good evening
[20:47] <psypointer> https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/238974 is the problem which causes this bug already known? this bug causes massive problems when installing via pxe + preseedfile.
[20:48] <psypointer> or is there any way to fix it by myself
[20:48] <cjwatson> psypointer: known and should be fixed in hardy-proposed; use the hardy-proposed images
[20:48] <cjwatson> http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/installer-i386/current/ etc.
[20:49] <cjwatson> it's basically bug 234486
[20:49] <calc> ok ooo/ooo-l10n is waiting for approval now
[20:49] <calc> also whoever has access please pocket copy(?) that to intrepid as well
[20:50]  * calc thinks that is the correct term
[20:50] <psypointer> cjwatson: oh, i'll try the new installer
[20:50] <psypointer> thank you !
[20:51] <cjwatson> psypointer: it's not actually ntfs-3g's fault, FWIW - that's just the current thing that happens to blow up
[20:51] <cjwatson> so just trying to exclude ntfs-3g might well not help anyway :)
[20:51] <psypointer> cjwatson: hm okay, good to know..
[20:54] <cjwatson> I've posted a similar note on the forums
[20:54] <psypointer> great, this will reduce the stresslevel of the other sys admins :) thanks!
[21:10] <xivulon> Mithrandir, hi
[21:10]  * Nafallo tickles Mithrandir 
[21:10] <xivulon> Mithrandir, one of your comments was reported in 230703,
[21:11] <xivulon> is there any plan to fix hibernation?
[21:12] <Mithrandir> to fix hibernation for casper?
[21:12] <xivulon> the issue being that if the initrd mounts a journaled filesystem that was hibernated, once the system resumes from hibernation you get fs corruption
[21:12] <xivulon> I am concerned that there are a few of those situations in place already
[21:12] <xivulon> other than 230703 (which was reverted)
[21:13] <cjwatson> xivulon: please take that to bug 41624, where I have commented
[21:13] <xivulon> cjwatson, thanks, will do that
[21:14] <xivulon> was only wondering if that could be fixed somehow when resuming hibernation rather than preventing other packages from mounting fs
[21:15] <cjwatson> no, it can't
[21:15] <Mithrandir> ideally the fs should have a revision counter of sorts and the hibernation should check the revision counter has not changed when resuming.
[21:15] <cjwatson> there's still potential for data loss there surely
[21:16] <Mithrandir> which would give you some sort of data loss, but if you're already in that situation, it's better than resuming and blasting the fs more or less out of existence.
[21:16] <cjwatson> we can't fix all the other systems in question, though
[21:16] <cjwatson> trivially, Windows
[21:16] <Mithrandir> true.
[21:17] <cjwatson> still potential for data loss> e.g. open applications with unsaved data
[21:17] <Mithrandir> it's in no way a replacement for not replaying journals of hibernated file systems.  It's a recovery mechanism when that has already happened.
[21:21] <ion_> Perhaps each OS (that we can control) should write a per-installation UUID to mounted partitions to say “i have mounted this” and remove it when umounting. Mount could then refuse to write anything to partitions it thinks are mounted by another OS, that is, mount readonly, not replay the journal.
[21:22] <ion_> Someone could even write a program for Windows® that writes such a thing to the filesystems, without needing to modify the actual OS. :-P
[21:23] <ion_> Although what Windows® decides to mount might not be that easy to control.
[21:24] <FabParma> [OT] Does exist a VM/CPU-emulator that can let chooses which cpu (amd or intel) to use into the guest enviroment w/o ties with host hw config? Thank You for help me, Fab
[21:25] <lukehasnoname> fabparma, check #ubuntu-server
[21:25] <lukehasnoname> they might know
[21:26] <lukehasnoname> and it would be on topic there
[21:40] <[cliff]> hi all
[21:40] <[cliff]> I just got home to find out my laptop didn't suspend properly if I remove an USB drive while it's suspending to ram. end result, the bloody machine was carried inside a bag for more than an hour at full throttle. how can I debug this crap so that it doesn't happen again? I'm running hardy (which I refuse to call LTS given the amount of trouble I've had with it)
[21:41] <[cliff]> last useful message in logs is: Jun 11 19:42:00 starfish gnome-power-manager: (cpinto) Suspending computer. Reason: The suspend button has been pressed.
[21:41] <brandon|work> It is still LTS, the amount of trouble you have doesn't dictate the length of support time :-/
[21:42] <brandon|work> and what kind of laptop is it?
[21:42] <[cliff]> brandon|work that's a good point, but it isn't as stable as an LTS should be (my perspective) and I've been using it since 4.10
[21:42] <[cliff]> hp dv1245
[21:43] <calc> slangasek: can you approve the 2.4.1 upload?
[21:43] <stgraber> [cliff]: always depend on the hardware ... I didn't have any single crash on my lappy since Hardy Beta, my uptime is only reset when I upgrade the kernel
[21:43] <slangasek> calc: I rather want to get the current package in -proposed copied to -updates first, if possible...
[21:44] <stgraber> so you can't really say if a release is stable or not, it will always be for some people and won't for others
[21:44] <[cliff]> i'm really open to whatever suggestions you may have. if there's a kernel param I need to set, let me know. if it's an acpi tweak, please tell. what I don't want is for the laptop to blow my back to smithereens :-)
[21:44] <brandon|work> [cliff], have you tried booting with the acpi=off option?
[21:44] <[cliff]> stgraber, yeah, I miss those days too :-) I once had an uptime of 2+months with this very same hardware
[21:44] <Mithrandir> brandon|work: that's hardly a solution for a laptop.
[21:44] <Mithrandir> [cliff]: I'd start by not pulling out hardware while the system is suspending or resuming. :-P
[21:44] <brandon|work> worked with mine for 6.10
[21:45] <stgraber> you said "if I remove an USB drive while it's suspending", what about just not doing that ?
[21:45] <[cliff]> brandon|work no, not really, but I'm giving it a shot
[21:45] <[cliff]> Mithrandir why not fix the software problem instead so that no one else gets to hear of it? :-)
[21:45] <stgraber> removing devices when drivers are unloaded or suspended is clearly not a good idea and I'd expect that to crash ...
[21:45] <calc> slangasek: ok
[21:46] <[cliff]> brandon|work any more suggestions? I'm taking notes so I'll try all of them
[21:46] <calc> slangasek: how do we go about doing that?
[21:46] <[cliff]> brb
[21:46] <slangasek> calc: hmm, maybe I should think twice about that, though, since that means double the bandwidth from users grabbing -updates
[21:46] <calc> slangasek: fwiw the 2.4.1-1ubuntu1 is the same as rc2 except for a few changes in ooo-build
[21:47] <stgraber> we can't lock your USB drive in the socket while the driver is being unloaded, so the kernel panic / oops / ... makes sense to me and the user should just not change their hardware configuration when suspending (I wouldn't do that with any OS actually)
[21:47] <calc> slangasek: they just renamed rc2 to 2.4.1 final since there were no new blockers found
[21:47] <slangasek> calc: ok, I'll have a look at whether that's reasonable to feed into -proposed then, thanks
[21:47] <[cliff]> stgraber, I'm here for solutions mate, not workarounds
[21:47]  * calc will take a look at the ooo-build diff here as well
[21:51] <[cliff]> stgraber, if the kernel ooops shouldn't it be in the logs?
[21:53] <stgraber> when it fails to suspend, does it go back to gnome or just get stuck there and needs rebooting to go back to something usable ?
[21:53] <[cliff]> stgraber, stuck, no keyboard response but video's (at least the monitor) on
[21:54] <[cliff]> only way is to power off
[21:54] <cjwatson> coo, we can sync xkeyboard-config
[21:55] <cjwatson> big pile of patches merged upstream, plus pre-hardy upgrade code ...
[21:55] <stgraber> [cliff]: ok, then if it's a kernel panic, you won't get any debug information logged because the whole system crashed, syslog included
[21:56] <[cliff]> as a side story, I've been muttering about this for a long time now: would you guys, at Canonical, accept donated hardware to perform regression testing? e.g. in a few months I'm retiring this laptop, do you have any QA program for regression testing that would like to receive it (minus hard-drive of course)?
[21:56] <[cliff]> if there is no such QA, would Canonical consider starting one?
[21:56] <lukehasnoname> [cliff] killdisk
[21:57] <[cliff]> stgraber, what about kern.log? does it depend on syslog too?
[21:57] <[cliff]> never mind, i'll check that
[21:57] <[cliff]> yeah
[21:58] <[cliff]> right, you have a point stgraber. almost i'd say... shouldn't the caps/scroll/numlock keys flash when an oops occurs? I remember that happening on desktop systems
[21:59] <stgraber> well, I never had one with 2.6.24 so I don't know :) but I remember of that behaviour with older kernels yes
[21:59] <[cliff]> brb (prep'ing chow)
[22:03] <[cliff]> right, so let me exclude that for now. any idea on how to debug kernel? I remember something had to be turned on to make it accept magic sysrq combos
[22:04] <slangasek> calc: um, clearly this isn't "the same as rc2 except for a few changes in ooo-build", it shows a merge with Debian which brings in various changes to debian/
[22:06] <calc> slangasek: ugh i forgot about that, of the changes in 'Debian' we have bugs about the filter-binfilter, the icon sizes (which why he credited me), so the only change we don't have a bug already is about the broffice bit
[22:07] <calc> i didn't annonate those since they were listed as fixed in the debian part of the changelog
[22:07] <calc> lp#237484 is about the icon sizes
[22:07] <slangasek> there are no LP bug numbers in the Debian part of the changelog
[22:07] <slangasek> which means we can't track them through LP as part of the SRU...
[22:08]  * calc adds the 237484 to sru
[22:08]  * calc sees if he can track down the number for the binfilter one
[22:11] <calc> grr i can't seem to find the binfilter bug :-\
[22:11]  * calc doesn't remember what the filer called it
[22:14] <calc> other one is 234917
[22:15] <calc> both have been marked for hardy and ubuntu-sru subscribed
[22:21] <slangasek> calc: ok - are you intending to re-upload with a fixed changelog, so these are trackable through the available reports?
[22:22] <calc> slangasek: i can if you would like, it takes ~ 1-1.5hr to reupload though on my dsl
[22:22] <slangasek> calc: if you can spare the bandwidth, I would appreciate being able to use our normal tools for tracking the bugs
[22:23] <[cliff]> back... can't jam it again. tried about 10 times, plugging and unplugging usb drive, usb mouse, with power, without power on, also closing lid, with lid open... I'm guessing it happens when some special alignment happens in the universe.
[22:23] <calc> slangasek: ok
[22:23] <calc> slangasek: i can use the same version number for the upload?
[22:23] <slangasek> calc: yes, please
[22:23] <[cliff]> it's not the first time, usually it happens when I leave the laptop on the desk so it doesn't bother me much but having it running so hot inside a bad was "it" for me
[22:23] <calc> ok
[22:24] <[cliff]> so if anyone has more suggestions, please share
[22:24] <calc> slangasek: lp knows to just close the bug for the hardy bit right since i am uploading to hardy-proposed?
[22:24] <compbrain> cjwatson: ping
[22:24] <slangasek> actually, lp won't close it at all, we get to close them by hand :)
[22:25] <slangasek> (we == SRU team)
[22:25] <calc> slangasek: ah ok
[22:28] <cjwatson> compbrain: yes?
[22:29] <compbrain> I'm updating #234486, im hitting a block with kernel/module mismatch with images in proposed/i386/current
[22:32] <cjwatson> compbrain: are you certain they're 2.6.24-16? That's very odd because they're supposed to be -19
[22:32] <cjwatson> compbrain: does uname -r say 2.6.24-16?
[22:34] <compbrain> hrm.
[22:34] <compbrain> This may be a mirroring issue, let me double check
[22:35] <cjwatson> I booted the mini.iso there in kvm, and uname -r says 2.6.24-19-generic
[22:35] <calc> slangasek: uploading now, should be done in an hour or so
[22:35] <slangasek> calc: cheers
[22:35] <cjwatson> however, I do get the kernel module error ... ah
[22:36] <cjwatson> compbrain: -19 isn't in -updates yet, so you need to put "apt-setup/proposed=true" on the kernel command line
[22:36] <compbrain> alright, good to know i'm not going crazy
[22:36] <compbrain> will give that a shot.
[22:36] <compbrain> I can't keep track of all the kernels moving into proposed these days
[22:36] <cjwatson> my bad for forgetting to mention it earlier; I've updated the bug report
[22:37] <compbrain> cheers, thanks for the nudge.
[22:37] <cjwatson> am just confirming the fix now
[22:42] <cjwatson> compbrain: yeah, works for me with that addition
[22:42] <compbrain> I fat fingered the debconf line, giving it another shot
[22:46] <[cliff]> cheer-io-s
[22:51] <compbrain> There needs to be a better way to determine the first bootable disk to install on, as opposed to the first disk detected
[22:52] <cjwatson> compbrain: sadly it's very difficult to extract this from the BIOS
[22:53] <compbrain> Yeah.
[22:53] <compbrain> The sun X4500 is especially fun, where the bootable disks are named sdac and sdy
[22:54] <ogra> you could try to interpret existing mbr's though
[22:54] <compbrain> hacky at best
[22:54] <ogra> indeed
[22:56] <cjwatson> it's not even clear that using the first bootable disk is unambiguously sensible
[22:56] <cjwatson> after all, if you have two disks and one of them already has a boot sector on it, then that clearly already has an OS on it that you might not want to erase; I can see an argument that in that event it would be better to default to the blank disk
[22:57] <cjwatson> in practice, the "first disk" hack in partman-auto is really not intended for any of this
[22:57] <cjwatson> its purpose is to simplify things when you only have one disk to start with
[22:57] <compbrain> thats fair. I'm thinking in the use case of enterprisey blast-an-image-out to all machines technique
[22:57] <cjwatson> on systems with more than one disk, I expect that people doing unattended installations would want to do something more sophisticated and ignore any defaults we set anyway
[22:58] <cjwatson> which they could do with preseed hooks
[22:59] <compbrain> I'm thinking something like 'user left a sd card in the reader' or had an external backup drive connected
[23:05] <pwnguin> someone filed aboug about leaving a usb drive in accidentally; i cant remember the resolution
[23:14] <compbrain> cjwatson: Everything works out with the apt-setup config item. Much thanks, again
[23:15] <cjwatson> compbrain: good stuff
[23:15] <cjwatson> compbrain: can you put that in the bug log if you haven't already, so that it can be considered for hardy-updates?
[23:16] <compbrain> Yup.
[23:31] <YokoZar> How do I make a "post from the developers" comment on brainstorm?
[23:32] <ajmitch> jcastro would know
[23:35] <jcastro> YokoZar: tell nand or stgraber that you'd like to get developer access and they'll set you up.
[23:36] <YokoZar> stgraber: I'd like Brainstorm developer access ;)
[23:39] <james_w> YokoZar: they need your numeric user id, if you don't know it log in and click your user name.
[23:39] <YokoZar> 10632
[23:42] <stgraber> jcastro: you should remember we both in the CEST timezone (00:40) so not very likely to answer at that time of the day :)
[23:42] <stgraber> YokoZar: done
[23:42] <YokoZar> stgraber: thank you :)
[23:42] <jcastro> stgraber: ah ok, next time I'll just have them send you mail
[23:43] <stgraber> that remains me I really should spec that LP integration bit and move everything to OpenID :)
[23:44] <kirkland> is there a "proper" way for a script to write to /etc/fstab?
[23:44] <kirkland> ie a library, or another program, or script, or such?
[23:48] <kirkland> kees: ^^ ?
[23:49] <kees> kirkland: uhm
[23:49]  * kees ponders
[23:49]  * ogra doesnt think something like that exists
[23:49] <kirkland> kees: see 'man fstab'
[23:49] <kirkland> i'm concerned about "fstab is only read by programs, and not written"
[23:50]  * kees punts to slangasek or others deeply familiar with conf file management
[23:50] <kirkland> kees: good call.... slangasek?
[23:51] <slangasek> if by "script" you mean "package", then no there's no proper way to write to it :)
[23:51] <slangasek> but of course, /etc/fstab itself is created by the installer, so you can probably steal info from there
[23:52] <kirkland> slangasek: no, by script i mean a shell script I'm working on for setting up per-user ~/Private encrypted directories
[23:52] <kirkland> slangasek: I need to add an fstab entry for those
[23:52] <kirkland> slangasek: I have shell code that works, but I was checking to see if there was any existing API
[23:52] <slangasek> API> nope
[23:53] <ogra> does it really need to be in fstab ? how about using gnome-mount instead ?
[23:53] <kirkland> slangasek: kthx
[23:53] <kirkland> ogra: what about server installs with no gnome?
[23:53] <ogra> (surely needs some hal integration though)
[23:53] <kirkland> ogra: i think for non-root users to be able to mount, it MUST be in fstab
[23:54] <kirkland> ogra: see "man mount" for that one
[23:54] <ogra> well, there is pmount (for which pitti would be reluctant to get it back to main though)
[23:55] <kirkland> ogra: interesting, never heard of pmount... what's wrong with it?
[23:55] <ogra> kirkland, i know how it is, i wrote a lot of ltspfs which needs to deal with such issues a lot
[23:55] <ogra> its been replaced by gnome-mount in ubuntu
[23:55]  * kirkland offers an empathy hug to ogra
[23:56] <ogra> and pitti was happy to let it go and not have to maintain it ... but ideed there is no gnome-mount on servers
[23:57] <kirkland> ogra: yeah, that's a bummer, we need to be able to do this with/without gnome
[23:57] <ogra> but mangling fstab is/can become quite dangerous
[23:58] <compbrain> cjwatson: You wouldn't happen to know what the kernel command line length limit in the netboot kernels is would you?