=== be1 [n=csy150@194.66.47.40] has joined #launchpad [12:22] 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? === jinty [n=jinty@127.Red-83-50-221.dynamicIP.rima-tde.net] has joined #launchpad === be1 [n=csy150@194.66.47.40] has left #launchpad [] === jml [n=jml@202.63.35.99] has joined #launchpad === belito [n=user@201.240.101.9] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === jml [n=jml@202.63.35.99] has joined #launchpad === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad [07:29] Gooooooooooooooooooood evening Launchpadders! [07:50] New bug: #66202 in rosetta "Transfer translations when a source package is renamed" [Undecided,Unconfirmed] http://launchpad.net/bugs/66202 [08:31] New bug: #66206 in malone "No advanced search option to search by bug privacy" [Undecided,Unconfirmed] http://launchpad.net/bugs/66206 === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [09:43] SteveA: around ? [09:43] spiv: or you ? [09:55] lifeless: hi [09:55] hi [09:55] 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] I read that as "untestful" at first :-) [09:56] this is for a little project some friends and I are fiddling with in weekends [09:56] and how is amsterdam ? [09:56] well, python does this for you with one of the command line switches [09:56] if that's enough [09:56] I'm currently in rotterdam. It's good here, but I need to start looking for a place in Amsterdam. [09:57] I suspect it would be too slow to invoke python for every code fragment we need to run [09:57] but it might be a reasonable starting point [09:57] import hooks are okay really [09:57] the main problem I've met, other than a small speed hit [09:57] (it needs to fire on imports done in an eval'd string, not on actual 'have to parse this .py file' conditions) [09:58] it that some diagnostic code (3rd party) that assumes things about the stack level an import causes an ImportError at [09:58] to distinguish between "immediate import errors" and "import errors caused by importing the code you asked to import" [09:59] we've had remarkably few issues with the import fascist in launchpad, for example [09:59] I'm having trouble parsing your line beginning 'it that some' [09:59] although, that's run only when tests are run, not in production [09:59] "is that some" [09:59] continuation line, starting with "is" [09:59] the end is a problem for me too - 'causes an ImportError at to distin...' [10:00] the 3rd party code is meant to give more helpful error messages for parsing and acting on ZCML [10:00] processing ZCML involves importing stuff [10:01] and the code wants to give ZCML errors for imports directly due to text in the zcml [10:01] but normal import errors due to faulty imports from python code [10:02] so the diagnostic code inspects the number of stack frames in the exception's traceback [10:02] and assumes that "import" goes straight to C [10:02] I see [10:02] so, an import hook changes the number of stack frames in the import error exception [10:02] I dont think that will be a problem :) [10:02] I think it's fine to run tests with a simple and robust import hook [10:03] I don't really like running in production with one [10:03] the use case here is for python as an extension language for a tool [10:03] sounds quite tasteful to hook import in that case [10:03] thanks for the feedback [10:04] meh, I mean - thanks for letting me pick your brain and your reactions [10:04] because users don't have the same expectations as for stand-alone python [10:04] but, my opinion might change if I actually saw it ;-) [10:04] np [10:04] the hook or the tool ;) [10:04] users should not ever see the hook [10:05] it just lets us setup appropriate triggers [10:12] the tool... how much you've changed imports from a regular python user's expectations [10:14] not at all [10:14] I dont want to go into too much detail right now, this is all quite experimental [10:14] ok [10:14] a very large thought experiment if you like [10:14] that's my main personal grounds for tastefulness === duncan [n=duncan@563421b6.rev.stofanet.dk] has joined #launchpad [10:15] like, it's possible to change python with an import hook so that "import" functions as a "print" statement [10:15] but that's not tasteful [10:15] 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] +1 [10:16] I always thought of these things as a hugely technical black bo [10:16] x [10:16] if they don't work for a particular project, I just don't use that project [10:16] 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] I mean, if that project is set up to use them, and I want to hack on it [10:16] if you change the build rules, then the output should be regenerated [10:16] right, they are mega pain, though many people have come to an accomodation with them. [10:17] hi all - I want to know what I need to do to get more priveleges on launchpad? [10:17] you want a build rule for the build rules ;-) [10:17] rule zero... [10:17] 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] duncan: talk to the specific project or product you want more access to [10:18] duncan: i.e. if its ubuntu, talk with the folk on #ubuntu-devel [10:19] lifeless, ah, so is it distro specific or package specific are a mixture? [10:19] duncan: policy for ubuntu packages is set by whether the package is in 'main' or 'universe' [10:19] universe -> #ubuntu-motu, main -> #ubuntu-devel [10:20] lifeless, can I ask a small question about xchat? [10:20] 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] duncan: it will not be answered here [10:21] duncan: because its a package! and the folk here know about the web UI, but not about packaging. [10:21] 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] lifeless, I'll try anyway. How do I make it generate "nick:" with a colon, at the moment it's a commar. [10:22] I dont know. [10:22] ok [10:22] my neither. I use irssi. [10:22] try #xchat or something perhaps [10:22] 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] thanks all, bye [10:23] (though that won't get you an interactive answer) [10:23] or perhaps #ubuntu [10:23] thanks === duncan [n=duncan@563421b6.rev.stofanet.dk] has left #launchpad ["Leaving"] [10:23] SteveA: so yes, the blackhole of the depends chain is the kernel developers [10:23] but beyond that it needs to be self referential all the way up [10:24] and we're considering how to make python do that [10:24] 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] sure. most projects aren't written in shell or make either [10:26] thats another point: if people can write in the language they are using in their project, it will make them happier [10:26] see ant, sure [10:26] do I mean ant? [10:26] ant uses xml [10:26] the java makefile-equiv [10:26] but java == xml :) [10:26] it is implemented in java [10:26] yes [10:27] ant files are really ugly for humans to read, but nice for IDE's to read. [10:27] its quite interesting [10:27] I'm off to find breakfast. thanks for the chat :-) [10:27] tchau tchau [10:27] dag === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [11:43] whoo === mpt has the help panel expanding and collapsing === jinty [n=jinty@127.Red-83-50-221.dynamicIP.rima-tde.net] has joined #launchpad [11:58] holy crap [11:59] === jml [n=jml@ppp105-240.lns1.hba1.internode.on.net] has joined #launchpad [12:09] 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] New bug: #66224 in malone "Bug visibility page (+secrecy) is missing a facet/application menu" [Undecided,Unconfirmed] http://launchpad.net/bugs/66224 === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === AlinuxOS [n=alinux@d83-184-248-227.cust.tele2.it] has joined #launchpad === daq4th [n=darkness@netstation-005.cafe.zSeries.org] has joined #launchpad === AstralJava [n=jaska@cm-083-102-068-117.lohjanpuhelin.fi] has joined #launchpad === AlinuxOS [n=alinux@d83-184-248-227.cust.tele2.it] has joined #launchpad [05:30] 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] Malone bug 64573 in amarok "Amarok crashes on iPod connection" [Unknown,Unknown] === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === AutOMarG|naO [i=Rp@pc-75-115-239-201.cm.vtr.net] has joined #launchpad [08:54] hello ? [08:54] hola ? [08:54] alguien ? [08:54] ChanServ [08:54] [PUPPETS] Gonzo [08:55] alguien habla espaol aki ? === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #launchpad === _thumper_ [n=tim@tpsoft.gotadsl.co.uk] has joined #launchpad === kiko-afk [n=kiko@200.103.112.11] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === ssam [n=ssam@88-107-27-194.dynamic.dsl.as9105.com] has joined #launchpad [10:51] 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] Freedesktop bug 8095 in App/compiz "Blue Compiz for PowerPC" [Normal,Assigned] http://bugzilla.freedesktop.org/show_bug.cgi?id=8095 [11:21] ssam: there may not be a compiz product yet [11:21] have you looked for one at https://launchpad.net/products ? [11:41] https://launchpad.net/products does not find it, but ubuntu bug 58373 is file against compiz [11:42] so the bug is against the compiz *package* [11:42] is there any way to link to the upstream bug then [11:43] someone needs to record in launchpad that there is a *product* compiz [11:43] which you can then specify as using bugzilla.freedesktop.org for its bugtracker [11:43] can i do that [11:43] and that will activate the upstream tracking [11:43] you can do this [11:45] just go to launchpad.net/products [11:45] select register a new product [11:46] ok thanks [11:48] when you have the product, select 'define launchpad usage' and there is a drop-down box [11:48] which has the freedesktop.org bugzilla in it [11:50] then go to 'published packages' [11:51] and clieck 'link a package' [11:52] there you should type in compiz, and set the distribution release to edgy [11:52] ok done :-) [11:52] now go to your bug [11:53] looks like its all linked [11:54] done that aswell, though looks like someone has since made upstream links to xorg-server [11:54] the activity log will help there [11:54] about an hour back [11:55] is it a xorg server bug or compiz ? [do we know ?] [11:58] on the freedesktop bugzilla its product:xorg, component: app/compiz [11:58] then you can reject it from the xorg server in launchpad [12:00] ok [12:00] though debian have it file against xorg [12:00] heh [12:01] I dont know enough, I suggest talking about this on #ubuntu-devel, or freedesktop's irc channels [12:03] i think i'll leave it as it is. maybe it will become clearer at some point