Re: upstream source is a source rpm!
On Mon, Mar 12, 2012 at 11:20 AM, Paul Elliott
pelli...@blackpatchpanel.com wrote:
I have an upstream source who did not put his source in a tarball, and then
put the tarball in a source rpm, (as would be usual in the rpm world).
Instead, he put his source files directly in the source .rpm file!
The best way to educate them about something called: .tar.gz :)
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPDygexNG1KFcA2c+BKtsMERNpmwATm-Cvq=8KwLKo=bqst...@mail.gmail.com
Re: upstream source is a source rpm!
Paul, On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: I can unpack this thingy with: rpm2cpio source.rpm | cpio -i But I have questions: Assuming I have the url of the source rpm, how would one write the watch file and get-orig-source: in rules to create a proper .ds tarball? watch file should be easy to write: this is just a regex and it should not care about the file extension. What you need to do is something like this: http://anonscm.debian.org/viewvc/pkg-java/trunk/fop/debian/watch?view=markup See how watch files are flexible ? Just provide an orig-tar.sh script yourself (using rpm2cpio for example) Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note this dependancy anywhere? No. You should repack the source using .xy, .gz, .bz2 only in your orig-tar.sh script. Make sure to exit with an error in orig-tar.sh when rpmcpio is not present, and you should be ready to roll. 2cts -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsyG5HK5VNUTkzO4OR=yob3vx+bevoxpe5a+nmecgqm...@mail.gmail.com
Re: upstream source is a source rpm!
I would do what Kartik said, file a bug upstream and wait for them to make a proper tarball. It will be useful for other distributions as well, not just Debian.
Bug#662955: RFS: rubyripper/0.6.2-2 [ITP] -- New upload
Dear mentors,
I am looking for a sponsor for my package rubyripper
* Package name: rubyripper
Version : 0.6.2-2
Upstream Author : Bouke Woudstra boukewouds...@gmail.com
* URL : https://code.google.com/p/rubyripper/
* License : GPL-3.0+
Section : sound
It builds those binary packages:
rubyripper-cli - Error-correcting compact disc digital audio extractor (CD
ripper)
rubyripper-gtk2 - Error-correcting compact disc digital audio extractor (CD
ripper)
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/rubyripper
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/r/rubyripper/rubyripper_0.6.2-2.dsc
More information about rubyripper can be obtained from
http://wiki.hydrogenaudio.org/index.php?title=Rubyripper
Changes since the last upload:
rubyripper (0.6.2-2) unstable; urgency=low
* Removed unnecessary ${shlibs:Depends} variable from dependencies.
* Change package priority to Optional.
* Unset unnecessary DH_VERBOSE in debian/rules.
* Add several optional packages to Suggests.
* Update debian/copyright to latest format.
* Improve package description in debian/control and manpage.
* Split upstream patch into two.
* Add two more patches to upstream:
Fix calls to deprecated API 'gettext/utils'.
Remove prerequisite to Makefile 'install' target to avoid compiling
translations twice.
* Disable updating of .po files due to crash in ruby 1.9.x.
* Add patch to use correct API for mofile generation function.
-- Scott Leggett sc...@sl.id.au Mon, 12 Mar 2012 16:13:16 +0800
--
Regards,
Scott.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203121648.36385.sc...@sl.id.au
Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Russ Allbery r...@debian.org writes: Goswin von Brederlow goswin-...@web.de writes: But then you have to split your workflow again. You have to edit upstream files in the master branch and debian files in the debian branch. Switching between the branches becomes a pain and working in 2 workdirs is also a pain. To testbuild you then need to merge from master to debian and so on. That is basically as bad as having 2 seperate git repositories, one for upstream and one for debian. This is how I actually want to work; I prefer the separation. But I can see why you don't want to do things this way (and indeed several of my coworkers prefer to maintain our local packages as native packages to avoid this separation). It does mean cherry-picking things back and forth a bunch while solving some packaging-related problems. The upstream branchs buys me that other people stop complaining that my package is native. Ah! Okay, I had somewhat misunderstood the problem. So in that case the only purpose the upstream branch is serving for you is that it's an export of the tarball distribution that you can base pristine-tar on, without forcing pristine-tar to maintain a delta to remove all the debian/* files. In that case, I would not bother with any of the merging logic and would maintain the upstream branch as a pure tarball import with git-import-orig without merging it. That means it would be a disconnected branch without the correct history, but at that point you don't care since it's only there for pristine-tar to use. Git will still do global object deduplication, so you'll get the compression advantages. So, in other words, branch upstream off of master, remove and commit the removal of the debian/* files, and then from that point forward your packaging method is to run make dist (which would omit the debian/* files), git-import-orig the tarball with --no-merge, and then build with git-buildpackage as you would normally do. I glanced at it but wasn't sure how to apply that to my setup where I merge from master to upstream. Looking at it again I think debian/import-upstream tarball master upstream/x.y would be correct. Will try that when I find the time to recreate the repository. Yes, that would work if you want to preserve the history. But since nothing other than pristine-tar is going to look at the upstream branch, I'm not sure I'd bother. Other people might. So say RH wants to see what has changed between upstream/1.0 and upstream/1.1 then the interconnect of the histories will allow them to see the seperate commits. Looks better in qgit even to me, better than as disconnected branch. I'm fine with experimenting a bit now trying things and will use that on 5 or 6 projects. Making things easier for other people is a good thing. If I can do it with just some initial overhead and no running costs (other than some extra commands in the release target or so) then I'm all for it. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipiaayak.fsf@frosties.localnet
Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
* Goswin von Brederlow goswin-...@web.de [120311 19:51]: git-dpm? http://git-dpm.alioth.debian.org/ http://wiki.debian.org/PackagingWithGit/GitDpm That would still make git think that your upstream branch is based on your master branch and thus has the modification remove debian/ in it which git will want to merge with any debian changes in the upstream branch once you merge the two. That was the merge. After that there is nothing more to merge. And the next merge will do the same git-import-orig + merge -s ours trick. But how do you get a new upstream code into master? If you try to update upstream and merge it in master, it will think you want to remove debian/ Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312110006.gd2...@client.brlink.eu
Re: upstream source is a source rpm!
Mathieu Malaterre mathieu.malate...@gmail.com writes: Paul, On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: I can unpack this thingy with: rpm2cpio source.rpm | cpio -i But I have questions: Assuming I have the url of the source rpm, how would one write the watch file and get-orig-source: in rules to create a proper .ds tarball? watch file should be easy to write: this is just a regex and it should not care about the file extension. What you need to do is something like this: http://anonscm.debian.org/viewvc/pkg-java/trunk/fop/debian/watch?view=markup See how watch files are flexible ? Just provide an orig-tar.sh script yourself (using rpm2cpio for example) Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note this dependancy anywhere? No. You should repack the source using .xy, .gz, .bz2 only in your orig-tar.sh script. Make sure to exit with an error in orig-tar.sh when rpmcpio is not present, and you should be ready to roll. I always hate when you patch a source or update the upstream part and suddenly things break because some tools are missing. I know they don't fall under Build-Depends and buildds should not need to install them. But maybe there could be a new Build-Depends-Extras field for things like this? MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehsyay42.fsf@frosties.localnet
Re: upstream source is a source rpm!
On Mon, Mar 12, 2012 at 11:54 AM, Goswin von Brederlow goswin-...@web.de wrote: Mathieu Malaterre mathieu.malate...@gmail.com writes: Paul, On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: I can unpack this thingy with: rpm2cpio source.rpm | cpio -i But I have questions: Assuming I have the url of the source rpm, how would one write the watch file and get-orig-source: in rules to create a proper .ds tarball? watch file should be easy to write: this is just a regex and it should not care about the file extension. What you need to do is something like this: http://anonscm.debian.org/viewvc/pkg-java/trunk/fop/debian/watch?view=markup See how watch files are flexible ? Just provide an orig-tar.sh script yourself (using rpm2cpio for example) Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note this dependancy anywhere? No. You should repack the source using .xy, .gz, .bz2 only in your orig-tar.sh script. Make sure to exit with an error in orig-tar.sh when rpmcpio is not present, and you should be ready to roll. I always hate when you patch a source or update the upstream part and suddenly things break because some tools are missing. I know they don't fall under Build-Depends and buildds should not need to install them. But maybe there could be a new Build-Depends-Extras field for things like this? That seems terribly complicated instead of adding another compression backend to uscan. uscan properly support repacking .zip into .tgz. I have seen java package distributing source files in a .jar file :) 2cts -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wusy3oyu0quxs6ynwf7yl7jp4jvadq2deh9qfyxvhehn...@mail.gmail.com
Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Bernhard R. Link brl...@debian.org writes: * Goswin von Brederlow goswin-...@web.de [120311 19:51]: git-dpm? http://git-dpm.alioth.debian.org/ http://wiki.debian.org/PackagingWithGit/GitDpm That would still make git think that your upstream branch is based on your master branch and thus has the modification remove debian/ in it which git will want to merge with any debian changes in the upstream branch once you merge the two. That was the merge. After that there is nothing more to merge. And the next merge will do the same git-import-orig + merge -s ours trick. But how do you get a new upstream code into master? If you try to update upstream and merge it in master, it will think you want to remove debian/ Bernhard R. Link I am upstream and I edit master so the code is already in master. The job is getting it into upstream when I roll the orig.tar.gz. So before upload I now run: @set -e;\ if git tag | grep -q ^upsteam/$(UPSTREAM_VERSION)$$; then \ echo Upstream $(UPSTREAM_VERSION) already exists.; \ else\ echo Creating $(ORIG_NAME) ...; \ git archive --format=tar.gz --output=$(ORIG_NAME) \ --prefix=$(SOURCE)-$(UPSTREAM_VERSION)/ \ --worktree-attributes HEAD; \ git-import-orig --no-merge --pristine-tar \ --upstream-version=$(UPSTREAM_VERSION)\ $(ORIG_NAME); \ echo Merging into upstream; \ git checkout upstream;\ git merge -s ours master; \ git checkout master; \ fi @echo Tagging release debian/$(VERSION) @git tag debian/$(VERSION) Those 2 checkouts can be avoided if I adopt the import+merge in one go magic from openafs but for the libaio-ocaml 1.0-1 upload the above is what I did. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx7lamx1.fsf@frosties.localnet
Re: RFS: trash-cli
Hi Javi :-), I've set up a repository in git.debian.org[0] and imported the history of the previous (deceased) package and the version you uploaded to mentors. See [1] to know how to get write access to it. [0] http://anonscm.debian.org/gitweb/?p=collab-maint/trash-cli.git;a=summary [1] http://alioth.debian.org/projects/collab-maint/ Thank you :-) I'll work on it. I just got answers from the upstream author and I have all info to work on it. About volume-of, I got confirmation that the command is removed upstream. Do I need to update man page or not? Cheers, Stefano -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/955a8642d9f02c3cdb98cf3fa4a9a...@karapetsas.com
Bug#660519: Re[2]: Bug#660519: RFS: manaplus/1.2.2.19
On Tue, Mar 6, 2012 at 8:43 AM, andrei karas wrote: Now i not sure. For me now task add manaplus to debian, after we will see. Ok, I would encourage you to join the team and help out with other games too. For now no, but in future yes. Now server not in state for packaging, need many work for adapt it to work from separate directories. Also it can work only in 32 bit version. Server from what it forked storing pointers in int and have some other 64 bit issues. Fair enough. Registration is simple, In game client need press register and enter login and password. I can create preregistered account but not sure what password i can put in public, because some one can change it after. Gotcha. SVG image was not drawed for manaplus, but used same as in mana. I removed it For other one image i add xcf file, but sad it in 2.7 gimp format or like this. I also removed some themes because license GPL and i dont have response from author about sources. Other themes relicensed from GPL to CC-BY-SA. Other themes from data/graphics/gui is a bit modified theme from mana client/package data/themes/wood is theme from tmw package (branding for mana) tmw and mana now in debian and i think if it accepted, then this themes here can be accepted too. ... It based in one of ogg files from The Mana World sounds. I simple cut and add delay to one channel. I can include ogg file as source if need. Also in new version i add sounds from psiplus package converted to ogg and some renamed. Should i also include source wav files? It sounds like you have included the source as you are using it and prefer it. I would encourage you to reconsider what the most useful form for modification of your audio/graphics is; personally I would not consider premixed audio or prerendered graphics to be my preferred form for modification: http://www.freedesktop.org/wiki/Games/Upstream#Source Manaplustest need for autocheck graphics settings/speed and add it to configuration. Desktop file removed. Thanks. I thinking about SDL-Pango not sure is it good to use it here. Since you are using SDL-TTF, SDL-Pango is the best choice here IMO. About fontconfig. Is possible with it create link to fonts with given names? Search for fontconfig in this code that I wrote, it is pretty easy: http://chromium-bsu.git.sourceforge.net/git/gitweb.cgi?p=chromium-bsu/chromium-bsu;a=blob;f=src/TextFTGL.cpp I left system call for now, but strict text what can be given to it. (only static or always safe strings allowed) Good, please consider switching to exec in the future though. I thinking about this. This possible in future versions. Cool. I removed most duplicates. Some left because this files accessed by physfs and in physfs soft links not allowed. I allow it only for fonts enumeration. I see, please file a bug on physfs upstream about this issue. This is all false positives. The first one is definitely not since the destructor does not delete the OpenGLGraphicsVertexes object. The second one indeed seems to be a false positive, please file a bug on cppcheck upstream. Some dont fixed other is by design in internal commands/events. Ah, OK. If you want to add an explanation for that you can override the lintian warning and add a comment in the override file. current dsc file: http://mentors.debian.net/debian/pool/main/m/manaplus/manaplus_1.2.3.4-1.dsc Here is an updated review: In the registration process there is an option for Male or Female. I would suggest removing that or adding an Other category since both gender and biological sex have more options than that. Often people who do not fit into either of these categories will be very offended to have to label themselves as Male or Female. The initial download when logging into a server is quite big, is that a per-server thing like with web browsers or can it be added to Debian? The first line in debian/copright should point at this URL instead now: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ You might want to switch to debhelper compat 9 so that manaplus gets built with security hardening compiler flags. This is especially important since manaplus is a network client. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HN94=dycpazgchdkbrxjsutnrfds3wfi8hoyoofrz...@mail.gmail.com
