Re: gbp buildpackage makes wrong orig.tar.gz

On Fri, Sep 06, 2019 at 01:37:17AM +0900, Yukiharu YABUKI wrote: > The orig.tar.gz which has different size and contents will be > REJECTED. > > I'd like to upload and accept the package. So a typical XY problem. Just changing the top-level directory name is not enough to recreate t

Re: gbp buildpackage makes wrong orig.tar.gz

Hi The orig.tar.gz which has different size and contents will be REJECTED. I'd like to upload and accept the package. original tar.gz $ LANG=C;ls -la vim-voom_5.3.orig.tar.gz -rw-r--r-- 1 yabuki yabuki 115841 Aug 14 2018 vim-voom_5.3.orig.tar.gz gbp buildpackage made: -rw-r--r-- 1

Re: gbp buildpackage makes wrong orig.tar.gz

On Thu, Sep 05, 2019 at 11:29:04PM +0900, Yukiharu YABUKI wrote: > Hello, there. > > I am trying to solve the below problem. I use git buildpackage with > cowbuilder. How can I chage top directory name of orig.tar.gz which > made by gbp buildpackage. > > I would like cha

gbp buildpackage makes wrong orig.tar.gz

Hello, there. I am trying to solve the below problem. I use git buildpackage with cowbuilder. How can I chage top directory name of orig.tar.gz which made by gbp buildpackage. I would like change top diretory name to VOoM-5.3 from vim-voom_5.3. original: > tar ztvf vim-voom_5.3.orig.tar

Re: same upstream version but different orig.tar.gz

Hi Ferenc Wágner, > > > You can work around this locally by rewriting your .changes files; the > > > changestool utility in the reprepro packages can help with that.  But > > > you won't be able to upload different files with the same name.  The > > > usual solution is adding a numeric part to

Re: same upstream version but different orig.tar.gz

Herbert Fortes writes: >> You can work around this locally by rewriting your .changes files; the >> changestool utility in the reprepro packages can help with that.  But >> you won't be able to upload different files with the same name.  The >> usual solution is adding a numeric

Re: same upstream version but different orig.tar.gz

Hi, > > You can work around this locally by rewriting your .changes files; the > changestool utility in the reprepro packages can help with that.  But > you won't be able to upload different files with the same name.  The > usual solution is adding a numeric part to the version after +dfsg, like

Re: same upstream version but different orig.tar.gz

Herbert Fortes writes: > So I did a new Debian revision after the +dfsg.orig.tar.gz file be > replaced. > > I just did a 'debdiff' to check the differences between the Debian > revisions, and of course, the output is: > > dpkg-source: error: file

Re: same upstream version but different orig.tar.gz

Hello, On Tue, Aug 02, 2016 at 08:47:06PM -0300, Herbert Fortes wrote: > First I removed libAvKys/Plugins/VirtualCamera/ > directory. Generated a new .symbols file and > uploaded to experimental. Then I tested the > software. It did not run. An email to the upstream > was sent. > > Only

same upstream version but different orig.tar.gz

Hi, I am packaging a new version of webcamoid. This new version has some files with Ms-LPL license(nonfree). First I removed libAvKys/Plugins/VirtualCamera/ directory. Generated a new .symbols file and uploaded to experimental. Then I tested the software. It did not run. An email to the

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

Gianfranco, On 1 February 2016 at 11:36, Gianfranco Costamagna wrote: > this is annoying for me too, but I usually keep them installed or I remove > them after > sponsoring the package. > (for uploading I use source-only if possible, pbuilder, or DebOMatic as >

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

Hi, >Mostly because using "USE_PDEBUILD_INTERNAL=yes" in "~/.pbuilderrc" I>don't >have to install the build dependencies (which maybe >needed[1][2]) on the system itself, as it will take care of everything >on the chroot. Although I do have a machine which is reserved for >development only, I

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

uot; (as it says on the excerpt from the manual above), but as "--git-pbuilder" is being used, it is calling "pbuilder" instead. The problem is that the chapter "9.2. Including orig.tar.gz for upload"[2] doesn't have any mentions about how to use "-sa" with "pbuilde

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

Hi Gianfranco, On 30 January 2016 at 06:25, Gianfranco Costamagna wrote: > Hi, > > gbp buildpackage -S -sa works for me. > > Mentors strips binaries, so I don't understand why to call it with pbuilder :) Mostly because using "USE_PDEBUILD_INTERNAL=yes" in

Including "orig.tar.gz" for upload with gbp/git-buildpackage

By default it should call "debuild" (as it says on the excerpt from the manual above), but as "--git-pbuilder" is being used, it is calling "pbuilder" instead. The problem is that the chapter "9.2. Including orig.tar.gz for upload"[2] doesn't have any mentions

Bug#766583: [ti...@debian.org: [libgeotiff-dfsg] 01/01: pristine-tar data for libgeotiff-dfsg_1.4.0.orig.tar.gz]

...@lists.alioth.debian.org Subject: [libgeotiff-dfsg] 01/01: pristine-tar data for libgeotiff-dfsg_1.4.0.orig.tar.gz This is an automated email from the git hooks/post-receive script. tille pushed a commit to branch pristine-tar in repository libgeotiff-dfsg. commit

Bug#766583: [ti...@debian.org: [libgeotiff-dfsg] 01/01: pristine-tar data for libgeotiff-dfsg_1.4.0.orig.tar.gz]

Yep, thought about it when I saw the mail on pkg-grass-devel passing by -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#759605: [geographiclib] 01/01: pristine-tar data for geographiclib_1.37.orig.tar.gz

hooks/post-receive script. ross-guest pushed a commit to branch pristine-tar in repository geographiclib. commit 1d49e845eeba41bdd64f6d1533476af27744956c Author: Ross Gammon rossgam...@mail.dk Date: Fri Aug 29 22:15:38 2014 +0200 pristine-tar data for geographiclib_1.37.orig.tar.gz

Bug#757225: Please do not change orig.tar.gz! [Was: pyfftw_0.9.2+dfsg-2_amd64.changes REJECTED]

Hi Ghislain, I reimported the originally uploaded source tarball to the Git repository and uploaded again. Please make sure that the content of the repository matches what was uploaded before in the future. Kind regards Andreas. - Forwarded message from Debian FTP Masters

Windows/Mac Stuff in .orig.tar.gz

hello, the freeplane package's .orig.tar.gz contains some windows/mac stuff like *.ico, stuff for windows/mac installer etc.: $ find . -regex .*\(win\|mac\).* | grep -v java$ ./freeplane_framework/windows-installer ./freeplane_framework/windows-installer/WizModernImage-IS.bmp

Re: Windows/Mac Stuff in .orig.tar.gz

Hi Felix, No need to remove if: - the individual files haven't a proprietary license. - the files are source code. - the compiled files have a source code in the tarball. Regards, Eriberto 2014-02-16 7:33 GMT-03:00 Felix Natter fnat...@gmx.net: the freeplane package's .orig.tar.gz contains

Re: Windows/Mac Stuff in .orig.tar.gz

On Sun, Feb 16, 2014 at 6:33 PM, Felix Natter wrote: the freeplane package's .orig.tar.gz contains some windows/mac stuff like *.ico, stuff for windows/mac installer etc.: Without having looked at how these were created and if DFSG item 2 is satisfied... ./freeplane_framework/windows-icons

pdebuild without orig.tar.gz

Hi! I'm having some problems using pdebuild recently. I'm pretty sure this command worked before, and I have updated my pbuilder chroot. I don't have a orig.tar.gz, so I ask it to build a binary package, but I get this: *** $ pdebuild --debuildopts -b dpkg-buildpackage

Re: pdebuild without orig.tar.gz

On 2013-06-30 18:21, Torquil Macdonald Sørensen wrote: Hi! I'm having some problems using pdebuild recently. I'm pretty sure this command worked before, and I have updated my pbuilder chroot. I don't have a orig.tar.gz, so I ask it to build a binary package, but I get

git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

Dear all, After several months of using git-buildpackage with the recommended pristine-tar option I still keep making myself the following question. Why does git-buildpackage need pristine-tar to generate the orig.tar.gz file?. Can't it just pick the contents from the upstream branch together

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

Hi, On 03.12.2012 13:44, Miguel Telleria de Esteban wrote: and it works !! so why does not git-buildpackage do this? Try: md5sum $orig_tarball_from_pristine_Tar vs md5sum $orig_tarball_recreated_from_the_upstream_branch While the /contents/ of the tarball are identical, the tarball

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

to generate the orig.tar.gz file?. Can't it just pick the contents from the upstream branch together with version number from debian/changelog and regenerate the orig.tar.gz from it? In my limited experience if the upstream project uses git already and _tags_ stable releases it is very easy to avoid

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

On 12/03/2012 10:30 PM, Antonio Ospite wrote: in debian/gbp.conf there are just these lines: [DEFAULT] debian-branch = debian upstream-branch = master upstream-tag = v%(version)s By just running git buildpackage the package builds fine, and the .orig.tar.gz

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

On Mon, Dec 03, 2012 at 01:44:55PM +0100, Miguel Telleria de Esteban wrote: Why does git-buildpackage need pristine-tar to generate the orig.tar.gz file?. It doesn't and it's even not enabled by default. Can't it just pick the contents from the upstream branch together with version number

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

On Mon, Dec 03, 2012 at 03:30:09PM +0100, Antonio Ospite wrote: In my limited experience if the upstream project uses git already and _tags_ stable releases it is very easy to avoid using pristine-tar It's also very easy to avoid it in any other workflow: just don't enable it. There is no

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

Thanks everybody for your answers. After some review on my files and seeing your responses I can see that: * The orig.tar.gz was not created because the debian/changelog version lacked a - to differentiate upstream_version from debian versions. As a result gbp considered my

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

Miguel Telleria de Esteban mig...@mtelleria.com writes: * In a pure git storage scenario, pristine-tar doesn't add much benefit since we can always generate an orig.tar.gz from an upstream tag and obtain the same result... ... or maybe subsequent git-buildpackage invocations may

Re: git-buildpackage: can it recreate the orig.tar.gz without the pristine-tar?

On Mon, 03 Dec 2012 13:11:56 -0800 Russ Allbery wrote: Miguel Telleria de Esteban writes: ... or maybe subsequent git-buildpackage invocations may generate md5sum different .orig.tar.gz?? I guess not (although I will check). Every time you generate an *.orig.tar.gz file from

Re: creating an orig.tar.gz from a CVS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 09/02/2012 02:50, Jerome BENOIT a écrit : Hello List On 06/02/12 15:00, Xavier Grave wrote: Le 02/02/2012 22:43, Jerome BENOIT a écrit : In short, I have to do it by hand. You can still add a target in your debian/rules file to avoid doing

Re: creating an orig.tar.gz from a CVS

Hello List On 06/02/12 15:00, Xavier Grave wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 02/02/2012 22:43, Jerome BENOIT a écrit : In short, I have to do it by hand. You can still add a target in your debian/rules file to avoid doing it too many times :). See [1] for explanation

Re: creating an orig.tar.gz from a CVS

Hi Jerome, does someone know Debian packages using get-orig-source in d/rules ? For example you can look at my package: https://github.com/tehnick/libterm-shellui-perl-debian/blob/master/debian/rules Nothing difficult. You can add any script or list of commands to get-orig-source section of

Re: creating an orig.tar.gz from a CVS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 02/02/2012 22:43, Jerome BENOIT a écrit : In short, I have to do it by hand. You can still add a target in your debian/rules file to avoid doing it too many times :). See [1] for explanation for example about get-orig-source target. xavier [1]

Re: creating an orig.tar.gz from a CVS

Hello List: Thanks Xavier for the trick. After getting information from the upstream maintainer, it appears that the CVS have a dedicated Makefile to build the upstream package. Of course, this Makefile is not distributed within the upstream package, as other part of the CVS tree: the

Re: creating an orig.tar.gz from a CVS

Le 02/02/12 22:43, Jerome BENOIT a écrit : In short, I have to do it by hand. In short, yes, that has been my understanding so far :-) But it's so simple that adding a dpkg-cvs-makeorigtgz script on top of that would just be confusing for no real benefit. Just make sure you exclude the CVS

creating an orig.tar.gz from a CVS

Hello List: what is the best Debian way to create a package orig.tar.gz from a CVS ? Thanks in advance. Best, Jerome -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http

Re: creating an orig.tar.gz from a CVS

Hello! Checkout from CVS. Run ./configure or equal. Run 'make tar' or 'make package' or 'make rpm' or 'make dist' or whatever the corresponding target in makefile is named. Then rename the produced tar.gz / bz2 to orig.tar.gz / bz2 Cheers, Björn. 2012/2/2 Jerome BENOIT g62993...@rezozer.net

Re: creating an orig.tar.gz from a CVS

is named. Then rename the produced tar.gz / bz2 to orig.tar.gz / bz2 Cheers, Björn. 2012/2/2 Jerome BENOITg62993...@rezozer.net: Hello List: what is the best Debian way to create a package orig.tar.gz from a CVS ? Thanks in advance. Best, Jerome -- To UNSUBSCRIBE, email to debian-mentors-requ

Re: creating an orig.tar.gz from a CVS

Le 02/02/12 18:56, Jerome BENOIT a écrit : Hello List: what is the best Debian way to create a package orig.tar.gz from a CVS ? Thanks in advance. Best, Jerome cvs export -d directory module ... tar cvf - directory | gzip -9 package_version.orig.tar.gz -- To UNSUBSCRIBE, email

Re: creating an orig.tar.gz from a CVS

In short, I have to do it by hand. Jerome On 02/02/12 20:51, Thibaut Paumard wrote: Le 02/02/12 18:56, Jerome BENOIT a écrit : Hello List: what is the best Debian way to create a package orig.tar.gz from a CVS ? Thanks in advance. Best, Jerome cvs export -ddirectory module ... tar

Re: creating an orig.tar.gz from a CVS

On Thu, Feb 02, 2012 at 10:43:34PM +0100, Jerome BENOIT wrote: In short, I have to do it by hand. Tarballs are usually created by upstream when making a release. There are a variety of build system (autotools, CMake, etc) that provide a standard way to prepare a release tarball: if your

Re: Stripping non-free/unnecessary files out of orig.tar.gz

Hi Anton, On Mon, 2011-06-13 at 22:30 +0200, Ove Kåven wrote: Den 12. juni 2011 19:13, skrev Anton Martchukov: In my package (opencpn) there are couple of binary files without source code/with unfree license that is required only for OS X and Windows builds (those are some dlls and

Re: Stripping non-free/unnecessary files out of orig.tar.gz

On 06/15/2011 03:27 PM, Kilian Krause wrote: Definitely. And name your version with suffix +debian or ~debian as you see fit. We are very often using +dfsg in the version, as in: upstream-version+dfsgdfsg-version-debian-release This way, you have the possibility to have dfsg-version to

Re: Stripping non-free/unnecessary files out of orig.tar.gz

Hi Thomas, On Wed, 2011-06-15 at 21:16 +0800, Thomas Goirand wrote: On 06/15/2011 03:27 PM, Kilian Krause wrote: Definitely. And name your version with suffix +debian or ~debian as you see fit. We are very often using +dfsg in the version, as in: -(snip)- right. Mixed that up.

Re: Stripping non-free/unnecessary files out of orig.tar.gz

On 06/12/11 19:13, Anton Martchukov wrote: Hello All. In my package (opencpn) there are couple of binary files without source code/with unfree license that is required only for OS X and Windows builds (those are some dlls and redistributable files). Upstream does like to keep them in

Re: Stripping non-free/unnecessary files out of orig.tar.gz

Den 12. juni 2011 19:13, skrev Anton Martchukov: In my package (opencpn) there are couple of binary files without source code/with unfree license that is required only for OS X and Windows builds (those are some dlls and redistributable files). Upstream does like to keep them in original

Stripping non-free/unnecessary files out of orig.tar.gz

system and I obviously get lintian warning about them. What is the proper way to handle this? I created a simple script that does tar --exclude ... and creates opencpn_2.4~611.orig.tar.gz out of upstream git repository. However I look to be havong some problems with quilt due to this when I try

create orig.tar.gz

Hello mentors, Exist some way to create project_version.orig.tar.gz from project-version.tar.gz without complete debianization? And make md5 for both files identical? best regards mira -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe.

Re: create orig.tar.gz

to project_version.orig.tar.gz. The orig.tar.gz is supposed to contain the tarball like you receive it from upstream. Adrian -- 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

Re: create orig.tar.gz

Jaromír Mikeš mira.mi...@seznam.cz (28/02/2010): Exist some way to create project_version.orig.tar.gz from project-version.tar.gz without complete debianization? And make md5 for both files identical? Sure: mv does that. :) Mraw, KiBi. signature.asc Description: Digital signature

Re: create orig.tar.gz

Od: Adrian Glaubitz glaub...@physik.fu-berlin.de Yes, just rename the original tarball to project_version.orig.tar.gz. The orig.tar.gz is supposed to contain the tarball like you receive it from upstream. Yep ... sometimes is solution in front of nose ;) thank you mira

Re: create orig.tar.gz

Od: Jaromír Mikeš mira.mi...@seznam.cz Yes, just rename the original tarball to project_version.orig.tar.gz. The orig.tar.gz is supposed to contain the tarball like you receive it from upstream. Yep ... sometimes is solution in front of nose ;) BTW what about orig.tar.bz2 is it allowed

Re: create orig.tar.gz

On Sun, Feb 28, 2010 at 10:18:37PM +0100, Jaromír Mikeš wrote: BTW what about orig.tar.bz2 is it allowed to us it? Yes, with source format 3.0 [1]. If not how to convert to tar.bz2 to orig.tar.gz with same md5 easily? You cannot. They're totally different compression types, so they produce

Re: create orig.tar.gz

Hi Jaromir, On Sun, Feb 28, 2010 at 10:18:37PM +0100, Jaromír Mikeš wrote: Od: Jaromír Mikeš mira.mi...@seznam.cz Yes, just rename the original tarball to project_version.orig.tar.gz. The orig.tar.gz is supposed to contain the tarball like you receive it from upstream. Yep

Re: create orig.tar.gz

On Sun, Feb 28, 2010 at 09:23:12PM +, Jonathan Wiltshire wrote: Yes, with source format 3.0 [1]. 1: http://wiki.debian.org/Projects/DebSrc3.0 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: create orig.tar.gz

Od: Jonathan Wiltshire deb...@jwiltshire.org.uk Yes, with source format 3.0 [1]. 1: http://wiki.debian.org/Projects/DebSrc3.0 Thank you all ... make things clearer for me I have been unsure best regards mira -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a

Re: create orig.tar.gz

rename the original tarball to project_version.orig.tar.gz. The orig.tar.gz is supposed to contain the tarball like you receive it from upstream. It is also common to have the original tarball keep the same name, and ‘ln -s foo-x.y.z.tar.gz foo_x.y.z.orig.tar.gz’. That way, manually checking the same

Re: create orig.tar.gz

Le Sun, Feb 28, 2010 at 10:23:24PM +0100, Adrian Glaubitz a écrit : As far as I know, bzip2 is supported in the source format 3.0 or newer. So, no need for conversion. If you want to convert, just decompress and repack with gzip. When you change the compression, you can't keep the same

Re: create orig.tar.gz

On Mon, 1 Mar 2010, Charles Plessy wrote: And also, the md5sum of the gzipped archive made from the original bzipped archive can vary from conversion to conversion unless the option ``--no-name'' is passed to gzip. We're dangerously digressing into pristine-tar's domain here. [0] From: Joey

Re: Reforming 'orig.tar.gz' with included tar-ball.

onsdag den 27 januari 2010 klockan 10:01 skrev Paul Wise detta: On Wed, Jan 27, 2010 at 10:00 AM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: The upstream author is a long time Debian Developer that has not touched the code since 2004. Ah, I guess you could/should take

Re: Reforming 'orig.tar.gz' with included tar-ball.

On Wed, Jan 27, 2010 at 10:46 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: It is Webfs, for its purpose a useful web server, but the present versions of Gcc emit warnings due to inconsistent string types. Ah, looks like upstream doesn't use a hosting service like sf.net. If

Re: Reforming 'orig.tar.gz' with included tar-ball.

torsdag den 28 januari 2010 klockan 07:11 skrev Paul Wise detta: On Wed, Jan 27, 2010 at 10:46 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: It is Webfs, for its purpose a useful web server, but the present versions of Gcc emit warnings due to inconsistent string types.

Reforming 'orig.tar.gz' with included tar-ball.

Hello all mentors, I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file

Re: Reforming 'orig.tar.gz' with included tar-ball.

. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking

Re: Reforming 'orig.tar.gz' with included tar-ball.

Mats Erik Andersson wrote: Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). It's nothing wrong and even preferable to convert your

Re: Reforming 'orig.tar.gz' with included tar-ball.

in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me

Re: Reforming 'orig.tar.gz' with included tar-ball.

dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking the step

Re: Reforming 'orig.tar.gz' with included tar-ball.

Hello, Mats Erik Andersson mats.anders...@gisladisker.se wrote: To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file

Re: Reforming 'orig.tar.gz' with included tar-ball.

Joachim Wiedorn ad_deb...@joonet.de writes: Hello, Mats Erik Andersson mats.anders...@gisladisker.se wrote: To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice

Re: Reforming 'orig.tar.gz' with included tar-ball.

the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Please do so, tarball-in-tarball packages are horrible. With 3.0 (quilt) format there is much less reason to use them

Re: Reforming 'orig.tar.gz' with included tar-ball.

maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Please do so, tarball-in-tarball packages are horrible. With 3.0 (quilt) format

Re: Reforming 'orig.tar.gz' with included tar-ball.

On Wed, Jan 27, 2010 at 10:00 AM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: The upstream author is a long time Debian Developer that has not touched the code since 2004. Ah, I guess you could/should take over this project too. Which package is it BTW? -- bye, pabs

Re: repackaged .orig.tar.gz (was: RFS: libmsn)

* Pau Garcia i Quiles [Wed, 19 Nov 2008 00:11:44 +0100]: True, on the other hand the Developer's Reference suggests in 6.7.8.2: A repackaged .orig.tar.gz [..] 4. should use -.orig as the name of the top-level directory in its tarball. This makes it possible

repackaged .orig.tar.gz (was: RFS: libmsn)

hand the Developer's Reference suggests in 6.7.8.2: A repackaged .orig.tar.gz [..] 4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones

Re: repackaged .orig.tar.gz

On Tue, 18 Nov 2008 23:58:36 +0100, Adeodato Simó wrote: You should not, dpkg-source copes well enough. True, on the other hand the Developer's Reference suggests in 6.7.8.2: 4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball.

Re: repackaged .orig.tar.gz (was: RFS: libmsn)

more difficult, or not rename the directory in the .orig.tar and make tamper-checking easier? You should not, dpkg-source copes well enough. True, on the other hand the Developer's Reference suggests in 6.7.8.2: A repackaged .orig.tar.gz [..] 4. should use -.orig as the name

Re: repackaged .orig.tar.gz (was: RFS: libmsn)

should not, dpkg-source copes well enough. True, on the other hand the Developer's Reference suggests in 6.7.8.2: A repackaged .orig.tar.gz [..] 4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball. This makes it possible

No orig.tar.gz or diff.gz with pdebuild

I'm trying to build some packages, and am using the following: pdebuild --auto-debsign --buildresult /tmp/$(basename $PWD) \ --debsign-k 0x5005EF07 --debbuildopts -D -sa The packages build properly, but despite the -sa option I'm not getting the orig.tar.gz or a diff.gz file added

Re: No orig.tar.gz or diff.gz with pdebuild

On Sat, 8 Mar 2008 13:44:41 -0800 Todd A. Jacobs [EMAIL PROTECTED] wrote: The packages build properly, but despite the -sa option I'm not getting the orig.tar.gz or a diff.gz file added to the relevant .changes or .dsc files. I do, however, get a tar.gz file with the current source tree

Re: No orig.tar.gz or diff.gz with pdebuild

On Sat, Mar 08, 2008 at 11:36:45PM +, Neil Williams wrote: Have you inadvertently made a native version? I'm not sure that's it's really inadvertent at this point. Since my original message, I've changed the naming scheme in the changelog revision entries, which may indeed have been causing

Re: No orig.tar.gz or diff.gz with pdebuild

On Sat, 8 Mar 2008 13:44:41 -0800, Todd A. Jacobs [EMAIL PROTECTED] said: The packages build properly, but despite the -sa option I'm not getting the orig.tar.gz or a diff.gz file added to the relevant .changes or .dsc files. I do, however, get a tar.gz file with the current source tree

Re: No orig.tar.gz or diff.gz with pdebuild

On 08/03/2008, Todd A. Jacobs wrote: If I try to do a standard build, I get all sorts of errors like: No. Not all are errors. dpkg-source: cannot represent change to test/test_compare/compare_siemens/siemens_010_f.png: binary file contents changed dpkg-source: cannot represent

file encoding and eol marker in orig.tar.gz

Hi! I am polishing the packages for omegat (#448867) and libhtmlparser-java (#448872) and I have a few questions. The background is that I already have to repackage upstream tarball, because they contain compiled jars. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: I am polishing the packages for omegat (#448867) and libhtmlparser-java (#448872) and I have a few questions. The background is that I already have to repackage upstream tarball, because they contain compiled jars. 1) Should I

Re: file encoding and eol marker in orig.tar.gz

they are regenerated. But of course I may be completely missing the point. :-) The idea is that FTP master rejects abt binary content in your orig.tar.gz for which you don't have source. So, if you package for Java, remove all the jars, package them from their source, and repackage your original

Re: file encoding and eol marker in orig.tar.gz

them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) The idea is that FTP master rejects abt binary content in your orig.tar.gz for which you don't have source. So, if you package for Java, remove

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: The background is that I already have to repackage upstream tarball, because they contain compiled jars. I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: The background is that I already have to repackage upstream tarball, because they contain compiled jars. I don't know much about java, but if those are just

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 10:09:59AM -0500, Justin Pryzby wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is

Re: file encoding and eol marker in orig.tar.gz

On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged

Re: debian .orig.tar.gz vs. upstream tar.gz

Hi, Kapil Hari Paranjape [EMAIL PROTECTED] wrote: On Mon, 27 Aug 2007, Jörg Sommer wrote: Do *not* get the upstream .tar.gz which may have changed for some mysterious reason. I don't think the upstream tar.gz have changed, but your orig.tar.gz is not the same as the upstream tar.gz

Re: debian .orig.tar.gz vs. upstream tar.gz

change that to a *should* :-) And I would change debian/changelog and/or README.Debian-source to debian/copyright, where the information about how orig.tar.gz was obtained belong. Regards, T.

debian .orig.tar.gz vs. upstream tar.gz

Hello, I got hit by this so I wanted to note it down where it might be of use to others. It *is* elementary but then ... Suppose pkg_123.45.orig.tar.gz is already in the Debian archive. To build a new version pkg_123.45-xxx of the Debian package. *Always* use the Debian version

Re: debian .orig.tar.gz vs. upstream tar.gz

that the upstream .tar.gz has had to be repacked for some reason? Suppose pkg_123.45.orig.tar.gz is already in the Debian archive. What is the current Debian version? To build a new version pkg_123.45-xxx of the Debian package. *Always* use the Debian version of the .orig.tar.gz by doing apt

Re: debian .orig.tar.gz vs. upstream tar.gz

On Mon, Aug 27, 2007 at 10:44:20AM +0100, Neil Williams wrote: Kapil Hari Paranjape [EMAIL PROTECTED] wrote: *Always* use the Debian version of the .orig.tar.gz by doing apt-get -d source pkg. Do *not* get the upstream .tar.gz which may have changed for some mysterious reason

  1   2   3   >