[12:22] <be1> hi guys! newbee question! How do I report a bug to Evince for Ubuntu? It seems I am forced to do that upstream? is that true?
[07:29] <mpt> Gooooooooooooooooooood evening Launchpadders!
[07:50] <Ubugtu> New bug: #66202 in rosetta "Transfer translations when a source package is renamed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66202
[08:31] <Ubugtu> New bug: #66206 in malone "No advanced search option to search by bug privacy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66206
[09:43] <lifeless> SteveA: around ?
[09:43] <lifeless> spiv: or you ?
[09:55] <SteveA> lifeless: hi
[09:55] <lifeless> hi
[09:55] <lifeless> I was wondering how untasteful it would be to have an import hook (python 2.3 and above style) that logged what was being imported
[09:56] <SteveA> I read that as "untestful" at first :-)
[09:56] <lifeless> this is for a little project some friends and I are fiddling with in weekends
[09:56] <lifeless> and how is amsterdam ?
[09:56] <SteveA> well, python does this for you with one of the command line switches
[09:56] <SteveA> if that's enough
[09:56] <SteveA> I'm currently in rotterdam.  It's good here, but I need to start looking for a place in Amsterdam.
[09:57] <lifeless> I suspect it would be too slow to invoke python for every code fragment we need to run
[09:57] <lifeless> but it might be a reasonable starting point
[09:57] <SteveA> import hooks are okay really
[09:57] <SteveA> the main problem I've met, other than a small speed hit
[09:57] <lifeless> (it needs to fire on imports done in an eval'd string, not on actual 'have to parse this .py file' conditions)
[09:58] <SteveA> it that some diagnostic code (3rd party) that assumes things about the stack level an import causes an ImportError at
[09:58] <SteveA> to distinguish between "immediate import errors" and "import errors caused by importing the code you asked to import"
[09:59] <SteveA> we've had remarkably few issues with the import fascist in launchpad, for example
[09:59] <lifeless> I'm having trouble parsing your line beginning 'it that some'
[09:59] <SteveA> although, that's run only when tests are run, not in production
[09:59] <SteveA> "is that some"
[09:59] <SteveA> continuation line, starting with "is"
[09:59] <lifeless> the end is a problem for me too - 'causes an ImportError at to distin...'
[10:00] <SteveA> the 3rd party code is meant to give more helpful error messages for parsing and acting on ZCML
[10:00] <SteveA> processing ZCML involves importing stuff
[10:01] <SteveA> and the code wants to give ZCML errors for imports directly due to text in the zcml
[10:01] <SteveA> but normal import errors due to faulty imports from python code
[10:02] <SteveA> so the diagnostic code inspects the number of stack frames in the exception's traceback
[10:02] <SteveA> and assumes that "import" goes straight to C
[10:02] <lifeless> I see
[10:02] <SteveA> so, an import hook changes the number of stack frames in the import error exception
[10:02] <lifeless> I dont think that will be a problem :)
[10:02] <SteveA> I think it's fine to run tests with a simple and robust import hook
[10:03] <SteveA> I don't really like running in production with one
[10:03] <lifeless> the use case here is for python as an extension language for a tool
[10:03] <SteveA> sounds quite tasteful to hook import in that case
[10:03] <lifeless> thanks for the feedback
[10:04] <lifeless> meh, I mean - thanks for letting me pick your brain and your reactions
[10:04] <SteveA> because users don't have the same expectations as for stand-alone python
[10:04] <SteveA> but, my opinion might change if I actually saw it ;-)
[10:04] <SteveA> np
[10:04] <lifeless> the hook or the tool ;)
[10:04] <lifeless> users should not ever see the hook
[10:05] <lifeless> it just lets us setup appropriate triggers
[10:12] <SteveA> the tool... how much you've changed imports from a regular python user's expectations
[10:14] <lifeless> not at all
[10:14] <lifeless> I dont want to go into too much detail right now, this is all quite experimental
[10:14] <SteveA> ok
[10:14] <lifeless> a very large thought experiment if you like
[10:14] <SteveA> that's my main personal grounds for tastefulness
[10:15] <SteveA> like, it's possible to change python with an import hook so that "import" functions as a "print" statement
[10:15] <SteveA> but that's not tasteful
[10:15] <lifeless> a couple of friends and I are considering rewriting the build-toolchain of autoconf/automake/libtool/make to be sane, useful, and faster
[10:15] <SteveA> +1
[10:16] <SteveA> I always thought of these things as a hugely technical black bo
[10:16] <SteveA> x
[10:16] <SteveA> if they don't work for a particular project, I just don't use that project
[10:16] <lifeless> one of the intrinsic problems all existing tools I've used ignore is that the build rules are part of the dependencies of their output
[10:16] <SteveA> I mean, if that project is set up to use them, and I want to hack on it
[10:16] <lifeless> if you change the build rules, then the output should be regenerated
[10:16] <lifeless> right, they are mega pain, though many people have come to an accomodation with them.
[10:17] <duncan> hi all - I want to know what I need to do to get more priveleges on launchpad?
[10:17] <SteveA> you want a build rule for the build rules ;-)
[10:17] <SteveA> rule zero...
[10:17] <lifeless> so what we are planning is a small kernel to do [handwaving] , and a standard library of routines to let you quickly describe what you want to achieve. That standard library will be built in some language
[10:18] <lifeless> duncan: talk to the specific project or product you want more access to
[10:18] <lifeless> duncan: i.e. if its ubuntu, talk with the folk on #ubuntu-devel
[10:19] <duncan> lifeless, ah, so is it distro specific or package specific are a mixture?
[10:19] <lifeless> duncan: policy for ubuntu packages is set by whether the package is in 'main' or 'universe'
[10:19] <lifeless> universe -> #ubuntu-motu, main -> #ubuntu-devel
[10:20] <duncan> lifeless, can I ask a small question about xchat?
[10:20] <lifeless> SteveA: right, if the kernel itself changes to the point that the input for rules would change, for instance the evaluation of command line parameters, then rules depending on that evaluation will re-run
[10:20] <lifeless> duncan: it will not be answered here
[10:21] <lifeless> duncan: because its a package! and the folk here know about the web UI, but not about packaging.
[10:21] <lifeless> xchat is in main IIRC, so #ubuntu-devel is where you should go if you are contributing to the xchat package is some regard
[10:21] <duncan> lifeless, I'll try anyway. How do I make it generate "nick:" with a colon, at the moment it's a commar.
[10:22] <lifeless> I dont know. 
[10:22] <duncan> ok
[10:22] <SteveA> my neither.  I use irssi.
[10:22] <SteveA> try #xchat or something perhaps
[10:22] <lifeless> for that, its really a user question, not so much a technical/development question, so I'd suggest #xchat as SteveA says, or file a support request in launchpad
[10:23] <duncan> thanks all, bye
[10:23] <lifeless> (though that won't get you an interactive answer) 
[10:23] <lifeless> or perhaps #ubuntu
[10:23] <duncan> thanks
[10:23] <lifeless> SteveA: so yes, the blackhole of the depends chain is the kernel developers
[10:23] <lifeless> but beyond that it needs to be self referential all the way up
[10:24] <lifeless> and we're considering how to make python do that
[10:24] <lifeless> because even if python is not the language the standard library is written in, many users will want to write rules in a better language than shell as make forces them to
[10:25] <SteveA> sure.  most projects aren't written in shell or make either
[10:26] <lifeless> thats another point: if people can write in the language they are using in their project, it will make them happier
[10:26] <SteveA> see ant, sure
[10:26] <SteveA> do I mean ant?
[10:26] <lifeless> ant uses xml
[10:26] <SteveA> the java makefile-equiv
[10:26] <lifeless> but java == xml :)
[10:26] <SteveA> it is implemented in java
[10:26] <lifeless> yes
[10:27] <lifeless> ant files are really ugly for humans to read, but nice for IDE's to read.
[10:27] <lifeless> its quite interesting
[10:27] <SteveA> I'm off to find breakfast.  thanks for the chat :-)
[10:27] <lifeless> tchau tchau
[10:27] <SteveA> dag
[11:43] <mpt> whoo
[11:58] <mpt> holy crap

[12:09] <mpt> SteveA, thanks for the work on https://launchpad.net/bugs/65629 - it's not finished yet though. I've given details in the bug report.
[12:15] <Ubugtu> New bug: #66224 in malone "Bug visibility page (+secrecy) is missing a facet/application menu" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66224
[05:30] <ryanakca> how do you remove a remote bug watch thingy? ex: https://launchpad.net/products/amarok/+bug/64573 is watching the same remote bug twice
[05:30] <Ubugtu> Malone bug 64573 in amarok "Amarok crashes on iPod connection" [Unknown,Unknown]  
[08:54] <AutOMarG|naO> hello ?
[08:54] <AutOMarG|naO> hola ?
[08:54] <AutOMarG|naO> alguien ?
[08:54] <AutOMarG|naO> ChanServ
[08:54] <AutOMarG|naO> [PUPPETS] Gonzo
[08:55] <AutOMarG|naO> alguien habla espaol aki ?
[10:51] <ssam> i am trying to add an upstream bug report (freedesktop 8095) to ubuntu bug 58373, it wont let me put 'compiz' as the product, am i doing something wrong?
[10:51] <Ubugtu> Freedesktop bug 8095 in App/compiz "Blue Compiz for PowerPC" [Normal,Assigned]  http://bugzilla.freedesktop.org/show_bug.cgi?id=8095
[11:21] <lifeless> ssam: there may not be a compiz product yet
[11:21] <lifeless> have you looked for one at https://launchpad.net/products ?
[11:41] <ssam> https://launchpad.net/products does not find it, but ubuntu bug 58373 is file against compiz
[11:42] <lifeless> so the bug is against the compiz *package*
[11:42] <ssam> is there any way to link to the upstream bug then
[11:43] <lifeless> someone needs to record in launchpad that there is a *product* compiz 
[11:43] <lifeless> which you can then specify as using bugzilla.freedesktop.org for its bugtracker
[11:43] <ssam> can i do that
[11:43] <lifeless> and that will activate the upstream tracking
[11:43] <lifeless> you can do this
[11:45] <lifeless> just go to launchpad.net/products
[11:45] <lifeless> select register a new product
[11:46] <ssam> ok thanks
[11:48] <lifeless> when you have the product, select 'define launchpad usage' and there is a drop-down box
[11:48] <lifeless> which has the freedesktop.org bugzilla in it
[11:50] <lifeless> then go to 'published packages'
[11:51] <lifeless> and clieck 'link a package'
[11:52] <lifeless> there you should type in compiz, and set the distribution release to edgy
[11:52] <ssam> ok done :-)
[11:52] <lifeless> now go to your bug 
[11:53] <lifeless> looks like its all linked
[11:54] <ssam> done that aswell, though looks like someone has since made upstream links to xorg-server
[11:54] <lifeless> the activity log will help there
[11:54] <lifeless> about an hour back
[11:55] <lifeless> is it a xorg server bug or compiz ? [do we know ?] 
[11:58] <ssam> on the freedesktop bugzilla its product:xorg, component: app/compiz
[11:58] <lifeless> then you can reject it from the xorg server in launchpad
[12:00] <ssam> ok
[12:00] <ssam> though debian have it file against xorg
[12:00] <lifeless> heh
[12:01] <lifeless> I dont know enough, I suggest talking about this on #ubuntu-devel, or freedesktop's irc channels
[12:03] <ssam> i think i'll leave it as it is. maybe it will become clearer at some point