Bug#1068220: normalize case of debian/control fields
Package: debian-policy Version: 4.6.2.1 In the process of preparing mass-NMUs for the time_t transition, I encountered a package where the scripted approach I was using failed because a package already had a 'replaces' field in debian/control, and dpkg detected the addition of a 'Replaces' field as a duplicate. Although we are accustomed to seeing a certain capitalization for fields in debian/control, I was surprised to see upon review that Debian Policy has always said that the field names are case-insensitive. While it may make sense for dpkg to be permissive in this regard, I don't think it makes sense for Debian to allow it, as it unnecessarily makes parsing of this file more difficult for little value. I therefore propose that we change Debian policy 5.1 to standardize its case rules for debian/control field names, using the well-known spongebob casing rules. The first, third, fourth, and seventh characters in the field name are capitalized, with the second, fith, sixth, and eighth characters in lower case, then repeating for each subsequent octet of characters. As you can see, this consistency immediately gives much more readable results: SoURce: xz-utils SeCTioN: utils PrIOriTy: optional MaINtaInEr: Jonathan Nieder UpLOadErS: Mohammed Adnène Trojette BuILd-DePeNDs: debhelper-compat (= 13), dpkg-dev (>= 1.16.2), autoconf (>= 2.64~), automake, libtool (>= 2.2), gettext, autopoint | gettext (<< 0.18-1), autopoint | cvs, po4a BuILd-DePeNDs-Indep: doxygen BuILd-CoNfLIctS: automake1.4 StANdaRdS-VErsIoN: 4.6.1 VcS-brOwSeR: https://salsa.debian.org/debian/xz-utils VcS-giT: https://salsa.debian.org/debian/xz-utils HoMEpaGe: https://tukaani.org/xz/ RuLEs-ReQuIRes-rOoT: no Thanks for considering, -- 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 Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote: > I now tend to switch to another approach (also proposed similarly by Adam): > > instead of relying on the rtd-theme package in the default install path of the > package installed by DSA, I will use the infrastructure in 1ftpfiles and > 7doc of webmaster's cron repo, to (always) fetch the latest version of that > package (and two more packages, which the former depends on: > fonts-font-awesome > and fonts-lato, to get the needed fonts) and unpack+copy them into > a dedicated path inside the www build tree. > > That path will be synced to the static www mirrors, and we can symlink > to it from the manuals. > (And the content of that path will automatically be kept up-to-date on > the unstable version of packages, so we don't get outdated/orphaned > copies of that packages in the isolated path.) > I want the unstable version of that packages here, since they need to > incorporate with the unstable version of the different manuals (like > debian-policy), and those packages are built by buildd, so unstable. > > How does that sound in the light of Debian guidelines and best practice? > > Is it ok, to have such "isolated copies" of packages as described above? > > I have not much experience in similar things, so I would like to get > some comments here, please. I mean, it seems okay to me, but it's up to the web team really. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
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? -- Sean Whitton
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 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 ? Do you need "Autobuild: yes" to preclude network access ? Cheers, -- Bill. Imagine a large red swirl here.
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
Hi, On Mon, 2024-04-01 at 17:52 +0200, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > 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: allowlisted non-free packages get built on buildds. Not allowing network access for contrib and non-free as well seems reasonable to me. Ansgar
Processed: retitle 1068192 to debian-policy: extend forbidden network access to contrib and non-free
Processing commands for cont...@bugs.debian.org: > retitle 1068192 debian-policy: extend forbidden network access to contrib and > non-free Bug #1068192 [debian-policy] debian-policy: extended forbidden network access to contrib and non-free Changed Bug title to 'debian-policy: extend forbidden network access to contrib and non-free' from 'debian-policy: extended forbidden network access to contrib and non-free'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1068192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068192 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
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 ? Cheers, -- Bill. Imagine a large red swirl here.
Processed: debian-policy: extended forbidden network access to contrib and non-free
Processing control commands: > affects -1 buildd.debian.org Bug #1068192 [debian-policy] debian-policy: extended forbidden network access to contrib and non-free Added indication that 1068192 affects buildd.debian.org -- 1068192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068192 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi,
Sean Whitton wrote (Thu, 28 Mar 2024 09:48:51 +0800):
> Many thanks all for working on this, especially you Holger for this
> scripting work. So, we're waiting in DSA and then on your script
> changes, and it'll work again.
DSA (adsb) did install the python3-sphinx-rtd-theme package on the www static
mirrors (thanks Adam for the quick reaction !!!), and I pushed my changings
to the 7doc script, but reality has proven me wrong, sadly:
The idea was, to have absolute symlinks from inside the manuals directories
to /usr/share/sphinx_rtd_theme/static/... and all looks fine on wolkenstein,
but those symlinks fail to get synced to the www static mirrors, because of
rsync's "--safe-links" option:
--safe-links ignore symlinks that point outside the tree
Thus, the debian-policy is still broken on our website, as before.
I now tend to switch to another approach (also proposed similarly by Adam):
instead of relying on the rtd-theme package in the default install path of the
package installed by DSA, I will use the infrastructure in 1ftpfiles and
7doc of webmaster's cron repo, to (always) fetch the latest version of that
package (and two more packages, which the former depends on: fonts-font-awesome
and fonts-lato, to get the needed fonts) and unpack+copy them into
a dedicated path inside the www build tree.
That path will be synced to the static www mirrors, and we can symlink
to it from the manuals.
(And the content of that path will automatically be kept up-to-date on
the unstable version of packages, so we don't get outdated/orphaned
copies of that packages in the isolated path.)
I want the unstable version of that packages here, since they need to
incorporate with the unstable version of the different manuals (like
debian-policy), and those packages are built by buildd, so unstable.
How does that sound in the light of Debian guidelines and best practice?
Is it ok, to have such "isolated copies" of packages as described above?
I have not much experience in similar things, so I would like to get
some comments here, please.
Or do people prefer a complete different way, like using another theme
or whatever? (since this thing is getting bigger and bigger currently)
(Please keep in mind that this is not only for debian-policy, but in the
long term all sphinx-based manuals are supposed to follow the path
discussed here.)
I already proposed to switch away from dh_sphinxdoc, to completely get rid
of this symlink issue, but someone mentioned various privacy issues as a
contra argument...
Patch attached for the first part (to get above mentioned packages
in the www build path) - just posted for reference here.
(Second part - to point the debian-policy manual to that path - will
follow in another round.)
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
diff --git a/parts/1ftpfiles b/parts/1ftpfiles
index 3a2d953..3079131 100755
--- a/parts/1ftpfiles
+++ b/parts/1ftpfiles
@@ -72,6 +72,11 @@ $WGET -O - $httpurlamd64 | xzcat >Packages-amd64
httpurlrepo="http://${ftpsite}/debian";
+# readthedocs.org html theme files and related fonts
+getdeb all sphinx-rtd-theme-common
+getdeb all fonts-font-awesome
+getdeb all fonts-lato
+
# many language specific binary packages (arch=all)
getdebs aptitude
getdebs debian-faq
diff --git a/parts/7doc b/parts/7doc
index 6998512..47e076e 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -428,6 +428,45 @@ echo -n "Installing documents:" >> $webdocdir/build.log
# We only have sid now
dist=sid
+# readthedocs.org html theme files and related fonts.
+# We need those files inside the www.d.o build tree on wolkenstein, because
+# the manuals will have symlinks pointing to those files, and syncing such
+# symlinks to the static www mirrors fails, when they point outside of the
+# tree (because of rsync's "--safe-links" option).
+# Therefore, we cannot simply have the packages installed by DSA on
+# wolkenstein, but we need an own copy inside the tree (in
+# www/doc/html-theme).
+# Since the manuals here are built on buildds and therefore are based on
+# unstable, I want to use the unstable version of the following packages
+# as well.
+unpack sphinx-rtd-theme-common
+ for themefilecss in usr/share/sphinx_rtd_theme/static/css/* ; do
+ mkdirp $webdocdir/html-theme/sphinx_rtd_theme/static/css
+ cp -rf $themefilecss $webdocdir/html-theme/sphinx_rtd_theme/static/css
+ done
+ for themefilefonts in usr/share/sphinx_rtd_theme/static/fonts/* ; do
+ mkdirp $webdocdir/html-theme/sphinx_rtd_theme/static/fonts
+ cp -rf $themefilefonts $webdocdir/html-theme/sphinx_rtd_theme/static/fonts
+ done
+unpack fonts-font-awesome
+ for fontfileawesome1 in usr/share/fonts-font-awesome/fonts/* ; do
+ mkdirp $webdocdir/html-theme/fonts-font-awesome/fonts
+ cp -rf $fontfileawesome1 $webdocdir/html-theme/fonts-font-awesome/fonts
+ done
+ for fontfileawesome2 in usr/share/fonts/opentype/font-awesome/* ; do
+ mkdirp $
