Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Surla, Sai Kalyan]

Hi Paul,

In this case can we still go with the temporary change that you suggested as 
the issue is little different with this PST?

Thank you
Sai Kalyan

From: Paul Wise 
Sent: 19 March 2021 08:26 AM
To: Surla, Sai Kalyan ; 984...@bugs.debian.org
Subject: Re: Bug#984581: pst-utils: Fails to extract email addresses for emails 
having ARC headers from PST file

On Fri, 2021-03-19 at 09:03 +0800, Paul Wise wrote:

> The specs indicate that 0x39fe is indeed the recipient address:

The issue in libpst when there are no MIME headers in the PST file is:

There are some MAPI properties for To/CC/BCC:

https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagdisplayto-canonical-property
https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagdisplaycc-canonical-property
https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagdisplaybcc-canonical-property

These contain *only* the names and not the addresses.

Outlook fills them automatically from the list of recipients.

Outlook stores the recipients in a separate table to email properties.

libpst stores them in the sentto/cc/bcc fields of the email structure.

libpst has no storage of the recipients table of the PST file.

libpst processes the MAPI types one-by-one rather than in separate
tables and only has one action per MAPI type.

So this is not going to be easy to fix.

I will discuss this with upstream.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#985633: warn about watch files that use github and include full refs

[Felix Lechner]

Hi Jelmer,

On Sun, Mar 21, 2021 at 6:30 PM Jelmer Vernooij  wrote:
>
> I was hoping that lintian could verify that there is at least
> something after "/archive/" in the matching pattern

Could Lintian-brush or the Janitor do so, when Lintian provides the string?

Kind regards
Felix Lechner

Bug#985687: linux-image-5.9.0-0.bpo.5-armmp: Set CONFIG_CAN_J1939=m

[Andrew Balmos]

Package: src:linux
Version: 5.9.15-1~bpo10+1
Severity: normal

Dear Maintainer,

Please consider setting kernel option "CONFIG_CAN_J1939=m" for at least
buster-backports armmp. Without this setting the CAN J1939 protocol can
not be easily used.

Regards
Andrew

-- Package-specific info:
** Version:
Linux version 5.9.0-0.bpo.5-armmp (debian-ker...@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.9.15-1~bpo10+1 (2020-12-31)

** Command line:
vmalloc=400M root=/dev/mapper/avena-root ro rootfstype=ext4 rootwait 
consoleblank=0 no_console_suspend=5 console=tty1 console=ttymxc0,115200n8 
mxc_hdmfbmem=32M

** Tainted: WE (8704)
 * kernel issued warning
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Revision: 
Device Tree model: Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1

** Loaded modules:
can_bcm(E)
veth(E)
xt_nat(E)
xt_tcpudp(E)
xt_conntrack(E)
xt_MASQUERADE(E)
nf_conntrack_netlink(E)
xfrm_user(E)
xfrm_algo(E)
nft_counter(E)
xt_addrtype(E)
nft_compat(E)
nft_chain_nat(E)
nf_nat(E)
nf_conntrack(E)
nf_defrag_ipv6(E)
nf_defrag_ipv4(E)
libcrc32c(E)
nf_tables(E)
nfnetlink(E)
br_netfilter(E)
bridge(E)
stp(E)
llc(E)
wireguard(E)
libchacha20poly1305(E)
poly1305_arm(E)
ip6_udp_tunnel(E)
udp_tunnel(E)
libblake2s(E)
libblake2s_generic(E)
libcurve25519_generic(E)
libchacha(E)
pps_ldisc(E)
pps_core(E)
rfkill(E)
overlay(E)
can_raw(E)
can(E)
joydev(E)
dw_hdmi_ahb_audio(E)
dw_hdmi_cec(E)
sg(E)
qmi_wwan(E)
cdc_wdm(E)
pl2303(E)
option(E)
usbnet(E)
usb_wwan(E)
mii(E)
usbserial(E)
stmpe_ts(E)
snd_soc_sgtl5000(E)
nvmem_imx_ocotp(E)
snd_soc_imx_sgtl5000(E)
snd_soc_imx_audmux(E)
snd_soc_imx_spdif(E)
imx_thermal(E)
snd_soc_fsl_ssi(E)
snd_soc_fsl_spdif(E)
imx_pcm_fiq(E)
imx_pcm_dma(E)
imx2_wdt(E)
snd_soc_core(E)
snd_pcm_dmaengine(E)
snd_pcm(E)
snd_timer(E)
snd(E)
soundcore(E)
flexcan(E)
pwm_imx27(E)
can_dev(E)
dw_hdmi_imx(E)
parallel_display(E)
imx_ldb(E)
imxdrm(E)
dw_hdmi(E)
etnaviv(E)
imx_ipu_v3(E)
gpu_sched(E)
cec(E)
drm_kms_helper(E)
panel_simple(E)
leds_gpio(E)
drm(E)
evdev(E)
pwm_bl(E)
imx6q_cpufreq(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
crc32c_generic(E)
uas(E)
usb_storage(E)
dm_mod(E)
sd_mod(E)
t10_pi(E)
crc_t10dif(E)
crct10dif_generic(E)
crct10dif_common(E)
pfuze100_regulator(E)
ahci_imx(E)
libahci_platform(E)
libahci(E)
libata(E)
ci_hdrc_imx(E)
phy_generic(E)
ci_hdrc(E)
ulpi(E)
roles(E)
scsi_mod(E)
ehci_hcd(E)
udc_core(E)
sdhci_esdhc_imx(E)
sdhci_pltfm(E)
cqhci(E)
usbcore(E)
usbmisc_imx(E)
sdhci(E)
i2c_imx(E)
anatop_regulator(E)
phy_mxs_usb(E)
micrel(E)

** PCI devices:
00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 [16c3:abcd] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport


** USB devices:
Bus 002 Device 003: ID 1bc7:1201 Telit Wireless Solutions 
Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.9.0-0.bpo.5-armmp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.9.0-0.bpo.5-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-5.9.0-0.bpo.5-armmp recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.9.0-0.bpo.5-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.9   

Versions of packages linux-image-5.9.0-0.bpo.5-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  

Bug#985633: warn about watch files that use github and include full refs

[Jelmer Vernooij]

On Sun, Mar 21, 2021 at 08:34:58AM +, Gordon Ball wrote:
> I started a branch for lintian-brush here:
> https://salsa.debian.org/chronitis/lintian-brush/-/tree/github-archive-url
> 
> (using a nonexistant lintian tag, so having a real one would definitely
> be a first step).
> 
> However, it turned out to be a bit more complex than I first thought (or
> hoped):
> 
> * Lots of unrelated test cases get broken (since it rewrites their watch
>   files)
> * Lots of different ways of spelling the match pattern - amongst my
>   there were at least three (and subvariants of each)
> 
> - .*/archive/v([0-9.]+)# now matches nothing
> - .*/archive/(.+)  # now matches refs/tags/x.y.z
> - .*/archive/@ANY_VERSION@ # now matches nothing
> 
>   and the discussion on IRC suggested other cases too (adding a wildcard
>   for the new /refs/tags/ part, just matching @any_vers...@.tar.gz, etc.
> * Unpreservable formatting in several of the test cases I was using
>   (continuation lines in comments?)
> * What new pattern to actually write? The initial idea was just to
>   literally replace /archive/ with /archive/refs/tags/, which _should_
>   meet the idea of being conservative about what to fix (but might still
>   collide with hand-written fixes for this issue like ./archive/.*/v...
> 
> I _think_ a good indicator for lintian (and a fixer) would be if the
> matching expression contains "archive" followed by no wildcard pattern
> before the capturing group for the version.
Thanks! I've merged your branch with some additional changes:

* reformatted the watch files in the examples to use a format that
  debian/watch can preserve
* changed the logic to follow your last suggestion

Ideally the other ways of formatting debian/watch would be handled
too, but that's something that is a work in progress and needs to be
fixed in debmutate.watch.

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#985425: sylpheed: email attachment send problem

[shuiqucheng]

On Sun, 21 Mar 2021 16:14:35 +0900 Kentaro Hayashi 
wrote:
> Hi,
> 
> I've tried sylpheed 3.7.0-8 with the following sample attachment.
> (recognized as message/rfc822)
> 
> https://www.phpclasses.org/browse/file/14672.html
> 
> It seems that it is not reproducible.
> 
> 
> 
> 

Hi:
  The result of my test is:

If the attachment is a ".eml" file, the "content disposition" attribute of the 
attachment in the email content is "inline" instead of "attachment". Many 
mailbox clients, including sylpheed, will not view it as an attachment.
  On Sun, 21 Mar 2021 16:14:35 +0900 Kentaro Hayashi 
wrote:
> Hi,
> 
> I've tried sylpheed 3.7.0-8 with the following sample attachment.
> (recognized as message/rfc822)
> 
> https://www.phpclasses.org/browse/file/14672.html
> 
> It seems that it is not reproducible.
> 
> 
> 
> 

Hi:
  The result of my test is:

If the attachment is a ".eml" file, the "content disposition" attribute of the 
attachment in the email content is "inline" instead of "attachment". Many 
mailbox clients, including sylpheed, will not view it as an attachment.
  _PNG

?_*K_Ko_2_֡___kcAbb_jn_(_o__
______:_U___g___(Is___p   _0_~L>_M_dH__F2ޟ__ 
(n_ǯ_____擦;跗WnBㆹ_(_H__I_@_ZU_d2___|_____,7__ 
_{__Ҳr]__?____Cw___QjⳎ_^h$_@S\D,Sw____b~___^WVF__TOQ^o__T__C_/MUh_*)E__/__W3___6_Ҝ___E_]:~Qa"_67_8_H_Ǹ__]'_
 \__SnF__#_mG_*f_8)Ӷ_4佊)___*7|k__Ǵ'^2__k_>um__G_utK___t__
___0#7___s_>d_(-_Q_x_}__m?A__ۭ_eMׅנ_O_
'#/__f綷2/#_0خ_Yf__FC___f_>&_g__h__!_uf_:_ׅ__[ƈB_3_o_pi_Y__t>_)_C___O.-6_)\_x__G_
w
X   
~3___z__{RT_j__}_o__
_____W___y___p_.(C______m_MW__WF:_-_!ٮ;_ 
_bv_{_?w_____ο__*__Z3"'둷____
_>_z__ר
F_9i _鐤__
___ 1G__Sp__K<6_-5\_S_[___ԩg^'}_soר__>.__ __~~˹L_%__Fâ$H  
_
*_1~RQ__~vm_E}0__l__k֌
;(_V4___9__Jl_\n____x__$_#__}S_no____w__,_vl____aj|\_O1.__F___ĤHhm
___;
A4u__щ__Ք___n___>XK5_o_'__;h_G__   }] 
1_q8___e7_k__4_aR0_Z[__]qr_7-_=?4_,___FӶ 
_|011i=___V\{_g_}5,"))__hm|i_@___=f__;m_fi_O"_e__;_Ue=_T__VR_RҔ_І___ܪ.1"Ht__˛_+o__X___a___+[M{بړ_bUd_ֲ_e5_Da__<;-__7B_}__ܴ_n
__v

_7?___i_>;__ӊ'l
__}__r_x_3_8N__e___]=__{_)
:__*1}___:nhe_2_ÝvP__>X___h__:___W`__'q .___ȝ__q7_X\X___Θ[RP…
e__`_iAO__.$Y__#ߺ_$>_f{_׺A_1_'\~q_
^{Õ_-k_Ѻ__4Tf_^_(XM_~_R[_____ݪ_
__?X__>_B__M___1_N__T'__3B__6l__,#__VW_5_E__woޕ_E)_jR-_ 
JMWE__5Wd|xv9__w`__i_ 
*___o_u_Ӟ__M_X*@%_o;_4ܾ___'mp___g__ƒo__>__}_7U˴____.___Ƶ_+_X<__S__k_#YZkVO__^V__f_L_%A}__߹n2_57__[=_M9__<_d_b_ap]y~FR___#y_M|_kyݝ|a_o__yG1_z___i_K_{ܞrjS_[_:__bk\_Ѷ_4kH~t__J_)_ZjO_$_K__Y
nk_z^V'w___l_];___um_9eTjMMUBZ#_T~_੎_0 Y5

";x_)____co_m_Hb%_?_/_*__֭5____{?L<_H___%_76k7{_2y_A__/__h__S___#__vx_R__}~j__\䳋____;P_&_/_z_}S_qb_(_I-_{A|_ǥ_O__u_h`2[ϫ_)_O__7__9AY_u__+_l___._M_g[_D__1[O__).___F_
_3___2`___K,z1_[5xА_S_=____F___?__6_____#_v_Y___4__;P_a>Im__9_7,__t
⨓_Mm/*F____~i__!___qJ_-GbB___<_i__r__[Pk__n,D__gc__t__d6&_m;_"__O_z_kM_)_2_GsD___@i_y___ٺ4

“___ڤ_[3z_eq__^w_cA[l}?t_0*?__cDimo___3_U_._______d2k_][6R_e__hN(}RQFU
…%_r_6_E__M____m7So,_Fnߩ__
VO_-骞_9/vO7__=__F__o˦__d~__r___0____j!KU_D_m_h__d\_1'_x>%݉9_n 
_rE^L_ƨ_|}__v____]_e_ޚI_!_)_?]_2]_ǝ_T_[_Ʌp"j___|_
___I___r_͐__n~S_W_Ր_b_T__e_,_`__bbwl__z'''ފ74__9%_8_oF_Y_E_%4_hGZh_g_os_g__
__ _*__?_vVmANq^BQEF_7>_YS__Z_
J*(J
___eP+_+___ 
'_SW_SHED_T_(C6___4___Uq_唕(___|__G_1_k__N︕_ˡL_p___9__:a___ef_Ր___C_
  ___o___:8Q_?p_;__1_
R_-2"__g_
KJ_CR___UDo___A_9q___
_Ť_#_ՓD__D___?____w__]__<$__~73pj_n4_ 
!,*&z___}\6_K_]__OBJTn___~n_z___!___n__vn_
___c__
_'____Q1TXs_o*NK+__
)i_
@hCIFjn__g_zl<_T_g_5__y_U_U_O_͐Â"B0`__M(__i_X_%U_RM__1_DUT%
.h]K_wH_0_@h~__ضœ_:Ќ___89i______N"Օ___1}_
nVЭ_s_͞P____r_-___9a_]___Ml-___Nx_Ko__!__)_9_tؠ`_Y^__z_ؙB_[_f__
 _(_{v_
_=^V_hi_U__@o_:__Ŋ__N_\roo__ڒ
_ܸ__s___}n___ҟ/꾭_w___O_Ny$4}___{___H_Hǫ_4mq_0__ƙ__;__K#E1_____[_M7_o__"_]?_W_m(MMϯ__(__d_Hŧ珂u__D_Z
_&__κ:P__O1__o_(_J_cڝ__(_ע_
v__;____J*(J___=___7__/wg_____K_鐄R_ӫ_ɨ),(___Q<_*2*__`U___ڳw1fmeyE_TP__U#_#$$__8L__WE_sr_J___S_$*_)__^u_X[__C_N_.__n_.(_:?_____&_s__j,|__c```_?__b6_L_mp)_____j_ߟݯ_,_0c_N__s.멇_
 _a_S`__~___g}oɺ.s___߄___nl_}_(=__I#__z;_
_?v"___|_{__U__/߫e____.~N_=o_K_e__(|___Ԭ*Dq___
_C_____i___l1i_4__&<:C;_U__i__="c?__WԱp__s
G;M_(__4_h__CB0Wc_\

_!s5000_l___6_7nmvr
__7u0˾___k___5g___R__-e__]d_ltz:__O)
_&_Q__5__  
_Tѷ7__?߉6܂___.Qi__w>_>__{s_{_{___s_

Bug#985425: sylpheed: email attachment send problem

[shuiqucheng]

On Sun, 21 Mar 2021 16:14:35 +0900 Kentaro Hayashi  wrote:
> Hi,
> 
> I've tried sylpheed 3.7.0-8 with the following sample attachment.
> (recognized as message/rfc822)
> 
> https://www.phpclasses.org/browse/file/14672.html
> 
> It seems that it is not reproducible.
> 
> 
> 
> 

Hi:
  The result of my test is:

If the attachment is a ".eml" file, the "content disposition" attribute of the 
attachment in the email content is "inline" instead of "attachment". Many 
mailbox clients, including sylpheed, will not view it as an attachment.

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[Ryutaroh Matsumoto]

Control: tags -1 - moreinfo

Hi Maximilian, thank you for your attention!

> please provide info on the affected hardware,

It is Raspberry Pi 4B 8GB model.

> please show affected dmesg output working and non working,
> the difference between 20210208-3 20210208-4 is minimal,
> hence it should be easy to find out what broke?

Not at all, unfortunately.
20210208-3 was completely broken on RPi4B as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489
20210208-1 to 20210208-3 were broken...
The last working version was 20201218-3, and I apt-mark-holded 
firmware-brcm80211.
I unhold it in the weekend and found this issue.

I attach dmesg of 20201218-3, 20210208-4, and 20210315-1.
It was also interesting that installation of 20210315-1 causes boot failure
and showed "Give root password for maintainance"...
Should I file a separete report against 20210315-1?
20210315-1~exp1 was booted fine...

Best regards, Ryutaroh


dmesg.tar.xz
Description: Binary data

Bug#985686: wpasupplicant: WPA supplicant tries to bring up wrong network device

[Vroomfondel]

Package: wpasupplicant
Version: 2:2.7+git20190128+0c1e29f-6+deb10u2
Severity: important

Dear Maintainer,

   * What led up to the situation?

   Regular wpasupplicant + backports kernel updates

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   Removing custom module parameters for iwlwifi module did not solve problem
   Configuring interface manually using the wlp36s0 device worked

   * What was the outcome of this action?

   Card was only able to associate with WLAN and connect successfully when
   enabled manually

   * What outcome did you expect instead?

   Connection to WLAN should have Just Worked as it has in the past


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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

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

Versions of packages wpasupplicant depends on:
ii  adduser    3.118
ii  libc6  2.28-10
ii  libdbus-1-3    1.12.20-0+deb10u1
ii  libnl-3-200    3.4.0-1
ii  libnl-genl-3-200   3.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libpcsclite1   1.8.24-1
ii  libreadline7   7.0-5
ii  libssl1.1  1.1.1d-0+deb10u5
ii  lsb-base   10.2019051400

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui    

-- no debconf information

I'm not quite sure when it happened (it's been an age since the last reboot) but 
I recently discovered that the wireless network on one of my machines wouldn't 
come up at boot.


To cut a long story short, it looks like wpasupplicant was throwing an error 
when bringing up the interface. Networking status pointed at a device that I 
don't recall seeing before, p2p-dev-wlp39s0. Because wpasupplicant threw an 
error, the rest of the networking steps were never performed (so I was left 
without a default gateway etc):


   /etc/init.d/networking status
   ● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor
   preset: enabled)
   Active: failed (Result: exit-code) since Sun 2021-03-21 22:18:34 GMT;
   6min ago
 Docs: man:interfaces(5)
  Process: 22444 ExecStart=/sbin/ifup -a --read-environment (code=exited,
   status=1/FAILURE)
 Main PID: 22444 (code=exited, status=1/FAILURE)

   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to open
   /proc/sys/net/ipv4/conf/p2p-dev-wlp36s0/drop_unicast_in_l2_multicast: No
   such file or directory
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to set IPv4
   unicast in multicast filter
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to open
   /proc/sys/net/ipv4/conf/p2p-dev-wlp36s0/drop_unicast_in_l2_multicast: No
   such file or directory
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: Failed to set IPv4
   unicast in multicast filter
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: deinit
   ifname=p2p-dev-wlp36s0 disabled_11b_rates=0
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: p2p-dev-wlp36s0:
   CTRL-EVENT-TERMINATING
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: nl80211: deinit
   ifname=wlp36s0 disabled_11b_rates=0
   Mar 21 22:18:34 macduff wpa_supplicant[22472]: wlp36s0: 
CTRL-EVENT-TERMINATING
   Mar 21 22:18:34 macduff systemd[1]: networking.service: Failed with result
   'exit-code'.
   Mar 21 22:18:34 macduff systemd[1]: Failed to start Raise network interfaces.

The same device showed up in /var/run/wpa_supplicant and wpa_cli (MACs and UIDs 
removed):


   wpa_cli status
   Selected interface 'p2p-dev-wlp36s0'
   wpa_state=DISCONNECTED
   p2p_device_address=
   address=
   uuid=

According to the doc, wpasupplicant will try and bring up the first device it 
sees in /var/run/wpa_supplicant which appears to be the wrong one.


Manually upping wlp36s0 with ifup worked but every attempt using the networking 
script/wpasupplicant failed and left me with an unconfigured network. Using the 
"correct" device name I'm able to connect successfully.


   wpa_cli status -i wlp36s0
   bssid=
   freq=5500
   ssid=
   id=0
   mode=station
   pairwise_cipher=CCMP
   group_cipher=CCMP
   key_mgmt=WPA2-PSK
   wpa_state=COMPLETED
   ip_address=
   p2p_device_address=
   address=
   uuid=
   ieee80211ac=1

I was using some custom parameters for the iwlwifi and kernel boot but I 
disabled those for the purposes of debugging. The wireless card in question is 
an Intel 8265 using the v36 firmware. iw reports that this device supports P2P, 
whatever that means. From dmesg:


   [    3.996170] iwlwifi :24:00.0: firmware: direct-loading firmware
   iwlwifi-8265-36.ucode
   [    3.997288] 

Bug#985685: matrix-mirage can’t login to the same server on multiple devices

[Marek Ľach]

Package: nheko

Version: <0.6.4>

The new version, 0.7.1 fixes this. Since the bug is quite fundamentally 
impairing usabíity, it’d be useful to have it updated within the repos on here.

Much thanks,

Bug#932290:

[Matteo Croce]

On Sun, Mar 21, 2021 at 12:38 PM Matthew Vernon  wrote:
> Have you upgraded to the later version of insserv? And if so, has this
> resolved the problem for you?
>

How to trigger it? Maybe with:

apt --reinstall install rsync

In case, I don't get any warning.

Regards,
-- 
per aspera ad upstream

Bug#984721: x2goserver: Username 'andrew' can log in only once

[Mike Gabriel]

HI Andrew,

On  So 07 Mär 2021 17:42:11 CET, andrew glaeser wrote:


Package: x2goserver
Version: 4.1.0.3-5
Severity: minor

Dear Maintainer,

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


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

* x2go used to be an external package, one had to fetch from x2go repsitories
* from bulls-eye onward x2go server is included in the main debian section
* my given name is 'andrew' in english, although of course I could call
  myself Luke, Darth, Jean-Paul, Max, user, Pingu, SnaFu, Schlurfi, Knuffi
  or whatever you wish, but those are not my real names
* and particularly with username 'andrew' I can log in only once to remote
  servers with the new x2goserver Debian package running
* how pathetic is this anyway? I will report back to you in more detail how
  difficult it really is to work around this by continuing to use  
the external

  package from upstream repositories, but naturally people are lazy and want
  so spare the effort, if possible.
* I tried to write directly to the maintainers already:



Let's try to avoid mixing upstream DEBs and Debian DEBs for X2Go  
Server / X2Go Client.


I will test multiple session startups with X2Go packages from vanilla  
Debian on a Debian testing system the coming week and report back.


Please let me know the settings you use in X2Go Client for starting up  
your session.


Make sure you _don't_ use "Connect to local desktop" (as that only  
allows sharing an already running desktop session). Here you can  
experience situation that seem like you are only able to launch one  
session at a time.


Can you, at least, launch multiple... say XFCE sessions... for  
different users on one server?


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpOUH2GPmJ3y.pgp
Description: Digitale PGP-Signatur

Bug#985633: warn about watch files that use github and include full refs

[Jelmer Vernooij]

Hi Felix,

On Sat, Mar 20, 2021 at 09:44:07PM -0700, Felix Lechner wrote:
> On Sat, Mar 20, 2021 at 7:27 PM Jelmer Vernooij  wrote:
> >
> > https://qa.debian.org/cgi-bin/watch?pkg=jupyter-core
> 
> I saw the traffic on IRC where someone suggested we replace
> 
> .*archive/v?([0-9.]*).tar.gz
> 
> with
> 
> .*archive/.*/v?([0-9.]*).tar.gz
> 
> to fix at least 1,500 affected packages. Unfortunately, that may not
> work for jupyter-core, which does not prefix tags with a "v" and for
> which "(.*)" catches the slash (or maybe even slashes).
> 
> As a tool without network access, Lintian is not well positioned to
> figure out, in general, whether a URL/regex combination works. Would
> it be okay if Lintian instead issues two now classification tags?
> 
> The first would occur once per source. It shows the watch file URL and
> the regular expression for HTML parsing, possibly followed by "debian
> update" (or similar). The second tag would occur once for each of the
> options selected, i.e. multiple times. Armed with that information,
> the Janitor could probe the URL and figure out which parts need
> fixing.
I was hoping that lintian could verify that there is at least
something after "/archive/" in the matching pattern that could
match slashes without relying on the main regex group - that could be
done without querying GitHub. That said, that code would have to be
updated if GitHub changes again in the future and it may be somewhat
tricky code.

The offer for informational tags is appreciated, but as you say - the
data is already available in UDD so just providing the pure uscan
contents wouldn't help much.

The alternative is to just let lintian-brush work without a signal
from lintian, and gradually grind through the archive. That'll work
too, though it'll take a few months - and we lose the verification
from lintian after the fix.

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#985666: alsa-utils: no sound after installation

[Nick Gawronski]

Hi, It sounds like static like what happens if you play a file between 
different byte orders.  I also tried arecord with no sound when I tried 
to play it back and pulseaudio is running this system I just chose the 
defaults with the ssh server so I could login and no orca login screen 
speaks.  The espeakup process is also running but again no sound.  Nick 
Gawronski


On 3/21/2021 1:55 PM, john doe wrote:

On 3/21/2021 7:50 PM, Samuel Thibault wrote:

Nick Gawronski, le dim. 21 mars 2021 13:45:37 -0500, a ecrit:

What else can I try to see if the sound is working are samples
provided to test with?


You could use aplay from alsa-utils on a .wav file.



In other words, are you able to play any sound on the installed system
(the one you installed without a DE (Mate/Gnome...)).

--
John Doe

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Don Armstrong]

On March 21, 2021 1:06:29 PM PDT, Harlan Lieberman-Berg  
wrote:
>tag 985675 +moreinfo
>thanks
>
>On Sun, Mar 21, 2021 at 3:39 PM Don Armstrong  wrote:
>> plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship
>> /usr/share/plover/assets/american_english_words.txt, but the latter
>is
>> missing the appropriate Conflicts/Replaces.
>
>Hi Don,
>
>Where have you installed plover-common from?  That's not a package I
>recognize in the archive.


Hrm.  It was maintained by you, but there's a non-zero chance I installed it 
directly from source. If it's never been uploaded, that's probably what 
happened. 


I can do more research later if that's helpful. 
-- 
This is not a signature.

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Harlan Lieberman-Berg]

On Sun, Mar 21, 2021 at 7:04 PM Don Armstrong  wrote:
> Hrm.  It was maintained by you, but there's a non-zero chance I installed it 
> directly from source. If it's never been uploaded, that's probably what 
> happened.

Iiiinteresting.  The plover repo that I've been working out of has
3.1.1 as the earliest version (Mon Nov 18 23:01:12 2019 -0500), but I
do remember vaguely trying to decide if I was going to split the
common out into its own repo.

I think the 3.0.0 might be dated back to when we were waiting on the
relicensing to solve the fact that it was undistributable (GPLv2 only
/ GPLv3 only) and I was trying to figure out the packaging in
preparation.

Sorry about that!
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Chris Hofstaedtler]

* Ritesh Raj Sarraf :
> On Tue, 2021-03-02 at 10:52 +0900, Ryutaroh Matsumoto wrote:
> > Is it expected? If this is an expected behavior, I am happy to attach
> > "wontfix" tag
> > and/or close this issue.
> > 
> 
> The installation of the open-iscsi package shouldn't have any
> difference in regard to the init system.
> 
> While I don't test with sysvinit any more, I don't recollect dropping
> support for it. So if there's any specific issue, we could try to
> resolve it.

TBF, if there's not going to be regular testing with sysvinit, maybe
the support code for it should go away...?

Chris

Bug#985502: release-notes: suggestions for usrmerge section

[McIntyre, Vincent (CASS, Marsfield)]

On Sun, Mar 21, 2021 at 11:33:38AM +, Justin B Rye wrote:
>Paul Gevers wrote:
>>> I'd forgotten the *Buster* release notes *do* mention usrmerge:
>>>
>>> https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#merged-usr
>>>
>>> but we've taken that part out now.  Could we perhaps recycle the
>>> phrase "the usrmerge package exists to do the conversion if desired"?
>>
>> Sounds like a plan.
>
>That would give us something like the attached...
>--
>JBRwith qualifications in linguistics, experience as a Debian
>   sysadmin, and probably no clue about this particular package

>diff --git a/en/issues.dbk b/en/issues.dbk
>index 4377402b..f926c775 100644
>--- a/en/issues.dbk
>+++ b/en/issues.dbk
>@@ -231,12 +231,18 @@ information mentioned in .
>
>   
> 
>-Historically there was a reason to split root level
>-bin, sbin and
>-lib directories into
>-/usr/, but that is no more. Debian
>-bullseye will be the last Debian release that supports the
>-non-merged-usr layout.
>+  The historical justifications for the filesystem layout with
>+  /bin, /sbin, and
>+  /lib directories separate from their
>+  equivalents under /usr no longer apply
>+  today; see the +  
>url="https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge;>Freedesktop.org
>+  summary. Debian bullseye will be the last Debian
>+  release that supports the non-merged-usr layout; for systems
>+  with a legacy layout that have been upgraded without a
>+  reinstall, the +  role="package">usrmerge package exists to do
>+  the conversion if desired.
> 
>   
>

This looks pretty good but that last sentence makes me wish for
something blunter (at the cost of more translation effort I guess)

+  summary. Debian bullseye will be the last Debian
+  release that supports the non-merged-usr layout. If you
+  want to convert your system from the legacy layout to the
+  new layout, install the
+  usrmerge package.

Thanks for your work on this issue
Vince

Bug#985666: alsa-utils: no sound after installation

[Nick Gawronski]

Hi, Here is that output and this system has the desktop environment plus 
the ssh server.  Nick Gawronski



> pulseaudio_ps_do
lightdm  901  2.2  0.3 893624 26276 ?    S/usr/bin/pulseaudio --daemonize=no --log-target=journal
nick    1383  0.0  0.1 161740  9328 ?    Ssl  16:53   0:00 
/usr/bin/pulseaudio --daemonize=no --log-target=journal
lightdm 2461  0.0  0.0   3180   716 pts/1    S+   16:54   0:00 grep 
pulseaudio


> which pulseaudio
/usr/bin/pulseaudio

> pidof pulseaudio
1383 901

> pulseaudio --version
pulseaudio 14.2

> pactl info
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

> pactl list
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

> cat /etc/pulse/daemon.conf
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as 
published by

# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

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

## commenting.

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

; lock-memory = no
; cpu-limit = no

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

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rescue-streams = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0

> cat /etc/pulse/client.conf
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as 
published by

# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

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

## commenting.

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

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

; cookie-file =

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


; auto-connect-localhost = no
; auto-connect-display = no

> cat /etc/pulse/default.pa
#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it 

Bug#985390: Make this request valid for 4.13-8

[Santiago Garcia Mantinan]

Hi!

While we were waiting for 4.13-7 to age and enter testing, we were filled a
security bug for CVE-2020-25097.

I decided to fix that security problem ASAP and that is what is on 4.13-8,
just that. 4.13-8 just adds the patch to fix the CVE as available at:
http://www.squid-cache.org/Versions/v4/changesets/SQUID-2020_11.patch

You can see more info on all this on the bug that was assigned, #985068.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#985684: arm64: please enable CONFIG_ARCH_MXC for mx8 boards

[Ying-Chun Liu (PaulLiu)]

Source: linux
Severity: wishlist

Dear Maintainer,

Please enable CONFIG_ARCH_MXC and related configs for i.mx8 boards.

In mainline's defconfig, CONFIG_ARCH_MXC is enabled by default. Thus the
mainline kernel supports mx8 boards by default. 

But it seems that Debian kernel doesn't enable it.


So please consider support mx8 boards.



Yours,
Paul





OpenPGP_signature
Description: OpenPGP digital signature

Bug#985683: unblock: powerline/2.8.2-1

[Samuel Henrique]

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

Please unblock package powerline

I'd like to update powerline to the latest release, it's a minor
version bump, with all the changes being fair for a minor bump.

powerline is a non-key package and a mature software at this point,
our users will benefit from a considerable amount of bugfixes which
would be too much work to port individually.

I have verified all commits since the previous release and everything
looks good.

Note that powerline is only blocked because it doesn't have autopkgtest,
but upstream does have good automated testing on their side.

[ Reason ]
* Use `--no-optional-locks` to reduce conflicts with other git editors
* Fixes elapsed time that is provided with a ',' instead of a '.'
* Render cpu_load_percent segment even when psutil returns 0.0
* Shifted away from (abandoned) Yahoo API to OpenWeatherMap
* Prefer Python 3 in the Vim plugin
* Fixed getcwd for tmux
* Fix escaping of sh specific characters in tmux
* Use updated i3ipc syntax in i3 segments/listers

[ Impact ]
Missing the fixes described above.

[ Tests ]
I use powerline daily and I have not found any issues with the latest
release.

Upstream also runs a lot of automated tests against different
environments and found no regressions.
https://travis-ci.org/github/powerline/powerline/builds/760903189

[ Risks ]
non-key package
The new release is mostly about fixinf existing problems, though
there are a few functionality additions, all the commits were
verified by me and can be seen here:
https://github.com/powerline/powerline/compare/d137a88...2.8.2

powerline is a mature software at this point, and this being a
minor release plus all the automated tests give me confidence
we should ship this release to our users.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock powerline/2.8.2-1

Bug#894463: synaptic icon seems pixelated - patch (testing bullseye)

[Federico Grau]

Control: tags -1 patch

Below is a patch that updates the default synaptic application icon size from
16x16 to 48x48.  According to Git logs the synaptic application icon has been
48x48 since at least 2004.

$ file pixmaps/synaptic.png
pixmaps/synaptic.png: PNG image data, 48 x 48, 8-bit/color RGBA, 
non-interlaced


Testing with a small 640x480 resolution desktop size, the higher 48x48
resolution icon looked OK and matched other current desktop applications
(e.g. xfce-terminal).

The current synaptic get_gdk_pixbuf() calls used to read the application icon,
don't define a size parameter, so the header file defaults downscale the icon
to look pixelated.
./rgmainwindow.cc:962:   GdkPixbuf *icon = get_gdk_pixbuf( "synaptic" );
./rguserdialog.cc:83:   GdkPixbuf *icon = get_gdk_pixbuf( "synaptic" );


I've also submitted a PR with this simple patch.
https://github.com/mvo5/synaptic/pull/79


$ diff -Naur synaptic-0.90.2_orig
synaptic-0.90.2_patch_icon_size_894463_2021-03-21
diff -Naur synaptic-0.90.2_orig/gtk/rgutils.h
synaptic-0.90.2_patch_icon_size_894463_2021-03-21/gtk/rgutils.h
--- synaptic-0.90.2_orig/gtk/rgutils.h  2020-11-16 03:56:34.0 -0500
+++ synaptic-0.90.2_patch_icon_size_894463_2021-03-21/gtk/rgutils.h 2021-03-21
16:27:04.326221170 -0400
@@ -51,8 +51,8 @@
 const char *utf8_to_locale(const char *str);
 const char *utf8(const char *str);
 
-GtkWidget *get_gtk_image(const char *name, int size=16);
-GdkPixbuf *get_gdk_pixbuf(const gchar *name, int size=16);
+GtkWidget *get_gtk_image(const char *name, int size=48);
+GdkPixbuf *get_gdk_pixbuf(const gchar *name, int size=48);
 
 std::string SizeToStr(double Bytes);
 bool RunAsSudoUserCommand(std::vector cmd);
$ 



donfede


signature.asc
Description: PGP signature

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 15:58:37 -0500, a ecrit:
>     868 ?    Sl 0:00  \_ lightdm --session-child 16 19
>     902 ?    Ssl    0:01  |   \_ /usr/sbin/lightdm-gtk-greeter
>     903 ?    Sl 0:00  |   \_ /usr/bin/python3 /usr/bin/orca
> --replace --no-setup --disable splash-window

I thought you said you didn't ask for the graphical desktop task, only
the ssh task?

So Orca is not emitting sound in the lightdm session?

Could you post the output of

sudo -u lightdm pa-info

Samuel

Bug#985617: glibc: flaky autopkgtest on most architectures

[Paul Gevers]

Hi Aurelien,

On 21-03-2021 00:03, Aurelien Jarno wrote:
> Yes, could you please provide a full log? I am not able to reproduce the
> issue locally nor on barriere.d.o, so I have no idea what fails.

Of course when you try to, it doesn't work. I had 5 runs on arm64 which
all succeeded. I'm wondering if this flakyness comes from activities in
parallel runs.

I'll try again tomorrow.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983704: Switch to fcitx5 for Simplified and Traditional Chinese desktop

[Holger Wansing]

Hi,

Shengjing Zhu  wrote (Sat, 20 Mar 2021 16:17:32 +0800):
> I forget to mention the MR is at
> https://salsa.debian.org/installer-team/tasksel/-/merge_requests/16

Merged into master.


Holger


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

Bug#985682: nim-kexpr-dev: broken long package description

[Daniele Forsi]

Package: nim-kexpr-dev
Severity: minor

Dear Maintainer,

the long package description reads:
> This panim wrapper for Heng Li's kexpr math expression library.

instead of something like this:
This package contains the nim wrapper for Heng Li's kexpr math expression 
library.


thanks,
Daniele

Bug#985666: alsa-utils: no sound after installation

[Nick Gawronski]

Hi, Here is that output.  Nick Gawronski

Script started on 2021-03-21 15:56:41-05:00 [TERM="xterm-256color" 
TTY="/dev/pts/0" COLUMNS="120" LINES="30"]

[?2004hroot@debian641:~# ps axf
[?2004l
    PID TTY  STAT   TIME COMMAND
  2 ?    S  0:00 [kthreadd]
  3 ?    I< 0:00  \_ [rcu_gp]
  4 ?    I< 0:00  \_ [rcu_par_gp]
  6 ?    I< 0:00  \_ [kworker/0:0H-events_highpri]
  9 ?    I< 0:00  \_ [mm_percpu_wq]
 10 ?    S  0:00  \_ [rcu_tasks_rude_]
 11 ?    S  0:00  \_ [rcu_tasks_trace]
 12 ?    S  0:00  \_ [ksoftirqd/0]
 13 ?    I  0:00  \_ [rcu_sched]
 14 ?    S  0:00  \_ [migration/0]
 15 ?    S  0:00  \_ [cpuhp/0]
 16 ?    S  0:00  \_ [cpuhp/1]
 17 ?    S  0:00  \_ [migration/1]
 18 ?    S  0:00  \_ [ksoftirqd/1]
 20 ?    I< 0:00  \_ [kworker/1:0H-kblockd]
 21 ?    S  0:00  \_ [cpuhp/2]
 22 ?    S  0:00  \_ [migration/2]
 23 ?    S  0:00  \_ [ksoftirqd/2]
 25 ?    I< 0:00  \_ [kworker/2:0H-events_highpri]
 26 ?    S  0:00  \_ [cpuhp/3]
 27 ?    S  0:00  \_ [migration/3]
 28 ?    S  0:00  \_ [ksoftirqd/3]
 30 ?    I< 0:00  \_ [kworker/3:0H-kblockd]
 31 ?    S  0:00  \_ [cpuhp/4]
 32 ?    S  0:00  \_ [migration/4]
 33 ?    S  0:00  \_ [ksoftirqd/4]
 35 ?    I< 0:00  \_ [kworker/4:0H-events_highpri]
 36 ?    S  0:00  \_ [cpuhp/5]
 37 ?    S  0:00  \_ [migration/5]
 38 ?    S  0:00  \_ [ksoftirqd/5]
 40 ?    I< 0:00  \_ [kworker/5:0H-events_highpri]
 41 ?    S  0:00  \_ [cpuhp/6]
 42 ?    S  0:00  \_ [migration/6]
 43 ?    S  0:00  \_ [ksoftirqd/6]
 45 ?    I< 0:00  \_ [kworker/6:0H-events_highpri]
 46 ?    S  0:00  \_ [cpuhp/7]
 47 ?    S  0:00  \_ [migration/7]
 48 ?    S  0:00  \_ [ksoftirqd/7]
 50 ?    I< 0:00  \_ [kworker/7:0H-events_highpri]
 51 ?    S  0:00  \_ [cpuhp/8]
 52 ?    S  0:00  \_ [migration/8]
 53 ?    S  0:00  \_ [ksoftirqd/8]
 55 ?    I< 0:00  \_ [kworker/8:0H-events_highpri]
 65 ?    S  0:00  \_ [kdevtmpfs]
 66 ?    I< 0:00  \_ [netns]
 67 ?    S  0:00  \_ [kauditd]
 69 ?    I  0:00  \_ [kworker/1:2-events]
 70 ?    I  0:00  \_ [kworker/2:1-cgroup_destroy]
 71 ?    I  0:00  \_ [kworker/2:2-events]
 72 ?    S  0:00  \_ [khungtaskd]
 73 ?    S  0:00  \_ [oom_reaper]
 74 ?    I< 0:00  \_ [writeback]
 75 ?    S  0:00  \_ [kcompactd0]
 76 ?    SN 0:00  \_ [ksmd]
 77 ?    SN 0:00  \_ [khugepaged]
 79 ?    I  0:00  \_ [kworker/3:1-events]
 96 ?    I  0:01  \_ [kworker/8:1-events]
 97 ?    I< 0:00  \_ [kintegrityd]
 98 ?    I< 0:00  \_ [kblockd]
 99 ?    I< 0:00  \_ [blkcg_punt_bio]
    100 ?    I< 0:00  \_ [edac-poller]
    101 ?    I< 0:00  \_ [devfreq_wq]
    102 ?    I  0:00  \_ [kworker/3:2-events]
    103 ?    I< 0:00  \_ [kworker/4:1H-kblockd]
    104 ?    I  0:00  \_ [kworker/4:1-events]
    105 ?    S  0:00  \_ [kswapd0]
    106 ?    I< 0:00  \_ [kthrotld]
    107 ?    S  0:00  \_ [irq/24-pciehp]
    108 ?    S  0:00  \_ [irq/25-pciehp]
    109 ?    S  0:00  \_ [irq/26-pciehp]
    110 ?    S  0:00  \_ [irq/27-pciehp]
    111 ?    S  0:00  \_ [irq/28-pciehp]
    112 ?    S  0:00  \_ [irq/29-pciehp]
    113 ?    S  0:00  \_ [irq/30-pciehp]
    114 ?    S  0:00  \_ [irq/31-pciehp]
    115 ?    S  0:00  \_ [irq/32-pciehp]
    116 ?    S  0:00  \_ [irq/33-pciehp]
    117 ?    S  0:00  \_ [irq/34-pciehp]
    118 ?    S  0:00  \_ [irq/35-pciehp]
    119 ?    S  0:00  \_ [irq/36-pciehp]
    120 ?    S  0:00  \_ [irq/37-pciehp]
    121 ?    S  0:00  \_ [irq/38-pciehp]
    122 ?    S  0:00  \_ [irq/39-pciehp]
    123 ?    S  0:00  \_ [irq/40-pciehp]
    124 ?    S  0:00  \_ [irq/41-pciehp]
    125 ?    S  0:00  \_ [irq/42-pciehp]
    126 ?    S  0:00  \_ [irq/43-pciehp]
    127 ?    S  0:00  \_ [irq/44-pciehp]
    128 ?    S  0:00  \_ [irq/45-pciehp]
    129 ?    S  0:00  \_ [irq/46-pciehp]
    130 ?    S  0:00  \_ [irq/47-pciehp]
    131 ?    S  0:00  \_ [irq/48-pciehp]
    132 ?    S  0:00  \_ [irq/49-pciehp]
    133 ?    S  0:00  \_ [irq/50-pciehp]
    134 ?    S  0:00  \_ [irq/51-pciehp]
    135 ?    S  0:00  \_ [irq/52-pciehp]
    136 ?    S  0:00  \_ [irq/53-pciehp]
    137 ?    S  

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 15:36:16 -0500, a ecrit:
> Hi, I am not sure if any desktop login screen is active as no sound is
> played just the boot beep from vmware player.  After the system boots I just
> login using ssh to check if things are running and this is how I found that
> espeakup and pulseaudio are running.

Could you send the output of 

ps axf

?

Samuel

Bug#985666: alsa-utils: no sound after installation

[Nick Gawronski]

Hi, I am not sure if any desktop login screen is active as no sound is 
played just the boot beep from vmware player.  After the system boots I 
just login using ssh to check if things are running and this is how I 
found that espeakup and pulseaudio are running. If anyone has a windows 
10 pro 64 bits system vmware player 16 work station free they can test 
this out.  I had to go into the virtual machine settings under sound 
card to tell the virtual machine to use the system's speakers on the 
internal sound card as if I leave it at auto detect during the 
installation at anytime the speech is lost but the installer is still 
running but if I specify what sound device to use from my usage the 
speech is not lost.  Nick Gawronski


On 3/21/2021 3:14 PM, Samuel Thibault wrote:

Nick Gawronski, le dim. 21 mars 2021 15:07:41 -0500, a ecrit:

pulseaudio is running

Pulseaudio is running? That's odd, I don't see how that could happen. So
you just boot the system, log-in through ssh, and there pulseaudio is
already running without having started anything? (no graphical session
and not even lightdm)

Samuel

Bug#985681: linux-cpupower: Fix Pkg Power tracking on Zen

[Christian Kastner]

Package: linux-cpupower
Version: 5.10.24-1
Severity: normal
Tags: patch

turbostat no longer works with at least some Zen-based systems, it exits
early with code 243.

A trivial fix has been proposed that reportedly works at least for Zen 2
and 3.

I myself have successfully tested it with Zen 2.

The patch has not yet been included upstream (there has been no reply to
it in quite a while), but since it's so trivial, perhaps it could be
included in our package, so that we may get back power statistics for
Zen CPUs.

(This may or may not warrant a higher severity. If Zen 2 belongs to the
officially supported platforms, that it should probably be more severe.)
Author: Kurt Garloff 
Date:   Sat Dec 26 13:00:15 2020 +0100

turbostat: Fix Pkg Power tracking on Zen

AMD Zen processors use a different MSR (MSR_PKG_ENERGY_STAT) than intel
(MSR_PKG_ENERGY_STATUS) to track package power; however we want to record
it at the same offset in our package_data.
offset_to_idx() however only recognized the intel MSR, erroring
out with -13 on Zen.

With this fix, it will support the Zen MSR.
Tested successfully on Ryzen 3000.

Signed-off-by: Kurt Garloff 

Origin: https://lore.kernel.org/lkml/f6143d7a-079d-3f3c-c947-47fc9858a...@debian.org/T/#t

diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
index f3a1746f7f45..eb845421f492 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -325,6 +325,7 @@ int offset_to_idx(int offset)
 	int idx;
 
 	switch (offset) {
+	case MSR_PKG_ENERGY_STAT:
 	case MSR_PKG_ENERGY_STATUS:
 		idx = IDX_PKG_ENERGY;
 		break;

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 15:07:41 -0500, a ecrit:
> pulseaudio is running

Pulseaudio is running? That's odd, I don't see how that could happen. So
you just boot the system, log-in through ssh, and there pulseaudio is
already running without having started anything? (no graphical session
and not even lightdm)

Samuel

Bug#985661: libboost1.71-dev: libboost-dev miss pkg-config .pc file

[Valerio]

Package: libboost1.71-dev
Version: 1.71.0-6~bpo10+1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
install the libboost-dev package
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
pkg-config --libs boost
pkg-config --libs libboost
   * What was the outcome of this action?
Package boost was not found in the pkg-config search path.
   * What outcome did you expect instead?
have a list of dependancies

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libboost1.71-dev depends on:
ii  libstdc++-8-dev [libstdc++-dev]  8.3.0-6

libboost1.71-dev recommends no packages.

Versions of packages libboost1.71-dev suggests:
ii  libboost-atomic1.71-dev   1.71.0-6~bpo10+1
ii  libboost-chrono1.71-dev   1.71.0-6~bpo10+1
pn  libboost-container1.71-dev
pn  libboost-context1.71-dev  
pn  libboost-contract1.71-dev 
pn  libboost-coroutine1.71-dev
ii  libboost-date-time1.71-dev1.71.0-6~bpo10+1
pn  libboost-exception1.71-dev
pn  libboost-fiber1.71-dev
ii  libboost-filesystem1.71-dev   1.71.0-6~bpo10+1
pn  libboost-graph-parallel1.71-dev   
pn  libboost-graph1.71-dev
pn  libboost-iostreams1.71-dev
ii  libboost-locale1.71-dev   1.71.0-6~bpo10+1
pn  libboost-log1.71-dev  
pn  libboost-math1.71-dev 
pn  libboost-mpi-python1.71-dev   
pn  libboost-mpi1.71-dev  
pn  libboost-numpy1.71-dev
pn  libboost-program-options1.71-dev  
pn  libboost-python1.71-dev   
pn  libboost-random1.71-dev   
pn  libboost-regex1.71-dev
ii  libboost-serialization1.71-dev1.71.0-6~bpo10+1
pn  libboost-stacktrace1.71-dev   
ii  libboost-system1.71-dev   1.71.0-6~bpo10+1
pn  libboost-test1.71-dev 
ii  libboost-thread1.71-dev   1.71.0-6~bpo10+1
pn  libboost-timer1.71-dev
pn  libboost-type-erasure1.71-dev 
pn  libboost-wave1.71-dev 
pn  libboost1.71-doc  
pn  libboost1.71-tools-dev
pn  libmpfrc++-dev
pn  libntl-dev

-- no debconf information

Bug#985679: O: gnucobol -- COBOL compiler

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:gnucobol

I am orphaning the gnucobol package.

The package description is:
 GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL
 implements a substantial part of the COBOL 85, COBOL 2002 and COBOL 2014
 standards and X/Open COBOL, as well as many extensions included in other COBOL
 compilers (IBM COBOL, MicroFocus COBOL, ACUCOBOL-GT and others).
 .
 GnuCOBOL translates COBOL into C and compiles the translated code using a
 native C compiler.
 .
 Build COBOL programs on various platforms, including GNU/Linux, Unix, Mac OS X,
 and Microsoft Windows. GnuCOBOL has also been built on HP/UX, z/OS, SPARC,
 RS6000, AS/400, along with other combinations of machines and operating
 systems.
 .
 While being held to a high level of quality and robustness, GnuCOBOL does not
 claim to be a “Standard Conforming” implementation of COBOL.
 .
 GnuCOBOL passes over 9600 of the NIST COBOL 85 test suite tests and over 750
 internal checks during build.

Bug#985678: O: rasdaemon -- utility to receive RAS error tracings

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:rasdaemon

I orphaning the rasdaemon package.

The package description is:
 rasdaemon is a RAS (Reliability, Availability and Serviceability) logging
 tool.  It currently records memory errors, using the EDAC tracing events.
 EDAC are drivers in the Linux kernel that handle detection of ECC errors
 from memory controllers for most chipsets on x86 and ARM architectures.
 This userspace component consists of an init script which makes sure EDAC
 drivers and DIMM labels are loaded at system startup, as well as a utility
 for reporting current error counts from the EDAC sysfs files.

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Harlan Lieberman-Berg]

tag 985675 +moreinfo
thanks

On Sun, Mar 21, 2021 at 3:39 PM Don Armstrong  wrote:
> plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship
> /usr/share/plover/assets/american_english_words.txt, but the latter is
> missing the appropriate Conflicts/Replaces.

Hi Don,

Where have you installed plover-common from?  That's not a package I
recognize in the archive.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream

[Alejandro Lorenzo]

El sábado, 20 de marzo de 2021 19:12:32 (CET) Dmitry Shachnev escribió:
> Control: severity -1 important
> Control: tags -1 - newcomer
> Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-86582
> 
> ¡Hola Alejandro!
> 
> On Thu, Feb 18, 2021 at 11:59:56AM +0100, Alejandro Lorenzo wrote:
> > Package: libqt5widgets5
> > Version: 5.15.2+dfsg-4
> > Severity: critical
> > Tags: upstream newcomer
> > Justification: breaks unrelated software
> > 
> > Dear Maintainer,
> > 
> > Recently i found a bug in QGLWidget (one of the widgets included in
> > libqt5widgets5) that creates a segfault. This bug was accepted as upstream
> > bug 86582
> > 
> > (https://bugreports.qt.io/browse/QTBUG-86582)
> > 
> > It was confirmed and fixed by the Qt people, unfortunately, it has been
> > committed to the 5.15 LTS branch of their development which is no longer
> > accessible to the OpenSource licensees
> > 
> > QGLWidget has been a deprecated Widget for some time now, and many
> > software
> > changed to QOpenGLWidget alternative, which does not exhibit this problem,
> > but other pieces of the debian system (e.g. libqtgstreamer; also
> > deprecated
> > but still in debian repos) uses it.
> 
> Can you please tell if any applications in Debian repos are affected by this
> bug? You mentioned libqtgstreamer but it's a library — do you know if there
> is a concrete application that can be used to reproduce that crash?
> 

If you want to reproduce the crash, you can use a very small concept 
application i submitted to the original bug report upstream. It is a very 
easily compiled application that will trigger the bug.

If the question is about any other software that might trigger this that is 
already in the repos i don't know of any from the top of my mind. 

> It is unlikely that we will be able to fix it, provided that upstream patch
> is not publicly available. So I am downgrading severity to make this bug not
> block the release of Debian Bullseye. This bug does not satisfy the
> criteria for critical anyway, because not the whole libqt5widgets5 library
> is broken, but only a specific use-case of it (which is also a deprecated
> one).

You probably know better than me :D

> Also I am removing the newcomer tag — newcomers won't have enough
> knowledge to be able to fix it.
> 
Ok

Bug#985677: O: acpica-unix -- ACPICA tools for the development and debug of ACPI tables

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:acpica-unix

I am orphaning the acpica-unix package.

The package description is:
 The ACPI Component Architecture (ACPICA) project provides an OS-independent
 reference implementation of the Advanced Configuration and Power Interface
 Specification (ACPI).  ACPICA code contains those portions of ACPI meant to
 be directly integrated into the host OS as a kernel-resident subsystem, and
 a small set of tools to assist in developing and debugging ACPI tables.
 .
 This package contains only the user-space tools needed for ACPI table
 development, not the kernel implementation of ACPI.  The following commands
 are installed:
-- iasl: compiles ASL (ACPI Source Language) into AML (ACPI Machine
   Language), suitable for inclusion as a DSDT in system firmware.
   It also can disassemble AML, for debugging purposes.
-- acpibin: performs basic operations on binary AML files (e.g.,
   comparison, data extraction)
-- acpidump: write out the current contents of ACPI tables
-- acpiexec: simulate AML execution in order to debug method definitions
-- acpihelp: display help messages describing ASL keywords and op-codes
-- acpinames: display complete ACPI name space from input AML
-- acpisrc: manipulate the ACPICA source tree and format source files
   for specific environments
-- acpixtract: extract binary ACPI tables from acpidump output (see
   also the pmtools package)

Bug#985676: Totem is unable to open network streams

[John Scott]

Package: apparmor-profiles-extra
Version: 1.31
Severity: normal
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: buggy-profile modify-profile
Tags: upstream
Control: affects -1 totem

Totem is unable to open network streams due to the AppArmor profile,
but is able them when the profile is disabled. Running
   totem https://www.debian.org
yields
   sh: 1: /usr/lib/x86_64-linux-gnu/libproxy/0.4.17/pxgsettings:
   Permission denied

This causes Totem to fail to open actual network streams and although
it doesn't hang--the UI remains responsive--it does cause a process
called 99-totem-pl-par to consume the CPU even after Totem has been
closed.

This appears to not be addressed by recent changes upstream.

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

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

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.13.6-9

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

-- no debconf information



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

Bug#978450: forwarded

[Łukasz Stelmach]

Control: forwarded -1 https://forum.freecadweb.org/viewtopic.php?t=56149

The problem appears to be fixed in upstream 0.19 AppImage releases.

-- 
Miłego dnia,
Łukasz Stelmach

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Don Armstrong]

Package: plover
Severity: serious
Version: 4.0.0~dev8~66~g685bd33-2

Preparing to unpack .../2-plover_4.0.0~dev8~66~g685bd33-2_all.deb ...
Unpacking plover (4.0.0~dev8~66~g685bd33-2) over (3.0.0-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-P6rk1s/2-plover_4.0.0~dev8~66~g685bd33-2_all.deb 
(--unpack):
 trying to overwrite '/usr/share/plover/assets/american_english_words.txt', 
which is also in package plover-common 3.0.0-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship
/usr/share/plover/assets/american_english_words.txt, but the latter is
missing the appropriate Conflicts/Replaces.

-- 
Don Armstrong  https://www.donarmstrong.com

[T]he question of whether Machines Can Think, [...] is about as
relevant as the question of whether Submarines Can Swim.
 -- Edsger W. Dijkstra "The threats to computing science"

Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility

[Al Stone]

On 21 Mar 2021 20:50, Adrian Bunk wrote:
> On Sun, Mar 21, 2021 at 11:31:45AM -0600, Al Stone wrote:
> > On 21 Mar 2021 14:20, Adrian Bunk wrote:
> > > On Sat, Mar 20, 2021 at 11:06:01AM -0600, Al Stone wrote:
> > > > On 20 Mar 2021 00:09, Ivo De Decker wrote:
> > > > > Control: tags -1 moreinfo
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote:
> > > > > > Please remove the version of gnucobol in unstable.  Per upstream,
> > > > > > this version in not backwards compatible with any prior version.
> > > > > > I made a mistake in packaging it at all.
> > > > > > 
> > > > > > An upload of the proper version (3.1.2) is being prepared.
> > > > > 
> > > > > Removing a package from unstable and then uploading the same package 
> > > > > with a
> > > > > lower version isn't possible. If you want to go back to version 3.x, 
> > > > > you'll
> > > > > need to do an upload with a version higher than the current one.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Ivo
> > > > 
> > > > Understood.  My only option may be to increase the epoch.
> > > 
> > > An epoch is not the only option, and it is the wrong option:
> > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
> > 
> > Why are you assuming I have not read the documentation? ...
> 
> You wrote "My only option", which implied to me that you were not aware 
> of the other option that is actually the recommended option.
> 
> > Or that I do not know that that particular bit of Policy
> > does not exist?  That is precisely why the word "may"
> > was used.
> 
> I'm really getting tired of these sorts of assumptions 
> that everyone is a native English speaker.
> 
> I am not.
> 
> My understanding of "only" is that it means "there is not any other".
> 
> Fancy interactions between the words "only" and "may" are beyond my
> knowledge of the English language.

Yet another assumption.  I taught English as a second language.  I
speak at least two others.  I am very aware of the strangeness of
the English language and write intentionally simple English.  I deal
with this on a daily basis with colleagues from multiple countries.

> > I'm really getting tired of these sorts of assumptions.
> > It would be much more useful to assume good intent on
> > the part of others.
> 
> This is an impossible proposition when it comes across as if the other 
> person is about to make an irreversible mistake, like adding an epoch 
> without first getting consensus on debian-devel.

No, it is not impossible.  You see it as impossible.  I do not.

And, this highlights the problem: you are assuming I do not know
about the need for consensus.  You have no idea what I'm planning
to do next, and you have no idea what I do and do not know.  Yet,
you assume I am going to make a mistake.  All I'm asking is that
you find a way to do as many others do -- assume that people know
what they are doing until proven otherwise.

> cu
> Adrian
> 

-- 
Ciao,
al
--
Al Stone Debian Developer
E-mail: a...@ahs3.nethttp://www.debian.org
 a...@debian.org
--

Bug#985610: unblock (pre-approval): glib2.0/2.66.8-1

[Simon McVittie]

Control: tags -1 - moreinfo

On Sun, 21 Mar 2021 at 18:46:05 +0100, Sebastian Ramacher wrote:
> Thanks, please go ahead and let us know once it reached unstable.

Uploaded to unstable, built on all release architectures except mips*el
(which are pending).

smcv

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

[Adrian Bunk]

On Wed, Mar 17, 2021 at 12:21:24PM -0700, Jonathan Nieder wrote:
>...
>  a. We could add a NEWS.Debian entry to help people see that the path
> changed and recommend using the $(git --exec-path) based incantation

And do a transition with Breaks against the non-migrated versions of 
packages that rely on the current path.

Sounds doable for bookworm, but would also make git in 
bullseye-backports harder to use for users of broken
packages or require backports also of these packages.

>  b. We could move $(git --exec-path) back to /usr/lib/git-core.  After
> all, while the FHS _allows_ libexec nowadays, it does not require
> it.
>...

If this was only done to please lintian, I would vote for that option.

> Thanks,
> Jonathan

cu
Adrian

Bug#985674: CVE-2021-28831

[Moritz Muehlenhoff]

Package: busybox
Version: 1:1.30.1-6+b1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-28831:
https://git.busybox.net/busybox/commit/?id=f25d254dfd4243698c31a4f3153d4ac72aa9e9bd

Cheers,
Moritz

Bug#985673: CVE-2020-15400

[Moritz Muehlenhoff]

Package: cakephp
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

The XSS issue mentioned here was assigned CVE-2020-15400:
https://bakery.cakephp.org/2020/04/18/cakephp_406_released.html

cakephp in bullseye is quite old compared to upstream, is it
still useful, should it be in bullseye?

Cheers,
Moritz

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[maximilian attems]

severity 985632 important
tags 985632 moreinfo
stop

On Sun, Mar 21, 2021 at 09:59:45AM +0900, Ryutaroh Matsumoto wrote:
> Package: firmware-brcm80211
> Version: 20210208-4
> Severity: grave
> Tags: sid bullseye
> Justification: renders package unusable

please provide info on the affected hardware,
also using apropriate bug levels would be nice.

> 5GHz WiFi stopped working with 20210208-4.
> iw wlan0 scan does not show SSID of 5GHz WiFi.
> With 20201218-3, 5GHz worked fine,
> provided that vc4.ko is blacklisted (see #981616).

please show affected dmesg output working and non working,
the difference between 20210208-3 20210208-4 is minimal,
hence it should be easy to find out what broke?

thank you for your report + kind regards,



signature.asc
Description: PGP signature

Bug#985672: unblock: mumps/5.3.5-2

[Drew Parsons]

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

Please unblock package mumps

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]

RC Bug#985514 reports that libmumps64-seq-dev has dangling library
symlinks.  This is because the Depends field of libmumps64-seq-dev
was misconfigured, Depending on libmumps-seq-5.3 instead of
libmumps-64pord-seq-5.3

Release 5.3.5-2 fixes this.

5.3.5-2 also promotes the Standards-Version to 4.5.1

[ Impact ]

The unpatched libmumps64-seq-dev will not function correctly, containing
empty symlinks to the wrong package, unless libmumps-64pord-seq-5.3
happens to be installed (it is supposed to be required)

[ Tests ]

debci tests are passing in testing (bullseye).

[ Risks ]

The patch is trivial, one fix in Depends field of libmumps64-seq-dev,
and update to


[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock mumps/5.3.5-2
diff -Nru mumps-5.3.5/debian/changelog mumps-5.3.5/debian/changelog
--- mumps-5.3.5/debian/changelog2020-10-29 05:11:59.0 +0100
+++ mumps-5.3.5/debian/changelog2021-03-20 04:52:40.0 +0100
@@ -1,3 +1,12 @@
+mumps (5.3.5-2) unstable; urgency=medium
+
+  * Team upload.
+  * libmumps64-seq-dev Depends: libmumps-64pord-seq-5.3
+(not libmumps-seq-dev, libmumps-seq-5.3). Closes: #985514.
+  * Standards-Version: 4.5.1
+
+ -- Drew Parsons   Sat, 20 Mar 2021 04:52:40 +0100
+
 mumps (5.3.5-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru mumps-5.3.5/debian/control mumps-5.3.5/debian/control
--- mumps-5.3.5/debian/control  2020-10-29 05:11:59.0 +0100
+++ mumps-5.3.5/debian/control  2021-03-20 04:52:40.0 +0100
@@ -13,7 +13,7 @@
  libscalapack-mpi-dev (>= 2.0.2),
  libscotch-dev,
  mpi-default-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Vcs-Git: https://salsa.debian.org/science-team/mumps.git
 Vcs-Browser: https://salsa.debian.org/science-team/mumps
 Homepage: http://mumps-solver.org/
@@ -192,8 +192,7 @@
 Depends:
  libmumps64-dev (= ${binary:Version}),
  libmumps-headers-dev (= ${source:Version}),
- libmumps-seq-dev (= ${binary:Version}),
- libmumps-seq-5.3 (= ${binary:Version}),
+ libmumps-64pord-seq-5.3 (= ${binary:Version}),
  ${misc:Depends},
 Description: Direct linear systems solver (64 bit) - non-parallel development 
files
  MUMPS implements a direct solver for large sparse linear systems, with a

Bug#985671: CVE-2020-35636 CVE-2020-35628 CVE-2020-28636 CVE-2020-28601

[Moritz Muehlenhoff]

Source: cgal
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-35636
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225

CVE-2020-35628
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225

CVE-2020-28636
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225

CVE-2020-28601
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225

Cheers,
Moritz  

Bug#985670: CVE-2020-27781 CVE-2020-27839

[Moritz Muehlenhoff]

Package: ceph
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-27781
https://bugs.launchpad.net/manila/+bug/1904015
https://bugzilla.redhat.com/show_bug.cgi?id=1900109
https://github.com/ceph/ceph/commit/1b8a634fdcd94dfb3ba650793fb1b6d09af65e05 
(octopus)
https://github.com/ceph/ceph/commit/7e3e4e73783a98bb07ab399438eb3aab41a6fc8b 
(nautilus)
https://github.com/ceph/ceph/commit/956ceb853a58f6b6847b31fac34f2f0228a70579 
(luminous)

CVE-2020-27839
https://tracker.ceph.com/issues/44591
https://github.com/ceph/ceph/pull/38259
https://github.com/ceph/ceph/commit/23f2604d6f9ac16779b4ac43aab6e4e434f2e8ec

Cheers,
Moritz  

Bug#985666: alsa-utils: no sound after installation

[john doe]

On 3/21/2021 7:50 PM, Samuel Thibault wrote:

Nick Gawronski, le dim. 21 mars 2021 13:45:37 -0500, a ecrit:

What else can I try to see if the sound is working are samples
provided to test with?


You could use aplay from alsa-utils on a .wav file.



In other words, are you able to play any sound on the installed system
(the one you installed without a DE (Mate/Gnome...)).

--
John Doe

Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility

[Adrian Bunk]

On Sun, Mar 21, 2021 at 11:31:45AM -0600, Al Stone wrote:
> On 21 Mar 2021 14:20, Adrian Bunk wrote:
> > On Sat, Mar 20, 2021 at 11:06:01AM -0600, Al Stone wrote:
> > > On 20 Mar 2021 00:09, Ivo De Decker wrote:
> > > > Control: tags -1 moreinfo
> > > > 
> > > > Hi,
> > > > 
> > > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote:
> > > > > Please remove the version of gnucobol in unstable.  Per upstream,
> > > > > this version in not backwards compatible with any prior version.
> > > > > I made a mistake in packaging it at all.
> > > > > 
> > > > > An upload of the proper version (3.1.2) is being prepared.
> > > > 
> > > > Removing a package from unstable and then uploading the same package 
> > > > with a
> > > > lower version isn't possible. If you want to go back to version 3.x, 
> > > > you'll
> > > > need to do an upload with a version higher than the current one.
> > > > 
> > > > Cheers,
> > > > 
> > > > Ivo
> > > 
> > > Understood.  My only option may be to increase the epoch.
> > 
> > An epoch is not the only option, and it is the wrong option:
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
> 
> Why are you assuming I have not read the documentation? ...

You wrote "My only option", which implied to me that you were not aware 
of the other option that is actually the recommended option.

> Or that I do not know that that particular bit of Policy
> does not exist?  That is precisely why the word "may"
> was used.

I'm really getting tired of these sorts of assumptions 
that everyone is a native English speaker.

I am not.

My understanding of "only" is that it means "there is not any other".

Fancy interactions between the words "only" and "may" are beyond my
knowledge of the English language.

> I'm really getting tired of these sorts of assumptions.
> It would be much more useful to assume good intent on
> the part of others.

This is an impossible proposition when it comes across as if the other 
person is about to make an irreversible mistake, like adding an epoch 
without first getting consensus on debian-devel.

cu
Adrian

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 13:45:37 -0500, a ecrit:
> I tried this with both a debian desktop environment and just the
> standard system utilities with the same result.

So this rules out the orca question indeed. Is pulseaudio running on the
installed system? (Normally that shouldn't be happening with a text-only
environment, but better make sure).

> If I try to run espeak with text when connected over ssh all I get is
> some static sounds for about a second.

What do you mean by "static sounds"? What does it sound like?

> What else can I try to see if the sound is working are samples
> provided to test with?

You could use aplay from alsa-utils on a .wav file.

Samuel

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Hello,

Please keep the bug in Cc, so the maintainers of the correspoding
package get the additional information too.

john doe, le dim. 21 mars 2021 19:38:43 +0100, a ecrit:
> On 3/21/2021 7:02 PM, Samuel Thibault wrote:
> > A user reports that although he has sound during installation (using
> > speech synthesis), there is no sound at reboot into the installed
> > system, although it looks like the audio levels seem correct. Any idea?
> > 
> 
> If Espeakup-ng and Orca are started at the same time, that might be
> where the issue lies...

In that case, either one or the other would be working. Nick reported
that none of them was working.

Samuel

Bug#985544: grafx2: the program crashes when selecting an image format

[Gürkan Myczko]

Hi Davide

First, I am sorry for the loss of your puppet, did you make backups or got an 
autosave somewhere or a screenshot?

Could you run
strace grafx2 &> g.log
from a terminal and do the actions needed for the crash?

and post that somewhere?

I will try and check the software tomorrow myself…

Best,

> On Mar 19, 2021, at 17:51, Davide Lombardo  wrote:
> 
> Package: grafx2
> Version: 2.7-1
> Severity: normal
> 
> Dear Maintainer, I was drawing a litte puppet in pixel-art, when I have 
> finished the job
> I wanted to save the image in png format, so I have clicked on the save as
> button. That opened a save picture window dialog; in that window dialog
> there is a format selection cascade menu button which let you select the 
> file image format you wish to save the image on. Every time I select
> an image format from the menu, whatever this image format it is the program 
> suddenly crashes without any explaination. 
> 
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages grafx2 depends on:
> ii  fonts-tuffy  20120614-2.1
> ii  libc62.31-9
> ii  libfontconfig1   2.13.1-4.2
> ii  liblua5.3-0  5.3.3-1.1+b1
> ii  libpng16-16  1.6.37-3
> ii  libsdl2-2.0-02.0.14+dfsg2-3
> ii  libsdl2-image-2.0-0  2.0.5+dfsg1-2
> ii  libsdl2-ttf-2.0-02.0.15+dfsg1-1
> ii  libtiff5 4.2.0-1
> ii  libx11-6 2:1.7.0-2
> ii  zlib1g   1:1.2.11.dfsg-2
> 
> grafx2 recommends no packages.
> 
> grafx2 suggests no packages.
> 
> -- no debconf information
> 

Bug#985669: RFP: pnpm -- Efficent NPM replacement

[Calum McConnell]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com, 
pkg-javascript-de...@lists.alioth.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: pnpm
  Version : 5.18.8
  Upstream Author : Zoltan Kochan 
* URL : https://pnpm.js.org/
* License : MIT
  Programming Lang: Javascript
  Description : Efficent NPM replacement

PNPM is a disk-efficent replacement for the NPM command. It
prevents duplication of package files across projects by hard
linking files to a content-addressed store.  It is a great solution
for developers with limited hard-drive space, or a large number of
projects.

- 

While I would love to package this myself, I do not work with
JavaScript regularally (in part due to ecosystem problems like
NPM's love of duplication).  As such, I am filing this as an RFP,
as opposed to an ITP.



-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAmBXkokdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzI/TxAAsIFoz0j7TLtDJLsi
dN5hbn+SAHg42qDWoWJs5OIkIAWkMOZxT/JIc+KP1dbMM/9nmBYwUHBTAMcK4uwB
DyHEJzRACW4cKsg7oC07O4cq9+7cld25DMpqDyLfOhU1NOO7VT3o94lsCcX17Ntb
Fi5DkdbYEzjVx+/+txM4l6nAMEjF5O3QggnWZwXLpuA8CLiWaLfgcjXSMDNZ37e3
9tNX3gxQd3a7HeLU0ffyhUQ3se1/UfM5jcivGSH6ILn7tV/4ShciVlLPojNYSbIB
vb6GGh2EQFk9CsmEUDZVouDHVDm4A1nNmntnK8x50TIOpUUPJlyCvVUdc+9FYNkb
J3PsD6rwi1wZV9jqpST2gzQi11Q5jFwlc77Gd8cnTQWfwZSSJM309iudHIvoQzeU
mUr6nhKIhWgGih3z/6q2Fvm/dagHE++jm3nhOv7EpXmP9AEXj3CqLGHc0gAXvzyS
zWo6jp+egqqoRlOAPpv6dA6t+egoxQUbgpFgSYRkUdIlttMzywPCI7VFjUT/arp1
D3xNG/O4DeceP0fQhyCWsDxy6fWstiihlw4zj9oP/PHPEqrMv3VQhvJPH7fucgje
vzKV9JztAyps1ppJ4Q2ttVbZMte6HYok+38hSEBOgDYl3tK9L5TjJC4ZDxutP8RZ
AMwHU4KRgQXZWNI8R3MhHok0O7g=
=YNZB
-END PGP SIGNATURE-

Bug#985657: Polyglot's merge-book option doesn't work as expected

[Christian Petersen]

Subject: polyglot: Polyglot's merge-book option doesn't work as expected
Package: polyglot
X-Debbugs-Cc: cpeter...@list.ru
Version: 2.0.4-2+b1
Severity: normal

Hello!

When two books (in bin-format) are merged with polyglot, it's expected
that lines from both of them can be found in the new combined/merged
one. This is not the case: the contents of the second entry are omitted:

pgn1:

[Event "?"]
[Site "?"]
[Date "2021.01.01"]
[Number "1"]
[White "?"]
[Black "?"]
[Result "1/2-1/2"]
[ECO "B74"]
[PlyCount "12"]

1. e4 c5 1/2-1/2

pgn2:

[Event "?"]
[Site "?"]
[Date "2021.01.01"]
[Number "1"]
[White "?"]
[Black "?"]
[Result "1/2-1/2"]
[ECO "A00"]
[PlyCount "12"]

1. g3 e5  1/2-1/2

After doing:
polyglot make-book -pgn 1.pgn -min-game 1 -max-ply 12 -bin 1.bin;
polyglot make-book -pgn 2.pgn -min-game 1 -max-ply 12 -bin 2.bin;
polyglot merge-book -in1 1.bin -in2 2.bin -out combined.bin

the 'g3 e5' entry gets scraped.

This might be the intended behavior though, but the option implies
otherwise.

Upstream has a fix, if this could be considered a malfunction, for this:

http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=polyglot.git;a=snapshot;h=c65fb132a94062b2e346322678f863d582ad9a9a;sf=tgz

(Author of 'Rebel',  E. Schröder reported this in the first place)

Thank you.


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages polyglot depends on:
ii  libc6  2.31-9

Versions of packages polyglot recommends:
ii  stockfish  12-2

polyglot suggests no packages.

-- no debconf information

Bug#984956: Me too

[sixerjman]

I am hit by this bug also. Going to try and learn SLURM in the meantime. Is
there
any progress? Thank you for your work on this excellent package.

Bug#985668: Undefined symbol in libfontmanager.so

[Yuri D'Elia]

Package: openjdk-17-jre-headless
Version: 17~14-1
Severity: normal

Just tried to run "josm" on openjdk-17, but I get the following error:

021-03-21 19:27:07.757 SEVERE: Handled by bug report queue: 
java.lang.UnsatisfiedLinkError: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined symbol: 
hb_font_destroy
java.lang.UnsatisfiedLinkError: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined symbol: 
hb_font_destroy

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-17-jre-headless:amd64 depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-10
ii  libcups2  2.3.3op2-3
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-7
ii  zlib1g1:1.2.11.dfsg-2

openjdk-17-jre-headless:amd64 recommends no packages.

Versions of packages openjdk-17-jre-headless:amd64 suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

Bug#985667: pkgconf: make use of personalities to replace the cross wrapper

[Andrej Shadura]

Source: pkgconf
Severity: wishlist

Since pkgconf added support for personalities [1], it is now possible to
implement cross support without pkgconf-cross-wrapper and most of the
related machinery.

[1]: https://manpages.debian.org/buster/pkgconf/pkgconf-personality.5.en.html

-- 
Cheers,
  Andrej

Bug#985644: libgssapi-krb5-2: properly dispose of /etc/gss/mech.d/README on upgrades

[Sam Hartman]

control: tags -1 wontfix

This is a duplicate of a wontfix bug.
Don't have time to go look up the other bug now.

Bug#985661: libboost1.71-dev: libboost-dev miss pkg-config .pc file

[Valerio Messina]

my current use case is:

1) I need to check for libboost-dev >= 1.71
pkg-config is good in this

2) libboost 1.7x seems require libpthread
so I expect boost.pc will report it as dependancy or, as pthread is a 
virtual package, at least the link option -lpthread is listed


--
Valerio

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Package: alsa-utils
Version: 1.2.4-1

Hello,

A user reports that although he has sound during installation (using
speech synthesis), there is no sound at reboot into the installed
system, although it looks like the audio levels seem correct. Any idea?

Samuel

Nick Gawronski, le mer. 17 mars 2021 19:34:24 -0500, a ecrit:
> # amixer -c 0 scontents
> Simple mixer control 'Master',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Mono:
>   Front Left: Playback 49 [78%] [-21.00dB] [on]
>   Front Right: Playback 49 [78%] [-21.00dB] [on]
> Simple mixer control 'PCM',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Mono:
>   Front Left: Playback 23 [37%] [0.00dB] [on]
>   Front Right: Playback 23 [37%] [0.00dB] [on]
> Simple mixer control 'Line',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'CD',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Mic',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [on]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [on]
> Simple mixer control 'Mic Boost (+20dB)',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Video',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Phone',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'IEC958',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Aux',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Capture',0
>   Capabilities: cvolume cswitch cswitch-joined
>   Capture channels: Front Left - Front Right
>   Limits: Capture 0 - 15
>   Front Left: Capture 8 [53%] [12.00dB] [on]
>   Front Right: Capture 8 [53%] [12.00dB] [on]
> Simple mixer control 'Mix',0
>   Capabilities: cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Capture channels: Front Left - Front Right
>   Front Left: Capture [off]
>   Front Right: Capture [off]
> Simple mixer control 'Mix Mono',0
>   Capabilities: cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Capture channels: Front Left - Front Right
>   Front Left: Capture [off]
>   Front Right: Capture [off]

Bug#985054: coturn: fails to purge: rmdir: failed to remove '/var/lib/turn': No such file or directory

[wferi]

wf...@niif.hu writes:

> Andreas Beckmann  writes:
>
>> According to policy 7.2 you cannot rely on the depends being available
>> during purge, only the essential packages are available for sure.
>
> I can't see coturn rely on any of its dependencies during purge, do you?

Hi Andreas,

Have you got anything to add here?

>> (this was observed in a piuparts nodocs test)
>
> Could you please explain to me what a "nodocs" test is?

I read through the Salsa repo, I get it now.

> Since the postinst creates /var/lib/turn/turndb if it doesn't exist,
> I've got no idea how /var/lib/turn can be missing during purge.

Now I understand: it's created only if the needed schema file is
present.  Unfortunately it's used from under /usr/share/doc.  I'll
upload a fix shortly.
-- 
Thanks,
Feri

Bug#763982:

[Fabio Pedretti]

Currently both zlib and Intel zlib are no longer actively developed,
however there is zlib-ng with optimization for many architectures:
https://github.com/zlib-ng/zlib-ng

Bug#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream

[Dmitry Shachnev]

Control: reassign -1 libqt5opengl5 5.15.2+dfsg-4

On Sun, Mar 21, 2021 at 05:05:53PM +0100, Alejandro Lorenzo wrote:
> If you want to reproduce the crash, you can use a very small concept
> application i submitted to the original bug report upstream. It is a very
> easily compiled application that will trigger the bug.
>
> If the question is about any other software that might trigger this that is
> already in the repos i don't know of any from the top of my mind.

No, I wanted not to reproduce the crash, but to assess the impact of this bug.
If it happens just with your own application, then you should really port it
away from QGLWidget. If it happened also with some package from Debian, we
would have to fix either that package or Qt.

By the way, QGLWidget is provided by Qt OpenGL module, not Qt Widgets, so I am
also reassigning this bug. (Qt Widgets module has QOpenGLWidget which is the
recommended replacement.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#985665: fish: new upstream release 3.2.1

[Patrice Duroux]

Package: fish
Version: 3.1.2-3
Severity: wishlist

Dear Maintainer,

A new upstream version is available and detectable after applying the attached
patch to d/watch.

Thanks!

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
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 fish depends on:
ii  bc  1.07.1-2+b2
ii  chromium [www-browser]  89.0.4389.90-1
ii  dpkg1.20.7.1
ii  firefox [www-browser]   86.0.1-1
ii  firefox-esr [www-browser]   78.8.0esr-1
ii  fish-common 3.1.2-3
ii  google-chrome-stable [www-browser]  89.0.4389.90-1
ii  libc6   2.31-10
ii  libpcre2-32-0   10.36-2
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  lynx [www-browser]  2.9.0dev.6-2
ii  man-db  2.9.4-2
ii  python3 3.9.2-2
ii  python3-distutils   3.9.2-1
ii  vivaldi-stable [www-browser]3.7.2218.45-1

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  
diff --git a/debian/watch b/debian/watch
index 8c940ba..5c09a51 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
 opts="pgpsigurlmangle=s%$%.asc%" \
https://github.com/fish-shell/fish-shell/releases \
-   (?:.*?)/fish-(\d[\d.]*)\.tar\.gz debian
+   (?:.*?)/fish-(\d[\d.]*)@ARCHIVE_EXT@ debian

Bug#985610: unblock (pre-approval): glib2.0/2.66.8-1

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-03-20 21:58:39 +, Simon McVittie wrote:
> On Sat, 20 Mar 2021 at 17:08:14 +, Simon McVittie wrote:
> >   [x] attach debdiff against the package in testing
> >   (as with the recent mutter and gnome-shell unblocks, to minimize
> >   noise this is a diff between patched trees, excluding the patches
> >   themselves)
> 
> Sorry, really attached now.

Thanks, please go ahead and let us know once it reached unstable.

Cheers

> 
> smcv

> git diff archive/debian/2.66.7-2..patch-queue/debian/master | filterdiff -p1 
> --exclude 'debian/patches/*.patch'
> 
> diff --git a/NEWS b/NEWS
> index 0f0a6a28b..d4a4703d2 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,15 @@
> +Overview of changes in GLib 2.66.8
> +==
> +
> +* Fix a security issue when using `g_file_replace()` with
> +  `G_FILE_CREATE_REPLACE_DESTINATION` (#2325)
> +
> +* Bugs fixed:
> + - #2325 file-roller symlink attack
> + - !1982 Backport !2325 “file-roller symlink attack” to glib-2-66
> + - !1990 Backport !1976 “Use the right permissions for directory watching on 
> Win32” to glib-2-66
> +
> +
>  Overview of changes in GLib 2.66.7
>  ==
>  
> diff --git a/debian/changelog b/debian/changelog
> index eefd875a6..80c0657ef 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,23 @@
> +glib2.0 (2.66.8-1) unstable; urgency=medium
> +
> +  * d/watch: Only watch for 2.66.x versions.
> +2.68.0 has been released but will not be in bullseye.
> +  * New upstream release
> +- Functionally equivalent to 2.66.7-2, except for the version number
> +  and a change to Windows-specific code that is not used in Debian
> +  * Drop patches that were included in the new upstream release
> +  * d/p/glocalfileoutputstream-Tidy-up-error-handling.patch:
> +Add patch from upstream to clean up error handling.
> +After the fix for #984969, this function could end up calling close(-1),
> +which is harmless but gets flagged as an error by static analysis and
> +by error-checking instrumentation. Fixing this will prevent it from
> +obscuring real errors.
> +  * Add CVE references in recent changelog entries.
> +CVE IDs for the vulnerabilities were not available at the time they were
> +fixed, but now they are.
> +
> + -- Simon McVittie   Sat, 20 Mar 2021 15:35:19 +
> +
>  glib2.0 (2.66.7-2) unstable; urgency=medium
>  
>* d/changelog: Add bug numbers for integer overflows in previous versions
> @@ -6,7 +26,7 @@ glib2.0 (2.66.7-2) unstable; urgency=medium
>  replace a path that is a dangling symlink, previously it would have also
>  created the target of the symlink as an empty file, which could
>  conceivably be security-sensitive if the symlink is attacker-controlled.
> -(Closes: #984969)
> +(Closes: #984969; CVE-2021-28153)
>  
>   -- Simon McVittie   Thu, 11 Mar 2021 10:23:38 +
>  
> @@ -16,7 +36,7 @@ glib2.0 (2.66.7-1) unstable; urgency=high
>  - Fix another regression caused by the GHSL-2021-045 fixes in 2.66.6
>  - Warn and fail on integer overflow in g_byte_array_new_take()
>for arrays larger than G_MAXUINT
> -  (Closes: #982779; similar to GHSL-2021-045)
> +  (Closes: #982779; CVE-2021-27218)
>  - Disallow using currently-undefined D-Bus connection or server flags,
>to prevent forward-compatibility problems with new security-sensitive
>flags that are likely to be introduced in GLib 2.68
> @@ -41,7 +61,7 @@ glib2.0 (2.66.6-1) unstable; urgency=high
>  
>* New upstream release
>  - Fix various integer overflows, some of them potentially exploitable
> -  (Closes: #982778, GHSL-2021-045)
> +  (Closes: #982778; CVE-2021-27219, GHSL-2021-045)
>  
>   -- Simon McVittie   Thu, 04 Feb 2021 20:24:20 +
>  
> diff --git 
> a/debian/patches/glocalfileoutputstream-Tidy-up-error-handling.patch 
> b/debian/patches/glocalfileoutputstream-Tidy-up-error-handling.patch
> new file mode 100644
> index 0..04f040d40
> diff --git a/debian/patches/series b/debian/patches/series
> index 772de8095..8e7842b2f 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -1,10 +1,6 @@
> -glocalfileoutputstream-Fix-a-typo-in-a-comment.patch
> -tests-Stop-using-g_test_bug_base-in-file-tests.patch
> -glocalfileoutputstream-Factor-out-a-flag-check.patch
> -glocalfileoutputstream-Fix-CREATE_REPLACE_DESTINATION-wit.patch
> -glocalfileoutputstream-Add-a-missing-O_CLOEXEC-flag-to-re.patch
>  glib-tests-fileutils-Make-more-use-of-g_assert_no_errno.patch
>  glib-tests-fileutils-Fix-expectations-when-running-as-roo.patch
> +glocalfileoutputstream-Tidy-up-error-handling.patch
>  01_gettext-desktopfiles.patch
>  0001-timer-test-use-volatile-for-locals.patch
>  gwakeuptest-Be-less-parallel-unless-invoked-with-m-slow.patch
> diff --git a/debian/watch b/debian/watch
> index f028879b9..5a5e3cbab 100644
> --- a/debian/watch
> 

Bug#985661: libboost1.71-dev: libboost-dev miss pkg-config .pc file

[Valerio Messina]

I saw was already requested in 2004:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674

but that bug seems dead.

At that time, pkg-config was not so common, today is another story

--
Valerio

Bug#985663: utf-8 decoding error

[Joey Hess]

Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20210225.1e7ef9e+dfsg-3
Severity: normal

 Copy message UID -347 (1/347) local: -> kite:INBOX
 ERROR: Copying message -347 [acc: joey]
  'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte
 ERROR: while syncing  [account joey]
  'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte
 ERROR: ERROR in syncfolder for joey folder : Traceback (most recent call last):
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 666, in 
syncfolder
localfolder.syncmessagesto(remotefolder, statusfolder)
  File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 1186, in 
syncmessagesto
action(dstfolder, statusfolder)
  File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 1013, in 
__syncmessagesto_copy
self.copymessageto(uid, dstfolder, statusfolder, register=0)
  File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 902, in 
copymessageto
message = self.getmessage(uid)
  File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 262, in 
getmessage
retval = file.read()
  File "/usr/lib/python3.9/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 3278: 
invalid start byte

  'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte

This seems the same as bug #981485 but I've upgraded to this version
that is supposed to fix that, and still happening.

It's not clear to me which message is causing the problem. Especially
since it seems to be trying to upload a message from inbox, but I normally
don't make changes to inbox that would need to upload a new message.

(I'm very surprised that offlineimap would be concerning itself with the
encoding of emails at all.)

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

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

Versions of packages offlineimap depends on:
ii  offlineimap3  0.0~git20210105.00d395b+dfsg-3

offlineimap recommends no packages.

offlineimap suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#925591: grub-install fails on raid1+efi setup

[Giorgio Bonfiglio]

Just stumbled upon this after converting a system from Legacy Boot to 
UEFI (boot into live, sort out partitions, remove grub-pc, install 
grub-efi, reboot, reconfigure bios).

After running `apt install grub-efi` and rebooting, although the former 
fails with the error mentioned above, debian correctly shows up in my 
boot menu and I can boot from it.

This is the partition tree on my boot devices:

nvme0n1 259:0    0 119.2G  0 disk
├─nvme0n1p1 259:2    0   512M  0 part
│ └─md10  9:10   0   512M  0 raid1 /boot/efi
├─nvme0n1p2 259:3    0   512M  0 part
│ └─md11  9:11   0   511M  0 raid1 /boot
└─nvme0n1p3 259:4    0 118.2G  0 part
   └─md12  9:12   0 118.2G  0 raid1
     └─nvme-root 253:0    0    25G  0 lvm   /
nvme1n1 259:1    0 119.2G  0 disk
├─nvme1n1p1 259:5    0   512M  0 part
│ └─md10  9:10   0   512M  0 raid1 /boot/efi
├─nvme1n1p2 259:6    0   512M  0 part
│ └─md11  9:11   0   511M  0 raid1 /boot
└─nvme1n1p3 259:7    0 118.2G  0 part
   └─md12  9:12   0 118.2G  0 raid1
     └─nvme-root 253:0    0    25G  0 lvm   /

I ended up cleaning UEFI's config up and adding the second drive to the 
boot sequence with:

efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Debian nvme0n1" -l 
\\EFI\\debian\\grubx64.efi
efibootmgr -c -d /dev/nvme1n1 -p 1 -L "Debian nvme1n1" -l 
\\EFI\\debian\\grubx64.efi

Although everything seems to be working as it should, it would be good 
if `grub2-install` could handle this to prevent unexpected 
errors/failures during installation, upgrades or even just minor updates.

Firmware info requested above (although I'm fairly sure this is not 
firmware-specific):

     Vendor: American Megatrends Inc.
     Version: 1.3
     Release Date: 11/25/2020
     Address: 0xF
     Runtime Size: 64 kB
     ROM Size: 32 MB
     [...]
     BIOS Revision: 5.14

-- 
Giorgio Bonfiglio

www: grg.pw
email: m...@grg.pw

Bug#985645: hurd: Hurd creates buggy core files or gdb cannot read core files properly

[Samuel Thibault]

Svante Signell, le dim. 21 mars 2021 11:47:14 +0100, a ecrit:
> Example session:
> host ftp.sunet.se
> ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
> sunet.ftp.acc.umu.se has address 194.71.11.173
> sunet.ftp.acc.umu.se has address 194.71.11.165
> socket.c:3175: REQUIRE(readable || writeable) failed, back trace
> #0 0x1337666 in ??
> #1 0x1337595 in ??
> #2 0x137e3d5 in ??
> #3 0x1372d1c in ??
> #4 0x13e782f in ??

So bind9 itself doesn't find its own symbols.  I'm then not surprised
that gdb can't either. Trying a trivial example:

int main(void) {  *(int*) 0 = 0; }

gives

€ gdb ./test core
[...]
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Unexpected size of section `.reg2/903' in core file.
#0  main () at test.c:5
5   *(int*) 0 = 0;

So it seems to work at least basically.

Samuel

Bug#985662: unblock: gimp/2.10.22-3

[Laurent Bigonville]

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

Please unblock package gimp

[ Reason ]
gimp now needs a hard dependency on graphviz as it uses an optional
feature of libgegl that requires the "dot" executable. Adding an hard
dependency on graphviz in libgegl package looks overkill as the other
packages dont seem to use that feature.

I also added a patch that define PATH_MAX for hurd, this is not changing
anything on the release architectures.

[ Impact ]
Without the graphviz package installed, gimp fails to start

[ Tests ]
Gimp now starts, this has been confirmed by some users.

[ Risks ]
Adding the dependency has no risk

PATH_MAX should already be defined in all other architectures than hurd,
so there is also no risks possible here either

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
This has been reported multiple times on the r/debian subreddit, so
there are actuall users impacted by this

unblock gimp/2.10.22-3
diff -Nru gimp-2.10.22/debian/changelog gimp-2.10.22/debian/changelog
--- gimp-2.10.22/debian/changelog   2020-11-24 10:25:51.0 +0100
+++ gimp-2.10.22/debian/changelog   2021-03-20 12:21:08.0 +0100
@@ -1,3 +1,13 @@
+gimp (2.10.22-3) unstable; urgency=medium
+
+  * debian/control.in: Add graphviz to the dependencies.
+Some optional functionality of libgegl used in gimp now requires the dot
+executable shipped in the graphviz package (Closes: #985317)
+  * debian/patches/02_hurd_ftbfs.patch: Fix FTBFS on hurd-i386.
+Thanks to Svante Signell  (Closes: #934077)
+
+ -- Laurent Bigonville   Sat, 20 Mar 2021 12:21:08 +0100
+
 gimp (2.10.22-2) unstable; urgency=medium
 
   * Team upload
diff -Nru gimp-2.10.22/debian/control gimp-2.10.22/debian/control
--- gimp-2.10.22/debian/control 2020-11-24 10:25:51.0 +0100
+++ gimp-2.10.22/debian/control 2021-03-20 12:21:08.0 +0100
@@ -6,7 +6,7 @@
 Priority: optional
 Section: graphics
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Iain Lane , Jeremy Bicha , Ari 
Pollak 
+Uploaders: Iain Lane , Jeremy Bicha , 
Laurent Bigonville , Ari Pollak 
 Build-Depends: debhelper-compat (= 13),
desktop-file-utils ,
dh-sequence-gnome,
@@ -74,6 +74,7 @@
  libgimp2.0 (<= ${source:Upstream-Version}-z),
  gimp-data (>= ${source:Upstream-Version}),
  gimp-data (<= ${source:Upstream-Version}-z),
+ graphviz,
  xdg-utils,
  ${shlibs:Depends},
  ${misc:Depends}
diff -Nru gimp-2.10.22/debian/control.in gimp-2.10.22/debian/control.in
--- gimp-2.10.22/debian/control.in  2020-11-24 10:25:51.0 +0100
+++ gimp-2.10.22/debian/control.in  2021-03-20 12:21:08.0 +0100
@@ -70,6 +70,7 @@
  libgimp2.0 (<= ${source:Upstream-Version}-z),
  gimp-data (>= ${source:Upstream-Version}),
  gimp-data (<= ${source:Upstream-Version}-z),
+ graphviz,
  xdg-utils,
  ${shlibs:Depends},
  ${misc:Depends}
diff -Nru gimp-2.10.22/debian/patches/02_hurd_ftbfs.patch 
gimp-2.10.22/debian/patches/02_hurd_ftbfs.patch
--- gimp-2.10.22/debian/patches/02_hurd_ftbfs.patch 1970-01-01 
01:00:00.0 +0100
+++ gimp-2.10.22/debian/patches/02_hurd_ftbfs.patch 2021-03-20 
12:21:08.0 +0100
@@ -0,0 +1,12 @@
+--- a/plug-ins/common/qbist.c
 b/plug-ins/common/qbist.c
+@@ -38,6 +38,9 @@
+ 
+ #include "libgimp/stdplugins-intl.h"
+ 
++#ifndef PATH_MAX
++#define PATH_MAX 4096
++#endif
+ 
+ /** qbist renderer 
***/
+ 
diff -Nru gimp-2.10.22/debian/patches/series gimp-2.10.22/debian/patches/series
--- gimp-2.10.22/debian/patches/series  2020-11-24 10:25:51.0 +0100
+++ gimp-2.10.22/debian/patches/series  2021-03-20 12:21:08.0 +0100
@@ -1 +1,2 @@
 01_hurd_ftbfs.patch
+02_hurd_ftbfs.patch

Bug#985654: dovecot-fts-xapian: Does not index attachments

[Andre Rodier]

Package: dovecot-fts-xapian
Version: 1.4.7-1
Severity: important

The version included (1.4.7) contains an important bug that prevents 
attachments to be indexed. This is now fixed in version 1.4.8.

https://github.com/grosjo/fts-xapian/issues/68

> doveadm(camille): Info: FTS Xapian: Unknown header (indexing) 
> 'contentdescription'
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_update_set_build_key
> doveadm(camille): Info: FTS Xapian: New part 
> (Header=Content-Disposition,Type=(null),Disposition=(null))
> doveadm(camille): Info: FTS Xapian: Unknown header (indexing) 
> 'contentdisposition'
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_update_set_build_key
> doveadm(camille): Info: FTS Xapian: New part 
> (Header=Content-Transfer-Encoding,Type=(null),Disposition=(null))
> doveadm(camille): Info: FTS Xapian: Unknown header (indexing) 
> 'contenttransferencoding'
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_update_set_build_key
> doveadm(camille): Info: FTS Xapian: New part 
> (Header=(null),Type=text/csv,Disposition=attachment; filename="file.csv")
> doveadm(camille): Info: FTS Xapian: Skipping part of type 'text/csv' and 
> disposition 'attachment; filename="file.csv"'
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_update_set_mailbox
> doveadm(camille): Info: FTS Xapian: Unset box 'INBOX' 
> (c0d4e304584e5460dae3075d7e67)
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_oldbox
> doveadm(camille): Info: FTS Xapian: Done indexing 'INBOX' 
> (c0d4e304584e5460dae3075d7e67) (13 msgs in 261 ms, rate: 49.8)
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_release (unset_box)
> doveadm(camille): Info: FTS Xapian: Committed 'unset_box' in 17 ms
> doveadm(camille): Info: FTS Xapian: Box is empty
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_update_deinit 
> (/home/users/camille/mails/indexes/xapian-indexes)
> doveadm(camille): Info: FTS Xapian: fts_backend_xapian_release (update_deinit)
> doveadm(camille): Info: FTS Xapian: Committed 'update_deinit' in 0 ms
> doveadm(camille): Info: FTS Xapian: Deinit 
> /home/users/camille/mails/indexes/xapian-indexes)

The interesting line is this one:

> doveadm(camille): Info: FTS Xapian: Skipping part of type 'text/csv' and 
> disposition 'attachment; filename="file.csv"'

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dovecot-fts-xapian depends on:
ii  libc62.31-9
ii  libgcc-s110.2.1-6
ii  libicu67 67.1-6
ii  libstdc++6   10.2.1-6
ii  libxapian30  1.4.18-3

dovecot-fts-xapian recommends no packages.

dovecot-fts-xapian suggests no packages.

-- no debconf information

Bug#983702: voltron: Update package with new upstream release

[Thomas Nyberg]

Package: voltron
Version: 0.1.7+git20200109-1
Followup-For: Bug #983702

Dear Maintainer,

I am attaching a patch.

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

Kernel: Linux 5.11.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages voltron depends on:
ii  python3  3.9.2-2
ii  python3-blessed  1.17.12-1
ii  python3-flask1.1.2-2
ii  python3-flask-restful0.3.8-5
ii  python3-pygments 2.7.1+dfsg-2
ii  python3-requests 2.25.1+dfsg-2
ii  python3-requests-unixsocket  0.2.0-2
ii  python3-scruffy  0.3.3-2
ii  python3-six  1.15.0-2

voltron recommends no packages.

voltron suggests no packages.

-- no debconf information

On 3/3/21 8:34 PM, Andrey Rahmatullin wrote:

Control: retitle -1 Doesn't work with current werkzeug
COntrol: tags -1 + upstream fixed-upstream patch

On Sun, Feb 28, 2021 at 05:52:23PM +0100, Thomas Nyberg wrote:

The reason seems to be that the debian testing packaged version of werkzeug is
1.0.1 while the packaged version of voltran does not support it. There is a
commit in the upstream repo that solves this problem:

 
https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a

Unfortunately that commit is not included in an official release. I'm unsure if
that is required for it to be packaged with debian. Regardless, the older
version does not work as packaged (though the required changes are admittedly
quite minor).

Assuming this patch fixes the problem, the correct way will be to apply it
to the current version and upload it.

Description: Update for backwards-incompatibe werkzeug api changes

Apply upsteam patch dealing with backwards-incompatible werkzeug changes.

Origin: 
https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a
Bug: https://bugs.debian.org/983702
Bug-Debian: https://bugs.debian.org/983702
Last-Update: 2021-03-21

Author: Thomas Nyberg 

--- voltron-0.1.7+git20200109.orig/voltron/core.py
+++ voltron-0.1.7+git20200109/voltron/core.py
@@ -15,7 +15,8 @@ import six
 import voltron
 from flask import Flask, Response, make_response, redirect, render_template, 
request
 from werkzeug.serving import BaseWSGIServer, ThreadedWSGIServer, 
WSGIRequestHandler
-from werkzeug.wsgi import DispatcherMiddleware, SharedDataMiddleware
+from werkzeug.middleware.dispatcher import DispatcherMiddleware
+from werkzeug.middleware.shared_data import SharedDataMiddleware
 from requests import ConnectionError
 
 

Bug#984136: fplll: ftbfs with GCC-11

[Nilesh Patra]

control: tags -1 patch

Fixed in the commit:

https://salsa.debian.org/science-team/fplll/-/commit/af75e051c4ffd116b0d7ed0eb1e38dacee913123

and can be uploaded post bullseye release.

Nilesh

Bug#985543: yubikey-luks: after upgrade and reboot - yubikey "not detected" (but blinking)

[Daniel Hevron Pereh]

  
  
On Sat, 20 Mar 2021 12:29:56 -0400 Jerome Charaoui
 wrote:
> user debian-rele...@lists.debian.org
> usertags 985543 + bsp-2021-03-ca-montreal
> tag 985543 + unreproducible moreinfo
> thank you
> 
> Hello,
> 
> I've attempted, but was unable, to reproduce this bug.
> 
> I set up the yubikey-luks challenge-response on a fresh stretch
system, 
> and after upgrading to bullseye, it was working as before,
which 
> suggests the package is working as intended even after a
release upgrade.
> 
> I'm wondering if your bug could actually be related to an
update in the 
> kernel or usb subsystem itself, rather than the yubikey-luks
package?
> 
> Did you try booting up using a live system such as Grml and
trying to 
> unlock your luks filesystem manually in that environment?
> 
> Thanks.
> 
> 



Hi,


First of all thank you for your afford!


I successfully managed to unlock my LUKS partition by generating
  the response on a different machine (with package 'ykpersonalize'
  using the command 'ykchalresp') and typing it manually. the system
  was updated as I thought. 


My system recognized my yubikey when it was unlocked and I could
  do the usual operation I'm using it for. the chalresp OTP slot
  works as usual as well for other oprations. 


Tried to do another update and rebooted the system, still no luck
  with the yubikey itself. 


As for your suggestion, I'll try to unlock it with the
  yubikey-luks package on a live system and report back.


thank you very much,
Daniel

  




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985543: yubikey-luks: after upgrade and reboot - yubikey "not detected" (but blinking)

[Daniel Hevron Pereh]

  
  
Hi,


First of all thank you for your afford!


I successfully managed to unlock my LUKS partition by generating
  the response on a different machine (with package 'ykpersonalize'
  using the command 'ykchalresp') and typing it manually. the system
  was updated as I thought. 


My system recognized my yubikey when it was unlocked and I could
  do the usual operation I'm using it for. the chalresp OTP slot
  works as usual as well for other oprations. 


Tried to do another update and rebooted the system, still no luck
  with the yubikey itself. 


As for your suggestion, I'll try to unlock it with the
  yubikey-luks package on a live system and report back.


thank you very much,
Daniel

  




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985660: libgazebo-dev built against wrong libprotobuf-dev version

[Timon Engelke]

Package: libgazebo-dev
Version: 11.1.0+dfsg-4+b3
Severity: important

Dear Maintainer,

I am building the gazebo_ros package from source, using libgazebo-dev header
files. When building, I get the following compiler error:

/usr/include/gazebo-11/gazebo/msgs/vector2d.pb.h:56:51: error: no type named
'AuxiliaryParseTableField' in namespace 'google::protobuf::internal'; did you
mean 'AuxillaryParseTableField'?
  static const ::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField
aux[]
   ~~~^
/usr/include/google/protobuf/generated_message_table_driven.h:141:7: note:
'AuxillaryParseTableField' declared here
union AuxillaryParseTableField {
  ^

The fix for the typo, i.e. changing Auxillary to Auxiliary, is in this commit
in the protobuf source:
https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b
.
It is included in all releases of protobuf since v3.13.0 and it is also
included in v3.12.3 due to a wrongly tagged release
(https://github.com/protocolbuffers/protobuf/issues/7632). Notably, it is not
included in version 3.12.4. You can see that the typo is still in the source
code for v3.12.4 here:
https://github.com/protocolbuffers/protobuf/blob/v3.12.4/src/google/protobuf/generated_message_table_driven.h#L141
.
Version 3.12.4 is also the current version of protobuf on Debian Testing.
Therefore, libgazebo-dev and libprotobuf-dev are currently incompatible and,
unless I'm missing something, libgazebo-dev should probably be rebuilt against
version 3.12.4 of libprotobuf-dev.


Sincerely
Timon Engelke


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

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

Versions of packages libgazebo-dev depends on:
ii  fonts-dejavu-core   2.37-2
ii  fonts-liberation1:1.07.4-11
ii  freeglut3-dev   2.8.1-6
ii  gazebo-common   11.1.0+dfsg-4
ii  gazebo-plugin-base  11.1.0+dfsg-4+b3
ii  libavcodec-dev  7:4.3.2-0+deb11u1
ii  libavformat-dev 7:4.3.2-0+deb11u1
ii  libboost-dev1.74.0.3
ii  libbullet-dev   3.06+dfsg-4
ii  libcurl4-openssl-dev [libcurl-dev]  7.74.0-1.1
ii  libdart-dev 6.9.5-3
ii  libfreeimage-dev3.18.0+ds2-6
ii  libgazebo11 11.1.0+dfsg-4+b3
ii  libgdal-dev 3.2.1+dfsg-1+b1
ii  libignition-fuel-tools-dev  4.1.0+dfsg-5+b4
ii  libignition-math-dev6.7.0+ds-3
ii  libignition-msgs-dev5.1.0+dfsg-7
ii  libignition-transport-dev   8.0.0+dfsg-3+b2
ii  libogre-1.9-dev 1.9.0+dfsg1-12.1
ii  libprotobuf-dev 3.12.4-1
ii  libprotoc-dev   3.12.4-1
ii  libqwt-qt5-dev  6.1.4-2
ii  libsdformat-dev 9.3.0+ds-3
ii  libsimbody-dev  3.6.1+dfsg-7
ii  libswscale-dev  7:4.3.2-0+deb11u1
ii  libtar-dev  1.2.20-8+b1
ii  libtbb-dev  2020.3-1
ii  libxml2-dev 2.9.10+dfsg-6.3+b1
ii  qtbase5-dev 5.15.2+dfsg-5

libgazebo-dev recommends no packages.

libgazebo-dev suggests no packages.

Bug#985659: petsc3.14-doc: broken symlinks: /usr/share/doc/petsc3.14-doc/html/_static/*.js -> ../../../../sphinx/themes/basic/static/*.js

[Andreas Beckmann]

Package: petsc3.14-doc
Version: 3.14.5+dfsg1-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m13.5s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/petsc3.14-doc/html/_static/underscore.js -> 
../../../../sphinx/themes/basic/static/underscore.js (petsc3.14-doc)
  /usr/share/doc/petsc3.14-doc/html/_static/searchtools.js -> 
../../../../sphinx/themes/basic/static/searchtools.js (petsc3.14-doc)
  /usr/share/doc/petsc3.14-doc/html/_static/jquery.js -> 
../../../../sphinx/themes/basic/static/jquery.js (petsc3.14-doc)
  /usr/share/doc/petsc3.14-doc/html/_static/doctools.js -> 
../../../../sphinx/themes/basic/static/doctools.js (petsc3.14-doc)

This should be fixable by adding a dependency on sphinx-common, which
should come automatically via some substvars. But in the build log I see

https://buildd.debian.org/status/fetch.php?pkg=petsc=all=3.14.5%2Bdfsg1-2=1615378365=0

   debian/rules override_dh_gencontrol
make[1]: Entering directory '/<>'
dh_gencontrol -- -VMPI:Depends="libopenmpi-dev (>= 4.1.0), libopenmpi-dev (<< 
4.2)"
dpkg-gencontrol: warning: Depends field of package libpetsc3.14-dev-common: 
substitution variable ${sphinxdoc:Depends} used, but is not defined
dpkg-gencontrol: warning: Depends field of package petsc3.14-doc: substitution 
variable ${sphinxdoc:Depends} used, but is not defined
dpkg-gencontrol: warning: package petsc3.14-doc: substitution variable 
${sphinxdoc:Built-Using} unused, but is defined
make[1]: Leaving directory '/<>'

i.e. sphinxdoc:Depends does not (no longer?) get populated.


cheers,

Andreas


libpetsc3.14-dev-common_3.14.5+dfsg1-2.log.gz
Description: application/gzip

Bug#984698: closed by "Steinar H. Gunderson" (Re: Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts)

[Marcel Partap]

[sorry, forgot to CC]

> The plot thickens; evidently, all of your files in /mnt/x are of type
> DT_UNKNOWN, where they should be DT_DIR or DT_REG. Is there anything strange
> about the filesystem on /mnt/x?


No, nothing I know of .. Inode size and sector size seem different between 
those XFSs that return unknown-type dir-entries and those that do not.. 
Probably more relevant: both of the former ones are V4 (which I see is now 
deprecated) and the ones not causing the issue are V5..
But mlocate's updatedb sees the same unknown type for dir entries and still 
continues to recurse...

Best Regards

[ THX for the fix! ]

Bug#985658: progress-linux-server: please add Breaks: exim4-config

[Andreas Beckmann]

Package: progress-linux-server
Version: 20210101-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
with --install-recommends enabled. (It installed fine with
--install-recommends disabled.) Apt does not find a proper dependency
solution due to exim vs. postfix, but adding a Breaks: exim4-config
to progress-linux-server makes the install succeed because possible
solutions that include installing exim (because some dependency of
progress-linux-server (transitively) recommends some MTA) are discarded
early and postfix wins.

>From the attached log (scroll to the bottom...):

0m10.2s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmp0Ay_j8', 
'apt-get', '-y', 'install', 'progress-linux-server=20210101-1']
0m10.8s DUMP: 
  Reading package lists...
  Building dependency tree...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   exim4-config : Conflicts: postfix but 3.5.6-1 is to be installed
  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.
0m10.8s ERROR: Command failed (status=100): ['chroot', 
'/srv/piuparts/tmp/tmp0Ay_j8', 'apt-get', '-y', 'install', 
'progress-linux-server=20210101-1']


cheers,

Andreas


progress-linux-server_20210101-1.log.gz
Description: application/gzip

Bug#985543: yubikey-luks: after upgrade and reboot - yubikey "not detected" (but blinking)

[Markus Frosch]

Hi Daniel,

On Sun, 2021-03-21 at 13:52 +0200, Daniel Hevron Pereh wrote:
> I successfully managed to unlock my LUKS partition by generating the response
> on a different machine (with package 'ykpersonalize' using the command
> 'ykchalresp') and typing it manually. the system was updated as I thought. 
> 
> My system recognized my yubikey when it was unlocked and I could do the usual
> operation I'm using it for. the chalresp OTP slot works as usual as well for
> other oprations. 
> 
> Tried to do another update and rebooted the system, still no luck with the
> yubikey itself. 
> 
> As for your suggestion, I'll try to unlock it with the yubikey-luks package on
> a live system and report back.

Sorry you are having problems with the integration.

Could you share a few details?

* dpkg -l "*yubi*"
* dpkg -l "*cryptsetup*"
* cat /etc/crypttab
* Screenshots of the prompt, error messages, maybe boot in recovery mode

You should always be able to unlock with any other passphrase, as long as the
YubiKey is not present, I hope this works for you?

Also make sure you have updated initramfs, after upgrading yubikey-luks: update-
initramfs -uv

Best Regards
Markus Frosch

Bug#985543: yubikey-luks: after upgrade and reboot - yubikey "not detected" (but blinking)

[Markus Frosch]

Hi Jerome,

On Sat, 2021-03-20 at 12:29 -0400, Jerome Charaoui wrote:
> I've attempted, but was unable, to reproduce this bug.
> 
> I set up the yubikey-luks challenge-response on a fresh stretch system, 
> and after upgrading to bullseye, it was working as before, which 
> suggests the package is working as intended even after a release upgrade.
> 
> I'm wondering if your bug could actually be related to an update in the 
> kernel or usb subsystem itself, rather than the yubikey-luks package?
> 
> Did you try booting up using a live system such as Grml and trying to 
> unlock your luks filesystem manually in that environment?

Thanks for verifying, I just re-confirmed it working on my test VMs without any
problems (from a fresh install).

And thanks for tagging! :)

Regards
Markus

Bug#985653: arduino: Arduino Leonardo bootloader missing (and possibly others)

[Ryan Armstrong]

On 2021-03-21 9:58 a.m., Carsten Schoenert wrote:

Control: reassign -1 arduino-core-avr

Hello Rayn,

the bootloader files doesn't belong to the Arduino IDE directly but to
the specific board support packages. In your case to arduino-core-avr.

This impression is correct but also documented.
Please have a look into
/usr/share/doc/arduino-core-avr/README.Debian

It's also partially documented within the Debian Wiki.

https://wiki.debian.org/Arduino#FAQ

If you can contribute more useful hints to the Wikis site please add
your additional information.

There is quite nothing we can do about this right now. We would like to
get rid of arduino-core-avr but the libary handling of the IDE isn't
supporting the dedicated installation of the AVRCore stuff in the
reklease of the 1.x version. Might be happen within 2.x.


Ah, my mistake on missing the README and wiki (and picking the wrong 
package for the report). I can't think of a better solution at the 
moment, aside from forcing the user to read the readme on install :)


I may try to get the bootloader to build myself and provide an update if 
I have any success.


Ryan

Bug#985596: [Debian-med-packaging] Bug#985596: emboss has mailcap entries with quoted %-escapes

[Marriott NZ]

Hello,

I see.
I agree that such file is not useful out of the box, and personally I have no 
objection to removing it (can't wait for mailcap to disappear :D).
But once fixed the file is probably not harmful either, and it can be useful to 
a user who is willing to add the corresponding entries to /etc/mime.types or 
~/.mime.types manually (for example if you have a mailcap-based file manager, 
and you want to make it open .ab1 files).
I'm not familiar with the registration of media types to IANA, so I'll leave 
the decision to you.

Thanks,
MNZ

Bug#953046: Wrongly picks AZERTY layout when alternative Canadian layout is present.

[Gunnar Hjalmarsson]

Thanks for your report!

Can you please run these terminal commands:

gsettings get org.gnome.desktop.input-sources sources

gsettings get org.freedesktop.ibus.general use-system-keyboard-layout

cat /etc/default/keyboard

and let us know what they output.

--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985653: arduino: Arduino Leonardo bootloader missing (and possibly others)

[Carsten Schoenert]

Control: reassign -1 arduino-core-avr

Hello Rayn,

Am 21.03.21 um 12:49 schrieb Ryan Armstrong:
> The Arduino package (and any related packes I can find)

the bootloader files doesn't belong to the Arduino IDE directly but to
the specific board support packages. In your case to arduino-core-avr.

> appear to be
> missing the bootloader for the Arduino Leonardo (technically tested
> using an Arduboy, which has the same hardware). When performing a
> "verify" operation on the board type, the build process reports the
> following message:
> 
> Bootloader file specified but missing: 
> /usr/share/arduino/hardware/arduino/avr/bootloaders/caterina/Caterina-Leonardo.hex
> 
> I did not attempt an upload beyond this, as recovering a Leonardo/Arduboy 
> with a missing bootloader is quite tricky. I saw several .txt files in
> this folder, but no hex files at all. I also did not see any hex files
> in the atmega8, lilypad, caterina-Arduino_Robot or caterina-LilyPadUSB
> so I suspect a fair number of board types will have similar problems.

This impression is correct but also documented.
Please have a look into
/usr/share/doc/arduino-core-avr/README.Debian

---[snip]---
> 1. Bootloaders - differences between Debian and upstream on provided .hex
>files
> 
> 
> This Debian package can't provide all the various *.hex files that are
> present within the upstream archive.
> Due the DFSG [1] we are required to build all binary stuff from source, and
> also have to remove any prebuilt binary stuff from the source tarball.
> Due this circumstances there are some differences between the included *.hex
> files in /usr/share/arduino/hardware/bootloaders and data provided by
> upstream. In detail there are the following differences.
> 
> 
> 
> Folder bootloaders/caterina,
>bootloaders/caterina-Arduino_Robot,
>bootloaders/caterina-LilyPadUSB
>  All the various *.hex files can't be rebuilded right now. Rebuilding
>  requires LUFA [2] as resource which isn't available as package right now
>  nor is it included as additional tarball to the source package.
---[snip]---

It's also partially documented within the Debian Wiki.

https://wiki.debian.org/Arduino#FAQ

If you can contribute more useful hints to the Wikis site please add
your additional information.

There is quite nothing we can do about this right now. We would like to
get rid of arduino-core-avr but the libary handling of the IDE isn't
supporting the dedicated installation of the AVRCore stuff in the
reklease of the 1.x version. Might be happen within 2.x.

-- 
Regards
Carsten

Bug#984969: glib2.0 CVE-2021-27218, CVE-2021-27219, CVE-2021-28153: DSA or s-p-u?

[Simon McVittie]

glib2.0 2.66.6 and 2.66.8 fixed some security issues, listed here as
most-severe-first (in my opinion):

* CVE-2021-28153 (#984969)
  When g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION is asked
  to overwrite a dangling symlink, in the vulnerable versions of GLib,
  the target of the symlink gets created as an empty regular file as a
  side-effect. If a malicious archive (e.g. tarball) is unpacked with
  file-roller, this can be exploited to create an empty file in an
  attacker-controlled location.

  Mitigation: the attacker cannot choose the file's contents or empty
  an existing file, so this is only interesting if they are creating
  a flag-file whose mere presence or absence is what matters, like
  /etc/staff-group-for-usr-local.

  The patches I've proposed for this include a later follow-up fix to
  error handling, which is not in bullseye/unstable yet (although I've
  asked for permission to include it in #985610).

* CVE-2021-27219 (#982778)
  On 64-bit platforms, if a buffer of length n > 4 GB is copied into a
  new GBytes object, only the first (n % (1<<32)) bytes get allocated and
  copied, but the new GBytes object still thinks it has length n, which
  can result in undefined behaviour. The only known exploit for this is
  memory corruption that crashes policykit-1's setuid polkit-agent-helper-1
  with an assertion failure (a denial of service) but there might be
  cases where an attacker can do something worse with this.

  While fixing this, the GLib developers also fixed similar issues where
  the same function g_memdup() was called elsewhere in GLib. Most of them
  are clearly not exploitable (either the length is fixed and small,
  or an attacker-specified length would be silly for other reasons)
  but some might be.

  In some of the places where changes were made, it's easy to see that the
  changes are correct and harmless. Luckily, this includes CVE-2021-27219
  itself. However, some of the other changes were non-trivial and caused
  regressions that had to be fixed in 2.66.7.

  To minimize regression risk, I am proposing that we only fix the
  easy cases in Debian 10, and deliberately leave the harder/more
  regression-prone places unfixed, unless someone can explain how the
  lengths can realistically become attacker-controlled and 4GB+. I talked
  to upstream maintainer Philip Withnall about this and he agrees with
  my reasoning.

* CVE-2021-27218 (#982779)
  Similar to CVE-2021-27219, if a buffer of length n > 4 GB is copied into
  a new GByteArray object, there's an integer overflow. No known exploit.
  The fix turns this into a critical warning and NULL return, which
  could still cause a crash (denial of service), but is the best we can
  do within the constraints of the existing API/ABI.

Note that just to be extra-confusing, MITRE allocated consecutive CVE IDs
for the two integer overflows, but assigned the first CVE ID to the issue
that was reported second.

Proposed changes are available here:
https://salsa.debian.org/gnome-team/glib/-/merge_requests/11

Do the security team want to do a DSA for this, or should I be talking to
the stable release team?

If we go via a stable point release, I'm aware that I've narrowly missed
the window for Debian 10.9, but that might be for the best: none of this
seems amazingly urgent, and lots of things use GLib, so regressions here
would be really bad.

Sorry this has taken a while to prepare, but at this point GLib 2.58 is
2½ years behind upstream's oldest supported branch, so the amount of
backporting involved is significant, and that made me extra-cautious about
regressions.

smcv

Bug#985656: sword-text-sparv: Build from source

[Bastian Germann]

Package: sword-text-sparv
Severity: important
Control: block -1 by 984600

Even though its USFX sources are included, sword-text-sparv is not built 
from source. Haiola is used by eBible to produce the sword module from 
USFX and it should be built from source as well in Debian.

Bug#985655: sword-text-kjv: Build from source

[Bastian Germann]

Package: sword-text-kjv
Severity: important
Control: block -1 by 984600

Even though its USFX sources are included, sword-text-kjv is not built 
from source. Haiola is used by eBible to produce the sword module from 
USFX and it should be built from source as well in Debian.

Bug#985647: telegram-desktop: Actively works against KDE Window rules

[Nicholas Guriev]

Hello!

If you prefer to see KDE's titlebar on Telegram Desktop, set the
System window frame checkbox in advanced settings inside the app.



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

Bug#985589: unblock: jsonnet/0.17.0+ds-2

[Sebastian Ramacher]

Control: tags -1 + confirmed moreinfo

On 2021-03-20 13:49:44 +, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> 
> Please unblock package jsonnet
> 
> [ Reason ]
> 
> I missed the lib package in the Depends: field of its -dev package,
> resulting in dangling symlinks during anbe's tests. Not yet uploaded.

Looks good. Please remove the moreinfo tag once it's available in
unstable.

Cheers

> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock jsonnet/0.17.0+ds-2
> 
> 
> 
> --- debdiff ---
> 
> diff -Nru jsonnet-0.17.0+ds/debian/changelog jsonnet-
> 0.17.0+ds/debian/changelog
> --- jsonnet-0.17.0+ds/debian/changelog  2020-12-01 11:12:06.0
> +0800
> +++ jsonnet-0.17.0+ds/debian/changelog  2021-03-20 21:44:30.0
> +0800
> @@ -1,3 +1,9 @@
> +jsonnet (0.17.0+ds-2) UNRELEASED; urgency=medium
> +
> +  * Fix broken symlinks in libjsonnet-dev due to missing deps (Closes:
> #985511)
> +
> + -- Mo Zhou   Sat, 20 Mar 2021 21:44:30 +0800
> +
>  jsonnet (0.17.0+ds-1) unstable; urgency=medium
>  
>* New upstream version 0.17.0+ds
> diff -Nru jsonnet-0.17.0+ds/debian/control jsonnet-
> 0.17.0+ds/debian/control
> --- jsonnet-0.17.0+ds/debian/control2020-12-01 11:12:06.0
> +0800
> +++ jsonnet-0.17.0+ds/debian/control2021-03-20 21:27:53.0
> +0800
> @@ -64,7 +64,7 @@
>  Package: libjsonnet-dev
>  Section: libdevel
>  Architecture: any
> -Depends: ${misc:Depends},
> +Depends: ${misc:Depends}, libjsonnet0 (= ${binary:Version})
>  Description: data templating language (devel)
>   A data templating language for app and tool developers
>   .
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Stephen Kitt]

Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
library wrapping SDL 2.0
Control: owner -1 !

On Sun, 21 Mar 2021 11:17:32 +, Simon McVittie  wrote:
> On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> > I've recently retried switching to Wayland and I think I'm sticking
> > with it. But while checking for toolkits support, noticed that SDL 1.2
> > does not have native Wayland support, but SDL 2.0 does.  
> 
> Note that SDL 2.0 currently defaults to using X11 if available, and will
> currently only use Wayland if X11 is unavailable, so in environments where
> Xwayland is either always run (such as GNOME 3.38) or started automatically
> on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
> I think typical desktop environments like GNOME and KDE Plasma are
> likely to want Xwayland available by default for quite a long time,
> even if it's only started on-demand.
> 
> You can override this with with environment variable
> SDL_VIDEODRIVER=wayland.

Right, I’ll make sure to document this in the package.

> On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> > As seen in [1] regarding the headers, sdl12-compat isn't a full
> > replacement yet.
> > 
> > It could work for pure binary-compatibility but you can't build anything
> > against it yet so it should be a Provide+Replace rather than something
> > like a newer version.
> > 
> > 1: https://github.com/libsdl-org/sdl12-compat/issues/34  
> 
> Yes, I'd come to that conclusion too.

Yup, for the time being it’s really only a runtime replacement, it’s not
ready as a build-time SDL2 shim for SDL1.2 projects.

> If we get to a point where we want to eliminate the original SDL 1.2 from
> the archive before sdl12-compat has headers, we could probably make some
> sort of hybrid package that builds SDL 1.2, keeps the headers, discards
> the actual shared library and uses the shared library from sdl12-compat
> instead - but I think it would probably work best to package sdl12-compat
> as a separate binary-compatibility-only library first.

Yes, that’s my plan at least. If we do end up wanting to drop (or deprecate)
libsdl1.2debian, I’m not sure we’d really even need a hybrid package — it
would be simpler to make libsdl1.2-dev depend on libsdl1.2-compat instead of
libsdl1.2debian... It’s not as if the licensing concerns really affect Debian
in this instance, AFAICT.

> It would probably be best to have the sdl12-compat shared library installed
> in a directory outside the default search path so that it can be
> co-installed with the real SDL 1.2, and then insert it into the default
> search path in a separate package that Provides/Conflicts/Replaces the
> real SDL 1.2. That way, individual games have the option to use sdl12-compat
> via DT_RUNPATH or LD_LIBRARY_PATH without preventing co-installation of
> the real SDL 1.2.
> 
> In particular, sdl12-compat has a few extra symbols not present in the
> real SDL 1.2, which are meant to make it binary-compatible with the
> modified SDL 1.2 build "libSDL-1.2.id.so.0" in some id Software games,
> such as the quake4-bin:i386 package built by game-data-packager. If
> it works well as a replacement for that modified library, then
> game-data-packager could prefer to use sdl12-compat.

Good point, I hadn’t thought of that. So we’d have a libsdl1.2-compat package
usable by packages that explicitly prefer the compatibility layer, and a
libsdl1.2-compat-shim (or something like that) package which actually
replaces libsdl1.2debian.

> On Thu, 18 Mar 2021 at 21:30:47 +0100, Stephen Kitt wrote:
> > I’m interested in maintaining this, I’ll ask to join the SDL team.  
> 
> I've added you.
> 
> I briefly started looking at this before seeing this message, so I've
> created an empty 
> (no content yet though).

Thanks!

Regards,

Stephen


pgpKWdE8uBbdi.pgp
Description: OpenPGP digital signature

Bug#985616: Document change to unbound ".d" config file fragment behavior

[Justin B Rye]

Robert Edmonds wrote:
> During the bullseye release cycle the default /etc/unbound/unbound.conf
> file was changed to use the newly introduced "include-toplevel:"
> directive rather than the "include:" directive. This should probably be
> mentioned in the bullseye release notes because it will break
> configurations where the user added a clauseless config file fragment to
> /etc/unbound/unbound.conf.d/.
> 
> The text from /usr/share/doc/unbound/NEWS.Debian.gz about this change is
> quoted below.

For the Release Notes we ought to add some material: people reading
the NEWS file can be assumed to have chosen to install unbound, but
this version needs to start by making it clear what unbound is (and
that if you haven't heard of it you don't need to read the technical
details).  Then after that we could squeeze things a bit:

  
Config file fragment handling in unbound

 The DNS resolver unbound
 has changed the way it includes configuration file fragments.
 Instead of using an include: directive to read
 in files in /etc/unbound/unbound.conf.d/*.conf,
 the default configuration file for Debian bullseye uses
 include-toplevel:, which has extra requirements.


 Instead of allowing fragments that need to be concatenated to form
 valid configuration clauses, include-toplevel:
 requires each one to begin its own clause (e.g.,
 server:). If your system uses included fragments
 you should ensure they will still be valid; if this is not possible
 the previous behavior can be restored by editing
 /etc/unbound/unbound.conf and switching the
 include-toplevel: directive back to
 include:.

   

Is that compressed too far?  I was hoping to fit the word "robustness"
somewhere.  Maybe a mention of unbound-checkconf?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#726062: Arduino SAM ARM support works

[Ryan Armstrong]

Just an FYI: I successfully programmed an Arduino Due (SAM ARM-based) 
using the Debian-packaged version of the Arduino IDE. The board support 
information is now controlled through the "Boards Manager" feature, 
which will independently install support into the ~/.arduino15 folder 
regardless of what the Debian package comes with.


That said, this bug is probably still valid for ADK devices. I don't own 
one of those boards to test.


Ryan

Bug#985512: liblingot-dev: broken symlink: /usr/lib/x86_64-linux-gnu/liblingot.so -> liblingot.so.0.0.0

[Nicolas Boulenguez]

Package: liblingot-dev
Followup-For: Bug #985512
Control: tags -1 pending

The VCS contains a trivial fix.
https://salsa.debian.org/debian/lingot/-/commit/5ef26d260e2f6858e3226223290e052237b92e00

Bug#985624: lirc 0.10.1-6.3~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 985624 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: lirc
Version: 0.10.1-6.3~deb10u1

Explanation: normalize embedded ${DEB_HOST_MULTIARCH} value in 
/etc/lirc/lirc_options.conf to find unmodified configuration files on all 
architectures; recommend gir1.2-vte-2.91 instead of non-existant gir1.2-vte

Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386

[Simon McVittie]

Control: retitle -1 flatpak/1.2.5-0+deb10u4 FTBFS on IPv6-only buildds
Control: reassign -1 glib2.0 2.50.0-1
Control: affects -1 + flatpak
Control: severity -1 important
Control: close -1 2.63.1-1

On Sun, 21 Mar 2021 at 12:15:15 +0100, Philipp Kern wrote:
> I have commented out stretch and buster (and their corresponding
> security and backports suites) on x86-conova-01 for now. I'll definitely
> leave bullseye on, though. Not sure if there's another IPv6-only buildd
> lingering around.

Thanks, I think this is appropriate. I'm reassigning the bug to glib2.0,
downgrading its severity and resolving it as fixed in bullseye. It's
effectively the same thing as #948834.

Justification for downgrade: it's a FTBFS, but it only affects (old)stable,
only affects certain builder configurations (IPv6-only machines and
some pbuilder configurations), and with Philipp's workaround it does
not prevent us from doing security and stable updates.

If anyone disagrees with the downgrade, we could backport the "let
localhost be localhost" change into buster's glib2.0, but for a stable
release that will soon become oldstable I'd prefer not to have the
regression risk of that behaviour change.

smcv

Bug#982669: portaudio19 19.6.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 982669 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: portaudio19
Version: 19.6.0-1+deb10u1

Explanation: 

Bug#985653: arduino: Arduino Leonardo bootloader missing (and possibly others)

[Ryan Armstrong]

Package: arduino
Version: 2:1.8.13+dfsg1-2
Severity: normal

Dear Maintainer,

The Arduino package (and any related packes I can find) appear to be
missing the bootloader for the Arduino Leonardo (technically tested
using an Arduboy, which has the same hardware). When performing a
"verify" operation on the board type, the build process reports the
following message:

Bootloader file specified but missing: 
/usr/share/arduino/hardware/arduino/avr/bootloaders/caterina/Caterina-Leonardo.hex

I did not attempt an upload beyond this, as recovering a Leonardo/Arduboy 
with a missing bootloader is quite tricky. I saw several .txt files in
this folder, but no hex files at all. I also did not see any hex files
in the atmega8, lilypad, caterina-Arduino_Robot or caterina-LilyPadUSB
so I suspect a fair number of board types will have similar problems.

Ryan

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

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

Versions of packages arduino depends on:
ii  arduino-builder   1.3.25-2+b1
ii  arduino-core-avr  1.8.3+dfsg1-1
ii  avrdude   6.3-20171130+svn1429-2+b1
ii  default-jre   2:1.11-72
ii  dpkg-dev  1.20.7.1
ii  libastylej-jni3.1-2+b1
ii  libbatik-java 1.12-4
ii  libbcpg-java  1.68-1
ii  libbcprov-java1.68-1
ii  libcommons-codec-java 1.15-1
ii  libcommons-compress-java  1.20-1
ii  libcommons-exec-java  1.3-2
ii  libcommons-io-java2.8.0-1
ii  libcommons-lang3-java 3.11-1
ii  libcommons-logging-java   1.2-2
ii  libcommons-net-java   3.6-1
ii  libhttpclient-java4.5.13-1
ii  libjackson2-annotations-java  2.12.1-1
ii  libjackson2-core-java 2.12.1-1
ii  libjackson2-databind-java 2.12.1-1
ii  libjaxp1.3-java   1.3.05-6
ii  libjmdns-java 3.5.5-1
ii  libjna-java   5.6.0-1
ii  libjna-platform-java  5.6.0-1
ii  libjsch-java  0.1.55-1
ii  libjssc-java  2.8.0-3
ii  liblistserialsj-dev   1.4.0-1+b1
ii  liblog4j2-java2.13.3-1
ii  librsyntaxtextarea-java   2.5.8-1
ii  librxtx-java  2.2pre2+dfsg1-2
ii  libsemver-java0.9.0-4
ii  libslf4j-java 1.7.30-1
ii  libxml-commons-external-java  1.4.01-5
ii  libxmlgraphics-commons-java   2.4-1
ii  openjdk-11-jre11.0.10+9-1

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-5
ii  policykit-1  0.105-30

arduino suggests no packages.

-- no debconf information