Hi,
please break the lines, as is customary, do not use overlong lines.
I also believe you are confusing packages with executables. Packages
do not have manual pages, executables do. Packages oftentimes *do*
have instructions in /usr/share/doc/. This also means that the second
sentence (missing a
On Thu, 30 Nov 2017, Sean Whitton wrote:
> wanna-build team / Release Team / Backports Team: exactly which buildds
> ignore alternative dependencies? We want to include this in an
> (existing) Policy footnote.
Good idea.
For porter uploads, some people (including me) use cowbuilder,
which uses
On Sat, 7 Jul 2018, root wrote:
> * Policy: Update version of POSIX standard for shell scripts
I wonder why the maintainers of the shell packages providing
a suitable /bin/sh were not contacted regarding this. We could
have provided input.
(tl;dr: Debian’s sh-suitable shells follow POSIX more
On Wed, 29 Aug 2018, root wrote:
> debian-policy (4.2.1.0) unstable; urgency=medium
> * Fix inconsistent wording in 4.9 by dropping the word 'maximally'
> (Closes: #905251).
> Thanks to several people who pointed out this issue, both in the BTS
> and in person.
> -- Sean Whitton
On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote:
> "You have to forward these bug reports to the upstream developers so that they
> can be fixed in a future upstream release."
>
> That's not the current/best practice for a number of packages, either because
> of the sheer volume of bug reports/size o
Hello Moritz,
> On Thu, Sep 06, 2018 at 11:29:52PM +0200, Thorsten Glaser wrote:
> > I’m trying to be constructive here, but in the end, I still
> > think that this was something package maintainers (at least
> > DDs) have read beforehand and signed up for, so there’s no
>
Hi Wouter,
> I agree that it's perfectly fine for a maintainer to say "this is an
> upstream bug, please report it upstream", which the current text
> doesn't allow for.
In theory, I could agree to that, were it not for a number of
points I outlined earlier:
• the variety of upstream bug tracker
On Fri, 7 Sep 2018, Ian Jackson wrote:
> I think it is usually better if the Debian maintainer can do this.
> I would like to encourage maintainers do do it. But I really don't
> think we can make this mandatory.
Uhm… it’s been mandatory the last couple of years.
> It's all very well to say tha
Short answer (slightly drunk and short on time), more later:
On Fri, 7 Sep 2018, Ian Jackson wrote:
> In some packages this will not be possible at least for some bug
> reports. You've seen the poor quality and hard-to-follow-up bug
[…]
Yes, but that does not mean we should make it permitted by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Sean Whitton dixit:
>2.3 & 4.5
>In cases where a package's distribution license explicitly permits
>its copyright information to be excluded from distributions of
>binaries built from the source, a verbatim copy of the package's
>cop
Package: debian-policy
Version: 4.3.0.3
Severity: normal
Hi,
Policy 4.3.0.3 §9.3.2 reads:
force-reload
cause the configuration to be reloaded if the service supports
this, ot
Ian Jackson dixit:
>The problem is that `3.0 (quilt)' has both advantages (eg that
>`nativeness' is declared explicitly) and disadvantages (patches stored
Not necessarily:
| $ cat rs/debian/source/local-options
|single-debian-patch
| $ cat rs/debian/source/local-patch-header
|Please review chang
Russ Allbery dixit:
>local-options means that the maintainer sees a very different view of the
>package than any other consumer on the package via the archive. Not only
Right, but the packaging workflow is the same (and since there is only
one quilt patch, the view other developers have pretty m
Aurelien Jarno dixit:
>Doing so means that the locales or locales-all package will be installed
Hm, localedef is in libc-bin – can C.UTF-8 not be generated
by its postinst (with some logic in locales-all to restore
C.UTF-8 in its postrm)?
bye,
//mirabilos
--
“Having a smoking section in a res
Hi,
with the latest developer news I saw mksh was listed. However, mksh
needs to have dependencies on "debconf ($foo) | cdebconf ($bar)" in
two flavours – one is added so lintian doesn’t complain due to mi-
nimum version requirements for certain features, the other is added
via misc:Depends from d
Russ Allbery dixit:
>that clearly, but I'm quite confident that's the intention.
Yes, thought so. However I was surprised to see it pop up in
the list, and perhaps other packages are similarly affected,
maybe not even this visible.
So what now? Does ftpteam read here or do I contact them, and
po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Guillem Jover dixit…
> : ~ (full stop, plus, hyphen, colon,
> - tilde) and should start with a digit. If there is no
> + tilde) and must start with a digit. If there is no
> debian_revisi
On Mon, 4 Apr 2011, Carsten Hey wrote:
> upstream_version git1234 could be prefixed with epoch 0 and thus lead to
> the version number 0:git1234-debian_revision. Maybe this could be
Nah. Just drop the leading 'git'.
On Mon, 4 Apr 2011, Raphael Hertzog wrote:
> We have no upstream with such ve
Hi all,
I think pbuilder’s strict interpretation is correct, especially
as the wording of Policy (and RFC822) don’t provide for an empty
line before the “first” paragraph, and think we should re-enforce
that (literal) reading of Policy and have the packages be fixed
and a check added to lintian in
Jakub Wilk dixit:
> * Colin Watson , 2012-11-25, 15:53:
Nothing in policy forbids using -j if parallel *isn't* set; it only
specifies behaviour when parallel is set.
>>> Hmm. Not in the wording, but that’s why I said that’s my reading.
>> To clarify, I think this would be a reasonable th
Sune Vuorela dixit:
>The handling of built-using is wrong. It is not meant to encode the
>compiler used, nor binutils or kernel headers should be recorded there
Policy 3.9.4 §7.8 says:
Some binary packages incorporate parts of other packages when built
but do not have to depend on thos
Russ Allbery dixit:
>In the meantime, please don't add Built-Using for libgcc. The libgcc
>license does not require it, due to the runtime exception, and essentially
The dietlibc licence does require for libgcc to be added there
(GPL without exception clause).
bye,
//mirabilos
--
> Hi, does an
Russ Allbery dixit:
>> The dietlibc licence does require for libgcc to be added there
>> (GPL without exception clause).
>
>I think you mean that dietlibc requires that *dietlibc* be added, right?
No, I meant it like that.
>If not, I'm confused. I don't see any reason why dietlibc's license wou
Russ Allbery dixit:
>If this license analysis is correct, then we have to do this for every
>binary on the system that's covered by the GPL v2, since I believe some
Hmm.
>stub code from libgcc is *always* included statically in every binary,
>even if the binary is built dynamically. (Or at leas
tl;dr: last paragraph.
Dixi quod…
>Russ Allbery dixit:
>
>>If this license analysis is correct, then we have to do this for every
>>binary on the system that's covered by the GPL v2, since I believe some
[…]
>The csu are included, and TTBOMK some of it comes from GCC
>and some from the libc in q
Russ Allbery dixit:
>debian-legal isn't really the correct venue. It's just a discussion list
Ah, okay.
>going to start with leader and see if Lucas has an opinion about where to
>start with making decisions here. One option available to leader is to
>ask for an opinion from external legal cou
Russ Allbery dixit:
>At the time, though, the assumption was that Built-Using would be a fairly
>rare thing that would only be used for those few score packages that were
>Build-Depending on *-source packages.
And statically linked executables, since that made it into the
Policy wording; or possi
Russ Allbery dixit:
>If we do need to preserve source for the libcc and libc components
>incorporated into binary builds, that's going to mean Built-Using for
>nearly the whole archive, and a lot of complexity on the DAK side. That's
>obviously not very desirable. We would rather decide that we
Russ Allbery dixit:
>of the GPLv2, the GPLv2 itself requires that all of the *source* for the
>binary be distributed under the GPLv2. And the libgcc *source* is only
>available under the GPLv3, and the runtime exception doesn't allow one to
>distribute the *source* under different terms, only the
Russ Allbery dixit:
>Thorsten Glaser writes:
>> If not… well, since snapshot.d.o is an official service now, I’d say,
[…]
>Hm, that's an interesting point, indeed.
>> Are those source packages (that would not otherwise be kept in the
>> archive) released along wit
On Wed, 18 Mar 2015, Bill Allombert wrote:
> On Wed, Mar 18, 2015 at 12:48:13PM +0100, Holger Levsen wrote:
> > buildd.debian.org uses
> >
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Urgh! /usr/local in package builds?
It’s unquestionable it should be set li
Package: debian-policy
Version: 3.8.1.0
Severity: wishlist
For the mksh regression tests, I need a UTF-8 locale working; most
systems either provide “en_US.UTF-8” or “en_US.utf8” with the former
being recommended.
Build-depending on locales-all has worked for me so far, except it
won’t do in Kubu
Giacomo A. Catenazzi dixit:
> If you need a specific locale (as seems from "mksh", not
> sure if it is a bug in that program), you need to set it.
You can only set a locale on a glibc-based system if it’s
installed beforehand, which root needs to do.
> Why does mksh need UTF-8?
The regression t
Bill Allombert dixit:
>What about LC_COLLATE (which is a major problem with sort(1)) ?
1:1, just like the C locale does.
>What about packages that run before /usr is mounted ?
They do not have /usr/*/locale/ anyway. This is a glibc problem.
>What about embedded systems with tight space requir
Adeodato Simó dixit:
>+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +):
>
>> Except the ton which sets LC_ALL=C to get sane (parsable,
>> dependable, historically compatible) output.
>
>> These would then unset all other LC_* and LANG and LANGUAGE,
>> and on
Bill Allombert dixit:
>Fortunately, since Sarge, debian-installer set LANG in
>/etc/environment so programs almost never run under C locale anymore.
Except the ton which sets LC_ALL=C to get sane (parsable,
dependable, historically compatible) output.
These would then unset all other LC_* and LA
Roger Leigh dixit:
>However, I would ideally like the C/POSIX locales to be UTF-8
>by default as on other systems (with a C.ASCII variant if required).
No, this has the potential to break, for example, tr(1).
I lived through that on MirBSD.
//mirabilos
--
“It is inappropriate to require that a
Adeodato Simó dixit:
>I would go as far as suggesting that some package like libc6 itself
FWIW:
-rw-r--r-- 1 tg tg 238336 Apr 7 22:59 en_US.UTF-8/LC_CTYPE
It's not *that* much...
>Finally, this stuff that Roger proposes about making “C” be UTF-8, and
>create some C.ASCII for people needing th
Roger Leigh dixit:
>But, does it not reject non 7-bit input in the C
>locale for completeness?
No, it doesn't - "we" (before my time though, I think) fought
hard for eight-bit transparence and eight-bit cleanliness.
>Should tools doing "raw" I/O not be using lower level interfaces
>such as fread
Roger Leigh dixit:
>Are you sure?
Not entirely, but I recall fgetc (or was it fgetwc?)
being affected.
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
Giacomo A. Catenazzi dixit:
> The locale C is already a UTF-8 compatible locale.
It is UTF-8 transparent but that's its pro and con.
It does not tell the system that UTF-8 encoding is to be used.
It basically says the encoding is none/unknown.
> Why build need to depend to a locale?
[...]
> For
Giacomo A. Catenazzi dixit:
> This is good way to do things!
Thanks.
> Or a debhelper (or like) utility
> that "construct it" for build needs.
That’s already done, as I said – vorlon gave me an idea, I implemented
it, it works, I uploaded a new mksh package… and then I saw someone’s
added it to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Debian Policy 10.4 states that shell scripts using a /bin/sh shebang
line must conform to POSIX Shell, with a few (listed) exceptions.
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
specifies, under “Command Search and Ex
Oops…
The bug I tried to handle was already archived. The new one is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539158
Sorry for the noise,
//mirabilos
--
23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)
23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mi
Steve Langasek dixit:
>You're aware that [ (test) is also not listed as a mandatory shell built-in,
>according to the POSIX reference you've cited?
Interesting.
>So from that perspective, there are lots of POSIX failures. Do you think we
>should treat [ specially, but not printf, because mksh h
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Steve Langasek dixit:
>Have you looked at this set yet, by chance,
>to see if there are others besides printf that mksh doesn't share with dash
Here they are:
Builtins in mksh (-current from CVS), but not in dash (source from sid):
* bind (inte
Albert Cahalan dixit:
>Any imperfection in a locale results in "C", as ASCII as can be.
Yes, and "C" shall not imply latin1 but 7-bit ASCII but 8-bit
transparent.
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty
Albert Cahalan dixit:
>Unless plain "C" goes UTF-8
Not going to happen, it’s not binary-safe. (I fought that in
MirBSD with the OPTU-8/16 encoding scheme.)
>The stupid broken en_US.UTF-8 fucks up the sort order.
So true… (and paper size!)
>We really need a do-nothing locale that follows the Un
Albert Cahalan dixit:
>Giacomo A. Catenazzi writes:
>> I think nobody should use "C" or "C.UTF-8" as user encoding.
I’d use it.
>Debian doesn't ship a proper locale. I want sorting according
>to the raw Unicode values.
Also called ASCIIbetically ☺ But C exists, C.UTF-8 doesn’t.
>>> * All ISO8
Giacomo A. Catenazzi dixit:
>> Not going to happen, it’s not binary-safe. (I fought that in
>> MirBSD with the OPTU-8/16 encoding scheme.)
>
> Why not? Note that usual functions work on bytes
Not really.
The difference between 'tr u x' on binary files can, depending on
the implementation of tr (
Russ Allbery dixit:
>I agree with others in this thread that having a UTF-8 locale without the
>collation changes implied by en_US is very useful for various software
>packages such as automated test suites that want reproducible results and
>were originally written for the C locale.
Same for tes
Samuel Thibault dixit:
>LC_CTYPE has differences between locales, transliterations notably. For
Oh, okay – good to know…
>I'd say go on :)
OK.
>(of course we'll need to wait for libc to provide the locale
>(post-squeeze I guess) before changing the policy).
Sure. Maybe think of something to
Samuel Thibault dixit:
>believe that's something that shouldn't break Squeeze at all.
I also believe it cannot possibly do that.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referen
On Mon, 5 Jun 2023, Simon McVittie wrote:
>No init system at all, (C.), can only happen when starting with a
>minbase debootstrap or equivalent (because a default debootstrap
>includes the init metapackage due to its Priority: required). In
>this scenario it *usually* doesn't really matter whether
On Tue, 13 Jun 2023, Bill Allombert wrote:
>I agree, chroots are important to consider, and the system should not
>make assumptions how and why there are used.
Thanks!
>Conversely, sometimes I need to use chroots to test init scripts.
>start-stop-daemon should not refuse to run in a chroot if po
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Thorsten Glaser writes:
>
>> Therefore I belive that Policy ought to *not* recommend any solution
>> that depends on starting dæmons or init scripts to create temporary
>> files/directories that are necessary for programs to wor
On Tue, 13 Jun 2023, Russ Allbery wrote:
>namely if you're running anything
>in a chroot that needs directories created in /tmp and /run, the chroot
>either needs to have a persistent /tmp and /run or you have to arrange for
>it to run at least some init scripts during boot.
I very much disagree
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Ah, I think I understand what you're getting at. You're talking about
>using the init script of a daemon as this sort of wrapper script for
Not really. I was talking about normal programs, not dæmons.
I have the expectation that these, when invoked, crea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Helmut Grohne dixit:
>I would like to take the opportunity make you aware of a Debian policy
>change #1074014 about merged-/usr. I mentioned your approach in mksh and
>pax and the consensus among discussion participants was that policy
>should not a
Russ Allbery dixit:
>Thorsten Glaser writes:
>
>> You got your merged /usr already, and to force packages to move their
>> files WILL break users’ systems. In particular, mksh as /bin/sh is a
>> supported configuration.
>
>Could you explain how this would break a us
Helmut Grohne dixit:
>that the way people tend to use mksh is by adding a local diversion for
Unfortunately not.
The way we have to do it since squeeze, when dash unilaterally broke
cross-package coordination, is:
dpkg-reconfigure dash ⇒ remove its owning of /bin/sh
(so it reverts to bash)
ln
(Another data point is that there’s versions of mksh with
version numbers larger than what’s in sid around in my own
repo, for those wanting to follow CVS snapshots more closely,
backported to all versions up to sarge, so bookworm users
can very well have mksh packages with a version number that
is
Helmut Grohne dixit:
>> Maybe the protective diversions also protect against this problem as well
>> as the problem of moved files? I unfortunately failed to spot where the
>> protective diversions were added in dh_movetouser (if that even is the
>> right place to be looking), so I'm fairly sure
On Fri, 14 Feb 2025, Sean Whitton wrote:
>Policy has to go through binary-NEW in order to be released. So there
Technicalities.
>isn't a quick fix here.
Not looking for one. dpkg should revert this until then.
>This bug does not count as RC just because Debian upload bureaucracy
>hasn't been
severity 1095791 serious
thanks
On Thu, 13 Feb 2025, Guillem Jover wrote:
>> >From what I can tell from other mails, I believe the package in
>> question is openjdk-8 (unstable only); see bug #1095746.
>
>Ah, thanks for the context. In that case, going by that bug report, it
>looks like openjdk-8
On Fri, 14 Feb 2025, Guillem Jover wrote:
>> >This bug does not count as RC just because Debian upload bureaucracy
>> >hasn't been performed yet.
>>
>> If packagers cannot rely on Policy to give correct information, what
>> *can* they rely on?
>
>This is not how Debian Policy has ever worked. By t
66 matches
Mail list logo
