Bug#1020605: kmod: Remove dependency on lsb-base

[Johannes Schauer Marin Rodrigues]

Package: kmod
Version: 29-1
Severity: normal
Tags: patch
X-Debbugs-Cc: jo...@debian.org

Hi,

the functionality of lsb-base is in the essential set in bullseye as
well as in bookworm and now provided as a virtual package by
sysvinit-utils. Since debootstrap does not understand the Provides
relationship, it is pulling in an empty lsb-base transitional package
which breaks the mmdebstrap autopkgtest.

This bug report has been filed against cron, ifupdown, kmod and procps
which are those packages in the Priority:important set that depend on
lsb-base and thus block mmdebstrap right now.

For your convenience, I've submitted a merge request on salsa:

https://salsa.debian.org/md/kmod/-/merge_requests/9

Further discussion about the lsb-base removal will probably happen in
this merge request against lintian:

https://salsa.debian.org/lintian/lintian/-/merge_requests/419

Thanks!

cheers, josch

Bug#1020604: ifupdown: Remove dependency on lsb-base

[Johannes Schauer Marin Rodrigues]

Package: ifupdown
Version: 0.8.37
Severity: normal
Tags: patch
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 mmdebstrap
Control: block 1020593 by -1

Hi,

the functionality of lsb-base is in the essential set in bullseye as
well as in bookworm and now provided as a virtual package by
sysvinit-utils. Since debootstrap does not understand the Provides
relationship, it is pulling in an empty lsb-base transitional package
which breaks the mmdebstrap autopkgtest.

This bug report has been filed against cron, ifupdown, kmod and procps
which are those packages in the Priority:important set that depend on
lsb-base and thus block mmdebstrap right now.

For your convenience, I've submitted a merge request on salsa:

https://salsa.debian.org/debian/ifupdown/-/merge_requests/12

Further discussion about the lsb-base removal will probably happen in
this merge request against lintian:

https://salsa.debian.org/lintian/lintian/-/merge_requests/419

Thanks!

cheers, josch

Bug#1020603: cron: Remove dependency on lsb-base

[Johannes Schauer Marin Rodrigues]

Package: cron
Version: 3.0pl1-149
Severity: normal
Tags: patch
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 mmdebstrap
Control: block 1020593 by -1

Hi,

the functionality of lsb-base is in the essential set in bullseye as
well as in bookworm and now provided as a virtual package by
sysvinit-utils. Since debootstrap does not understand the Provides
relationship, it is pulling in an empty lsb-base transitional package
which breaks the mmdebstrap autopkgtest.

This bug report has been filed against cron, ifupdown, kmod and procps
which are those packages in the Priority:important set that depend on
lsb-base and thus block mmdebstrap right now.

For your convenience, I've submitted a merge request on salsa:

https://salsa.debian.org/debian/cron/-/merge_requests/7

Further discussion about the lsb-base removal will probably happen in
this merge request against lintian:

https://salsa.debian.org/lintian/lintian/-/merge_requests/419

Thanks!

cheers, josch

Bug#1020602: procps: Remove dependency on lsb-base

[Johannes Schauer Marin Rodrigues]

Package: procps
Version: 2:3.3.17-6
Severity: normal
Tags: patch
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 mmdebstrap
Control: block 1020593 by -1

Hi,

the functionality of lsb-base is in the essential set in bullseye as
well as in bookworm and now provided as a virtual package by
sysvinit-utils. Since debootstrap does not understand the Provides
relationship, it is pulling in an empty lsb-base transitional package
which breaks the mmdebstrap autopkgtest.

This bug report has been filed against cron, ifupdown, kmod and procps
which are those packages in the Priority:important set that depend on
lsb-base and thus block mmdebstrap right now.

For your convenience, I've submitted a merge request on salsa:

https://salsa.debian.org/debian/procps/-/merge_requests/6

Further discussion about the lsb-base removal will probably happen in
this merge request against lintian:

https://salsa.debian.org/lintian/lintian/-/merge_requests/419

Thanks!

cheers, josch

Bug#1020601: ld-vsb/vsb.exp tests fail

[Matthias Klose]

Package: src:binutils
Version: 2.39-1
Severity: important

seen with the 2.39-1 upload:

Test results, compared with installed binutils:
W: [ld-vsb/vsb.exp] REGRESSION (PASS -> FAIL): weak hidden symbol DSO last
W: [ld-vsb/vsb.exp] REGRESSION (PASS -> FAIL): weak hidden symbol DSO first
2 REGRESSIONS (0.09%).

Bug#1020600: gcc: objc: remove unused binary-without-manpage lintian overrides

[Helmut Grohne]

Source: gcc-12
Version: 12-20220319-1
Severity: wishlist
Tags: patch

Hi Matthias,

during DC22, I promised to send some cleanup patches preparing for
gcc-for-host. This is one of the.

The objc/objc++ frontends don't contain any binaries as they reuse
existing compiler binaries. As such, the lintian overrides
binary-without-manpage are not useful and should be deleted. Deleting
them now reduces the code churn for gcc-for-host. I'm attaching a patch
for your convenience.

Helmut
>From 7e3722a05d8855d71c985706c8d503ba53562af5 Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Fri, 27 Mar 2020 15:50:21 +0100
Subject: [PATCH] remove unused binary-without-manpage overrides

gobjc-N and gobjc++-N don't contain any binaries on $PATH that would
warrant a manual page.
---
 debian/rules.d/binary-objc.mk   | 4 
 debian/rules.d/binary-objcxx.mk | 4 
 2 files changed, 8 deletions(-)

diff --git a/debian/rules.d/binary-objc.mk b/debian/rules.d/binary-objc.mk
index b5cd216..743bf52 100644
--- a/debian/rules.d/binary-objc.mk
+++ b/debian/rules.d/binary-objc.mk
@@ -36,10 +36,6 @@ $(binary_stamp)-objc: $(install_stamp)
 	mkdir -p $(d_objc)/usr/share/lintian/overrides
 	echo '$(p_objc) binary: hardening-no-pie' \
 	  > $(d_objc)/usr/share/lintian/overrides/$(p_objc)
-ifeq ($(GFDL_INVARIANT_FREE),yes)
-	echo '$(p_objc) binary: binary-without-manpage' \
-	  >> $(d_objc)/usr/share/lintian/overrides/$(p_objc)
-endif
 
 	debian/dh_doclink -p$(p_objc) $(p_xbase)
 
diff --git a/debian/rules.d/binary-objcxx.mk b/debian/rules.d/binary-objcxx.mk
index 4f6d8e1..e750cae 100644
--- a/debian/rules.d/binary-objcxx.mk
+++ b/debian/rules.d/binary-objcxx.mk
@@ -34,10 +34,6 @@ $(binary_stamp)-objcxx: $(install_stamp)
 	mkdir -p $(d_objcx)/usr/share/lintian/overrides
 	echo '$(p_objcx) binary: hardening-no-pie' \
 	  > $(d_objcx)/usr/share/lintian/overrides/$(p_objcx)
-ifeq ($(GFDL_INVARIANT_FREE),yes)
-	echo '$(p_objcx) binary: binary-without-manpage' \
-	  >> $(d_objcx)/usr/share/lintian/overrides/$(p_objcx)
-endif
 
 	debian/dh_rmemptydirs -p$(p_objcx)
 
-- 
2.37.2

Bug#1020599: gcc: objc: drop obsolete sparc-only conflict

[Helmut Grohne]

Source: gcc-12
Version: 12-20220319-1
Severity: wishlist
Tags: patch

Hi Matthias,

during DC22, I promised to send some cleanup patches preparing for
gcc-for-host. This is one of them.

There is a conflict on the objc package that is only relevant to sparc,
but sparc support is discontinued. As such the conflict should be
dropped rather than moved around with the gcc-for-host patches. I'm
attaching a patch for your convenience.

Helmut
>From 5c93b56b9a8b758e459e636a0235b648d459590b Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Fri, 27 Mar 2020 15:31:00 +0100
Subject: [PATCH] drop obsolete sparc-only conflict

---
 debian/control.m4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control.m4 b/debian/control.m4
index 3328f9d..f5fcd8e 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -3360,7 +3360,6 @@ Priority: optional
 Depends: BASEDEP, gcc`'PV`'TS (= ${gcc:Version}), ${dep:libcdev}, ${shlibs:Depends}, libidevdep(objc`'PV-dev,,=), ${misc:Depends}
 Suggests: ${gobjc:multilib}, gcc`'PV-doc (>= ${gcc:SoftVersion}), libdbgdep(objc`'OBJC_SO-dbg),
 Provides: objc-compiler`'TS
-ifdef(`__sparc__',`Conflicts: gcc`'PV-sparc64', `dnl')
 BUILT_USING`'dnl
 Description: GNU Objective-C compiler
  This is the GNU Objective-C compiler, which compiles
-- 
2.37.2

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi Russ and Gregor,

thanks for your feedback,

I think that I made most of the points I was thinking about and hope
that some of them related to Simple English and jargon can be useful in
the future.  I also understand your point of view.  One final comment I
would like to make is that the format is used in other contexts, such as
Apt (using "paragraph" in https://wiki.debian.org/DebianRepository/Format),
DEP-11 (using "block" in https://wiki.debian.org/DEP-11), and probably
other files generated for the Debian archive.  I recommend to keep
producers and consumers of these files in the loop before changing
Chapter 5.  As for on which word to standardise on, I trust the Policy
Editors to make a good choice, even if it is not my favourite.

Have a nice week-end,

-- 
Charles

Bug#1020598: rtkit should depend on polkitd instead of policykit-1

[Christopher Martin]

Package: rtkit
Version: 0.13-4

rtkit depends on policykit-1, which is now a transitional package that
pulls in both polkitd and pkexec.

Please update rtkit to depend directly on polkitd, thereby helping
users remove pkexec.

Thanks.

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[Russ Allbery]

Vincent Lefevre  writes:
> On 2022-09-23 10:13:50 -0700, Russ Allbery wrote:

>> naïvely (and naïve) are correct alternate spellings in English.
>> English historically uses a diaeresis to indicate that two adjacent
>> vowels form separate syllables rather than a diphthong.  This is one of
>> the only "native" accept marks in the English language, which otherwise
>> only uses accept marks in loan words and tends to drop them.

> If naïve is correct, I find it strange that none of dict-gcide, dict-wn
> and dict-foldoc have it, while they know "naive". Ditto for naïvely vs
> naively in dict-gcide and dict-wn.

Maybe they don't cope with accent marks?  I'm not sure what to tell you
other than that good English dictionaries are (unfortunately) proprietary
and the freely available dictionaries, while useful for many things, are
of poorer quality.

Merriam-Webster (one of the canonical US dictionaries) lists it as a
variant:

https://www.merriam-webster.com/dictionary/naive

The OED (the canonical UK dictionary) also lists it as a form, with the
following etymology note:

All editions of D. Jones Eng. Pronouncing Dict. s.v. naïve mark stress
on the second syllable, until 1947 giving alternative pronunciations
with stress on the first. Editions until 1982 give the form naive as a
separate headword, with the monosyllabic pronunciation /neɪv/.

(No direct link because I have OED access via my local public library.)

See also:

https://www.languagetrainers.com/blog/youre-not-naive-not-to-know-about-diaereses/
https://ell.stackexchange.com/questions/51042/why-does-the-i-in-na%C3%AFve-have-two-dots

All that said, it *is* much more common than not to omit the diaeresis,
and that is certainly a simple solution to this specific bug.  (But as
Pod::Text and Pod::Man maintainer, I'm glad that you reported it because I
think there are deeper bugs in both modules that I need to fix.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Hi Aurelien, 

Old libc is because I reverted it as some scripts I use and autoconf as well 
were breaking.

I assume I have mentioned in report that a downgrade solved crash. If I missed 
sorry about that.

Sorry for top posting as I’m replying from my pho e 

Sent from my iPhone

> On 24-Sep-2022, at 03:21, Aurelien Jarno  wrote:
> 
> Hi,
> 
>> On 2022-09-23 21:28, Bernhard Übelacker wrote:
>>> On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath  
>>> wrote:
>>> Package: libc6
>>> Version: 2.34-8
>> 
>>> I upgraded libc6 to latest released 2.35-1
>> 
>>>Module ld-linux-x86-64.so.2 with build-id 
>>> a03c3b14d371da908a3f22007b3f0c73d1f9f634
>>>Module libc.so.6 with build-id 
>>> ef3afb43092687d7fcc8167fabdee73f4a3287f1
>>>Module libgmp.so.10 with build-id 
>>> 25c73b398493c695a013a6d9d493a8316aac0fa0
>>>Module expr with build-id 
>>> b919757cbc30fbb64b14498222499d972fd80acd
>> 
>> 
>>> Versions of packages libc6 suggests:
>>> ii  debconf [debconf-2.0]  1.5.79
>>> pn  glibc-doc  
>>> ii  libc-l10n  2.35-1
>>> ii  libnss-nis 3.1-4
>>> ii  libnss-nisplus 1.3-4
>>> ii  locales2.35-1
>> 
>> 
>> 
>> Hello Vasudev,
>> I wonder if this libc6 installation is completed.
>> Because the bug report mentions version 2.34-8 from testing,
>> but e.g. locales and libc-l10n is 2.35-1.
>> 
>> Also searching for a package containing the debug information
>> for the build-id from the modules listing returns currently
>> the version 2.34-8 from testing.
>> 
>> But the build-id for ld-linux-x86-64.so.2 points to 2.35-1.
>> 
>> Maybe the libc package installation got interrupted?
> 
> Good catch. I also noticed that the libraries seems to be located in
> /usr/lib/x86_64-linux-gnu/, which is typical of a usrmerge system, but
> reportbug says "merged-usr: no".
> 
> Vasudev, you should probably check that you do not have too versions of
> the glibc on your system, one in /lib/x86_64-linux-gnu/ and another one
> in /usr/lib/x86_64-linux-gnu/ without the /lib -> usr/lib symlink.
> 
> Regards
> Aurelien
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[duck]

Quack,

First, Steinar, I had the same crash and you need to exclude 
'inline-signing yes' if your zone uses 'allow-update' or 
'update-policy'. A proper error message would have been welcome indeed.


I was also struck by this breakage and my whole infra was down because I 
use unattended-upgrades + needrestart. This really has no place in a 
security updates but clearly upstream made a mistake. I would be in 
favor of a rollback to the previous version but maybe by the time it's 
already too late.


Regards.
\_o<

--
Marc Dequènes

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[Vincent Lefevre]

On 2022-09-23 10:13:50 -0700, Russ Allbery wrote:
> naïvely (and naïve) are correct alternate spellings in English.  English
> historically uses a diaeresis to indicate that two adjacent vowels form
> separate syllables rather than a diphthong.  This is one of the only
> "native" accept marks in the English language, which otherwise only uses
> accept marks in loan words and tends to drop them.

If naïve is correct, I find it strange that none of dict-gcide,
dict-wn and dict-foldoc have it, while they know "naive". Ditto
for naïvely vs naively in dict-gcide and dict-wn.

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

Bug#1020597: Acknowledgement (r8169 transmit queue 0 timed out)

[Jiann-Ming Su]

Huh, maybe related to the switch these two computers are both connected to?

[   93.999895] [ cut here ]
[   93.33] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[   93.85] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:467
dev_watchdog+0x260/0x270
[   93.92] Modules linked in: nft_counter 8021q garp stp mrp llc
xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6
nf_defrag_i
pv4 nft_compat nf_tables libcrc32c nfnetlink ath3k btusb btrtl btbcm
nls_ascii btintel nls_cp437 vfat bluetooth fat snd_hda_codec_hdmi
jitte
rentropy_rng snd_hda_codec_realtek x86_pkg_temp_thermal
intel_powerclamp drbg snd_hda_codec_generic coretemp ledtrig_audio
ath9k ath9k_commo
n snd_hda_intel snd_intel_dspcfg kvm_intel i915 soundwire_intel
ath9k_hw soundwire_generic_allocation snd_soc_core ath kvm mac80211
snd_comp
ress soundwire_cadence irqbypass snd_hda_codec snd_hda_core
aes_generic ghash_clmulni_intel snd_hwdep soundwire_bus cfg80211
snd_pcm snd_tim
er mei_me aesni_intel drm_kms_helper ansi_cprng intel_rapl_msr snd
crypto_simd processor_thermal_device ecdh_generic cryptd ecc rfkill
iTCO_
wdt cec evdev glue_helper libaes mei intel_rapl_common libarc4
soundcore intel_pmc_bxt i2c_algo_bit rapl int340x_thermal_zone tpm_tis
iTCO_v
endor_support at24
[   94.000697]  intel_soc_dts_iosf watchdog intel_pch_thermal
tpm_tis_core intel_cstate sg intel_uncore tpm rng_core pcspkr
efi_pstore butto
n drm fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16
mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic
ah
ci xhci_pci libahci xhci_hcd libata crct10dif_pclmul crct10dif_common
crc32_pclmul r8169 crc32c_intel usbcore scsi_mod realtek mdio_devres l
ibphy i2c_i801 i2c_smbus lpc_ich usb_common fan video
[   94.001059] CPU: 3 PID: 0 Comm: swapper/3 Not tainted
5.10.0-17-amd64 #1 Debian 5.10.136-1
[   94.001067] Hardware name: GOOGLE Panther/Panther, BIOS
MrChromebox-4.10 08/22/2019
[   94.001089] RIP: 0010:dev_watchdog+0x260/0x270
[   94.001103] Code: eb a9 48 8b 1c 24 c6 05 5f be 0d 01 01 48 89 df
e8 35 75 fa ff 44 89 e9 48 89 de 48 c7 c7 78 cf 76 9f 48 89 c2 e8 b5
99
14 00 <0f> 0b eb 86 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 41
[   94.001118] RSP: 0018:96d20012ceb0 EFLAGS: 00010282
[   94.001134] RAX:  RBX: 88fc40af2000 RCX: 083f
[   94.001145] RDX:  RSI: 00f6 RDI: 083f
[   94.001155] RBP: 88fc40af23dc R08:  R09: 96d20012ccd0
[   94.001166] R10: 96d20012ccc8 R11: 9fccb448 R12: 88fcb4bd0280
[   94.001177] R13:  R14: 88fc40af2480 R15: 0001
[   94.001188] FS:  () GS:88fcb4b8()
knlGS:
[   94.001199] CS:  0010 DS:  ES:  CR0: 80050033
[   94.001207] CR2: 7ff9f1380860 CR3: 00015ee0a002 CR4: 001706e0
[   94.001219] Call Trace:
[   94.001228]  
[   94.001247]  ? pfifo_fast_enqueue+0x150/0x150
[   94.001264]  call_timer_fn+0x29/0x100
[   94.001277]  __run_timers.part.0+0x1d9/0x250
[   94.001294]  ? recalibrate_cpu_khz+0x10/0x10
[   94.001308]  ? ktime_get+0x38/0xa0
[   94.001324]  ? lapic_next_deadline+0x28/0x40
[   94.001335]  ? clockevents_program_event+0x8d/0xf0
[   94.001346]  run_timer_softirq+0x26/0x50
[   94.001363]  __do_softirq+0xc5/0x279
[   94.001376]  asm_call_irq_on_stack+0x12/0x20
[   94.001386]  
[   94.001402]  do_softirq_own_stack+0x37/0x50
[   94.001419]  irq_exit_rcu+0x92/0xc0
[   94.001435]  sysvec_apic_timer_interrupt+0x36/0x80
[   94.001450]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[   94.001464] RIP: 0010:cpuidle_enter_state+0xc7/0x350
[   94.001477] Code: 8b 3d 5d da 34 61 e8 78 0a a0 ff 49 89 c5 0f 1f
44 00 00 31 ff e8 e9 15 a0 ff 45 84 ff 0f 85 fe 00 00 00 fb 66 0f 1f
44
00 00 <45> 85 f6 0f 88 0a 01 00 00 49 63 c6 4c 2b 2c 24 48 8d 14 40 48 8d
[   94.001487] RSP: 0018:96d20009fea8 EFLAGS: 0246
[   94.001503] RAX: 88fcb4bafd40 RBX: 0008 RCX: 001f
[   94.001510] RDX:  RSI: 4b77ec53 RDI: 
[   94.001523] RBP: 88fcb4bb9a00 R08: 0015e2d42563 R09: 0015e2bc50e3
[   94.001530] R10: 000353b7 R11: 88ad R12: 9fdae7c0
[   94.001541] R13: 0015e2d42563 R14: 0008 R15: 
[   94.001560]  ? cpuidle_enter_state+0xb7/0x350
[   94.001574]  cpuidle_enter+0x29/0x40
[   94.001593]  do_idle+0x1f3/0x2b0
[   94.001609]  cpu_startup_entry+0x19/0x20
[   94.001626]  secondary_startup_64_no_verify+0xb0/0xbb
[   94.001641] ---[ end trace 9c348499639096c8 ]---

On Fri, Sep 23, 2022 at 8:39 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1020597: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020597.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> 

Bug#1017313: postfix: FTBFS: unistd.h:363:13: error: conflicting types for ‘closefrom’; have ‘void(int)’

[Paul Wise]

On Fri, 2022-09-23 at 10:45 -0400, Antoine Beaupré wrote:

> Would this patch cut it? Not sure where to forward this upstream
> either...

I think the problem is that HAS_CLOSEFROM is not getting defined even
though the unistd.h header clearly has closefrom(). That should be
fixed first. Of course the definition of the compat function should be
changed to match the common definitions of closefrom() too. Your patch
is missing changing the definition and implementation of closefrom in
sys_compat.c, currently it is defined as returning an int and does
return -1 on errors, 0 on success.

PS: I note that closefrom is not in POSIX, maybe postfix should be
closing individual files more manually or using close_range instead.

https://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html#index-closefrom
https://www.gnu.org/software//gnulib/manual/html_node/closefrom.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1020597: r8169 transmit queue 0 timed out

[Jiann-Ming Su]

Package: linux-image-5.10.0-17-amd64
Version: 5.10.136-1

[651163.019588] [ cut here ]
[651163.019767] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[651163.019928] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:467
dev_watchdog+0x260/0x270
[651163.020071] Modules linked in: nls_utf8 cifs libarc4 dns_resolver
fscache libdes tcp_diag udp_diag inet_diag tun cmac algif_hash algif_s
kcipher af_alg bnep nft_chain_nat xt_MASQUERADE nf_nat nft_counter
xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6
nf_defrag_ipv
4 amdgpu gpu_sched nft_compat nf_tables libcrc32c crc32c_generic
nfnetlink uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2
videob
uf2_common videodev mc rtsx_usb_ms snd_hda_codec_realtek memstick
snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio snd_hda_intel
snd_i
ntel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core
btusb edac_mce_amd btrtl btbcm btintel nls_ascii bluetooth nls_cp437 s
nd_compress soundwire_cadence snd_hda_codec vfat fat snd_hda_core
jitterentropy_rng kvm snd_hwdep soundwire_bus snd_pcm drbg radeon
irqbypas
s ansi_cprng ecdh_generic snd_timer ecc snd ghash_clmulni_intel crc16
soundcore ideapad_laptop aesni_intel sparse_keymap libaes ttm rfkill c
rypto_simd cryptd wmi
[651163.020621]  glue_helper joydev drm_kms_helper serio_raw sg cec
evdev ccp i2c_algo_bit efi_pstore sp5100_tco pcspkr watchdog
fam15h_powe
r k10temp rng_core acpi_cpufreq ac button drm configfs fuse efivarfs
ip_tables x_tables autofs4 jfs rtsx_usb_sdmmc mmc_core rtsx_usb sd_mod
sr_mod t10_pi cdrom crc_t10dif crct10dif_generic ahci xhci_pci libahci
xhci_hcd crct10dif_pclmul crct10dif_common libata ehci_pci r8169 ehci
_hcd realtek crc32_pclmul mdio_devres scsi_mod usbcore psmouse libphy
crc32c_intel i2c_piix4 usb_common battery video
[651163.022997] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
5.10.0-17-amd64 #1 Debian 5.10.136-1
[651163.023140] Hardware name: LENOVO INVALID/VIUU4, BIOS 1QCN32WW 08/18/2016
[651163.023291] RIP: 0010:dev_watchdog+0x260/0x270
[651163.023375] Code: eb a9 48 8b 1c 24 c6 05 5f be 0d 01 01 48 89 df
e8 35 75 fa ff 44 89 e9 48 89 de 48 c7 c7 78 cf 96 8d 48 89 c2 e8 b5 9
9 14 00 <0f> 0b eb 86 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 41
[651163.023568] RSP: 0018:a3a500104eb0 EFLAGS: 00010282
[651163.023749] RAX:  RBX: 8ed5002d6000 RCX:

[651163.023883] RDX: 8ed51b4ac760 RSI: 8ed51b49ca00 RDI:
0300
[651163.023977] RBP: 8ed5002d63dc R08:  R09:
a3a500104cd0
[651163.024099] R10: a3a500104cc8 R11: 8decb448 R12:
8ed507f18c80
[651163.024222] R13:  R14: 8ed5002d6480 R15:
0001
[651163.024349] FS:  () GS:8ed51b48()
knlGS:
[651163.027477] CS:  0010 DS:  ES:  CR0: 80050033
[651163.035480] CR2: 7f8ca499dd00 CR3: 00010225a000 CR4:
000406e0
[651163.039535] Call Trace:
[651163.043484]  
[651163.051482]  ? pfifo_fast_enqueue+0x150/0x150
[651163.055477]  call_timer_fn+0x29/0x100
[651163.059476]  __run_timers.part.0+0x1d9/0x250
[651163.067477]  ? ktime_get+0x38/0xa0
[651163.071478]  ? native_x2apic_icr_read+0x20/0x20
[651163.075476]  ? lapic_next_event+0x1d/0x30
[651163.083476]  ? clockevents_program_event+0x8d/0xf0
[651163.087477]  run_timer_softirq+0x26/0x50
[651163.091476]  __do_softirq+0xc5/0x279
[651163.095476]  asm_call_irq_on_stack+0x12/0x20
[651163.103476]  
[651163.107477]  do_softirq_own_stack+0x37/0x50
[651163.111477]  irq_exit_rcu+0x92/0xc0
[651163.115476]  sysvec_apic_timer_interrupt+0x36/0x80
[651163.119476]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[651163.127475] RIP: 0010:cpuidle_enter_state+0xc7/0x350
[651163.131476] Code: 8b 3d 5d da 14 73 e8 78 0a a0 ff 49 89 c5 0f 1f
44 00 00 31 ff e8 e9 15 a0 ff 45 84 ff 0f 85 fe 00 00 00 fb 66 0f 1f 4
4 00 00 <45> 85 f6 0f 88 0a 01 00 00 49 63 c6 4c 2b 2c 24 48 8d 14 40 48 8d
[651163.139476] RSP: 0018:a3a5000bfea8 EFLAGS: 0246
[651163.147477] RAX: 8ed51b4afd40 RBX: 0002 RCX:
0002503ab4787fa4
[651163.151476] RDX: 01fa RSI: 0002503ab4787fa4 RDI:

[651163.155477] RBP: 8ed507c3c400 R08: 0002503ab478819e R09:
0001
[651163.159477] R10:  R11: f456 R12:
8dfb9180
[651163.163475] R13: 0002503ab478819e R14: 0002 R15:

[651163.171477]  ? cpuidle_enter_state+0xb7/0x350
[651163.175477]  cpuidle_enter+0x29/0x40
[651163.179478]  do_idle+0x1f3/0x2b0
[651163.183477]  cpu_startup_entry+0x19/0x20
[651163.187476]  secondary_startup_64_no_verify+0xb0/0xbb
[651163.191476] ---[ end trace 4cb2b634af66d097 ]---



-- 
Jiann-Ming Su

Bug#804404: tag as wheezy

[Alban Browaeys]

package libdvd-pkg
tag 804404 + wheezy
thanks

Maybe this bug should be closed as wheezy is not supported anymore?

Kind regards,

Alban

Bug#1020596: bullseye-pu: mod-wsgi/4.7.1-3+deb11u1

[Thorsten Alteholz]

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


The attached debdiff for mod-wsgi fixes CVE-2022-2255 in Bullseye. This 
CVE has been marked as no-dsa by the security team.


The same fix has already been uploaded to Unstable/Testing, Stretch, 
Jessie and Buster and nobody complained yet.


  Thorsten
diff -Nru mod-wsgi-4.7.1/debian/changelog mod-wsgi-4.7.1/debian/changelog
--- mod-wsgi-4.7.1/debian/changelog 2020-10-15 21:48:24.0 +0200
+++ mod-wsgi-4.7.1/debian/changelog 2022-09-12 23:03:02.0 +0200
@@ -1,3 +1,11 @@
+mod-wsgi (4.7.1-3+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2022-2255 (Closes: #1016476)
+drop X-Client-IP header when is not a trusted header
+
+ -- Thorsten Alteholz   Mon, 12 Sep 2022 23:03:02 +0200
+
 mod-wsgi (4.7.1-3) unstable; urgency=medium
 
   [ Stefano Rivera ]
diff -Nru mod-wsgi-4.7.1/debian/patches/CVE-2022-2255.patch 
mod-wsgi-4.7.1/debian/patches/CVE-2022-2255.patch
--- mod-wsgi-4.7.1/debian/patches/CVE-2022-2255.patch   1970-01-01 
01:00:00.0 +0100
+++ mod-wsgi-4.7.1/debian/patches/CVE-2022-2255.patch   2022-07-31 
02:01:02.0 +0200
@@ -0,0 +1,18 @@
+commit af3c0c2736bc0b0b01fa0f0aad3c904b7fa9c751
+Author: Graham Dumpleton 
+Date:   Mon Jul 18 12:29:38 2022 +1000
+
+Add fix to ensure that X-Client-IP header is dropped when is not a trusted 
header.
+
+Index: mod-wsgi-4.7.1/src/server/mod_wsgi.c
+===
+--- mod-wsgi-4.7.1.orig/src/server/mod_wsgi.c  2022-07-31 02:00:58.799486663 
+0200
 mod-wsgi-4.7.1/src/server/mod_wsgi.c   2022-07-31 02:00:58.795486661 
+0200
+@@ -13942,6 +13942,7 @@
+ name = ((const char**)trusted_proxy_headers->elts)[i];
+ 
+ if (!strcmp(name, "HTTP_X_FORWARDED_FOR") ||
++ !strcmp(name, "HTTP_X_CLIENT_IP") ||
+  !strcmp(name, "HTTP_X_REAL_IP")) {
+ 
+ match_client_header = 1;
diff -Nru mod-wsgi-4.7.1/debian/patches/series 
mod-wsgi-4.7.1/debian/patches/series
--- mod-wsgi-4.7.1/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ mod-wsgi-4.7.1/debian/patches/series2022-07-31 02:00:46.0 
+0200
@@ -0,0 +1 @@
+CVE-2022-2255.patch

Bug#1012333: u-boot-menu: add support for using config fragments

[Jonas Smedegaard]

Quoting Arnaud Ferraris (2022-09-23 14:51:40)
> On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian 
>  wrote:
> > On 2022-06-04, Jonas Smedegaard wrote:
> > > Seems more sensible for me, however, to implement this using debconf.

[ thoughts on non-debconf mechanism snipped ]

> > That seems a lot simpler than introducing the complexity of debconf
> > generated configuration files...
> 
> Indeed, so far my experiments with debconf for solving this matter have 
> been sub-optimal at best.

Can you elaborate on your bad experiences with debconf?


 - 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#703190: closed by Patrick Matthäi (Closing already long fixed bugs)

[Dmitry Katsubo]

On 2022-09-21 10:14, Patrick Matthäi wrote:
> Hi,
> 
> I have uploaded here an untested backport for you for the next days: 
> https://cloud.linux-dev.org/index.php/s/jBZmioEZWRP9ebb
> 
> You have to update libxine and xine-ui

Many thanks. I confirm that xine plays video on framebuffer console just fine. 
Fantastic!

-- 
With best regards,
Dmitry

Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: tomlplusplus
  Version : 3.2.0
  Upstream Author : Mark Gillard 
* URL : https://marzer.github.io/tomlplusplus/
* License : MIT/Expat
  Programming Lang: C++
  Description : TOML config parser and serializer for C++17

Features:
- - Supports the latest TOML release (v1.0.0), plus optional support for some
unreleased TOML features
- - Passes all tests in the toml-test suite
- - Supports serializing to JSON and YAML
- - Proper UTF-8 handling (incl. BOM)
- - C++17 (plus some C++20 features where available, e.g. experimental support
for char8_t strings)
- - Doesn't require RTTI
- - Works with or without exceptions
- - Tested on Clang (6+), GCC (7+) and MSVC (VS2019)
- - Tested on x64, x86 and ARM

I've used this library in the past, and I was surprised to find out that it is
not available in Debian.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYy4sExQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p7IMAP9BKJ8/B6nrKHvKzREXrz8n2nqxGRr5
Yuc+QCCNtjOL0wD+IWVXon6q2S5n4SUSMqRzAWw0zJXc7OppfpTaKzk7cgQ=
=dCnP
-END PGP SIGNATURE-

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Aurelien Jarno]

Hi,

On 2022-09-23 21:28, Bernhard Übelacker wrote:
> On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath  wrote:
> > Package: libc6
> > Version: 2.34-8
> 
> > I upgraded libc6 to latest released 2.35-1
> 
> > Module ld-linux-x86-64.so.2 with build-id 
> > a03c3b14d371da908a3f22007b3f0c73d1f9f634
> > Module libc.so.6 with build-id 
> > ef3afb43092687d7fcc8167fabdee73f4a3287f1
> > Module libgmp.so.10 with build-id 
> > 25c73b398493c695a013a6d9d493a8316aac0fa0
> > Module expr with build-id 
> > b919757cbc30fbb64b14498222499d972fd80acd
> 
> 
> > Versions of packages libc6 suggests:
> > ii  debconf [debconf-2.0]  1.5.79
> > pn  glibc-doc  
> > ii  libc-l10n  2.35-1
> > ii  libnss-nis 3.1-4
> > ii  libnss-nisplus 1.3-4
> > ii  locales2.35-1
> 
> 
> 
> Hello Vasudev,
> I wonder if this libc6 installation is completed.
> Because the bug report mentions version 2.34-8 from testing,
> but e.g. locales and libc-l10n is 2.35-1.
> 
> Also searching for a package containing the debug information
> for the build-id from the modules listing returns currently
> the version 2.34-8 from testing.
> 
> But the build-id for ld-linux-x86-64.so.2 points to 2.35-1.
> 
> Maybe the libc package installation got interrupted?

Good catch. I also noticed that the libraries seems to be located in
/usr/lib/x86_64-linux-gnu/, which is typical of a usrmerge system, but
reportbug says "merged-usr: no".

Vasudev, you should probably check that you do not have too versions of
the glibc on your system, one in /lib/x86_64-linux-gnu/ and another one
in /usr/lib/x86_64-linux-gnu/ without the /lib -> usr/lib symlink.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1020594: ipxe-qemu: Cannot boot Linux image in UEFI VM

[Kevin Otte]

Package: ipxe-qemu
Version: 1.0.0+git-20190125.36a4c85-5.1
Severity: important

When attempting to network boot a UEFI VM, cannot boot the Linux kernel image:

iPXE> ifopen net0
iPXE> dhcp
Configuring (net0 52:54:00:b1:e7:9f).. ok
iPXE> kernel http://gemini.int.home.nivex.net/boot/bullseye/amd64/linux
http://gemini.int.home.nivex.net/boot/bullseye/amd64/linux... ok
Could not select: Exec format error (http://ipxe.org/2e008081)
iPXE>

This works fine in a BIOS based VM.

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

Kernel: Linux 5.19.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

-- no debconf information

Bug#1012474: [PATCH] Xsession does not recognise shell builtins as session-type

[Vassilis Virvilis]

Thanks for this patch.

For months and months I had to go through the click + click ordeal in order to 
access the remote session.

I would note that it has to be applied in the client.

Thanks again.

   Vassilis

Bug#1020593: mmdebstrap: debootstrap installing empty lsb-base package prevents autopkgtest from passing

[Johannes Schauer Marin Rodrigues]

Package: mmdebstrap
Version: 1.2.1-2
Severity: serious
X-Debbugs-Cc: jo...@debian.org

The functionality of lsb-base is in the Essential:yes set since
Bullseye. The package itself is now an empty transitional package
(because debootstrap doesn't understand the Provides relationship) which
depends on the new provider of the functionality, sysvinit-utils, which
is also in the Essential:yes set.

The problem is, that this empty package is only installed by debootstrap
because its resolver is not clever enough to realize that its
installation can be avoided. The resolver used by mmdebstrap (apt) does
not draw in the useless empty lsb-base package, thus resulting in a
difference between the chroots created by debootstrap and mmdebstrap
that makes the mmdebstrap test suite not succeed:

https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mmdebstrap/26125615/log.gz

[...]
I: Retrieving logrotate 3.20.1-1
I: Validating logrotate 3.20.1-1
I: Retrieving lsb-base 11.4
W: Couldn't download package lsb-base (ver 11.4 arch all) at 
http://127.0.0.1/debian/pool/main/l/lsb/lsb-base_11.4_all.deb
I: Retrieving dmsetup 2:1.02.185-1
I: Validating dmsetup 2:1.02.185-1
[...]
I: Retrieving zlib1g 1:1.2.11.dfsg-4.1
I: Validating zlib1g 1:1.2.11.dfsg-4.1
E: Couldn't download packages: lsb-base

Instead of adding a hack to mmdebstrap, lets correct all packages in the
Priority:important set that still carry a useless dependency on
lsb-base:

https://salsa.debian.org/debian/cron/-/merge_requests/7
https://salsa.debian.org/debian/ifupdown/-/merge_requests/12
https://salsa.debian.org/md/kmod/-/merge_requests/9
https://salsa.debian.org/debian/procps/-/merge_requests/6

There is also a proposed lintian message deprecating the use of lsb-base
in dependencies:

https://salsa.debian.org/lintian/lintian/-/merge_requests/419

Thanks!

cheers, josch

Bug#1020592: [Pkg-javascript-devel] Bug#1020592: nodejs: Testsuite is using smoil keys

[Jérémy Lal]

Le ven. 23 sept. 2022 à 23:03, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> control: found -1 odejs/18.7.0+dfsg-5
>
> On 2022-09-23 22:55:23 [+0200], Jérémy Lal wrote:
> > Thanks, I'm already aware of the need to run nodejs testsuite using
> > their own specific openssl.cnf.
> > It seems you are reporting a bug against a version of nodejs that has
> never
> > made it
> > to debian. Did you mean to report to ubuntu or some other distribution
> > instead ?
> > If that's the case please close this bug and open a new one at the right
> > place.
>
> Ehm. It seems I forgot a 1 while copy paste. The current openssl version
> in unstable is blocked due that reason:
> |   autopkgtest for nodejs/18.7.0+dfsg-5: amd64: Regression
>
> so I think I am at the right place ;)
>

I'll upload nodejs 18.9.1 this week-end, along with a/your fix for that
issue.

Jérémy

Bug#1020592: [Pkg-javascript-devel] Bug#1020592: nodejs: Testsuite is using smoil keys

[Sebastian Andrzej Siewior]

control: found -1 odejs/18.7.0+dfsg-5

On 2022-09-23 22:55:23 [+0200], Jérémy Lal wrote:
> Thanks, I'm already aware of the need to run nodejs testsuite using
> their own specific openssl.cnf.
> It seems you are reporting a bug against a version of nodejs that has never
> made it
> to debian. Did you mean to report to ubuntu or some other distribution
> instead ?
> If that's the case please close this bug and open a new one at the right
> place.

Ehm. It seems I forgot a 1 while copy paste. The current openssl version
in unstable is blocked due that reason:
|   autopkgtest for nodejs/18.7.0+dfsg-5: amd64: Regression

so I think I am at the right place ;)

> Thanks,
> Jérémy

Sebastian

Bug#1020592: [Pkg-javascript-devel] Bug#1020592: nodejs: Testsuite is using smoil keys

[Jérémy Lal]

Le ven. 23 sept. 2022 à 22:51, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> Package: nodejs
> Version: 8.7.0+dfsg-5
> Severity: serious
> control: tags -1 patch
>
> The last OpenSSL upload moved the default security level from the
> openssl.cnf file to build-time default so I don't have to fiddle with
> the config file anymore.
> Unfortunately nodejs is using smoil keys in its testsuite so the
> testsuite fails now. Previously it didn't because it used the "default"
> openssl.cnf which did not specify any of this so the security level was
> never changed from its default - 1. Now it is 2 and nodejs needs either
> to increase the default key size or lower security level via the config
> file.
> A patch for the latter has been attached.


Thanks, I'm already aware of the need to run nodejs testsuite using
their own specific openssl.cnf.
It seems you are reporting a bug against a version of nodejs that has never
made it
to debian. Did you mean to report to ubuntu or some other distribution
instead ?
If that's the case please close this bug and open a new one at the right
place.

Thanks,
Jérémy

Bug#1020592: nodejs: Testsuite is using smoil keys

[Sebastian Andrzej Siewior]

Package: nodejs
Version: 8.7.0+dfsg-5
Severity: serious
control: tags -1 patch

The last OpenSSL upload moved the default security level from the
openssl.cnf file to build-time default so I don't have to fiddle with
the config file anymore.
Unfortunately nodejs is using smoil keys in its testsuite so the
testsuite fails now. Previously it didn't because it used the "default"
openssl.cnf which did not specify any of this so the security level was
never changed from its default - 1. Now it is 2 and nodejs needs either
to increase the default key size or lower security level via the config
file.
A patch for the latter has been attached.

Sebastian
From: Sebastian Andrzej Siewior 
Date: Fri, 23 Sep 2022 22:39:50 +0200
Subject: [PATCH] Add a CipherString for nodejs

If the default security level is overwritten at build time of openssl
then it is needed to lower it again for nodejs in order to pass the
testsuite because it is using smoil keys.

Signed-off-by: Sebastian Andrzej Siewior 
---
 deps/openssl/openssl/apps/openssl.cnf | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/deps/openssl/openssl/apps/openssl.cnf b/deps/openssl/openssl/apps/openssl.cnf
index 03330e0120a2..65ae201e44aa 100644
--- a/deps/openssl/openssl/apps/openssl.cnf
+++ b/deps/openssl/openssl/apps/openssl.cnf
@@ -15,6 +15,7 @@ HOME			= .
 
  # Use this in order to automatically load providers.
 openssl_conf = openssl_init
+nodejs_conf = nodejs_init
 
 # Comment out the next line to ignore configuration errors
 config_diagnostics = 1
@@ -388,3 +389,12 @@ oldcert = $insta::certout # insta.cert.pem
 # Certificate revocation
 cmd = rr
 oldcert = $insta::certout # insta.cert.pem
+
+[nodejs_init]
+ssl_conf = ssl_sect
+
+[ssl_sect]
+system_default = system_default_sect
+
+[system_default_sect]
+CipherString = DEFAULT:@SECLEVEL=1
-- 
2.37.2

Bug#1020590: tiger: diff for NMU version 1:3.2.4~rc1-3.1

[Francois Marier]

Package: tiger
Version: 1:3.2.4~rc1-3
Severity: normal
Tags: patch

Dear maintainer,

I've prepared an NMU for tiger (versioned as 1:3.2.4~rc1-3.1) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it longer.

It consists of a single fix for bug #987512. Attached is the debdiff.

Regards.

Francois


-- 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.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (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 tiger depends on:
ii  binutils   2.38.90.20220713-2
ii  bsdutils   1:2.38.1-1
ii  debconf [debconf-2.0]  1.5.79
ii  debianutils5.7-0.3
ii  libc6  2.35-1
ii  lsb-release11.4
ii  net-tools  1.60+git20181103.0eebece-1
ii  ucf3.0043

Versions of packages tiger recommends:
ii  chkrootkit  0.55-4+b2
pn  john
ii  postfix [mail-transport-agent]  3.6.4-1+b3
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof   4.95.0-1
ii  lynis  3.0.8-1

-- debconf information:
* tiger/mail_rcpt: root
* tiger/policy_adapt:

-- 
https://fmarier.org/
diff -u tiger-3.2.4~rc1/debian/changelog tiger-3.2.4~rc1/debian/changelog
--- tiger-3.2.4~rc1/debian/changelog
+++ tiger-3.2.4~rc1/debian/changelog
@@ -1,3 +1,10 @@
+tiger (1:3.2.4~rc1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Teach tiger about fuse.portal (Closes: #987512)
+
+ -- Francois Marier   Fri, 23 Sep 2022 12:03:08 -0700
+
 tiger (1:3.2.4~rc1-3) unstable; urgency=medium
 
   * Acknowledge NMU (Closes: #969303)
diff -u tiger-3.2.4~rc1/systems/Linux/2/gen_mounts tiger-3.2.4~rc1/systems/Linux/2/gen_mounts
--- tiger-3.2.4~rc1/systems/Linux/2/gen_mounts
+++ tiger-3.2.4~rc1/systems/Linux/2/gen_mounts
@@ -184,6 +184,7 @@
   [ "$1" = "fuse.gvfsd-fuse" ] && LOCAL=1   # Used in Ubuntu 13.10 (Saucy Salamander) replaces fuse.gvfs-fuse-daemon
   [ "$1" = "fuse.ltspfs" ] && LOCAL=0 		# Used by LTSP 5.x
   [ "$1" = "fuse.lxcfs" ] && LOCAL=0
+  [ "$1" = "fuse.portal" ] && LOCAL=0
   [ "$1" = "fuse.clamfs" ] && LOCAL=0   # ClamFS anti-virus protected file system
   [ "$1" = "fuse.javafs" ] && LOCAL=0   # Java FS, used by Wuala secure online storage, see:
 # https://github.com/puniverse/javafs
only in patch2:
unchanged:
--- tiger-3.2.4~rc1.orig/configure
+++ tiger-3.2.4~rc1/configure
@@ -1,9 +1,10 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69.
+# Generated by GNU Autoconf 2.71.
 #
 #
-# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
+# Copyright (C) 1992-1996, 1998-2017, 2020-2021 Free Software Foundation,
+# Inc.
 #
 #
 # This configure script is free software; the Free Software Foundation
@@ -14,14 +15,16 @@
 
 # Be more Bourne compatible
 DUALCASE=1; export DUALCASE # for MKS sh
-if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
+as_nop=:
+if test ${ZSH_VERSION+y} && (emulate sh) >/dev/null 2>&1
+then :
   emulate sh
   NULLCMD=:
   # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
   # is contrary to our usage.  Disable this feature.
   alias -g '${1+"$@"}'='"$@"'
   setopt NO_GLOB_SUBST
-else
+else $as_nop
   case `(set -o) 2>/dev/null` in #(
   *posix*) :
 set -o posix ;; #(
@@ -31,46 +34,46 @@
 fi
 
 
+
+# Reset variables that may have inherited troublesome values from
+# the environment.
+
+# IFS needs to be set, to space, tab, and newline, in precisely that order.
+# (If _AS_PATH_WALK were called with IFS unset, it would have the
+# side effect of setting IFS to empty, thus disabling word splitting.)
+# Quoting is to prevent editors from complaining about space-tab.
 as_nl='
 '
 export as_nl
-# Printing a long string crashes Solaris 7 /usr/bin/printf.
-as_echo='\\\'
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
-# Prefer a ksh shell builtin over an external printf program on Solaris,
-# but without wasting forks for bash or zsh.
-if test -z "$BASH_VERSION$ZSH_VERSION" \
-&& (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
-  as_echo='print -r --'
-  as_echo_n='print -rn --'
-elif (test "X`printf %s $as_echo`" = "X$as_echo") 2>/dev/null; then
-  as_echo='printf %s\n'
-  as_echo_n='printf %s'
-else
-  if test "X`(/usr/ucb/echo -n -n $as_echo) 2>/dev/null`" = "X-n $as_echo"; then
-

Bug#1020591: RM: mz -- RoQA; Orphaned; Dead Upstream; RC-Buggy; Merged Into Other Package

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: b...@debian.org

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/961969 , package mz in Debian (
https://tracker.debian.org/pkg/mz ) has a dead upstream since 2011. The
package is also orphaned and saw no maintainer upload since 2010. Besides,
its functionality is also provided by another package in Debian. As a
result, I believe we should have src:mz removed from Debian Sid.

Regards,
Boyuan Yang


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

Bug#1020589: batik: CVE-2022-38398 CVE-2022-38648 CVE-2022-40146

[Salvatore Bonaccorso]

Source: batik
Version: 1.14-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for batik.

CVE-2022-38398[0]:
| Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache
| XML Graphics allows an attacker to load a url thru the jar protocol.
| This issue affects Apache XML Graphics Batik 1.14.


CVE-2022-38648[1]:
| Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache
| XML Graphics allows an attacker to fetch external resources. This
| issue affects Apache XML Graphics Batik 1.14.


CVE-2022-40146[2]:
| Server-Side Request Forgery (SSRF) vulnerability in Batik of Apache
| XML Graphics allows an attacker to access files using a Jar url. This
| issue affects Apache XML Graphics Batik 1.14.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-38398
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38398
https://issues.apache.org/jira/browse/BATIK-1331
http://svn.apache.org/viewvc?view=revision=1903462
[1] https://security-tracker.debian.org/tracker/CVE-2022-38648
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38648
https://issues.apache.org/jira/browse/BATIK-1333
http://svn.apache.org/viewvc?view=revision=1903625
[2] https://security-tracker.debian.org/tracker/CVE-2022-40146
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40146
https://issues.apache.org/jira/browse/BATIK-1335
http://svn.apache.org/viewvc?view=revision=1903910

Regards,
Salvatore

Bug#1020588: cmark-gfm: CVE-2022-39209

[Salvatore Bonaccorso]

Source: cmark-gfm
Version: 0.29.0.gfm.3-3
Severity: important
Tags: upstream security
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org

Hi,

The following vulnerability was published for cmark-gfm.

CVE-2022-39209[0]:
| cmark-gfm is GitHub's fork of cmark, a CommonMark parsing and
| rendering library and program in C. In versions prior to 0.29.0.gfm.6
| a polynomial time complexity issue in cmark-gfm's autolink extension
| may lead to unbounded resource exhaustion and subsequent denial of
| service. Users may verify the patch by running `python3 -c
| 'print("![l"* 10 + "\n")' | ./cmark-gfm -e autolink`, which will
| resource exhaust on unpatched cmark-gfm but render correctly on
| patched cmark-gfm. This vulnerability has been patched in
| 0.29.0.gfm.6. Users are advised to upgrade. Users unable to upgrade
| should disable the use of the autolink extension.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-39209
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39209
[1] 
https://github.com/github/cmark-gfm/commit/cfcaa0068bf319974fdec283416fcee5035c2d70

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1020587: squid: CVE-2022-41317

[Salvatore Bonaccorso]

Source: squid
Version: 5.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.13-10
Control: found -1 4.13-10+deb11u1

Hi,

The following vulnerability was published for squid.

CVE-2022-41317[0]:
| Exposure of Sensitive Information in Cache Manager

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41317
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41317
[1] https://www.openwall.com/lists/oss-security/2022/09/23/1

Regards,
Salvatore

Bug#1020586: squid: CVE-2022-41318

[Salvatore Bonaccorso]

Source: squid
Version: 5.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.13-10+deb11u1
Control: found -1 4.13-10

Hi,

The following vulnerability was published for squid.

CVE-2022-41318[0]:
| Buffer Over Read in SSPI and SMB Authentication

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41318
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41318
[1] https://www.openwall.com/lists/oss-security/2022/09/23/2

Regards,
Salvatore

Bug#1020549: usrmerge: needs a stricter conflict with libpng12-0

[Manuel Bilderbeek]

Package: usrmerge
Version: 31
Followup-For: Bug #1020549

Dear Maintainer,

FYI, I ran into exactly the same issue.

$ dpkg -l libpng12-0
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
ii  libpng12-0:amd64 1.2.54-6 amd64PNG library - runtime
sonata@21:36:~$ dpkg -S libpng12.so.0
libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0
libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0.54.0
$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0 
/usr/lib/x86_64-linux-gnu/libpng12.so.0
lrwxrwxrwx 1 root root 18 apr 13  2016 /lib/x86_64-linux-gnu/libpng12.so.0 -> 
libpng12.so.0.54.0
lrwxrwxrwx 1 root root  9 mrt  7  2016 /usr/lib/x86_64-linux-gnu/libpng12.so.0 
-> libpng.so

So, probably more people will run into it.

I have manually removed libpng12-0, apparently I still had this lib depeding on 
it:
he following packages have unmet dependencies:
 libpoppler46 : Depends: libpng12-0 (>= 1.2.13-4) but it is not going to be 
installed
The following actions will resolve these dependencies:

 Remove the following packages: 
1) libpoppler46 [0.26.5-4 (now)]

So I said Yes, and this resulted in:
The following packages will be REMOVED:
  libfile-find-rule-perl{u} libnumber-compare-perl{u} libpng12-0{p} 
  libpoppler46{a} libtext-glob-perl{u} usrmerge{u} 

So, I just removed these... and then the upgrade worked again.

HTH.

Kind regards,
Manuel

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

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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-5

usrmerge recommends no packages.

usrmerge suggests no packages.

-- no debconf information

Bug#1017098: decopy: may overturn the hierarchy of files w.r.t. the base debian/copyright file

[Jochen Sprickerhof]

Hi Francesco,

* Francesco Poli (wintermute)  [2022-08-13 19:08]:

I applied the following patch to the Makefile:

 -CEX := po/
 +CEX := po/.*\.mo


This includes the po/*.po in the file list which where excluded, 
previously.



Honestly, I expected that decopy would abide by this new base copyright
file and regenerate an identical debian/copyright file.


It works just fine if you do a debclean before generating it.


Well, this looks (almost) technically correct,


Yes and I think that's all you can ask for for such a tool. To me decopy 
is a good first step to create a d/copyright file but it always need 
some human eyes.



Firstly, decopy decided that the license for po/* applies to * !!!


I don't know all the decopy code but I think it has some heuristics for 
which copyright block should be the top one.



Then, I see that apt-listbugs.1 is listed among the special cases.
But that file is generated, and I thought it was excluded through
the --exclude option of decopy. Apparently, it is not! Why?


I guess exclude is only for the content not for the file list. Maybe 
that's what meant in #997814..



Finally, I fail to understand where the "2002-2020, Masato Taruishi"
additional Copyright come from.
It seems to me that every copyright notice referring to Masato Taruishi
in the source tree is either followed by his e-mail address or by "et al.".
So where does this additional Copyright come from?


decopy strips the et al.:

https://sources.debian.org/src/decopy/0.2.4.7-0.2/decopy/res.py/#L509

So with the Makefile change above the .po files are searched again and 
the entry is added.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1018224: RE: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Hi Dipak,

On Tue, 30 Aug 2022 09:57:44 + Dipak Zope1  wrote:

Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it further and 
will keep this thread updated.


I think we established that you replied here but had the other bug in 
mind (in atop).



I am looking forward to have a fix for this for s390x.


Can you still look into the exempi issue in this bug report?


On 30/08/22, 12:44 AM, "Paul Gevers"  wrote:
Hi Michael

On 29-08-2022 14:23, Michael Biebl wrote:
> As you are probably aware, this issue is known and tracked in [1].

Which I added as a blocker and mentioned in my message, so yes.

> The
> package FTBFS after enabling the test suite. I raised this issue
> upstream but there is no real interest/motivation [2] on their part to
> address these (most likely endianess related) issues.
> So I informed the s390x porters as well but got not feedback so far.

Ack, I saw the latter part.

> To me it seems it's better to not continue ship a known broken package
> on s390x and think a partial architecture removal is probably the better
> alternative.

If you think the package indeed is severely broken, then removal sounds
best. If its broken in some less common use cases, it may be OK to leave
it for now (skipping those tests on 390x) and let the porters have a
look when they have time.

> Let me know what you think

It all depends on how broken it is. If you would consider the bugs found
by the tests RC, then removal is the better choice unless a porter steps
up to fix it. If the bugs would be important at most, than skipping
broken tests on s390x sounds like the better option. Removal bugs are
hard to time predict.

Paul

PS: I would not disable building on s390x if you have the test suite
finding out severe problems (as the d/control file doesn't have negated
architecture fields yet). Just getting the binary removed and FTBFS will
prevent the architecture from building again.


Otherwise I think we need to go this route.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Bernhard Übelacker]

On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath  wrote:

Package: libc6
Version: 2.34-8



I upgraded libc6 to latest released 2.35-1



Module ld-linux-x86-64.so.2 with build-id 
a03c3b14d371da908a3f22007b3f0c73d1f9f634
Module libc.so.6 with build-id 
ef3afb43092687d7fcc8167fabdee73f4a3287f1
Module libgmp.so.10 with build-id 
25c73b398493c695a013a6d9d493a8316aac0fa0
Module expr with build-id 
b919757cbc30fbb64b14498222499d972fd80acd




Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.79
pn  glibc-doc  
ii  libc-l10n  2.35-1
ii  libnss-nis 3.1-4
ii  libnss-nisplus 1.3-4
ii  locales2.35-1




Hello Vasudev,
I wonder if this libc6 installation is completed.
Because the bug report mentions version 2.34-8 from testing,
but e.g. locales and libc-l10n is 2.35-1.

Also searching for a package containing the debug information
for the build-id from the modules listing returns currently
the version 2.34-8 from testing.

But the build-id for ld-linux-x86-64.so.2 points to 2.35-1.

Maybe the libc package installation got interrupted?

Kind regards,
Bernhard

[1] /usr/lib/debug/.build-id/ef/3afb43092687d7fcc8167fabdee73f4a3287f1.debug

https://packages.debian.org/search?searchon=contents=3afb43092687d7fcc8167fabdee73f4a3287f1=filename=testing=any

[2] /usr/lib/debug/.build-id/a0/3c3b14d371da908a3f22007b3f0c73d1f9f634.debug

https://packages.debian.org/search?searchon=contents=3c3b14d371da908a3f22007b3f0c73d1f9f634=filename=unstable=any

Bug#1020585: ITP: golang-github-marekm4-color-extractor -- simple image color extractor written in Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-marekm4-color-extractor
  Version : 1.2.0-1
  Upstream Author : Marek Michalik
* URL : https://github.com/marekm4/color-extractor
* License : Expat
  Programming Lang: Go
  Description : simple image color extractor written in Go

 Simple image color extractor written in Go with no external dependencies.
 .
 Demo: https://color-extractor-demo.herokuapp.com/
 .
 Blog post:
 
https://medium.com/@marek.michalik/c-vs-rust-vs-go-performance-analysis-945ab749056c

Reason for packaging: Needed by hugo (>= 0.104.0)

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[gregor herrmann]

On Fri, 23 Sep 2022 01:03:28 +0200, Guillem Jover wrote:

> In the end nothing will match exactly, and we need to choose some
> terminology. In this case, as previously mentioned, «stanza» has the
> good properties of not usually applying to prose, being short, distinct
> from the other terms and the less ambiguous of them all. It also makes
> constructing sentences to describe things less cumbersome.

FWIW, and knowing this is not a popularity vote, as yet another
non-native speaker-with a different first language-I also like
"stanza" and agree with Guillem's arguments.

Additionally I'd like to mention that also some software uses this
term:

/usr/share/perl5/Debian/Control/Stanza
/usr/share/perl5/Debian/Control/Stanza.pm
/usr/share/perl5/Debian/Control/Stanza/Binary.pm
/usr/share/perl5/Debian/Control/Stanza/CommaSeparated.pm
/usr/share/perl5/Debian/Control/Stanza/Source.pm
/usr/share/perl5/Debian/Copyright/Stanza
/usr/share/perl5/Debian/Copyright/Stanza.pm
/usr/share/perl5/Debian/Copyright/Stanza/Files.pm
/usr/share/perl5/Debian/Copyright/Stanza/Header.pm
/usr/share/perl5/Debian/Copyright/Stanza/License.pm
/usr/share/perl5/Debian/Copyright/Stanza/OrSeparated.pm

(That's dh-make-perl and libdebian-copyright-perl. Also
libparse-debcontrol-perl talks about "stanzas" in its documentation.)
 

Cheers
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1020535: Some confusion regarding PCMCIA-related changes

[Cyril Brulebois]

Holger Wansing  (2022-09-23):
> Done in git.
> 
> Kibi: thanks for the heads-up. Good catch.

No worries, it was easy to spot since PCMCIA is not so common these days,
and I remembered having written some entry about it not so long ago. :)

Initially I even thought my changelog collection tool had failed to
include or exclude the right entries. :)

Thanks for the fix!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1020584: src:vkd3d: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: vkd3d
Version: 1.2-13
Severity: serious
Control: close -1 1.2-14
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1017106

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:vkd3d has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package didn't build 
successfully on ppc64el because of the unresolved issue in bug #1017106.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=vkd3d



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[gregor herrmann]

On Fri, 23 Sep 2022 10:13:50 -0700, Russ Allbery wrote:

> Pod::Man breaks here in a different way because it interprets the
> diaeresis as a German umlaut and assumes you can just stick an e after it
> if you don't have umlauts available.  My understanding is that this German
> umlaut conversion is only correct for ä, ö, and ü, not for ï (which I
> don't believe is a character in German, at least from some quick
> searching).

Your assumptions about German umlauts are correct :)

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1020535: Some confusion regarding PCMCIA-related changes

[Holger Wansing]

Control: tags -1 + pending

> I will revert the template change in hw-detect (this was indeed never 
> required :-(( )
> Sorry, mea culpa.

Done in git.

Kibi: thanks for the heads-up. Good catch.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1020582: kitty: CVE-2022-41322

[Salvatore Bonaccorso]

Source: kitty
Version: 0.21.2-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for kitty.

CVE-2022-41322[0]:
| In Kitty before 0.26.2, insufficient validation in the desktop
| notification escape sequence can lead to arbitrary code execution. The
| user must display attacker-controlled content in the terminal, then
| click on a notification popup.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41322
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41322
[1] 
https://github.com/kovidgoyal/kitty/commit/f05783e64d5fa62e1aed603e8d69aced5e49824f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1012404: Removal of llvm-toolchain-12

[Sylvestre Ledru]

Le 23/09/2022 à 19:18, Thorsten Alteholz a écrit :

Hi Sylvestre,


On 22.09.22 08:56, Sylvestre Ledru wrote:


aspectc++ is the last package depending on llvm toolchain 12


according to dak there are:
Checking reverse dependencies...
# Broken Depends:
crystal: crystal [amd64]
opencl-clang-12: libopencl-clang12
spirv-llvm-translator-12: libllvmspirvlib12
 llvm-spirv-12

# Broken Build-Depends:
aspectc++: libclang-12-dev
  llvm-12-dev
opencl-clang-12: clang-12
libclang-12-dev
libclang-cpp12-dev
llvm-12-dev
spirv-llvm-translator-12: libclang-12-dev
 llvm-12-dev


Those need to be removed first. Do you mind filing RM bugs?


oups, sorry, I missed that. I will
S

Bug#1020580: FTBFS: ruby3.1 needs network/DNS during tests

[Antonio Terceiro]

On Fri, Sep 23, 2022 at 06:37:02PM +0200, Sven Mueller wrote:
> Package: ruby3.1
> Version: 3.1.2-3
> 
> The package violates policy 4.9, namely:
> 
> For packages in the main archive, required targets must not attempt
> network access, except, via the loopback interface, to services on the
> build host that have been started by the build.
> 
> The relevant snippet from a build with restricted network (only
> internal Debian mirror available):
> 
>   1) Error:
> TestAddressResolve#test_socket_getnameinfo_domain_blocking:
> SocketError: getnameinfo: Temporary failure in name resolution
> /<>/test/fiber/test_address_resolve.rb:272:in `getnameinfo'
> /<>/test/fiber/test_address_resolve.rb:272:in `block
> (2 levels) in test_socket_getnameinfo_domain_blocking'
> 
> The test attempts to resolve example.com which our resolver returns a
> temporary error for.
> 
> The interesting part is: Why does it? If I read the source correctly,
> it *should* use a stub resolver? And if it doesn't use the stub: Why
> would the test succeed on the Debian autobuilders?
> So this might point at some more serious issue?

I can reproduce this failure either by going offline, or by emptying
/etc/resolv.conf while still online.


signature.asc
Description: PGP signature

Bug#1020397: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Steve,

there is a reverse dependency that needs to be taken care of:


Checking reverse dependencies...
# Broken Depends:
matrix-mirage: matrix-mirage

Dependency problem found.


In case this matters, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1012333: u-boot-menu: add support for using config fragments

[Vagrant Cascadian]

On 2022-09-23, Arnaud Ferraris wrote:
> On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian 
>  wrote:
>> On 2022-06-04, Jonas Smedegaard wrote:
>> > Quoting Arnaud Ferraris (2022-06-04 16:39:03)
>> >> Currently u-boot-menu makes use of a single configuration file
>> >> one has to edit in order to change the default options. It could
>> >> be useful to use config fragments containing only one (or more)
>> >> variables, so that different packages could change different
>> >> config options (for example, one fragment could modify the
>> >> default cmdline, while another one could change the DTB folder).
>> >
>> > Thanks, that sounds like a useful feature indeed.
>> >
>> > Seems more sensible for me, however, to implement this using debconf.
>> >
>> > Otherwise, installation and removal of a package would need to trigger
>> > u-boot-menu, and u-boot-menu would need to specially examine such
>> > cofigfile snippets to skip snippets belonging to removed but not purged
>> > packages.
>> 
>> Well, you could implement configuration files snippets directory outside
>> of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that),
>> which would avoid this problem. u-boot-menu could have a dpkg trigger
>> that for when files in this directory change.
>
> I quite like this approach, thanks for the suggestion!
>
> Do you think allowing both /etc/u-boot-menu.d (aimed solely at 
> end-users) and /usr/share/u-boot-menu/conf.d (for other packages and/or 
> derivatives), with a dpkg trigger only on the latter, would make sense? 
> Or should we aim only for the /usr/share... approach?

I think it's reasonable, though you'd have to encourage packages to
*not* use /etc/u-boot-menu*.d, maybe documenting it in
README.Debian...

I could see a preference order being /etc/default/u-boot which is
overidden by /usr/share/u-boot-menu/conf.d which is overridden by
/etc/u-boot-menu.d (or /etc/u-boot-menu/conf.d ?).

A fancy implementation might allow /etc to override /usr/share if the
filenames match, but that might be more complicated than it's
worth. Jonas knows I've fallen into that rabbit hole in packages of the
ancient past... :)


>> That seems a lot simpler than introducing the complexity of debconf
>> generated configuration files...
>
> Indeed, so far my experiments with debconf for solving this matter have 
> been sub-optimal at best.
>
> I'll update my patch in the next few days and submit it asap.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[Russ Allbery]

Russ Allbery  writes:

> naïvely (and naïve) are correct alternate spellings in English.  English
> historically uses a diaeresis to indicate that two adjacent vowels form
> separate syllables rather than a diphthong.  This is one of the only
> "native" accept marks in the English language, which otherwise only uses
> accept marks in loan words and tends to drop them.

I have no idea how I typed accept twice instead of accent, other than the
curse that any discussion of picky points of spelling and punctuation
contains spelling and punctuation errors.

-- 
Russ Allbery (r...@debian.org)  

Bug#1012404: Removal of llvm-toolchain-12

[Thorsten Alteholz]

Hi Sylvestre,


On 22.09.22 08:56, Sylvestre Ledru wrote:


aspectc++ is the last package depending on llvm toolchain 12


according to dak there are:
Checking reverse dependencies...
# Broken Depends:
crystal: crystal [amd64]
opencl-clang-12: libopencl-clang12
spirv-llvm-translator-12: libllvmspirvlib12
 llvm-spirv-12

# Broken Build-Depends:
aspectc++: libclang-12-dev
  llvm-12-dev
opencl-clang-12: clang-12
libclang-12-dev
libclang-cpp12-dev
llvm-12-dev
spirv-llvm-translator-12: libclang-12-dev
 llvm-12-dev


Those need to be removed first. Do you mind filing RM bugs?

  Thorsten

Bug#1020581: ITP: play.it-contrib -- ./play.it game scripts collection

[Antoine Le Gonidec]

Package: wnpp
Severity: wishlist
Owner: Antoine Le Gonidec 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-devel-ga...@lists.debian.org, deb...@dotslashplay.it

* Package name: play.it-contrib
  Version : 2022.09.23
  Upstream Author : Multiple ./play.it contributors 
* URL : https://forge.dotslashplay.it/play.it/games/
* License : BSD 2-Clause
  Programming Lang: Shell
  Description : ./play.it game scripts collection

./play.it is a packages generator for commercial games, that is already 
included in the contrib section of Debian repositories: 
https://wiki.debian.org/Games/PlayIt

Starting with its 2.14 release, its development has been splitted over two 
repositories: one including the library and main wrapper, following a cycle of 
stable feature releases and bugfix releases, and one including the collection 
of game scripts, with no stable releases.

Starting with its 2.16 release, the game scripts are no longer included in the 
main repository. That means that we can not update the Debian package to builds 
more recent than the current 2.15.1 without making it useless to most users.

By adding this package providing the main game scripts collection, we would 
unlock the ability to update the library and main wrapper up to the most 
current upstream build (2.18.0 at the time of writing this ITP).

I wish to maintain this new package under the Games team umbrella, while still 
planning to handle the updates myself most of the time. I hope the sponsor of 
the current play.it package (Phil Morrell) will be OK with sponsoring this 
package too, otherwise I hope someone else from the Games team would be willing 
to sponsor it.

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[Russ Allbery]

Vincent Lefevre  writes:

> "perldoc perlfaq4" gives in UTF-8 locales

> [...]
> The trick to this problem is avoiding accidental autovivification. If
> you want to check three keys deep, you might navely try this:

> where  is actually the EF byte as shown by the "less" pager.

This is an interesting bug.  I'm going to have to dig in a bit to figure
out what's going on here.  The POD source has naE<0xEF>vely, and for some
reason the output is ISO 8859-1 instead of UTF-8.

The underlying formatting module is Pod::Text, and it defaults to using
the same output character set as the input character set, which in this
case is not specified.  I think there may be an old default in play.

Pod::Man breaks here in a different way because it interprets the
diaeresis as a German umlaut and assumes you can just stick an e after it
if you don't have umlauts available.  My understanding is that this German
umlaut conversion is only correct for ä, ö, and ü, not for ï (which I
don't believe is a character in German, at least from some quick
searching).  I think this may be a very long-standing bug, although
there's a deeper problem that one cannot assume German umlaut rules.  It
depends very much on the source language.

> This should be encoded in UTF-8. However, this is a spelling mistake:
> contrary to French, there is no ï in English (at least, my dictionaries
> cannot find such a variant): naively.

naïvely (and naïve) are correct alternate spellings in English.  English
historically uses a diaeresis to indicate that two adjacent vowels form
separate syllables rather than a diphthong.  This is one of the only
"native" accept marks in the English language, which otherwise only uses
accept marks in loan words and tends to drop them.

It's common in modern English writing to drop the diaeresis, in part
because US English keyboards tend to make typing them difficult, so both
usages are now accepted, but there is a school of thought that the version
with the diaeresis is more correct.  The New Yorker famously insists on
diaereses in its house style, even going so far as to use coöperate when
every other publication has switched to cooperate:

https://www.merriam-webster.com/words-at-play/mary-norris-diaeresis

The other place you'll sometimes see diaereses in English is with proper
names such as Chloë or Zoë.

-- 
Russ Allbery (r...@debian.org)  

Bug#1020421: /usr/libexec/at-spi-bus-launcher: If I start some programs (i.e. gimp), system gets me out of the session and show me login again

[Timo Aaltonen]

Roberto kirjoitti 23.9.2022 klo 15.45:
Il giovedì 22 settembre 2022 15:00:02 CEST, Timo Aaltonen 
 ha scritto:



Samuel Thibault kirjoitti 22.9.2022 klo 15.38:
 > Control: reassign -1 mesa
 > Control: retitle -1 If I start some programs (i.e. gimp), system gets 
me out of the session and show me login again

 >
 > Roberto, le jeu. 22 sept. 2022 12:33:13 +, a ecrit:
 >> In the .old file I found:
 >> --
 >> [  1450.752] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not 
supported.

 >> Supported versions are: 1.10, 1.20, and 1.00 ES
 >> --
 >>
 >> I think this is the problem...
 >
 > That's a sign indeed. Thus reassigning to mesa for now.
 >
 > Samuel
 >

either use a wayland session, or install libgl1-amber-dri which has the
old i965 dri driver



--
t


Thank you Timo,

I use Mate and it doesn't support wayland

I'm trying to installlibgl1-amber-dri but I can't find it in debian repo 
and the only package I found is
libgl1-amber-dri_21.3.7-0ubuntu1_arm64.deb but it doesn't work with dpkg 
on debian

(it gives me " unknown compression for member 'control.tar.zst', giving up")

how can I install libgl1-amber-dri ?

Thanks in advance


sorry, my bad.. the upload to sid got rejected by the ftpadmin and needs 
to be fixed.


you can use the intel X driver in the meantime, that should be another 
workaround for this bug


--
t

Bug#996484: pushover does not start

[Jakub Wilk]

* Picca Frédéric-Emmanuel , 2021-10-14 18:32:

$ pushover
Using portable datadir: ./data


Apparently pushover tries to load its data from the ./data directory. If 
the directory is unrelated to the game, you get a crash.


The relevant code is:

  if (stat(portable_datadir.c_str(), ) == 0) {
  std::cout << "Using portable datadir: " << portable_datadir << std::endl;
  return portable_datadir;
  } else {
  std::cout << "Using system datadir: " << DATADIR << std::endl;
  return DATADIR;
  }

The Debian package should get rid of the "portable datadir" branch.
(But ideally this should be fixed upstream.)

--
Jakub Wilk

Bug#1020580: FTBFS: ruby3.1 needs network/DNS during tests

[Sven Mueller]

Package: ruby3.1
Version: 3.1.2-3

The package violates policy 4.9, namely:

For packages in the main archive, required targets must not attempt
network access, except, via the loopback interface, to services on the
build host that have been started by the build.

The relevant snippet from a build with restricted network (only
internal Debian mirror available):

  1) Error:
TestAddressResolve#test_socket_getnameinfo_domain_blocking:
SocketError: getnameinfo: Temporary failure in name resolution
/<>/test/fiber/test_address_resolve.rb:272:in `getnameinfo'
/<>/test/fiber/test_address_resolve.rb:272:in `block
(2 levels) in test_socket_getnameinfo_domain_blocking'

The test attempts to resolve example.com which our resolver returns a
temporary error for.

The interesting part is: Why does it? If I read the source correctly,
it *should* use a stub resolver? And if it doesn't use the stub: Why
would the test succeed on the Debian autobuilders?
So this might point at some more serious issue?

Cheers,
Sven

Bug#1019579: raku-json-unmarshal: trying to overwrite '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package rak

[Dominique Dumont]

On Mon, 12 Sep 2022 17:21:45 +0300 Adrian Bunk  wrote:
> Unpacking raku-json-unmarshal (0.10-1) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-Kxnez1/92-raku-json-
unmarshal_0.10-1_arm64.deb (--unpack):
>  trying to overwrite '/usr/lib/perl6/vendor/precomp/
C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/
C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package raku-json-
marshal 0.0.23-1
> ...

This bug is due to the fact that raku-json-fast package does not contain the 
precompiled file for JSON::Fast.

This package is a dependency of both raku-json-unmarshal and raku-json-
marshal. So the build process of both package recompile JSON::Fast and both 
ship the precompiled file. Hence the collision.

The issue with JSON::Fast precompilation is tracked there:

https://github.com/rakudo/rakudo/issues/4907

All the best

Bug#1020452: Re: Bug#1020452: kodi: 20 Nexus with upstream/Debian libdvdnav4 6.1.1 does not work - call to undefined functions

[Alban Browaeys]

On Fri, 23 Sep 2022 07:02:18 + Vasyl Gello 
wrote:
> Dear Alban,
> 
> Thanks for the PRs! Let me check all them tonight.
> Just FYI, to prepare release there will be some extra work on my side
(i.e rebase cdatetime patchset upstream
> and check if ffmpeg thumbnailer code also works with 5.1.1).


About the PR I found out the libcdio cannot eject when space in mount
directory is fixed upstream. I sent a MR to the debian maintainer
https://salsa.debian.org/debian/libcdio/-/merge_requests/6 .


> I dont have any DVDs at hand so I will need you to be my tester :)
> -- 

If I am out of reach there is a workaround, cdemu (still not packaged
for Debian :-/). cdemu upstream packages have debian build rules. But I
admit I use the ppa on debian
deb http://ppa.launchpad.net/cdemu/ppa/ubuntu jammy main

testcase:

ffmpeg -f lavfi -i color=size=1280x720:rate=25:color=black -f lavfi -i
anullsrc=channel_layout=stereo:sample_rate=44100  -target pal-dvd -
aspect 16:9 -t 10 output.mpeg
VIDEO_FORMAT=PAL dvdauthor -t -o ./dvd output.mpeg
VIDEO_FORMAT=PAL dvdauthor -T -o ./dvd output.mpeg 
genisoimage -o dvdvideo.iso -V A\ TEST -dvd-video dvd
cdemu load 0 dvdvideo.iso

then in /proc/mounts you will have:
/dev/sr0 /media/prahal/A\040TEST udf
ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8 0 0

It helps to test eject.
If you want to test with a video with image and sound, you can converty
any file to dvd mpeg with:
ffmpeg -i  -target pal-dvd -aspect 16:9
output.mpg

from
https://evilshit.wordpress.com/2015/08/10/how-to-create-a-video-dvd-with-command-line-tools/


Kind regards,
Alban

> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1020579: linux-image-5.19.0-1-amd64: Lenovo Thinkpad crashes after being removed from dockstation with a kernel segmentation fault

[Claudio Saavedra]

Package: src:linux
Version: 5.19.6-1
Severity: important
X-Debbugs-Cc: csaave...@igalia.com

Dear Maintainer,

Lenovo Thinkpad X1 Carbon 6th gen, removing it from its dock station and 
attempting to suspend causes a kernel segmentation fault shortly after, and the 
computer becomes irresponsive.

These are the kernel logs from the moment the computer is disconnected from the 
dock until it stops responding:

Sep 23 18:49:29 capablanca kernel: usb 3-6: USB disconnect, device number 4
Sep 23 18:49:29 capablanca kernel: usb 3-6.1: USB disconnect, device number 6
Sep 23 18:49:29 capablanca kernel: usb 3-6.2: USB disconnect, device number 7
Sep 23 18:49:29 capablanca kernel: usb 3-6.4: USB disconnect, device number 8
Sep 23 18:49:29 capablanca kernel: usb 3-6.4.1: USB disconnect, device number 12
Sep 23 18:49:29 capablanca kernel: usb 3-6.4.1.1: USB disconnect, device number 
13
Sep 23 18:49:29 capablanca kernel: thunderbolt 1-1: device disconnected
Sep 23 18:49:29 capablanca kernel: usb 2-3: USB disconnect, device number 2
Sep 23 18:49:29 capablanca kernel: usb 2-3.4: USB disconnect, device number 3
Sep 23 18:49:29 capablanca kernel: usb 2-3.4.4: USB disconnect, device number 4
Sep 23 18:49:29 capablanca kernel: usb 2-3.4.4.3: USB disconnect, device number 
5
Sep 23 18:49:29 capablanca kernel: thinkpad_acpi: undocked from hotplug port 
replicator
Sep 23 18:49:29 capablanca kernel: usb 3-6.4.4: USB disconnect, device number 9
Sep 23 18:49:29 capablanca kernel: usb 3-6.4.4.2: USB disconnect, device number 
10
Sep 23 18:49:29 capablanca kernel: usb 3-6.4.4.4: USB disconnect, device number 
11
Sep 23 18:49:29 capablanca kernel: pcieport :00:07.2: pciehp: Slot(0-1): 
Card not present
Sep 23 18:49:29 capablanca kernel: pcieport :50:00.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:04.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:03.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:00.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:01.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:02.0: Unable to change 
power state from D3cold to D0, device inaccessible
Sep 23 18:49:29 capablanca kernel: pcieport :51:03.0: Runtime PM usage 
count underflow!
Sep 23 18:49:29 capablanca kernel: pcieport :51:02.0: Runtime PM usage 
count underflow!
Sep 23 18:49:29 capablanca kernel: pcieport :51:01.0: Runtime PM usage 
count underflow!
Sep 23 18:49:29 capablanca kernel: pci_bus :52: busn_res: [bus 52] is 
released
Sep 23 18:49:29 capablanca kernel: pci_bus :53: busn_res: [bus 53-5e] is 
released
Sep 23 18:49:29 capablanca kernel: pci_bus :5f: busn_res: [bus 5f-6a] is 
released
Sep 23 18:49:29 capablanca kernel: pci_bus :6b: busn_res: [bus 6b-78] is 
released
Sep 23 18:49:29 capablanca kernel: pci_bus :79: busn_res: [bus 79] is 
released
Sep 23 18:49:29 capablanca kernel: pci_bus :51: busn_res: [bus 51-79] is 
released
Sep 23 18:49:30 capablanca kernel: rfkill: input handler enabled
Sep 23 18:49:30 capablanca kernel: BUG: kernel NULL pointer dereference, 
address: 0380
Sep 23 18:49:30 capablanca kernel: #PF: supervisor write access in kernel mode
Sep 23 18:49:30 capablanca kernel: #PF: error_code(0x0002) - not-present page
Sep 23 18:49:30 capablanca kernel: PGD 0 P4D 0 
Sep 23 18:49:30 capablanca kernel: Oops: 0002 [#1] PREEMPT SMP NOPTI
Sep 23 18:49:30 capablanca kernel: CPU: 0 PID: 92140 Comm: kworker/0:0 Not 
tainted 5.19.0-1-amd64 #1  Debian 5.19.6-1
Sep 23 18:49:30 capablanca kernel: Hardware name: LENOVO 20XW005PMX/20XW005PMX, 
BIOS N32ET80W (1.56 ) 08/29/2022
Sep 23 18:49:30 capablanca kernel: Workqueue: kacpi_notify 
acpi_os_execute_deferred
Sep 23 18:49:30 capablanca kernel: RIP: 0010:queue_work_on+0x15/0x50
Sep 23 18:49:30 capablanca kernel: Code: 0f 82 f4 fe ff ff e9 12 fc ff ff 66 2e 
0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 
44 00 00  48 0f ba 2a 00 73 17 45 31 c0 80 e7 02>
Sep 23 18:49:30 capablanca kernel: RSP: :a7ee448f7e38 EFLAGS: 00010006
Sep 23 18:49:30 capablanca kernel: RAX: 0206 RBX: 0206 
RCX: 
Sep 23 18:49:30 capablanca kernel: RDX: 0380 RSI: 98e4c0051000 
RDI: 2000
Sep 23 18:49:30 capablanca kernel: RBP: 0004 R08: 98e55619b840 
R09: 8040003f
Sep 23 18:49:30 capablanca kernel: R10:  R11: 0001 
R12: 98ebff630680
Sep 23 18:49:30 capablanca kernel: R13: 98ebff639f00 R14:  
R15: 98ebff639f55
Sep 23 18:49:30 capablanca kernel: FS:  () 
GS:98ebff60() 

Bug#1020535: Some confusion regarding PCMCIA-related changes

[Holger Wansing]

Control: retitle -1 hw-detect: change /etc/pcmciautils/ into /etc/pcmcia/ in 
template


Hi,

Colin Watson  wrote (Thu, 22 Sep 2022 23:17:01 +0100):
> On Thu, Sep 22, 2022 at 10:58:21PM +0200, Holger Wansing wrote:
> > Am 22. September 2022 04:09:42 MESZ schrieb Cyril Brulebois 
> > :
> > >A while back, this ended up in a release announcement
> > >(https://www.debian.org/devel/debian-installer/News/2021/20210802):
> > >
> > > - pcmciautils:
> > >+ Update /etc/pcmciautils/ dir to /etc/pcmcia/ in udeb (#980271).
> > >
> > >and I had a déjà-vu while adding this in the upcoming one
> > >(https://www.debian.org/devel/debian-installer/News/2022/20220922):
> > >
> > > - hw-detect:
> > >+ Replace /etc/pcmcia/ with /etc/pcmciautils/ (#980271).
> > >
> > >
> > >It would be great if someone could double-check what's going on here. :)
> > 
> > Everything fine!
> > That's correct, as it is.
> > 
> > pcmciautils (moreover its udeb) is the package, 
> > which installs this path, so it's the main target for
> > this change.
> 
> But it doesn't.  As of your change in pcmciautils 018-13, it uses
> /etc/pcmcia/ in the udeb as well.  /etc/pcmciautils/ is nonexistent and
> should not be referred to in any way.

Ahh, now I see.
I did not read kibi's mail carefully enough, to get the point:

The first change moves to /etc/pcmcia
while the second changes to /etc/pcmciautils.

This is of course not correct.
I will revert the template change in hw-detect (this was indeed never required 
:-(( )
Sorry, mea culpa.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1020575: pipewire-pulse: Sound card not detected

[Dylan Aïssi]

Hi,

Le ven. 23 sept. 2022 à 16:51, Christophe Lohr
 a écrit :
>
>
> The hardware is well detected by the system:
>
> But pipewire does not see the card (only the dummy pulseaudio sink):
>
> What can I do?
>

Please try with pipewire 0.3.58-2 in debian/unstable. This version
should fix this issue.


Best,
Dylan

Bug#1020577: RFP: warewulf4 -- operating system provisioning platform for Linux

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: warewulf4
  Version : 4.3.0
  Upstream Author : Gregory Kurtzer  and others from HPCng 
community
* URL : https://warewulf.org/
* License : BSD-3-clause
  Programming Lang: Go
  Description : operating system provisioning platform for Linux

Long description

Warewulf is an operating system provisioning platform for Linux that is
designed to produce secure, scalable, turnkey cluster deployments that
maintain flexibility and simplicity.
.
Since its initial release in 2001, Warewulf has become the most popular
open source and vendor-agnostic provisioning system within the global
HPC community. Warewulf is known for its massive scalability and simple
management of stateless (disk optional) provisioning.
.
Warewulf leverages a simple administrative model centralizing administration 
around virtual node images which are used to provision out to the cluster 
nodes. This means you can have hundreds or thousands of cluster nodes all 
booting and running on the same, identical virtual node file system image.

Additional information
==
This package would be useful to manage HPC (High Performance Computing)
clusters (or other kinds of clusters), where many nodes boot from a
limited number of system images. These OS images may be updated and/or
modified and then propagated to the associated nodes.

Please note that this is a complete rewrite in Go (with different
license) with respect to version 3 (see bug #919494). Hence,
this RFP bug report should not be merged with the other one.

Bug#613997: gnome-games: Backtrace

[Chris Lamb]

forwarded 613997 https://gitlab.gnome.org/GNOME/quadrapassel/-/issues/44
thanks

Jeremy Bicha wrote:

> Wow, you're replying today to a bug that hasn't been touched in a decade?

Oh sure — I mean, it seems like the same bug at least. :)

> Are you able to report this issue upstream?
> https://gitlab.gnome.org/GNOME/quadrapassel/-/issues

Indeed. In fact, it looks like someone beat me to it, but I've added
the details there (including that this was with 1:40.2-1).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Bill Allombert]

Source: sagemath
Severity: normal

Dear Sagemath team,

Please update sagemath so that it can work with both PARI 2.15.0 (in unstable)
and GAP 4.12.0 (in experimental).

I am not saying it is easy :)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

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

[Simon McVittie]

On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote:
> I also reworded the paragraph about backports to hopefully address
> Holger's reading.  It's just trying to say that backports uses aptitude in
> the normal way and doesn't do anything special to transform the
> alternative.

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

smcv

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: Bug#981405: man crypttab file conflict with systemd

[Christoph Anton Mitterer]

Am 23. September 2022 16:16:08 MESZ schrieb Luca Boccassi :
>We could patch systemd's to have a link to Debian's near the top, with
>a one-liner explanation? That should be easy to maintain and retain
>visibility?

That's the same what we already have the other way round...

Plus,  you'd need to patch it upstream and not just in Debian, otherwise people 
would find the upstream version all over Google, and not realise,  that this is 
likely far less relevant for them.


Also, it wouldn't change anything else of what it wrote before, about 
cryptsetup's crypttab manpage being typically much more relevant for debian 
users, much closer, to upstream, etc..


Why exactly should cryptsetup's manpage step back,  if that's still well 
maintained, more powerful and what's most probably more relevant for Debian 
dm-crypt users?
Just because some other distros do it different doesn't seem a good reason 
(while all Debian-based don't) , because Debian should probably do what's most 
relevant for its users.

Wouldn't be an option to rename the manpage upstream at systemd?
Seems to me that this would fit much better in usual systemd convention of 
naming most manpages systemd-* or systemd.*?
Since systemd is not cryptsetup, that would seem a much more natural choice.

To my best knowledge, Debian's cryptsetup was first in having crypttab (the 
oldest reference I've found is 16 years old,  while systemd was only startet 
some 10 years or so ago). So it rather belongs there and systemd should have 
taken care not to create incompatibilities.
Again, if Debian's cryptsetup/tab would be unmaintained... or far less 
important... sure, but since neither is the case, it would seem impolite to me 
if systemd insisted on its position (not that I'd imply that it would actually 
do so), just because they're overall bigger. 


At least IMHO at best cryptsetup upstream could really "claim" the manpage 
under having a higher precedence.
But I guess Milan would then take care not to become incompatible with the 
pre-existing crypttab of Debian.


Anyway, these were just my thoughts an in the end Jonas /Guilhem will 
decide and I'm actually off for some diving expedition (i.e. its not meant 
as rudeness if I don't answer anymore for a few weeks).

Best wishes, 
Chris.

Bug#973915: I think I'll give this a try

[Hilko Bengen]

control: retitle -1  ITP: elm -- Elm is a functional language that compiles to 
JavaScript

Version 0.19.1 of the Elm compiler requires just one extra
build-dependency (language-glsl) which is not yet in Debian.

The main remaining blocking issue is some apparent breakage in the
Debian Haskell tooling which I'll have to debug.

Cheers,
-Hilko

Bug#1020575: pipewire-pulse: Sound card not detected

[Christophe Lohr]

Package: pipewire-pulse
Version: 0.3.57-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,

The audio card of my ASUS K501N laptop by pipewire-pulse.

The hardware is well detected by the system:

# lspci -v -s 0:8
00:08.0 Audio device: NVIDIA Corporation MCP79 High Definition Audio (rev b1)
Subsystem: ASUSTeK Computer Inc. MCP79 High Definition Audio
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at fae78000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel


The card is also detected by alsa:

$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


But pipewire does not see the card (only the dummy pulseaudio sink):

$ pw-cli list-objects|grep -B6 Audio
id 31, type PipeWire:Interface:Node/3
object.serial = "33"
factory.id = "18"
client.id = "32"
node.description = "Dummy Output"
node.name = "auto_null"
media.class = "Audio/Sink"


What can I do?

Best regards
Christophe


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.57-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
pn  libspa-0.2-bluetooth  
ii  pulseaudio-utils  15.0+dfsg1-4+b1

-- no debconf information

Bug#1020290: apt incorrectly prefer usr-is-merged

[Craig Sanders]

On Fri, Sep 23, 2022 at 01:17:52PM +0200, Christoph Berg wrote:
> I think that was well beyond what could be acceptable for a Debian member to
> behave like. Have you considering finding other venues?

Have you considered minding your own fucking business?  You've all been
fucking dog-piling me since I first posted the fucking bug report, and I'm
fucking sick of it.

Obviously I've beens far too subtle for you fuckers to understand, so I'll
state it very plainly so that even a cretin can understand:

ALL OF YOU FUCK OFF AND STOP FUCKING HARASSING ME.

Bug#1017313: postfix: FTBFS: unistd.h:363:13: error: conflicting types for ‘closefrom’; have ‘void(int)’

[Antoine Beaupré]

Control: tags -1 +patch

On 2022-08-14 10:46:11, Lucas Nussbaum wrote:
>> In file included from ./vstream.h:22,
>>  from attr_print0.c:100:
>> /usr/include/unistd.h:363:13: error: conflicting types for ‘closefrom’; have 
>> ‘void(int)’
>>   363 | extern void closefrom (int __lowfd) __THROW;
>>   | ^
>> In file included from attr_print0.c:92:
>> ./sys_defs.h:1512:12: note: previous declaration of ‘closefrom’ with type 
>> ‘int(int)’
>>  1512 | extern int closefrom(int);
>>   |^
>> make: *** [Makefile:212: attr_print64.o] Error 1

Would this patch cut it? Not sure where to forward this upstream
either...

-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde
Description: fix closefrom declaration (Closes: #1017313)
  Some change in libc (or gcc?) broke compilation of Postfix in Debian
  bookworm (coming stable). It's unclear exactly when this definition
  changed, but it's clearly breaking builds in Debian right now.
  .
  Postfix uses this function only once, and discards the return value,
  so it's effectively void anyways.  
Author: Antoine Beaupré 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017313
Forwarded: no
Last-Update: 2022-09-23

--- postfix-3.6.4.orig/src/util/sys_defs.h
+++ postfix-3.6.4/src/util/sys_defs.h
@@ -1509,7 +1509,7 @@ extern int setsid(void);
 #endif
 
 #ifndef HAS_CLOSEFROM
-extern int closefrom(int);
+extern void closefrom(int);
 
 #endif
 

Bug#1009329: New upstream version 2.7.1 - Please package

[Amr Ibrahim]

Hello,

Please update keepassxc to latest version 2.7.1.

Best,
Amr

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: man crypttab file conflict with systemd

[Christoph Anton Mitterer]

Am 23. September 2022 16:06:25 MESZ schrieb Luca Boccassi :
>On Fri, 2022-09-23 at 15:50 +0200, Christoph Anton Mitterer wrote:
>The problem is, what's upstream and what's not.

Well, at least systemd certainly is not. It merely integrates cryptsetup.
*If* there's any upstream at all,  it's cryptsetup,  which already contains the 
manpage, and added its distro-specific extensions on documentation to it.
Since it even contains information about differences with systemd, it seems 
quite fine to me. 

> Everywhere else, the
>crypttab manpage shows something completely different from what it does
>on Debian. And that's a problem, it doesn't make the situation better
>but just adds confusion.
>If upstream cryptsetup shipped it, then you'd have been right, but it
>does not.

Well, Debian ain't everywhere else... and Debian users likely want the 
information that's most relevant to them, which for cryptsetup seems to be is 
extensions... at least for the foreseeable future.



>We no longer live in a world where each distro is a world in its own,
>completely insulated from everything else, and that's a good thing
>IMHO.

Sure, but still, distros are different and that's a good thing - otherwise we 
could just merge Debian into Feddebarchsuse.


> Also, information is not siloed either - if you google
>'crypttab', it's the upstream's systemd manpage that comes up.

Well but mere popularity in Google surely cannot be what decides.
What if Apple made some FLOSS cryptowallet software and calls its config 
crypttab. And when so and so many people use that, the cryptsetup manpage has 
to go away?
Or if other distris all use the name apt for something else... than Debian's 
APT manpage needs to rename?
That alone isn't a criteria which is in the sense of Debian users. 

I can understand if one wants to rename pre- existing stuff, like was done with 
chromium bsu package because that's far less important than the browser, but 
here? 

Cryptsetup's crypttab seems more close to what could be called upstream. It's 
well maintained, it's most likely much more used (in Debian and all 
derivatives) and it was there first. 

>If the
>Debian-specific one had a Debian-specific name, it would (should?) come
>up first when searched for specifically.

The "Debian-specific" isn't more or less specific than systemd's.

But apart from that, for that we have manpage in the system as well as a Debian 
manpage website.
If people take their documentation from just somewhere,  no one really can 
complain.
And IMO that's well established practise, since we have *many* manpage names 
which have different content just consider any C/POSIX library call, which 
may greatly differ from Linux with oder UNIXes.

Confusion would actually much bigger,  if the one from systemd would be taken 
as the "main" one,  cause I guess, unlike Debian's, it wouldn't get any 
pointers that things are incompatible with Debian - at least not in the 
upstream version (which again people might find on the Web,  even if they 
actually use Debian's cryptsetup).

Cheers, 
Chris

Bug#1020574: perl-doc: encoding issue / spelling mistake with "perldoc perlfaq4"

[Vincent Lefevre]

Package: perl-doc
Version: 5.34.0-5
Severity: minor

"perldoc perlfaq4" gives in UTF-8 locales

[...]
The trick to this problem is avoiding accidental autovivification. If
you want to check three keys deep, you might navely try this:

where  is actually the EF byte as shown by the "less" pager.

This should be encoded in UTF-8. However, this is a spelling mistake:
contrary to French, there is no ï in English (at least, my dictionaries
cannot find such a variant): naively.


-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-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 perl-doc depends on:
ii  perl  5.34.0-5

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base1.22.4-8
ii  man-db [man-browser]  2.10.2-3

-- no debconf information

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

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: man crypttab file conflict with systemd

[Luca Boccassi]

On Fri, 2022-09-23 at 15:06 +0100, Luca Boccassi wrote:
> On Fri, 2022-09-23 at 15:50 +0200, Christoph Anton Mitterer wrote:
> > Hey.
> > 
> > I'm not the maintainer,  so in the end it's of course not my decision...
> > 
> > 
> > 
> > Am 23. September 2022 12:04:16 MESZ schrieb Luca Boccassi 
> > :
> > > On Sat, 20 Mar 2021 20:45:11 +0100 Guilhem Moulin 
> > > wrote:
> > > We'd greatly appreciate it if you could please rename the downstream-
> > > specific one
> > 
> > ... but isn't that a rather unfortunate idea, effectively just confusing 
> > users of cryptsetup?
> > 
> > 
> > crypttab is not a canonical systemd configuration file - if anything at 
> > all, it's rather cryptsetup configuration file.
> > Also, the Debian crypttab specifics aren't just about initramfs... these 
> > options work for any "normal" mappings, too,... so I seems that placing 
> > them in some initramfs specific manpage wouldn't really fit either. 
> > 
> > 
> > Also most users in Debian will set up their dm- crypt volumes with that, 
> > which btw. and thanks to the efforts of Jonas and Guilhem works quite 
> > nicely and powerful.
> > 
> > 
> > At least last time I've checked systemd's cryptsetup integration hadn't 
> > support for "FDE"... and if that's still the case, one could anyway argue 
> > how serious it can be used - at least for some of the scenarios that DE 
> > protects against.
> > 
> > 
> > Last but not least, wasn't Debian's crypttab there first? Like much earlier 
> > as systemd?
> > 
> > 
> > 
> > So given these three points, why should cryptsetup's manpage change and not 
> > systemd's?
> > 
> > Just when systemd would claim the config file as its, which it clearly 
> > isn't, doesn't seem to be a valid reason. 
> > 
> > And don't get this wrong was systemd-bashing, I like it actually quite a 
> > lot,... but here I see rather just drawbacks, especially confusion amongst 
> > any current users as well as implying that systemd's crypttab would have 
> > any more official or canonical status than that of Debian's, which it has 
> > not. 
> > 
> > Doesn't systemd prefix most of its manpages with systemd? Wouldn't that be 
> > a much more satisfying option for both sides of users?
> > 
> > 
> > Best wishes, 
> > Chris
> 
> The problem is, what's upstream and what's not. Everywhere else, the
> crypttab manpage shows something completely different from what it does
> on Debian. And that's a problem, it doesn't make the situation better
> but just adds confusion.
> If upstream cryptsetup shipped it, then you'd have been right, but it
> does not.
> 
> We no longer live in a world where each distro is a world in its own,
> completely insulated from everything else, and that's a good thing
> IMHO. Also, information is not siloed either - if you google
> 'crypttab', it's the upstream's systemd manpage that comes up. If the
> Debian-specific one had a Debian-specific name, it would (should?) come
> up first when searched for specifically.

We could patch systemd's to have a link to Debian's near the top, with
a one-liner explanation? That should be easy to maintain and retain
visibility?

-- 
Kind regards,
Luca Boccassi


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

Bug#1020573: ITP: haskell-language-glsl -- GLSL abstract syntax tree, parser, and pretty-printer

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist
Control: block 973915 by -1

* Package name: haskell-language-glsl
  Version : 0.3.0
  Upstream Author : Minh Thu
* URL or Web page : 
* License : BSD-3-clause
  Description : GLSL abstract syntax tree, parser, and pretty-printer

This is a build-dependency for the Elm compiler (wnpp bug: #973915).

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: man crypttab file conflict with systemd

[Luca Boccassi]

On Fri, 2022-09-23 at 15:50 +0200, Christoph Anton Mitterer wrote:
> Hey.
> 
> I'm not the maintainer,  so in the end it's of course not my decision...
> 
> 
> 
> Am 23. September 2022 12:04:16 MESZ schrieb Luca Boccassi :
> > On Sat, 20 Mar 2021 20:45:11 +0100 Guilhem Moulin 
> > wrote:
> > We'd greatly appreciate it if you could please rename the downstream-
> > specific one
> 
> ... but isn't that a rather unfortunate idea, effectively just confusing 
> users of cryptsetup?
> 
> 
> crypttab is not a canonical systemd configuration file - if anything at all, 
> it's rather cryptsetup configuration file.
> Also, the Debian crypttab specifics aren't just about initramfs... these 
> options work for any "normal" mappings, too,... so I seems that placing them 
> in some initramfs specific manpage wouldn't really fit either. 
> 
> 
> Also most users in Debian will set up their dm- crypt volumes with that, 
> which btw. and thanks to the efforts of Jonas and Guilhem works quite nicely 
> and powerful.
> 
> 
> At least last time I've checked systemd's cryptsetup integration hadn't 
> support for "FDE"... and if that's still the case, one could anyway argue how 
> serious it can be used - at least for some of the scenarios that DE protects 
> against.
> 
> 
> Last but not least, wasn't Debian's crypttab there first? Like much earlier 
> as systemd?
> 
> 
> 
> So given these three points, why should cryptsetup's manpage change and not 
> systemd's?
> 
> Just when systemd would claim the config file as its, which it clearly isn't, 
> doesn't seem to be a valid reason. 
> 
> And don't get this wrong was systemd-bashing, I like it actually quite a 
> lot,... but here I see rather just drawbacks, especially confusion amongst 
> any current users as well as implying that systemd's crypttab would have any 
> more official or canonical status than that of Debian's, which it has not. 
> 
> Doesn't systemd prefix most of its manpages with systemd? Wouldn't that be a 
> much more satisfying option for both sides of users?
> 
> 
> Best wishes, 
> Chris

The problem is, what's upstream and what's not. Everywhere else, the
crypttab manpage shows something completely different from what it does
on Debian. And that's a problem, it doesn't make the situation better
but just adds confusion.
If upstream cryptsetup shipped it, then you'd have been right, but it
does not.

We no longer live in a world where each distro is a world in its own,
completely insulated from everything else, and that's a good thing
IMHO. Also, information is not siloed either - if you google
'crypttab', it's the upstream's systemd manpage that comes up. If the
Debian-specific one had a Debian-specific name, it would (should?) come
up first when searched for specifically.

-- 
Kind regards,
Luca Boccassi


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

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: man crypttab file conflict with systemd

[Christoph Anton Mitterer]

Hey.

I'm not the maintainer,  so in the end it's of course not my decision...



Am 23. September 2022 12:04:16 MESZ schrieb Luca Boccassi :
>On Sat, 20 Mar 2021 20:45:11 +0100 Guilhem Moulin 
>wrote:
>We'd greatly appreciate it if you could please rename the downstream-
>specific one

... but isn't that a rather unfortunate idea, effectively just confusing users 
of cryptsetup?


crypttab is not a canonical systemd configuration file - if anything at all, 
it's rather cryptsetup configuration file.
Also, the Debian crypttab specifics aren't just about initramfs... these 
options work for any "normal" mappings, too,... so I seems that placing them in 
some initramfs specific manpage wouldn't really fit either. 


Also most users in Debian will set up their dm- crypt volumes with that, which 
btw. and thanks to the efforts of Jonas and Guilhem works quite nicely and 
powerful.


At least last time I've checked systemd's cryptsetup integration hadn't support 
for "FDE"... and if that's still the case, one could anyway argue how serious 
it can be used - at least for some of the scenarios that DE protects against.


Last but not least, wasn't Debian's crypttab there first? Like much earlier as 
systemd?



So given these three points, why should cryptsetup's manpage change and not 
systemd's?

Just when systemd would claim the config file as its, which it clearly isn't, 
doesn't seem to be a valid reason. 

And don't get this wrong was systemd-bashing, I like it actually quite a 
lot,... but here I see rather just drawbacks, especially confusion amongst any 
current users as well as implying that systemd's crypttab would have any more 
official or canonical status than that of Debian's, which it has not. 

Doesn't systemd prefix most of its manpages with systemd? Wouldn't that be a 
much more satisfying option for both sides of users?


Best wishes, 
Chris

Bug#1019725: new grep 3.8 causes regressions in test suite and autopkgtests of other packages

[Santiago Ruano Rincón]

Control: tags -1 + upstream
Control: severity -1 important
Control: forwarded -1 https://savannah.gnu.org/patch/index.php?10282

Increasing the severity since this is a FTBFS bug. I'd say it is even
serious, but since it is being caused by grep, I am limiting the
increase to important for now.

On Wed, 14 Sep 2022 09:10:37 +0200 Jochen Sprickerhof  
wrote:
> Package: libtool
> Version: 2.4.7-4
> Tags: patch
> 
> Hi,
> 
> the new grep in unstable causes a FTBFS in libtool:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/libtool.html
> 
> with a proposed upstream patch:
> 
> https://lists.gnu.org/archive/html/libtool-patches/2022-09/msg0.html
> 
> And it breaks autopkgtests of unrelated packages like:
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dpkg/26032114/log.gz
> 
> proposed upstream patch:
> 
> https://lists.gnu.org/archive/html/libtool-patches/2022-09/msg1.html
> 

grep upstream proposes a more complete patch for libtool here:
https://savannah.gnu.org/patch/index.php?10282
This patch fixes the problematic patterns in libtool, other than in the
tests. Attached you can find a refreshed patch against 2.4.7-4 (current
version in unstable).

As listed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019724#52
there are 4235 debian packages that exhibit the "stray \" warning in
their build logs. I can suppose most of them relates to libtool.

I've applied the patch to libtool, used it to rebuild grep, and I can
confirm the warnings disappeared.

> I've asked the grep maintainer to silence the warning in #1019724 but
> maybe would still be great to fix this.

While I think silencing these "stray \" warnings in debian's grep is OK
for now, fixing this bug in libtool is the proper solution in the long
term.

FTR, this is some grep upstream's input about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019724#62

Please, consider applying the patch.

Cheers,

 -- Santiago
From bb6e526657e9c03dd3be954123c091a001c06811 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 19 Sep 2022 13:22:53 -0700
Subject: [PATCH 1/2] libtool: port to GNU grep 3.8
Origin: other, https://savannah.gnu.org/patch/index.php?10282
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019725
Last-Update: 2022-09-22

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Do not use \- in a BRE or ERE,
as this produces undefined results that GNU grep 3.8 warns about.
Use [-] instead.
* tests/link-order.at (Link order test): Similarly, do not use
\/ in an ERE; use / instead.
---
 m4/libtool.m4   | 12 ++--
 tests/link-order.at |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

Index: libtool/m4/libtool.m4
===
--- libtool.orig/m4/libtool.m4
+++ libtool/m4/libtool.m4
@@ -6469,7 +6469,7 @@ if test yes != "$_lt_caught_CXX_error";
   # Commands to make compiler produce verbose output that lists
   # what "hidden" libraries, object files and flags are used when
   # linking a shared library.
-  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP " \-L"'
+  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP "[[-]]L"'
 
 else
   GXX=no
@@ -6845,7 +6845,7 @@ if test yes != "$_lt_caught_CXX_error";
 # explicitly linking system object files so we need to strip them
 # from the output so that they don't get included in the library
 # dependencies.
-output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $EGREP " \-L"`; list= ; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; func_echo_all "$list"'
+output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $EGREP "[[-]]L"`; list= ; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; func_echo_all "$list"'
 ;;
   *)
 if test yes = "$GXX"; then
@@ -6910,7 +6910,7 @@ if test yes != "$_lt_caught_CXX_error";
 	# explicitly linking system object files so we need to strip them
 	# from the output so that they don't get included in the library
 	# dependencies.
-	output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $GREP " \-L"`; list= ; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; func_echo_all "$list"'
+	output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $GREP "[[-]]L"`; list= ; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; func_echo_all "$list"'
 	;;
   *)
 	if test yes = "$GXX"; then
@@ -7249,7 +7249,7 @@ if test yes != 

Bug#1020572: lintian-brush shouldn't add a build dependency to pkg-js-tools

[Yadd]

Package: lintian-brush
Version: 0.130
Severity: important

Hi,

now lintian-brush replaces build dependency to dh-sequence-nodejs by
"pkg-js-tools | dh-sequence-nodejs". This change is wrong:
dh-sequence-nodejs is provided by dh-nodejs, not pkg-js-tools (which has
a lot of dependencies and depends on dh-nodejs).

Question, why this change, is dh-sequence-nodejs not enough ?

Cheers,
Yadd

Bug#1020571: cppimport's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:cppimport
Version: 22.05.11-1
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cppimport/26322071/log.gz

[...]
autopkgtest [07:47:50]:  summary
unittests3   FAIL stderr: 
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning: 
Distutils was imported before Setuptools, but importing Setuptools also replaces 
the `distutils` module in `sys.modules`. This may lead to undesirable behaviors 
or errors. To avoid these issues, avoid using distutils directly, ensure that 
setuptools is installed in the traditional way (e.g. not an editable install), 
and/or make sure that setuptools is always imported before distutils.

Bug#1020570: yoyo's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:yoyo
Version: 7.3.2+dfsg1-2
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/y/yoyo/26325726/log.gz

[...]
self = 

def get_original(self):
target = self.getter()
name = self.attribute

original = DEFAULT
local = False

try:
original = target.__dict__[name]
except (AttributeError, KeyError):
original = getattr(target, name, DEFAULT)
else:
local = True

if name in _builtins and isinstance(target, ModuleType):
self.create = True

if not self.create and original is DEFAULT:
>   raise AttributeError(
"%s does not have the attribute %r" % (target, name)
)
E   AttributeError: 'pkg_resources._vendor.pyparsing.common.pyparsing_common'> does not have the 
attribute 'datetime'


/usr/lib/python3/dist-packages/mock/mock.py:1387: AttributeError
__ TestNewMigration.test_it_calls_post_create_command __

self = 
tmpdir = local('/tmp/pytest-of-debci/pytest-0/test_it_calls_post_create_comm0')

def test_it_calls_post_create_command(self, tmpdir):
self.writeconfig(post_create_command="/bin/ls -l {} {}")
>   with frozendate.freeze(2001, 1, 1):

/tmp/autopkgtest-lxc.weskrs7o/downtmp/build.pgf/src/yoyo/tests/test_cli_script.py:522: 


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3.10/contextlib.py:135: in __enter__
return next(self.gen)
/tmp/autopkgtest-lxc.weskrs7o/downtmp/build.pgf/src/debian/tests/frozendate.py:251: 
in freeze

_patch(modules, when)
/tmp/autopkgtest-lxc.weskrs7o/downtmp/build.pgf/src/debian/tests/frozendate.py:196: 
in _patch

patches = sum((_patch_module(m, relnow) for m in modules), [])
/tmp/autopkgtest-lxc.weskrs7o/downtmp/build.pgf/src/debian/tests/frozendate.py:196: 
in 

patches = sum((_patch_module(m, relnow) for m in modules), [])
/tmp/autopkgtest-lxc.weskrs7o/downtmp/build.pgf/src/debian/tests/frozendate.py:169: 
in _patch_module

p.start()
/usr/lib/python3/dist-packages/mock/mock.py:1550: in start
result = self.__enter__()
/usr/lib/python3/dist-packages/mock/mock.py:1414: in __enter__
original, local = self.get_original()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 

def get_original(self):
target = self.getter()
name = self.attribute

original = DEFAULT
local = False

try:
original = target.__dict__[name]
except (AttributeError, KeyError):
original = getattr(target, name, DEFAULT)
else:
local = True

if name in _builtins and isinstance(target, ModuleType):
self.create = True

if not self.create and original is DEFAULT:
>   raise AttributeError(
"%s does not have the attribute %r" % (target, name)
)
E   AttributeError: 'pkg_resources._vendor.pyparsing.common.pyparsing_common'> does not have the 
attribute 'datetime'


/usr/lib/python3/dist-packages/mock/mock.py:1387: AttributeError

Bug#1020569: python-pbr's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:python-pbr
Version: 5.8.1-2
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pbr/26325724/log.gz

[...]
==
FAIL: pbr.tests.test_packaging.TestPEP517Support.test_pep_517_support
pbr.tests.test_packaging.TestPEP517Support.test_pep_517_support
--
testtools.testresult.real._StringException: traceback-1: {{{
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
  File 
"/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/test_packaging.py", 
line 193, in _setUp

self.useFixture(base.CapturedSubprocess(
  File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 257, in 
useFixture

fixture.setUp()
  File "/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/base.py", 
line 182, in setUp

proc = subprocess.Popen(*self.args, **self.kwargs)
  File "/usr/lib/python3.10/subprocess.py", line 969, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.10/subprocess.py", line 1845, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmplt8wfzfl/tmpomttwh8z/bin/python'


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 208, in setUp
raise SetupError(details)
fixtures.fixture.SetupError: {}
}}}

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 197, in setUp
self._setUp()
  File 
"/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/test_packaging.py", 
line 193, in _setUp

self.useFixture(base.CapturedSubprocess(
  File "/usr/lib/python3/dist-packages/fixtures/fixture.py", line 257, in 
useFixture

fixture.setUp()
  File "/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/base.py", 
line 182, in setUp

proc = subprocess.Popen(*self.args, **self.kwargs)
  File "/usr/lib/python3.10/subprocess.py", line 969, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.10/subprocess.py", line 1845, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmplt8wfzfl/tmpomttwh8z/bin/python'



==
FAIL: pbr.tests.test_wsgi.TestWsgiScripts.test_wsgi_script_install
pbr.tests.test_wsgi.TestWsgiScripts.test_wsgi_script_install
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/test_wsgi.py", 
line 55, in test_wsgi_script_install

self._check_wsgi_install_content(stdout)
  File 
"/tmp/autopkgtest-lxc.qnyxzolq/downtmp/build.pCk/src/pbr/tests/test_wsgi.py", 
line 133, in _check_wsgi_install_content

script_txt = open(cmd_filename, 'r').read()
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmp8zrthiwx/tmpm8xted4s/bin/pbr_test_wsgi'



--
Ran 215 tests in 26.973s

FAILED (failures=2, skipped=24)

Bug#1020568: pocketsphinx-python's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:pocketsphinx-python
Version: 1:0.1.15-2
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pocketsphinx-python/26322074/log.gz

[...]
autopkgtest [07:48:02]: test tests: [---
patching file setup.py
  configure with PYTHON 3.10 ==
/tmp/autopkgtest-lxc.wiu8e7yd/downtmp/build.lPV/src/setup.py:7: 
DeprecationWarning: The distutils package is deprecated and slated for removal 
in Python 3.12. Use setuptools or check PEP 632 for potential alternatives

  from distutils import log
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning: 
Distutils was imported before Setuptools, but importing Setuptools also replaces 
the `distutils` module in `sys.modules`. This may lead to undesirable behaviors 
or errors. To avoid these issues, avoid using distutils directly, ensure that 
setuptools is installed in the traditional way (e.g. not an editable install), 
and/or make sure that setuptools is always imported before distutils.

  warnings.warn(
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning: 
Setuptools is replacing distutils.

  warnings.warn("Setuptools is replacing distutils.")
error: Multiple top-level packages discovered in a flat-layout: ['deps', 'swig', 
'debian', 'pocketsphinx_disabled'].


To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.

If you are trying to create a single distribution with multiple packages
on purpose, you should not rely on automatic discovery.
Instead, consider the following options:

1. set up custom discovery (`find` directive with `include` or `exclude`)
2. use a `src-layout`
3. explicitly set `py_modules` or `packages` with a list of names

To find more information, look for "package discovery" on setuptools docs.

Bug#1008601: mirror submission for ftp.psnc.pl

[Julien Cristau]

Hi Rafal,

On Fri, Sep 23, 2022 at 03:00:36PM +0200, PSNC Mirrors Team wrote:
> Hi,
> 
> Our mirror was updating twice a day.
> According to the recommendation, we changed to run every hour with a random
> offset of 1-60 minutes.
> We also changed from ftpsync to ftpsync-cron.
> If you have any more comments, let us know about it, we will correct it.
> 
Thank you :)

> It is known perhaps where we could see the statuses of mirrors?
> On https://people.debian.org/~jcristau/mirror-status/mirror-status.html
> shows our server under the old name ftp.man.poznan.pl where the current one
> we have now is ftp.psnc.pl and on other sites we are not there, such as:
>  - https://mirror-master.debian.org/status/mirror-status.html
>  - https://www.debian.org/mirror/list
> What is the difference between these sites?
> 
https://people.debian.org/~jcristau/mirror-status/mirror-status.html was
an old static snapshot of the status page from 5 years ago, I've now
deleted it.
https://mirror-master.debian.org/status/mirror-status.html is updated
every 20 minutes or so; I've now added the mirror to the list it uses as
source, so it should show up soon.
https://www.debian.org/mirror/list is updated regularly, by filtering
the source list and removing mirrors with a low "score", as seen by the
mirror-status page.  So for new mirrors it takes a few days for the
score to reach the threshold.

Cheers,
Julien

> Greetings
> Rafal Wisniewski
> PSNC Mirror Team
> 
> On 9/17/22 15:39, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > Hi,
> > 
> > o It seems your mirror is not up to date, having last updated on Fri, 16 
> > Sep 2022 20:56:25 +
> > o The latest ftpsync versions come with a wrapper script called
> >ftpsync-cron, which is intended to be run out of cron every hour or so
> >(at a randomish offset).  The script monitors your upstream mirror,
> >and if there was an update triggers a full sync using ftpsync.
> >You might want to give it a try.
> > 
> >NOTE: This requires having your upstream mirror name set correctly to
> >a specific mirror which is also correctly configured (and thus has a
> >tracefile in /debian/project/trace with its name).
> > 
> > Can you double check on this?  (The debian archive updates roughly every
> > six hours, and we expect mirrors to follow that frequency.)
> > 
> > Cheers,
> > Julien
> > 
> > On Tue, Mar 29, 2022 at 11:29:44AM +, PSNC mirrors team wrote:
> > > Package: mirrors
> > > Severity: wishlist
> > > User: mirr...@packages.debian.org
> > > Usertags: mirror-submission
> > > 
> > > Submission-Type: new
> > > Site: ftp.psnc.pl
> > > Type: leaf
> > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > > Archive-http: /debian/
> > > Maintainer: PSNC mirrors team 
> > > Country: PL Poland
> > > Location: Poznań
> > > Sponsor:  Poznan Supercomputing and Networking Center https://psnc.pl/
> > > 
> > > 
> > > 
> > > 
> > > Trace Url: http://ftp.psnc.pl/debian/project/trace/
> > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp-master.debian.org
> > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp.psnc.pl
> 

Bug#1020567: meson's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:meson
Version: 0.63.2-1
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/26322073/log.gz

[...]
autopkgtest [07:51:16]: test exhaustive: [---
Meson build system 0.63.2 Project and Unit Tests
System information.
Architecture: ('64bit', 'ELF')
Machine: x86_64
Platform: Linux
Processor:
System: Linux


test_meson_exe_windows (__main__.CommandTests) ... skipped 'NOT IMPLEMENTED'
test_meson_installed (__main__.CommandTests) ... 
/usr/lib/python3/dist-packages/setuptools/config/expand.py:65: EncodingWarning: 
'encoding' argument not specified

  with open(spec.origin) as strm:  # type: ignore
/usr/lib/python3/dist-packages/setuptools/config/setupcfg.py:508: 
SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use 
license_files instead.

  warnings.warn(msg, warning_class)
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip 
and other standards-based tools.

  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:146: 
EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and 
pip and other standards-based tools.

  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:584: 
EncodingWarning: 'encoding' argument not specified

  f = open(pth_file, 'w')
TEST FAILED: /tmp/tmprcqr8ahm/prefix/local/lib/python3.10/dist-packages/ does 
NOT support .pth files

bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

/tmp/tmprcqr8ahm/prefix/local/lib/python3.10/dist-packages/

and your PYTHONPATH environment variable currently contains:

'/tmp/tmprcqr8ahm/prefix/lib/python3.10/site-packages/'

Here are some of your options for correcting the problem:

* You can choose a different installation directory, i.e., one that is
  on PYTHONPATH or supports .pth files

* You can add the installation directory to the PYTHONPATH environment
  variable.  (It must then also be on PYTHONPATH whenever you run
  Python and want to use the package(s) you are installing.)

* You can set up the installation directory to support ".pth" files by
  using one of the approaches described here:


https://setuptools.pypa.io/en/latest/deprecated/easy_install.html#custom-installation-locations


Please make the appropriate changes for your system and try again.
/usr/lib/python3/dist-packages/setuptools/_distutils/text_file.py:118: 
EncodingWarning: 'encoding' argument not specified

  self.file = open(self.filename, errors=self.errors)
zip_safe flag not set; analyzing archive contents...
mesonbuild.__pycache__.mdevenv.cpython-310: module references __file__
mesonbuild.__pycache__.minstall.cpython-310: module references __file__
/usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py:352: 
EncodingWarning: 'encoding' argument not specified

  f = open(fn, 'wt')
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:871: 
EncodingWarning: 'encoding' argument not specified

  with open(target, "w" + mode) as f:
FAIL

Bug#1020566: git-buildpackage's autopkg tests fail with setuptools 65

[Matthias Klose]

Package: src:git-buildpackage
Version: 0.9.28
Severity: serious
Tags: sid bookworm

https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-buildpackage/26322072/log.gz

[...]
running install_scripts
creating 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin
copying build/scripts-3.10/gbp-builder-mock -> 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin
copying build/scripts-3.10/git-pbuilder -> 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin
changing mode of 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin/gbp-builder-mock 
to 755
changing mode of 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin/git-pbuilder 
to 755
Installing gbp script to 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/local/bin
+ find /tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch -name 
__pycache__

+ xargs -r rm -r
+ mkdir -p 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/share/git-buildpackage
+ mv 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/bin/gbp-builder-mock 
/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/share/git-buildpackage/
mv: cannot stat 
'/tmp/tmp.weIfNHqOje/BUILDROOT/git-buildpackage-0.9.28-0.noarch/usr/bin/gbp-builder-mock': 
No such file or directory

error: Bad exit status from /var/tmp/rpm-tmp.9gx9Va (%install)
Bad exit status from /var/tmp/rpm-tmp.9gx9Va (%install)

RPM build errors:
gbp:error: 'rpmbuild '-D%__python3 /usr/bin/python3' '-D%__python 
/usr/bin/python3' '-D%python_sitelib %(%{__python3} -Ic "from sysconfig import 
get_path; print(get_path('"'"'platlib'"'"'))")' '-D%_arch noarch' -bb --nodeps 
--define '_topdir /tmp/tmp.weIfNHqOje' --define '_specdir %_topdir/SPECS' 
--define '_sourcedir %_topdir/SOURCES' 
/tmp/tmp.weIfNHqOje/SPECS/git-buildpackage.spec' failed: it exited with 1

+ cleanup
+ [ -z /tmp/tmp.weIfNHqOje ]
+ rm -rf /tmp/tmp.weIfNHqOje

Bug#1013876: Please close if fixed to migrate to testing

[Amr Ibrahim]

On Mon, 27 Jun 2022 07:21:33 +0200 Bruno Kleinert 
wrote:

> thanks for the report. Something else in 1.8.0 is bugging me that may
> be related to upstream's jQuery removal. I'm expecting upstream may
> release 1.8.1 soonish.

Hello,

Please close this bug if fixed in unstable to migrate the package to
testing.

Best,
Amr

Bug#1013616: Thanks

[Anton Gladky]

Thanks, Jonathan, for the patch!


Anton

Bug#1008601: mirror submission for ftp.psnc.pl

[PSNC Mirrors Team]

Hi,

Our mirror was updating twice a day.
According to the recommendation, we changed to run every hour with a 
random offset of 1-60 minutes.

We also changed from ftpsync to ftpsync-cron.
If you have any more comments, let us know about it, we will correct it.

It is known perhaps where we could see the statuses of mirrors?
On https://people.debian.org/~jcristau/mirror-status/mirror-status.html 
shows our server under the old name ftp.man.poznan.pl where the current 
one we have now is ftp.psnc.pl and on other sites we are not there, such as:

 - https://mirror-master.debian.org/status/mirror-status.html
 - https://www.debian.org/mirror/list
What is the difference between these sites?

Greetings
Rafal Wisniewski
PSNC Mirror Team

On 9/17/22 15:39, Julien Cristau wrote:

Control: tag -1 moreinfo

Hi,

o It seems your mirror is not up to date, having last updated on Fri, 16 Sep 
2022 20:56:25 +
o The latest ftpsync versions come with a wrapper script called
   ftpsync-cron, which is intended to be run out of cron every hour or so
   (at a randomish offset).  The script monitors your upstream mirror,
   and if there was an update triggers a full sync using ftpsync.
   You might want to give it a try.

   NOTE: This requires having your upstream mirror name set correctly to
   a specific mirror which is also correctly configured (and thus has a
   tracefile in /debian/project/trace with its name).

Can you double check on this?  (The debian archive updates roughly every
six hours, and we expect mirrors to follow that frequency.)

Cheers,
Julien

On Tue, Mar 29, 2022 at 11:29:44AM +, PSNC mirrors team wrote:

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.psnc.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: PSNC mirrors team 
Country: PL Poland
Location: Poznań
Sponsor:  Poznan Supercomputing and Networking Center https://psnc.pl/




Trace Url: http://ftp.psnc.pl/debian/project/trace/
Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp-master.debian.org
Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp.psnc.pl

Bug#1012333: u-boot-menu: add support for using config fragments

[Arnaud Ferraris]

On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian 
 wrote:

On 2022-06-04, Jonas Smedegaard wrote:
> Quoting Arnaud Ferraris (2022-06-04 16:39:03)
>> Currently u-boot-menu makes use of a single configuration file
>> one has to edit in order to change the default options. It could
>> be useful to use config fragments containing only one (or more)
>> variables, so that different packages could change different
>> config options (for example, one fragment could modify the
>> default cmdline, while another one could change the DTB folder).
>
> Thanks, that sounds like a useful feature indeed.
>
> Seems more sensible for me, however, to implement this using debconf.
>
> Otherwise, installation and removal of a package would need to trigger
> u-boot-menu, and u-boot-menu would need to specially examine such
> cofigfile snippets to skip snippets belonging to removed but not purged
> packages.

Well, you could implement configuration files snippets directory outside
of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that),
which would avoid this problem. u-boot-menu could have a dpkg trigger
that for when files in this directory change.


I quite like this approach, thanks for the suggestion!

Do you think allowing both /etc/u-boot-menu.d (aimed solely at 
end-users) and /usr/share/u-boot-menu/conf.d (for other packages and/or 
derivatives), with a dpkg trigger only on the latter, would make sense? 
Or should we aim only for the /usr/share... approach?




That seems a lot simpler than introducing the complexity of debconf
generated configuration files...


Indeed, so far my experiments with debconf for solving this matter have 
been sub-optimal at best.


I'll update my patch in the next few days and submit it asap.

Cheers,
Arnaud




live well,
  vagrant

Bug#1020421: /usr/libexec/at-spi-bus-launcher: If I start some programs (i.e. gimp), system gets me out of the session and show me login again

[Roberto]

   Il giovedì 22 settembre 2022 15:00:02 CEST, Timo Aaltonen 
 ha scritto:  
 
 Samuel Thibault kirjoitti 22.9.2022 klo 15.38:
> Control: reassign -1 mesa
> Control: retitle -1 If I start some programs (i.e. gimp), system gets me out 
> of the session and show me login again
> 
> Roberto, le jeu. 22 sept. 2022 12:33:13 +, a ecrit:
>> In the .old file I found:
>> --
>> [  1450.752] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not 
>> supported.
>> Supported versions are: 1.10, 1.20, and 1.00 ES
>> --
>>
>> I think this is the problem...
> 
> That's a sign indeed. Thus reassigning to mesa for now.
> 
> Samuel
> 

either use a wayland session, or install libgl1-amber-dri which has the 
old i965 dri driver


-- 
t

Thank you Timo,
I use Mate and it doesn't support wayland

I'm trying to install libgl1-amber-dri but I can't find it in debian repo and 
the only package I found islibgl1-amber-dri_21.3.7-0ubuntu1_arm64.deb but it 
doesn't work with dpkg on debian 
(it gives me " unknown compression for member 'control.tar.zst', giving up")
how can I install libgl1-amber-dri ?
Thanks in advance
r




  

Bug#1020565: Redundant atop log rotation

[IB Development Team]

Package: atop
Version: 2.6.0-2

Installing atop in Debian 11 adds atop-rotate.service that restarts atop 
at midnight and rotates its log.


Same task is still fired using /etc/cron.d/atop when systemd is present...

0 0 * * * root [ -d "/run/systemd/system" ] && systemctl restart atop

...and atop is restarted+rotated twice -> races may occur.

Please consider:

* removing above line from /etc/cron.d/atop,

* randomizing rotation schedule to avoid resource congestions (all 
systems rotating in same time).


Randomization docs: 
https://www.freedesktop.org/software/systemd/man/systemd.timer.html#RandomizedDelaySec=


Randomization example:

[Timer]
AccuracySec=10s
RandomizedDelaySec=600s
FixedRandomDelay=true

--

Regards,
Paweł Bogusławski

IB Development Team
E:d...@ib.pl

Bug#1020564: transition: coq-simple-io

[julien . puydt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: jpu...@debian.org
X-Debbugs-Cc: Debian OCaml Maintainers


Hi,

there is a new version of coq-simple-io ; it requires re-building
another package:

 nmu coq-quickchick_1.6.4-2+b1 . ANY . -m 'Rebuild because of upload of
coq-simple-io=1.8.0-1'
 dw coq-quickchick_1.6.4-2+b1 . ANY . -m 'coq-simple-io >= 1.8.0-1'


I'm waiting for your approval to upload coq-simple-io 1.8.0-1.

Cheers,

J.Puydt

Bug#1020563: ifupdown2: ifreload -a sets all veth interfaces DOWN.

[Karl Heinz Grube]

Package: ifupdown2
Version: 3.0.0-1
Severity: normal

Dear Maintainer,


When I use ifupdown2 and have lxc containers running on the system (using 
VETH), I lose all connectivity to them when using ifreload -a. Their interfaces 
are DOWN.

I expected it to not affect my containers' connectivity (as it is the case on 
Proxmox). 

To replicate, use ifupdown2 + lxc containers (using VETH). Then enter ifreload 
-a on the console.

Their interfaces should not go down in this way.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-17-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown2 depends on:
ii  iproute2  5.10.0-4
ii  python3   3.9.2-3

ifupdown2 recommends no packages.

Versions of packages ifupdown2 suggests:
ii  bridge-utils 1.7-1
ii  ethtool  1:5.9-1
ii  isc-dhcp-client  4.4.1-2.3
pn  python3-gvgen
pn  python3-mako 

-- no debconf information

Bug#1020290: apt incorrectly prefer usr-is-merged

[Christoph Berg]

Re: Craig Sanders
> I certainly have no respect or tolerance for posturing busybody wankers
> pretending they have the high moral ground.

Hi Craig,

I think that was well beyond what could be acceptable for a Debian
member to behave like. Have you considering finding other venues?

Christoph

Bug#1018938: ITS: libtext-string-hexconvert-perl

[Roland Rosenfeld]

On Fr, 02 Sep 2022, I wrote:

> Package: libtext-string-hexconvert-perl
> Version: 0.01-2.1
> Severity: important

> I'd like to salvage and take over the package (under the perl team
> umbrella).
> For more information about the salvaging process see 
> https://wiki.debian.org/PackageSalvaging and
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

I now updated the package to upstream version 0.02 and did the
following debian/* changes/updates:

  * New upstream version 0.02.
  * Rename package from libtext-string-hexconvert-perl to
libstring-hexconvert-perl.
  * Take over unmaintained package (Closes: #1018938, #979504).
  * Add debian/watch file.
  * Update debian/copyright.
  * Add debian/source/format.
  * Update debian/control: New debhelper, Priority optional,
Standards-Version 4.6.1, updated Homepage, Rules-Requires-Root: no.
  * Add VCS headers to debian/control.
  * Add Testsuite: autopkgtest-pkg-perl.
  * Add CI via debian/salsa-ci.yml.

The main change is the renaming of the source and binary package from
libtext-string-hexconvert-perl to libstring-hexconvert-perl, since
this the canonical name for a Perl moduled named String::HexConvert,
the "text-" part does not make sense here.

I pushed the new package to salsa:
https://salsa.debian.org/perl-team/modules/packages/libstring-hexconvert-perl 
where the salsa pipeline runs without issues and the package is now
lintian clean.

I attached a diff of debian/ directory between 0.01-2.1 and new
0.02-1, if you are interested in the upstream changes, have a look at
salsa (see above).

I didn't receive any response to the ITS request for 21 days now, so
as the next step I'll upload the package to the DELAYED queue with 7
days delay now.

Greetings
Roland
diff --git a/debian/changelog b/debian/changelog
index 623d674..76c2243 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+libstring-hexconvert-perl (0.02-1) unstable; urgency=medium
+
+  * New upstream version 0.02.
+  * Rename package from libtext-string-hexconvert-perl to
+libstring-hexconvert-perl.
+  * Take over unmaintained package (Closes: #1018938, #979504).
+  * Add debian/watch file.
+  * Update debian/copyright.
+  * Add debian/source/format.
+  * Update debian/control: New debhelper, Priority optional,
+Standards-Version 4.6.1, updated Homepage, Rules-Requires-Root: no.
+  * Add VCS headers to debian/control.
+  * Add Testsuite: autopkgtest-pkg-perl.
+  * Add CI via debian/salsa-ci.yml.
+
+ -- Roland Rosenfeld   Fri, 23 Sep 2022 12:50:11 +0200
+
 libtext-string-hexconvert-perl (0.01-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 45a4fb7..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-8
diff --git a/debian/control b/debian/control
index 9326066..101f165 100644
--- a/debian/control
+++ b/debian/control
@@ -1,16 +1,21 @@
-Source: libtext-string-hexconvert-perl
-Priority: extra
-Maintainer: Cyril Bouthors 
-Uploaders: Cyril Bouthors , Cyril Bouthors 
-Build-Depends: debhelper (>= 8.0.0)
-Standards-Version: 3.9.4
+Source: libstring-hexconvert-perl
+Priority: optional
+Maintainer: Debian Perl Group 
+Uploaders: Roland Rosenfeld 
+Build-Depends: debhelper-compat (= 13)
+Standards-Version: 4.6.1
 Section: perl
-Homepage: http://search.cpan.org/~ahernit/String-HexConvert/
+Homepage: https://metacpan.org/release/String-HexConvert
+Rules-Requires-Root: no
+Testsuite: autopkgtest-pkg-perl
+Vcs-Git: https://salsa.debian.org/perl-team/modules/packages/libstring-hexconvert-perl.git
+Vcs-Browser: https://salsa.debian.org/perl-team/modules/packages/libstring-hexconvert-perl
 
-Package: libtext-string-hexconvert-perl
-Section: perl
+Package: libstring-hexconvert-perl
 Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${misc:Depends}, ${perl:Depends}
+Replaces: libtext-string-hexconvert-perl
+Breaks: libtext-string-hexconvert-perl
 Description: Converts ASCII strings to hexadecimal and reverse
  Wrapper around pack and unpack of Perl to convert a string of hex digits to
  ASCII and other way around.
diff --git a/debian/copyright b/debian/copyright
index d37134b..976b47a 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,41 +1,45 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: libtext-string-hexconvert-perl
-Source: http://search.cpan.org/~ahernit/String-HexConvert/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source: https://metacpan.org/release/String-HexConvert
+Upstream-Contact: Andreas Hernitscheck 
+Upstream-Name: String-HexConvert
 
 Files: *
-Copyright: 2010 Andreas Hernitscheck 
+Copyright: 2014 Andreas Hernitscheck 
 License: LGPL-3
- String-HexConvert 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
- 

Bug#1020562: RFP: kde-service-menu-reimage

[Yvan Masson]

Package: wnpp

kde-service-menu-reimage is a package allowing useful image manipulations
right from Dolphin/Konqueror.

Compress and resize:
- Advanced optimization for web
- Compress in % (change quality)
- Resize in % or square

Convert and rotate:
- Convert to all formats supported by ImageMagick
- Convert to PDF or PDF/A-1
- Generate favicons for browser/android/apple/ms
- Convert to Base64
- Generate favicons
- Rotate
- Overturn vertically/horizontally

Metadata:
- Rename jpg and tiff files with data content in Exif metadata.
- (For example: 001.jpg -> 2018-04-27_133741.jpg)
- Rename jpg and tiff files with file's data.
- Set file's datetime from Exif date.
- Set file date from file's name
- Set Exif datetime from file's date.
- Set Exif datetime from file's name.
- Add comment
- View metadata
- Extract metadata to file
- Delete comment field
- Strip Exif section
- Delete IPTC section
- Delete XMP section
- Strip all unnecessary data
- Add timestamp from Exif

Tools:
- Create animated GIF
- Append to right
- GrayScale
- Sepia filter
- Change transparent to color
- Add colored border
- Add transparent border
- Drop shadow

Homepage: https://www.egregorion.net/
KDE store: https://store.kde.org/p/1231579


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018036: Processed: retitle 1018036 to ITP: php-barryvdh-laravel-dompdf -- Laravel wrapper for Dompdf HTML to PDF Converter

[Katharina Drexel]

Repo for php-barryvdh-laravel-dompdf can be found here:

https://salsa.debian.org/php-team/pear/php-barryvdh-laravel-debugbar

Hint: You need a more actual version of php-dompdf and some other dependent
packages, s.a.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567928#45

--

Bug#1016141: ghc uses a 64-bit assembler instruction on 32-bit hppa platform

[Helge Deller]

I've been able to analyze that further.

It seems, that ghc produces/uses this 64-bit hppa assembler instruction 
although ghc is built for 32-bit:
  depd,z,*ev dp,63,32,r11

How to reproduce/analysis:

apt install haskell-devscripts-minimal ghc:native
->
 Setting up ghc (9.0.2-3) ...
update-alternatives: using /usr/bin/runghc to provide /usr/bin/runhaskell 
(runhaskell) in auto mode
update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler 
(haskell-compiler) in auto mode
qemu: CPU exception 0x8
Failing executable: /usr/lib/ghc/bin/ghc-pkg
IA_F f1e5e4bf IA_B f1e5e4c3 IIR f17be000
PSW  0100 CB   0001 --
GR00  GR01 6779 GR02 f1e5e4bc GR03 f1e5a888
GR04 f1e5c684 GR05 0001 GR06 f1e5e4bc GR07 f1e5e76c
GR08 f1ae1590 GR09 f17be028 GR10 0005 GR11 f1e5e888
GR12 f1e5e884 GR13 0001 GR14 000e9000 GR15 f17be000
GR16 f1e5de84 GR17 f1e5d684 GR18 f1e5e180 GR19 f1e5c684
GR20 000f GR21  GR22 001e GR23 000f
GR24  GR25  GR26 000f GR27 000d5738
GR28  GR29 001e GR30 fa0010c0 GR31 f1e42fcf

Illegal instruction
---

IIR=f17be000 means this is this 64-bit (!!!) assembler instruction:
 depd,z,*ev dp,63,32,r11
which is in
 /usr/lib/ghc/rts/libHSrts-ghc9.0.2.so


This happens when running "ghc-pkg recache --global" (try multiple times) in 
the debian postinst script.

QEMU_LOG=strace ghc-pkg recache --global
gives: ...
2394997 
openat(AT_FDCWD,"/usr/lib/ghc/package.conf.d/containers-0.6.4.1.conf",O_RDONLY|O_LARGEFILE|O_NOCTTY|O_NONBLOCK)
 = 4
2394997 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0xfa000ec8) 
= 0
2394997 ioctl(4,TCGETS,0xfa000e48) = -1 errno=25 (Inappropriate ioctl for 
device)
2394997 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0xfa000ec8) 
= 0
2394997 read(4,0xf178a010,8192) = 2388
2394997 read(4,0xf178a010,8192) = 0
2394997 close(4) = 0
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, 
si_sigval=0} ---
2394997 rt_sigreturn(983040,0,0,983040,30,0) = -1 errno=513 (Successful exit 
from sigreturn)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, 
si_sigval=0} ---
2394997 rt_sigreturn(20,0,-100659704,-243487028,-236589632,0) = -1 errno=513 
(Successful exit from sigreturn)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, 
si_sigval=0} ---
qemu: CPU exception 0x8
Failing executable: /usr/lib/ghc/bin/ghc-pkg
IA_F f1e5e4bf IA_B f1e5e4c3 IIR f17be000
PSW  0100 CB   0001 --
GR00  GR01 6779 GR02 f1e5e4bc GR03 f1e5a888
GR04 f1e5c684 GR05 0001 GR06 f1e5e4bc GR07 f1e5e76c
GR08 f1ae1590 GR09 f17be028 GR10 0003 GR11 f1e5e888
GR12 f1e5e884 GR13 0001 GR14 000e9000 GR15 f17be000
GR16 f1e5de84 GR17 f1e5d684 GR18 f1e5e180 GR19 f1e5c684
GR20 000f GR21  GR22 001e GR23 000f
GR24  GR25  GR26 000f GR27 000d5738
GR28  GR29 001e GR30 fa001040 GR31 f1e42fcf

f1dc4000-f1e56000 r-xp  08:21 32510835   
/usr/lib/ghc/rts/libHSrts-ghc9.0.2.so
f1e56000-f1e5c000 rwxp 00092000 08:21 32510835   
/usr/lib/ghc/rts/libHSrts-ghc9.0.2.so
f1e5c000-f1e5d000 rwxp 00098000 08:21 32510835   
/usr/lib/ghc/rts/libHSrts-ghc9.0.2.so
f1e5d000-f1e5e000 rwxp 00099000 08:21 32510835   
/usr/lib/ghc/rts/libHSrts-ghc9.0.2.so
f1e5e000-f1e5f000 rwxp 0009a000 08:21 32510835   
/usr/lib/ghc/rts/libHSrts-ghc9.0.2.so
f1e5f000-f1e62000 rwxp  00:00 0

--- SIGILL {si_signo=SIGILL, si_code=1, si_addr=0xf1e5e4bf} ---
Illegal instruction