On Wednesday, December 28, 2022 2:49:19 PM MST Barry Scott wrote:
> If you ever need to package RPMs I can return the favor.
I might some day. I am the upstream developer for Privacy Browser PC, which
will
shortly reach an alpha release. I am planning to maintain Debian packages, but
I
might
On 27/12/2022 19:06, Andrew M.A. Cater wrote:
On Tue, Dec 27, 2022 at 10:57:51AM -0700, Soren Stoutner wrote:
Barry,
Figuring out how to package for Debian has a stiff learning curve (speaking as
someone
who is going through the process myself).
I have given up a number of times in the past
On Tue, Dec 27, 2022 at 10:57:51AM -0700, Soren Stoutner wrote:
> Barry,
>
> Figuring out how to package for Debian has a stiff learning curve (speaking
> as someone
> who is going through the process myself).
>
> There are a couple of website that collect links to information that might be
>
Barry,
Figuring out how to package for Debian has a stiff learning curve (speaking as
someone
who is going through the process myself).
There are a couple of website that collect links to information that might be
useful to you.
https://mentors.debian.net/intro-maintainers/[1]
https://wiki.d
On 27/12/2022 12:49, Santiago Vila wrote:
El 27/12/22 a las 13:12, Ole Streicher escribió:
Santiago Vila writes:
If you don't have deb-src lines, they are the same as the usual deb
lines
except that they begin with deb-src.
Just curious: why are the deb line not used by default here?
The
On 27/12/2022 11:16, Ole Streicher wrote:
Hi Barry,
Barry Scott writes:
I am build my first Debian package for Barry's Emacs
(https:://barrys-emacs.org)
Aside from Santiagos technical tips: If you really want to contribute
your package to the Debian distribution, you should also have a few
El 27/12/22 a las 13:12, Ole Streicher escribió:
Santiago Vila writes:
If you don't have deb-src lines, they are the same as the usual deb lines
except that they begin with deb-src.
Just curious: why are the deb line not used by default here?
There is a question during install about deb-src
On 2022-12-27 at 07:12, Ole Streicher wrote:
> Hi Santiago,
>
> Santiago Vila writes:
>
>> If you don't have deb-src lines, they are the same as the usual deb
>> lines except that they begin with deb-src.
>
> Just curious: why are the deb line not used by default here?
As a place to look for
Hi Santiago,
Santiago Vila writes:
> If you don't have deb-src lines, they are the same as the usual deb lines
> except that they begin with deb-src.
Just curious: why are the deb line not used by default here?
Best
Ole
El 27/12/22 a las 12:28, Barry Scott escribió:
How do I go from a installed package and find its debian source?
On a Debian/Ubuntu system, if you have deb-src lines in your
/etc/apt/sources.list,
then
apt-get source source-package-name
will retrieve the source and unpack it automatically.
I
Hi Barry,
Barry Scott writes:
> I am build my first Debian package for Barry's Emacs
> (https:://barrys-emacs.org)
Aside from Santiagos technical tips: If you really want to contribute
your package to the Debian distribution, you should also have a few
other things in mind:
* Your package shoul
On 27/12/2022 01:37, Santiago Vila wrote:
El 26/12/22 a las 16:28, Barry Scott escribió:
E: bemacs source: malformed-debian-changelog-version 8.9.3 (for
non-native) [debian/changelog:1]
It seems that the changelog issue is around lintian mandating a issue
to close?
I have no issue what do I
El 26/12/22 a las 16:28, Barry Scott escribió:
E: bemacs source: malformed-debian-changelog-version 8.9.3 (for non-native)
[debian/changelog:1]
It seems that the changelog issue is around lintian mandating a issue to close?
I have no issue what do I put in the changelog? Or do I have to configu
I am build my first Debian package for Barry's Emacs (https:://barrys-emacs.org)
My build environment is Ubuntu 22.10.
There are some lintian errors that I do not know how to handler.
Now running lintian bemacs_8.9.3_amd64.changes ...
E: bemacs source: malformed-debian-changelog-version
I have revised the previous iteration of Debian patch for libshairplay,
specifically fixed
the source package name to match upstream repository name.
Now Lintian throws an error "Package closes bugs in wrong way" despite of
retitle.
I am closing this bug and opening a new RFS with source package
On 21/01/17 09:32, Ferenc Wágner wrote:
> Shall I upload the backport, or do you plan to add anything else?
Yes, please upload it. :) I updated the debian/jessie-backports branch
with the contents of the package on mentors.
Etienne
signature.asc
Description: OpenPGP digital signature
Etienne Dysli-Metref writes:
> On 20/01/17 12:31, Ferenc Wágner wrote:
>
>> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:
>>
>> The postrm script is called after the package's files have been
>> removed or replaced. The package whose postrm is being called may
On 20/01/17 12:31, Ferenc Wágner wrote:
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:
>
> The postrm script is called after the package's files have been
> removed or replaced. The package whose postrm is being called may
> have previously been deconfigured
Etienne Dysli-Metref writes:
> On 19/01/17 23:46, Ferenc Wágner wrote:
>
>> I couldn't reproduce this on a real jessie system, only in a piuparts
>> chroot. I think the reason is that piuparts removes init-system-helpers
>> (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
On 19/01/17 23:46, Ferenc Wágner wrote:
> I couldn't reproduce this on a real jessie system, only in a piuparts
> chroot. I think the reason is that piuparts removes init-system-helpers
> (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
> could instruct it to clean up. I'm
Etienne Dysli-Metref writes:
> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
>
>> 0m34.6s ERROR: FAIL: Package
Etienne Dysli-Metref:
> On 17/01/17 18:30, Niels Thykier wrote:
E: libshibsp7: postinst-must-call-ldconfig
usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>>
>> This lintian error:
>>
>> * is aimed at stretch or later, and
>> * should be ignored for stable and stable-backports
Correction;
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>
> This lintian error:
>
> * is aimed at stretch or later, and
> * should be ignored for stable and stable-backports
After having overridden this lintian erro
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>
> This lintian error:
>
> * is aimed at stretch or later, and
> * should be ignored for stable and stable-backports
Thanks Niels! :)
That's a bit strange t
Etienne Dysli-Metref:
> Hello mentors,
>
> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
>
>> [...]
>
> So I
Hello mentors,
Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
holidays, I'm now backporting it to jessie. So far there is nothing to
change, however piuparts gives me the following error (which does not
appear on stretch):
> 0m34.6s ERROR: FAIL: Package purging left files on sy
On Mon, Feb 08, 2016 at 06:02:27PM +0100, toogley wrote:
> On 02/07/2016 10:30 PM, gregor herrmann wrote:
Hi,
> thanks.
> >Additionally, lintian runs more tests when run against the .changes
> >file (and not the .debs); and lintian has some nice command line /
> >configuration options to enable
thanks.
On 02/07/2016 10:30 PM, gregor herrmann wrote:
On Sun, 07 Feb 2016 18:12:36 +0100, Axel Beckert wrote:
$ lintian ../wicd-daemon_1.7.3-3_all.deb
$ lintian ../wicd-gtk_1.7.3-3_all.deb
$
==> Where is my mistake?
On which Debian release have you run lintian? On Debian stable? (I
guess s
On Sun, 07 Feb 2016 18:12:36 +0100, Axel Beckert wrote:
> > $ lintian ../wicd-daemon_1.7.3-3_all.deb
> > $ lintian ../wicd-gtk_1.7.3-3_all.deb
> > $
> >
> > ==> Where is my mistake?
>
> On which Debian release have you run lintian? On Debian stable? (I
> guess so, because the deprecated "git bui
Hi toogley,
toogley wrote:
> hey. i want to fix the lintian errors
> https://lintian.debian.org/maintainer/packa...@qa.debian.org.html#wicd
> in the 1.7.3-3 wicd packages
Cool, thanks!
> $ git checkout -b debian/1.7.3-3
> Switched to a new branch 'debian/1.7.3-3'
Tha
hey. i want to fix the lintian errors
https://lintian.debian.org/maintainer/packa...@qa.debian.org.html#wicd
in the
1.7.3-3 wicd packages
$ git checkout -b debian/1.7.3-3
Switched to a new branch 'debian/1.7.3-3'
$ git buildpackage --git-debian-branch=debian/1.7.3-3
[...]
$
On Monday 14 September 2015 15:21:56 Sabniveesu Shashank wrote:
> Running lintian on '.dsc' says:
>
> E: variety source: source-is-missing data/panoramio/underscore-min.js
>
> However, I do see that the path shown is right and it is present in
> the source tarball.
> Am I reading it wrong?
This
On Tue, Sep 15, 2015 at 12:26:27AM +0500, Andrey Rahmatullin wrote:
> On Mon, Sep 14, 2015 at 03:21:56PM -0400, Sabniveesu Shashank wrote:
> > Running lintian on '.dsc' says:
> >
> > E: variety source: source-is-missing data/panoramio/underscore-min.js
> >
> > However, I do see that the path show
On Mon, Sep 14, 2015 at 03:21:56PM -0400, Sabniveesu Shashank wrote:
> Running lintian on '.dsc' says:
>
> E: variety source: source-is-missing data/panoramio/underscore-min.js
>
> However, I do see that the path shown is right and it is present in
> the source tarball.
> Am I reading it wrong?
L
Hi!
I am taking up my first packaging task. I now have '.dsc', '.changes',
'.tar.gz' and '.deb' files created using 'quickly' tool.
Running lintian on '.dsc' says:
E: variety source: source-is-missing data/panoramio/underscore-min.js
However, I do see that the path shown is right and it is pres
Your message dated Sun, 19 Apr 2015 05:57:02 +
with message-id
and subject line closing RFS: hastymail2/1.1-1 [ITP] -- need help with lintian
errors
has caused the Debian Bug report #768377,
regarding RFS: hastymail2/1.1-1 [ITP] -- need help with lintian errors
to be marked as done.
This
Sorry, I just accidentally uploaded a package with two lintian tags
about d/copyright. I've just fixed them and the new package is now on .
You can get it using the command:
dget -x
http://mentors.debian.net/debian/pool/main/s/signify-openbsd/signify-openbsd_8-1.dsc
--
To UNSUBSCRIBE, email to d
On Fri, Nov 7, 2014 at 4:46 PM, Tobias Frost wrote:
> E source-is-missing
> plugins/notices/swf/soundmanager2.swf
> plugins/notices/swf/soundmanager2_flash9.swf
> plugins/html_mail/tiny_mce/plugins/media/moxieplayer.swf
>
> You'll need sources for everything and rebuild everything fro
Thanks Tobi,
for your quick review and suggestions - they definitely helped.
I'll have a look and ask on the mentors ml when I am stuck or have
further questions.
Cheers,
Christian
signature.asc
Description: OpenPGP digital signature
Sorry, I made a big error below:
> You'll need sources for everything and rebuild everything from source.
> (Don't know about flash packaging, if that is possible at all. )
> If the swf are not required for functioning, you could also packge them as a
> separate package (non-free) and only Recomme
PS: Sorry, I missed your RFH in the subject. (put those information in the
body, please)
Away from my dev machine, I can only give remote ideas without checking the
code.
Regarding the lintian errors:
license-problem-md5sum-non-free-file
Consider removing those files, preferable by a Files
thanks for contributing to Debian!
However, taking a look at the mentors page only, there are obvious problems --
among others several lintian errors.
I recommend you work on those as many sponsors have this as a prerequisite for
sponsoring.
Thanks!
--
tobi
--
To UNSUBSCRIBE, email to debian
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package "hastymail2"
* Package name: hastymail2
Version : 1.1-1
Upstream Author : Jason Munro ja...@hastymail.org
* URL : http://www.hastymail.org/
* License
* Tanguy Ortolo , 2010-05-30, 19:02:
FYI, your package does not build in a clean chroot; some
build-dependencies[1] are missing.
Do you have a log of such a failure?
No, but should easily reproduce it yourself.
The second one, missing-dep-for-interpreter, is about a Zsh script
(autojump pro
On 2010-05-30 19:31 +0200, Tanguy Ortolo wrote:
> Le dimanche 30 mai 2010, Sven Joachim a écrit :
>> On 2010-05-30 19:03 +0200, Tanguy Ortolo wrote:
>> > Le dimanche 30 mai 2010, Sven Joachim a écrit :
>> >> I think the autojump.* files should not have shebang lines, because it
>> >> would be rath
Le dimanche 30 mai 2010, Sven Joachim a écrit :
> On 2010-05-30 19:03 +0200, Tanguy Ortolo wrote:
> > Le dimanche 30 mai 2010, Sven Joachim a écrit :
> >> I think the autojump.* files should not have shebang lines, because it
> >> would be rather pointless to run them directly. If you remove the
>
On 2010-05-30 19:03 +0200, Tanguy Ortolo wrote:
> Le dimanche 30 mai 2010, Sven Joachim a écrit :
>> I think the autojump.* files should not have shebang lines, because it
>> would be rather pointless to run them directly. If you remove the
>> shebang lines and make the files non-executable, Lint
Le dimanche 30 mai 2010, Sven Joachim a écrit :
> I think the autojump.* files should not have shebang lines, because it
> would be rather pointless to run them directly. If you remove the
> shebang lines and make the files non-executable, Lintian should stop
> complaining.
… and compain instead
Le dimanche 30 mai 2010, Jakub Wilk a écrit :
> * Tanguy Ortolo , 2010-05-30, 18:19:
> FYI, your package does not build in a clean chroot; some
> build-dependencies[1] are missing.
Do you have a log of such a failure?
>> The second one, missing-dep-for-interpreter, is about a Zsh script
>> (aut
On 2010-05-30 18:19 +0200, Tanguy Ortolo wrote:
> The second one, missing-dep-for-interpreter, is about a Zsh script
> (autojump providing a Zsh extension, this is expected) and the following
> dependency set:
> Depends: ${misc:Depends}, python, ${python:Depends}, bash (>= 4.0) | zsh
> You wil
* Tanguy Ortolo , 2010-05-30, 18:19:
[2] http://vanvogt.ortolo.eu/~tanguy/deb/autojump/autojump_8-1.dsc
FYI, your package does not build in a clean chroot; some
build-dependencies[1] are missing.
The second one, missing-dep-for-interpreter, is about a Zsh script
(autojump providing a Zsh ex
Hello,
I am making a package for autojump [1], which is a Bash and Zsh
extension to chdir more efficiently. My package is available at [2].
[1] http://wiki.github.com/joelthelion/autojump/
[2] http://vanvogt.ortolo.eu/~tanguy/deb/autojump/autojump_8-1.dsc
My problem is that lintian gives me erro
On Wed, Dec 2, 2009 at 6:44 PM, rosea grammostola
wrote:
>> In this case I'm guessing the upstream package has an embedded code
>> copy of gettext, I'd suggest asking upstream to remove it and switch
>> to the standard system gettext.
>
> Is this something I can do myself to? How?
http://www.deb
Paul Wise wrote:
On Wed, Dec 2, 2009 at 6:05 AM, rosea grammostola
wrote:
dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if
"debian/openoctave/usr/bin/openoctavesequencer
debian/openoctave/usr/bin/openoctave" were not uselessly linked against it
(they use none of its s
On Wed, Dec 2, 2009 at 6:05 AM, rosea grammostola
wrote:
> dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if
> "debian/openoctave/usr/bin/openoctavesequencer
> debian/openoctave/usr/bin/openoctave" were not uselessly linked against it
> (they use none of its symbols).
>
Hi,
I get these messages:
dpkg-shlibdeps: warning: dependency on libXext.so.6 could be avoided if
"debian/openoctave/usr/bin/openoctavesequencer
debian/openoctave/usr/bin/openoctave" were not uselessly linked against
it (they use none of its
symbols).
On Tue, Aug 27, 2002 at 07:03:31PM -0600, Jay Graves wrote:
> Hello
> I have actively been trying to package the waimea window manager to be
> sponsored. There was an error in the 0.3.3 upstream code that has been
> fixed in the cvs branch. I have made a new package against the cvs
> branch and
On 2002.08.28 03:38 Rene Engelhard wrote:
Not necessary anymore
I see. That's the reason I sometimes do not see /usr/share/doc symlink
anymore. ;-)
___
If computers take over (which seems to be their natural tendency), it
will
serve us right.
-- Alistair Cooke
Hi Giorgio,
Giorgio Mandolfo wrote:
> As lintian said, you have to write a simple prerm and postinst script
> (or add to your previous one) in the debian/ dir, that set the symlink
> to your extra documentation page (and remove it if you remove the
> package).
Not necessary anymore
Regard
Hi Jay,
Jay Graves wrote:
> fixed in the cvs branch. I have made a new package against the cvs
> branch and put it at http://jay.skabber.com/debian/. However I get
> these two lintian erros.
>
> W: waimea: prerm-does-not-remove-usr-doc-link
> W: waimea: postinst-does-not-set-usr-doc-link
[...]
On 2002.08.28 03:03 Jay Graves wrote:
W: waimea: prerm-does-not-remove-usr-doc-link
W: waimea: postinst-does-not-set-usr-doc-link
I am really not quite sure what to do here and I would really
appreciate
some guidance.
Thanks
Hi.
As lintian said, you have to write a simple prerm and postinst
Hello
I have actively been trying to package the waimea window manager to be
sponsored. There was an error in the 0.3.3 upstream code that has been
fixed in the cvs branch. I have made a new package against the cvs
branch and put it at http://jay.skabber.com/debian/. However I get
these two lint
On Tue, Aug 27, 2002 at 07:03:31PM -0600, Jay Graves wrote:
> Hello
> I have actively been trying to package the waimea window manager to be
> sponsored. There was an error in the 0.3.3 upstream code that has been
> fixed in the cvs branch. I have made a new package against the cvs
> branch and
On 2002.08.28 03:38 Rene Engelhard wrote:
> Not necessary anymore
I see. That's the reason I sometimes do not see /usr/share/doc symlink
anymore. ;-)
___
If computers take over (which seems to be their natural tendency), it
will
serve us right.
-- Alistair Cooke
--
Hi Giorgio,
Giorgio Mandolfo wrote:
> As lintian said, you have to write a simple prerm and postinst script
> (or add to your previous one) in the debian/ dir, that set the symlink
> to your extra documentation page (and remove it if you remove the
> package).
Not necessary anymore
Regar
Hi Jay,
Jay Graves wrote:
> fixed in the cvs branch. I have made a new package against the cvs
> branch and put it at http://jay.skabber.com/debian/. However I get
> these two lintian erros.
>
> W: waimea: prerm-does-not-remove-usr-doc-link
> W: waimea: postinst-does-not-set-usr-doc-link
[...]
On 2002.08.28 03:03 Jay Graves wrote:
> W: waimea: prerm-does-not-remove-usr-doc-link
> W: waimea: postinst-does-not-set-usr-doc-link
> I am really not quite sure what to do here and I would really
> appreciate
> some guidance.
> Thanks
Hi.
As lintian said, you have to write a simple prerm and
Hello
I have actively been trying to package the waimea window manager to be
sponsored. There was an error in the 0.3.3 upstream code that has been
fixed in the cvs branch. I have made a new package against the cvs
branch and put it at http://jay.skabber.com/debian/. However I get
these two lin
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
> another thought here. If you actually MUST have libucxx0 (= 1.2) or whatever
> then the library is not doing its job and defining the soname correctly and
> perhaps libucxx0 is the wrong name. The whole point of SONAMEs is that the
> library
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
> another thought here. If you actually MUST have libucxx0 (= 1.2) or whatever
> then the library is not doing its job and defining the soname correctly and
> perhaps libucxx0 is the wrong name. The whole point of SONAMEs is that the
> librar
On 30-Oct-2001 Robert Bihlmeyer wrote:
> Andreas Rottmann <[EMAIL PROTECTED]> writes:
>
>> Depends: ${shlibs:Depends}, libucxx0 (= ${Source-Version})
>>
>> which results in:
>>
>> Depends: libc6 (>= 2.2.4-4), libsigc++0, libucxx0, python2-base (>= 2.0-1),
>> libucxx0 (= 0.2.0-1)
>>
>> Anybody
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> Depends: ${shlibs:Depends}, libucxx0 (= ${Source-Version})
>
> which results in:
>
> Depends: libc6 (>= 2.2.4-4), libsigc++0, libucxx0, python2-base (>= 2.0-1),
> libucxx0 (= 0.2.0-1)
>
> Anybody got a hint how to avoid that?
You can put the foll
On 30-Oct-2001 Robert Bihlmeyer wrote:
> Andreas Rottmann <[EMAIL PROTECTED]> writes:
>
>> Depends: ${shlibs:Depends}, libucxx0 (= ${Source-Version})
>>
>> which results in:
>>
>> Depends: libc6 (>= 2.2.4-4), libsigc++0, libucxx0, python2-base (>= 2.0-1),
>> libucxx0 (= 0.2.0-1)
>>
>> Anybody
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> Depends: ${shlibs:Depends}, libucxx0 (= ${Source-Version})
>
> which results in:
>
> Depends: libc6 (>= 2.2.4-4), libsigc++0, libucxx0, python2-base (>= 2.0-1), libucxx0
>(= 0.2.0-1)
>
> Anybody got a hint how to avoid that?
You can put the foll
On 30-Oct-2001 Andreas Rottmann wrote:
> I repackaged a previously lintian-clean package of mine right now and
> the new lintian (v1.20.16) barks:
>
> E: libucxx0-python: package-has-a-duplicate-relation libucxx0
> E: libucxx0-guile: package-has-a-duplicate-relation libucxx0
>
> Yeah, I understa
On Tue, Oct 30, 2001 at 01:11:46PM +0100, Andreas Rottmann wrote:
> I repackaged a previously lintian-clean package of mine right now and
> the new lintian (v1.20.16) barks:
> W: libucxx0: postinst-unsafe-ldconfig
> W: libsigcx0-gtk: postinst-unsafe-ldconfig
>
> But both of them have the ldconfi
On 30-Oct-2001 Andreas Rottmann wrote:
> I repackaged a previously lintian-clean package of mine right now and
> the new lintian (v1.20.16) barks:
>
> E: libucxx0-python: package-has-a-duplicate-relation libucxx0
> E: libucxx0-guile: package-has-a-duplicate-relation libucxx0
>
> Yeah, I underst
On Tue, Oct 30, 2001 at 01:11:46PM +0100, Andreas Rottmann wrote:
> I repackaged a previously lintian-clean package of mine right now and
> the new lintian (v1.20.16) barks:
> W: libucxx0: postinst-unsafe-ldconfig
> W: libsigcx0-gtk: postinst-unsafe-ldconfig
>
> But both of them have the ldconf
I repackaged a previously lintian-clean package of mine right now and
the new lintian (v1.20.16) barks:
E: libucxx0-python: package-has-a-duplicate-relation libucxx0
E: libucxx0-guile: package-has-a-duplicate-relation libucxx0
Yeah, I understand this, but I dont know how to avoid it, since I must
I repackaged a previously lintian-clean package of mine right now and
the new lintian (v1.20.16) barks:
E: libucxx0-python: package-has-a-duplicate-relation libucxx0
E: libucxx0-guile: package-has-a-duplicate-relation libucxx0
Yeah, I understand this, but I dont know how to avoid it, since I mus
Joey Hess <[EMAIL PROTECTED]> wrote:
>Colin Watson wrote:
>>You should not create hard links in the manual page directories, nor
>>put absolute filenames in .so directives.
>
>Heh. There's a man page somewhere in debian that looks something like:
>
>
>.so /usr/bin/foo
>
>
>You can probably
Joey Hess <[EMAIL PROTECTED]> wrote:
>Colin Watson wrote:
>>You should not create hard links in the manual page directories, nor
>>put absolute filenames in .so directives.
>
>Heh. There's a man page somewhere in debian that looks something like:
>
>
>.so /usr/bin/foo
>
>
>You can probably
Colin Watson wrote:
>You should not create hard links in the manual page directories, nor
>put absolute filenames in .so directives.
Heh. There's a man page somewhere in debian that looks something like:
.so /usr/bin/foo
You can probably imagine what an unholy mess of groff pretending
Bob Hilliard wrote:
> The only guidance I can find in policy 3.5.2.0 on the subject of
> stripping binaries is in section 11.1. Binaries:
>
> Note that by default all installed binaries should be stripped, either
> by using the `-s' flag to `install', or by calling `strip' on the
>
Colin Watson wrote:
>You should not create hard links in the manual page directories, nor
>put absolute filenames in .so directives.
Heh. There's a man page somewhere in debian that looks something like:
.so /usr/bin/foo
You can probably imagine what an unholy mess of groff pretending
Bob Hilliard wrote:
> The only guidance I can find in policy 3.5.2.0 on the subject of
> stripping binaries is in section 11.1. Binaries:
>
> Note that by default all installed binaries should be stripped, either
> by using the `-s' flag to `install', or by calling `strip' on the
>
Josip Rodin <[EMAIL PROTECTED]> writes:
> > If lintian objects to them, shouldn't policy mention stripping them?
>
> Doesn't it already?
The only guidance I can find in policy 3.5.2.0 on the subject of
stripping binaries is in section 11.1. Binaries:
Note that by default all installed
Josip Rodin <[EMAIL PROTECTED]> writes:
> > If lintian objects to them, shouldn't policy mention stripping them?
>
> Doesn't it already?
The only guidance I can find in policy 3.5.2.0 on the subject of
stripping binaries is in section 11.1. Binaries:
Note that by default all installe
On Sat, Apr 21, 2001 at 10:08:12AM -0400, Bob Hilliard wrote:
> Josip Rodin <[EMAIL PROTECTED]> writes:
> > Hmm, did you run strip --remove-section=.comment --remove-section=.note on
> > the binaries?
>
> Carlos Laviola <[EMAIL PROTECTED]> writes:
> > Call strip with '--strip-unneeded' in your deb
[EMAIL PROTECTED] (Colin Watson) writes:
> >Please install dictunzip.1 and dictzcat.1 as symlinks or hardlinks.
>
> Actually, ignore the "... or hardlinks" bit. Policy 13.1:
>
>You should not create hard links in the manual page directories, nor
>put absolute filenames in .so directives.
Josip Rodin <[EMAIL PROTECTED]> writes:
> Hmm, did you run strip --remove-section=.comment --remove-section=.note on
> the binaries?
Carlos Laviola <[EMAIL PROTECTED]> writes:
> Call strip with '--strip-unneeded' in your debian/rules to strip
> these sections out of the binaries when building th
[EMAIL PROTECTED] (Colin Watson) wrote:
>Bob Hilliard <[EMAIL PROTECTED]> wrote:
>> The gzip package has a similar situation with gunzip and zcat,
>>but it has created gunzip.1 and zcat.1 as hardlinks to gzip.1. Since
>>man can deal with a manpage with multiple names, this seems like an
>>unne
Bob Hilliard <[EMAIL PROTECTED]> wrote:
> I have added symlinks from /usr/bin/dictunzip and
>/usr/bin/dictzcat to /usr/bin/dictzip. The manpage for dictzip
>includes the following:
>
>NAME
> dictzip, dictunzip, dictzcat - compress (or expand) files,
> allowing random access
>
>SYNO
On Sat, Apr 21, 2001 at 10:08:12AM -0400, Bob Hilliard wrote:
> Josip Rodin <[EMAIL PROTECTED]> writes:
> > Hmm, did you run strip --remove-section=.comment --remove-section=.note on
> > the binaries?
>
> Carlos Laviola <[EMAIL PROTECTED]> writes:
> > Call strip with '--strip-unneeded' in your de
[EMAIL PROTECTED] (Colin Watson) writes:
> >Please install dictunzip.1 and dictzcat.1 as symlinks or hardlinks.
>
> Actually, ignore the "... or hardlinks" bit. Policy 13.1:
>
>You should not create hard links in the manual page directories, nor
>put absolute filenames in .so directives
Josip Rodin <[EMAIL PROTECTED]> writes:
> Hmm, did you run strip --remove-section=.comment --remove-section=.note on
> the binaries?
Carlos Laviola <[EMAIL PROTECTED]> writes:
> Call strip with '--strip-unneeded' in your debian/rules to strip
> these sections out of the binaries when building t
[EMAIL PROTECTED] (Colin Watson) wrote:
>Bob Hilliard <[EMAIL PROTECTED]> wrote:
>> The gzip package has a similar situation with gunzip and zcat,
>>but it has created gunzip.1 and zcat.1 as hardlinks to gzip.1. Since
>>man can deal with a manpage with multiple names, this seems like an
>>unn
Bob Hilliard <[EMAIL PROTECTED]> wrote:
> I have added symlinks from /usr/bin/dictunzip and
>/usr/bin/dictzcat to /usr/bin/dictzip. The manpage for dictzip
>includes the following:
>
>NAME
> dictzip, dictunzip, dictzcat - compress (or expand) files,
> allowing random access
>
>SYN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20-Apr-2001 Bob Hilliard wrote:
> I am preparing a new release of dictd. Lintian gives the
> following warnings:
>
> W: dictd: binary-has-unneeded-section ./usr/bin/dictzip .note
> W: dictd: binary-has-unneeded-section ./usr/bin/dictzip .com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20-Apr-2001 Bob Hilliard wrote:
> I am preparing a new release of dictd. Lintian gives the
> following warnings:
>
> W: dictd: binary-has-unneeded-section ./usr/bin/dictzip .note
> W: dictd: binary-has-unneeded-section ./usr/bin/dictzip .co
1 - 100 of 136 matches
Mail list logo