Issue persists in
Version: 1.28.17-3 (Debian 12 bookworm)
Package: cups-filters
Version: 1.28.7-1+deb11u1
Severity: normal
Dear Maintainer,
usr/lib/cups/backend/cups-brf has permissions set at 700. It "should" be
universally readable as per
https://www.debian.org/doc/debian-policy/ch-files.html#permissions-and-owners.
Likewise, usr/lib/cups/backend
As noted in the error message itself: "This error originates from a
subprocess, and is likely not a problem with pip."
Should the bug be filed against libpython3.10-stdlib since the infinite
loop seems to occur within the logic of
/usr/lib/python3.10/_distutils_system_mod.py?
Perhaps this feature request has been resolved since the time it was
submitted?
For me, "sudo -u " does do username completion.
Moreover, "sudo -u user " does do command completion, including
commands in (/usr)/sbin which are not included in the bash-completion
PATH for my normal (non-privileged)
Regarding the patch proposed by Bolesław Tokarski
(logrotate-dest-file-exists(2).patch) , I would not want logrotate to
delete a zero-size log file that it happens to find on the system. An
empty log file could be telling you something very important!
However, if logrotate runs into an error which
OK so, after learning more, dpkg-divert doesn't seem to be the
solution for this type of situation where a maintainer script wants to
modify one of its own files.
Next question, then: can /var/lib/xine/xine.desktop simply be excluded
from xine-ui.md5sums? I couldn't find any policy about whic
Same problem here as OP.
> Finally... is Renameuser the only affected extension?
Here is my attempt to find matching filenames between the two packages:
$ /bin/grep -f <(for x in `dpkg -L mediawiki-extensions-base | /bin/grep
php` ; do echo "/"`basename $x` ; done) <(dpkg -L mediawiki)
/usr/
I'm not a package maintainer, but isn't this just the sort of thing
that dpkg-divert is for?
Tiger (at least the Debian package version), for example, is
"dpkg-divert aware" when it goes around checking md5sums, so even if a
file has been dpkg-diverted the checksum test is still able to verif
As implied in the original report, the forked version of rinse at
http://gitorious.org/rinse is much more up to date.
Rinse 2.0.1-1 (as contained in both wheezy and sid) only goes up to
Fedora 10, whereas the fork handles Fedora releases up to 18.
Nathan O' Sullivan appears to be actively maintaini
I'm having the same problem in Wheezy with kernel 3.9-0.bpo.1-amd64. I
keep getting the following error message in cron logs:
/usr/lib/tiger/scripts/check_known: 129: [: Illegal number: 9-0
There are a couple issues with this line (check_known:129):
1) As the comment in the script precedi
Russ,
OK, I'm tracking with you now. I'm sorry for my own misunderstanding.
I was getting the impression that my request to document the
"non-compliant status quo" was going to be relegated to a "wish" that
would most likely be utterly ignored, and that didn't seem right. Having
open issues, but
Under #652011, presumably with reference to my proposed addition to
policy here, Russ Allbery wrote:
> Policy already says what you want it to say currently,
Where? If policy is already clear on this, then this bug should be
closed rather than wishlisted. On the other hand, if policy is not c
Russ,
Not only is your new title for this bug a different (though related)
issue from the original bug report, the new title is in fact
contradictory to, and incompatible with, the problem that the original
bug was addressing. I am using 8G in /usr and the entire root partition
is 2G. If the sep
Some addition to Debian policy such as the one suggested here would,
in my opinion, close bug #652011 which I filed in December.
-Zach
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: debian-policy
Version: 3.9.1.0
Severity: normal
Tags: patch
Proposed additional bullet point to 9.1.1 regarding Debian exceptions to
FHS:
* The FHS language of "essential" vs. "non-essential" binaries and
libraries is
local system dependent, and cannot be well defined at the distribution
I would propose:
1) /bin vs. /usr/bin (likewise for sbin) is both subjective and
context dependent. It is subjective because it may be *possible* to do
certain essential tasks with a certain minimal set of tools, but far
*easier* or *preferable* to get them done with a larger set. The ability
to
After some time, I've recently gotten back to tackling the FHS dynamic
library dependency issue for separate root and usr partitions.
Testing release 0.1.3 of my FHS-utils package is available at
git://everythingwiki.sytes.net/fhs-utils. It currently consists of three
commands:
fhscheck -
Package: gpgsm
Version: 2.0.14-2
Severity: important
The package gpgsm should depend on (or at the very least recommend) the
package
dirmngr.
-- System Information:
Debian Release: 6.0.5
APT prefers stable
APT policy: (700, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Ke
Ok, ok, ok, I think I may have got it. Some of your comments helped
get me on the proper track of distro-oriented thinking where different
systems are picking and choosing a different subset of available
packages, but those packages have predefined locations where they have
to put things. It has
On 12/14/2011 04:43 PM, J.A. Bezemer wrote:
>
> On Wed, 14 Dec 2011, Roger Leigh wrote:
>
> [..]
>> The same argument applies to encryption. / and /usr both contain a
>> selection of programs, libraries etc. If you're encrypting one, why
>> would you not encrypt all of it?
>
> Speed.
>
> On one o
Wow, if this sort of bug report is re-evoking questions on the whole
relevance of the historical FHS to modern distros, it does seem that
some real "soul searching" is in order on the part of the community as
far as the future of where people see Debian/GNU/Linux headed. "Begin
with the end in m
Package: general
Severity: serious
Justification: Policy 10.1.1
My understanding of the FHS would be that if a library is a dependency of a
binary in /bin or /sbin, then such library belongs in /lib, not
/usr/lib. (If
for some reason the library is also desired in /usr/lib then a sym link from
/li
22 matches
Mail list logo
