and asking if
dak supports .bz2 and if they're willing to accept such packages in the
archive. If so, we should change Policy.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(Note that this does
*not* apply to all software created by US government contractors. It
depends on the terms of the contract. But if they say that the contract
didn't assign copyright to the contractor in this case, it's reasonable to
believe them.)
--
Russ Allbery ([EMAIL PROTECTED
libraries on the default search path. Private libraries don't need it,
and Policy 8.1.1 only says to run ldconfig when installing libraries into
the default search path.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
earch
path, why aren't they in /usr/lib?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
say* that.
I think it's buggy wording rather than a problematic license, but the
wording is buggy. I expect upstream really intends something more like
the license Automake uses.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, e
kage of,
say, 1.1.4 would have the same symbols even if it was -1~bpo.40 or -0.1 or
something strange.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
.
If the two libraries do change independently, you'll have to change the
library package name to not include an underscore since underscore isn't
allowed in package names in Debian. The recommendation (which will make
lintian happy) is to replace _ with - in the package name.
--
Rus
t; This is a bug in python-central IIRC, i have tried to fix it for hours
>> but someone point me at a bug that makes this empty usr/lib/
>
> FTR: #452227.
Let me know if python-central decides to keep the empty directories and I
can add an exception to lintian. This tag is fairly new
r to Library Packaging guide 5 for details.
>
> Also false positive. Check shlibs. (If I remember well there was a bug
> in lintian.)
I didn't build this package to double-check, but I expect this lintian tag
is correct as far as it goes and isn't a bug. It looks like you have a
package named libpoco2 which doesn't contain a shared library named
libpoco.so.2.
It is a place where an override is probably justified, however.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
he Debian Free Software Guidelines.) So
the practical impact for a Debian derivative of including or not including
one more package with the four-clause BSD license is minimal.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EM
issues, I wanted to
clarify that including one more package with this license would not cause
any noticable hardship for redistributors compared to what they already
would need to deal with.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSU
the
advertising clause in July of 1999 and the DFSG were adopted in July of
1997 according to Wikipedia. Hence, I assumed the BSD license as referred
to in the DFSG must, regardless of what the web site currently links to,
actually refer to the 4-clause license since that's the only thing that
exist
Charles Plessy <[EMAIL PROTECTED]> writes:
> Le Wed, Feb 06, 2008 at 10:27:55PM -0800, Russ Allbery a écrit :
>> Am I missing something?
> This ?
> http://web.archive.org/web/19990210065944/http://www.debian.org/misc/bsd.license
> http://web.archive.org/web/200012050832
cripts. dpkg may be modified to not install /usr/share/doc at all. You
should ship them in /usr/share/ and add a symlink in
/usr/share/doc if desired.
See Policy 12.3.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL P
s implications. We haven't
figured out what to say instead, but deleting the files is fairly common
right now.
See http://bugs.debian.org/397939 for some additional discussion.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email
Székelyi Szabolcs <[EMAIL PROTECTED]> writes:
> What's the usual way of handling "preX" upstream version numbers in
> watch files? I'm having trouble because uscan considers 1.0pre3 newer
> than 1.0.
opts=uversionmangle=s/pre/~pre/
--
Russ Allbery ([EM
re out which files are generated in
order to remove them, but that's probably programmatically fixable.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bas Wijnen <[EMAIL PROTECTED]> writes:
> On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
>> Always re-running autoconf and automake would increase the number of
>> FTBFS's that we'd need to fix.
> Not really.
No, really, I promise it will. :)
t form by the libtool
maintainers, but if so, whatever generation is done is already done as
part of the installation of libtool.
It's not like Autoconf or Automake where a file in the source is used as
input to a compiler which generates a shell script based on it.
--
Russ Allbery ([EMAIL PROTE
Bas Wijnen <[EMAIL PROTECTED]> writes:
> On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
>> Note that libtool is an unusual case here and isn't the same as
>> Autoconf or Automake. The files included in the package (libtool.m4
>> and ltmain.sh) are
Clint Adams <[EMAIL PROTECTED]> writes:
> On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
>> Note that libtool is an unusual case here and isn't the same as
>> Autoconf or Automake. The files included in the package (libtool.m4
>> and ltmain.sh) are
ying
one of those files can suddenly spark the discovery that upstream isn't
compatible with the current autotools, the partial run of Automake can
leave the whole tree in a broken state, and so forth.
But I suppose that's basically the normal argument for AM_MAINTAINER_MODE.
--
Russ A
table/main Packages
*** 1:1.10.1-2 0
990 http://exodus.stanford.edu testing/main Packages
100 /var/lib/dpkg/status
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ing.
It's a weird target in various respects. For example, should you declare
the programs it needs in Build-Depends? I don't think so, and it would
feel weird to me to do so, but as a result I use software in
get-orig-source for which there's no hint in the source package contr
x27;s correct, except that the processing is only
semi-automatic and has to be kicked off by a person. But I don't think
you need to file a bug for this case.
You need to file a bug if you drop a package from only some architectures
that previously had that package, but if you stop building
not like it's
strictly checking against Free Desktop specifications right now anyway
(since tons and tons of .desktop files use Applications, which also isn't
valid).
If you can tell me the list of categories on which you've agreed, I'll add
them to lintian.
--
Russ Allbery ([EM
at this. I don't get these on i386 ( I only get 2
> warnings and 1 informational about a manpage). I don't have an amd64.
>
> Any suggestions/pointers?
Usually, but not always, this means upstream is using an outdated libtool.
--
Russ Allbery ([EMAIL PROTECTED])
eader in the file.. if you remove
> it, the warning will disapear.
While I think it's pointless to have a #! header in .py library files,
this is common enough practice with Python that the next release of
lintian will ignore it. So you can also leave it alone and the warning
will go away with the
me are correct,
> for one thing. Can someone perhaps help?
You have dh_makeshlibs commented out in your debian/rules file. You have
to run dh_makeshlibs when building shared libraries. Otherwise, you don't
get a shlibs file, which means that the shared library package won't work
aries that the plugin uses.
That dlopen() guarantee isn't as much of a guarantee as people think it
is, and there are options with which you can call it that will cause this
to fail. However, lots and lots and lots of stuff does work this way and
usually doesn't cause problems.
--
Rus
ot from the environment in which the package was
built. You have to edit the *.changes file after the build if you want to
target a different distribution than the debian/changelog entry indicates.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To
ompliant ??
I don't know what "it" refers to in this sentence.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
her than something you're owed. Not building
your package for other architectures isn't treating you like shit; it
really isn't personal.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sible-gpl-code-linked-with-openssl
If you add the exception from upstream to the copyright file and it uses
one of the standard wordings that talks about an exception or exemption,
lintian will figure it out for itself without needing an override.
--
Russ Allbery ([EMAIL PROTECTED]
ation that is useful only in the context
> of that VCS data.
Is this some additional VCS that the default dpkg-source regex should be
changed to also handle? Excluding any VCS files seems to be the goal of
the regex and I expect the maintainers would not be adverse to adding
another one.
would make that
process simpler for you is great here.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
used here to separate groups of changes, if desired.
I don't know if it's worth being more formal here in Policy or not. It
might be more of a devref thing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL
anslations updated, release codenames and indeed
> maintainer names are there only for humans to read.
This is not *completely* true; lintian parses the changelog for certain
words and conventions and will whine if you don't follow them. But
lintian tends to be a weird special case about some
;m actually working to other people working on
packages.
In the meantime, you can still look at the openafs package, which is
currently using quilt and applies a whole bunch of patches (although we
may switch to Git at some point down the road).
--
Russ Allbery ([EMAIL PROTECTED]) <
"Paul Johnson" <[EMAIL PROTECTED]> writes:
> On Sat, May 31, 2008 at 9:59 PM, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> At this point, I've converted most of my packages to use Git, which
>> means that the source package as uploaded to Debian has one col
Git.
I'm hopeful that the 3.0 package format will address this, or that
otherwise one of the people who are talking about doing this with their
packages will write up a good set of tools to let me do this easily, so
that I don't have to do the work of writing such a tool.
--
Russ Allbery
George Danchev <[EMAIL PROTECTED]> writes:
> On Sunday 01 June 2008, Russ Allbery wrote:
>> I'm currently not doing this for a very prosaic reason: I don't have a
>> simple tool that does it for me, and I'm too busy with other things to
>> write one. Th
Vincent Bernat <[EMAIL PROTECTED]> writes:
> This is a bit odd to have a package depends on xfonts-75dpi. Do you know
> the rationale behind this dependency?
It's also a Policy violation. See Policy 11.8.5, first point, last
sentence.
--
Russ Allbery ([EMAIL PROTECTED])
. (I haven't looked at
the description to see the situation. Usually referring to command-line
programs rather than software in the description is rare, but there are
cases where you want to do it.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
not
sure why it's not triggering -- maybe I'm misunderstanding what's going
on?)
If you're shipping a debugging version of the shared library that's a full
shared library in its own right because building with debugging changes
the library, then yes, you'll need to over
was confusing me. You're
also shipping a different shared library in the same package, which
happens to be a debugging build of another shared library.
If the package contained only detached debugging information, Lintian
wouldn't be confused.
--
Russ Allbery ([EMAIL PROTECTED])
into a package
name. This line removes the ".so." part of the SONAME.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
that says that a library named
libkrb5.so.3 should result in a package name of libkrb5-3 and not
libkrb53. It therefore only matches library names that end in a number.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PR
g.guess
> endif
Better, you can just Build-Depend on autotools-dev and copy them
unconditionally. You don't really want the build to change depending on
whether or not someone happens to have autotools-dev installed.
--
Russ Allbery ([EMAIL PROTECTED]) <http://ww
ntical, but common-licenses/BSD specifically is about the
> *university* license, while ours refers to the real authors.
You're correct. You can only use /usr/share/common-licenses/BSD for code
that's actually owned by the Regents of the University of California, not
for other cod
"standard" set of such defines
that the compiler sets up automatically (standard in the sense that every
time I need to figure out what they are, I have to go grovelling through
arcane compiler flags or obscure documentation).
--
Russ Allbery ([EMAIL PROTECTED]) <http:/
ll, that's one of the less important reasons
> why I always write mdoc manual pages :)
POD is a very simple language for writing man pages and takes care of this
for you too. :)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"William Vera" <[EMAIL PROTECTED]> writes:
> But I don't know yet how to fix those lintian warnings :/
For each line identified by lintian, look at all the dashes (-) on that
line. If any of them are literal - characters, usually for program
options, put a \ in front of
by upstream or they wouldn't be in the Debian diff.
If you run autotools before the build, you need to delete all the files
modified by that build process in debian/rules clean so that those
spurious changes aren't included in the Debian diff.
--
Russ Allbery ([EMAIL PROTECTED])
before something added itself to the
global Apache configuration.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I think that's more a matter of convenience and because they have
well-known and non-problematic licenses. Since we're distributing them,
to be fully and formally correct, we should probably document the license
status. (Not that I expect many people to go to the effort, but I do do
so wh
Stefan Fritsch <[EMAIL PROTECTED]> writes:
> On Sunday 06 July 2008, Russ Allbery wrote:
>> That would really upset me if I were a systems administrator. Most of
>> my Apache configurations have multiple virtual hosts, and having some
>> package randomly add itsel
thing except bug upstream, but I'm not horribly happy with them and
having more of them is generally not useful. Ideally, the lintian.d.o
report for a package should represent some sort of meaningful to-do list
for the Debian maintainer. Including things on that list that aren't
acti
uot;$(CURDIR)/file.extension"
> work in the debian/.links file, or is there some other
> preferred method?
You should provide the full path of the target file to dh_link. dh_link
will then do whatever is necessary to make it a Policy-compliant link. So
if you're linki
Julien Cristau <[EMAIL PROTECTED]> writes:
> On Sun, Jul 13, 2008 at 22:13:27 -0700, Russ Allbery wrote:
>> [EMAIL PROTECTED] writes:
>>> 3) Even if "mkfontdir" were invoked directly or if it's okay to give
>>> "update-fonts-dir" an
Julien Cristau <[EMAIL PROTECTED]> writes:
> Maybe HOME was still set to the user's home dir? If XAUTHORITY isn't
> set Xlib looks in $HOME/.Xauthority, so that may work depending how you
> get root.
Ah, XAUTHORITY was set. Thank you. I didn't know about t
n your xorg.conf.
Policy needs some wording adjustment here to make this more clear. It's
caused a fair bit of confusion lately.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ot;command-line-driven" is more correct. The
phrase "command-line driven" is being used as an adjective, which
conventionally means that you hyphenate the entire phrase.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRI
ugh that it's supported by any debhelper that a building
host is likely to be able to install (in practice, old enough that it's
supported in stable), but there's really no reason not to use the more
accurate and informative dependency.
--
Russ Allbery ([EMAIL PROTECTED])
version a dependency if I knew there was an oldstable
(or even just stable) version that didn't support what I needed, but with
debhelper it's just so easy to always version it for consistency.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
verride for these.
Lintian does not warn about empty directories in /var. I suspect that
your empty directories (particularly cache) may be in the wrong place
according to the FHS for what the package will put in them.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~
f any such thing in policy
> Then maybe the lintian warning could be removed.
The Lintian warning frequently catches scripts that were supposed to be
executable but don't have correct permissions, as Joey says. There are
already exceptions in Lintian for libraries for some scri
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> writes:
> group www-data may be absent on buildd
I should certainly hope not, given that it's in base-passwd.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, ema
user may not exist on the machine the
> package is build from, right ?).
I'm surprised that this doesn't work. Shouldn't fakeroot handle this case
and do the right thing? Or am I confused about what fakeroot is capable
of?
--
Russ Allbery ([EMAIL PROTECTED]) <
s way, but I think it's much better to run the
autotools during the build. Just delete the generated files during the
clean target and then the changes won't bloat the diff.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email
ing subsequent changes on the new fixed commit. Then move all
the other tags and branches to the new commits, and git gc should remove
the unreachable objects.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
nsferred is not so big, and
> IMHO does not justifies two separate packages (ssystem and ssystem-data).
That would imply that Lintian's threshold for this warning is too low.
What do other people think?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~e
lize this even if a file with that name
exists for some other reason.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
at the
diffs they're broken (you have the same block in both diffs).
Please re-upload without those changes and I'll be happy to upload this
NMU given that the maintainer is listed in LowNMU.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
which
is already tagged pending).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uot; with some proper
> variables set. Apart from that configure, the rest is using the
> standard Debian packaging tools.
>
> If anyone knows about a more elegant way than the "dummy configure
> file", I'd be also interested in it :-)
Why not take the commands in you
perl | libtest-harness-perl probably isn't necessary, though. Just
listing perl is fine, unless you are trying to support backports to a
verison of the perl package before Test::Harness was added to core.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
hange?
No need, I just changed this in Policy's Git repository. It will be in
the next release.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
_SYS_LARGEFILE will add to CFLAGS
whatever flags are needed to enable large files. (Unfortunately, since
upstream is using ext_CFLAGS instead of CFLAGS, you may not be able to
just delete upstream's Autoconf code and add that macro.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Raphael Geissert <[EMAIL PROTECTED]> writes:
>> Build-Depends: debhelper (>= 6.0.7~)
>
> what is that tilde doing there? (lintian should probably warn about it)
It allows the package to build with backports of debhelper 6.0.7.
--
Russ Allbery ([EMAIL PROTECTED]
seeing obscure bugs and issues on some architectures unless a
current version of libtool was used. These sorts of bugs unfortunately
are the kind that can be hidden or cause weird failures. I really think
this one should be fixed.
--
Russ Allbery (r...@debian.org) <http://ww
h is designed for exactly
this purpose.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ing an explicit architecture to the package wastes archive space by
duplicating the package on all 32-bit platforms.
It would be nice if there were some way of telling the archive software
not to include this package in the archive index on the platforms it
doesn't support, though.
--
Russ Allber
ple, which then passes it along to dpkg-buildpackage and
from there to dpkg-genchanges.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
may have to do something more complicated
(grep-dctrl would probably help).
The sort there isn't entirely correct; you really want to do a dpkg
version comparison.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, ema
n a wishlist bug against devscripts
with the final version of the code?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ches that the upstream maintainers might take.
They still might not be willing, but at least you have a fighting chance,
where as the post-configure sed stuff they'll never want.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [E
at could
be easily fixed
I think it's very important to use the upstream tarball exactly as it was
downloaded from upstream whenever possible, since that way (as previously
mentioned) signatures are still valid, MD5 checksums are still valid, etc.
The exception would be when you have to
t to run the clean rule, although I
know that isn't always as easy as it sounds. But it's nice to be able to
use pdebuild without having the build dependencies installed outside the
chroot.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ge the doc is for.
I prefer -tutorial to -doc in this particular case, since otherwise when
browsing the package list I'd think I'd have to install the -doc package
to get any documentation at all (rather than just a separate tutorial).
--
Russ Allbery ([EMAIL PROTECTED]) &
as part of package installation, which this isn't.
Depends is for things the package needs to run. Build-Depends is for
things the package needs to build. Things the package needs to run
get-orig-source or the like are neither, and therefore don't need to be
listed, IMO.
--
Russ Allb
> Upgrading is typically in the postinst. Or did I misunderstand?
I'm pretty sure that he's talking about updating the .orig.tar.gz tarball,
and the script that was upthread called rpm2cpio as part of that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eag
in progress, in fact.
That leaves the following as the only differences that I don't know the
story behind off-hand:
> +gcc-4.0-base
> +lsb-base
> +makedev
> +passwd
> +procps
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Justin Pryzby <[EMAIL PROTECTED]> writes:
> On Wed, Nov 09, 2005 at 01:13:44PM -0800, Russ Allbery wrote:
>> Essential means that it's very difficult to remove the package and you
>> have to jump through extreme hoops to do so, and that removing it may
>> break the
id it come from, anyway? If
> they serve a purpose, they should probably be listed in .PHONY, for
> consistency and transparency.
It's common in older packages, probably due to some migration of policy
from long ago. I just strip it out routinely whenever I see it.
--
Russ Allbery ([EMAIL
er uploading that package, I believe you'd need to file
a bug with ftp.debian.org to remove the old fhist-doc package.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ian messages stay rather than using overrides. A
lintian override to me means that the lintian message is wrong in this
particular case, not that it's a known bug.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PR
(which should happen before any upload).
Right. And for this particular lintian error, it also means that if the
"missing man page" QA project gets resurrected, it will be easy for others
to find the packages that need assistance.
--
Russ Allbery ([EMAIL PROTECTED])
res that cdrtoaster uses
alternatives too, but then the result is much more maintainable and
predictable for the user.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
w when you've fixed the above (except maybe the last) and I'll
sponsor the package.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 707 matches
Mail list logo
