Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory

[Sean Whitton]

Hello Xiyue,

On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote:

> I have prepared a patch at [3] and also attached.  Please help review
> and comment.  I'll merge it once it's approved.

Please don't merge this yourself; let me or David do it.  Thanks.

-- 
Sean Whitton

Bug#1077220: pgloader: please stop building on i386

[Sean Whitton]

Source: pgloader
Version: 3.6.10-2
X-debbugs-cc: m...@debian.org

Hello,

I wrote Thursday requesting an ACK for removing CL-IRONCLAD on i386.

But as CL-IRONCLAD is arch:all, that doesn't make sense.  In fact,
the fix is for pgloader to drop i386 from its architectures list.

So this bug is to track that.

Thanks!

-- 
Sean Whitton

Bug#1074014: encode mandatory merged-/usr into policy

[Sean Whitton]

Hello,

On Thu 25 Jul 2024 at 03:12pm +02, Helmut Grohne wrote:

> Can a policy editor follow up with instructions on where we are (from a
> policy procedures point of view) and what needs to be done to move this
> proposal forward?

I'm focused on tag2upload right now.  If Russ doesn't get to this soon,
please ping again.

-- 
Sean Whitton

Bug#1077080: emacs-pgtk: When emacs-pgtk fails to find a Wayland display available, it fails to run instead of opening in -nw mode

[Sean Whitton]

Hello,

On Thu 25 Jul 2024 at 07:22pm -06, Gunnar Wolf wrote:

> Package: emacs-pgtk
> Version: 1:29.4+1-3
> Severity: normal
>
> I have Emacs installed in all of my systems. Paricularly, I have
> emacs-pgtk all systems where I often use a graphical environment (and
> emacs-nox in those where I don't).
>
> Back when I used X11, if I started Emacs and had no $DISPLAY set, it
> would open in a terminal. With emacs-pgtk, the behavior is not the
> same:
>
> $ emacs foobar
>
> (emacs:3988): Gtk-WARNING **: 19:19:10.887: cannot open display:
> $
>
> This impacted me because I neede to use a remote machine to do work
> via scripts (i.e. dch, debcommit) that call /usr/bin/editor and I
> found impossible to hand-specify emacs to use -nw; I ended up
> installing emacs-nox, but I don't find it to be an acceptable,
> transparent-enough solution.
>
> I think emacs-pgtk should behave just as emacs-gtk, falling back to
> the console if a windowed environment is not found.

You know about 'emacs -nw' right?

I guess this is an upstream bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065416: requesting input on recent posts to #1065416

[Sean Whitton]

Hello,

On Sat 20 Jul 2024 at 01:01pm +02, Matthias Klose wrote:

> - I am accepting the offer given in
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108
>   to take over the linux-libc-dev package.
>   I will start working on that at DebCamp and DebConf.

This is a significant point of agreement.  Bastian, how about we revert
your changes for the time being, to give Matthias time to do this work?

-- 
Sean Whitton

Bug#1076696: RM: sbcl [armel armhf] -- ROM; broken 32-bit builds blocking migration

[Sean Whitton]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: s...@packages.debian.org
Control: affects -1 + src:sbcl
Control: block 1069520 by -1
Control: block 1075754 by -1

Hello,

Please remove sbcl on armhf and armel.  There is an upstream bug on these
32-bit archs atm: see #1069520.  It doesn't look like they are going to be
able to fix it soon so I don't think this should be blocking migration.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1076117: dgit: crashes with a remote memory error on clone

[Sean Whitton]

Hello,

On Thu 11 Jul 2024 at 04:30pm +01, Ian Jackson wrote:

>> For now, I've been advised to just use a temporary clone for dgit
>> commands so that it won't introduce incompatible branches/tags/etc. into
>> the normal working repo(s).
>
> I don't know who advised you to do this, nor do I known what your git
> workflow is, but you should be able to work on everything in one git
> tree.  Whats important is to keep the *branches* separate, and run the
> right command(s) on the right branch.

It was me :)  The tree is used for more than one source package, emacs
and emacs-non-dfsg, so tags made by dgit can't co-exist.

-- 
Sean Whitton

Bug#1075856: Clarify filename conflicts for programs

[Sean Whitton]

Hello,

On Sat 06 Jul 2024 at 07:49pm +02, Chris Hofstaedtler wrote:

> I'm happy to file the bugs, if policy intended to forbid this, and/or
> this bug does not get rejected.

I would be happy to second this change too.

Generally however we seek not to make packages buggy by releasing
Policy.  So it would be good to file those bugs first.

-- 
Sean Whitton

Bug#1076116: org-roam: restore rebuilding org-roam.texi

[Sean Whitton]

Source: org-roam
Version: 2.2.2-2
Severity: important
X-debbugs-cc: aymeric.a...@yandex.com

As discussed on debian-emacsen@lists.d.o, rebuilding the .texi docs from
the .org should be restored, so that we know that it can be done with
only tools from Debian main.  If it cannot, then we do not have all
files in their preferred form for modification, and this bug becomes RC.

-- 
Sean Whitton

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Sean Whitton]

Hello,

Sorry to keep asking for these minor changes, but it does help me
understand the change better.

Why can't you just use debian/install to install the .nosearch?  Are you
trying to avoid creating an empty .nosearch in the source package, or is
there some other reason?

-- 
Sean Whitton

Bug#879555: parted: Option '-s' incompatible with shrinking a partition

[Sean Warner]

I am also having this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879555

$ parted -v
parted (GNU parted) 3.6
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+
Written by
.

$ cat /etc/lsb-release 
DISTRIB_ID="ManjaroLinux"
DISTRIB_RELEASE="24.0.2"
DISTRIB_CODENAME="Wynsdey"

-- If increasing the size of a partition the following command works
but if reducing the size of a partition it gives a warning "Warning:
Shrinking a partition can cause data loss, are you sure you want to
continue?" and the command just exits back to the command prompt and no
changes are made to the partition.

sudo parted -s /dev/loop0 resizepart 1 46280703s

I assumed that parted -s would automatically supply a default value of
'Yes' in this instance?

According to the Parted Man page:
-s, --script
never prompts for user intervention

Is this a bug or am I misunderstanding something?

>From researching the interweb this might be a bug that for many years
has never been addressed.

There appears to be no way to make this work with parted -s. The only
option is to resort to the undocumented ---pretend-input-tty <-- But is
this safe to keep using if not documented? Any plans to make it an
official "thing" in Parted?

Example that will work whether increasing or reducing the partition
size:

echo -e "resizepart 1 46280703s\nyes\nunit s\nprint\nquit" | sudo
parted /dev/loop0 ---pretend-input-tty

Any help much appreciated,

Flex

Bug#1072836: Switch to an active upstream

[Sean Anderson]

Package: libnginx-mod-http-cache-purge
Version: 1:2.3-4

The current upstream for ngx_cache_purge [1] is defunct, with no updates
for 10 years (despite multiple outstanding PRs fixing bugs). Please
switch to the nginx-modules upstream [2] which has fixed bugs and added
features (such as wildcards). This upstream is also used by Arch
Linux [3].

[1] https://github.com/FRiCKLE/ngx_cache_purge
[2] https://github.com/nginx-modules/ngx_cache_purge
[3] https://archlinux.org/packages/extra/x86_64/nginx-mod-cache_purge/

Bug#1070108: bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u2

[Sean Whitton]

Hello,

On Wed 05 Jun 2024 at 10:21pm +01, Jonathan Wiltshire wrote:

> Control: tag -1 confirmed
>
> Hi,
>
> On Tue, Apr 30, 2024 at 09:16:06AM +0100, Sean Whitton wrote:
>> This is security update for CVEs marked no-dsa by the secteam.
>> It backports a series of upstream commits for CVE-2024-30203, CVE-2024-30204
>> and CVE-2024-30205.
>
> Please go ahead.

Hmm, I uploaded it when I filed the bug.  I just checked and I got an
ACCEPTED for this version number.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1071563: emacs: Don't let test suite failures block the build

[Sean Whitton]

Hello,

On Mon 27 May 2024 at 02:32pm -05, Rob Browning wrote:

> Sean Whitton  writes:
>
>> I agree with you in principle, but I'm proposing this precisely because
>> I think that the level of effort has already become too high.  I find
>> that I have to do multiple givebacks every upload.
>
> Understood, but I was wondering if that might be a more recent
> phenomenon, perhaps because of the switch to parallel testing (or
> something else we could fix).
>
> Of course if things have just gotten worse for other reasons that are
> outside our control, then that's a different matter.

I think it's just that upstream has lots and lots of tests now.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1071563: emacs: Don't let test suite failures block the build

[Sean Whitton]

Hello,

On Sun 26 May 2024 at 06:02pm -05, Rob Browning wrote:

> Sean Whitton  writes:
>
>> I think we should move the tests to run under autopkgtest, rather than
>> during the build.  Debian's autopkgtest infrastructure, with things like
>> blocking migration, is by now quite sophisticated.
>>
>> On IRC it's also been suggested that we also
>>
>> - mark dired-test-bug27243-02 as flaky (thanks Arto Jantunen); and
>>
>> - in the new autopkgtest, don't run the tests in parallel.
>
> I don't have a good overall sense of what's been failing lately, but I
> did wonder if just marking that test (and any others that have been
> (unnecessary) trouble) as flaky, and going back to not running the tests
> in parallel on the autobuilders might be sufficient.
>
> As long as the package tests restrict transitions, moving the tests
> there, if we can, may be fine too, but if we could keep the spurious
> test failure rate low enough (pretty low) without *too* much effort,
> then I think catching failures during the build is somewhat preferable
> (in case the error is serious).

I agree with you in principle, but I'm proposing this precisely because
I think that the level of effort has already become too high.  I find
that I have to do multiple givebacks every upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1071563: emacs: Don't let test suite failures block the build

[Sean Whitton]

Hello,

On Tue 21 May 2024 at 11:20am +01, Sean Whitton wrote:

> Source: emacs
> Version: 1:29.3+1-3
>
> Hello,
>
> I propose that we make test suite failures non-fatal to the build.
>
> The test suite has got quite flaky in recent years, and uploading Emacs
> often requires issuing several giveback requests for random failures.
>
> Patching individual tests to mark them as flaky does not scale.

I think we should move the tests to run under autopkgtest, rather than
during the build.  Debian's autopkgtest infrastructure, with things like
blocking migration, is by now quite sophisticated.

On IRC it's also been suggested that we also

- mark dired-test-bug27243-02 as flaky (thanks Arto Jantunen); and

- in the new autopkgtest, don't run the tests in parallel.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Sean Whitton]

control: tag -1 + patch

Hello,

Thanks Xiyue.  I think that this is a clean way to improve upon the
current situation and I would be happy to upload this to experimental.

David, since you figured out the /usr/share/site-lisp/elpa layout to
begin with, do you have time to give any comments?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1071563: emacs: Don't let test suite failures block the build

[Sean Whitton]

Source: emacs
Version: 1:29.3+1-3

Hello,

I propose that we make test suite failures non-fatal to the build.

The test suite has got quite flaky in recent years, and uploading Emacs
often requires issuing several giveback requests for random failures.

Patching individual tests to mark them as flaky does not scale.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069943: bullseye-pu: package emacs/27.1+1-3.1+deb11u3

[Sean Whitton]

control: tag -1 - moreinfo

Hello Jonathan,

On Sun 12 May 2024 at 09:00pm +01, Jonathan Wiltshire wrote:

> The security release hasn't been accepted into bullseye yet because
> there were reports of it being broken on mips64el. There was a bug but
> I'm afraid I don't have a reference to it.

I believe this was #1031888.

> Do you know if your version solves the issue?

Upstream addressed the memory leak that Adrian thought might be causing
#1031888.  I prepared a deb11u4 in git which includes that fix.

Unfortunately, however, #1031888 is no longer reproducible.
Adam took a look at my deb11u4 (thank you), but the buildds which were
previously showing the problem are no longer running bullseye.

I just tried preparing a mips64el qemu image and booting that, but the
problem is not reproducible there: deb11u2 installs fine.

How should we proceed?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el

[Sean Whitton]

control: reopen 1031888

Hello Adam,

On Fri 21 Apr 2023 at 10:19am +01, Adam D. Barratt wrote:

> On Fri, 2023-04-21 at 12:08 +0300, Adrian Bunk wrote:
>> On Tue, Mar 14, 2023 at 02:04:19PM -0700, Sean Whitton wrote:
>> > Version: 1:28.2+1-11
>> >
>> > Hello,
>> >
>> > On Sun 26 Feb 2023 at 09:41PM +02, Adrian Bunk wrote:
>> >
>> > > While I suspect they are the same, there is no proof that this
>> > > leak is
>> > > actually the same as the mips64el installation issue.
>> >
>> > Looks like it was.
>>
>> If this was confirmed, could the fix go into the next point release,
>> which would require a -pu request+upload today (or early tomorrow)?
>>
>
> With my DSA hat on, I'm not aware of it having been confirmed to fix
> the issue on bullseye. I'm happy to test an updated package in the
> meantime. (FWIW the update isn't in p-u currently because of this
> issue.)

I have prepared an update for bullseye incorporating upstream's fix for
the memory leak.
I would be grateful if you could test whether the mips64el installation
is still reproducible.

As deb11u3 is already in p-u and tagged, I've versioned this deb11u4.
I've pushed it to the fix-1031888 branch of salsa:rlb/deb-emacs.git.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065416: requesting input on recent posts to #1065416

[Sean Whitton]

Hello Matthias,

There have been a number of posts to #1065416 and it hasn't heard from
you in some time.  The Technical Committee would like to help, but it is
difficult to see how we could do so without input from your side.

The ownership issue seems tractable.  On the one hand, the binary
package names clearly belong to your package, but on the other hand, the
files that are installed seem like they belong to Linux.

If you could respond to the recent messages, we may be able to get a
grip on some of the problems and make suggestions.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc

[Sean Whitton]

Hello,

On Fri 03 May 2024 at 03:18pm GMT, Martin wrote:

> On 2024-05-03 10:28, Sean Whitton wrote:
>> Hmm, have you considered asking upstream to rename it?  "casual-calc"
>> being the obvious, much less generic choice.
>
> It didn't occur to me, that the name is pretty generic, indeed. OTOH,
> I'm not aware of any other (existing or requested) package named
> "*casual*". And the fact, that the name is not really telling what
> it is about, is common among almost all Debian and Emacs packages :-(
>
> If I were to package this, I would now consider naming the source
> package "emacs-casual{-calc}" and the binary package
> "elpa-casual{-calc}", but I guess, it is easy enough to find by the
> short description anyway, which mentions "Emacs Calc".

Yes, the source package would need to be emacs-casual.  I still think it
should be suggested upstream.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc

[Sean Whitton]

Hello,

On Fri 03 May 2024 at 07:11am GMT, Martin wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name: elpa-casual
>   Version : 1.5.0
>   Upstream Author : Charles Y. Choi 
> * URL or Web page : https://github.com/kickingvegas/Casual/
> * License : GPL-3
>   Description : a transient-based porcelain for Emacs Calc
>
>   Casual is an opinionated Transient-based porcelain to support the
>   casual usage of Emacs Calc.
>
>   While Emacs Calc has an embarrassingly rich feature set, for many
>   users this capability is inaccessible due the overwhelming number of
>   keybindings used to access them. These keybindings have a steep
>   learning curve that is quickly lost if not in constant use.
>
>   Menus are a user interface (UI) affordance that offer users
>   discoverability and recall. Providing a hierarchical menu UI over Calc
>   greatly improves its casual use.
>
> Here is a nice introduction into casual:
>
> http://yummymelon.com/devnull/

Hmm, have you considered asking upstream to rename it?  "casual-calc"
being the obvious, much less generic choice.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069890: Resignation & call for votes to elect the Chair

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 02:04pm +01, Sean Whitton wrote:

> ===BEGIN
>
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Stefano Rivera 
> E: Timo Röhling 
> F: Craig Small 
> G: Matthew Vernon 
> H: Sean Whitton 
>
> ===END

I vote

    A = B = C = G = H > D = E > F

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067630: various uploads made

[Sean Whitton]

fixed 1067630 1:26.1+1-3.2+deb10u5
fixed 1067663 9.1.14+dfsg-3+deb10u2
thanks 

I've uploaded to Emacs and Org-mode to buster-security and
bullseye-proposed-updates, and Emacs to bookworm-proposed-updates.

-- 
Sean Whitton

Bug#1070108: bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u2

[Sean Whitton]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: org-m...@packages.debian.org
Control: affects -1 + src:org-mode
Control: block -1 by 1069943

This is security update for CVEs marked no-dsa by the secteam.
It backports a series of upstream commits for CVE-2024-30203, CVE-2024-30204
and CVE-2024-30205.

I had to backport a feature that the fixes use to pop up a dialog asking the
user about the potentially unsafe remote resources.
This involves only localised code changes, and is already two years old, so
has received an adequate amount of testing upstream.

The fix depends on some corresponding changes to Emacs, in #1069943.

I manually tested the fixes using reproducers provided in the BTS and from
upstream.  The fixes are already in unstable.  I have uploaded to oldstable-pu.

-- 
Sean Whitton
diff -Nru org-mode-9.4.0+dfsg/debian/changelog 
org-mode-9.4.0+dfsg/debian/changelog
--- org-mode-9.4.0+dfsg/debian/changelog2023-08-03 14:28:47.0 
+0100
+++ org-mode-9.4.0+dfsg/debian/changelog2024-04-30 09:08:33.0 
+0100
@@ -1,3 +1,11 @@
+org-mode (9.4.0+dfsg-1+deb11u2) bullseye; urgency=high
+
+  * Team upload.
+  * Fix CVE-2024-30203, CVE-2024-30204 & CVE-2024-30205 (Closes: #1067663).
+- Require Emacs 1:27.1+1-3.1+deb11u3 to ensure we get the whole fix.
+
+ -- Sean Whitton   Tue, 30 Apr 2024 09:08:33 +0100
+
 org-mode (9.4.0+dfsg-1+deb11u1) bullseye; urgency=medium
 
   * Team upload.
diff -Nru org-mode-9.4.0+dfsg/debian/control org-mode-9.4.0+dfsg/debian/control
--- org-mode-9.4.0+dfsg/debian/control  2023-08-03 14:28:47.0 +0100
+++ org-mode-9.4.0+dfsg/debian/control  2024-04-30 09:08:33.0 +0100
@@ -11,7 +11,8 @@
 
 Package: elpa-org
 Architecture: all
-Depends: ${elpa:Depends}, ${misc:Depends}, elpa-htmlize
+Depends: ${elpa:Depends}, ${misc:Depends}, elpa-htmlize,
+ emacs-gtk (>= 1:27.1+1-3.1+deb11u3) | emacs-lucid (>= 1:27.1+1-3.1+deb11u3) | 
emacs-nox (>= 1:27.1+1-3.1+deb11u3)
 Recommends: emacs (>= 46.0)
 Suggests: org-mode-doc, ditaa, texlive-latex-extra, texlive-fonts-recommended, 
texinfo
 Enhances: emacs,
diff -Nru 
org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_01.patch 
org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_01.patch
--- org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_01.patch   
1970-01-01 01:00:00.0 +0100
+++ org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_01.patch   
2024-04-30 09:08:33.0 +0100
@@ -0,0 +1,56 @@
+From: Ihor Radchenko 
+Date: Tue, 20 Feb 2024 12:47:24 +0300
+Subject: org-latex-preview: Add protection when `untrusted-content' is
+ non-nil
+
+* lisp/org/org.el (org--latex-preview-when-risky): New variable
+controlling how to handle LaTeX previews in Org files from untrusted
+origin.
+(org-latex-preview): Consult `org--latex-preview-when-risky' before
+generating previews.
+
+This patch adds a layer of protection when LaTeX preview is requested
+for an email attachment, where `untrusted-content' is set to non-nil.
+
+(cherry picked from Emacs commit 6f9ea396f49cbe38c2173e0a72ba6af3e03b271c)
+---
+ lisp/org.el | 19 +++
+ 1 file changed, 19 insertions(+)
+
+diff --git a/lisp/org.el b/lisp/org.el
+index 4964e01..eea46cb 100644
+--- a/lisp/org.el
 b/lisp/org.el
+@@ -1074,6 +1074,24 @@ the following lines anywhere in the buffer:
+   :package-version '(Org . "8.0")
+   :type 'boolean)
+ 
++(defvar untrusted-content) ; defined in files.el
++(defvar org--latex-preview-when-risky nil
++  "If non-nil, enable LaTeX preview in Org buffers from unsafe source.
++
++Some specially designed LaTeX code may generate huge pdf or log files
++that may exhaust disk space.
++
++This variable controls how to handle LaTeX preview when rendering LaTeX
++fragments that originate from incoming email messages.  It has no effect
++when Org mode is unable to determine the origin of the Org buffer.
++
++An Org buffer is considered to be from unsafe source when the
++variable `untrusted-content' has a non-nil value in the buffer.
++
++If this variable is non-nil, LaTeX previews are rendered unconditionally.
++
++This variable may be renamed or changed in the future.")
++
+ (defcustom org-insert-mode-line-in-empty-file nil
+   "Non-nil means insert the first line setting Org mode in empty files.
+ When the function `org-mode' is called interactively in an empty file, this
+@@ -15820,6 +15838,7 @@ fragments in the buffer."
+   (interactive "P")
+   (cond
+((not (display-graphic-p)) nil)
++   ((and untrusted-content (not org--latex-preview-when-risky)) nil)
+;; Clear whole buffer.
+((equal arg '(64))
+ (org-clear-latex-preview (point-min) (point-max))
diff -Nru 
org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_02.patch 
org-mode-9.4.0+dfsg/debian/patches/CVE-2024-30203_CVE-2024-30204_

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:

> From afac52fa956087eb737c123682f634fc739c7e20 Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Tue, 27 Feb 2024 23:37:06 +0100
> Subject: [PATCH] =?UTF-8?q?Add=20references=20to=20=C2=ABdpkg-buildtree=20?=
>  =?UTF-8?q?clean=C2=BB=20for=20debian/{substvars,files}?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> These files are generated by dpkg tools (and in some cases by helpers),
> but the maintainer was responsible for cleaning them up. There is now
> a new command that will take care of cleaning these (and any other
> future) files that the dpkg suite might end up generating, making their
> introduction easier as the responsibility to remove them shifts back
> where it belongs.
> ---
>  policy/ch-source.rst | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 4307e89..2fb05cd 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -685,7 +685,7 @@ variables are also available.
>
>  The ``debian/substvars`` file is usually generated and modified
>  dynamically by ``debian/rules`` targets, in which case it must be
> -removed by the ``clean`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
>
>  See :manpage:`deb-substvars(5)` for full details about source variable
>  substitutions, including the format of ``debian/substvars``.
> @@ -725,8 +725,9 @@ building packages to record which files are being 
> generated.
>
>  It should not exist in a shipped source package, and so it (and any
>  backup files or temporary files such as ``files.new``)  [#]_ should be
> -removed by the ``clean`` target. It may also be wise to ensure a fresh
> -start by emptying or removing it at the start of the ``binary`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
> +It may also be wise to ensure a fresh start by emptying or removing it at the
> +start of the ``binary`` target.
>
>  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>  to ``debian/files`` for the ``.deb`` file that will be created when

Seconded.

It seems prudent to get reference to this tool into Policy as soon as
possible, even if we're not yet sure how it relates to debhelper.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Sat 20 Apr 2024 at 09:00pm +02, Guillem Jover wrote:

> Hi!
>
> On Thu, 2024-03-28 at 09:58:29 +0800, Sean Whitton wrote:
>> On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:
>> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> > index 4307e89..2fb05cd 100644
>> > --- a/policy/ch-source.rst
>> > +++ b/policy/ch-source.rst
>> > @@ -685,7 +685,7 @@ variables are also available.
>> >
>> >  The ``debian/substvars`` file is usually generated and modified
>> >  dynamically by ``debian/rules`` targets, in which case it must be
>> > -removed by the ``clean`` target.
>> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
>> > clean``).
>> >
>> >  See :manpage:`deb-substvars(5)` for full details about source variable
>> >  substitutions, including the format of ``debian/substvars``.
>> > @@ -725,8 +725,9 @@ building packages to record which files are being 
>> > generated.
>> >
>> >  It should not exist in a shipped source package, and so it (and any
>> >  backup files or temporary files such as ``files.new``)  [#]_ should be
>> > -removed by the ``clean`` target. It may also be wise to ensure a fresh
>> > -start by emptying or removing it at the start of the ``binary`` target.
>> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
>> > clean``).
>> > +It may also be wise to ensure a fresh start by emptying or removing it at 
>> > the
>> > +start of the ``binary`` target.
>> >
>> >  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>> >  to ``debian/files`` for the ``.deb`` file that will be created when
>>
>> Instead of "It may also be wise ..." can you use one of the sets of
>> magic words from Policy 1.1, please?
>
> This text was already part of policy and the proposed patch did not
> really touch it, except for wrapping it into a new line. I think
> modifying it feels a bit out-of-scope for this request? But if you
> think it's relevant, and the sentence should be improved as part of
> this, then I'll try to provide some wording. :)

Ah yes, sorry, that is indeed out-of-scope.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069933: bookworm-pu: package emacs/1:28.2+1-15+deb12u1

[Sean Whitton]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: em...@packages.debian.org
Control: affects -1 + src:emacs

This is security update for CVEs marked no-dsa by the secteam.
It backports a series of upstream commits for CVE-2024-30202, CVE-2024-30203,
CVE-2024-30204 and CVE-2024-30205.

I had to backport a feature that the fixes use to pop up a dialog asking the
user about the potentially unsafe remote resources.
This involves only localised code changes, and is already two years old, so
has received an adequate amount of testing upstream.

I manually tested the fixes using reproducers provided in the BTS and from
upstream.  The fixes are already in unstable.  I have uploaded to stable-pu.

-- 
Sean Whitton
diff -Nru emacs-28.2+1/debian/changelog emacs-28.2+1/debian/changelog
--- emacs-28.2+1/debian/changelog   2023-05-13 21:17:27.0 +0100
+++ emacs-28.2+1/debian/changelog   2024-04-27 10:49:04.0 +0100
@@ -1,3 +1,10 @@
+emacs (1:28.2+1-15+deb12u1) bookworm; urgency=high
+
+  * Fix CVE-2024-30202, CVE-2024-30203, CVE-2024-30204 & CVE-2024-30205
+(Closes: #1067630).
+
+ -- Sean Whitton   Sat, 27 Apr 2024 10:49:04 +0100
+
 emacs (1:28.2+1-15) unstable; urgency=medium
 
   * emacs-common: add breaks/replaces emacs-bin-common (<< 1:28) since the
diff -Nru emacs-28.2+1/debian/.git-dpm emacs-28.2+1/debian/.git-dpm
--- emacs-28.2+1/debian/.git-dpm2023-03-31 19:22:32.0 +0100
+++ emacs-28.2+1/debian/.git-dpm2024-04-27 10:49:04.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-023ac1eff558f6fb387fea1629b084c8929de18d
-023ac1eff558f6fb387fea1629b084c8929de18d
+1c0b3e5ae5cef71210b094bfd1f8582efe3a7b90
+1c0b3e5ae5cef71210b094bfd1f8582efe3a7b90
 279b82e64e15b5e2df3cb522636c6db85a8ee659
 279b82e64e15b5e2df3cb522636c6db85a8ee659
 emacs_28.2+1.orig.tar.xz
diff -Nru emacs-28.2+1/debian/.gitignore emacs-28.2+1/debian/.gitignore
--- emacs-28.2+1/debian/.gitignore  1970-01-01 01:00:00.0 +0100
+++ emacs-28.2+1/debian/.gitignore  2024-04-27 10:49:04.0 +0100
@@ -0,0 +1,81 @@
+*~
+.\#*
+/*-stamp
+/.debhelper/
+/build-gtk/
+/build-lucid/
+/build-nox/
+/build-src/
+/build-x/
+/elgz-canary
+/elgz-info
+/emacs
+/emacs-bin-common
+/emacs-bin-common.README.Debian
+/emacs-bin-common.debhelper.log
+/emacs-bin-common.lintian-overrides
+/emacs-bin-common.postinst
+/emacs-bin-common.postrm
+/emacs-bin-common.prerm
+/emacs-bin-common.substvars
+/emacs-common
+/emacs-common.README.00
+/emacs-common.README.01
+/emacs-common.README.Debian
+/emacs-common.debhelper.log
+/emacs-common.docs
+/emacs-common.links
+/emacs-common.lintian-overrides
+/emacs-common.postinst
+/emacs-common.postinst.debhelper
+/emacs-common.postrm.debhelper
+/emacs-common.prerm
+/emacs-common.prerm.debhelper
+/emacs-common.substvars
+/emacs-el
+/emacs-el.debhelper.log
+/emacs-el.prerm
+/emacs-el.substvars
+/emacs-gtk
+/emacs-gtk.README.Debian
+/emacs-gtk.debhelper.log
+/emacs-gtk.desktop
+/emacs-gtk.links
+/emacs-gtk.lintian-overrides
+/emacs-gtk.menu
+/emacs-gtk.postinst
+/emacs-gtk.postinst.debhelper
+/emacs-gtk.postrm
+/emacs-gtk.postrm.debhelper
+/emacs-gtk.prerm
+/emacs-gtk.substvars
+/emacs-lucid
+/emacs-lucid.README.Debian
+/emacs-lucid.debhelper.log
+/emacs-lucid.desktop
+/emacs-lucid.lintian-overrides
+/emacs-lucid.menu
+/emacs-lucid.postinst
+/emacs-lucid.postinst.debhelper
+/emacs-lucid.postrm.debhelper
+/emacs-lucid.prerm
+/emacs-lucid.substvars
+/emacs-nox
+/emacs-nox.README.Debian
+/emacs-nox.debhelper.log
+/emacs-nox.desktop
+/emacs-nox.links
+/emacs-nox.lintian-overrides
+/emacs-nox.menu
+/emacs-nox.postinst
+/emacs-nox.postinst.debhelper
+/emacs-nox.postrm
+/emacs-nox.postrm.debhelper
+/emacs-nox.prerm
+/emacs-nox.substvars
+/emacs.debhelper.log
+/emacs.substvars
+/files
+/stamp-configured
+/tmp-alt-list
+\#*\#
diff -Nru 
emacs-28.2+1/debian/patches/0029-org-macro-set-templates-Prevent-code-evaluation.patch
 
emacs-28.2+1/debian/patches/0029-org-macro-set-templates-Prevent-code-evaluation.patch
--- 
emacs-28.2+1/debian/patches/0029-org-macro-set-templates-Prevent-code-evaluation.patch
  1970-01-01 01:00:00.0 +0100
+++ 
emacs-28.2+1/debian/patches/0029-org-macro-set-templates-Prevent-code-evaluation.patch
  2024-04-27 10:49:04.0 +0100
@@ -0,0 +1,44 @@
+From d9bd61923515607fcc7ada4ba66b7e58e8ba00d9 Mon Sep 17 00:00:00 2001
+From: Ihor Radchenko 
+Date: Tue, 20 Feb 2024 12:19:46 +0300
+Subject: org-macro--set-templates: Prevent code evaluation
+
+* lisp/org/org-macro.el (org-macro--set-templates): Get rid of any
+risk to evaluate code when `org-macro--set-templates' is called as a
+part of major mode initialization.  This way, no code evaluation is
+ever triggered when user merely opens the file or when
+`mm-display-org-inline' invokes Org major mode to fontify mime part
+preview in email messages.
+
+(cherry picked f

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

[Sean Whitton]

Hello,

Many thanks for this.  Hopefully someone will be interested in
implementing it at some point.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#877337: single-page html of debian-policy to be revived?

[Sean Whitton]

Hello,

On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote:

> 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.

Thanks.  I'd be grateful for some feedback from other regular Policy
contributors.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1

[Sean Whitton]

Hello,

Thanks Peter.  Looks like upstream might be able to commit a fix.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: New appointments for the Debian Technical Committee: csmall

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 03:08pm +02, Timo Röhling wrote:

> * Andreas Tille  [2024-04-26 14:22]:
>>The Technical Committee now consists of:
>>
>>  * Sean Whitton  (chair)
>>  * Simon McVittie 
>>  * Christoph Berg 
>>  * Helmut Grohne 
>>  * Matthew Vernon 
>>  * Matthew Garrett 
>>  * Stefano Rivera 
>>  * Timo Röhling 
>>  * Craig Small 
>>
> Correct me if I'm wrong, but I think Simon McVitie's term has ended already.

It has.  Possibly a follow-up correction should be sent.

Anyway, thanks for handling it, Andreas.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069890: Resignation & call for votes to elect the Chair

[Sean Whitton]

Package: tech-ctte

Dear committee members,

As the membership of the committee has changed, in accordance with
convention I hereby resign as Chair, effective one week from now, and
call for votes to elect the Chair of the Technical Committee.
Per the Debian Constitution, the vote runs until all members have voted,
or until my resignation takes effect.

I am happy to continue to volunteer for the role, if the committee agrees.

The ballot:

===BEGIN

A: Christoph Berg 
B: Matthew Garrett 
C: Helmut Grohne 
D: Stefano Rivera 
E: Timo Röhling 
F: Craig Small 
G: Matthew Vernon 
H: Sean Whitton 

===END

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 12:38pm +02, Andreas Tille wrote:

> Hi Sean,
>
> Am Fri, Apr 26, 2024 at 10:53:41AM +0100 schrieb Sean Whitton:
>> > Possibly I need to send some delegation mail like this[1]?
>>
>> It's an appointment, not a delegation, but yes something like that mail.
>
> So something I could copy-n-paste from
>
>https://lists.debian.org/debian-devel-announce/2023/07/msg0.html
>
> adding
>
>Craig Small 
>
> on top?

Yes, though you'd also need to update each of the https:// links.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069707: It is only in wayland

[Sean Whitton]

Hello,

On Tue 23 Apr 2024 at 10:34am +02, Luis Llana wrote:

> Since simplescreenrecoding only works on X11, I have changed to X11 to record 
> a video
> of the problem and in X11 works fine. The problem is with wayland.

On Wayland, consider 'apt-get install emacs-pgtk'.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 09:12am +02, Andreas Tille wrote:

> Possibly I need to send some delegation mail like this[1]?

It's an appointment, not a delegation, but yes something like that mail.

> Since I'm now in contact with CTTE I'd like to start here:
>
> I currently don't have any questions for your team. Like previous DPLs,
> I'm open to any inquiries or requests for assistance. I personally
> prefer public discussions whenever possible, as they can benefit a wider
> audience. You can find a list of contact options at the bottom of my
> page on people.d.o[2].
>
> I prefer being offline when I'm away from my keyboard, so I don't carry
> a phone. In urgent situations, I can provide the number of my dumb
> phone, though it may not always be within reach. Feel free to ping me if
> I don't respond promptly to ensure I address your concerns.
>
> Please let me know whether I can do something for you.  I'm fine
> joining your IRC channel for the next couple of hous but I'll be
> offline later today.

Thanks.  Nothing comes to mind for now from me, and see you in Busan
indeed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Sean Whitton]

Hello Go and Rust packagers,

On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote:

> With the increasing amount of programs in Debian that Build-Depend and
> statically link with Golang and Rust libraries, it's important that
> the Debian Policy clearly sets out the requirements for declaring
> these statically-linked libraries.

I think Maytham is right that updating Policy for this is a priority.
It has been bothering me that misunderstandings of Built-Using have been
proliferating somewhat among newer contributors.  See also #999785.

Could you take a look at his proposed changes to Policy in #1069256,
please, and confirm they successfully reconcile Debian Policy with your
team policies?

I think that we should also include an explanation of why we have chosen
to do this using a new field in d/control like Static-Built-Using.
Policy is meant to be a record of our lessons learned in building a
distribution, and the lessons learned in trying to handle these new
hyper-statically linked language ecosystems seem important.

My immediate question is why the Haskell and OCaml team's approaches,
were not copied.  They seem to work well and don't require a new field.
That seems worth writing down.

Thank you Maytham for your work so far.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

[Sean Whitton]

Hello,

On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> control: tag -1 + moreinfo
>>
>> Hello Xiyue,
>>
>> Please explain the autopkgtest_keep change.  Remember that autopkgtests
>> are to test the installed package.  If you need to keep the .el files,
>> it must be for some reason other than because the test suite actually
>> just tests those.
>>
>
> I think this is another example of buttercup tests that requires source
> .el files to run.  I'll probably open a bug on buttercup to see whether
> this is required for buttercup.  Meanwhile I think it'd probably be
> better to just disable autopkgtest as the tests are already run as part
> of the build process.

I agree.  It is important not to use autopkgtest_keep without being sure
it's the right answer.

>> You've removed the Built-Using with the justification that it's an
>> arch:all package, but that doesn't make sense; Built-Using is for
>> licensing reasons, and may well be applicable to an arch:all package (I
>> think this came up before with one of your uploads?).
>
> Ah I was following the suggestions of Lintian which said it cannot be
> used by arch:all packages which is probably wrong.

See #999785.

> On the other hand, on a closer look at the policy regarding
> Built-Using on section 7.8[1], it has the following passage:
>
> ,
> | This field should be used only when there are license or DFSG
> | requirements to retain the referenced source packages. It should not be
> | added solely as a way to locate packages that need to be rebuilt against
> | newer versions of their build dependencies.
> `
>
> I checked that lua-mode is of GPL-2+[2], and of all its dependencies
> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
> requirement.  The change was introduced in [3] but it was part of the
> modernization effort so there is no direct justification of adding the
> field.  May be I'm missing something here?

It sounds like it shouldn't have been introduced.  So you can remove it
based on your reading of Policy, and briefly note your reasoning in
d/changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069078: Acknowledgement (RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs)

[Sean Whitton]

control: tag -1 + moreinfo

Hello Xiyue,

Please explain the autopkgtest_keep change.  Remember that autopkgtests
are to test the installed package.  If you need to keep the .el files,
it must be for some reason other than because the test suite actually
just tests those.

You've removed the Built-Using with the justification that it's an
arch:all package, but that doesn't make sense; Built-Using is for
licensing reasons, and may well be applicable to an arch:all package (I
think this came up before with one of your uploads?).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069001: dgit: tag2upload: [dgit ...] should include source= and version= fields

[Sean Whitton]

Source: dgit
Version: 11.8
Severity: important

Dear maintainer,

As discussed elsewhere, we want source= and version= tags in the
tag2upload metadata to prevent the possibility of a certain form of
attack by someone who is able to replace git objects on salsa.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#877337: single-page html of debian-policy to be revived?

[Sean Whitton]

Hello,

On Sun 14 Apr 2024 at 01:57pm +02, Holger Wansing wrote:

> 1.
> Currently, the package does not ship this version. So this would have to
> be re-added there.

The changelog for 4.2.0.0 says

  * Stop installing policy-1.html because Sphinx's singlehtml output is
too buggy at present (Closes: #873456, #876075, #879048).
See also #877367.  Thanks to Paul Wise for switching the web mirrors
away from policy-1.html.

I had forgotten about this.  It seems that the first thing to do would
be to determine if the issues discussed in those bugs still exist.

> 2.
> There are pro's and con's for both the single-page and multi-page variants.
> Thus the only possible way IMO is to ship both via www.d.o.
> The developers-refererence also ships both already, so it would be consistent
> there.

... but if dev-ref is already shipping both, maybe singlepage is indeed
usable these days ...

> 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 :\

Holger L., did you know about this issue?
Did you decide it was worth publishing anyway?

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote:

> 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.

I agree, and still think we should be publishing the single page version.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Ping again.  Thanks.

On Thu 28 Mar 2024 at 01:33pm +08, Sean Whitton wrote:

> Hello,
>
> On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote:
>
>> The vote has concluded.  The result is that the Technical Committee
>> recommends that Craig Small  be appointed by the Debian Project
>> Leader to the Technical Committee.
>>
>> Jonathan, over to you.
>
> Quick ping about this.  The appointment holds up some administrative
> stuff for us.  Thanks.

-- 
Sean Whitton

Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages

[Sean Whitton]

Hello,

On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote:

> On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote:
>> Do you have your 1.34 upload of buttercup in git, please?
>
> Yup, it's all on Salsa.

Er.  I got confused, then, didn't I?  Should this RFS be closed?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages

[Sean Whitton]

Hello Jeremy,

Do you have your 1.34 upload of buttercup in git, please?

Xiyue, you need to merge in the 1.34 upload, either something from
Jeremy, or we can fall back to merging from dgit/sid.  This has happened
a few times now -- please check whether you're missing uploads before
starting to work on top of the branch on salsa :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Mon 08 Apr 2024 at 07:15pm +02, Salvatore Bonaccorso wrote:

> Hi Sebastian,
>
> On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote:
>> control: tags -1 patch
>> control: reassign -1 yapet 2.6-1
>>
>> On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote:
>> > There might be a related change that doesn't allow restarting the
>> > operation with the same context without setting things up again.
>>
>> Yapet is broken and the openssl update revealed the problem. I
>> reassigned it to yapet 2.6 but probably affects earlier versions.
>> But then the 1.1.1 series is no longer maintained so…
>>
>> Patches attached and they hold the details of why and such.
>>
>> This needs to be applied to unstable and Bookworm.
>> The testsuite passes and I can open Sean's test file.
>> Further testing is welcome by actual users ;)
>
> Thanks for the investigation and bringing the fixes to upstream
> already: https://github.com/RafaelOstertag/yapet/pull/29
>>
>> I can NMU if needed just yell.
>
> No need for that, will take it with my maintainers hat on from here.

Many thanks both.

-- 
Sean Whitton

Bug#963524: fixed in debian-policy 4.7.0.0

[Sean Whitton]

Hello,

On Sun 07 Apr 2024 at 08:44am +02, Petter Reinholdtsen wrote:

> For the record, and as stated in https://bugs.debian.org/999598 >,
> I would rather have the description lines back in the changes file to
> provide the information in the emails presenting uploads, instead of
> dropping them.  I guess this bug report will be closed unsolved instead.

In this case we weren't really making a decision on the Policy side, but
just updating documentation.  So it can be changed back if the decision
is reversed.

-- 
Sean Whitton

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Sean Whitton]

Hello,

On Sun 07 Apr 2024 at 08:54am +02, Paul Gevers wrote:

> Hi,
>
> On Sat, 09 Sep 2023 18:51:52 -0700 Russ Allbery  wrote:
>
> """
> +``systemd`` uses dependency and ordering information contained within the
> ++enabled unit files to decide which services to run and in which order.
> """
>  ^ is that "+" before "enabled" really intended? It looks weird to me.

Fixed in git, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Sat 06 Apr 2024 at 03:24pm +02, Salvatore Bonaccorso wrote:

> As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is
> it reassigned to yapet? (the regression is as well present in
> unstable).

I was just thinking that it may be a flaw in how YAPET calls into
openssl, and we don't have evidence either way atm.

> That said: You are right, opening 1.0 format databases should still
> work that said, but is regressing with the openssl update. And as per
> manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET
> 2.0 files are converted to YAPET 2.0 files when changing the master
> password. Once converted, the files can no longer be read by pre YAPET
> 2.0 versions.
>
> I can ask upstream, but currently yapet will FTBFS with problems in
> the testsuite anyway, and the problems are related.
>
> And yapet FTBFS with the new openssl in bookworm-pu in same way as in
> unstable (but not with the old version).
>
> Thus I believe #1068045 and #1064724 are actually related.

Thanks for the info.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Sat 06 Apr 2024 at 09:30pm +02, Sebastian Andrzej Siewior wrote:

> On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote:
>> Hello,
> Hi,
>
>> It looks like the problem is opening YAPET1.0-format databases, which
>> the manpage explicitly says is meant to work.
>>
>> I've made a sample YAPET1.0 database using a stretch VM.  Using the
>> attached:
>>
>> - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it.
>> - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't.
>
> Thank you for the testcase. It asks for a password, what is it?

Sorry!  It's 'asdf'.

-- 
Sean Whitton

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote:

> On 30 March 2024 13:14:37 CET, Sean Whitton  wrote:
>
>>I downgraded, changed the password for my database to 'asdf',
>>changed it back to the password it had before, upgraded libssl3,
>>and the bug did not appear.
>>
>>I reverted to my original db, downgraded again, deleted an entry without
>>changing the password, upgraded, and the bug appeared.
>>
>>I can't really say more without compromising my opsec.  But does the
>>above give any clues / further debugging ideas?
>
> I would look at the function yapet is using from openssl and compare the 
> results.
> Could create a database from scratch an use similar patterns in terms number
> of entries and password (length, special characters) until you have something
> that you can share with me. I don't mind if throw it in my inbox without Cc:
> the bug.

It looks like the problem is opening YAPET1.0-format databases, which
the manpage explicitly says is meant to work.

I've made a sample YAPET1.0 database using a stretch VM.  Using the
attached:

- On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it.
- On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't.

Thanks again.

-- 
Sean Whitton


yapet1.0.pet
Description: Binary data


signature.asc
Description: PGP signature

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

control: reassign -1 libssl3,yapet
control: found -1 libssl3/3.1.5-1
control: found -1 yapet/2.6-1
control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB

Hello,

On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote:

>>
>>> Also, yapet is unchanged in unstable. Is the problem there, too?
>>

I have now confirmed that the problem is in unstable too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

control: tag -1 + pending

Hello,

On Sat 06 Apr 2024 at 01:23am -04, Daniel Kahn Gillmor wrote:

> On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote:
>> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:
>>
>>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>>>> Thanks, but can you sign this off?  Ty!
>>>
>>> Sure, attached.  Let me know if you need anything different.
>>
>> Thanks.  Unfortunately, it doesn't seem to fix the FTBFS, on sid.
>
> Here is a replacement patch, tested now against mypy 1.9.0-4.  It also
> updates the typechecking for imap-dl for the same version of mypy.

Thanks!  Just to note that I also had to add python3-gssapi as a b-d.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sat 06 Apr 2024 at 12:15pm +08, Sean Whitton wrote:

> Hi Russ,
>
> We have two seconded solutions, so you and I should perhaps break the
> tie.  I prefer the Bill's 'Autobuild: no' solution as the more
> conservative change: we only have data about packages that are currently
> autobuilt, not those that aren't, so we might be making those buggy if
> we just ban network access for all non-free packages.  How about you?

(It's not actually a tie in terms of number of seconds, but we don't do
this quantatively.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hi Russ,

We have two seconded solutions, so you and I should perhaps break the
tie.  I prefer the Bill's 'Autobuild: no' solution as the more
conservative change: we only have data about packages that are currently
autobuilt, not those that aren't, so we might be making those buggy if
we just ban network access for all non-free packages.  How about you?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068022: Document the Testsuite-Triggers field

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 11:30am +02, Christian Kastner wrote:

> Hi again,
>
> On 2024-03-29 20:30, Christian Kastner wrote:
>> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
>> Testsuite-Triggers field that seems to be part of Sources files and is
>> generated by dpkg-source >= 1.18.8.
>>
>> This field is quite useful, as given my package src:foo, I can find out
>> which packages have autopkgtests that depend on it, and are thus in the
>> set of reverse dependencies that I could check for breakage.
>
> I've read up on the change process [1], and I guess my proposal to
> submit a patch was too far into the process.
>
> Thus, I take a step back, and seek discussion first.
>
> In addition to what I've said above, I think documenting this field
> would not only enhance discoverability, but give more weight to it for
> tooling that makes use of these fields.
>
> For discussion context, I'd like to quote dsc(5) on this field:
>> Testsuite-Triggers: package-list
>>
>> This field declares the comma-separated union of all test dependencies
>> (Depends fields in debian/tests/control file), with all restrictions
>> removed, and OR dependencies flattened (that is, converted to separate AND
>> relationships), except for binaries generated by this source package and its
>> meta-dependency equivalent @.
>>
>> Rationale: this field is needed because otherwise to be able to get the test
>> dependencies, each source package would need to be unpacked.

Sounds good to me.  If you'd like to propose wording, there's some more
guidance in our README.md.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064593: issue with Debian-style html theme for sphinx-based documents

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 02:07pm +02, Holger Wansing wrote:

> Hi,
>
> Holger Wansing  wrote (Tue, 2 Apr 2024 14:47:12 +0200):
>> We need a separate copy of 3 packages in our www build tree on
>> wolkenstein and all www static mirrors (simply let DSA install those
>> packages on the machines will not work).
>> And every sphinx-based manual needs relative symlinks in its tree, pointing
>> to the above packages' content.
>> The 1ftpfiles and 7doc scripts, which need to be adapted for that, and
>> also the situation on the www mirrors is getting more complex, so I'm unsure
>> if we want this.
>> See my patch.
>>
>> On the other side, I don't see any other solution apart from developing
>> a new theme.
>
> Since there were no objections, I pushed that yesterday (+ one additional
> change was needed), and that works now.

Thank you very much again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

Hello,

On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:

> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>> Thanks, but can you sign this off?  Ty!
>
> Sure, attached.  Let me know if you need anything different.

Thanks.  Unfortunately, it doesn't seem to fix the FTBFS, on sid.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

Thanks, but can you sign this off?  Ty!
-- 
Sean Whitton

Bug#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Sean Whitton]

Hello,

On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote:

> I now tend to switch to another approach (also proposed similarly by Adam):
>
> instead of relying on the rtd-theme package in the default install path of the
> package installed by DSA, I will use the infrastructure in 1ftpfiles and
> 7doc of webmaster's cron repo, to (always) fetch the latest version of that
> package (and two more packages, which the former depends on: 
> fonts-font-awesome
> and fonts-lato, to get the needed fonts) and unpack+copy them into
> a dedicated path inside the www build tree.
>
> That path will be synced to the static www mirrors, and we can symlink
> to it from the manuals.
> (And the content of that path will automatically be kept up-to-date on
> the unstable version of packages, so we don't get outdated/orphaned
> copies of that packages in the isolated path.)
> I want the unstable version of that packages here, since they need to
> incorporate with the unstable version of the different manuals (like
> debian-policy), and those packages are built by buildd, so unstable.
>
> How does that sound in the light of Debian guidelines and best practice?
>
> Is it ok, to have such "isolated copies" of packages as described above?
>
> I have not much experience in similar things, so I would like to get
> some comments here, please.

I mean, it seems okay to me, but it's up to the web team really.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:

> Package: debian-policy
> Version: 4.6.2.1
> Severity: normal
> X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> Control: affects -1 buildd.debian.org
>
> Hi,
>
> The debian policy, section 4.9, forbids network access for packages in
> the main archive, which implicitly means they are authorized for
> packages in contrib and non-free (and non-free-firmware once #1029211 is
> fixed).
>
> This gives constraints on the build daemons infrastructure and also
> brings some security concerns. Would it be possible to extend this
> restriction to all archives?

We need to know if this is going to break existing packages and allow
some input from their maintainers.  Are you able to prepare a list of
the affected packages?

-- 
Sean Whitton

Bug#1068094: RFH: sbcl -- Common Lisp compiler and development system

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org, debian-de...@lists.debian.org, 
debian-emac...@lists.debian.org
Control: affects -1 + src:sbcl

I request assistance with maintaining SBCL in Debian.

It is the most popular Free Software compiler for Common Lisp.
So, most anyone who is interested in both Debian and Common Lisp is likely
interested in SBCL, too.

The upstream project is stable but seems relatively often to introduce changes
that break our packaging scripts.
Possibly there should be an attempt made to simplify how we do things.

This would be good for a new contributor to Debian who is otherwise
experienced with bootstrapping compilers / development environments.
You definitely don't need to be a Debian Developer to help.

The package description is:
 SBCL is a development environment for the ANSI Common Lisp language.
 It provides a native-code compiler and an integrated debugger, as well
 as all the features in the ANSI specification.
 .
 SBCL also contains other extensions to the ANSI specification, including
 a foreign-function interface, a pseudo-server API, user-extensible
 stream functionality, a Meta-Object Protocol, and an ability to run
 external processes.
 .
 To browse SBCL source definitions with development environments,
 install the sbcl-source package. For documentation on SBCL's usage
 and internals, the package sbcl-doc is provided.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Sat 30 Mar 2024 at 09:29am +01, Sebastian Andrzej Siewior wrote:

> On 2024-03-30 09:25:27 [+0800], Sean Whitton wrote:
>> Package: libssl3
>> Version: 3.0.13-1~deb12u1
>> Severity: grave
>> Justification: renders package unusable
>> X-Debbugs-Cc: t...@security.debian.org
>> Control: affects -1 + yapet
>>
>> Dear maintainer,
>>
>> This version of libssl3 from bookworm-proposed-updates breaks YAPET.
>> When I try to open my passwords database, it claims the master password I 
>> type
>> is incorrect.  But downgrading libssl3 fixes the problem.
>
> Can you give me more to go on? I installed yapet created a database,
> updated and it remains to work.
> Maybe supply a test database which works with the old but not with the
> new library.

I downgraded, changed the password for my database to 'asdf',
changed it back to the password it had before, upgraded libssl3,
and the bug did not appear.

I reverted to my original db, downgraded again, deleted an entry without
changing the password, upgraded, and the bug appeared.

I can't really say more without compromising my opsec.  But does the
above give any clues / further debugging ideas?

> Also, yapet is unchanged in unstable. Is the problem there, too?

Unfortunately I do not have an unstable machine to hand right now, and
until we know more about the xz-utils situation I would want to set up
something air-gapped before copying my password db in there -- but can
do that if we can't otherwise make progress.

Thanks for looking!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068022: Document the Testsuite-Triggers field

[Sean Whitton]

Hello,

On Fri 29 Mar 2024 at 08:30pm +01, Christian Kastner wrote:

> Package: debian-policy
> Version: 4.6.2.0
> Severity: wishlist
>
> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
> Testsuite-Triggers field that seems to be part of Sources files and is
> generated by dpkg-source >= 1.18.8.
>
> This field is quite useful, as given my package src:foo, I can find out
> which packages have autopkgtests that depend on it, and are thus in the
> set of reverse dependencies that I could check for breakage.
>
> I'd provide a patch based on the documentation in dsc(5), but I don't
> know what the current process is. Does anyone have a link to a doc on
> how to submit a change?

There is a chapter of Policy regarding the Policy Changes Process.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Package: libssl3
Version: 3.0.13-1~deb12u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@security.debian.org
Control: affects -1 + yapet

Dear maintainer,

This version of libssl3 from bookworm-proposed-updates breaks YAPET.
When I try to open my passwords database, it claims the master password I type
is incorrect.  But downgrading libssl3 fixes the problem.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libssl3 depends on:
ii  libc6  2.36-9+deb12u5

libssl3 recommends no packages.

libssl3 suggests no packages.

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067895: RFS: emacs-format-all-the-code/0.6.0-1 [Team] -- Auto-format C, C++, JS, Python, Ruby and 50 other languages

[Sean Whitton]

control: tag -1 + moreinfo

Looks like the Source: in d/copyright is bogus?

-- 
Sean Whitton

Bug#1067924: dgit: can't clone/fetch dockerfile-mode past few days

[Sean Whitton]

Package: dgit
Version: 11.6
Severity: important

spwhitton@chiark:~/tmp>dgit clone dockerfile-mode
canonical suite name for unstable is sid
fetching existing git history
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
dgit: failed command: git ls-remote -q --refs 
https://git.dgit.debian.org/dockerfile-mode 'refs/tags/archive/debian/*' 
'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map

dgit: error: subprocess failed with error exit status 128
255 spwhitton@chiark:~/tmp>

I was able to successfully dgit push the package, after doing an
import-dsc for the purposes I wanted to fetch.

-- 
Sean Whitton

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Sean Whitton]

Hello,

On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello,
>>
>> Rob, can you review the implementation in d/rules for Xiyue's patch to
>> this bug, please?  I'm not sure it's the straightforward way to do it.
>>
>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
>> for the relationships.
>
> Ah indeed, I should update the versions after the Emacs 29.3 upload,
> though I think you meant "1:29.3+1-2".  Also, as we are just moving
> files from emacs-common to emacs-pgtk, breaks/replaces is only needed
> from emacs-pgtk to emacs-common but no the other way around, so I
> dropped the breaks on emacs-pgtk from emacs-common.
>
> I have updated the patch accordingly and attached here.  PTAL.

Thanks.

> (BTW, I'm always curious about the "+1" part of the version number.  I
> would expect something like "+dfsg" or "+ds" as we are dropping some
> of the non-DFSG conformant files, but why "+1"? :)

It's just in case the DFSG split is done incorrectly and another attempt
is required -- given how complex it is.

-- 
Sean Whitton

Bug#1067581: RFS: package-lint-el/0.22-1 [Team] -- package-lint Flymake backend

[Sean Whitton]

control: tag -1 + moreinfo

Hello,

Looks like you didn't push to master :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Hello,

On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote:

> The vote has concluded.  The result is that the Technical Committee
> recommends that Craig Small  be appointed by the Debian Project
> Leader to the Technical Committee.
>
> Jonathan, over to you.

Quick ping about this.  The appointment holds up some administrative
stuff for us.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Sean Whitton]

Hello,

Rob, can you review the implementation in d/rules for Xiyue's patch to
this bug, please?  I'm not sure it's the straightforward way to do it.

Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
for the relationships.

Thanks both.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

 types in assignment 
> (expression has type "Message | str | list[Message | str] | Any", variable 
> has type "list[Message] | str | bytes | None")  [assignment]
> email-print-mime-structure:109: error: Incompatible types in assignment 
> (expression has type "Message | bytes | Any", variable has type 
> "list[Message] | str | bytes | None")  [assignment]
> email-print-mime-structure:121: error: Incompatible types in assignment 
> (expression has type "Message | bytes | Any", variable has type 
> "list[Message] | str | bytes | None")  [assignment]
> email-print-mime-structure:181: error: Incompatible types in assignment 
> (expression has type "Message | str | list[Message | str] | Any", variable 
> has type "list[Message] | str | bytes | None")  [assignment]
> Found 6 errors in 1 file (checked 1 source file)
> make[1]: *** [Makefile:15: check] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: error: make -j2 check returned exit code 2
> make: *** [debian/rules:4: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> 
>
> The above is just how the build ends and not necessarily the most relevant 
> part.
> If required, the full build log is available here:
>
> https://people.debian.org/~sanvila/build-logs/202403/
>
> About the archive rebuild: The build was made on virtual machines
> of type m6a.large from AWS, using sbuild and a reduced chroot
> with only build-essential packages.
>
> If you could not reproduce the bug please contact me privately, as I
> am willing to provide ssh access to a virtual machine where the bug is
> fully reproducible.
>
> If this is really a bug in one of the build-depends, please use
> reassign and affects, so that this is still visible in the BTS web
> page for this package.
>
> Thanks.
>

-- 
Sean Whitton

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 4307e89..2fb05cd 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -685,7 +685,7 @@ variables are also available.
>
>  The ``debian/substvars`` file is usually generated and modified
>  dynamically by ``debian/rules`` targets, in which case it must be
> -removed by the ``clean`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
>
>  See :manpage:`deb-substvars(5)` for full details about source variable
>  substitutions, including the format of ``debian/substvars``.
> @@ -725,8 +725,9 @@ building packages to record which files are being 
> generated.
>
>  It should not exist in a shipped source package, and so it (and any
>  backup files or temporary files such as ``files.new``)  [#]_ should be
> -removed by the ``clean`` target. It may also be wise to ensure a fresh
> -start by emptying or removing it at the start of the ``binary`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
> +It may also be wise to ensure a fresh start by emptying or removing it at the
> +start of the ``binary`` target.
>
>  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>  to ``debian/files`` for the ``.deb`` file that will be created when

Instead of "It may also be wise ..." can you use one of the sets of
magic words from Policy 1.1, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Sean Whitton]

Hello,

On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:

> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.

I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Sean Whitton]

Hello,

On Sat 23 Mar 2024 at 05:08pm +01, Holger Wansing wrote:

> While working on adapting the parts/7doc script (from Debian Webmaster
> Team's 'cron' repo), I realized that this is not going to work out of the
> box: while the concept of the symlinks mentioned above is working fine,
> when the debian-policy document is installed on a machine as usual
> (means it recides in the same path as in the binary deb package, aka
> /usr/share/doc/debian-policy/policy.html), we have the docs for the website
> on the debian.org website machine in another path. That is in
> /srv/www.debian.org/www/doc/debian-policy/.
>
> That means the (relative) symlinks will not resolve!
> Therefore I think the best solution here is, to change the relative
> symlinks into absolute ones, on the debian.org website machine.
>
> I have worked out the needed changes for cron/parts/7doc to deal with all
> this (it works fine here locally). The debian-policy package could stay
> unchanged.
> I attach the patch here just for reference; will apply it, as soon as
> sphinx-rtd-theme-common gets installed on wolkenstein
> (working on a bugreport to DSA to get this done).
>
> Closing #1066967 against sphinx-common/dh_sphinxdoc now.
> Thanks python people for your help!

Many thanks all for working on this, especially you Holger for this
scripting work.  So, we're waiting in DSA and then on your script
changes, and it'll work again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sean Whitton]

Hello,

On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote:

>>>>>> "Josh" == Josh Triplett  writes:
>
>
>
> I tend to agree with  Sean that your rationale is not convincing.
> It sounds like you want to use policy as a stick to hit people
> over the head and say "policy is not a stick."

This was basically my concern.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067630: fixed in emacs 1:29.3+1-1

[Sean Whitton]

Hello,

On Mon 25 Mar 2024 at 04:58pm +07, Max Nikulin wrote:

> On 25/03/2024 15:47, Sean Whitton wrote:
>> On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:
>>
>>> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:
>>>> Source: emacs
>>>> Source-Version: 1:29.3+1-1
>>>> Done: Rob Browning
>>>
>>> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
>>> Debian stable?
>> Neither are necessary.
>
> Do you mean that somebody is working on backporting changes to 28.2 in
> bookworm already? This bug is closed. Have I missed other ones for elpa-org in
> unstable and for emacs in stable?

No, I just mean that the bug metadata is correct.  Closed does not mean
resolved in all suites.

-- 
Sean Whitton

Bug#1067630: fixed in emacs 1:29.3+1-1

[Sean Whitton]

Hello,

On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:

> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:
>> Source: emacs
>> Source-Version: 1:29.3+1-1
>> Done: Rob Browning
>
> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
> Debian stable?

Neither are necessary.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067155: debian-policy: prerm scripts cannot actually rely on dependencies

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 01:02pm +01, Julian Andres Klode wrote:

> Package: debian-policy
> Severity: wishlist
> X-Debbugs-Cc: de...@lists.debian.org, debian-d...@lists.debian.org
>
> APT's installation planner does not consider dependencies of packages
> being scheduled for removal, so a prerm must fail equally gracefully
> as a postrm does in absence of its dependencies.
>
> This does break dpkg's assumptions which it happily tells you about,
> but this is the reality we live in.
>
> So e.g. one thing you see is that apt removes libapt-pkg6.0, then
> unpacks libapt-pkg6.0t64, then removes libapt-pkg6.0 reverse
> dependencies.
>
> Clearly APT should be considering dependencies when removing packages
> but even in that case, removals may sometimes need to be forced in the
> wrong order because any order leads to broken dependencies, so still,
> prerms should not rely on dependencies, but only on essential packages.

I'm not sure that Policy is the place to discuss a change proposal like
this, and we can't render a swathe of packages RC buggy by making such a
change here.  The archive would need to change first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sean Whitton]

Hello,

On Mon 18 Mar 2024 at 04:06am -07, Josh Triplett wrote:

> On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
>> Was there some recent packaging situation that prompted you to think
>> about this?  I'm cautious about adding it in the absence of that.
>
> Mostly, recent discussions in various places regarding whether packages
> are required to use *cron* to run periodic jobs. Policy says what
> packages must do if they install a cronjob, but that itself does not
> mandate the use of cron specifically. It seemed worth explicitly stating
> the understood-but-unwritten interpretation that having Policy about XYZ
> does not mandate that packages use XYZ.
>
> I've also seen a few arguments over the decades that amount to "Policy
> talks about A, and doesn't talk about B" being used as some amount of
> weight towards A or against B.
>
> And finally, I have occasionally seen someone try to build a Debian
> package by sitting down with the Policy manual, and start down the route
> of trying to supply everything Policy talks about that seems like it
> makes sense for the package. The mention of "Policy talking about where
> to install info documentation, but that doesn't mean you have to have
> info documentation" was not a hypothetical; I've seen that and similar
> reasoning a non-zero number of times.
>
> I figured that something like this text would help address all of those.

Thanks.  For the time being, I myself am not convinced.  Policy is not a
stick to beat maintainers with, as we say, but I'm not sure that idea is
one that ought to be in Policy itself.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067420: RM: emacsql-sqlite3 -- ROM; obsolete

[Sean Whitton]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: emacsql-sqli...@packages.debian.org
Control: affects -1 + src:emacsql-sqlite3

Quoting Aymeric Agon-Rambosson <https://bugs.debian.org/1052967#15>:

> [...] I think we should not be packaging emacsql-sqlite3 anymore, and we
> should use the occasion to remove it.
>
> The upstream maintainers themselves contend that package developers should not
> use it, and rely on emacsql instead :
> https://github.com/cireu/emacsql-sqlite3#important-note.
>
> It has no reverse dependencies [...]
>
> The next release of emacsql will not support it, and will make it obsolete,
> a point of view the upstream maintainers of emacsql-sqlite3 themselves seem
> to accept : https://github.com/cireu/emacsql-sqlite3/issues/38.
>
> It was removed from MELPA last April for this reason.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Sean Whitton]

Hello,

On Wed 22 Feb 2023 at 05:21pm -07, Sean Whitton wrote:

>
> Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
> will never hit any of those behaviours.  So it's a high cost to impose
> on someone in a position such as mine.
>

I still regret that this change went into bookworm, and would like to
simplify things again.  I still think that this is a case where the cost
of correctness-in-all-cases is too high.

I think we can revert the behavioural change and come up with an
appropriate warning in the workflow manpage.  It might be relevant to
recommend users consider using source format 1.0, even.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1050713: mixed team workflows incl. --overwrite, split brain

[Sean Whitton]

Hello,

On Wed 20 Mar 2024 at 06:12pm GMT, Ian Jackson wrote:

> Control: severity -1 important
>
> Having thought about it, I propose the following changes to try to
> help with this:
>
> 1. Provide an alias for --overwrite (without version) called
>something like --trust-changelog, and make that be the primary name.
>That's really what --overwrite (without version) does.

Nice.

> 2. Provide a new option --collab-sceptics [1] which implies
>--split-view=always --trust-changelog.
>
> [1] I'm very unusre of the right name.  This option should be used in
> two situations:
>
>  (a) The package is team maintained, and you are doing a team upload;
>  your teammates don't use dgit (and object to the .dsc import
>  commits that can happen in the dgit history (so the maintainer
>  history doesn't have the .dsc imports).  So you must hide the
>  .dsc imports (which are in the dgit view) and trust the
>  changelog.
>
>  (b) You are doing an NMU, and you're doing it from maintainer git,
>  but the maintainer doesn't use dgit.  Nevertheless the maintainer
>  wants your git commits.  So you want to provide a git branch that
>  doesn't have the .dsc import commits (and you must truxt the
>  changelog).

How about --with-non-dgit ?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1050713: mixed team workflows incl. --overwrite, split brain

[Sean Whitton]

Hello,

On Thu 21 Mar 2024 at 10:16am +08, Sean Whitton wrote:

>
> How about --with-non-dgit ?

Or, combining suggestions, --collab-non-dgit .

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Sean Whitton]

control: tag -1 + pending
control: close 1067133

Hello,

On Wed 20 Mar 2024 at 12:06am -07, Xiyue Deng wrote:

> Found the upstream fix for the test failures[1].  I have backported the
> patch in [2]

In the future, especially with dgit-maint-merge(7), it's a good idea to
use 'git cherry-pick -x' to backport upstream patches like this, so that
it's easily traceable by others.  In lieu of this, I've added a note of
the upstream commit in d/changelog.

> Meanwhile, it looks like I was jumping to conclusion a little too
> soon.  TL;DR it will still get stuck without running in the source
> directory.  So IMHO disabling autopkgtest would be a sensible choice,
> which I did in [3].
>
> Also built and uploaded the latest version to mentors[4].  PTAL.  TIA!
>
> Longer analysis of tests getting stuck:
>
> Comparing working and not working settings using strace, I noticed that
> during buttercup tests it would get stuck closing
> test/clojure-mode-refactor-rename-ns-alias-test.el, which I still didn't
> know why unfortunately.  If I disabled/renamed this file, buttercup
> would finish running, and would fail due to unable to load clojure-mode
> in the source tree.  And yes, specifically the file in the source tree
> as in the following error message:
>
> ,
> | Cannot open load file: No such file or directory,
> | /home/manphiz/Projects/debian-packaging/clojure-mode/clojure-mode
> `
>
> I even tried directly using `--eval "(load-library \"clojure-mode\")"`
> which actually succeeded, but it still failed with the same error.
> Given this I would have to assume that buttercup requires running in the
> source tree.

It's likely possible to patch the tests; I doubt it's fundamental to Buttercup.

Thanks for adopting the package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 04:04pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:
>>
>>> Control: tags -1 pending
>>>
>>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].
>>
>> Thanks for looking at this, but I'm not sure the fix is valid.
>>
>> The idea behind autopkgtest_keep is to ensure we test the installed
>> package, not the files in the source tree.  But if you just include them
>> all, don't the files in the source tree get tested?
>
> After some testing this turns out to be an issue with buttercup: if the
> required module is not immediately in the current loading path it will
> get stuck.  I've tested with `-L` and directly `--eval "(load-library
> 'clojure-mode)"` and while the load-library succeeded it will still get
> stuck.
>
> Meanwhile I have tested locally that with a newer buttercup version 1.34
> this won't be an issue anymore.  However it fails some other tests which
> we'll have to deal with later.
>
> So this is a workaround of the buttercup issue in 1.31.  An alternative
> is to disable autopkgtest as it's doing basically the same thing as the
> test during building.
>
> Wdyt?

Looks like buttercup 1.34 is now in unstable, so perhaps worth making an
attempt at fixing those failing tests, before considering disabling?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:

> Control: tags -1 pending
>
> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].

Also, you need to remove me from Uploaders in order to close the ITA :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:

> Control: tags -1 pending
>
> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].

Thanks for looking at this, but I'm not sure the fix is valid.

The idea behind autopkgtest_keep is to ensure we test the installed
package, not the files in the source tree.  But if you just include them
all, don't the files in the source tree get tested?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sean Whitton]

Hello Josh,

Was there some recent packaging situation that prompted you to think
about this?  I'm cautious about adding it in the absence of that.

-- 
Sean Whitton

Bug#904233: Adoption of persp-projectile

[Sean Whitton]

Hello,

On Tue 12 Mar 2024 at 08:47pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello Xiyue,
>>
>> Do you still intend to adopt persp-projectile?
>>
>> Thanks.
>
> Yes.  And it seems I forgot to close this ITA bug in the Changelog.  Can
> we close this directly instead?

We could, but I don't think you actually adopted it :)

-- 
Sean Whitton

Bug#904233: Adoption of persp-projectile

[Sean Whitton]

Hello Xiyue,

Do you still intend to adopt persp-projectile?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote:
> Package: tech-ctte
> X-debbugs-cc: csm...@debian.org, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Craig Small  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> C: Recommend to Appoint Craig Small 
> F: Further Discussion
> ===END

I vote

C > F

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Package: tech-ctte
X-debbugs-cc: csm...@debian.org, lea...@debian.org

I call for votes on the following ballot to fill a vacant seat on the
Debian Technical Committee.  The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt.

===BEGIN
The Technical Committee recommends that Craig Small  be
appointed by the Debian Project Leader to the Technical Committee.

C: Recommend to Appoint Craig Small 
F: Further Discussion
===END

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065148: vokoscreen-ng: asks to install package with wrong name

[Sean Whitton]

Package: vokoscreen-ng
Version: 3.5.0-1
Severity: minor

Dear maintainer,

On bookworm, when you start vokoscreen-ng under Sway, there is a popup asking
you to install "gstreamer-plugins-pipewire".  But the package one should
install on Debian is gstreamer1.0-pipewire.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vokoscreen-ng depends on:
ii  gstreamer1.0-plugins-good  1.22.0-5+deb12u1
ii  libc6  2.36-9+deb12u4
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2
ii  libgstreamer1.0-0  1.22.0-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus55.15.8+dfsg-11
ii  libqt5gui5 5.15.8+dfsg-11
ii  libqt5multimedia5  5.15.8-2
ii  libqt5network5 5.15.8+dfsg-11
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14
ii  libwayland-client0 1.21.0-1
ii  libx11-6   2:1.8.4-2+deb12u2

Versions of packages vokoscreen-ng recommends:
ii  gstreamer1.0-libav 1.22.0-2
ii  gstreamer1.0-pulseaudio1.22.0-5+deb12u1
ii  libqt5multimedia5-plugins  5.15.8-2
ii  pulseaudio 16.1+dfsg1-2+b1

Versions of packages vokoscreen-ng suggests:
ii  gstreamer1.0-plugins-bad   1.22.0-4+deb12u5
ii  gstreamer1.0-plugins-ugly  1.22.0-2+deb12u1
pn  gstreamer1.0-vaapi 
ii  intel-media-va-driver  23.1.1+dfsg1-1

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#973393: truncate less of the backtrace during failing ert tests

[Sean Whitton]

control: tag -1 + pending

Applied, thanks.

-- 
Sean Whitton

Bug#973393: truncate less of the backtrace during failing ert tests

[Sean Whitton]

Hello,

On Mon 26 Feb 2024 at 06:16pm -08, Xiyue Deng wrote:

> Recently when debugging an ERT failure I found that enabling larger
> backtrace margin by default would be very help.

Hmm, interesting.  Can you show an example where it helps, so I can get
an idea of what you have in mind?

> I have tested [1] in my fork to be working.  As dh-elpa doesn't enable
> merge requests, I'd like to gather some reviews/comments here before
> merging.  TIA!

I'd be grateful if you'd attach patches to BTS mail in the future, for
inline review.

Thanks for looking into this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs

[Sean Whitton]

control: tag -1 - moreinfo + pending

Hello,

On Tue 27 Feb 2024 at 09:17am +08, Sean Whitton wrote:

> Hmm, I added Breaks/Replaces, and piuparts is happy.  Requesting manual
> review.  Thank you.

Ah, my relations were missing the 1: epoch.  Uploading shortly.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs

[Sean Whitton]

control: tag -1 + moreinfo

Hello,

On Mon 26 Feb 2024 at 06:26pm +01, Helmut Grohne wrote:

> 4 packages from emacs have an undeclared file conflict. This may result
> in an unpack error from dpkg.
>
> The file /usr/bin/emacsclient.emacs is contained in the packages
>  * emacs-bin-common
>* 1:27.1+1-3.1+deb11u1 as present in bullseye
>* 1:27.1+1-3.1+deb11u2 as present in bullseye-security
>* 1:28.2+1-15 as present in bookworm
>* 1:29.1+1-5 as present in trixie
>* 1:29.1+1-5~bpo12+1 as present in bookworm-backports
>  * emacs-gtk/1:29.2+1-1 as present in unstable
>  * emacs-lucid/1:29.2+1-1 as present in unstable
>  * emacs-nox/1:29.2+1-1 as present in unstable
>  * emacs-pgtk/1:29.2+1-1 as present in unstable
>
> These packages can be unpacked concurrently, because there is no
> relevant Replaces or Conflicts relation. Attempting to unpack these
> packages concurrently results in an unpack error from dpkg, because none
> of the packages installs a diversion for the affected file.

Hmm, I added Breaks/Replaces, and piuparts is happy.  Requesting manual
review.  Thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Sean Whitton]

Hello,

On Sun 25 Feb 2024 at 02:24pm +01, Holger Wansing wrote:

> Seems there is more than only one issue:
>
> 1.
> In the binary package (debian-policy latest version) the above files and
> directories are existing, but the files are all empty (0 B size).
> However, in the previous version (4.6.2.0) the javascript .js files
> are also empty (0 B), so that's most probably not the issue.
> I remember we don't have full javascript functionality in our sphinx-based
> manuals on debian.org for a longer time, search is not working for example.
> That's #1026446, #872944, #987943.
>
> In a local build here, they are all fine, and the document is displayed
> correctly. But that's build on bookworm, so sphinx version 5.3.0.
> The binary packages built by buildd will get build on sphinx 7.2.x
> I think, so maybe there is the difference?
> Maybe we need some adaption for latest sphinx version?
>
>
> 2.
> The first file from above list _static/css/theme.css is likely to be
> the point, since the html layout is completely broken.
> That file is also empty in latest debian-policy binary package.
> Since it is fine in local build here, also an issue with latest sphinx
> version maybe ???
> Or do we no longer need _static/css/theme.css, as we now have
> _static/debian.css ?
>
>
> 3.
> Despite the fact, that the files from above are empty, there seems to be
> another issue with debian.org website:
> the subdirectories under _static are not existing on debian.org, as well as
> the files within of course (like _static/css/theme.css).
> Apparently there is some more magic needed in webmaster-team's cron
> https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7doc?ref_type=heads#L319
> to get such files copied over to debian.org during website build.
>
> But first, we need to have a working version in the binary package,
> since that's the basis for website build.

I guess I should have done a debdiff huh? :)

Thank you for the analysis.  Osamu, Stéphane, could you take a look?
Thank you.

-- 
Sean Whitton