[00:12] Dear everyone: Please testbuild before you upload. I just 'love' it when I see FTBFS that there is no way could ever have worked. [00:12] kthnxbye [00:14] i'm getting better at that! [00:15] (that's so a real pain to find email for the debian/copyright file !!) [00:15] 30 min to find a mail of a developer for 1 .h ... :( [00:16] dolanor, welcome to debian/copyright [00:16] please enjoy your stay [00:17] directhex: In the case that caused me to save that the uploader had inexplicably added a new patch name to debian/patches/series when all the changes in the revision where in the debian dir (no patch). [00:17] So it FTBFS when it couldn't find the non-extant patch. [00:18] directhex: thanks ^^' [00:18] There is no way in God's green Earth that was test built. [00:18] Unfortunately Daniel Hahler lives in +0100, so I imagine he uploaded and went to bed. [00:20] If you see him, let him know I want that 15 minutes of my life back. [00:20] * ScottK steps off the soap box. [00:21] * Laney snoops [00:23] * directhex burns soapbox for warmth [00:23] * directhex also wonders the chances of a motu in the UK having an intel core i7 processor [00:25] Good god, how can I still *never* remember to run update-maintainer? [00:26] also, how does my housemate not understand that running your torrents at full upstream is not a good idea? [00:26] * Laney mutters [00:26] fire him into the sun? [00:26] also, bedtime [00:27] I think I will [00:27] nn [00:27] and when some people do captcha for email, that's even harder ! [00:27] http://www.smilax.org/101 [00:28] (love the area code of his) [00:28] Laney: This will make your snooping easier: http://launchpadlibrarian.net/22618531/lighttpd_1.4.19-5ubuntu2_1.4.19-5ubuntu3.diff.gz [00:28] but when you see what 123people do, you understand why some become paranoid ... [00:28] ScottK: Yeah, I found it [00:28] why test build locally when you have several powerful buildds to do it for you? [00:29] Yes, why confine the breakage to your system when you can break the archive. [00:29] dolanor: Captcha for email? You mean like Challenge and Response? [00:34] ScottK, "click this url and fill in the captcha for your mail to be relayed" [00:35] I take stuff like that as a sign they don't actually want mail from me. [00:35] heh [00:35] anyway, bed === ianto is now known as failianto === danielm__ is now known as danielm === failianto is now known as ianto [01:05] ScottK: yes some captcha [01:05] not automatic, though [01:06] You have to understand english to determine his mail or physical address [01:06] hmmm, is the mail in copyright mandatory ? I've search for 30 min for 1 email, and can't find any clue for that ... [01:08] dolanor_: I don't think it is mandatory [01:12] nhandler: ok, so i'll skip this one :o [01:12] lucky me, he was the last one [01:18] what is the command to avoid typing gpg password at each debuild ? [01:19] dolanor: Install gnupg-agent. [01:21] i have gpg-agent running, is it that ? [01:23] dolanor, I followed this https://help.ubuntu.com/community/KMailGPGAgent [01:24] F me [01:24] dolanor, and by that link, I meant https://help.ubuntu.com/community/GnuPrivacyGuardHowto [01:24] sorry about that [01:27] dolanor_: hi! hexdiff looks good, I'm test-building it now [01:28] sorry quadrispro, I misguided you with X-Comment [01:28] you were right ! [01:28] I was too lazy to read the entire RFC :o [01:28] :) [01:28] it builds fine -> http://home.alessiotreglia.com/jaunty/result/hexdiff_0.0.53-0ubuntu1/hexdiff_0.0.53-0ubuntu1.buildlog [01:28] I'm reading it tgm4883, thanks :) [01:29] dolanor_: there's just a little thing -> I: hexdiff: hyphen-used-as-minus-sign usr/share/man/fr/man1/hexdiff.1.gz:7 [01:36] quadrispro: oh, I thought I corrected that one [01:37] hmmmm, that's the original manpage [01:37] I didn't modify it at all [01:37] must I provide a patch ? [01:37] dolanor_: no no [01:37] dolanor_: it's not very important [01:39] tgm4883: hmmm, the pinentry-gtk doesn't work for me [01:39] I can't use the graphical gpg manager of gnome [01:39] dolanor_: the application name is Visual Hexdiff -> http://tboudet.free.fr/hexdiff/ [01:39] don't know why ... [01:39] I can't type in [01:39] dolanor_: why upstream doesn't provide the last release?? :-/ [01:40] Not sure :) google for it. If you type "visual hexdiff", it find some sites speaking of this one. If you type "Visuel hexdiff", you get the official website [01:40] because I'm in close contact with upstream [01:41] ah-ah! you're right [01:41] ok ok [01:41] he wait for me to upload the new version [01:41] since he is quite busy, he hasn't time to upload every minor thing that I change :p [01:42] I understand [01:52] dolanor_: uploaded to Jaunty NEW [01:52] bug 317331 [01:52] Launchpad bug 317331 in ubuntu "[needs-packaging]hexdiff" [Wishlist,In progress] https://launchpad.net/bugs/317331 [01:58] doko, did you go though the tips and tricks part of that link/ [02:00] quadrispro: \o/ [02:00] thanks :) [02:01] you're welcome [02:01] thanks for your work ;) [02:02] dolanor: pinentry-gtk you almost certainly don't want. Try pinentry-gtk2. [02:04] c [02:05] dolanor: What release are you running? [02:07] ScottK : the pinentry bug since I use SCIM ... [02:07] https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/284044 [02:07] Ubuntu bug 284044 in scim "seahorse passphrase dialogs don't accept input" [Low,Confirmed] [02:08] dolanor: seahorse is not much of an agent. It's pretty broken. [02:08] dolanor: The reason I ask is that we removed pinentry-gtk in Gutsy, so either you've upgraded your system several times or you're using an olde release. [02:09] no no, I was using a shortcut [02:10] I don't know exactly what utility it use, but this is the window from seahorse when I have GPGKEY env set [02:10] can't I use the gpg-agent with only terminal prompt ? [02:11] You should be able to. I don't use Gnome, so I can't say how Seahorse gets involved. [02:13] dolanor_: sudo apt-get install gnupg-agent && man gpg-agent [02:14] jmarsden: already done, the bug is between scim and seahorse [02:14] :) [02:14] jmarsden: Part of the problem is that Seahorse is involved. It's a crap gpg-agent in it and the actual gnupg-agent don't play well together. [02:14] I've killed the seahorse-agent processus, and relaunched gpg-agent --daemon [02:14] OK... so just use gpg-agent in your .profile and forget seahorse... right. [02:14] and now I've got some Qt4 window, lol... But at least... It works :) [02:15] seahorse could get better. [02:15] right now it isn't very useful. [02:16] another question ... Any cdbs guru there ? [02:17] kolby: As recently as the version in Hardy it would do 'fun' stuff like remove an existing gnupg.conf and replace it with a blank one (except I nice comment confessing it's sins). [02:17] !ask [02:17] Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [02:17] dolanor: ^^ [02:17] ^^ [02:18] World of Goo came out for Linux today [02:18] it's a game I've never heard of... it has a debian package => it's related to motu. [02:18] (not really) I just found it interesting. [02:19] In debian/rules with cdbs, it tells : put any env var here (after the makefile.mk include, etc ...) but if I set DEBBUILDDIR after the include ... the options is not passed to make [02:19] kolby: world of goo is a great game [02:19] I don't really like puzzle game, but I think I like this one very much :) [02:19] Yay ! ^^ [02:19] I have the demo [02:20] yes me too [02:20] I might buy it then [02:20] * kolby plays games... [02:20] I can't afford the 15€ right now (french taxes, ouch), but next month, he is mine [02:20] hi all! got a bug to file... any info on how to do it? [02:20] so I'll play the demo ... And for now I'm blocked by tower of goo [02:20] launchpad, right? [02:21] sbaginov: just fill the bug description in launchpad :) (But verify if it doesn't exist on launchpad already) [02:21] Then there's this: https://help.ubuntu.com/community/ReportingBugs [02:21] thank you [02:22] I hope I gave you the right info. I'm new here. [02:23] yes, i found the bugs list and no info on mine, but i did not know how to report it even if i was logged in. i thought that motu had its page to report bugs [02:24] I think I'll buy world of goo for my mother... I just installed ubuntu for her ^^ Must keep her on it by any means :p She is fond of those type of games [03:08] Can I please get a REVU on http://revu.ubuntuwire.com/p/mythnettv === bluesmoke is now known as Amaranth [03:35] tgm4883: looking at it [03:35] dolanor_, thanks [03:38] tgm4883: ftbfs [03:38] :/ [03:38] tgm4883: just kidding [03:39] but I'm no expert in python package [03:39] lol, you got me ;) [03:39] from what I see, it is good [03:39] except from the COPYING file [03:39] it is still in the .deb [03:39] what about the copying file? [03:39] hmm [03:40] let me get on that like a pirate getting some booty [03:41] as said superm1 or mok0, there shouldn't be a COPYING file in the .deb, only the source file [03:41] I'm commenting on revu [03:45] did you patch yourself the original source package ? [03:45] without dpatch ? [03:46] dolanor_, when adding the license? [03:48] I speak for setup.py [03:48] hmmmm, I may be dumb [03:48] wait :p [03:49] no I'm not that dumb :p [03:49] all editing i've done should be in either dpatches or done upstream [03:49] so you wrote setup.py in upstream ? [03:49] yea [03:49] ok [03:49] so, 1 more issue with copyright :) [03:49] gflags.py is full of google coder copyright [03:49] and BSD license i think [03:49] you should add it [03:49] hmm [03:50] ok, will do [03:50] Added comment on revu [03:50] and now ... goind to bed ..., already 5:50 [03:50] bye [03:52] night [09:46] Anyone around who could have a peek at one last issue I'm having with a package on REVU? It's "modglue". [09:51] kpirc, What issue are you having? === ogra_ is now known as ogra [10:03] persia, another MOTU made a remark concerning re-factoring of debian/rules to account for arch all in the -dev package. I don't understand what that comment means. [10:06] kpirc, Well, packages that are arch-specific or arch-any will run the binary-arch rule. Packages that are arch-all will run the binary-indep rule. Your current binary-indep rules doesn't do anything, so it won't build the arch-all binary. [10:07] persia, strange, when I build the binary packages I do get a -dev package which contains the relevant files. In any case, should I just copy the stuff below binary-arch to the binary-indep section? [10:08] kpirc, Also, it's recommended to pass -a and -i to debhelper programs when building both arch-dependent and arch-independent packages from the same source. [10:08] Well, you might not need all of them, but yes. [10:09] In fact, you don't need all the ones you have listed now for arch-specific. Read the manpages: I suspect you'll find that many can just be removed. [10:09] What architecture do you run? [10:09] i386 [10:09] Try setting up an lpia pbuilder or sbuild chroot in parallel. [10:10] When you build packages on i386, it builds both arch-dependent and arch-independent binary packages by default. [10:10] With lpia, it won't build the arch-independent binary packages by default. [10:10] If you try your current source, you'll find that it builds your -dev package also on lpia, which is the source of the complaint. [10:11] (for those with amd64 environments, the recommendation is to use i386 and amd64 chroots, as amd64 doesn't get arch-all by default either: no lpia required). [10:13] persia: Can one not also test just with i386? [10:15] ok, so now I'm thoroughly confused. Can you give me a rough guess of what my binary-indep and binary-arch parts of debian/rules should look like? I see no dh_* calls which seem to have anything to do with installing the header files, so I don't understand how to change these sections. [10:16] wgrant, I suppose. I find it easier to launch two sbuild sessions in separate architectures and examine the results than remember the appropriate flags to pass to override the default behaviour, and build twice. [10:17] kpirc, First lets trim you binary-arch rule. Do you need each of the helpers? Also, you want to pass -a as an argument. [10:20] I don't think there's any helpers that can be dropped, given that this is building a shared library. Should '-a' be given as an argument to all helpers or only specific ones? [10:20] OK. Let's look at some specifics. How are you using dh_installdocs? === _neversfelde is now known as neversfelde [10:21] -a should be passed to all helpers in the binary-arch target, and -i to all helpers in the binary-indep target [10:22] I don't know whether that gets used. I never understand which files these helpers act on, so I was assuming that READMEs and other related material would get installed by this helper. [10:22] Does reading man dh_installdocs help you determine this? [10:23] well, it mentions installing debian/copyright, so I guess I need this one. [10:23] OK. It would also install a README if your package had one, but it doesn't, so it's not important, and yes, you need this one. [10:23] How about dh_installexamples? [10:25] Bad man page for that one. How does dh_installexamples figure out which files count as 'examples'? Does it not do anything without parameters? [10:26] It can either take arguments, or look in the contents of a file named "debian/package.examples". It does nothing if there are no arguments, and this file doesn't exist. [10:26] In the case of your package, you have a nice examples directory, which you probably want to install as examples. Given that it's dev examples, you probably want to install it in the -dev package. [10:27] I'd recommend only having `dh_installexamples -i -plibmodglue1-dev` in binary-indep, and not including it in binary-arch. [10:27] ok. Why the explicit -plibmodglue1-dev ? [10:28] Because I think you want to include the examples only for that package. Of course, you could run it for all arch:all packages, and just only have debian/libmodglue1-dev.examples contain anything. Your choice. [10:29] With the extended argument, I believe you can just use debian/examples. [10:29] Since it doesn't matter which way you do it, please pick the one that makes more sense to you. [10:31] ok [10:35] Shall we go through the others individually, or would you like to go through them, and just ask if you have questions? [10:37] I would say that for a minimal -dev which only installs the 'examples' directory and the header files, I need [10:38] dh_testdir -i [10:38] dh_testroot -i [10:38] dh_installexamples -i [10:38] dh_fixperms -i [10:38] dh_installdeb -i [10:38] dh_gencontrol -i [10:38] dh_md5sums -i [10:38] dh_builddeb -i [10:38] (plus the debian/libmodglue1-dev.examples file containing 'examples'). [10:38] Well, I'd probably put the manpages in the -dev package, so put dh_installman there, and dh_compress [10:39] kpirc: Please use a pastebin [10:39] I'd also suggest putting the changelog there, either with dh_installchangelogs, or with dh_link to the changelog from the actual library. [10:40] no, there are some small binary helper programs which go into the non-dev package, and they need manual pages. [10:40] i'd use dh7, and not manually list any dh_foo stuff [10:40] (the library itself is still not properly documented; have been spending my time making debian packages ;-)) [10:40] StevenK: sorry [10:41] kpirc, So you'd have your section 1 pages in the tools package and the section 3 pages in the -dev package, so you'd put it in both (and need to add a couple package.manpages to get them included with the right binary. [10:42] Where "both" means binary-arch and binary-indep (sorry for the lost referent). [10:43] I only have section 1 pages so far, so I'll keep this as-is for now. [10:44] Well, OK, but don't be too surprised if some future reviewer balks at a lack of manpages :) === asac_ is now known as asac [10:45] I know. The problem is that I'm only packaging modglue because it is needed by my cadabra package (also waiting on REVU). If I had known all this I would probably have stuffed the lot into cadabra itself, and made it non-public and statically linked to the binary. [10:46] kpirc, Well, then you would have had complaints about static linking and embedded libraries :) [10:47] Anyway, I'm not sure everyone checks for library-missing-manpage: you might get lucky. [10:47] you can never please them all... [10:47] It's work in progress, I can't do all at once _and_ get a decent number of users interested. [10:48] Release early, release often, so to say. [10:48] kpirc: you can also just check a common library man page and use it as a model - it saves a lot of time, and might end up faster ;) [10:49] loic-m, Except that a *good* set of library manpages actually document each function call, which is a bit more documentation than most application manpages. [10:49] loic-m: any recommendations for a good C++ library man page? I never use them, they are mostly of the microsoft form: "do_something(): this function does something." [10:50] persia: that would be quite a pain then ;) [10:52] loic-m, Which is precisely why not everyone checks for library-missing-manpage. Pretty much every reviewer checks for binary-missing-manpage, as that's more directly exposed, and much easier to fix in packaging. [10:54] kpirc: I can't remember having read any... As long as the doc is there in a way or another (I just checked a bit and couldn't find one ;) ) [10:55] All in the header files so far. It takes _a lot_ of effort to write good library docs, I'd rather have none than a bunch of useless pages. [10:57] loic-m, The manpages-dev package as some very good examples, as does glibc-doc. [10:57] neither of those are C++ [10:57] monodoc! [11:00] kpirc, libcrypto++-doc has some C++ examples (dunno how good). Anyway, as discussed above, let's skip writing full documentation for a single-user library right now, and focus on your packaging. [11:04] persia, ok, I have uploaded a new version to revu, can you give that a look? [11:04] kpirc, look at doxygen [11:05] kpirc, I thought you had manpages for some of the helper binaries that belonged in an arch-specific package. [11:05] It can extract documentation from your source files [11:05] 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 [11:05] mok0: I don't like doxygen, it tends to focus on documentation in which each and every function is documented well, but there is no proper overview (I know, you can do that with doxygen too, but it does not really help you in that area). [11:06] kpirc, Also, you either need to install a changelog for your arch:any stuff, or link it with dh_link. [11:06] Lastly, how are you using dh_link for your arch:any packages? [11:06] On another note, why does control specify debhelper (>=5) and compat have "4"? [11:06] persia, "dh_link -a". I guess that can go too. [11:07] persia, because it took me more than 6 months to have someone look at this package... In the meantime versions bumped several times. [11:07] kpirc: that depends on how you do the markup [11:07] mok0: up to you of course [11:08] kpirc, I understand the delay, which is why I'm not suggesting dh7: it's just the inconsistency that stands out. [11:10] kpirc, Reading through the comments, I'm also curious why you haven't included mok0's contributed symbols file. [11:12] kpirc, You probably also want to check the "legal" link from your REVU upload. I suspect there may be issues with some files (I didn't look in depth). [11:13] persia: ok, fixed dh_link, compat version, included the symbols file (was on a different machine, forgot to check it in there). Will now check legal. [11:15] persia: legal, ouch, this is a serious pain, will have to go through all files now. Hang on. [11:33] persia, ok, have uploaded a new version. Please have a look, and leave a comment on REVU if there's anything else missing (have to run now). Thanks a lot for the help! [11:55] * directhex smiles sweetly @ motu-release [11:56] DktrKranz: your turn \o/ [11:57] sebner, huh? [11:58] btw, congrats Debian! \o/ [11:58] DktrKranz: heh, MD2 beta needs motu-release love to make it into the archive ;D [11:58] md2? [11:58] DktrKranz: monodevelop 2 :P [11:59] heh [11:59] it's not motu-release time already [11:59] DktrKranz, not until tuesday, but reality has a horrible habit of doing things an expected way... see https://lists.ubuntu.com/archives/ubuntu-motu/2008-November/005025.html [12:02] directhex, which stage is current development? [12:02] DktrKranz, beta 1 preview packages are building and being tested [12:03] directhex, has schedule for 2.0 final been defined? [12:03] DktrKranz, yes, let me find their release schedule... [12:03] Is it ok if I tag packages on REVU with my nick? It is a useful way to keep track of packages I've looked at. It does pollute tag-space, though [12:04] DktrKranz: mid march -> final releaes [12:04] DktrKranz: http://www.monodevelop.com/Development_Roadmap [12:04] DktrKranz, http://monodevelop.com/Development_Roadmap [12:04] hah [12:04] :) [12:04] which one should I follow? :P [12:04] not sebner's ;) [12:04] DktrKranz, we delayed packaging work until upstream feature freeze, so updating the packages would be 0-effort [12:05] is there a ruby package that doesn't use cdbs? [12:05] i.e. who knows what would break from alpha1->alpha2 from a packager perspective, but beta1--->final should just be uupdate [12:06] directhex, if we have 2.0beta1 now, I think we can safely ship 2.0 final before release day [12:06] the question is if we want 2.0beta1 now [12:06] I guess there will be several bugs fixed since 1.0 [12:07] DktrKranz, yes, and some major new features [12:07] DktrKranz, hence worried about feature freeze more than bug fixes, since bug fixes are due in beta2 and final too [12:07] could we gather some informations and bug fixed somewhere, and make packages available for testing? [12:09] DktrKranz, trying to get my hands on a source package for ppa love [12:10] I could test it from a mono-dumb perspective [12:10] (so I can understand C# a bit) [12:10] DktrKranz, well MD is a nice IDE for other languages too [12:10] * DktrKranz is basically a Python-lover guy [12:11] it has a python plugin afaik [12:12] though c# is the main focus of it, that's true === RainCT_ is now known as RainCT [12:23] Laney, gnome-do-plugins FTBFS applying 03_buildsystem_respect_mcs.dpatch, removing it should fix it. Mind looking at it? [12:23] DktrKranz: I am [12:23] and there's another problem [12:38] Laney, re bug 328224, it seems package in experimental didn't transition to new gnome-sharp2 packages [12:38] Launchpad bug 328224 in muine "Please sync muine 0.8.10-1 (universe) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/328224 [12:43] DktrKranz: is it uninstallable? [12:44] it is until we ship old gnome-sharp2 packages, which are scheduled for removal before release [12:44] DktrKranz, the gnome# transition is a mess. experimental doesn't help [12:44] aren't the old gnome-sharp2 packages already on NBS? [12:44] geser, they are [12:44] geser, yes [12:45] directhex, fortunately we're close to finish it [12:45] DktrKranz, excellent [12:45] DktrKranz: Then you'll submit all patches to Debian?! [12:45] ;) [12:45] iirc only package build-depending on it are still to be done (tomboy is in progress) [12:46] Laney, not sure if they already have new gnome-sharp2 [12:46] problem is there's a little API breakage as well as ABI [12:46] DktrKranz, in experimental... but experimental is a funny beast [12:46] heh :) [12:46] we need to do this transition somehow [12:46] we = debian [12:46] DktrKranz, i.e. you cherry-pick version numbers on things, so building against mono from exp but gnome# from sid is possible [12:46] and infact building against gnome# from exp is hard [12:46] I noticed ;) [12:47] but I noticed it in jaunty, which should *not* be a funny beast at this stage [12:47] re Debian experimental: someone set an alias for experimental on the Debian archive: rc-buggy :) [12:47] http://pastebin.com/d38c51efc lintian message misses the important part. do you know what is going wrong? [12:48] remove build-essential from your Build-Depends line in debian/control [12:48] directhex, Laney: except for b-d mangling, there aren't many changes. I just faced some GnomePrint routines (obsolete) to be removed [12:49] I use sed to make this transition ;) [12:49] sed -i 's/libgconf2.0-cil/libgconf2.24-cil/;s/libgnome2.0-cil/libgnome2.24-cil/;s/libgnome-vfs2.0-cil/libgnome-vfs2.24-cil/;s/libart2.0-cil/libart2.24-cil/' debian/control [12:49] geser: I had the build-dependency g++ before there. lintian wanted me to replace it with build-essential [12:50] c_korn: you don't need g++ in Build-Depends unless you need it versioned (very unlikely) [12:51] so g++ can be expected to be installed in every build environment? [12:52] DktrKranz, we can start to move things to unstable now, where the "funny" goes way..... but meebey's priority is now MD2 ;) [12:52] yes, it's guaranteed that build-essential (and it dependencies) are always installed [12:53] ok, thanks [12:53] directhex, if I can borrow a hand... I'm definitely not good in C#, but it's a good way to learn things [12:57] DktrKranz, i've been working hard in the background really at the debian end... if you need specific help with something, let me know [12:57] sure [12:57] thanks ;) [12:57] DktrKranz, i contribute to ubuntu through alioth & LAUNCHPAD ;p [12:58] BAH capslock === RainCT_ is now known as RainCT [13:30] DktrKranz: I will fix muine and muinescrobbler [13:31] * DktrKranz hugs Laney [13:34] <_16aR_> Hello === _16aR_ is now known as dolanor_ [13:44] does anybody notice sound issues with jaunty. my audio is quite distorted [13:53] is it possible to have some sort of orig.tar.gz like that : soft_x.y.z-revision.orig.tar.gz ? [13:53] with revision made of text [13:54] hi [13:54] im wanting to get involved [13:54] pop79: no problem :) [13:54] wait [13:54] dolanor, You can certainly do that, although it's only in the rare case you wish to do so. [13:54] Lot of work to be done :) [13:54] what im wanting to do is design a presentation of ubuntu [13:55] persia: the fact is that the revision is some sort of branch of the original soft. Not already released right now (I've asked upstream to do so). This branch only add Cmake support [13:55] dolanor: doesn't the 1.2.3.4.5.... scheme give you enough variables for defining your version ;-) [13:55] i was discussing it on #ubuntu-offtopic, but they didn't like the idea [13:55] pop79, Based on what you've said above, and what you've said on #ubuntu-devel, I'd recommend chatting with the folk in #ubuntu-docs to both build on the work already done, and integrate with future efforts. [13:56] ok [13:56] dolanor, Hrm. That's trickier. It's usually only used for things like ~ppaX or +dfsgX. Dunno how to advise you. [13:56] there is only one person there [13:56] mok0, Think multiple parallel trees... [13:56] persia: and since the original Makefile aren't that cool (I have to modify a lot to have shared lib compiling instead of static, with soname support, etc... With cmake, only a 1 line patch do this [13:57] or else, I do a static lib package, but I don't like the idea [13:58] there is soooo much i want to do to help the ubuntu project [13:58] as it is preferred to have dynamic lib into debian [13:58] (that's a 2d physcis engine in C++) [13:59] dolanor, I'd recommend working with upstream to build a common solution, rather than patching in a branch, and packaging your branch. It will save considerable coordinate issues later. [13:59] ok... I try to do with my version and see what happens ? [13:59] ok [14:00] because right now, the original upstream is ok to add cmake support. But hasn't done it. So the only package is an embedded archive in the forum. Or else you must get it from a branch in the svn [14:09] DktrKranz: Yes, I have the same issue. I believe there is a bug reported, not sure though. [14:10] iulian, nice to know. If you will remember, could you please subscribe me? [14:10] Sure [14:21] dolanor_: using x.y.z-revision as upstream is possible but you have to use an pkg-revision also, e.g. x.y.z-revision-0ubuntu1 [14:21] as packageversion [14:26] One shouldn't use "-" for that, if it can be avoided, as it's confusing. "+" is generally preferred. [14:27] no problems if I use + instead of - then ? [14:28] so If I use : box2d_2.0.1+cmake.orig.tar.gz, every body is ok ? [14:29] I can even drop the cmake if wanted. That was just better to track from what source it was since it wasn't the official release available in the download section of sourceforge [14:29] it's a least better than using 2.0.1-cmake [14:29] but i forgot to say that it correct some FTBFS error of the original package n linux :) so it is better anyway :) [14:30] allright, I'll use +cmake then, I'm happy with that :) [14:30] i'm going now, bye [14:31] dolanor, It's still *much* better to coordinate with upstream about it. [14:32] dolanor, Given that box2d isn't in either Ubuntu or Debian now, your best bet is to get it into squeeze sometime in the next couple months, and that gives you enough time for upstream to complete the transition and make a proper release. [14:35] Miriam has started packaging box2d in SVN [14:35] (not read context, ignore me if you know this) [14:52] If I modify the .diff.gz manually, is there some script to update the .diff.gz and .changes files accordingly? [14:53] why would you want to modify the .diff.gz manually? [14:53] RainCT, Just manually modify the md5sums. [14:54] RainCT, Be *very* careful manually adjusting diff.gz: use editdiff if you are at all unsure, and don't upload the result. [14:54] geser: to remove some crap from it to minimize the debdiff to the previous version, without having to touch debian/rules (as this would allso increase the diff) [14:54] RainCT, What! What are you doing? [14:54] don't worry, it's not for Ubuntu [14:54] :P [14:55] RainCT: why not edit the debdiff? [14:55] No, but trimming diff.gz to minimise debdiff is very rarely actually useful. [14:55] right, not really sure why I'm messing with this anyway XD [14:57] hi [14:58] geser: (because it's not me who is going to look at the debdiff, but someone else who will create it himself) [14:58] hi Tamass [14:58] :) [15:04] uhm.. why did cowbuilder-hardy login --bindmounts $(pwd) just delete everything I had in $(pwd)? -.- [15:07]