[12:16] <seb128> can we mark specs rejected or something like that?
[12:16] <seb128> https://blueprints.launchpad.net/distros/ubuntu/+spec/ubuntu-secure-gdm by example
[12:16] <seb128> that's a spec about building gdm with --enable-secure-remote
[12:16] <seb128> which is not a spec topic, just a wishlist bug
[12:31] <Keybuk> no, I believe that was removed
[12:42] <keescook> oooh, sneaky, clamav 0.88.2 takes the upstream patch cleanly... but doesn't fix the problem.
[12:53] <jdub> bhale: gosh, nautilus does *seem* faster.
[12:59] <bhale> jdub: by a lot
[01:18] <jdong> ooh, you can't say no to specs! yay!
[03:11] <shaya> Q. about changelog.Debian.gz, it doesn't seem to track ubuntu changes well
[03:11] <shaya> as the ubuntu log is constantly dumped in resync'ing w/ debian
[03:12] <shaya> why is that?
[03:16] <keescook> shaya: if the current version of the program has no Ubuntu changes in it, then it won't show prior ubuntu changes that were made but more recently dropped.
[03:21] <shaya> yes, but there are versions, such as gnome program (2.17~) that dont have any debian changes as there are no debian versions of them
[03:21] <shaya> so the changelog history is lost
[03:28] <keescook> shaya: I'm not sure I understand what you're describing.  do you have a example package?
[03:28] <keescook> 2.6.20-1> has anyone tried to burn a CD with it?
[03:31] <shaya> vino
[03:38] <keescook> BenC: ^^ did you try cd burning?
[03:38] <BenC> not yet, but I haven't heard anything about it not working
[03:39] <keescook> shaya: I see vino's changes in /usr/share/doc/vino/changelog.Debian.gz
[03:39] <keescook> BenC: okay, hm, once my two builds finish, I'm going to reboot to .19 and see if this comes back.  so many things have changed on my system... it's been a while since I burned a CD.  :)
[03:43] <shaya> keescook: wat version do you see?
[03:43] <shaya> I see 2.17.4-0buntu1 and 2.16.0-3
[03:44] <shaya> but there were ubuntu versions between them
[03:49] <keescook> shaya: I think the reason is because the prior version of vino was entirely packaged by debian.  So when the package got merged with the debian vino, all the only-in-ubuntu changelog entries went away, since only the changes from debian are relevant any more.
[03:49] <mjg59> Right
[03:50] <mjg59> The changelog is there to tell you about the history of the branch of code that ended up in that package
[03:50] <mjg59> Not about every change made to every branch that we ever shipped
[04:00] <shaya> except that ubuntu shipped 2.17.2....
[04:01] <mjg59> And then dropped the Ubuntu branch and re-adopted the Debian one
[04:01] <shaya> ok
[04:01] <shaya> seems weird to me
[04:01] <shaya> means bug closing gets lost
[04:01] <mjg59> The alternative would be that whenever we re-merge with Debian, we need to carry around an extra Ubuntu changelog
[04:01] <mjg59> Even if the package is otherwise identical
[04:05] <shaya> would that be so bad?  use changelog.Debian to keep the changelog for the "branch" while changelog.Ubuntu would keep the ubuntu change history.  If none for a specific version, it be empty
[04:06] <mjg59> It means that any package that's ever diverged in Ubuntu would be divergent forever
[04:06] <mjg59> Which is less than ideal
[04:10] <bddebian> shaya: It would kill us in Universe where we have few resources and TONS of packages
[04:12] <shaya> hmm, mjg59 then perhaps (version)Ubuntu* should be extracted and stored somewhere?
[04:13] <ajmitch> all the previous versions are still on launchpad, I believe
[04:13] <ajmitch> so the history is there
[04:13] <shaya> but easy to view?
[04:13] <shaya> or version by version?
[04:13] <shaya> which is somewhat annoying
[04:13] <ajmitch> each version, and there are changelogs
[04:13] <shaya> I understand
[04:13] <ajmitch> not the most discoverable, but that's LP
[04:13] <ajmitch> it's slowly getting some UI love
[04:14] <keescook> BenC: yeah, on .19 I can burn again.  cdrdao disk-info on .20 reports CDRs have 0 bytes available for writing.  :)
[04:16] <Solarion> any gnumeric people here/
[04:16] <Chipzz> Solarion: highly unlikely
[04:17] <LaserJock> Solarion: gnumeric people as in?
[04:17] <Chipzz> I suppose he's referring to upstream?
[04:18] <LaserJock> ah, I doubt it
[04:18] <Solarion> no, I mean packaging people.
[04:18] <Solarion> I'd like to know why edgy is stuck at 1.7.0
[04:19] <LaserJock> Solarion: stuck?
[04:19] <BenC> keescook: Is that 2.6.20-2.2?
[04:20] <Solarion> LaserJock: is half a year old
[04:20] <Chipzz> Solarion: not quite that old, yet :)
[04:20] <Chipzz> 4 months, hardly
[04:20] <Chipzz> ftp://ftp.gnome.org/pub/gnome/sources/gnumeric/1.7
[04:20] <Solarion> May
[04:20] <keescook> BenC: 2.6.20-1-generic, I will go update.  Also: burning actually works, it's just the information query that seems to fail.
[04:20] <LaserJock> well, that's what it was when Edgy was released
[04:20] <Chipzz> oh
[04:21] <LaserJock> basically that's the way it goes
[04:21] <Chipzz> that's MM/DD/YY
[04:21] <Chipzz> how confusing
[04:21] <Solarion> I guess I can live with that.
[04:21] <Solarion> Chipzz: yeah.  It's teh suck
[04:21] <BenC> keescook: Interesting, let me know the result of -2
[04:21] <LaserJock> we can request backports
[04:21] <Solarion> hey keescook
[04:21] <_MMA_> I get some burning issue also. "(gnomebaker:6657): libglade-WARNING **: could not find signal handler 'gnomebaker_on_format_dvdrw"
[04:22] <Chipzz> Solarion: oh btw
[04:22] <Chipzz> it is not "stuck" on 1.7.0
[04:22] <Chipzz> latest version is 1.7.5 in feisty
[04:22] <Chipzz> gnumeric (1.7.5-1ubuntu1) feisty; urgency=low
[04:22] <Chipzz>   * Merge with debian experimental:
[04:22] <Chipzz>     - debian/control, debian/*-gtk-*, debian/rules,
[04:22] <Chipzz>       debian/shlibs.local: Xubuntu changes for
[04:22] <Chipzz>       gtk/gnome multibuild.
[04:22] <Chipzz>     - run intltool-update in po*
[04:22] <Chipzz>     - Build Depend on intltool
[04:22] <Chipzz>  -- Gauvain Pocentek <gauvainpocentek@ubuntu.com>  Wed,  6 Dec 2006 13:55:23 +0100
[04:25] <Chipzz> Solarion: basically, the definition of a release is that software that is "released" has a low tendency of changing.
[04:25] <Chipzz> except for security updates and stuff like that
[04:28] <derekS> fabbione: ping
[04:28] <fabbione> derekS: pong
[04:28] <derekS> fabbione: i noticed a while ago you filed bug 73425 and it was set to low priority... is there a fix that you found?
[04:28] <Ubugtu> Malone bug 73425 in udev "warning at boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73425
[04:29] <derekS> it makes my system almost non-useable
[04:29] <derekS> (as a desktop)
[04:29] <fabbione> derekS: no, i didn't check for a fix and it's just a warning.
[04:29] <fabbione> it doesn't affect any functionaility
[04:29] <derekS> fabbione: it makes the mouse not work :)
[04:29] <fabbione> derekS: works here. the problem might be something else
[04:30] <fabbione> and you see a warning for other reasons
[04:30] <fabbione> added a comment to the bug
[04:30] <fabbione> your problem is different
[04:30] <derekS> fabbione: i am pretty sure it is the same bug :)
[04:30] <fabbione> so don't mix any more info with that
[04:31] <fabbione> i am pretty sure it's not
[04:31] <derekS> alright, i will keep searching
[04:31] <fabbione> file another one
[04:31] <fabbione> check the data coming from the mouse port
[04:31] <derekS> fabbione: i filed another one, but then set it to duplicate
[04:31] <derekS> fabbione: well, i am not sure how to do that :)
[04:31] <fabbione> i don't have time now to debug it with you
[04:31] <fabbione> check if it works with a different kernel
[04:31] <fabbione> for example
[04:32] <fabbione> if that solves the problem, you know who to blame
[04:32] <derekS> fabbione: it doesnt, problem has been around since like 2.17...
[04:32] <derekS> kernel people said it was udev :)
[04:33] <fabbione> derekS: that warning is new in feisty
[04:33] <fabbione> if your problem is older than it's not udev
[04:33] <fabbione> gotta go
[04:33] <fabbione> later
[04:33] <derekS> hmm, ok... i will look around on how to fix it...
[04:33] <derekS> thanks for your help
[04:36] <Solarion> Chipzz: you'll note the word "edgy" in my posting and "feisty" in yours.
[04:36] <Solarion> Hence edgy *is* stuck at 1.7.0
[04:37] <Chipzz> for your definition of 'stuck' ofcourse ;)
[04:37] <Solarion> umm
[04:37] <Solarion> is it going to go higher than 1.7.0?
[04:37] <Chipzz> depends if the maintainer is willing to backport it
[04:38] <Solarion> then until that point it is stuck at 1.7.0
[04:38] <Chipzz> but since it also requires a higher version of goffice
[04:38] <Chipzz> no, it is not
[04:38] <Chipzz> read the definition of "release"
[04:38] <Solarion> maybe for your definition of "stuck"
[04:38] <Chipzz> releases don't get stuck, they get released :)
[04:38] <Chipzz> subtile difference :)
[04:39] <Solarion> bah, this is semantic wanking
[04:39] <Chipzz> no it's not
[04:39] <Solarion> it centers around the precise meaning of the word "stuck"
[04:39] <Chipzz> if releases were to upgrade to the latest versions of everything after they are released, they wouldn't be called releases now, would they? ;)
[04:40] <Solarion> umm, yes they would be.
[04:40] <Chipzz> what I'm trying to say is that "stuck" is the wrong way of looking at it
[04:40] <Chipzz> no they would not
[04:40] <Chipzz> releases require a specific version in order to be able to give support on that release
[04:41] <Chipzz> if you're constantly upgrading, you're unable to support it
[04:41] <Chipzz> hence 'release'
[04:41] <Chipzz> bottom line is, if you want a higher version of gnumeric, either file a bug report requesting a backport (kinda unlikely to happen IMVHO), or upgrade to feisty
[04:44] <Solarion> I can build my own; I was just curious why it was so old.
[04:44] <Chipzz> most likely it'll be easiest of you add deb-src lines for edgy
[04:45] <Chipzz> Solarion: does the new version of gnumeric fix a severe bug?
[04:45] <Chipzz> because if it does, the chances of getting a new release are significantly higher
[04:45] <Solarion> I dunno
[04:45] <Solarion> maybe? :)
[04:45] <Solarion> Chipzz: I need to access it for my own nefarious purposes, so deb-src is insufficient
[04:45] <Solarion> I was just curious why it was so old
[04:46] <Solarion> I haven't looked to see if any major fixes were in.  I suspect so, but I'm not certain
[04:46] <Chipzz> depends on your definition of building of course ;)
[04:46] <Hobbsee> Chipzz: they add in a patch for the fix, FYI - not the entire new version
[04:46] <Solarion> Hobbsee: problem is that lots of fixes go "upstram" into libgsf,goffice
[04:46] <Solarion> so it's not quite so simple.  :)
[04:46] <Chipzz> Hobbsee: depends; there was a discussion about a new version of evince several weeks ago in which a new version of evince was suggested instead of just that fix
[04:46] <Chipzz> Hobbsee: but basically, you're right
[04:47] <Hobbsee> ah
[04:47] <Chipzz> depends on how big the delta is I suppose
[04:48] <Chipzz> but I think (not sure), that 1.7.x is a development release
[04:48] <Chipzz> given the odd minor number
[04:51] <Solarion> yes
[04:51] <Solarion> I was wondering why it was chosen over 1.6.x
[04:53] <Chipzz> Good point; not sure really
[04:53] <BenC> Solaris: Because if they went with 1.6.x you would have complained more about the age? :)
[04:58] <Solarion> Solarion: it's a devlopment version, so no
[04:58] <Solarion> I understand wanting stability
[04:58] <Solarion> but if you go for broke.... :)
[06:20] <keescook> BenC: hey, neato.  2.6.20-2.2 solved the CDR info issue.  :)
[06:21] <BenC> keescook: Gotta love that :)
[07:35] <cypher1> can anyone pls tell what is this december 21st deadline for "Outstanding Merges" ?
[08:01] <lifeless> BenC: can we get a virtual package for linux-image-generic-debug, like we have for linux-image-generic ?
[09:41] <dholbach> good morning
[10:07] <cypher1> dholbach: good morning ! :)
[10:07] <dholbach> hey cypher1
[10:08] <cypher1> dholbach: how are you ?
[10:09] <dholbach> thanks a lot... I'm fine - how are you?
[10:23] <cypher1> dholbach: fine here too although lot of work ;) .. thanks :)
[10:24] <dholbach> I know the feeling ;-)
[10:40] <cjwatson> seb128: rejecting specs> Change status -> Definition status: Obsolete
[10:41] <cjwatson> seb128: (and a status whiteboard comment about why)
[10:41] <seb128> cjwatson: ok, thank you
[11:34] <seb128> ogra: new gnome-screensaver (2.17.4) to package
[11:41] <mneptok> seb128: ooo! gnome-screensaver!
[11:41] <seb128> mneptok: ooo! new GNOME ;)
[11:41] <mneptok> seb128: i probably should have written a mini-spec, but how about making the default 'saver in Feisty "blank screen"
[11:41] <elmo> flying pony module!11!
[11:41] <seb128> mneptok: why?
[11:42] <mneptok> seb128: because when it's set to an OpenGL saver (like it is by default) it completely crashes machines with poor drivers. also, it makes no sense on laptops to go into a mode that consumes *more* power when not being used.
[11:42] <mneptok> seb128: my GF's machine uses the VIA video driver. the default screensaver completely kills X.
[11:43] <Ng> a pure black screen might be a big confusing, but something very light (ubuntu logo skipping around the screen slowly) would be good
[11:43] <seb128> mneptok: there is a spec about using opengl hacks only where it makes sense I think
[11:43] <seb128> mneptok: ogra was supposed to work on that for edgy
[11:43] <mneptok> k
[11:43] <seb128> maybe he'll for feisty
[11:43] <Ng> fyi, the glslideshow screensaver is both pretty and very light on resources afaics
[11:43] <mneptok> Ng: agreed. a low-resource floating image would be great.
[11:43] <seb128> mneptok: any problem using a non-opengl hack by default? ;)
[11:44] <mneptok> seb128: only that in the case of laptops and servers the best screensaver is none at all.
[11:44] <mneptok> (of course, servers shouldn;t have a GUI, but these are Ubuntu users ...) ;)
[11:45] <thom> Ng: the BSD  ascii art daemon console screensaver?
[11:45] <thom> something like that'd be keen
[11:45] <seb128> mneptok: well, no screensaver is not nice, I like images slideshow by example
[11:46] <mneptok> or the blinkenlights Star Wars :)
[11:46] <mneptok> you know, i have never actually watched that all the way through.
[11:47] <mneptok> having a girlfriend and other outside interests really puts a crimp on the uber0geek lifestyle
[11:48] <seb128> mneptok: I don't use a screensaver here :p
[11:48] <seb128> mneptok: I just think users will like something on screen better than a blank screen
[11:51] <mneptok> seb128: i'll look into something that is both Ubuntu-quality good looking, and resource light.
[11:52] <mneptok> what a concept. maybe if it catches on we could actually *do* something with this open source stuff.
[11:52] <mneptok> ;)
[11:55] <mneptok> lol. the Matrix screensaver has a "KNOPPIX.RU" ad in it
[11:56] <Fujitsu> mneptok, of course!
[11:57] <mneptok> classy.
[12:03] <infinity> cjwatson: Dailies back on.  And with only a 23 hour response time, too!
[12:03] <jono> imbrandon: yo
[12:05] <cjwatson> infinity: great, thanks
[12:05] <cjwatson> heh
[12:05] <cjwatson> you're on holiday, I can cope with long response times
[12:11] <gpocentek> ogra: are ltsp-server{,-standalone} uninstallable on edubuntu daily builds, or is it a xubuntu issue?
[12:12] <gpocentek> ok...
[12:13] <gpocentek> ogra: hello!
[12:13] <gpocentek> ogra: are ltsp-server{,-standalone} uninstallable on edubuntu daily builds, or is it a xubuntu issue?
[12:17] <infinity> cjwatson: Hey, it was (barely) less than a day, I'm pretty happy with that. :)
[12:22] <pitti> hello
[12:23] <imbrandon> moins pitti 
[12:43] <cjwatson> sivang: are you going to merge bittornado, moin, and libnotify? your name's listed against them on http://merges.ubuntu.com/main.html
[12:44] <pitti> sivang, cjwatson: ^ I'm fine with taking libnotify if I shall
[12:44] <cjwatson> libnotify is only an updated merge, so is less urgent than your other ones
[12:59] <pitti> cjwatson: I did the apport API changes in ubiquity trunk; is there an easy way to call the gtkui from the source tree without booting a live CD and everything?
[12:59] <pitti> cjwatson: the change is trivial and I'm fairly sure that it works, but still, I'd like to test it a bit
[12:59] <pitti> hi Hobbsee 
[01:06] <cjwatson> pitti: not very easily, unfortunately
[01:06] <cjwatson> pitti: you could build a package from it and install that, and then run it ...
[01:06] <pitti> cjwatson: that's fine
[01:06] <cjwatson> pitti: (remember to 'debian/rules update' first if you're building straight from bzr)
[01:06] <pitti> oh, thanks, didn't do that
[01:07] <dholbach> X love!
[01:07] <cjwatson> pitti: you'll also need to bzr update right before committing, as I've been pushing a few changes this morning
[01:07] <rodarvus> :)
[01:07] <rodarvus> finally!
[01:07] <dholbach> yeeeeha
[01:07] <rodarvus> packages are mostly done, I'm hoping to upload all of them today
[01:08] <rodarvus> (but I messed my .changes, so am carefully checking each of them as I go)
[01:09] <cjwatson> rodarvus: thanks
[01:12] <cjwatson> infinity: mind if I steal your bogl merge?
[01:12] <cjwatson> infinity: and ndoc and scim?
[01:13] <Hobbsee> cjwatson: isnt he away?
[01:13] <infinity> cjwatson: Go nuts.  Feel free to give all my merges away.
[01:15] <cjwatson> Hobbsee: so ner ;)
[01:16] <cjwatson> infinity: ta
[01:16] <cjwatson> mdz asked me to be actually-getting-merges-done czar, so I plan to spend a good chunk of today nagging people ...
[01:18] <Hobbsee> infinity: you're on holidays!  go away!  stop proving me wrong!  :P
[01:20] <mneptok> lick me too! LICK ME TOO!
[01:21] <Hobbsee> mmm...postage stamps....
[01:21] <Hobbsee> tasty :)
[01:23] <Simira> mneptok: hey, are you the "new" distro-guy?
[01:23] <mneptok> uhhh ... no?
[01:23] <mneptok> am i?
[01:23] <Simira> mneptok: but you just started working for Canonical, right?
[01:23] <Simira> mneptok: trying to keep up on who's who....
[01:23] <mneptok> if by "just" you mean "6 months ago" then yes :)
[01:24] <Simira> mneptok: right :p I didn't attend Paris
[01:24] <Hobbsee> mneptok: if you're getting paid by them, then you're probably working for them
[01:24] <Simira> hi Hobbsee, how are you?
[01:24] <mneptok> Hobbsee: not on distro, though. AFAIK.
[01:24] <Hobbsee> i'm doing OK :)
[01:24] <Hobbsee> mneptok: ah.  what do you do, apart from hang around on IRC?
[01:24] <Simira> mneptok: what, then?
[01:25] <Simira> ah
[01:25] <Hobbsee> so we blame mneptok when it all goes wrong?  excellent!
[01:25] <Simira> Hobbsee: nonono, he's the one you can whine to and who will help you when all goes wrong
[01:25] <Hobbsee> Simira: ahhh...
[01:25] <mneptok> no, you blame me when it all goes wrong, the package is in Main, you have purchased a support contract, and we can't help you. :)
[01:26] <Hobbsee> mneptok: why havent you fixed all the bugs yet!!!!
[01:26] <mneptok> Hobbsee: because you still haven't pruned that hedge that blocks the view to your boudoir from the oak tree in the back yard.
[01:26] <Simira> ah, I love my dog when he is sleeping... everything is much more quiet then.
[01:27] <mneptok> i mean, i buy binoculars, and nothing. NOTHING! *sigh*
[01:27] <Hobbsee> hehe
[01:27] <Hobbsee> mneptok: get better glasses
[01:27] <mneptok> Hobbsee: but then i'll have to acknowledge what i *really* look like! allow me my illusions.
[01:27] <Hobbsee> heh
[01:32] <pitti> cjwatson: apport API fix tested and committed (yay, my first ubiquity commit)
[01:33] <pitti> hey siretart_ 
[01:34] <siretart_> :)
[01:34] <Fujitsu> apport API fix... to Ubiquity? Am I missing something here?
[01:34] <pitti> Fujitsu: yesterday I cleaned up apport's code/module structure
[01:34] <pitti> Fujitsu: and ubiquity uses apport for crash reporting, too
[01:35] <Fujitsu> Ah, that makes more sense now :)
[01:39] <cjwatson> pitti: thanks
[01:46] <\sh> sorry guys, could be that this was answered on some of our MLs but what is the work order for diffs between ubuntu and debian regarding firefix/iceweasel thunderbird/icedove?
[01:46] <cjwatson> "work order"?
[01:47] <\sh> how to change the build-deps e.g. is there any policy?
[01:48] <cjwatson> \sh: nothing formal as far as I know, but as long as firefox satisfies the dependencies it should be fine
[01:48] <cjwatson> (or thunderbird, or whatever)
[01:48] <\sh> so changing build-deps from iceweasel to firefox...
[01:49] <cjwatson> as usual, do the minimum necessary to make it work and reduce merge pain in future
[02:35] <cjwatson> Keybuk: an indicator on merges.ubuntu.com for when the person listed as owning the merge isn't in the relevant LP team would be useful
[02:41] <Keybuk> cjwatson: and impossible to find out
[02:44] <Chipzz> \sh: doesn't debian use the standalone gecko rendering instead of firefox anyway?
[02:44] <Chipzz> what's the bloody thing called again...
[02:45] <cjwatson> Keybuk: why?
[02:45] <cjwatson> Chipzz: xulrunner. yes.
[02:46] <Keybuk> cjwatson: getting a list of e-mail addresses out of LP for a team is HARD
[02:46] <Chipzz> yeah that one :)
[02:48] <Keybuk> cjwatson: note that sysvinit is deliberately not merged, btw
[02:51] <cjwatson> Keybuk: heh, sorry, I missed that you'd already posted a merge warning to ubuntu-devel and posted something similar to ubuntu-devel-announce
[02:51] <cjwatson> Keybuk: what's up with sysvinit?
[02:55] <Keybuk> cjwatson: we're replacing much of it for replacement-initscripts
[02:58] <cjwatson> Keybuk: ok ...
[03:01] <Keybuk> cjwatson: a large portion of the Debian changes are ...different... attempts at merging our changes
[03:01] <Keybuk> so it's a very sticky merge
[03:01] <Keybuk> I'd rather just write the startup-tasks job definitions by reading both, than trying to read a single merged shell script that may be broken
[03:03] <Keybuk> it also has an extraordinarily questionable change to the behaviour of sysvinit!
[03:04] <sivang> cjwatson: I'm happy to do libnotify as well if pitti hasn't already done it
[03:05] <cjwatson> sivang: please coordinate with him
[03:05] <sivang> cjwatson: will do, thanks
[03:05] <pitti> sivang: go ahead
[03:25] <ogra> BenC, 2.6.20 behaves very badly for me with bcm43xx
[03:26] <BenC> ogra: Yeah, it's a known bug (if you mean an oops) that is patch pending
[03:26] <ogra> ah, cool
[03:26] <ogra> i resorted to 2.6.19 for now ...
[03:27] <BenC> cjwatson: I'm going to look over kernel-{wedge,package}, but I'm sort of inclined to not merge them if there's nothing in there that we need
[03:28] <BenC> they always give me so many problems after merge that never gets noticed till the kernel gets built against them, then I have to fix kernel-{package,wedge} and reupload kernels to get it fixed
[03:30] <imbrandon> heh
[03:30] <imbrandon> man i fsk fried my mb on my bday ( today ) , i guess i know what 'm getting today
[03:32] <Chipzz> BenC: btw, is it known that drivers with firmware don't work on boot?
[03:32] <BenC> Chipzz: You mean during the initramfs phase?
[03:32] <Chipzz> BenC: I have a laptop with ipw2200 chipset, and neither 2.6.19 nor 2.6.20 kernels load the firmware on boot
[03:32] <BenC> Chipzz: sounds like a udev issue, I'd file a bug there
[03:32] <BenC> firmware works for me with ipw3945
[03:33] <Chipzz> it does work wif I rmmod ipw2200; modprobe ipw2200 when my laptop is booted
[03:33] <Chipzz> s/wif/if
[03:33] <BenC> is ipw2200 getting loaded during initramfs for some odd reason?
[03:33] <Chipzz> I have no idea really
[03:33] <Chipzz> haven't looked at it in detail yet
[03:33] <BenC> Chipzz: hold a sec...
[03:35] <BenC> Chipzz: zcat /boot/initrd.img-`uname -r` | cpio -i -t  | grep ipw2200
[03:36] <Chipzz> root@Reel:~# zcat /boot/initrd.img-`uname -r` | cpio -i -t  | grep ipw2200
[03:36] <Chipzz> lib/modules/2.6.20-2-generic/kernel/drivers/net/wireless/ipw2200.ko
[03:36] <BenC> Chipzz: grep ipw2200 /etc/initramfs-tools/modules
[03:37] <Chipzz> BenC: I have:
[03:37] <Chipzz> MODULES=dep
[03:37] <Chipzz> in /etc/initramfs-tools/initramfs.conf
[03:37] <Chipzz> could that be the cause?
[03:37] <BenC> ah, that's why then
[03:38] <Chipzz> hrrrm
[03:38] <Chipzz> pebkac? :)
[03:38] <BenC> Change it back to "most", and "sudo update-initramfs -u -k `uname -r`", that should fix it
[03:39] <BenC> In future kernels, the module will be able to list what firmware it needs, and initramfs-tools will be able to copy needed firmware
[03:39] <Chipzz> can I blacklist ipw2200 from getting in the initramfs?
[03:40] <Chipzz> s
[03:40] <BenC> You can probably do that, but unless you have a specific reason for not doing "most", I'd change that back
[03:40] <cjwatson> BenC: I'm not too concerned about those, but if we don't merge them this time, do expect me to nag about getting them merged next time :)
[03:40] <Chipzz> apart from wanting a smaller initramfs you mean? :)
[03:40] <BenC> cjwatson: But next time I'll have precedence :)
[03:41] <BenC> cjwatson: I'll most likely merge them, but if it gets to be too much of a headache, I'll just hold off
[03:41] <Chipzz> BenC: anyway, is the fix for that going to take a long time or not? if not, I'll just live with it until it gets fixed...
[03:42] <cjwatson> BenC: *nod*
[03:42] <BenC> Chipzz: Fix is coming from upstream, and I think is scheduled for 2.6.21, so we wont see it in feisty
[03:42] <Chipzz> BenC: or is that an upstream issue?
[03:42] <Chipzz> oh ok
[03:44] <pitti> cjwatson: can we promote apr and apr-util to main so that apache 2.2 and the reverse depends can build?
[03:44] <pitti> cjwatson: it also holds up the php5 merge etc.
[03:46] <cjwatson> pitti: certainly; do they have/need MIRs?
[03:47] <pitti> cjwatson: they haven't, but they are just split-outs from the former apache source
[03:47] <pitti> cjwatson: Mithrandir and I agreed that this wouldn't need an MIR
[03:47] <pitti> do you?
[03:48] <cjwatson> ok, if you're happy then that's fine with me and I'll promote them
[03:48] <cjwatson> pitti: done
[03:49] <pitti> great, thanks
[03:49] <pitti> then it should be able to build now
[03:49] <giskard> ogra, did you updated the *dont save session* gpm patch
[03:49] <pitti> and I can fix php5 for apache 2.2 while I merge it again
[03:49] <giskard> update*
[03:49] <ogra> nope
[03:50] <ogra> oh, i'm an idiot
[03:50] <ogra> giskard, thanks for pointing, i'll merge it into the gconf-defaults file
[03:51] <BenC> cjwatson: If a package to merge can be done sans all the ubuntu changes, what's the best way to handle that?
[03:51] <cjwatson> BenC: sounds like a sync
[03:51] <cjwatson> BenC: you mean, we should just take the Debian package verbatim?
[03:51] <BenC> cjwatson: Ok, let me verify the build, and I'll let you know
[03:51] <BenC> right
[03:52] <giskard> ogra, :) 
[03:52] <BenC> directfb was nothing but build fixes
[03:52] <cjwatson> BenC: https://wiki.ubuntu.com/DeveloperResources#syncs
[03:52] <BenC> cjwatson: Thanks
[04:00] <doko> cjwatson: the syslinux merge is still outstanding; didn't make any progress yet
[04:06] <ogra> argh, gcompris was updated ...
[04:11] <fabbione> BenC, kylem, pitti: git is still uninstallable in main... any chance to get that sorted please?
[04:11] <kylem> er, why don't you do it?
[04:11] <BenC> fabbione: We need liberror-perl or something, right?
[04:12] <fabbione> kylem: because i recall one of you was already looking at it?
[04:12] <fabbione> BenC: probably
[04:12] <fabbione> BenC: i was looking at http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html to kill sparc uninstallable crap
[04:12] <fabbione> and i noticed git too
[04:20] <kylem> BenC, i'll do it.
[04:21] <BenC> kylem: You da man
[04:22] <cjwatson> pitti: will you have time to look at Till's merges?
[04:23] <pitti> cjwatson: if he's not around, I could make some time; but I cannot test stuff like hplip at all, and I don't know the foomatic stuff either
[04:24] <cjwatson> who does? doko's on holiday now
[04:24] <pitti> (/me too)
[04:24] <cjwatson> oh
[04:24] <pitti> cjwatson: that's the problem, apart from Till noone really knows the foomatic stuff
[04:24] <cjwatson> I'm not sure if Till's around; it's just that it tends to be easier for core-devs to merge directly than to review somebody else's
[04:24] <mjg59> There's a pretty obvious issue with the hplip-toolbox
[04:24] <pitti> and he did a lot of modifications recently
[04:24] <mjg59> It's QT
[04:25] <mjg59> And needs python-qt3
[04:25] <ogra> Riddell, would you mind merging the seeds to get the openbsd-inetd switch in ?
[04:25] <mjg59> So probably shouldn't be in the preferences by default...
[04:25] <ogra> hmm, no janimo ...
[04:25] <doko> pitti: my OfficeJet is still defect
[04:26] <doko> mjg59: which issue?
[04:26] <pitti> cjwatson: so, I'll take a look at the foomatic stuff, but I'd really prefer to not blindly merge hplip
[04:27] <cjwatson> pitti: hplip's only an updated merge, so that's a lot better than nothing; thanks!
[04:27] <mjg59> doko: It appears in the Ubuntu preferences menu, but it won't run without python-qt3
[04:28] <mjg59> Never mind that it's a completely different interface to print queuing
[04:28] <mjg59> And ugly, confusing and inconsistent
[04:28] <doko> mjg59: yes, that's fixed by the updated merge. I can look at it tonight
[04:28] <mjg59> (I have to admit to not being entirely sure what hplip is for - why doens't cups handle this stuff?)
[04:29] <cjwatson> doko: it is? the Debian changelog says nothing about that
[04:29] <cjwatson> +  * dpatch 00_01_upstream-fix-libusb-bigendian (new): Do not hto* libusb
[04:29] <cjwatson> +    stuff, it does so by itself (at least on the non-ancient versions),
[04:29] <cjwatson> +    backport from upstream 1.6.12-rc3 (closes: #401530)
[04:29] <cjwatson> +  * dpatch 00_02_upstream-fix-pragma-pack (new): Do not use pragma pack, use
[04:29] <cjwatson> +    attribute packed instead, backport from upstream 1.6.12-rc3
[04:30] <doko> cjwatson: ohh, he updated to a version directly from upstream. didn't notice that
[04:31] <cjwatson> ah, this was the mail he sent?
[04:31] <cjwatson> Till doesn't like merging from Debian, AFAICS
[04:33] <doko> cjwatson: it's difficult, because the debian package is built from CVS directly. I only know about http://www.freestandards.org/~till/tmp/ubuntu/feisty/hplip/
[04:34] <cjwatson> doko: that's just the version currently in feisty
[04:36] <cjwatson> doko: the current Debian->Ubuntu patch doesn't seem substantial enough to suggest a different upstream; as far as I can tell the Debian maintainer just isn't using the proper -i options to avoid .cvsignore and such ending up in the source package
[04:38] <Mithrandir> mjg59: yeah, I have it on my hard drive, I should upload it, sorry. :-/
[04:41] <bddebian> heya
[04:46] <thom> yay
[04:51] <mvo> have fun testing it :)
[04:54] <seb128> are packages prerm supposed to remove alternatives on "upgrade" or only on "remove"? 
[04:55] <mjg59> Mithrandir: If you could, that would be great
[04:56] <elmo> seb128: I tend to do it on !upgrade
[04:56] <elmo> to catch the other possiblities for a prerm
[04:56] <seb128> elmo: ok, thank you, looks a good idea to me :)
[04:58] <seb128> There is a bug open about some packages removing the alternative on "remove" and I wanted some other opinion before changing it :) I'll change the package to use != "upgrade"
[05:11] <cjwatson> seb128: there's a pathetic lack of standardisation about what to do there
[05:12] <tepsipakki> cjwatson: partman-auto complains about expert recipe being too large. noticed that you made that change ;) When does it say that?
[05:13] <cjwatson> seb128: e.g. Debian bug #71621
[05:14] <tepsipakki> cjwatson: I've used basically the same recipe since dapper
[05:14] <cjwatson> tepsipakki: if the minimum computed total size for the partitions exceeds the amount of free space on the disk
[05:14] <cjwatson> tepsipakki: my change was just a bug fix; previously, it would have crashed and burned
[05:14] <tepsipakki> heh, ok.. I think it miscalculates the disk size then
[05:15] <cjwatson> tepsipakki: -> #ubuntu-installer ?
[05:15] <tepsipakki> ah
[05:15] <seb128> cjwatson: do you think that != "upgrade" makes sense?
[05:16] <cjwatson> seb128: you should exclude failed-upgrade too
[05:17] <cjwatson> (yeah, I know nobody appears to care about failed-*, but still ...)
[05:17] <cjwatson> seb128: I'm not sure about prerm deconfigure
[05:17] <seb128> if [ "$1" = "remove" ]  || [ "$1" = "deconfigure" ]  ; then
[05:17] <seb128> that's what firefox does
[05:17] <BenC> cjwatson: directfb still needed 2-of-3 patches, merge done and uploaded
[05:17] <seb128> (random example picked)
[05:17] <seb128> BenC: thank you!
[05:18] <BenC> seb128: quite welcome :)
[05:18] <cjwatson> seb128: I realise my analysis in that Debian bug is six years old, but it was pretty hideously inconsistent among packages then
[05:18] <cjwatson> seb128: remove|deconfigure was one of the cases I couldn't unambiguously say was wrong, let's put it that way :-)
[05:19] <seb128> :)
[05:51] <pitti> cjwatson: foomatic-db-engine was an easy merge, uploaded; the other two foomatic packages turned into syncs (bugs filed); apart from hplip this covers Till's merges
[05:52] <pitti> oh, can some archive admin guru please NEW apache2?
[05:52] <pitti> (sorry for urging, but it blocks merges)
[05:55] <ivoks> and please just sync atari-fdisk, ubuntu changes are applied in debian
[05:56] <BenC> Keybuk: ping...got a question about udev
[05:56] <cjwatson> ivoks: DeveloperResources#syncs
[05:56] <ivoks> thanks
[05:56] <fabbione> slomo: you got a fixed mono for sparc
[05:56] <fabbione> slomo: please make sure to let me know if it breaks again
[05:57] <cjwatson> pitti: done
[05:58] <slomo> fabbione: already saw it... thanks :) could you add this patch to the upstream bugreport?
[05:58] <fabbione> slomo: can you instead? i don't even an account on the bugzilla and so much don't plan to get one
[05:59] <fabbione> slomo: sending you the original email/patch
[05:59] <slomo> fabbione: sure... can you upload just the patch somewhere? :)
[05:59] <slomo> thanks
[06:07] <xerxas> is that normal that I cannot do apt-cache {search,show} on a feisty ? 
[06:08] <xerxas> herd 1 , and then update to current 
[06:08] <seb128> xerxas: how can't you do that? what error do you get?
[06:09] <xerxas> no error 
[06:09] <seb128> xerxas: your description is not clear
[06:09] <seb128> what do you do exactly
[06:09] <xerxas> root@xerxas-laptop:/home/xerxas# time apt-cache show rssh
[06:09] <xerxas> real    0m0.016s
[06:09] <xerxas> user    0m0.016s
[06:09] <xerxas> sys     0m0.000s
[06:09] <xerxas> root@xerxas-laptop:/home/xerxas# 
[06:09] <seb128> and what happens then?
[06:09] <seb128> sudo apt-get update?
[06:09] <xerxas> nothing 
[06:09] <xerxas> done an apt-get update 
[06:09] <xerxas> and still the same ?
[06:09] <xerxas> and still the same 
[06:10] <seb128> do you have some apt sources configured?
[06:10] <xerxas> yes 
[06:10] <xerxas> I've added: 
[06:10] <xerxas> Screenshot of Blaze Audio Voice Cloak 1.1
[06:10] <xerxas> view screenshot 	Blaze Audio Voice Cloak 1.1
[06:10] <xerxas> oops 
[06:11] <xerxas> deb http://download.tuxfamily.org/3v1deb edgy 3v1n0
[06:11] <xerxas> deb-src http://download.tuxfamily.org/3v1deb edgy 3v1n0
[06:11] <xerxas> this is for flash9 
[06:11] <seb128> do you have some Packages file to /var/lib/apt?
[06:12] <xerxas> root@xerxas-laptop:/var/lib/apt# ls
[06:12] <xerxas> extended_states  lists  periodic
[06:12] <seb128> to the lists directory
[06:12] <xerxas> 24 files within lists 
[06:12] <seb128> BTW why do you want to use that apt source?
[06:12] <xerxas> do you want me to list ? 
[06:12] <xerxas> seb128:  because flash9 isn't in feisty, is it ? 
[06:13] <seb128> no, that should work, maybe ask to mvo, looks an apt bug
[06:13] <xerxas> seems so 
[06:13] <seb128> or something
[06:13] <xerxas> I can apt-get 
[06:13] <xerxas> I also can apt-cache dump
[06:13] <seb128> xerxas: dunno about flash9, that's non free anyway, no?
[06:13] <xerxas> but no search neither show 
[06:13] <xerxas> seb128:  yes, that's why I have this apt source 
[06:14] <xerxas> mvo:  ? 
[06:14] <xerxas> you there ?
[06:14] <mvo> xerxas: so you can do apt-get update/install etc? but not apt-cache search/show ?
[06:15] <xerxas> yes 
[06:15] <xerxas> also dist-upgrade
[06:15] <mvo> xerxas: can you please rm /var/cache/apt/pkgcache.bin and see if that changes anything?
[06:15] <mvo> xerxas: do you use any special LANG setting?
[06:16] <xerxas> probably 
[06:16] <xerxas> not special 
[06:16] <xerxas> but french 
[06:16] <xerxas> not C 
[06:16] <xerxas> I think so 
[06:16] <xerxas> I removed the file 
[06:16] <xerxas> apt-get update ? 
[06:16] <xerxas> or apt-cache search ? 
[06:16] <mvo> apt-cache search
[06:16] <xerxas> # apt-cache search telepathy
[06:16] <xerxas> nothing more 
[06:16] <mvo> and if that doesn't help, please check if switching the languaguge makes a difference
[06:17] <mvo> xerxas: does switching the language help?
[06:17] <xerxas> root@xerxas-laptop:/var/lib/apt# echo $LANG 
[06:17] <xerxas> fr_FR.UTF-8
[06:17] <xerxas> root@xerxas-laptop:/var/lib/apt# LANG=C apt-cache show rssh 
[06:17] <xerxas> root@xerxas-laptop:/var/lib/apt# 
[06:18] <mvo> hmmmm
[06:18] <xerxas> root@xerxas-laptop:/var/lib/apt# LANG=C apt-cache show rsshttt
[06:18] <xerxas> W: Unable to locate package rsshttt
[06:18] <xerxas> E: No packages found
[06:18] <xerxas> root@xerxas-laptop:/var/lib/apt# 
[06:18] <xerxas> if that helps 
[06:18] <seb128> xerxas: strace -e open -f apt-cache show package?
[06:18] <xerxas> -o log ? 
[06:18] <seb128> do you get any error while doing that?
[06:18] <xerxas> want me to send a log ? 
[06:18] <seb128> no
[06:18] <mvo> to a pastebin please
[06:18] <xerxas> -e open , sorry 
[06:18] <xerxas> -f is childs ? 
[06:20] <Keybuk> BenC: what's up?
[06:20] <BenC> Keybuk: What the hell is the bus_id that is supposed to be used for bind/ubind?
[06:21] <BenC> Keybuk: I've tried everything I can think of, including the device name that udevmonitor shows
[06:21] <Keybuk> same as the name under /sys/bus/*/devices afaik
[06:21] <Keybuk> I've never got bind/unbind to work :p
[06:21] <BenC> I always get a ENODEV
[06:21] <BenC> the function in the kernel looks pretty simple, it uses strcmp(buf, dev->bus_id)
[06:22] <Keybuk> right
[06:22] <xerxas> http://pastebin.wikistuce.info/?423
[06:22] <Keybuk> syndicate pci# ls drivers/tg3
[06:22] <Keybuk> 0000:00:13.0@  bind  module@  new_id  unbind
[06:22] <Keybuk> syndicate pci# echo -n 0000:00:13.0 > drivers/tg3/unbind
[06:22] <Keybuk> syndicate pci# ls drivers/tg3                           
[06:22] <Keybuk> bind  module@  new_id  unbind
[06:22] <Keybuk> syndicate pci# echo -n 0000:00:13.0 > drivers/tg3/bind  
[06:22] <Keybuk> syndicate pci# ls drivers/tg3                         
[06:22] <xerxas> mvo:  that's the output of strace 
[06:22] <Keybuk> 0000:00:13.0@  bind  module@  new_id  unbind
[06:23] <Keybuk> -- 
[06:23] <xerxas> mvo:  |grep "no such" 
[06:23] <mvo> xerxas: can you run it again please without the -e trace=open?
[06:23] <Keybuk> BenC: the -n is important when playing with sysfs :)
[06:24] <BenC> Keybuk: Yeah, -n was killing me
[06:24] <xerxas> mvo:  without the grep also ? 
[06:24] <xerxas> the full output of strace
[06:24] <BenC> Keybuk: works for me now, thanks
[06:24] <xerxas> mvo:  want a malone bug ? 
[06:25] <mvo> xerxas: yes, without the grep too
[06:25] <xerxas> ok 
[06:25] <mvo> xerxas: maybe a malone bug, lets wait for the next strace log
[06:26] <xerxas> mvo:  # wc -l /tmp/log  
[06:26] <xerxas> 994 /tmp/log
[06:27] <xerxas> I won't paste that 
[06:27] <xerxas> creating a bug 
[06:29] <mvo> xerxas: the pastebin can't handle it? can you put it onto some webspace or mai lit to me?
[06:29] <mvo> mail it
[06:29] <xerxas> mvo:  mail yep 
[06:29] <xerxas> I was creating the bug currently 
[06:30] <xerxas> mvo:  I can paste , I think the pastebin manages it 
[06:30] <mvo> xerxas: ok, cool. append it there then please
[06:30] <mvo> xerxas: and let me know the bugnumber
[06:30] <xerxas> but the thing is , copy paste 900 lines, I don't want to 
[06:31] <xerxas> mvo:  what's your mail
[06:31] <xerxas> ? 
[06:33] <cjwatson> slomo: could you or somebody who speaks mono have a look at http://librarian.launchpad.net/5461908/buildlog_ubuntu-feisty-i386.ndoc_1.3.1-2_FAILEDTOBUILD.txt.gz ?
[06:33] <cjwatson> please
[06:34] <slomo> cjwatson: sure, one moment
[06:34] <bhale> cjwatson: looking
[06:34] <bhale> ooh
[06:34] <cjwatson> thanks
[06:34] <cjwatson> I was pretty sure all the Ubuntu changes were unnecessary now, so synced - the build failure doesn't seem to be related to any of them anyway
[06:35] <slomo> no, there seems to be something really unhappy ;)
[06:35] <bhale> a mystery crash
[06:36] <slomo> bhale: no... just 150 minutes of no console output... i remember ndoc to build in less than a minute
[06:37] <xerxas> mvo: synaptic seems to work 
[06:37] <bhale> oh the buildd killed it
[06:38] <bhale> slomo: you know muine is almost ready to release with managed dbus :)
[06:38] <bhale> im not sure there is anything else with libdbus-1-cil
[06:38] <bhale> (no feisty handy)
[06:40] <slomo> bhale: there is... unfortunately it's one of the packages i maintain in debian too, gshare :/ i guess i have to port it myself
[06:41] <bhale> slomo: :(
[06:41] <bhale> i guess I need to work on muine and tomboy in Debian
[06:42] <bhale> dajobe said he was going to give them up a awhile ago, and i havent seen him touch them
[06:42] <bhale> beagle is behind too
[06:43] <slomo> bhale: but we planned to simply replace dbus-sharp with alp's one shortly after etch release in debian... and i guess we can do it for feisty already too. there should be a gac'able version in the middle of january
[06:43] <bhale> bye slomo :)
[06:45] <slomo> bhale: but we planned to simply replace dbus-sharp with alp's one shortly after etch release in debian... and i guess we can do it for feisty already too. there should be a gac'able version in the middle of january
[06:45] <slomo> bhale: can you reproduce ndoc build failure on x86? works fine on ppc
[06:45] <fabbione> slomo: bingo...
[06:46] <bhale> slomo: ENOLINUX :(
[06:46] <bhale> believe it or not
[06:46] <fabbione>  feisty sparc   Successfully built
[06:46] <slomo> fabbione: yay :)
[06:46] <bhale> slomo: mailing myself to test it
[06:53] <bddebian> cjwatson: You about?
[06:53] <LaserJock> I was going to go for Keybuk, but OK
[06:53] <bddebian> Oh yeah, whoops, Keybuk
[06:54] <LaserJock> either way
[06:54] <bddebian> Apparently they're both hiding ;-)
[06:54] <Keybuk> hmm?
[06:55] <bddebian> Keybuk: WRT to your e-mail.  Are the Univserve/Multiverse syncs/merges to be done by Thursday also?
[06:55] <slomo> cjwatson: was ndoc tried twice with the same error?
[06:55] <LaserJock> we are a little confused about the "Merges must be done by Thursday"
[06:57] <cjwatson> slomo: not to my knowledge
[06:58] <cjwatson> bddebian: it's just main/restricted
[06:58] <LaserJock> when was that decided?
[06:58] <vdepizzol> can ubuntu feisty come with beautiful icons in gaim? http://img139.imageshack.us/img139/4732/capturadatelalistadeamilz6.png
[06:58] <LaserJock> I don't see any discussion that merges had to be done by Debian Import Freeze, aren't they traditionally allowed until UVF?
[07:00] <Keybuk> I thought universe was following the same freeze dates as main this time?
[07:01] <Keybuk> LaserJock: it was discussed during the FeistyReleaseSchedule BOF at UDS-MTV
[07:01] <slomo> cjwatson: so let's just retry it one time... might be just bad weather :)
[07:01] <LaserJock> Keybuk: but I don't see where it is communicated to devs, I might have missed it.
[07:02] <Keybuk> LaserJock: wiki.ubuntu.com/FeistyReleaseSchedule
[07:02] <Keybuk> it's very clear
[07:02] <LaserJock> well, it's really not to me
[07:02] <LaserJock> it looks like MoM will stop running on Thursday
[07:02] <Keybuk> "Remaining upstream merges completed" ?
[07:02] <Keybuk> that's not clear ?
[07:02] <LaserJock> "Prior to this date, new versions of packages will be automatically imported from Debian where they have not been customized for Ubuntu. After, this will only happen by explicit request from a developer."
[07:02] <Keybuk> see the note
[07:03] <LaserJock> but it doesn't make much sense
[07:03] <LaserJock> but all right
[07:03] <Keybuk> why not?
[07:03] <Keybuk> what doesn't make sense?
[07:03] <LaserJock> because you still don't have UVF
[07:03] <Keybuk> ?
[07:03] <LaserJock> so we can have new upstream versions, but no merging?
[07:04] <Keybuk> right, outstanding merges and automatic syncs stop on thursday
[07:04] <Keybuk> but there's still a couple of months during which updates can be done without freeze exception approval
[07:05] <LaserJock> well, ok
[07:06] <vdepizzol> can ubuntu feisty come with beautiful icons in gaim? http://img139.imageshack.us/img139/4732/capturadatelalistadeamilz6.png
[07:07] <LaserJock> it just isn't clear to me why you would allow new upstream versions (whether sourced from Debian or not) while not allowing merges
[07:08] <Keybuk> LaserJock: oh, I remember
[07:08] <Keybuk> it's the last safe point before etch releases
[07:08] <LaserJock> ah
[07:08] <Keybuk> and if we merge past this Thursday, we'll end up suffering huge changes as Debian upload all the crack they've been sitting on for months
[07:08] <LaserJock> that makes sense
[07:09] <mc44> is etch releasing then?
[07:10] <LaserJock> it's like waiting for an earthquake, or a volcano eruption
[07:10] <LaserJock> you know it's going to happen "soon" but you can't pinpoint it
[07:10] <Keybuk> and getting rained on by liquid magma is one way to ruin christmas
[07:11] <LaserJock> hehe
[07:12] <Robot101> Keybuk: are you aware of any iftab breakage in etch?
[07:12] <\sh> oh christmas...I think I need to s/2006 Dec 24/2007 Jun 10/ or so...
[07:14] <Keybuk> Robot101: -v
[07:14] <keescook> mornin'
[07:16] <Robot101> Keybuk: -v on what?
[07:17] <seb128> hey keescook!
[07:17] <_ion> robot101: /lastlog robot101
[07:17] <Robot101> I thought he was telling me to run a program with -v :P
[07:18] <Robot101> otherwise it should've been: killall robot101; robot101 -v
[07:18] <_ion> Not a program but a question. :-)
[07:19] <Robot101> Keybuk: less specifically, my iftab applies reliably when I initially boot, but is totally non-deterministic when resuming from suspend. I either get wired and eth0, eth0 and wireless, eth0 and eth1, or eth1 and eth0
[07:19] <Robot101> (iftab names them to wired and wireless)
[07:21] <Keybuk> Robot101: I've heard that
[07:21] <Robot101> Keybuk: how can I debug it?
[07:22] <Keybuk> Robot101: dunno, never seen resume working, so don't know how it works
[07:24] <Robot101> hm
[07:25] <Robot101> but how can I see what's going on?
[07:25] <Keybuk> running udevmonitor will show you what udev
[07:25] <Keybuk> does
[07:25] <Keybuk> udevcontrol log_priority=info will add more to syslog
[07:25] <Keybuk> no idea whether that all works though
[07:25] <Keybuk> as to what actually happens, no idea
[07:25] <Keybuk> ask mjg59
[07:26] <mjg59> Modules get loaded. udev is supposed to deal.
[07:26] <mjg59> There's nothing about it that's suspend/resume specific
[07:27] <mjg59> Keybuk: You could test by just removing the final call to /sys/power/state
[07:27] <Keybuk> mjg59: removing from what?
[07:27] <mjg59> /etc/acpi/sleep.sh
[07:27] <Keybuk> as long as that doesn't kill udev, there's no reason it shouldn't work
[07:28] <Keybuk> I think the problem is that some modules don't get removed
[07:28] <Keybuk> yet, for some reason, they destroy and then reactivate their interfaces
[07:28] <mjg59> That would seem unlikely
[07:28] <Keybuk> perhaps its firmware and power-off related?
[07:28] <Keybuk> when suspend, the device loses all state
[07:28] <mjg59> They won't remove their interfaces unless they're removed
[07:28] <Keybuk> and thus destroys its interfaces
[07:28] <Keybuk> and on resume, has to have the firmware reloaded and gets new interfaces?
[07:28] <Keybuk> why not?
[07:28] <Keybuk> that's a huge assumption :p
[07:28] <mjg59> Because that's not what drivers do
[07:29] <mjg59> Nothing in the suspend path touches the netdev structures
[07:29] <Keybuk> err, the suspend path in the kernel gives a driver an opportunity to do whatever it onces
[07:29] <Keybuk> s/onces/wants/
[07:29] <mjg59> Yes
[07:29] <mjg59> And network drivers don't tear down their interfaces
[07:30] <Keybuk> *shrug*
[07:30] <Keybuk> a brief read of a random module I picked says you're wrong <g>
[07:31] <pitti> question to our shell gurus: I want to find all empty .po and .pot files which are not contained in hidden directories; does this look halfway correct? find -mindepth 1 -name '.*' -prune -o \( -name "*.po" -o -name "*.pot" \) -empty -print
[07:32] <mjg59> Keybuk: ?
[07:33] <mjg59> Keybuk: The closest I can find are calls to netif_device_detach()
[07:34] <mjg59> And those just prevent the network layer from queuing any more work on the device
[07:34] <mjg59> The interface doesn't go away
[07:34] <mjg59> (Easy check: echo -n 2 >/sys/class/net/eth0/device/power/state
[07:36] <Keybuk> mjg59: how will that help?
[07:37] <mjg59> Keybuk: Does it make the interface go away?
[07:37] <Keybuk> mjg59: it just gave -EINVAL
[07:37] <mjg59> Oh, that's interesting
[07:38] <mjg59> Nnngh.
[07:39] <mjg59> CONFIG_PM_SYSFS_DEPRECATED
[07:39] <Treenaks> mjg59: sysfs deprecated?!
[07:39] <mjg59> No, that can't be it
[07:40] <pitti> Treenaks: AFAIUI only the general 'power' attributes in sysfs are deprecates
[07:40] <mjg59> And we've got that enabled anyway
[07:41] <mjg59> So that's not why this has stopped working
[07:41] <pitti> Treenaks: it was allegedly impractical to use in its generality, so they wanted to redesign it per bus
[07:41] <mjg59> Not that they've redesigned it per bus yet
[07:42] <mjg59> Ngh.
[07:44] <tkamppeter> pitti, ping
[07:47] <Keybuk> mjg59: it's a mystery to me, the vague reports I've had don't really make sense
[07:52] <mjg59> Keybuk: Ok. If you want to test this, you'll have to go back to 2.6.17
[07:52] <mjg59> Or do as I suggested earlier, and fake the entire suspend/resume cycle
[07:53] <Keybuk> mjg59: I have faked it, didn't change the interfaces for me
[07:53] <mjg59> Keybuk: It doesn't on every attempt
[07:53] <Keybuk> it seems to only do it if a real suspend is involved
[07:53] <mjg59> The code called in the network modules is identical
[07:54] <mjg59> The only way there could be any difference would be for the modules to not get unloaded
[07:54] <mjg59> Which is trivial to verify
[07:54] <Keybuk> it definitly works if the modules are unloaded/loaded
[07:54] <Keybuk> becauses that's how I test things
[07:55] <mjg59> Well
[07:55] <mjg59> Is there any mechanism by which modprobe -r can return without either having failed or the module being unloaded?
[07:56] <Keybuk> shouldn'tbe
[07:56] <tkamppeter> doko, ping
[07:56] <mjg59> The modprobe calls are there
[07:58] <Keybuk> heh
[07:58] <Keybuk> I wonder what ifconfig'ing wifi0 down does
[07:59] <Keybuk> for x in /sys/class/net/*; do
[07:59] <Keybuk>     if [ -e $x/device/driver ] 
[07:59] <Keybuk>         then
[07:59] <Keybuk>         MODULES="$MODULES $(basename $(readlink $x/device/driver) | tr [:upper:\
[07:59] <Keybuk> ]  [:lower:] )"
[07:59] <Keybuk>     fi
[07:59] <Keybuk> done
[07:59] <Keybuk> mjg59: there's a module symlink in device/driver
[08:00] <Keybuk> so $x/device/driver/module is guaranteed to give you the module name
[08:04] <mjg59> Keybuk: There may be now - there wasn't when that was written
[08:40] <linnuxxy> im working on building a Arabic version of ubuntu... it is an Ubuntu Desktop CD with arabic support packages installed and configured by default... is there a similar projects... even for different languages?
[08:40] <LaserJock> all it is is Ubuntu+arabic lang support?
[08:41] <linnuxxy> + artwork
[08:41] <linnuxxy> yes
[08:41] <linnuxxy> i've used uck... and it worked ok as a first step
[08:44] <mjg59> Keybuk: Might be 5 minutes late to tb
[08:50] <LaserJock> linnuxxy: you might as some of the LoCo teams, I think they've been doing a fair amount of that sort of thing
[08:51] <ajmitch> morning
[09:00] <tkamppeter> pitti, doko, ping
[09:13] <Keybuk> mjg59: the weird thing is that the reports I've got about misbehaving network names on resume come from people with "sensible" hardware
[09:14] <mjg59> Yes
[09:14] <mjg59> I'm really not sure what's up
[09:14] <Keybuk> the only thing I could think of is that somehow udev doesn't get the messages
[09:14] <Keybuk> which implies kernel badness
[09:14] <mjg59> On resume, I'd expect there to be quite a lot of messages
[09:16] <fabbione> Keybuk: can you please give back beagle on sparc?
[09:17] <Keybuk> fabbione: is infinity not around?
[09:17] <Keybuk> mjg59: hardly more than on boot though, no?
[09:17] <fabbione> Keybuk: he is on vacation
[09:17] <fabbione> Keybuk: so is Mith
[09:17] <Keybuk> heh, so amI
[09:17] <fabbione> i think you are the only one around :)
[09:18] <bhale> fabbione: yay dmiller!
[09:18] <fabbione> yeah i know.. i am trying to sort out stuff that doesn't install
[09:18] <Keybuk> fabbione: given back
[09:18] <fabbione> cjwatson: are you around?
[09:18] <fabbione> Keybuk: thanks mucho
[09:22] <fabbione> Keybuk: gnome-applets seems to need the same love... there might be more.. i am just digging into all the stuff
[09:23] <pitti> Keybuk: can you please give-back shadow? I fixed pkgbinarymangler to not make it FTBFS any more
[09:24] <fabbione> Keybuk: that should do it.. the others are in DEPWAIT
[09:24] <fabbione> Keybuk: thanks a lot man
[09:24] <Keybuk> done anddone
[09:25] <fabbione> Keybuk: thanks.. this should make ubuntu-desktop installable again on sparc
[09:28] <pitti> Keybuk: cheers