Am 30.08.2021 um 13:22 teilte debian-ment...@jugra.de mit:
Hi,
maybe you can try to copy with
cat <<'EOF' >>debian/$PACKAGENAME.install
program usr/bin
EOF
...and replace the
override_dh_auto_clean:
rm -f program
By a file debian/clean containing the names of the be deleted files.
H.
-
Hello,
maybe you can try to copy with
cat <<'EOF' >>debian/$PACKAGENAME.install
program usr/bin
EOF
and then you don't need override_dh_auto_install.
Best Regards,
Juri Grabowski
Ryan McClue writes:
> override_dh_auto_install:
> cp program /usr/local/bin
Unrelated to your actual question, but this won't work well. You need
to install into debian/PACKAGENAME as if it was the filesystem root,
that is: cp program debian/PACKAGENAME/usr/bin (after ensuring the
directory
On Mon, Aug 30, 2021 at 10:20:48AM +, Ryan McClue wrote:
> Upon running dpkg-buildpackage, I get: dh: error: Unknown sequence
> application (choose from: binary binary-arch binary-indep build
> build-arch build-indep clean install install-arch install-indep)
How are you running it?
--
WBR, wR
I want to create a Debian package from a C program without the use of a build
tool such as autotools or CMake. My debian/rules file:
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_clean:
rm -f program
override_dh_auto_build:
gcc program.c -o program
override_dh_auto_install:
cp
Thanks, Miroslav and Santiago for your feedback!
On Wed, Nov 14, 2018 at 7:43 AM Miroslav Kravec
wrote:
> Certainly not acceptable. Package build should not touch anything outside of
> package. Ie. no side effects.
> Anyway, what would be the goal? If specific binary is needed, then setup env
>
Dňa ut, 13. nov 2018 22:57 Santiago Vila napísal(a):
> On Mon, Nov 12, 2018 at 01:26:11PM +0100, JOSE LUIS BLANCO CLARACO wrote:
>
> > And my question is: is it "acceptable" to run `update-alternatives`
> > during debian/rules? [...]
>
> I don't think so.
On Mon, Nov 12, 2018 at 01:26:11PM +0100, JOSE LUIS BLANCO CLARACO wrote:
> And my question is: is it "acceptable" to run `update-alternatives`
> during debian/rules? [...]
I don't think so. Would that work at all if you are using fakeroot?
* building the packages from
sources, fixing the problem.
And my question is: is it "acceptable" to run `update-alternatives`
during debian/rules? Is there any better way to handle with this
(apart of proposing a change all the way down to the
FindWxWidgets.cmake module by CMake?
Any advi
Hello Ross,
>#858563 reports that debian/rules cannot be invoked directly on efl.
>The suggested fix is to add "include /usr/share/dpkg/default.mk".
another fix might be to do something like
DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
DEB_HOST_ARCH_OS
Hello,
#858563 reports that debian/rules cannot be invoked directly on efl.
The suggested fix is to add "include /usr/share/dpkg/default.mk".
That doesn't work, I'm struggling to understand why:
$ gbp buildpackage --git-builder=sbuild --git-arch=amd64
--git-dist=experimen
On Wed, 01 Jan 2014 21:00:18 -0800, Russ Allbery wrote:
> There have been several replies to this, but none of them quite tell you
> exactly what to do, so let me take a stab at that.
>
> First, dh_installdirs is not actually useful for solving this particular
> problem . . .
Thank you, thank y
Russ Allbery writes:
> I guess I should say, for the sake of completeness, that you *can* make
> dh_installdirs do this with the -P flag. But I would find that
> confusing; I think an explicit install -d is easier to understand. And,
> regardless, dh_installdirs isn't normally run before dh_aut
Russ Allbery writes:
> First, dh_installdirs is not actually useful for solving this particular
> problem since dh_installdirs creates directories in the package staging
> area. Your problem is happening prior to that; make install of the
> upstream source into debian/tmp is failing because it's
T o n g writes:
> Is it possible to have a generic debian/rules that creates directories?
> The upstream Makefiles was not designed to install into $DESTDIR but
> to /, so it assumes /usr/bin exists, while that creates problems for me:
> install -s -m 755 autogb /exp
On Thu, Jan 2, 2014 at 12:08 PM, T o n g wrote:
> Ok, so I read the manpage of dh_installdirs(1), which I included below.
> But still how can I use it to create patch that I can send upstream to
> support creating $DESTDIR/usr/bin and so on, as suggested by Paul?
The two topics are completely sep
On Thu, 02 Jan 2014 00:23:42 +0100, Gergely Nagy wrote:
>> Is it possible to alter the following `debian/rules` file so that it
>> plays nicely with such upstream Makefiles?
>
> Yes. You want to use dh_installdirs(1). I suggest you read its manpage.
> Mind you, you won&#
On Thu, Jan 2, 2014 at 6:11 AM, T o n g wrote:
> The upstream Makefiles was not designed to install into $DESTDIR but
> to /, so it assumes /usr/bin exists, while that creates problems for me:
In addition to the solution suggested by Gergely Nagy, please send
upstream a patch to support creating
T o n g writes:
> Hi,
>
> Is it possible to have a generic debian/rules that creates directories?
>
> The upstream Makefiles was not designed to install into $DESTDIR but
> to /, so it assumes /usr/bin exists, while that creates problems for me:
>
> install -s -m 755
Hi,
Is it possible to have a generic debian/rules that creates directories?
The upstream Makefiles was not designed to install into $DESTDIR but
to /, so it assumes /usr/bin exists, while that creates problems for me:
install -s -m 755 autogb /export/build/zh-autoconvert/bld/zh-
autoconvert
2013/9/12 Mathieu Malaterre :
> Hi,
>
> Does anyone sees anything wrong with:
>
> ...
> $ cat debian/rules:
> VERSION = $(shell dpkg-parsechangelog | grep '^Version' | cut -d' '
> -f2 | cut -f1 -d-)
> debian/tbb.pc: debian/tbb.pc.in
> sed -e&q
Hi,
Does anyone sees anything wrong with:
...
$ cat debian/rules:
VERSION = $(shell dpkg-parsechangelog | grep '^Version' | cut -d' '
-f2 | cut -f1 -d-)
debian/tbb.pc: debian/tbb.pc.in
sed -e"s/@VERSION@/$(VERSION)/g" $< > $@
build: debian/tbb.pc
...
It us
* Paul Elliott [130815 11:52]:
>
> What is the official way to add additional -D definitions
> to the gcc command line from the debian/rules file?
>
> Is it DEB_CFLAGS_MAINT_APPEND ?
DEB_CPPFLAGS_MAINT_APPEND, as -D is for the C PreProcessor
and not the Compiler itself. Make su
What is the official way to add additional -D definitions
to the gcc command line from the debian/rules file?
Is it DEB_CFLAGS_MAINT_APPEND ?
Thank You.
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
be removed automatically as
well. At least by 'debian/rules clean' from that package, which appears to
simply run 'dh clean' as far as I can tell.
And better, if you're using dh, it maintains its own internal stamp files so
that you don't have to.
Which makes it
and how "necessary" are they?
> >>
> >>They are entirely optional, in fact. It's a custom behavior to work around
> >>issues with pseudo-phony targets which aren't declared as such for some
> >>reason [1]. That's just one way (among many)
t one way (among many) to implement a debian/rules
file.
I can also suggest to use *-stamp: such files will be removed by dh_clean
automatically :-)
From what I can see, the stamp-* files seem to be removed automatically as well.
At least by 'debian/rules clean' from that package, which
e been) used in a number of other packages as well. What are
>> they used
>> for, and how "necessary" are they?
>
> They are entirely optional, in fact. It's a custom behavior to work
> around issues with pseudo-phony targets which aren't declared as such
>
used
> for, and how "necessary" are they?
They are entirely optional, in fact. It's a custom behavior to work
around issues with pseudo-phony targets which aren't declared as such
for some reason [1]. That's just one way (among many) to implement a
debian/rules fil
I'm attempting to rework the removed e16 package to sumbit it for reinclusion.
The debian/rules file for the old version of this package contains the targets
'debian/stamp-build' and 'debian/stamp-install', and includes
debian/builddir.mk, which contains the target
On 02/27/2012 05:09 PM, Gergely Nagy wrote:
> Jerome BENOIT writes:
>
>
>> Hello List:
>>
>> What should be the default target for debian/rules ?
>>
> I usually make a help target (or something similar) and make that the
> default. But now that you
Jerome BENOIT writes:
> Hello List:
>
> What should be the default target for debian/rules ?
I usually make a help target (or something similar) and make that the
default. But now that you reminded me, I always wanted to make it
display debian/README.source, so I'll just do that f
Jerome BENOIT writes:
> What should be the default target for debian/rules ?
Whatever you want, basically. None of the standard tools ever invoke it
with the default target, so it's up to the discretion of the maintainer.
--
Russ Allbery (r...@debian.org) <http://ww
Hello List:
What should be the default target for debian/rules ?
Thanks in advance,
Jerome
--
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/4
Dear Andreas,
Andreas Tille schrieb am 17.12.2011 14:26:
> is there any better method to know whether source format 3.0 (quilt) is
> used than manually parse whether debian/source/format exists and
> contains this string? I'd like to do an include statement depending
> from format 3.0 (quilt) is u
Hi,
is there any better method to know whether source format 3.0 (quilt) is
used than manually parse whether debian/source/format exists and
contains this string? I'd like to do an include statement depending
from format 3.0 (quilt) is used or not.
Kind regards
Andreas.
--
http://fam-
Dear Ansgar,
On Mon, Nov 21, 2011 at 09:31:07AM +0100, Ansgar Burchardt wrote:
> Hi,
> Cédric Boutillier writes:
> > For this package, I would need to run an instance of postgres server to
> > be able to run the test suite of the package. Contrary to mysqld,
> > postgres refuses to be run as roo
Hi,
Cédric Boutillier writes:
> For this package, I would need to run an instance of postgres server to
> be able to run the test suite of the package. Contrary to mysqld,
> postgres refuses to be run as root. I tried to use su/sudo but I get
> some error when I try to build the package (with git
Dear all,
After having asked here how to run mysqld to run a test suite in
debian/rules for the ruby-dataobjects-mysql ruby package [1]
and having received useful advice from Thomas Goirand [2], which helped
me a lot, I would like to ask a similar question for
ruby-dataobjects-postgres, ruby
ying to split indep operations from the rest on the
> >> > activiz.net package, see:
> >> >
> >> > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup
> >> >
> >> > However the -inde
as suggested. And -2 seems to
> compile just fine -well almost I need to B-D on doxygen-latex-
There's an alternative solution, that lets you keep B-D-I separate, and
doesn't break buildds. But it's ugly, and 'breaks' debian/rules build:
If you disable the build t
ackage, see:
>> >
>> > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup
>> >
>> > However the -indep rules are still being called on the buildd machine:
>> >
>> > Eg:
>> >
>> > http
/packages/activiz.net/trunk/debian/rules?view=markup
> >
> > However the -indep rules are still being called on the buildd machine:
> >
> > Eg:
> >
> > http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.net&arch=s390x&ver=5.6.1-2&stamp=1
On 2011-11-10 08:20, Mathieu Malaterre wrote:
> Hi all,
>
Hi
> I have been trying to split indep operations from the rest on the
> activiz.net package, see:
>
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup
>
&
Hi all,
I have been trying to split indep operations from the rest on the
activiz.net package, see:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup
However the -indep rules are still being called on the buildd machine:
Eg:
http
Bonjour Charles,
Charles Plessy wrote:
> Le Sun, Oct 30, 2011 at 11:04:38PM +0100, Cédric Boutillier a écrit :
> >
> > For the test suite to run for this package, an instance of the mysqld
> > server needs to be started. Installing mysql-server-5.1 as a
> > build-dependency does not start the dae
Thomas Goirand wrote:
>On 10/31/2011 08:54 AM, Paul Wise wrote:
>> On Mon, Oct 31, 2011 at 6:04 AM, Cédric Boutillier wrote:
>>
>>> I was wondering what would be the best way to start (and possibly
>>> stop) the mysql server from the debian/rules makefile.
Hi Ben,
> Cédric Boutillier writes:
> > A best practice instaured in the Ruby Extras Team is to run the test
> > suite at build time to ensure that it will work with the versions of
> > the Ruby interpreter supported by Debian.
> Where is that documented? I couldn't find it at
> http://wiki.deb
On Mon, Oct 31, 2011 at 5:39 PM, Jakub Wilk wrote:
> No, it will not. See bug #568897.
I stand corrected. Ugh.
--
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.
* Paul Wise , 2011-10-31, 13:15:
Also, remember to use the BUILD_OPTIONS to have the test suite be
disabled in case we don't want to run them. That's a Debian policy
requirement. So you'll also need something like that in your
debian/rules:
ifeq (,$(findstring nocheck, $(DE
On Mon, Oct 31, 2011 at 12:54 PM, Thomas Goirand wrote:
> Also, remember to use the BUILD_OPTIONS to have the test suite
> be disabled in case we don't want to run them. That's a Debian
> policy requirement. So you'll also need something like that in
> your debian/rul
On 10/31/2011 08:54 AM, Paul Wise wrote:
> On Mon, Oct 31, 2011 at 6:04 AM, Cédric Boutillier wrote:
>
>> I was wondering what would be the best way to start (and possibly stop)
>> the mysql server from the debian/rules makefile. Could anyone help me on
>> this?
>>
On Mon, Oct 31, 2011 at 6:04 AM, Cédric Boutillier wrote:
> I was wondering what would be the best way to start (and possibly stop)
> the mysql server from the debian/rules makefile. Could anyone help me on
> this?
Run mysqld from debian/rules?
--
bye,
pabs
http://wiki.debian.org
Le Sun, Oct 30, 2011 at 11:04:38PM +0100, Cédric Boutillier a écrit :
>
> For the test suite to run for this package, an instance of the mysqld
> server needs to be started. Installing mysql-server-5.1 as a
> build-dependency does not start the daemon in a pbuilder chroot, because
> of policy-rc.d
nit tests at build time.
> I was wondering what would be the best way to start (and possibly
> stop) the mysql server from the debian/rules makefile.
IMO, you should not do that.
Instead, disable the tests which require that, since they are not unit
tests and hence are irrelevant to the go
start (and possibly stop)
the mysql server from the debian/rules makefile. Could anyone help me on
this?
Thank you in advance.
Best regards,
Cédric
signature.asc
Description: Digital signature
Adam Borowski writes:
> On Fri, Apr 29, 2011 at 10:48:04AM +0200, Bernhard R. Link wrote:
>> * Daniel Stender [110429 10:37]:
>> > is it best practice to set LC_MESSAGE=C in debian/rules to prevent
>> > things like test suite breaking when building within non-English
On Fri, Apr 29, 2011 at 10:48:04AM +0200, Bernhard R. Link wrote:
> * Daniel Stender [110429 10:37]:
> > is it best practice to set LC_MESSAGE=C in debian/rules to prevent
> > things like test suite breaking when building within non-English
> > locales?
>
> If you
* Daniel Stender [110429 10:37]:
> is it best practice to set LC_MESSAGE=C in debian/rules to prevent things
> like test suite breaking
> when building within non-English locales?
If you want to set something, set LC_ALL.
Otherwise a user-set LC_ALL will override it.
(and it also sets
Hello guys,
is it best practice to set LC_MESSAGE=C in debian/rules to prevent things like
test suite breaking
when building within non-English locales?
Greetings,
Daniel Stender
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe"
On Mon, 04 Apr 2011, Mathieu Malaterre wrote:
> Dear all,
>
> I am trying to understand why dpkg-buildpackage -A is not simply
> calling make -f ./debian/rules build-indep. I tried turning
> DH_VERBOSE=1 but I do not see which rules imply runing the build-arch
> while I spec
On 04.04.2011, at 11:40, Mathieu Malaterre
wrote:
> Dear all,
>
> I am trying to understand why dpkg-buildpackage -A is not simply
> calling make -f ./debian/rules build-indep. I tried turning
> DH_VERBOSE=1 but I do not see which rules imply runing the build-arch
> wh
Dear all,
I am trying to understand why dpkg-buildpackage -A is not simply
calling make -f ./debian/rules build-indep. I tried turning
DH_VERBOSE=1 but I do not see which rules imply runing the build-arch
while I specifically tell dpkg-buildpackage to only run build-indep.
Thanks
--
Mathieu
Hi Joachim,
dpk-vendor checks the contents of /etc/dpkg/origins/default.
Both are missing on lenny.
Trying to call (the missing) dpk-vendor on lenny results in an error.
That's the reason I'm checking for file existence.
Rgds
Richard
signature.asc
Description: This is a digitally signed messa
Richard Ulrich wrote on 2011-03-02 22:13:
> ifeq ( $(shell [ -e /etc/dpkg/origins/default ]; printf $$?), 0)
> ifeq ( $(shell dpkg-vendor --derives-from Ubuntu && echo yes), yes)
> @echo "ubuntu maverick"
> else
> @echo "debian squeeze"
> endif
> else
>
* Richard Ulrich , 2011-03-03, 00:29:
ifeq ($(shell[-e /etc/dpkg/origins/default];printf $$?),0)
How could this possibly work?
$ [-e /etc/dpkg/origins/default];printf $?
bash: [-e: command not found
127
I didn't tell you to remove space from every place you can think
of, but only two particu
Hi Jakub,
I played around with the spaces a lot. The result was always the same.
ifeq ($(shell[-e /etc/dpkg/origins/default];printf $$?),0)
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
Rgds
Richard
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
w
* Richard Ulrich , 2011-03-02, 22:13:
ifeq ( $(shell [ -e /etc/dpkg/origins/default ]; printf $$?), 0)
ifeq ( $(shell dpkg-vendor --derives-from Ubuntu && echo yes), yes)
Remove spaces between "(" and "$".
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
w
I have so far:
http://flightpred.svn.sourceforge.net/viewvc/flightpred/trunk/debian/rules?revision=297
But it basically boils down to the following behavior, which I don't
understand:
$ cat makefile
all:
@echo $(shell [ -e /etc/dpkg/origins/default ]; printf $$?)
@echo $(shell [ -e /et
In , Hai Zaar
wrote:
>On Tue, Sep 8, 2009 at 3:49 PM, Mathieu
>Malaterre wrote:
>> nawk -f ../../.././libsrc/support/strval.awk \
>>role=declare outname=strvalc
>> <../../.././libsrc/standard/strval.tpl >strvalc.h nawk: cannot open
>> "/dev/tty" for output (No such device or addres
On Tue, Sep 8, 2009 at 3:49 PM, Mathieu
Malaterre wrote:
> On Tue, Sep 8, 2009 at 1:10 PM, Jakub Wilk wrote:
>> * Mathieu Malaterre , 2009-09-08, 11:38:
>>>
>>> Hi there,
>>>
>>> There is a problem with the following rules file (in dicom3tools), I
>>> wrote:
>>>
>>> for file in ancp andiff
On Tue, Sep 8, 2009 at 1:10 PM, Jakub Wilk wrote:
> * Mathieu Malaterre , 2009-09-08, 11:38:
>>
>> Hi there,
>>
>> There is a problem with the following rules file (in dicom3tools), I
>> wrote:
>>
>> for file in ancp andiff antodc.all binpatch bmpdump dcanon dcburn
>> dccmp dccomb dcdecmpr
On Tue, Sep 8, 2009 at 12:38 PM, Mathieu
Malaterre wrote:
> Hi there,
>
> There is a problem with the following rules file (in dicom3tools), I wrote:
>
> for file in ancp andiff antodc.all binpatch bmpdump dcanon dcburn
> dccmp dccomb dcdecmpr dcdiff dclutburn \
>
* Mathieu Malaterre , 2009-09-08, 11:38:
Hi there,
There is a problem with the following rules file (in dicom3tools), I wrote:
for file in ancp andiff antodc.all binpatch bmpdump dcanon dcburn
dccmp dccomb dcdecmpr dcdiff dclutburn \
Hi there,
There is a problem with the following rules file (in dicom3tools), I wrote:
for file in ancp andiff antodc.all binpatch bmpdump dcanon dcburn
dccmp dccomb dcdecmpr dcdiff dclutburn \
dclutmix dcmvhier.8only
dcmvhier.all
Hi, Jaromír.
On Mar 12 2009, Jaromír Mikeš wrote:
> Od: Rogério Brito
> > > # Add here commands to clean up after the build process.
> > > -$(MAKE) -C source/ PREFIX=/usr clean
> >
> > Hummm, here you should also make sure that you don't ignore errors from
> > make (see the hyphen that was pu
> Od: Rogério Brito
> > # Add here commands to clean up after the build process.
> > -$(MAKE) -C source/ PREFIX=/usr clean
>
> Hummm, here you should also make sure that you don't ignore errors from
> make (see the hyphen that was put there). Are current versions of
> dh_make producing su
> Od: Charles Plessy
> it looks fine, but the ultimate answer comes of course from building the
> binary
> package and inspecting its contents with dpkg -c. In addition, you can run the
> checker `lintian' on the .changes file; it will give you a lot of useful
> stylistic comments.
Hello,
Than
On Thu, Mar 12, 2009 at 05:10:38AM -0300, Rogério Brito wrote:
> On Mar 11 2009, Jaromír Mike?? wrote:
> > # Add here commands to clean up after the build process.
> > -$(MAKE) -C source/ PREFIX=/usr clean
>
> Hummm, here you should also make sure that you don't ignore errors from
> make (
other question about debian/rules
>
> original variable PREFIX in makefile is PREFIX = /usr/local
>
> I shouldn't edit makefile itself so I should to do it in debian/rules file.
> The result should looks like this?
Usually, some makefiles derived from configure scripts acc
Le Wed, Mar 11, 2009 at 09:50:01PM +0100, Jaromír Mikeš a écrit :
> build-stamp: configure-stamp
> $(MAKE) -C source/ PREFIX=/usr
>
> clean:
> -$(MAKE) -C source/ PREFIX=/usr clean
>
> install: build
> $(MAKE) -C source/ PREFIX=/usr DESTDIR=$(CURDIR)/debian/jkmeter install
Dea
advice and link it can really save frustration.
I have one other question about debian/rules
original variable PREFIX in makefile is PREFIX = /usr/local
I shouldn't edit makefile itself so I should to do it in debian/rules file.
The result should looks like this?
build-stamp: configur
On Wed, Mar 11, 2009 at 12:30 PM, Jaromír Mikeš wrote:
> Hello,
>
> I just going through "New Maintainers' Guide" and editing debian/rules file.
>
> In NMG is sentence:
> "If your package is an `Architecture: all' one, you need to include all the
&g
Hello,
I just going through "New Maintainers' Guide" and editing debian/rules file.
In NMG is sentence:
"If your package is an `Architecture: all' one, you need to include all the
commands for building the package under the `binary-indep' rule, and leave the
`b
I have corrected the package and added all copyright holders I could
find into debian/copyright. I am not quite sure if copyright notices in
files like po/Makefile.in.in need to be mentioned, so left them out for
now. The same is true for the hundrets of FSF copyrights - I know that
at least the bu
[CC'ing -mentors]
Hi Fabian,
2008/5/3 Fabian Greffrath <[EMAIL PROTECTED]>:
>
> Hi Raphael,
>
> thanks for the pointer. Would you mind sponsoring the upload?
I'm afraid I can't sponsor your package, I am not a DD. But hopefully
a potential sponsor in -mentors will read this message, review the
Justin Pryzby <[EMAIL PROTECTED]> writes:
> The debhelper tools (dh_install) used to use debian/tmp but now
> (depending on DH_COMPAT) use debian/$package. So this is a small-ish
> lintian bug.
I've changed the lintian message to use debian/ instead.
--
Russ Allbery ([EMAIL PROTECTED])
Justin Pryzby wrote:
> Hi,
>
> The debhelper tools (dh_install) used to use debian/tmp but now
> (depending on DH_COMPAT) use debian/$package. So this is a small-ish
> lintian bug.
But debian/tmp also happens to be where dh_make defaults to install (make
DESTDIR=$(CURDIR)/debian/tmp), and then
le named
> N: .packlist in them. Those files are useless, and (in some cases) have
> N: the additional problem of creating an architecture-specific directory
> N: name in an architecture-independent package.
> N:
> N: They can be suppressed by adding the following to debian/rul
On Sep 9, 2007, at 8:22 PM, Damyan Ivanov wrote:
I then placed the changed code (the line above with my comment) in
the
install section of the debian/rules file and the lintian error went
away! I hope this helps some one else.
If you think I was wrong to do it this way please inform me of
> N: They can be suppressed by adding the following to debian/rules:
> N:
> N: find debian/tmp -type f -name .packlist | xargs rm -f
> N:
> N: -find debian/tmp/usr/lib/perl5 -type d -empty | xargs rmdir -p
> N:
> N: Or by telling MakeMaker to use vendor install dirs; cons
them. Those files are useless, and (in some cases)
have
N: the additional problem of creating an architecture-specific
directory
N: name in an architecture-independent package.
N:
N: They can be suppressed by adding the following to debian/rules:
N:
N: find debian/tmp -type f -name
On Fri, May 05, 2006 at 01:20:33PM -0400, Joey Hess wrote:
> It seems silly to me that the ftpmasters would take especial umbrage to
> A while not caring about B, and while probably not checking for C even
> though it is nearly identical to A in effect.
I think the ftpmasters should have much bett
Jari Aalto <[EMAIL PROTECTED]> writes:
> This is bad, such micromanagement for few commented lines should not
> warrant rejection criteria by the ftp masters. The dh_* calls are there
> for later upgrade of the package and retaining the order of the items is
> not the same as this pages' suggestio
Jari Aalto wrote:
> > See <http://ftp-master.debian.org/REJECT-FAQ.html> down near the bottom
> > near debian/rules.
>
> This is bad, such micromanagement for few commented lines should not
> warrant rejection criteria by the ftp masters.
Except the FAQ doesn't sa
Simon Richter <[EMAIL PROTECTED]> wrote:
> Exactly. So in order to understand my own packages better I leave the
> dh_* calls in, commented out so I can grep for them and see that they
> are disabled.
Well, I never felt this need.
> Being a DD, I think I should be able to make that judgement for
Hello,
Florent Rougon schrieb:
I'd say that if you're ready to sacrifice understanding of your package
in order to spare 15 seconds, you should probably spend your time on
something else than official Debian packages...
Exactly. So in order to understand my own packages better I leave the
dh
Romain Beauxis <[EMAIL PROTECTED]> wrote:
> Would you argue that you are not skilled if you comment your dh_* calls?
No, rather that if you're skilled, you don't need to comment them.
> You could simply not want to loose time to find back the good order...
I'd say that if you're ready to sacrif
On Friday 05 May 2006 15:23, Florent Rougon wrote:
> I disagree. If you aren't able to figure out a sane order for the dh_
> calls by yourself, you shouldn't be maintaining the package IMO (of
> course, you could maintain a private package for yourself and your
> friends, but we are talking here ab
Bart Martens <[EMAIL PROTECTED]> wrote:
> Anyway, I don't see a problem with the readability of debian/rules with
> the commented dh_ lines, and I agree with Jari Aalto that leaving the
> commented dh_ lines can be useful, so I would vote "allow" if a
> disc
1 - 100 of 277 matches
Mail list logo
