[00:00] <directhex> persia, um........... only a little bit?
[00:00] <_16aR_> hi REVU people ! I got one 2D physics game engine to be reviewed : http://revu.ubuntuwire.com/p/box2d , thank you :)
[00:00] <persia> directhex, What's up?
[00:01] <directhex> persia, i need to Depends: on a /usr/bin/javac of some kind
[00:02] <persia> Right.  I'll answer that in the original forum, if such a package exists.
[00:04] <directhex> persia, monodevelop-java needs a java compiler, to run javac with. - how sane does the dep on http://packages.ubuntu.com/jaunty/monodevelop-java look to you?
[00:05]  * persia experiences network skew
[00:05]  * directhex emits a gravametric pulse
[00:05] <binarymutant> is there an Ubuntu Ruby packaging team?
[00:06] <binarymutant> like pkg-ruby-extras in Debian
[00:06] <directhex> binarymutant, if there is, tell them how awesome ironruby is. it's like ikvm, but for ruby!
[00:06] <persia> directhex, Only issue is that openjdk doesn't match.
[00:06] <binarymutant> directhex, whats ikvm?
[00:06] <directhex> binarymutant, a really space-efficient openjdk!
[00:07] <binarymutant> .NET ruby? sounds...odd
[00:08] <directhex> moreso than .net Scheme?
[00:08] <binarymutant> about the same to me :P
[00:09] <binarymutant> directhex, is it .NET metaprogramming ruby? or the other way around
[00:09] <directhex> binarymutant, it's ruby language on .net runtime, with interop into other .net libs & apps
[00:10] <binarymutant> definitely not my thing :/
[00:15] <persia> binarymutant, Don't worry about it.  Ruby is portable.  Write however you want, and directhex will probably run it in CLR (as with most other languages).
[00:15] <binarymutant> lols
[00:15] <directhex> persia, let me show you ironlisp.....
[00:16] <directhex> persia, oh, and brainfuck.net
[00:16] <directhex> can write some soap web services with it...
[00:17] <ajmitch> directhex: did you see the thing about ironpython loading cpython extensions?
[00:18] <directhex> ajmitch, yes, "ironclad". it's on my radar, but isn't a jaunty task
[00:18] <ajmitch> obviously not, with FF this close
[00:19] <ajmitch> and that it's mostly for windows at the moment
[00:20] <directhex> is it? i honestly hadn't looked in detail
[00:21] <ajmitch> "Ironclad works with IronPython 2 and targets CPython 2.5 on 32-bit Windows; efforts to support other platforms are underway. "
[00:21] <directhex> we can't even run ipy2 without backported fixes (or mono 2.2), so...
[00:21] <ajmitch> maybe by jaunty+1 FF
[00:22] <directhex> i don't think we've discussed goals as a team for summertime
[00:22] <directhex> once monodevelop 2 is resolved, the next priority is bringing all the work done over the past few months into unstable, post-lenny - but that particular goal isn't relevant to jaunty
[00:23] <ajmitch> still fairly important
[00:23] <ajmitch> are you currently in NM?
[00:26] <directhex> no. seems like 2 years of delays for no tangible benefit. i'm happy with "debian shadowy puppetmaster" status for now
[00:26] <ajmitch> I guess if it works for you
[00:26] <directhex> hanska is, though. he's one of the other nice pkg-mono people
[00:26] <ajmitch> especially as there are team members who can quickly upload
[00:27]  * ajmitch hasn't really been using mono stuff enough recently to justify rejoining the team
[00:28] <ajmitch> though my main desktop at work runs sid :)
[00:34] <kirkland> can anyone explain what the .PHONY target in a rules file actually does?
[00:34] <andersk> http://www.gnu.org/software/make/manual/html_node/Special-Targets.html
[00:34] <kirkland> andersk: thx
[01:14] <AdamDH> i need some help with my copyright file, I am packaging a cross compiler based on binutils-2.19, I get a patch from cvs from the cross compilers website and that is the same license as binutils, do I need to in the files section list the modified files from the patch to show who wrote the cross compiler part then the rest is part of binutils?
[02:02] <AdamDH> https://wiki.ubuntu.com/PackagingGuide/Complete reading that is X-Comment: a correct tag as I cannot find it any one in the documentation at http://wiki.debian.org/Proposals/CopyrightFormat
[02:04] <RAOF> X-* means "extended", IE: "I've made this one up".
[02:05] <RAOF> There are no X- tags in the format itself, but you can make them up if you feel you need to (I've used X-Repacked-Reason before)
[02:06] <StevenK> RAOF: That's hideous!
[02:06] <RAOF> X-Because-I-Can:
[02:07] <RAOF> X-Music-Listened-To: Yo La Tengo ♪ You can have it all ♫.
[02:07] <RAOF> That's an important part of every debian/copyright file!
[02:11] <persia> RAOF, Now, implement libcopyright in such a way that it processes that, pulls an .ogg from somewhere and pushes through ogg123 in the background whenever the file is checked.
[02:12] <RAOF> persia: We'd need a couple of years of wrangling about the precise format of the Music-Lisened-To field before I could feel confident implementing it in libcopyright :P
[02:12] <persia> RAOF, It's your implementation.  Embrace and Extend!
[02:12] <persia> If someone doesn't like it, they can write their own libcopyright.
[02:14] <AdamDH> thanks guys, X can allow me to add a comment to the copyright file to explain what is happening?
[02:38] <bitbuzter> how should i create a patch to be used on debian/patches?
[02:38] <bitbuzter> a diff of the orig and new dirs?
[02:39] <persia> bitbuzter, Run what-patch in the source directory to discover the patch system.
[02:39] <persia> If it's dpatch or CDBS, you can use dpatch-edit-patch or cdbs-edit-patch to automate the patch creation.
[02:39] <bitbuzter> ok
[02:40] <persia> If it's quilt, you can use quilt to manage the patch creation.
[02:40] <persia> If it's not one of those, ask again.
[02:44] <TheMuso> c/c
[02:45] <bitbuzter> its cdbs.. im trying with cdbs-edit-patch now
[02:45] <bitbuzter> thanks for the tips!
[02:46] <persia> bitbuzter, Thanks for working on a patch to fix a package.  With your help, Ubuntu will be better :
[02:46] <bitbuzter> :))
[03:07] <Davedan> can I make an ubuntu package without a source package with dh_make ?
[03:09] <persia> Davedan, What is your end goal?
[03:10] <Davedan> persia: the package should put two simple python scripts ( /usr/share/<pkgname>/ ), a file under /etc/apt/apt.conf.d/ and a config file that will hold the user mail which will be entered duiring the install
[03:13] <persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling
[03:15] <Davedan> persia: looks interesting. I'm reading it. thanks
[03:16] <persia> So, the short answer is "No", but it's not hard to create the source package, and then create the Ubuntu package.
[03:18] <Davedan> persia: so I don't understand what is a source package. I thought that in my case I have only a binary, or maybe they are the same
[03:20] <nhandler> persia: Would your example package on that wiki page even be accepted? I would think the fact that upstream just put the properly licensed copy of the file on pastebin would cause issues
[03:20] <persia> nhandler, Well, see, upstream was creating the source during the lesson, and didn't have time to register a project on LP.
[03:21] <nhandler> lol persia
[03:21] <persia> Anyway, I mostly trust upstream.  I've spent a lot of time going over code by that author, and while there are a fair number of mistakes, it's nothing I wouldn't have done.
[03:22] <nhandler> :)
[03:22] <persia> Actually, that document could do with a refresh, to use the new copyright format, debhelper 7, etc.
[03:23] <persia> And yes, to have a proper upstream project registered, with a proper downloadable tarball, and a watch file.
[03:23] <persia> Might even benefit from a better script :)
[03:32] <ScottK> persia: Actually I have concerns about pushing the new copyright format too hard on new contributors.
[03:33] <ScottK> I think it's subtantially more complex to write and raises the barrier to contribution.
[03:33] <ScottK> Requiring it has no basis in policy.
[03:36] <persia> Well, for simple things, it's no more complex to write, and for complex things, the other format is almost always done wrong anyway, but I see your point.
[03:36] <jacob> ScottK: do you mean the RFC 2822 / email format? if so then I sure agree.
[03:36] <persia> Do you object to it being offered as an option?
[03:36] <ScottK> jacob: Yes.
[03:37] <jacob> I've gotten used to the format now and am comfortable writing it, but there seems to be a lot of boilerplate for simple tasks.
[03:37] <ScottK> persia: I don't object to it being offered as an option, but I think it should clearly be an alternative.
[03:37] <ScottK> That and it's just flat out got more things to be wrong.
[03:38] <persia> I'm not sure there are more things to be wrong, if we're picky about debian/copyright.  LucidFox wrote a number of fairly interesting old-format ones for ugly sources.  I'm happy to be clear that it's very much an alternative, and not the primary recommendation.
[03:39] <ScottK> persia: It has additional structural requirements.
[03:40] <ScottK> There aren't any things you must write in the old format that don't also apply to the new one.
[03:40] <ScottK> So it's got to have additional ways to screw up.
[03:41] <persia> OK.  I can see that.
[03:41] <persia> I guess I just haven't encountered it because every one of the new format ones I've reviewed looked good enough, and was human parseable.  If the goal of machine parsability is ever reached, I suspect many would break.
[03:42] <anakron> HI all
[03:53] <anakron> how you can apply a debdiff?
[03:53] <anakron> sudo patch -p1 < ../file.debdiff
[03:53] <anakron> that's the way
[03:53] <anakron> ?
[03:54] <nhandler> anakron: Don't use sudo
[03:54] <anakron> and where i must do it
[03:54] <anakron> ok
[03:54] <nhandler> And that command should be run from within the foo-X.Y directory
[03:54] <nhandler> (assuming the patch is in the parent directory0
[03:54] <anakron> ok
[03:54] <anakron> appears an error
[03:54] <anakron> can't find file to patch at input line 4
[03:54] <nhandler> What is the error?
[03:55] <anakron> and i can patch
[03:55] <anakron> can't find file to patch at input line 13
[03:55] <anakron> Perhaps you used the wrong -p or --strip option?
[03:55] <nhandler> Are you sure the patch is meant to be applied to that version of the source?
[03:55] <anakron> when i try to patch
[03:55] <anakron> i create this debdiff
[03:55] <anakron> from the same version
[03:55] <nhandler> How did you create the debdiff?
[03:56] <anakron> in the same way that wiki says
[03:56] <nhandler> And is this an Ubuntu->Ubuntu debdiff or a Debian->Ubuntu debdiff?
[03:56] <anakron> ubuntu debdiff
[03:56] <anakron> from source
[03:57] <nhandler> So this is a debdiff from an older Ubuntu version to a newer Ubuntu version? And you are attempting to apply it to the older version to make sure it works?
[03:58] <anakron> i make some changes in the source
[03:58] <anakron> the same source
[03:58] <anakron> and now im testing my debdiff file
[03:58] <anakron> but it seems that i make some "lines changes"
[03:58] <nhandler> You are trying to apply the debdiff to a clean/unchanged copy of the old source, correct?
[03:59] <anakron> ok
[04:02] <anakron> Its added correctly T-T
[04:02] <anakron> jeje
[04:02] <nhandler> :)
[04:06] <Davedan> to be able to create a package do I need tar.gz and orig.tar.gz files or two folders or both?
[04:09] <persia> You need the orig.tar.gz, and an unpacked folder.  The tar.gz or second folder are entirely optional.
[04:09] <persia> (well, technically, if you have the second folder, you don't need the orig.tar.gz, but that requires passing interesting arguments to the package build scripts)
[04:12] <Davedan> and the orig.tar.gz should be outside of the package-version folder
[04:12] <Davedan> I forgot to add a quetion mark ? :)
[04:12] <persia> Right.
[04:12] <Davedan> thanks
[04:12] <persia> ?
[04:13] <Davedan> do I need to care about permissions or do it all under my user and not sudo?
[04:14] <persia> All under your user.
[04:14] <Davedan> ok
[04:18] <Davedan> I have to go. I apreciate your help.
[04:22] <anakron> persia
[04:22] <anakron> can you check a bug? i test it applying my debdiff and runs ok
[04:22] <anakron> https://bugs.launchpad.net/ubuntu/+source/slingshot/+bug/315725
[04:23] <anakron> or other motu that can review it
[04:23]  * nhandler goes to look
[04:23] <anakron> ok thanks
[04:23] <fabrice_sp> Hi. When the last uploader of a package is not a MOTU, is there a way to know who really uploaded it? (Bug #329830)
[04:24] <fabrice_sp> (just wanted to know who sponsored it)
[04:24] <nhandler> anakron: Just as a heads up, the MOTU Reviewers Team is dead. You will want to subscribe, not assign, ubuntu-universe-sponsors or ubuntu-main-sponsors to your bugs
[04:24] <nhandler> fabrice_sp: One second, I'll find it
[04:24] <anakron> ups!
[04:24] <anakron> sorry, i knew it but i forgot it
[04:25] <fabrice_sp> thanks :-)
[04:27] <nhandler> fabrice_sp: james_w uploaded it: https://lists.ubuntu.com/archives/jaunty-changes/2009-February/005210.html
[04:27] <nhandler> (Look at the Signed-By field)
[04:29] <fabrice_sp> nhandler, I can see it. Thanks! (as I'm willing to apply to U-C-D, I'm actively looking for my sponsors, to have their feeling). Thanks again!
[04:29] <nhandler> You're welcome fabrice_sp
[04:29] <fabrice_sp> (feedback, I mean)
[04:30] <nhandler> anakron: It doesn't look like you did anything about the .desktop file. You just added an icon
[04:31] <anakron> i move his installation
[04:31] <anakron> from /usr/share/games/applications to /usr/share/applications
[04:31]  * nhandler just noticed that
[04:32] <nhandler> anakron: Why is the patch you submitted to Debian different than the Ubuntu one?
[04:33] <anakron> ops
[04:33] <anakron> because that one was an old one
[04:33] <anakron> i must send the new one
[04:34] <nhandler> anakron: Since we currently sync the package from Debian, I do not feel it is worth introducing a delta for this small patch. I think it would be better to submit the patch upstream and wait for the Debian Maintainer to apply it.
[04:35] <anakron> ok
[04:35] <nhandler> I'll add a comment saying this on the bug
[04:36] <anakron> ill send a mail to debian maintainer with the debdiff
[04:36] <persia> Also, since Debian and Ubuntu have a common, and well-integrated Games team, it doesn't make sense to introduce Ubuntu-specific deltas in games (especially now that squeeze is open), unless there's some reason we can't use what's in the alioth SVN.
[06:08] <dholbach> good morning
[06:27] <Milyardo> Good Morning
[06:28] <Milyardo> I'm somewhat new to debian packaging, and I'm trying to package a peice of non-free proprietary software, of which I only have the binary. I've looked at dholbach's screencast on youtube, but I'm not sure how'd they apply here
[06:32] <dholbach> Milyardo: if you just have some kind of blob that needs to be installed somewhere, take a look at dh_install and maybe a simple package like ubuntu-artwork
[06:37] <Milyardo> dholbach: I'm reading the dh_install man page now, not exactly sure how it would help, could you elaborate?
[06:38] <dholbach> Milyardo: you basically put a debian/install file (or debian/<package>.install file if you have more than one binary packages) in there and describe what goes where by putting something like this in there:
[06:39] <dholbach> source_directory/some_file                usr/share/something
[06:39] <dholbach> some_other_directory                usr/lib/bla
[06:39] <dholbach> etc
[06:39] <dholbach> and dh_install will take care of it
[06:39] <dholbach> (if there's no real "build process" going on)
[06:41] <persia> Ah, there it is.  "pq" is an example of a proprietary (windows even) application packaged for Ubuntu (you can get it with apt-get source pq).  It nicely demonstrates how to drop in a prebuilt binary while using the packaging infrastructure to assist with integration and helper files.
[06:42] <Milyardo> hrrmmm... my binary is distrbuted in the form a .run file, is there a debhelper tool to extract its contents into one directory?
[06:42] <Milyardo> oh wait nevermind
[06:42] <Milyardo> I guess I could use chroot couldn't I?
[06:43] <dholbach> Milyardo: what happens if the .run file is executed? is that the application itself or does it do some "installation" of sorts?
[06:44] <Milyardo> It does the installation of the game
[06:45] <dholbach> Milyardo: then I'd run the .run script during the build process of the package, it uses fakeroot itself
[06:46] <dholbach> you might just need to adapt a few paths
[06:48] <Milyardo> I'm sorry, now I'm even more confused ._.
[06:50] <dholbach> the package build process wraps around the build process of the project itself (ie: "./configure && make && sudo make install" in a 'typical' C+autoconf scenario)
[06:51] <dholbach> you seem to have a froblicator.run script, comparable to "sudo make install" -- just a few files are put somewhere
[06:52] <dholbach> but instead of installing all files into / properly, things get installed into build_dir/debian/tmp or some such and get put into the resulting .deb package afterwards
[06:53] <dholbach> even more confused? :)
[06:54] <Milyardo> nope :)
[06:54] <dholbach> good, I hoped I made a bit of sense :)
[06:56] <Milyardo> okay so far the only thing I have, is my project directory in ~/workspace/project and the .run installer inside of it at ~/workspace/project/installer.run
[06:57] <Milyardo> The first I'd do would be to use dh_make to create the debian directory and all of the file insides inside of it, then strip it down to only the files I need
[06:57] <Milyardo> correct?
[06:58] <dholbach> sounds good
[06:59] <Milyardo> :) great, I'm going to do that now then
[06:59] <didrocks> morning o/
[07:04] <Milyardo> Okay dh_make told me it could not find a tar.gz, but that is to be expected correct? Should I speficy the .run file as an alternate with -f instead then?
[07:04] <Milyardo> Good Morning didrocks
[07:04] <didrocks> hi Milyardo
[07:07] <fabrice_sp> 'morning didrocks and dholbach !
[07:07] <dholbach> hi fabrice_sp
[07:07] <didrocks> hey fabrice_sp!
[07:13] <Milyardo> or should I put the .run file into a tarball?
[07:14] <persia> Put the .run file in the tarball, and call it an orig.tar.gz.  Document that you did this in debian/README.source
[07:14] <Milyardo> will do
[07:14] <Milyardo> thanks
[07:15] <Caesar> Hi, is there a way to tell when a package was uploaded to gutsy-backports?
[07:16] <persia> Caesar, You can look at the LP entry.  Which package?
[07:16] <Caesar> persia: puppet
[07:16] <persia> https://launchpad.net/ubuntu/puppet
[07:17] <persia> Err.
[07:17] <Caesar> persia: thanks
[07:17] <persia> https://launchpad.net/ubuntu/+source/puppet
[07:17] <persia> Yeah.  Just scroll down and it has the publication date.
[07:33] <Milyardo> http://pastebin.ubuntu.com/119123/
[07:34] <Milyardo> I'm baffled as to why dh_make cannot findmy tarball
[07:36] <ara> hello all! is tomboy package broken for you guys in Jaunty?
[07:51] <Milyardo> http://pastebin.ubuntu.com/119124/
[07:51] <Milyardo> I remade the tarball no luck still
[07:51] <Milyardo> :(
[07:53] <slytherin> directhex: ping
[08:21] <directhex> slytherin, pong, but i'm about to catch a bus. back in ~30
[08:22] <slytherin> directhex: ok, talk to you later
[08:22] <TheMuso> Anyone around who can change my status on revu from contributor to MOTU?
[08:26] <directhex> actually, bugger, i have things i need to sort here first
[08:26] <directhex> what's up?
[08:28] <slytherin> directhex: yesterday I did dist-upgrade on jaunty. It upgraded f-spot but removed tomboy and bunch of -cil packages. Thought you would like to know.
[08:29] <ara> slytherin: that happened to me as well
[08:30] <geser> slytherin: there is a gnome-sharp transition going on and tomboy is in progress
[08:31] <slytherin> ok
[08:32] <geser> see bug 314516
[08:34] <jms_> slytherin: sorry, you'll have to repeat anything from the last few minutes. my office pc decided now was a brilliant time to implode. and it's also my irc gateway.
[08:36] <slytherin> jms_: never mind, I got my answers. I was checking why tomboy got removed on dist-upgrade yesterday on a jaunty installation.
[08:39] <jms_> i wish my office pc hadn't died
[08:44] <jms_> there it goes
[08:48] <slytherin> persia: just FYI ... I have uploaded libnb-platform-java today, packages are in new queue now.
[08:51] <petski> Anyone so kind to sponsor the upload of the debdiff attached to #77980 ?
[08:53] <slytherin> bug 77980
[08:55] <petski> The bug is there since early 2007, would be cool to have it fixed in jaunty :)
[09:06] <jms_> hm, it now seems to be booting at ~1mhz
[09:09] <directhex> i'm back, baby!
[09:47] <sistpoty|work> hi folks
[09:52] <sistpoty|work> StevenK: would you like to act as motu-release delegate for MID and netbook?
[09:53] <Juli_> slytherin: Hi, I've just came back. Thank you a lot for libnb-platform-java. Have you had any problem with this package?
[10:00] <slytherin> Juli_: yes, it took lot of time to build on my ibook. :-)
[10:01] <Juli_> slytherin: oh yes, this is a problem:) but netbeans takes even more time:)
[10:02] <slytherin> Juli_: I will build ide on my PC. but I will have to free some space in home folder for that.
[10:02] <directhex> try building OOo you moaners
[10:04] <Juli_> slytherin: hope it is not too difficult for you... for me my home folder is the holy of holies:)
[10:04] <slytherin> directhex: I tried once. Didn't know it needed 5+ GB of space to build. :-)
[10:04] <directhex> slytherin, and 8-10 hours on a fast system
[10:05] <slytherin> Juli_: How much is the source download?
[10:06] <Juli_> slytherin: let me see
[10:06] <slytherin> Juli_: and does it have build dep on libnb-platform-java?
[10:06] <Juli_> slytherin: yes it has
[10:07] <slytherin> Juli_: then we will have to wait for the packages to clear NEW queue anyway.
[10:07] <slytherin> Juli_: in any case, I am in office right now, so I won't be building the ide package.
[10:08]  * directhex awaits a lib clearing NEW, hopes it happens pretty sharpish so he can sign off on the mono 2.0 app transition as complete
[10:08] <Juli_> slytherin: yes I understand. just tell me if you need any help from me:)
[10:08] <Juli_> slytherin: unpacked netbeans sources is about 239 MB
[10:09] <slytherin> that is huge. :-)
[10:09] <Juli_> slytherin: but orig.tar.gz is just 35 MB:)
[10:10] <slytherin> Juli_: By the way, may I know the reason why you wanted to have version in libnb-platform-java package name?
[10:11] <Juli_> slytherin: there was a big correspondence half a year ago...
[10:12] <slytherin> Juli_: yes, persia told me that. But I was too sleepy to actually ask him any links to the conversation.
[10:13] <Juli_> slytherin:  I'm afraid there is no access outside to this conversation
[10:13] <slytherin> ok
[10:14] <Juli_> slytherin: as far as I remember This is requirement for platform to have multiple platform versions on one system
[10:15] <slytherin> Juli_: but then why the 'Conflicts' between different version. How can you install different versions if you have conflicts
[10:15] <Juli_> slytherin:  persia said that for most libraries, there is only one source package, and the binary names are changed when there is an incompatible ABI change
[10:16] <Juli_> slytherin:  and everybody decided it is ok to have one source package but still change names
[10:17] <slytherin> Juli_: but then does the conflict make sense? those packages can not be installed in parallel.
[10:18] <Juli_> slytherin: why? actually Conflicts are in libnb-platform-devel-java only
[10:19] <slytherin> Juli_: ahh, right. my mistake
[10:20] <Juli_> slytherin: and as far as i remember visualvm depends on platform8
[10:20] <slytherin> Juli_: so will we need to rebuild visualvm?
[10:21] <Juli_> slytherin: i think I should ask doko about that
[10:21] <slytherin> ok
[10:21] <slytherin> Juli_: just FYI ... I made a small change in watch file to deal with weird upstream version.
[10:21] <Juli_> slytherin: i'll write him right now to be sure everything will be ok with visualvm
[10:23] <Juli_> slytherin: ok, thanks. It is a good chance for me to improve my packaging skills - by the example of your:)
[10:25] <StevenK> sistpoty|work: Hmm. I could be convinced
[10:25] <sistpoty|work> StevenK: excellent!
[10:25] <sistpoty|work> thanks StevenK
[10:26] <StevenK> I said I could be convinced, not yes :-P
[10:26] <slytherin> does anyone know why do we have backport bugs in u-u-s? We have a separate backport team don't we?
[10:27]  * sistpoty|work tries to convince StevenK
[10:30] <sistpoty|work> StevenK: please, please, with sugar on the top ;)
[10:32] <StevenK> sistpoty|work: Heh, okay
[10:38] <sistpoty|work> StevenK: thanks :)
[10:45] <sistpoty|work> btw.: any archive-admin around who knows why sabnzdplus was rejected? maybe ScottK?
[10:46] <Laney> it was? :(
[10:47] <sistpoty|work> yep, got the reject mail (as uploader) yesterday
[10:47] <Laney> sistpoty|work: probably best -> devel
[10:48] <Laney> (does the mail not say why?)
[10:49] <sistpoty|work> Laney: no, that's why I'm asking :)
[10:53] <jcfp> sistpoty|work: apparently Apache and GPL-2 can't live together
[10:54] <sistpoty|work> jcfp: ah, eww...
[10:55] <jcfp> sistpoty|work: did a repack, has been reuploaded already
[10:56] <sistpoty|work> jcfp: ah, good :)
[10:56] <jcfp> which reminds me - still have to poke upstream about that
[10:56] <sistpoty|work> jcfp: also about the generated javascript thingies...
[10:59] <jcfp> sistpoty|work: should they include the stuff in the tarball, or is having the javascript "non-packed" in a public repository good enough (their own, or further upstream)?
[10:59] <jcfp> cause I know they're gonna say it's for saving bandwidth etc, hard to argue with :)
[11:00] <sistpoty|work> jcfp: I'm not entirely sure actually in regards to ubuntu guidelines... from a legal POV it's nothing to worry, since the original source is BSD licensed
[11:01] <jcfp> siretart: yeah, found a discussion on some debian mailing list, lots of argument about whether the packed js should be considered sources or not
[11:02] <Laney> I have gpg set up to auth with gpg-agent using pinentry-gtk2, but now it fails when called over SSH remotely. How can I get the two to live in harmony?
[11:02] <sistpoty|work> jcfp: ah, what was the outcome?
[11:04] <jcfp> sistpoty|work: opinions differed, some thinking it is as long as function names are kept (rather than replaced by a(), b() etc) and that a simple script allows to get back an easier to read file, others argued the source should be the preferred format for making mods, saying that it wasn't
[11:05] <jcfp> (in their case, the stuff was under gpl so it really did matter)
[11:05] <sistpoty|work> ah, k
[11:05] <morgs> james_w: ping
[11:06] <jcfp> sistpoty|work: appears I bookmarked it http://lists.debian.org/debian-devel/2009/01/msg00584.html
[11:09] <james_w> hey morgs
[11:09] <morgs> hi james_w, thanks for looking at my tickets
[11:09] <morgs> james_w: Here's what happened: to get the directory structure used previously I had to repack the tarballs
[11:10] <morgs> james_w: The upstream tar.bz2 has Read-63/foo but the orig.tar.gz has sugar-read-activity-63/Read.activity/foo
[11:11] <slytherin> hey, an off topic question. Does anyone know what is exact license for bugzila? I am not able to find any information at http://www.bugzilla.org/about/
[11:11] <james_w> morgs: ah
[11:12] <morgs> james_w: is that a problem? Should I change the packaging?
[11:12] <james_w> morgs: if you repack the tarball then you should use a suffix to the version number to indicate that
[11:12] <james_w> morgs: is it required to repack?
[11:13] <morgs> If I changed more in debian/ then it wouldn't be required - although upstream has tar.bz2 so recompressing at least is required
[11:13] <james_w> yeah
[11:26] <loic-m> Is there a way to tell tar to unpack a tarball in a certain directory instead of at the directory it's run in?
[11:27] <Laney> tar -C /foo
[11:27] <hmg> Hello ubuntu people - sorry if I'm asking Questions you'll probably get to read over and over - but I'm stuck in the workflow of contributing packages to ubuntu (to be released in "universe") - I'm not ubuntu proof and I've just created my launchpad account - so I'v got no experience - sorry for that. My problem: I've uploaded our tar.gz files we've build and optimized for ubuntu 9.04. I've used the upload functions of launchpad you may find th
[11:27] <directhex> jcfp, isn't javascript often whitespace-purched to save bandwidth?
[11:28] <directhex> hmg, your irc client cut you off.
[11:29] <hmg> ping (am I alive?)
[11:29] <hmg> ok - the short version: https://code.launchpad.net/x2go/trunk/2.99 -> wrong place for rfp?
[11:30] <loic-m> thx a lot Laney
[11:30] <jcfp> directhex: I suppose so, fafaik all the sabnbzdplus authors did was take an off-the-shelf-without-tabs-and-spaces js file directly from the plotkit project.
[11:31] <jcfp> directhex: but then again, one could also strip newlines (also fairly common), or go even further and "shorten" var and function names.
[11:31] <loic-m> hmg: not an expert, but at least I can tell you your tar.gz shouldn't contain a debian folder
[11:32] <jcfp> directhex: and then the question rises whether and/or when is it still source code... even if there's no intention to obfuscate anything
[11:32] <loic-m> hmg: make tar.gz without debian folder, then debian folder is created during packaging (will be in the diff.gz
[11:33] <hmg> loic-m: the debian folder contains our install scripts like postinstall
[11:33] <directhex> jcfp, perhaps your JS IDE should make "verbose" whitespace for editing, but save minimally? :)
[11:34] <directhex> jcfp, at that point, if such a thing exists, surely "obfuscated" JS *is* legit?
[11:34] <hmg> loic-m: without them a user will have a lot of things to do to get the server running
[11:34] <hmg> loic-m: but thank you for youf advice - i'll keep them in another place
[11:37] <loic-m> hmg: AFAIU distribution packagers (Debian, Ubuntu) would have to remove the debian folder before packaging
[11:38] <jcfp> directhex: some claim one could easily regain pleasantly readable code even from code that has everything stripped (but nothing intentionally obfuscated), which comes down to the same thing as having some IDE do that automatically
[11:38] <loic-m> hmg: so not having a debian folder in the upstream tarball simplify the packager's life
[11:39] <loic-m> hmg: if upstream tarball need to be repackaged, that means somebody has to write a get-orig-source rule, which can be painful
[11:39] <ScottK> jcfp: That's rather irrelevant, since we require source to be in its preferred form for modification.
[11:40] <ScottK> loic-m: It isn't required to remove an upstream debian dir, but generally they cause more problems than they solve.
[11:43] <jcfp> ScottK: the slighty packed js could be the preferred form for mods, with an ide behaving like in directhex's example
[11:43] <directhex> does such a thing exist? dunno
[11:43] <loic-m> ScottK: I didn't know, thanks for the correction
[11:44] <jcfp> no idea, I stay away as far as I can from touching js, but it doesn't seem inconceivable.
[11:45] <Laney> I guess the idea is to compress the readable source file at build-time
[11:45] <Laney> much like compilation
[11:48] <directhex> yay conjecture :)
[11:48]  * Laney rolls pies
[11:49] <loic-m> Is there a way to tell tar to archive a subdirectory without including in the archive the parent directory - say I want to archive repack/foo-version but don't want the "repack" path inside the archive ?
[11:49] <Laney> --strip-components
[11:50] <loic-m> Thanks again Laney. You should have written tar's man page ;)
[11:50] <Laney> loic-m: I just needed to read it ;)
[11:51] <loic-m> Laney: I read it, but I never get the meaning of the options right
[11:51] <directhex> is acking a sync request a MOTU job?
[11:51] <directhex> no, wait, crap, main. core-dev
[11:51] <directhex> sigh, stupid main
[11:51] <Laney> whoever can upload
[11:55] <directhex> if it was in universe i'd poke you viciously, but the core devs look busy. i'll be good & leave i to the u-m-s gods
[11:56] <Laney> I'm sure super seb would love to ack it
[11:56] <Laney> if it fixes f-spotness
[11:59] <petski> Anyone so kind to sponsor the upload of the debdiff attached to bug 77980 ?
[12:00] <loic-m> When writting get-orig-source target, the resulting orig.tar.gz should be two directories above debian -=same directory uscan puts the files in)?
[12:00] <Laney> loic-m: It should be in the current directoyr
[12:03] <loic-m> which is the directory parent to foo-version/ ?
[12:13] <slytherin> loic-m: I prefer it to be in same directory as where uscan puts files.
[12:15] <loic-m> slytherin: that should be ok then. I'm putting it in the directory above foo-version/, which is where uscan puts its files
[12:16] <loic-m> before I submit the diff.gz to Launchpad, can MOTU review my xvidcore get-orig-target rule at http://paste.ubuntu.com/119175/ and the copyright at http://paste.ubuntu.com/119172/ ?
[12:17] <loic-m> (I checked the get-orig-source rule works as expected)
[12:23] <loic-m> ...and possibly check I didn't mess up the changelog ;) : http://paste.ubuntu.com/119179/
[12:26] <incorrect> i am trying to package up openldap 2.4.14 and i am puzzled why my openldap_2.4.14.orig.tar.gz isn't being decompressed into debian/build
[12:28] <directhex> erm... debian/build?
[12:29] <incorrect> hang on something is totally screwed
[12:49] <Laney> slytherin, loic-m: Policy says that get-orig-source should leave the resulting file in the current directory
[12:49] <slytherin> Laney: really? Till now I haven't seen any get-orig-source designed that way.
[12:49]  * Laney shrugs
[12:52] <directhex> DktrKranz, are you on jaunty? i could build a fixed mono-addins package for my ppa, so you can try monodevelop 2. if you like. and if it helps grease the wheels of slightly-missing-FF-but-its-so-awesome-lets-let-it-in-anyway
[12:54] <directhex> especially since md2 might be delayed by a few days due to the debian kde team
[13:03] <morgs> james_w: got a moment? I'm having a problem installing files into the right places.
[13:12] <DktrKranz> directhex: yes, I use jaunty
[13:13] <directhex> DktrKranz, let me yank the debian m-a package then & dput it
[13:14] <DktrKranz> directhex: I won't be able to test it until this evening, so you can delay it if you have more urgent tasks
[13:15] <directhex> DktrKranz, nothing i'm going to get done in the next 45 mins
[13:16] <DktrKranz> anyway, gnome# transition is almost done! \O/
[13:17] <directhex> DktrKranz, yay! and the problem children with their gnome panel nonsense?
[13:17] <DktrKranz> only three packages were affected
[13:17] <directhex> tomboy being the high-profile one
[13:18] <DktrKranz> and patch to fix them is already upstream, so I think Debian would have a easy transition too
[13:18] <DktrKranz> (unless there are hidden ABI changes)
[13:19] <DktrKranz> directhex: in yesterday meeting, we went long and overlapped with another meeting, so I haven't the chance to discuss about it
[13:19] <directhex> DktrKranz, i know, i read the log :/
[13:20] <DktrKranz> I think you should file a bug about monodevelop upgrade and subscribe motu-release for preliminary review
[13:20] <directhex> DktrKranz, in my brief tinkering though, MD2 seems lovely, once the bugged mono-addins is updated
[13:21] <DktrKranz> My mono fanboy is learning Python :)
[13:21] <DktrKranz> but he will try MD2 as well
[13:21] <DktrKranz> He had issues with previous alpha versions, though
[13:21] <directhex> how should i title this bug?
[13:24] <DktrKranz> "Monodevelop: road to 2.0" (or the correct version)
[13:36] <loic-m> Laney: DPM says "This target may be invoked in any directory" so if i want to leave the orig.tar.gz in the same directory uscan leaves the tar, I just have to invoke it in that same dir (above foo-version/, same dir the .dsc ar produced in) no?
[13:37] <directhex> DktrKranz, k.
[13:37] <loic-m> or doesn "current directory" means debian, debian/.. or something else?
[13:38] <Laney> loic-m: Right. But anyone else may also invoke it where they feel
[13:39] <loic-m> oh, it means that...
[13:40] <loic-m> right, I've got to modify my get-orig-target then...
[13:40] <loic-m> Laney: any package you worked on where I can use the get-orig-source as an exemple?
[13:42] <maxb> Does the DPM explain where you are supposed to leave the tar?
[13:42] <maxb> relative to the package, or relative to the invocation wd?
[13:43] <loic-m> maxb: "in the current directory" see http://www.debian.org/doc/debian-policy/ch-source.html
[13:43] <directhex> DktrKranz, bug 330519
[13:44] <sistpoty|work> directhex: do you have an estimate how many packages will need to be touched to reach the end of the road?
[13:45] <directhex> sistpoty|work, beyond the mono-addins sync (which will help other things)? monodevelop itself plus five or six plugins
[13:45] <sistpoty|work> directhex: ah, k, so no effect on other packages besides these?
[13:45] <directhex> sistpoty|work, indeed. it's pretty self-contained
[13:46] <sistpoty|work> directhex: :)
[13:46] <directhex> sistpoty|work, give it a punt, it's in my PPA
[13:46] <sistpoty|work> directhex: sorry, won't be able to test it until this weekend or so :/
[13:47] <maxb> debian/rules presumes, gnu make, right? so you can do locating the DEBIAN_DIR in pure make expansions $(dir $(firstword $(MAKEFILE_LIST)))   - no need for shell
[13:50] <directhex> sistpoty|work, our attention is being diverted in debian since post-lenny, a lot of teams we've been interoperating with in experimental need us in place in unstable (e.g. kde team for kdebindings). so i hope to get monodevelop-database done this afternoon. hopefully
[13:51] <sistpoty|work> ah, I see
[13:52] <directhex> sistpoty|work, i think hitting FF is... optimistic. but not unexpected - http://www.mail-archive.com/ubuntu-motu@lists.ubuntu.com/msg04950.html
[13:52] <sistpoty|work> directhex: I guess if upstream is aware of our release schedule and offering help to get 2.0 into jaunty, I don't see too big problems with being late
[13:53] <directhex> sistpoty|work, i've been badgering them since november. like a badger!
[13:53] <sistpoty|work> heh
[13:54] <directhex> unless the gnome team move immediately in debian too, then it'll need to be merged not synced, for gnome# 2.24
[13:54] <james_w> hello morgs, back now
[13:54]  * Panarchy says Hi
[13:55] <Panarchy> Interested in getting into the packaging of different tools for Ubuntu
[13:55] <Panarchy> Is this the right place to ask questions?
[13:55] <directhex> Panarchy, yes, and the usual response is "start wiuth bug fixes and/or upstream version updates"
[13:56] <directhex> and don't overreach. you don't know enough to package the kernel yet
[13:56] <Panarchy> Nope, I know what tools I would like to package
[13:56] <Panarchy> (about 120)
[13:56] <Panarchy> Can I please have a recommendation of a tool (haven't tried checkinstall yet, so don't know if it can do this) that can create .deb's from source code (./configure, make, make install/checkinstall) but which can also allow me to put in my name (as Maintainer) and a Description?
[13:58] <sistpoty|work> Panarchy: you're asking exactly for dpkg :)
[13:58] <Panarchy> Since I have so many packages I would like to install, I want to make it as 'easy' as possible for me to do what needs to be done: Packaging the tool into a .deb | Having a description | Including that I am maintainer | Including version number. Can I please have a recommendation?
[13:58] <directhex> Panarchy, checkinstall is a big red "no chance" sign as far as official archive inclusion goes
[13:59] <Panarchy> sistopy|work: dpkg-dev? :P
[13:59] <Panarchy> directhex: But can checkinstall do what I would like done?
[13:59] <sistpoty|work> Panarchy: there are lot's of stacks that lay above dpkg, (e.g. debhelper or cdbs)... but some tasks are still manual work like e.g. writing manpages or checking copyright
[13:59] <Panarchy> I don't need to worry about copyright or anything... dunno how manpages work though
[13:59] <directhex> Panarchy, depends. do you want your stuff to ever appear in the ubuntu archive?
[14:00] <Panarchy> Not sure
[14:00] <Panarchy> Want to make these 120 packages first, then decide
[14:00] <Panarchy> Might make my own repostiory and put it on launchpad. Haven't decided yet
[14:00] <directhex> 120 packages from 120 source tarballs?
[14:00] <Panarchy> yes
[14:01] <Panarchy> well tar, tar.gz, .gz & .zip (think there was a .rar as well)
[14:01] <Panarchy> Is there an Ubuntu-Motu part of the ubuntuforums?
[14:01] <directhex> the archive only understands .tar.gz. repacking will be needed.
[14:01] <Panarchy> As I could better rephrase myself there
[14:01] <Panarchy> directhex: Don't mind!
[14:02] <Panarchy> Is there an Ubuntu-Motu part of the ubuntuforums?
[14:02] <james_w> morgs: and shouldn't read depend on the fixed version of evince? :-)
[14:02] <sistpoty|work> Panarchy: are all these things written by yourself?
[14:03] <Panarchy> sistpoty|work: Nup!
[14:03] <sistpoty|work> Panarchy: ah, k... (because then I'd just use a common build system and a script to turn these into packages)
[14:03] <Panarchy> Should I ask it on the forum here: Ubuntu Forums > The Ubuntu Forum Community  > Other Community Discussions  > Development & Programming  > Repositories & Backports
[14:03] <Panarchy> ?
[14:04] <sistpoty|work> Panarchy: but then if you want to publish these things, you *must* worry about copyright :P
[14:04] <Panarchy> Well, it's 1AM here, I'd quickly like to post my question on the ubuntuforums, then go to sleep
[14:05] <Panarchy> please tell me where to post a (more detailed, better set out) question on the forums about packaging
[14:05] <Panarchy> Thanks
[14:05] <sistpoty|work> Panarchy: you're more likely to hit MOTUs either right here or on the mailing list <ubuntu-motu@lists.ubuntu.com> than in the forums
[14:05] <luisbg> is there a guide somewhere to package a python app with cdbs? I can't find it :(
[14:05] <kirkland> persia: thanks for the package review
[14:05] <kirkland> persia: i'm struggling with the Launchpad syntax for the debian/watch file for
[14:05] <kirkland> persia: http://launchpad.net/screenbin/screenbin/1.1/+download/screenbin_1.1.orig.tar.gz
[14:06] <kirkland> persia: this doesn't seem to work:
[14:06] <kirkland> http://launchpad.net/screenbin/screenbin/(.*)/+download/screenbin_(.*).orig.tar.gz
[14:06] <Panarchy> what's the work for requirements
[14:07] <Panarchy> ah
[14:07] <Panarchy> dependencies
[14:07] <kirkland> persia: looks like some confusion with (a) two version bits in the string, (b) doesn't like the "+" in +download (tried escaping it)
[14:07] <petski> kirkland; try to do this (.+?)
[14:07] <petski> kirkland, the questionmark tells the re-handler to be "ungreedy"
[14:08] <kirkland> petski: hmm, lots of noise, then uscan ends with:   no matching hrefs for watch line
[14:08] <kirkland>   http://launchpad.net/screenbin/screenbin/(.+?)/+download/screenbin_(.+?).orig.tar.gz
[14:10] <sistpoty|work> kirkland: I'm not entirely sure if uscan can actcually have wildcards for http pathes in the first place
[14:10] <kirkland> sistpoty|work: it can...  i have it working elsewhere
[14:11] <kirkland> sistpoty|work: but not with launchpad
[14:11] <sistpoty|work> kirkland: oh, nice
[14:11] <sistpoty|work> kirkland: maybe LP disallows to list the directory where the wildcard is?
[14:11] <kirkland> sistpoty|work: yeah, i think it has something to do with the +download
[14:12] <kirkland> sistpoty|work: i think that's some sort of a cgi action, rather than a real directory
[14:12] <sistpoty|work> kirkland: right, I guess that might screw it
[14:12]  * kirkland applies his old web terminology to launchpad's newfangled web technology
[14:12] <kirkland> okay, no worries, i'm going to skip the watchfile for now
[14:13] <kirkland> it's really low priority
[14:13] <sven777> would a MOTU be so kind as to review my package?  Thanks in advance!  http://revu.ubuntuwire.com/p/lmalinux
[14:13] <Panarchy> Okay, posted it on the Debian forums and the Ubuntu forums
[14:15] <Panarchy> I've written two topics, on two different forums | Here: http://forums.debian.net/viewtopic.php?t=35836 and here: http://ubuntuforums.org/showthread.php?t=1072332 | Please try and reply to one of them, telling me your advice on the subject (Creating .deb packages, quickly, including description, dependencies, version number, tool name & maintainers name") Thanks in advance!
[14:20] <petski> kirkland, I looked into the source code of uscan and for http it needs an page containing the URL to the .tar.gz (or whatever). http://launchpad.net/screenbin/screenbin/1.1/+download/ gives 404
[14:21] <kirkland> petski: agreed
[14:21] <kirkland> petski: i saw the same thing (404 for +download)
[14:21] <petski> kirkland, somebody made a "hack" in uscan for SourceForge packages: http://qa.debian.org/watch/sf.php
[14:22] <petski> kirkland, you could do something simular for LP
[14:25] <slytherin> petski: simply https://edge.launchpad.net/screenbin/screenbin/1.1 will work
[14:26] <kirkland> slytherin: it chases a bunch of links on that page
[14:26] <kirkland> slytherin: and thinks that "+subscribe" is the latest version :-)
[14:27] <maxb> what's the point of a watchfile pointed at a pinned version, though?
[14:27] <slytherin> kirkland: tried this - https://edge.launchpad.net/screenbin/screenbin/1.1 .*screenbin_([\d\.]*).orig.tar.gz ??
[14:27] <kirkland> slytherin: lemme try
[14:28] <kirkland> sladen: oh, wait, the first 1.1 needs to be variable too
[14:28] <mneptok> magic, fear, and superstition. this is the Curse Of The Mekons.
[14:29] <slytherin> kirkland: how about using this url instead - https://edge.launchpad.net/screenbin/+download :-D
[14:30] <slytherin> kirkland: this should work - https://edge.launchpad.net/screenbin/+download ﻿*screenbin_([\d\.]*).orig.tar.gz
[14:31] <kirkland> Nested quantifiers in regex; marked by <-- HERE in m/^(?:(?:https://edge.launchpad.net)?\/screenbin\/\+download)?* <-- HERE screenbin_([\d\.]*).orig.tar.gz$/ at /usr/bin/uscan line 889, <WATCH> line 6.
[14:38] <slytherin> kirkland: here is a working version - http://paste.ubuntu.com/119223/
[14:38]  * kirkland tries
[14:38] <kirkland> slytherin: that looks better
[14:39] <kirkland> slytherin: thanks, man :-)
[14:39] <slytherin> welcome
[14:39] <slytherin> :-)
[15:06] <bddebian> Heya gang
[15:06] <ScottK> o/
[15:10] <sistpoty|work> hi bddebian
[15:11] <bddebian> Heya ScottK, sistpoty|work
[15:12] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[15:20] <Laney> AndrewGee: Not reviewed, but have you considered licensing your packaging as GPL3+ too?
[15:21] <AndrewGee> Laney: I think I did that.
[15:21] <Laney> it is gpl3 only
[15:22] <AndrewGee> Ah.
[15:22] <AndrewGee> How would I specify 3+ ?
[15:22] <Laney> "GPL-3 or later"
[15:22] <Laney> or so
[15:23] <AndrewGee> Ok. Will do :) Thanks Laney.
[15:30] <jcfp> if an author says some code is licensed under GPL, without specifying which version(s), how should I read that? "all versions"?
[15:31] <Laney> jcfp: I think I saw someone say that assumes GPL1, but take that with a truckload of salt
[15:32] <jcfp> Laney: even if that author's staement is made recently, i.e. no chance that is was made when only GPL v1 existed?
[15:32] <Laney> it's best to avoid ambiguity in these situations anyway
[15:32] <jcfp> I know, I know.... but still this must be fairly common
[15:33] <Laney> someone could still intentionally use GPL1 if they wanted
[15:33] <Laney> look on debian-legal to see if it's come up before
[15:34] <incorrect> packing is a really pain in the ass,
[15:34] <Laney> how so
[15:34] <incorrect> well i am packaging up openldap 2.4.14
[15:35] <incorrect> it needs more up to date libs, and loads of other stuff
[15:36] <incorrect> i was lazy and took the debian dir from the intrepid release and modified it
[15:36] <ScottK> Since Perl is still licensed GPL 1+ or Artistic, GPL 1 does come up.
[15:37] <ScottK> If in doubt, I'd ask.
[15:38] <jcfp> ScottK: I'll try - but in case of no response, what to assume? No version = any?
[15:39] <ScottK> I'm not sure.
[15:39] <jcfp> no precendent?
[15:41] <ScottK> Not that I'm familiar with.  I'm sure there is one.
[15:42] <jcfp> Couldn't find one myself either; guess I'll have to try mailing the author (again)
[15:44] <luisbg> so I've dput a package to revu and my ppa (half an hour ago) and it doesnt show in any of them :(
[15:49] <maxb> luisbg: Regarding PPA, be very sure that your .changes file was properly named, properly signed, and the signing key known to Launchpad. If it doesn't manage to process the .changes, it doesn't know who did the upload, so silently drops it
[15:51] <luisbg> maxb, gpg: Good signature from ... freemix_0.2_source.changes: done. ... Successfully uploaded packages.
[15:52] <dholbach> hiya luisbg!
[15:52] <luisbg> dholbach, hey dholbach :)
[15:52] <luisbg> how are things going?
[15:52] <dholbach> very good, very good - how are you?
[15:52] <maxb> luisbg: And the key is definitely known to launchpad?
[15:52] <luisbg> dholbach, good good :) finally some sun in Ireland
[15:53]  * dholbach hugs luisbg
[15:53] <maxb> If so, head over to #launchpad, and maybe one of the admins can dig around in its guts and find why it ate your upload.
[15:54]  * luisbg grabs dholbach's ass since he has the chance :P feels like valkan beats
[15:54] <luisbg> maxb, going to check if its the same GPG key as launchpad has
[15:54] <luisbg> maxb, but revu shouldn't have that problem, right?
[15:54] <dholbach> haha
[15:55] <maxb> luisbg: For REVU, you need to have logged into REVU's web interface at least once before uploading
[15:55] <maxb> And I think the same thing about keys applies there too
[15:56] <luisbg> maxb, I logged in before uploading
[15:56] <luisbg> dholbach, how was having everybody at Berlin? stress of the host got to you?
[15:56] <luisbg> maxb, thanks for the awesome help
[15:56] <dholbach> luisbg: it's all good here - cold but beautiful, lots of snow
[15:57] <luisbg> :)
[15:57] <luisbg> dholbach, I'm trying to push freemix before feature release hits us :P
[15:57] <dholbach> I should have taken the camera with me today, when I was taking the dog out
[15:58] <dholbach> luisbg: NICE
[15:58] <dholbach> awesome
[15:58] <luisbg> the only two things that make 0.2 a beta
[15:59] <luisbg> are intrepid/hardy related (pygobject 2.16 and gstreamer bug recently fixed)
[15:59] <luisbg> so it is ready for massive use by videogeeks in jaunty \m/
[16:07] <DktrKranz> directhex: thanks, I'll try it out this eve
[16:11] <slytherin> ember: Do you have any idea how is brasero-nautilus integration supposed to work?
[16:15] <sistpoty|work> slangasek: do you plan to make an announcement for feature freeze? I'd have a list of motu-release delegates for you ;)
[16:17] <slangasek> sistpoty|work: yes - please feed me your list
[16:18] <sistpoty|work> slangasek: http://paste.ubuntu.com/119275/
[16:18] <slytherin> slomo: Do you have any objection if I work on sync/merge of libdvdread/libdvdnav from Debian unstable?
[16:19]  * sistpoty|work hopes he got all names written correctly *g*
[16:19] <slomo> slytherin: no
[16:24] <ember> slytherin left click on a file used by brasero (eg iso)
[16:24] <ember> you should have two, one from ncb and other from brasero
[16:25] <slytherin> ember: But ncd is removed, right?
[16:25] <slytherin> ncb
[16:25] <ember> slytherin not yet, but brasero will replace ncb
[16:27] <slytherin> ember: oh, since I didn't see any 'CD/DVD Creator' menu in nautilus (Go menu) I thought ncb was removed.
[16:32] <slytherin> Does anyone have any idea why is python3.0-minimal is being pulled every time I try to dist-upgrade a jaunty installation?
[16:32] <sistpoty|work> slytherin: maybe it's Essential:Yes?
[16:33] <slytherin> sistpoty|work: I don't understand.
[16:33] <sistpoty|work> slytherin: apt-cache show python3.0-minimal | grep Essential
[16:33] <sistpoty|work> slytherin: if that's not the case, I'd check the rdepends of python3.0-minimal
[16:34] <slytherin> sistpoty|work: python3-minimal is essential
[16:34] <sistpoty|work> slytherin: then that's the reason it's pulled in ;)
[16:34] <slytherin> and I wonder why, the package is in universe
[16:35] <sistpoty|work> slytherin: maybe it still needs to get promoted to main? (or the essential:yes thingy is a bug)
[16:36] <ScottK> That's a bug.
[16:36] <ScottK> doko: ^^^^
[16:36] <slytherin> considering python3 is so new, none of the packages use it and it brings backward compatibility, I don't think it will get promoted so soon.
[16:36] <slytherin> s/brings/breaks
[16:38] <james_w> It may have been a copy/paste issue from the python 2 packaging
[16:38] <james_w> file a bug in the issue
[16:38] <ScottK> No, it's not planned to.
[16:38] <ScottK> That's why I say it's a bug.
[16:40] <slytherin> ok. I will file a bug
[16:44] <slytherin> a bug 273359 was already filed and fixed in intrepid. Should I reopen it?
[16:45] <ScottK> I'd file a new one.
[16:46] <luisbg> maxb, revu keeps ignoring my dputs and I have my gpg key in my launchpad account, I'm sure because my ppa saw the dput
[16:49] <slytherin> ScottK: done. bug 330613
[16:49] <sistpoty|work> luisbg: first reviewer feedback from the rejected queue: freemix is a native package, intended?
[16:49] <sistpoty|work> (I'll take a look why revu doesn't like it)
[16:52] <luisbg> sistpoty|work, I dont understand completetly
[16:53] <sistpoty|work> luisbg: there's no .orig.tar.gz/.diff.gz for the package, only a .tar.gz (which makes it a native package)
[16:53] <sistpoty|work> luisbg: but that's not the reason why revu rejected your package, it says, it cannot find your key :/
[16:54] <luisbg> sistpoty|work, it is a native package... I coded the app myself, and build the package from my source branch, should I include a tarball?
[16:55] <luisbg> sistpoty|work, maybe revu hasnt updated the key from launchpad yet
[16:55] <sistpoty|work> luisbg: yes, please include a tarball... makes work for derivatives much easier :)
[16:56] <LaserJock> sistpoty|work: is there a wiki page on motu-release delegation?
[16:56] <sistpoty|work> luisbg: well, last keyring sync from lp was 1 and a half hours ago (not too sure though, how I can trigger it by hand)
[16:56] <sistpoty|work> LaserJock: nope
[16:56] <luisbg> sistpoty|work, so I will have to wait for the next sync
[16:57]  * sistpoty|work looks through crontab entries
[16:57] <ScottK> sistpoty|work: Since you're our library expert....  Would you please take a look at the gpgme1.0 merge and tell me if you think we should take that change for Jaunty?
[16:57] <sistpoty|work> ScottK: got a link?
[16:57] <ScottK> sistpoty|work: Sure.  Just a moment.
[16:57] <LaserJock> so how does motu-release know what packages to delegate?
[16:58] <slytherin> luisbg: did you ever log in to revu before uploading the package?
[16:58] <ScottK> sistpoty|work: http://merges.ubuntu.com/g/gpgme1.0/REPORT http://packages.debian.org/changelogs/pool/main/g/gpgme1.0/current/changelog
[16:59] <luisbg> slytherin, yeap :)
[16:59] <ScottK> LaserJock: It's mostly up to the judgement of the delgatee.  Your catagory is a bit fuzzy, so I'd say whatever you're confortable with.
[16:59] <luisbg> slytherin, "Logged in as luisbg"
[17:00] <slytherin> luisbg: And you are signing the package with same key as the one in launchpad, right?
[17:01] <LaserJock> ScottK: the only stuff we're likely to be messing with is Sugar
[17:02] <ScottK> LaserJock: OK.  I'm comfortable with you deciding what is in scope for your delgation. If in doubt, feel free to ask.
[17:02] <LaserJock> k, np
[17:03] <luisbg> slytherin, yes
[17:03] <luisbg> I am
[17:05] <sistpoty|work> ScottK: gpgme merge looks sane to me
[17:06] <ScottK> sistpoty|work: Care to do it?
[17:06] <ScottK> I will if you won't?
[17:06] <sistpoty|work> ScottK: sorry, can't upload at work, and I guess I won't come around until this weekend
[17:07] <ScottK> OK.  Thanks.
[17:11] <Riddell> mr_pouit: sion renamed to errr.. gigolo?
[17:12] <cpscotti> hey, when packing a python app, can external libraries (e.g. diacanvas or amara) go inside the package? Amara isn't in the repositories and diacanvas repository version is incompatible with the one I need...
[17:12] <Riddell> I'm surprised that hasn't caused large numbers of flame wars
[17:13] <Riddell> cpscotti: that seems very bad practice, duplication of code should be avoided
[17:13] <cpscotti> I see
[17:13] <cpscotti> but what to do when that code isn't in the repositories.. (even though it is oss)
[17:14] <LaserJock> well, you could package that up to
[17:14] <cpscotti> funny
[17:14] <cpscotti> hehehe
[17:14] <LaserJock> more work, but you help out a lot of people
[17:14] <cpscotti> yes...
[17:14] <LaserJock> so the next person who comes along doesn't have to worry about it
[17:14] <cpscotti> well.. I was expecting something like that.. but.. doesn't hurt asking..
[17:15] <cpscotti> thanx
[17:15] <LaserJock> but you may not want to invest that much time, perhaps somebody else could do it?
[17:15] <LaserJock> I'm working on untangeling a package now that shipped external libraries inside
[17:15] <LaserJock> it's not fun to go back later either :-)
[17:16] <cpscotti> hmm
[17:16] <cpscotti> how are you shipping those libraries?
[17:16] <cpscotti> .so ?
[17:17] <LaserJock> well, in my case it's PHP so it just does a copy of the .php files
[17:17] <cpscotti> I see
[17:17] <cpscotti> way better
[17:17] <LaserJock> you would *not* get just shipping .so files through the archive admins
[17:18] <LaserJock> if you're gonna ship an external library you need to ship the source and build it
[17:18] <cpscotti> hmm
[17:18] <cpscotti> de repositorie's daemons would build my .so then?
[17:18] <LaserJock> yep
[17:19] <cpscotti> thanks LaserJock
[17:19] <incorrect> arg, stupid libtool upgrade
[17:23] <jdong> *cry* firefox-3.1 PPA segfaults like no other today :)
[17:44] <luisbg> can somebody check this http://revu.ubuntuwire.com/p/freemix for me please? would be very happy :)
[17:49]  * james_w takes a look
[17:49] <james_w> luisbg: there are some things to fix in http://revu.ubuntuwire.com/revu1-incoming/freemix-0902171842/lintian
[17:49] <luisbg> james_w, thanks!
[17:50] <luisbg> its the first time I package a python app
[17:50]  * luisbg goes to fix the lintian warnings
[17:51] <james_w> do you need to build-depend on python-dev ?
[17:51] <james_w> that's usually only needed for python extensions
[17:52] <james_w> "Ubuntu Studio Controls is a free live video performance tool."
[17:52] <james_w> should be fixed, but the long description should be fleshed out some
[17:52] <luisbg> ok
[17:53] <luisbg> james_w, :) will do
[17:53] <mr_pouit> Riddell: yes... (apparently all started upstream with a joke, and finally the dev kept this name...)
[17:53] <james_w> as you license under "GPL v2 or later" then just point to "/usr/share/.../GPL" rather than GPL-2
[17:54] <james_w> "# Add an alternative for aterm"
[17:54] <james_w> also, do you need an alternative, is there more than one freemix?
[17:55] <james_w> you don't need to include "include /usr/share/cdbs/1/rules/simple-patchsys.mk" in debian/rules
[17:56] <luisbg> james_w, wow... keeping me busy here LOL
[17:56] <luisbg> catching up
[17:56] <luisbg> :P
[17:57] <james_w> W: freemix: binary-without-manpage usr/bin/freemix
[17:57] <james_w> W: freemix: maintainer-script-ignores-errors postinst
[17:57] <james_w> W: freemix: maintainer-script-ignores-errors prerm
[17:57] <james_w> W: freemix: desktop-entry-invalid-category Multimedia /usr/share/applications/freemix.desktop
[17:57] <james_w> E: freemix: description-starts-with-package-name
[17:57] <james_w> W: freemix: description-synopsis-might-not-be-phrased-properly
[17:57] <james_w> that's on the binary package
[17:57] <james_w> I can explain any if you don't understand
[17:59] <james_w> other than that it looks pretty good :-)
[18:00] <luisbg> heh
[18:00] <luisbg> fixed all the lintian
[18:00] <sistpoty|work> james_w: btw.: some people prefer that GPL-2+ points to /u/s/c-l/GPL-2 (as the very new lintian --pedantic shows this as message)
[18:00] <luisbg> W: freemix: binary-without-manpage usr/bin/freemix
[18:00] <luisbg> do I need a manpage?
[18:00] <luisbg> even for a gui app?
[18:00] <james_w> it's nice to have one
[18:01] <james_w> it can be minimal
[18:01] <james_w> sistpoty|work: ORLY?
[18:01] <ScottK> sistpoty|work: Anything marked pedantic is safe to  ignore I think.
[18:01]  * luisbg goes and finds a minimal man page to use as source of inspiration
[18:01] <james_w> it was a little overly-picky of me anyway
[18:02] <sistpoty|work> james_w: iirc it complains if the license points to a symlink, but only if used with the --pedantic parameter (as some people also prefer to have it point to a symlink ;))
[18:03] <pochu> sistpoty|work, james_w: it's not even pedantic, will show with lintian -I
[18:04] <sistpoty|work> ah... well, it was a week ago or so when I checked *g*
[18:04] <sistpoty|work> anyway /me calls it a day now and heads home
[18:04] <sistpoty|work> cya
[18:05] <pochu> later sistpoty|work
[18:05] <luisbg> james_w, other than the man I fixed everything
[18:06] <luisbg> james_w, any package I could get a minimal man page from the top of your head?
[18:06]  * Amaranth always thought the man page requirement was a bit too strict
[18:06] <Amaranth> Some apps don't have any command line arguments and don't run outside of X
[18:06] <LaserJock> I think /u/s/c-l/GPL-2 is GPL2+ isn't it?
[18:07] <james_w> luisbg: not off the top of my head, it won't stop me advocating anyway
[18:07] <james_w> LaserJock: the + is external to the license
[18:07] <Amaranth> The + is in your per-file header
[18:08] <luisbg> james_w, thanks a lot
[18:08] <luisbg> will be dput'ing soon :)
[18:08] <luisbg> double checking stuff
[18:10] <luisbg> ok, did the dput -f
[18:10] <LaserJock> Amaranth: and the man page should say as such ;-)
[18:11] <LaserJock> I thought the text of the license (at least the "how to apply it" bit) was GPLv2+ by default
[18:11] <LaserJock> that was my point anyway
[18:19] <luisbg> any REVU administrators in the channel? my put might be in rejected queue again :(
[18:20] <luisbg> there seams to be a problem with my gpg key
[18:27] <pochu> RainCT: ^
[18:32] <slytherin> Juli_: around?
[18:33] <Davedan> I'm trying to follow the tutorial on https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling
[18:33] <Davedan> but get an error that the script can't be found under debian/tmp/scriptname
[18:34] <Davedan> I have a file debian/install with:
[18:34] <Davedan> scriptname /usr/share/packagename
[18:34] <Davedan> where do I need to put files to be placed when the package is installed?
[18:35] <slytherin> Davedan: what is the location of scriptname currently?
[18:35] <Davedan> in the root folder of the package: package-0.1/scriptname
[18:36] <Davedan> cp: cannot stat 'debian/tmp/scriptname': No suce file or directory
[18:36] <kpirc> Anybody here who could help me get my 'modglue' package advocated? I'm almost 100% there (see the REVU page).
[18:36] <Davedan> dh_install: command returned error code 256
[18:37] <slytherin> Davedan: can you paste complete error on pastebin?
[18:38] <Davedan> yes. a sec
[18:41] <Davedan>  slytherin: http://dpaste.com/121789/
[18:42] <Davedan> debian/install http://dpaste.com/121791/
[18:42] <RainCT> luisbg: hi
[18:43] <luisbg> RainCT, hello :)
[18:44] <Davedan> debian/control http://dpaste.com/121793/
[18:44] <RainCT> luisbg: which upload is it?
[18:44] <luisbg> RainCT, freemix... an update after a few suggested changes
[18:45] <RainCT> luisbg: Uhm.. There's no rejected upload for it on REVU
[18:45] <luisbg> RainCT, want me to dput again?
[18:46] <slytherin> Davedan: it is hard to say why you are getting the error without taking a look at sources. By the way, remove the first / from /usr/share/mypkg in debian/install file
[18:46] <RainCT> luisbg: yes please
[18:46] <fabrice_sp> james_w, about Bug #330392. I had to add that dependency because the package FTBFS
[18:46] <luisbg> RainCT, "Successfully uploaded packages."
[18:47] <james_w> fabrice_sp: ok, please talk to the Kubuntu team about the merge then
[18:47] <RainCT> luisbg: still not here :/
[18:48] <luisbg> RainCT, this one is the charm... I'm sure
[18:48] <luisbg> did it again
[18:48] <slytherin> RainCT: Just wanted to say thanks for all the improvements to revu. You rock. :-)
[18:49] <sladen> ls -l
[18:49] <RainCT> luisbg: Err.. No luck.  What command are you using to upload it?
[18:50] <Davedan>  slytherin: I removed the /    . Thanks I'll keep trying to find the error.
[18:50] <luisbg> RainCT, dput -f revu ../freemix_0.2_source.changes
[18:50] <RainCT> slytherin: Thanks, I'm happy you like them :).
[18:53] <RainCT> luisbg: I really don't know... There are other uploads incoming, but yours isn't visible anywhere :S
[18:54] <luisbg> I get this:
[18:54] <luisbg> Package includes an .orig.tar.gz file although the debian revision suggests
[18:54] <luisbg> that it might not be required. Multiple uploads of the .orig.tar.gz may be
[18:54] <luisbg> rejected by the upload queue management software.
[18:54] <RainCT> then the version number is wrong :P
[18:54] <RainCT> but this is no reason for it to fail
[18:55] <RainCT> can you paste the full output?
[18:56] <luisbg> RainCT, sure, give me a quick sec
[18:57] <sladen> RainCT: I'm just poked 3x openbve-* to revu, does it take a while for them to appear?
[18:57] <RainCT> sladen: up to 3 minutes
[18:57] <sladen> coo
[18:57] <RainCT> sladen: yours got rejected
[18:57] <luisbg> RainCT, http://dpaste.com/121800/
[18:57] <sladen> RainCT: oh, any idea why?
[18:58] <RainCT> sladen: I've just processed them again and it seems like all openbve- were accepted now.
[18:59] <sladen> RainCT: it's been ages since I packaged anything from scratch (rather than pacakge-slashing), figureud I should get some comment
[19:01] <RainCT> luisbg: dput's output looks fine. Uhm.. Do you have this package on a PPA?
[19:01] <sladen> RainCT: oops, I pressed the little icon at the side "Archive" and it makde one disapepar
[19:01] <RainCT> sladen: look for it at the archived section and you'll have an unarchive button there
[19:02] <RainCT> luisbg: err. now there are 2 uploads on revu
[19:02] <RainCT> the cronjob must have gotten it before I looked
[19:02] <luisbg> RainCT, :S
[19:02] <luisbg> so from none to double :P
[19:04] <sladen> right people anyone want to tear my package apart of using 102 image-in-usr-lib lintian overrides
[19:05] <_16aR_> Hello
[19:05] <ScottK> sladen: So why did you do that?
[19:07] <sladen> ScottK: it's a cross-platform mono app, so I've stuff the .exe in /usr/lib/openbve/ and the icons that the GUI uses internally below that;
[19:08] <sladen> ScottK: so I can move them to /usr/share if I either (a) carry a diff  (b) pursuade the upstream author to except the changes
[19:09] <sladen> ScottK: so game data I think I'll place in /usr/share/openbve/... by default; although suggestions welcomed
[19:09] <_16aR_> I got one 2D physics game engine uploaded : http://revu.ubuntuwire.com/p/box2d . Can I get some REVU on it, please ? :)
[19:09] <RainCT> sladen: either option sounds better than having data files in /usr/lib
[19:10] <luisbg> james_w, http://revu.ubuntuwire.com/details.py?upid=5184 thanks!
[19:10] <slytherin> _16aR_: At this point I am sure most of the MOTUs are busy updating/fixing important packages before feature freeze.
[19:10] <RainCT> luisbg: have you seen the Warnings / Notices?
[19:11] <luisbg> RainCT, yes... one is because version=x expects a full integer
[19:11] <luisbg> I have version=0.2
[19:11] <luisbg> wait!
[19:11] <luisbg> *blurg*
[19:12] <sladen> RainCT: okay.  wht about the non-images; move them too?
[19:12] <RainCT> luisbg: the description should also be rewamped, adding more info about what it actually does (and the "powered by" part can be removed altogether)
[19:12] <luisbg> RainCT, ok, doing so, thanks!
[19:12] <RainCT> sladen: what are they? data files should go to /usr/share too, .exe files are fine in /usr/lib
[19:12] <sladen> I was really hoping to keep /usr/share/openbve 'clean' for the multiple train and multiple route packages to drop their contents into
[19:13] <maxb> luisbg: your version number error is because the version does not contain a hyphen
[19:13] <maxb> luisbg: You should be using 0.2-0ubuntu1
[19:13] <sladen> nod.  What's the general system for game data "expansion addons"
[19:14] <_16aR_> slytherin: Yes, you may be right :)
[19:14] <_16aR_> but I still can get peer review from REVU people not MOTU :)
[19:14] <RainCT> sladen: where do such addons come from?
[19:15] <bdmurray> siretart: I was going to add some package bug guidelines for xine-lib and ffmpeg similar to what is at http://wiki.ubuntu.com/Bugs/Responses.  Does that work for you?
[19:15] <RainCT> sladen: and where does the game expect them to be?
[19:15] <slytherin> _16aR_: revu people? You think there is separate team reviewing packages on revu?
[19:15] <maxb> luisbg: You should definitely fix all the big red ! warnings, otherwise the initial reaction of any reviewer is to focus on those and not look deeper
[19:16] <LaserJock> slytherin: I think _16aR_ meant that non-MOTUs could be reviewing still while MOTU are busy
[19:16] <RainCT> slytherin: what LaserJock said. There are actually a few of non-MOTUs who review packages
[19:17] <luisbg> maxb, thanks, doing so
[19:17] <fabrice_sp_> I do from time to time :-)
[19:17]  * RainCT hugs fabrice_sp_ :)
[19:17] <luisbg> maxb, do I need to create a launchpad bug just to close it?
[19:17]  * fabrice_sp_ hugs back RainCT :-)
[19:18] <maxb> luisbg: I agree that's a bit silly. Still, it's probably worth doing just to get rid of the big red !
[19:18] <RainCT> luisbg: that's actually the first thing you should do BEFORE starting packaging something, to avoid that someone else might do the same
[19:19] <luisbg> RainCT, I should be aware if anybody else is packaging it... its my project :P
[19:19] <AdamDH> in control and Description can I have blank lines if indentiated by a space and a .?
[19:19] <RainCT> luisbg: (about the second lintian warning, it's XSBC-Original-Maintainer, nor just Original-Maintainer)
[19:20] <luisbg> RainCT, cool, thanks!
[19:20] <RainCT> luisbg: heheh. Well, packagers don't always poke upstream before packaging something
[19:20] <_16aR_> RainCT: I do this too
[19:20] <slytherin> RainCT: LaserJock: I misunderstood.
[19:20] <_16aR_> But I got no new upload after my comments ^^
[19:20] <RainCT> slytherin: thought so :)
[19:20] <luisbg> RainCT, I have that already... :S
[19:20] <luisbg> RainCT, XSBC-Original-Maintainer: Luis de Bethencourt <luisbg@ubuntu.com>
[19:21] <LaserJock> why wouldn't he just use Maintainer?
[19:21] <RainCT> luisbg: not sure what lintian wants then :P
[19:21] <luisbg> RainCT, heh
[19:22] <maxb> LaserJock: the maintainer of everything in ubuntu is MOTU or core-dev
[19:22] <LaserJock> not necessarily
[19:22] <RainCT> maxb: I think LaserJock knwos this :). If you have an @ubuntu.com you are allowed to set yourself as Maintainer, though.
[19:23] <LaserJock> however, since the purpose of XSBC-Original-Maintainer is to distinguish derived packages, I don't see why any package from REVU should set it
[19:23] <maxb> Isn't that a bit at odd with the "everything is team maintained" philosophy that gets espoused frequently?
[19:23] <LaserJock> no
[19:23] <maxb> *odds
[19:23] <LaserJock> the responsible team should be in Maintainer
[19:23]  * RainCT thinks it would be a good idea for people reviewing packages to say so here in order that bored MOTUs (uhm.. I doubt those exist, but well :P) can check that the comments are sane and move the package to needs-work if there are enough complaints (or perhaps even get motivated to do a full review themselves)
[19:24] <LaserJock> unless there is a specific reason otherwise
[19:24] <LaserJock> Maintainer is not used as a locking mechanism as in Debian
[19:24] <LaserJock> but a "this is who I can go to about this package"
[19:24] <LaserJock> since by definition we know that anybody in ~ubuntu-dev can upload it
[19:25] <LaserJock> anyway, that's a longstanding pet-peeve of mine, but that shouldn't deter people from using current standard procedures ;-)
[19:26] <maxb> XSBC-Original-Maintainer does seem a bit pointless/wrong for originally-for-ubuntu packages, yeah
[19:26] <ScottK-desktop> It's not required.
[19:26] <LaserJock> the distinction would actually be useful
[19:27] <RainCT> LaserJock: it's basically a way for the packager to have his name somewhere
[19:27] <LaserJock> those packages not derived from Debian/some other upstream would clearly be packages not setting XSBC-Original-Maintainer
[19:27] <LaserJock> RainCT: why not in Maintainer?
[19:27] <RainCT> LaserJock: because not everyone has an @ubuntu.com
[19:27] <LaserJock> so?
[19:27] <kpirc> I need a reviewer for my 'modglue' package currently on REVU. Any takers?
[19:27] <RainCT> LaserJock: the Maintainer *must* have an @ubuntu.com
[19:28] <LaserJock> RainCT: why?
[19:28] <ScottK-desktop> LaserJock: It's in the DebianMaintainerSpec
[19:28] <pochu> LaserJock: otherwise dpkg complains I think
[19:28] <pochu> if it has ubuntu in the version number
[19:28] <RainCT> LaserJock: because it's policy, and there are tools that complain
[19:28] <ScottK-desktop> It will complain, but not die.
[19:28] <LaserJock> right, a bad spec implementation is no reason to stand in the way of progress ;-)
[19:29] <ScottK-desktop> If I do an Ubuntu upload of a package I maintain in Debian, I do not change the maintainer
[19:29] <ScottK-desktop> ... which is technically incorrect, but oh well.
[19:29] <RainCT> LaserJock: another reason, we don't know how involved non-Ubuntu Members are
[19:29] <LaserJock> RainCT: so? at least we'd know who to track down :-)
[19:29] <RainCT> LaserJock: they may leave and ignore people sending them mails
[19:30] <LaserJock> like many MOTU are any better? ;-)
[19:30] <LaserJock> it would allow us to have a MIA system
[19:30] <RainCT> .. so if the maintainer is MOTU we are sure any mails will get somewhere
[19:30] <pochu> people shouldn't mail maintainers
[19:30] <pochu> they should use bug trackers
[19:30] <LaserJock> and better track the health of the package
[19:30] <RainCT> pochu: that's also true :)
[19:30] <LaserJock> pochu: quite often that's not the case
[19:31] <LaserJock> we wouldn't have mailing lists if that was the case
[19:31] <pochu> not true
[19:31] <RainCT> LaserJock: raise the point (allowing maintainers without @ubuntu.com and whatever) on ubuntu-devel and I'll probably second it :P
[19:36] <ScottK-desktop> stgraber: You might mention to the person that updated unbound that by stripping the revisions off the symbols file they've now created a permanent diff with Debian unless they can get Debian to do that too.
[19:37] <luisbg> RainCT, the red errors in the page are the ones I had when I did the first dput... its not updating to show the new things... for example I changed the description to something longer and it is showing the original one :(
[19:37] <RainCT> luisbg: because you are using the URL for the previous upload, probably
[19:38] <RainCT> luisbg: which page are you looking at?
[19:38] <luisbg> RainCT, http://revu.ubuntuwire.com/details.py?upid=5192
[19:39] <RainCT> luisbg: arr.. you've uploaded the same as before
[19:39] <luisbg> huh?
[19:39] <RainCT> luisbg: forgot to debuild? :)
[19:40] <luisbg> RainCT, I wonder why am I failing so much today :(
[19:41] <RainCT> hey mok0_ :)
[19:41] <RainCT> hehe
[19:42] <LaserJock> luisbg: well, I was gonna say maybe it was a case of the Mondays. $DAY_OF_WEEK FAIL on my part ;-)
[19:43] <luisbg> woohoo
[19:43] <luisbg> http://revu.ubuntuwire.com/details.py?upid=5194
[19:43] <luisbg> only has the launchpad bug thing
[19:45]  * RainCT tells luisbg that there's something called capitalisation *g*
[19:46] <luisbg> RainCT, LOL
[19:46] <luisbg> seriously
[19:46] <luisbg> I have the dumb. I cant brain
[19:54] <RainCT> uhm.. if a package needs LUA to build, should I depend on liblua5.1-dev or liblua5.1-0-dev?
[19:55] <luisbg> http://revu.ubuntuwire.com/details.py?upid=5196
[19:55] <luisbg> much prettier
[19:55] <luisbg> RainCT, ^
[19:55] <luisbg> :)
[19:55] <RainCT> :)
[19:56] <RainCT> luisbg: http://revu.ubuntuwire.com/revu1-incoming/freemix-0902172054/freemix_0.2-0ubuntu1.diff
[19:56] <RainCT> luisbg: look at the bottom. all that shouldn't be in the .diff.gzz
[19:57] <luisbg> very true
[19:57] <luisbg> well spotted :P
[19:58] <ScottK-desktop> james_w: One other case to consider for your Debian Import Spec: Klamav was initially packaged independently in Debian and Ubuntu (Ubuntu first, but I don't think that matters).  When I adopted the package in Debian I used the Ubuntu package as a basis and kept the Ubuntu debian/changelog.
[19:59] <ScottK-desktop> I'm not sure how that one will work out ....
[20:00] <james_w> ScottK-desktop: how would you expect it to work out?
[20:01] <RainCT> argh.. now that is was starting to think "after all, maybe quilt is not that bad" it goes and starts doing weird stuff with my patches :P
[20:01] <siretart> bdmurray: they sound pretty similar to what I proposed in the past. Thanks for adding them, they sound pretty useful
[20:01] <siretart> bdmurray: now just get seb128 to actually obey them! :-)
[20:01] <ScottK-desktop> james_w: I'm not entirely sure, but I guess I'd expect it to show the Ubuntu and Debian history separtely and then a merge.
[20:01] <james_w> ScottK-desktop: it will have two independent lines of development, then one day Debian will merge Ubuntu and both will carry on, diverged, but with same content
[20:02] <james_w> (assuming you synced back)
[20:02] <james_w> perfect then :-)
[20:02] <ScottK-desktop> I did, eventually
[20:02] <james_w> though if you did all that in one Debian release it won't look like that
[20:02] <james_w> it would just start Debian from Ubuntu, as it doesn't know about the previous Debian uploads
[20:03] <ScottK-desktop> Actually it's slightly more complex as I used the Debian history in the first merged upload and then had a different sponsor who told me to switch it.
[20:03] <ScottK-desktop> Looking back from the current changelog though has the Ubuntu history in it.
[20:03] <ScottK-desktop> OK.
[20:03] <james_w> it would do something sensible I hope
[20:04] <_16aR_> RainCT: I think you should depends on liblua5.1-dev
[20:04] <james_w> can't tell you exactly what right now :-)
[20:04] <ScottK-desktop> james_w: OK.  Just thought I mention it as it seemed perhaps a slightly different case.
[20:04] <RainCT> _16aR_: thanks
[20:05] <_16aR_> RainCT: since liblua5.1 contains the soname in his name, there are no chances of API changes
[20:06] <_16aR_> if liblua5.1-0-dev become libluad5.1-1-dev, tha API wouldn't have change, so it should work the same
[20:06] <_16aR_> I think that's how I would have done it
[20:06] <luisbg> RainCT, http://revu.ubuntuwire.com/details.py?upid=5198 only debian/ stuff in diff :)
[20:06] <RainCT> luisbg: great :)
[20:06] <luisbg> RainCT, thanks a million for the help! :)
[20:07] <RainCT> no problem
[20:08] <bdmurray> siretart: they show up when reporters are filing bugs about those specific packages
[20:09] <siretart> bdmurray: excellent.
[20:09] <siretart> bdmurray: I was jokingly referring to the fact that many users experience crashes in the nautilus indexer, which produce an apport crash.
[20:09] <quadrispro> hi guys
[20:09] <luisbg> james_w, http://revu.ubuntuwire.com/details.py?upid=5198 sorry I'm annoying, just want to get it in before feature freeze :)
[20:10] <quadrispro> RainCT: do you have a moment for taking a loot at http://revu.ubuntuwire.com/p/theorur?
[20:10] <siretart> bdmurray: later then it turns out that the crash is actually in ffmpeg-gstreamer's invocation of libavcodec, which makes seb128 reassign the bug to ffmpeg
[20:10] <RainCT> quadrispro: sorry, trying to finish a package update myself :)
[20:11] <quadrispro> ;)
[20:11] <siretart> bdmurray: which is in almost all cases useless, because people often have no idea or just don't want to attach their videos/pictures/pr0n? to the bug
[20:11] <james_w> ScottK-desktop: thanks, but it's a case that falls out naturally.
[20:12] <james_w> luisbg: dinner comes before feature freeze :-)
[20:13] <luisbg> james_w, LOL!
[20:15] <luisbg> RainCT, no nice comment in the package page? :P
[20:15]  * RainCT tells luisbg the same as to quadrispro :)
[20:16] <luisbg> ahhh sorry sorry :(
[20:16] <luisbg> didnt saw that
[20:20] <Davedan> how do I prompt a user for his mail and create a /etc/packagename.conf file during package installation?
[20:23] <kirkland> anyone out there interested in merging LTP?
[20:23] <kirkland> http://merges.ubuntu.com/l/ltp/REPORT
[20:24] <kirkland> i received a request to do so today, but I don't really have time to mess with it
[20:24] <kirkland> i won't lie....  it's a messy merge (by my standards)  :-)
[20:25]  * ajmitch sees a lot of Cs
[20:26] <RainCT> woo.. glest built \o/
[20:28] <RainCT> now if I got the quilt patches to not do weird stuff..
[20:30] <fabrice_sp_> kirkland, won't it be easier to do an upgrade of the Ubuntu package instead of a merge? The base version is not the same...
[20:31] <kirkland> fabrice_sp_: sure, but the Ubuntu changes need to be examined, and determined if they still apply
[20:31] <andersk> Can I get a MOTU to sponsor (what is now) a quick sync request?  bug 295127
[20:31] <andersk> Oops, wrong bug
[20:31] <andersk> bug 303112
[20:31] <kirkland> fabrice_sp_: i tried to straight build the debian package in ubuntu, and that didn't succeed immediately
[20:32] <kirkland> fabrice_sp_: i'm swamped and didn't have time to troubleshoot it ;-)
[20:32] <fabrice_sp_> kirkland, that would have been my first approach, yeas
[20:32] <fabrice_sp_> a bit too close from FF, I fear
[20:33] <mrooney> kirkland: hey Dustin :) Did you have any thoughts on where/when to ship the python API? ecryptfs-utils, or as a separate package which it recommends?
[20:34] <fabrice_sp_> kirkland, I'll see if I can do something
[20:34]  * fabrice_sp_ building ltp
[20:34] <kirkland> fabrice_sp_: thanks
[20:34] <kirkland> mrooney: howdy
[20:35] <kirkland> mrooney: part of ecryptfs-utils would be easiest, i think
[20:35] <kirkland> mrooney: just a new binary package there
[20:35] <kirkland> mrooney: ecryptfs-utils is already in main, etc.
[20:35] <kirkland> mrooney: that should be most straightforward
[20:35] <kirkland> mrooney: we need to get that in ASAP, though
[20:35] <kirkland> mrooney: thursday is FF
[20:37] <RainCT> (btw, I'll probably not be around tomorrow)
[20:37] <mrooney> kirkland: yeah, it doesn't seem like any UI stuff will land in Jaunty alas, but at least having that API there will be a good step I feel
[20:37] <kirkland> mrooney: bummer
[20:37] <kirkland> mrooney: okay
[20:37] <kirkland> mrooney: well, yeah, let's get the api in
[20:38] <mrooney> kirkland: also I think adding a function which migrates a directory would be cool to add. so you say API.migrateDir("~/.mozilla") and it moves that to your ~/Private and symlinks it back
[20:38] <mrooney> then it would be trivial for apps which typically use private information to offer to do this for you via a menu or something
[20:41] <kirkland> mrooney: that's still a very difficult operation
[20:41] <kirkland> mrooney: i'm working with the kernel guys to get some support from them for a live migration mechanism
[20:42] <kirkland> mrooney: very difficult to do in a way that we can guarantee success
[20:42] <mrooney> kirkland: ahh, is it? I know migrating to an encrypted home is hard, but I thought copying over a directory to an already setup Private was easy
[20:42] <kpirc> I'm looking for a MOTU who can be the 2nd advocate for my modglue package on REVU. Any takers?
[20:42] <Davedan> how do I prompt a user for his mail and store it during package install?
[20:42] <cpscotti> does anyone there knows why package libdiacanvas2-1 ( http://packages.ubuntu.com/gutsy/libs/libdiacanvas2-1 ) is not available anymore? (I can't find it on hardy nor intrepid repositories)
[20:43] <mrooney> kirkland: (should we move this over to -devel?)
[20:43] <kirkland> mrooney: right, that is simpler
[20:44] <mrooney> kirkland: yeah, that is what I was proposing, a one-liner API call to move a directory into ~/Private and symlink it back
[20:44] <__iron> anybody needs a programmer ?
[20:44] <__iron> c, cpp or java ?
[20:45] <RainCT> Davedan: with debconf
[20:45] <kirkland> mrooney: hmm, i find that's less necessary now that we have encrypted home directory support
[20:45] <mrooney> kirkland: anyway I will try to get you an ecryptfs-utils patch by tonight or tomorrow, and I'll try to hack up ecryptfs-gui to at least work as a separate System->Prefs entry and see if there is interest for that in Jaunty
[20:46] <RainCT> cpscotti: https://edge.launchpad.net/ubuntu/+source/diacanvas2
[20:46] <RainCT> cpscotti: Deleted in hardy-release on 2008-03-29  (Reason: (From Debian) RoM; no longer needed)
[20:46] <RainCT> (RoM = Requested by the Maintainer, iirc)
[20:46] <RainCT> hey __iron
[20:47] <Davedan> RainCT: when do I use debconf and when a /etc/package.confg file?
[20:47] <RainCT> __iron: I'd suggest looking for some project you are interested in and trying to get involved there
[20:47] <RainCT> Davedan: debconf is an interface to ask questions on install time. you can then get the results and write them to a config file
[20:47] <kirkland> mrooney: cheers
[20:47] <RainCT> Davedan: however, asking stuff at install is usually a bad idea.. can't it be avoided?
[20:47] <kirkland> mrooney: it would be nice if you branched lp:ecryptfs
[20:48] <kirkland> mrooney: and sent a merge proposal in Launchpad
[20:48] <Davedan> RainCT: thanks. I saw it is involved with a db and that what confused me.
[20:49] <iron> hi RainCT
[20:49] <Davedan>  RainCT: I need the to store the user's email somewhere. Is there a better way to do it?
[20:50] <RainCT> iron: hi
[20:50] <iron> do you need someone ?
[20:50] <RainCT> >> iron: I'd suggest looking for some project you are interested in and trying to get involved there
[20:51] <RainCT> iron: or if you want to start something by yourself you can have a look at open blueprints or at brainstorm
[20:51] <ScottK> __iron: I'll need some C help probably next week.
[20:51] <iron> i need a team and a support
[20:51] <ScottK> What do you mean?
[20:52] <iron> ScottK: maybe i can help you
[20:52] <RainCT> ScottK: planning anything nice? :)
[20:52] <ScottK> __iron: Perhaps.  There is a new clamav version coming out very soon that will break all the libclamav rdepends.
[20:53] <ScottK> Since it'll be after Feature Freeze, we probably can't wait for upstreams to port everthing to the new API.
[20:53] <ScottK> So there are at least a handful of packages that will need some serious love to work with the new version.
[20:55] <iron> clamav pretty nice
[20:56] <ScottK> So once we have a reasonably complete snapshot available, I'll need some help.
[20:56] <ScottK> I expect that this week or next.
[20:56] <iron> i will idle in this channel
[20:57] <ScottK> Great.
[20:57] <iron> if you want i sent you my emailaddress
[20:57] <mrooney> kirkland: ahh yes thanks that is a better workflow, I'll do that
[20:57] <kirkland> mrooney: np
[21:01] <ScottK> __iron: You can pm it to me if you want.
[21:02] <iron> ScottK: sec pm
[21:09] <maxb> What's special about python3-minimal that apt wants to install it even though I can't find any dependencies that would account for that?
[21:10] <ScottK> It's set essential yes.
[21:10] <ScottK> There's a bug already
[21:11] <maxb> oh, I was looking hard at Priority, and thinking "optional"? nothing special there
[21:12] <iron> RainCT: you do you any projects they needs some help ?
[21:12] <ScottK> Essential isn't a priority
[21:12] <iron> +also
[21:13] <maxb> Yeah, I just wasn't thinking clearly and didn't even look for Essential since the Priority wasn't anything special
[21:13] <maxb> interesting that aptitude doesn't seem to care about Essential
[21:13] <maxb> insofar as installing new essential packages, anyway
[21:16] <RainCT> iron: Right now, no. Do you know Python, though?
[21:16] <iron> nop
[21:28] <RainCT> argh
[21:29] <RainCT> if somehow a file got magically deleted but another program still has it open, how can I recover it?
[21:29] <RainCT> :P
[21:30] <RAOF> RainCT: Save it in the program that has it open? :)
[21:30] <RainCT> RAOF: it's scp :P
[21:31] <RAOF> Ah.  Problem :).
[21:31] <ajmitch> there are evil ways of dabbling with /proc/$pid/fds
[21:31] <RAOF> Creating a hardlink to one of those?
[21:31] <ajmitch> something like that, or using cat, I can't remember what I read about it
[21:31]  * ajmitch has never tried it
[21:32] <RainCT> Invalid cross-device link
[21:32] <RainCT> doesn't /proc have it's own filesystem?
[21:33] <ajmitch> yes, so hardlinks won't work
[21:33] <RainCT> even funnier, the file in proc is in fact a symlink to the file
[21:34] <ajmitch> http://modal-echoes.blogspot.com/2007/02/recovering-deleted-files-through-open.html
[21:35] <RainCT> thanks
[21:35] <neversfelde> I get an error while building krename 3.9.2 http://pastebin.ca/1340473 Can someone give me a hint how to solve this?
[21:36] <kpirc> Is there a MOTU here willing to help me with my computer algebra package 'cadabra' on REVU?
[21:47] <JontheEchidna> neversfelde: is this a kde3 app? I remember having similar trouble with konversation
[21:48] <neversfelde> JontheEchidna: no, it is the new KDE 4 version
[21:48] <JontheEchidna> hmm
[21:48] <JontheEchidna> the .gmo files are generated during build time iirc
[21:49] <RainCT> I guess Ubuntu's archive handles debian/control files with contrib/ and non-free/ in the section fine?
[21:49] <JontheEchidna> if you run debuild -S -sa does it complain about direct modifications to the source?
[21:50] <JontheEchidna> Most likely krename is not deleting the .gmo files on make clean
[21:51] <neversfelde> JontheEchidna: nope, does not complain
[21:52] <JontheEchidna> When this happened with Konversation I added this to debian/rules and it stopped failing:
[21:52] <JontheEchidna> http://paste.ubuntu.com:80/119405/
[21:53] <neversfelde> JontheEchidna: thanks, I will try it
[21:53] <Davedan> I'm using dh_make to create a package template. I've created a debian/template file and a /debain/config file in order to use debconf but I don't see the question when I'm installing the app
[21:54] <maxb> Davedan: template*s*, right?
[21:56] <Davedan>  maxb: yes debian/templates but when I try: dpkg-buildpackage -us -uc and then sudo debi I don't see the question
[21:56] <maxb> Did you remember to use dh_installdebconf in your debian/rules ?
[21:57] <Davedan> no. how do I use it?
[21:58] <Davedan> in my debian/rules I only have include /usr/share/cdbs/1/rules/debhelper.m
[21:58] <maxb> um
[21:58] <maxb> cdbs is magical in ways I've never bothered to learn
[21:58] <Davedan> what do you mean?
[21:59] <maxb> As in, I do not know how much the use of cdbs automates for you
[22:00] <Davedan> I do see "dh_installdebconf -pmypkg" when building the package
[22:01] <maxb> manpage of dh_installdebconf suggests  your files must be called mypkg.templates, mypkg.config
[22:03] <maxb> though apparently looking at the source, the bare names should work
[22:04] <maxb> If you feel like posting your source package somewhere, I'll see if I can offer any advice
[22:04] <Davedan> maxb: thanks, that'll be great
[22:04] <Davedan> I've tried changing the name but it doesn't work
[22:15] <Davedan> maxb: where can I post mypkg.tar.gz ?
[22:15] <maxb> if you don't have anywhere you can put it for me to download, I could PM you my email address
[22:16] <Davedan> maxb: I'll find somewhere, a sec
[22:25] <Davedan> maxb: http://cid-fc2d3fb8537c2a34.skydrive.live.com/self.aspx/Public/mypkg|_0.1-1.tar.gz
[22:26] <Davedan> maxb: http://cid-fc2d3fb8537c2a34.skydrive.live.com/self.aspx/Public/mypkg-0.1.orig.tar.gz
[22:26] <Davedan> maxb: the second one is empty just to let the build work
[22:28] <maxb> erm? that's not right
[22:29] <Davedan> maxb: erm?
[22:29] <maxb> " the second one is empty just to let the build work"
[22:30] <azeem> Davedan: a source packages consists of the .orig.tar.gz (from upstream), plus a .diff.gz with the Ubuntu changes (mostly the debian/ directory) and a .dsc control file
[22:31] <maxb> Alternatively, there's the concept of a "native" package. This contains just a .tar.gz and a .dsc
[22:31] <maxb> Note: no .orig.
[22:31] <maxb> A "native" package has no hyphen character in its version
[22:32] <azeem> it's not very useful to highlight native packages in most cases, IMO
[22:32] <maxb> Except if someone is making a package to hold a custom script of their own :-)
[22:33] <Davedan> sorry but I don't understand
[22:33] <Davedan> I do understand that the native package should hold usefull info in it but I just created an empty one for testing
[22:34] <Davedan> I don't understand the comment about hyphen character
[22:34] <maxb> I do not believe the orig.tar.gz you have at the moment serves any useful purpose
[22:35] <maxb> There are two kinds of package: ones using an orig.tar.gz and a diff.gz, and ones which have no diff, only a tar.gz
[22:35] <maxb> They are distinguished primarily on whether their version number contains a "-" character separating the upstream version from the packaging revision, or not
[22:36] <Davedan>  maxb: it doesn't server anything. I created it when "dh_make -c gpl -s -b" complinaed that it is missing
[22:36] <maxb> Davedan: unfortunately you created it with slightly the wrong name, however: it would need a _ not a - in it
[22:37] <maxb> anyway, to go back to the original problem, the issue is that you don't have the required postinst
[22:37] <Davedan> maxb: ok. now I get it.
[22:38] <Davedan> maxb: I thought that the posinst is required only for processing of the debconf
[22:39] <maxb> See "man dh_installdebconf"
[22:39] <maxb> the last paragraph of the main section
[22:41] <maxb> For more explanation on *why* you have to do this, read the start of the HACKS section of "man debconf-devel"
[22:42] <Davedan>  maxb: thanks. reading
[22:46] <maxb> Davedan: so, adding the necessary line in postinst makes things work, but then the package fails to install, because db_input returns 30, signifying that my importance threshold makes me only be asked high-priority questions during initial configuration
[22:49] <Davedan>  maxb: I'm trying that
[22:49] <nhandler> mok0: Why did you change all of the guides on the wiki to *only* talk about the new machine-readable debian/copyright file? There is no policy that requires this style, and the old format is still widely used. I can understand adding additional examples that use the newer style, but why did you remove the older examples?
[22:53] <Davedan>  maxb: works :) thank you so much
[22:54] <ScottK> nhandler: If you reverted that, I would stand behind it.  It's really out of line IMO.
[22:54] <Davedan>  maxb: now I need to get back, read and understand more
[22:55] <nhandler> scottk: I plan to do that once I talk to mok0 (I also need to find the correct revision to revert to).
[23:03] <quadrispro> hi guys
[23:03] <quadrispro> anyone could give an opinion on this? http://revu.ubuntuwire.com/p/theorur
[23:05] <luisbg> any MOTU has 2 minutes to look at a package in revu that has no errors anymore?
[23:08] <luisbg> http://revu.ubuntuwire.com/details.py?upid=5198
[23:18]  * RainCT uploads glest 3.2.1 to Jaunty :)