[04:33] <sivang> jdub : I have tried to modify gnome-system-tools package, if I dpkg-buildpackage -rfakeroot it without modifications, no prob. it makes a new deb.
[04:34] <sivang> jdub : however, if I change anything inside /src  or /backends  it gets upset telling that intltool is outdated.
[04:39] <sivang> jdub : I've been trying to add some code to it to enable me to do xml output dump outs to see what's going on the interfaces xml db, see #2221
[04:49] <jdub> what are you changing?
[04:52] <sivang> jdub : I tried to you xml_doc_dump (or something similar) to profile_save_interfaces.
[04:53] <sivang> jdub : I also enabled debugging mode for the backend,
[04:53] <sivang> jdub : so it won't trash my system's iface file and allow me to see errors.
[04:53] <sivang> jdub : there was a debug flag commented on network-conf.in , I used it
[04:55] <sivang> jdub : I'm headed to bed (4:45 am my time :) you can leave here comments if you have any idea ;) I'd appriciate it.
[04:57] <sivang> jdub : better, on the bugtrail
[04:59] <sivang> night all
[06:10] <fabbione> mdz: ping
[06:31] <fabbione> anybody around?
[07:03] <mdz> fabbione: here
[07:03] <fabbione> mdz: cupsys is up
[07:03] <fabbione> i am working on emacs21
[07:03] <fabbione> mdz: is the patch for emacs final?
[07:13] <mdz> fabbione: upstream accepted it
[07:13] <mdz> on the mailing list, RMS said to commit it, so I think that is good enough :-)
[07:15] <fabbione> ok
[07:15] <fabbione> wtf is wrong with dpatch
[07:26] <fabbione> mdz: emacs is ready
[07:26] <fabbione> ok to upload?
[07:28] <fabbione> heck.. you gave me the patch ;)
[07:29] <fabbione> goody we are down again to 13
[07:29] <fabbione> later :-)
[09:24] <doko> review wanted: patch for #2216 attached to the bug report.
[10:25] <Mithrandir> mdz: nvidia; approval wanted.
[10:25] <mdz> Mithrandir: has someone looked over it?
[10:25] <mdz> and have you done the regression test on the i386 packages that we discussed?
[10:26] <Mithrandir> mdz: fabbione thinks the nvidia part of it looks good; I've done a debdiff on i386, but I don't have any i386 with ubuntu at home
[10:26] <mdz> debdiff should be sufficient
[10:26] <Mithrandir> (debdiff on the binary packages, that is)
[10:26] <mdz> if you would unpack it and checksum all the files, too, I wouldn't be opposed to that :-)
[10:27] <mdz> that debian/rules seemed a bit clumsy
[10:27] <mdz> (the original one)
[10:27] <mdz> did you clean it up, or add an amd64-specific mess? :-)
[10:27] <Mithrandir> somewhere in between -- I abstracted stuff a little, but I don't want to possibly destabilize the package this close to release.
[10:28] <Mithrandir> I can unpack the packages and checksum, sure.
[10:29] <Mithrandir> http://err.no/patches/linux-restricted-modules-2.6.8.1.2-3_2.6.8.1.3-1.amd64.diff is the diff
[10:34] <Mithrandir> mdz: if you could look at it, test it on i386 and do whatever other magic you want to do, it would be most appreciated; I'll checksum it on i386.  If that matches, is it ok to upload?
[11:13] <cc> say, glibc has been "updated" to allow the time within gnome to be updated fixing gnome bug #19197 - can that make it before release?
[11:14] <cc> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133481 is the bug thats fixed in Fedora, but still around in Ubuntu (just tested)
[11:18] <daniels> mdz: ^^ looks like a reasonably non-intrusive patch to me
[11:19] <cc> daniels: it is, and makes the UI more usable
[11:19] <cc> also, how comfortable are ya'all if i link to RH bugzilla stuff in Ubuntu bugzilla?
[11:20] <daniels> cc: as in, 'check out this Ubuntu bug', or intimate BZ linking?
[11:21] <cc> daniels: no as in I'll file an RFE or bugreport in Ubuntu, link to a RH bz entry where the "fix" is, and hope ya'all integrate it :)
[11:24] <daniels> cc: ah, right, sure :)
[11:25] <daniels> cc: we don't really have RFEs, just bugs
[11:25] <daniels> pick the right severity, that's all you need
[11:25] <cc> daniels: yeah, just checking in case ya'all get annoyed or not. thanks.
[11:28] <daniels> cc: that'd be great, thanks :)
[11:37] <daniels> thom: dude, you need to set up a Planet for Planet developers
[11:37] <daniels> thom: planet.planetplanet.org
[11:40] <pitti_> jdub: here?
[11:41] <jdub> pitti: pong
[12:17] <mdz> daniels: I don't see a patch there..the description in RH bugzilla sounds fairly straightforward, but to be honest, I think that touching glibc right now, for a feature, would be in very bad taste
[12:19] <sabdfl> anybody able to help with a question on python packages?
[12:19] <Mithrandir> sabdfl: shoot.
[12:19] <daniels> mdz: s/patch/change/
[12:19] <daniels> mdz: fair enough
[12:19] <sabdfl> i have a directory call vocabulary
[12:19] <sabdfl> inside that an __init__.py
[12:20] <sabdfl> which imports * from two other files, call them foo and bar
[12:20] <sabdfl> now, in another file, i want to import * from foo but I don't want to trigger the import of bar
[12:20] <sabdfl> because of circular imports
[12:20] <sabdfl> but when I do: vocabilary.foo
[12:21] <mdz> wasn't this just discussed on the launchpad list?
[12:21] <sabdfl> sorry
[12:21] <sabdfl> could be
[12:21] <sabdfl> when i do from vocablary.foo import * it seems to import bar as well
[12:22] <mdz> foo imports bar?
[12:24] <sabdfl> no
[12:24] <sabdfl> foo and bar are independent
[12:25] <sabdfl> it's the __init__.py that binds them together
[12:25] <mdz> and when you import vocabulary.foo, it evaluates __init__.py?
[12:26] <sabdfl> appears to
[12:26] <sabdfl> >>> import canonical.launchpad.database
[12:26] <sabdfl> --Return--
[12:26] <sabdfl> > /usr/lib/python2.3/pdb.py(992)set_trace()->None
[12:26] <sabdfl> -> Pdb().set_trace()
[12:26] <sabdfl> (Pdb) bt
[12:26] <sabdfl>   <stdin>(1)?()
[12:26] <sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/database/__init__.py(4)?()
[12:26] <sabdfl> -> from canonical.launchpad.database.person import *
[12:26] <sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/database/person.py(14)?()
[12:26] <Mithrandir> sabdfl: having __init__.py being __all__ = ['foo', 'bar' ] 
[12:26] <sabdfl> -> from canonical.launchpad.interfaces.person import IPerson, IPersonSet,  \
[12:27] <sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/interfaces/__init__.py(13)?()
[12:27] <sabdfl> -> from canonical.launchpad.interfaces.bug import *
[12:27] <sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/interfaces/bug.py(12)?()
[12:27] <sabdfl> -> from canonical.launchpad.vocabulary.dbschema import *
[12:27] <sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/vocabulary/__init__.py(2)?()
[12:27] <sabdfl> -> import pdb; pdb.set_trace()
[12:27] <sabdfl> > /usr/lib/python2.3/pdb.py(992)set_trace()->None
[12:27] <sabdfl> -> Pdb().set_trace()
[12:27] <sabdfl> (Pdb)
[12:27] <sabdfl> Mithrandir: but I want to populate the __init__.py namespace with the contents of both foo and bar
[12:28] <sabdfl> i want to refer to these things as canonical.launchpad.vocabulary.XYZ
[12:28] <sabdfl> whenre XYZ could be in foo or bar
[12:28] <mdz> this would seem to only be a problem because foo and bar are under 'vocabulary'; could they not be in an adjacent module rather than in the same one?
[12:29] <sabdfl> that's why i have "from canonical.launchpad.vocabulary.foo import *" in __init__.py
[12:29] <sabdfl> hmm... could be
[12:30] <sabdfl> i could maybe create a vocabulary.py which imported them from adjacent files
[12:30] <mdz> yes, or that
[12:31] <sabdfl> does every directory in the module tree need to have an __init__.py?
[12:31] <mdz> no
[12:32] <sabdfl> ok
[12:32] <sabdfl> let me play with that idea
[12:36] <mdz> hmm, actually they do need a __init__.py if they have .py files in them, rather than extension modules and the like
[12:36] <mdz> but it can be empty
[12:37] <sabdfl> ok
[12:37] <sabdfl> just ran into that problem :-)
[12:37] <sabdfl> whadyaknow
[12:37] <sabdfl> thanks mdz, Mithrandir
[12:38] <mdz> I was still technically correct, since the top-level directory doesn't need a __init__.py :-)
[12:39] <sabdfl> well, then you were correct both times, slightly differently
[12:40] <mdz> I get the feeling that I should be asleep
[12:40] <mdz> night
[12:57] <sabdfl> night mdz
[01:00] <hazmat> btw. i pointed out an important bug in sqlos txn integration the other day, svn should be updated.
[01:00] <hazmat> txn aborts could lead to data corruption on subsequent commits
[01:53] <Mithrandir> mdz: the checksums don't line up, but that seems to be due to timestamps for .a files and hardcoding of paths in kernel objects.
[02:09] <doko> mdz: still there? what about the template translations for the installer packages?
[02:10] <Mithrandir> doko: 12:40 < mdz> night
[03:58] <daniels> Keybuk: hey ho
[03:58] <Keybuk> heyhi
[03:58] <daniels> sup?
[03:58] <Keybuk> hungover :(
[03:58] <daniels> heh
[03:58] <daniels> f1 party? or did you also hold a massive post-.au-election wake?
[03:59] <Keybuk> neither.  went out last night with an old school friend
[03:59] <daniels> ahr
[06:15] <lamont> bob2: optional:uncompiled isn't a state...
[06:15] <bob2> oh
[06:15] <lamont> but I'm checking
[06:16] <lamont> universe/net/kismet_2004.04.R1-1.1: Installed [optional:uncompiled] 
[06:16] <lamont> that'd be 'Installed'...
[06:16] <lamont> Filename: pool/universe/k/kismet/kismet_2004.04.R1-1.1_i386.deb
[06:16] <lamont> Size: 953826
[06:17] <lamont> or which arch are you asking about?
[06:17] <bob2> powerpc.
[06:17] <bob2> sorry, didn't even think to check if it was built on another arch
[06:18] <lamont> snacc is ftbfs on powerpc.  and kismet is dep-wait on that
[06:18] <lamont> poke me tomorrow and I'll see what I can do about that...
[06:18] <bob2> sure, thanks a lot
[11:26] <lamont> bob2: interestingly, snacc is now ftbfs on i386 as well..
[11:48] <thom> nice, the firefox no scroll wheel crappiness has been confirmed and may even get worked on soon
[11:52] <thom> mdz: just snagged the last security patch, getting ready to upload
[11:54] <thom> (for firefox, i mean)