Bug#1069934: 4.9.2. The dak ls utility should mention rmadison

[Holger Levsen]

control: severity -1 wishlist
thanks

Hi Bill,

On Sat, Apr 27, 2024 at 12:11:21PM +0200, Bill Allombert wrote:
> 4.9.2. The dak ls utility
> could mention rmadison from devscripts
> that does not require to log to ftp-master.debian.org.
 
yes. patches, commits & pushes welcome.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

20230709: Today was the warmest day on earth in 125,000 years. Today was also
the day with the most planes in the air at one time ever in history. By the time
you read this both of these records have probably been broken.


signature.asc
Description: PGP signature

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Holger Levsen]

On Sat, Apr 20, 2024 at 08:30:52PM +0200, Guillem Jover wrote:
> While I fully support properly marking obsolete packages by putting
> them in the (unfortunately misnamed :) oldlibs section (well excluding
> library-like depended on packages that get dropped as a mater of course).
> I wanted to note that I've received some pushback from the archive
> maintainers about this being considered unnecessary churn (paraphrasing
> from what ISTR). So it would be nice to clarify this with them before
> creating and proposing a procedure that might end up generating social
> friction.
 
I tend to agree. Already now maintainers forget to drop transitional
packages after having them been part of *two* releases (I have filed >400 bugs
requesting removal of such old transitional packages in the last 10y, so 
roughly 80 per release), so I don't think requiring them to do *more*
will work out nicely.

(also this adds workload to ftpmasters too.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"In just 6 decades, roughly the life span of a blue whale, humans took blue 
whale
population down from 360,000 to just 1,000. In one century, whalers killed two
million baleen whales, which together weighed twice as much as all wild mammals
on Earth today."
https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/


signature.asc
Description: PGP signature

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Holger Levsen]

Hi Vincent,

On Wed, Apr 17, 2024 at 04:24:16AM +0200, Vincent Lefevre wrote:
> Now that the deborphan package has been removed from unstable,
> the section "Make transition packages deborphan compliant" in
> "Best Packaging Practices" is out of date and should be updated.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
> where "apt-mark auto ..." (for autoremove) is suggested as a
> replacement. But with it, putting transition packages to oldlibs
> is even more necessary.

thanks for filing this bug report. Patches are very welcome, it's all
mark down now.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

So what CAN we actually do? Well, individual decisions (eating less meat,
taking public transport, buying less fast fashion) are all important, but we
also need to change the system. As you may know, just 100 companies are
responsible for 71% of global emissions. (@JessicaTheLaw)
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change


signature.asc
Description: PGP signature

Re: single-page html of debian-policy to be revived?

[Holger Levsen]

On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote:
> ... but if dev-ref is already shipping both, maybe singlepage is indeed
> usable these days ...

I think it is.
 
> > Could the Policy Editors team check, if everything is fine now, and if
> > this should be published again?
> > At least there is still an issue with the footnotes, there are 16 
> > occurrences
> > of #id1 for example... (search for "[1]" in policy-1.html).
> Hrm.  That seems like a pretty serious problem :\

I wouldnt call it serious. annoying yes, maybe.
 
> Holger L., did you know about this issue?
> Did you decide it was worth publishing anyway?

yes.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages
or (single page) 
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages
both show four footnotes, right where they belong, it's just that
each foot note is numbered and that [1] or [2] or whatever is
a link, pointing to a wrong place.

I agree it's a bug, but I do think it's a pretty harmless one.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Any fool can know. The point is to understand." - A. Einstein 


signature.asc
Description: PGP signature

Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

[Holger Levsen]

On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote:
> A single page html may be an additional option but there's already the
> single page txt version and the PDF. That's sufficient and I see no
> need in providing more formats of this manual.
> 
> Therefore we can close this and I will close 877337.

fwiw, I disagree with this conclusion. single page txt and pdf versions
are no replacements for single page html.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Another end of the world is possible.


signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Holger Levsen]

On Fri, Apr 05, 2024 at 09:49:58PM +0200, Aurelien Jarno wrote:
> 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.

seconded as well.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

There never has been more knowledge in the world with less conclusions.
(Die Goldenen Zitronen, 1996 or so)


signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Holger Levsen]

On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> 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

thanks, this looks good to me as well. seconded.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bananas are berries.


signature.asc
Description: PGP signature

Bug#1062983: Developers Reference in A4 instead of US Letter

[Holger Levsen]

On Mon, Feb 05, 2024 at 11:00:42AM +0800, Paul Wise wrote:
> > I think for English at least I'd prefer to offer both A4 and letter, for eg
> > the German translation I think it's enough to only provide A4.
> Looks like that info can be gotten from the locales on glibc systems:
[...]

nice, thanks.

> For languages with one translation instead of one per dialect,
> you could produce documents in each of the unique sizes.

I don't understand, what do you mean with "one per dialect" here?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Cholera is over. It's safe to put sewage in our drinking water again.
(@stimmyskye)


signature.asc
Description: PGP signature

Bug#1062983: Developers Reference in A4 instead of US Letter

[Holger Levsen]

hi & thanks for filing this bug report!

On Sun, Feb 04, 2024 at 10:57:03AM +0100, Sebastian Geiger (Lanoxx) wrote:
> May I request, that:
> 
> a) We switch to A4 as the default format for the developers-reference
> since that is the format used by most of the world.
> b) We consider offering both formats on the Debian manuals page, so that
> users can choose their preferred format.

I think for English at least I'd prefer to offer both A4 and letter, for eg
the German translation I think it's enough to only provide A4.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"I like beautiful people. I don't care about their looks."


signature.asc
Description: PGP signature

Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness

[Holger Levsen]

control: reopen -1
control: reassign -1 debian-policy
control: retitle -1 please stop mentioning urgency=critical
thanks

On Wed, Dec 13, 2023 at 10:27:20PM +0100, Daniel Gröber wrote:
> On Wed, Dec 13, 2023 at 07:24:49PM +0000, Holger Levsen wrote:
> > I believe Debian policy should be changed then and not mention a severity
> > which is not used in practice.
> Easier said than done. I see debian-policy@d.o is already CCed on this bug
> so, opinions?

debian-policy@ has been cc: on this bug because developers-reference and
debian-policy share the same mailinglist.
 
> Doesn't policy document the reality that these urgency values are in fact
> usable? Do you not agree that britney does in fact support these? If I go
> ahead and upload a package with urgency=critical will this be REJECTed by
> ftp-master?

It will not be rejected but setting the urgency has little practical
relevance these days. You could also upload with urgency=low or urgency=high
and that would be the same in practice.

> If not they exist so why shouldn't they be documented in devref?

- because it will make people use them
- because people always think their issues are critical
- because using them will not have an effect
- because people will then complain that they have no effect
- because all of this is a waste of someones time.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

https://showyourstripes.info


signature.asc
Description: PGP signature

Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness

[Holger Levsen]

On Wed, Dec 13, 2023 at 07:04:01PM +0100, Daniel Gröber wrote:
> That's fine, but in that case this fact should be documented instead no?
> Right now there's confusion across the docs what criticality levels are
> available. Britney.conf and d-policy mention critical/emergency but nothing
> else even acknowledges they exist which is just confusing.

I believe Debian policy should be changed then and not mention a severity
which is not used in practice.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

half the worlds poor life in resource rich countries.
HOME: https://youtu.be/Eu6ieWI3yjI


signature.asc
Description: PGP signature

Bug#1057057: debian-policy: Please make Checksums-Sha1 optional

[Holger Levsen]

hi,

snapshot.d.o also uses sha1 sums, at least internally, but I'd not
surprised if also for external verification. 


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Reporter: You're the first person ever to win two Olympic tennis gold medals.
That's an extraordinary feat, isn't it?
Andy Murray: I think Venus and Serena have won about four each.


signature.asc
Description: PGP signature

Bug#1042779: developers-reference: overhaul of chapter about i18n / l10n

[Holger Levsen]

Hi Holger,

On Mon, Jul 31, 2023 at 10:49:20PM +0200, Holger Wansing wrote:
> yesterday I was a bit shocked when reading chapter 8 of the developers-ref:
> https://www.debian.org/doc/manuals/developers-reference/l10n.en.html
> 
> That chapter has several wrong/bad sentences (or is heavily outdated, if that
> things have been correct like that at some time).
> 
> I comment here on the different parts; a complete patch which integrates all
> this proposals is attached to this mail.

thank you very much for this! I'll upload shortly. In future please also feel 
free
to directly commit fixes to git if you are confident about the changes.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This is the year of gpg on the desktop! (Gunnar Wolf)


signature.asc
Description: PGP signature

Bug#1040704: #1040704: check_running_kernel fails to find version on bookworm/armhf as well

[Holger Levsen]

control: retitle -1 check_running_kernel fails to find version on 
bookworm/(arm64|armhf)
thanks

hi,

I can confirm this bug affects armhf as well:

holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@jtx1a:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname -a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux jtx1a 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 GNU/Linux

I can also confirm the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1033791;filename=0001-Extend-fix-for-on-disk-version-detection-on-Bookworm.patch;msg=15
to be working:

holger@jtx1a:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

And this also affects armhf systems running with an arm64 kernel:

holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname 
-a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux virt64c 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 
GNU/Linux


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We can send billionaires to space but not kids to fully funded public schools.


signature.asc
Description: PGP signature

Bug#1040914: dev-ref: update best practices around security (Re: Securing Debian Manual too old?)

[Holger Levsen]

package: developers-reference
x-debbugs-cc: debian-secur...@lists.debian.org

hi,

On Tue, Jul 11, 2023 at 10:46:20PM +0200, Moritz Mühlenhoff wrote:
> > I found the Securing Debian Manual
> > (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
> > This version is from 2017.
> 
> This document is in fact too outdated and not in a shape we should
> prominently present it on the Debian website, thanks for flagging it.
> It even predates systemd and no mention of it at all...
> 
> Can you please "reportbug www.debian.org" asking to remove it from the
> website?

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-around-security

currently contains this text:



Best practices around security


A set of suggestions and links to other reference documents around
security aspects for packaging can be found at the `Developer's Best
Practices for OS Security chapter inside the Securing Debian Manual
`__.



and unsure what to do now, as I'd like to keep the anchor and chapter, so
just dropping this would be wrong. Help welcome.

> It's also packaged as src:harden-doc and probably stick around in
> case someone wants to improve it going forward.

I'm not even sure this is useful to keep around. :/


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just today, over 800 women will have died due to preventable pregnancy and
birth complications, over 130 due to femicide.
https://www.who.int/news-room/fact-sheets/detail/maternal-mortality
https://en.wikipedia.org/wiki/Femicide#Worldwide


signature.asc
Description: PGP signature

Re: 6.1.3. Multiple binary packages question

[Holger Levsen]

On Sun, Jun 18, 2023 at 11:19:06PM +0200, Bill Allombert wrote:
> On Sat, Jun 17, 2023 at 09:21:00PM +0000, Holger Levsen wrote:
> > On Mon, Apr 03, 2023 at 09:29:04AM -0600, Sam Hartman wrote:
> > > >>>>> "Kristian" == Kristian Penno  writes:
> > > Kristian> source package is referenced.  The lyx source package uses
> > > Kristian> some shell commands to move files around in the rules
> > > Kristian> file.  Is this preferred to using debhelper
> > > Kristian> .install files?
> > > No.
> > > If .install files work for you, that's better.
> The drawback of dh_install is that it requires more diskspace to build than
> dh_movefiles but is less error prone.
> So unless your package is very large, it is safer to use dh_install.

interesting, I've never heard of dh_movefiles before.

what does "more diskspace" mean, however? kilobytes? terabytes? 100% of
the diskspace used by the files installed? 200%?

"my" largest package was less than 100mb in size, which can be a bit annoying 
for
uploads, but for diskspace during build, several gigabytes (or more) are
not uncommon, so I'm having a somewhat hard time imaginening that the
above is a relavant argument in most situations.

But I might be wrong. :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Homophobia is a sin against god.


signature.asc
Description: PGP signature

Re: 6.1.3. Multiple binary packages question

[Holger Levsen]

On Mon, Apr 03, 2023 at 09:29:04AM -0600, Sam Hartman wrote:
> > "Kristian" == Kristian Penno  writes:
> Kristian> source package is referenced.  The lyx source package uses
> Kristian> some shell commands to move files around in the rules
> Kristian> file.  Is this preferred to using debhelper
> Kristian> .install files?
> No.
> If .install files work for you, that's better.

thank you, Kristian and Sam, I've updated src:dev-ref in git
to refer to libxml2 instead of lyx.

https://salsa.debian.org/debian/developers-reference/-/commit/4bc621bb5fae5ed43a6873e8bbd26c397ab78b61


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Everyone is entitled to their own opinion, but not their own facts.


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Holger Levsen]

On Tue, Jun 13, 2023 at 11:04:07PM +0100, Luca Boccassi wrote:
> ---
>  policy/ap-pkg-alternatives.rst |  3 +++
>  policy/ap-pkg-diversions.rst   |  3 +++
>  policy/ch-binary.rst   | 35 ++
>  3 files changed, 41 insertions(+)
> 
> diff --git a/policy/ap-pkg-alternatives.rst b/policy/ap-pkg-alternatives.rst
> index ffa2163..6f7780f 100644
> --- a/policy/ap-pkg-alternatives.rst
> +++ b/policy/ap-pkg-alternatives.rst
> @@ -24,3 +24,6 @@ See the :manpage:`update-alternatives(8)` man page for 
> details.
>  If ``update-alternatives`` does not seem appropriate you may wish to
>  consider using diversions instead.
>  
> +Do not use alternatives for ``systemd`` configuration files. See
> +:doc:`ch-binary` for more information.
> +
> diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst
> index fe360d1..d299d04 100644
> --- a/policy/ap-pkg-diversions.rst
> +++ b/policy/ap-pkg-diversions.rst
> @@ -81,3 +81,6 @@ when the file does not exist.
>  Do not attempt to divert a conffile, as ``dpkg`` does not handle it
>  well.
>  
> +Do not use diversions for files that have their own native override 
> mechanisms,
> +such as ``systemd`` unit files. See :doc:`ch-binary` for more information.
> +
> diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
> index e517f26..19635e7 100644
> --- a/policy/ch-binary.rst
> +++ b/policy/ch-binary.rst
> @@ -371,6 +371,41 @@ against earlier versions of something that previously 
> did not use
>  ``update-alternatives``; this is an exception to the usual rule that
>  versioned conflicts should be avoided.)
>  
> +Diversions are primarily intended as a tool for local administrators or local
> +packages to override the behavior of Debian. While there are some 
> circumstances
> +where one Debian package may need to divert a file of another Debian package,
> +those circumstances are rare and diversions should only be used as a last 
> resort
> +when no other suitable mechanism exists. Diversion of a file in one Debian
> +package by another Debian package should be coordinated between the 
> maintainers
> +of those packages. Maintainers should strongly prefer using other overriding
> +mechanisms, instead of diversions, whenever those other mechanisms are
> +sufficient to accomplish the same goal. In other words, diversions in 
> packages
> +should be considered a last resort.
> +
> +One specific case of that rule is that configuration files used by
> +``systemd`` components, such as `units,
> +`_
> +`udev rules,
> +`_
> +`tmpfiles.d,
> +`_
> +`modules-load.d,
> +`_,
> +`sysusers
> +`_
> +and other such files, including those specific to systemd daemons
> +(e.g.:  `/etc/systemd/system.conf).
> +`_
> +must not be diverted by any Debian package. Instead, use `masking and 
> drop-ins
> +`_.
> +
> +Alternatives must never be used for ``systemd`` configuration files. The
> +alternatives system does not know how to apply changes to services when 
> updating
> +alternatives, so the resulting behavior would be confusing and unpredictable.
> +Instead, `aliases
> +`_
> +can be used to provide alternative implementations of the same named unit.
> +
 
seconded.

and wondering, if there should be a recommendation similar to consulting 
debian-devl@l.d.o
when introducing epochs, or...

..the other way round: should it be explicitly spelled out that, unlike for 
epochs, 
in general there's no need to consult -devel for diversions for packages as 
they are 
generally ment for local admins and only in very very very rare cases...

(maybe be even more verbose about "other overriding mechanisms"?!)

but in any case seconded, things can always be improved, and this is good.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Punk ist nicht tot.
Punk trägt Maske, ist solidarisch und schützt sich und andere.
(@Kreuzpirat)


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Holger Levsen]

On Wed, Jun 07, 2023 at 08:19:08AM -0700, Russ Allbery wrote:
> I would like to add more documentation like this around systemd-related
> things to Policy because systemd is complicated and has a lot of options,
> so people who aren't deeply familiar with it will easily miss best
> practices in its reams of very good but overwhelming documentation, and
> Debian should be opinionated about steering people towards best practices
> for our primary init system, just as we were very opinionated about how to
> write init scripts for sysvinit.
[...]
> I definitely agree that Policy should have a whole section devoted to
> systemd and its configuration files, but I don't want to try to boil the
> ocean in one bug.  But yes, we should be working towards that, IMO.

yes! (to everything in said email.) thank you.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Only change is constant.


signature.asc
Description: PGP signature

menu-policy still there and not-deprecated (Re: Bug#975631: debian-policy: window manager: remove reference to Debian menu)

[Holger Levsen]

hi,

someone on irc wondered about icons and Debian packages so I noticed
https://www.debian.org/doc/packaging-manuals/menu-policy/
prominently linked from https://www.debian.org/doc/devel-manuals#policy

But then I though the menu system has been deprecated as eg noted in
#975631:

On Tue, Nov 24, 2020 at 12:11:58PM +0100, Ansgar wrote:
> Section 11.8.4 "Packages providing a window manager" still references
> the Debian menu.  But the Debian menu is deprecated.

so I'm wondering whether the link to 
https://www.debian.org/doc/packaging-manuals/menu-policy/
should be dropped from https://www.debian.org/doc/devel-manuals#policy
?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Imagine god created trillions of galaxies but freaks out because some dude
kisses another.


signature.asc
Description: PGP signature

Re: Reducing allowed Vcs for packaging?

[Holger Levsen]

On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote:
> Why don't we just fix all those packacges, instead of changing any
> documents?  Is there anyone who actually wants to introduce new packages
> not using git?  I'm not so sure.

mostly agreed, i'm just sure there will be very few people who want that,
though for the scope of developers-reference I think those should be ignored.

that said, dev-ref currently only explicitly mentions vcs-git.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The mark of a civilized man is the ability to look at a column of numbers and
weep. (Bertrand Russell)


signature.asc
Description: PGP signature

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Holger Levsen]

On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote:
> I've created a PR for devref - 
> https://salsa.debian.org/debian/developers-reference/-/merge_requests/41
 
fwiw, merged into developers-reference 12.16 in sid.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

A ship is always safe at shore, but that is not what it's built for.
(Albert Einstein)

Bug#934536: info version shipped, but IMO complete, close this bug?

[Holger Levsen]

On Sun, Feb 12, 2023 at 06:56:28AM +0900, Osamu Aoki wrote:
> Yes, info version is included and it contains appendix, too.
> So closing this bug is right action.

thanks for confirming!

> Thanks for your effort.
 
:) thanks.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Dat gifft in Plattdüütschen keen Woort för „Flüchtlinge”. Dat sünd allens Lüüd, 
Mischen, Kinners, Olle, Froons, Mannslüüd, so as Du un Ick.


signature.asc
Description: PGP signature

Bug#934536: info version shipped, but IMO complete, close this bug?

[Holger Levsen]

hi,

actually I found the info version now, but it seems complete to me:

$ sudo apt install info
$ info developers-reference

# voila. /usr/share/info/developers-reference.info.gz is where the file is.

So I'm still inclined to close this bug.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Das Leben ist schön. Von 'einfach' war nie die Rede. (@lernzyklus)


signature.asc
Description: PGP signature

Bug#934536: info version not shipped, close this bug?

[Holger Levsen]

control: tags -1 +moreinfo
thanks

hi,

(originally sent to the wrong (but archived) bug number...)

we're not shipping the manual in .info format, so I'm wondering whether this
bug should simply be closed, or why not?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Another end of the world is possible.


signature.asc
Description: PGP signature

Bug#934527: update on appendix situation

[Holger Levsen]

hi,

some updates on this bug:

- the issue seems to have nothing to do with the single page html format,
  it's also present in the multi page html version, and the cause seems
  to be https://github.com/sphinx-doc/sphinx/issues/6614
- the issue is visible annoying in the generated package descriptions.
- the issue is less annoying in the HTML and epub versions, because there's
  the word 'appendix' prefacing the numbers.
- the issue is migated in the PDF version, where it's just chapter 9.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Es ist das laute Nein, hinter dem Ausrufezeichen stehen.


signature.asc
Description: PGP signature

Bug#801065: Documenting how to not fail postinst on service fails to starto

[Holger Levsen]

On Wed, Feb 08, 2023 at 06:39:08PM +0100, Bill Allombert wrote:
> Note that the TC declining to rule on an issue does not override the policy 
> group right to make
> a determination on that issue. So we are back to the situation before the 
> referral to the TC.
 
do you think #801065 should be assigned from developers-reference to
debian-policy?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's climate crime, not climate change.


signature.asc
Description: PGP signature

Bug#801065: consent unclear

[Holger Levsen]

On Wed, Feb 08, 2023 at 06:13:32PM +0100, Bill Allombert wrote:
> > not only based on that, but way more importantly that this would change
> > *years* of existing practice.
> Could you clarify which 'existing practices' ?
 
how Debian packages behaved in the last decades.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The wrong Amazon is burning.


signature.asc
Description: PGP signature

Bug#801065: Documenting how to not fail postinst on service fails to start

[Holger Levsen]

retitle -1 turn #904558 into advice - how postinst should deal with failures
thanks

On Wed, Feb 08, 2023 at 09:26:58AM -0700, Sam Hartman wrote:
> The TC bug is 904558.

thank you very much for this pointer, that's a pretty good discussion,
which resulted in

-

So, the TC declines to rule on what should maintscripts do when failing 
to
(re)start a service (or otherwise encountering a similarly serious
problem).

-
(read the full result at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904558#137 )

so I still think "#801065 discourage failing install or upgrade when service
fails to start" is the wrong recommendation for dev-ref.

That said, I'd still appreciate a patch that conveys the gist of #904558.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The apocalypse is here now, it’s just not equally distributed.


signature.asc
Description: PGP signature

Bug#801065: consent unclear

[Holger Levsen]

hi,

btw, as pointed out on irc: I ment consensus, not consent. :)

On Wed, Feb 08, 2023 at 10:36:02AM -0500, Marvin Renich wrote:
> > I don't think there has been consent on the issue, thus I'm tagging it
> > moreinfo.
> > 
> > I'm also wondering whether to mark this bug as wontfix (until there is
> > consent) or to reassign to debian-policy or simply to close it.
> 
> I disagree.  Re-reading the messages to the bug report, We have
> "strongly support" from Sam Hartman, and "also in favor" from Russ
> Allbery and Bill Allombert.
> 
> The only objection was from Henrique de Moraes Holschuh based on lack of
> risk assessment from the mistaken impression

not only based on that, but way more importantly that this would change
*years* of existing practice.

> What is being proposed in this bug is simply a change to the Developers
> Reference to encourage package maintainers to allow dpkg installation to
> succeed even if the service fails to start, unless the package
> maintainer has a specific reason to do otherwise.

"patches welcome", especially for something which some perceive as simple
change!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Stop saying that we are all in the same boat.
We’re all in the same storm. But we’re not all in the same boat.


signature.asc
Description: PGP signature

Bug#801065: Documenting how to not fail postinst on service fails to start

[Holger Levsen]

On Wed, Feb 08, 2023 at 08:39:36AM -0700, Sam Hartman wrote:
> >>>>> "Holger" == Holger Levsen  writes:
> Holger> I don't think there has been consent on the issue, thus I'm
> Holger> tagging it moreinfo.
> My reading of the TC and debian-devel discussion was that this was at
> least a reasonable thing for maintainers to do,

can you give pointers?

> and whether it should be done depended on the circumstances.

I do agree with that. I'm more against a general recommendation, depending
on the circumstances, it's the right thing to do.

> Holger, would you support adding a comment to 6.4 explaining how to do
> it?

surely.

> I'd write text but I'm honestly baffled how to accomplish this for
> systemd units with dh.
 
:)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.


signature.asc
Description: PGP signature

Bug#299927: debtags future unclear

[Holger Levsen]

control: tags -1 +moreinfo
control: affects -1 debtags
thanks

hi,

https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qe...@enricozini.org
and
https://lists.debian.org/msgid-search/bb7064071ebd838a9e045a1916bba49a9b960d80.ca...@debian.org
indicate that debtags.debian.org might be shutdown after the release
of bookworm, thus tagging this bug moreinfo for now, as there's not
much point documenting something which is going away.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

figures don't lie, but liars figure.


signature.asc
Description: PGP signature

Bug#829611: updated url

[Holger Levsen]

hi,

annex.debconf.org is gone, the slides are at 
https://salsa.debian.org/debconf-team/public/share/debconf16/-/raw/master/slides/13-we-need-you-to-release-debian.pdf


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Every time you see the word "smart" used to describe a device, replace it with
"surveillance." Surveillance watch. Surveillance streetlights. Surveillance
oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali)


signature.asc
Description: PGP signature

Bug#801065: consent unclear

[Holger Levsen]

control: tags -1 +moreinfo
thanks

hi,

I don't think there has been consent on the issue, thus I'm tagging it
moreinfo.

I'm also wondering whether to mark this bug as wontfix (until there is
consent) or to reassign to debian-policy or simply to close it.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Nach wieviel Einzelfällen wird ein Einzelfall zum Normalfall?
(Jan Böhmermann)


signature.asc
Description: PGP signature

Bug#660193: change trigged by this bug

[Holger Levsen]

hi,

the bug got closed, but not in vain:

commit 61a395888206b5ef45beb3d47d5ae81471f85c78
Author: Holger Levsen 
Date:   Mon Feb 6 20:11:22 2023 +0100

tools: add a pointer to https://wiki.debian.org/debian/watch
when watch files are mentioned. Thanks to #660193

Signed-off-by: Holger Levsen 

diff --git a/source/tools.rst b/source/tools.rst
index aabdf6f..18af8e4 100644
--- a/source/tools.rst
+++ b/source/tools.rst
@@ -396,8 +396,9 @@ helpful for maintaining your Debian packages. Example 
scripts include
 is a wrapper around ``dpkg-buildpackage``. The ``bts`` utility is also
 very helpful to update the state of bug reports on the command line.
 ``uscan`` can be used to watch for new upstream versions of your
-packages. ``suspicious-source`` outputs a list of files which are not
-common source files.
+packages (see https://wiki.debian.org/debian/watch for more info on that).
+``suspicious-source`` outputs a list of files which are not common source
+files.
 
 See the devscripts 1 manual page for a complete list of available
 scripts.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Ich bin so alt, ich hab im Kindergarten noch Aschenbecher getöpfert.
(@joanalistin)


signature.asc
Description: PGP signature

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Holger Levsen]

On Thu, Jan 19, 2023 at 11:28:41AM -0600, Gunnar Wolf wrote:
> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index ab04261..15b9343 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -24,11 +24,11 @@ The aims of this are:
>  
>  The *main* archive area forms the *Debian distribution*.
>  
> -Packages in the other archive areas (``contrib``, ``non-free``) are not
> -considered to be part of the Debian distribution, although we support
> -their use and provide infrastructure for them (such as our bug-tracking
> -system and mailing lists). This Debian Policy Manual applies to these
> -packages as well.
> +Packages in the other archive areas (``non-free-firmware``,
> +``contrib``, ``non-free``) are not considered to be part of the Debian
> +distribution, although we support their use and provide infrastructure
> +for them (such as our bug-tracking system and mailing lists). This
> +Debian Policy Manual applies to these packages as well.
>  
>  .. _s-dfsg:
>  
> @@ -130,6 +130,27 @@ In addition, the packages in *main*
>  
>  - must meet all policy requirements presented in this manual.
>  
> +.. _s-non-free-firmware:
> +
> +The non-free-firmware archive area
> +~~
> +
> +The *non-free-firmware* archive area contains packages providing
> +firmware needed to initialize, use or keep updated hardware required
> +by our users, typically necessary for important functions to be
> +available (i.e. wireless network connectivity) or for fixing security
> +defects in hardware (i.e. CPU microcode updates). Packages in this
> +archive may not comply with all of the policy requirements in this
> +manual due to lack of source code availability, restrictions on
> +modification or other limitations.
> +
> +Packages in *non-free-firmware*
> +
> +- must not be so buggy that we refuse to support them, and
> +
> +  - must meet all policy requiremens presented in this manual that it
> +is possible for them to meet.
> +
>  .. _s-contrib:
>  
>  The contrib archive area
> @@ -261,8 +282,8 @@ prohibited" and "distribution restricted".
>  Sections
>  
>  
> -The packages in the archive areas *main*, *contrib* and *non-free* are
> -grouped further into *sections* to simplify handling.
> +The packages in the archive areas *main*, *non-free-firmware*, *contrib*
> +and *non-free* are grouped further into *sections* to simplify handling.
>  
>  The archive area and section for each package should be specified in the
>  package's ``Section`` control record (see
> @@ -272,8 +293,8 @@ the Debian distribution. The ``Section`` field should be 
> of the form:
>  
>  -  *section* if the package is in the *main* archive area,
>  
> --  *area/section* if the package is in the *contrib* or *non-free*
> -   archive areas.
> +-  *area/section* if the package is in the *non-free-firmware*, *contrib*
> +   or *non-free* archive areas.
>  
>  The Debian archive maintainers provide the authoritative list of
>  sections. At present, they are: admin, cli-mono, comm, database, debug,

seconded, with or without the minor fixes by James Addison. thanks!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you upload your address book to "the cloud", I don't want to be in it.


signature.asc
Description: PGP signature

Re: new policy upload before the freeze?

[Holger Levsen]

On Thu, Dec 15, 2022 at 01:25:10PM -0700, Sean Whitton wrote:
> Thanks Holger for pointing this out.  I'll cut a release today or
> tomorrow.

\o/ & thank you!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"The two hardest problems in computer science are: (i) people, (ii), convincing
computer scientists that the hardest problem in computer science is people, and,
(iii) off by one errors." - Jeffrey P. Bigham


signature.asc
Description: PGP signature

new policy upload before the freeze?

[Holger Levsen]

hi,

do you plan to release a new version of debian-policy before the freeze
in January?

I'm wondering whether I should start polishing uploads now or better
wait.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The pandemic isn’t over. We just stopped caring about other people.


signature.asc
Description: PGP signature

Bug#1015784: source-only upload requirement not documented

[Holger Levsen]

hi Simon,

On Sun, Nov 13, 2022 at 03:49:13PM +, Simon McVittie wrote:
> I've had the attached sitting in my outbox for a while and I think it's at
> least a good start towards what Marc requests?

yes, thanks a lot!

> I have deliberately not documented the precise meaning of needing to
> include binary packages for NEW, on the basis that the conservative thing
> to do is to include a complete set (debuild --full). My understanding is
> that *technically*, the upload does not need to include *every* binary
> package, but that the ftp team would prefer uploads to NEW to include
> everything from debuild --full, except in rare special cases such as
> the kernel, whose maintainers already know what all the tradeoffs are.

this could also change very easily, there's already an option in dak
which allows throwing away binaries after the package passed NEW.
(=this would mean one needs to upload a binary build to NEW still, 
however the binaries would be thrown away when the packages moves
to unstable, thus automatically triggering a build on the buildds,
allowing testing migration later.)
this option has not been enabled yet however.

> Similarly, I have deliberately been a bit vague about whether uploads
> that will add a package to a suite other than unstable/experimental
> need binaries, because I don't know whether they do or
> not. unstable/experimental NEW definitely needs binaries, I *think*
> backports-NEW also needs binaries but I'm not sure,

I think so too.

> but I think new
> additions to -security can/should be source-only?

no idea :)

> I have also not attempted to improve §5.10 "Porting and being ported",
> which seems to have been written from a circa 1998 perspective where all
> maintainers uploaded source+i386, binaries for other architectures were
> often hand-built by porting teams, and the ability for a package to be
> autobuilt successfully was somewhere between "optional but recommended"
> and "newly required". It could probably benefit from restructuring or a
> rewrite, but I don't think I'm the right writer for that.

*nods*

> > I THINK that arch any packages get an automatic binNMU to avoid that.
> My understanding is that the release team often schedule a binNMU to
> be helpful, but it is not automatic. 

yes, it's scripted but needs to be triggered manually. also this doesnt
work for arch:all packages.

> We can give simpler advice if we
> ignore these binNMUs, which seems better to me anyway - maintainers of
> source packages with at least one "Architecture: all" binary package
> have to do a sourceful upload regardless, and I'd prefer to encourage
> maintainers to be responsible for their packages' migration to testing
> rather than centralising that responsibility into the release team.

same here.

thanks again, will merge and upload now! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Punk ist nicht tot.
Punk trägt Maske, ist solidarisch und schützt sich und andere.
(@Kreuzpirat)


signature.asc
Description: PGP signature

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Holger Levsen]

On Mon, Sep 26, 2022 at 10:15:07AM +0200, Wouter Verhelst wrote:
> Experimental is different because it is an incomplete distribution,
> which needs to default to using packages from unstable except if
> build-depends explicitly lists versions that are only available in
> experimental.
[...]

Thanks, Wouter. I guess backports is rather similar. 


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Money is worth nothing on a dead planet.


signature.asc
Description: PGP signature

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Holger Levsen]

On Fri, Sep 23, 2022 at 04:17:04PM +0100, Simon McVittie wrote:
> On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote:
> > I also reworded the paragraph about backports to hopefully address
> > Holger's reading.  It's just trying to say that backports uses aptitude in
> > the normal way and doesn't do anything special to transform the
> > alternative.
 
yup, it's better, thanks.

> It's perhaps worth mentioning that experimental does something similar
> (it has used the aptitude and aspcud resolvers at various times, but
> I'm not sure which one is currently in use).

I see.

I think my biggest concern is actually not how it's described but rather
why/that it is different at all (and then wondering whether it will stay
that way...)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes... (Greta Thunberg)


signature.asc
Description: PGP signature

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Holger Levsen]

On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> +The autobuilders for the Debian backports suite do not perform this
> +transformation and instead use the full alternatives list to resolve
> +dependencies.
 
this sounds like they install all build depends, incl alternative ones?!
is that really the case? (and why?)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Make facts great again.


signature.asc
Description: PGP signature

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Holger Levsen]

On Tue, Sep 20, 2022 at 06:39:11PM -0700, Russ Allbery wrote:
> Here is proposed wording that I think is ready for seconds.
> 
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 18:35:55 -0700
> Subject: [PATCH] Clarify udeb-only source packages are out of scope
> 
> Note that source packages that only produce udebs are, like udebs,
> out of scope and may not follow all of the requirements of Policy.
> 
> Say explicitly in the Standards-Version description that udebs and
> source packages that only produce udebs do not use Standards-Version.
> ---
>  policy/ch-controlfields.rst |  3 +++
>  policy/ch-scope.rst | 10 +-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..ea8f4a3 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -540,6 +540,9 @@ Thus only the first three components of the policy 
> version are
>  significant in the *Standards-Version* control field, and so either
>  these three components or all four components may be specified. [#]_
>  
> +udebs and source packages that only produce udebs do not use
> +``Standards-Version``.
> +
>  .. _s-f-Version:
>  
>  ``Version``
> diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
> index 289c9a9..a279c26 100644
> --- a/policy/ch-scope.rst
> +++ b/policy/ch-scope.rst
> @@ -71,11 +71,11 @@ Much of the information presented in this manual will be 
> useful even
>  when building a package which is to be distributed in some other way or
>  is intended for local use only.
>  
> -udebs (stripped-down binary packages used by the Debian Installer) do
> -not comply with all of the requirements discussed here. See the `Debian
> -Installer internals
> -manual `_ for
> -more information about them.
> +udebs (stripped-down binary packages used by the Debian Installer) and
> +source packages that produce only udebs do not comply with all of the
> +requirements discussed here. See the `Debian Installer internals manual
> +`_ for more information
> +about them.

seconded, thanks.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not the lockdown which is unbearable, but the virus.


signature.asc
Description: PGP signature

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Holger Levsen]

On Mon, Sep 19, 2022 at 09:29:36PM -0700, Russ Allbery wrote:
> I'm fine with this change, but as Sam points out, the deeper point here is
> that Policy doesn't apply to udebs.  This is the whole point of udebs.

When you say it like this, it sounds to strong to me, if it were written in
-policy.

.udebs are allowed to break some rules, but not all. it's not ok to put
Microsoft Word in an udeb in main. there are many other rules .debs need to
comply to.

> udebs (stripped-down binary packages used by the Debian Installer) do
> not comply with all of the requirements discussed here. See the Debian
> Installer internals manual for more information about them.
 
this sounds good to me.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Where will your kids go when they become climate refugees?


signature.asc
Description: PGP signature

Bug#1015784: source-only upload requirement not documented

[Holger Levsen]

control: tags -1 wishlist
thanks

On Thu, Jul 21, 2022 at 10:44:26AM +0200, Marc Haber wrote:
> for a few years now, the Debian archive wants to see source-only
> uploads. This is not documented in the Developer's Reference and also
> now in the New Maintainer's Guide. It should be there.

I agree & thanks for filing this bug report. Downgrading to wishlist,
as devref is not *wrong*, just missing information.

Not tagging 'help' because then I could tag all devref bugs with it.
(maybe I should??)

Help *is* much welcome, either via a patch or directly commiting
to the master branch in git, which anyone in the Debian group on
salsa can do.

(and for those who havent noticed: devref is now developed in plain
markdown, so no more xml...)

> Also, it should be documented that the first upload of a new package to
> debian MUST be a source+binary upload. Arch all packages need another
> source-only upload after being accepted into the archive to be allowed
> to migrate to testing. I THINK that arch any packages get an automatic
> binNMU to avoid that.

I *believe* the latter is due to release team people being nice and proactive,
so it's not fully automatic.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The past is over.


signature.asc
Description: PGP signature

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Mon, Jun 20, 2022 at 07:43:45PM +0700, Teukumif tahulziran wrote:
> > 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.

as you say, it *might* be a good idea, but in our experience it's not practical
because too many sources cannot be rebuild reproducibly.

Also, and probably more importantly, it's quite unclear what the practical 
benefit is can you explain?

> > I haven't checked how many packages do not fulfill this condition

You should definitly do this before asking policy to be changed.
It's also not really hard, just loop through all source packages,
download them, rebuild them, compare.

And you might want to start with just the essential set. 

and, TBH, I'm pretty sure very few source packages can be rebuild 
reproducible. Proove me wrong! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The corona crisis is peanuts compared to the global climate disaster.


signature.asc
Description: PGP signature

Bug#986320: Stronger advice on when to use native packages

[Holger Levsen]

On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
> > Even if that consensus does not exist, there is probably consensus
> > that native packages are a poor match for large packages (because of
> > the inefficiency of making small updates to the packaging of native
> > packages),
> Do you mean large packages with a separate upstream existence, or
> large packages in general?  I don't think there's such a consensus for
> large packages in general: if Debian is the canonical place for a
> particular package to be released (e.g., as is true for dpkg), then it
> doesn't seem like it would be worth the overhead of making two
> releases, one upstream and one for packaging, whenever updating that
> package.
 
speaking as the debian-edu-artwork maintainer, which at one point in time
was a >50mb sized native package: it's pretty annoying to upload 50 or more
megabytes for a 2 byte fix of a maintainer script.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Humans despise their genitals so much they often use them as metaphors for
humans they dislike.


signature.asc
Description: PGP signature

Bug#930565: dev-ref: should use distro-info instead of hardcoding version numbers

[Holger Levsen]

On Wed, Mar 02, 2022 at 02:21:20PM +0100, kaliko wrote:
> On Sat, 15 Jun 2019 16:26:33 +0000 Holger Levsen 
> wrote:
> > […]
> > and then for bullseye we should use distro-info(-data). (wondering how
> > to do this sensibly at run time and not at build time...)
> What is "run time" for manual (pdf, html, etc…), do you mean when the manual
> is actually shown in the browser for instance with html?

could also be a monthly (?) cron job or some such.
 
> I was thinking about using python distro-info to set variables to format
> rst_epilog with along with _version and _date. But I guess this is not what
> you expect.

Ideally I'd like something that also works in a pdf viewer and for the txt
version.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We need to learn to live with cholera. What is the alternative? Breaking up
all streets, building drainage with toilets in every building? (@tadeas_)


signature.asc
Description: PGP signature

Bug#1006912: is it time to have account deletion in policy?

[Holger Levsen]

On Sat, Mar 12, 2022 at 01:21:24PM +0100, Marc Haber wrote:
> > unpredictable or non-deterministic allocation of such ids is a cause of non-
> > reproducibiliy for Debian images and installations, so us reproducible folks
> > would like to see "sensible" to be expanded to take reproducible builds into
> > account.
> So we should go (in Policy) more towards "dynamic global UIDs and GIDs
> which may post additional load towards the base-passwd maintainers?

I guess so, yes. :/

> Or would it be enough for reproducible images if adduser would finally
> implement #243929, making it possible to pre-determine UIDs before an
> image is built?

for reproducible images it would be 'enough' but I believe this would also shift
the burden of the work to each and every image designer, so in a way this feels
like a workaround with the main purpose of removing load from base-passwd
maintenance while putting load on everyone else forever :/

Roland Clobus has put a lot of work & thoughts into reproducible images, so I've
added him to cc: now, so he can comment on this aspect of #1006912.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Smart things make us dumb.


signature.asc
Description: PGP signature

Bug#1006912: is it time to have account deletion in policy?

[Holger Levsen]

Hi Marc,

On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote:
> This is my patch.

I like your patch. :) I just have one comment:

> +``Dynamic local`` allocated ids should by default be arranged in some
> +sensible order, but the behavior should be configurable.

unpredictable or non-deterministic allocation of such ids is a cause of non-
reproducibiliy for Debian images and installations, so us reproducible folks
would like to see "sensible" to be expanded to take reproducible builds into
account.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Ich dachte immer, jeder sei gegen den Krieg, bis ich herausfand, dass es
 welche gibt, die nicht hingehen müssen.“ (Erich Maria Remarque)


signature.asc
Description: PGP signature

Bug#1005357: developers-reference: fix formatting issues in French translation

[Holger Levsen]

control: tags -1 + pending
thanks

Hi Philippe,

On Fri, Feb 11, 2022 at 11:01:29PM +0100, Philippe SWARTVAGHER wrote:
> (first bug report and patch to Debian here ! :) )

whhooo, congrats! And thank you very much!
 
> I attach a patch fixing some minor formatting issues in the French
> translation of the documentation.

& extra thanks for providing a git patch! merged & will be included in the
next upload! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Plastic bottles: made to last forever, designed to throw away.


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Holger Levsen]

On Sun, Dec 12, 2021 at 06:47:21PM +0100, Mattia Rizzolo wrote:
> On Sun, Oct 31, 2021 at 11:18:35AM +0100, Mattia Rizzolo wrote:
> > If I get no pushbacks I'll also propose some text later on when I'm
> > freer (unless somebody beats me to it!).
> 
> I'm hereby seeking seconds (or, well, suggestions for improvements) for
> the following diff, which is based on
> daa7d69fbffc1c438002993860f0df407e4aaeb1 (4.6.0.1):
> 
> |--- a/policy/ch-controlfields.rst
> |+++ b/policy/ch-controlfields.rst
> |@@ -131,6 +131,8 @@ package) are:
> | 
> | -  :ref:`Rules-Requires-Root `
> | 
> |+-  :ref:`Description `
> |+
> | The fields in the binary package paragraphs are:
> | 
> | -  :ref:`Package ` (mandatory)
> |@@ -652,9 +654,14 @@ orderings.  [#]_
> | ~~~
> | 
> | In a source or binary control file, the ``Description`` field contains a
> |-description of the binary package, consisting of two parts, the synopsis
> |-or the short description, and the long description. It is a multiline
> |-field with the following format:
> |+description of the package, consisting of two parts, the synopsis or the 
> short
> |+description, and the long description.
> |+
> |+When used in a source control file in the general paragraph (i.e., the first

I believe the 2nd "in" in this line is too much.

> |+one, for the source package), the text in this field is relevant for all 
> binary
> |+packages built by the given source package.

and then I'd rewrite "the general paragraph (i.e., the first one, for 
the source package)" into "the first paragraph" and the whole paragraph into

When used in a source control file the first paragraph is used as the first
paragraph for all binary packages built by the given source package.

> |+
> |+It is a multiline field with the following format:

I'd second this change too.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This is the year of gpg on the desktop! (Gunnar Wolf)


signature.asc
Description: PGP signature

Bug#999826: debian-policy: fix Build-Depends footnoteo

[Holger Levsen]

On Wed, Nov 17, 2021 at 03:11:55PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> > This footnote might not be the best place to document the precise behaviour
> > of autobuilders (which currently is outside the scope of policy). On the
> > other hand, having a fully specified build process could reduce build
> > variability and make builds more reproducible.
> Do you have suggestions for a better place to document this?

src:developers-reference maybe? with a pointer to it in -policy?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

:wq


signature.asc
Description: PGP signature

Re: Bug#999598: dpkg-dev: Can we have binary package descriptions back for source uploads?

[Holger Levsen]

hi,

(leaving full context for debian-policy@l.d.o)

On Sat, Nov 13, 2021 at 06:56:24AM +0100, Petter Reinholdtsen wrote:
> Package: dpkg-dev
> Version: 1.20.9
> 
> Dear dpkg-dev developers,
> 
> One feature that is deeply missed, and which disappered when we moved to
> source only uploads, is the listing of binary package descriptions in
> the email to debian-devel-chan...@lists.debian.org.
> 
> The emails used to have a section like this, listing the short
> description of each binary package:
> 
>   Description: 
>gdm- GNOME Display Manager
> 
> I used this to see if a package I never heard about could be interesting
> to check out or not.  After we moved to source only uploads to unstable,
> there is no Description section any more in the emails, and it is a lot
> harder to guess what the odd packages are useful for.
> 
> The email content is simply the uploaded .changes file.
> 
> Would it be possible to adjust the .changes generator to include the
> description of all binary packages listed in d/control, even if none of
> them are included in the upload?

IMO this would only be a clumsy workaround (esp for packages with many binary
package) and we should rather fix the cause:
 
#963524 debian-policy: Binary and Description fields not mandatory in .changes 
on source-only uploads
#998165 debian-policy: document and allow Description in the source paragraph
#998282 Please make Section a required field for the source paragraph in 
d/control

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#19 is a nice example
how this would work in practice.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you own several guns but no guitars, you are doing life all wrong.


signature.asc
Description: PGP signature

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Holger Levsen]

On Fri, Oct 29, 2021 at 10:51:44AM +0100, Simon McVittie wrote:
> Here are some updated patches for Policy, incorporating this requirement.

thanks for your work on this, Simon.
 
> I have not attempted to incorporate the corner case involving
> build-profiles. I think if we were going to do that, it would require
> documenting build-profiles first (#757760), and maybe even then it's too
> much of a corner-case to be documenting unless/until it actually happens.

sounds good.

> From a332e4e787837cac0856c9c36d6e87e9f19197e2 Mon Sep 17 00:00:00 2001
> From: Simon McVittie 
> Date: Thu, 9 Sep 2021 15:43:20 +0100
> Subject: [PATCH 1/2] archive: Point out that mixed main/contrib source
>  packages can exist
> 
> Most source packages produce only binary packages in the same archive
> area, but a few source packages in main (such as bumblebee) produce
> a mixture of main and contrib binary packages.
> 
> If an upstream project is in this situation (for example a program with
> optional plugins that have non-free dependencies) it isn't entirely
> obvious how to package it; clarify that a single source package in main
> is considered to be appropriate in this case, as long as no non-free
> build-dependencies are required.
> 
> Signed-off-by: Simon McVittie 
> Closes: #994008
> ---
>  policy/ch-archive.rst | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index ab04261..3d40f55 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -130,6 +130,27 @@ In addition, the packages in *main*
>  
>  - must meet all policy requirements presented in this manual.
>  
> +If a source package is in the *main* archive area, then at least one of
> +the binary packages that it produces must be in the *main* archive area,
> +and each of the remaining packages must be in either the *main* or *contrib*
> +archive area. Each binary package's archive area is indicated by its
> +``Section`` field: see :ref:`s-subsections`.
> +
> +Source packages in *main* with a mixture of *main* and *contrib* binary
> +packages should be limited to situations where it would be inconvenient
> +to split the source package. If it is straightforward to split the source
> +package into a *main* part and a *contrib* part that are compiled
> +separately, then those parts should be represented as separate source
> +packages.
> +
> +When a *main* source package has a mixture of *main* and *contrib*
> +binary packages, the source package and the *main* binary packages must
> +follow the requirements for *main* packages, but the *contrib* binary
> +packages may follow the weaker requirements for *contrib* packages.
> +In particular, build-dependencies outside *main* are not allowed in
> +these source packages, but the *contrib* binary packages may have runtime
> +dependencies outside *main*.
> +
>  .. _s-contrib:
>  
>  The contrib archive area
> -- 
> 2.33.1

seconded.

maybe it would be better to replace 'complied' with 'build' in the patch
above? Obviously I'd also second this patch with that replacement...


> From 14cd80454fc2ef8122315a1edcc05eed43106583 Mon Sep 17 00:00:00 2001
> From: Simon McVittie 
> Date: Thu, 9 Sep 2021 15:53:20 +0100
> Subject: [PATCH 2/2] archive: Clarify binaries produced by contrib and
>  non-free source
> 
> A source package outside main cannot produce main binary packages, because
> we want main to be self-contained: if you download all main source
> packages, that should give you the source code of all main binary
> packages.
> 
> A source package in contrib cannot produce non-free binary packages,
> because by definition contrib only contains free software (with non-free
> dependencies, but those are not part of the source code).
> 
> A source package in non-free cannot produce contrib binary packages,
> because we want main + contrib to be self-contained: if you download
> all main or contrib source packages, that should give you the source
> code of all main and contrib binary packages.
> 
> Signed-off-by: Simon McVittie 
> ---
>  policy/ch-archive.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index 3d40f55..0979d87 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -177,6 +177,10 @@ Examples of packages which would be included in 
> *contrib* are:
>  -  wrapper packages or other sorts of free accessories for non-free
> programs.
>  
> +If a source package is in the *contrib* archive area, then each of the
> +binary packages that it produces must also be in the *contrib* archive
> +area.
> +
>  .. _s-non-free:
>  
>  The non-free archive area
> @@ -199,6 +203,10 @@ In addition, the packages in *non-free*
>  -  must meet all policy requirements presented in this manual that it is
> possible for them to meet.  [#]_
>  
> +If a source package is in the *non-free* archive area, then each of the
> +binary packages that it produces must 

Bug#337086: provide a link to the Debian Security Manual

[Holger Levsen]

Hi Marco,

On Mon, Aug 30, 2021 at 09:48:50PM -0500, Marco Villegas wrote:
> It seems like the mentioned link[1] is not working anymore, and looking
> around a bit it seems to be at [2] now instead.

agreed.

> I was thinking about the right place to add the link to.
> Even if there are some sections related to security, namely _Security
> uploads_ and _Handling security-related bugs_, they are only
> tangentially related to the contents for the linked resource.
> 
> Hence, instead of adding it to an existing section, I have created a new
> one inside the _Best Packaging Practices_ section. This could also be
> useful if more information about security, or other links are wanted to
> be added in the future. The change is available at [3].
 
awesome, thank you very much! merged into the main branch. will
release soon.

plus <3 for updating the .po files too! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Not everything was bad during capitalism.


signature.asc
Description: PGP signature

Bug#990054: developers-reference: Please replace words about freenode irc network

[Holger Levsen]

On Fri, Jun 18, 2021 at 04:56:25PM -0400, Boyuan Yang wrote:
> According to
> https://lists.debian.org/debian-devel-announce/2021/06/msg2.html ,
> Debian's presence on Freenode has ceased. However,
> https://www.debian.org/doc/manuals/developers-reference/resources.html#irc-channels
> still mentions freenode IRC network and provides link to external freenode
> documentation. Please consider updating the content and possibly provide
> pointers to https://libera.chat/ .

ack, patches or better commits welcome. developers-reference is free to push
for all Debian developers. 

that said, cc:ing urbec who has a more or less ready patch somewhere...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Encryption is like pregnancy. Either something is end to end encrypted or it's
not.  If there are backdoors,  they will be open to anyone eventually and thus
encryption with backdoors is like there's no encryption at all.
 Privacy and thus encryption are human rights.


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Holger Levsen]

On Fri, Apr 02, 2021 at 10:26:47AM -0700, Russ Allbery wrote:
> I'll therefore propose that we move the discussion of whether to give
> stronger advice on when to use native packages to a separate bug.  Once
> this is merged, there will be some text in Policy defining native
> packages, so it will be easier to work on that.
> 
> Sound good?

sounds good, thanks!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Holger Levsen]

Hi Russ,

On Thu, Apr 01, 2021 at 06:17:59PM -0700, Russ Allbery wrote:
> Here is an updated diff that documents the most well-understood version
> conventions in the Debian archive.  More could certainly be added; this is
> just a first start that addresses this specific bug.

thank you for this, I've reviewed it and am generally very happy with these
changes.

> This revised patch is less aggressive about defining native packages to
> only mean packages with no existence external to Debian. 

I'm not sure if in this regard I would have liked the previous version better,
as the paragraph about native packages is the only one which I would like to
see extended to explain that it has been observed that packages we thought 
were native to Debian were not really native to Debian at all and require
modifications in Debian downstream distributions, which are harder to do
when the packages are native (eg modified orig.tar's despite no upstream 
changes).

src:piuparts is one example for this where this is even annoying within
Debian, as eg piuparts 1.1.2 was uploaded to sid and then that orig tarball
cannot be used for the upload to backports.

Also big/huge native packages are also annoying to maintain when one has
to do small packaging changes and each time has to upload huge orig.tar.
This was annoying when src:debian-edu-artwork was 50-100mb and native, today
that package is 8mb and non-native.

> I think this change is ready for seconds.

All that said, I'm still happy to second this! :)
 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..cd7daaa 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -582,20 +582,17 @@ The three components here are:
>  alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
>  tilde) and is compared in the same way as the ``upstream_version`` is.
>  
> -It is optional; if it isn't present then the ``upstream_version``
> -may not contain a hyphen. This format represents the case where a
> -piece of software was written specifically to be a Debian package,
> -where the Debian package source must always be identical to the
> -pristine source and therefore no revision indication is required.
> +It is conventional to restart the ``debian_revision`` at ``1`` each
> +time the ``upstream_version`` is increased.
>  
> -It is conventional to restart the ``debian_revision`` at ``1``
> -each time the ``upstream_version`` is increased.
> +The package management system will break the version number apart at
> +the last hyphen in the string (if there is one) to determine the
> +``upstream_version`` and ``debian_revision``. The absence of a
> +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
>  
> -The package management system will break the version number apart
> -at the last hyphen in the string (if there is one) to determine
> -the ``upstream_version`` and ``debian_revision``. The absence of a
> -``debian_revision`` is equivalent to a ``debian_revision`` of
> -``0``.
> +Presence of the ``debian_revision`` part indicates this package is a
> +non-native package (see :ref:`s-source-packages`).  Absence indicates
> +the package is a native package.
>  
>  When comparing two version numbers, first the epoch of each are
>  compared, then the ``upstream_version`` if epoch is equal, and then
> @@ -646,6 +643,83 @@ numbers containing strings of letters which the package 
> management
>  system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
>  orderings.  [#]_
>  
> +Special version conventions
> +^^^
> +
> +The following special version numbering conventions are used in the Debian
> +archive:
> +
> +- The absence of ``debian_revision``, and therefore of a hyphen in the
> +  version number, indicates that the package is native.
> +
> +- ``debian_revision`` components ending in ``.`` (period) followed by a
> +  number indicate this version of the non-native package was uploaded by
> +  someone other than the maintainer (an NMU or non-maintainer upload).
> +  This is used for a source package upload; for uploads of only binary
> +  packages without source changes, see the binary NMU convention below.
> +
> +- ``upstream_version`` components in native packages ending in ``+nmu``
> +  followed by a number indicate an NMU of a native package.  As with the
> +  convention for non-native packages, this is used for a source package
> +  upload, not for uploads of only binary packages without source changes.
> +
> +- ``upstream_version`` components in native packages or
> +  ``debian_revision`` components in non-native packages ending in ``+b``
> +  followed by a number indicate a binary NMU: an upload of a binary
> +  package without any source changes and hence without any corresponding
> +  source package upload or version change.
> +
> +- ``upstream_version`` 

Bug#975250: clarify gathering together of copyright information

[Holger Levsen]

On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote:
> My rationale is that debian/copyright is a summary, it's not the license
> text in the files.
> I absolutely agree we shouldn't go change people's actual copyright
> notices in the files.

that. and what Bill said.

> As a copyright holder I'd probably be more annoyed at the hyphen instead
> of the n-dash rather than the notice.  But that's  just me.
 
oh dear, you've send me into a small rabbit hole researching the distinctions
between hyphen, dash, hyphen-minus and the minus sign... :) thanks! :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

If secure encryption is outlawed, only criminals will have it.


signature.asc
Description: PGP signature

Bug#975250: clarify gathering together of copyright information

[Holger Levsen]

On Wed, Nov 25, 2020 at 03:32:04PM -0500, Sam Hartman wrote:
> I'd like to see people chime in who have not participated in the
> discussion yet.
 
AIUI the first year of contributions and the last year of contributions are
important data points for each contributor for a project, and mostly only
the last year as that might be used to calculate when a project becomes
public domain after the dead of an author.

So if I have contributed to something in 2018 and 2020 I find it ok to claim
'Copyright 2018-2020 Holger Levsen'. (Also because I might not have commited
something in 2019 but you have no idea how much I prepared my 2020 commits
in 2019...)

IANAL :) (and please correct me where I'm wrong, half right or whatever.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Never waste a crisis.


signature.asc
Description: PGP signature

Bug#974911: debian-policy: Date in documentation varies with timezone

[Holger Levsen]

On Mon, Nov 16, 2020 at 04:02:54AM -0800, Vagrant Cascadian wrote:
> While a consistent time was returned, depending on the timezone
> the package was built in can cause the date to vary:
> diff --git a/Makefile b/Makefile
> -DATE  := $(shell date -d '@$(TIMESTAMP)' +'%Y-%m-%d')
> +DATE  := $(shell date --utc -d '@$(TIMESTAMP)' +'%Y-%m-%d')

as debian-policy and developers-reference share quite some code I just checked
the Makefile of developers-reference and to my joy I found:

DATE  ?= $(shell date -u -d '@$(TIMESTAMP)' +'%Y-%m-%d')

:)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

If secure encryption is outlawed, only criminals will have it.


signature.asc
Description: PGP signature

Bug#971023: Version field (5.6.12) and colons

[Holger Levsen]

On Mon, Nov 09, 2020 at 12:12:18PM +0100, Mattia Rizzolo wrote:
> On Sat, Nov 07, 2020 at 01:01:28PM -0700, Sean Whitton wrote:
> > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > index 0d7a3e9..a21a510 100644
> > --- a/policy/ch-controlfields.rst
> > +++ b/policy/ch-controlfields.rst
> > @@ -552,8 +552,7 @@ The three components here are:
> > 
> >  ``epoch``
> >  This is a single (generally small) unsigned integer. It may be
> > -omitted, in which case zero is assumed. If it is omitted then the
> > -``upstream_version`` may not contain any colons.
> > +omitted, in which case zero is assumed.
> > 
> >  Epochs can help when the upstream version numbering scheme
> >  changes, but they must be used with care.  You should not change
> I don't consider this a normative change tbh (after the previous change
> already forbidding multiple colons).
> If it's really needed, consider it seconded by me.

I second the diff and what Mattia said.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

There are no jobs on a dead planet. (Also many other things but people mostly
seem to care about jobs.)


signature.asc
Description: PGP signature

Bug#228692: Bug#962384: Support for systemd-sysusers

[Holger Levsen]

On Tue, Jun 30, 2020 at 07:07:50PM +0200, Michael Biebl wrote:
> It's my understanding, that there is no clear consensus what should
> happen on package purge. Some packages do manually remove system users
> and go to some length to find files/directories owned by a system
> user/group and remove them.
> Some maintainers are of the opinion, that a system user once created
> should not be removed again.
> I think both viewpoints are valid, but the never-remove-a-system-user is
> probably the safer approach.

I actually thought we had consensus that system users should not be removed,
but couldnt find this documented neither in policy nor developers-reference
nor developers-reference's bugs or wiki.d.o pages with the the word user in
them. so, then I checked policy's bugs and found

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692#33

which is a nice description of the 2018 consensus about the bug from 2004
titled "User/group creation/removal in package maintainer scripts".

And to quote Russ from bug=228692#33: 'I think Policy should say something
like "created users and groups should not be removed by default, but may be
removed on purge if the local administrator explicitly requests this, either
for that package or as a system-wide default."

voila.

I'm bcc-ing #228692 as a ping (and so it won't get unneeded cc:s later.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Holger Levsen]

hi,

I'm not fully sure if people really intend to change the 1.0 format, but if so,
I'm against it. If you do it, please call it 1.1 or whatever, but please don't
change 1.0, too many tools rely on it's decade old behavior.

Besides that it's also my opinion that we should get rid off native packages
completly, though that's yet another discussion. Native packages made sense
when Debian had little or no downstreams, but...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#960926: developers-reference: updating the packages copyright notices

[Holger Levsen]

On Mon, May 18, 2020 at 03:46:05PM +0200, Raphael Hertzog wrote:
> > I'd appreciate a quick review and possible corrections from you!
> Fine for me.

:) thanks!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#960926: developers-reference: updating the packages copyright notices

[Holger Levsen]

Package: developers-reference
Version: 11.0.11
Severity: normal

Hi,

I'd like to update the copyright statements in d/changelog and and
source/index.rst and bring them in sync as well. Thus I have prepared
the following diff.

I'd appreciate a quick review and possible corrections from you!

Thank you for this and all your previous work on the reference!

$ git diff
diff --git a/debian/copyright b/debian/copyright
index 5f6e1f6..b28fa30 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,16 +1,17 @@
 
 This is the Debian package of the Debian Developer's Reference.  It
-was assembled by Christian Schwarz , has been maintained
-by Adam Di Carlo  and is now maintained by Andreas Barth
-.
+was originally assembled by Christian Schwarz .
 
 --
 Copyright of the Debian Developer's Reference:
 
-Copyright (c) 1997, 1998 Christian Schwarz; 
-  (c) 2002 - 2003 Raphaël Hertzog
+Copyright (c) 1997 - 1998 Christian Schwarz
   (c) 1998 - 2003 Adam Di Carlo
+  (c) 2002 - 2009 Raphaël Hertzog
   (c) 2004 - 2007 Andreas Barth
+  (c) 2008 - 2015 Lucas Nussbaum
+  (c) 2015 - 2020 Hideki Yamane
+  (c) 2019 - 2020 Holger Levsen
 
 This manual is free software; you may redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
diff --git a/source/index.rst b/source/index.rst
index a3d04b9..08922c1 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -3,11 +3,13 @@ Debian Developer's Reference
 
 Developer's Reference Team 
 
-* Copyright © 2004, 2005, 2006, 2007 Andreas Barth
-* Copyright © 1998, 1999, 2000, 2001, 2002, 2003 Adam Di Carlo
-* Copyright © 2002, 2003, 2008, 2009 Raphaël Hertzog
-* Copyright © 2008, 2009 Lucas Nussbaum
-* Copyright © 1997, 1998 Christian Schwarz
+* Copyright © 2019 - 2020 Holger Levsen
+* Copyright © 2015 - 2020 Hideki Yamane
+* Copyright © 2008 - 2015 Lucas Nussbaum
+* Copyright © 2004 - 2007 Andreas Barth
+* Copyright © 2002 - 2009 Raphaël Hertzog
+* Copyright © 1998 - 2003 Adam Di Carlo
+* Copyright © 1997 - 1998 Christian Schwarz
 
 This manual is free software; you may redistribute it and/or modify it under
 the terms of the GNU General Public License as published by the Free Software



In case you are interested, 
https://salsa.debian.org/debian/developers-reference.git
has it all today. Thanks again!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#956818: developers-reference: contradictory information about removing packages from Incoming

[Holger Levsen]

control: tags -1 + pending
thanks

On Fri, Apr 24, 2020 at 05:46:06AM +0700, Judit Foglszinger wrote:
> Added a patch for clarifying removability from upload queue.

thank you very much! merged to master and updated .po files. (I vaguely plan an
upload before the end of the month.)

> Subject: [PATCH] Adding footnote clarifying removability of packages from the
>  upload queue

minor nitpicks, which I've fixed in the applied patch:

- prephased the message with 'pkgs:' to indicate where the change was made, 
  to ease good d/changelog assembling later.
- added a 'Closes: #956818' at the end.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#956818: developers-reference: contradictory information about removing packages from Incoming

[Holger Levsen]

On Wed, Apr 15, 2020 at 06:33:29PM +0200, Bill Allombert wrote:
> > In section 5.6.1, it is mentioned that the dcut command can be used to
> > remove packages from the upload queue.
> > However, section 5.9.2.1 states that it is no longer possible to remove
> > packages from incoming.
> > This seems contradictory.
> It is not. The upload queue and incoming are separate entities.
> Package are uploaded to the upload queue, then the signature are checked
> and they are moved to incoming.

I'd still happily take a patch which clarifies this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#908155: Bug #908155 in developers-reference marked as pending

[Holger Levsen]

Hi Moritz,

On Thu, Apr 09, 2020 at 08:32:58AM +0200, Moritz Mühlenhoff wrote:
> The current version in unstable (11.0.10) again reads:
> | If it's an upstream problem, you have to forward it to the upstream author.
> | Forwarding a bug is not enough, you have to check at each release if the
> | bug has been fixed or not.

where exactly do you see this? I don't see it on 
https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#coordination-with-upstream-developers
nor in source/developer-duties.rst in the source git repo.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


signature.asc
Description: PGP signature

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Holger Levsen]

Hi Daniel,

On Sat, Mar 14, 2020 at 06:14:02PM +, Daniel Shahaf wrote:
> The documentation of the "Closes: #NN" changelog syntax describes
> the syntax in terms of a Perl regular expression.  However, not all
> readers know Perl.  I suggest to describe the semantics in English,
> in addition to or instead of the description in Perl.

oh, wow, ❤️ , very nice catch! 

> -   /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i

the english version is so much easier to read. thanks a lot!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Holger Levsen]

Hi Simon, everyone:

On Fri, Mar 13, 2020 at 11:32:00AM +, Simon McVittie wrote:
> To be completely clear about this for those using this bug report as a
> stand-in for the requested documentation in devref (like me), it's now at:
> https://auth.buildd.debian.org/auth/giveback.cgi?pkg===

I'd be very glad to review(, improve) and merge a patch... ;)

(dev-ref is written in markdown nowadays, so a plaintext patch with the wording
would be sufficient^wwonderful as well.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

[Holger Levsen]

Hi,

thanks for your feedback, I've now rewritten the paragraph in question
to simply read:


If you need to check for the existence of a command, you should use
something like

::

   if command -v install-docs > /dev/null; then ...

You can use this function to search ``$PATH`` for a command name, passed
as an argument. It returns true (zero) if the command was found, and
false if not. This is really the best way, since ``command -v`` is a
shell-builtin for many shells and is defined in POSIX.

Using ``which`` is an acceptable alternative, since it is from the required
``debianutils`` package.


I think this is much better.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Holger Levsen]

On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
> Changes:
> 
> * Add "prohibited" to the terms for requirements
> * Add another tier (Policy advice) using encouraged and discouraged
> * Stop confusing may and optional with wishlist bugs
> * Add terms for the collective set of Policy requirements at each tier
> * Explicitly state the long-standing policy that the release team determines
>   release-critical bugs

wow, nice!

> diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
> index 2404e84..98983e9 100644
> --- a/policy/ch-scope.rst
> +++ b/policy/ch-scope.rst
> @@ -31,21 +31,41 @@ part of Debian policy itself.
>  The appendices to this manual are not necessarily normative, either.
>  Please see :doc:`ap-pkg-scope` for more information.
>  
> -In the normative part of this manual, the words *must*, *should* and
> -*may*, and the adjectives *required*, *recommended* and *optional*, are
> -used to distinguish the significance of the various guidelines in this
> -policy document. Packages that do not conform to the guidelines denoted
> -by *must* (or *required*) will generally not be considered acceptable
> -for the Debian distribution. Non-conformance with guidelines denoted by
> -*should* (or *recommended*) will generally be considered a bug, but will
> -not necessarily render a package unsuitable for distribution. Guidelines
> -denoted by *may* (or *optional*) are truly optional and adherence is
> -left to the maintainer's discretion.
> -
> -These classifications are roughly equivalent to the bug severities
> -*serious* (for *must* or *required* directive violations), *minor*,
> -*normal* or *important* (for *should* or *recommended* directive
> -violations) and *wishlist* (for *optional* items).  [#]_
> +In the normative part of this manual, the following terms are used to
> +describe the importance of each statement:  [#]_
> +
> +* The terms *must* and *must not*, and the adjectives *required* and
> +  *prohibited*, denote strong requirements. Packages that do not conform
> +  to these requirements will generally not be considered acceptable for
> +  the Debian distribution. These statements correspond to the *critical*,
> +  *grave*, and *serious* bug severities (normally serious). They are
> +  collectively called *Policy requirements*.
> +
> +* The terms *should* and *should not*, and the adjective *recommended*,
> +  denote best practices. Non-conformance with these guidelines will
> +  generally be considered a bug, but will not necessarily render a package
> +  unsuitable for distribution. These statements correspond to bug
> +  severities of *important*, *normal*, and *minor*. They are collectively
> +  called *Policy recommendations*.
> +
> +* The adjectives *encouraged* and *discouraged* denote places where Policy
> +  offers advice to maintainers, but maintainers are free to follow or not
> +  follow that advice. Non-conformance with this advice is normally not
> +  considered a bug; if a bug seems worthwhile, normally it would have a
> +  severity of *wishlist*. These statements are collectively calld *Policy
> +  advice*.
> +
> +* The term *may* and the adjective *optional* are sometimes used to
> +  clarify cases where it may otherwise appear that Policy is specifying a
> +  requirement or recommendation. These words describe decisions that are
> +  truly optional and at the maintainer's discretion.
> +
> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is intended to provide flexibility to balance the
> +quality standards of the distribution against the release schedule and the
> +importance of making a stable release.
 
seconded, thank you.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#904246: developers-reference: section 6.4 should recommend command -v, not which

[Holger Levsen]

hi Sean,

On Sun, Jul 22, 2018 at 03:54:05PM +0800, Sean Whitton wrote:
> Section 6.4 should perhaps recommend `command -v` not `which`, because
> Debian Policy 4.1.5.0 allows maintainer scripts to assume SUSv4, which
> requires support for `command -v`.

three comments: 

a.) 'should perhaps' is a pretty weak statement ;p 
b.) whats SUSv4?
c.) I'm pondering to mention both but recommend "the winner" once I
learned about SUSv4 - or do you think that's a bad idea?

> Additionally see the discussion in #747320, where Jakub Wilk does point
> out that maintainer scripts may assume /usr is mounted, so I'm not sure
> about this.

how is it relevant if /usr is mounted? if its not, both 'which' and '-v' can
fail...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941198: initscripts: packages should ship systemd units

[Holger Levsen]

On Fri, Nov 01, 2019 at 11:20:59AM -0700, Russ Allbery wrote:
> > I think there is already a lintian warning:
> >   
> > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
> Oh!  I should have checked rather than assuming.  It would ideally be nice
> to make it a warning rather than a pedantic tag before we add it to
> Policy, but meh, and the count of tags isn't all that high.

from:

 lintian (2.33.0) unstable; urgency=medium
 .
   [ Chris Lamb ]
   * Upgrade the severity of missing-systemd-service-for-init.d-script from
 pedantic to a warning. (Closes: #943957)

:)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#934528: email gate and db/LDAP

[Holger Levsen]

On Thu, Oct 31, 2019 at 09:10:42PM +0100, Ansgar wrote:
> Sure, changes@db.d.o still works and is the only way to configure some
> settings.  It is documented here: https://db.debian.org/doc-mail.html

aaah! I even use that regulary via a script in ~/bin here :)

So I guess for developers-reference we will just add a pointer to the
URL above, thanks!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#934528: email gate and db/LDAP

[Holger Levsen]

control: tags +1 moreinfo

On Sun, Aug 11, 2019 at 11:27:46PM +, Osamu Aoki wrote:
> Source: developers-reference
> Please mention email gate
>  https://lists.debian.org/debian-devel/1999/12/msg00627.html

does that even still work today? and if so, how?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941803: debian-policy: dependencies on font packages

[Holger Levsen]

On Wed, Oct 23, 2019 at 12:13:00PM -0700, Russ Allbery wrote:
> > From d5895ca185fa1d678a098697d9e1c601c84f45dd Mon Sep 17 00:00:00 2001
> > From: Stephen Kitt 
> > Date: Mon, 7 Oct 2019 21:09:52 +0200
> > Subject: [PATCH] Allow strong dependencies on X font packages
> 
> > The X server shipped in Debian no longer supports remote retrieval of
> > fonts from an X font server, so it no longer makes sense to forbid
> > packages from strongly depending on X font packages. On the contrary,
> > since local fonts are now the only way for an X program to obtain its
> > fonts, packages which require specific fonts to operate should depend
> > on the corresponding font package. (This is already common practice
> > for non-X font packages.)
> 
> > Closes: #941803
> > Signed-off-by: Stephen Kitt 
> > ---
> >  policy/ch-customized-programs.rst | 17 +
> >  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> > diff --git a/policy/ch-customized-programs.rst 
> > b/policy/ch-customized-programs.rst
> > index dbba4fc..dfe6ce4 100644
> > --- a/policy/ch-customized-programs.rst
> > +++ b/policy/ch-customized-programs.rst
> > @@ -380,11 +380,10 @@ themselves.
> >  1.  Fonts of any type supported by the X Window System must be in a
> >  separate binary package from any executables, libraries, or
> >  documentation (except that specific to the fonts shipped, such as
> > -their license information). If one or more of the fonts so packaged
> > -are necessary for proper operation of the package with which they
> > -are associated the font package may be Recommended; if the fonts
> > -merely provide an enhancement, a Suggests relationship may be used.
> > -Packages must not Depend on font packages.  [#]_
> > +their license information). Packages which require one or more of
> > +the fonts thus packaged should Depend on the font package; if the
> > +fonts merely provide an enhancement, a Recommends or Suggests
> > +relationship may be used.  [#]_
> >  
> >  2.  BDF fonts must be converted to PCF fonts with the ``bdftopcf``
> >  utility (available in the ``xfonts-utils`` package, ``gzip``\ ped,
> > @@ -617,9 +616,11 @@ installed in ``/usr/share/man/man6``.
> > Window System, however, must abide by this font policy.
> >  
> >  .. [#]
> > -   This is because the X server may retrieve fonts from the local file
> > -   system or over the network from an X font server; the Debian package
> > -   system is empowered to deal only with the local file system.
> > +   In the past, the X server could 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 retrieval.
> >  
> >  .. [#]
> > Note that this mechanism is not the same as using app-defaults;
 
seconded, thanks.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#942857: developers-reference: updates on debian.org mail handling updates

[Holger Levsen]

package: developers-reference
severity: wishlist

- Forwarded message from "Adam D. Barratt"  -

Date: Tue, 22 Oct 2019 05:59:08 +0100
From: "Adam D. Barratt" 
To: debian-devel-annou...@lists.debian.org
Subject: debian.org mail handling updates
Message-ID: <21e81b9e413c3b7c36ba271adbcf400b3dffa512.ca...@adam-barratt.org.uk>

[ TL;DR: the "default mail handling" option in LDAP now actually does
something by default :) and additional optional checks are available. ]

Hi,

This mail summarises recent updates to @debian.org mail handling.

All mail passing through the front-end mail servers is subject to a
number of mandatory checks that help to ensure that Debian's resources
are not overloaded. These mandatory checks include:
- "nomail" and "noservers" RBLs from SORBS;
- rate-limiting;
- fail2ban rules; and
- manually-curated blacklists.

Additionally, there are a number of optional checks which may be
controlled via your LDAP settings:
- greylisting;
- sender verification callouts;
- RBLs / RHSBLs such as Spamhaus XBL or SORBS "relay" RBL;
- malware scanning using clamav (with some unofficial signatures); and
- checking of URLs within a message body against the SURBL and Spamhaus
DBL.

The "mail content inspection action" setting can be used to determine
if the result of the final two checks should be to reject the mail,
blackhole it or deliver it to you with the addition of a header
indicating the issue.

Enabling "default mail handling" indicates that you accept DSA's
choices regarding @debian.org mail handling. In addition to the
mandatory checks mentioned above, this currently means that the
following optional checks are enabled:
- greylisting;
- Spamhaus XBL
- SORBS "relay" RBL
- Spamhaus DBL for sender address

Finally, documentation on @debian.org mail handling can be found at 
https://db.debian.org/forward.html, whilst all of the configuration
relating to "default mail handing" comes from DSA's Puppet repository,
a mirror of which can be found on Salsa. DSA may alter the mandatory
checks and/or the optional checks enabled by "default mail handling" as
necessary.

Adam
wrangling exim on behalf of DSA



- End forwarded message -

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#288822: marked as done (developers-reference: "Bugs" control field not documented)

[Holger Levsen]

On Wed, Oct 09, 2019 at 08:30:03PM +0200, Guillem Jover wrote:
> > thanks for that information! do you agree there's nothing to be added to
> > dev-ref?
> Yeah, looks like it.

& thanks for confirming this too! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#288822: marked as done (developers-reference: "Bugs" control field not documented)

[Holger Levsen]

Hi Guillem,

On Tue, Oct 08, 2019 at 12:30:50PM +0200, Guillem Jover wrote:
> > I don't really understand "#288822: developers-reference: "Bugs" control 
> > field
> > not documented" and I'm not sure it's really an issue still.
> This would be the Bugs field documented now in both deb-control(5) and
> deb-src-control(5), since dpkg 1.14.7 (2007-10-08), ref #173463.

thanks for that information! do you agree there's nothing to be added to
dev-ref?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941835: debian-policy: drop mentioning of legacy manual in package description

[Holger Levsen]

Package: debian-policy
Version: 4.4.1.1
Severity: normal

Dear Maintainer,

the current package description contains this paragraph:

 It also replaces the old Packaging Manual; most of the still-relevant
 content is now included as appendices to the Policy Manual.

I'm around a long time and I dont remember the old Packaging Manual, so
I think this paragraph can safely be dropped.


Thanks for your work on debian-policy!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#399028: developers-reference: best practices to create and delete system accounts

[Holger Levsen]

Hi Marc,

On Fri, Nov 17, 2006 at 09:41:48AM +0100, Marc Haber wrote:
> The information collected in
> http://wiki.debian.org/AccountHandlingInMaintainerScripts should
> eventually be put into the developer's reference, chapter 6.5.
 
would you suggest to remove all of that from this wiki page and then add
a pointer to developers-reference or what would you suggest today?

A suggestion where exactly to add this in the developers-reference would
also be welcome, btw.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

On Sat, Oct 05, 2019 at 12:12:55PM +0200, Bill Allombert wrote:
> > the comments are outdated, all these three bugs have been fixed in the
> > meantime...
> Does that mean the singlehtml version can be restored ?
> Does this apply to debian-policy too ?

I've no idea, I just noticed these bugs are closed (and thus the
comments are outdated).


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

On Fri, Oct 04, 2019 at 09:07:41PM +, Holger Levsen wrote:
> fwiw, src:developers-reference/Makefile now contains these lines:
> 
> # singlehtml files
> # don't install Sphinx singlehtml output until various bugs
> # are fixed upstream (e.g. #873456, #876075, #879048)
> #cp $(BUILD_DIR)/en/singlehtml/$(PACKAGE).html $(DESTDIR)$(datadir)
> #@set -ex; for l in $(filter-out en,$(LANGS)); do   \
> #cp $(BUILD_DIR)/$$l/singlehtml/$(PACKAGE).html 
> $(DESTDIR)$(datadir)/$$l ;  \
> #done
 
the comments are outdated, all these three bugs have been fixed in the
meantime...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#658825: Provide *single* page HTML manuals in http://www.debian.org/doc/*

[Holger Levsen]

block 658825 by 873456
block 658825 by 876075
block 658825 by 879048
thanks

hi,

fwiw, src:developers-reference/Makefile now contains these lines:

# singlehtml files
# don't install Sphinx singlehtml output until various bugs
# are fixed upstream (e.g. #873456, #876075, #879048)
#cp $(BUILD_DIR)/en/singlehtml/$(PACKAGE).html $(DESTDIR)$(datadir)
#@set -ex; for l in $(filter-out en,$(LANGS)); do   \
#cp $(BUILD_DIR)/$$l/singlehtml/$(PACKAGE).html 
$(DESTDIR)$(datadir)/$$l ;  \
#done


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941475: debian-policy: please document the /run/reboot-required thingy in the upgrade changelog

[Holger Levsen]

On Thu, Oct 03, 2019 at 10:40:09AM +0200, Mattia Rizzolo wrote:
> I only read the title of the d-d-a mail, but I read the upgrade
> checklist many times over the course of the years.  

almost the same here, just that I usually read the mail too.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941274: Acknowledgement (developers-reference: please mention packaging-tutorial)

[Holger Levsen]

control: retitle -1 developers-reference: please mention the packaging-tutorial 
and lintian-brush packages
thanks

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#941274: developers-reference: please mention packaging-tutorial

[Holger Levsen]

package: developers-reference
severity: wislist

hi,

subject says it all, please mention packaging-tutorial somewhere.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Holger Levsen]

On Mon, Sep 23, 2019 at 12:46:19AM +0700, Judit Foglszinger wrote:
> Updated both descriptions.

merged, thank you both.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Holger Levsen]

On Sat, Sep 21, 2019 at 05:24:34PM +0700, Judit Foglszinger wrote:
> Added patch for updating retirement/return description to new process.

thank you & happily merged!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 11:57:43PM +0200, Guillem Jover wrote:
> > >> I haven't checked how many packages do not fulfill this condition
> > > please do check. last (and only) time we (=r-b) looked, it wasn't
> > > practical at all. this was around 5 years ago, but I don't remember any
> > > work done on improving this.
> Back when we were fixing the binary package reproducible problems
> within dpkg, I also checked the source side, and fixed a few
> problematic cases. Assuming the same tools installed as defined in
> the .buildinfo file, and the same content in the unpacked source
> tree, dpkg-source should be producing the same output source packages.

oh, cool, thanks for this spreading this information!

> If this does not hold, I'd consider it a bug to be fixed.

great!

so now someone just needs to do something^wa rebuild of say 1000 source
packages and share the stats...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 01:34:49PM +0200, Aurelien Jarno wrote:
> 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

please do check. last (and only) time we (=r-b) looked, it wasn't
practical at all. this was around 5 years ago, but I don't remember any
work done on improving this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx -- developers-reference

[Holger Levsen]

On Sun, Aug 11, 2019 at 11:51:32PM +0900, Osamu Aoki wrote:
> I saw you uploaded a new version.  Thanks.

most changes were from you, so thank you very much too!

> As I see this package, remaining tasks are:

this list looks good to me. highest prio for me is getting
https://www.debian.org/doc/devel-manuals#devref fixed though.

> I am playing with the pudb python debugger to learn how docutils/sphinx works 
> :-)

nice!

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx -- developers-reference

[Holger Levsen]

Hi,

On Tue, Aug 06, 2019 at 11:36:25PM +0900, Osamu Aoki wrote:
> With today's commit, pull-down language selection seems to work for
> package installed files.  Also now we have Gnome desktop icon ;-)

great!

> It is usable, I think.

I think so too! :)

> > yeah, I also strongly prefer option 2.
> I think I figured out OK.  This is my first web page using javascript.
> It should be easy to add menu to select pdf/text/epub download now just by
> updating the existing template file and javascript.

coolio.

> If any of you have good sense of color, adjusting color via CSS may be
> an option for this pull-down menu.

I'm sure eventually someday someone will come around and improve this.

> Your feed back is most appreciated.

thank you for your work!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

hi,

On Thu, Jul 25, 2019 at 10:22:24PM +0900, Osamu Aoki wrote:
> > > -- I'm afraid I wasn't involved other than reporting problems with the
> > > published version of Policy, and I don't think we made changes to our
> > > package in response to any requests from the www-team.
> > Am I correct to assume we could go a similar way with 
> > src:developers-reference ?
> Yes.

coolio

> Only remaining problem is it builds multi-language outputs as packages
> but not for web.

well, the packaging also expects to have .txt files to work on to
replace the placeholders with common-entities?


> I mean that the English files are available on
> www.debian.org but translations don't show up as described in
> https://www.debian.org/intro/cn This is because  all html files are
> names as index.html etc. without language code, so automatic language
> selection can not be implemented.
> 
> We can do 2 ways.  
[...] 
> If I figure how to set up option2 type i18n web page, I may even do it
> for debian-handbook.

yeah, I also strongly prefer option 2.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

hi,

dear debian-www people: src:developers-reference was just switched to
use sphinx, just like src:debian-policy. However, no upload to unstable
has been made yet...

On Tue, Jul 23, 2019 at 08:13:50AM -0700, Sean Whitton wrote:
> On Mon 22 Jul 2019 at 09:22pm +00, Holger Levsen wrote:
> > I wonder how this was done for debian-policy which is also hosted on
> > www.debian.org. Sean, do you have any insight on this?
> Paul, Laura and Osamu hacked on the www-team's scripts until it worked
> -- I'm afraid I wasn't involved other than reporting problems with the
> published version of Policy, and I don't think we made changes to our
> package in response to any requests from the www-team.

Am I correct to assume we could go a similar way with src:developers-reference ?

If you wanted, you could test by cloning the git repo, install the
build-depends and run 'make'. The package build is still broken...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

Hi,

adding Sean to cc: for the question mentioned below.


On Mon, Jul 22, 2019 at 11:24:41PM +0900, Osamu Aoki wrote:
> Do you know anyone good in this.   Is there any volunteer?  (I am
> seeking help on the mailinglist at sphinx-us...@googlegroups.com now)

I'm currently constantly asking on the #debconf channel for any takers :)

> > I think it's ok if the master branch is broken for some time, this
> > conversation has been much desired to get developers-reference in an
> > editable state again, so here we go.
> 
> One thing stopping me to move forward is the difference of i18n HTML
> page arrangement:
> 
>  * Debian web site https://www.debian.org/doc/manuals/developers-reference/
>It offers the automatic locale adjusted content by using
>index.en.html, index.fr.html, ...
>  * Sphinx based web sites such as https://docs.python.org/3/
>It offers the manual pull-down menu and web pages are placed at
>.../en/index.html .../fr/index.html
> 
> How should we arrange web page? I want to migrate to Sphinx-style.
> But that will break current URL links.  Any opinion?

I wonder how this was done for debian-policy which is also hosted on
www.debian.org. Sean, do you have any insight on this?

> Please note Debian web pages will be generated from the latest unstable
> version binary package. 
 
nods. Given how few development there was in recent years on dev-ref I
do think its ok if it will take 1-3 months until the next release ;)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

Hi Osamu,

On Sun, Jul 07, 2019 at 10:52:23PM +0900, Osamu Aoki wrote:
> You can build HTML and PDF with "make".

\o/

> debian/* still needs to be polished as of this posting.

ok :)

> The conversion process is completely recorded in the history.  If main branch
> is update, we can rebase most of rest8 and do the operation as in the commit
> message to get conversion for the updated master if needed.

cool cool cool!

> Maybe, now I think Sphinx expert can take over to get proper packaging.

yeah, indeed! ;)

I think it's ok if the master branch is broken for some time, this
conversation has been much desired to get developers-reference in an
editable state again, so here we go.

And thank you very much for the work until here, Osamu!


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature