[00:58] <pochu> slangasek: any chance you can sponsor the debdiff in bug 194536?
[00:58] <ubotu> Launchpad bug 194536 in monodoc "FTBFS in latest archive rebuild test" [High,In progress] https://launchpad.net/bugs/194536
[01:00] <TheMuso> ember_: Got mousetweaks covered.
[01:49]  * ScottK wonders if FTBFS of mono related stuff might be considered a good thing.
[01:56] <pochu> lol
[01:56] <pochu> I guess not as tomboy is shipped by default
[02:08] <ScottK2> pochu: Not in any distribution I use.
[02:08] <ScottK2> ;-)
[02:11] <pochu> heh, you win :)
[02:12] <pochu> GNOME rocks btw :P
[02:15] <ScottK2> For some definition of the word rock I agree with you.
[02:16]  * pochu wonders why wordreference lists so many acceptions but none of them is like "to be great"
[02:17] <pochu> perhaps I didn't get the meaning of it right
[02:17] <pochu> Ok, I'm off to bed
[02:17] <pochu> ScottK2: feel free to upload that monodoc debdiff :P
[02:17]  * pochu runs to bed
[02:26] <ScottK2> slangasek: If you're around and have a moment, I'd appreciate a bit of bin New on pypolicyd-spf.  I sort of forgot the transitional package the first time around ...
[02:36] <slangasek> pochu: that doesn't fix the bug in the handling of cs-errors.zip, which means the package lacks a policy-compliant clean rule (it removes stuff that can't be regenerated).
[02:50] <slangasek> ScottK2: this is on what suite
[02:50] <slangasek> ?
[02:51] <ScottK2> slangasek: It's an arch all package
[02:51] <ScottK2> https://launchpad.net/ubuntu/+source/pypolicyd-spf/0.6-1ubuntu1
[02:55] <slangasek> ScottK2: accepted
[02:58] <ScottK2> slangasek: Thanks.
[03:05] <emgent> heya
[04:05]  * jdong figures out how to dynamically have torrent clients punchthrough his firewall....
[04:06] <StevenK> jdong: Not run torrent clients seems to be one solution.
[04:06] <jdong> StevenK: :P
[04:48] <jdong> StevenK: well to protest, I'm writing a hackish ruby script to punch open ports :D
[05:03] <RAOF> jdong: You can't get your firewall to respond to UPnP requests?  Or any of the other couple of "I'd like to accept some incoming connections, thanks" protocols?
[05:03] <jdong> RAOF: my firewall is a localhost iptables
[05:04] <RAOF> Right.  No so much with the UPnP integration.
[05:04] <jdong> RAOF: and there's a number of programs that I use which open dynamic  port numbers that I would rather not try to fix
[05:04] <jdong> RAOF: now I'm just trying to figure out how the hell to maintain half-decent security and not have ports punched open everywhere
[05:05] <RAOF> Surely someone has tried to get iptables to do that?
[05:05] <RAOF> In fact, google says: http://gentoo-wiki.com/HOWTO_Setup_UPnP_with_IPTables
[05:08] <RAOF> jdong: Or there seem to be a number of NAT-PMP daemons out there if that floats your boat.
[05:08] <jdong> RAOF: I think UPnP is overkill for this, I'd rather not require my program to be modified to support UPNP/NAT-PNP
[05:08] <jdong> RAOF: I'm writing a wrapper such that I can run "punchfw cmdname arg1 arg2" and any ports the child process opens will be opened by iptables
[05:08] <slomo_> superm1: hm, why was it rejected? :)
[05:09] <slomo_> superm1: looking at the new packages now
[05:09] <superm1> slomo_, for the exact reason i fixed in  there :)
[05:09] <RAOF> jdong: Aaaah.  _That_ makes more sense.
[05:09] <superm1> LGPL vs GPL
[05:09] <slomo_> superm1: gnar... where? i checked this :)
[05:09] <superm1> slomo_, the COPYING file says LGPL
[05:09] <slomo_> superm1: and the files say GPL?
[05:10] <slomo_> superm1: i hope you don't mind if i remove the -2 changelog? we can upload this as -1 again
[05:10] <superm1> slomo_, hm then perhaps upstream has made mistakes in throwing the package together
[05:10] <superm1> sure
[05:10] <superm1> well the i386 binary was rejected
[05:10] <superm1> i didnt get anything about the source package
[05:10] <superm1> i wasnt sure if they all came as one upload
[05:10] <slomo_> they do
[05:10] <superm1> ook
[05:11] <slomo_> *building* :)
[05:11] <slomo_> sorry that i didn't catch this last time
[05:11] <superm1> not a big deal, myself and at least 3 other people missed it too :)
[05:13] <slomo_> scary :)
[05:17] <slomo_> superm1: gmyth uploaded
[05:17] <superm1> k great thx
[05:17] <slomo_> erm, not the version you put on mentos 3 minutes ago though ;)
[05:17] <slomo_> what did you change?
[05:18] <superm1> well it's just the -1 in the changelog instead
[05:18] <slomo_> ah ok
[05:18] <superm1> like you had said to do
[05:18] <slomo_> now -upnp :)
[05:21] <slomo_> superm1: hm, but -upnp is GPL
[05:21] <slomo_> superm1: and gmyth can link to gmyth-upnp, right?
[05:22] <superm1> argh, yeah it should be allowed to
[05:22] <slomo_> so this would render gmyth as GPL again...
[05:22] <slomo_> superm1: could you talk with upstream to get gmyth-upnp LGPL too? :)
[05:22] <superm1> well wait other way around though isn't it?
[05:22] <superm1> gmyth-upnp links to gmyth
[05:22] <slomo_> no
[05:23] <slomo_> omg
[05:23] <slomo_> gmyth's configure checks for gmyth-upnp
[05:23] <slomo_> and the other way around
[05:23] <slomo_> wtf
[05:23] <superm1> and gmyth_upnp.c lists itself as LGPL
[05:23] <superm1> i'll send a few emails to upstream about this...
[05:24] <slomo_> superm1: i expect that gmyth-upnp's COPYING is wrong and should be LGPL
[05:24] <superm1> yeah, that's what it looks like to me too
[05:24] <slomo_> superm1: please ask them why they have this circular build dependency too :) that doesn't make sense to me
[05:25] <slomo_> superm1: and if we know that, ping me and i'll review and upload, ok?
[05:25] <superm1> slomo_, sure will do
[05:25] <slomo_> :)
[05:25] <superm1> everything else look kosher?
[05:26] <slomo_> superm1: from a short look, yes... will look closer when this is clarified
[05:26] <superm1> ok
[05:48] <jdong> RAOF: whee, done, and it seems to work :)
[05:48] <RAOF> Wooo!
[06:07] <slomo_> pochu, persia: would be nice if you could get gst-plugins-bad0.10 and wildmidi synced/merged with my latest changes later ;)
[06:57] <superm1> pochu & slomo_, i was going to let you guys know, neither MPEG2 TS or MPEG2 PS streams track at all
[06:57] <superm1> you had asked for me to try both of them
[06:57] <superm1> i can't skip around the recordings in either
[06:57] <slomo_> superm1: ok
[06:57] <superm1> er seek is probably the better word to use
[06:59] <superm1> slomo_, i can however seek in a mpeg2-ps file if its opened directly in totem.
[06:59] <superm1> mpeg2-ts i can't
[06:59] <slomo_> superm1: yeah, mpeg2-ts doesn't work because the demuxer doesn't support seeking
[06:59] <slomo_> superm1: for ps, no idea :)
[06:59] <slomo_> it should work in theory
[06:59] <superm1> well once upstream gets back to me on the other stuff, maybe i'll bugger them :)
[07:08] <warp10> Good morning
[07:09] <dholbach> good morning
[07:09] <emgent> heya dholbach :)
[07:09] <dholbach> hey emgent
[08:00] <elmargol> morning
[08:01] <elmargol> How do I see if a package has ubuntu changes?
[08:02] <dholbach> elmargol: if the version number has a *ubuntu<n> it should have Ubuntu changes
[08:02] <dholbach> elmargol: apt-cache showsrc <package> | grep ^Version
[08:02] <elmargol> 3.2.0-2ubuntu1
[08:03] <dholbach> elmargol: or     aptitude changelog <package>        if you want to know what kind of changes it has
[08:03] <dholbach> elmargol: likely to have Ubuntu changes :)
[08:03] <elmargol> ok this is going to be complicated :(
[08:06] <elmargol> How do I merge a changefile? Do I take the debian changefile and add the latest ubuntu change?
[08:07] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/Merging might have all the answers
[08:07] <elmargol> thanx a lot
[08:07] <dholbach> keep the ubuntu changelog entries
[08:13] <emgent> morning \sh :)
[08:26] <_ruben> question regarding rebuilding a kernel for ubuntu (server) .. with the official kernel package, uname -r will show 2.6.22-14-server .. im kinda confused on which params to use for make-kpkg to make my package end up 2.6.22-14-server-klips
[08:29] <elmargol> \sh: Hi. can I help you to merge claws-mail-extra-plugins? Some plugins are not working for me (too old)
[08:30] <elmargol> The only difference I see are those sylpheed-claws dummy packages
[08:41] <pochu> slomo__: yeah, I'll merge that stuff!
[08:49] <\sh> elmargol: oh I didn't upload the last packages...
[08:50] <elmargol> \sh: the packages are out of sanc
[08:50] <elmargol> sync
[08:50] <\sh> elmargol: who did the last upload? give me a min to check this
[08:50] <elmargol> you did the last claws-mail update
[08:51] <\sh> elmargol: nope
[08:51] <elmargol> Steve Langasek
[08:51] <\sh> elmargol: I merged 3.2.0-2 together with the plugins
[08:51] <\sh> elmargol: the last upload of 3.3.0 came from morten kjeldgaard
[08:51] <elmargol> ah ok you did the last plugins merge
[08:52] <\sh> elmargol: yes for 3.2.0...the version which is not in the archives anymore...claws-mail and claws-mail-extra-plugins are belonging together, so the uploader of the last version need to take action and push the extra-plugins to the very same version
[08:52] <\sh> I wonder why this wasn't the case now
[08:55] <\sh> and oh wonder...morten doesn't use launchpad
[08:55] <\sh> does anybody know the ircnick of morten?
[08:59] <\sh> elmargol: if you be so kind, please merge the new extra-plugins...and I'll happy to discuss with motu-release a FFE
[08:59] <\sh> elmargol: I'm confident that no one would object the upload
[09:01] <geser> good morning
[09:04] <\sh> moins geser
[09:06] <geser> Hi \sh
[09:26] <persia> slomo, pochu: Thanks again.  Let me know if there is anything leftover that needs attention.
[09:27] <elmargol> launchpad is somehow very slow
[09:28] <slomo__> tsmithe: url? :)
[09:29] <slomo__> persia: sf2 support... but tsmithe was looking into that
[09:31] <persia> slomo__: If I'm lucky, I'll be able to integrate that patch before you upload :)
[09:31] <slomo__> persia: which patch?
[09:32] <persia> Also, if you're looking at fluid-soundfont changes, there's a candidate Ubuntu debdiff at https://bugs.edge.launchpad.net/ubuntu/+source/mscore/+bug/195179 (although I don't have a URL for a debian-target update).
[09:32] <ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New]
[09:32] <persia> The sf2 patch from tsmithe.
[09:32] <persia> (it doesn't exist yet)
[09:32] <slomo__> persia: what's mscore?
[09:33] <persia> slomo__: It's an score-editor to go with the MuSE sequencer.  Let's you edit the staff, and plays it to you with a soundfont.
[09:33] <tsmithe> slomo__, i'm thinking sf2 support may be a bit outside of my expertise, but i can persevere if you like. it would just take a while...
[09:34] <tsmithe> slomo__, http://mentors.debian.net/debian/pool/main/f/fluid-soundfont/fluid-soundfont_3.1-1.dsc
[09:34] <persia> tsmithe: If you are willing to work on it, please go ahead.  Feel free to ask me for help (although I've a bit of a learning curve to chase as well).
[09:34] <slomo__> tsmithe: if you want... :) would be a nice feature but not too important i guess
[09:34] <\sh> elmargol: if you can't do it, I'm sitting this evening and do the merge myself...
[09:34] <elmargol> I'm done here
[09:35] <elmargol> try to upload the debdiff to launchpad
[09:35] <tsmithe> persia, right. i have to leave soon, but i can take a hack at it when i get back later today
[09:35] <persia> tsmithe: No big rush.  It would be nice, but having any gstreamer-midi in hardy (even with freepats) is better than none.
[09:36]  * persia suspects lenny may be a more reasonable timeframe for sf2 support.
[09:36] <elmargol> \sh: somehow I can not upload the diff...
[09:37] <tsmithe> ok :)
[09:37] <\sh> elmargol: just send it to me by email...I'm taking care of it
[09:38] <\sh> elmargol: sh at sourcecode dot de
[09:39] <elmargol> \sh: only the debdiff?
[09:42] <\sh> elmargol: the debdiff from 3.3.0-?? <debian version> to new ubuntu version
[09:42] <\sh> elmargol: afaik we only need to add the old transitional packages to -extra-plugins because of upgrade from dapper to hardy
[09:43] <elmargol> launchpad did work now
[09:45] <tsmithe> slomo__, would you also be willing to upload my mscore package for debian? (once fluid-soundfont is through NEW)
[09:46] <\sh> elmargol: cool..bug no?
[09:47] <elmargol> 195369
[09:52] <\sh> elmargol: I assigned the bug to me...and confirmed it and set prio to critical...(in my opinion it is :))
[09:52] <persia> Does anyone have any suggestions about who might know about the use of Ubuntu to process CT scans?
[09:52] <\sh> persia: decompile "CT scans" please :)
[09:53] <elmargol> \sh: yes mail is critical :D
[09:54] <persia> \sh: Applied Computed Tomography to successive radial X-Rays for multidimensional rendering of internal organisation (used for either of the big devices at hospitals where you go into a tube, and the technician in the next room makes pretty pictures).
[09:54] <tsmithe> \sh, i think he means "computed tomography"
[09:54]  * persia gives tsmithe a gold star for successful acronym expansion
[09:55] <\sh> persia: thx :) I just needed a context for it ;) medical stuff is not on my list of acronyms for this channel ;)
[09:56] <tsmithe> persia, it would be very cool if there was a package to deal with that (though i personally would have no use for it, not having a personal ct scanner and all)
[09:57] <persia> tsmithe: There is such a package (ctsim).  I want to disable the GUI as porting it is painful, and it is the only reverse dependency of a library I'd like to drop.  Of course, I don't want to do this if anyone uses it.
[09:57] <tsmithe> ahh. is that one of your wx2.4 packages?
[09:58] <persia> The last one :)  bddebian and I uploaded the other two remaining packages about 12 hours ago.
[09:59] <tsmithe> wow. that's very good going! and then i suppose we'll drop wx2.4?
[10:00] <persia> Right, as nobody (not even upstream) wants to support it for the next few years.
[10:01] <tsmithe> ah yes, which they would have to otherwise, as hardy is lts. got it.
[10:02] <persia> tsmithe: lenny too.  There are actually two packages left in Debian, but one has a patch in the BTS and is expected to upload in the next couple months.
[10:02] <tsmithe> right, but lenny's not too urgent. when is it expected to be released?
[10:04] <persia> tsmithe: September or so, but freeze starts in June.
[10:05] <tsmithe> hmm. the cycles seem to have sped up. etch was released not that long ago, but sarge was back in 2005.
[10:08] <tsmithe> anyhow, i'm off
[10:09] <\sh> oh damn...wtf is going on between keybuk and mjg?
[10:10] <warp10> persia: regarding ctsim, I believe we can safely drop the GUI, based on the lack of support upstream, and also since it is just a simulator and not an actual CT appliance.
[10:16] <persia> warp10: Perhaps.  Upstream seems to close most of the bugs that get opened against the package though.  Maybe just for hardy, and bring it back later.
[10:18] <warp10> persia: sounds like a reasonable plan
[10:18] <slicer> When updating a package, should the changelog include a (LP: #xxx) for the bug I'm uploading the diff.gz in?
[10:19] <persia> slicer: Ideally.
[10:25] <fdr> hello! I've modified the source in a source package to fix a bug (simply modified a translation...), now how do I make a diff to upload in launchpad? Thanks
[10:27] <slicer> fdr: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[10:28] <coolbhavi> hello when does development for 8.10 start?
[10:28] <pochu_> coolbhavi: when 8.04 is released
[10:29] <coolbhavi> OK
[10:29] <fdr> sladen, so debdiff is the way to go?
[10:30] <persia> fdr: You'll want either diff -urN or debdiff, depending on how you made your patch.  There's a few links and some guide information available from https://wiki.ubuntu.com/MOTU/Contributing
[10:31] <fdr> I simply did apt-get source <packagename>, and edited one single line of one single file with vim
[10:32] <persia> fdr: Well, you've a choice.  You can follow the guidance from https://wiki.ubuntu.com/Bugs/HowToFix, or you can act as a member of the maintenance team, and prepare a new revision based on MOTU/Contributing.  It depends on how much time you have, and how familiar you wish to become with the tools.  Participants in this channel would be happy to help you either way.
[10:35] <fdr> thank you, I think I will go with HowToFix, since it is just a very simple fix...  But I'll get back with the other way later, since there are a couple of apps that I'd like to see in ubuntu and I'd like to try packaging
[10:37] <persia> fdr: Please share the bug number here when you have a patch.  There are a number of people who may be happy to package it and prepare the new candidate.  Thanks for helping to make Ubuntu better.
[10:38] <fdr> ok thanks. Is it enough to write the bug number here?
[10:39] <proppy> oy
[10:42] <emgent> bug #195380
[10:42] <ubotu> Launchpad bug 195380 in lighttpd "lighttpd crashes in some cases and giving a remote DoS possibility" [Undecided,New] https://launchpad.net/bugs/195380
[10:44] <\sh> emgent: fixing the hardy stuff the patch is trivial
[10:50] <fdr> persia, it is bug LP: #194745
[10:52] <fdr> anything else I should do?
[10:53] <phoenix24> I'm behind the University Proxy server, How can I use => bzr push bzr+ssh://..
[10:53] <phoenix24>  ?
[10:54] <\sh> phoenix24: blocked outgoing port 22?
[10:54] <phoenix24> \sh: yes.
[10:55] <slicer> Hm. SponsorsQueue on the wiki says that the debdiff should apply cleanly with -p1. However, Recipies/Debdiff says to run debdiff on .dsc's, which will unpack to /tmp/random/package, resulting in a patch that needs -p4. Which is right?
[10:56] <\sh> phoenix24: there are solution, but they could violate your university security statement ... so I think you know that you could forward port 22 from an outside server to launchpad, and listen on this very same machine on a port which could be opened on your universities FW?
[10:57] <phoenix24> \sh: Yes, can be done.
[10:58]  * Fujitsu normally uses an external machine with SSH on 443, and tunnels through some accessible HTTPS proxy.
[10:59] <phoenix24> are the there public servers that do port forwarding ?
[11:00] <Fujitsu> I doubt it.
[11:00] <phoenix24> Fujitsu: How do you forward your connection ?
[11:01] <Fujitsu> I use SSH's port-forwarding capability.
[11:01] <\sh> phoenix24: nope...you need your own rootserver e.g.
[11:02] <phoenix24> In my case, is the server to be reached is : bazaar.launchpad.net ?
[11:05] <\sh> phoenix24: well, you proxy server is blocking port 22 to the outside...so eventually port > 1024 are opened as destination ports...catch your rootserver which will have an ssh listen on 1025 e.g. and forwars this connection to port 22 of bazaar.launchpad...you can then configure ssh for your rootserver to use port 1025 instead of 22 and connect via bzr to your rootserver which will forward then the very same connection to port 22 of bazaar
[11:06] <\sh> phoenix24: and this way is eventually a violation of your university security laws (which could give you problems with your universities authorities, as a reminder)
[11:07] <phoenix24> :)
[11:07] <phoenix24> is launchpad ID, same as the launchpad login id ?
[11:08] <\sh> phoenix24: yes
[11:14] <persia> bug #194745
[11:14] <ubotu> Launchpad bug 194745 in language-pack-gnome-it "Misleading Italian translation for UML use-case" [Undecided,New] https://launchpad.net/bugs/194745
[11:14] <persia> slicer: Either you need to install patchutils, or you've encountered a native package, for which the instructions are not as optimal.
[11:18] <slicer> persia: It includes a upstream version change.
[11:18] <persia> slicer: Ah.  debdiff isn't very good at that.  Just attach your new diff.gz to the bug.
[11:19] <slicer> persia: I did, and was told to not do that but include the debdiff.
[11:19] <persia> slicer: Which bug?
[11:19] <slicer> persia: So I'm confused, and will include .diff, .debdiff and .interdiff
[11:19] <slicer> bug 194836
[11:19] <ubotu> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,Confirmed] https://launchpad.net/bugs/194836
[11:19] <persia> slicer: No, don't do that.  Let's figure out what you should attach, and attach the right thing.
[11:20] <slicer> persia: Er. Oops. Too late :(
[11:21] <slicer> persia: I thought I'd give the eventual sponsor the freedom of choice. The interdiff is much easier to read through, the debdiff includes the upstream changes, and the .diff.gz is what should be applied to the final package.
[11:21] <persia> slicer: You did exactly the right thing the first time.  When someone complains, and you think you did it right, feel free to check their LP page to see if they are sponsors, and ask again here.
[11:21] <persia> slicer: If the interdiff is easier to read, the sponsor can't use it, because combinediff doesn't support hunking.
[11:22] <persia> The debdiff cannot reliably be applied because it needs the new orig.tar.gz, and may end up with oddities in the diff.gz that aren't in the original as a result of application of the diff.  The diff.gz is the only bit that can be used.
[11:22] <persia> Putting lots of things in the bug report just confuses sponsors, who really want that first attachment of yours, and should be ignoring the rest of them.
[11:23] <slicer> persia: I understood that, but if the uploader wants to check that I didn't goof up, it's much easier to read. .. Then again, chances are the sponor knows how to use interdiff.
[11:23] <persia> slicer: Right, and the sponsor oughtn't trust your interdiff anyway: they should be reviewing the package themselves (as they are signing off on it being correct)
[11:24]  * slicer nods.
[11:24] <slicer> Ok, so I just contributed to doing something in the wrong way? Bah :)
[11:25] <slicer> And no, the commenter isn't a sponsor. Shame on me for assuming such.
[11:25] <persia> slicer: It's OK.  Most of the sponsors check anyway.  You just did a bit of extra work, but at least you know now, and can be more efficient in the future.
[11:26]  * persia notes that many non-sponsor commentors can have good feedback, and should not be ignored, but that when the suggestion runs counter to previous experience, it may be good to get a second opinion.
[11:26] <slicer> persia: *nod*. I did update the .diff.gz to close the bug though. Though it's a bit of circular logic there, as the bug with the .diff.gz in it didn't exist until the .diff.gz was uploaded :)
[11:27] <persia> slicer: That would be bug #179857
[11:27] <ubotu> Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857
[11:28] <slicer> Yes it would :) Nice to see it's being addressed.
[11:40] <phoenix24> \sh: I've forwarded a local port (2222) to bazaar.launchpad.net (22). How do I configure bzr to use 2222, instead of 22 ?
[11:43] <\sh> phoenix24: in your .ssh/config normally...
[11:43] <\sh> phoenix24: not knowing if bzr+ssh uses the normal ssh stack
[11:44] <phoenix24> ~/.ssh/config doesn't exist ?
[11:45] <\sh> phoenix24: man ssh :)
[11:46] <\sh> phoenix24: actually this is a question for #ubuntu :)
[11:46] <phoenix24> ok! thanks
[11:48] <persia> fdr: My apologies for the long delay.  The patch itself looks good, but that source package is in main, so I believe the translations are pulled from Rosetta (but would appreciate confirmation from someone more familiar), in which case your patch may not be the fastest way to get the fix applied.
[11:50] <\sh> anyone from motu-release online? :)
[11:51] <\sh> claws-mail-extra-plugins needs to be updated..the merge was done by elmargol, the merge looks good, and the new upstream release would solve a bug, which prevents latest claws-mail from working with the old version plugins
[11:51] <\sh> is it ok to just upload and fix this bug, or should I file a FFE for it as reference?
[11:52] <persia> \sh: From what I hear of policy, I believe the new upstream is supposed to not have any new features.  If there are also new features, it needs approval.  I believe the motu-release team is still discussing whether it needs a bug anyway, but it's probably safer to open and close a bug at least, even if you don't seek approval (and it never hurts to ask).
[12:02] <\sh> persia: I'll fil
[12:02] <\sh> e
[12:02] <\sh> one
[12:02] <persia> \sh: Seems the safest way.  If you're still not sure, maybe wait ~12 hours before running dput to see if any of motu-release respond.
[12:10] <fdr> persia, thanks for your remark. Anyway, I think doing the fix with Rosetta is almost impossible, since it does not have a search function and I don't feel like browsing all the messages in the language pack... Or is there any alternative I am missing?
[12:11] <Fujitsu> Good old bug #44.
[12:11] <ubotu> Launchpad bug 44 in rosetta "Translations should be searchable" [Medium,Confirmed] https://launchpad.net/bugs/44
[12:12] <persia> fdr: My apologies, but I have no idea.  I did one translation on Rosetta several years ago, and haven't used it since.
[12:13] <fdr> ok, thanks!
[12:16] <\sh> motu-release was the right team to subscribe for FFEs I hope
[12:19] <persia> \sh: Yes.
[12:20] <\sh> ok..bug #195369 :)
[12:20] <ubotu> Launchpad bug 195369 in claws-mail-extra-plugins "[FF Exception] Please merge claws-mail-extra-plugins <3.3.0+dfsg-2> (universe) from Debian <unstable> (<main>)" [Critical,Confirmed] https://launchpad.net/bugs/195369
[12:20] <\sh> I adjusted the bug actually
[12:22] <persia> \sh: Now you just have to wait for either two ACK's or one not-for-us :)
[12:23] <\sh> persia: well, not-for-us gives many angry users, including me ;)
[12:23] <persia> \sh: "not-for-us" means not-for-motu-release, meaning not--a-FFe, meaning, "Just upload, already".
[12:24] <\sh> persia: ah...;) I thought "not-for-us" means "no, we don't want this in" ;)
[12:25] <persia> \sh: No, I've seen a couple FFe requests that were unsub'd as not-for-us because a member of motu-release didn't think they needed an exception.
[12:28] <frenchy> fdr: As I'm sure that you've already read, just download the po to find the translation that you want.  Then fix it either online or in the po and re-upload.
[12:30] <fdr> frenchy, mmm... thanks, but either I am missing something, or it takes particular privileges to re-upload the .po file...
[12:31] <frenchy> Would I be wrong in assuming that getting a FFe for an "extra" would be easier than an "optional" or "recommended" priority?
[12:32] <frenchy> fdr: well I can on my project ... let me try someone else's ... does the "Upload a file" option come up for you?
[12:34] <persia> frenchy: Assuming the package has the correct Priority, likely, but it's really a matter of avoiding possible regressions or transitions, as there's not much time left for testing.
[12:34] <frenchy> fdr: Yeah, LP can sometimes be a bit confusing.  I subscribe to the Brownian motion theory of just start clicking till stuff works ... i.e. Click the "View Template & All Languages..." to get the upload link.
[12:35] <frenchy> fdr: Go figure.
[12:35] <fdr> on dia, when I select the "translation" tab it says that the project is not set up to manage translations with launchpad, while when I can't find the page for language-pack-gnome-it
[12:36] <fdr> mmm I *hate* LP. It seems just to be trying to stand in my way and nothing more.
[12:37] <frenchy> persia: Thanks again.  Your continued effort amazes and inspires me.  I'm sure that a lot of developers get caught in this pattern of minor bugs fixes that they want uploaded (80-20 rule).
[12:39] <frenchy> fdr: I hear you.  Somethings it does really well and I haven't really found a better alternative.
[12:39] <fdr> well, I did no real work with either, since I only reported some bugs, but I liked bugzilla much more :)
[12:40] <Hobbsee> boo
[12:40] <persia> frenchy: Yep.  Personally, I tend to look at different packages after the freeze starts than I was chasing beforehand.  There are lots of easy bugs and simple packaging tasks that need doing that often get missed because nobody is paying attention to some package.
[12:40]  * persia turns on all the lights
[12:41] <frenchy> Hobbsee: boo who
[12:42] <frenchy> Hobbsee: Don't worry .. that was a joke ... I laughed, so it hit its intended audience.
[12:44] <frenchy> persia: Yeah, I'm now aware of the amount of work that you guys put in to hold this thing together.  3 Cheers for MOTU.  I have enough trouble with one.
[12:52] <\sh> Hobbsee: my dear release member :) could you provide your opinion to https://bugs.launchpad.net/bugs/195369 , please? :) thx :)
[12:52] <ubotu> Launchpad bug 195369 in claws-mail-extra-plugins "[FF Exception] Please merge claws-mail-extra-plugins <3.3.0+dfsg-2> (universe) from Debian <unstable> (<main>)" [Critical,Confirmed]
[12:55]  * Hobbsee is playing with shiny things, and is therefore distracted
[12:55] <\sh> Hobbsee: diamonds? :)
[12:57] <joejaxx> https://launchpad.net/~joejaxx/+packages is looking sparse :( i need stuff to do lol
[12:57] <Hobbsee> nope
[13:07] <persia> joejaxx: There's about 200 packages that need maintainer mangling.  There are about 750 patches that need review and new candidate revisions prepared.  There's about 40,000 bugs available to be fixed.  You might also look at the output of `apt-cache unmet -i`.  Let me know if you run out again.
[13:08] <mruiz> hi all
[13:23] <Iulian> Hi
[13:25] <DaveMorris> I've been using the opensg libs I created for hardy, and I've just noticed that a couple of install dependencies have been missed off, whats the policy for fixing this?
[13:25] <DaveMorris> File a bug, and attach a debdiff I assume
[13:27] <ScottK2> DaveMorris: Yes
[13:28] <DaveMorris> how do you create a deb diff?
[13:34] <slytherin> DaveMorris: debdiff oldversion.dsc newversion.dsc
[13:44] <DaveMorris> who do I need to subscribe to get it fixed?
[13:47] <\sh> ScottK: thx
[13:48] <ScottK> No problem.
[13:49] <\sh> ScottK: two acks are needed, right?
[13:49] <ScottK> Yes
[13:52] <ScottK> \sh: Approved.
[13:56] <DaveMorris> ScottK once the bugs been fixed, who do I need to subscribe to it?
[13:56] <ScottK> ubuntu-universe-sponsors
[13:56] <DaveMorris> thnaks
[13:56]  * DaveMorris makes notes for next time :)
[14:01] <sistpoty|work> hi folks
[14:07] <mok1> ScottK, have you had time to cast an eye on bug 156100 ?
[14:07] <ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
[14:08] <mok1> ScottK: ah, you did
[14:08] <ScottK> mok1: Did you see my comment?
[14:08] <mok1> I will go ahead and do the update, then
[14:10] <lool> Hi folks; I'm pondering pushing gstreamermm (C++ bindings for GStreamer) which is a very new module to universe; I just pushed it to Debian experimental and thought it might be nice to have it in hardy for backports, third party devs etc. but would like to hear from you
[14:10] <mok1> ScottK: I will assign the bug to me, ok?
[14:10] <ScottK> Sure.
[14:12] <sistpoty|work> lool: any reason, why it's not yet in unstable, but only in experimental?
[14:13] <lool> sistpoty|work: Because we avoid publishing unstable API in Debian unstable in pkg-gnome/pkg-gstreamer
[14:14] <lool> For example we don't publish the gtk or glib dev series in unstable because of this
[14:14] <ScottK> lool: If it's not stable enough for unstalbe, it seems unlikely it'd be stable enough for us to drop in late in the release cycle.
[14:14] <sistpoty|work> lool: I guess it would be better to get it in hardy+1 then, and backport it to hardy from there, what do you think?
[14:15] <lool> ScottK: Ok; I was wondering whether it was too late for this cycle too
[14:15] <ScottK> lool: We are past Feature Freeze.  It's need good justification.  I think, without knowing a lot on the topic, it would likely be better to wait.
[14:15] <lool> I think we tend to merge unstable apps and unstable which are going to stabilize before release, but as I can't tell for gstreamermm it might be best to wait after release
[14:16] <lool> +libs
[14:17] <lool> "we tend to merge unstable apps and unstable libs which are going to stabilize"
[14:24] <\sh> Hobbsee: thx...
[14:24] <\sh> elmargol: uploading
[14:25] <\sh> ScottK: btw...the bug was the original merging bug, and I set it to me and confirmed it...
[14:31] <sistpoty|work> \sh: we use bug states for state of an FFe, confirmed means "granted"... (and bugs being confirmed will hence not show up on the working list of motu-release)
[14:36] <\sh> sistpoty|work: yepp...next time I reset the bugstates :)
[14:36] <sistpoty|work> :)
[14:37] <joejaxx> persia: where do i get this grand list of non-mangled maintainer packages?
[14:38] <joejaxx> the funny thing is
[14:39] <joejaxx> i could probably write something up to fix all of those and build source packages for them
[14:39] <joejaxx> lol
[14:39] <joejaxx> hello dholbach and zul
[14:39] <zul> hello
[14:40] <dholbach> heya
[14:40] <joejaxx> :)
[14:40] <sistpoty|work> hi dholbach and zul
[14:41] <dholbach> hey sistpoty|work
[14:41] <dholbach> sistpoty|work: awesome work on the library packaging session
[14:42] <sistpoty|work> thanks dholbach... w.o. slangasek it wouldn't have been that good however ;)
[14:42] <dholbach> you guys rock, both :)
[14:42] <RainCT> Hi
[14:43] <sistpoty|work> hi RainCT
[14:56] <stani> I need help to fix pychecker. Is there someone experienced in Python around ( ScottK )?
[14:56] <RainCT> stani: just ask
[14:57] <stani> The problem is that the test suite of pychecker supposes a python2.4 install, which leads to a FTBS.
[14:58] <geser> stani: I once looked at pychecker
[14:58] <stani> I am quite familiar with Python, but don't know how I can adapt the code so that all python 2.4 references are transferred to 2.5
[14:59] <geser> stani: but I don't know if patching the test output of pychecker with python2.5 is the correct way
[14:59] <stani> Better would be that pychecker tests against the current python versions and that version numbers are not hard coded in the test suite.
[15:01] <geser> changing the path in the test suite isn't hard, but I don't know if the other test failure are a regression or not
[15:03] <stani> geser: I am willing to review and fix all the tests, if someone can explain me how the test suite works. Especially where the expected output is defined.
[15:03] <geser> the development version of pychecker mentions support for python2.5 in its changelog but last I checked it, it failed in the test suite too
[15:05] <stani> Some tests may be related to the python version number, other tests might be due to a bug in pychecker. Probably I can fix them, but I just need to know how the information I asked above.
[15:05] <geser> stani: see test_input/ for the tests and test_expected/ for the results
[15:05] <emgent> heya
[15:06] <geser> stani: debian/regression.sh is the script doing the tests
[15:07] <stani> ok, geser, I'll start and will ask questions here if I get stuck.
[15:08] <stani> geser: is there any information you still remember, from when you looked at pychecker?
[15:12] <bddebian> Heya gang
[15:13] <\sh> moins bddebian
[15:14] <bddebian> Hi \sh
[15:14] <sistpoty|work> hi bddebian
[15:16] <bddebian> Heya sistpoty|work
[15:16] <geser> Hi bddebian
[15:17] <geser> stani: not more than I already told you
[15:17] <sistpoty|work> bddebian: /me hopes to see ufoai in debian soon... strange enough, I downloaded it on the same day, before the thread started and am currently busy testing it *g*
[15:18] <bddebian> Heya geser
[15:18] <bddebian> sistpoty|work: Yeah, is it good? :)
[15:19] <sistpoty|work> bddebian: well, I *loved* the old ufo - enemy unknown, and ufoai is even better :)
[15:27] <mok1> ScottK: I've uploaded the diff.gz file for python-storm. Should I change bug status to New?
[15:27]  * mok1 wonders why LP doesn
[15:27] <mok1> ' do this by itself
[15:29] <bddebian> sistpoty|work: I'll have to check it out.  Though it sounds like there's going to be licensing issues and I HATE those :-(
[15:30] <sistpoty|work> bddebian: yeah... license issues in *data* files are a nightmare :(
[15:30] <stani> geser: ok, fixed one test already ;-)
[15:34] <warp10> gpe-mixer has an unmetdep on gpe-icons  >= 0.23 since Hardy ships gpe-icons 0.20-1.1. I was wondering if this could be worth to ask a FFe, since gpe-icons 0.25-1 (in sid) isn't changed so much and I would avoid to add an ubuntu1 delta to gpe-icons.
[15:35] <warp10> ("delta to gpe-mixer", of course)
[15:35] <mruiz> Hi all. Where can I find information about debian/control fields supported by Ubuntu?
[15:36] <sistpoty|work> warp10: if it's an unmet dependency, sounds sane to me
[15:37] <warp10> sistpoty|work: good. I'll report a sync request soon, at a first look gpe-icons has just some minor changes
[15:39] <sistpoty|work> warp10: since it's an icons package, it also doesn't fall under FFe's imho but rather under ArtworkDeadline. ScottK, Hobbsee, TheMuso: agreed?
[15:41] <hellboy195> sistpoty|work: time for some questions about sensors-applet?
[15:42] <sistpoty|work> hellboy195: what's up?
[15:43] <hellboy195> sistpoty|work: as I see on the homepage currently there is only nvidia support. also ati support planned?
[15:44] <sistpoty|work> hellboy195: no idea... actually... maybe asking upstream?
[15:45] <hellboy195> sistpoty|work: ah thought you know it maybe .. :) nvm. and I should also ask upstream why the indicator for my graphics card is red though it's running at 47°?
[15:46] <warp10> sistpoty|work: if we consider it under ArtowrkDeadline it should be fine syncing it before UIF, shouldn't it?
[15:46] <sistpoty|work> hellboy195: yes, please ;)
[15:46] <sistpoty|work> warp10: yes
[15:46] <hellboy195> sistpoty|work: ^^ k, anyway. thx :)
[15:46] <sistpoty|work> np
[15:54] <hellboy195> afflux: ahoi ;)
[15:54] <afflux> morning hellboy195! :)
[16:15] <ScottK> sistpoty|work: Since it's not Ubuntu artwork, but more general, I think it needs an FFe, but I don't see a problem with giving it.
[16:21] <sistpoty|work> ScottK: ok, makes sense
[16:32] <bobbo> does anyone have any docs on syncing packages from Debian? I'd like to add ogre-plugins-cgprogrammanager to Universe to fix Bug #194686/Bug #195065
[16:32] <ubotu> Launchpad bug 194686 in funguloids "Error installing Funguloids: ogre-plugins-cgprogrammanager doesnt exist" [Undecided,New] https://launchpad.net/bugs/194686
[16:32] <ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-plugins-cgprogrammanager from debian unstable" [Undecided,New] https://launchpad.net/bugs/195065
[16:42] <RainCT> bobbo: You have to do some changes in the "Please sync..." bug and then subscribe ubuntu-universe-sponsors. If a MOTU thinks that the sync is OK he will change the status to confirmed and subscribe ubuntu-archive, and then an archive admin will do the sync
[16:43] <geser> RainCT: what about the needed FFe?
[16:45] <RainCT> bobbo: a sync request should look like this : a) bug title: "Please sync <package name> <version> from Debian unstable (<main/contrib/non-free>)";  b) explain what the changes in Debian are and if there were any Ubuntu changes why they can be dropped (this isn't applicable in this case); c) include a rational about why it should be synced
[16:46] <RainCT> and in this case as geser says you'll also need a Freeze Exception
[16:46] <sistpoty|work> jdong: can you comment on bug #195389 please?
[16:46] <ubotu> Launchpad bug 195389 in deluge-torrent "Please sync deluge-torrent 0.5.8.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/195389
[16:49] <bobbo> RainCT: ok, im on it
[16:51] <RainCT> geser: for the freeze exception, should contributors subscribe motu-release before u-u-s, or just subscribe u-u-s and let the sponsor subscribe motu-release?
[16:53] <jpatrick> RainCT: before to allow acking
[16:54] <bobbo> Ok, ive fixed up the description, im guessing i subsribe motu-release now for the FFe?
[16:54]  * jdong grumbles at deluge's large diffstat
[16:54] <geser> RainCT: I'd say motu-release and if the FFe got granted u-u-s (if it's still needed, perhaps the FFe counts as an ACK)
[16:55] <RainCT> jpatrick, geser: thanks
[16:56] <jpatrick> bobbo: yes
[16:56] <bobbo> jpatrick, RainCT: right thats the title/description updated and motu-release subscribed, anything else I need to do?
[16:57] <jpatrick> bobbo: wait :)
[16:58] <RainCT> heh
[17:00] <sistpoty|work> RainCT, geser: well, at least for what I ack with the motu-release hat, I don't consider this necessarily an ACK for sponsoring (as I don't test-build the package)
[17:01] <jdong> sistpoty|work: commented...
[17:01] <sistpoty|work> jdong: thanks
[17:02] <jdong> sistpoty|work: though let the record show that's an ok with a grumble attached
[17:02] <jdong> :)
[17:02] <sistpoty|work> heh
[17:04] <geser> sistpoty|work: doesn't the FFe needs a build log?
[17:06] <sistpoty|work> geser: yes, though I'm not too sure why (and looking at a build log and building it myself is still a difference (e.g. buildlog outdated))
[17:13] <emgent> heya blueyed :P
[17:13] <blueyed> Hi emgent :)
[17:20] <bobbo> sistpoty|work: in bug #195065 you said you can only sync source packages, where do i get the source package?
[17:20] <ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-plugins-cgprogrammanager 1.4.6-1 from debian unstable contrib" [Medium,Invalid] https://launchpad.net/bugs/195065
[17:20] <bobbo> sistpoty|work: wait, doesnt matter, found it
[17:21] <sistpoty|work> bobbo: apt-cache showsrc in an unstable chroot is what works for me... others than that there is also packages.debian.org/packagename with links
[17:23] <bobbo> sistpoty|work: thanks, got the package and added it to the report
[17:24] <sistpoty|work> bobbo: also the necessary build log, diffstat and diff of upstream changelog?
[17:24] <bobbo> sistpoty|work: not got that yet ;)
[17:24] <sistpoty|work> then please add it ;)
[17:26] <jpatrick> bobbo: see bug #192350 for an example
[17:26] <ubotu> Launchpad bug 192350 in semantik "[Feature Freeze Exception] New upstream release" [Undecided,Fix released] https://launchpad.net/bugs/192350
[17:27] <bobbo> jpatrick: thanks :D
[17:27] <bobbo> jpatrick, sistpoty|work: is the diffstat etc between the Debian Version and Current Ubuntu version?
[17:28] <jpatrick> bobbo: between the two releases
[17:28] <\sh> DktrKranz: Re: bug #185513 -> the dh_strip in our sbuild chroot needs a fix...adding this to the amd64 part of debian/rules in wine doesn't help actually
[17:28] <ubotu> Launchpad bug 185513 in wine "Wine packages overly large" [Undecided,New] https://launchpad.net/bugs/185513
[17:28] <bobbo> jpatrick: the package isnt in Ubuntu though...
[17:29] <jpatrick> bobbo: then no need I guess
[17:29] <sistpoty|work> bobbo: ogre-contrib is in hardy?
[17:30] <DktrKranz> \sh, I tested only in i386 and it worked. I haven't any amd64 boxes to test it out.
[17:30] <\sh> DktrKranz: on i386 it works without any problem :)
[17:30] <\sh> DktrKranz: it's only on amd64
[17:30] <bobbo> sistpoty|work: it is but not building ogre-plugins-cgprogrammanager
[17:31] <DktrKranz> so, it's just half-a-fix :)
[17:31] <sistpoty|work> bobbo: aha... because it obviously failed to build
[17:31]  * bobbo goes to check logs
[17:31] <sistpoty|work> bobbo: which could be related with that old changelog entry: " * Bootstrapping will be done manually."
[17:31] <DktrKranz> \sh, anyway, main issue is segfaults. I tried to look at them, but got no useful details, even with dbgsym
[17:32] <\sh> DktrKranz: it looks like that something is terribly wrong...when invoking wine from != a direct wine src tree dir
[17:32] <\sh> DktrKranz: there are some messages on wine-devel ml...
[17:32] <sistpoty|work> bobbo: nope, looks like s.th. different is making problems: http://launchpadlibrarian.net/11901495/buildlog_ubuntu-hardy-i386.ogre-contrib_1.4.5-1_FAILEDTOBUILD.txt.gz
[17:33]  * bobbo never gets the easy bugs :/
[17:34] <jpatrick> bobbo: there are none
[17:34] <DktrKranz> \sh, so it's not just us... this is good and bad at the same time
[17:34] <bobbo> heh :)
[17:34] <hellboy195> bobbo: start with merging ^^
[17:35] <\sh> DktrKranz: yeah...
[17:35] <geser> bobbo: there is a nvidia-cg-installer in multiverse but it won't work on the buildds as it wants net access (for downloading) and the buildds have no net access
[17:40]  * bobbo is now yoyally confused over ogre-contrib bug :/
[17:40] <bobbo> s/yoyally/totally
[17:48] <jpatrick> bobbo: http://paste.ubuntu-nl.org/57358/ - it's missing a libraby
[17:49] <geser> bobbo: the last version in Debian has "* Specify Build-Depends and Depends on nvidia-cg-toolkit (>= 2.0)" so it might work now
[17:49] <bobbo> jpatrick, geser: so the original plan of merging in the current debian version might work?
[17:52] <DRebellion> how can i get pbuilder to use a hardy enviroment for building packages? I have changed the DISTRIBUTION= variable in /etc/pbuilderrc but it seems to still build under gutsy =/
[17:52] <DRebellion> i am running gutsy btw
[17:54] <jpatrick> DRebellion: you sure it's not DIST=hardy? :)
[17:55] <DRebellion> jpatrick, from /etc/pbuilderrc:
[17:55] <DRebellion> # specifying the distribution forces the distribution on "pbuilder update"
[17:55] <DRebellion> DISTRIBUTION=hardy
[17:55] <jpatrick> DRebellion: hrmm, then I have my pbuilder set up differently
[17:55] <DRebellion> :(
[17:56] <HighN1> DRebellion: did you 'reinit' pbuilder after changing the distribution?
[17:56] <DRebellion> HighN1, erm, no?
[17:56] <HighN1> DRebellion: wait a sec...
[17:57] <HighN1> DRebellion: sudo pbuilder update --distribution hardy --override-config
[17:58] <DRebellion> HighN1, i did that, but when i go to build a package it starts to download all of the gutsy packages again!
[17:58] <HighN1> DRebellion: hm, how do you bulid your package?
[17:58] <DRebellion> HighN1, sudo pbuilder build --logfile ~/pbuilder3.log package.dsc
[17:59] <HighN1> DRebellion: just a try: sudo pbuilder build --distribution hardy --logfile ~/pbuilder3.log package.dsc
[18:00] <bobbo> sistpoty|work, jpatrick: What information do i need to add to the FFe/Sync request?
[18:00] <DRebellion> HighN1, i'll give that a shot. its just that i shouldn't have to specify on the cmd line every time right?
[18:00] <jpatrick> bobbo: the ones in the example I gave you
[18:01] <HighN1> DRebellion: Right. I can't tell - I did it the other way - sudo pbulider login  gives you a full chroot environment with a bash, there you can do the debuild manually. that works for me all the time...
[18:01] <bobbo> jpatrick: ive lost the link (embarrased), can you send it again?
[18:02] <jpatrick> bobbo: https://launchpad.net/bugs/192350
[18:02] <ubotu> Launchpad bug 192350 in semantik "[Feature Freeze Exception] New upstream release" [Undecided,Fix released]
[18:02] <bobbo> jpatrick: thank you!
[18:03]  * sistpoty|work heads home
[18:03] <sistpoty|work> cya
[18:17] <DRebellion> Hrm, still can't get this hardy pbuilder to work properly... could someone talk me through the steps to get a hardy pbuilder enviroment? HighN1?
[18:18] <bobbo> jpatrick: that should be everything that needed up for Bug #195065 if you are interested
[18:19] <ubotu> Launchpad bug 195065 in ubuntu "Please sync ogre-contrib (1.4.6-1) from debian unstable contrib" [Medium,New] https://launchpad.net/bugs/195065
[18:19] <james_w> DRebellion: you might like to try pbuilder-dist from ubuntu-dev-tools, but I think that might mean you creating a new chroot.
[18:20] <DRebellion> james_w, that's not a problem, I only need the default (and only) chroot to be hardy.
[18:23] <HighNo> DRebellion: hm, I did everything according to this wiki: https://wiki.ubuntu.com/PbuilderHowto
[18:23] <DRebellion> HighNo, same.
[18:25] <HighNo> DRebellion: brb
[18:26] <james_w> DRebellion: pbuilder login --save-after-login
[18:27] <james_w> DRebellion: then edit /etc/apt/sources.list to say hard, then run update; dist-upgrade and log out
[18:37] <jpatrick> bobbo: see noresetto's comment on the bug :)
[18:41] <bobbo> jpatrick: just got the email, checking it out now
[18:58] <tsmithe> slomo__, thanks for the upload
[19:01] <bmhm> hi all
[19:01] <bmhm> I'd like to mention THIS backport URGENTLY: https://bugs.launchpad.net/gutsy-backports/+bug/192751
[19:01] <ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Undecided,New]
[19:02] <pochu_> bmhm: what's urgent from it?
[19:02] <slangasek> wow, pioneers is urgent, how far we've come
[19:02] <bmhm> pochu_: I've been waiting for... weeks =)
[19:02] <bmhm> pochu_: can't I provide MY packages?
[19:02] <bmhm> I can provide gutsy amd64 and edgy x86
[19:03] <pochu_> no, you can't. packages are built in ubuntu buildds
[19:03] <bmhm> I see. Anyway, thanks for the tipp regarding prevu. Wounderful tool.
[19:03] <bmhm> Indeed.
[19:06] <ScottK> bmhm: Once it's tested, set the bug to Triaged.  I don't even look at New backports requests.
[19:07] <bmhm> thanks ScottK
[19:07] <bmhm> ScottK: What is "Triaged"?
[19:08] <ScottK> In general terms it means that the bug has been evaluated and a root cause has been determined (it's ready for a developer to look at fixing)
[19:08] <ScottK> We use it in backports to mean it's fully tested and ready to be looked at for approval.
[19:09] <bmhm> I didn't see the option "Triaged"
[19:09] <bmhm> So i picked confirmed instead
[19:10] <ScottK> Confirmed is fine.
[19:11] <ScottK> Triaged has some restrictions on it.  I look at confirmed too.
[19:17] <bmhm> fine
[19:30] <LaserJock> RainCT: ping
[19:33] <RainCT> LaserJock: pong
[19:33] <LaserJock> RainCT: I had a chance to test pbuilder-dist
[19:33] <RainCT> LaserJock: evil again? ;)
[19:33] <LaserJock> well, kidna
[19:33] <LaserJock> *kinda
[19:33] <LaserJock> I needed to fix something
[19:34] <RainCT> LaserJock: ya?
[19:34] <LaserJock> RainCT: at the very bottom of the actual pbuilder command, it sets the aptconfdir
[19:34] <LaserJock> and the quoting is incorrect I believe
[19:35] <LaserJock> when I tried to do a pbuilder create it actually added a " to the path
[19:35] <LaserJock> so I just made that line: $( [ $ISDEBIAN != "False" ] || echo "--aptconfdir ${BASE_DIR}/etc/${DISTRIBUTION}/apt.conf/" ) \
[19:35] <LaserJock> and it seemed to work fine after that
[19:36] <RainCT> LaserJock: can you try if      $( [ $ISDEBIAN != "False" ] || echo "--aptconfdir '${BASE_DIR}/etc/${DISTRIBUTION}/apt.conf/'" ) \      works, please?
[19:36] <RainCT> LaserJock: I think it wouldn't work if the basedir contains spaces if it has no quotes at all
[19:37] <LaserJock> hmm
[19:51] <LaserJock> RainCT: no go, it still puts ' in the path
[19:52]  * RainCT is pondering if rewriting the damn think in Python might help :P
[19:53] <geser> RainCT: it can't get worse :)
[19:55] <hellboy195> geser: quick question. I'm doing bug 195532 is bug 186130 really necessary?
[19:55] <ubotu> Launchpad bug 195532 in libnxml "Merge libnxml 0.18.1-4 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/195532
[19:56] <ubotu> Launchpad bug 186130 in libnxml "libnxml needs a versioned build-dependency on cdbs" [Undecided,New] https://launchpad.net/bugs/186130
[19:57] <LaserJock> RainCT: honestly, I think it could be much simpler as well
[19:57] <RainCT> LaserJock: I'm adding the original script as pbuilder-dist-simple right now ;)
[19:57] <LaserJock> doing it in Python is an idea though
[19:58] <geser> hellboy195: if you do the merge please also the second bug
[19:58]  * ScottK2 cheers simplicity
[19:58] <LaserJock> it seems like right now though it's too easy to break it
[19:59] <geser> hellboy195: *fix the second bug
[19:59] <RainCT> Indeed. I think I'll have a go at converting it to Python, that should make it much more robust
[19:59] <hellboy195> geser: so it's necessary though he has a gutsy machine and I suppose on hardy there aren't problems?
[20:00] <captlogic> quit
[20:01] <geser> hellboy195: on hardy it's no problem (else it would FTBFS), only when backporting
[20:01] <hellboy195> geser: . so I suppose cdbs (>= 0.4.5)
[20:03] <geser> hellboy195: check the cdbs changelog when it was introduced
[20:03] <hellboy195> geser: k, thank you :)
[20:03] <geser> hellboy195: cdbs (>= 0.4.49ubuntu5)
[20:03] <hellboy195> geser: ah. again thx :)
[20:08] <mok0_> he
[20:08] <ScottK2> llo
[20:12] <dsop> does revu notice when the version number of an not yet approved package changed?
[20:14] <LaserJock> dsop: how do you mean?
[20:15] <joejaxx> LOL
[20:15] <joejaxx> the next version of ubuntu is called Intrepid Ibex ?
[20:15] <LaserJock> uhh, yeah, where have you been? ;-)
[20:16] <joejaxx> :P
[20:16] <joejaxx> hello LaserJock :)
[20:16] <LaserJock> hiya joejaxx
[20:16] <LaserJock> how's it going?
[20:16] <joejaxx> it is going well :D
[20:18] <dsop> hmm LaserJock my upload wsa rejected but i had revu upload rights two month ago
[20:19] <LaserJock> dsop: did you use the same name & address in the changelog entry?
[20:19] <dsop> LaserJock: in the debian changelog, yes
[20:20] <LaserJock> dsop: you probably need to talk to a REVU admin
[20:20] <LaserJock> if it was two months ago that you last uploaded I'd think it'd be ok
[20:26] <mok0_> ScottK: I uploaded a diff.gz to bug 156100 .
[20:26] <ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
[20:29] <RainCT> dsop: what's your email?
[20:29] <dsop> RainCT: sn_@gmx.net
[20:31] <dsop> RainCT: i got Signer has no upload rights at all to this distribution.
[20:33] <pochu_> dsop: are you sure you dput to revu? ;)
[20:33] <RainCT> you're in the database
[20:33] <pochu_> (if you just dput, it will go to the ubuntu archive)
[20:33] <dsop> argg
[20:34] <dsop> pochu_: okay, man i should read better the wiki nexttime
[20:38] <pochu_> dsop: it once happened to me the other way round, I dput'ed to the archive instead of to revu ;)
[20:38] <RainCT> pochu_: you're not the only one ;)
[20:39] <HighNo> hehe - i guess one is a real motu only if you have done that at least once...
[20:41] <jdong> spawn new motumedia_member()
[20:41] <pochu_> jdong: who's him?
[20:41] <jdong> looking for any :)
[20:41] <pochu_> heh
[20:41] <jdong> or anyone else who knows what happened to xvidcap
[20:41]  * pochu_ hides from jdong ;)
[20:42]  * HighNo is out since he still uses feisty...
[20:42] <pochu_> jdong: ah, so you aren't recluiting :)
[20:42] <jdong> pochu_: ha like I have the power to recruit ;-)
[20:42] <pochu_> HighNo: that's old!! ;)
[20:43] <jdong> hmm FFe for a FTBFS'ed package since like Feisty.
[20:43] <jdong> shouldn't be hard to grant, right?
[20:43] <jdong> </famous last words>
[20:44] <HighNo> pochu_: true, but it is still working. Updating would be nice but only 150MB free atm. Updating would require like 1GB... :-(
[20:46] <pochu_> jdong: if it builds with the new version, I don't think so :P
[20:46] <jdong> Local variables:
[20:46] <jdong> mode: debian-changelog
[20:46] <jdong> End:
[20:46] <jdong> WTF is that stuff?
[20:46] <jdong> found it at the end of debian/changelog
[20:47] <jdong> I'm guessing some of marillat's editor cruft?
[20:47] <man-di> jdong: for emacs
[20:47] <jdong> man-di: is it supposed to be at the bottom of debian/changelog or should I snip it out?
[20:47] <man-di> if its there emacs uses that settings for that file
[20:48] <HighNo> snip it - that should not be there
[20:48] <man-di> if its not there, it uses its default settings
[20:48] <bobbo> hi, ive got a fix available for Bug #195196 but dnot know whether i should forward it to Debian or add the patch to the Ubuntu bug
[20:48] <ubotu> Launchpad bug 195196 in graphmonkey "graphmonkey: Upgrade to new upstream release (1.7)" [Wishlist,Confirmed] https://launchpad.net/bugs/195196
[20:48] <man-di> jdong: there are many many packages with this
[20:48] <jdong> man-di: so it's safe to leave in?
[20:48] <man-di> jdong: yes, doesnt hurt
[20:48] <HighNo> man-di: there are?
[20:48] <man-di> HighNo: I have seen this a couple of times in Debian packages
[20:49] <jdong> ok, then I'll leave it in. I was concerned because *cough* vim puts it in syntax error red :)
[20:50] <man-di> jdong: vim is not optimal either
[20:50] <HighNo> jdong: I guess vim is not debian compliant here :-)
[20:50] <jdong> lol here we go... :)
[20:50] <man-di> too many false positive errors for debian/control files
[20:50] <jdong> yeah vim does seem to be chicken little with that
[20:51] <dsop> please, is some of the motus willing to review gcutils?
[21:02] <jdong> urgh I made the most retarded upload ever
[21:04] <Fujitsu> Does anybody else find that Thunderbird hangs when gnome-settings-daemon crashes?
[21:04] <hellboy195> Hi, I want to merge nspluginwrapper 0.9.91.5-2 from Debian. With the -1ubuntu1 version people suffer from crashes like bug 195170 . The problem is that I have no idea if new Debian revision fixes these issues. So merge or wait?
[21:04] <ubotu> Launchpad bug 195170 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_slice_free_chain_with_offset()" [Undecided,New] https://launchpad.net/bugs/195170
[21:05] <Fujitsu> Neither. Test.
[21:06] <hellboy195> Fujitsu: well, personally I don't usw nspluginwrapper. Maybe I find a person who is willing to test :)
[21:06] <hellboy195> *usw
[21:06] <hellboy195> *use
[21:06] <hellboy195> argh
[21:12] <albert23> RainCT: Thanks for sponsoring gcal. Regarding forwarding the changes to Debian, can I send them the Ubuntu debdiff or should I make a Debian version?
[21:13] <RainCT> albert23: You're welcome :). You choose, the main thing is that they get the changes.
[21:13] <albert23> RainCT: OK, thank's, I will make a Debian version then
[21:14] <Flare183> What does this mean: create all leading components of DEST except the last, then copy SOURCE to DEST
[21:14] <Flare183> I don't get it
[21:15] <Flare183> bug 175404
[21:15] <ubotu> Launchpad bug 175404 in ubuntu "[needs-packaging] Nemo" [Wishlist,In progress] https://launchpad.net/bugs/175404
[21:15] <Flare183> exactly
[21:16] <Flare183> that is the one I am working on
[21:22] <LaserJock> Flare183: I think you need to describe your question more, I can't quite figure out what you're asking
[21:24] <Flare183> LaserJock: ok on the Man page for Install it says that the "-D" syntax means this: create all leading components of DEST except the last, then copy SOURCE to DEST; What does that mean?
[21:25] <Flare183> esp. the part about except the last
[21:25] <Flare183> correction "except the last"
[21:27] <LaserJock> I guess it's just "create the directory structure, then copy"
[21:30] <Flare183> LaserJock: ok thanks
[21:50] <macd> whats the best way to take an existing package, add an init script to it and repackage? I've read a bit about dh init but I can't seem to discern howto use it, I've looked at a few packages that have init scripts, but they're pretty big can someone recommend a smaller package to peep out?
[21:52] <mok0_> macd: look what's in /etc/init.d
[21:52] <macd> Im not sure how that helps me use dh init?
[21:52] <mok0_> macd: all you need is to put it in debian and call it <package>.init
[21:52] <macd> if its that simple I feel like a fool
[21:53] <macd> thx :)
[21:53] <mok0_> macd: you just call dh_init in debian/rrules and it takes care of it
[21:53] <mok0_> dh_init is in the rules template, iirc
[21:56] <macd> ok, another question, if a package exists, and the only thing it needs is an init script to add alot of functionality, is it better to just repackage with included script, or package the script seperate?
[21:57] <macd> I should mention, it has an init script already, but this gives the ability to start one or more instances, so it really expands the existing one
[23:04] <LaserJock> slangasek: your sync bugmail always munges the title of the email to be [Bug #] Synced, would it be possible to have it not do that?
[23:06] <slangasek> LaserJock: to what mail are you referring?
[23:06] <LaserJock> when you do syncs
[23:06] <slangasek> I don't send mail when I do syncs
[23:07] <LaserJock> well, I'm assuming the script you use does
[23:07] <geser> slangasek: but you add a comment to the sync bug which gets then mailed
[23:07] <LaserJock> take bug #195032
[23:07] <ubotu> Launchpad bug 195032 in starplot "Please sync starplot 0.95.4-3 from Debian(Unstable)" [Wishlist,Fix released] https://launchpad.net/bugs/195032
[23:07] <LaserJock> that's the one I got today
[23:07] <slangasek> yes, all I'm doing is adding comments to the bug in launchpad. If that generates mails with wrong subjects, I would think that's a LP issue?
[23:08] <LaserJock> hmm
[23:08] <LaserJock> odd
[23:08] <LaserJock> I was assuming it was a script
[23:08] <slangasek> there is a script.  but it works by adding comments to LP, not by sending email.
[23:09] <LaserJock> sure
[23:09] <LaserJock> ahh, perhaps it sets the "Subject" line in the comment
[23:09] <geser> that's what it does
[23:09] <LaserJock> I remember seb128's sync seemed to do that when he first became and archive admin
[23:10] <slangasek> well, ok, so what are you suggesting the subject should be instead?
[23:10] <LaserJock> no subject
[23:10] <slangasek> (anyway, pitti maintains this script, not me)
[23:10] <LaserJock> then it just get's the bug's subject
[23:10] <slangasek> ok
[23:28] <LaserJock> I need a MOTU for a huge favor
[23:28] <StevenK> LaserJock: You're all out of favours
[23:28]  * geser hides
[23:28] <LaserJock> dang
[23:30] <LaserJock> I actually need somebody to look over 5 Multiverse packages I'm going try to upload
[23:30] <LaserJock> I think they should be pretty ready to go
[23:30] <LaserJock> but I'd like to get a 2nd opinion
[23:31]  * geser says good night
[23:33] <LaserJock> heh
[23:57] <Legendario> what am i supposed to do to pack a source which has only an install script?
[23:58] <RAOF> Legendario: Write a debian/rules file which has an empty build: target, and call the install script in the install: target?
[23:59] <Legendario> RAOF, what is an empty build?