On Fri, Nov 22, 2024 at 03:56:02PM +0100, Andreas Tille wrote:
> This problem does not occure when I build locally with pbuilder and I
> have no idea what's wrong here.
The answer is still "you have pristine-tar enabled locally; noone else
knows that".
--
WBR, wRAR
signature.asc
Description: P
Em ter., 15 de mar. de 2022 às 13:29, escreveu:
>
> > > Why should it matter to anything, including Debian, unless there are
> > > technical problems caused by that?
> >
> > So such as not compiling. Or another reason not yet shared with us.
> >
>
> No problem with building the package. I just sa
> > Why should it matter to anything, including Debian, unless there are
> > technical problems caused by that?
>
> So such as not compiling. Or another reason not yet shared with us.
>
No problem with building the package. I just saw a comment on a bug and I was
in doubt [1].
I decided to ask
RLF?
> Why should it matter to anything, including Debian, unless there are
> technical problems caused by that?
So such as not compiling. Or another reason not yet shared with us.
> > The question is about the upstream source code, not to the debian directory.
As Andrey says: No need
On Mon, Mar 14, 2022 at 12:25:53PM -0300, Lourisvaldo Figueredo Junior wrote:
> I have a doubt. In cases where the upstream uses the MS-DOS pattern CRLF
> ("\r\n") to end of line, instead Unix pattern LF ("\n").
> In this situation, should the maintainer make a patch converting this files
> to
>
' to build a package from source keeping the MS-DOS
pattern CRLF?
The question is about the upstream source code, not to the debian directory.
Thank so much.
signature.asc
Description: This is a digitally signed message part.
On Thu, Mar 26, 2020 at 11:51:59AM -0400, Calum McConnell wrote:
> Okay, thanks: but isn't my new package a non-native package?
Is it your package or just a rebuild of an existing 3rd-party native one?
> Yes, the upstream happens to be a Debian redistribution: but there is an
> &q
en I tried to run
> > debuild,
> > I got the attached text file as the output.
> >
> > What is going on here? The upstream tarball clearly exists, but
> > debuild
> > doesnt see it?
Okay, thanks: but isn't my new package a non-native package? Yes, the
upstr
On 2020-03-18, at 13:49:29 -0400, Calum McConnell wrote:
> So, I was looking at repackaging Yannubuntu/boot-repair for Sid
> because when I first set up my debian dual-boot, I had to use to to
> actually dual boot. I followed the instructions in the wiki for
> repackaging PPA's, and added a new ch
The old version number was for a "native package" - with no trailing dash
and Debian package revision. When you added your suffix of -1, that implied
a non-native package for which there should be an orig tarball and a Debian
diff tarball.
Use + (to increase vs. version without) or ~ (to decrease
On Wed, Mar 18, 2020 at 01:49:29PM -0400, Calum McConnell wrote:
> calum@CalumsDebianSupreme:~/package/boot-repair/boot-repair_4ppa69-1$ ls
> boot-repair_4ppa69.orig.tar.gz debian docs etc po usr
The orig tarball must be in the parent directory.
> calum@CalumsDebianSupreme:~/package/boot-repa
So, I was looking at repackaging Yannubuntu/boot-repair for Sid because
when I first set up my debian dual-boot, I had to use to to actually
dual boot. I followed the instructions in the wiki for repackaging
PPA's, and added a new changelog entry (as well as changing the package
to be a quilt inst
On Sun, Aug 14, 2016 at 11:27 PM, Jerome BENOIT wrote:
> is there a simple way with uscan(1) to add a single PDF document
> as complement to the upstream source ball ?
It appears that mk-origtargz only allows repacking zip/tar files:
unless ($is_zipfile or $is_tarfile) {
# TODO: Sho
Hello Forum,
is there a simple way with uscan(1) to add a single PDF document
as complement to the upstream source ball ?
Thanks in advance,
Jerome
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello Paul:
On 02/03/16 04:27, Paul Wise wrote:
> On Wed, Mar 2, 2016 at 8:48 AM, Jerome BENOIT wrote:
>
>> I have just tried to download the source, I get
>>
>> Parameter ../6.10.26 does not look like a tar archive or a zip file. at
>> /usr/bin/
On Wed, Mar 2, 2016 at 8:48 AM, Jerome BENOIT wrote:
> I have just tried to download the source, I get
>
> Parameter ../6.10.26 does not look like a tar archive or a zip file. at
> /usr/bin/mk-origtargz line 375.
That happens after the download is done.
> Let get more hacky: what must be added
Hello:
On 01/03/16 17:50, Paul Wise wrote:
> On Tue, 2016-03-01 at 17:04 +0100, Jerome BENOIT wrote:
>
>> Of course, the version is somewhere in the source:
>> the issue would be solved if the automates could play with the involved file.
>
> pagemangle should be able to take care of that.
>
>>
On Tue, 2016-03-01 at 17:04 +0100, Jerome BENOIT wrote:
> Of course, the version is somewhere in the source:
> the issue would be solved if the automates could play with the involved file.
pagemangle should be able to take care of that.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802176
Hello Forum:
Thanks for your prompt reply.
On 01/03/16 06:51, Paul Wise wrote:
> On Tue, Mar 1, 2016 at 1:05 AM, Jerome BENOIT wrote:
>
>> I am on my way to package a software whose the upstream source is
>> available at github with only commits: the upstream team uploads
&
On Tue, Mar 1, 2016 at 1:05 AM, Jerome BENOIT wrote:
> I am on my way to package a software whose the upstream source is available
> at github with only commits:
> the upstream team uploads new material the last Friday of each month, but
> without emitting any tags.
> Can we use
Jerome BENOIT writes:
> I am on my way to package a software whose the upstream source is
> available at github with only commits: the upstream team uploads new
> material the last Friday of each month, but without emitting any tags.
I'm not an expert on the corner cases o
Dear Mentaors:
I am on my way to package a software whose the upstream source is available at
github with only commits:
the upstream team uploads new material the last Friday of each month, but
without emitting any tags.
Can we use uscan (version 4) for such a scheme ?
Thanks in advance
Sorry, I gave the wrong link in the previous email. I meant to say
https://github.com/pelliott80/simplescreenrecorder-dpm instead of
https://github.com/pelliott80/simplescreenrecorder-dpm/blob/upstream/debian/control
pgpDyu20yEhxs.pgp
Description: PGP signature
oped"
> to mean that the VCS fields should point to the packaging source,
> not the upstream source.
>
> Experenced package maintainers please comment.
>
> Am I wrong?
No, your interpretation is correct. My concern is that
https://github.com/MaartenBaert/ssr is the upstream
kage is developed.
I interpreted "repository where the Debian source package is developed"
to mean that the VCS fields should point to the packaging source,
not the upstream source.
Experenced package maintainers please comment.
Am I wrong?
> -Is there any reason that you are limited to i38
Patrick,
If you don't want to involve autoconf and friends, you may want to try
mk-configure, which is easier to use. It gives you install, clean and other
typically used targets for free, among more specific things. It's also
easily integrated with dh, you just need to build-depend on it and add
On Wed, Apr 30, 2014 at 09:08:33AM +, Patrick Schleizer wrote:
> >> I don't understand the need to call a shell script from the Makefile.
> >> According to the FHS,
> >> the main directories where you may want to install shell scripts, shell
> >> libraries, config files
> >> and their documen
Andrey Rahmatullin:
> On Mon, Apr 28, 2014 at 08:20:04PM +0200, bilibop project wrote:
>> I don't understand the need to call a shell script from the Makefile.
>> According to the FHS,
>> the main directories where you may want to install shell scripts, shell
>> libraries, config files
>> and the
On Mon, Apr 28, 2014 at 08:20:04PM +0200, bilibop project wrote:
> I don't understand the need to call a shell script from the Makefile.
> According to the FHS,
> the main directories where you may want to install shell scripts, shell
> libraries, config files
> and their documentation are: /etc,
bilibop project:
> Hi
>
> message d'origine
> De: Patrick Schleizer
> A: debian-mentors@lists.debian.org
> Sujet: Re: Install /usr/bin/something from upstream source to
> /usr/bin/somethingon hdd?
> Date: Sun, 27 Apr 2014 15:25:16 +
>
>&g
Hi
message d'origine
De: Patrick Schleizer
A: debian-mentors@lists.debian.org
Sujet: Re: Install /usr/bin/something from upstream source to
/usr/bin/somethingon hdd?
Date: Sun, 27 Apr 2014 15:25:16 +
> Andrey Rahmatullin:
>
> I like to make it generic, so I
Andrey Rahmatullin:
>> For the following make snippet, I need a replacement not using rsync.
>>
>> install:
>> rsync \
>> -C \
>> --verbose \
>> --recursive \
>> --links \
>> --perms \
>> --times \
>> --
On Sun, Apr 27, 2014 at 12:43:07AM +, Patrick Schleizer wrote:
> Sure, the effort required for that is minimal. (I managed to create a
> non-Debian specific Makefile for "make install" that uses rsync.
> Debhelper can pick it up from there just fine.)
> >>> I don't think using rs
Osamu Aoki:
> On Sat, Apr 26, 2014 at 12:42:45PM +, Patrick Schleizer wrote:
>> Andrey Rahmatullin:
>>> On Sat, Apr 26, 2014 at 12:24:18PM +, Patrick Schleizer wrote:
Sure, the effort required for that is minimal. (I managed to create a
non-Debian specific Makefile for "make insta
On Sat, Apr 26, 2014 at 12:42:45PM +, Patrick Schleizer wrote:
> Andrey Rahmatullin:
> > On Sat, Apr 26, 2014 at 12:24:18PM +, Patrick Schleizer wrote:
> >> Sure, the effort required for that is minimal. (I managed to create a
> >> non-Debian specific Makefile for "make install" that uses r
Hi,
On Fri, Apr 25, 2014 at 06:56:33PM +, Patrick Schleizer wrote:
> >> I am upstream as well as would like to become a debian maintainer some
> >> day. Still learning packaging.
So what you need is a simple solution.
> >> Due to the luxury of being upstream a
Andrey Rahmatullin:
> On Sat, Apr 26, 2014 at 12:24:18PM +, Patrick Schleizer wrote:
I see no reason why not. Whether it's easy to install the software
outside of Debian isn't really something that Debian itself should be that
worried about, as long as the packages in Debian do
On Sat, Apr 26, 2014 at 12:24:18PM +, Patrick Schleizer wrote:
> >> I see no reason why not. Whether it's easy to install the software
> >> outside of Debian isn't really something that Debian itself should be that
> >> worried about, as long as the packages in Debian do the right thing.
> >
Paul Wise:
> On Sat, Apr 26, 2014 at 3:04 AM, Russ Allbery wrote:
>
>> I see no reason why not. Whether it's easy to install the software
>> outside of Debian isn't really something that Debian itself should be that
>> worried about, as long as the packages in Debian do the right thing.
>
> I'd
On Sat, Apr 26, 2014 at 3:04 AM, Russ Allbery wrote:
> I see no reason why not. Whether it's easy to install the software
> outside of Debian isn't really something that Debian itself should be that
> worried about, as long as the packages in Debian do the right thing.
I'd say we should encourag
Patrick Schleizer writes:
> Would a package created that way be allowed to enter Debian (if there
> are no other issues)?
I see no reason why not. Whether it's easy to install the software
outside of Debian isn't really something that Debian itself should be that
worried about, as long as the p
Russ Allbery:
> Patrick Schleizer writes:
>
>> I am upstream as well as would like to become a debian maintainer some
>> day. Still learning packaging.
>
>> Due to the luxury of being upstream as well, the upstream source package
>> can be formatted in any
Patrick Schleizer writes:
> I am upstream as well as would like to become a debian maintainer some
> day. Still learning packaging.
> Due to the luxury of being upstream as well, the upstream source package
> can be formatted in any way I wish. [In this case it is a simple package
Andrey Rahmatullin:
> On Fri, Apr 25, 2014 at 12:23:38PM +, Patrick Schleizer wrote:
>> I am upstream as well as would like to become a debian maintainer some
>> day. Still learning packaging.
>>
>> Due to the luxury of being upstream as well, the upstream source pac
On Fri, Apr 25, 2014 at 12:23:38PM +, Patrick Schleizer wrote:
> I am upstream as well as would like to become a debian maintainer some
> day. Still learning packaging.
>
> Due to the luxury of being upstream as well, the upstream source package
> can be formatted in any way I
Hi,
I am upstream as well as would like to become a debian maintainer some
day. Still learning packaging.
Due to the luxury of being upstream as well, the upstream source package
can be formatted in any way I wish. [In this case it is a simple package
with shell scripts only.]
Personally I find
One question Gabriele,
If I add -iop and upload the package to mentors and my package will be
uploaded to Debian, will Debian build servers know they should also add
-iop option when building ?
On 4 January 2014 01:08, Gabriele Giacone <1o5g4...@gmail.com> wrote:
> On Fri, Jan 3, 2014 at 6:09 P
@Gabriele thank you. When I add -i to debuild will Debian build servers do
the same ?
@Paul good idea but I'll contact upstream, however they are not so
responsive.
On 4 January 2014 06:52, Paul Wise wrote:
> On Sat, Jan 4, 2014 at 12:18 AM, Dariusz Dwornikowski wrote:
>
> > So I have got a pr
On Sat, Jan 4, 2014 at 12:18 AM, Dariusz Dwornikowski wrote:
> So I have got a problem, upstream has localization files in po/ directory.
> When make is called, it traverses to po/ and also calls make, then .po files
> change (they are updated with the current date) like in the example below.
> Un
On Sat, Jan 4, 2014 at 1:08 AM, Gabriele Giacone <1o5g4...@gmail.com> wrote:
> On Fri, Jan 3, 2014 at 6:09 PM, Игорь Пашев wrote:
>> 2014/1/3 Gabriele Giacone <1o5g4...@gmail.com>:
>>> Teach clean target how to remove them.
>>
>> No-no-no :-)
>>
>> *.po files are handwritten [1]
>
> $ debuild -ipo
On Fri, Jan 3, 2014 at 6:09 PM, Игорь Пашев wrote:
> 2014/1/3 Gabriele Giacone <1o5g4...@gmail.com>:
>> Teach clean target how to remove them.
>
> No-no-no :-)
>
> *.po files are handwritten [1]
$ debuild -ipo
--
G..e
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a
2014/1/3 Gabriele Giacone <1o5g4...@gmail.com>:
> Teach clean target how to remove them.
No-no-no :-)
*.po files are handwritten [1]
[1] http://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "un
On Fri, Jan 3, 2014 at 5:18 PM, Dariusz Dwornikowski
wrote:
> hi again,
>
> So I have got a problem, upstream has localization files in po/ directory.
> When make is called, it traverses to po/ and also calls make, then .po files
> change (they are updated with the current date) like in the exampl
2014/1/3 Dariusz Dwornikowski :
> hi again,
>
> So I have got a problem, upstream has localization files in po/ directory.
> When make is called, it traverses to po/ and also calls make, then .po files
> change (they are updated with the current date) like in the example below.
> Unfortunately, deb
hi again,
So I have got a problem, upstream has localization files in po/ directory.
When make is called, it traverses to po/ and also calls make, then .po
files change (they are updated with the current date) like in the example
below. Unfortunately, debuild when using quilt 3.0 format crashes wi
For your review, Vincent:
http://mentors.debian.net/package/capnproto
http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.3.0-1.dsc
Thanks again.
On Wed, Nov 13, 2013 at 12:29 AM, Vincent Bernat wrote:
> ❦ 13 novembre 2013 09:21 CET, Tom Lee :
>
> > Can I assume you're inter
❦ 13 novembre 2013 09:21 CET, Tom Lee :
> Can I assume you're interested in sponsoring capnproto_0.3.0-1 Vincent, or
> should I open an RFS?
Yes, mail me directly so I don't forget.
--
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
De
Cool -- I'll roll kj back into the libcapnp package & push this out to
mentors.debian.net.
Can I assume you're interested in sponsoring capnproto_0.3.0-1 Vincent, or
should I open an RFS?
Thanks for the feedback.
Cheers,
Tom
On Wed, Nov 13, 2013 at 12:12 AM, Vincent Bernat wrote:
> ❦ 13 nov
❦ 13 novembre 2013 09:04 CET, Tom Lee :
> Yes it is -- all the libraries built by the source package have the same
> version numbers.
>
> It wasn't too much trouble to split out libkj, so I did that. I can either
> leave it that way or fold it back into the libcapnp binary package. Any
> strong
Yes it is -- all the libraries built by the source package have the same
version numbers.
It wasn't too much trouble to split out libkj, so I did that. I can either
leave it that way or fold it back into the libcapnp binary package. Any
strong feelings either way with this?
I should note that the
❦ 13 novembre 2013 05:30 CET, Tom Lee :
> I work on the packaging for capnproto.
>
> Upstream has provided a new source tarball that introduces a new shared
> library (libkj). Theoretically, this shared library is stand-alone & could
> be used independently, but it is likely only interesting to
Hi folks,
I work on the packaging for capnproto.
Upstream has provided a new source tarball that introduces a new shared
library (libkj). Theoretically, this shared library is stand-alone & could
be used independently, but it is likely only interesting to users of
capnproto in the short term.
In
On 12/14/12, Paul Wise wrote:
> On Fri, Dec 14, 2012 at 4:31 PM, Alexander Busorguin wrote:
>
>> dualword is a foreign language vocabulary trainer. There is original
>> index with words in
>> /usr/share/dualword/index and user can create a copy in
>> .dualword/index where user
>> statistics is sto
On Fri, Dec 14, 2012 at 4:31 PM, Alexander Busorguin wrote:
> dualword is a foreign language vocabulary trainer. There is original
> index with words in
> /usr/share/dualword/index and user can create a copy in
> .dualword/index where user
> statistics is stored.
Sounds reasonable (and an interes
In-reply-to:
References:
>> I'm working on this ITP:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695255
>> Is it ok to distribute xapian index with Upstream Source file?
>Please include some more information about your situation.
>Why is the xapian index
On Fri, Dec 14, 2012 at 2:44 AM, Alexander Busorguin wrote:
> I'm working on this ITP:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695255
>
> Is it ok to distribute xapian index with Upstream Source file?
Please include some more information about your situation.
Why is
Mathieu Malaterre writes:
> On Mon, Mar 12, 2012 at 11:54 AM, Goswin von Brederlow
> wrote:
>> Mathieu Malaterre writes:
>>
>>> Paul,
>>>
>>> On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
>>> wrote:
I can unpack this thingy with:
rpm2cpio source.rpm | cpio -i
But I have que
On Mon, Mar 12, 2012 at 11:54 AM, Goswin von Brederlow
wrote:
> Mathieu Malaterre writes:
>
>> Paul,
>>
>> On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
>> wrote:
>>> I can unpack this thingy with:
>>> rpm2cpio source.rpm | cpio -i
>>>
>>> But I have questions:
>>>
>>> Assuming I have the url of
Mathieu Malaterre writes:
> Paul,
>
> On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
> 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:
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.
Paul,
On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
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?
On Mon, Mar 12, 2012 at 11:20 AM, Paul Elliott
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 be
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!
I can unpack this thingy with:
rpm2cpio source.rpm | cpio -i
But I have
* Daniele Tricoli , 2012-01-31, 01:50:
Sorry, this won't work. Epoch is not included in .orig.tar name, and
dak wouldn't accept a different file with the same name.
Many thanks for the explaination.
Yes, ask upstream to do a proper release with new version number.
I wrote upstream and I ask
Hello Jakub,
On Tuesday 31 January 2012 01:22:52 Jakub Wilk wrote:
> Sorry, this won't work. Epoch is not included in .orig.tar name, and
> dak wouldn't accept a different file with the same name.
Many thanks for the explaination.
> Yes, ask upstream to do a proper release with new version numb
* Daniele Tricoli , 2012-01-31, 01:13:
I'm working on tipa (see #534384)
Thanks!
and I want to regenerate the orig source because upstream updated
PostScript Type 1 Fonts and added a reference manual.
The problem is that upstream did't make a new release but updated 1.3
instead.
The last
Dear mentors,
I'm working on tipa (see #534384) and I want to regenerate the orig source
because upstream updated PostScript Type 1 Fonts and added a reference
manual.
The problem is that upstream did't make a new release but updated 1.3
instead.
The last packaged version of tipa in Debian is
Paul Elliott writes:
> On Friday, March 25, 2011 01:43:59 am Ben Finney wrote:
> > What I thought you were referring to was that the images were a
> > binary form and the “preferred form for making modifications” wasn't
> > included, hence making the source package non-free. Is that the case
> >
On Friday, March 25, 2011 01:43:59 am Ben Finney wrote:
> Paul Elliott writes:
> > Never mind, I found out that patent expired
>
> I didn't think you were referring to the Unisys patent on GIF. Yes, that
> patent has expired long ago (but GIF is still obsoleted by PNG, and I
> usually encoura
Holger Levsen writes:
> On Freitag, 25. März 2011, Ben Finney wrote:
> > What I thought you were referring to was that the images were a
> > binary form and the “preferred form for making modifications” wasn't
> > included, hence making the source package non-free. Is that the case
> > for this p
Unless the PDF itself is "source code" then yeah Debian requires the
.tex/.doc/etc file that the PDF is built from:
Source missing: Your packages contains files that need source but do
not have it. These include PDF and PS files in the documentation.
http://ftp-master.debian.org/REJECT-FAQ.html
I assume this is a problem for the debian distribution? I will try to get
upstream to release the source. I know that fedora and perhaps opensuse can
live with unsourced pdfs
http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre-
built_binaries_or_libraries
> Content binaries (s
On Freitag, 25. März 2011, Ben Finney wrote:
> What I thought you were referring to was that the images were a binary
> form and the “preferred form for making modifications” wasn't included,
> hence making the source package non-free. Is that the case for this
> package?
I'd say (certain) .gif im
Paul Elliott writes:
> Never mind, I found out that patent expired
I didn't think you were referring to the Unisys patent on GIF. Yes, that
patent has expired long ago (but GIF is still obsoleted by PNG, and I
usually encourage upstream to replace them).
What I thought you were referring to
On Fri, Mar 25, 2011 at 1:38 PM, Paul Elliott
wrote:
> Never mind, I found out that patent expired
Ah, the patent expired so long ago that I completely forgot it existed
and didn't put two and two together, sorry!
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to
On Thursday, March 24, 2011 10:00:32 pm Paul Wise wrote:
> On Fri, Mar 25, 2011 at 10:50 AM, Paul Elliott
>
> wrote:
> > My upstream source contains .gif files that are not essential. If I
> > delete these file and never use them, can I use this tarball as my
> >
On Fri, Mar 25, 2011 at 10:50 AM, Paul Elliott
wrote:
> My upstream source contains .gif files that are not essential. If I delete
> these file and never use them, can I use this tarball as my pristine source,
> or must I resource?
Unless they are non-free or you are already repa
My upstream source contains .gif files that are not essential. If I delete
these file and never use them, can I use this tarball as my pristine source,
or must I resource?
Thank You.
P.S. there are a lot of complicated rules to create a package.
--
Paul Elliott 1
Hi Jérémy
On Fri, Feb 25, 2011 at 12:13:31PM +0100, Jérémy Lal wrote:
> On 25/02/2011 10:44, Harald Jenny wrote:
> > Hi Paul
> >
> > On Wed, Feb 23, 2011 at 07:48:13AM +0800, Paul Wise wrote:
> >> If you weren't using git I would say use dpkg-source v3 which removes
> >> any upstream debian/ dir
ULT]
> pristine-tar = True
>
> [git-import-orig]
> filter = debian/*
> filter = lib/*
> filter-pristine-tar = True
This sounds very interesting - and as the package already uses v3 there should
also be no problem for people who want to rebuild it from upstream source...
withou
On 25/02/2011 10:44, Harald Jenny wrote:
> Hi Paul
>
> On Wed, Feb 23, 2011 at 07:48:13AM +0800, Paul Wise wrote:
>> If you weren't using git I would say use dpkg-source v3 which removes
>> any upstream debian/ dir during the unpack process.
>
> Well using v3 format does indeed solve the problem
Hi
On Fri, Feb 25, 2011 at 06:44:49PM +0800, Paul Wise wrote:
> On Fri, Feb 25, 2011 at 5:44 PM, Harald Jenny
> wrote:
>
> > You don't have some Howto lying around making going into the detail in here?
>
> I've never done it myself, searching the web for git pull pristine-tar
> found some thing
On Fri, Feb 25, 2011 at 5:44 PM, Harald Jenny
wrote:
> You don't have some Howto lying around making going into the detail in here?
I've never done it myself, searching the web for git pull pristine-tar
found some things though.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIB
Hi Paul
On Wed, Feb 23, 2011 at 07:48:13AM +0800, Paul Wise wrote:
> If you weren't using git I would say use dpkg-source v3 which removes
> any upstream debian/ dir during the unpack process.
Well using v3 format does indeed solve the problem for the user which is not a
bad thing either :-).
>
If you weren't using git I would say use dpkg-source v3 which removes
any upstream debian/ dir during the unpack process.
With git I'm not sure but I'd be inclined to just resolve conflicts,
continue the merge and maybe send upstream some patches. Now that
upstream is also using git you can probab
Dear list members,
I'm currently uploader for openswan were upstream ships it's own version of a
debian directory as they provide debs themselves (no chance to change this). As
the upstream source did contain non-free docs we had to repackage it anyway so
removing the debian directory t
Paul Wise writes:
> On Sun, Jul 18, 2010 at 3:50 AM, Russ Allbery wrote:
>> Source packages in main can build binary packages in contrib. The
>> licensing requirements for the two areas are the same, so no problem is
>> created by that.
> Stuff related to nvidia-cg cannot be built using only t
Hello,
On Saturday 17 July 2010 09:54:16 Paul Wise wrote:
> 2010/7/17 Sébastien Barthélemy :
> > Besides collada-dom, the upstream svn and tarballs include several
> > related programs, which I do not plan to build. They are either
> > - dependancies (such as pcre) which are already packaged separ
On Sun, Jul 18, 2010 at 3:50 AM, Russ Allbery wrote:
> Source packages in main can build binary packages in contrib. The
> licensing requirements for the two areas are the same, so no problem is
> created by that.
Stuff related to nvidia-cg cannot be built using only tools in main so
in this ca
Paul Wise writes:
> 2010/7/17 Sébastien Barthélemy :
>> I think some of these additional programs should go in contrib, because
>> they use nvidia-cg, whereas collada-dom is fit to main.
> You won't be able to build those from the same source package.
Source packages in main can build binary pa
1 - 100 of 206 matches
Mail list logo
