Arno Töll writes:
> On 23.07.2013 20:08, Russ Allbery wrote:
>> Hm, how do you deal with the conf.d vs. conf-available change and the
>> completely different maintainer script actions?
> there are several possibilities, but I suggest something like [1] which
> I wrote fo
h comes from just having
the libraries be multi-arch, and we've not yet made a push to multi-arch
the dev packages. The dev packages pose a variety of additional
challenges that we haven't completely sorted through.
--
Russ Allbery (r...@debian.org) <http://www.ey
dh_makeshlibs -Xusr/lib/gemrb/plugins
(This is really a (minor) upstream bug, since, as plugins, these objects
should not have SONAMEs.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
w
Beren Minor writes:
> On Wed, Sep 4, 2013 at 12:49 AM, Russ Allbery wrote:
>> Alternately (and in my opinion preferrably) just exclude the plugins
>> directory from dh_makeshlibs:
>> override_dh_makeshlibs:
>> dh_makeshlibs -Xusr/lib/gemrb/plugins
the correct path forward.
Note that this only works if the only binaries linked with that shared
library are built from the same source package. If you have to link with
that shared library across source packages, you may want to consider a
different approach.
--
Russ Allbery (r...@debian.org
Russ Allbery writes:
> Beren Minor writes:
>> I can either:
>> - exclude usr/lib/gemrb from dh_makeshlibs
> I would do this. If the library is not a public API that should be used
> by other projects, then having out it ouf /usr/lib is probably the right
> decision
e DFSG #1 and #3. (It
would be okay for the separate non-free archive.)
--
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..
to your
package and don't require any further investigation.
--
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 list
library isn't widely used enough that
it's worth maintaining two versions, but I think those are generally
rarer.
But the default should be to not include it, just like the default for
-dev packages is to not include version numbers in the package name or
support more than one -dev packa
uff\n");
> reorderscore_memory();
> savescore_memory2file();
> }
> What would be the standard way to lock the scorefile?
fcntl(fd, F_SETLK). See fcntl(2).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to de
ily see it that way. I've seen
upstreams just refuse to add the license exception on the grounds that
they think Debian's concern is silly and they refuse to cater to it.
*sigh*
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBS
rmal IETF process. (I think this is quite reasonable
given how scarce such ports are.)
--
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".
sd, "tag logout\r\n", 12) < 0) {}
socket_close(sd);
which gcc is happy with. (The socket_* calls are, on Linux, just macros
that expand to write and close. They exist for compatibility with
Windows, where different functions have to be used when working with
sockets.)
--
Russ A
prefix. You can possibly
work around this by setting prefix to $(CURDIR)/debian/tmp, but this
really should be fixed upstream by adding support for DESTDIR.
http://www.gnu.org/prep/standards/html_node/DESTDIR.html
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
eral years. I have
> fix it myself, but I don't know how.
Generally it's as simple as adding $(DESTDIR) in front of the installation
paths for all install rules in the upstream Makefiles.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSU
Paul Wise writes:
> Send the lintian authors a patch to update the current
> Standards-Version.
This is already in progress -- no need to send more patches.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-
nd then just move
the files around yourself instead of using dh_install. Which in this
case means making a debian/glimpse/usr/lib/glimpse directory and moving
some of the files into it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRI
to start with the empty set and just keep building and
adding dependencies to fix each failure or each missing feature in
configure.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
wit
n your Depends line with
${perl:Depends}, although the details can depend on the exact situation.
--
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
ow this policy section is interpreted for normative
> behaviour.
What's currently done everywhere in the archive is that the targets run by
dpkg-buildpackage (either arch or arch-indep builds) must have their
dependencies listed, and dependencies for the other targets are not
listed.
--
Rus
inly
actively maintained.
I always just write this stuff by hand, but I also mostly don't support
long options. I keep meaning to find a more portable solution to that for
C programs than GNU getopt_long(3).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
am is using something else
to name the destination binary directory, use whatever variable upstream
is using; if they're just using usr/bin literally, then use:
install -d $(DESTDIR)/usr/bin
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRI
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 fai
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 no
med after the thing you were trying to
rename it to, which is obviously broken. If you want to rename things,
you'll need to do that separately, usually with an override and some code
that runs before dh_install.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/
Schwimmer
* Extensively modified by Russ Allbery
from one of my projects.
> - I should inherit the BSD-licensed, right?
Yes, almost always.
> - How to express that the new file was based on another old file from a
> different author in the debian/copyright file?
Copyright: 2003-2008 John Doe
compat level 9, you need debhelper 9 or later, which means
stable or squeeze-backports (but not squeeze itself).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "un
ream changes since the previous
release.
--
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
closed in the Debian packaging.
> For the CVE's already fixed by a older version than 1.4.12, it is
> allowed to modify the old changelog entries, when the fix was actually
> added.
Yup.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Dariusz Dwornikowski writes:
> On wto, lut 18, 2014 at 01:29:06 -0800, Russ Allbery wrote:
>> I think you were also saying this, but just to be very clear: please
>> also include the CVE numbers directly in debian/changelog in the entry
>> for whatever release they were fixe
cialized users for running
particular applications normally should not have a valid shell, and
auditors will often require that they not have a valid shell. You don't
want that sort of change (possibly required by local audit policies) to
break the package.
--
Russ Allbery (r...@
into a
UID via getpwnam)? Then you wouldn't have to modify the configuration
file.
If it doesn't support names now, could that be added? It might be a
fairly simple patch, a few lines at most.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
hese days for most
packagers to spend time on.
--
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
Archive: h
in unstable
or testing. wheezy was still Apache 2.2, and the Apache packaging for
wheezy is substantially different than Apache packaging for jessie and
newer releases.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to deb
rmat: it's
> probably a plugin.
> ```
> then.
Yes. The "it's probably a plugin" part is basically trying to tell you to
ignore this as long as the message is correct and it is a plugin.
Python, PHP, and Apache modules all generally get this warning.
--
Russ Allbery (
ONAME. I'm not sure why -- I think it shouldn't -- but that will
at least affect Apache and PHP modules.
I must be misremembering the Python situation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-re
rectly. Changing that to /usr/lib/*/*.a is usually the
right fix (and similarly for the other patterns in other *.install files).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a su
ian, so you may
not want to do things this way and instead provide some sort of Makefile
to install things, but it works great for quick internal packages.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@li
, as long as the packages in Debian do the right thing.
> Is any of these Stanford-internal packages available to be looked at in
> a public place?
It doesn't look like it, unfortunately.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNS
ppreciate any recommendations on dealing with this myself, as I'm
running into this in several packages I'm working on. For the time being,
I've just been ignoring it, but I'm not sure if that's correct.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
better answer.
Well, I'm the upstream maintainer of pod2man, so if you can give me
specifics, I can try to get this fixed. Note that there's a much newer
version of pod2man that's awaiting Pod::Simple to be completely ready for
it to be released, and a variety of changes are waiting on that process.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
0 -0700
@@ -517,6 +517,7 @@
my $lines = tr/\n/\n/;
1 while s/^(.*?)(\t+)/$1 . ' ' x (length ($2) * 8 - length ($1) % 8)/me;
s/\\/\\e/g;
+s/-/\\-/g;
s/^(\s*\S)/'\&' . $1/gme;
$self->makespace;
$self->output (".Vb $lines\n$_.Ve\n");
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
it hard to comment
without retrieving the whole source package and poking around, and I'm not
sure what segfaults you're getting or how they're produced. Is there a
fairly self-contained example that you know is segfaulting that you can
include? I've done varargs conversions befo
e the
package details:
Package: xfonts-jmk
Priority: optional
Section: x11
Installed-Size: 984
Maintainer: Russ Allbery <[EMAIL PROTECTED]>
Architecture: all
Version: 3.0-5
Depends: xutils (>= 4.0.3)
Filename: dists/sid/main/binary-all/x11/xfonts-jmk_3.0-5_all.deb
Size: 515976
MD5sum: de
would be easier to sponsor, I can start on one of them.
I do have a bunch of new packages that I'd like to contribute over time
too, but I figured it would be better to start with adoptions and only add
new packages after I'd helped with the backlog of packages needing a
a new upstream version. I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
grading-checklist.txt.gz works for
> me. Naturally you need the debian-policy package installed for that to
> work...
Having debian-policy installed plus using apt-listchanges is a pretty nice
way of getting notified of new policy releases too. :)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ppreciate any recommendations on dealing with this myself, as I'm
running into this in several packages I'm working on. For the time being,
I've just been ignoring it, but I'm not sure if that's correct.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.o
better answer.
Well, I'm the upstream maintainer of pod2man, so if you can give me
specifics, I can try to get this fixed. Note that there's a much newer
version of pod2man that's awaiting Pod::Simple to be completely ready for
it to be released, and a variety of changes are wait
0 -0700
@@ -517,6 +517,7 @@
my $lines = tr/\n/\n/;
1 while s/^(.*?)(\t+)/$1 . ' ' x (length ($2) * 8 - length ($1) % 8)/me;
s/\\/\\e/g;
+s/-/\\-/g;
s/^(\s*\S)/'\&' . $1/gme;
$self->makespace;
$self->output (".Vb $lines\
it hard to comment
without retrieving the whole source package and poking around, and I'm not
sure what segfaults you're getting or how they're produced. Is there a
fairly self-contained example that you know is segfaulting that you can
include? I've done varargs conversions befo
e the
package details:
Package: xfonts-jmk
Priority: optional
Section: x11
Installed-Size: 984
Maintainer: Russ Allbery <[EMAIL PROTECTED]>
Architecture: all
Version: 3.0-5
Depends: xutils (>= 4.0.3)
Filename: dists/sid/main/binary-all/x11/xfonts-jmk_3.0-5_all.deb
Size: 515976
MD5sum: de
would be easier to sponsor, I can start on one of them.
I do have a bunch of new packages that I'd like to contribute over time
too, but I figured it would be better to start with adoptions and only add
new packages after I'd helped with the backlog of packages needing a
a new upstream version. I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.
--
grading-checklist.txt.gz works for
> me. Naturally you need the debian-policy package installed for that to
> work...
Having debian-policy installed plus using apt-listchanges is a pretty nice
way of getting notified of new policy releases too. :)
--
Russ Allbery ([EMAIL PROTECTED])
modifications.
To do anything else, you have to get permission from DJB, although he's
stated elsewhere that he doesn't think copyright law can prohibit the
distribution of patches or your application of patches to software you're
building yourself. (Note that doesn't include d
> debian-mentors, but I can't find it, nor remember the conclusion.)
I would, yes, just to make sure that the files you distribute can be
regenerated from the package. You should be able to do this by running
latex and pdflatex on the .dtx file.
--
Russ Allbery ([EMAIL PROTECTED])
them, but that shouldn't be questionable.
I thought the user would only be prompted if the file changed *and* they
had made local modifications to the old file. The last is fairly unlikely
for READMEs.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To
to do, any reason Debian doesnt want them there?
If they're really just shell libraries (and hence platform-independent),
they should go into /usr/share rather than /usr/lib per the FHS.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRI
Ben Finney <[EMAIL PROTECTED]> writes:
> On 08-May-2005, Russ Allbery wrote:
>> If they're really just shell libraries (and hence
>> platform-independent), they should go into /usr/share rather than
>> /usr/lib per the FHS.
> Relevant sections of the FHS:
ce, and most of my concern only
applies when maintaining the package rather than NMUing it. The minimal
modifications that one makes in an NMU are hopefully unlikely to result in
other unrelated Policy violations due to forgetting to do something that a
debhelper script might have remembered
at.
The required timeliness depends a lot on what you're using leap seconds
for, and in particular if you need to know about them far in advance, or
if it's only necessary to have an updated table before the leap second
itself arrives.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
n't, by itself, trigger a new release.
So the update would wait for some other time zone change to be rolled into
a release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
those stanzas (the notices are fairly
consistent and open for that sort of automation) rather than asking people
to do tedious and not very productive manual work.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
lieved that this
can be done for MIT-licensed software regardless of whether it's
dual-licensed, since there aren't any license terms that conflict.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...
files are better treated as source, and the
generated files regenerated on every build. This ensures that the files
can still be generated from the source, which in turn ensures that anyone
wanting to make changes to the source package will be able to do so
easily.
--
Russ Allbery (r...@deb
Yavor Doganov writes:
> Russ Allbery wrote:
>> I would still use dh-autoreconf. It's not as critical, since it's
>> unlikely to be necessary for supporting new architectures, but I think
>> the Autoconf and Automake files are better treated as source, and the
&g
stable (in part because upstream development of the projects has
died down a bit again).
> I also wonder why debian/autoreconf is needed given that autoreconf
> is recursive.
I don't think autoreconf can always figure out what to do when the files
are buried in some random subdirect
x27;t
actually want done, and they don't always regenerate everything.
--
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? Conta
. From that
point forward, changes have to be made via bugs filed with ftp.debian.org.
It's possible that Policy could stand some work to make this clearer.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-
debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) writes:
> Russ Allbery writes:
>> I'm pretty sure that default is applied before dak ever sees the binary
>> package priority. (In other words, it's expanded via the build process
>> before priorities are added to the
ent of the man page name from the .TH line, but the name
component is taken from the basename of the source file. So you need to
rename funopen.3 to FunOpen.3, and then it should install in the correct
location.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/&
Ole Streicher writes:
> Russ Allbery writes:
>> This is arguably a bug in te dh_installman documentation. It takes the
>> section component of the man page name from the .TH line, but the name
>> component is taken from the basename of the source file. So you need to
&
just ignore this. That's what I do in similar situations
for my packages.
--
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
Archive: https://lists.debian.org/87k3374r2i@hope.eyrie.org
ke some progress.
+1.
I use help as a sort of variant of wontfix. It means that I'm not opposed
to a fix for that bug, but I'm not going to work on it, either because I
don't have the time or I don't have the necessary skills. Therefore,
unless someone else works on it, it&#
ude ${perl:Depends} in the Depends line in debian/control so
that dh_perl can use it to add the perl dependency. If you're not, you
can leave it out.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@l
people do find this approach too complicated. I guess I'm just used
to it, but it works for me.
--
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". Tro
n upstart configuration, all of the same (simple)
daemon, so it's easy to compare them.
--
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&q
-with systemd and the dh-systemd dependency, since that takes
care of activating your systemd unit file. --parallel is up to you and
depends on whether your package supports parallel build. (It's unrelated
to systemd support.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.
hough (but bugs and requests are probably welcome!).
--
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
Archive: https://lists.debian.org/87tx0xd40q@hope.eyrie.org
pendencies are installed. I think that you can work around this by
having your internal packages use Pre-Depends for the package that
provides your script library (instead of Depends).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE
hey're self-contained in the generated package.
--
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
Archive: https://lists.debian.org/8761cvfjx3@hope.eyrie.org
bly didn't push anything to the
Git repository. Debian packages are not required to use Git, and QA
uploads for orphaned packages often don't.
You can import the changes from 1.10 into the repository using a tool such
as gbp import-dsc from the git-buildpackage package. That's wha
looks like
patchelf can do that (in the patchelf package):
$ patchelf --remove-needed libraw1394.so.8 /path/to/binary
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "
u *really* want to provide an HTML version for some reason,
multimarkdown < README.org > README.html does a pretty good job (probably
redirecting it to some path under the staging area for building the new
package).
BTW, are you sure that this is in Markdown? org-mode is something else
that i
w include the debian/copyright file from
> gnu-efi in the syslinux-efi binary package?
Yes, or at least the portions relevant to the code that's being statically
linked. The resulting binary is a derivative work of the syslinux-efi
package, so you need to follow its license.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise writes:
> Personally, I feel this change to policy is a mistake.
Alternative proposals that achieve the goal of not adding Built-Using
fields to the entire archive are welcome.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rom the included package into the including binary
> package somewhere in /usr/share/doc/$package. While it will waste some
> space (and duplicate files), it will also make sure that we correctly
> follow any copyright changes without requiring the package maintainers
> to manu
use +pristine).
We don't have great or consistent naming conventions for this stuff.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ian.org/cgi-bin/bugreport.cgi?bug=658333
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
If you install dgit and then run man dgit-user, hopefully that should get
you started.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
helper tool, please use an empty override target.
Please note that the dh_installsystemd tool has a slightly
different behaviour in some cases (e.g. when using the
--name parameter).
You may want to read the dh_installsystemd(1) man page to see if any of
the changes af
Usually it's not worth the effort to diverge too far from upstream in
trying to maintain backward compatibility. If upstream has decided not to
maintain that compatibility, trying to do it ourselves in Debian is rarely
a good use of scarce resources. That sometimes means package-breaking
transit
Andrius Merkys writes:
> On 09/06/2018 07:12 AM, Russ Allbery wrote:
>> As part of that transition, it looks like exactly what you said
>> ("adaptation and rebuilding of all packages depending on blacs-mpi")
>> was done for the packages in Debian.
> many tha
Debian for working with non-free
software.
This sort of upstream repackager, if it itself is released under a free
software license, is in general acceptable for contrib if someone is
willing to sponsor it. (I haven't looked at the details of this specific
package.)
--
Russ Allbery
t notices just want us to
preserve whatever notice upstream decided to write.
There's generally no useful purpose served in trying to improve upstream's
copyright notices or make them more accurate, and it arguably can be a
technical violation of some licenses that require preserving copyright
notices.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
tream breaks that guarantee and the SONAMEs diverge.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion "for".
It *is* possible to have a legitimate and grammatical use of the phrase
"to allow" by saying something like "This program is designed to allow for
a variety of uses," but it's not as common of phrasing for a package
description, and it's usually a pretty indirect and unusual way of
phrasing things.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
"Thomas Schmitt" writes:
> Russ Allbery wrote:
>> That intransitive form of allow is almost always used
>> in combination with the preposition "for".
> But why then isn't the lintian check called
> "allows to allows for" or "allow
ided' packages
>are held back.
I think you need Replaces. See:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
601 - 700 of 707 matches
Mail list logo
