Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On 2024-04-04 22:38, Bill Allombert wrote: > On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote: > > I'm not sure what I think about that. We have a general escape hatch > > already for non-free packages in Policy 2.2.3 that says they may not fully > > comply with Policy, which may be sufficient. > > But precisely, we _do_ want non-free packages that are built on the > autobuilders > to comply with this requirement. So we do not want 2.2.3 to apply in that > specific case. It seems cleaner to say that the requirement only apply if > Autobuild: yes is declared. If we go that route, here is a proposed alternative patch: --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -338,7 +338,8 @@ For example, the build target should pass ``--disable-silent-rules`` to any configure scripts. See also :ref:`s-binaries`. -For packages in the main archive, required targets must not attempt +Except for packages in the non-free archive with the ``Autobuild`` +control field unset or set to ``no``, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On 2024-04-03 12:37, Philipp Kern wrote: > Hi, > > On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote: > > On 2024-04-02 09:21, Sean Whitton wrote: > > > Hello, > > > > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > > the main archive, which implicitly means they are authorized for > > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > > fixed). > > > > > > > > This gives constraints on the build daemons infrastructure and also > > > > brings some security concerns. Would it be possible to extend this > > > > restriction to all archives? > > > > > > We need to know if this is going to break existing packages and allow > > > some input from their maintainers. Are you able to prepare a list of > > > the affected packages? > > > > Fair enough. I can work on that, but help would be welcome as my > > resources are limited. > > I did a test rebuild of contrib, non-free and non-free-firmware packages > in sid with both stable sbuild schroot and unshare backends and could > not find a difference in build success (i.e. what failed failed in both, > what succeeded succeeded in both). Thanks Philipp. Following that result, please find a patch proposal: --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -338,9 +338,9 @@ For example, the build target should pass ``--disable-silent-rules`` to any configure scripts. See also :ref:`s-binaries`. -For packages in the main archive, required targets must not attempt -network access, except, via the loopback interface, to services on the -build host that have been started by the build. +Required targets must not attempt network access, except, via the +loopback interface, to services on the build host that have been started +by the build. Required targets must not attempt to write outside of the unpacked source package tree. There are two exceptions. Firstly, the binary Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On 2024-04-02 09:21, Sean Whitton wrote: > Hello, > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > Package: debian-policy > > Version: 4.6.2.1 > > Severity: normal > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > Control: affects -1 buildd.debian.org > > > > Hi, > > > > The debian policy, section 4.9, forbids network access for packages in > > the main archive, which implicitly means they are authorized for > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > fixed). > > > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > We need to know if this is going to break existing packages and allow > some input from their maintainers. Are you able to prepare a list of > the affected packages? Fair enough. I can work on that, but help would be welcome as my resources are limited. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free
On 2024-04-01 18:18, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote: > > On 2024-04-01 17:52, Bill Allombert wrote: > > > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > > > Package: debian-policy > > > > Version: 4.6.2.1 > > > > Severity: normal > > > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > > > Control: affects -1 buildd.debian.org > > > > > > > > Hi, > > > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > > the main archive, which implicitly means they are authorized for > > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > > fixed). > > > > > > > > This gives constraints on the build daemons infrastructure and also > > > > brings some security concerns. Would it be possible to extend this > > > > restriction to all archives? > > > > > > Does the build daemons actually build non-free ? > > > > Yes, they do, though only part of non-free, only the packages that have > > Autobuild: yes and that have been put on an allow list after review. > > Is your concern is that the package start to do network acces during build > after it has been added to the allow list ? Yes, this is the security concern. > Do you need "Autobuild: yes" to preclude network access ? Not right now, but the goal is to fully disable the network access, and we do not want to have to special case contrib or non-free, as it just makes things complicated. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free
On 2024-04-01 17:52, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > Package: debian-policy > > Version: 4.6.2.1 > > Severity: normal > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > > Control: affects -1 buildd.debian.org > > > > Hi, > > > > The debian policy, section 4.9, forbids network access for packages in > > the main archive, which implicitly means they are authorized for > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > fixed). > > > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > Does the build daemons actually build non-free ? Yes, they do, though only part of non-free, only the packages that have Autobuild: yes and that have been put on an allow list after review. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Package: debian-policy Version: 4.6.2.1 Severity: normal X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, The debian policy, section 4.9, forbids network access for packages in the main archive, which implicitly means they are authorized for packages in contrib and non-free (and non-free-firmware once #1029211 is fixed). This gives constraints on the build daemons infrastructure and also brings some security concerns. Would it be possible to extend this restriction to all archives? Regards, Aurelien
Bug#940234: debian-policy: add a section about source reproducibility
Package: debian-policy Version: 4.4.0.1 Severity: wishlist There is already a section about reproducibility in the debian-policy, but it only mentions the binary packages. It might be a good idea to add a new requirement that repeatedly building the source package in the same environment produces identical .dsc file modulo the GPG signature. I haven't checked how many packages do not fulfill this condition, but there are for sure packages where the Build-Depends: entry in the dsc file does not match the debian/control file, as they have been added manually after the package build. TTBOMK there is nothing preventing that in the debian policy. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 1.8.5-3 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#846970: Patch to document Build-Indep-Architecture field
On 2018-06-15 19:05, Sean Whitton wrote:
> control: tag -1 -patch
>
> [CCing those involved in the original discussion, and wanna-build team,
> in case they object to my proposal below to just close this bug]
>
> Hello,
>
> On Fri, Jun 15 2018, Ian Jackson wrote:
>
> > Sean Whitton writes ("Bug#846970: Patch to document
> > Build-Indep-Architecture field"):
> >> > +``Build-Indep-Architecture``
> >> > +
> >> > +
> >> > +Specification of architectures on which the architecture-independent
> >> > +binary packages are known to be buildable and/or not buildable. If
> >> > +this field is not specified, it defaults to ``any``, matching all
> >> > +Debian machine architectures. If specified, it should be either
> >> > +
> >> > +- A unique single word identifying a Debian machine architecture as
> >> > + described in :ref:`s-arch-spec`.
> >> > +
> >> > +- An architecture wildcard identifying a set of Debian machine
> >> > + architectures, see :ref:`s-arch-wildcard-spec`.
> >> > +
> >> > +This header is useful in the rare case where architecture-independent
> >> > +packages cannot be built on all architectures for reasons outside the
> >> > +maintainer's control.
> >> > +
> >> > +Although the syntax of the field permits it, you should avoid
> >> > +specifying that the package can be built on only a single
> >> > +architecture. This provides flexibility to the administrators of
> >> > +autobuilder infrastructure.
> >
> > I'm afraid I don't understand this.
> >
> > AFAICT from reading s-arch-spec and s-arch-wildcard-spec and looking
> > at the output of dpkg-architecture -L, the above syntax specification
> > permits, with our current arch list, only Build-Indep-Architecture
> > field contents of the following four forms:
> >
> > amd64 (FSVO amd64) doc says don't do this
> > kfreebsd-any (FSVO kfreebsd) useful but niche
> > kfreebsd-amd64 (FSVO kfreebsd & amd64) doc says don't do this
> > any-amd64 (FSVO amd64 not very useful
> > any the default
> >
> > So there is no good use for this field.
>
> Thank you for this analysis.
>
> My original expectation was that the most common use of the field would
> be of the form
>
> Build-Indep-Architecture: !amd64
>
> but this is not actually permitted by my patch. Negating architecture
> names is described only under the Depends field. I think that Mattia
> had realised this mistake, but I mustn't have read his e-mail carefully
> enough, so sorry, all, for being a bit careless.
>
> We can fix my patch in a few different ways:
>
> 1. add "an exclamation mark followed by a unique single word identifying
>a Debian machine architecture ..." as one of the possible values
>
> 2. add the ability to specify a list of architectures and/or
>architecture wildcards, separated by commas
>
> 3. both of the above, (1) and (2)
>
> 4. drop the 'should' requirement that the field specify at least two
>architectures.
>
> The main problem with (1), (2) and (3) is that it means a new parser has
> to be written for this field, as we will be departing from the syntax of
> the Architecture field.
>
> The main problem with (4) has already been discussed: we don't want to
> encourage people to just type `Build-Indep-Architecture:
> my-laptops-arch` whenever their arch:all package FTBFSs on another arch.
>
> Zooming out a bit:
>
> We do not normally add fields to Policy until they are already in use in
> the archive.
>
> Looking at codesearch.debian.net reveals that only a single package is
> actually using this field at present. I haven't checked, but presumably
> the field is not supported by the Debian autobuilders.
I confirm this is not currently supported by the autobuilders. If it
gets added, we'll add support to respect this field, i.e. not try to
build the package on an autobuilder with a different architecture than
the specified one. That said, we do not plan to add support for
non-amd64 based arch:all autobuilder at this point.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: Debian Policy 4.1.0.0 released
On 2017-08-22 09:42, Russ Allbery wrote: > Aurelien Jarno <aurel...@aurel32.net> writes: > > On 2017-08-21 14:35, Sean Whitton wrote: > > >> 9.1.1 > >> Only the dynamic linker may install files to /lib64/. > > > How is that supposed to work for the multilib glibc? For example > > libc6-amd64:i386 installs all its libraries into /lib64. We don't want > > to install these files in the multiarch path, as they will collide with > > the libc6:amd64 package. This is actually forbidden by the same > > paragraph of the policy (and that's a good thing). > > > In the long term we should get ready of multilib now that we have > > multiarch, but it seems it's not something we are ready to do yet. I > > have added debian-...@lists.debian.org in Cc: as GCC is the main user of > > the multilib glibc. > > Ack, thank you, we just didn't know about this and it didn't come up in > the discussion. We can add an additional exception. The goal here wasn't > to change any behavior of packages like that, only to keep ordinary > non-glibc, non-toolchain packages from using that directory because of > what Red Hat does or because of what the FHS says. > > Would it resolve this to just make a general exception for libc? Yes, that would solve the issue. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Debian Policy 4.1.0.0 released
Hi, On 2017-08-21 14:35, Sean Whitton wrote: > Hello everyone, > > Debian Policy 4.1.0.0 is on its way into unstable. > > The source of the Policy Manual is now in reStructuredText, and the > Sphinx toolchain is used to produce our output formats. This has > enabled us to introduce new ePub and Texinfo output formats, so it's now > more comfortable to read Policy on the beach, and in Emacs. > > Many thanks to Hideki Yamane for writing the rST conversion scripts and > pushing the project forward, and David Bremner for help proofreading. > Russ Allbery and I updated the build system. > > We are seeking volunteers to design a Debian documentation Sphinx > theme. The maintainers of other core pieces of Debian documentation are > also looking to move to Sphinx, so such a theme would see wide use. > > Here are the changes from the previously announced version of Policy > (4.0.1): > 9.1.1 > Only the dynamic linker may install files to /lib64/. How is that supposed to work for the multilib glibc? For example libc6-amd64:i386 installs all its libraries into /lib64. We don't want to install these files in the multiarch path, as they will collide with the libc6:amd64 package. This is actually forbidden by the same paragraph of the policy (and that's a good thing). In the long term we should get ready of multilib now that we have multiarch, but it seems it's not something we are ready to do yet. I have added debian-...@lists.debian.org in Cc: as GCC is the main user of the multilib glibc. > No package for a 64 bit architecture may install files to > /usr/lib64/ or any subdirectory. I guess you want to use the same formulation for /lib64, it should only be for 64-bit architecture. That said you should define what is a 64 bit architecture. On x32 (not an official architecture) for example libc6-amd64:x32 installs files in /lib64 and libc6-amd64-dev:x32 installs file in /usr/lib64. Is it considered a 32-bit architecture or a 64-bit architecture? Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
On Thu, May 08, 2014 at 09:08:58AM +0200, Tollef Fog Heen wrote: ]] Aurelien Jarno How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. I think the whole libqual thing should be avoided and we should nack it for any new ports. Ideally, we should also try to get ourselves out of the hole we've dug ourselves into. Unfortunately given we still want to keep multilib compilers in the archive, we need to provide foreign binaries, and thus install them in libqual. The policy clearly states that a foreign binary should not be installed in the multiarch path, and that's really a good thing given how much pain multilib packages are already (especially when people start to install libc6-dev-amd64:i386 on an amd64 system or things like that). Currently for being able to build i386 binaries on an amd64 system, you need to install libc6-i386:amd64, usually used in addition to libc6:i386. This is a pain from the glibc side as we have to handle the fact that they both provide ld.so and that they can be removed in any order. The development of multiarch seems to be more or less stalled now, people being satisfied of being able to install packages from foreign architectures. To be able to progress further we need to solve the toolchain issue. They are multiple solutions from using foreign packages to build multilib toolchain, to stopping providing a multilib toolchain and using either cross compiler or allow both gcc:amd64 and gcc:i386 to be co-installable. In any case to support kernel and bootloader packages we need to create new architectures with a minimal set of packages (basically the toolchain). On the other hand if we just continue to wait, 32-bit architectures are going to die, and the kernel and bootloader issue will simply disappear ;-). I don't see anybody being against relaxing the requirement for /usr/local/libqual to exist, so we're presumably blocked on more seconds. Ok, great. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140508114233.gl25...@hall.aurel32.net
Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
block 720777 by 613143 block 720778 by 613143 block 720780 by 613143 thanks On Fri, Sep 23, 2011 at 10:18:05AM +0200, Bill Allombert wrote: On Thu, Sep 22, 2011 at 05:08:33PM -0500, Jonathan Nieder wrote: Tollef Fog Heen wrote: ]] Steve Langasek | How do we square that with the FHS, then? The FHS says: | | If directories /libqual or /usr/libqual exist, the equivalent | directories must also exist in /usr/local. | | That seems to require /usr/local/lib64 even if we *don't* include | /usr/lib64, right? Should we amend policy to take this exception to the | FHS? Please open a bug report on policy if you think we should. I think this is a bug in the FHS that we need to work around in Debian policy. libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem described in bug#612000 no longer exists and there's no reason to want a /usr/local/lib64 symlink any more. We're left in the less worrisome situation Steve described, with the question of whether to create a (useless) /usr/local/lib64 directory. So now I can wholeheartedly endorse your proposed change. --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p /item + item +p + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file or + file/usr/liblt;qualgt/file exists is removed. +/p + /item /enumlist /p Seconds? Seconded. The whole lib64 business was completly backward from the start. Ping! How can we progress on this bug? We now have bugs #720777, #720778 and #720780 which ask for /usr/libqual to be created if /libqual exists. It's something that can be implemented, but before doing so, I would like to know if a decision has been taken wrt the policy. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507234242.ga27...@volta.rr44.fr
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
On Mon, Mar 21, 2011 at 02:34:36PM -0700, Steve Langasek wrote: Package: debian-policy Version: 3.9.1.0 Severity: normal Tags: patch User: debian-pol...@packages.debian.org Usertags: normative Hi guys, Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. Cc:ing the respective maintainer mailing lists for sign-off. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 1f0f1281c53701e2fe549ed9f80a265ebcd9282a Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Mon, 21 Mar 2011 02:17:14 -0700 Subject: [PATCH] Fix multiarch FHS exception for i386 in light of recent discussions The current value of DEB_HOST_GNU_TYPE on i386 is unsuitable for cross-distro standardization, because it varies according to the default CPU target of the toolchain. Discussion with the toolchain and dpkg maintainers yielded an alternative solution, a new dpkg-architecture variable DEB_HOST_MULTIARCH which is committed to dpkg upstream in commit af3153d09aa3ed5597d6d415e5ab7cc3ba972e7c and will be included in the upload of dpkg 1.16.0. Update Policy to document this new requirement for multiarch. --- policy.sgml |4 ++-- upgrading-checklist.sgml |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6e04c81..c708a18 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6027,13 +6027,13 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ file/lib/vartriplet/var/file and file/usr/lib/vartriplet/var/file, where ttvartriplet/var/tt is the value returned by - ttdpkg-architecture -qDEB_HOST_GNU_TYPE/tt for the + ttdpkg-architecture -qDEB_HOST_MULTIARCH/tt for the architecture of the package. Packages may emnot/em install files to any vartriplet/var path other than the one matching the architecture of that package; for instance, an ttArchitecture: amd64/tt package containing 32-bit x86 libraries may not install these - libraries to file/usr/lib/i486-linux-gnu/file. + libraries to file/usr/lib/i386-linux-gnu/file. footnote This is necessary in order to reserve the directories for use in cross-installation of library packages from other diff --git a/upgrading-checklist.sgml b/upgrading-checklist.sgml index e696077..2138b5c 100644 --- a/upgrading-checklist.sgml +++ b/upgrading-checklist.sgml @@ -58,6 +58,13 @@ Unreleased. that install prgn/usr/bin/mailx/prgn and implement at least the POSIX-required interface. /item +tag9.1.1/tag + itemPackages installing to architecture-specific subdirectories of + file/url/lib/file must use the value returned by + prgndpkg-architecture -qDEB_HOST_MULTIARCH/prgn, not by + prgndpkg-architecture -qDEB_HOST_GNU_TYPE/prgn; this is a path change + on i386 architectures and a no-op for other architectures. + /item /taglist/p sect Version 3.9.1.0 -- 1.7.1 Signed-off-by: Aurelien Jarno aure...@debian.org -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Bug#522776: C.UTF-8 in squeeze
tag Roger Leigh a écrit : clone 522776 -1 reassign -1 eglibc retitle -1 eglibc: Please provide a C.UTF-8 locale by default severity -1 important thanks On Fri, Jan 07, 2011 at 09:14:47PM -0500, David Holland wrote: Can this please get done (adding a C.UTF-8 locale)? It is absolutely required for writing shell scripts that handle UTF-8 data, if you want those shell scripts to have anything like portable or reliable behavior. This is really in the hands of the glibc maintainers. I thought that a bug had been filed months ago, but I can't find it. I've done so now. Note this comment from Aurelien Jarno: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776#342 This will only be done with the approval of the release team, who I've copied in. I know some persons already tried to work on that, so if patches are already available, they will be really appreciated. Providing a C.UTF-8 locale is quite easy, d-i is already doing that. Providing a C.UTF-8 *by default* is more complicated, as it has to be done in the GNU libc code, we can't really on the locale package generating one. This would mean this package should always be installed, and that we should trust on user to correctly regenerate the locales if they do. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2ab8ca.5030...@aurel32.net
Bug#522776: C.UTF-8 in squeeze
Roger Leigh a écrit : On Mon, Jan 10, 2011 at 08:44:10AM +0100, Aurelien Jarno wrote: Roger Leigh a écrit : On Fri, Jan 07, 2011 at 09:14:47PM -0500, David Holland wrote: Can this please get done (adding a C.UTF-8 locale)? It is absolutely required for writing shell scripts that handle UTF-8 data, if you want those shell scripts to have anything like portable or reliable behavior. This is really in the hands of the glibc maintainers. I thought that a bug had been filed months ago, but I can't find it. I've done so now. I know some persons already tried to work on that, so if patches are already available, they will be really appreciated. Providing a C.UTF-8 locale is quite easy, d-i is already doing that. Providing a C.UTF-8 *by default* is more complicated, as it has to be done in the GNU libc code, we can't really on the locale package generating one. This would mean this package should always be installed, and that we should trust on user to correctly regenerate the locales if they do. Hi Aurelien, I think that initially, simply guaranteeing the presence of C.UTF-8 as a standard locale, generated by localedef/gen will be sufficient. This will allow packages to rely on its presence during normal system operation e.g. in maintainer scripts, for lintian and other programs requiring it. Doing so means that the locales or locales-all package will be installed by default. People are going to shout... Or we should create a locales-cutf8 packages, but then the integration with the two other packages will become quite complex. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2ae542.2030...@aurel32.net
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Fri, Sep 03, 2010 at 04:20:27PM +0200, Samuel Thibault wrote: Roger Leigh, le Fri 03 Sep 2010 14:52:39 +0100, a écrit : On Fri, Sep 03, 2010 at 01:37:24AM +0200, Samuel Thibault wrote: without any convergence. I think reading back through the entire log, Thanks for having done it! people who were initially rather opposed to the proposal did come around once they appreciated exactly what the changes would be, and why they were needed. Ok. There was still a question of en_US.UTF-8 vs C.UTF-8, but I believe the en_US.UTF-8 is fine enough argument doesn't hold any more since some other people say that it isn't for them. There were no objections to having a UTF-8 locale installed and available by default, just to it *being* the default. Taking this first small step is IMO important to do, preferably for squeeze if possible. Since it's a tiny one-liner change, this should be no trouble in getting this done. I believe so too, I just didn't want to push it too much, but yes, I believe that's something that shouldn't break Squeeze at all. That's not something allowed anymore at this period of the freeze, you will have to get an exception from the release team first. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100903171640.gb26...@hall.aurel32.net
Bug#542865: Grant an FHS exception for the multiarch library directories
On Fri, Sep 04, 2009 at 08:50:30PM -0700, Steve Langasek wrote:
On Fri, Aug 21, 2009 at 09:25:30PM -0700, Russ Allbery wrote:
Manoj Srivastava sriva...@debian.org writes:
On Fri, Aug 21 2009, Russ Allbery wrote:
The current restriction is specific to libraries. Don't we need to say
that you can't put *any* files into any triplet directory that isn't
for your package architecture?
Hmm. My first read was that one could not put anything that was
not a library in these directories, but perhaps it should be stated
explicitly.
I was expecting that we'd need to put anything that you might want to have
simultaneous installs from multiple architectures in that directory, which
would include, for instance, any shared library plugins or loadable
modules, which aren't strictly libraries.
We might have to duplicate some library helper programs as well, if for
instance they communicate with the library using binary structures that
are sensitive to sizeof(long).
Right, this was a bug in the proposed patch, not a deliberate statement that
only libraries belong in these directories. (As I mentioned, the first
patch was something of a trial balloon.) I think this updated patch should
cover everything for the first round.
Re-seconds?
Seconded.
---
policy.sgml | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 0bf8253..347c0bf 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,40 @@ libbar 1 bar1 (= 1.0-1)
/item
item
p
+ The requirement for object files, internal binaries, and
+ libraries, including filelibc.so.*/file, to be located
+ directly under file/lib{,32}/file and
+ file/usr/lib{,32}/file is amended, permitting files
+ to instead be installed to
+ file/lib/vartriplet/var/file and
+ file/usr/lib/vartriplet/var/file, where
+ ttvartriplet/var/tt is the value returned by
+ ttdpkg-architecture -qDEB_HOST_GNU_TYPE/tt for the
+ architecture of the package. Packages may emnot/em
+ install files to any vartriplet/var path other
+ than the one matching the architecture of that package;
+ for instance, an ttArchitecture: amd64/tt package
+ containing 32-bit x86 libraries may not install these
+ libraries to file/usr/lib/i486-linux-gnu/file.
+ footnote
+This is necessary in order to reserve the directories for
+use in cross-installation of library packages from other
+architectures, as part of the planned deployment of
+ttmultiarch/tt.
+ /footnote
+/p
+p
+ Applications may also use a single subdirectory under
+ file/usr/lib/vartriplet/var/file.
+/p
+p
+ The execution time linker/loader, ld*, must still be made
+ available in the existing location under /lib or /lib64
+ since this is part of the ELF ABI for the architecture.
+/p
+ /item
+ item
+p
The requirement that
file/usr/local/share/man/file be synonymous
with file/usr/local/man/file is relaxed to a
--
1.6.3.3
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: Digital signature
Bug#209008: How should the build logs be handled?
Hi, I have just noticed that that things are moving. Nice :) First of all, I am personally in favor of DEB_BUILD_OPTIONS=parallel=n because it is consistent with all other options that can be set when building a package. If the code to parse it is too long, it could be put for example in debhelper. On Tue, Apr 10, 2007 at 03:19:56PM +0200, Loïc Minier wrote: I added support for DEB_BUILD_OPTIONS_PARALLEL to some big packages which are building multiple flavors of the software. First, there's a choice of what to parallelize: do you parallelize ./configure runs and multiple builds when you have multiple configure + build runs to achieve? Second, I noticed that the output wasn't very easy to read, especially with libtool based builds which produce several line of output and run multiple commands per object. On glibc we are running configure normally, and then invoking the build phase with make -j. We still build all flavour sequentially. I can't say what is the best solution. Building all the flavours sequentially has the advantage to fail faster if some code does not compile. Not really useful on the build daemon, but that can be useful locally. So while I think it's a good thing to add such a support in packages for some use cases (perhaps archive rebuilds, repetitive builds of the same software after each commit etc.), I wonder how we will deal with build logs. Should we recommend that such builds have to save their build logs and output it at the end of the build? e.g.: make debian/build.log || (cat debian/build.log; exit 1) cat debian/build.log This is what I used in my packages: MAKEFLAGS += $(if $(DEB_BUILD_OPTIONS_PARALLEL),-j2 $(DEB_BUILD_OPTIONS_PARALLEL)) (It wont work with packages calling $(MAKE) -f debian/rules which should protect against adding another -j flag in the submake.) I should warn about using MAKEFLAGS. A lot of software do support using -j for the make all phase, but do not for the make install phase. In the case of the glibc, using -j for the make install phase was causing a build failure, rarely but enough often to bother us (and the SRM team). That's why I would advise to call make -j explicitely in the parts that have been well tested. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408500: debian-policy: Section 2.2.1: add package must be rebuilt from source
Package: debian-policy Version: 3.7.2.2 Severity: wishlist A few packages in the archive are providing sources, but the .deb packages are not rebuild from those sources. That is allowed as there is nothing in the DFSG nor in the debian-policy that prevents a binary package to not be built from the accompanied sources. I think this should be forbidden for packages in main. This could be added in section 2.2.1. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-xen-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
