[12:23] <keescook> so, it looks like "tee" is getting stuck on the i386/amd64 builds of gdb.  very odd
[12:38] <Riddell> jpetso: KDE questions often best in #kubuntu-devel (but I'm off to sleep
[12:39] <jpetso> Riddell: well it's not a kde question, technically
[12:39] <jpetso> Riddell: but thanks anyways, good night
[01:06] <sistpoty> lamont: did you upload libnss-ldap (universe sru) yet?
[02:23] <mjg59>  /win 10
[02:23] <mjg59> Ng.
[02:26] <cr3> what's the difference between daily and daily-live? the only difference I can see is that the former provides alternate and the latter provides desktop.
[02:30] <jdub> cr3: yes, the desktop cd is the new live cd
[02:31] <jdub> cr3: 'daily' vs. 'daily-live' is a historical thing
[02:33] <cr3> jdub: is there any guarantee at which time the daily and daily-live directories on cdimage.ubuntu.com are updated? is that cronned at a particular time?
[02:36] <jdub> cr3: they are but i forget when
[02:39] <bhale> jdub: The Office is 1 hr
[04:21] <lamont> sistpoty: dunno - probably not
[04:21] <lamont> uploaded to sru, I thought
[04:21] <lamont> or rather, proposed updates
[05:34] <fabbione> morning
[05:36] <jdong> what is a SIGABRT in the context of Openoffice?
[05:36] <jdong> the latest 0day word exploit causes a SIGABRT in openoffice
[05:36] <jdong> (on Edgy)
[05:36] <jdong> (haven't tried anything else)
[05:37] <jdong> http://www.milw0rm.com/sploits/12122006-djtest.doc   <-- POC
[05:37] <jdong> OOo dies with a stack trace
[05:37] <jdong> Fatal exception: Signal 6
[05:40] <PuMpErNiCkEl> http://en.wikipedia.org/wiki/SIGABRT
[05:42] <jdong> PuMpErNiCkEl: I know that much
[05:42] <jdong> I was wondering what it means in terms of OpenOffice in this specific exploit
[05:42] <dieman_> jdong: nice.
[05:42] <jdong> more importantly, if OOo is open to a similar exploit as MS Office
[05:43] <jdong> some people on other distros report a segmentation fault
[05:43] <jdong> which raises a big red flag in my  mind
[05:43] <dieman_> i'd collect debug information and open a bug
[05:43] <jdong> dieman_: ok, will do
[05:51] <keescook> jdong: it's either OOo calling abort() or glibc calling it as a result of heap corruption.
[05:51] <jdong> keescook: yikes... so it shouldn't be exploitable then on Edgy?
[05:51] <jdong> or is it still up in the air?
[05:51] <jdong> keescook: is it worth me filing a bug on it then?
[05:52] <keescook> I haven't had the time to study it, but the "exploits" floaitng around won't work on linux.
[05:52] <keescook> jdong: best to get a backtrace, actually.
[05:52] <jdong> keescook: openoffice did print something at the console that starts with this
[05:52] <jdong> Stack:
[05:52] <jdong> /usr/lib/openoffice/program/libuno_sal.so.3[0x4387d4fb] 
[05:52] <jdong> /usr/lib/openoffice/program/libuno_sal.so.3[0x4387d631] 
[05:53] <jdong> is that good enough as a backtrace
[05:53] <jdong> or is there some other procedure I should follow?
[05:53] <keescook> nah, I'd like to get one out of apport.
[05:53] <keescook> do you have gdb installed?
[05:53] <jdong> (it didn't trigger apport)
[05:53] <jdong> I do have gdb
[05:53] <keescook> apport ignores abort.  okay, edit /usr/share/apport/apport
[05:53] <keescook>     if signum == str(signal.SIGQUIT) or signum == str(signal.SIGABRT):
[05:53] <keescook>         sys.exit(0)
[05:53] <keescook> drop the "or signum == str(signal.SIGABRT)" part, and try crashing OOo again
[05:53] <jdong> that's simple enough :)
[05:55] <jdong> keescook: it still doesn't trigger apport
[05:56] <jdong> :-/
[05:57] <jdong> ah, oowriter is a shell script
[05:58] <jdong> yes!
[05:58] <jdong> I think I triggered apport
[05:58] <jdong> the disk grinding is all too familiar
[05:58] <jdong> yep
[06:02] <jdong> sheesh it's 5MB :)
[06:03] <keescook> jdong: cool.  can you open a bug and attach the crash?  I think it's heap allocation or something.  ooffice just ate my machine alive trying to open that file.  :P
[06:03] <jdong> keescook: bug is 75847, apport blob is uploading
[06:03] <jdong> keescook: bug  75847, apport blob is uploading
[06:04] <keescook> cool, thanks
[06:04] <jdong> ahem, bug 75847
[06:04] <Ubugtu> Malone bug 75847 in openoffice.org "OOo crashes when opening MS Word Exploit POC" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75847
[06:04] <jdong> ha the bot doesn't like double-space
[06:04] <somerville32> lol
[06:05] <jdong> keescook: while we're waiting I linked to a /. discussion on this that a google turned up
[06:05] <jdong> keescook: oh look at that, it uploaded :)
[06:05] <keescook> cool, thanks.
[06:06] <jdong> (by the way jeez Firefox traces are gigantic)
[06:07] <jdong> that really does explain half my incremental dumps :D
[06:07] <keescook> btw: you may want to put that SIGABRT thing back into apport... there are lot of things that barf that don't produce useful traces on an abort.  :)
[06:08] <jdong> lol yeah
[06:10] <keescook>  #2  0x420cfef3 in abort () from /lib/tls/i686/cmov/libc.so.6
[06:10] <keescook>  #3  0x4387d636 in osl_raiseSignal ()
[06:10] <keescook>     from /usr/lib/openoffice/program/libuno_sal.so.3
[06:10] <keescook> so it looks like an OOo lib raised the abort, so that just means it's a bug in OOo, as far as how it handles reading the file.
[06:10] <keescook> (so, not a security vuln)
[06:11] <jdong> keescook: that's good to know
[06:11] <jdong> keescook: what about the /. folk who reported segfault
[06:12] <keescook> that's slightly more interesting, but plenty of stuff that segfaults isn't a security problem.  :)
[06:12] <jdong> :)
[06:13] <jdong> either way, it still (1) worries me
[06:13] <jdong> (2) is a problem that OOo doesn't gracefully handle the error
[06:13] <jdong> it still makes this word exploit at minimum a denial-of-service to OOo
[06:13] <jdong> I'm sure upstream has heard about this by now :D
[06:15] <keescook> well, i386 just crashes.  amd64 it eats all available memory.  :P  We need to invesgitate some kind of popup that SIGSTOPs massive hogs and pops up "process Blah is eating your system for lunch.  Kill it?  [ Ok ]  [ I like trashing ] "
[06:16] <keescook> okay, dinner time.  cya
[06:16] <jdong> enjoy, keescook
[06:24] <Chipzz> keescook: that would stop my firefox every time I start it :P
[08:14] <pitti> Good morning
[08:16] <Hobbsee> pitti
[08:16] <Hobbsee> !!!
[08:57] <AnAnt> hello
[08:57] <AnAnt> I think there is a problem with libc6-dev
[08:57] <AnAnt> in libieee.a
[08:57] <AnAnt> I got a program linking against it
[08:57] <AnAnt> and it gave this error:
[08:57] <AnAnt> /usr/lib/libieee.a:(.data+0x0): multiple definition of `_LIB_VERSION'
[08:57] <AnAnt> /usr/lib/libieee.a:(.data+0x0): first defined here
[08:57] <mdke> AnAnt: this isn't a support channel. You can file bugs in the bugtracker at bugs.ubuntu.com
[08:58] <Hobbsee> AnAnt: filed a bug?
[09:02] <keescook> late night hackin'
[09:03] <keescook> pitti: so there relro won't go in like ssp did, eh?
[09:03] <pitti> hey keescook 
[09:03] <keescook> hiya pitti, Hobbsee :)
[09:03] <pitti> keescook: well, we might be able to sneak relro into gcc, if it's really that unintrusive as it sounds
[09:04] <pitti> keescook: but PIE? we shouldn't do that...
[09:04] <keescook> PIE, no way.
[09:04] <mdke> mmm, pie
[09:04] <keescook> I want to test it with stuff in feisty first.
[09:04] <keescook> relro is hardly anything at all.
[09:04] <keescook> I looked at the patch to enable ssp.  kinda scary
[09:04] <pitti> keescook: for that, using a ~/bin/gcc wrapper should work
[09:05] <keescook> what's the reason for not doing it the way ssp was done?
[09:05] <pitti> keescook: ccache manages to divert cc/gcc/etc. quite well, too
[09:05] <pitti> keescook: mainly because it alters the default gcc behaviour which might lead to unexpected things when building upstream software
[09:06] <pitti> keescook: for the short term I'd prefer a gcc wrapper while we discuss this with Debian
[09:06] <pitti> keescook: after all, we had a package 'gcc-opt' on the buildds for a loong time
[09:06] <keescook> okay, cool.
[09:07] <pitti> keescook: and got rid of it about the time when we started discussing SSP :/
[09:07] <keescook> heh
[09:07] <pitti> keescook: how's 2.6.20 wrt. ASLR? does PIE do any good there to enable more juggling?
[09:07] <keescook> can you or doko mock something up so I can see how that would look?
[09:08] <keescook> I haven't tried 2.6.20 yet; i've been dog-fooding compiz, so unwinding stuff without lrm wasn't something I wanted to jump on.  :P
[09:08] <pitti> keescook: a ~/bin/gcc with '#!/bin/sh\nexec $0 -fPIE "$@", something like that
[09:08] <keescook> oh, seriously that simple of a wrapper?
[09:08] <pitti> keescook: for testing, why not
[09:08] <pitti> keescook: ccache does it much the same way
[09:08] <keescook> fair enough.
[09:09] <keescook> I'd be stuffing it into my build schroot's
[09:09] <pitti> keescook: a gcc wrapper could look much like the ccache package
[09:09] <keescook> relro> -Wl,-z,relro
[09:09] <keescook> PIE> -fPIE -pie
[09:10] <pitti> the effect would be much like the global build flags, but a centralized change, so the only drawback is that you don't see it in build logs
[09:10] <AnAnt> Hobbsee: nope
[09:10] <keescook> I'll add logic to notice -norelro, etc.
[09:10] <pitti> keescook: for proper operation, we would need to change dpkg-buildpackage to add the wrapper gcc's to $PATH, of course, but for initial testing, a hack should suffice
[09:11] <keescook> sure.  I was thinking I could model the expected "real" correction instead of just hacking it.  :)
[09:12] <keescook> so, for ASLR, I swear we saw heap randomization while at UDS, but I don't see it on feisty now.
[09:12] <keescook> exec randomization is for sure not happening.
[09:12] <pitti> keescook: I envision a package ubuntu-gcc-wrapper with wrappers in /usr/share/ubuntu-gcc/ and a diversion of dpkg-buildpackage which mangles $PATH
[09:12] <keescook> ah, very good.
[09:12] <pitti> well, crackful, but effective
[09:13] <keescook> Program Headers: Type           Offset             VirtAddr           PhysAddr
[09:13] <keescook> hm
[09:13] <keescook> Program Headers:
[09:13] <keescook>   Type           Offset             VirtAddr           PhysAddr
[09:13] <keescook>   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
[09:13] <pitti> keescook: ah, that's from relro? 0 == arbitrary random location?
[09:14] <keescook> 555555554000-555555555000 r-xp 00000000 fd:00 1412097                    /scratch/ubuntu/build/local/pie
[09:14] <keescook> nah, that's PIE.
[09:14] <pitti> ah
[09:14] <keescook> relro is just an extra header with a few sections:
[09:14] <keescook>   GNU_RELRO      0x0000000000000de8 0x0000000000200de8 0x0000000000200de8
[09:14] <keescook>                  0x0000000000000218 0x0000000000000218  R      1
[09:14] <keescook>    08     .ctors .dtors .jcr .dynamic .got 
[09:15] <pitti> keescook: while at it, that dpkg-buildpackage wrapper should make any build fail which has ELFs with pages that are w and x :-P
[09:15] <keescook> Oooh!  Great idea!
[09:15] <keescook> that will break all KINDS of things, though.  :P
[09:15] <keescook> there are tons of packages that still have exec stack due to asm code.
[09:15] <keescook> :)
[09:15] <keescook> er
[09:15] <keescook> :(
[09:16] <keescook> gdb ftbfs> did you see that insanity?  tee isn't quitting.
[09:17] <keescook> should I upload gdb with the PIE patches even though the builds are busted?
[09:17] <keescook> it seems to work fine, and (at least) fedora has been running with it for a while now, so it's reasonably stable.
[09:18] <keescook> I've started trying to get it merged upstream, we'll see how that goes.
[09:18] <pitti> keescook: hm, I saw the FTFBS logs from my upload from yesterday
[09:18] <pitti> keescook: but it looked like it failed due to unexpectedly failed tests
[09:18] <pitti> keescook: was a bit strange, it built fine for me
[09:18] <pitti> locally
[09:19] <pitti> keescook: I suspect different kernels (I built under .20 AFAIR, buildds are probably edgy)
[09:19] <keescook> from what I see, the make check runs and finishes.  but the pipe open to "tee" stays.  tee is blocked on read(stdin...) and the shell is blocked on a wait() for tee.  bizarre
[09:19] <pitti> oh, ugh
[09:19] <keescook> hm, I'm still on 2.6.19-7
[09:19] <keescook> but I saw exactly the same behavior as the buildds (on both amd64 and the i386 chroot)
[09:20] <keescook> anyway, should I up the PIE patch anyway, and the build failures can be sorted out as we go?
[09:20] <pitti> keescook: it would only make sense if the package actually builds again
[09:20] <pitti> and we need a built gdb, the current one is totally broken
[09:21] <pitti> keescook: so feel free to throw in the PIE patch if you have a workaround/solution for the hang
[09:21] <keescook> I don't have anything yet.  :(
[09:22] <pitti> keescook: oh, right
[09:22] <pitti> the previous package even had *more* unexpected failures than my upload
[09:22] <pitti> and it still finished building
[09:22] <keescook> heh
[09:22] <pitti> so it's not that
[09:23] <pitti> keescook: maybe:
[09:23] <pitti>  $(MAKE) -C objdir/gdb check > objdir/check.log 2>&1
[09:23] <pitti>   cat objdir/check.log
[09:23] <keescook> yeah, the gnu.hash fixes the tests quite a bit.  (without your changes, the tests just grind away forever, slowly timing out)
[09:23] <pitti> keescook: if you can reproduce the hang, does that work for you?
[09:24] <pitti> keescook: right, I tried the previous package on current edgy, all tests fail
[09:24] <keescook> I can try that; I guess we don't need tee for automated builds.  :)
[09:24] <pitti> still strange...
[09:25] <pitti> as if make wouldn't close stdin or stderr...
[09:25] <Yagisan> it just doesn't like you pitti 
[09:26] <pitti> hi Yagisan 
[09:26] <Yagisan> long time no see
[09:26] <Yagisan> How are you mate ?
[09:26] <pitti> I'm great, and you?
[09:27] <Yagisan> going ok
[09:27] <pitti> keescook: right, buildds won't care, but it would suck for local builds of course
[09:27] <Yagisan> overloaded myself time-wise
[09:28] <keescook> If this actually works, I could just fake a tee:  touch log; tail -f log &; pid=$1; make check >> log 2>&1; kill $pid   :P
[09:28] <pitti> keescook: are you sure that & DTRT in scripts?
[09:29] <pitti> last time I tried something like that it blew up on my face
[09:29] <keescook> If you do it all on the same "line", I think it's safe.  I'll try it if this build is okay
[09:30] <pitti> keescook: did you happen to strace the make process when it hanged?
[09:30] <pitti> is it just select()ing? (i. e. poll())
[09:31] <keescook> the rules make?  I didn't.  the make check had already quit, though.
[09:31] <keescook> I'm wondering if it's a dash vs bash thing.
[09:31] <pitti> oh, good point
[09:32] <keescook> I couldn't reproduce it using simple cases, either.
[09:54] <keescook> pitti: yup, dropping tee fixes the build.  :(
[09:54] <pitti> keescook: weird, weird, weird
[09:59] <pitti> Mithrandir: btw, your give-back of gnome-panel in edgy-proposed didn't work
[10:00] <pitti> Mithrandir: but now the apt error message mentions different packages, so it did *something* :/
[10:00] <Mithrandir> pitti: I saw it; Adam's fixing it now.
[10:00] <pitti> ah, great
[10:08] <keescook> pitti: okay, off it goes, gdb_6.5.dfsg-2ubuntu3 has been uploaded with PIE and the tee-- fix.  I'm off to bed.
[10:08] <pitti> \o/
[10:12] <slomo> keescook: congrats :)
[10:20] <pitti> hey seb128 
[10:20] <seb128> hi pitti!
[10:22] <cjwatson> morning
[10:22] <pitti> hi cjwatson 
[10:25] <pitti> cjwatson: I uploaded a new s-t-b with the fixed conflicts yesterday
[10:25] <cjwatson> judging from shell history, I noticed that last night before I went to bed but then collapsed before remembering to process it
[10:25] <cjwatson> I'll do that now
[10:27] <pitti> great
[10:27] <cjwatson> pitti: could you attach the most recent s-t-b patch to the bug for completeness, please?
[10:27] <pitti> oh, sure, doing now
[10:29] <cjwatson> pitti: all done, please proceed to testing
[10:29] <pitti> great
[10:44] <stub> Launchpad will be going down in 15 minutes for a code update. Estimated downtime is 10 mins.
[10:45] <MidMark> hi I've a question: is there a motivation because a very stupid bug that annoy ALL people that uses amule, and that has a patch based in ONE line took 3 months (and still not fixed) to be committed in wxwidgets?
[10:46] <MidMark> where is the maitainer??
[10:46] <dholbach> good morning
[10:47] <MidMark> https://launchpad.net/distros/ubuntu/+source/amule/+bug/59138
[10:47] <Keybuk> MidMark: Ubuntu doesn't have maintainers (at least, not in the Debian sense).  amule is in universe, so you'd be best off asking on #ubuntu-motu
[10:47] <Ubugtu> Malone bug 59138 in wxwidgets "amule crashes when I close a tab" [Unknown,Unknown]  
[10:47] <MidMark> oook will do now
[10:52] <dholbach> ?
[10:52] <dholbach> sorry
[10:54] <jsgotangco> ah
[11:07] <mneptok> belligerent ghouls run Manchester schools. spineless bastards all.
[11:26] <seb128> mjg59: around?
[12:32] <pitti> carlos: I'm curious, how did your attempt for feisty langpacks work out?
[12:33] <carlos> pitti: waiting for kiko
[12:33] <pitti> ooh, new LP with icon and task tree shinyness
[12:36] <pitti> carlos: what do I have to do to clean up https://translations.launchpad.net/distros/ubuntu/edgy/+source/tsclient/+pots/tsclient/ru/+translate ?
[12:36] <carlos> pitti: nothing, I'm able to do it today
[12:36] <carlos> pitti: I had a problem with permissions
[12:36] <carlos> but today it was fixed
[12:36] <pitti> ah, cool
[12:37] <maswan> BenC: hey, any chance of a CONFIG_DEBUG_INFO in the near future for -dbg- stuff (aka make systemtap work, AIUI)
[12:46] <CypherBIOS> mvo: ping
[12:47] <Hobbsee> mvo: just merged apt-watch, hope that's OK.
[12:48] <gnomefreak> Hobbsee: apt-index-watcher?
[12:48] <Hobbsee> gnomefreak: er, yeah
[12:48] <Hobbsee> the one that's in universe
[12:49] <gnomefreak> thats not in universe 
[12:49] <gnomefreak> phew
[12:51] <CypherBIOS> mvo: when you come back, see this http://en.cypherbios.org/archives/4
[01:03] <seb128> mjg59: http://people.ubuntu.com/~seb128/compiz-update/, I've updated to the new version, switched to cdbs and moved changes to debian/patches too. If you want to have a look and let me know if you have some objection, I'll wait for your comments before uploading. What is the rational to use indirectRendering by default BTW?
[01:54] <gnomefreak> is beryl-core still FTB?
[01:56] <seb128> gnomefreak: hint: you want to use compiz ;)
[01:56] <gnomefreak> oh no :(
[01:57] <seb128> why no?
[01:57] <gnomefreak> seb128: last time i used compiz was during dapper devel and it was crap. i hope it has gotten better
[01:58] <seb128> gnomefreak: good reason to try it again
[01:58] <seb128> gnomefreak: http://people.ubuntu.com/~seb128/compiz-update/, I've started working on updating it to the new version if you want to try
[01:58] <gnomefreak> ok cool i will ty
[02:00] <gnomefreak> should i still grab the desktop-effects package?
[02:01] <seb128> gnomefreak: yep, that's an easy way to enable it and revert if it doesn't work fine (just use esc key or wait)
[02:02] <gnomefreak> ok ty
[02:03] <seb128> np
[02:04] <gnomefreak> seb128: the package cgwd shouldnt be a recommend since there is no package
[02:04] <gnomefreak> seb128: for the desktop-effects package ;)
[02:05] <seb128> gnomefreak: 
[02:05] <seb128> $ apt-cache show desktop-effects | grep Recommends
[02:05] <seb128> $
[02:05] <seb128> for compiz you mean
[02:05] <seb128> right :)
[02:05] <gnomefreak> yeah sorry
[02:06] <gnomefreak> i was installing the -effects package and it depends on compiz and the recommends shows up i forgot compiz was gonna be installed
[02:17] <Mithrandir> dholbach: do you understand why my networkmanager build doesn't seem to update the gtk icon cache on installation?
[02:17] <ogra> again ?
[02:18] <Mithrandir> (it uses cdbs, so I though it was supposed to call dh_iconcache and get that thing fixed automatically)
[02:18] <Hobbsee> Mithrandir: because it needs to call dh_iconcache.  i'll bet it's a custom cdbs.mk
[02:18] <ogra> seems we have that every beginning of a new release 
[02:18] <Mithrandir> ogra: you're not helping.
[02:18] <Mithrandir> Hobbsee: nope
[02:18] <Hobbsee> ogra: i saw that bug in edgy, but didnt fix it, as i'd need a sponsor
[02:19] <Mithrandir> ah, it's only called if you add the gnome package too
[02:19] <Mithrandir> as in, gnome.mk
[02:19] <dholbach> ah! :-)
[02:20] <Hobbsee> Mithrandir: gnome.mk isnt included in it
[02:20] <Mithrandir> Hobbsee: see four-five lines up. :-P
[02:21] <Hobbsee> Mithrandir: i meant at pre-install time
[02:21] <Mithrandir> I think I got it now.
[02:22] <Hobbsee> cool
[02:24] <seb128> is anybody working on the xorg-server merge with Debian?
[02:24] <Hobbsee> seb128: shouldnt you be asking that in #ubuntu-x or something?
[02:25] <seb128> Hobbsee: well, I expect that most of people are on -devel too
[02:25] <Hobbsee> ah
[02:25] <Hobbsee> true that
[02:25] <seb128> Hobbsee: and believe it if you want some non-xorg people are doing merges for xorg packages too :p
[02:25] <zul> morning
[02:25] <pitti> seb128: geser :)
[02:26] <pitti> hi zul
[02:26] <gnomefreak> morning zul 
[02:26] <seb128> hi pitti
[02:26] <Hobbsee> seb128: that's scary.  i've not attempted that
[02:26] <seb128> Hobbsee: the xorg-server one is assigned to me according to the merge list because I touched it to fix a bug before edgy :p
[02:26] <geser> pitti: I only merged the xserver-xorg-input-* from universe
[02:27] <pitti> geser: oh, I thought I saw more from you
[02:27] <gnomefreak> seb128: is there a theme package? i hate this boarderless windows. it happens on beryl also changing theme normally works
[02:27] <seb128> gnomefreak: compiz should respect the metacity theme no?
[02:27] <Hobbsee> seb128: heh.  poor bugger.
[02:27] <gnomefreak> its not i have no boarders
[02:27] <geser> pitti: no, only xserver-xorg-input-* and xserver-xorg-video-i810-modesetting
[02:27] <pitti> gnomefreak: bug 73544
[02:27] <Ubugtu> Malone bug 73544 in desktop-effects "enabled desktop effects window decoration" [Undecided,Confirmed]  http://launchpad.net/bugs/73544
[02:28] <gnomefreak> and window is stuck in upper left hand cornber
[02:28] <gnomefreak> pitti: ty
[02:28] <pitti> gnomefreak: Option "AddARGBGLXVisuals" "True"
[02:28] <gnomefreak> it is
[02:28] <gnomefreak> ff has boarder
[02:28] <gnomefreak> terminal doesnt :(
[02:28] <pitti> gnomefreak: right, current compiz' idea of workspaces is, erm, totally broken
[02:28] <gnomefreak> brb let me see what i can do
[02:28] <seb128> pitti: hum?
[02:29] <seb128> pitti: how so?
[02:29] <pitti> seb128: bug 75597
[02:29] <Ubugtu> Malone bug 75597 in compiz "workspace handling totally broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75597
[02:29] <seb128> the workspace switcher applet is working fine for me with 0.3.4
[02:29] <seb128> pitti: 
 http://people.ubuntu.com/~seb128/compiz-update/ is anybody wants to try compiz 0.3.4
[02:29] <seb128>  it understands workspaces now
[02:30] <pitti> oh I might have filed a dup of bug 74767 with that
[02:30] <Ubugtu> Malone bug 74767 in compiz "Use workspaces instead of viewports by default" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74767
[02:30] <seb128> pitti: from #ubuntu-desktop 1h30 ago :p
[02:30] <pitti> seb128: ah, was away at that time :)
[02:30] <seb128> pitti: I would appreciate if you can give it a try
[02:30] <pitti> seb128: does it also solve the horribly slow window resizing?
[02:30] <pitti> seb128: right, will do
[02:30] <seb128> well
[02:31] <seb128> I think that's because the package is patched to use indirectRendering by default
[02:31] <seb128> I've pinged mjg59 about that, I'm waiting for a reply
[02:31] <seb128> you can maybe try compiz --direct-rendering --replace
[02:32] <seb128> I get a white screen when doing that
[02:32] <seb128> cube rotation works though
[02:32] <seb128> all the face are all white though :/
[02:32] <seb128> I had to run metacity --replace to get my screen back :p
[02:32] <pitti> hm
[02:32] <cypher1> is anyone part of upstart-devel ML ?
[02:32] <seb128> pitti: BTW https://launchpad.net/distros/ubuntu/+source/compiz/+bug/58373
[02:32] <Ubugtu> Malone bug 58373 in xorg-server "Blue compiz for PowerPC" [Unknown,In progress]  
[02:32] <pitti> seb128: it's just that with normal metacity it's smooth and slick
[02:33] <gnomefreak> i added the boolean option and it worked
[02:33] <seb128> pitti: your blue screen on ppc is xorg-server bog
[02:33] <pitti> oh, that too
[02:33] <seb128> gnomefreak: which one?
[02:33] <seb128> pitti: that's why I'm asking about the sync, it's fixed to Debian, and I'm pondering just patching for that or doing the sync
[02:33] <gnomefreak> Option          "AddARGBGLXVisuals"    "true" Option          "AddARGBGLXVisuals"    "boolean"
[02:33] <gnomefreak> both of those are needed
[02:34] <seb128> ok
[02:34] <seb128> what videodriver do you use?
[02:34] <gnomefreak> atleast on my nvidia 5200
[02:34] <gnomefreak> :)
[02:34] <gnomefreak> nvidia 9xxx
[02:34] <gnomefreak> oh wait crap
[02:35] <cypher1> by any chance, is anyone using ATI Rage 128 with direct rendering on ?
[02:35] <gnomefreak> ok yep still working good :) i forgot to enable compiz :(
[02:35] <cjwatson> seb128: I don't know for sure, but from the way that rodarvus hasn't done any uploads to feisty, I'm guessing that other people need to step in
[02:36] <seb128> cjwatson: ok, what I thought, I figured I would ask first
[02:36] <cjwatson> I'll mail him and ask
[02:36] <seb128> I'll upload that on monday if I get no reply before
[02:36] <seb128> I don't want to upload some xorg package on friday
[02:36] <gnomefreak> seb128: no it doesnt fix it
[02:36] <cjwatson> seb128: sensible
[02:37] <seb128> gnomefreak: "fix" what?
[02:37] <gnomefreak> seb128: the boarderless windows
[02:37] <seb128> gnomefreak: what plugins do you have to /apps/compiz/general/allscreens/options/active_plugins ?
[02:37] <seb128> you need "decoration"
[02:38] <gnomefreak> hmmmmm
[02:39] <pitti> seb128: compiz amd64 debs in chinstrap:~pitti if you want to copy them to your people dir
[02:39] <gnomefreak> seb128: how do i open the plugins package?
[02:39] <gnomefreak> there is no menu
[02:39] <seb128> gnomefreak: "unset" the gconf key from gconf-editor to get the default list
[02:39] <seb128> gnomefreak: that's a gconf key
[02:39] <seb128> pitti: danke
[02:39] <pitti> seb128: de rien :)
[02:39] <gnomefreak> i see it now i thought compiz removbed gconfig awhile ago
[02:40] <seb128> gnomefreak: user config stays to gconf
[02:40] <seb128> nothing clean your user data
[02:41] <gnomefreak> decoration is there
[02:42] <seb128> gnomefreak: what about /apps/compiz/plugins/decoration/allscreens/options/command ?
[02:42] <gnomefreak> gtk-window-decorator
[02:43] <seb128> pitti: copied
[02:43] <seb128> gnomefreak: weird, is gtk-window-decorator running?
[02:44] <gnomefreak> yep its in ps aux
[02:44] <seb128> so I don't know
[02:44] <pitti> brb, restarting X with new nvidia option
[02:44] <Treenaks> is the decorator plugin loaded?
[02:44] <seb128> I've the same theme as with metacity
[02:44] <seb128> Treenaks: <gnomefreak> decoration is there
[02:44] <gnomefreak> Treenaks: i would assume since its in ps aux
[02:45] <seb128> gnomefreak: are you sure than the window is not simply under the top panel? Does alt + click for move it work?
[02:45] <gnomefreak> ah
[02:46] <gnomefreak> ummmm shouldnt the panels respect the windows?
[02:46] <gnomefreak> seb128: and moving it worked 
[02:46] <cjwatson> seb128: if you have xorg-server at all ready, please take it
[02:46] <cjwatson> seb128: it might need some library merges first, though
[02:47] <pitti> seb128: ok, tested; window resizing is fine now, but workspaces are as broken as before
[02:47] <seb128> cjwatson: no, I've not started on it yet, but since it's on my list and I want some fixes from Debian I was going to start on it if nobody else already started
[02:47] <seb128> pitti: you get one workspace only on the workspace switcher?
[02:48] <pitti> seb128: well, there still seem to be two different concepts around
[02:48] <pitti> one is the cube workspace, and the other the workspace switcher workspace
[02:49] <seb128> pitti: desktop-effect has a box to map workspace on cube faces
[02:49] <pitti> and on top of that, the switcher only shows windows at the current space, not from the others any more
[02:49] <seb128> but right, it's still optimal
[02:49] <seb128> *not* optimal
[02:49] <pitti> seb128: oh, that option; I thought it was 'show cube effects', not 'break my workspaces'
[02:49] <Mithrandir> pitti: your avahi patch applied without fuzz or rejects.
[02:49] <Mithrandir> (to nm)
[02:50] <pitti> Mithrandir: \o/
[02:51] <pitti> seb128: ouch, when I disable that option it gets worse -- now I'm totally confused
[02:52] <seb128> pitti: still some way to go, I think I'll have a look to those libwnck patches too
[02:52] <seb128> pitti: it's still early, let's give it a try next year when new versions and patches will have landed ;)
[02:52] <Zdra> dholbach: hi ! do you know if there is a package repos with backport of telepathy stuff for edgy ?
[02:52] <pitti> seb128: right
[02:53] <pitti> seb128: so the idea is *not* to put that into feisty by default?
[02:54] <seb128> pitti: well, that's either that or beryl as I understand it
[02:54] <pitti> urgh
[02:54] <seb128> pitti: so the idea is that I'll spend some time from now to get *that* on shape :p
[02:55] <seb128> from now being next week
[02:55] <seb128> landing new version and the wnck patches going with it maybe
[02:55] <seb128> and some configurator tools available on revu
[02:57] <gnomefreak> is there an easy way to enable all plugins?
[02:58] <apokryphos> gnomefreak: on the command-line. compiz --replace gconf decoration.......
[02:58] <gnomefreak> and list the plugins?
[02:58] <apokryphos> yeah
[02:58] <cjwatson> Keybuk: <request type="implausible">It'd be lovely to have merges.ubuntu.com topologically sorted in build-dependency order</request>
[02:59] <apokryphos> gnomefreak: i.e. compiz --replace gconf decoration wobbly fade minimize cube rotate zoom scale move resize place menu switcher water &
[02:59] <gnomefreak> ah ty i got my rain back :)
[03:01] <Hobbsee> cjwatson: in build-dep order?
[03:01] <rodarvus> cjwatson: I'm doing X.Org merges now. I had to start very late (due to personal problems), but I expect to have them completed this weekend
[03:02] <pitti> seb128: argh, the keyboard indicator applet suddenly grew to a hundred pixels or so :/
[03:03] <pitti> seb128: I switched to the German keyboard layout for a minute, and then it suddenly displayed 'de nodeadkeys' instead of 'DE'; and now it doesn't shrink any more (even though it just displays 'us')
[03:03] <seb128> pitti: nice bug
[03:03] <pitti> will file later
[03:03] <cjwatson> rodarvus: hmm, OK, that would be great. Can you keep me informed?
[03:03] <seb128> rodarvus: ah, nice, so xorg-server is on your list too? ;)
[03:05] <cjwatson> rodarvus: I expect quite a few syncs in the list, based on our experiences last time round; let me know if you need to coordinate with the archive team
[03:07] <Hobbsee> seb128: *grin*.  you're just trying to avoid it
[03:08] <seb128> Hobbsee: like you would not? :p
[03:09] <Hobbsee> seb128: i'm not crazy enough to touch it in the first place, just so that i wouldnt have to merge it :P
[03:11] <Mithrandir> Hobbsee: you can merge it anyway! :-)
[03:13] <StevenK> Surely a non core-dev doing main merges is a little pointless?
[03:13] <rodarvus> cjwatson: sure, I will
[03:14] <rodarvus> seb128: yes
[03:14] <seb128> cool
[03:14] <seb128> I'm away for ~45min, bbl
[03:14] <rodarvus> cjwatson: this time I'm doing the packaging locally, so it will be a long queue of uploads in one time, instead of a longish upload, taking a few days
[03:15] <rodarvus> so the uplods are (hopefully) less disruptive
[03:15] <cjwatson> rodarvus: you don't expect it to matter whether uploads are built against old or new libraries, then?
[03:15] <seb128> most of those uploads should not break anything
[03:15] <cjwatson> we were probably overly conservative last time, I agree
[03:16] <Hobbsee> Mithrandir: i'm not insane :P
[03:16] <Hobbsee> Mithrandir: besides, i'd need a sponsor.
[03:16] <Hobbsee> StevenK: depends how good that person is at gettign people to do what they want
[03:18] <Mithrandir> Hobbsee: you're here, so the former is clearly not true. :-)
[03:18] <Hobbsee> Mithrandir: hehe, good point. 
[03:20] <Hobbsee> Mithrandir: i'm just in here as part of my master plan to take over the world.
[03:22] <rodarvus> cjwatson: no, this is not what I said. I *will* wait for new binaries to be published when/if needed. (or Build-Depends on the new version, if necessary).
[03:23] <rodarvus> what I'm doing differently is that I will proceed with all uploads/sync requests when I have it all updated, instead of doing small bits of the upload every day
[03:23] <rodarvus> I believe this tends to be less disruptive to the quality of the archive, as the transition time will be smaller
[03:26] <cjwatson> rodarvus: oh, I see
[03:27] <cjwatson> rodarvus: hmm, the only problem is that it's harder for the rest of the team to tell how much has been done in the event that they're waiting for something, and you have a higher risk of conflicts
[03:27] <cjwatson> rodarvus: but if you've already started down this path and you'll be done by the end of the weekend, then yoou might as well continue now
[03:27] <cjwatson> youo
[03:27] <cjwatson> damnit. "you"
[03:28] <elmo> english is hard
[03:28] <cjwatson> keyboards are hard
[03:29] <cjwatson> speaking of merges, I'm still on top of pam, but just asking vorlon about a couple of weird-looking bits in the Debian patch
[03:32] <ailean> pitti, thanks for fixing the scots bug
[03:36] <matthewrevell> heno: Howdy - did you get any feedback from the rest of the team for Fix-it Friday?
[03:37] <heno> matthewrevell: generally positive, I'll speak with simon today and draw up some ideas
[03:37] <heno> matthewrevell: do you want to have a talk as well about it?
[03:38] <dholbach> Zdra: no, there's not
[03:39] <matthewrevell> heno: I'd be happy to. My main involvement is to report what's been fixed, at the moment. Once it's happened a few times, I'll let people know it's happening a little more.
[03:39] <matthewrevell> heno: Let me know when and where  and I should be there.
[03:40] <heno> matthewrevell: ok, cool. I've forwarded you a mail I sent to the team yesterday
[03:40] <matthewrevell> heno: Thanks.
[03:41] <heno> dholbach: thanks for making the bughelper code look sane :)  I've pushed up your changes
[03:42] <dholbach> heno: rock and roll :-)
[03:42] <dholbach> heno: I thought about adding the feature to handle queries with more than 75 bugs next
[03:43] <heno> and peaking into attachments
[03:43] <dholbach> right
[03:43] <dholbach> 10MB crash files - yay! :-)
[03:43] <bddebian> Heya
[03:43] <heno> :) the LP guys and server admins will love us
[03:44] <heno> then post it on the fridge :)
[03:47] <Keybuk> cjwatson: <response type="glib">I'll get one of my people on it, right away</response>
[03:49] <bddebian> heh
[03:50] <pitti> ailean: you're welcome
[03:50] <pitti> Keybuk: 'glib'?
[03:50] <bddebian> flippant?
[03:50] <pitti> oh, nothing to do with libglib, sorry :)
[03:51] <Keybuk> pitti: polite, and positive, but with no intention of going through with it
[03:51] <Mithrandir> there, new network-manager uploaded.  
[03:51] <Mithrandir> it might work.
[03:51] <Mithrandir> ;-)
[03:51] <bhale> Mithrandir: woo!
[03:52] <bddebian> "If it compiles it works" right? :)
[03:52] <pitti> bddebian: right, everything else is a gcc bug, and thus doko's
[03:53] <Mithrandir> bddebian: hey, it even installed on _two_ machines here.  It's clearly ready for release.
[03:53] <bddebian> hehe
[03:54] <giskard> Mithrandir, 0.6.4?
[03:54] <cjwatson> Keybuk: heh
[03:55] <Mithrandir> giskard: yeah, based on your merge; thanks.
[03:56] <Keybuk> Mithrandir: the fact that neither machine can now access the network is just a minor detail?
[03:57] <Mithrandir> Keybuk: yeah.
[03:57] <Keybuk> after all, the work being done and uploaded is good enough for Feature Freeze
[03:57] <Keybuk> the fact it doesn't work is just a bug, and can be done after
[03:57] <Keybuk> ? :)
[03:57] <Mithrandir> Keybuk: actually, this machine is really good, since it manages to talk to my IRC client without networking!
[03:58] <mjg59> seb128: Indirectrendering needs to be default for aiglx
[03:59] <giskard> Mithrandir, rejected :(
[03:59] <bddebian> doh
[04:00] <Mithrandir> giskard: meh, I suck.
[04:01] <Mithrandir> there, reuploaded
[04:02] <mjg59> seb128: Otherwise, looks good
[04:06] <seb128> mjg59: nothing against the switch to cdbs? Should I upload the update then?
[04:07] <mjg59> seb128: Well, I hate cdbs with a passion, but I seem to be in a minority so feel free :)
[04:08] <seb128> mjg59: ok, let's keep it to be coherent with the other desktop packages then ;) thank you
[04:09] <ogra> mjg59, you are not in a minority ... :)
[04:10] <seb128> ogra: you don't make a majority :p
[04:11] <Keybuk> CDBS Must Die.
[04:11] <ogra> mjg59, i'll check the CVS for g-p-m over the weekend, if that isnt sufficient, i'll disable pieces in the existing glade file
[04:11] <ogra> seb128, i didnt say that :P
[04:12] <giskard> ogra, why you want do this?
[04:13] <ogra> giskard, did you try the new UI ?
[04:13] <ogra> its horrible ... 
[04:13] <giskard> no :( 
[04:14] <giskard> did you already talked with hughsie?
[04:14] <ogra> giskard, apart from that i have bug 75811, bug 75804 and bug 75803 since the upload
[04:14] <Ubugtu> Malone bug 75811 in gnome-power-manager "gnome-power-manager UI has become unnecessarily complicated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75811
[04:14] <Ubugtu> Malone bug 75804 in gnome-power-manager "performance setting missing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75804
[04:14] <Ubugtu> Malone bug 75803 in gnome-power-manager "non privilege user can change cpu speed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75803
[04:15] <ogra> giskard, mjg59 mailed the g-p-m list and hughsie replied we should have a look at CVS...
[04:15] <ogra> which i plan to look qat if i find time over the weekend
[04:15] <jdong> o_O
[04:15] <jdong> mr evolution says "Getting message 40 of 98"
[04:15] <jdong> I'm guessing today's archive day?
[04:16] <jdong> nope, nvm, just a bunch of spam
[04:16] <giskard> ogra, he said "Checkout CVS - I've made things a lot simpler."
[04:16] <giskard> (but you probably already know this)
[04:17] <ogra> yep, i'm subscribed to g-p-m
[04:18] <pitti> Mithrandir: just reading your merge log; was the autoipd patch already accepted in Debian? (no -v :( ) or did you simply not mention it in the merge log?
[04:19] <giskard> pitti, no :(
[04:20] <giskard> pitti, i will add it but afaik it will not enter in etch.
[04:20] <pitti> giskard: I sent it to upstream, let's see what he says
[04:20] <pitti> giskard: it's not really that crucial any more
[04:21] <pitti> giskard: I erroneously thought that you had to use avahi-autoipd to make SD work, but that was just due to the broken avahi security patch with network-manager
[04:21] <pitti> giskard: I didn't try, but nss-mdns should actually work with n-m's internal ipv4ll implementation as well
[04:22] <giskard> ok.
[04:22] <slomo> pitti: nss-mdns doesn't need a ipv4ll implementation at all, only mdns by avahi-daemon
[04:22] <pitti> right
[04:23] <pitti> seb128: btw, new gdb is in the archive; running the pkg-create-dbgsym test suite with that on 2.6.19 and .20 would be great
[04:24] <slomo> pitti: have fun :)
[04:36] <seb128> pitti: 
[04:36] <seb128> PASS: dbgsym ddeb for dhtest1_2.3-1_i386.deb exists
[04:36] <seb128> PASS: unpacked/usr/bin/crash has .gnu_debuglink section
[04:36] <seb128> Failed to read a valid object file image from memory.
[04:36] <seb128> etc
[04:37] <seb128> $ uname -r
[04:37] <seb128> 2.6.20-1-generic
[04:37] <seb128> ii  gdb                      6.5.dfsg-2ubuntu3        The GNU Debugger
[04:43] <dieman_> wow, encrypted disk is really not as much of a performance hit as I would have figured
[04:46] <jdong> dieman_: got a powerful CPU?
[04:46] <pitti> seb128: hmm, wfm on amd64; so that's still the kernel bug
[04:47] <pitti> seb128: bug 74691, something for BenC
[04:47] <Ubugtu> Malone bug 74691 in linux-source-2.6.19 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix committed]  http://launchpad.net/bugs/74691
[04:47] <pitti> seb128: thanks for testing!
[04:47] <seb128> pitti: ok
[04:47] <seb128> np
[04:47] <dieman_> jdong: im using a 1.2Ghz ULV chip in my laptop...
[04:47] <dieman_> jdong: its not insanely powerful.
[04:47] <jdong> dieman_: what kind of ULV chip? who makes it?
[04:48] <dieman_> jdong: i think its because the kernel in edgy (I don't think the dapper kernel had this) has the i586 optimized aes module
[04:48] <dieman_> jdong: intel 1.2ghz ULV pentium m
[04:48] <jdong> dieman_: the kernel in dapper was "more" optimized
[04:48] <jdong> dieman_: i686
[04:48] <dieman_> ahh, nifty
[04:48] <jdong> but that's pretty irrelevant
[04:48] <jdong> the relevant issue is...
[04:49] <jdong> dieman_: you realize your processor has similar power to a mid-grade Opteron chip from last year?
[04:49] <jdong> ;-)
[04:49] <dieman_> this isn't a core or core2 tho :)
[04:49] <jdong> A 1.2GHz P-M is not a low-power chip
[04:49] <dieman_> this box is over 1.5 years old :)
[04:50] <dieman_> "753 (1.2 GHz) models are ultra-low voltage (0.940 V) with a TDP of 5 W."
[04:50] <dieman_> http://en.wikipedia.org/wiki/Intel_Pentium_M
[04:51] <dieman_> i'll admit, its not OLPC 'low voltage'
[04:51] <dieman_> though
[04:51] <dieman_> i'm just seeing a huge push at my employer for encrypting all laptop disks
[04:52] <dieman_> basically the fallout of privacy laws
[05:07] <\sh> Keybuk: do you happen to know why diacanvas2 (source pkg) is not on the universe merging list? :)
[05:09] <Keybuk> \sh: because it's up to date?
[05:11] <\sh> Keybuk: not as p.u.c. tells me somehow
[05:11] <\sh> 0.14.2-2ubuntu1 in feisty and 0.14.4-4 in debian unstable
[05:12] <geser> \sh: diacanvas2 FTBFS
[05:12] <\sh> ah...I can see now...:(
[05:13] <geser> I have a fix for it but it is blocked by bug 75606
[05:13] <Ubugtu> Malone bug 75606 in pygtk "Module codegen.createdefs is not installed" [Unknown,Unconfirmed]  http://launchpad.net/bugs/75606
[05:14] <Keybuk> \sh: right, source package is newer than the binaries because it FTBFS
[05:14] <Keybuk> https://launchpad.net/distros/ubuntu/+source/diacanvas2
[05:15] <\sh> Keybuk: yepp
[05:26] <BenC> pitti: Work on specs  today, which includes apport :)
[05:32] <seb128> BenC: hi
[05:32] <BenC> seb128: hey
[05:33] <BenC> seb128: I'm going to try to get around to that gdb thing over the weekend
[05:33] <seb128> BenC: do you know if there is already a bug open about 8139 network cards breaking after some time on 2.6.19 or 2.6.20?
[05:33] <seb128> BenC: ok, thank you
[05:33] <BenC> seb128: I remember there is a bug about it in edgy/2.6.17
[05:33] <BenC> or maybe that was 8169
[05:37] <seb128> BenC: well, 2.6.17 works fine for me, 2.6.19 crash like several time a day (I did try for a long time, I rolled back to using 2.6.17 while waiting for 2.6.20), and I got the same problem once with 2.6.20 since I'm running it
[05:37] <seb128> what informations are useful for such bugs out of lspci and syslog log?
[05:38] <BenC> seb128: Please test 2.6.20
[05:38] <BenC> if you need lrm, I should have it uploaded over the weekend
[05:43] <jdong> BenC: are the metapackages updated yet for 2.6.20 in feisty?
[05:43] <seb128> sorry, xorg crashed
[05:43] <BenC> jdong: no
[05:44] <seb128> BenC: I'm running 2.6.20 atm, network card stop working only once since I use it
[05:44] <seb128> when it stops working it prints that to syslog
[05:44] <seb128> kernel: [  259.246426]  NETDEV WATCHDOG: eth1: transmit timed out
[05:44] <seb128> kernel: [  259.246436]  eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x2, t=180.
[05:45] <seb128> a bunch of times
[05:46] <BenC> seb128: That may be work queue related breakage
[05:46] <seb128> what information could be useful with a bug like that?
[05:47] <kylem> BenC, if it happened with .19 then it probably isn't workqueue related...
[05:48] <BenC> oh, true
[05:48] <kylem> seb128, what kind of network card? :)
[05:49] <seb128> kylem: 
[05:49] <seb128> 02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
[05:49] <seb128>         Subsystem: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
[05:49] <seb128>         Flags: medium devsel, IRQ 19
[05:49] <seb128>         I/O ports at c000 [size=32] 
[05:49] <xipietotec> question regarding Fiesty re: recent kernel news regarding binary blobs, does this mean that feisty won't be distributed with Nvidia and ATI drivers pre-installed?
[05:50] <jdong> xipietotec: what recent kernel news regarding binary blobs?
[05:50] <jdong> xipietotec: I thought Linus posted a retort to it, and the patch was retracted
[05:51] <kylem> seb128, what driver and can you paste just the first line of the -n so i can see what pci id it has?
[05:51] <xipietotec> the patch was retracted, but the linux kernel the plans to have the kernel free of all binary blobs are still going through
[05:52] <xipietotec> the patch was retracted because it prevented users from adding binary blobs as well (If I'm not mistaken)
[05:52] <jdong> I doubt it'll happen with Feisty though
[05:52] <jdong> if anything happens
[05:52] <seb128> kylem: 8390                   11904  1 ne2k_pci
[05:53] <seb128> kylem: 02:09.0 0200: 10ec:8029
[05:53] <xipietotec> 'cause It seems to be the prevailing opinion of people in #gnu and #fsf that binary blobs in the kernel are illegal
[05:53] <kylem> seb128, oh wow. that's a seriously classic piece of hardware.
[05:54] <keescook> xipietotec: that patch didn't stop anything; it just issued a warning.  so, no, I think the mainline kernel will continue to allow binary drivers for some time.
[05:54] <Mithrandir> pitti: I just forgot to mention it.
[05:55] <seb128> kylem: well, my other network card broke so I got an old one out of the stock, and it's working fine for months now so I didn't bother replacing it :)
[05:55] <xipietotec> keescook: hrrm, cool
[05:55] <xipietotec> I guess
[05:55] <seb128> hey keescook
[06:27] <orvils> Hello... I have a question about gnome latvian (lv) localisation package. Due to the rosetta bug 68014 we had a lot of mistakes in Latvian translations of gnome. Today I uploaded fixes to rosetta, and I would like to know when we can expect update to gnome-lv package?
[06:27] <Ubugtu> Malone bug 68014 in rosetta "Rosetta reverts translation fixes to old faulty values" [Critical,Fix released]  http://launchpad.net/bugs/68014
[06:28] <orvils> Can anyone make an update of gnome-base-lv or gnome-lv packages?
[06:28] <cjwatson> orvils: contact pitti
[06:28] <pitti> orvils: hi
[06:29] <orvils> pitti, hi... can you help with the update?
[06:29] <pitti> orvils: was this a regression of the -updates pacakges uploaded yesterday? or has it always been broken?
[06:30] <pitti> orvils: the next regular update is on January 2nd, but if the latest edgy/dapper updates introduced a regression, I'm fine to do an -lv update out of band
[06:31] <orvils> it was broken for a while (some 2 month), but due to the bug i mentioned uploads to rosetta were disabled and we couldn't fix these mistakes... now they are fixed 
[06:31] <pitti> orvils: oh, I see; well, a stable release update is painful, so TBH I'd rather wait until January
[06:32] <pitti> orvils: however, please test the daily language packs and tell me if/when they get fixed
[06:32] <pitti> orvils: deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates/ ./
[06:32] <pitti> orvils: (likewise with dapper)
[06:32] <orvils> ok
[06:32] <orvils> january is notthat far away... we can wait :)
[06:33] <dholbach> hey heno
[06:33] <pitti> orvils: and, as I said, you are welcome to use the daily packages
[06:33] <dholbach> heno: how's it going?
[06:33] <pitti> orvils: in general I recommend translators to use them to immediately get and give feedback
[06:33] <orvils> ok... thanks...
[06:34] <heno> dholbach: good, triaging :)
[06:34] <dholbach> heno: nice :-)
[06:34] <heno> dholbach: even fixed a bug after you in bughelper ;)
[06:34] <dholbach> heno: ROCK, I'll merge from you :)
[06:35] <dholbach> heno: does your bughelper mail mean that we'd get a HUGE xml blob containing all bug information? or did I get that wrong?
[06:35] <heno> dholbach: I've asked the LP guys for some XML data
[06:35] <heno> it would make sense if we could choose a subset
[06:36] <dholbach> and it'd probably be quite big and probably not always up to date?
[06:36] <heno> like the evo bugs with the word 'pop' in them
[06:36] <heno> right, but it could be set up to rsync I guess
[06:37] <heno> it should be a feature on the advanced search page: dump to xml
[06:37] <dholbach> ah ok
[06:37] <heno> so you can get what you need
[06:37] <heno> imo
[06:37] <dholbach> but I guess this is a feature that is planned and might take some time to get implemented, right?
[06:38] <heno> yes, but I'm sure we can get some sample data to play with
[06:38] <dholbach> if that's the case, I think we should continue with our efforts and at some stage start to write the xml code - that could happen plugin-esque
[06:39] <heno> it's a feature they were planning anyway, which was set to low priority, but now elevated to high again
[06:39] <dholbach> that's great to hear
[06:40] <heno> the previous usecase was projects considering malone, but worried about how to get the data back out if they changed their minds
[06:40] <dholbach> I think we should continue with our efforts. stuff like the command line interface and making the .info file structure cleverer will have to happen anyway
[06:40] <dholbach> right
[06:41] <heno> dholbach: agree, the info files need some love (and content ...)
[06:42] <jdong> nm-netlink-monitor.c:52:27: error: linux/if_addr.h: No such file or directory
[06:42] <jdong> aww, no nm 0.6.4 on edgy for me :(
[06:43] <pitti> jdong: current feisty package has a patch for that
[06:43] <pitti> jdong: oh, argh, no; not for that
[06:43] <cjwatson> jdong: there's a post on ubuntu-devel-announce from a month or two ago explaining how to fix that problem in general
[06:43] <cjwatson> from Fabio
[06:43] <dholbach> heno: i'll look into pitti's xml file structure for the apport bug patterns
[06:43] <pitti> cjwatson: that explained it in the other direction
[06:43] <jdong> cjwatson: oh?
[06:43] <pitti> jdong: my gut feeling is that merely removing the #include should work on edgy
[06:43] <dholbach> heno: which is xml but gives us more flexibility
[06:43] <heno> dholbach: yep, hat sounds good
[06:44] <heno> pitti: explained that a bit for me yesterday
[06:44] <pitti> dholbach: heno and I had a quick talk about this yesterday; we want to get something cool at the sprint
[06:44] <heno> \o/
[06:45] <dholbach> pitti: it'd be great to have a shared set of .xml/.info files
[06:45] <cjwatson> actually, it may have been ubuntu-devel and not -announce
[06:45] <heno> yep, catch the bugs in both ends :)
[06:45] <dholbach> i'll have a look at them and see how that could make sense
[06:46] <cjwatson> jdong: https://lists.ubuntu.com/archives/ubuntu-devel/2006-November/022171.html
[06:46] <heno> dholbach: where can I see them? the apport source?
[06:46] <cjwatson> pitti's right, it's the other direction
[06:46] <pitti> heno: http://people.ubuntu.com/~pitti/bugpatterns/
[06:46] <heno> cool, thx
[06:46] <jdong> cjwatson: useful nonetheless
[06:46] <dholbach> pitti was faster :)
[06:47] <dholbach> heno: we shouldn't feel guilty about making ubuntu-bugsquad@ a bughelper-dev@ list ;-)
[06:47] <pitti> heno: erm, the coreutils one is still the demo that I gave on the annoucement; it's bogus, of course :)
[06:48] <dholbach> heno: I'm happy to work on that xml code (but will look at pitti's code first)
[06:48] <heno> makes sense
[06:48] <pitti> dholbach, heno: the format is as general as I could think of; you can do arbitrary matches on apport-style reports; but we might need more operators; if you need something, I'm happy to add it
[06:50] <jdong> yay, it appears to have gotten past that build step
[06:51] <heno> pitti: I didn't see version # in there but I'm sure you'll add that (the version at which the bug is kown to be fixed for example)
[06:52] <jdong> successful build; thanks cjwatson, pitti
[06:52] <heno> from that we should have bughelper look up distro release version, to make it easier to triagers
[06:52] <heno> that's a common question
[06:53] <dholbach> pitti: generally we want to be able to say 1) this bug is a dup of #24797 or 2) give out an arbitrary message like "You might want to subscribe ubuntu-x-swat on this" - I think it'd make sense to have several DoesInclude and DoesNotInclude tags to determine if it's a match
[06:53] <dholbach> pitti: I'm not sure if it makes sense to integrate that into the apport bug patterns - atm we're still in the brain storming phase :)
[06:55] <pitti> dholbach: not sure yet; let's collect some use cases, write them down, and then do the pattern design on them
[06:55] <pitti> dholbach: since it's more or less the same thing (identify a bug based on some properties of a report), I think it should make sense to have those in the same db
[06:56] <pitti> dholbach: for crashes I only need the properties -> bug # mapping, but if the db has more info, that won't hurt me :)
[06:56] <pitti> dholbach: and likewise, if you feed a bug through that db, you can find out whether it's already known as another bug
[06:56] <pitti> oh, door bell, bbl
[06:57] <dholbach> pitti: makes perfect sense
[06:57] <pitti> dholbach: the arbitrary message thing is interesting, though, and should be added
[06:58] <pitti> dholbach: maybe as a second stage; (1) properties -> bug#, (2) bug# -> further information
[06:58] <heno> pitti: I think they key difference is that with apport you want to be quite sure when you indentify a dupe and drop the bug, while with debhelper you can tell the triager: It's similar to all these 10 bugs, go have a look
[06:58] <pitti> debhelper?
[06:58] <pitti> ah, bughelper
[06:58] <dholbach> bughelper! :-)
[06:58] <heno> erm, bughelper
[06:58] <pitti> heno: right, that might be an issue
[06:58] <pitti> argh, have to leave for a bit, sorry
[06:59] <dholbach> pitti: no problem - you'll be off for VAC then?
[07:01] <dholbach> heno: thanks for the fixes - I'll push them to ~bugsquad/bughelper/main if you don't mind
[07:01] <heno> dholbach: please do
[07:02] <pitti> dholbach: semi-off; I'll still be around now and then, as I wrote
[07:02] <dholbach> pitti: have a good, refreshing, relaxing time :-)
[07:04] <dholbach> heno: done
[07:16] <bluefoxicy> ugh
[07:16] <bluefoxicy> I have like 2 copies of beagled in my start-up programs according to gnome-session-manager
[07:37] <jdong> bluefoxicy: that does tend to happen...
[07:37] <jdong> bluefoxicy: amusingly nm-applet has done that to me before
[07:37] <jdong> that was a bit more amusing
[07:37] <jdong> since apparently nm doesn't deal well with two clients trying to simultaneously operate
[07:38] <bluefoxicy> jdong:  one of them isn't from a package
[07:38] <bluefoxicy> jdong:  I guess it got there by me telling beagle to start up beagled automatically, long ago, when I wanted to play with it
[07:38] <bluefoxicy> i.e. somehow beagle, without my authorization, wrote root-owned files into a root-owned directory
[07:38] <jdong> bluefoxicy: yep
[07:38] <jdong> bluefoxicy: same with nm-applet; I accidently saved my session with it running
[07:38] <bluefoxicy> it just magically got root
[07:38] <bluefoxicy> jdong:  this was in /etc/xdg/autostart/
[07:39] <jdong> whoa
[07:39] <jdong> that's weird :)
[07:39] <bluefoxicy> ~$ dpkg-query -S /etc/xdg/autostart/beagled.desktop 
[07:39] <bluefoxicy> dpkg: /etc/xdg/autostart/beagled.desktop not found.
[07:39] <bluefoxicy> ~$ sudo rm /etc/xdg/autostart/beagled.desktop
[07:39] <bluefoxicy> that ends that.
[07:41] <keescook> BenC: 2.6.20-1> so far, so good.  boots my X2 3800+ okay
[07:41] <bluefoxicy> jdong:  someone needs to background modprobe, damn.
[07:42] <BenC> keescook: Great, thanks
[07:42] <jdong> bluefoxicy: I'm not sure how well that'd work :)
[07:42] <bluefoxicy> jdong:  my boot process halts for 10 seconds waiting for modprobe
[07:43] <bluefoxicy> jdong:  when upstart is fully integrated that will probably go away anyway
[07:43] <jdong> bluefoxicy: modprobes tend to stall everything anyway
[07:44] <bluefoxicy> jdong:  some of the DT_GNU_HASH stuff is trickling in; most of /lib has it, I'm waiting on /bin/bash to get rebuilt
[07:44] <jdong> cool
[07:45] <Ng> bluefoxicy: the "beagle" package owns that autostart file, there's no magic root stealing going on
[07:45] <bluefoxicy> Ng:  the beagle package owns beagled-autostart.desktop
[07:46] <bluefoxicy> It didn't own the SECOND beagled autostart file.
[07:46] <Ng> bluefoxicy: on my edgy and feisty boxes, beagle owns /etc/xdg/autostart/beagled.desktop and there is no beagled-autostart.desktop
[07:47] <bluefoxicy> Ng:  that's weird; on my feisty box, I uninstalled beagle and beagled-autostart.desktop vanished
[07:47] <bluefoxicy> but beagled.autostart stayed there
[07:49] <bluefoxicy> jdong:  http://rafb.net/paste/results/u6KjAC63.html
[08:07] <cbx33> hey guys I'm trying to edit a glade file...but it says a required catalog was not found....the catalog is gnomecanvas
[08:07] <cbx33> do i install the gnomecanvas-dev library
[08:41] <superm1> ping infinity 
[08:41] <superm1> oh away...
[08:42] <pitti> dholbach: thanks, you too!
[08:49] <pitti> keescook: btw, new gdb == , thanks
[08:49] <pitti> have a nice weekend everyone
[08:49] <crimsun_> bye pitti 
[08:49] <keescook> pitti: new gdb?
[08:50] <keescook> oh! that "?" I saw was probably unicode.  gah, gotta fix my terminal.
[08:50] <crimsun_> it's a heart
[08:50] <keescook> sweet.  thanks crimsun_
[11:58] <sistpoty> cjwatson: around? seems like we got a non-free file in universe (edgy + feisty): copy is here http://revu.tauware.de/revu1-incoming/pax-utils-0612122225/pax-utils-0.1.13.dfsg.1/macho.h
[11:59] <sistpoty> cjwatson: should we do s.th. urgently about it?