[02:43] <persia> crimsun: Does bug 74906 still need sponsorship?
[02:43] <ubotu> Launchpad bug 74906 in psycopg "python-psycopg: Missing dependencies? (libc6, libpq4)" [Medium,In progress]  https://launchpad.net/bugs/74906
[02:44] <crimsun> no
[02:45] <crimsun> it may or may not need ubuntu-sru subscribed
[02:45] <crimsun> our policy does not make it explicit, unfortunately
[02:45] <persia> crimsun: What do you think is the right way to handle it?
[02:46] <crimsun> I think subscribing ubuntu-sru is appropriate, but I want it formalized before I apply it
[02:46] <persia> crimsun: Is there a proposal under consideration?
[02:46] <crimsun> not AFAIK
[02:47] <persia> crimsun: Do you have time to write one up for Friday?  If not, please dump your basic thoughts somewhere, and I'll formalise it.
[02:47] <crimsun> I can try, but I can't promise.  I'm travelling through July 5, and then I'll be away beginning July 9.
[02:48] <persia> crimsun: Ah.  In that case, if you find a couple free minutes in the next couple days, please drop me a short email describing the scope, and I'll put something together.
[02:50] <crimsun> my goodness, I really need to rename this cruft
[02:50] <crimsun> too much *parser and *ui confusion
[02:51] <SlimG> Lintian gives me this warning: can't find numbered character 248, 248 is the character "", so what's the problem? the number is correct too afaik
[02:52] <SlimG> Its a norwegian latin1 encoded manpage
[02:57] <SlimG> persia: how do I insert the 241 char instead of the 248 char?
[02:59] <persia> SlimG: My solution is usually to edit in a UTF-8 environment and either use a keymap that can type the character I want or something like the GNOME character picker applet.
[03:01] <SlimG> would it work if I created the manpage in utf8 and use a utf8-2-latin1 tool (if I can find one)?
[03:02] <persia> SlimG: Why do you need a latin1 manpage?
[03:03] <SlimG> manpages within /usr/share/man/no is forced to be read as latin1
[03:04] <persia> SlimG: In that case, you probably don't want UTF8 (what happened to UTF8ByDefault?), and 241 may not be correct.
[03:06] <persia> SlimG: Separately, use iconv to convert between encodings.
[03:08] <SlimG> according to http://casa.colorado.edu/~ajsh/iso8859-1.html the "" character is number 248, I don't really understand why lintian complains about it beeing unable to find the numbered character 248
[03:10] <SlimG> I'll google around to see if there's others with the same issue
[03:21] <SlimG> persia: Might it have something to do with me using nn_NO.UTF-8 locale when running lintian?
[03:26] <persia> SlimG: Um.  Probably.  I'm not sure why the default nn_NO locale is UTF8, and there is the restriction that "manpages within /usr/share/man/no is forced to be read as latin1".  This seems like a policy bug to me.
[03:28] <SlimG> I'm pretty sure the main problem is the outdated "forced latin1 for norwegian manpages"
[03:28] <persia> SlimG: Where is that policy stated?
[03:28] <SlimG> mandb I think someone mentioned
[03:30] <SlimG> I believe I've found the problem that triggers Lintians warning, Lintian get's confused if the manpage encoding and locale encoding isn't the same
[03:31] <persia> SlimG: Ah.  That's probably the bug then.  As far as I can tell, manpages are transcoded to current locale when viewed (or at least by man: other tools may be buggy)
[03:32] <SlimG> So in theory, if I were to run the Lintian check on this manpage at a computer with latin1 locale it would probably not mention any warning
[03:33] <btm_> Is there a deb compatible version of ar kicking around out there?
[03:33] <Hobbsee> btm_: it's not in ubuntu/debian.  possibly
[03:33] <SlimG> persia: thanks for your help, I really aprechiate it
[03:34] <persia> SlimG: Thanks for tracking down the source issue.  Please file a bug against lintian about this.
[03:35] <btm_> Hobbsee:  It's my understanding that the bsd versions don't generate the filename/ that the included gnu version does, but oddly enough I don't see a bsd compatible binary on debian/ubuntu.
[03:36] <persia> btm_: Take a look at binutils
[03:37] <persia> Hobbsee: We need ar - it's the basis of .deb :)
[03:37] <SlimG> persia: I'll see if I can find the lintian bug-tracker and file a bug
[03:38] <Hobbsee> oh, right
[03:38] <persia> SlimG: https://bugs.launchpad.net/ubuntu/+source/lintian/ is a good place to start, and sending something to http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lintian might also be appropriate (but search those bugs first).
[03:39] <btm_> persia: Yes, binutils has ar, but it's GNU ar which is not 100% deb compatible.
[03:39] <persia> btm_: Ah.  Last time I actually used ar was a few years ago, and it was enough to address my severely broken bootstrap issues then, but I believe you if you say that it's not 100% compatible.
[03:40] <btm_> persia: if you head -2 a deb, you'll see that debian-binary does not have a slash after it. but if you 'ar r test.r somerandomfile ; head -2 test.ar' you'll see that somerandomfile has a slash after it.
[03:40] <SlimG> persia: lintian has no open bugs in launchpad... not bad :)
[03:40] <btm_> which makes apt-extracttemplates and others unhappy.
[03:41] <StevenK> I don't think Linda does, either.
[03:42] <StevenK> Actually, it does.
[03:42] <StevenK> And I think it's fixed in the version I should really get around to uploading.
[03:43] <persia> btm_: Hmm..  That's probably a bug then.  Given that we ship GNU ar by default, we probably want GNU ar style .debs, but it's the sort of bug is exremely unlikely to be fixed in Ubuntu - it needs a Debian solution, if any.
[03:47] <btm_> persia: I'll ask around debian, thanks.
[04:01] <aanderse> RAOF: thank you for your ubuntuforums response, but i would also like to know if there any motu effort to get precompiled kqemu kernel modules underway?
[04:03] <jsgotangco> haha
[04:03] <Hobbsee> hiya spam
[04:03] <persia> Hobbsee: I suggest it's still safe to ignore the kernel for a little while yet :)
[04:03] <Hobbsee> oh good
[04:03] <RAOF> You could *possibly* file a wishlist bug against linux-ubuntu-modules, asking for the kqemu module to be added, but I really don't know what the response would be
[04:03] <Hobbsee> then again, i touched casper a week ago...
[04:03] <persia> heh
[04:04] <aanderse> hmmm, because of lack of interest?
[04:05] <persia> aanderse: https://wiki.ubuntu.com/KernelTeamBugPolicies and https://wiki.ubuntu.com/KernelPatches should give you some understanding of the response
[04:05] <aanderse> thanks, i'll read up on that
[04:08] <ajmitch> Hobbsee: that's fine, i'll just hassle you to do stuff in main
[04:08] <persia> ajmitch: about gnue-?
[04:09] <ajmitch> persia: no
[04:09] <persia> ajmitch: OK.  I'll take your name off the assignment list on the migration page then.  Thanks.
[04:10] <ajmitch> whatever
[04:11] <Hobbsee> ajmitch: hah.  dream on.  you have your own powers
[04:11] <ajmitch> Hobbsee: nah, i feel like just removing myself
[04:12] <Hobbsee> ajmitch: not allowed.
[04:12] <Hobbsee> ajmitch: unless you'll contribute more to debian and ubuntu as a result
[04:12] <ajmitch> is allowed, actually
[04:31] <Fujitsu> Hm, I see that Canonical is advertising bzr through AdWords.
[04:31] <ajmitch> funny
[04:31] <Fujitsu> ?
[04:33] <jsgotangco> really?
[04:46] <zakame> good day MOTUs!   I'm just looking at the team wiki page, and noticed a request for help.  I'd like to recommend https://wiki.ubuntu.com/BuildingCommunity/CreatingTeamGuide as a good source of team building information.
[04:51] <Hobbsee> ahh.
[04:52] <zakame> persia: coolness!  thanks for that!
[04:53] <persia> zakame: That itself is a work-in-progress, so if you find anything new, please also add it there.
[04:53] <zakame> so is life, work-in-progress :D
[04:53] <persia> :)
[04:55] <jussi01> hello all
[04:55] <persia> hi jussi01
[04:55] <jussi01> persia: could you take a look at http://paste.ubuntu-nl.org/25370/
[04:55] <leonel> motujava ??  that sounds  good ..
[04:56] <persia> leonel: It is good.  Warm and rich.  Sign up now, get it on the ground floor, and great things will happen :)
[04:56] <leonel> persia: where  is the motujava party ?
[04:56] <jussi01> persia: Im not a very good email writer...
[04:57] <persia> leonel: Ask the team leader: zakame
[04:57] <leonel> found it !
[04:57] <leonel> motu java growers ?
[04:57] <zakame> yep
[04:58] <leonel> what about   ubuntu-java ?
[04:58] <zakame> still reforming it though
[04:58] <leonel> is that another ?
[05:00] <persia> jussi01: In general, nice work.  There's a couple spelling issues, and I recommend avoiding things like "you need to {foo}" in favour of things like the policy for Ubuntu prevents my packaging because {foo} has not been done.
[05:01] <jussi01> persia: ok. would you mind making a few changes to the paste? (do you have time?)
[05:01] <persia> jussi01: Sure.  Do you want 1) comments, 2) minor edits, or 3) a rewrite?
[05:01] <leonel> zakame: what's to be done with  motujava ?
[05:02] <zakame> leonel: at the moment, merging java packages
[05:03] <StevenK> persia: Okay. "Don't"
[05:04] <StevenK> :-P
[05:04] <leonel> zakame: ok let's learn to merge   I have  dbmail pending to merge  but  I'm stuck  with  some dapper's  clamav  bugs
[05:04] <jussi01> persia: well any of the above is good, though a rewrite would be nice.... I'm just not a very good email composer...
[05:04] <persia> StevenK: Why not?  Upstream usually works with a direct download, but it's messy, and doesn't generaly work for all system users.
[05:05] <StevenK> persia: I'm just bitter because I dislike Java. :-)
[05:05] <persia> jussi01: Sure - that will take a little longer.  Please review it carefully, as my style is surely different than yours.
[05:05] <zakame> leonel: did you look at http://merges.ubuntu.com/universe.html and grab-merge.sh'd the package?
[05:06] <leonel> zakame:  yes
[05:06] <persia> StevenK: From what I understand, java packages should be safe to ignore for everyone else, so you can be safe.
[05:06] <jussi01> persia: sure, I will. Im on holidays so I have a fair bit of time, but I am AFK for periods so if i dont answer you know why.
[05:06] <leonel> zakame: but Let me finish first  with  clamav bugs  I have pending   to start  merging  dbmail and  java packages
[05:07] <zakame> leonel: ah, cool
[05:07] <persia> jussi01: No worries.  Are you around for a while now?  "a little longer" in this case is probably <15 minutes.
[05:07] <zakame> waah I'm out of HD space
[05:08] <jussi01> persia: Im going to grab some lunch, but yes, i will be around for the next hour or so.
[05:08] <leonel> zakame:  I really feel  a little bad  because It's been 1 week long to sort out the clamav bugs in dapper
[05:08] <zakame> leonel: why? what's been bugging clamav?
[05:09] <jmg> update
[05:09] <Amaranth> so it's not possible to snag a package from the NEW queue?
[05:09] <jmg> zakame: apt-get autoclean
[05:09] <zakame> jmg: yeah, doing that now
[05:10] <jmg> :)
[05:13] <leonel> zakame:  3 cve   which 2 have the fix in the  90.x version of clamav  and need to patch for  the 88.2  in dapper   and the 90.x  has changed  some things     and I need to figure out what's for those CVEs
[05:14] <zakame> waah, that's quite a lot
[05:14] <jmg> leonel: why cant you use the 90.x in dapper?
[05:15] <leonel> jmg:  I do but can't be uploaded  to  dapper-security   and not everyone has  backports enabled   and  there are some packages that would break with 0.90.3
[05:16] <jmg> leonel: that sucks
[05:16] <leonel> and it's an important package to keep updated with the latest version
[05:17] <leonel> and theres a  message from freshclam  that says  that the clamav  package  is  outdated  even if it's patched    and that  gives some confusion to endusers
[05:18] <jmg> yeah
[05:21] <leonel> well got to go
[05:22] <leonel> for now ...
[05:22] <leonel> apt-get remove leonel
[05:22] <leonel> good  night !
[05:22] <persia> jussi01: I'd probably send something like http://pastebin.ca/563393, but that itself would benefit from a spell check, and definitely needs real URLs :)
[05:23] <persia> jussi01: rather http://pastebin.ca/563395: "confirm" is not an ideal word there.
[05:26] <tonyyarusso> Does Gutsy sync _every_ package from Debian unstable, or would it be wise to request a specific one?
[05:26] <jussi01> persia: second url doesnt work. but the firs one looks quite nice :D
[05:26] <Hobbsee> tonyyarusso: everything that's not blacklisted, or has ubuntu changes
[05:26] <persia> jussi01: It's your IRC client.  Drop the ":"
[05:26] <tonyyarusso> Hobbsee: blacklisted?
[05:27] <tonyyarusso> (specifically shell-fm, just found it)
[05:27] <jussi01> persia: hehe... didnt see that
[05:27] <StevenK> tonyyarusso: There's a list of package which are never going to be sync'd. Such as the d-i kernels and so on
[05:27] <StevenK> packages, even
[05:28] <tonyyarusso> ah
[05:28] <persia> tonyyarusso: Also, Ubuntu only auto-syncs new packages from Debian main.  If you need something new from contrib or non-free, that's a manual request.
[05:30] <tonyyarusso> Hobbsee, persia: Those two statements seem to be in conflict with each other.
[05:30] <ajmitch> tonyyarusso: everything in debian main that's not blacklisted or has ubuntu changes
[05:30] <ajmitch> and providing that it's not past DebianImportFreeze
[05:31] <persia> tonyyarusso: OK.  Ubuntu syncs everything from Debian main, unless there it has been blacklisted or has Ubuntu changes, and anything already in Ubuntu from contrib and non-free unless there are Ubuntu changes.
[05:31] <Hobbsee> sorry, everything in debian main
[05:31] <persia> Plus what ajmitch said
[05:31] <tonyyarusso> okay, then I likely need to make a request for this.
[05:31] <ajmitch> tonyyarusso: new packages in debian still get checked to a degree before being imported into ubuntu
[05:31] <ajmitch> tonyyarusso: why?
[05:31] <ajmitch>   shell-fm | 0.2+svn20070605.r215-1 | http://apt-proxy gutsy/universe Sources
[05:31] <ajmitch>   shell-fm | 0.2+svn20070605.r215-1 | http://apt-proxy sid/main Sources
[05:32] <StevenK> Twitch. apt-proxy
[05:33] <jussi01> persia: what is the exactloaction for the dfsg?
[05:33] <StevenK> It's linked off http://www.debian.org/devel/
[05:33] <tonyyarusso> ajmitch: never mind then :)  Hadn't actually gotten to the checking gutsy step, but was assuming until proven wrong that it hadn't found its way there yet.
[05:33] <tonyyarusso> cool
[05:33] <persia> tonyyarusso: Generally, new packages are only in the current development release.  Once should check there first.
[05:34] <StevenK> persia =~ s/\(On\)ce/\1e/
[05:34] <tonyyarusso> persia: Well yeah, was getting there - was a passing thought so far ;)
[05:34] <crimsun> persia: once-overed. http://pastebin.ca/563406
[05:34] <persia> StevenK: s/ce/e/ is cleaner for that string :)
[05:35] <StevenK> persia: Meh. :-)
[05:36] <StevenK> jussi01: http://www.debian.org/social_contract
[05:36] <persia> jussi01: See crimsun's updates - it's even better :)
[05:36] <StevenK> jussi01: (For the DFSG)
[05:38] <jussi01> alright thank you all. Ill put it together and you can comment then :D
[05:47] <jussi01> persia: http://pastebin.ca/563425
[05:59] <persia> jussi01: Good links :)  My only two thoughts for changes would be 1) Consider "I would like to solicit" rather than "I am soliciting" in the first paragraph, and 2) prefixing the second paragraph with "Also, ", "In addition, ", or "Separately, ".  I think these are edits to my text rather than yours :)
[06:02] <jussi01> persia: http://pastebin.ca/563443
[06:05] <persia> jussi01: Looks fine to me.  Does it still match what you wanted to send, and are you set to follow up on responses?
[06:07] <jussi01> persia: it says exactly what i wanted, in words I couldnt have put together :D thanks! When I get a response, If I cant deal with it Ill know where to come ;)
[06:07] <persia> jussi01: Great.  Good luck.
[06:15] <jussi01> ok, lets see everyones investigative skills... someone find me the authors email address... http://genpo.sourceforge.net/ I cant find it anywhere....
[06:16] <jussi01> nm... found it on the ml... finally
[06:16] <persia> jussi01: It's always right after you give up :)
[06:17] <jussi01> lol, yeah
[06:17] <jussi01> although it doesnt give me the whole address grrr...
[06:17] <StevenK>   merronys at users.sourceforge.net
[06:17] <jussi01> StevenK: thank you... :D
[06:26] <jussi01> SENT!! :D
[07:29] <zakame> anyone working on azureus merge?
[07:31] <StevenK> zakame: There be dragons with that merge. Commonly called users.
[07:32] <zakame> StevenK: wahehehe
[07:32] <zakame> yo jsgotangco
[07:32] <zakame> checking LP bugs now, 16 uncon
[07:32] <man-di> yes, azurues is evil
[07:32] <man-di> I fight with it in debian
[07:33] <man-di> zakame: I feel your pain
[07:33] <zakame> wah, there's even a new-version wishlist
[07:33] <man-di> zakame: the debian maintainer of it is on vacation...
[07:34] <zakame> oh, shaun jackman
[07:34] <zakame> I remember him, I adopted robotour from him (now it has a couple of RCs related to 64-bit machines)
[07:35] <zakame> can't seem to squash it though
[07:36] <persia> man-di: If you have a bit of time, could you please take a look at the build logs for https://launchpad.net/ubuntu/+source/eclipse/3.2.2-1
[07:42] <minghua> did anybody get azureus working with GCC java?
[07:43] <minghua> I only heard sad stories, and all the conclusions seem to be "use Sun java and everything will be fine"
[07:43] <man-di> persia: yes, I'm already on that one
[07:43] <persia> man-di: Great.  Thanks.
[07:44] <man-di> hmmm
[07:51] <superm1> minghua, there is a package that is azureus-gij i believe
[07:52] <superm1> that uses GCC java
[07:52] <superm1> or azureus-gcj
[07:59] <minghua> superm1: Thanks.  I still don't quite understand though (but that's okay, I don't want to become a java packaging expert), as azureus-gcj's package description says "This package contains the natively compiled code for use by gij."
[07:59] <superm1> minghua, my understanding is gij byte compiles the java code
[07:59] <superm1> so its supposed to be a little faster
[07:59] <superm1> than purely interpreted java code
[07:59] <man-di> gcj can compile bytecode to native
[08:00] <man-di> minghua: if you have questions, ask me
[08:01] <superm1> man-di, so it really is a lot faster when gcj handles the compilation?
[08:01] <superm1> rather than using sun java to interpret it?
[08:01] <minghua> I see.  So besides "using Sun java" and "using GCC java", there is a third option of "using native compiled version"?
[08:02] <minghua> man-di: Oh, glad to see you here.  Not many MOTUs dare to touch azureus in Ubuntu, it seems.
[08:03] <man-di> minghua: same for DDs
[08:03] <man-di> minghua: I fight with debian maintainer of azurues for a long time to make it correct
[08:05] <man-di> superm1: its not faster then SUN, its faster then interpreted with gcj
[08:05] <man-di> superm1: the interpreter of gcj is *really* slow
[08:05] <man-di> superm1: we compile to native to get acceptable speed with a runtime that is in main
[08:05] <man-di> superm1: so far SUN JDK is not free
[08:05] <superm1> man-di, but then is there still an option to run with sun though?
[08:06] <superm1> or is that forfeited by doing this
[08:06] <man-di> superm1: sure
[08:06] <man-di> you can use whatever runtime you prefer
[08:06] <man-di> superm1: the native gcj libs are just additional
[08:06] <superm1> ah i've wondered how that worked with it
[08:07] <man-di> and only used when gcj is used as runtime
[08:07] <superm1> that's pretty neat then
[08:07] <man-di> and kaffe has some code that could use them hypothetically
[08:07] <man-di> superm1: think of it as native jars
[08:08] <man-di> I need to leave now, cu later
[08:08] <superm1> ok. thanks a lot man-di you really helped clear that up :)
[08:11] <minghua> man-di: so even if the azureus package is built with GCC java, the bytecode version can run on all VMs, either Sun java or e.g. kaffe?
[08:53] <dholbach> good morning
[08:53] <gnomefreak> good morning
[08:53] <dholbach> hey gnomefreak
[08:53] <RAOF> Good afternoon dholbach, gnomefreak
[08:53] <dholbach> hey RAOF
[08:53] <gnomefreak> hi RAOF
[08:55] <zakame> good day folks
[08:55] <gnomefreak> hi zakame
[09:23] <man-di> minghua: yes, it does
[09:23] <man-di> minghua: thats the cool thing about java bytecode being arch independant
[09:24] <man-di> minghua: and in fact GCJ was designed to be interoperable with SUN Java
[09:25] <minghua> man-di: thanks for the explanation
[09:26] <man-di> minghua: no problem, I help you and you help me some day
[09:59] <persia> Is matti lindell around?
[09:59] <crimsun> no, he's not.
[10:01] <persia> crimsun: Thanks (I guess)
[10:03] <jussi01> lol
[10:07] <crimsun> well, I can't magically make him appear
[10:07] <man-di> crimsun: did you lost your magical powers? damn
[10:07] <persia> crimsun: Even for a pony?
[10:07] <crimsun> never had them.  You need to see Hobbsee for that.
[10:07] <jussi01> hello Hobbsee
[10:07] <Hobbsee> hiya
[10:07] <RAOF> Yay!  Recent builds of gnash!
[10:14] <crimsun> well, now that we have GSt 0.10.13, this crossfading in RB should be interestin.g
[10:16] <zakame> gnashing of streams
[10:17] <RAOF> crimsun: s/interesting/works with wavpack files/?
[10:18] <RAOF> I refer of course to bug #119044
[10:18] <ubotu> Launchpad bug 119044 in rhythmbox "Crossfading engine never starts playing wavpack files" [Medium,Confirmed]  https://launchpad.net/bugs/119044
[10:19] <crimsun> it's not limited to wavpack IME
[10:19] <RAOF> wavpack was the only codec I tried that didn't work.
[10:20] <crimsun> doesn't work at all on my files
[10:20] <RAOF> I don't think I have a wma encoder to duplicate the original upstream bug.
[10:20] <crimsun> I do get a nice xkill or pkill exercise, however.
[10:20] <RAOF> Really?  It actually *hangs* RB for you?
[10:20] <crimsun> yes, massively.
[10:20] <RAOF> Isn't software wonderful.
[10:22] <RAOF> Well, it doesn't work, but it doesn't hang.  Huzzah for system differences.
[10:22] <crimsun> hangs with pulse removed from the equation, too
[11:06] <dholbach> wow - we have LOADS of bugs marked as 'upgrade'
[11:06] <dholbach> most of them should be easy to fix
[12:15] <man-di> bluekuja: ping
[12:15] <bluekuja> man-di, pong
[12:15] <bluekuja> :)
[12:15] <man-di> bluekuja: why did you reintroduced https://bugs.launchpad.net/ubuntu/+source/libcommons-dbcp-java/+bug/81876 ?
[12:15] <ubotu> Launchpad bug 81876 in libcommons-dbcp-java "Dependency on java2-runtime removed" [Undecided,Confirmed]
[12:15] <man-di> bluekuja: a sync of the package would have been enough to get everything fixed
[12:16] <man-di> bluekuja: that was why I uploaded -5 to Debian at all
[12:16] <bluekuja> man-di, it seems it wasnt removed in previous version
[12:16] <bluekuja> and nothing was marked in changelog
[12:16] <bluekuja> didnt see that bug
[12:16] <man-di> bluekuja: it MAY not be removed
[12:17] <man-di> bluekuja: it was not in changelog because it was no Debian bug
[12:17] <man-di> bluekuja: only Ubuntu
[12:17] <bluekuja> man-di, yeah, badly I didnt see that bug in LP
[12:19] <bluekuja> man-di, we will sync next release then
[01:06] <icf7> Somebody in here who'd like to review (and maybe advocate) http://revu.tauware.de/details.py?upid=5467 (Sunflow rendering system, http://sunflow.sf.net ) ?
[01:17] <doko> bluekuja: about the various scim merges; please go ahead with the merges; if you do have questions, ask on this channel, or use REVU to get feedback
[01:17] <bluekuja> doko: great, thanks :)
[01:27] <DktrKranz> could you please clarify me a bit about bug #119936?
[01:27] <ubotu> Launchpad bug 119936 in aptoncd "Please fakesync aptoncd 0.1-1" [Wishlist,Needs info]  https://launchpad.net/bugs/119936
[01:42] <pochu> DktrKranz: persia means if it's a Fakesync, it should just be the debian package with a changelog entry saying "Fakesync", but no other changes.
[01:45] <DktrKranz> this has different upstream tarball, it's unclear to me how to handle a fakesync that way
[01:46] <shawarma> Um... That's what fakesync means, afaik.
[01:46] <pochu> DktrKranz: with a different tarball you mean different content, or just different md5sum?
[01:46] <DktrKranz> different md5sums
[01:46] <DktrKranz> IIRC
[01:46] <pochu> If the latter, use the ubuntu one, but use the debian/ dir.
[01:47] <pochu> And add a changelog entry saying it's fakesync, and that it can be synced with the next upstream release :)
[01:47] <DktrKranz> it has no ubuntu changes to be kept
[01:47] <shawarma> A sync is just a copy of the debian package with no changes at all. A fakesync is the same only we use our own orig.tar.gz (because they differ for some reason), but Debian's diff.gz. In that case we add an entry to the changelog saying that it was fakesync'ed.
[01:48] <DktrKranz> so a it should be a fakesync
[01:48] <DktrKranz> I'm curious to know how this can be managed during upload
[01:49] <DktrKranz> as a normal debdiff?
[01:49] <shawarma> Uploads are never actually done with debdiffs.
[01:51] <shawarma> A fakesync (if the tarballs are identical, but with different md5sums (due to timestamps or whatever)) can be done by fetching the source of the debian package, putting our orig.tar.gz where the debian one was, add an entry to the changelog, debuild -S, upload.
[01:52] <DktrKranz> and what if the two packages are not the same (md5 and content)?
[01:53] <shawarma> DktrKranz: that's difficult to say anything general about, really.
[01:53] <shawarma> DktrKranz: It depends on how the differ.
[01:53] <shawarma> they*
[01:54] <DktrKranz> could it be case of a merge?
[01:54] <DktrKranz> anyway, I'll check orig.tar.gzs to see if they are identical in content
[01:55] <DktrKranz> if so, I will ask for a fakesync following your advices
[01:55] <DktrKranz> thanks for now :)
[02:04] <shawarma> -ENOCOFFEE
[02:06] <xxxxx1> morning people
[02:25] <Pumpernickel> Wow... someone put this guy out of his misery.
[02:26] <AndyP> !ops
[02:26] <ubotu> Help! Hobbsee, Riddell, sladen, or fbond
[02:28] <xxxxx1> wow
[02:28] <elkbuntu> imbrandon?
[02:29] <imbrandon> my aliases are borked
[02:29] <imbrandon>  /kb<EMAIL_ADDRESS>[02:29] <imbrandon> err
[02:29] <elkbuntu> shit... he leaves too quick
[02:30] <Fujitsu> elkbuntu: Hahah.
[02:31] <xxxxx1> \o/
[02:31] <fernando> elkbuntu: congrats
[02:31] <StevenK> elkbuntu: Thanks!
[02:31] <elkbuntu> and makes things scroll so i cant copy the damn hostmask
[02:31] <Pumpernickel> ...and there was much rejoicing.
[02:31] <Fujitsu> ... and Pumpernickel.
[02:31] <elkbuntu> not even a registered nick
[02:31] <imbrandon> thanks elk /me goes to fix his aliases
[02:32] <elkbuntu> i'll hang on to the ops for a bit, he might find a new hostmask
[02:32] <imbrandon> i doubt it was intentional
[02:32] <imbrandon> but okies
[02:33] <imbrandon> probably a bitchx client on the uni computer and he's not even there
[02:33] <imbrandon> thats trying to constantly reconnect
[02:33] <imbrandon> heya BearPerson
[02:33] <BearPerson> heya
[02:33] <elkbuntu> BearPerson, we fixed it, thanks for coming though
[02:34] <imbrandon> i was just a tad slow, aliases wasent setup apparently
[02:34] <imbrandon> :)
[02:34] <BearPerson> anytime
[02:35] <zul> hey imbrandon
[02:36] <imbrandon> heya zul
[02:39] <DarkSun88> Hi all
[03:14] <MehdiHassanpour> hi, I need some help t o create a font .deb package... any guide/howto ?
[03:16] <DarkSun88> MehdiHassanpour: Try to read this page: http://www.debian.org/devel/index.en.html
[03:17] <Hobbsee> MehdiHassanpour: follow the packaging guide, usually works
[03:18] <Q-FUNK> MehdiHassanpour: the general guidelines abotu creating packages apply.  for fonts, the main issue is defoma support and installing the fonts in the right directory.
[03:18] <MehdiHassanpour> Hobbsee, should I write a Makefile to copy ttf files in appropriate folder ?
[03:19] <Hobbsee> i have no idea, i dont touch fonts.  probably for good reason
[03:19] <Q-FUNK> MehdiHassanpour: are these just TTF font files and a copyright file?
[03:19] <MehdiHassanpour> Q-FUNK, yes, they are TTF files
[03:20] <Q-FUNK> MehdiHassanpour: ok.  does the upstream archive include proper copyrights and does thelicense meet free software guidelines?
[03:21] <MehdiHassanpour> Q-FUNK, I want to create it for our company local use.
[03:22] <MehdiHassanpour> Q-FUNK, we've designed them for our local use and will not be published for public use
[03:22] <Q-FUNK> MehdiHassanpour: ok.  if it's not for uploading to MOTU, then all you need to worry about is installng fonts in the right directory.  using cdbs with the debhelper rule, you just need to fill debian/install content.
[03:24] <Q-FUNK> MehdiHassanpour: so, as Hobbsee said, standard packaging guidelines apply for making a good package.
[03:24] <MehdiHassanpour> Q-FUNK, ok ty. what about the defoma support ?
[03:26] <Q-FUNK> MehdiHassanpour: you generally want fonts to successfully register with defoma and pango.
[03:32] <jussi01> hello all
[03:58] <persia> bluekuja: When requesting syncs, please list the Ubuntu changes from the current version, and indicate why they no longer apply to the new Debian version.
[04:04] <siretart> persia: hi there!
[04:04] <persia> siretart: Good day.
[04:04] <siretart> persia: btw, did Hobbsee tell you that I created an account for you on tiber?
[04:05] <persia> siretart: No.  Was she so assigned?
[04:05] <persia> siretart: Also, thanks.  Is there a guide on using it?
[04:05] <siretart> persia: she said that you were interested in helping out with revu by resyncing keyring and rechecking the incoming queue
[04:06] <siretart> persia: ssh to 'tiber.tauware.de', read /etc/motd, and check ~ftp/incoming
[04:06] <persia> siretart: Those are both things I'd certainly be willing to do - I often tell people to wait when they have that type of request.
[04:07] <siretart> persia: I'd suggest that you look a bit around and see what you can do there. If you need additional permissions, tell me what you need
[04:08] <persia> siretart: Thanks.  I can see how to resync, and I'm guessing I can just rm to clean incoming, right?
[04:08] <siretart> persia: right. or mv from ~ftp/incoming/rejected to ~ftp/incoming
[04:08] <siretart> the process script is run every 5 minutes from revu1's crontab
[04:08] <persia> siretart: mv from rejected?  When is that good?
[04:08] <siretart> when the uploader wasn't in the keyring at the time the process script ra
[04:08] <siretart> n
[04:09] <svschwart1> hello :) I've installed Gusty Tribe1, wanted to try fresh KVM, used this howto https://help.ubuntu.com/community/KVM
[04:09] <persia> siretart: Ah.  That makes sense.  Thanks for the explanation.
[04:10] <Hobbsee> siretart: no.  i suck.
[04:10] <svschwart1> but when I want to start my VM it says
[04:10] <svschwart1> user@amd1-desktop:~$ kvm -no-acpi -m 384 -cdrom /dev/cdrom windows.img
[04:10] <svschwart1> kvm_create_vm: Invalid argument
[04:10] <svschwart1> Could not create KVM context
[04:10] <Hobbsee> persia: siretart created you an account on tiber.
[04:10] <Hobbsee> siretart: consider it done :P
[04:10] <xxxxx1> svschwart1: try #ubuntu
[04:10] <persia> Hobbsee: Thanks for telling me :)
[04:10] <Hobbsee> :)
[04:10] <xxxxx1> hello siretart :)
[04:12] <siretart> Hobbsee: :)
[04:12] <siretart> xxxxx1: *wave*
[04:15] <Hobbsee> :)
[04:23] <persia> siretart: After a little exploration and testing, I appear to be able to assist with minor administrative tasks.  Thanks again.
[04:23] <RainCT> Hi
[04:44] <tobiasschulz> can someone check and perhaps advocate http://revu.tauware.de/details.py?upid=5503 ?
[04:44] <persia> tobiasschulz: There's a bunch of outstanding lintian and linda errors.  Are you having difficulties with these?
[04:46] <tobiasschulz> what does litian exactly?
[04:47] <man-di> tobiasschulz: checks for common mistakes in packages
[04:47] <geser> lintian and linda check if your package conforms to the Debian policy
[04:47] <man-di> tobiasschulz: another tool to install is linda, does basically the same
[04:47] <tobiasschulz> ans what are tehre errors?
[04:47] <persia> tobiasschulz: lintian and linda are package checkers.  They both check either source or binary packages, and indicate issues that might be found.  Try `lintian -iIv *.changes` or `linda -v -f long -t E,I,W,X *.changes` to get some information on things that need work.
[04:47] <man-di> tobiasschulz: note that both show slightly different issues
[04:48] <man-di> tobiasschulz: having both installed at debuild-time you will get their ouptut automatically at the end of your build
[04:48] <tobiasschulz> ok
[04:48] <persia> tobiasschulz: You can see some of the errors listed from the lintian and linda links on the URL you posted, but you'll likely get better information from running it locally.
[04:49] <persia> man-di: Not quite - default debuild behaviour in current Ubuntu doesn't call linda.
[04:49] <man-di> persia: really? oh, in debian its on by default
[04:50] <persia> man-di: That's my experience.  I haven't hunted the relevant patches.
[04:51] <persia> man-di: Also, even if it were enabled, it doesn't have all the flags I listed above, which are encouraged for REVU, as the packages should be perfect, not just compliant :)
[04:52] <man-di> persia: these flags are all default on debian afaik
[04:52] <man-di> I thought ubuntu migth do the same, I was wrong...
[04:52] <persia> man-di: All of them?  Hmmm...
[04:53] <man-di> no, not -i for lintian
[04:53] <man-di> and not -f long for linda
[04:53] <man-di> but the rest
[04:54] <bluekuja> heya persia
[04:54] <persia> bluekuja: Hey.
[04:54] <bluekuja> persia: yeah, gonna add them now
[04:55] <persia> bluekuja: Great.  Thanks.  Please update the descriptions, rather than adding a comment.
[04:55] <bluekuja> ok
[04:56] <geser> Hi bluekuja
[04:56] <bluekuja> heya geser
[05:07] <bluekuja> persia: I need to leave for a while, when I'm back gonna change that desc
[05:07] <bluekuja> ;)
[05:07] <persia> bluekuja: OK.  I'll unsubscribe for a while then.  Please resub when you're done.  Thanks again.
[05:07] <bluekuja> persia: ok, sounds great! ;)
[05:07] <bluekuja> cya later
[05:15] <RainCT> nixternal: hi. is plucker this? plkr.org :P
[05:15] <persia> RainCT: Yes.
[05:18] <persia> RainCT: Do you have a few free minutes?
[05:19] <RainCT> persia: well.. yes :)
[05:21] <persia> RainCT: Would you mind cleaning up the icon path for bug 93894, or am I misremembering that you use KDE?
[05:21] <ubotu> Launchpad bug 93894 in dvdrip "icon for dvdrip missing in KDE" [Undecided,Confirmed]  https://launchpad.net/bugs/93894
[05:22] <RainCT> persia: I use GNOME; don't like most KDE application, except for a few
[05:23] <persia> RainCT: My apologies then :)  I'll try to remember correctly in the future.
[05:23] <shawarma> If anyone (preferably someone with perl packaging skills) is bored, there's a bunch of stuff on REVU that needs an ACK. (Look for<EMAIL_ADDRESS>[05:24] <persia> shawarma: Is there a specific package that you'd like reviewed?
[05:26] <shawarma> persia: Well.. the system-config-printer would be nice to get off my todo list.
[05:26] <shawarma> persia: The order of the rest of them (the perl ones) does not matter.
[05:27] <persia> shawarma: I'll look at that first then.  Also, this'll be my first peer review: do I ack, and you archive upload, or is there a different process?
[05:27] <RainCT> persia: do you know on what category plucker would go?
[05:28] <shawarma> persia: You ack, I upload, I archive.
[05:28] <persia> shawarma: That's easiest for me :)  Thanks for the explanation.
[05:28] <persia> RainCT: No strong idea really.  Utility maybe as a main?
[05:29] <shawarma> RainCT: plucker is already in the archive?
[05:29] <shawarma> !plucker
[05:29] <ubotu> Sorry, I don't know anything about plucker - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:30] <shawarma> !pkg plucker
[05:30] <ubotu> Sorry, I don't know anything about pkg plucker - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:30] <shawarma> bah.
[05:30] <persia> shawarma: I'm not seeing system-config-printer.  Do you mean system-config-samba?
[05:30] <RainCT> persia: okay, that's what I think too, thanks
[05:30] <shawarma> persia: Yes.  In component universe, is optional. Version 1.8-20ubuntu1 (feisty), package size 455 kB, installed size 1304 kB
[05:30] <persia> shawarma: OK.  Just like to confirm these things :)
[05:30] <shawarma> persia: thanks. :)
[05:31] <shawarma> RainCT: ^^ Is that the same plucker?
[05:31] <RainCT> shawarma: yes
[05:31] <shawarma> RainCT: It's currently in universe/otherosfs.
[05:31] <persia> shawarma: Category section for .desktop file for plucker-desktop (the GUI interface).
[05:31] <shawarma> Oh!
[05:35] <persia> shawarma: Sorry, but I'm not comfortable ACKing an rpm conversion with neither of debian/README.Debian-source nor debian/rules: get-orig-source: :)
[05:35] <persia> s/:)/:(/
[05:35] <statik> anyone feel like doing a review of a simple python module (my first package?) I think I've addressed all the comments that were made so far in the version that I uploaded yesterday
[05:35] <statik> python-coverage, http://revu.tauware.de/details.py?upid=5490
[05:37] <siretart> TheMuso: do you have experience with using dogtail?
[05:38] <siretart> persia: you are a perl guy?
[05:39] <persia> siretart: I've written lots of perl code, and I've explored a fair amount of perl packaging, but I wouldn't necessarily categorise myself as a "perl guy".
[05:39] <siretart> persia: I'm looking for a framework for testing GUIs, preferably one in perl. can you recommend something?
[05:40] <persia> siretart: That's much more perl-y than I get.  Sorry :(
[05:41] <shawarma> persia: Fair enough.
[05:45] <persia> shawarma: For the perl packages, you don't seem to claim copyright on the packaging ("The Debian packaging is copyright $year $packager, and is licensed under $license, see above", at least for the case where the packaging carries an identical license).
[05:47] <shawarma> persia: That may very well be true..
[05:48] <persia> Is it uncopyrighted?  I think that requires explicit disclaimer is most common jurisdictions (and certainly under WTO practices).
[05:52] <persia> shawarma: Other than the copyright notes, all the perl stuff looks fairly standard and clean.  I've not actually tested the build & run the packaging checks yet, as copyright is enough to block me.
[05:56] <shawarma> persia: Fair enough. system-config-samba updated, perl packages on their way.
[05:57] <persia> shawarma: Thanks.  I'll take another look.
[05:57] <RainCT> how can I uuencode a file? uuencode file.png isn't doing anything :S
[05:58] <shawarma> uuencode file.png file.png
[05:58] <shawarma> no shit :)
[05:58] <shawarma> The first file.png tell uuencode what the name of it should be in the uuencoded stuff, while the second arg tells it where to get the data.
[06:00] <RainCT> thanks. I think I tried that before, strange xD
[06:00] <geser> doesn't this destroy file.png?
[06:00] <shawarma> geser: uu*en*ode?
[06:00] <persia> geser: No.  The name is just a name, and the .uu is added automatically.  It's counterintuitive, but it works.
[06:00] <LucidFox> is it wise to add a photo to my public key?
[06:01] <shawarma> persia: The perl updated  perl packages should be there in a minute or so. thanks a bunch for reviewing them.
[06:01] <shawarma> persia: I'm running off for a few hours, but I'll stay online, so just shout if anything else is wrong. Thanks!
[06:01] <LucidFox> Also, what will happen if I edit the key (eg. add a new UID) after someone signs it? Will they have to re-sign it?
[06:02] <persia> LucidFox: Not everything supports it, but if you do, people will see the picture when they get the key.  It's the same question as "it is best to carry a photo ID, or a non-photo ID", except that in this case, non-photo is more common.
[06:02] <persia> shawarma: I'll send you and email with the results of my checks.  Everything is refreshed?
[06:02] <shawarma> persia: Looks like it.
[06:02] <shawarma> persia: Thanks!
[06:03] <persia> shawarma: Happy to help.  I like new packages.
[06:06] <LucidFox> Also, after I upload the updated key to the keyserver, will I have to update it on Launchpad as well?
[06:06] <RainCT> eh.. does 1.8-21ubuntu1 mean that 21 .deb's were created for the same version in Debian? :S
[06:06] <LucidFox> RainCT> yes
[06:08] <persia> RainCT: Upstream has been working on 1.9 for a long time, and hasn't updated 1.8, although a lot of bugfix patches have been extracted over the past few years.  Packages with active upstreams rarely reach that.
[06:11] <RainCT> ok thanks
[06:13] <persia> RainCT: Why the sudden interest in plucker?
[06:14] <RainCT> persia: I'm not interested in it, just trying to fix the bug :p
[06:14] <RainCT> can you check the debdiff please? bug 118361
[06:14] <ubotu> Launchpad bug 118361 in plucker "plucker-desktop: Missing menu entry" [Low,In progress]  https://launchpad.net/bugs/118361
[06:15] <RainCT> (new debdiff - copy-paste is bad lol)
[06:16] <persia> RainCT: Ah.  I wasn't sure that we should fix that, but looking at the bug, I see you're already coordinating with the right person :)  Preparing to redownload the debdiff now...
[06:17] <bmm> Any MOTU: after fixing some details, ccbuild http://revu.tauware.de/details.py?upid=5511 is looking for advocates for the newest version.
[06:21] <RainCT> persia: (where `cp debian/plucker.desktop debian/usr/share/applications' it's `debian/plucker.desktop' :p)
[06:21] <RainCT> * debian/plucker-desktop.desktop
[06:21] <persia> RainCT: Given that the package already uses dh_install, please use that for the .desktop and icon installation.  Also, the .desktop won't actually work, as plucker-desktop has been recently dropped: you want to have that install in the plucker-desktop binary package, which doesn't currently exist.
[06:23] <persia> RainCT: Check with nixternal, but I suspect providing the .desktop, icons, and documenting the install locations would be easier to merge (unless you can get a pre-release package for 1.9.0, in which case patching against that might be good).
[06:27] <RainCT> persia: ok, I've uploaded everything and will wait to see what nixternals says. Thanks
[06:28] <RainCT> off-topic: someone here that can help me with a Python+Qt problem?
[06:28] <persia> RainCT: Thanks a lot for chasing the menus - it makes the apps a lot more accessible (although I'm still hoping https://blueprints.launchpad.net/rosetta/+spec/rosetta-desktopfile-ui happens soon).
[06:31] <RainCT> persia: how will that work?
[06:35] <persia> RainCT: Nobody knows yet (which is a large part of why it doesn't exist).  The tricky part is figuring out how to reinsert the data into the packages safely, or alternately, how to provide support packages that would actually work (and not be *too* large on user systems).  If you have a good idea how to do that safely, writing it up would be great.
[06:37] <RainCT> persia: I don't have, that's why I'm asking :p
[06:38] <persia> RainCT: For now, best practice has just been to translate into as many languages as one can, and send to Debian and upstream, hoping to interface with upstream translation, but it's still not ideal.
[06:40] <RainCT> persia: just an idea but perhaps M-o-M could be expanded to update the .desktop files inserting the translations when merging and syncing...
[06:41] <LucidFox> What should be done if the upstream version includes a debian/ subdir?
[06:42] <persia> RainCT: Doesn't even need MoM: if Rosetta could export the data, and MOTUs were encouraged to merge on some schedule, we'd have a manual process: the difficulty there is coordinating with upstream translations for packages where there is already a translated .desktop file, and passing the patches appropriately so as not to annoy people.
[06:43] <xxxxx1> LucidFox: check topic 6.7.8 in developers-reference
[06:43] <persia> LucidFox: Request upstream to remove it.  While waiting, if you can use it as a basis for your packaging, do so (this requires that no files in debian/ must be deleted - they may be converted to empty files).  If you cannot, repacking may be done, but it is not preferred.
[06:44] <RainCT> persia: uhm.. Launchpad could store the last entry from Debian's .desktop file for each translation that is changed on LP and then if it hasn't changed apply Ubuntu's one
[06:44] <LucidFox> xxxxx1> what is developers-reference?
[06:45] <xxxxx1> LucidFox: http://www.debian.org/doc/developers-reference/
[06:45] <LucidFox> thanks
[06:45] <persia> RainCT: When would it be applied?  Manually or automatically?
[06:46] <RainCT> persia: well, those who adds the translations, whatever it's M-o-M or a MOTU
[06:49] <persia> RainCT: Maybe.  There's a lot of manual processes involved, and it might be annoying to have a .desktop file in more languages that the actual application, but it might work.  Do you want to draft up something describing all the moving parts?  I'd be happy to glance at it, and it can be submitted for review by those who might work on an implementation.
[06:49] <bluekuja> persia: done
[06:49] <bluekuja> persia: descriptions changed, should be ok now
[06:49] <persia> bluekuja: Great.  If someone else doesn't first, I'll hit them when I next review the queue.  Thanks for that.
[06:50] <bluekuja> persia: great! :) thanks to you :)
[06:50] <bmm> persia: I've made the changes you commented on while advocating the package. Do I need your new advocation for the new update? (ccbuild http://revu.tauware.de/details.py?upid=5511 )
[06:50] <persia> bmm: Yes, as REVU can't tell what changed.  I'll take a look in a bit.  Do you already have someone else as well?
[06:51] <RainCT> persia: well, maybe later
[06:51] <bmm> persia: no, but then I know I should call for the first advocate again :-) Thanks!
[06:51] <persia> RainCT: Welcome to the club :)
[06:53] <persia> bmm: Updated.  I'm not sure you needed the upload, but it doesn't hurt :)
[06:54] <persia> bmm: Just a note - it's a good idea to use dch when editing the changelog.
[06:55] <bmm> persia: thanks, but how did you see that I didn't? Oh, wait the date didn't change, right?
[06:58] <ScottK-laptop> persia: Would you look at http://revu.tauware.de/details.py?upid=5505.  I think it's pretty close, but I don't know enough about the desktop stuff to check that.
[07:00] <persia> ScottK: I was just looking at that earlier, and am composing a mail to the submitter that I didn't know enough python packaging to advocate :)  I'll look again, for the desktop stuff.
[07:01] <persia> ScottK: It's not compliant, but not any more so than much of what we have, and it will work (and be translated - hurrah!).
[07:02] <persia> ScottK: I'll put a note up with suggested changes.
[07:19] <LucidFox> why aren't revu packages sorted by date of upload?
[07:20] <Hobbsee> for an unknown reason
[07:21] <Hobbsee> i think they are, but they're sorted by number of ack's too
[07:21] <LucidFox> all right, here we go - uploaded psi 0.11 RC1
[07:21] <LucidFox> it's my first package, so I probably made a lot of errors, and comments are welcome
[07:22] <bluekuja> LucidFox, provide the link
[07:22] <LucidFox> http://revu.tauware.de/details.py?upid=5512
[07:26] <persia> Hey Mez.
[07:27] <icf7> LucidFox: What are that certificates you are adding? Why aren't they in the original source?
[07:29] <LucidFox> you mean qsa?
[07:30] <icf7> yes, in this directory is a file rootcerts.pem
[07:30] <LucidFox> QSA is a Qt cryptography library
[07:31] <LucidFox> Psi 0.11 uses QSA2, which is not currently in Ubuntu and the Debian version conflicts with QSA1; however, the Psi configure script allows for a bundled QSA
[07:31] <icf7> LucidFox: ah, I see, your patch is *big* and there is no original .tar.gz
[07:31] <LucidFox> so I added its source
[07:31] <LucidFox> dput didn't upload the original tar.gz
[07:32] <xxxxx1> LucidFox: did you check existing psi source as start?
[07:32] <LucidFox> it distributes the source as tar.bz2
[07:32] <LucidFox> so I did bunzip2, then gzip
[07:32] <LucidFox> maybe this is the problem?
[07:32] <icf7> LucidFox: no, afaik this is the right way
[07:33] <icf7> LucidFox: But you didn't rename the file to $package_$version.orig.tar.gz
[07:33] <LucidFox> I did
[07:33] <icf7> LucidFox: Mmm, then it's an upload problem ... http://revu.tauware.de/revu1-incoming/psi-0706131310/linda
[07:33] <LucidFox> otherwise dpkg-buildpackage would refuse to work at all
[07:34] <persia> LucidFox: You probably want to review https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball for hints on how to make it work properly.
[07:34] <LucidFox> the file is there in the directory - was dput supposed to upload it?
[07:35] <persia> LucidFox: dput uploads it iff you generated Source.changes with -S -sa
[07:35] <LucidFox> ahhhhhhhhh
[07:36] <LucidFox> I forgot -sa
[07:37] <LucidFox> okay, reuploading it
[07:37] <persia> LucidFox: That would do it.  Please upload again.
[07:37] <icf7> Could someone check this package? http://revu.tauware.de/details.py?upid=5467 (Sunflow rendering system)
[07:37] <LucidFox> reuploaded
[07:38] <LucidFox> oddly enough, the SVN tree for psi does include a bundled qsa - only the release tarballs don't
[07:39] <icf7> LucidFox: There's a small warning from linitan ... http://revu.tauware.de/revu1-incoming/psi-0706131330/lintian
[07:39] <LucidFox> okay, I will comment out the compat level in rules then
[07:42] <icf7> The diff is still incredibly big (contains everything). I wonder why ...
[07:43] <LucidFox> it doesn't contain everything - it contains the bundled QSA source tree
[07:43] <LucidFox> because it isn't provided with the original tarball, it's only in SVN
[07:44] <persia> LucidFox: Do you have a bug open for the upgrade?
[07:44] <LucidFox> in Launchpad?
[07:46] <LucidFox> if yes, then I don't - should I have opened it first?
[07:48] <persia> LucidFox: Yes.  When making significant changes to a package in the archive, you want to have an LP bug listed as "In Progress" and assigned to you, so that others know you're touching it (and may avoid colliding with you, or otherwise contact you).  In this specific case, please also upload a diff -urN of the debian/ directories for the current archive package and the new package to the bug.
[07:48] <LucidFox> Ok.
[07:49] <persia> (the reason for this is that standard REVU requires 100% lintian and linda compliance, etc., but new upstreams only require packaging that is as clean as it was before, based on the principle of minimal diffs with Debian)
[07:50] <LucidFox> Thanks, I'll do it in a few hours. I must go now.
[07:59] <persia> icf7: You've credited me twice :)  See https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/DebianCopyright about your copyright.  Don't use a filetype extension for the icon in the .desktop file.  Did you already try running the lintian and linda tests on your binaries?
[08:00] <icf7> persia: Thank you, the linitan warnings consist only of gutsy and NMU, am I doing something wrong here?
[08:01] <pochu> icf7: run it against the binaries too.
[08:01] <persia> icf7: Those are the warnings against the source.  Did you run against the binaries?
[08:03] <icf7> pochu, persia: Ah, ok, didn't know there was a difference. I'll do that
[08:09] <bluekuja> persia: if the remaining ubuntu changes are a fakesync for an NMU, shoul them be dropped?
[08:09] <bluekuja> *should
[08:10] <bluekuja> persia: or for version change
[08:10] <bluekuja> caused by a NMU too
[08:10] <persia> bluekuja: Just to make sure I understand: the package you're looking now only has changes in debian/changelog (and maybe XSBC-Original-Maintainer), right?
[08:11] <bluekuja> persia: yeah
[08:11] <bluekuja> with a different versioning
[08:11] <persia> bluekuja: And the orig.tar.gz's differ, but are for the same upstream version?
[08:11] <bluekuja> persia: yup
[08:12] <bluekuja> persia: I see here that previous mergers left it as remaining change
[08:12] <bluekuja> for 2 upstream versions
[08:12] <bluekuja> I think it's ok to leave it then
[08:13] <persia> bluekuja: Which package?  If there have been two upstreams since the fakesync, I don't believe that the orig.tar.gz's differ.
[08:13] <bluekuja> persia: one of them is carpaltunnel
[08:14] <bluekuja> it has been synced from debian unstable
[08:14] <bluekuja> and version changed for NMU
[08:14] <bluekuja> in edgy
[08:15] <persia> bluekuja: Ubuntu and Debian have the same orig.tar.gz.  carpaltunnel may sync.
[08:16] <bluekuja> persia, ok
[08:16] <bluekuja> persia: what about syslog-summary?
[08:16] <bluekuja> fakesync on there
[08:18] <bluekuja> persia: tarballs seems to differ
[08:19] <persia> bluekuja: Nevermind.  Don't do anything to carpaltunnel - there's no change: 0.0.9-0.1 was fakesync's in edgy, and hasn't updated in Debian since.
[08:19] <bluekuja> persia: ok then, can you take a fast look to syslog-summary?
[08:19] <bluekuja> tarballs differ
[08:20] <bluekuja> fakesynced in egdy
[08:22] <persia> bluekuja: Don't do anything to syslog-summary - there's no change: 1.12-0.1 was fakesync'd in edgy, and hasn't updated in Debian since.
[08:22] <bluekuja> ok, there are 3 packages with this behaviour
[08:22] <bluekuja> I'll leave them
[08:23] <icf7> lintian advises to add to postrm the line "if [ -x /usr/bin/update-menus ]  ; then update-menus ; fi". Why "update-menus" instead of "/usr/bin/update-menus" the second time?
[08:24] <persia> bluekuja: Basically, there's a policy bug in Ubuntu versioning that breaks with Debian native NMUs.  When you see a version number like 0.0.9-0.1, check the changelog - it's probably already there.
[08:24] <bluekuja> ok
[08:24] <bluekuja> thanks for the hint
[08:25] <persia> icf7: Because /usr/bin should be in the path, but -x requires the full path to verify the file is there.
[08:26] <icf7> persia: Thank you
[08:26] <persia> bluekuja: Also, in both those cases, the orig.tar.gz files didn't differ.  You can easily check by comparing the md5sums in the .dsc files, if you don't want to download.
[08:26] <bluekuja> persia, ok, It looked different here in local, that's why I asked
[08:26] <bluekuja> strange thing
[08:27] <persia> bluekuja: (that's because in both those cases, there is no orig.tar.gz, just tar.gz - they are native) :)
[08:27] <bluekuja> yeah, that's it
[08:28] <bluekuja> persia: thanks! ;) I've added something more to queue
[08:34] <soc> hi
[08:34] <soc> is there a way to speed up "sudo pbuilder create"
[08:34] <soc> since an ubuntu update broke checkinstall i#m trying to set up pbuilder, but it looks like that this command downloads packages from the server which are already available on my computer
[08:35] <soc> seems to be quite unnecessary
[08:35] <soc> pbuilder takes ages ..
[08:35] <persia> soc: If you want faster, and you're willing to install things locally, consider debuild.
[08:37] <soc> mh ok
[08:38] <so1> checkinstall worked quite well until some update broke it
[08:39] <so1> is there a tutorial for debuild?
[08:42] <so1> someone?
[08:49] <icf7> so1: Not quite a tutorial, but there's man debuild
[08:50] <so1> mh ok+
[08:51] <so1> man debuild
[08:51] <so1> No manual entry for debuild
[08:51] <so1> nice :-)
[08:51] <bluekuja> so1: ?
[08:51] <jrib> man debuild  works here
[08:51] <bluekuja> same
[08:52] <bluekuja> so1, man 1 debuild
[08:52] <so1> no ...
[08:52] <AndyP> installing debuild might be the first thing to check :)
[08:52] <bluekuja> lol
[08:52] <so1> there is no such package ,,,
[08:52] <bluekuja> AndyP, nice hint :P
[08:52] <jrib> so1: you have devscripts?
[08:52] <man-di> so1: the package is called devscripts
[08:53] <so1> no
[08:53] <so1> ok, i'm installing it
[08:53] <so1> so what are the requirement for debuild?
[08:53] <so1> i want to turn a source-package into a deb ...
[08:54] <so1> ok
[08:54] <icf7> so1: Your package manager will normally install all dependencies needed to run debuild. Other than that, I can't imagine any requirements
[08:54] <man-di> so1: unpackage the source package with dpkg-source -x ....dsc, cd into the resulting dir, debuild
[08:55] <so1> man debuild says it runs dpkg-buildpackage ... wow that helps :-)
[08:55] <so1> so where do i get the dsc-file?
[08:55] <man-di> so1: oh, and apt-get build-dep packagename
[08:55] <icf7> I updated the Sunflow package, reviews are welcome: http://revu.tauware.de/details.py?upid=5514
[08:55] <man-di> so1: its part of the source packages
[08:55] <so1> i want to provide a deb for gimp which is not in the repositories
[08:56] <man-di> apt-get source packagename downloads everything from the repos
[08:56] <icf7> so1: gimp itself?
[08:56] <so1> yes
[08:56] <man-di> so1: why do you wanna rebuild gimp?
[08:56] <so1> i don't want to rebuild a package from the repos, i want to build a new one "from scratch"
[08:57] <so1> i don't want to rebuild it
[08:57] <so1> because gimp 2.3.18 is not available in the repos
[08:57] <so1> if it would be in the repos i wouldn't have to build a package on my own
[08:57] <man-di> so1: so you want to update an existing package
[08:58] <so1> wouldn't say that ... i install gimp 2.3 into its own namespace
[08:58] <icf7> so1: As man-di said:  apt-get source gimp  will get what you want, but chances are someone has already updated it, though not in Ubuntu 7.04
[08:58] <so1> so it doesn't overwrite gimp 2.2
[08:58] <so1> it's not in gutsy
[08:59] <so1> so apt-get source gimp, then replacing the source with that from gimp 2.3.18, modifying the dsc and hoping it builds?
[08:59] <man-di> so1: debian experimental has 2.3.16
[08:59] <azeem> so does gutsy
[08:59] <man-di> so1: update to 2.3.18 from there should be much easier
[08:59] <so1> yes
[08:59] <so1> so how do i do it?
[08:59] <azeem> 20:57  * persia points at https://wiki.ubuntu.com/MOTU/Recipes/PackageUpdate
[09:00] <man-di> so1: dont forget to edit debian/changelog
[09:00] <so1> sorry, dinner, i'll back in 5 minutes :-(
[09:00] <azeem> so1: don't eat too fast
[09:00] <man-di> so1: you must be a fast eater
[09:09] <persia> icf7: I'm going to recommend you get someone who has previously packaged something with Java to give this a look - I have no idea if some of it is correct or not :)
[09:10] <icf7> persia: Thank you, I'll ask in #ubuntu-java !
[09:10] <jrib> if anyone would like to review a new package: http://revu.tauware.de/details.py?upid=5444 thanks!
[09:11] <so1> so ok
[09:11] <so1> back
[09:11] <persia> icf7: It may be that few people there can comment directly, but you might get some good advice either in-channel, or in a pastebin.
[09:11] <so1> ok be right back
[09:18] <persia> icf7: Commented.
[09:18] <man-di> icf7: Java package?
[09:18] <icf7> persia: Thanks, will fix that too
[09:18] <icf7> man-di: Yes.
[09:19] <icf7> persia: 1): Do I need more than "License for package and content:" ?
[09:19] <soc> i have done apt-get source gimp
[09:20] <soc> what now?
[09:20] <soc> tarball is extracted
[09:20] <soc> should i move the new source from gimp.org over the old one?
[09:21] <soc> then rename the folder=
[09:21] <soc> then ./configure, make
[09:23] <soc> if i wanted it to be called gimp-2.3 instead of gimp, what would i have to do?
[09:23] <soc> someone there?
[09:23] <man-di> soc: use uupdate
[09:23] <man-di> soc: then debuild
[09:23] <persia> icf7: https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/DebianCopyright is what you want to check, but somehow it fails to mention http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html, which has a good example at the bottom.
[09:25] <soc> so
[09:25] <soc> uupdate gimp_2.3.18.orig.tar.gz?
[09:26] <mok0> I've made a new upload of wulfware based on the last review, I've addressed most of the issues raised, and I now seek further review... ;-)
[09:26] <persia> mok0: It's best to include the URL when saying that :)
[09:27] <mok0> Just a min...
[09:27] <mok0> http://revu.tauware.de/details.py?upid=5495
[09:27] <soc> can someone give me an advice on using uupdate=
[09:27] <soc> in which directory do i have to run that?
[09:28] <mok0> top dir of package
[09:28] <soc> of which one?
[09:28] <soc> of the old or the new?
[09:28] <mok0> old
[09:28] <soc> ok
[09:28] <mok0> you don't yet have the new
[09:28] <soc> how can i tell it where the new tar.gz is?
[09:28] <mok0> :)
[09:29] <soc> ah ok
[09:29] <soc> so what exactly does uupdate
[09:29] <mok0> that is given in debian/watch
[09:29] <soc> si i can run uupdate without arguments?
[09:29] <mok0> yes
[09:29] <mok0> man uupdate
[09:29] <soc> in watch there is just a ftp-server, is taht right?
[09:30] <mok0> watch has the uri of where to look for the source code
[09:30] <soc> but the uri of the official package is wrong?
[09:30] <soc> it points to 2.2
[09:30] <mok0> then you need  to fix it
[09:31] <soc> i have the file already localy ... can i use that?
[09:31] <man-di> soc: uupdate ....pathtoyourtgz
[09:31] <man-di> soc: you dont need a watch file
[09:31] <mok0> it should have a regexp in () where the version is
[09:31] <soc> btw ... what does "version=3" mean in watch?
[09:31] <soc> ok
[09:31] <man-di> soc: the tool that uses watch files is called uscan anyway
[09:31] <mok0> that is the version of the watch syntax
[09:31] <soc> ahhh it works :-)
[09:31] <mok0> never mind that
[09:31] <soc> a thx
[09:31] <mok0> :-)
[09:32] <man-di> soc: man uscan explains watch files
[09:32] <mok0> ok
[09:32] <soc> ok, now i have the new source directory
[09:32] <soc> ./configure=
[09:32] <soc> make?
[09:32] <man-di> soc: now build it with debuild
[09:33] <mok0> there is a detailed manual somewhere on how to update a package to a new version
[09:33] <man-di> configure and make is called by dpkg-buildpackage which is called by debuild
[09:33] <AndyP> is anybody working on the rt2500 FTBFS? or does anyone know anything about it? i might have a look at it myself if no one's working on it (i need it to build to have wireless workage in gutsy)
[09:34] <persia> AndyP: If there's not an assigned bug open in LP, it's fair game.
[09:34] <soc> the problem is, i want the package to be called gimp-2.3" instead of "gimp
[09:34] <soc> how do i do that when debuild runs configure?
[09:35] <mok0> soc: but the package name does not have version numbers in it
[09:36] <mok0> the version is given in the changelog file, top line
[09:36] <AndyP> can't find a bug... this should be fun :)
[09:36] <soc> mh ok so how can i provide a gimp package without overwriting the one from ubuntu
[09:36] <soc> i distribute the package which use gimp extensively
[09:36] <soc> they want to work with gimp-2.2 but want to try gimp-2.3, too
[09:37] <mok0> you can (should) not call package SSgimp, but ssgimp
[09:37] <mok0> (if that is neither in ubuntu or debian)
[09:37] <mok0> only lowercase.
[09:37] <soc> SSgimp?
[09:37] <geser> soc: you would need to replace the package name in all debian/ files and filenames
[09:37] <soc> dont understand that ...
[09:37] <soc> ah ok ...
[09:38] <soc> when using checkinstall i can just specify the name ...
[09:38] <soc> so debuild is a bit more complicates in that matter?
[09:38] <mok0> control defines package names, changelog defines version nums
[09:38] <mok0> debuild reads the files in debian/
[09:39] <soc> so i would just have to modify control?
[09:39] <mok0> mmmmm perhaps
[09:40] <mok0> there can be files called gimp.install etc
[09:40] <mok0> they should be renamed to ssgimp.install etc.
[09:40] <soc> i would have to change that manually too?
[09:40] <mok0> yes
[09:40] <soc> why ss?
[09:40] <geser> soc: at least, perhaps also debian/rules and rename some files in debian/
[09:40] <mok0> errrr, didn't you want to call the package ssgimp?
[09:40] <soc> ssgimp?
[09:41] <soc> never mentioned that ...
[09:41] <geser> mok0:  is next to "
[09:41] <mok0> ah :-)
[09:41] <soc> ahh
[09:41] <soc> i see
[09:41] <soc> sorry
[09:41] <soc> "gimp-2.3"
[09:41] <mok0> not on my keyboard
[09:41] <geser> soc: if you want to name it differently, you probably also want to make sure that gimp and gimp-2.3 are installable in parallel
[09:41] <mok0> ok, so the package name is still "gimp"
[09:42] <soc> i just want to be able to install both in parallel, how i do that doesn't matter+
[09:42] <soc> i just thought renaming the package would be the right way
[09:43] <mok0> you can call it socgimp :-)
[09:43] <mok0> or gimpsoc
[09:43] <soc> what would be the difference to gimp-2.3?
[09:43] <soc> gimpsoc wouldn't be easier?
[09:44] <soc> gimp-2.3 seems to be more intuitive
[09:44] <mok0> no, it's probably simpler to just change the version
[09:44] <geser> soc: but the binary will still be gimp and collide with the gimp from gimp
[09:44] <mok0> so you just update the version number in debian/changelog
[09:44] <geser> so need to rename the binary
[09:44] <soc> i mean if i call it gimpsoc, nobody knows what it is
[09:44] <soc> if i call it gimp-2.3 it's clear
[09:44] <geser> and also make sure that the data files are in different dirs
[09:44] <soc> and people will know that it doensa't overwrite their regular gimp
[09:45] <soc> with checkinstall i called the package gimp-2.3 and installed it to /usr/local
[09:45] <geser> dpkg will complain if a file /usr/bin/gimp is installed from "gimp" and "gimp-2.3"
[09:46] <soc> yes, that's why i want to install it to /usr/local
[09:46] <geser> packages must not install files in /usr/local
[09:46] <soc> why's that?
[09:46] <mok0> debian packaging policy
[09:50] <mok0> gimp is maintained in the debian distro
[09:50] <geser> /usr/local is in control of the local admin
[09:50] <geser> and packages should not interfere with it
[09:50] <mok0> soc: gimp is a complicated package, perhaps you should start with a simpler one
[09:52] <zul> checkinstall is evil as well
[09:55] <so1> sorry, lost connection ...
[09:55] <so1> last thing i read was
[09:56] <so1> (21:46:36) soc: why's that?
[09:56] <so1> shouldn't unofficial packages install to local?
[09:56] <mok0> no
[09:57] <crimsun> No package should touch /usr/local period.  That's the domain of the administrator, as has been stated.
[09:57] <mok0> it's debian packaging policy
[09:57] <mok0> He was offline
[09:57] <so1> ah ok
[09:57] <so1> so to install it to /usr
[09:58] <so1> i would have to rename really everything to another name?
[09:58] <mok0> soc: gimp is a complicated package, perhaps you should start with a simple on e
[09:58] <so1> don't think that's even possible ...
[09:58] <mok0> You just change the version number in debian/changelog
[09:58] <so1> problem is, i promised people that i would provide them with the latest and greatest gimp-2.3 packages until they are in ubuntu ...
[09:59] <so1> yeah but that would overwrite the old version wouldn't it?
[09:59] <mok0> ah, promises :-)
[09:59] <so1> i know i know
[09:59] <so1> it seemed easy to hold ... until checkinstall broke
[09:59] <so1> don't know why it f'cks up every package ...
[10:00] <mok0> In principle is _should_ be possible to move the debian directory to the new 2.3 directory
[10:00] <so1> it produces debs with files like, "ld", "nm", "gcc","grep" in it
[10:00] <so1> don't know why ...
[10:00] <mok0> but perhaps there are big changes in the way 2.3 is configured and installed
[10:00] <so1> mh ...
[10:01] <mok0> ... can you compile 2.3 outside of debian?
[10:01] <so1> would it be possible for me to provide updated gimp-packages for the official ubuntu repos?
[10:01] <mok0> (ubuntu)
[10:01] <mok0> gimp already has a maintainer
[10:01] <so1> don't understand the question .-...
[10:02] <so1> so how could i get him to update gimp 2.3 faster? :-P
[10:02] <mok0> can you download gimp-2.3.tar.gz and compile it?
[10:02] <so1> yes that works
[10:02] <so1> ./configure && make && make install works
[10:02] <mok0> fine
[10:02] <crimsun> so1: it is not Ubuntu main's policy to always have the latest & greatest.
[10:02] <so1> but ./configure && make && checkinstall not
[10:03] <so1> so there we have the problem ...
[10:03] <crimsun> main has a _much_ stricter set of requirements for updated software
[10:03] <so1> i don't overwrite ubuntus gimp packages
[10:03] <mok0> I don't know checkinstall -- while you were gone someone said it is evil
[10:03] <so1> i don't WANT overwrite ubuntus gimp packages
[10:03] <so1> arrgh
[10:03] <so1> i don't WANT TO overwrite ubuntus gimp packages
[10:03] <crimsun> then install them to /opt or something
[10:03] <mok0> that makes it more difficult
[10:03] <so1> but it seems to be difficult to rename it
[10:03] <crimsun> pass --prefix=/opt to configure
[10:03] <so1> ok /opt is acceptable
[10:04] <so1> how do i do that if debuild does congiure for me?
[10:04] <crimsun> other packages do that - the KDE 4 snaps, for instance
[10:04] <crimsun> edit debian/rules appropriately
[10:05] <crimsun> since gimp uses cdbs, you'll need the appropriate redefinition
[10:06] <crimsun> https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528414
[10:06] <geser> !info gimp gutsy
[10:06] <ubotu> gimp: The GNU Image Manipulation Program. In component main, is optional. Version 2.3.16-1ubuntu3 (gutsy), package size 4073 kB, installed size 10768 kB
[10:06] <geser> so1: ^^
[10:06] <crimsun> -2 is in experimental
[10:07] <crimsun> 2.3.17 should be skipped anyhow due to the crasher
[10:07] <crimsun> I'm not sure of 2.3.18
[10:07] <mok0> so1: funny, before there was someone name soc asking about that very same package
[10:07] <mok0> ;-)
[10:09] <so1> ah ,,,
[10:09] <so1> seems that the server renamed me again ...
[10:09] <so1> sorry, if that was confusing ...
[10:09] <mok0> np
[10:10] <mok0> just trying to keep the spirit up here on the channel
[10:11] <so1> ok, i give up for today ...
[10:11] <so1> see you tomorrow ...
[10:11] <mok0> see you, do some reading...
[10:13] <so1> yes ...
[10:14] <so1> i wonder why there is such a divison between those which just want to build a package and those "professional" packaging mechanisms....
[10:15] <mok0> ... that's what keeps Ubuntu so very, very stable
[10:15] <so1> most people will never be able to participate because it so complicated ...
[10:15] <so1> "digital divide"
[10:15] <so1> :-)
[10:15] <mok0> yes
[10:16] <so1> maybe it would be better to fix up checkinstall ...
[10:16] <mok0> If you want quick-n-easy packaging, you need to go to the RPM world
[10:16] <so1> mh no ,,,
[10:16] <so1> no way...
[10:16] <mok0> Fedora
[10:16] <mok0> :-)
[10:16] <mok0> Well, there you are
[10:16] <so1> rpm reminds me of suse ...
[10:16] <mok0> the hard work is up front, with the packager
[10:17] <so1> i just don't like the idea of checkinstall <----> debuild
[10:17] <so1> that reminds me of win xp home <-----> professional ...
[10:18] <mok0> like I said, I don't know checkinstall, but someone said it is evil
[10:18] <so1> to keep consumers and developers/producer/worker/professionals apart ...
[10:18] <so1> yeah i heard that too ...
[10:18] <mok0> Your project is doable
[10:19] <mok0> but you need guidance
[10:19] <so1> checkinstall is so widely used because it normally works and it's easy to understand
[10:19] <so1> it's doable for casual users, with checkinstall they maxbe need 1 minte to build a deb ...
[10:19] <mok0> I've worked 25 years with unix and never heard of it
[10:19] <so1> but debuild is highly advanced ...
[10:20] <so1> then try it
[10:20] <so1> download a normal source ...
[10:20] <mok0> once you've edited the files in debian, you just cd .. and do: debuild
[10:20] <so1> no need for dsc etc ...
[10:20] <mok0> never mind
[10:20] <so1> ./configure && make && sudo checkinstall
[10:21] <mok0> just do debuild and distribute the .debs to your friends
[10:21] <man-di> so1: both tools are for different user groups
[10:21] <so1> then there comes a dialog where you can modify things like email, dependencies, packagename etc
[10:21] <so1> yes i know ... and i don't like that division
[10:21] <mok0> configure && make && make install is done by debian/rules
[10:21] <so1> if checkinstall is evil, it should be fixed up ...
[10:22] <so1> because normal users will never bother with debuild/pbuilder
[10:22] <mok0> you don't need pbuilder
[10:22] <persia> so1: Is there a nice guide to checkinstall with screenshots and the like?
[10:22] <so1> the good thing about ubuntu is, that you will always find a deb
[10:22] <man-di> so1: checkinstall has its users, but looking for them among packagers is like fighting against windmills
[10:22] <so1> persia: you won't need that
[10:23] <so1> it's as easy as it can get
[10:23] <so1> it might be possible that there is a guide
[10:23] <so1> but i never needed that
[10:23] <so1> checkinstall is selfexplanatory
[10:23] <mok0> back to basics: what is the diff between gimp 2.2 and 2.3??
[10:24] <so1> quite much i think ...
[10:24] <so1> one is the stable version, one the development which will become 2.4
[10:24] <so1> ok, but o have to go now ...
[10:24] <crimsun> ...if checkinstall is dumping things like ld and nm into the deb, uh, I think it has much more serious problems.
[10:24] <so1> see you tomorrow
[10:24] <mok0> cu
[10:24] <so1> no, i think that ubuntu broke something
[10:25] <so1> it always worked since around the time gimp 2.3.16 came out
[10:25] <keescook> any kubuntu users around?  what application launches when a non-disk usb camera gets plugged in?
[10:25] <crimsun> keescook: not #kubuntu-devel ?
[10:25] <so1> it always worked UNTIL around the time gimp 2.3.16 came out
[10:26] <crimsun> I have no idea why anyone would checkinstall 2.3.16 anyhow
[10:26] <so1> surely ubuntu broke something in an update
[10:26] <mok0> so1: dont understand
[10:26] <shawarma> StevenK: Around?
[10:26] <crimsun> there's a known-good, working Debian source package for 2.3.16-2 in Debian experimental
[10:26] <so1> at that time there was no gimp 2.3.16
[10:27] <so1> i always built the packages some hours after they were released
[10:27] <so1> but now it doesn't work anymore
[10:27] <shawarma> I've noticed that the copyright holders of the .po files are *very* often left out of debian/copyright.. Is this just the way it is? Is it policy? What gives?
[10:27] <mok0> must be changes in the upstream source
[10:28] <so1> checkinstall doesn't work anymore snce april ...
[10:28] <crimsun> shawarma: they should be listed in the *.po, but yes, it does seem inconsistent.
[10:29] <so1> but i couldn't identify the package which broke it yet
[10:29] <shawarma> crimsun: So there's no particular reason, but just customary..
[10:29] <crimsun> shawarma: AFAICT
[10:29] <crimsun> so1: hmm, the merge from Debian indicates only two changes
[10:29] <crimsun> the use of /usr/bin/which (as opposed to a shell built-in) and the addition of make as a Dependency
[10:29] <so1> ok ...
[10:30] <crimsun> so if checkinstall is truly broken, then something is broken in the original source package, which I'm finding a bit difficult to see
[10:30] <so1> the problem is, it could just be anything ...
[10:30] <crimsun> that's not to say that checkinstall itself isn't broken
[10:30] <so1>  compiler, linker, autotools, etc ...
[10:31] <crimsun> I don't think it's anywhere that invasive
[10:31] <crimsun> if so, we'd have massive toolchain issues in addition to a completely broken archive
[10:31] <so1> mh yeah, maybe just a bugfix in a gnutool which triggered a bug in checkinstall
[10:31] <mok0> so1: you can file a bug report
[10:32] <so1> maybe checkinstall depended on a undefined behavior which was fixed recently ...
[10:32] <so1> ok, tomorrow ...
[10:32] <RainCT> good night
[10:38] <so1> i hate it ...
[10:38] <so1> it was so easy with checkinstall ...
[10:38] <crimsun> s/easy/broken/
[10:40] <so1> :-(
[10:40] <mok0> so1: debian package guidelines are meant to protect users from breakage
[10:40] <so1> in the last two months more than 2000 people donwloaded my gimp packages ,,,
[10:41] <mok0> so, you are tracking gimp developement closely?
[10:41] <so1> yes ...
[10:42] <so1> normally my packages are a few ours behind the current release
[10:42] <mok0> what version is it that your users have downloaded?
[10:42] <so1> ^hours
[10:42] <so1> 2.3.15 and 2.3.16
[10:42] <so1> i didn't package 2.3.17 because of the crasher
[10:43] <so1> and now people are waiting for my gimp 2.3.18 package ...
[10:43] <mok0> so, you are complaining that something's changed recently in ubuntu?
[10:43] <so1> yes ...
[10:43] <so1> something caused checkinstall to malfunction ...
[10:43] <so1> on both
[10:43] <so1> on my pc (i386)
[10:43] <mok0> what did you use to do when updating a package?
[10:43] <so1> and laptop (amd64)
[10:44] <crimsun> please don't use checkinstall if you know it's broken.
[10:44] <mok0> You used to use checkinstall?
[10:44] <so1> download the source package from gimp.org
[10:44] <so1> ./configure && make && sudo checkinstall -> upload
[10:44] <mok0> you need to file a bug report against checkinstall
[10:44] <so1> yeah ok
[10:44] <so1> crimsun: i don't use it anymore ...
[10:44] <so1> because it's broken
[10:44] <crimsun> if your users are frothing at the mouth, I'd use uupdate
[10:45] <so1> yes, but i can't distribute it as "gimp"
[10:45] <so1> that will overwrite their packages
[10:45] <mok0> I'd tell'em to use PhotoShop...
[10:45] <mok0> :-)
[10:45] <crimsun> so1: of course you can distribute it as gimp
[10:45] <crimsun> see, this is one of the problems with checkinstall
[10:45] <so1> it will overwrite the officail gimp-2.2
[10:46] <mok0> yes
[10:46] <so1> but if i install it as "gimp" it will overwrite it
[10:46] <mok0> yes, but does it matter'
[10:46] <crimsun> its users have no motivation to learn about Conflicts and other Debian source package protocol.
[10:46] <so1> dpkg can't handle two different packages with the same name
[10:46] <crimsun> yes it can
[10:47] <crimsun> I just told you the precise field
[10:47] <so1> if you mean, it will try to update the one with the other than yes
[10:47] <so1> but you can't have two "gimp"s installed
[10:47] <so1> conflicts won't help, because that will remove the old gimp 2.2 package
[10:47] <crimsun> oh, you mean concurrently installed? No, that's bad.
[10:48] <so1> yes exactly
[10:48] <crimsun> just name it something else
[10:48] <so1> thats waht i'm atlking about since hours
[10:48] <mok0> you need pretty advance packaging to have two different versions
[10:48] <so1> yes exactly -----------> gimp-2.3
[10:48] <mok0> I'd suggest gimp23 then
[10:48] <crimsun> so1: what release is this for?
[10:48] <crimsun> so1: because gimp already exists as 2.3.16-2 in Debian experimental
[10:49] <so1> mok0: as long as checkinstall worked that was a matter of seconds to change the fieldname from "gimp" to "gimp-2.3"
[10:49] <mok0> your package will be gimp23_2.3_i385.deb
[10:49] <so1> ^exactly
[10:49] <mok0> ok
[10:49] <crimsun> so1: it's not any worse in Debian.  You edit one field in the appropriate files.
[10:50] <so1> mok0 told me, i would have to rename the hole debian directory ...
[10:50] <crimsun> you need to be very careful if you're maintaining third-party packages that already exist in Debian and its derivatives
[10:50] <mok0> change gimp -> gimp23 -> change names of files in debian/
[10:50] <crimsun> you do not have to rename the directory
[10:50] <mok0> and in control
[10:50] <so1> see the prolem?
[10:50] <mok0> no
[10:50] <crimsun> it's the content of debian/* that matters, not the name of the extracted source dir
[10:50] <mok0> piece of cake
[10:52] <soc> sorry
[10:52] <soc> i HATE pidgin
[10:52] <mok0> soc!!!
[10:52] <soc> :-)
[10:52] <mok0> heghe
[10:52] <mok0> hehe
[10:52] <soc> i always loose the connection
[10:53] <mok0> when was the split?
[10:53] <soc> some seconds ago ...
[10:53] <soc> "so1" == "soc"
[10:53] <mok0> Ah!
[10:55] <mok0> Anyways: rename gimp-> gimp23 -> edit control, rename all files in debian called gimp.* ->  gimp23.*
[10:55] <azeem> mok0: there's already a gimp-2.3 package, why do you want to fundamentally change it?
[10:55] <azeem> eh, I guess that was for soc
[10:56] <crimsun> he wants them parallel-installable
[10:56] <azeem> oh well, I didn't read scrollback
[10:56] <azeem> to be uploaded to ubuntu?
[10:56] <mok0> no obvously :-)
[10:56] <azeem> soc: or for your own leisure?
[10:56] <azeem> ah, /me doesn't mind then
[10:57] <soc> azeem: i provide some (2000) friends with always up-to-date packages ...
[10:57] <azeem> aha
[10:57] <soc> what's wrong with checkinstall btw?
[10:57] <azeem> soc: did you see the part about gimp-2.3.17 being broken?
[10:57] <soc> yes ...
[10:57] <azeem> ok
[10:58] <soc> i didn't package it at all
[10:58] <soc> it's not a problem with gimp, but with checkinstall ...
[10:58] <soc> and because checkinstall is broken i'm trying to learn proper packaging with debuild
[10:58] <soc> but that seems not that easy though ...
[10:59] <soc> crimsun?
[10:59] <crimsun> soc?
[10:59] <soc> could you explain what exactly is evil with checkinstall?
[10:59] <soc> maybe i'll understand it ...
[11:00] <soc> that would help me to use debuild :-)
[11:00] <crimsun> checkinstall has generated broken packages
[11:01] <crimsun> I didn't say it was evil, I said it is foolish to use checkinstall when there is an existing 2.3.16 source package in Debian
[11:01] <soc> but there is no 2.3.18 ...
[11:01] <crimsun> so take it, and use uupdate
[11:02] <soc> but that is 10 times more complicated than checkinstall ...
[11:02] <soc> ^approximately :-)
[11:02] <crimsun> and at at least 10^6 times "easier" than doing it from scratch.
[11:02] <man-di> soc: and produces 100 times better packages
[11:02] <soc> what's better about them?
[11:03] <man-di> soc: e.g. correct dependencies
[11:03] <man-di> or at least better dependencies
[11:03] <soc> you can specify them in checkinstall too
[11:03] <azeem> but you'd need to start from scratch
[11:04] <man-di> soc: in debian package you already have them
[11:04] <soc> i might just copy them from the dsc file
[11:04] <crimsun> does checkinstall handle shlibdeps?
[11:04] <man-di> soc: with checkinstall you start everytime from scratch
[11:04] <man-di> crimsun: nope
[11:04] <soc> have no problem with that :-)
[11:04] <crimsun> right, that's at least one potential disaster
[11:04] <soc> takes approximately 1 minute ...
[11:05] <mok0> soc: you just said you'd like to learn proper debian packaging: it take some effort
[11:05] <soc> compared to the countless hours i'm just trying tu _understand_ how debuild/pbuilder etc. work
[11:05] <soc> :-)
[11:05] <crimsun> soc: we all started there
[11:05] <AndyP> understanding is good
[11:05] <soc> ok, that makes me more comfortable
[11:05] <soc> yes i know
[11:06] <soc> but for now my top priority is that those people waiting for my package get it within hours of the release
[11:06] <mok0> so: let's agree about you forget about checkinstall
[11:06] <soc> nr 2 is debian packaging
[11:06] <soc> if i combine those two, it would be nice .-..
[11:06] <crimsun> so take the Debian source package for 2.3.16-2 and work with it.
[11:06] <soc> ok
[11:06] <soc> ok
[11:07] <soc> so rename all gimp-files to gimp-2.3
[11:07] <mok0> your users are not served well if your packages one day break their systems
[11:07] <soc> yeah ... but it worked for a half year :-)
[11:07] <soc> ok ...
[11:08] <soc> rename all gimp-files to gimp-2.3 <--- is there something INSIDE which i have to rename, too=
[11:08] <mok0> Ahhh.... half a year... let's talk about 5 years
[11:08] <mok0> in debian/contral
[11:08] <soc> then modify control
[11:08] <soc> ok
[11:08] <mok0> yup
[11:08] <soc> so inside control
[11:09] <soc> and the rest just the filename
[11:09] <mok0> and all files in debian named "gimp.*"
[11:09] <mok0> and libgimp.*
[11:09] <mok0> etc
[11:09] <soc> btw. how do i have to change control so that it just generates a big gimp-2.3 package and not 10 small ones?
[11:10] <mok0> Oh, that's a huge project
[11:10] <soc> downloading and installing them manually is pita
[11:10] <man-di> soc: famous last words: ... but it worked in the past
[11:10] <soc> (about repositories we'll talk later)
[11:10] <mok0> most of us use apt
[11:10] <soc> (23:10:22) soc: (about repositories we'll talk later)
[11:10] <soc> :-)
[11:11] <soc> my fear is, that if i know change the packaging AND the distribution nothing works in the end
[11:11] <mok0> soc: we're not getting anywhere
[11:11] <soc> so i would like to sort out the packaging first, then maybe if it works i'll set up a repo
[11:12] <soc> would that be acceptable?
[11:12] <mok0> netsplit, huh?
[11:12] <soc> did i already mention that i hate pidgin? :-P
[11:12] <soc> yeah ---
[11:12] <mok0> yup
[11:13] <mok0> well, you're kinda bitchin that checkinstall doesn't work, you say you wanna learn proper packaging and then you say that it's too difficult
[11:13] <soc> i just have some webspace, but for setting up a repo i would need my own server, wouldn't i?
[11:13] <mok0> yes
[11:14] <soc> my problem is, that people wait for my packages ...
[11:14] <soc> :-(
[11:14] <soc> and i will do everything necessary so they will get them
[11:14] <soc> if that means debain packaging, ok
[11:14] <soc> i will do it
[11:14] <mok0> good
[11:14] <soc> i just have some different priorities ...
[11:14] <man-di> you dont really need your own server, you can create a repo on your host and then rsync/ftp/whatever the result to your webspace
[11:14] <mok0> we've told you what to do
[11:15] <soc> so for instance "falcon" would be able to install it from remote?
[11:15] <soc> just with http/ftp?
[11:15] <man-di> anyway, enough hacking for today, good nite all
[11:15] <crimsun> night
[11:15] <mok0> if he/she knows the exact URI
[11:16] <mok0> night, crimsun
[11:16] <mok0> man-di, night!
[11:16] <soc> night, madi
[11:16] <soc> ^man-di
[11:17] <soc> problem is i don't really have a change starting to learn it with a simple package, because i exactly need gimp :-(
[11:17] <mok0> gimp is a complicated package
[11:17] <azeem> soc: I'm curious, what's the new features in .18 compared to .16?
[11:18] <soc> don't know ...
[11:18] <soc> -> changelog
[11:18] <jmg> lawl
[11:18] <soc> i'm just doing people a favor
[11:18] <soc> i'm no artist ...
[11:18] <mok0> lol = laughing my legs off
[11:19] <soc> 95% of my time with gimp i'm resizing some holiday pics or so ...
[11:19] <soc> :-)
[11:19] <mok0> laugh off legs
[11:19] <mok0> :)
[11:19] <xxxxx1> bye all
[11:20] <mok0> luckily we still have xxxxx2
[11:20] <soc> why are people laughing at me? :-)
[11:20] <jmg> :)
[11:20] <mok0> It's all in good fun
[11:21] <soc> yeah, i know ...
[11:21] <soc> :-)
[11:21] <soc> is there maybe a simple package which needs a maintainer?
[11:21] <mok0> Ah!
[11:21] <jmg> check the rfps
[11:22] <mok0> http://www.debian.org/devel/wnpp/work_needing
[11:22] <jmg> oh
[11:22] <jmg> orphanage
[11:22] <mok0> Lots and lots
[11:23] <TheMuso> siretart: No, not for any great length of time.
[11:23] <mok0> TheMuso: Errrrr?
[11:23] <TheMuso> mok0: siretart contacted me earlier about something, so I am just replying to him.
[11:24] <soc> mh  ... nothing interesting ...
[11:24] <soc> exaile, listen those things are already in ubuntu, aren't they?
[11:24] <soc> exaile even has its own repo :-/
[11:25] <crimsun> yes, they are already in Debian and in Ubuntu.
[11:25] <AndyP> hm, out of my depth with this rt2500 bug... i think i'll just file a bug with my findings so far and hope someone with more clue than i finds it
[11:26] <soc> mh ...ok
[11:26] <soc> how about the kernels?
[11:26] <crimsun> the what?
[11:26] <soc> has hurd a maintainer already?
[11:26] <soc> :-P
[11:27] <crimsun> there is a kernel team
[11:27] <mok0> Yeah, hurd has 1 maintainer and 1 user
[11:27] <soc> ah ok ...
[11:27] <soc> the same person?
[11:27] <soc> let me guess ...
[11:27] <soc> duke nukem?
[11:27] <AndyP> and a fanboy (bddebian) :)
[11:27] <mok0> That is yet to be determined
[11:27] <soc> booting ..........
[11:28] <BlueDevil> hello, please build a desktop kernel with HIGHMEM 64GB support :)
[11:28] <soc> duke nukem forever logged in at hurd release 12.12.2089
[11:28] <azeem> soc: the hurd package already has a maintainer
[11:28] <soc> damn :-(
[11:29] <soc> lol
[11:29] <mok0> Hello, duke? duke? DUKE? DUUUUUKKKEEEE?
[11:29] <mok0> laughing off legs
[11:29] <soc> i don't think that 64gb and desktop fit together
[11:29] <BlueDevil> why not?
[11:29] <soc> you see ...
[11:29] <soc> desk-top ...
[11:29] <soc> would you place your machine with 64gb on a desk?
[11:30] <soc> would be a bit too heavy ....
[11:30] <BlueDevil> ok, deskbottom :)
[11:30] <soc> but ... of course better than lap-top ...
[11:30] <mok0> Better be a damn solid desk
[11:30] <soc> who would want to place his 64gb machine on his lap ...
[11:30] <BlueDevil> i'm close to kicking it...
[11:31] <soc> :-)
[11:31] <soc> kick-top hay yet to be invented
[11:31] <soc> ^has
[11:31] <BlueDevil> been trying to build than damn kernel forever
[11:31] <soc> btw why?
[11:31] <mok0> apt-get install kernel
[11:31] <BlueDevil> it won't see more than 2GB without highmem 64gb support
[11:32] <crevette> hello
[11:32] <BlueDevil> the bios configures a hole in the 2gb-4gb range
[11:32] <crevette> apt-get uses 100% inside  pubuilder, could you help me to solve that
[11:32] <BlueDevil> and the generic kernel can only address 4gb
[11:32] <mok0> I though himem support meant > 640 Kb
[11:33] <BlueDevil> highmem
[11:33] <SlimG> What character encoding is required for /usr/share/man/man6/ manuals?
[11:33] <BlueDevil> so my kernel addresses 2GB of memory and 2GB of nothing
[11:34] <BlueDevil> damn frustrating
[11:34] <mok0> BlueDevil: reality is cruel
[11:34] <BlueDevil> i feel like i'm on gentoo
[11:34] <mok0> :-)
[11:34] <crimsun> BlueDevil: we don't care for the kernel
[11:34] <BlueDevil> je sais
[11:34] <crimsun> well, most of us don't
[11:35] <BlueDevil> is there motm?
[11:35] <SlimG> #ubuntu-motm ;)
[11:35] <mok0> Most of us don't have > 2 Gb RAM
[11:35] <crimsun> no, there's the Ubuntu Kernel Team.  We're in #ubuntu-kernel
[11:35] <BlueDevil> why?! why?! why?! :)
[11:35] <mok0> motm -> mothers of the metaphor?
[11:36] <BlueDevil> s/metaphor/monkey/
[11:38] <BlueDevil> crimsun: any idea why was EXTRAVERSION = .3ubuntu1 defined in the 2.6.20-19 source?
[11:38] <crimsun> I asked that a while ago, and I don't remember the answer
[11:39] <shawarma> StevenK: Around?
[11:40] <crimsun> shawarma: I think it's still very, very early in the A.M. for him
[11:40] <shawarma> crimsun: I forget where he is..
[11:41] <shawarma> crimsun: I've got a stack of stuff that could use a review, by the way. If you do it, I'll fix your favorite server bug. :)
[11:42] <crimsun> as in stuff on revu?  which ones?  I'm at work, but I can look tonight.
[11:42] <shawarma> crimsun: Just look for<EMAIL_ADDRESS>A stack (5-6 or so) perl things, and a python app.
[11:42] <crimsun> k
[11:43] <shawarma> crimsun: I'm pretty sure, they're good to go, I just need an ACK on them.
[11:43] <mok0> goodnight, folks!
[11:43] <soc> night
[11:43] <soc> thx for your help
[11:44] <mok0> Hope it helps
[11:44] <soc> i'll try things tomorrow
[11:44] <soc> bye!
[11:46] <geser> AndyP: about the rt2500 FTBFS: have to tried to add #include <linux/if.h> before wireless.h?
[11:46] <geser> linux/if.h defined IFNAMSIZ
[11:58] <ScottK-laptop> Who do I subscribe to a proposed SRU for Feisty once I have a feisty-proposed debdiff?  It isn't clear to me from the wiki.
[11:58] <crimsun> you don't subscribe anyone
[11:58] <crimsun> you handle it from there
[12:00] <ScottK-laptop> OK.  I'll upload it then.  Thanks.
[12:01] <crimsun> np
[12:03] <BlueDevil> crimsun: is usually anyone alive on ubuntu-kernel?
[12:03] <crimsun> yes, but it's very sporadic
[12:03] <ScottK-laptop> crimsun: You find a place to live yet?
[12:04] <crimsun> ScottK-laptop: not yet
[12:04] <BlueDevil> so, it's likely that someone will read my msgs...
[12:04] <crimsun> ScottK-laptop: yep, will do.  Lots to wrap up first.
[12:05] <Q-FUNK> hm. where in debian/rules would i normally put the deletion of *.la that the upstream makefile automaticlly installs to destdir?
[12:05] <Burgundavia> shawarma: ping
[12:08] <geser> Q-FUNK: iirc the install target
[12:09] <crimsun> well, anytime before dh_installdeb(1) if debhelper is used
[12:09] <crimsun> most will nuke them in install or binary-*
[12:10] <Q-FUNK> right, so install:: then
[12:12] <Q-FUNK> very stubborn autotools that insist upon telling the Makefile to install everything and the kitchen sink to /usr/lib/
[12:12] <shawarma> Burgundavia: pong
[12:13] <Burgundavia> shawarma: are you packaging ebox? have you decided on a sysadmin framework?
[12:13] <shawarma> Burgundavia: Yes and almost.