[12:16] <mjg59> calc: Yeah, you can't with the current approach
[12:20] <mikmorg> the driver disk could be checked for a 'casper-hooks' folder 
[12:20] <mikmorg> mt
[12:20] <mikmorg> cjwatson: I just tested your patch, and it works in casper at least
[12:20] <mikmorg> cjwatson: I have not tried ubiquity yet, however.
[12:38] <cjwatson> mikmorg: great
[12:47] <mikmorg> cjwatson: I'm installing as we speak, to test ubiquity.
[12:49] <calc> heh looks like i should be shooting for half hour ooo builds ;)
[01:06] <mikmorg> cjwatson: ubiquity works as well. Job well done!
[03:40] <calc> hot compile using ccache of openoffice.org in 42m5s 8)
[03:40] <calc> not too shabby with my little system
[03:40] <calc> c2d 6300, 2gb ram
[03:40] <minghua> calc: 42m5s is supposed to be a fast number, right?
[03:40] <calc> considering it can take some systems upwards of 8h yea
[03:41] <calc> ooo has ~ 200MB just of object files
[03:41] <calc> after compilation
[03:41] <minghua> no wonder not many people compile OO.o themselves :-)
[03:42] <calc> i think it has somewhere around 3GB of source
[03:43] <calc> hmm maybe only 2gb after all
[04:05] <ajmitch> hello Hobbsee 
[04:06] <Burgundavia> hey Hobbsee, ajmitch
[04:06] <Hobbsee> hiya
[04:06] <ajmitch> hi Burgundavia, how goes unemployment?
[04:06] <Hobbsee> better than exams, i'll guess
[04:11] <ajmitch> exams aren't too bad
[04:13] <Hobbsee> ajmitch: physics exams where i missed a lot of the content are!
[04:13] <ajmitch> true
[04:14] <ajmitch> but I know you've been busy studying
[04:14] <minghua> hmm, physics exams, fond memories
[04:15] <Hobbsee> ajmitch: of *course*.
[04:15] <Hobbsee> not.
[04:17] <mneptok> pop quiz!
[04:17] <Hobbsee> hiya mneptok!
[04:18] <Hobbsee> let's hope the answer to that is true
[04:18] <StevenK> mneptok: True
[04:18] <mneptok> you people need more study time
[04:18] <StevenK> But we don't want to study your pants.
[04:19] <mneptok> no one does. :(
[04:19] <mneptok> sanity, my old nemesis.
[04:20] <ajmitch> hello mneptok 
[04:20] <ajmitch> I never thought you had a problem with sanity?
[04:37] <Hobbsee> ajmitch: no, that's you, being the crotchety old man and all :)
[04:38] <ajmitch> right
[04:45] <Hobbsee> awww, we never got below 30K open bugs.
[04:48] <Hobbsee> makes me wonder where the heck they all are, though
[05:03] <mneptok> ajmitch: i have no problem with sanity. mostly as i relegate to a small shed in the backyard.
[05:19] <Burgundavia> ajmitch: it goes
[05:31] <pygi> good morning folks
[05:32] <brycerr> heya pygi 
[05:33] <pygi> hello brycerr 
[07:58] <StevenK> It is just me, or should artigas have actually finished building glibc by now?
[08:08] <fabbione> StevenK: yes.. and it's hanging on an old version too
[08:09] <fabbione> infinity: ^^^^ could you please take a look?
[08:12] <StevenK> fabbione: Ta.
[08:20] <mvo> keescook: hey! just read in your report that you investiage the SHA* usage in apt
[08:47] <dholbach> good morning
[08:54] <pitti> Good morning
[08:55] <StevenK> pitti: topic diff?
[08:55] <pitti> StevenK: removed hug day
[08:55] <StevenK> Ah
[08:57] <shawarma> StevenK: IRC client?
[08:58] <shawarma> StevenK: irrsi-scripts has /usr/share/irssi/scripts/topic-diff.pl which tells you exactly what was changed when someone changes the topic of a channel.
[08:58] <shawarma> StevenK: Very handy.
[08:59] <StevenK> I've been meaning to update my irssi scripts.
[08:59] <StevenK> I've been told autorealname and lightbar are both crap.
[08:59] <shawarma> I'm not familiar with those.
[08:59] <StevenK> They are both *old*
[09:01] <StevenK> I need to fix my theme, too. The blue is a little too dark for black text.
[09:02] <shawarma> StevenK: I found a bug in linda, by the way.
[09:03] <shawarma> StevenK: It breaks when there are man pages with "::" in the filename.
[09:04] <StevenK> Known.
[09:04] <dholbach> can a build admin give back at-spi on all architectures?
[09:04] <StevenK> I need to get around to uploading 0.3.25
[09:05] <dholbach> same for gnome-vfs-obexftp on sparc please
[09:15] <pitti> mvo: good morning
[09:15] <pitti> mvo: HAPPY BIRTHDAY!!!
[09:16] <dholbach> mvo: HAPPY BIRTHDAY!!! :-)
[09:17] <highvoltage> mvo: happy birthday :)
[09:29] <stgraber> any idea who shall I ping to have post right on ubuntu-devel ? I received a : "Post by non-developer to moderated list." when I wanted to answer to the guy asking about the testing tracker DNS problem
[09:39] <tepsipakki> could the automatic-bug-closing-feature be modified so that it doesn't spam bugs which are already closed?
[09:40] <tepsipakki> and where to file a bug if it isn't already?
[09:41] <pochu> tepsipakki: I filed one. Bug 118671
[09:41] <ubotu> Launchpad bug 118671 in soyuz "Changelog-Close feature tries to close already-closed bugs." [Undecided,Unconfirmed]  https://launchpad.net/bugs/118671
[09:45] <tepsipakki> pochu: nice
[09:54] <pitti> stgraber: new iso tracker is great!
[10:13] <Lure> pitti: re source NEW: do we need to do something special (like open bug in LP/MIR-like request) to get packages through source NEW? khalki and kde-tweak are there for weeks now...
[10:14] <pitti> Lure: no, we just need more archive team power
[10:14] <seb128> I'm doing some source NEW atm
[10:14] <pitti> Lure: I'll try to do more tomorrow, but due to seb128's and now Mithrandir's vac it is understaffed
[10:14] <Lure> pitti, seb128: ok, I just though that we did not do something right
[10:15] <pitti> Lure: no, don't worry, we'll get to it; sorry for the delay
[10:15] <Lure> pitti: no problem at all, I just want to understand the process
[10:15] <seb128> Lure: if somebody is not right you get a rejection mail
[10:15] <seb128> s/somebody/something
[10:17] <dholbach> pitti: does iwj do MIRs now? or who apart from you is it? (I'm asking because of libgda3)
[10:18] <pitti> dholbach: iwj and me
[10:18] <dholbach> ah ok - thanks
[10:19] <pitti> dholbach: isn't it only a new upstream version of libgda2?
[10:19] <dholbach> yes
[10:19] <dholbach> python-gnome-extras will build-depends on it
[10:19] <dholbach> and if we do something about planner, we can have the supported gda3 in main and dump gda2 to universe
[10:21] <pitti> right, I'm worried about the duplication, not a soname change
[10:24] <dholbach> it's not just a soname change, but a separate maintained branch (gda3 more than gda2) - hopefully all upstream projects will soon switch to it
[10:26] <pitti> Riddell: FYI, strigi needs libextractor, which in turn needs mpeg2dec; these either need MIRs or get dropped
[10:34] <seb128> Lure: khalkhi accepted
[11:01] <asac> doko: cjwatson: if you have a minute, please push the button to retry gnash on sparc :).
[11:02] <cjwatson> asac: (I do not have access to do that)
[11:02] <asac> cjwatson: who has?
[11:02] <seb128> ups, I though you had
[11:03] <seb128> asac: infinity and doko then I guess
[11:04] <cjwatson> asac: anyone in the launchpad-buildd-admins team
[11:04] <doko> asac: was gtk updated in the meantime?
[11:04] <seb128> doko: I've uploaded a fixed gtk+ yesterday evening
[11:05] <asac> doko: yes
[11:05] <doko> ok, given back
[11:05] <asac> doko: thanks!
[11:06] <seb128> doko: can you also give back vlc on sparc?
[11:06] <seb128> and dasher everywhere
[11:08] <doko> seb128: for the same reason?
[11:08] <seb128> yes
[11:08] <dholbach> same for gnome-vfs-obexftp on spar
[11:08] <dholbach> and at-spi on all archs
[11:09] <doko> the interface sucks for mass retries
[11:12] <asac> doko: do you know why openoffice shows up as an rdepend for firefox in dapper?
[11:12] <doko> seb128, dholbach: all done
[11:12] <seb128> danke
[11:12] <dholbach> doko: thanks a lot
[11:13] <doko> asac: AFAICR it did buidl a plugin to show documents directly in the browser
[11:13] <doko> should be possible to reenable that for gutsy
[11:13] <asac> hmmm but i don't see a plugin package?
[11:14] <asac> doko: in gutsy there is mozilla-openoffice.org package in rdepends ... but in dapper there is just openoffice.org
[11:14] <doko> openoffice.org is a pure dependency package
[11:16] <asac> doko: ah ok ... its just a suggests ... which probably makes not much sense in dapper
[11:16] <asac> cool
[11:38] <iwj> doko: Can I ask you a question about weird compiler behaviour ?
[11:41] <doko> iwj: asking is free =)
[11:43] <iwj> This is in glibc.
[11:43] <Robot101> therefore it costs extra? :)
[11:43] <iwj> :-).
[11:43] <seb128> Bixente: around?
[11:43] <iwj> I have an object file compiled from a .c file I added.  The build system generates various object files using different compiler flags.
[11:44] <iwj> In the case of the *.os file, one of the aliases I put in the source seems to have been randomly removed.
[11:45] <seb128> Bixente: you packaged xfce4-time-out-plugin right? Could you fix debian/copyright to mention "Copyright (c) 2007 Jannis Pohlmann <jannis@xfce.org>" as copyright holder for panel-plugin/time-out-fadeout.c?
[11:45] <iwj> Compiler command line is at http://paste.ubuntu-nl.org/25509/
[11:47] <iwj> The compiler generates a file enospck.so which doesn't contain a weak alias __open (although it has invented __GI___open), despite me requesting it with strong_alias (which is glibc's macro for generating aliases).
[11:49] <tepsipakki> does someone know if the ubuntu apache has some trickery to make it work with utf8 filenames?
[11:49] <tepsipakki> or is it a feature of apache 2.x
[11:51] <iwj> (What are these __GI_* aliases for, anyway?)
[11:52] <thom> tepsipakki: feature
[11:52] <tepsipakki> thom: excellent
[11:53] <Bixente> seb128: ok i'll fix it
[11:54] <seb128> Bixente: I've just rejected the package and mailed you
[11:54] <seb128> Bixente: sources are un LGPL but COPYING and debian/copyright claim it's GPL
[11:54] <seb128> s/un/under
[12:09] <iwj> doko: ^
[12:13] <doko> iwj: sorry for the delay. but haven't worked with the __GI_* aliases yet
[12:13] <iwj> Right.
[12:13] <iwj> I'm not sure if my problem is anything to do with them.
[12:13] <iwj> What's going wrong is that the compiler is randomly not generating the alias __open (and a couple of others which are similar).
[12:13] <iwj> And only with certain compiler flags.
[12:14] <iwj> The other versions of enospck.*o have it just fine.
[12:16] <doko> do you see the same behaviour with other compiler versions?
[12:17] <iwj> I haven't tried any.
[12:17] <iwj> It takes about 4 hours to build so I'm not keen on that plan :-).
[12:19] <iwj> ISTR reading something about these __GI_* symbols being something to stop the compiler removing things.  But I wasn't able to find anything resembling a coherent explanation.
[12:19] <doko> try to build on ronne, with gcc-4.2 and gcc-snapshot installed; that should cut down the build times with a parallel build
[12:19] <iwj> You really think it might be a bug just in this version ?
[12:19] <iwj> It seems too clean a fault for that somehow.
[12:20] <doko> the alias doesn't show up in the assembler file when building with -save-temps?
[12:20] <iwj> Oh, I didn't try that.  Let me see ...
[12:24] <iwj> I see  .weak __GI___open  but no  .weak __open
[12:25] <iwj> It's truly bizarre.  It generates the weak alias `open' but not `__open' and they're specified identically in the source.
[12:36] <iwj> doko: Err, it turns out that the difference is already in the -E output so it's the glibc build system that's doing it.
[12:38] <doko> fun :-/
[12:39] <iwj> I hadn't previously looked at the -E output _for the .os build_.
[12:40] <StevenK> iwj: There still appears to be a warning from update-alternatives. I'll investigate a little further and let you know anything more I stumble over.
[12:44] <iwj> StevenK: Just a verbatim copy of the warning message would be sufficient.
[12:44] <iwj> It's probably something upstream did.  They've reorganised it completely and turned on perl -w.
[12:44] <StevenK> iwj: Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
[12:45] <StevenK> iwj: It looks like a typo/thinko from my glance at the code.
[12:47] <iwj> This is with 1.14.4+svn20070602r802-0ubuntu1 ?
[12:48] <StevenK> iwj: That's right.
[12:48] <iwj> It's not a trivial thinko.  I'll go back to my libc problems so I don't get distracted.  Could you file a bug and assign it to me ?
[12:49] <iwj> Does it happen every time ?  A bit of contextual transcript would be ideal.
[12:49] <StevenK> iwj: Ahh. I can reproduce it in a clean gutsy chroot by installing fakeroot.
[12:50] <StevenK> iwj: I'm happy to debug it and file a bug with a patch if you like.
[01:03] <iwj> StevenK: Whatever you prefer but it might be easier for me as I've been more or less following what upstream have been doing.
[01:03] <iwj> StevenK: But helpful would be a tarball of your /var/lib/dpkg/alternatives from before the run that produces the warning.
[01:11] <StevenK> iwj: The bug is already filed and assigned to you. Bug 118246
[01:11] <ubotu> Launchpad bug 118246 in dpkg "update-alternatives warnings" [Medium,Confirmed]  https://launchpad.net/bugs/118246
[01:11] <iwj> StevenK: Ah, excellent.
[01:26] <cjwatson> DAMN, I hate having a slightly sticky . key
[01:26] <cjwatson> mv <glob that expands to two files> <tried to press . but it didn't quite work>
[01:27] <ogra> just remove the sesame seed :)
[01:40] <Keybuk> "Your battery has only 2m left!"
[01:40] <ogra> heh
[01:40] <Keybuk> ...no it doesn't!
[01:40] <ogra> mine dies at 37% atm
[01:40] <pitti> Keybuk: two meters?
[01:40] <Keybuk> afaict, what happened was the first time I ran the new g-p-m, it profiled the period when it was on battery as I walked down the stairs
[01:40] <ogra> and it tells me my battery is bad every boot 
[01:40] <Keybuk> so now it is convinced that I only have 2 min of battery power, because that's the longest it's ever seen on battery
[01:40] <Keybuk> of course, if I could run for longer on battery, it could re-profile
[01:41] <Keybuk> except I can't, because g-p-m takes immediate action and shuts down my machine
[01:41] <ogra> can you define "profile" ? 
[01:41] <Keybuk> ogra: dunno, seems to be some new bullshit thing g-p-m does
[01:41] <ogra> afaik it just gets live values from hal now
[01:41] <ogra> g-p-m is dumb nowadays
[01:41] <Keybuk> rather than just get the current time left from the battery, it profiles it
[01:41] <ogra> hmm, weird
[01:43] <mjg59> It's not dumb, just (currently) trying to be too smart
[01:43] <Keybuk> mjg59: I assume it's so it tells you how much time your battery really has left, based on real measurements
[01:44] <mjg59> Yes
[01:44] <mjg59> I need to speak to Richard about it
[01:44] <ogra> well, hughsie likes to experiment at the beginning of a cycle ...
[01:44] <Keybuk> what I don't understand is why it doesn't use the time the battery thinks until it has seen at least one full charge/discharge cycle
[01:44] <ogra> usually he gets it right along the way
[01:44] <mjg59> Keybuk: Right, unless it has evidence that the battery deviates from what it reports it ought to trust the battery
[01:44] <Keybuk> yeah, it bites me really bad because it's coupled with two other major bugs
[01:45] <mjg59> I'll be chatting to him at guadec
[01:45] <Keybuk> 1) full computer hang when you plug in the AC cord
[01:45] <pitti> mjg59: will you do the laptop-mode-tools merge, or shall I try it myself? (can't test it, though)
[01:45] <Keybuk> 2) Network Manager is unable to associate with the wireless on a fresh boot
[01:45] <ogra> Keybuk, that sounds rather like hal or kernel 
[01:45] <mjg59> pitti: Sorry, I'll get to it
[01:45] <mjg59> Full computer hang = kernel bug
[01:45] <Keybuk> yeah, both seem to be kernel bugs
[01:46] <Keybuk> the NM one is weird, since dhclient itself just works
[01:46] <mjg59> Keybuk: Which driver?
[01:46] <Keybuk> it looks like the kernel isn't giving the right info to HAL which isn't giving the right info to NM
[01:46] <Keybuk> mjg59: ipw3945
[01:46] <StevenK> Keybuk: Does it happen if you boot with the AC plugged in?
[01:46] <Keybuk> StevenK: yes
[01:46] <mjg59> Keybuk: ipw3945 or iwlwifi?
[01:46] <StevenK> Keybuk: Neat.
[01:46] <Keybuk> mjg59: ipw
[01:46] <mjg59> Ok
[01:47] <mjg59> I blame softmac
[01:47] <Keybuk> I wondered whether it has anything to do with HAL gaining software-control support for the hardware kill switch on the Dells
[01:47] <mjg59> Doubt it
[01:47] <Keybuk> because toggling the kill switch cures the problem
[01:47] <mjg59> I suspect it'd also work fine if you force a reassociation
[01:48] <Keybuk> mjg59: that doesn't seem to work
[01:48] <Keybuk> though not sure how to force one
[01:48] <ogra> Keybuk, what about reloading the module ? 
[01:49] <mjg59> Keybuk: While n-m is in the broken state (no green circles), select your network again
[01:49] <ogra> thats what helps me on my broadcom
[01:49] <Keybuk> mjg59: yeah, tried that, that doesn't fix it
[01:49] <Keybuk> ogra: doesn't fix NM
[01:49] <mjg59> ogra: He's already got a workaround, the aim is to try to work out what the problem actually is
[01:49] <mjg59> Keybuk: Ok. Just to check that the symptoms are what I think they are - n-m never associates (draws the first green circle)?
[01:49] <pygi> hey folks
[01:50] <Keybuk> mjg59: NM never draws any green circles
[01:50] <Keybuk> mjg59: it sticks at two empty circles
[01:50] <mjg59> Keybuk: Right.
[01:50] <mjg59> Keybuk: So n-m is never getting the association event. It's basically impossible for it to get that wrong, which means softmac is never sending it properly
[01:50] <Keybuk> toggling the hardware kill switch on and off makes NM draw the first circle, then the next
[01:50] <Keybuk> right
[01:51] <mjg59> Toggling the hardware kill switch makes the interface reassociate without actually taking it down
[01:51] <mjg59> So it sends another event, which /does/ get through softmac this time
[01:51] <Keybuk> which explains why dhclient works, since that doesn't bother checking ;)
[01:51] <mjg59> Yes
[01:51] <Keybuk> that sounds like an entirely reasonable description of a bug which would cause my symptoms
[01:51] <pitti> gnomefreak: iceape-calendar binary is empty; I'll accept it for now, but I guess it should be fixed
[01:51] <mjg59> You want to talk to Tim about that. He managed to track down the issue, though in 2.6.20 it only seemed to hit bcm43xx and zd1211rw
[01:51] <gnomefreak> pitti: ok thank you ill look at it today
[01:52] <mjg59> pitti: Sorry, things have just been hectic. I'm planning on blitzing all of this stuff during Debconf
[01:52] <pitti> mjg59: no problem, I just wanted to confirm that someone is at it
[01:53] <pygi> Keybuk: mhm ... since when it doesn't draw green circles?
[01:53] <mjg59> pygi: When it's broken
[01:53] <pygi> mjg59: oh, that's possible
[01:53] <pygi> sorry
[01:53] <Keybuk> pygi: "gutsy"
[01:53] <pygi> Keybuk: yea, didn't use that for wireless yet :-/
[01:53] <mjg59> Keybuk: We should actually fix that - replacing grey circles with green ones is an accessibility nightmare
[01:53] <Keybuk> mjg59: nice weather for Debconf; I always think Edinburgh looks at its best in rain and thunderstorms
[01:53] <Keybuk> it has the architecture and geography to carry it off with style
[01:54] <mjg59> Keybuk: Oh yes
[01:54] <ogra> seb128, is gnome_sound_play still not switched to gstreamer ? it seems a but odd if apps start to introduce their own gstreamer dep to play one ping sound
[01:54] <ogra> s/but/bit/
[01:54] <seb128> ogra: no, it's not, and they don't intend to I think
[01:54] <ogra> gah
[01:54] <ogra> so we'll have esd eternally ?
[01:54] <ogra> thats bad
[01:54] <asac> pitti: thanks for letting iceape in ... gnomefreak will take care for -calendar
[01:54] <gnomefreak> :)
[01:55] <seb128> ogra: no sure of what the plans are, but I think somebody said they don't want to make every app link to gst only for that
[01:57] <ogra> well, adding gst to gnome_sound_play would make the apps depend on gnomenot on gst ...
[01:58] <cjwatson> would probably still affect desktop memory use a bit
[01:59] <ogra> having a centralized function instead of loading the libs for every single app ?  i dont think that will make a *big* difference
[02:00] <ogra> the thing is that most apps have the gnome dep anyway
[02:00] <seb128> they are trying to deprecated libgnome and libgnomeui
[02:00] <ogra> nw they get an additional one instead of fixing the actual problem
[02:00] <seb128> deprecate
[02:00] <ogra> ah, that would work as well indeed
[02:01] <ogra> anything that lets us drop esd is fine ... ;)
[02:10] <Riddell> dholbach: human-icon-theme seems good to sync from debian, they've done some fancy packaging to include the appropriate distro specific bits.  shall I file a sync request?
[02:14] <Riddell> dholbach: it would mean losing our changelog is the only issue
[02:38] <Hobbsee> hey everyone
[02:38] <zul> hey Hobbsee 
[02:38] <cjwatson> stgraber: you should be able to post unmoderated to ubuntu-devel now
[02:38] <Hobbsee> :)
[02:39] <stgraber> cjwatson: thank you
[02:39] <cjwatson> speaking of which, if anyone would like to get involved with ubuntu-devel moderation, I'd welcome community folks to help take care of that - please let me know
[02:39] <xxxxx1> hello Hobbsee 
[02:51] <pygi> hi
[02:52] <Hobbsee> hiya pygi 
[02:52] <Hobbsee> cjwatson: out of curiousity - what's the S/N ratio on ubuntu-devel, pre-filtering?
[02:58] <cjwatson> Hobbsee: counting or discounting spam?
[03:02] <Hobbsee> cjwatson: um...perhaps both. 
[03:02] <Hobbsee> cjwatson: what are the stats, when counting spam, or when not counting spam?
[03:02] <Hobbsee> i was originally thinking with it - but both stats are useful
[03:03] <cjwatson> Hobbsee: counting spam it's like 40 or 50/1
[03:04] <cjwatson> Hobbsee: discounting it, it's hard to say accurately because I tend to let whole threads through once they've started, but maybe 4/1
[03:04] <cjwatson> err, you said S/N, so 1/4
[03:05] <Hobbsee> as in, you're only letting thru 25% of non-spam mail.  wow
[03:11] <cjwatson> Hobbsee: it's really hard to say, and it might be better than that
[03:12] <cjwatson> actually, it probably is better than that, because I only see the stuff that's held for moderation
[03:12] <cjwatson> a lot of people's addresses are whitelisted
[03:12] <Hobbsee> point
[03:12] <cjwatson> http://wiki.ubuntu.com/UbuntuDevelModeration has some guidelines I've been trying to establish
[03:15] <Hobbsee> cjwatson: looks sane
[03:15] <Hobbsee> except maybe the "Point of contact for upstream developers to reach Ubuntu developers" - thoought that was -discuss
[03:21] <Hobbsee> there can only be one mvo!
[03:21] <seb128> mvo: cursing your provider again? ;)
[03:21] <mvo> seb128: oh yes
[03:22] <pygi> mvo: why is your provider always so bad :P
[03:22] <mvo> I think my ISP hates me
[03:22] <StevenK> mvo: "Oh T-Online, how I loathe and desipe thee?"
[03:22] <pygi> meh, T-* sucks very much
[03:22] <Hobbsee> mvo: against ISP's?  yes.
[03:23] <Hobbsee> mvo: even defenestration is allowed, in some circumstances
[03:23] <StevenK> I'm curious how you plan to defenestrate Telstra.
[03:23] <Hobbsee> i'll find a way
[03:23] <StevenK> Heh
[03:24] <pygi> you cannot touch me
[03:24] <pitti> (funny word)
[03:24] <cjwatson> Hobbsee: oh, that part is just a quote from the original charter ...
[03:25] <Hobbsee> ah right
[03:26] <pbn> Goddamnit, this machine is always being rebooted
[03:30] <seb128> Riddell: when you open a sync request and a patch can be dropped could you mention which one or what it was doing and why it can be dropped?
[03:37] <Riddell> seb128: sure, let me add a comment
[03:38] <pitti> BenC: FYI, kexec-tools MIR approved, promoted
[03:38] <BenC> pitti: thanks
[03:39] <Riddell> seb128: done
[03:39] <seb128> Riddell: thanks
[03:39] <BenC> pitti: patch commited for typo in coredump handler
[03:39] <pitti> BenC: just saw it, thanks
[03:39] <BenC> pitti: Current gutsy is an ABI bump, but if you want to test the tree, it should be good (sans lum/lrm)
[03:42] <dholbach> Riddell: I think they drop the distro icon
[03:43] <dholbach> Riddell: that was last time I checked and I didn't just sync it
[03:43] <dholbach> Riddell: I don't care about the changelog, so if that's the only thing, .... :)
[03:43] <seb128> dholbach, Riddell: I did sync it sync there was a sync bug open
[03:43] <dholbach> Riddell, seb128: ok, I'll check it once again
[03:45] <seb128> dholbach: though I didn't flush the sync queue yet so I can undo, let me know
[03:45] <Riddell> dholbach: distributor-logo.png is still there, with build system stuff to work out which one to put there
[03:48] <dholbach> Riddell: ok, sounds good
[03:48] <dholbach> let's do it then
[03:49] <Riddell> I think seb128 is ahead of us :)
[03:49] <pygi> hey dholbach 
[03:49] <Riddell> dholbach: are you going to look at tangerine-icon-theme?  I suspect it's in a similar position
[03:50] <dholbach> i'll look at it in a bit
[03:52] <Hobbsee> :)
[03:53] <pygi> Hobbsee: sorry, you know you can't do me anything
[03:54] <elkbuntu> Hobbsee, is the stick in for repairs?
[03:54] <pygi> elkbuntu: nah, she knows she can't touch me
[03:54] <elkbuntu> pygi, well of course, she wasnt going to... that's the whole point of the stick ;)
[03:54] <Hobbsee> hehe
[03:54] <Hobbsee> nope
[03:54] <pygi> elkbuntu: no, no. I mean she can't do anything to me
[03:59] <pitti> doko: ufsparse moved to main
[04:00] <pitti> doko: lp-solve as well, so happy OO.o building :)
[04:04] <wasabi> scarey. latest upgrade... or something... broke /var/lib/dpkg/available
[04:04] <wasabi> EOF after field name Original-Maintainer
[04:04] <wasabi> Sure enough, it was an empty field.
[04:04] <wasabi> Filled it in with "foo" and it works now.
[04:04] <wasabi> Original-Maintainer something new and perhaps busted?
[04:05] <StevenK> Which package?
[04:06] <pitti> wasabi: that field exists for over a year, probalby just a particular package where it's broken
[04:06] <doko> pitti: thanks, will enable it
[04:06] <wasabi> libnss3-0d
[04:06] <wasabi> Sure, but that package broke dpkg.
[04:06] <wasabi> That's not really... good.
[04:06] <pitti> $ acsh libnss3-0d|grep Original
[04:06] <pitti> Original-Maintainer: Maintainers of Mozilla-related packages <pkg-mozilla-maintainers@lists.alioth.debian.org>
[04:06] <pitti> hmm, looks fine here
[04:06] <wasabi> Mine was empty.
[04:06] <wasabi> In fact, that was the last field in my available file.
[04:06] <fabbione> wasabi: i have seen stuff like that happening at random with fs corruption or bad ram
[04:06] <pitti> wasabi: which version?
[04:07] <wasabi> Which makes me wonder if something ... was torn off the end.
[04:07] <fabbione> i would rather spend time checking that than a broken package
[04:07] <seb128> looks like a local corruption indeed
[04:07] <wasabi> bah.
[04:07] <wasabi> [51806.444903]  Call Trace:[51806.444925]   [<ffffffff802948ca>]  get_slab+0x1ca/0x260[51806.444931]   [<ffffffff80294a1d>]  __kmalloc+0xd/0x80
[04:08] <wasabi> There's a stack trace in my dmesg. =0  And "nvidia" is in it!
[04:10] <fabbione> wasabi: before you do anything bad with available.. there are backup copies of that file
[04:11] <fabbione> make sure to reboot, check the fs extensively and in case roll back the file to a copy
[04:11] <fabbione> and then re-update the machine
[04:11] <fabbione> that should fix
[04:18] <cjwatson> wasabi: you use XFS, don't you?
[04:18] <cjwatson> wasabi: anyway, 'sudo dselect update' will refresh /var/lib/dpkg/available
[04:19] <cjwatson> fabbione: available is entirely downloaded from the net, so who cares
[04:22] <fabbione> cjwatson: ehr.. of course you are right.. confused with another file in there
[04:23] <StevenK> status
[04:23] <StevenK> Which is a little more important.
[04:24] <StevenK> I've seen filesystem corruption that managed to swap the contents of available and status. dpkg was quite confused by that.
[04:26] <pitti> Riddell: dolphin approved+promoted
[04:27] <soc> hi
[04:27] <soc> does someone know the status/progress of upstart?
[04:27] <soc> what is expected to be released with gutsy?
[04:27] <pitti> Keybuk for sure
[04:27] <Riddell> pitti: woo, thanks
[04:28] <Riddell> pitti: also I uploaded a copy of strigiapplet removing the build-depends on libextractor, it isn't actually used
[04:28] <Keybuk> soc: hi, how can I help?
[04:28] <pitti> Riddell: did you see my strigi IRC msg from this morning?
[04:28] <pitti> Riddell: heh, snap; great
[04:28] <soc> i wonder what's the status of upstart ...
[04:29] <Keybuk> soc: from a strictly upstream POV, edgy shipped with 0.2.x, feisty with 0.3.x and gutsy will ship with 0.5.x
[04:29] <soc> so what can we expect?
[04:29] <Keybuk> the principal thing we're working towards is being able to have sufficient flexibility to define when all the services should be running
[04:29] <Keybuk> and have a consistency of operation as a result
[04:30] <Keybuk> if we achieve that, then we'll begin the process of migrating to using it natively
[04:30] <soc> ah thx
[04:30] <Keybuk> in hindsight, the version shipped with edgy was an interesting technology essay
[04:30] <Keybuk> and wasn't actually ready to build on
[04:30] <soc> so the guideline that only packages which were adapted to upstart are allowed to enter the repos isn't in effect yet?
[04:31] <Keybuk> the version we shipped with feisty was much, much better (over 70% of the code was changed)
[04:31] <pitti> Riddell: hm, no strigiapplet upload visible yet
[04:31] <Keybuk> correct, we're about a release behind where we expected
[04:31] <soc> ah ok
[04:32] <superm1> Keybuk, will you also be writing a guide on properly migrating a package's init script to take advantage of upstart more appropriately?
[04:32] <Keybuk> superm1: yes
[04:32] <soc> but even edgy worked without problems, seemed to be very good work
[04:33] <Riddell> pitti: my fault, one second
[04:33] <soc> so will tracker some time use upstart, too or is this a per-user setting?
[04:33] <Keybuk> soc: it was certainly very reliable
[04:33] <soc> ^yes
[04:33] <Keybuk> what's tracker?
[04:33] <soc> never failed to work
[04:34] <soc> http://www.gnome.org/projects/tracker/
[04:34] <Keybuk> the version in feisty was much more consistent, however.  especially with regards to how events and jobs behaved together
[04:34] <pitti> ogra: the two that appear in my evo that say 8:00 and 18:00? :) (fridge + distroteam)
[04:34] <soc> like beagle, but without mono
[04:34] <soc> (and quite a bit faster)
[04:34] <Keybuk> soc: to start, you mean?
[04:34] <soc> yes
[04:35] <Keybuk> not for gutsy
[04:35] <soc> ah ok
[04:35] <seb128> the indexing is by user
[04:35] <seb128> no?
[04:35] <seb128> it's using a .desktop autostart which works correctly
[04:35] <seb128> why do you want to change to upstart?
[04:35] <ogra> pitti, well, isnt 18:00 CEST 16:00 UTC ?
[04:35] <seb128> ogra: 16utc is wrong time, meeting is 15utc
[04:35] <soc> i didn't want to change it, i was just curious ...
[04:36] <ogra> seb128, i know, i wa just asking which calendars was referred to
[04:36] <soc> i'm trying to understand things a bit better
[04:36] <pitti> ogra: right, meeting is at 1500 UTC/1700 CEST though
[04:36] <ogra> seb128, since fridge says 16:00 UTC :)
[04:36] <soc> can somebody able to tell me, what is upstart's relation to dbus?
[04:36] <ogra> (and did so since yesterday)
[04:36] <ogra> so i was wondering if i miss a new calendar
[04:36] <Keybuk> soc: dbus is a messaging bus, upstart is a service manager
[04:36] <Keybuk> soc: dbus is used to pass messages between applications
[04:36] <soc> will they be able to communicate or are they a completely different osi-layer?
[04:37] <Keybuk> soc: upstart is used to start and stop applications
[04:37] <soc> yes, but is it possible to pass events through dbus to upstart?
[04:37] <Keybuk> soc: it is entirely reasonable that you would be able to communicate with upstart via dbus
[04:37] <Keybuk> soc: that is planned
[04:37] <soc> ah ok, sorry, if i sound a bit helpless ...
[04:37] <Keybuk> that's ok
[04:38] <soc> i'm currently trying to learn proper debian packaging
[04:38] <Keybuk> there are some interesting overlaps between upstart, dbus and HAL
[04:39] <pitti> heno: colorblind approved+promoted
[04:39] <soc> the guys over at motu are really friendly and helpfull ...
[04:39] <Keybuk> in particular, dbus "service bus activation" and HAL's add-ons/helpers
[04:39] <soc> i hope that gets sorted out
[04:39] <Keybuk> we'll tackle those as and when we meet them
[04:39] <heno> pitti: thanks
[04:39] <soc> but packaging something with checkinstall versus packaging with debuild/pbuilder is quite a difference as i experienced :-)
[04:39] <superm1> cjwatson, you got my mail with the patch that you had asked for the modularized glade?  You probably haven't looked through it thoroughly yet, but is that the general idea you were looking for? (I'd like to proceed with moving mythbuntu changes around that, so if it looks basically right I can continue)
[04:44] <soc> does someone know when fglrx will be updated to work with xserver 1.3 again?
[04:45] <ogra> ... mailto:support@ati.com ?
[04:46] <soc> no, a working fglrx was released some weeks ago, bit in gutsy there is a old version which doesn't work with xserver 1.3
[04:47] <ogra> ah
[04:47] <ogra> sorry then :)
[04:47] <soc> no problem :-)
[04:47] <soc> hate this laptop ...
[04:47] <soc> it's just not nice having to block 16 packages because of this damned ati driver
[04:48] <Hobbsee> soc: pin?
[04:49] <superm1> soc, or just disable the one in l-r-m for now, and use the package generation script in the .run file shipped by ATI
[04:52] <soc> yes, i did pin it ... wasn't sure of the right term ...
[04:52] <soc> but no problem, i'll wait for it ...
[04:53] <soc> the ubuntu developers do a really great job transforming this trash into an usable form ...
[04:54] <pygi> soc: ^_^
[04:58] <johanbr> soc: A driver (alpha quality, probably) for the R500 ATI cards was just packaged for Gutsy. If that's what you have, you may want to try it out.
[04:59] <soc> ok i'm on it!!!
[04:59] <Riddell> pitti: Accepted strigiapplet
[05:00] <soc> read about it, but didn't know that it was in gutsy already!!!!!!
[05:00] <soc> i have an ati x14000
[05:00] <johanbr> That must be a new card. :)
[05:00] <soc> s/14000/1400
[05:00] <soc> i thought so too
[05:00] <soc> but in fact wouldn't be faster than a geforce 2
[05:00] <soc> :-)
[05:00] <soc> crappy binary drivers
[05:00] <soc> johanbr: where do i get that driver?
[05:01] <johanbr> xserver-xorg-video-avivo in the standard repo.
[05:01] <soc> weird name ...
[05:01] <soc> mhh didn't see that ...
[05:02] <soc> don't see that
[05:02] <soc> is it in main?
[05:03] <soc> johanbr: i don't find it ...
[05:03] <johanbr> So it's probably not on your mirror yet.
[05:04] <seb128> it's not in main, no
[05:04] <seb128> and it's on gutsy only
[05:04] <seb128> it failed to build in fact, so no binaries yet
[05:04] <soc> it's not on archive.ubuntu.com too ...
[05:04] <soc> ahok
[05:05] <soc> that explains it
[05:05] <soc> btw, why are there some xserver-xorg-video packages and some xserver-xorg-driver?
[05:08] <soc> when can we expect a working build?
[05:08] <cjwatson> superm1: I did, it looks pretty good actually
[05:09] <soc> ah thx
[05:09] <superm1> cjwatson, great.  I'll proceed with getting our glade stuff to fit in with it then
[05:17] <pygi> hey mvo :)
[05:17] <mardi_soir> hello 
[05:21] <mardi_soir> i d like to say that an upgrade yesterday with a kernel image update made  a bad thing to grub .. grub.conf or menu.lst have been replace by a grub.conf without any windows Xp reference 
[05:21] <mardi_soir> on feisty linux .
[05:22] <mardi_soir> hop i will not happen on the futur :)
[05:22] <mardi_soir> and another thing i notice
[05:23] <Hobbsee> er, that's because you modified your grub list, and stuck XP in the autoupdated section, i expect.
[05:23] <mardi_soir> on a read only partion . nautilus do not allow to create a symbolic link (in order for exemple to make a link on  the desktop=
[05:24] <mardi_soir>  (with right clic )
[05:24] <mardi_soir> send link to desktop could be apreciate 
[05:25] <pitti> Hobbsee: can bug 108870 actually be closed? It has a changelog which seems to indicate that
[05:25] <ubotu> Launchpad bug 108870 in kubuntu-default-settings "[Feisty regression]  install two or more debian files with right click on them and install doesn't work" [Low,Fix committed]  https://launchpad.net/bugs/108870
[05:25] <Tonio_> pitti: hi :) Was about to drop the pmount dep for kdebase, but looking at the debian/changelod, I must say I don't know what to do
[05:25] <Hobbsee> pitti: see -meeting.
[05:25] <Tonio_> pitti: it's bin removed by debian some time ago and they re-added it since it seemed to cause issues with HAL
[05:25] <pitti> Hobbsee: ah, I see
[05:26] <Hobbsee> pitti: i'm typing slowly today - i'm cold.  and i'm looking thse bugs up, and waiting on LP each time.  this takes time, from an au connection, so please be patient with me.
[05:26] <pitti> Tonio_: the dependency is not necessary any more since edgy
[05:26] <pitti> Tonio_: we tested that already
[05:26] <Tonio_> hum, okay, let's upload a fix version then, I have a couple of other fixes to commit
[05:26] <pitti> Hobbsee: oh, I wasn't hurrying; IRC is horribly lagging for me, so I didn't see your replies fast enough
[05:27] <pitti> Tonio_: great, thanks
[05:27] <Hobbsee> pitti: fair enough.  18 second lag on each launchpad page here...
[05:30] <mardi_soir> Hobbsee,  yes i guess but it a problem 
[05:30] <mardi_soir> it is 
[05:30] <pitti> seb128: btw, please give me some gutsy crashers and dups of them, I wanna test my new toys :-)
[05:30] <Hobbsee> mardi_soir: you wanted to make XP boot by default, or change the boot order?
[05:30] <Hobbsee> and so moved the XP block into the autogenerated kernel list?
[05:30] <seb128> pitti: maybe it's time to enable apport again ;)
[05:31] <pitti> seb128: nah, I really want to get the private bug filing sorted out first
[05:32] <pitti> seb128: the malone fix for that is in review now
[05:32] <mardi_soir> Hobbsee, the problem is solved .. but i have modified the grub.conf for my sister's computer .. . (to make menu looks good with a custom string instaead of "ubuntu version" who looks bad for her .. and after a update windows was not present .. 
[05:32] <pitti> seb128: btw, I'll clean up the existing CoreDump.gz attachments soon
[05:32] <seb128> good idea
[05:32] <pitti> seb128: the rejected/duplicate/fixreleased ones don't need discussion
[05:32] <bddebian> Heya
[05:32] <seb128> pitti: I've to run after the meeting but I can send you some crashes and dups tonight or tomorrow morning
[05:32] <pitti> seb128: WDYT about the ones on open bugs which have a broken retrace?
[05:32] <Hobbsee> mardi_soir: but did you move the windows section inside the autogenerated list?
[05:33] <mardi_soir> Hobbsee, yes
[05:33] <pitti> seb128: btw, you can re-tag existing bugs to have them retraced again, then they will get into the dup db
[05:33] <Hobbsee> right.  then there's your problem.  you can modify the strings and such fine
[05:33] <seb128> pitti:  broken retrace because of the retracer or because the crash file is outdate or b0rked?
[05:33] <seb128> pitti: k
[05:33] <pitti> seb128: hard to tell automatically
[05:34] <mardi_soir> Hobbsee, yes this is the reason of my presence here .. to notify develloper about this . :)
[05:35] <seb128> pitti: that them so we can review the list easily?
[05:35] <seb128> s/that/tag
[05:35] <mardi_soir> Hobbsee,  a set of sed instruction could easyly solve this i guess 
[05:35] <pitti> seb128: I actually have another idea
[05:35] <pitti> seb128: ok, I'll leave the core for open non-dup bugs for now and think about it some more
[05:35] <seb128> pitti: ok
[05:36] <pitti> mardi_soir: btw, there is a bug about that, let me look
[05:37] <pitti> mardi_soir: bug 21412
[05:37] <ubotu> Launchpad bug 21412 in grub "Default update-grub behaviour is not intuitive with respect to user modifications" [Medium,Confirmed]  https://launchpad.net/bugs/21412
[05:38] <mardi_soir> ok pitti thank 
[05:39] <pitti> ubotu: mdz recently said that we shuold really aim for a solution for this in gutsy, so there's some hope :)
[05:39] <pitti> erm, mardi_soir ^
[05:39] <pitti> what made me type ubotu??
[05:44] <Tonio_> pitti: talking about the upload queue, can you confirm me if kio-umounwrapper is still in NEW please ?
[05:45] <seb128> Tonio_: it's not good to be accepted
[05:45] <Tonio_> seb128: ah ?
[05:45] <seb128> I switched to somethijng else this morning but I think there was problems with it
[05:46] <seb128> let me look quickly
[05:46] <Tonio_> thanks
[05:46] <Tonio_> seb128: I noticed an issue in the postrm file after uploading, I wanted to fix once accepted
[05:47] <seb128> ah right, I think that was the one call debconf to an install script but which is not using debconf in fact
[05:47] <seb128> s/call/calling
[05:48] <seb128> and do you need all those comments?
[05:49] <seb128> Tonio_: please fix the debconf use, out of that it looks ok
[05:50] <seb128> I've to run, later
[05:50] <iwj> pitti: So what's this about apport and a separate place where crash reports get filed ?
[05:50] <Tonio_> seb128: debconf ?
[05:50] <Tonio_> seb128: I didn't notice debconf stuff in it.... talking about dpkg-divert usage maybe ?
[05:50] <pitti> iwj: (CC: asac) the immediate solution which will give us 90% of the desired effect is https://wiki.ubuntu.com/CrashReporting
[05:51] <seb128> Tonio_: grep for debconf in the prerm
[05:51] <Tonio_> seb128: ho indeed, evil.....
[05:51] <pitti> iwj: in short: file bugs privately, have the retracer do its job, delete the core dump, and then subscribe the triaging teams
[05:51] <seb128> later
[05:51] <pitti> iwj: longer-term solution is to introduce a proper 'crash table' concept into Launchpad
[05:51] <iwj> pitti: Oh, yes, that sounds very sensible.
[05:52] <pitti> iwj: kiko and Bjorn have some concrete ideas about that, and we had a ~ 90 minute discussion about the behaviour
[05:52] <iwj> Sorry, I should have read it before asking.
[05:52] <pitti> iwj: that approach will avoid bug spam and a totally public data exposure, but it intrinsically limits the number of people who can take a look at the crashes, of course
[05:52] <pitti> np
[05:52] <iwj> Indeed.
[05:53] <asac> pitti: good is that we get access-control 
[05:53] <asac> pitti: from launchpad.
[05:53] <pitti> right, and we never expose core dumps to humans at all
[05:53] <asac> pitti: but i still have a bad feeling about using bugs to process crashes at all
[05:54] <pitti> asac: why?
[05:54] <Tonio_> hum is that necessary to increment the version number f a package still in NEW ?
[05:54] <pitti> oh, crud -- it just occurs to me that dup detection of Python crashes doesn't work ATM
[05:54] <asac> i mean ... it somehow heavy weight imo
[05:54] <pitti> Tonio_: no, it isn't
[05:54] <asac> and not really flexible
[05:54] <Tonio_> pitti: thanks
[05:54] <asac> e.g. i think we get a crash db anyways?
[05:54] <pitti> Tonio_: please ask seb128 or me to reject the old one though, so that we don't get confused about which one to accept and which to reject
[05:55] <pitti> asac: we will, right
[05:55] <asac> for duplicate matching ... why not contain info in that
[05:55] <pitti> asac: but the 'master' crash will be escalated as a bug anyway
[05:55] <asac> yes right
[05:56] <pitti> so whether the place where we store it has a 'crash' or a 'bug' label doesn't really matter
[05:56] <asac> i would open a master crash when i see a crash that happens multiple times
[05:56] <pitti> in terms of storage space or workflow
[05:56] <pitti> you have to review the crashes in both cases
[05:56] <Tonio_> pitti: you can reject the old one now, I'm about to upload the fixed package
[05:56] <Tonio_> pitti: in fact I already uploaded it :)
[05:56] <pitti> I haven't found an use case so far that showed me how a separate crash table that humans interact with makes things any eaier
[05:56] <pitti> easier
[05:56] <asac> pitti: i don't know ... if they are one time crashes i usually don't want to look at them
[05:56] <pitti> Tonio_: great, thanks
[05:56] <asac> pitti: at least if there is no good testcase
[05:56] <pitti> asac: so don't :)
[05:57] <pitti> asac: so, the separate crash table would be easier for prioritizing etc.
[05:57] <asac> and having all these wierd crashes associated with a bug id, sounds heavyweight
[05:57] <asac> e.g. all get backups ... stays available forever et al
[05:57] <pitti> asac: NB that we *will* get it; what I'm saying is that private bugs are 'almost' as good for now
[05:58] <asac> ah ok :)
[05:58] <asac> pitti: if its an intermediate solution then its pretty elegant
[05:58] <pitti> so, I'll see to making this dup stuff work for python crashes, too, to make cjwatson and evand happy :)
[06:00] <pitti> Tonio_: oh, what was the pacakge name?
[06:00] <pitti> Tonio_: ah, kio-umount wrapper?
[06:00] <Tonio_> kio-umountwrapper
[06:00] <Tonio_> pitti: true
[06:00] <pitti> Tonio_: ok, I killed the old one
[06:01] <pitti> Tonio_: oh, there are more; killing the middle-aged one, too
[06:02] <Tonio_> pitti: there was 3 uploads ???????
[06:02] <pitti> Tonio_: yes, apparently so
[06:02] <Tonio_> hum lure probably uploaded after me in fact...
[06:14] <Hobbsee> Is any member of management of Canonical going to comment on http://www.linspire.com/linspire_letter.php anywhere public?
[06:18] <pygi> Hobbsee: wasn't that already commented on?
[06:18] <elkbuntu> pygi, by who? where?
[06:19] <pygi> elkbuntu: oh, that's new
[06:19] <pygi> I saw the last letter I think
[06:19] <Hobbsee> pygi: not by a person from Canonical, i believe
[06:19] <pygi> Hobbsee: indeed, sorry. I was refering to the old letter.
[06:19] <Hobbsee> pygi: it's hit planet and such, and is getting responded to.
[06:19] <Hobbsee> ahh
[06:20] <pygi> Hobbsee: great, double bed :-/
[06:20] <Hobbsee> s/bed/bad/?
[06:23] <pygi> Hobbsee: no, the bed :P
[06:23] <pygi> because they have pact with two completely opposite sides
[06:23] <Hobbsee> oh right
[06:30] <pygi> Hobbsee: ^_^
[06:31] <Hobbsee> hm?
[06:31] <pygi> Hobbsee: just read the letter. He's trying to say he's not doing anything bad, and we should all follow his way :P
[06:32] <elkbuntu> aka 'come to the dark side'
[06:33] <Hobbsee> heh
[06:34] <pitti> *shrug* apt-get install microsoft-office would certainly be good for improving the chance of Linux to get adopted widely
[06:34] <pitti> so, as much as I love free software, that guy has a certain point
[06:36] <Hobbsee> commercial repo's presumably the solution to that
[06:36] <pitti> Hobbsee: well, commercial repo is the vehicle
[06:36] <pitti> but you need something to put into it :)
[06:37] <evand> it struck me that he was using the lure of microsoft software to mask the fact that he was really making a deal over patents.
[06:37] <pitti> M$ did a really good job of nailing people tightly to their products once they started using it
[06:37] <Hobbsee> yeah, true that
[06:37] <pitti> evand: right, that's the bit that is frightening me (just as with the Novell deal)
[06:38] <pitti> but some people I know are mainly nailed to things like their extensive collection of Excel spreadsheets and scripts, etc.
[06:38] <pitti> they don't actually need the Windows beneath it, but they do need e. g. office
[06:40] <pitti> so, we can only hope that there's something in for the free software world as well, and that all those Novell/Linspire deals aren't just a Trojan for more patent wars
[06:41] <evand> indeed
[06:42] <Amaranth> I'm actually leaning toward the theory eben moglen had
[06:42] <Amaranth> at least i think it was him
[06:43] <Amaranth> microsoft doesn't want to piss off businesses by threatening to sue them but it does want to stop the developers
[06:43] <Amaranth> these deals give them a way out of the problem, the businesses will be safe
[06:44] <pitti> Amaranth: interesting, how so/
[06:44] <pitti> ?
[06:44] <pitti> door bell -> brb
[06:44] <Amaranth> http://youtube.com/watch?v=6YExl9ojclo&v3
[06:46] <wasabi> So does Debian or us have any policy about generating debsums for each package?
[06:48] <the_dark_lord> hello
[07:29] <rohan> is there any way to disable libata in feisty, without rebuilding the kernel ? e.g. by blacklisting a module or so ?
[07:39] <pitti> yay, python crash dup detection works now
[07:40] <rohan> btw, this is strange .. first with the stock feisty kernel, libata was enabled .. then in build .16-23 it was disabled.. and now again in .16-29 it is enabled .. why are so 'major' changes taking place in a _Stable_ release ?
[07:40] <pitti> rohan: that change was a major fault in -16.28 and thus was reverted again in -16.29
[07:41] <rohan> pitti: oh .. that was the best thing that had happened to me :(
[07:41] <pitti> rohan: we will make sure to avoid such things in the future, we had a big discussion about it
[07:41] <rohan> libata works really horribly here, causing cd drive timeouts every now and then
[07:41] <pochu> pitti: that's great :)
[07:59] <mathiaz> What is the role of linux-backports-modules package ?
[08:00] <pitti> mathiaz: AFAIUI, it's for post-release updates which we do not want to force upon a default install
[08:02] <mathiaz> pitti: thks. What are the solutions to provide a module that is not included in the kernel ?
[08:03] <pitti> mathiaz: that's quite tricky; common practice for now is to provide a -source package and use module-assistant
[08:03] <mathiaz> pitti: hum. That's how things are done for apparmor now.
[08:04] <pitti> mathiaz: but I thought the modules were supposed to get into the proper kernel package?
[08:04] <mathiaz> pitti: is there a way/common practice that avoid end users compiling the module ?
[08:05] <pitti> mathiaz: not really; we either put it into linux-ubuntu-modules, or provide a source
[08:05] <pitti> maintaining a separate package and follow the ABIs is way too much effort
[08:05] <mathiaz> pitti: well. I misunderstood that part. What goes into the kernel is a small patch that make it possible to compile the module
[08:05] <pitti> mathiaz: OIC; it won't go into l-ubuntu-modules then?
[08:06] <mathiaz> pitti: NAFAIK
[08:06] <mathiaz> pitti: for now, it's just the 2 line patch that goes into the kernel.
[08:07] <mathiaz> pitti: I misunderstood that part. I thought it would be the whole module.
[08:07] <pitti> mathiaz: we should discuss that on the ML
[08:08] <pitti> mathiaz: also in conjuntion with the apparmor MIR
[08:08] <pitti> mathiaz: even if the kernel would provide the modules by default, I have the feeling that apparmor is just not mature enough yet to be put into main now; even less so if there are no kernel modules available
[08:08] <mathiaz> pitti: ok. I'll send an email to ubuntu-devel.
[08:12] <mathiaz> BTW, what's the difference between linux-ubuntu-modules and linux-image ?
[08:13] <wasabi> ENV{FOO} in a udev rule. What does this refer to?
[08:13] <wasabi> ENV{ID_FS_TYPE} actually.
[08:24] <shawarma> wasabi: by the looks of it, it checks the value of an environment variable by the name of "ID_FS_TYPE". Just a guess. 
[08:25] <DexterF> hi
[08:25] <pitti> mathiaz: linux-image is by and large upstream kernel, and -ubuntu-modules are 3rd party drivers (e. g. linux-wlan-ng, external wifi drivers, etc.)
[08:25] <DexterF> nfs issue: got an nfs v3 server, have some shares in fstab here on 7.04, and tho I can access them they don't show up in "mount" or "df". how come?
[08:47] <DGMurdockIII> hi
[08:48] <DGMurdockIII> has then been any work dose on making the sound better in ubuntu
[08:48] <DGMurdockIII> work done*
[08:55] <crimsun> what do you mean by "making the sound better"?
[08:55] <crimsun> driver? audio theme(s)?
[08:58] <DGMurdockIII> drivers
[08:58] <crimsun> sure, there's ongoing work.  Do you have something specific in mind?
[11:05] <cjwatson> turk_: why do you need to?
[11:06] <cjwatson> it goes in the parent of wherever you're building. if you want it somewhere else, build somewhere else or else move it afterwards. :)
[11:07] <turk_> yeah; i'm looking for a way to automate something and i was just wondering why it wasn't an option
[11:07] <cjwatson> it's also not just dpkg-buildpackage involved, it's scripts called by debian/rules
[11:07] <cjwatson> (e.g. dh_builddeb but not quite everything uses that)
[11:07] <cjwatson> so it's much more reliable to just have it be fixed
[11:08] <turk_> ok, thanks for the info
[11:37] <siretart> asac: new python-debian in debian now, which should fix your problem. please report if it doesn't
[11:50] <asac> siretart: ok cool. thanks!
[11:53] <pkern> Is Henrik Nilsen Omma here?
[11:57] <mc44> pkern: heno, he is offline now by the looks of it
[11:58] <pkern> mc44: Thanks.
[11:58] <mc44> pkern: try in european working hours :)
[11:58] <pkern> Well I just received a mail from him.
[11:59] <pkern> An hour ago.