s must use ``update-rc.d`` as described below to
> +interact with the service manage for requests such as enabling or
> +disabling services. They should use ``invoke-rc.d`` as described below
> +to invoke initscripts for requests such as starting and stopping
> +service.
>
> .. _s-writing-init:
>
> --
> 2.23.0
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar writes:
> Russ Allbery writes:
>> I'm hesitant to remove all discussion of run levels because package
>> maintainers are still responsible for choosing a run level at which to
>> start their service and providing that run level as an argument to
>> update-rc.d
uments only the already-in-use path
syntax. (We're probably overdue for introducing ABNF into Policy so that
we can properly specify the syntax of things, but I didn't attempt to do
that here.)
Author: Russ Allbery
Date: Wed Oct 23 13:56:06 2019
Add support for paths in Vcs-Git
ont remember the old Packaging Manual, so
> I think this paragraph can safely be dropped.
Agreed and done for the next release.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ts and the service
could not or should not be started, it should produce an appropriate
error message and exit with a non-zero status.
and then moving this whole paragraph into 9.3.2, probably as the
second-to-last paragraph?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
by this is xfonts-jmk.
Felix Lechner writes:
> On Sat, Aug 10, 2019 at 4:51 PM Russ Allbery wrote:
>> I don't think there was anything specific to git-buildpackage there.
> Isn't the whole problem specific to git-buildpackage?
No, the root problem, and the reason why the Lintian tag e
Control: tags -1 pending
Russ Allbery writes:
> Stephen Kitt writes:
>> Is the following suitable?
> Yup, this looks great. Seconded. Once this gets one more second, we'll
> apply it.
And now applied for the next release.
--
Russ Allbery (r...@debian.org)
retrieve fonts from the local file
> + system or over the network from an X font server, so packages were
> + forbidden from declaring a Depends relationship with font
> + packages. This is no longer the case: the X font server shipped in
> + Debian no longer supports remote font
hing compatible with groff and start using more groff-specific logic
(such as assuming that the formatter can handle Unicode output).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nk you for raising this, Stephen! I use remote display of X
applications all the time and noticed a while back that fonts were being
loaded on the local machine instead of on the machine hosting the X
server, but never had a chance to dig into what had changed.
This change looks right to me as wel
Dmitry Bogatov writes:
> Does it mean that lack of systemd unit file is RC-critical bug?
No, it would be a should. So just a regular bug.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bill Allombert writes:
> On Sat, Sep 28, 2019 at 06:02:52PM -0700, Russ Allbery wrote:
>> I agree. This seems entirely reasonable to me. Both the behavior and
>> the inherent documentation are better with unit files, and systemd is
>> the default init system so that's a
d to separate patterns, cannot be
> +escaped with a backslash. A path like "foo bar" may be
> +selected with a pattern like "foo?bar".
> +
>
>
>
Seconded, thanks.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.
That said, if anyone does object to this, please do speak up and explain
why this would be a problem.
--
Russ Allbery (r...@debian.org)
had gone away once I added a file to
that directory in the packaging, I would have been quite happy with the
tag and its recommendation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
it other than
what I already did. Surely this isn't important enough to warrant
repacking the upstream tarball and thus breaking verifiable provenance?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a
variant of Markdown with table and definition list support, which can be a
bit hard to find.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
on a lighter-weight machine than Firefox requires. And it's possible that
multi-core may be a reasonable requirement for that "heavy package" tier.
If we do go down that path, though, it would be nice to add a metadata
field so that maintainers can flag their packages as being "h
the results.
Given that, I would argue against having a Lintian tag at all, or at most
making it pedantic.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
onal complexity of in-field key/value pairs.
Yeah, this is a pretty good point, and it decreases the complexity of the
syntax a fair bit. Ian, what do you think about making the extensibility
model for any future thing be add another field?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
already almost have that, though it's fussy
> to set up sparse checkout to do it and you still have to "cd" into the
> subdirectory).
Being able to clone a subdirectory of a Git repository would be lovely,
speaking as someone who works at a company that insists on using a
monorepo. I t
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
>> info in .dsc [and 1 more messages]"
we have a few too many
different ad hoc parsers and novel grammars in Debian), but I think it's
unavoidable at this point without breaking backward compatibility in ways
that aren't worth it.
So, looks good to me. Next step is for someone to get a chance to write
the language. (I'll tag the bug accordingly.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
allows the tagger field to be defined has having the same syntax
as Maintainer (or one of the other existing RFC-2822-style fields we
have), which I think increases the chances that parsers will get this
right.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ian Jackson writes:
> Russ Allbery writes:
>> Sure, an extensible syntax sounds great. The problem is that we kind
>> of had one (Vcs-Git was a subset of a git checkout command line, which
>> allowed support of the -b option), but this (if I understand it
>> cor
https URL to the Git
repository itself. Subversion was closer to getting this right, although
made easier by Subversion's repository structure.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
this for unstable and will see about getting a targeted fix into
stable as well, although it won't go out, at best, until the next point
release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
directory at any time, or may choose to put it on an ephemeral
filesystem, although after such deletion programs may stop working
until the next system reboot.
I'm still not very happy with this language. Any other suggestions
welcome.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
There are no guarantees provided by the ``/var/reboot-required``
> +convention as to when or whether the requested reboot will occur.
This looks good to me as well. Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
erminated
> I got the same result on two different machines, over Wayland and X11.
I can't reproduce this.
Can you enable core dumps (ulimit -c unlimited) and then run gdb on the
corresponding core dump (gdb /usr/games/gnubg core) and then run backtrace
and show the backtrace for this?
--
Russ All
rsion control
+systems, the maintainer should specify the one that they would prefer
+other people to use as the basis for proposing changes to the package.
For both fields, any URLs given should use a scheme that provides
confidentiality (``https``, for example, rather than ``http`` or ``git``)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a scheme that provides
confidentiality (``https``, for example, rather than ``http`` or ``git``)
I think one could argue that the above change is informative, given that
Policy already says "A paragraph must not contain more than one instance
of a particular field name" in Policy 5.1.
I'm sure there's some good way to do
this with standard tools, but I don't know off-hand how to do it.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
; +presenting documentation. Debian packages that provides online
> +documentation (other than just manual pages) may register these
> +documents with doc-base by installing a doc-base control file in
> +``/usr/share/doc-base/``.
>
> Please refer to the documentation that comes
Felix Lechner writes:
> On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery wrote:
>> The name of the files and directories installed by binary packages
>> outside the system PATH must be encoded in UTF-8 and should be
>> restricted to ASCII when it is possible to do
(namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be
encoded in ASCII.
The name of the files and directories installed by binary packages
outside the system PATH must be encoded in UTF-8 and should be
restricted to ASCII when it is possible to do so.
--
Russ A
, ``binary``, ``binary-arch``,
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
quot;starting point for the content
> of d/rules" and say something like "this starting point is often
> sufficient to build a package satisfying most of the requirements below
> (and many others), and where it is not, package-specific instructions
> are usually expressed using override targets" ?
That sounds great to me. I'll make that change in my draft.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bill Allombert writes:
> On Tue, Jun 18, 2019 at 06:24:45PM -0700, Russ Allbery wrote:
>> The following targets are required and must be implemented by
>> ``debian/rules``: ``clean``, ``binary``, ``binary-arch``,
>> -``binary-indep``, ``build``, ``build-arc
. (When
+using ``dh``, these are implemented using the wildcard pattern shown
+above.) These are the targets called by ``dpkg-buildpackage``.
Since an interactive ``debian/rules`` script makes it impossible to
auto-compile that package and also makes it hard for other people to
--
nel
errors like:
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo
underrun on pipe B
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO
underrun
and then lots and lots of:
[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle
patterns
--
esn't appear to be a Debian bug for this; it
might be a good idea to open one against light-locker (or, if you confirm
switching to slick-greeter per that bug, lightdm-gtk-greeter).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
tifications.
I did some research on that a while back and ended up not filing a bug
about it because it looked relatively pointless. It appeared to be a deep
design choice on both sides, and not something anyone was likely to solve,
so I just switched to a desktop-aware locker.
--
Russ Allbery (
Georg Faerber writes:
> On 19-06-01 11:04:28, Russ Allbery wrote:
>> I did some research on that a while back and ended up not filing a bug
>> about it because it looked relatively pointless. It appeared to be a
>> deep design choice on both sides, and not someth
eze
exception.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
t.
> https://lwn.net/Articles/664800/
The work is actively underway in both the kernel and in glibc, but I don't
think it's fully working in buster. I would expect it to be there by the
next Debian release, though.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Mike Miller writes:
> On Mon, Jun 19, 2017 at 09:07:44 -0700, Russ Allbery wrote:
>> After upgrading network-manager to 1.8.0-5 from 1.6.2-3, connecting to
>> a VPN with network-manager-openconnect still works but doesn't set up
>> the routing table entries properly. (This
Control: tag -1 -moreinfo
Jonathan Wiltshire writes:
> On Sat, Mar 09, 2019 at 12:44:59PM -0800, Russ Allbery wrote:
>> * Upload 1.02-1 to unstable and have you unblock that for propagation to
>> testing as a regular package update? This is a leaf package, so I'm
>&g
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
This is an unblock request for a package I've not yet uploaded, since I
wanted to get your guidance on how you'd prefer to get this update.
On March 15th, the Duo API is changing to
Package: libnet-duo-perl
Version: 1.01-2
Severity: important
Tags: upstream
(Arguably this could be grave, although it only affects the admin APIs
and not the more-common auth API.)
As of March 15th, pagination will be required by Duo Security for some
admin APIs. The affected APIs implemented
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 (r...@debi
Package: ftp.debian.org
Severity: normal
rssh has been orphaned upstream and has had a chain of security
vulnerabilities in stable that indicate that its security model
is fundamentally unsound. Attempting to do whitelist filtering of
the arguments of various programs to protect against them
ries
changes in the future.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the host may not be using systemd). We don't have good helpers for this
yet, so it requires some careful thought to make this work properly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that
could mostly be cleaned up by debhelper), and is also a pretty significant
break with past practice that will probably break some system out there in
some way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
lities, and I suspect there are a lot more that we just haven't
found yet. You're therefore unfortunately going to have to start thinking
about a migration plan, although I'm going to try to keep it limping
along for the lifetime of stable.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ermissions.
You need to either run dpkg-reconfigure rssh and respond to the debconf
prompt saying that you want it to be setuid, or you need to use
dpkg-statoverride.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: rssh
Version: 2.3.4-8
Severity: grave
Tags: security upstream
https://sourceforge.net/p/rssh/mailman/message/36519118/ is the upstream
report. The reporter indicated they asked for a CVE but didn't include it
in the message.
scp allows remote code execution inside the server
te loop during byte-compilation does make it feel like there may
be some underlying but in Emacs as well, since that doesn't feel like
something that should be possible, but it may not be detectable or
avoidable depending on what the cause was.)
--
Russ Allbery (r...@debian.org) &l
Submitted upstream as https://github.com/manwar/Test-Strict/issues/26.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: libtest-strict-perl
Version: 0.47-1
Severity: normal
Test::Strict::all_perl_files_ok contains hard-coded logic to exclude
CVS and .svn directories, but doesn't skip .git directories. It does
provide a way to pass in a list of files to skip, but that is applied
as a filter to the list of
Package: perltidy
Version: 20180220-1
Severity: normal
Upstream has released 20181120, which improves perltidy's ability to
detect consecutive variable assignments that should be aligned. This
unfortunately means that there is some code that passes with 20180220
and fails with 20181120 which,
d go a long way to making
this data more useful.
Does anyone reading the Policy list know of anything that would *break* if
we converted the virtual package list to a structured form? I think it's
likely we'll accept this if not, so this is a call for any issues that I'm
not thinking of.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
That is,
> +dpkg's vendor-specific patch series feature should not be used for
> +packages in the Debian archive.
> +
> 10.1
> Binaries should be stripped using
> ``strip --strip-unneeded --remove-section=.comment
> --remove-section=.note``
Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Sean Whitton writes:
> On Fri 09 Nov 2018 at 05:39PM -0800, Russ Allbery wrote:
>> Thank you! Seconded.
> This change seems to be purely informative; could you say why you think
> it needs seconding, please?
Oh, sorry, I didn't even double-check whether there was normative
lang
u! Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
won't start bothering for this.
Maybe https://wiki.debian.org/UpstreamGuide would be a better place for
this? Currently, it doesn't even explicitly recommend that upstream
provide man pages.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Santiago Vila writes:
> On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:
>> In a way, I don't think this goes far enough. Build-Conflicting with
>> something installed by debhelper would be incredibly painful and would
>> basically require the package be buil
ixed in the package, not worked around by adding Build-Conflicts
against an incredibly commonly-installed package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
lar, the required targets must not attempt to
> +write into ``HOME``.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
to read):
I believe this matches the new ftp-master statement, and they're canonical
for this part of Policy, so seconded. Thank you for writing this up as a
diff!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s, including the ones
implemented by other tools, but at the same time nearly everyone doing
Debian packaging is using debhelper (either directly or indirectly), so
it's a bit of a disservice to people to ask them to wade through a bunch
of specifications for stuff that normally they don't and shouldn't t
be
worth pointing out that data such as what you show above is probably not
copyrightable under at least US law (and I think that exception is fairly
common internationally). It therefore probably isn't meaningfully under
any license, although including the Unicode Data License in the package
doesn't hurt
y here; the intent is only
to cover unit files that are equivalent to init scripts, and none of those
things are. I certainly support fixing that to make it clearer.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
fair point, and I think we could certainly change the wording
here to reflect that it's unreasonable to expect 100% equivalent
functionality; there are features that sysvinit simply doesn't support,
for instance.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
could leverage doc-base files better to make documentation more easily
> discoverable. That is work-in-progress.
That sort of thing would be really cool.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s. So, this is expected; could you provide some more information
about what broke? (Error messages, etc.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
are
in the fonts section. If ftp-master had wanted them in a different
section, that's entirely under their control, and they could have just
made that change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
info enabled if you care about this sort of thing. Or
is this about the default view in the package tracker?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
l the things we
think are reasonably fixable."
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jeremy Bicha writes:
> On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery wrote:
>> Maybe exclude shared libraries linked with glib (and whatever the Qt
>> equivalent is)?
> One package that triggers this tag a lot is samba and it doesn't use
> glib or qt.
> https://linti
assuming the NEEDED metadata is erroneously missing even though the
library has undefined symbols, as opposed to a shared library that really
doesn't need other libraries.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s, and Stanford because we couldn't create enough accounts for all of
our users without using this space.
This space is also often used for uidmap for containers. It's typical to
have a single container user get a full 16-bit UID space that gets mapped
to an equivalent range somewhere in the >2^16 space of the containing
system.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
gnome_shell.json
Splitting that single config file into a separate contrib package feels
like overkill here. It shouldn't hurt anything on a system without Chrome
and it doesn't create any sort of dependency on Chrome, which is the
normal case for contrib.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Lefevre writes:
> On 2018-09-11 15:29:02 -0700, Russ Allbery wrote:
>> Vincent Lefevre writes:
>>> This would mean that a breakage is possible after any patch (in
>>> particular with those "Update to SVN..." in the changelog). Thus this
>>
the one used to build the kernel. For
> sid, GCC is often not in sync with the one used to build the
> kernel. This is a really big problem.
I don't think it's an NVIDIA-specific problem, though, right? Doesn't
this happen with any kernel module build? Or am I confused and this is an
NVID
tisfiable dependency since the compiler packages aren't
broken apart that way.)
> If the minor version really matters, why Debian doesn't ship different
> packages, such as gcc-6.3 and gcc-6.4?
I suspect that usually only the kernel is affected.
--
Russ Allbery (r...@debian.org)
Control: severity -1 grave
Russ Allbery writes:
> After upgrading from 9.1.14+dfsg-1 to 9.1.14+dfsg-2, org-mode stopped
> loading correctly. Attempting to open a file with the .org extension
> produced the error:
On second thought, this should probably be RC to prevent migration t
Package: elpa-org
Version: 9.1.14+dfsg-2
Severity: important
After upgrading from 9.1.14+dfsg-1 to 9.1.14+dfsg-2, org-mode stopped loading
correctly. Attempting to open a file with the .org extension produced the
error:
WARNING: No org-loaddefs.el file could be found from where org.el is
re,
since my package uses the same section as the archive uses in
debian/control. (Well, I could have made the change in Lintian... one of
these days I'll get back to doing that.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
doing based on the sections of
what's in the archive now, and they're canonical for sections (not the
packages pages on www.debian.org).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
bian.tar.xz
dpkg-source: info: applying debian-changes
gwaihir:~/tmp$ ls -al xfonts-jmk-3.0/neep/ascii
total 4
drwxr-xr-x 1 eagle eagle 24 Sep 5 15:46 ./
drwxr-xr-x 1 eagle eagle 292 Sep 5 15:46 ../
-rw-r--r-- 1 eagle eagle 341 Sep 5 15:46 .placeholder
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ven the entire RFC 5322
header field (and then fix it to do the right thing in that case), given
the line length limits.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
eld and then separately
adding the header field name. This happens to accidentally work if the
encoding reproduces pure ASCII words in the output text without encoding
them, but it's technically incorrect because it's not valid in the email
format to encode the header field name using RFC 2047 enc
a custom script with the ssh authorized_keys forced command
> feature, as in:
> https://joeyh.name/blog/entry/locking_down_ssh_authorized_keys/
Yeah, given the state of upstream development of rssh, I suspect those may
be more workable options. Sorry about that!
--
Russ All
some
love and attention, including incorporating more backend programs and
making it more extensible. I unfortunately don't have the time to do
that; I personally only use it for rsync, so it does the one thing I want
from it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
>> section when a package could fall into multiple sections.
> Sounds good to me.
>
>> (I'm not sure where to report the packages.debian.org bug. Do you know?)
> Against the "www.debian.org" pseudo-package.
Thanks, filed as #907782.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: www.debian.org
Severity: minor
Lintian bugs #907725 and #878609 were due to some confusion because the
section documentation at https://packages.debian.org/en/sid/ says both:
X Window System software
X servers, libraries, fonts, window managers, terminal emulators and
many related
Package: lintian
Version: 2.5.99
Severity: minor
On a personal package of a documentation tool (not in Debian yet):
I: docknot: package-contains-documentation-outside-usr-share-doc
usr/share/perl5/auto/share/module/App-DocKnot/templates/readme-md.tmpl
I: docknot:
Package: lintian
Version: 2.5.99
Severity: minor
xfonts-jmk 3.0-22 (just now uploaded to the archive) receives the tag:
P: xfonts-jmk source: source-contains-empty-directory neep/ascii/
but a patch in the quilt series adds a file to that directory. I believe
this addresses the concerns
401 - 500 of 6053 matches
Mail list logo
