Bug#1012736: cpufreqd: failed to parse profile= per CPU node at Rules section.

[Kyuma Ohta]

Package: cpufreqd
Version: 2.4.2-2.3
Severity: important

Dear Maintainer,
  At [Rule] Section, setting profile per CPU node failes to parse cpufreqd.conf.
  i.e)
 profile=foo_profile -> Success.
 profile=ALL:foo_profile -> Success.
 profile=CPU0:foo_profile -> Failed with below log;
 > init_configuration   : Wrong format for Profile name 
"CPU0:foo_profile".
  This is bug of config parser around [Rule] section.   
 

Below is fix for this issue.
Best regards,
Ohta.

Patch:
--- cpufreqd-2.4.2.orig/src/config_parser.c
+++ cpufreqd-2.4.2/src/config_parser.c
@@ -834,7 +834,7 @@ int init_configuration(struct cpufreqd_c
 
strncpy(profile_name, strstr(token, ":") + 1, 
MAX_STRING_LEN);
cpu_num = atoi(token + 3);
-   if (profile_name[0]) {
+   if (!profile_name[0]) {
clog(LOG_ERR, "Wrong format for Profile 
name \"%s\".\n",
token);
return -1;



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.3-homebrew-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cpufreqd depends on:
ii  libc62.33-7
ii  libcpufreq0  008-2
ii  libsensors5  1:3.6.0-7
ii  libsysfs22.1.1-1
ii  lsb-base 11.2

Versions of packages cpufreqd recommends:
ii  acpid  1:2.0.33-1

Versions of packages cpufreqd suggests:
ii  cpufrequtils  008-2

-- Configuration Files:
/etc/cpufreqd.conf changed:
[General]
pidfile=/run/cpufreqd.pid
poll_interval=2
verbosity=6
enable_remote=1
remote_group=cpufreq
[/General]
[sensors_plugin]
sensors_conf=/etc/sensors3.conf
[/sensors_plugin]
[Profile]
name=On Demand High
minfreq=0%
maxfreq=100%
policy=ondemand
freq_step=10
sampling_rate=10%
[/Profile]
[Profile]
name=On Demand Middle
minfreq=0%
maxfreq=75%
policy=ondemand
up_threshold=5
freq_step=5
sampling_rate=5%
[/Profile]
[Profile]
name=On Demand Low
minfreq=0%
maxfreq=15%
policy=ondemand
freq_step=5
sampling_rate=50%
[/Profile]
[Profile]
name=SCHED_Very_High
minfreq=0%
maxfreq=100%
policy=schedutil
up_threshold=15
down_threshold=5
ignore_nice_load=0
freq_step=5
sampling_rate=5%
[/Profile]
[Profile]
name=SCHED_Very_High
minfreq=0%
maxfreq=100%
policy=schedutil
up_threshold=15
down_threshold=5
ignore_nice_load=0
freq_step=5
sampling_rate=5%
[/Profile]
[Profile]
name=SCHED_High
minfreq=0%
maxfreq=85%
policy=schedutil
up_threshold=5
down_threshold=10
ignore_nice_load=0
freq_step=10
sampling_rate=5%
[/Profile]
[Profile]
name=SCHED_Middle
minfreq=0%
maxfreq=75%
policy=schedutil
freq_step=15
sampling_rate=10%
[/Profile]
[Profile]
name=SCHED_Middle_Low
minfreq=0%
maxfreq=45%
policy=schedutil
up_threshold=5
down_threshold=10
freq_step=15
sampling_rate=30%
[/Profile]
[Profile]
name=SCHED_Low
minfreq=0%
maxfreq=30%
policy=schedutil
up_threshold=5
down_threshold=5
freq_step=1
sampling_rate=45%
[/Profile]
[Profile]
name=CONSERVATIVE Very_High
minfreq=0%
maxfreq=100%
policy=conservative
ignore_nice_load=0
freq_step=5
sampling_rate=5%
[/Profile]
[Profile]
name=CONSERVATIVE High
minfreq=0%
maxfreq=85%
policy=conservative
ignore_nice_load=0
freq_step=5
sampling_rate=5%
[/Profile]
[Profile]
name=CONSERVATIVE Middle
minfreq=0%
maxfreq=75%
policy=conservative
freq_step=5
sampling_rate=10%
[/Profile]
[Profile]
name=CONSERVATIVE Middle_Low
minfreq=0%
maxfreq=45%
policy=conservative
up_threshold=5
down_threshold=10
freq_step=10
sampling_rate=30%
[/Profile]
[Profile]
name=CONSERVATIVE Low
minfreq=0%
maxfreq=30%
policy=conservative
up_threshold=5
down_threshold=5
freq_step=1
sampling_rate=45%
[/Profile]
[Profile]
name=Performance High
minfreq=70%
maxfreq=100%
policy=performance
[/Profile]
[Profile]
name=Performance Low
minfreq=0%
maxfreq=70%
policy=performance
[/Profile]
[Profile]
name=Powersave High
minfreq=0%
maxfreq=100%
policy=powersave
sampling_rate=20%
[/Profile]
[Profile]
name=Powersave Middle
minfreq=0%
maxfreq=75%
policy=powersave
sampling_rate=30%
[/Profile]
[Profile]
name=Powersave Low
minfreq=0%
maxfreq=30%
policy=powersave
sampling_rate=30%
[/Profile]
[Profile]
name=Powersave Very Low
minfreq=0%
maxfreq=20%
policy=powersave
up_threshold=65
down_threshold=5
sampling_rate=20%
[/Profile]
name=AC Rule Very_High ALL
ac=on# (on/off)
sensor=Tctl:0-77 # Uprise limit.
cpu_interval=ALL:85-100,4.0
profile=SCHED_High
[/Rule]
[Rule]
name=AC Rule 

Bug#1012362: transition: luajit

[M. Zhou]

On Sun, 2022-06-12 at 21:19 +0200, Paul Gevers wrote:
> Hi Mo,
> 
> On 10-06-2022 08:00, M. Zhou wrote:
> > > There are some compilation flags tweakable. I'll try with
> > > qemu to see whether I can make it work.
> > 
> > I tried to tweak some compilation flags, and did not manage to make it
> > work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro.
> > Segfault persists.
> > 
> > So src:luajit2 is still seemingly badly broken for ppc64el.
> 
> Do you have a proposal how to continue? If you believe this can be fixed 
> soon (with help from upstream?) I'm OK with trying, but otherwise we 
> should inform the reverse dependencies on ppc64el that they have to 
> either remove themselves on ppc64el or switch to lua if that works for 
> them too. I don't want this lingering for months. src:luajit is 
> out-of-sync between testing and unstable since January already.

After browsing the corresponding github issues I think there is virtually
nobody working on the ppc64el port. And I don't have any idea on how to
fix it. So let's inform the reverse dependencies to remove ppc64el support,
or switch back to lua.

The only outcome for this luajit2 transition is that s390x seems working.

Bug#1003272: lintian: chokes on overrides with "(" but no ")"

[Axel Beckert]

unmerge 1003272
unmerge 1003353
unmerge 1007002
tag 1003272 + pending
notfound 1003272 2.114.123
retitle 1003353 lintian: Override processing defective for square brackets and 
curly brackets
notfound 1003353 2.114.0
severity 1007002 important
notfound 1007002 2.114.123
tag 1007002 + wontfix
kthxbye

Hi again,

I disagree that #1003272, #1003353 and #1007002 are the same bug. The
former two are similar, but not identical and the latter was only the
reason why the second one is showing up more often. Hence unmerging
all three.

Axel Beckert wrote in #1003272:
> Tobias Frost wrote:
> > Package: lintian
> > Version: 2.114.0
>
> Felix Lechner wrote:
> > On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost  wrote:
> > >
> > > Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE
> > 
> > That is a consequence of switching to Text::Glob for overrides.
> 
> No. That feature only came _after_ 2.114.0 against which Tobias
> reported the bug:
> 
> https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe

And it actually fixed Tobias' issue. I can reproduce Tobias' issue
with 2.114.0, but no more the current git HEAD (which is approximately
2.114.211, git commit 1c7bb81662e5e23a64fc272a008ddfc75c855537 or so).

> Ack. For the current version in git, I suggest using "?" or "*" to
> match problematic characters. E.g. for myself
> 
>   links2 source: very-long-line-length-in-source-file * > 512 *graphics/font/*
> 
> worked while
> 
>   links2 source: very-long-line-length-in-source-file * > 512 [graphics/font/*

This is actually #1003353 which claims that processing of parentheses
is broken, too, but actually only seems to be about brackets.

This issue is still present in the current git HEAD. Will handle that
one separately later.

And #1007002 is only (!) about design decision to change nearly all
tag formats involving file paths and line numbers. It has nothing to
do with the other two real bugs and I have no idea why they have been
merged.

While I was (and still am) annoyed by these changes, I do value the
goal behind it. I currently suspect that we're mostly through this
migration and I do hope that no such mass-changes will ever be needed
again. Especially since — as I wrote — the following will likely never
happen without Felix working on Lintian:

> > We will likely allow globbing on the file pointer, regular expressions
> > on the annotation and require literal matches for the tag name. To
> > keep those fields separate, we may switch to a Deb822 format for
> > override files, but hope to provide automated tools for migration and
> > management similar to those we already use internally to interactively
> > recalibrate Lintian's test suite.
> 
> Given that Felix quit working on Lintian, this will likely not happen
> unless someone steps up and continues the ideas and his work.
>
> I will only try to fix things for now. (And I'm not sure how I'll
> handle this, maybe mitigate it by more fitting documentation and
> maybe some sanity checks.)

Since at least I will not revert such huge changes, I'll tag #1007002
as "wontfix" for now and downgrade it to its original severity.

We can continue working on that bug report if we find someone who
either will work on reverting all the related work (although I think,
it's both, too late and also probably way too much work given all the
other recent changes) or, probably much better, provide either a
migration script or some code which also accepts the old override
formats. In that case, I'd remove the "wontfix" again. (Sorry, Simon,
I generally agree with #1007002, but we currently have way more severe
issues with Lintian than #1007002. Hence I also didn't remove the
confirmed tag.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

[Shengjing Zhu]

X-Debbugs-CC: siret...@debian.org, t...@security.debian.org

Hi,

On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote:
> diff -Nru runc-1.0.0~rc93+ds1/debian/changelog 
> runc-1.0.0~rc93+ds1/debian/changelog
> --- runc-1.0.0~rc93+ds1/debian/changelog  2022-06-12 14:49:36.0 
> -0400
> +++ runc-1.0.0~rc93+ds1/debian/changelog  2021-05-19 14:46:14.0 
> -0400
> @@ -1,10 +1,3 @@
> -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
> -
> -  * Team upload.
> -  * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #1012030
> -
> - -- Reinhard Tartler   Sun, 12 Jun 2022 14:49:36 -0400
> -

Could you include the patch for CVE-2022-29162?

https://security-tracker.debian.org/tracker/CVE-2022-29162

If you don't have time, I can work on this later in this week.

Bug#1012734: firejail-profiles: Debian-patched transmission programs cannot run inside firejail with shipped profiles

[Mad Horse]

Package: firejail-profiles
Version: 0.9.70-1
Severity: normal

Dear Maintainer,

Debian have patched the current transmission to fit OpenSSL 3.0, but in 
order
to use the legacy RC4 algorithm, ossl-modules/legacy.so should be able 
to load
at runtime, otherwise Debian-patched transmission programs will be 
terminated

with SIGSEGV when trying to set up an EVP_CIPHER_CTX for RC4, as in the
attached backtrace. (against a /usr/local/bin/transmission-daemon built from
Debian-patched source with the same config, but with debug symbols retained)

This dependency has rendered the current Debian-patched transmission 
programs

cannot run inside firejail with shipped profiles. To walk this issue around,
"private-lib /ossl-modules,legacy.so" should be added 
into

the (included) profile snippet of the transmission program.


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail-profiles depends on:
ii firejail 0.9.70-1

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information
#0  0x563113cb4c0f in tr_rc4_set_key (h=0x0, key=key@entry=0x7f5ee6068170 "D\333O\357m\020F\260\213\r\216\320u\310\330Vs\273>\272", key_length=key_length@entry=20) at crypto-utils-openssl.c:255
255	if (!check_result(EVP_CIPHER_CTX_set_key_length(handle->cipher_ctx, key_length)))
[Current thread is 1 (Thread 0x7f5ee606a640 (LWP 55))]
#1  0x563113cdad31 in initRC4 (crypto=crypto@entry=0x7f5ee38f69b0, setme=setme@entry=0x7f5ee38f69b8, key=) at crypto.c:106
#2  0x563113cdb040 in tr_cryptoEncryptInit (crypto=0x7f5ee38f69b0) at crypto.c:140
#3  0x563113cdbaba in readYb (inbuf=0x7f5ee376dba0, handshake=0x7f5ee3699190) at handshake.c:460
#4  canRead (io=, arg=0x7f5ee3699190, piece=) at handshake.c:1060
#5  0x563113cc5c5b in canReadWrapper (io=0x7f5ee38f65f0) at peer-io.c:211
#6  0x563113ced542 in UTP_ProcessIncoming (conn=conn@entry=0x7f5ee376d050, packet=packet@entry=0x7f5ee6068a50 "\001", len=len@entry=363, syn=syn@entry=false) at utp.cpp:2158
#7  0x563113cee380 in UTP_IsIncomingUTP (incoming_proc=incoming_proc@entry=0x563113ca78e0 , send_to_proc=send_to_proc@entry=0x563113ca7a30 , send_to_userdata=send_to_userdata@entry=0x563114b0ac00, buffer=buffer@entry=0x7f5ee6068a50 "\001", 
len=len@entry=363, to=, tolen=16) at utp.cpp:2587
#8  0x563113ca7aba in tr_utpPacket (buf=buf@entry=0x7f5ee6068a50 "\001", buflen=buflen@entry=363, from=from@entry=0x7f5ee60689d0, fromlen=16, ss=ss@entry=0x563114b0ac00) at tr-utp.c:181
#9  0x563113ca71f5 in event_callback (s=, type=, sv=0x563114b0ac00) at tr-udp.c:285
#10 0x7f5ee7d25428 in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7
#11 0x7f5ee7d25b77 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7
#12 0x563113ca84d8 in libeventThreadFunc (veh=0x563114b0b170) at trevent.c:263
#13 0x563113c96d38 in ThreadFunc (_t=0x563114af5570) at platform.c:104
#14 0x7f5ee762ad80 in start_thread (arg=0x7f5ee606a640) at pthread_create.c:481
#15 0x7f5ee754476f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug#1003272: lintian: chokes on overrides with "(" but no ")"

[Axel Beckert]

Hi,

Tobias Frost wrote:
> Package: lintian
> Version: 2.114.0

Felix Lechner wrote:
> On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost  wrote:
> >
> > Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE
> 
> That is a consequence of switching to Text::Glob for overrides.

No. That feature only came _after_ 2.114.0 against which Tobias
reported the bug:

https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe

~/lintian/lintian → git describe
139009d5a54225ebff4509ec37b979cb898c17fe
2.114.0-32-g139009d5a

So it came 32 commits _after_ the 2.114.0 release. gitk confirms this
as well.

> We recently introduced 'pointed hints' which allow live links on our
> website to sources.d.o and soon others. In terminal output, they are
> shown as
> 
> tag annotation [file pointer]
> 
> but that format is not great for overrides.

Ack. For the current version in git, I suggest using "?" or "*" to
match problematic characters. E.g. for myself

  links2 source: very-long-line-length-in-source-file * > 512 *graphics/font/*

worked while

  links2 source: very-long-line-length-in-source-file * > 512 [graphics/font/*

bailed out with a regexp syntax error, but now at
"/usr/share/perl5/Text/Glob.pm line 18", which might be actually a bug
in Text::Glob which does not seem to catch unproper shell bracket
wildcards.

> We will likely allow globbing on the file pointer, regular expressions
> on the annotation and require literal matches for the tag name. To
> keep those fields separate, we may switch to a Deb822 format for
> override files, but hope to provide automated tools for migration and
> management similar to those we already use internally to interactively
> recalibrate Lintian's test suite.

Given that Felix quit working on Lintian, this will likely not happen
unless someone steps up and continues the ideas and his work.

I will only try to fix things for now. (And I'm not sure how I'll
handle this, maybe mitigate it by more fitting documentation and
maybe some sanity checks.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1012733: racket: should no longer recommend libssl1.1

[Vincent Lefevre]

Package: racket
Version: 8.5-1
Severity: serious

debian/control has for package racket:

Recommends: racket-doc (>= ${source:Upstream-Version}),
libglib2.0-0, libpangocairo-1.0-0, libjpeg62-turbo, libpng16-16,
libgtk2.0-0, libgdk-pixbuf2.0-0, libssl1.1

Due to the OpenSSL 3 transition, racket should no longer recommend
libssl1.1.

Perhaps other files, like collects/openssl/libssl.rkt, need to be
updated too, but the current Recommends prevents libssl1.1 from
being automatically removed.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages racket depends on:
ii  libc6  2.33-7
ii  liblz4-1   1.9.3-2
ii  racket-common  8.5-1
ii  sgml-base  1.30
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages racket recommends:
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.72.2-2
ii  libgtk2.0-0  2.24.33-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libpangocairo-1.0-0  1.50.7+ds-1
ii  libpng16-16  1.6.37-5
ii  libssl1.11.1.1o-1
ii  racket-doc   8.5-1

racket suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1012354: Please add support for systemd-binfmt

[Sean Whitton]

Hello Michael,

On Sun 05 Jun 2022 at 04:09PM +02, Michael Biebl wrote:

> Package: sbcl
> Version: 2:2.2.3-1
> Severity: wishlist
> Tags: patch
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: systemd-binfmt
>
> Hi,
>
> your package sbcl declares a dependency (Recommends) on binfmt-support
> and ships binfmt-support configuration files in /usr/share/binfmt/.
>
> systemd provides a builtin, cross-distro facility named systemd-binfmt to
> register binary formats.
>
> You can read more about it at
> https://www.freedesktop.org/software/systemd/man/systemd-binfmt.html
> https://www.freedesktop.org/software/systemd/man/binfmt.d.html
> https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
>
> The systemd package provides a dpkg file trigger so it is sufficient to
> simply install configuration files in /usr/lib/binfmt.d/, no
> modifications in the maintainer scripts are necessary.
>
> The attached patch adds support for systemd-binfmt and adjusts the
> dependency on binfmt-support accordingly, so binfmt-support is no longer
> installed automatically if systemd is already installed.

Thanks for the patch.  I take it you got the sbcl.conf from the
binfmt-conf package?  So systemd-binfmt means that these config files
get stored in packages rather than all stored in binfmt-conf?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages

[Paul Wise]

On Sun, 2022-06-12 at 17:50 +0200, Georges Khaznadar wrote:

> * Package name    : ai

This is a very generic name, please use php-ai as the source package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1005985: scim-skk: diff for NMU version 0.5.2-7.3

[Boyuan Yang]

Control: tags -1 +pending  +patch

Dear maintainer,

I've prepared an NMU for scim-skk (versioned as 0.5.2-7.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru scim-skk-0.5.2/debian/changelog scim-skk-0.5.2/debian/changelog
--- scim-skk-0.5.2/debian/changelog 2022-06-12 20:26:31.0 -0400
+++ scim-skk-0.5.2/debian/changelog 2022-06-12 20:23:35.0 -0400
@@ -1,3 +1,15 @@
+scim-skk (0.5.2-7.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Migrate from dpatch to dh. (Closes: #1005985, #998953)
+  * Refresh packaging:
++ Bump debhelper compat to v13.
++ Bump Standards-Version to 4.6.1.
++ Migrate to "3.0 (quilt)" source format.
+  * debian/patches: Add patch to fix LIBTOOL_EXPORT_OPTIONS.
+
+ -- Boyuan Yang   Sun, 12 Jun 2022 20:23:35 -0400
+
 scim-skk (0.5.2-7.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru scim-skk-0.5.2/debian/compat scim-skk-0.5.2/debian/compat
--- scim-skk-0.5.2/debian/compat2022-06-12 20:26:31.0 -0400
+++ scim-skk-0.5.2/debian/compat1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-7
diff -Nru scim-skk-0.5.2/debian/control scim-skk-0.5.2/debian/control
--- scim-skk-0.5.2/debian/control   2022-06-12 20:26:31.0 -0400
+++ scim-skk-0.5.2/debian/control   2022-06-12 20:15:44.0 -0400
@@ -3,8 +3,8 @@
 Priority: optional
 Maintainer: Ikuya Awashiro 
 Uploaders: Yukiharu YABUKI 
-Build-Depends: debhelper (>= 7.0.0), dpatch (>= 1.11),  libscim-dev (>=
1.4.6), autotools-dev, pkg-config, libltdl-dev
-Standards-Version: 3.9.1.0
+Build-Depends: debhelper-compat (= 13), libscim-dev (>= 1.4.6), pkg-config,
libltdl-dev
+Standards-Version: 4.6.1
 Homepage: http://scim-imengine.sourceforge.jp/
 
 Package: scim-skk
diff -Nru scim-skk-0.5.2/debian/patches/0005-AC_SUBST-
LIBTOOL_EXPORT_OPTIONS.patch scim-skk-0.5.2/debian/patches/0005-AC_SUBST-
LIBTOOL_EXPORT_OPTIONS.patch
--- scim-skk-0.5.2/debian/patches/0005-AC_SUBST-
LIBTOOL_EXPORT_OPTIONS.patch1969-12-31 19:00:00.0 -0500
+++ scim-skk-0.5.2/debian/patches/0005-AC_SUBST-
LIBTOOL_EXPORT_OPTIONS.patch2022-06-12 20:23:25.0 -0400
@@ -0,0 +1,20 @@
+From: Boyuan Yang 
+Date: Sun, 12 Jun 2022 20:23:21 -0400
+Subject: AC_SUBST LIBTOOL_EXPORT_OPTIONS
+
+---
+ configure.ac | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/configure.ac b/configure.ac
+index bd3f9fb..acf4a3f 100644
+--- a/configure.ac
 b/configure.ac
+@@ -79,6 +79,7 @@ AC_SUBST(ac_aux_dir)
+ # libtool option to control which symbols are exported
+ # right now, symbols starting with _ are not exported
+ LIBTOOL_EXPORT_OPTIONS='-export-symbols-regex "^[[^_]].*"'
++AC_SUBST([LIBTOOL_EXPORT_OPTIONS])
+ 
+ # Extra args.
+ AC_ARG_ENABLE(debug,
diff -Nru scim-skk-0.5.2/debian/patches/00list scim-skk-
0.5.2/debian/patches/00list
--- scim-skk-0.5.2/debian/patches/00list2022-06-12 20:26:31.0
-0400
+++ scim-skk-0.5.2/debian/patches/00list1969-12-31 19:00:00.0
-0500
@@ -1,4 +0,0 @@
-01_error_check_to_cdb_get
-02_scim_skk_dictionary.cpp
-20_gcc-4.3-fixes
-99_fix_ftbfs_gtk.dpatch
diff -Nru scim-skk-0.5.2/debian/patches/01_error_check_to_cdb_get.dpatch scim-
skk-0.5.2/debian/patches/01_error_check_to_cdb_get.dpatch
--- scim-skk-0.5.2/debian/patches/01_error_check_to_cdb_get.dpatch  2022-
06-12 20:26:31.0 -0400
+++ scim-skk-0.5.2/debian/patches/01_error_check_to_cdb_get.dpatch  1969-
12-31 19:00:00.0 -0500
@@ -1,48 +0,0 @@
-#! /bin/sh /usr/share/dpatch/dpatch-run
-## 01_error_check_to_cdb_get.dpatch by Ikuya Awashiro 
-##
-## All lines beginning with `## DP:' are a description of the patch.
-## DP: No description.
-
-@DPATCH@
-diff -urNad scim-skk-0.5.2~/src/cdb.cpp scim-skk-0.5.2/src/cdb.cpp
 scim-skk-0.5.2~/src/cdb.cpp2005-11-11 20:05:51.0 +0900
-+++ scim-skk-0.5.2/src/cdb.cpp 2005-12-23 22:18:33.0 +0900
-@@ -70,14 +70,21 @@
- {
- if (!m_open_flag) return false;
- 
--bool retval = false;
--unsigned int hash_val = calc_hash(key);
--unsigned int hashtbl_pos = get_value((hash_val % 256) * 2 * 4);
--unsigned int hashtbl_len = get_value((hash_val % 256) * 2 * 4 + 4);
--unsigned int entry_point =
--hashtbl_pos + ((hash_val / 256) % hashtbl_len) * 2 * 4;
--unsigned int entry_hashval = get_value(entry_point);
--unsigned int entry_pos = get_value(entry_point + 4);
-+unsigned int hash_val; /* hash value of key */
-+unsigned int hashtbl_pos, hashtbl_len; /* position and length of
-+  the hash table */
-+unsigned int entry_point;  /* position of the entry */
-+unsigned int entry_hashval, entry_pos; /* hash value and position of
-+  the entry */
-+hash_val = calc_hash(key);
-+hashtbl_pos = get_value((hash_val % 256) * 2 * 4);
-+hashtbl_len = get_value((hash_val % 

Bug#1012731: pulseaudio mutes sound when plugging and unplugging headphones

[Ben Goodwin]

Package: pulseaudio
Version: 15.0+dfsg1-4+b1
Severity: normal
X-Debbugs-Cc: vbgoodw...@gmail.com

When I plug in or unplug headphones, pulseaudio mutes the sound
(mute button lights up) and turns the volume down to 0. To get sound
back, I have to unmute and turn the volume back up.

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.121
ii  init-system-helpers 1.63
ii  libasound2  1.2.6.1-2+b1
ii  libasound2-plugins  1.2.6-1
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.1.0-2
ii  libglib2.0-02.72.1-1
ii  libgstreamer-plugins-base1.0-0  1.20.2-2
ii  libgstreamer1.0-0   1.20.2-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.0-1
ii  libstdc++6  12.1.0-2
ii  libsystemd0 250.4-1
ii  libtdb1 1.4.6-3
ii  libudev1250.4-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.7.5-1
ii  libx11-xcb1 2:1.7.5-1
ii  libxcb1 1.14-3
ii  libxtst62:1.2.3-1
ii  lsb-base11.2
ii  pulseaudio-utils15.0+dfsg1-4+b1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-1
ii  libpam-systemd [logind]  250.4-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 250.4-1

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling 

Bug#1012730: O: redland-bindings -- Perl language bindings for the Redland RDF library

[Mattia Rizzolo]

Package: wnpp

The current maintainer of redland-bindings, Dave Beckett ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: redland-bindings
Binary: librdf-perl, python-librdf, ruby-librdf, librdf-ruby
Version: 1.0.17.1+dfsg-1.4
Maintainer: Dave Beckett 
Build-Depends: autotools-dev, dh-autoreconf, debhelper (>= 9), dh-python, 
gem2deb, librdf0-dev (>= 1.0.14), libtool (>= 1.5), perl (>= 5.8.1-2), 
python-all-dev (>= 2.6.6-3~), ruby, ruby-dev, swig (>= 2.0.0)
Architecture: any all
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 124cc67dd1ba2ff556d975556c465120 2184 redland-bindings_1.0.17.1+dfsg-1.4.dsc
 9b03c7b14a0b34d94e303c0331f53f6a 909195 
redland-bindings_1.0.17.1+dfsg.orig.tar.gz
 f53e6f63869c30258c76f578eeef0c9b 6560 
redland-bindings_1.0.17.1+dfsg-1.4.debian.tar.xz
Checksums-Sha256:
 49807df671efe8ce6df57eb3e33e786319d40570be67af263181054ccda3b09a 2184 
redland-bindings_1.0.17.1+dfsg-1.4.dsc
 c9fd9d686d9d8f1ec426e863d4e2eed8a5b42698815d458a32cab73e85fa3e29 909195 
redland-bindings_1.0.17.1+dfsg.orig.tar.gz
 3650d8ca3f32cc24e1c5df2525c0dc29c2cbba6c8e7670aec71f8cd737ab10b0 6560 
redland-bindings_1.0.17.1+dfsg-1.4.debian.tar.xz
Homepage: http://librdf.org/
Package-List: 
 librdf-perl deb perl optional arch=any
 librdf-ruby deb oldlibs extra arch=all
 python-librdf deb python optional arch=any
 ruby-librdf deb ruby optional arch=any
Directory: pool/main/r/redland-bindings
Priority: source
Section: devel


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1012728: O: rasqal -- Rasqal RDF query library development libraries and headers

[Mattia Rizzolo]

Package: wnpp

The current maintainer of rasqal, Dave Beckett ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: rasqal
Binary: librasqal3-dev, librasqal3, rasqal-utils, librasqal3-doc
Version: 0.9.33-0.3
Maintainer: Dave Beckett 
Build-Depends: debhelper-compat (= 13), pkg-config, libraptor2-dev (>= 
2.0.12-2), libgmp-dev, libmhash-dev, libpcre3-dev, uuid-dev, gtk-doc-tools
Architecture: any all
Standards-Version: 4.6.0
Format: 3.0 (quilt)
Files:
 0c44831cdfc3770bb9a912f8e4163dd3 2102 rasqal_0.9.33-0.3.dsc
 1f5def51ca0026cd192958ef07228b52 1595647 rasqal_0.9.33.orig.tar.gz
 edf4394de8f67cd37699331782bb957e 6068 rasqal_0.9.33-0.3.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/rasqal
Vcs-Git: https://salsa.debian.org/debian/rasqal.git
Checksums-Sha256:
 acc6bc4e9f004159b9f839d8d14344dcd888a4ec456501a6d766e4f059ecda65 2102 
rasqal_0.9.33-0.3.dsc
 6924c9ac6570bd241a9669f83b467c728a322470bf34f4b2da4f69492ccfd97c 1595647 
rasqal_0.9.33.orig.tar.gz
 7330caaae94515bbeb42bdcb2d28e9279914cfe944e895d887a2fa9630958e2d 6068 
rasqal_0.9.33-0.3.debian.tar.xz
Homepage: http://librdf.org/rasqal/
Package-List: 
 librasqal3 deb libs optional arch=any
 librasqal3-dev deb libdevel optional arch=any
 librasqal3-doc deb doc optional arch=all
 rasqal-utils deb text optional arch=any
Directory: pool/main/r/rasqal
Priority: source
Section: libs


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1012729: O: redland -- Redland RDF library development libraries and headers

[Mattia Rizzolo]

Package: wnpp

The current maintainer of redland, Dave Beckett ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: redland
Binary: librdf0-dev, librdf0, librdf-storage-postgresql, librdf-storage-mysql, 
librdf-storage-sqlite, librdf-storage-virtuoso, redland-utils
Version: 1.0.17-1.2
Maintainer: Dave Beckett 
Build-Depends: debhelper (>= 8.1.3), dh-autoreconf, cdbs (>= 0.4.93~), libtool 
(>= 1.5), perl (>= 5.8.1-2), libraptor2-dev (>= 2.0.10), librasqal3-dev (>= 
0.9.30), libdb-dev, default-libmysqlclient-dev, libsqlite3-dev, libpq-dev, 
libltdl-dev, unixodbc-dev, gtk-doc-tools
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 31cfd23a0a57d4f44d90140a959cc39a 2353 redland_1.0.17-1.2.dsc
 e5be03eda13ef68aabab6e42aa67715e 1621566 redland_1.0.17.orig.tar.gz
 7787c2cf11ab9af83a677800c690bbeb 8344 redland_1.0.17-1.2.debian.tar.xz
Checksums-Sha256:
 14f0efb4fc57ea78b7100f6ea6db5db7126810f4ee860e4fa336b69aac9e0aa3 2353 
redland_1.0.17-1.2.dsc
 de1847f7b59021c16bdc72abb4d8e2d9187cd6124d69156f3326dd34ee043681 1621566 
redland_1.0.17.orig.tar.gz
 61943ab1101cb8bd1bf5d5809a521c78f3e52c00f310f6fba5779720d9fda8ae 8344 
redland_1.0.17-1.2.debian.tar.xz
Homepage: http://librdf.org/
Package-List: 
 librdf-storage-mysql deb libs optional arch=any
 librdf-storage-postgresql deb libs optional arch=any
 librdf-storage-sqlite deb libs optional arch=any
 librdf-storage-virtuoso deb libs optional arch=any
 librdf0 deb libs optional arch=any
 librdf0-dev deb libdevel optional arch=any
 redland-utils deb text optional arch=any
Directory: pool/main/r/redland
Priority: source
Section: devel


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1012727: O: raptor2 -- Raptor 2 RDF syntax library development libraries and headers

[Mattia Rizzolo]

Package: wnpp

The current maintainer of raptor2, Dave Beckett ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: raptor2
Binary: libraptor2-dev, libraptor2-0, raptor2-utils, libraptor2-doc, 
libraptor2-0-dbg
Version: 2.0.14-1.2
Maintainer: Dave Beckett 
Build-Depends: debhelper (>= 8.1.3), dh-autoreconf, cdbs (>= 0.4.93~), libtool 
(>= 1.5), libxml2-dev (>= 2.5.10), libcurl4-gnutls-dev, libxslt1-dev (>= 
1.0.18), libyajl-dev, quilt, gtk-doc-tools
Architecture: any all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 b28d8000a05abf0261d1c493c46fb760 2276 raptor2_2.0.14-1.2.dsc
 d3e0b43866197a5367b781b25510f728 1877454 raptor2_2.0.14.orig.tar.gz
 62e84d0dde99219a3f6a928c231fdff9 8792 raptor2_2.0.14-1.2.debian.tar.xz
Checksums-Sha256:
 9f9c7152c72c4721685fd6e066278e6c7adbacf7de4d91a405d8fee2fa96bd30 2276 
raptor2_2.0.14-1.2.dsc
 cb447b7c684cbe60f1266d622691fd20fdcf7b91f4a470c6de5fc8e8961df1b2 1877454 
raptor2_2.0.14.orig.tar.gz
 887e57183d1938d5c5c301e31da97938698432c51731fbee01b3ffd55ad7ea89 8792 
raptor2_2.0.14-1.2.debian.tar.xz
Homepage: http://librdf.org/raptor/
Package-List: 
 libraptor2-0 deb libs optional arch=any
 libraptor2-0-dbg deb debug extra arch=any
 libraptor2-dev deb libdevel optional arch=any
 libraptor2-doc deb doc optional arch=all
 raptor2-utils deb text optional arch=any
Directory: pool/main/r/raptor2
Priority: source
Section: devel


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1012725: Updating the flickcurl Uploaders list

[Mattia Rizzolo]

Source: flickcurl
Version: 1.26-7
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Dave Beckett  has retired, so can't work on
the flickcurl package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1012726: Updating the pycairo Uploaders list

[Mattia Rizzolo]

Source: pycairo
Version: 1.20.1-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Dave Beckett  has retired, so can't work on
the pycairo package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0

[Thomas Goirand]

On 5/29/22 15:08, Samuel Henrique wrote:

Hello all,

The recent releases of ansible-lint (>= 6.1.0) requires python-jsonschema

= 4.5.1, mainly due to the following bugfix (thought there might be

other changes required from that release):
https://github.com/python-jsonschema/jsonschema/pull/940

Thomas, are you aware of anything specific which will break openstack
or is it because it hasn't been tested yet?


It's because it hasn't been tested yet. I've seen many cases were 
uploading a single package breaks everything...


Since I added so many autopkgtest, what I can do is upload the latest 
version to Experimental, and let the Debian CI run its tests against 
what's currently in Unstable. Then the pseudo excuse page will show how 
it goes.


Maybe you can also deal with the latest version of python-jsonschema in 
Experimental for a short time too?


Note I wrote to the OpenStack list and ask if we can upgrade jsonschema. 
Please allow a few days until I get some replies.


Cheers,

Thomas Goirand (zigo)

Bug#1012724: gnostic: new upstream version 0.6.9

[Domenico Andreoli]

Package: golang-github-google-gnostic-dev
Severity: wishlist

Dear Dmitry and Anthony,

I was wandering in the dependencies of the kind tool (which I'm
attempting to package), in the need of the gnostic module. Therefore
I packaged it (not uploaded) from scratch [0].

It's only later that I noticed we already have a previous version in
the archive with name `golang-github-googleapis-gnostic-dev` but it's
too old for my purposes and needs a good refresh of paths and name.

The old path is
  /usr/share/gocode/src/github.com/googleapis/gnostic

The new path is
  /usr/share/gocode/src/github.com/google/gnostic

As a consequence, the binary package should be renamed to
`golang-github-google-gnostic-dev`.

Because some CLI tools have been added, a new binary pacage is also
needed with, I guess, name `gnostic`.

I light of this, I think the source package should be renamed to
`gnostic` as well.

Essentially upgrading your golang-github-googleapis-gnostic-dev is
equivalent to upload my new - almost ready to go - package modulo
history and uploaders.

How do you prefer to proceeed? I'm open to any option as long it can
be uploaded sooner than later.

Regards,
Domenico

[0] https://salsa.debian.org/go-team/packages/gnostic/-/merge_requests/1

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]
In a recent stable update to podman changes to the seccomp filter where
introduced to allow podman to work with glibc found in bookwork See #​994451,
#1006138. That update was successful in the sense it allows to run such
containers in the default configuration.

What was overlooked is that podman can run with two competing container runtime
engines: runc and crun. In bullseye, the default runtime is crun, and works
with the updates. However, some users prefer to run with runc, which is the
default in bookworm (and used by docker), which is currently broken (unless one
disables seccomp filtering completely). See #1012030 for full context,

[ Impact ]
This update backports a necessary upstream patch to allow podman to run with
runc in stable again. Without it, users need to make sure to use crun, or
disable seccomp filtering


[ Tests ]
There are unit tests and manual functional tests.

[ Risks ]
The functional change is small and easy to review. The majority of changes are
from updates to the unit tests.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

This is the functional code change:

--- a/libcontainer/configs/config.go
+++ b/libcontainer/configs/config.go
@@ -31,9 +31,10 @@
 // for syscalls. Additional architectures can be added by specifying them in
 // Architectures.
 type Seccomp struct {
-   DefaultAction Action `json:"default_action"`
-   Architectures []string   `json:"architectures"`
-   Syscalls  []*Syscall `json:"syscalls"`
+   DefaultAction   Action `json:"default_action"`
+   Architectures   []string   `json:"architectures"`
+   Syscalls[]*Syscall `json:"syscalls"`
+   DefaultErrnoRet *uint  `json:"default_errno_ret"`
 }
 
 // Action is taken upon rule match in Seccomp
--- a/libcontainer/seccomp/patchbpf/enosys_linux.go
+++ b/libcontainer/seccomp/patchbpf/enosys_linux.go
@@ -523,6 +523,11 @@
 }
 
 func generatePatch(config *configs.Seccomp) ([]bpf.Instruction, error) {
+   // Patch the generated cBPF only when there is not a defaultErrnoRet set
+   // and it is different from ENOSYS
+   if config.DefaultErrnoRet != nil && *config.DefaultErrnoRet == 
uint(retErrnoEnosys) {
+   return nil, nil
+   }
// We only add the stub if the default action is not permissive.
if isAllowAction(config.DefaultAction) {
logrus.Debugf("seccomp: skipping -ENOSYS stub filter 
generation")
--- a/libcontainer/seccomp/seccomp_linux.go
+++ b/libcontainer/seccomp/seccomp_linux.go
@@ -39,7 +39,7 @@
return errors.New("cannot initialize Seccomp - nil config 
passed")
}
 
-   defaultAction, err := getAction(config.DefaultAction, nil)
+   defaultAction, err := getAction(config.DefaultAction, 
config.DefaultErrnoRet)
if err != nil {
return errors.New("error initializing seccomp - invalid default 
action")
}
--- a/libcontainer/specconv/spec_linux.go
+++ b/libcontainer/specconv/spec_linux.go
@@ -872,6 +872,7 @@
return nil, err
}
newConfig.DefaultAction = newDefaultAction
+   newConfig.DefaultErrnoRet = config.DefaultErrnoRet
 
// Loop through all syscall blocks and convert them to libcontainer 
format
for _, call := range config.Syscalls {



[ Other info ]
full debdiff attached
diff -Nru runc-1.0.0~rc93+ds1/debian/changelog 
runc-1.0.0~rc93+ds1/debian/changelog
--- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12 14:49:36.0 
-0400
+++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19 14:46:14.0 
-0400
@@ -1,10 +1,3 @@
-runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
-
-  * Team upload.
-  * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #1012030
-
- -- Reinhard Tartler   Sun, 12 Jun 2022 14:49:36 -0400
-
 runc (1.0.0~rc93+ds1-5) unstable; urgency=high
 
   * Team upload.
diff -Nru runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch 
runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch
--- runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch  2022-06-12 
14:49:36.0 -0400
+++ runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch  1969-12-31 
19:00:00.0 -0500
@@ -1,459 +0,0 @@
-commit c61f6062547d20b80a07e9593e9617e115773b28
-Author: Giuseppe Scrivano 
-Date:   Fri May 14 10:58:16 2021 +0200
-
-libcontainer: honor seccomp defaultErrnoRet
-
-https://github.com/opencontainers/runtime-spec/pull/1087 added support
-for defaultErrnoRet to the OCI runtime specs.
-
-If a defaultErrnoRet is specified, disable patching the generated
-libseccomp cBPF.
-
-Closes: 

Bug#1012722: wireguard-tools: wg-quick DNS server setup should remove existing /etc/resolv.conf lines

[Celejar]

Package: wireguard-tools
Version: 1.0.20210914-1
Severity: normal

I use wg-quick to setup a tunnel to my home LAN from various wireless
(WiFi) networks that I don't control. My /etc/wireguard/wg0.conf
contains the line:

DNS = yy.yy.yy.yy

where yy.yy.yy.yy is a DNS server on my LAN.

With a typical WiFi network, when I initially connect to it,
/etc/resolv.conf becomes populated with something like the following:

nameserver xx.xx.xx.xx
search nnn.nnn.nnn

When I then do 'wg-quick' up, resolv.conf ends up like this:

nameserver yy.yy.yy.yy
nameserver xx.xx.xx.xx
search nnn.nnn.nnn

So DNS queries will generally go through my designated DNS server, which
is good, but if something goes wrong with my server, queries will leak
out to the DNS server supplied by the WiFi network, which is not good.
Similarly, queries for addresses like 'example.com.nnn.nnn.nnn'
sometimes end up going out into the DNS system, which is also not good.

I would think that the correct behavior would be for wg-quick to *replace*
the existing contents of resolv.conf, rather than just *prepending* the
specified DNS server. I understand that as per the man page, I can
presumably get this behavior by using the PostUp and PostDown keys, but
I think the default should be changed, or at least that users should be
warned of the leak potential in the documentation.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages wireguard-tools depends on:
ii  libc6  2.33-7

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.8-1
ii  linux-image-amd64 [wireguard-modules]  5.18.2-1
ii  nftables   1.0.4-1

Versions of packages wireguard-tools suggests:
ii  resolvconf  1.91

-- no debconf information

Bug#1012717: git-buildpackage: git-buildpackage should declare a dependency on python 3.10

[Diane Trout]

On Sun, 2022-06-12 at 21:52 +0200, Guido Günther wrote:
> > After looking the problem it up there's a line where it's trying to
> > do a
> > union type between _GenericAlias and NoneType, but that's a feature
> > that
> > was added in 3.10.
> > https://peps.python.org/pep-0604/
> > 
> > Some of us on testing still have 3.9 as the default because numba
> > doesn't work with 3.10. I think it's pretty reasonable to inidicate
> > that
> > gpb 0.9.27 does requires 3.10.
> 
> I'm also happy to apply a patch that makes it compatible with python
> 3.9
> again. The gain from the type annotations is pretty low atm.
>  -- Guido


This looks like a good solution for 3.9 & 3.10 compatibility
it works on both 3.9 and 3.10 and expresses the same meaning.
https://docs.python.org/3/library/typing.html#typing.Optional

Diane

diff --git a/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py~
b/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py
index c5427ee..9016828 100644
--- a/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py~
+++ b/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py
@@ -34,8 +34,8 @@ class PkgPolicy(object):
  r'%(?P([^%]|\\%))+'
  r'\)s')
-packagename_re: typing.Pattern[str] | None = None
-packagename_msg: str | None = None
-upstreamversion_re: typing.Pattern[str] | None = None
-upstreamversion_msg: str | None = None
+packagename_re: typing.Optional[typing.Pattern[str]] = None
+packagename_msg: typing.Optional[str] = None
+upstreamversion_re: typing.Optional[typing.Pattern[str]] = None
+upstreamversion_msg: typing.Optional[str] = None
 
 @classmethod

Bug#1011646: libthrust: autopkgtest: please be more gentle on ci.d.n infrastructure

[Paul Gevers]

Hi Andreas,

On 11-06-2022 22:27, Andreas Beckmann wrote:

with the latest tuned autopkgtest versions of src:libthrust and src:cub
having migrated to testing, could you check whether these packages now
only put an "acceptable" load on the CI infrastructure?


Well, I haven't spotted issues with amd64 the last couple of days, so in 
that sense...


Both packages still only results neutral (with flaky skips):
[cub]
cmake_find_package_CUB PASS (superficial)
compile_testsuite_cuda-g++_C++17 PASS (superficial)
compile_testsuite_cuda-g++_C++14 PASS (superficial)
compile_testsuite_g++-11_C++17 FLAKY non-zero exit status 2
compile_testsuite_g++-10_C++17 SKIP exit status 77 and marked as skippable
[libthrust]
cmake_find_package_Thrust PASS (superficial)
run_testsuite_CPP_C++17_g++-12 PASS (superficial)
run_testsuite_CPP_C++17_g++-11 FLAKY non-zero exit status 8
run_testsuite_CPP_C++17_g++-10 PASS (superficial)
run_testsuite_CPP_C++14 FLAKY non-zero exit status 8
run_testsuite_TBB_C++17 PASS (superficial)
compile_testsuite_CPP_CUDA_C++17_cuda-g++ PASS (superficial)
compile_testsuite_TBB_CUDA_C++17_cuda-g++ PASS (superficial)
compile_testsuite_CPP_CUDA_C++17_g++-11 FLAKY non-zero exit status 2
compile_testsuite_TBB_CUDA_C++17_g++-11 FLAKY non-zero exit status 2
compile_testsuite_CPP_CUDA_C++17_g++-10 SKIP exit status 77 and marked 
as skippable
compile_testsuite_TBB_CUDA_C++17_g++-10 SKIP exit status 77 and marked 
as skippable


That's a bit disappointing for a test that takes around 5 to 7 hours 
(but better than before).. Alas.

(the src:nvidia-cuda-toolkit autopkgtest will be dropped with the next
upload, src:pycuda should have equivalent tests now while requiring no
extraordinary space to unpack :-)


Please ping me when that future upload migrates, than I can drop my 
entry in the reject list.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012030: (no subject)

[Reinhard Tartler]

Control: reassign -1 runc 1.0.0~rc93+ds1

Shengjing, you are right (as always),

I can confirm that backporting this patch does fix this issue:
https://salsa.debian.org/go-team/packages/runc/-/commit/1d73689985b29ec5b8477dbc6df8004aa09771d1

I'll upload to stable and request it to be unblocked shortly.

On Tue, May 31, 2022 at 12:10 AM Shengjing Zhu  wrote:

> On Tue, May 31, 2022 at 3:33 AM Reinhard Tartler 
> wrote:
> >
> >
> > I wonder whether this may be related to upstream report at
> https://github.com/containers/common/issues/631
> >
> > It seems that in debian/bullseye, podman is only able to work in crun,
> since the version of runc we have in stable seems to have issues with
> seccomp. Can you please try the following for me with both crun and runc
> installed:
> >
> > root@pve:~# podman run --runtime runc
> --security-opt=seccomp=unconfined  --rm -it debian date
> > Mon May 30 19:18:05 UTC 2022
> >
> > That does appear to work at least on my system.
> >
> > This might indicate that this is actually a change that needs to go into
> golang-github-containers-common then...
> >
>
> If I read the issue correctly, it's because in the last stable update,
> the defaultErrnoRet feature is backported. However runc doesn't
> support it until v1.0.0-rc95(stable has rc93). I don't think runc will
> get feature backports in stable. So probably only crun can be used by
> podman now in stable.
>
> --
> Shengjing Zhu
>


-- 
regards,
Reinhard

Bug#1012721: RFP: chezmoi -- manage your dotfiles across multiple machines, securely

[Tom Payne]

Package: chezmoi
Severity: wishlist

* Package : chezmoi
  Version : 2.17.1
  Upstream author : Tom Payne 
* URL : https://chezmoi.io/
* License : MIT
  Programming Lang: Go
  Description : cross-platform dotfile manager

chezmoi is the most popular dotfile manager [1] with over 6.8K stars on
GitHub
and over 100 contributors. It has particularly strong support for managing
machine-to-machine differences (with templates and alternative files) and
security (via password manager integration or age and GPG encryption).

chezmoi is stable, popular, well-tested, with an active maintainer. It is
already available in many other Linux distributions and other packaging
systems
for other operating systems [2]. Guidelines for packagers are at [3].

It would be great to have chezmoi in Debian. Please tell me how I can help
make
this happen.

[1] https://dotfiles.github.io/utilities/
[2] https://www.chezmoi.io/install/#one-line-package-install
[3] https://www.chezmoi.io/developer/packaging/
Source code: https://github.com/twpayne/chezmoi
Releases: https://github.com/twpayne/chezmoi/releases/latest

Bug#1012575: [3dprinter-general] Bug#1012575: libarcus: FTBFS with protobuf 3.20.1+

[Christoph Berg]

Re: Gregor Riepl
> I took the liberty to branch from the last 4.13 release, so we can push
> a fixed version before 5.0 arrives:
> https://salsa.debian.org/3dprinting-team/libarcus/-/tree/testing
> 
> And I added it to the master branch for the 5.0 release as well.
> 
> @myon Please upload 4.13.0-3 when you have time. Thank you!

Done. Thanks for preparing it!

Christoph

Bug#1012717: git-buildpackage: git-buildpackage should declare a dependency on python 3.10

[Guido Günther]

Hi,
On Sun, Jun 12, 2022 at 11:37:20AM -0700, Diane Trout wrote:
> Package: git-buildpackage
> Version: 0.9.27
> Severity: normal
> X-Debbugs-Cc: none, Diane Trout 
> 
> Dear Maintainer,
> 
> I was attempting to update some packages using git-buildpackage and had
> the following stack trace
> 
> 
> ~/src/debian/geiser$ gbp import-orig --uscan
> Traceback (most recent call last):
>   File "/usr/bin/gbp", line 149, in 
> sys.exit(supercommand())
>   File "/usr/bin/gbp", line 137, in supercommand
> module = import_command(cmd)
>   File "/usr/bin/gbp", line 71, in import_command
> return __import__('gbp.scripts.%s' % modulename, fromlist='main', level=0)
>   File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 26, 
> in 
> from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
>   File "/usr/lib/python3/dist-packages/gbp/deb/__init__.py", line 28, in 
> 
> from gbp.deb.policy import DebianPkgPolicy# noqa: F401
>   File "/usr/lib/python3/dist-packages/gbp/deb/policy.py", line 27, in 
> 
> from gbp.pkg.pkgpolicy import PkgPolicy
>   File "/usr/lib/python3/dist-packages/gbp/pkg/__init__.py", line 20, in 
> 
> from gbp.pkg.pkgpolicy import PkgPolicy # noqa: F401
>   File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 28, in 
> 
> class PkgPolicy(object):
>   File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 36, in 
> PkgPolicy
> packagename_re: typing.Pattern[str] | None = None
> TypeError: unsupported operand type(s) for |: '_GenericAlias' and 'NoneType'
> 
> 
> After looking the problem it up there's a line where it's trying to do a
> union type between _GenericAlias and NoneType, but that's a feature that
> was added in 3.10.
> https://peps.python.org/pep-0604/
> 
> Some of us on testing still have 3.9 as the default because numba
> doesn't work with 3.10. I think it's pretty reasonable to inidicate that
> gpb 0.9.27 does requires 3.10.

I'm also happy to apply a patch that makes it compatible with python 3.9
again. The gain from the type annotations is pretty low atm.
 -- Guido

> 
> Thank you,
> Diane Trout
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
> 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), 
> (100, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.22.1
> ii  git1:2.35.1-1
> ii  man-db 2.10.2-1
> ii  python33.9.8-1
> ii  python3-dateutil   2.8.1-6
> ii  python3-pkg-resources  59.6.0-1.2
> ii  sensible-utils 0.0.17
> 
> Versions of packages git-buildpackage recommends:
> ii  cowbuilder0.89
> ii  pbuilder  0.231
> ii  pristine-tar  1.49
> ii  python3-requests  2.27.1+dfsg-1
> ii  sbuild0.83.1
> 
> Versions of packages git-buildpackage suggests:
> ii  python3-notify2  0.3-4
> ii  sudo 1.9.10-3
> ii  unzip6.0-26
> 
> -- no debconf information
> 

Bug#1000217: Ugrade libcap2

[Christian Kastner]

Hi,

On 2022-06-04 14:57, Sebastian Spaeth wrote:
> Hi, a new libcap is one of the hurdles towards users being able to wake
> up systems from suspend using systemd user units.
> 
> A former libcap developer told us that: we'd need to use a modern enough
> version of libcap & pam_cap.so (version >= 2.58): we have v2.44 in
> Debian (https://tracker.debian.org/pkg/libcap2) (upstream is 2.64).
> 
> The systemd issue where this is described is at
> https://github.com/systemd/systemd/issues/17564). Apparently all pieces
> are in place but nobody has put them together, ever.
> 
> so, bumping libcap2 would really help there. Is there anything we can do
> to help progress that one?

apologies for the delay. I haven't updated libcap2 in quite a while and
there were some changes that needed extra checking.

I plan to upload 2.63 to experimental soon (within the next few days).

Best,
Christian

Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects

[Domenico Andreoli]

Package: wnpp
Severity: wishlist
Owner: Domenico Andreoli 

* Package name: golang-k8s-apimachinery
  Version : 1.25.0~alpha0-1
  Upstream Author : Kubernetes
* URL : https://github.com/kubernetes/apimachinery
* License : Apache-2.0
  Programming Lang: Go
  Description : Handle Kubernetes-like API objects.

 This library is a shared dependency for servers and clients to work with
 Kubernetes API infrastructure without direct type dependencies. Its
 first consumers are k8s.io/kubernetes, k8s.io/client-go, and
 k8s.io/apiserver.

Bug#1012719: astropy breaks astroplan autopkgtest: No module named 'astropy.tests.plugins'

[Paul Gevers]

Source: astropy, astroplan
Control: found -1 astropy/5.1-1
Control: found -1 astroplan/0.7-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of astropy the autopkgtest of astroplan fails in 
testing when that autopkgtest is run with the binary packages of astropy 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
astropyfrom testing5.1-1
astroplan  from testing0.7-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of astropy to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=astropy

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroplan/22587870/log.gz

ImportError while loading conftest 
'/usr/lib/python3/dist-packages/astroplan/conftest.py'.

/usr/lib/python3/dist-packages/astroplan/conftest.py:12: in 
from astropy.tests.plugins.display import (TESTED_VERSIONS,
E   ModuleNotFoundError: No module named 'astropy.tests.plugins'
autopkgtest [21:11:57]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012362: transition: luajit

[Paul Gevers]

Hi Mo,

On 10-06-2022 08:00, M. Zhou wrote:

There are some compilation flags tweakable. I'll try with
qemu to see whether I can make it work.


I tried to tweak some compilation flags, and did not manage to make it
work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro.
Segfault persists.

So src:luajit2 is still seemingly badly broken for ppc64el.


Do you have a proposal how to continue? If you believe this can be fixed 
soon (with help from upstream?) I'm OK with trying, but otherwise we 
should inform the reverse dependencies on ppc64el that they have to 
either remove themselves on ppc64el or switch to lua if that works for 
them too. I don't want this lingering for months. src:luajit is 
out-of-sync between testing and unstable since January already.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010937: transition: gdal

[Sebastiaan Couwenberg]

On 6/11/22 18:14, Sebastiaan Couwenberg wrote:

On 6/11/22 11:06, Sebastiaan Couwenberg wrote:

On 6/11/22 01:32, Sebastian Ramacher wrote:

Please go ahead


Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built 
and installed on all release architectures.


libgdal-grass (1:1.0.0-1) has also been uploaded to unstable.


Thanks for the binNMUs.

qgis can bin rebuilt now that grass is built and installed on all 
release architectures.


Please also binNMU gazebo and postgis in experimental.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1007170: transition: qtbase-opensource-src

[Dmitry Shachnev]

Hi Sebastian!

On Sat, Jun 11, 2022 at 01:34:49AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
>
> Please go ahead

Sorry, I was travelling. I will upload it tomorrow or worst case on Tuesday.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1012718: RM: aseba [ppc64el s390x] -- ANAIS; maintainer restricted the supported architectures

[Paul Gevers]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Georges Khaznadar 

Dear ftp-master,

In the lastest upload of aseba, the maintainer (in CC) limited the
architectures. However, because of the binaries on ppc64el and s390x,
the package can't migrate. Can you please remove them?

Paul

Bug#1012717: git-buildpackage: git-buildpackage should declare a dependency on python 3.10

[Diane Trout]

Package: git-buildpackage
Version: 0.9.27
Severity: normal
X-Debbugs-Cc: none, Diane Trout 

Dear Maintainer,

I was attempting to update some packages using git-buildpackage and had
the following stack trace


~/src/debian/geiser$ gbp import-orig --uscan
Traceback (most recent call last):
  File "/usr/bin/gbp", line 149, in 
sys.exit(supercommand())
  File "/usr/bin/gbp", line 137, in supercommand
module = import_command(cmd)
  File "/usr/bin/gbp", line 71, in import_command
return __import__('gbp.scripts.%s' % modulename, fromlist='main', level=0)
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_orig.py", line 26, in 

from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
  File "/usr/lib/python3/dist-packages/gbp/deb/__init__.py", line 28, in 

from gbp.deb.policy import DebianPkgPolicy# noqa: F401
  File "/usr/lib/python3/dist-packages/gbp/deb/policy.py", line 27, in 
from gbp.pkg.pkgpolicy import PkgPolicy
  File "/usr/lib/python3/dist-packages/gbp/pkg/__init__.py", line 20, in 

from gbp.pkg.pkgpolicy import PkgPolicy # noqa: F401
  File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 28, in 

class PkgPolicy(object):
  File "/usr/lib/python3/dist-packages/gbp/pkg/pkgpolicy.py", line 36, in 
PkgPolicy
packagename_re: typing.Pattern[str] | None = None
TypeError: unsupported operand type(s) for |: '_GenericAlias' and 'NoneType'


After looking the problem it up there's a line where it's trying to do a
union type between _GenericAlias and NoneType, but that's a feature that
was added in 3.10.
https://peps.python.org/pep-0604/

Some of us on testing still have 3.9 as the default because numba
doesn't work with 3.10. I think it's pretty reasonable to inidicate that
gpb 0.9.27 does requires 3.10.

Thank you,
Diane Trout

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.22.1
ii  git1:2.35.1-1
ii  man-db 2.10.2-1
ii  python33.9.8-1
ii  python3-dateutil   2.8.1-6
ii  python3-pkg-resources  59.6.0-1.2
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.89
ii  pbuilder  0.231
ii  pristine-tar  1.49
ii  python3-requests  2.27.1+dfsg-1
ii  sbuild0.83.1

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-4
ii  sudo 1.9.10-3
ii  unzip6.0-26

-- no debconf information

Bug#1012716: elpa-geiser: Package out of date and upstream likely moved

[Diane Trout]

Package: elpa-geiser
Version: 0.10-1
Severity: normal
X-Debbugs-Cc: none, Diane Trout 

Dear Maintainer,

Hello I was trying to experiment with emacs-guix, but it failed looking
for a geiser symbol.

I looked the versions of geisers available in guix and found they have
0.23.2 compared to Debian's 0.10.0

On the home page listed in the Debian metadata
http://www.nongnu.org/geiser/
The source link now points at https://gitlab.com/emacs-geiser
instead of http://download.savannah.gnu.org/releases/geiser/ which is in
the debian/watch file

the gitlab site lists 0.23.2 as the latest version.

Diane Trout

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-geiser depends on:
ii  dh-elpa-helper   2.0.10
ii  emacs1:27.1+1-3.1
ii  emacs-gtk [emacsen]  1:27.1+1-3.1+b1
ii  emacsen-common   3.0.4
it  install-info 6.8-4+b1

elpa-geiser recommends no packages.

Versions of packages elpa-geiser suggests:
ii  racket  8.4-1

-- no debconf information

Bug#1011772: libcap2: unneeded deprecated value of Rules-Requires-Root

[Christian Kastner]

On 2022-06-12 19:02, Christian Kastner wrote:
> do you have some context for this change?

I no longer require context because in the mean time, upstream has split
tests into those requiring root and those not requiring root, and I
believe it's sufficient to run the former.

Those requiring root are using in autopkgtest.

> libcap2 doesn't strictly need root to build, however it does need root
> (real, not fakeroot) to run some of the tests.
> 
> The action determined by the presence of the DEB_RULES_REQUIRES_ROOT
> environment variable, and without context, I'm not sure how to adapt the
> relevant part in debian/rules.

Best,
Christian

Bug#1011772: libcap2: unneeded deprecated value of Rules-Requires-Root

[Christian Kastner]

Hi Adam,

On 2022-05-26 17:28, Adam Borowski wrote:
> Source: libcap2
> Version: 1:2.44-1
> Severity: normal
> 
> Hi!
> Values for Rules-Requires-Root other than "no" and "binary-targets" are
> going to no longer be supported.  Your package, however, does not
> actually need root during the build, thus the custom value you're
> currently using can be changed to "no".

do you have some context for this change?

libcap2 doesn't strictly need root to build, however it does need root
(real, not fakeroot) to run some of the tests.

The action determined by the presence of the DEB_RULES_REQUIRES_ROOT
environment variable, and without context, I'm not sure how to adapt the
relevant part in debian/rules.

Best,
Christian

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

0.62.3 draft 1, needs embedding 164 crates (112 missing, 1 broken, 27 outdated, 
24 ahead); Builds in ~65 minutes; runs but functionality not yet properly tested

Main task continues to be to keep package up-to-date with upstream 
releases and try replace more embedded crates with packaged ones.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built) and provide 
feedback on how well it works for you.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking/upgrading/adding needed crate packages, as listed here: 
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1012715: ITP: data-fressian-clojure

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jerome Charaoui 

   Package name : data-fressian-clojure
   Version  : 1.0.0
   Upstream author  : Stuart Halloway 
   URL  : https://github.com/clojure/data.fressian
   License  : EPL-1.0
   Programming Lang : Clojure
   Description  : Read and write Fressian data from Clojure

Fressian is an extensible binary data notation. It is inspired by, and 
shares many design objectives with Hessian and edn.


This package provides Clojure bindings for Fressian.


Thanks,

-- Jerome

Bug#1012714: ITP: fressian

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jerome Charaoui 

   Package name : fressian
   Version  : 0.6.6
   Upstream author  : Metadata Partners, LLC.
   URL  : https://github.com/Datomic/fressian
   License  : EPL-1.0
   Programming Lang : Java
   Description  : extensible binary data notation

Fressian is an extensible binary data notation. It is inspired by, and 
shares many design objectives with hessian and edn.


Thanks,

-- Jerome

Bug#1012713: nvidia-graphics-drivers: Fails to build from source: 510.73.08 missing upstream

[Christian Weeks]

Source: nvidia-graphics-drivers
Version: 510.73.08-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I am trying to build the associated flathub packages for 510.73.08 and they 
seem to be completely absent upstream
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to build the git 510 branch from source.

   * What was the outcome of this action?
The get-orig-source command failed.

   * What outcome did you expect instead?
The upstream source should exist?

curl  
https://download.nvidia.com/XFree86/Linux-x86_64/510.73.08/NVIDIA-Linux-x86_64-510.73.08.run
 results in 404

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
http://www.w3.org/1999/xhtml; xml:lang="en" lang="en">

404 - Not Found


404 - Not Found





It seems that the version 510.73.08 is completely absent upstream. The archive 
page only lists 510.73.05 from this
series. I'm not sure where this version came from, there seems to be little 
reference to it outside of debian's
ecosystem. Perhaps this was a prelude to the opensourcing somehow??

It's frustrating that this is completely unbuildable now. I'm guessing the 
adoption of the 515 branch is going to
be held up in debian-legal for some time, because of obvious reasons.

Is it perhaps that this is secretly 510.73.05 and got the wrong number somehow?

Christian

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.1-tkg-pds (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ai
  Version : 0.03
  Upstream Author : François Élie 
* URL : https://gitlab.adullact.net/felie/ai
* License : AGPL
  Programming Lang: PHP
  Description : PHP library to develop easily SQL queries usable in web
pages

 AI is an Allmighty Intelligence: just think about the SQL query which
 you would use in MySQL's command line, or in phpmyadmin, and AI offers you
 the right code to display its results in a web page. Unfortunately, AI
 can not yet read your mind directly: you've got to type the query.

Bug#1012711: start-pulseaudio-x11: pactl load-module module-x11-publish reports: Failure: No such entity

[Julian Gilbey]

Package: pulseaudio
Version: 15.0+dfsg1-4+b1
Severity: normal

Pulseaudio is not starting properly when my X session starts; trying
to run start-pulseaudio-x11 manually in a terminal gives this output:

euler:~ $ start-pulseaudio-x11 
Failure: No such entity
euler:~ $ sh -x /usr/bin/start-pulseaudio-x11 
+ set -e
+ [ -n  ]
+ [ x:0.0 != x ]
+ /usr/bin/pactl load-module module-x11-publish display=:0.0 
xauthority=/home/jdg/.Xauthority
Failure: No such entity

But systemctl --user start pulseaudio.service works fine.

Best wishes,

   Julian


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.121
ii  init-system-helpers 1.63
ii  libasound2  1.2.6.1-2+b1
ii  libasound2-plugins  1:1.2.6-dmo1
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.1.0-2
ii  libglib2.0-02.72.1-1
ii  libgstreamer-plugins-base1.0-0  1.20.2-dmo2
ii  libgstreamer1.0-0   1.20.2-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.0-1
ii  libstdc++6  12.1.0-2
ii  libsystemd0 250.4-1
ii  libtdb1 1.4.6-3
ii  libudev1250.4-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.7.5-1
ii  libx11-xcb1 2:1.7.5-1
ii  libxcb1 1.14-3
ii  libxtst62:1.2.3-1
ii  lsb-base11.2
ii  pulseaudio-utils15.0+dfsg1-4+b1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-1
ii  libpam-systemd [logind]  250.4-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
ii  pavumeter0.9.3-4+b4
ii  udev 250.4-1

-- no debconf information

Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

[Carsten Schoenert]

Control: tags -1 pending

Hello Daniel,

Am Sat, Mar 26, 2022 at 04:06:46PM -0400 schrieb Daniel Kahn Gillmor:
> I've just uploaded rnp 0.16.0 into debian unstable.  According to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1732809 the main
> development line of thunderbird now has a --with-system-rnp flag (but
> the 91esr series doesn't have it.
> 
> So when new versions of thunderbird get built in debian (in experimental
> first, maybe?) please try to use --with-system-rnp.  If you run into any
> reason why building against the system rnp isn't working, please don't
> hesitate to file bug reports against rnp and we'll sort them out.

after again months of waiting for some typical build tools and a lot of
try and errors attempts I'm now able to build the current beta version
of Thunderbird (102.0~b4) together with the system package of
librnp-dev.

The downside is that this requires currently the usage of the internal
version of botan, bz2 and jsonc.
I've no kowledge if upstream has plans to reenable the usage of system
packages for these tools, maybe it's also just a misconfiguration of the
buildsystem.

Hopefully I can upload a first beta version of Thunderbird zu
experimental soon.

Regards
Carsten

Bug#1012710: tracker.debian.org: uses old, glossy logo instead of flat one

[Agathe Porte]

Package: tracker.debian.org
Severity: minor
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

The instance of disto-tracker on tracker.debian.org uses the old glossy
logo of Debian, served at the following address:

https://tracker.debian.org/static/img/logo.png

The new logo that is not glossy can be found at the following address:

https://www.debian.org/logos/openlogo-nd-100.png

I wanted to provide a merge-request on Salsa, but this seems to be
instance-specific as no PNG files seems to be stored inside of the
distro-tracker repository.

So it seems to me that only an administrator of tracker.debian.org can
update this logo, and there is nothing more that I can do from my side
other than opening this bug. If this is not the case, please let me know
how I can help.

Bests,

Agathe.

Bug#951831: Groovy is at 4.0.3 now

[Dirk Heinrichs]

Hi,

current Groovy version is 4.0.3, while even Sid still has 2.4.21. Please...

Bye...

    Dirk

-- 
Dirk Heinrichs 
Matrix-Adresse: @heini:chat.altum.de
GPG Public Key: 80F1540E03A3968F3D79C382853C32C427B48049
Privacy Handbuch: https://www.privacy-handbuch.de



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012294:

[Daichi Fukui]

Hi

I intend to adopt jsonnet -- data templating language.

I am looking for an opportunity to contribute to Debian through packaging.
If you don't mind, let me adopt this package.

Regards,
Fukui

Bug#1012709: groff-base: eqn sup renders adversarially in nroff mode

[наб]

Package: groff-base
Version: 1.22.4-8
Severity: normal

Dear Maintainer,

Consider the following manual:
-- >8 --
'\" e
.\" SPDX-License-Identifier: 0BSD
.\"
.Dd
.Dt CKSUM 1
.Os
.
.Sh NAME
.Nm cksum
.Nd compute Ethernet checksum
.
.EQ
delim %%
.EN
.
.Sh STANDARDS
Conforms to
.St -p1003.1-2008 .
The CRC polynomial is
% x sup 32 + x sup 26 + x sup 23 + x sup 22 + x sup 16 + x sup 12 + x sup 11 + 
x sup 10 + x sup 8 + x sup 7 + x sup 5 + x sup 4 + x sup 2 + x + 1 %,
the same one used by
.St -iso8802-3 Pq Ethernet .
-- >8 --

mandoc trunk renders it as
-- >8 --
CKSUM(1)General Commands Manual   CKSUM(1)

NAME
 cksum – compute Ethernet checksum

STANDARDS
 Conforms to IEEE Std 1003.1-2008 (“POSIX.1”).  The CRC polynomial is x^32
 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4
 + x^2 + x + 1, the same one used by ISO 8802-3: 1989 (Ethernet).

Linux 5.10.0-14-amd64Linux 5.10.0-14-amd64
-- >8 --
with all `x`es being fI (as expected for a variable).

Compare it to groff 1.22.4-8:
-- >8 --
CKSUM(1)  BSD General Commands Manual   
  CKSUM(1)

NAME
 cksum — compute Ethernet checksum

STANDARDS
 Conforms to IEEE Std 1003.1-2008 (“POSIX.1”).  The CRC polynomial is
 x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1, the same one used by 
ISO/IEC 8802-3:1989 (Ethernet).

BSD  Epoch  
   BSD
-- >8 --
`x`es are also fI, but the rest is a mess. What's more important is the
`sup`s were lost entirely! It's just a soup of text (in this case it's
obvious from context what that means, but that doesn't always hold,
obviously).

Best,
наб


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

Kernel: Linux 5.10.0-14-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages groff-base depends on:
ii  libc6 2.31-13+deb11u3
ii  libgcc-s1 10.2.1-6
ii  libstdc++610.2.1-6
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#1012708: RFS: jsonnet/0.18.0 ds-1 [ITA] -- data templating language

[Daichi Fukui]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "jsonnet":

 * Package name: jsonnet
   Version : 0.18.0+ds-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/google/jsonnet
 * License : MD5-a-certain-license, Apache-2.0, Expat
 * Vcs : https://salsa.debian.org/debian/jsonnet
   Section : devel

The source builds the following binary packages:

  jsonnet - data templating language
  libjsonnet0 - data templating language (lib)
  libjsonnet-dev - data templating language (devel)
  python3-jsonnet - data templating language (Python)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/jsonnet/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/j/jsonnet/jsonnet_0.18.0+ds-1.dsc

Changes since the last upload:

 jsonnet (0.18.0+ds-1) unstable; urgency=medium
 .
   * New upstream version 0.18.0+ds
   * Remove tests-dont-use-python2.patch

Regards,

Bug#1009078: Version 8.17.1-2 does not work again

[Joerg Dorchain]

Hello Andreas,

On Sun, Jun 12, 2022 at 03:13:34PM +0200, Andreas Beckmann wrote:
> On 12/06/2022 09.03, Joerg Dorchain wrote:
> > reopen 1009078 =
> > thanks
> > 
> > Hi,
> > 
> > I am sorry to say that the newly arrived version 8.17.1-2 in testing shows 
> > the same behaviour as the
> > originally reported version 8.16.1-2, no auth mechanisms offered after 
> > starttls.
> > 
> > Downgrading to version 8.17.1-1 helps, though.
> 
> The only relevant difference is that -2 is built against openssl 3 while
> -1 was built against openssl 1.1. Do other distros have patches for
> 8.17.1 and openssl 3?

The freebsd folks have(had) a similiar bug 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263287 and
a patch https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233346=diff

They say the patch is from sendmail 8.17.1.9. A version of the patch for 
inclusion in the patch subdir
is also attached.

If you could create a package with either the patch applied or from the 
mentioned source version (or
newer) I'd be happy to test.

Bye,

Joerg
--- patch-zsasl2	1970-01-01 01:00:00.0 +0100
+++ patch-zsasl2	
@@ -0,0 +1,21 @@ 
+--- sendmail/sendmail.h.orig	2022-04-19 21:07:42 UTC
 sendmail/sendmail.h
+@@ -760,7 +760,7 @@ extern bool	filesys_free __P((long));
+ # define SASL_IS_AUTH	2		/* authenticated */
+ 
+ /* SASL options */
+-# define SASL_AUTH_AUTH	0x1000		/* use auth= only if authenticated */
++# define SASL_AUTH_AUTH	0x1		/* use auth= only if authenticated */
+ # if SASL >= 20101
+ #  define SASL_SEC_MASK	SASL_SEC_MAXIMUM /* mask for SASL_SEC_* values: sasl.h */
+ # else /* SASL >= 20101 */
+@@ -775,6 +775,9 @@ extern bool	filesys_free __P((long));
+ #  endif /* SASL_SEC_NOPLAINTEXT & SASL_SEC_MASK) == 0 ... */
+ # endif /* SASL >= 20101 */
+ # define MAXOUTLEN 8192	/* length of output buffer, should be 2^n */
++# if (SASL_AUTH_AUTH & SASL_SEC_MASK) != 0
++#  ERROR "change SASL_AUTH_AUTH notify sendmail.org!"
++# endif
+ 
+ /* functions */
+ extern char	*intersect __P((char *, char *, SM_RPOOL_T *));


signature.asc
Description: PGP signature

Bug#1006638: firmware-misc-nonfree: /lib/firmware/i915/adlp_dmc_ver2_12.bin missing

[Yllman, Jens]

On 2022-04-12 01:22, Gabriel Filion wrote:
 From what I can see, upstream has merged the addition of version 2.12 
of the firmware (and later also 2.14, 2.15 and 2.16)


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0268c1b8a06798f5167cbef8fb16241298b3eba9 



so this package would have the firmware available on the next version bump.


Now when sid is running kernel 5.18 there are even more firmware that 
want newer versions. So when I did upgrade to kernel 5.18 I got the 
following list of 'missing' firmware.


update-initramfs: Generating /boot/initrd.img-5.18.0-1-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for 
module r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for 
module r8152
W: Possible missing firmware /lib/firmware/i915/skl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/glk_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/icl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/dg1_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/adlp_guc_69.0.3.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/adlp_dmc_ver2_14.bin for 
module i915


So that version bump would be nice.

Bug#1009078: Version 8.17.1-2 does not work again

[Andreas Beckmann]

On 12/06/2022 09.03, Joerg Dorchain wrote:
> reopen 1009078 =
> thanks
> 
> Hi,
> 
> I am sorry to say that the newly arrived version 8.17.1-2 in testing shows 
> the same behaviour as the
> originally reported version 8.16.1-2, no auth mechanisms offered after 
> starttls.
> 
> Downgrading to version 8.17.1-1 helps, though.

The only relevant difference is that -2 is built against openssl 3 while
-1 was built against openssl 1.1. Do other distros have patches for
8.17.1 and openssl 3?


Andreas

Bug#1005865: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 v2.0.1)

$ wget2 --content-disposition -P maps https://addons.wz2100.net/download/1
[0] Downloading 'https://addons.wz2100.net/download/1' ...
Saving 'maps/2c-Battle_hills_v2.wz'
HTTP response 200 OK [https://addons.wz2100.net/download/1]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#991540: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 2.0.1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#974708: Fixed upstream

[Tim Rühsen]

Fixed upstream in commit c355efb7c86b4dfc9ac8d9f441101aa97aeef918 (on 
top of wget2 v2.0.1).


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)

[Diederik de Haas]

Control: tag -1 - moreinfo
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/1455
Control: tag -1 fixed-upstream

On Sunday, 12 June 2022 06:59:12 CEST ng wrote:
> Hi,  I went on and installed the respective image from
> https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-am
> d64-unsigned_5.10.46-5 and had no luck,  no change whatsoever.

Hi!

Thanks for testing, then this is a separate issue.

https://lore.kernel.org/linux-firmware/CADnq5_PYhDcR3tNYgzQ-uz80Nf++oMPsF3=huk+qcgntiy_...@mail.gmail.com/
is where a fix has been proposed+merged upstream (date: 2022-02-28).

An update of the firmware to version >= 20220310 _should_ fix this issue.
If such a version becomes available, could you test whether it indeed fixes
your issue and report your findings back to this bug report?

TIA,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1003865: GPG error: http://deb.debian.org/debian sid InRelease: The following signatures were invalid: BADSIG 648ACFD622F3D138 Debian Archive Automatic Signing Key (10/buster)

[Diederik de Haas]

On 19 Jan 2022 21:40:18 +0530 Pirate Praveen  wrote:
> On Wed, 19 Jan 2022 02:47:56 +0530 Pirate Praveen
>  wrote:
> > >Based on the fact that autobuilding of unstable is still continuing and
> > >there haven't been any reports of this issue on either #d-devel or 
> > >debian-devel@lists, it seems unlikely that there's a general issue
> > >here, rather than something more local to your environment.
> > 
> > May be related to apt-cacher-ng (though I tried with apt-cacher-ng
> > disabled without fixing this issue).
> 

I'm having/seeing this issue for ~1 week now and it very much looks like it is
caused by apt-cacher-ng.
I don't know why it popped up now as usually/normally it works.

# debootstrap --arch arm64 sid /home/diederik/tmp/debootstrap/sysbase-sid-arm64 
http://:3142/deb.debian.org/debian
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
E: Invalid Release signature (key id 648ACFD622F3D138)

# debootstrap --arch arm64 sid /home/diederik/tmp/debootstrap/sysbase-sid-arm64 
http://deb.debian.org/debian
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A7236886F3CCCAAD148A27F80E98404D386FA1D9)

Interestingly enough, this only happens when specifying 'sid':

# debootstrap --arch arm64 testing 
/home/diederik/tmp/debootstrap/sysbase-bookworm-arm64 
http://:3142/deb.debian.org/debian
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A7236886F3CCCAAD148A27F80E98404D386FA1D9)

> sudo rm -rf /var/lib/apt/*
> 
> fixed the issue (sharing in case someone someone searches for the same
> error)

Do you do that on the host machine or on the machine running apt-cacher-ng?

I have a device running acng in my LAN which all (other) devices use, 
but I also have one running on my main PC when repeatedly building images.

signature.asc
Description: This is a digitally signed message part.

Bug#913997:

[Chan vannak]

Get Outlook for iOS

Bug#913997:

[Chan vannak]

Get Outlook for iOS

Bug#1012659: Workaround

[David Bremner]

I can confirm that using ed25519 keys is a workaround for this
bug. Of course re-keying production servers to get duplicity backups
working may not be easy (or possible) for everyone.



signature.asc
Description: PGP signature

Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0

[Bastian Germann]

Hi,

I would also like to stress that I would like to see dt-schema moving to a version that one can actually use for current 
Linux kernel's device tree checking. As of now I have to pip install jsonschema and dt-schema for this use case.


Lots of kernel developers on Debian will be thankful for this to be resolved.

Thanks,
Bastian

Bug#1012706: ITP: golang-github-ncw-swift-v2 -- Go language interface to Swift

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: Félix Sipma 

* Package name: golang-github-ncw-swift-v2
  Version : 2.0.1-1
  Upstream Author : Nick Craig-Wood
* URL : https://github.com/ncw/swift
* License : Expat
  Programming Lang: Go
  Description : Go language interface to Swift / Openstack Object Storage / 
Rackspace cloud files (golang)

It is needed to which is needed to update restic. 

-- 
Félix


signature.asc
Description: PGP signature

Bug#990109: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 2.0.1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011627: transition: armadillo

[Kumar Appaiah]

Dear Sebastian,

On Sat, Jun 11, 2022 at 01:32:22AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-05-25 19:12:00 +0530, Kumar Appaiah wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > Please provide me permission to upload Armadillo to sid. I have
> > verified the build of the reverse dependencies and haven't run into
> > issues.
> > 
> > If you need any other information, please let me know.
> 
> Please go ahead

Uploaded and it built on all relevant architectures.

Thanks.

Kumar

Bug#1011699: pygmsh: FTBFS: make: *** [debian/rules:11: build] Error 25

[Drew Parsons]

Source: pygmsh
Followup-For: Bug #1011699


I can't reproduce this build failure.

The reproducibility builds at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pygmsh.html
have consistently been successful, apart from one failure around the
same time in May on arm64.

freeimage was updated just after this bug report. Looks like it fixed a
problem with libfreeimage.so.3

I'll close this bug now, judging it fixed by freeimage 3.18.0+ds2-7

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#705068: Please provide dh-make library for non-perl packaging helpers

[Damyan Ivanov]

Control: tag -1 help

Almost 10 years later, I think it is obvious the dh-make-perl authors 
(me included) aren't very keen on separating the parts that are 
specific to the Debian Perl Group and providing a more universal 
library that can be used by others.

-=| Thomas Koch, 08.05.2013 19:49:19 +0200 |=-
> Some clarifications:
> 
> There is for example a lot of logic in the package 
> DhMakePerl::Command::Packaging that I'd like to reuse for java packaging. For 
> that I'd need a reliable API and some logic would need to extracted from 
> larger functions into separate functions:
> 
> * get_developer(), get_wnpp() are fine for reuse
> * fill_maintainer() has hardcoded reference to perl team
> * set_package_name() contains logic to fall back to create a perl library 
> package name
> * extract_desc() contains useful logic to format the long package description
> * ...
> 
> I think it's fine to keep all this logic in the dh-make-perl package. It 
> would 
> just be helpful to have a clear distinction between reusable code 
> that could be used for languages other than perl and code specific 
> for packaging perl.

Right. These are all good ideas. They "just" need someone to implement 
them. We won't, it seems, so I am tagging the bugreport with 'help'.

If I was going to do it, I'd try to split all DPG-specific parts into 
a ::Packaging::DPG or a similar package, sublcassing ::Packaging, and 
change dh-make-perl to use that.

Then another tool, say dh-make-java, would need to provide 
::Packaging::Java, subclassing ::Packaging with Java-specific 
functions.

Perhaps there are some perl-specific things outside ::Packaging too.

The whole thing involves identifying domain specific parts, some 
shuffling around and a lot of testing. I hope people who need this 
functionality would be able to spend the time to try it.


-- Damyan

Bug#1012705: transition: ros-class-loader

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-06-12 10:11:59 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi Release team,
> 
> I would like to transition to the new ros-class-loader (and a new
> ros-pluginlib with it). The auto generated ben file is fine but a number
> of packages need updates. I'm the maintainer of all downstream packages
> and can upload fixed packages once the transition started.

Please go ahead

Cheers

> 
> Packages that I will upload:
> 
> ros-ros-comm
> 
> ros-diagnostics
> ros-image-common
> 
> ros-image-pipeline
> ros-opencv-apps
> ros-perception-pcl
> ros-rviz
> 

-- 
Sebastian Ramacher

Bug#1012705: transition: ros-class-loader

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release team,

I would like to transition to the new ros-class-loader (and a new
ros-pluginlib with it). The auto generated ben file is fine but a number
of packages need updates. I'm the maintainer of all downstream packages
and can upload fixed packages once the transition started.

Packages that I will upload:

ros-ros-comm

ros-diagnostics
ros-image-common

ros-image-pipeline
ros-opencv-apps
ros-perception-pcl
ros-rviz

Bug#1007222: transition: onetbb

[Graham Inggs]

Control: tags -1 + confirmed - moreinfo

Hi

On Tue, 7 Jun 2022 at 18:39, Andrius Merkys  wrote:
> In the meantime I am test-rebuilding plastimatch, now unblocked by
> #1005485.

There you will hit #1012439, but plastimatch is now no longer in testing.

Please go ahead with the upload of onetbb to unstable.

Regards
Graham

Bug#1012704: Does not work with current perl anymore

[Klaus Ethgen]

Package: ipcalc
Version: 0.42-2
Severity: normal

`ipcalc 61.177.0.0 - 61.177.255.255` should give 61.177.0.0/16 but it
runs endless now until I hit ctrl-c. I remember, that worked in the
past...

There was no ipcalc update in the last time but there was a perl update
to 5.34.

   ~> ipcalc 61.177.0.0 - 61.177.255.255
   deaggregate 61.177.0.0 - 61.177.255.255
   Deep recursion on subroutine "Math::BigInt::bior" at 
/usr/share/perl5/Math/BigFloat.pm line 3856.
   Deep recursion on subroutine "Math::BigFloat::bior" at 
/usr/share/perl5/Math/BigInt.pm line 3495.

-- System Information:
Debian Release: bookworm/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ipcalc depends on:
ii  perl  5.34.0-4

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1009078: Version 8.17.1-2 does not work again

[Joerg Dorchain]

reopen 1009078 =
thanks

Hi,

I am sorry to say that the newly arrived version 8.17.1-2 in testing shows the 
same behaviour as the
originally reported version 8.16.1-2, no auth mechanisms offered after starttls.

Downgrading to version 8.17.1-1 helps, though.

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#1012655: upstream bug and fix

[Stephan Verbücheln]

They merged it (on June 7) into kernel 5.19, but kernel 5.18.3
(released June 9) does not seem to have it yet.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=v5.18.3=v5.18=2

I will just use 5.17 or external mouse until the fix lands in Sid.

Thank you and regards