Bug#1014938: dash: please package version 0.5.11.5

[Martin-Éric Racine]

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-8
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Version 0.5.11.5 is available upstream. Could you please package it?

Thanks!

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dash depends on:
ii  debianutils  5.7-0.2
ii  dpkg 1.21.9
ii  libc62.33-8

dash recommends no packages.

dash suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmLQ9zAACgkQrh+Cd8S0
17aCDg//Z63FTMf43yJ9FKgKawQr+4q4SAOKBsGkb+KdxOb9LsOJtEG883joDn1A
v4rohaoxH0hMi961fd6RtdCYHoE9SB4SmcWYFSSNY3GDZ/0YupBONw5Ry4HhKlVU
soxiBhZNqpCOuoNycvItrfIUuZQf5X/evTtAVaqZmBBKDloD8ofJEvTYHSW7/KDp
LtCe9VQAh8/9OcBrrOa+V17kM/6PxKzzprjHqoNdgbPBK4/lBdfY6AOQnKsjd51A
dQAwf+GEHURHGn59ki56N6rPG/yWcRt+hbGcAXp7J+9fhfOF78LGyGenyzF/iQiy
tlOG0uaaoDVEyKn+4niqznYMGkAw65foczx9ix1ccvN0+EZiMUBvhdReuTQ0pgMy
hUfFm/GFZOvOmdWbKZiXKJBrNs+STbADbsuQyWX7/RAGz14JO4REDTYJ9A70Ya/a
tgBIieE724MTRJCzY8Mg3pOqQ0zzXacxjnqeb9IVdYrb+G71ZD/BIjUI7Of/sUWP
hmMKQPtYSzXjzE1t2PmyQ6pG92boLfOGECH9XANxUnKz1VxeC9G2w2+ty3m3PFMB
Y1EdrJuAHghCABOK1hj+YVkxJa8B9hEVOz1Roz+ceAdFHetjACc76vJIpB+NRpZu
RkoqVS1TVoGCth3xg/qUn7vimI9Uaa+iBUb//iMv5kG03y8dcek=
=X3J8
-END PGP SIGNATURE-

Bug#991011: v5.2.1-1 fixes the bug

[肖盛文]

Some enhancements could be done:

If you put an image in `/boot/grub` the settings, e.g. the normal 
font color, will be reset to default (and the background will be the 
image).

I'd do the test in my notebook.
When I put an image and font settings, the font setting is also not to 
become affect,

but the display color of the font is take affcet.

The /boot/grub/grub.cfg updated like this:

if background_image /atzlinux/IMG_2021.jpg; then
  set color_normal=green/black
  set color_highlight=red/light-cyan
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi

O, I test again, the font setting is take affect.

atzlinux@debian:/boot/grub$ file unicode.pf2
unicode.pf2: GRUB2 font "MingLiU Regular 28"

From info grub:

7.2.2 Fonts
---

The fonts GRUB uses "PFF2 font format" bitmap fonts.  Fonts are
specified with full font names.

so select the  bitmap fonts in grub-customizer is OK.

Regards.

xiao sheng wen



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014894: closed by Ben Hutchings (Re: Bug#1014894: firmware-amd-graphics: With the firmware installed Teamviewer unable to start with segfault error)

[eugene.klepik...@gmail.com]

More of testing: on Debian 10 everilything works well too. So I tried three 
systems Debian 11, Ubuntu 18.04, Debian 10. Why only on Debian 11 I have issues?

14 июл. 2022 г. 20:45:03 Debian Bug Tracking System :

> This is an automatic notification regarding your Bug report
> which was filed against the firmware-amd-graphics package:
> 
> #1014894: firmware-amd-graphics: With the firmware installed Teamviewer 
> unable to start with segfault error
> 
> It has been closed by Ben Hutchings .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings 
>  by
> replying to this email.
> 
> 
> -- 
> 1014894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014894
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1000242: new upstream required for ttyd

[Daniel Baumann]

Hi,

is there any news or ETA for an updated package?

Regards,
Daniel

Bug#964170: new upstream (4.15)

[Daniel Baumann]

Hi,

is there any news or ETA on a update to a current xterm.js version?

Regards,
Daniel

Bug#1000246: new upstream required for ttyd

[Daniel Baumann]

Hi Daniel,

webpack 5 is currently both in unstable and testing since, would you
mind updating node-style-loader?

Regards,
Daniel

Bug#991011: v5.2.1-1 fixes the bug

[肖盛文]

Hi,

    Thanks for your reply.


在 2022/7/14 22:57, Scorpion2185 写道:

Hi,

I try it on my VM with sid, it is working now.

Ok, this bug may close.


Some enhancements could be done:

If you put an image in `/boot/grub` the settings, e.g. the normal font 
color, will be reset to default (and the background will be the image).

I'd do the test in my notebook.
When I put an image and font settings, the font setting is also not to 
become affect,

but the display color of the font is take affcet.

The /boot/grub/grub.cfg updated like this:

if background_image /atzlinux/IMG_2021.jpg; then
  set color_normal=green/black
  set color_highlight=red/light-cyan
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi




If grub-customizer doesn't found the image, e.g. you put it on LUKS 
partitions, all the settings will be reset to default.

Is grub support LUKS partitions now?
grub is a bootloader, it's start before kernel, LUKS is supported after 
kernel load.


Best regards


Thanks!

--
肖盛文 xiao sheng wen
https://www.atzlinux.com  《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa:https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Vincent Lefevre]

Control: forwarded -1 https://github.com/systemd/systemd/issues/24026

On 2022-07-05 00:30:14 +0200, Michael Biebl wrote:
> Since this appears to be a regression in v251, please file this
> upstream at https://github.com/systemd/systemd/issues

OK, I've just reported the issue upstream.

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

Bug#162917: Verify your mail account

[Zimbra]

Dear user, your mailbox account has exceeded the quota limit set by the Zimbra 
team, access to your email account will soon be restricted, you will not be 
able to send or receive incoming emails until you activate your account, to 
activate your Zimbra account:CLICK HERE TO VERIFY
Note that failure to verify, your account will be permanently disable and 
deleted from our database.
* ©2022 Zimbra Customer Care

Bug#1014847: mirror submission for fastmirror.pp.ua

[Marco d'Itri]

On Jul 14, Ivan Barabash  wrote:

> That's true. My ISP doesn't have an IPv6 option. Also mirror speed and 
> availability are not affected by the 6to4 tunnel.
Of course they are, since traffic will be routed to Warsaw and back.
If you cannot provide real IPv6 connectivity then just don't: this is 
not 2002 anymore.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1014937: stormbaancoureur: Slow/wrong rendering on Intel 945GM x86/MMX/SSE2

[Nils Dagsson Moskopp]

Package: stormbaancoureur
Version: 2.1.6-3
Severity: important
Tags: patch
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

when I started stormbaancoureur, it had very low FPS (about 3) in racing mode.
Additionally, the level textures looked broken – a bit like a moiré effect.

I expected the game to look non-broken and run well on my Thinkpad T60.

Using software rendering with LIBGL_ALWAYS_SOFTWARE=1 I got about 14 FPS.
In the main menu I got over 30 FPS, always, which seemed highly unusual …

I remembered the game running fine on worse hardware than I am using now.
Henwe, I tried to disable Mesa extensions by year. I found the following:

The game ran fine using: MESA_EXTENSION_MAX_YEAR=2001 stormbaancoureur 
The game was broken using: MESA_EXTENSION_MAX_YEAR=2002 stormbaancoureur

To figure out which extensions this could be i looked at glxinfo output.
It reported different extensions based on the MESA_EXTENSION_MAX_YEAR.

Here is a word-diff of the extensions between 2001 and 2002:

--- 8< --- snip --- 8< ---
@@ -61,28 +61,32 @@ OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 20.3.5
OpenGL extensions:
GL_3DFX_texture_compression_FXT1, {+GL_APPLE_packed_pixels,+} 
GL_ARB_depth_texture, {+GL_ARB_draw_buffers, GL_ARB_fragment_program, +}
{+GL_ARB_fragment_shader,+} GL_ARB_multisample, GL_ARB_multitexture, 
GL_ARB_point_parameters, {+GL_ARB_shader_objects,+} GL_ARB_shadow, 
GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
GL_ARB_transpose_matrix, {+GL_ARB_vertex_program, GL_ARB_vertex_shader,+} 
GL_ARB_window_pos, {+GL_ATI_draw_buffers, GL_ATI_texture_env_combine3,+} 
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, 
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, 
GL_EXT_separate_specular_color, {+GL_EXT_shadow_funcs,+} 
GL_EXT_stencil_two_side, {+GL_EXT_stencil_wrap,+} GL_EXT_subtexture, 
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, 
GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, 
GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, 
GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, 
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
{+GL_MESA_pack_invert,+} GL_MESA_window_pos, {+GL_MESA_ycbcr_texture,+} 
GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, 
GL_NV_texgen_reflection, GL_NV_texture_env_combine4, 
GL_NV_texture_rectangle, GL_S3_s3tc, GL_SGIS_generate_mipmap, 
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
--- >8 --- snap --- >8 ---

Disabling any of th the following extensions makes the game run well:

GL_ARB_fragment_shader
GL_ARB_vertex_shader
GL_EXT_shadow_funcs

A line in the output of stormbaancoureur changed in all cases from

“This platform supports all required GL extensions to do hardware accelerated 
shadowing.”

to

“This platform does not support all required GL extensions to do hardware 
accelerated shadowing.
”

therefore it seems to me that shadow rendering is (at least partially) broken.

To make the game run well, I suggest to make it start using:

MESA_EXTENSION_OVERRIDE='-GL_EXT_shadow_funcs' stormbaancoureur

If you do not want to always disable shadows, please add a hint to the man page.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-10-686 (SMP w/2 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages stormbaancoureur depends on:
ii  freeglut3   2.8.1-6
ii  libasound2  1.2.4-1.1
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libode8 2:0.16.2-1
ii  libplib11.8.5-8+deb11u1
ii  libstdc++6  10.2.1-6
ii  stormbaancoureur-data   2.1.6-3

stormbaancoureur recommends no packages.

stormbaancoureur suggests no packages.

-- no debconf information

Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1

[Sebastian Ramacher]

On 2022-07-14 16:23:16 +0200, Paolo Greppi wrote:
> Hi Sebastian!
> 
> Il 14/07/22 11:22, Sebastian Ramacher ha scritto:
> > Control: tags 1000932 + patch
> > Control: tags 1000932 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for doxygen (versioned as 1.9.1-2.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> > Cheers
> 
> thanks for the quick patch; alas your fix will break this logic:
> https://salsa.debian.org/debian/doxygen/-/blob/master/debian/rules#L23
> which was contributed by Norbert Lange to fix
> https://bugs.debian.org/945427.
> 
> At this point I am unsure what effects this may cause, I only vaguely
> remember that the Clang_DIR and LLVM_DIR env vars plug into cmake somehow.
> 
> So I'd propose to skip this NMU, as I'd rather address this as part of the
> new upstream release (https://bugs.debian.org/1013636).
> With each upstream release, I usually run massive archive rebuilds with ratt
> which helps pinpoint which of the ~700 paackages that reverse-build-dep on
> doxygen might fail when the new version is pushed through.

ACK, I've canceled the NMU. Please consider that doxygen is a key
package and thus effectively keeping llvm-toolchain-11 in testing. A
timely fix for this issue would be much appreciated.

Cheers
-- 
Sebastian Ramacher

Bug#938351: marked as pending in renpy

[Markus Koschany]

Am Donnerstag, dem 14.07.2022 um 22:43 +0200 schrieb Moritz Mühlenhoff:

> The latest 8.0.0 release now supports Python 3-based games:
> https://www.renpy.org/release/8.0.0?mode=release-8=8.0.0

Hi Moritz,

That's great news. Thanks for pointing it out.


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

Bug#1014894: closed by Ben Hutchings (Re: Bug#1014894: firmware-amd-graphics: With the firmware installed Teamviewer unable to start with segfault error)

[eugene.klepik...@gmail.com]

Along with Debian 11 I have Ubuntu 18.04 installed on my laptop. And it has no 
issues neither with mentioned programs nor with initramfs update (no warnings 
that some firmware is missing)
Are you sure that the problem with these particular applications and I should 
contact their support? Ubuntu is based on Debian why does everything work well 
there?

14 июл. 2022 г. 20:45:03 Debian Bug Tracking System :

> This is an automatic notification regarding your Bug report
> which was filed against the firmware-amd-graphics package:
> 
> #1014894: firmware-amd-graphics: With the firmware installed Teamviewer 
> unable to start with segfault error
> 
> It has been closed by Ben Hutchings .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings 
>  by
> replying to this email.
> 
> 
> -- 
> 1014894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014894
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#938351: marked as pending in renpy

[Moritz Mühlenhoff]

Am Sat, Dec 18, 2021 at 03:46:28PM +0100 schrieb Markus Koschany:
> Renpy still has not been ported to Python 3 yet. The status of renpy and other
> Python 2 games was previously discussed on debian-devel-games.
> 
> https://lists.debian.org/debian-devel-games/2020/12/msg00013.html
> 
> A removal request was filed:
> 
> https://bugs.debian.org/1001888
> 
> 
> I don't think a removal is necessary at the moment. If we remove the game and
> the Python 3 port would be finished in time, we had to go through NEW again.
> This is just extra work for all involved parties. I intend to request the
> removal at the end of 2022, if there is no visible upstream progress though.

The latest 8.0.0 release now supports Python 3-based games:
https://www.renpy.org/release/8.0.0?mode=release-8=8.0.0

Cheers,
Moritz

Bug#992360: #992360 xfce4-notes-plugin in sid/bullseye

[Andres Salomon]

On Thu, 23 Jun 2022 15:42:33 -0400 Andres Salomon wrote:
>
> On Thu, Jun 23, 2022 at 20:08, Yves-Alexis Perez
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Wed, 2022-06-22 at 19:11 -0400, Andres Salomon wrote:
> >> Can we please get an upload of xfce4-notes-plugin 1.9.0 to
> >> unstable? I'm
> >> happy to do a backport to bullseye once it migrates to bookworm.
> >


Wow, okay - so my computer crashed and xfce4-notes lost like 2 weeks 
worth of notes. For some reason it didn't save onto disk (although one 
group did, and the other group didn't), and after my reboot it restored 
to an old version. That would be an RC data loss bug, so maybe 1.9 isn't 
suitable for bookworm after all!


I'm going to stop using it now.

Bug#1014901: Home directories should not be setgid by default

[Matt Barry]

Hi Josh,

On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote:
> > > The more recent issue 643559 suggests that
> > > > Those "bad side-effects", if they were ever relevant and
> > > > important
> > > > enough to make personal groups not work properly, have now been
> > > > fixed.
> > > 
> > > However, this is not the case; this change does in fact have bad
> > > side-effects. This change breaks some common use cases that apply
> > > to
> > > users on many systems, both single-user and multi-user.
> > 
> > Can we please have more information than just "bad side-effects"?
> 
> The use case below, and any other tools that create files and know to
> set their permissions appropriately but don't expect unusual
> ownership
> by default:
> > > In particular, it is common to build various kinds of filesystem,
> > > container, or disk images, and to do so within your home
> > > directory.
> > > Users writing tools and scripts to build such images need to make
> > > sure
> > > to create files with an appropriate mode, but such scripts often
> > > assume
> > > (reasonably) that if they're running as root:root and they create
> > > a
> > > file, that file will be owned by root:root. Attempting to build
> > > filesystems, containers, disk images, or similar in an
> > > unexpectedly
> > > setgid directory will produce unexpected results (leaving aside
> > > that the
> > > directory mode itself will be surprising).

Could you be just slightly more specific about a use case that fails? 
Given how many times this has come up over the years, I'm trying to get
a sense of what the *actual* issues are (as opposed to what they used
to be).

Enough instruction that I can reproduce a specific problem(s) would be
great.

(If it makes sense to take this part to -devel, please feel free.)

> > 
> > Would it help to do this kind of work in a subdirectory under the
> > home
> > directory and making sure that one is not setgid? I am happy to
> > document
> > this.
> 
> That's certainly a workaround if you know it's a problem. On the
> other
> hand, it's likewise possible for anyone doing shared-work-directories
> on
> a multiuser system to create a directory that *is* setgid.
> 
> I fully acknowledge here that there's no one default that will make
> everyone happy, and that someone is going to end up needing to
> configure
> it. I'm attempting to make the case for what the default should be.
> 
> I'm also hoping to make a case for "this change is a surprise and a
> regression, and changing it *back* shouldn't have the burden of
> 'changing the default' but rather 'reverting this change and
> returning to the
> previous default'". But either way, I'm willing to make the case
> regarding the default itself.

The previous conversation on -devel would have been the best point at
which to identify this as a regression (or indeed, to document any
downsides).  My personal choice of defaults align with neither the
current nor the previous config; if it is to keep changing, the setting
should really have some consensus.

Cheers,
Matt

Bug#1014936: weasyprint: manpage for weasyprint(1) is too much

[Daniel Kahn Gillmor]

Package: weasyprint
Version: 54.1-3
Severity: minor

Hi there!  I'm glad that there's a weasyprint(1) manpage, but the
contents of the manual page contain way too much info.

The manpage in section 1 should make it clear how to use the command
line utility.

the current manpage contains:

 - retreival and build instructions (including packaging for different
   distros)

 - descriptions of how to use the python module

 - explanations of CSS

 - full changelog

 - instructions on how to contribute

the python API could be included in a different manpage in section 3.
the other stuff should maybe just live in /usr/share/doc/weasyprint/

Thanks for keeping weasyprint in debian!

--dkg


signature.asc
Description: PGP signature

Bug#1013997: libminion-perl: Wrong version of fontawesome

[gregor herrmann]

On Tue, 28 Jun 2022 18:24:59 +0200, Alexander Sulfrian wrote:

> libminion-perl replaces the embedded copy of fontawesome with
> fonts-font-aweseome. Upstream uses fontaweseom v5, that is not available
> in Debian because of licensing concerns (see #902981). I suggest
> replacing this with fonts-fork-awesome, that is available as
> fonts-fork-awesome.

Thanks for the bug report!

> Fork-awesome does not provide all icons from font-aweseom, but most of
> the used icons are avialable. Only fa-hard-hat and fa-traffic-light are
> not available and needs to be replaced and fa-redo is available under a
> different name.

Great, thanks for this research …
 
> I attach a quilt patch to replace the usage of font-awesome with
> fork-awesome.

… and the patch, which I've used (slightly adjusted for the included
css files) in the upload I just did, plus some more package massaging
to get the new symlinks etc.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

On Thu, 14 Jul 2022 11:38:46 +0200 Marc Haber  
wrote:
> On Wed, Jul 13, 2022 at 11:45:58PM -0700, Josh Triplett wrote:
> > adduser 3.122 changes home directories to be setgid by default. The
> > issues discussing that change mention use cases involving multiuser
> > systems with shared groups, though that doesn't explain setting this
> > mode on home directories rather than on shared work areas.
> 
> This was part of the big adduser discussion debian-devel@l.d.o and
> didn't get much attention. The setting is run-time configurable in
> adduser.conf.
> 
> I would be willing to re-raise the severity of this issue if I can find
> a case for changing the default AGAIN and there is some discussion on
> debian-devel on this topic.
[...]
> It is really sad that you didn't participate in the discussion in march,
> where this part of the changes didnt get much attention and noone came
> up with any arguments against sgid home directories. I personally am at
> a loss here since I am just a server jockey who doesn't have many
> unprivileged shell account users on my boxes.

I'm not subscribed to -devel. I saw that some discussion about adduser
took place, and saw some of the topics, but I didn't see any mention of
sgid home directories. I would have been happy to participate in such a
discussion, had I known about it. The first I heard about this was via
apt-listchanges. :(

> > One of the issues links to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks
> > about easing the setup of shared directories for users who don't feel
> > comfortable running `chmod 2770` or similar themselves. That seems like
> > a relatively small justification, given that anyone setting up a shared
> > work directory *can* run `chmod 2770` or similar themselves, and doing
> > so does not require any special permission.
> 
> A local admin who doesn't like the behavior is free to change the
> default by setting an appropriate DIR_MODE in adduser.conf. There is a
> NEWS.Debian entry pointing the local administrator to this new behavior.

I understand this, and I understand that there's no one default that
will make everyone happy. I'm hoping to make the case for what the
default should be, to both minimize surprises and minimize the impact on
the most users.

> > The more recent issue 643559 suggests that
> > > Those "bad side-effects", if they were ever relevant and important
> > > enough to make personal groups not work properly, have now been fixed.
> > 
> > However, this is not the case; this change does in fact have bad
> > side-effects. This change breaks some common use cases that apply to
> > users on many systems, both single-user and multi-user.
> 
> Can we please have more information than just "bad side-effects"?

The use case below, and any other tools that create files and know to
set their permissions appropriately but don't expect unusual ownership
by default:
> > In particular, it is common to build various kinds of filesystem,
> > container, or disk images, and to do so within your home directory.
> > Users writing tools and scripts to build such images need to make sure
> > to create files with an appropriate mode, but such scripts often assume
> > (reasonably) that if they're running as root:root and they create a
> > file, that file will be owned by root:root. Attempting to build
> > filesystems, containers, disk images, or similar in an unexpectedly
> > setgid directory will produce unexpected results (leaving aside that the
> > directory mode itself will be surprising).
> 
> Would it help to do this kind of work in a subdirectory under the home
> directory and making sure that one is not setgid? I am happy to document
> this.

That's certainly a workaround if you know it's a problem. On the other
hand, it's likewise possible for anyone doing shared-work-directories on
a multiuser system to create a directory that *is* setgid.

I fully acknowledge here that there's no one default that will make
everyone happy, and that someone is going to end up needing to configure
it. I'm attempting to make the case for what the default should be.

I'm also hoping to make a case for "this change is a surprise and a
regression, and changing it *back* shouldn't have the burden of
'changing the default' but rather 'reverting this change and returning to the
previous default'". But either way, I'm willing to make the case
regarding the default itself.

> > Given those tradeoffs, I don't think this change is the right default.
> > I'd like to ask that the default mode be reverted from 2700 to 700.
> 
> I'd like you to take this discussion to debian-devel, most desireably as
> reply to https://lists.debian.org/debian-devel/2022/03/msg00304.html,
> .

I can do that.

> We can also talk to the ctte if the discussion on -devel doesn't bring
> any more consensus.

I sincerely hope it doesn't come to that.

Bug#1014935: lua5.4: CVE-2022-33099

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for lua5.4.

CVE-2022-33099[0]:
| An issue in the component luaG_runerror of Lua v5.4.4 and below leads
| to a heap-buffer overflow when a recursive error occurs.

Btw, I'm right now not sure about older lua versions. While the patch
im principle I think apply I'm unsure if the issue has introduced in
5.4 only. Can you double check so we can update the tracker
accordingly?

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-33099
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33099
[1] https://github.com/lua/lua/commit/42d40581dd919fb134c07027ca1ce0844c670daf
[2] https://lua-users.org/lists/lua-l/2022-05/msg00035.html
https://lua-users.org/lists/lua-l/2022-05/msg00042.html
https://lua-users.org/lists/lua-l/2022-05/msg00073.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1014934: libgav1: Please package new version 0.18.0

[Boyuan Yang]

Source: libgav1
Version: 0.17.0-1
Severity: normal
Tags: sid
X-Debbugs-CC: xialei...@gmail.com

Dear Debian libgav1 package maintainer,

A new upstream release 0.18.0 is available at
https://chromium.googlesource.com/codecs/libgav1/+/refs/tags/v0.18.0 .
Please consider packaging the new upstream release.

Thanks,
Boyuan Yang


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

Bug#971971: nemo-audio-tab_5.2.0-1_i386.changes REJECTED

[Bastian Germann]

Am 14.07.22 um 21:11 schrieb Joshua Peisach:

And I'm not a perl expression expert so I can't figure out how to 
extend-diff-ignore those files


You do not use extend-diff-ignore for this case but rather Files-Excluded in 
debian/copyright.
No regex involved there.

Bug#682156: groupdel performance

[Matt Barry]

On Thu, 2022-07-14 at 21:54 +0200, Marc Haber wrote:
> On Thu, Jul 14, 2022 at 03:00:50PM -0400, Matt Barry wrote:
> > Any objections to either moving this bug to passwd, or just
> > wontfix'ing
> > this?
> 
> No objection from me, I'd just reassign the bug. If we can do
> something
> to speed deletion up while having more pretty code, we should do that
> anyway though.

To make the test fast enough to be realistically runnable, I had to
replace even useradd/groupadd with direct writes to /etc/passwd et al.
So.. no prettier code to be had here. :(

We can do as suggested above and remove our own (arguably superfluous)
check, and take the minor performance win.

Bug#682156: groupdel performance

[Marc Haber]

On Thu, Jul 14, 2022 at 03:00:50PM -0400, Matt Barry wrote:
> Any objections to either moving this bug to passwd, or just wontfix'ing
> this?

No objection from me, I'd just reassign the bug. If we can do something
to speed deletion up while having more pretty code, we should do that
anyway though.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#446036:

[Nelson Bilen]

Are you there? I'm waiting to hear you

Bug#1014933: gnome-user-share: needs to be ported to gtk4

[Jeremy Bicha]

Source: gnome-user-share
Version: 3.34.0-5
Severity: serious

gnome-user-share will need to be ported to gtk4 because nautilus 43
will be using gtk4

Thank you,
Jeremy Bicha

Bug#1014675: as a workaround you can set mailnews.nntp.jsmodule set to false via config editor...

[Eric Valette]

Read that in a bug upstream. Tried it and it worked for me.

-- eric

Bug#1010024: git-buildpackage: fails to import pristine-tar: File name too long

[Sergio Durigan Junior]

On Friday, April 22 2022, Drew Parsons wrote:

> I'm trying to update the rclone package, using gbp import-orig in the
> "usual" way, with uscan, pristine-tar and importing into the
> experimental branch.
>
> The import is failing, apparently due to using a git commit in a
> filename during the pristine-tar step.
>
> $ git clone g...@salsa.debian.org:go-team/packages/rclone.git
> $ cd rclone
> $ git checkout upstream; git checkout pristine-tar; git checkout experimental
> $ git branch
> * experimental
>   master
>   pristine-tar
>   upstream
> $ uscan --report
> uscan: Newest version of rclone on remote site is 1.58.0, local version is 
> 1.53.3
> uscan:  => Newer package available from:
> => https://github.com/rclone/rclone/archive/refs/tags/v1.58.0.tar.gz
>
> $ gbp import-orig --verbose --uscan --pristine-tar  
> --debian-branch=experimental
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
> gbp:debug: ['git', 'status', '--porcelain']
> gbp:info: Launching uscan...
> gbp:info: Using uscan downloaded tarball ../rclone_1.58.0.orig.tar.gz
> What is the upstream version? [1.58.0] 
> gbp:debug: ['git', 'tag', '-l', 'upstream/1.58.0']
> gbp:debug: tar ['-C', '../tmpkiz0ywn3', '-a', '-xf', 
> '../rclone_1.58.0.orig.tar.gz'] []
> gbp:debug: Unpacked '../rclone_1.58.0.orig.tar.gz' to 
> '../tmpkiz0ywn3/rclone-1.58.0'
> gbp:info:  signaturefile=None>
> gbp:info: Importing '../rclone_1.58.0.orig.tar.gz' to branch 'upstream'...
> gbp:info: Source package is rclone
> gbp:info: Upstream version is 1.58.0
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
> gbp:debug: ['git', 'add', '-f', '.']
> gbp:debug: ['git', 'write-tree']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
> gbp:debug: ['git', 'commit-tree', '260bd813325c0b30022ab31e09fc3d9ab570e072', 
> '-p', '4d715ab7de2dd24d802fe89bd79048ba674a25ea']
> gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 1.58.0', 
> 'refs/heads/upstream', '70bb7aad80b8c50a88d59be119fbdc5c0f72ad3c', 
> '4d715ab7de2dd24d802fe89bd79048ba674a25ea']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
> gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
> gbp:debug: ['git', 'mktree', '-z']
> gbp:debug: pristine-tar [] ['commit', '../rclone_1.58.0.orig.tar.gz', 
> '260bd813325c0b30022ab31e09fc3d9ab570e072']
> gbp:error: Import of ../rclone_1.58.0.orig.tar.gz failed: Couldn't commit to 
> 'pristine-tar' with upstream '260bd813325c0b30022ab31e09fc3d9ab570e072': 
> mkdir 
> /tmp/pristine-tar.iXqSpNTndf/workdir/rclone-1.58.0/cmd/bisync/testdata/test_extended_char_paths/golden/normal-sync._testdir_path1_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.._testdir_path2_\346\270\254\350\251\246_\320\240\321\203\321\201\321\201\320\272\320\270\320\271_\304\233_\303\241\303\261.copy1to2.que:
>  File name too long at /usr/bin/pristine-tar line 451.
> gbp:error: Error detected, Will roll back changes.
> gbp:info: Rolling back branch upstream by resetting it to 
> 4d715ab7de2dd24d802fe89bd79048ba674a25ea
> gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
> upstream', 'refs/heads/upstream', '4d715ab7de2dd24d802fe89bd79048ba674a25ea']
> gbp:info: Rolling back branch pristine-tar by resetting it to 
> f92427a73c1a897f36b08dbf40a402c144d75b73
> gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
> pristine-tar', 'refs/heads/pristine-tar', 
> 'f92427a73c1a897f36b08dbf40a402c144d75b73']
> gbp:error: Rolled back changes after import error.
> gbp:debug: rm ['-rf', '../tmpkiz0ywn3'] []

I think this should be filed against pristine-tar, not git-buildpackage,
because it's the former that's complaining about the long filename.

On a side note, I also believe that it's worth proceeding with rclone's
update and just resort to Files-Excluded meanwhile in order to remove
these tests from the orig tarball.

A quick attempt with the following excerpt on d/copyright succeeded
here:

--8<---cut here---start->8---
Files-Excluded:
  cmd/bisync/testdata/test_extended_char_paths*
--8<---cut here---end--->8---

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#682156: groupdel performance

[Matt Barry]

Hi,

I have added a test to benchmark the deletion of groups on a system
with tens of thousands of users, and it is indeed (still) not great.

However, removing the overhead described in this bug (and replacing it
with *nothing*) only yields < 10-15% speed-up.

I would not be opposed to relying on the failure of userdel if it meant
a real boost, but I am tempted to say that this decade-old problem
might be better taken up with the passwd package.

Here is a snippet of the performance test output.  The times for
comparable groups are shown both for delgroup and for groupdel.

ok 2 - populated 1 groups in 4 seconds (< 120).
ok 3 - command success: /usr/sbin/delgroup --quiet dgpg_3
ok 4 - delgroup dgpg_3 took 8s (< 30).
ok 5 - command success: /usr/sbin/delgroup --quiet dgpg_
ok 6 - delgroup dgpg_ took 9s (< 30).
ok 7 - command success: /usr/sbin/delgroup --quiet dgpg_
ok 8 - delgroup dgpg_ took 11s (< 30).
ok 9 - command success: /usr/sbin/delgroup --quiet dgpg_9998
ok 10 - delgroup dgpg_9998 took 13s (< 30).
ok 11 - command success: /usr/sbin/groupdel dgpg_4
ok 12 - groupdel dgpg_4 took 11s (< 30).
ok 13 - command success: /usr/sbin/groupdel dgpg_3334
ok 14 - groupdel dgpg_3334 took 10s (< 30).
ok 15 - command success: /usr/sbin/groupdel dgpg_6667
ok 16 - groupdel dgpg_6667 took 11s (< 30).
ok 17 - command success: /usr/sbin/groupdel dgpg_
ok 18 - groupdel dgpg_ took 13s (< 30).

Any objections to either moving this bug to passwd, or just wontfix'ing
this?

Cheers,
Matt



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

Bug#1014847: mirror submission for fastmirror.pp.ua

[Ivan Barabash]

On Wed, 13 Jul 2022 09:08:16 +0200 Marco d'Itri  wrote:
> On Jul 13, Ivan Barabash  wrote:
> 
> > Site: fastmirror.pp.ua
> I do not think that it is appropriate to list a mirror which has IPv6 
> connectivity from a tunnel broker.
> 
> -- 
> ciao,
> Marco

That's true. My ISP doesn't have an IPv6 option. Also mirror speed and 
availability are not affected by the 6to4 tunnel.

Bug#971971: nemo-audio-tab_5.2.0-1_i386.changes REJECTED

[Bastian Germann]

Am 04.06.22 um 09:00 schrieb Thorsten Alteholz 
:

according to setup.py the license of this software is only GPL-3 instead of 
GPL-3+
Please update you debian/copyright accordingly.

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Ben Hutchings]

On Thu, 2022-07-14 at 16:56 +0200, Arnaud Rebillout wrote:
> Source: hw-detect
> Version: 1.147
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Dear Maintainer,
> 
> The package open-vm-tools 11.3.5, released in January 2022, depends on
> fuse3 rather than fuse [1].
> 
> As a consequence, hw-detect fails to install open-vm-tools if ever the
> package fuse was already installed. This is because installing fuse3
> would cause the removal of fuse, and removals are not allowed.
> 
> This can be seen in the logs of the installer:
> 
> in-target: The following additional packages will be installed:
> in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
> in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
> in-target:   libsigc++-2.0-0v5 open-vm-tools zerofree
> in-target: Suggested packages:
> in-target:   cloud-init
> in-target: The following packages will be REMOVED:
> in-target:   fuse
> in-target: The following NEW packages will be installed:
> in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
> in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
> in-target:   libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree
> in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
> in-target: E: Packages need to be removed but remove is disabled.
> 
> In practice, it hits Kali Linux users, as reported in [2]. For some
> reasons, fuse gets installed if users install the KDE desktop for Kali.
[...]

You should find out why that is, before proposing to override it.  What
if something in KDE really does need FUSE 2?

(Since you found that removing fuse doesn't remove anything else, this
implies that the relationship is only a Recommends and not a Depends. 
But that doesn't mean that removal won't break anything.)

If we find that it's not really needed, then a better fix may be to
remove the recommendation(s) or change them to "fuse3 | fuse".

Ben.


-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014431: popularity-contest: automatically create hostid if not specified in popularity-contest.conf

[Petter Reinholdtsen]

[Ansgar]
>> What would be the advantage ?
>
> No host-specific configuration would be required for popcon. One can
> just install an identical popularity-contest.conf on several machines
> instead of having to deal with a host-specific setting (MY_HOSTID).

Is the use case mirrored installations, thin clients with identical
disks, cloud installations, or what?

--
Happy hacking
Petter Reinholdtsen

Bug#1014431: popularity-contest: automatically create hostid if not specified in popularity-contest.conf

[Bill Allombert]

On Thu, Jul 14, 2022 at 06:29:55PM +0200, Ansgar wrote:
> On Wed, 2022-07-13 at 18:26 +0200, Bill Allombert wrote:
> > On Wed, Jul 06, 2022 at 12:05:49AM +0200, Ansgar wrote:
> > > Package: popularity-contest
> > > Version: 1.73
> > > Severity: wishlist
> > > 
> > > It would be nice if it was not required to have host-specific data
> > > in
> > > the configuration file (MY_HOSTID).
> > 
> > > If no MY_HOSTID is specified, popularity-contest could for example
> > > generate an application-specific MY_HOSTID from the machine-id as
> > > described for libsystemd's `sd_id128_get_machine_app_specific`
> > > function (i.e., HMAC-SHA256 of a application ID for
> > > popularity-contents keyed by the machine-id).
> > 
> > Hello Ansgar,
> > 
> > What is the life cycle of the machine-id ? How would that work while
> > fulfilling all the goal of MY_HOSTID ?
> 
> >From man:machine-id(5):
> 
> +---
> | The machine ID is usually generated from a random source during
> | system installation or first boot and stays constant for all
> | subsequent boots. Optionally, for stateless systems, it is generated
> | during runtime during early boot if necessary.
> +---
> 
> That looks like it fulfills what I guess popcon needs.

Almost. Is it possible to detect stateless system so that they do not report to
popcon ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1014912: cargo-mozilla 0.57.0-7~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1014912 = 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: cargo-mozilla
Version: 0.57.0-7~deb10u1

Explanation: new upstream version to support building of newer firefox-esr and 
thunderbird versions

Bug#1014907: rustc-mozilla 1.59.0+dfsg1-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1014907 = 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: rustc-mozilla
Version: 1.59.0+dfsg1-1~deb10u1

Explanation: new upstream version to support building of newer firefox-esr and 
thunderbird versions

Bug#1014909: rust-cbindgen 0.23.0-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1014909 = 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: rust-cbindgen
Version: 0.23.0-1~deb10u1

Explanation: new upstream version to support building of newer firefox-esr and 
thunderbird versions

Bug#1014860: llvm-toolchain-13 13.0.1-6~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1014860 = 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: llvm-toolchain-13
Version: 13.0.1-6~deb10u1

Explanation: new source package to support building of newer firefox-esr and 
thunderbird versions

Bug#1014932: python3-jellyfish: DeprecationWarning: getargs: The 'u' format is deprecated. Use 'U' instead

[Jakub Wilk]

Package: python3-jellyfish
Version: 0.8.9-1+b1

I'm getting this deprecation warning:

   >>> import jellyfish
   >>> jellyfish.soundex("Wilk")
   :1: DeprecationWarning: getargs: The 'u' format is deprecated. Use 
'U' instead.
   'W420'


-- System Information:
Architecture: i386

Versions of packages python3-jellyfish depends on:
ii  python3  3.10.4-1+b1
ii  libc62.33-8

--
Jakub Wilk

Bug#1014929: kea-dhcp4-server: uses predictable filenames in /tmp

[Paride Legovini]

Ansgar wrote on 14/07/2022:
> kea-dhcp4-server_2.1.3-1_amd64.deb includes:
> 
> +---
> | "control-socket": {
> | "socket-type": "unix",
> | "socket-name": "/tmp/kea4-ctrl-socket"
> | },
> +---[ /etc/kea/kea-dhcp4.conf ]
> 
> This looks like incorrect use of /tmp as one cannot (without much
> extra work) place files with fixed names there.  Clients would also
> need to make sure they actually connect to the right program.
> 
> Sockets should be placed in /run or a service-specific subdirectory
> such as /run/kea or /run/kea-dhcp4.
> 
> Other kea-* packages probably have similar issues.

Hello Ansgar and thanks for this bug report. I agree we should fix the
location of the control sockets, but see comment #2 here on a reason why
doing that isn't straightforward:

  https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100

Paride

Bug#1014690: llvmlite breaks numba autopkgtest: segmentation fault

[Diane Trout]

On Thu, 2022-07-14 at 10:10 +0200, Paul Gevers wrote:
> Control: reassign 1014690 src:llvmlite 0.38.1-2
> Control: affects 1014690 src:numba
> Control: fixed 1014690 0.38.1-3
> 
> Hi Diane,
> 
> On 14-07-2022 05:26, Diane Trout wrote:
> > I know there's some problems with some of numba's autopkgtests but
> > I
> > couldn't reproduce the segmentation fault.
> 
> That's because Mo reverted the change to use llvm-toolchain-13 in
> llvmlite.
> 
> > llvmlite's tracker suggests that the tests are passing now?
> > 
> > Did you find a solution or is this likely to be a random problem?
> 
> Well, reverting reopened another issue we have which is that we want
> to 
> drop llvm-toolchain-11 from testing.


In that case what about submitting the llvm-toolchain-13 version of
llvmlite to experimental to start the process of trying to fix what it
breaks?

Diane


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

Bug#1014931: openstack-pkg-tools: * Set umask in init-script-template to ensure log files are created

[Corey Bryant]

Package: openstack-pkg-tools
Version: update log creation permissions and pkgos_adduser shell
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

In Ubuntu, the attached patch was applied to achieve the following:


  * Set umask in init-script-template to ensure log files are created
with 0640 mode bits.
  * Update pkgos_adduser to use /usr/sbin/nologin instead of /bin/false
when creating system accounts that do not run a shell.


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-37-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
diff -Nru openstack-pkg-tools-119/init-template/init-script-template 
openstack-pkg-tools-119ubuntu1/init-template/init-script-template
--- openstack-pkg-tools-119/init-template/init-script-template  2021-02-09 
08:44:31.0 -0500
+++ openstack-pkg-tools-119ubuntu1/init-template/init-script-template   
2022-07-08 15:12:01.0 -0400
@@ -181,6 +181,8 @@
 }
 
 do_systemd_start() {
+   # Set umask to ensure log files are created with 0640 mode bits
+   umask 0026
if [ -n "${PYARGV}" ] ; then
exec $DAEMON $DAEMON_ARGS --pyargv "${PYARGV}"
else
diff -Nru openstack-pkg-tools-119/pkgos_func 
openstack-pkg-tools-119ubuntu1/pkgos_func
--- openstack-pkg-tools-119/pkgos_func  2021-02-09 08:44:31.0 -0500
+++ openstack-pkg-tools-119ubuntu1/pkgos_func   2022-07-08 15:12:01.0 
-0400
@@ -838,7 +838,7 @@
VAR_UG_SHELL=${2}
 
if [ -z "${VAR_UG_SHELL}" ] ; then
-   VAR_UG_SHELL='/bin/false'
+   VAR_UG_SHELL='/usr/sbin/nologin'
fi
 
# These are reserved UID/GID allocation

Bug#1014841: workaround

[Akkana Peck]

Since this has persisted for a couple days and prevents any security
updates, here's a workaround (for people who find this bug report
after a web search):

dpkg --purge --force-all libguvcview-2.0-2
apt --fix-broken install

Bug#1014431: popularity-contest: automatically create hostid if not specified in popularity-contest.conf

[Ansgar]

On Wed, 2022-07-13 at 18:26 +0200, Bill Allombert wrote:
> On Wed, Jul 06, 2022 at 12:05:49AM +0200, Ansgar wrote:
> > Package: popularity-contest
> > Version: 1.73
> > Severity: wishlist
> > 
> > It would be nice if it was not required to have host-specific data
> > in
> > the configuration file (MY_HOSTID).
> 
> > If no MY_HOSTID is specified, popularity-contest could for example
> > generate an application-specific MY_HOSTID from the machine-id as
> > described for libsystemd's `sd_id128_get_machine_app_specific`
> > function (i.e., HMAC-SHA256 of a application ID for
> > popularity-contents keyed by the machine-id).
> 
> Hello Ansgar,
> 
> What is the life cycle of the machine-id ? How would that work while
> fulfilling all the goal of MY_HOSTID ?

>From man:machine-id(5):

+---
| The machine ID is usually generated from a random source during
| system installation or first boot and stays constant for all
| subsequent boots. Optionally, for stateless systems, it is generated
| during runtime during early boot if necessary.
+---

That looks like it fulfills what I guess popcon needs.

(But please do not use the machine-id directly, but hashed as described
above.)

> What would be the advantage ?

No host-specific configuration would be required for popcon. One can
just install an identical popularity-contest.conf on several machines
instead of having to deal with a host-specific setting (MY_HOSTID).

Ansgar

Bug#1014930: irssi: FTBFS with Perl 5.36: ISO C90 forbids mixed declarations and code

[Niko Tyni]

Source: irssi
Version: 1.4.1-1
Severity: normal
Tags: ftbfs patch fixed-upstream
Forwarded: https://github.com/irssi/irssi/issues/1381
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition

Hi,

irssi_1.4.1-1 started building with -Werror=declaration-after-statement,
which broke the build with Perl 5.36 (currently in experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.36/irssi_1.4.1-1/irssi_1.4.1-1+b1_amd64-2022-07-11T15:30:44Z.build

  FAILED: src/perl/libperl_core.so.p/perl-signals.c.o 
  cc -Isrc/perl/libperl_core.so.p -I. -I.. -Isrc/perl -I../src/perl 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/local/include -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE 
-fdiagnostics-color=always -Wall -Winvalid-pch -O0 
-Werror=declaration-after-statement -fno-strict-aliasing -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -D_REENTRANT 
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -fPIC -pthread '-DSCRIPTDIR="/usr/share/irssi/scripts"' 
'-DPERL_USE_LIB=""' -DPERL_STATIC_LIBS=0 -MD -MQ 
src/perl/libperl_core.so.p/perl-signals.c.o -MF 
src/perl/libperl_core.so.p/perl-signals.c.o.d -o 
src/perl/libperl_core.so.p/perl-signals.c.o -c ../src/perl/perl-signals.c
  In file included from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/perl.h:7242,
   from ../src/perl/module.h:8,
   from ../src/perl/perl-signals.c:23:
  /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/inline.h: In function 
‘Perl_cop_file_avn’:
  /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/inline.h:3489:5: error: ISO C90 
forbids mixed declarations and code [-Werror=declaration-after-statement]
   3489 | const char *file = CopFILE(cop);
| ^
  cc1: some warnings being treated as errors
  ninja: build stopped: subcommand failed.
  dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v 
returned exit code 1
  make: *** [debian/rules:12: binary-arch] Error 25
 
Dropping C89 support seems to be a conscious choice on the perl side
with 5.36, see

  https://github.com/Perl/perl5/issues/19382

  https://github.com/Perl/perl5/pull/19384

Reported on the irssi upstream side as

  https://github.com/irssi/irssi/issues/1381

and supposedly fixed with

  https://github.com/irssi/irssi/pull/1384

though I haven't verified that.

Thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org

Bug#1014929: kea-dhcp4-server: uses predictable filenames in /tmp

[Ansgar]

Package: kea-dhcp4-server
Version: 2.1.3-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

kea-dhcp4-server_2.1.3-1_amd64.deb includes:

+---
| "control-socket": {
| "socket-type": "unix",
| "socket-name": "/tmp/kea4-ctrl-socket"
| },
+---[ /etc/kea/kea-dhcp4.conf ]

This looks like incorrect use of /tmp as one cannot (without much
extra work) place files with fixed names there.  Clients would also
need to make sure they actually connect to the right program.

Sockets should be placed in /run or a service-specific subdirectory
such as /run/kea or /run/kea-dhcp4.

Other kea-* packages probably have similar issues.

Ansgar

Bug#1014928: fcitx5-config-qt: Unneeded/unwanted/bloating dependency on libkf5plasma5

[Fcitx5 bugreporter]

Package: fcitx5-config-qt
Version: 5.0.14-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Updating from the previous version 5.0.13-1 pulls in whole KDE
via libkf5plasma5.

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

For now, not doing update of this package to avoid bringing
unwanted KDE into the main systems.

   * What was the outcome of this action?
   * What outcome did you expect instead?

No such dependency, it is to be in the other package, kde-config-fcitx5.


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

Kernel: Linux 5.15.4 (SMP w/8 CPU threads)
Locale: LANG=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages fcitx5-config-qt depends on:
ii  libc6 2.33-8
ii  libfcitx5-qt1 5.0.14-1
ii  libfcitx5config6  5.0.18-1
ii  libfcitx5utils2   5.0.18-1
ii  libgcc-s1 12.1.0-5
ii  libkf5itemviews5  5.94.0-1
ii  libkf5plasma5 5.94.0-1
ii  libkf5widgetsaddons5  5.94.0-2
ii  libqt5core5a  5.15.4+dfsg-4
ii  libqt5dbus5   5.15.4+dfsg-4
ii  libqt5gui55.15.4+dfsg-4
ii  libqt5svg55.15.4-2
ii  libqt5widgets55.15.4+dfsg-4
ii  libqt5x11extras5  5.15.4-2
ii  libstdc++612.1.0-5
ii  libx11-6  2:1.7.5-1
ii  libxkbfile1   1:1.1.0-1

Versions of packages fcitx5-config-qt recommends:
pn  libime-bin  

Versions of packages fcitx5-config-qt suggests:
pn  kde-config-fcitx5  

-- no debconf information

Bug#1014927: pipewire: Please provide the systemd system units (too)

[Diederik de Haas]

Package: pipewire
Version: 0.3.54-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pipewire also has systemd *system* units, next to the user units, but
those are not available in the Debian packages.
AFAICT they're in pipewire/src/daemon/systemd/system.

I have a headless 'sound server' device and the systemd system unit
should be used in that case.

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

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.64
ii  libpipewire-0.3-modules  0.3.54-2
ii  pipewire-bin 0.3.54-2

pipewire recommends no packages.

pipewire suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYtA96AAKCRDXblvOeH7b
bpdXAQCJQ56oLdLSLd5Ytj4v9m9TXXA+DqC0DYZwdGPmK5eUhQD+Itoq91utIUKg
2zXcwuCsognOmXgyAAsIPmRPUvzg2wA=
=g0Gj
-END PGP SIGNATURE-

Bug#1014926: pipewire: module-echo-cancel causes distortion in microphone input

[Jan K]

Package: pipewire
Version: 0.3.54-2
Severity: normal
X-Debbugs-Cc: jkran...@gmail.com

After upgrading pipewire from version 0.3.53-1 to version 0.3.54-2 the echo 
cancellation module (module-echo-cancel) doesn't seem to work properly for me. 

When module-echo-cancel is loaded with pipewire version 0.3.54-2 there is heavy 
crackling in the captured microphone input, the sound is very distorted.  When 
the module is unloaded the mic sounds fine again (but there is no echo 
cancellation obviously).

With version 0.3.53-1 the module doesn't have this problem, echo cancellation 
works and there is no distortion.

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

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.64
ii  libpipewire-0.3-modules  0.3.54-2
ii  pipewire-bin 0.3.54-2

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#933683: [Bug 1972833] Re: Merge cacti from Debian unstable for kinetic

[Paul Gevers]

Hi,

On Thu, 12 May 2022 09:00:49 +0200 Paul Gevers  wrote:
As Debian has MySQL 8+ for some time now, wouldn't it make sense to 
merge this back into Debian now. Are these changes compatible with 
MariaDB, and if not, what would it take to make them compatible?


I guess the required changes are not compatible with MariaDB? Can you 
confirm?


paul@mulciber ~/packages/cacti/cacti $ sudo mysql -e "create user 
'bla'@'localhost';"
paul@mulciber ~/packages/cacti/cacti $ sudo mysql -e "alter user 
'bla'@'localhost' identified with 'sha256_password';"
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 
'bla'@'localhost'


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Arnaud Rebillout]

Source: hw-detect
Version: 1.147
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

The package open-vm-tools 11.3.5, released in January 2022, depends on
fuse3 rather than fuse [1].

As a consequence, hw-detect fails to install open-vm-tools if ever the
package fuse was already installed. This is because installing fuse3
would cause the removal of fuse, and removals are not allowed.

This can be seen in the logs of the installer:

in-target: The following additional packages will be installed:
in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target:   libsigc++-2.0-0v5 open-vm-tools zerofree
in-target: Suggested packages:
in-target:   cloud-init
in-target: The following packages will be REMOVED:
in-target:   fuse
in-target: The following NEW packages will be installed:
in-target:   ethtool fuse3 libatkmm-1.6-1v5 libcairomm-1.0-1v5 libfuse3-3
in-target:   libglibmm-2.4-1v5 libgtkmm-3.0-1v5 libmspack0 libpangomm-1.4-1v5
in-target:   libsigc++-2.0-0v5 open-vm-tools open-vm-tools-desktop zerofree
in-target: 0 upgraded, 13 newly installed, 1 to remove and 0 not upgraded.
in-target: E: Packages need to be removed but remove is disabled.

In practice, it hits Kali Linux users, as reported in [2]. For some
reasons, fuse gets installed if users install the KDE desktop for Kali.

Does it happen in Debian as well? A quick check tells me that it does
NOT happen for GNOME, as gnome-core Depends on gvfs-fuse which Depends
on fuse3. But for other desktop environments I don't know.

I've seen that the script apt-install supports an option --allow-remove,
so I wonder if we could make use of it in this case, to make installing
open-vm-tools more reliable.

For example, this kind of patch:

diff --git a/hw-detect.finish-install.d/08hw-detect 
b/hw-detect.finish-install.d/08hw-detect
index a91bff07..5269f114 100755
--- a/hw-detect.finish-install.d/08hw-detect
+++ b/hw-detect.finish-install.d/08hw-detect
@@ -103,10 +103,12 @@ enable_modules_loading() {

 case "$(detect_virt)" in
 vmware)
+   # open-vm-tools depends on fuse3, which Replaces fuse,
+   # so we allow removal in case fuse is already installed.
if detect_desktop; then
-   apt-install --with-recommends open-vm-tools-desktop || true
+   apt-install --with-recommends --allow-remove open-vm-tools-desktop 
|| true
else
-   apt-install --with-recommends open-vm-tools || true
+   apt-install --with-recommends --allow-remove open-vm-tools || true
fi
;;
 oracle)

Does anyone has an opinion on that? I can submit a patch if you think
it's a good idea.

Cheers,

Arnaud



NB: fuse3 seems to be a drop-in replacement for fuse:

Package: fuse3
Version: 3.11.0-1
[...]
Provides: fuse (= 3.11.0-1)
Depends: libc6 (>= 2.33), libfuse3-3 (= 3.11.0-1), adduser,
 mount (>= 2.19.1), sed (>= 4), lsb-base (>= 3.2-14)
Breaks: fuse
Replaces: fuse



References:

[1]: 
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/d5176b54
[2]: https://bugs.kali.org/view.php?id=7774

Bug#988979: libwww-perl: Peculiar 308 Permanent redirect causes LWP::UserAgent to return an error

[gregor herrmann]

Version: 6.49-1

On Sat, 22 May 2021 12:41:42 +0100, Dominic Sweetman wrote:

> This results in a "308 Permanent redirect".  Using wget suggests that the
> redirect is just the original URL with a '/' at the end.

According the the upstream Changes file:

6.48  2020-09-20 15:25:51Z
- Support 308 Permanent Redirect (GH#349) (Galen Huntington)

this should be fixed by now.

Sorry for coming back the this issue so late …


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1014924: gtk-gnutella: FTBFS with glibc >= 2.34

[Nick Rosbrook]

Package: gtk-gnutella
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi,

This is technically not a problem in Debian yet, since sid is on glibc
2.33. But, once glibc >= 2.34 is in place, this package will FTBFS. The
cause is that gtk-gnutella uses preprocessor directives to check
PTHREAD_STACK_MIN at compile time, but in glibc >= 2.34,
PTHREAD_STACK_MIN may be dynamic and cannot be checked at compile time.

In Ubuntu, we pulled an upstream patch to fix compilation with newer
glibc:

  * debian/patches/0001-Fix-compilation-with-newest-glibc.patch: Fix FTBFS
against glibc >= 2.34 by checking dynamically-defined PTHREAD_STACK_MIN 
at run time instead of compile time (LP: #1981474).

This patch should be safe for glibc < 2.34 as well.

Thanks,
Nick
diff -Nru 
gtk-gnutella-1.1.15/debian/patches/0001-Fix-compilation-with-newest-glibc.patch 
gtk-gnutella-1.1.15/debian/patches/0001-Fix-compilation-with-newest-glibc.patch
--- 
gtk-gnutella-1.1.15/debian/patches/0001-Fix-compilation-with-newest-glibc.patch 
1969-12-31 19:00:00.0 -0500
+++ 
gtk-gnutella-1.1.15/debian/patches/0001-Fix-compilation-with-newest-glibc.patch 
2022-07-12 14:20:53.0 -0400
@@ -0,0 +1,63 @@
+Description: Fix compilation with newest glibc
+  The PTHREAD_STACK_MIN value is no longer a constant but rather
+  defined as sysconf(_SC_THREAD_STACK_MIN).
+Author: Raphael Manfredi 
+Origin: upstream, 
https://github.com/gtk-gnutella/gtk-gnutella/commit/31d06cecac572852c6e5e8d85cea641883cbe4c6
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk-gnutella/+bug/1981474
+Last-Update: 2022-07-12
+---
+From: Raphael Manfredi 
+Date: Mon, 9 Aug 2021 09:36:00 +0200
+Subject: [PATCH] Fix compilation with newest glibc.
+
+The PTHREAD_STACK_MIN value is no longer a constant but rather
+defined as sysconf(_SC_THREAD_STACK_MIN).
+
+Therefore, we must avoid using cpp computations on that value.
+---
+ src/lib/thread.c | 7 +--
+ src/lib/thread.h | 2 +-
+ 2 files changed, 2 insertions(+), 7 deletions(-)
+
+diff --git a/src/lib/thread.c b/src/lib/thread.c
+index 178c09794..e7a702029 100644
+--- a/src/lib/thread.c
 b/src/lib/thread.c
+@@ -9705,7 +9705,7 @@ thread_launch_trampoline(void *arg)
+  * In case PTHREAD_STACK_MIN is not defined by .
+  */
+ #ifndef PTHREAD_STACK_MIN
+-#define PTHREAD_STACK_MIN 0
++#define PTHREAD_STACK_MIN 1024U
+ #endif
+ 
+ /**
+@@ -9737,12 +9737,7 @@ thread_launch(struct thread_element *te,
+   pthread_attr_init();
+ 
+   if (stack != 0) {
+-  /* Avoid compiler warning when PTHREAD_STACK_MIN == 0 */
+-#if PTHREAD_STACK_MIN != 0
+   stacksize = MAX(PTHREAD_STACK_MIN, stack);
+-#else
+-  stacksize = stack;
+-#endif
+   stacksize = MAX(stacksize, THREAD_STACK_MIN);
+   } else {
+   stacksize = MAX(THREAD_STACK_DFLT, PTHREAD_STACK_MIN);
+diff --git a/src/lib/thread.h b/src/lib/thread.h
+index 73e15fa36..740f3a6f9 100644
+--- a/src/lib/thread.h
 b/src/lib/thread.h
+@@ -63,7 +63,7 @@ typedef size_t thread_qid_t; /* Quasi Thread ID */
+ typedef unsigned int thread_key_t;/* Local thread storage key */
+ 
+ #define THREAD_MAX64  /**< Max amount of 
threads we can track */
+-#define THREAD_STACK_DFLT (65536 * PTRSIZE)   /**< Default stack 
requested */
++#define THREAD_STACK_DFLT (65536U * PTRSIZE)  /**< Default stack 
requested */
+ #define THREAD_LOCAL_MAX  1024/**< Max amount of thread-local keys */
+ 
+ #define THREAD_SUSPEND_TIMEOUT90  /**< secs: thread max 
suspension time */
+-- 
+2.34.1
+
diff -Nru gtk-gnutella-1.1.15/debian/patches/series 
gtk-gnutella-1.1.15/debian/patches/series
--- gtk-gnutella-1.1.15/debian/patches/series   2020-02-26 04:01:31.0 
-0500
+++ gtk-gnutella-1.1.15/debian/patches/series   2022-07-12 14:17:33.0 
-0400
@@ -1 +1,2 @@
 # Auto-applied patches
+0001-Fix-compilation-with-newest-glibc.patch

Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1

[Paolo Greppi]

Hi Sebastian!

Il 14/07/22 11:22, Sebastian Ramacher ha scritto:

Control: tags 1000932 + patch
Control: tags 1000932 + pending

Dear maintainer,

I've prepared an NMU for doxygen (versioned as 1.9.1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers


thanks for the quick patch; alas your fix will break this logic:
https://salsa.debian.org/debian/doxygen/-/blob/master/debian/rules#L23
which was contributed by Norbert Lange to fix 
https://bugs.debian.org/945427.


At this point I am unsure what effects this may cause, I only vaguely 
remember that the Clang_DIR and LLVM_DIR env vars plug into cmake somehow.


So I'd propose to skip this NMU, as I'd rather address this as part of 
the new upstream release (https://bugs.debian.org/1013636).
With each upstream release, I usually run massive archive rebuilds with 
ratt which helps pinpoint which of the ~700 paackages that 
reverse-build-dep on doxygen might fail when the new version is pushed 
through.


Having said that, if you feel confident this will not break too many 
things, feel free to let it go.


Otherwise I'm more than happy if you are inspired to contribute in any 
way to doxygen maintenance; for me the preferred way is by means of 
Merge Requests on salsa.


MfG,

Paolo

P.S. I also tried reviving the salsa gitlab CI:
https://salsa.debian.org/debian/doxygen/-/commits/bugfix/sramacher/1000932 
but ATM the pipeline is failing for unrelated reasons:

https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/358

Bug#1014922: please --enable-rshim

[dann frazier]

Package: openocd
Version: 0.11.0-1+b1
Severity: wishlist

I'm using openocd to debug an Nvidia Bluefield device using rshim. In order
to do this, I needed to rebuild the package with --enable-rshim.

-- System Information:
Debian Release: bookworm/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.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openocd depends on:
ii  libc6  2.33-8
ii  libcapstone4   4.0.2-5
ii  libftdi1-2 1.5-5+b2
ii  libgpiod2  1.6.3-1+b2
ii  libhidapi-hidraw0  0.11.2-1
ii  libjaylink00.2.0-1
ii  libjim0.81 0.81+dfsg0-2
ii  libusb-0.1-4   2:0.1.12-32
ii  libusb-1.0-0   2:1.0.26-1

openocd recommends no packages.

openocd suggests no packages.

-- no debconf information

Bug#1014921: ITP: coq-iris -- high-order concurrent separation logic framework for Coq

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-iris
  Version : 3.6.0
  Upstream Author : iris developers and contributors
* URL : https://gitlab.mpi-sws.org/iris/iris
* License : BSD-3-clause and CC-BY-4.0
  Programming Lang: Coq
  Description : high-order concurrent separation logic framework for Coq
 This package provides a high-order concurrent separation
 logic framework for Coq, which means it is useful to reason
 about safety of concurrent programs.
 .
 Coq is a proof assistant for higher-order logic.


I plan to maintain this package within the Debian OCaml Maintainers team, along
with the rest of the Coq-related packages.

Cheers,

J.Puydt

Bug#953844: This appears to be due to "provide-stdint-for-embedded.patch"

[Steve Capper]

Hello,
I also ran into this issue when building firmware.

FWIW, my steps can be found condensed here:
=
FROM debian:sid
WORKDIR /build
RUN apt-get update && apt-get -y install gcc-arm-none-eabi git \
cmake make
RUN git clone https://git.morello-project.org/morello/scp-firmware.git && \
cd scp-firmware && git checkout \
97c99fcc60b5f3d86767c66390353d1205bce4a5
RUN mkdir build-scp && cd build-scp && cmake -DCMAKE_BUILD_TYPE=Debug \
-DSCP_FIRMWARE_SOURCE_DIR:PATH=morello/scp_ramfw_soc \
../scp-firmware
RUN cmake --build build-scp
=

This then led to:
=
In file included from 
/build/scp-firmware/module/cmn_skeena/src/cmn_skeena_ccix.c:18:
/build/scp-firmware/module/cmn_skeena/src/cmn_skeena_ccix.c: In function 
'enable_and_start_ccix_link_up_sequence':
/build/scp-firmware/module/cmn_skeena/src/cmn_skeena_ccix.c:383:46: 
error: expected ')' before 'PRIx64'

383 | MOD_NAME "CXLA_PCIE_HDR_FIELDS: 0x%" PRIx64,
| ^~
/build/scp-firmware/framework/include/fwk_log.h:222:46: note: in 
definition of macro 'FWK_LOG_INFO'

222 | # define FWK_LOG_INFO(...) fwk_log_printf(__VA_ARGS__)
| ^~~
/build/scp-firmware/module/cmn_skeena/src/cmn_skeena_ccix.c:28:18: 
error: spurious trailing '%' in format [-Werror=format=]

28 | #define MOD_NAME "[CMN_SKEENA] "
| ^~~
/build/scp-firmware/framework/include/fwk_log.h:222:46: note: in 
definition of macro 'FWK_LOG_INFO'

222 | # define FWK_LOG_INFO(...) fwk_log_printf(__VA_ARGS__)
| ^~~
/build/scp-firmware/module/cmn_skeena/src/cmn_skeena_ccix.c:383:9: note: 
in expansion of macro 'MOD_NAME'

383 | MOD_NAME "CXLA_PCIE_HDR_FIELDS: 0x%" PRIx64,
| ^~~~
cc1: all warnings being treated as errors
gmake[2]: *** 
[module/modules/cmn-skeena/CMakeFiles/module-cmn-skeena.dir/build.make:104: 
module/modules/cmn-skeena/CMakeFiles/module-cmn-skeena.dir/src/cmn_skeena_ccix.c.obj] 
Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1748: 
module/modules/cmn-skeena/CMakeFiles/module-cmn-skeena.dir/all] Error 2

gmake: *** [Makefile:91: all] Error 2
=

With some stracing, it became apparent that the newlib headers were 
pulling in an extra stdint.h (that wasn't part of newlib). I rebuilt the 
gcc-arm-none-eabi package with the "provide-stdint-for-embedded.patch" 
removed. That then allowed me to build the SCP firmware without issue.


Could the stdint patch please be tweaked? (apologies, I haven't the 
first clue how it can be tweaked :-( )


Cheers,
--
Steve

Bug#1014920: firefox: please remove blank URL from tab history after opening a new tab

[Gary Dale]

Package: firefox
Version: 78.0.1-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
I use tabs

   * What exactly did you do (or not do) that was effective (or ineffective)?
when I open a new tab then go to the site I want to visit, the site actually 
becomes the 
second page in the tab's history. The first one is the "New tab" entry. This is 
annoying
because if I later back up through the history, I can overshoot the actual 
first site
and end up at the "New tab", which is almost never what I want.

   * What was the outcome of this action?
   * What outcome did you expect instead?
In almost every case, I have zero interest in the "New tab" page. And even if I 
did, I can 
always get to it by creating a new tab rather than going back to it in an 
existing tab.


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


-- Package-specific info:

-- Extensions information
Name: Amazon.co.uk
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Web Compat
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox78.0.1-1 amd64Mozilla Firefox web browser

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=iu_CA.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii  debianutils 5.7-0.2
ii  fontconfig  2.13.1-4.4
ii  libatk1.0-0 2.38.0-1
ii  libc6   2.33-7
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libdbus-1-3 1.14.0-1
ii  libdbus-glib-1-20.112-2
ii  libevent-2.1-7  2.1.12-stable-5+b1
ii  libffi7 3.3-6
ii  libfontconfig1  2.13.1-4.4
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.1.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.72.3-1
ii  libgtk-3-0  3.24.34-1
ii  libnspr42:4.34-1
ii  libnss3 2:3.79-1
ii  libpango-1.0-0  1.50.7+ds-1
ii  libstdc++6  12.1.0-5
ii  libvpx6 1.10.0+really+1.10.0-dmo1
ii  libx11-62:1.7.5-1
ii  libx11-xcb1 2:1.7.5-1
ii  libxcb-shm0 1.14-3
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.4-1
ii  libxfixes3  1:6.0.0-1
ii  libxrender1 1:0.9.10-1.1
ii  procps  2:3.3.17-7+b1
ii  zlib1g  1:1.2.11.dfsg-4

Versions of packages firefox recommends:
ii  libavcodec53  7:0.10.3-dmo1
ii  libavcodec54  10:1.2.6-dmo4
ii  libavcodec55  10:2.3.1-dmo1
ii  libavcodec56  6:11.4-2
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  10:4.4.2-dmo7

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.19.2-2+b2
ii  libgtk2.0-02.24.33-2
ii  pulseaudio 15.0+dfsg1-4+b1

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: 

Bug#1014492: guzzle: CVE-2022-31090 CVE-2022-31091

[Andrius Merkys]

Hi Katharina,

On Thu, 7 Jul 2022 10:56:06 +0200 Katharina Drexel
 wrote:
> thanks for the hints. I pushed a new version in the repo
> (https://salsa.debian.org/php-team/pear/php-guzzlehttp-guzzle).
> TBD: someone should upload it in the debian repo.

Is it OK if I upload guzzle? By the way, debian/changelog contains two
Debian versions for 7.4.5: 7.4.5-1 and 7.4.5-2. It does not seem 7.4.5-1
has been uploaded yet, could you merge both of them to be 7.4.5-1?

Best,
Andrius

Bug#1014460: transition: php8.2

[Paul Gevers]

Control: forwarded -1 
https://release.debian.org/transitions/html/php8.2.html


Hi Ondřej,

On 06-07-2022 16:05, Ondřej Surý wrote:

to prevent the situation from the last time, I am kind of "starting"
the transition to PHP 8.2 now with PHP 8.2.0~alpha2.  I will be uploading
packages to experimental as I will be updating them to support PHP 8.2.


Ack and appreciated. I assume your ambition is to ship bookworm with PHP 
8.2.



title = "php8.2";
is_affected = .depends ~ "phpapi-20210902" | .depends ~ "phpapi-20210903";
is_good = .depends ~ "phpapi-20210903";
is_bad = .depends ~ "phpapi-20210902";


Tracker file set up and will be available in a short while.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014914: [Pkg-javascript-devel] Bug#1014914: Regression in @types

[Jérémy Lal]

Le jeu. 14 juil. 2022 à 14:03, Mark Weyer  a
écrit :

> Package: nodejs
>
> Version: 12.22.12~dfsg-1~deb11u1
>
>
>
> The upgrade from Version 12.22.5~dfsg-2~11u1 to 12.22.12~dfsg-1~deb11u1
> broke Typescript (from package node-typescript) for me.
>
> For a minimal example, let test.ts contain just the following line:
>
>
>
>   process.exit(0)
>
>
>
> And compile it with
>
>
>
>   tsc --typeRoots /usr/share/nodejs/@types/node test.ts
>
>
>
> With Version 12.22.5~dfsg-2~11u1, everything is fine. With Version
> 12.22.12~dfsg-1~deb11u1 I get
>
>
>
>   test.ts:1:1 - error TS2580: Cannot find name 'process'. Do you need to
> install type definitions for node? Try `npm i --save-dev @types/node`.
>
>
>
>   1 process.exit(0)
>
> ~~~
>
>   Found 1 error.
>

Thank you for your report.

The latest typescript definitions for nodejs 12.22.12 dropped support for
tsc 3.6 by removing @types/node/tsc3.6 directory.
That's unfortunate because bullseye have tsc 3.6.

Workaround:
ln -sT /usr/share/nodejs/@types/node /usr/share/nodejs/@types/node/tsc3.6

I'm not sure what's the best solution now.

Jérémy

Bug#1014865: [Pkg-raspi-maintainers] Bug#1014865: raspi-firmware dependencies

[Jiri Kastner]

firmware-misc-nonfree i added because it adds some blobs to /lib/firmware/brcm:

$ dpkg -S /lib/firmware/brcm/*.hcd
firmware-misc-nonfree: /lib/firmware/brcm/BCM-0a5c-6410.hcd
firmware-misc-nonfree: /lib/firmware/brcm/BCM-0bb4-0306.hcd
bluez-firmware: /lib/firmware/brcm/BCM43430A1.hcd
bluez-firmware: /lib/firmware/brcm/BCM43430B0.hcd
bluez-firmware: /lib/firmware/brcm/BCM4345C0.hcd
bluez-firmware: /lib/firmware/brcm/BCM4345C5.hcd

just checked on amd64 and arm64, that those files are probably not needed by 
any kernel module
explicitly, but probably requested by btusb module.

maybe another subpackage - bluez-firmware-nonfree

another solution raspi-wireless-firmware and raspi3-wireless-firmware 
subpackages
(maybe also raspi-bluetooth-firmware/raspi3-bluetooth-firmware)

On Wed, Jul 13, 2022 at 06:58:33PM +0200, Diederik de Haas wrote:
> On woensdag 13 juli 2022 15:41:25 CEST Jiri Kastner wrote:
> > raspi-firmware should depend on following packages:
> >  - firmware-brcm80211
> >  - firmware-misc-nonfree
> >  - bluez-firmware
> 
> I'd object to the use (and implementation) of the word 'depend'.
> A recommends or suggests seems more appropriate.



-- 


signature.asc
Description: PGP signature

Bug#1014919: libflint17 is incorrectly marked Multi-Arch: same

[Adrian Bunk]

Package: libflint17
Version: 2.9.0-2
Severity: serious

/usr/lib/x86_64-linux-gnu/libflint-2.8.5.so.16.1.5
-> /usr/lib/libflint.so.17.0.0

It was likely unintentional that the library moved to a
non-multiarch location in
https://salsa.debian.org/math-team/flint/-/commit/5cee4678c1eb7699283418f9b48b2b59ac1c35f0

Bug#1012999: tagging and additional text

[Geert Stappers]

control: tags -1 confirmed


Hi,


Here a potential uploading sponsor.

Thing I want to tell^W^W^Wtelling is that I have seen the
  Please keep the issue open until the package can be built in
  a follow-up test rebuild.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1014394: linux-image-5.10.0-15: Re: linux kernel 5.10.0-15 on virtualbox host causes random process crashes in guests

[Walter Schweizer]

Package: src:linux
Followup-For: Bug #1014394
X-Debbugs-Cc: s...@users.sourceforge.net

Dear Maintainer,

VirtualBox (6.1.35) fixes the crashes on my system too.

See https://www.virtualbox.org/ticket/20914

Regards
Walter


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: FUJITSU
product_name: CELSIUS H760
product_version: 10601186099
chassis_vendor: FUJITSU
chassis_version: CELSIUS H760
bios_vendor: FUJITSU // Insyde Software Corp.
bios_version: Version 1.32
board_vendor: FUJITSU
board_name: FJNB29A
board_version: D4

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1910] (rev 07)
Subsystem: Fujitsu Limited. Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Host Bridge/DRAM Registers [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 07) (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

00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset 
Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family USB 
3.0 xHCI Controller [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230 
Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31)
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family MEI 
Controller [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:16.3 Serial controller [0700]: Intel Corporation 100 Series/C230 Series 
Chipset Family KT Redirection [8086:a13d] (rev 31) (prog-if 02 [16550])
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family KT 
Redirection [10cf:1937]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: serial

00:17.0 SATA controller [0106]: Intel Corporation HM170/QM170 Chipset SATA 
Controller [AHCI Mode] [8086:a103] (rev 31) (prog-if 01 [AHCI 1.0])
Subsystem: Fujitsu Limited. HM170/QM170 Chipset SATA Controller [AHCI 
Mode] [10cf:1937]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset 
Family PCI Express Root Port #1 [8086:a110] (rev f1) (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

00:1c.1 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset 
Family PCI Express Root Port #2 [8086:a111] (rev f1) (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

00:1c.2 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series Chipset 
Family PCI Express Root Port #3 [8086:a112] (rev f1) (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- 

Bug#1014918: src:nrepl-clojure: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: nrepl-clojure
Version: 0.6.0-2
Severity: serious
Control: close -1 0.9.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1011970

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:nrepl-clojure has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package has an 
autopkgtest regression that I reported some time ago in bug #1011970.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014917: libflint17 lacks SONAME

[Adrian Bunk]

Package: libflint17
Version: 2.9.0-2
Severity: grave
Tags: ftbfs
Control: affects src:antic src:flint-arb src:linbox src:calcium src:e-antic 
src:gyoto src:normaliz src:singular src:macaulay2 src:polymake src:sagemath

$ objdump -p /usr/lib/x86_64-linux-gnu/libflint-2.8.5.so.16.1.5 | grep SONAME
  SONAME   libflint-2.8.5.so
$ objdump -p /usr/lib/libflint.so.17.0.0 | grep SONAME
$

One of the problems this causes is that reverse dependencies
do not get a shlibs-generated dependency on libflint17.

debian/rules sets EXTRA_SHARED_FLAGS (to avoid the rpath?),
but upstream configure also uses it to set -soname and
https://salsa.debian.org/math-team/flint/-/commit/ea3ae82694953d6386898f051dd9b1b2f111dfaa
removed the code correcting that.

Bug#1014916: aseba: please add support for riscv64

[Bo YU]

Source: aseba
Version: 1.6.99+dfsg-1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The aseba package can be built riscv64 arch with the patch attached,
please consider to add support for riscv64. Thank you.

Bo
-- 
Best Regards,

diff -Nru aseba-1.6.99+dfsg/debian/control aseba-1.6.99+dfsg/debian/control
--- aseba-1.6.99+dfsg/debian/control	2022-05-12 14:09:31.0 +
+++ aseba-1.6.99+dfsg/debian/control	2022-05-12 14:10:00.0 +
@@ -18,7 +18,7 @@
 Homepage: https://github.com/aseba-community/aseba
 
 Package: aseba
-Architecture: any-amd64 any-i386 arm64 mips64el mipsel
+Architecture: any-amd64 any-i386 arm64 mips64el mipsel riscv64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: aseba-plugin-blockly
 Description: Event-based framework for distributed mobile robots control


signature.asc
Description: PGP signature

Bug#1014915: orage: packaging for orage-4.16

[Saša Janiška]

Package: orage
Severity: wishlist

Dear Maintainer,

The Xfce's calenaring application orage has become revived, ported to 
GTK3 and there is 4.16 releasa available 
(https://gitlab.xfce.org/apps/orage/-/blob/master/NEWS) , so it would be 
nice to re-add it to Debian?


Sincerely,
Saša Janiška

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.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

Bug#906752: sudo, pam_keyinit, what to do?

[Marc Haber]

On Thu, Jul 14, 2022 at 12:20:48PM +0200, Chris Hofstaedtler wrote:
> Well, the pam_keyinit man page says it was written by David Howells
> , but I don't know if he is still working on
> it.

I reached out to that address a few months ago, they didnt bother
replying.

> This openSUSE bug seems to touch on related questions:
> https://bugzilla.suse.com/show_bug.cgi?id=1081947

Lesson learned: The major distributions ALL do not know what they're
doing, they're blindly copying from each other. And nobody cares.

Greetings
Marc



-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1013916: missing dependency

[Mark Hindley]

Control: tags -1 patch

Georges,

I have bumped into this issue as well.

A patch to fix is below.

Thanks,

Mark

>From 88e5b316d6ad0587226e17b010d7c43e75d4815d Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Thu, 14 Jul 2022 12:50:18 +0100
Subject: [PATCH] d/control: move adduser dependency to cron-daemon-common
 (Closes: #1013916).

d/cron-daemon-common.postinst uses addgroup. When the -common package was
created, moving the adduser dependency was overlooked.
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 8f00824..a7f2bab 100644
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,6 @@ Depends:
 ${shlibs:Depends},
 ${misc:Depends},
 sensible-utils,
-adduser,
 lsb-base,
 libpam-runtime
 Recommends:
@@ -58,7 +57,8 @@ Description: process scheduling daemon
 
 Package: cron-daemon-common
 Architecture: all
-Depends: ${misc:Depends}
+Depends: ${misc:Depends},
+adduser,
 Conflicts:
cron (<< 3.0pl1-140),
cronie (<< 1.6.1-4),
-- 
2.35.1

Bug#1014914: Regression in @types

[Mark Weyer]

Package: nodejs
Version: 12.22.12~dfsg-1~deb11u1

The upgrade from Version 12.22.5~dfsg-2~11u1 to 12.22.12~dfsg-1~deb11u1 broke 
Typescript (from package node-typescript) for me.
For a minimal example, let test.ts contain just the following line:

  process.exit(0)

And compile it with

  tsc --typeRoots /usr/share/nodejs/@types/node test.ts

With Version 12.22.5~dfsg-2~11u1, everything is fine. With Version 
12.22.12~dfsg-1~deb11u1 I get

  test.ts:1:1 - error TS2580: Cannot find name 'process'. Do you need to 
install type definitions for node? Try `npm i --save-dev @types/node`.

  1 process.exit(0)
~~~


  Found 1 error.

Best regards,

  Mark Weyer


Hahn-Schickard
Dr. Mark Weyer
Application Engineering

Telefon: +49 7721 943-189
E-Mail: mark.we...@hahn-schickard.de

Hahn-Schickard-Gesellschaft für angewandte Forschung e.V.
Wilhelm-Schickard-Str. 10
D-78052 Villingen-Schwenningen
www.Hahn-Schickard.de

Wir verweisen hiermit auf unsere 
Datenschutzerklärung.

Bug#1014913: [Pkg-utopia-maintainers] Bug#1014913: network-manager: Follow Up: L2TP-VPN still doesn't work (worked with 1.34.0-1)

[Michael Biebl]

Am 14.07.22 um 13:35 schrieb Marcel Jira:

Package: network-manager
Version: 1.38.2-1
Severity: important
X-Debbugs-Cc: marcel.j...@gmail.com

Dear Maintainer,

In March 2022 I reported bug #1007899 (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1007899) that prevents me to connect to a L2TP-VPN. Until
version 1.34.0-1 the connection was working.

The problem still couldn't be solved even after updating to

* network-manager 1.38.2-1
* network-manager-l2tp 1.20.2-1
* network-manager-l2tp-gnome 1.20.2-1

Also, me and our IT department were able to reproduce this bug with a fresh
installation of Debian Bookworm, Ubuntu 22.04 and Ubuntu 22.10.

The L2TP VPN is provided by a hardware firewall ZYXEL USG60.

I shall be happy to provide additional information in order to get this problem
resolved.




Please report this upstream at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/

Thanks,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Dominik George]

Hi,

what practical use, except for direct discriminatory attempts against 
non-binaries and probably even many cis people, does such a package have?

-nik

Bug#1014913: network-manager: Follow Up: L2TP-VPN still doesn't work (worked with 1.34.0-1)

[Marcel Jira]

Package: network-manager
Version: 1.38.2-1
Severity: important
X-Debbugs-Cc: marcel.j...@gmail.com

Dear Maintainer,

In March 2022 I reported bug #1007899 (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1007899) that prevents me to connect to a L2TP-VPN. Until
version 1.34.0-1 the connection was working.

The problem still couldn't be solved even after updating to

* network-manager 1.38.2-1
* network-manager-l2tp 1.20.2-1
* network-manager-l2tp-gnome 1.20.2-1

Also, me and our IT department were able to reproduce this bug with a fresh
installation of Debian Bookworm, Ubuntu 22.04 and Ubuntu 22.10.

The L2TP VPN is provided by a hardware firewall ZYXEL USG60.

I shall be happy to provide additional information in order to get this problem
resolved.


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

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

Versions of packages network-manager depends on:
ii  adduser  3.121
ii  dbus 1.14.0-1
ii  libaudit11:3.0.7-1+b1
ii  libbluetooth35.64-2
ii  libc62.33-7
ii  libcurl3-gnutls  7.83.1-2
ii  libglib2.0-0 2.72.3-1
ii  libgnutls30  3.7.6-2
ii  libjansson4  2.14-2
ii  libmm-glib0  1.18.8-1
ii  libndp0  1.8-1
ii  libnewt0.52  0.52.21-5+b1
ii  libnm0   1.38.2-1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1.2-1.2
ii  libselinux1  3.4-1
ii  libsystemd0  251.2-7
ii  libteamdctl0 1.31-1
ii  libudev1 251.2-7
ii  policykit-1  0.105-33
ii  udev 251.2-7

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.86-1.1
ii  libpam-systemd   251.2-7
ii  modemmanager 1.18.8-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.04.08-2
ii  wpasupplicant2:2.10-9+b1

Versions of packages network-manager suggests:
ii  iptables   1.8.8-1
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-2

-- no debconf information

Bug#1014898: ITP: gcompat -- The GNU C library compatibility layer for musl

[Ben Hutchings]

On Thu, 2022-07-14 at 14:15 +0900, Nobuhiro Iwamatsu wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nobuhiro Iwamatsu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: gcompat
>   Version : 1.0.0
>   Upstream Author : A. Wilcox
> * URL : https://git.adelielinux.org/adelie/gcompat
> * License : Expat
>   Programming Lang: C
>   Description : The GNU C library compatibility layer for musl
> 
>   The gcompat provides glibc-compatible APIs for use on musl libc systems.
>   .
>   This library is designed to be used for binaries that are already
>   compiled against glibc. It does not contain any headers, and cannot be
>   used to build software that requires glibc. It is instead recommended
>   that any software that requires glibc APIs be modified to become more
>   portable.
>   .
>   This library can optionally be compiled with other libraries to make a
>   single, unfied solution. This can include fts, libucontext, obstack,
>   and others.
>   .
>   gcompat additionally provides a loader stub. This is a small library
>   that has the same name as the glibc dynamic linker on glibc platforms;
>   when a binary is run that uses glibc as its dynamic linker, the stub
>   will run, redirecting it to use musl and automatically preloading the
>   gcompat library.
> 

How would this be used in Debian, when all our ports already use glibc?

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Ben Hutchings]

On Thu, 2022-07-14 at 10:20 +0100, Edward Betts wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: gender-guesser
>   Version : 0.4.0
>   Upstream Author : Israel Saeta Pérez 
> * URL : https://github.com/lead-ratings/gender-guesser
> * License : GPL-3 & GFDL-1.2+
>   Programming Lang: Python
>   Description : Guess the gender from first name
[...]

This is a horribly bad idea, what do you need it for?

Ben.


-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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

Bug#998664: Normal issue after a second look

[julien . puydt]

Hi,

I'm giving a second look at your problem. What I don't get is why you
get a link-time error for a function that should have been missing at
compile-time already.

I put your sample code in essai.cc then compiled in two stages:
$ g++ -Wall -c -o essai.o essai.cc (compilation)
$ g++ -Wall -o essai essai.o -lntl (link)

and everything worked, but I'm using the testing package for NTL, so
that might explain things.

Can you tell me what happens with the old package?

Thanks,

J.Puydt

Bug#1011259: pdns shouldn't be built on 32-bit architectures

[Chris Hofstaedtler]

Hi,

* Sergio Durigan Junior  [220519 04:00]:
> --8<---cut here---start->8---
> checking size of time_t... 4
> configure: error: size of time_t is 4, which is not large enough to fix the 
> y2k38 bug
> --8<---cut here---end--->8---
> 
> This is done on purpose by upstream.  I also noticed that Fedora
> disables the build of pdns on i386 and armhf.

Yeah, I know.

> I strongly believe we
> should do the same in Debian.  If you take a look at the current build
> logs, you'll notice that the package is already FTBFSing on those
> architectures.

I am waiting for glibc allowing 64bit time_t, which is supposedly
"coming soon".

Chris

Bug#906752: sudo, pam_keyinit, what to do?

[Chris Hofstaedtler]

Hi Marc,

* Marc Haber  [220705 15:53]:
> I'm coming back to this after being busy with other things.
> 
> On Sun, Feb 06, 2022 at 05:09:10PM +0100, Chris Hofstaedtler wrote:
> > * Marc Haber  [220206 12:36]:
> > > in sudo, we have currently the situation whether to add calls to
> > > pam_keyinit in our pam configuration files. There is quite a number of
> > > packages doing this, but the pam_keyinit documentation advises "programs
> > > like su" against doing so. However, in Debian, /etc/pam.d/su-l
> > > references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
> > > doas doesnt seem to reference pam_keyinit at all.
> > > 
> > > If sudo goes the way to mimic what su does, we would reference
> > > pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
> > > an interactive session, but not in /etc/pam.d/sudo.
> > > 
> > > May I ask for you rationale to do things the way you did them for su and
> > > pam_keyinit? Your insights might help us to take a wise decision for
> > > sudo.
> > 
> > I do not know why this was done for su-l and not su. My speculation
> > would be that we have inherited the su-l PAM config from Fedora, and
> > the su PAM config from src:shadow before 2018. Maybe the distinction
> > is an accident.

[..]

> > It would appear to me that keyutils and pam_keyinit, and most of the
> > util-linux PAM config originate in Fedora(/RH). The Fedora folks
> > are probably the ones to ask how all of this is supposed to work.
> 
> Chris,
> Can you give me a pointer to whom in Fedora I'm supposed to reach out?

Well, the pam_keyinit man page says it was written by David Howells
, but I don't know if he is still working on
it.

This openSUSE bug seems to touch on related questions:
https://bugzilla.suse.com/show_bug.cgi?id=1081947

Unfortunately the only real doc appears to be the man page :-|

Chris

Bug#1014912: buster-pu: package cargo-mozilla/0.57.0-7~deb10u1

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This updates cargo-mozilla in buster. The debdiff against the bullseye
update is trivial, I bumped the rustc-mozilla build-deps to avoid a FTBFS
if this is built before rustc.

Cheers,
Emilio
diff -Nru cargo-mozilla-0.57.0/debian/changelog 
cargo-mozilla-0.57.0/debian/changelog
--- cargo-mozilla-0.57.0/debian/changelog   2022-07-01 12:25:10.0 
+0200
+++ cargo-mozilla-0.57.0/debian/changelog   2022-07-14 12:00:57.0 
+0200
@@ -1,3 +1,11 @@
+cargo-mozilla (0.57.0-7~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to buster.
+  * Bump rustc-mozilla build-dep.
+
+ -- Emilio Pozuelo Monfort   Thu, 14 Jul 2022 12:00:57 +0200
+
 cargo-mozilla (0.57.0-7~deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cargo-mozilla-0.57.0/debian/control 
cargo-mozilla-0.57.0/debian/control
--- cargo-mozilla-0.57.0/debian/control 2022-07-01 12:25:10.0 +0200
+++ cargo-mozilla-0.57.0/debian/control 2022-07-14 12:00:57.0 +0200
@@ -11,8 +11,8 @@
  debhelper (>= 12~),
  dpkg-dev (>= 1.17.14),
  cargo:native(>= 0.17.0),
- rustc-mozilla:native(>= 1.16),
- libstd-rust-mozilla-dev (>= 1.16),
+ rustc-mozilla:native(>= 1.59),
+ libstd-rust-mozilla-dev (>= 1.59),
  pkg-config,
  bash-completion,
  python3:native,

Bug#1014745: thunderbird: Reply all remove Cc participants

[Carsten Schoenert]

Hello Eric,

Am 14.07.22 um 11:48 schrieb eric:

I had the same problem on a specific exchnage account. Reply all did
not copy the content and did remove all the CC.
you could try out TB 1:103.0~b5-1 from experimental which should have 
included the fix which issue here is about.


Keep in mind that the configuration will get bumped to the new main 
version and isn't backward compatible, so please make a backup of your 
config before starting the installed version from experimental.


--
Regards
Carsten

Bug#1014745: thunderbird: Reply all remove Cc participants

[Eric Valette]

On 14/07/2022 12:04, Carsten Schoenert wrote:


Hello Eric,

Am 14.07.22 um 11:48 schrieb eric:

I had the same problem on a specific exchnage account. Reply all did
not copy the content and did remove all the CC.
you could try out TB 1:103.0~b5-1 from experimental which should have 
included the fix which issue here is about.


Keep in mind that the configuration will get bumped to the new main 
version and isn't backward compatible, so please make a backup of your 
config before starting the installed version from experimental.





That's exactly why I will not do this. I want to be on the next esr 
branch and test more deeply as I will have to use it on my professionnal 
account as well. If it is fixed in 103, I bet it will be backported (ESR 
after all). I cannot afford to break my main setup even more.


It did happen everytime on .1, did not manage to reproduce it with the 
broken mail on .2.


Thanks for the support anyway.

--eric

Bug#1014910: libantic0 package not depending on libflint

[julien . puydt]

Hi,

I can confirm the problem, but since libflint-dev is in the source
package Build-Depends: and the binary package Depends: does mention
${shlibs:Depends}, I'm pretty clueless on how that happens...

Cheers,

J.Puydt

Bug#1014675: thunderbird: Confirmed here also.

[eric]

Package: thunderbird
Version: 1:102.0.2-1
Followup-For: Bug #1014675

I can confirm nntp account is broken as welle as newgroup subscription.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  kdialog  4:21.12.3-1
ii  libasound2   1.2.7.1-1
ii  libatk1.0-0  2.45.1-1
ii  libc62.34-0experimental5
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.73.2-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.17.0~git20220428-1
ii  libstdc++6   12.1.0-5
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-1
ii  x11-utils7.7+5
ii  zenity   3.42.1-2
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1

Versions of packages thunderbird suggests:
ii  apparmor  3.0.4-3
ii  fonts-lyx 2.3.6.1-1
ii  libgssapi-krb5-2  1.20~beta1-1

-- no debconf information

Bug#1014911: thunderbird: Upgrading from 91 breaks e2ee setup on all accounts

[eric]

Package: thunderbird
Version: 1:102.0.2-1
Severity: important

I add an email account with end to end encryption setup (both SMIME and OpenPGP 
keys).
After 102 upgrade, the e2ee setup menu in all the mail accounts of the profile
disappeared.

I have another account with no e2ee setup and for this one the  the e2ee setup
menu are normally shown.

Probably an e2ee upgrade problem.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  kdialog  4:21.12.3-1
ii  libasound2   1.2.7.1-1
ii  libatk1.0-0  2.45.1-1
ii  libc62.34-0experimental5
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.73.2-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.17.0~git20220428-1
ii  libstdc++6   12.1.0-5
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-1
ii  x11-utils7.7+5
ii  zenity   3.42.1-2
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1

Versions of packages thunderbird suggests:
ii  apparmor  3.0.4-3
ii  fonts-lyx 2.3.6.1-1
ii  libgssapi-krb5-2  1.20~beta1-1

-- no debconf information

Bug#243929: adduser: Reserve specific UIDs for users that will be created at a later time

[Christoph Biedl]

Upon request of Marc Haber, I'm attaching the latest version of the
patch for this feature I had implemented more than twelve years ago and
maintained for all the adduser versions that followed.

Documentation is missing, so here are the relevant bits:

===

To enable this feature, you need to define a variable UID_POOL (for
user IDs) and/or GID_POOL (for group IDs) in F. The value
is either a file or a directory, in the latter case all files named
F<*.conf> in that directory are considered.

The file format is inspired by F: Text lines,
records separated by a colon. The values are 

* user name/group name (mandatory)
* user ID/group ID (mandatory)
* gecos field (optional, useful for user IDs only)
* home directory (ditto)
* shell (ditto)

It is possible to use the same file/directory for UID_POOL and GID_POOL.

===

If you want to include that, I'll be happy to provide more explanation
if needed.

The coding style might be a bit outdated, I tried to follow the style
adduser had in 2009.

My personal preference for the pool variables is.

UID_POOL=/etc/adduser-pool.d/
GID_POOL=/etc/adduser-pool.d/

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#243929: adduser: Reserve specific UIDs for users that will be created at a later time

[Christoph Biedl]

Christoph Biedl wrote...

> Upon request of Marc Haber, I'm attaching the latest version of the
diff --git a/AdduserCommon.pm b/AdduserCommon.pm
index d8cf966..21d2195 100644
--- a/AdduserCommon.pm
+++ b/AdduserCommon.pm
@@ -27,6 +27,7 @@ my $lockfile;
 'gtx',
 'invalidate_nscd',
 'read_config',
+'read_pool',
 's_print',
 's_printf',
 'systemcall',
@@ -132,6 +133,64 @@ sub read_config {
 close CONF || die "$!";
 }
 
+# read names and IDs from a pool file
+# parameters:
+#  -- filename of the pool file, or directory containing files
+#  -- a hash for the pool data
+sub read_pool {
+my ($pool_file, $poolref) = @_;
+my ($name, $id);
+my %ids = ();
+
+if (-d $pool_file) {
+	opendir (DIR, $pool_file) or
+	dief gtx("Cannot read directory `%s'"),$pool_file;
+	my @files = readdir (DIR);
+	closedir (DIR);
+	foreach (sort @files) {
+	next if (/^\./);
+	next if (!/\.conf$/);
+	my $file = "$pool_file/$_";
+	next if (! -f $file);
+	read_pool ($file, $poolref);
+	}
+	return;
+}
+if (! -f $pool_file) {
+	warnf gtx("`%s' does not exist.\n"),$pool_file if $verbose;
+	return;
+}
+
+open (POOL, $pool_file) || dief ("%s: `%s'\n",$pool_file,$!);
+while () {
+	chomp;
+	next if /^#/ || /^\s*$/;
+
+	($name, $id, $gecos, $home, $shell) = split (/:/);
+	if (!$name || $name !~ /^([_a-zA-Z0-9-]+)$/ ||
+	!$id || $id !~ /^(\d+)$/) {
+	warnf gtx("Couldn't parse `%s', line %d.\n"),$pool_file,$.;
+	next;
+	}
+	if (defined($poolref->{$name})) {
+	dief gtx("Duplicate name `%s' at `%s', line %d.\n"),$name,$pool_file,$.;
+	}
+	if (defined($ids{$id})) {
+	dief gtx("Duplicate ID `%s' at `%s', line %d.\n"),$id,$pool_file,$.;
+	}
+
+	$poolref->{$name} = {
+	'id' => $id,
+	'gecos' => $gecos,
+	'home' => $home,
+	'shell' => $shell
+	};
+}
+
+close POOL || die "$!";
+}
+
+
 # return a user's groups
 sub get_users_groups {
 my($user) = @_;
@@ -281,7 +340,9 @@ sub preseed_config {
 exclude_fstypes => "(proc|sysfs|usbfs|devpts|devtmpfs|devfs|afs)",
 skel_ignore_regex => "(dpkg|ucf)-(old|new|dist)\$",
 extra_groups => "users",
-add_extra_groups => 0
+add_extra_groups => 0,
+uid_pool => "",
+gid_pool => "",
   );
 
   # Initialize to the set of known variables.
diff --git a/adduser b/adduser
index 045b87f..531af4e 100755
--- a/adduser
+++ b/adduser
@@ -116,6 +116,8 @@ my $first_uid = undef;
 my $last_uid = undef;
 my $dir_mode = undef;
 my $perm = undef;
+my %uid_pool;
+my %gid_pool;
 
 our @names;
 
@@ -237,6 +239,14 @@ $ENV{"DEBUG"}   = $verbose;
 # preseed configuration data and then read the config file
 preseed_config(\@defaults,\%config);
 
+# read the uid and gid pool
+if ($config{"uid_pool"}) {
+read_pool ($config{"uid_pool"}, \%uid_pool);
+}
+if ($config{"gid_pool"}) {
+read_pool ($config{"gid_pool"}, \%gid_pool);
+}
+
 ($new_name) if defined $new_name;
 $SIG{'INT'} = $SIG{'QUIT'} = $SIG{'HUP'} = 'handler';
 
@@ -293,7 +303,8 @@ if ($action eq "addsysgroup") {
 
 if (!defined($new_gid)) {
 $new_gid = _avail_gid($config{"first_system_gid"},
-   $config{"last_system_gid"});
+   $config{"last_system_gid"},
+   $gid_pool{$new_name}{'id'});
 if ($new_gid == -1) {
 	warnf gtx("No GID is available in the range %d-%d (FIRST_SYS_GID - LAST_SYS_GID).\n"),$config{"first_system_gid"},$config{"last_system_gid"};
 dief (gtx("The group `%s' was not created.\n"),$new_name);
@@ -323,7 +334,8 @@ if ($action eq "addgroup") {
 	if (defined($new_gid) && defined(getgrgid($new_gid)));
 if (!defined($new_gid)) {
 $new_gid = _avail_gid($config{"first_gid"},
-   $config{"last_gid"});
+   $config{"last_gid"},
+   $gid_pool{$new_name}{'id'});
 
 if ($new_gid == -1) {
 	print STDERR "$0: ";
@@ -391,18 +403,21 @@ if ($action eq "addsysuser") {
 
 if (!defined($new_uid) && $make_group_also) {
 	$new_uid = _avail_uid($config{"first_system_uid"},
-   $config{"last_system_uid"});
+   $config{"last_system_uid"},
+   $uid_pool{$new_name}{'id'});
 if ($new_uid == -1) {
 	warnf gtx("No UID/GID pair is available in the range %d-%d (FIRST_SYS_UID - LAST_SYS_UID).\n"),$config{"first_system_uid"},$config{"last_system_uid"};
 dief (gtx("The user `%s' was not created.\n"),$new_name);
 }
 $new_gid = _avail_gid($config{"first_system_gid"},
-	$config{"last_system_gid"});
+	$config{"last_system_gid"},
+$gid_pool{$new_name}{'id'});
 	$ingroup_name = $new_name;
 }
 elsif (!defined($new_uid) && !$make_group_also) {
 	$new_uid = _avail_uid($config{"first_system_uid"},
-   $config{"last_system_uid"});
+   $config{"last_system_uid"},
+   $uid_pool{$new_name}{'id'});
 if ($new_uid == -1) {
 	warnf gtx("No UID is available in the range %d-%d (FIRST_SYS_UID - 

Bug#1014745: thunderbird: confirmed here

[eric]

Package: thunderbird
Version: 1:102.0.2-1
Followup-For: Bug #1014745

I had the same problem on a specific exchnage account. Reply all did not copy 
the content and did remove all the CC.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  kdialog  4:21.12.3-1
ii  libasound2   1.2.7.1-1
ii  libatk1.0-0  2.45.1-1
ii  libc62.34-0experimental5
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.73.2-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.17.0~git20220428-1
ii  libstdc++6   12.1.0-5
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-1
ii  x11-utils7.7+5
ii  zenity   3.42.1-2
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1

Versions of packages thunderbird suggests:
ii  apparmor  3.0.4-3
ii  fonts-lyx 2.3.6.1-1
ii  libgssapi-krb5-2  1.20~beta1-1

-- no debconf information

Bug#1014910: antic: lost libflint dependency after binNMU

[Sebastian Ramacher]

Source: antic
Version: 0.2.5+ds-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org

After the binNMU to rebuild antic against libflint17, antic's binary
packages no longer depend on any libflint package.

https://buildd.debian.org/status/fetch.php?pkg=antic=amd64=0.2.5%2Bds-1%2Bb1=1657745373=0

Cheers
-- 
Sebastian Ramacher

Bug#1014901: Home directories should not be setgid by default

[Marc Haber]

Control: -1 severity wishlist

On Wed, Jul 13, 2022 at 11:45:58PM -0700, Josh Triplett wrote:
> adduser 3.122 changes home directories to be setgid by default. The
> issues discussing that change mention use cases involving multiuser
> systems with shared groups, though that doesn't explain setting this
> mode on home directories rather than on shared work areas.

This was part of the big adduser discussion debian-devel@l.d.o and
didn't get much attention. The setting is run-time configurable in
adduser.conf.

I would be willing to re-raise the severity of this issue if I can find
a case for changing the default AGAIN and there is some discussion on
debian-devel on this topic.

> One of the issues links to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks
> about easing the setup of shared directories for users who don't feel
> comfortable running `chmod 2770` or similar themselves. That seems like
> a relatively small justification, given that anyone setting up a shared
> work directory *can* run `chmod 2770` or similar themselves, and doing
> so does not require any special permission.

A local admin who doesn't like the behavior is free to change the
default by setting an appropriate DIR_MODE in adduser.conf. There is a
NEWS.Debian entry pointing the local administrator to this new behavior.

> The more recent issue 643559 suggests that
> > Those "bad side-effects", if they were ever relevant and important
> > enough to make personal groups not work properly, have now been fixed.
> 
> However, this is not the case; this change does in fact have bad
> side-effects. This change breaks some common use cases that apply to
> users on many systems, both single-user and multi-user.

Can we please have more information than just "bad side-effects"?

> In particular, it is common to build various kinds of filesystem,
> container, or disk images, and to do so within your home directory.
> Users writing tools and scripts to build such images need to make sure
> to create files with an appropriate mode, but such scripts often assume
> (reasonably) that if they're running as root:root and they create a
> file, that file will be owned by root:root. Attempting to build
> filesystems, containers, disk images, or similar in an unexpectedly
> setgid directory will produce unexpected results (leaving aside that the
> directory mode itself will be surprising).

Would it help to do this kind of work in a subdirectory under the home
directory and making sure that one is not setgid? I am happy to document
this.

> Given those tradeoffs, I don't think this change is the right default.
> I'd like to ask that the default mode be reverted from 2700 to 700.

I'd like you to take this discussion to debian-devel, most desireably as
reply to https://lists.debian.org/debian-devel/2022/03/msg00304.html,
.

We can also talk to the ctte if the discussion on -devel doesn't bring
any more consensus.

It is really sad that you didn't participate in the discussion in march,
where this part of the changes didnt get much attention and noone came
up with any arguments against sgid home directories. I personally am at
a loss here since I am just a server jockey who doesn't have many
unprivileged shell account users on my boxes.


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1014909: buster-pu: package rust-cbindgen/0.23.0-1~deb10u1

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This updates rust-cbindgen to 0.23 for FF 102. FF/TB are the only users
of this package, so that should be fine.

The debdiff against bullseye adds a missing build-dep on the new rustc.

Cheers,
Emilio
diff -Nru rust-cbindgen-0.23.0/debian/changelog 
rust-cbindgen-0.23.0/debian/changelog
--- rust-cbindgen-0.23.0/debian/changelog   2022-07-04 10:53:21.0 
+0200
+++ rust-cbindgen-0.23.0/debian/changelog   2022-07-14 10:52:44.0 
+0200
@@ -1,3 +1,11 @@
+rust-cbindgen (0.23.0-1~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to bullseye.
+  * Bump rustc-mozilla build-deps to 1.59.
+
+ -- Emilio Pozuelo Monfort   Thu, 14 Jul 2022 10:52:44 +0200
+
 rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rust-cbindgen-0.23.0/debian/control 
rust-cbindgen-0.23.0/debian/control
--- rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.0 +0200
+++ rust-cbindgen-0.23.0/debian/control 2022-07-14 10:52:18.0 +0200
@@ -4,8 +4,8 @@
 Build-Depends: debhelper (>= 12),
  dh-cargo (>= 17),
  cargo:native,
- rustc-mozilla:native,
- libstd-rust-mozilla-dev,
+ rustc-mozilla:native (>= 1.59),
+ libstd-rust-mozilla-dev (>= 1.59),
 # librust-clap-3+default-dev (>= 3.1-~~),
 # librust-heck-0.4+default-dev,
 # librust-indexmap-1+default-dev,

Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1

[Sebastian Ramacher]

Control: tags 1000932 + patch
Control: tags 1000932 + pending

Dear maintainer,

I've prepared an NMU for doxygen (versioned as 1.9.1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru doxygen-1.9.1/debian/changelog doxygen-1.9.1/debian/changelog
--- doxygen-1.9.1/debian/changelog	2021-03-22 00:04:01.0 +0100
+++ doxygen-1.9.1/debian/changelog	2022-07-14 11:12:01.0 +0200
@@ -1,3 +1,10 @@
+doxygen (1.9.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Switch to unversioned llvm dependencies (Closes: #1000932)
+
+ -- Sebastian Ramacher   Thu, 14 Jul 2022 11:12:01 +0200
+
 doxygen (1.9.1-2) unstable; urgency=medium
 
   * Build with LLVM support on riscv64. Closes: #985587.
diff -Nru doxygen-1.9.1/debian/control doxygen-1.9.1/debian/control
--- doxygen-1.9.1/debian/control	2021-03-21 11:06:46.0 +0100
+++ doxygen-1.9.1/debian/control	2022-07-14 11:11:30.0 +0200
@@ -10,9 +10,9 @@
   zlib1g-dev,
   libxapian-dev (>= 1.2.21-1.2),
   cmake,
-  llvm-11-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
-  libclang-11-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
-  clang-11[amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
+  llvm-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
+  libclang-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
+  clang[amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el riscv64 s390x sparc64],
   sassc,
   faketime,
   mat2

Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This updates rustc-mozilla in buster, in preparation for Firefox 102.

I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.

I've uploaded the package already to oldstable-new.

Cheers,
Emilio
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/changelog 
buster/rustc-mozilla-1.59.0+dfsg1/debian/changelog
--- rustc-mozilla-1.59.0+dfsg1/debian/changelog 2022-07-03 11:51:30.0 
+0200
+++ buster/rustc-mozilla-1.59.0+dfsg1/debian/changelog  2022-07-12 
00:18:55.0 +0200
@@ -1,3 +1,12 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u1) buster; urgency=medium
+
+  * Backport to buster.
+  * Lower debhelper compat to 12. Stop using env variables in debhelper
+install files.
+  * Disable windows target.
+
+ -- Emilio Pozuelo Monfort   Tue, 12 Jul 2022 00:18:55 +0200
+
 rustc-mozilla (1.59.0+dfsg1-1~deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/control 
buster/rustc-mozilla-1.59.0+dfsg1/debian/control
--- rustc-mozilla-1.59.0+dfsg1/debian/control   2022-06-17 17:51:59.0 
+0200
+++ buster/rustc-mozilla-1.59.0+dfsg1/debian/control2022-07-11 
16:52:06.0 +0200
@@ -9,7 +9,7 @@ Rules-Requires-Root: no
 # :native annotations are to support cross-compiling, see README.Debian
 Build-Depends:
  debhelper (>= 9),
- debhelper-compat (= 13),
+ debhelper-compat (= 12),
  dpkg-dev (>= 1.17.14),
  python3:native,
 # cargo:native (>= 0.40.0)  ,
@@ -17,8 +17,8 @@ Build-Depends:
 # rustc:native (<= 1.59.0++),
  llvm-13-dev:native,
  llvm-13-tools:native,
- gcc-mingw-w64-x86-64-posix:native [amd64] ,
- gcc-mingw-w64-i686-posix:native [i386] ,
+# gcc-mingw-w64-x86-64-posix:native [amd64] ,
+# gcc-mingw-w64-i686-posix:native [i386] ,
  libllvm13 (>= 1:13.0.0),
  cmake (>= 3.0) | cmake3,
 # needed by some vendor crates
@@ -123,34 +123,34 @@ Description: Rust standard libraries - d
  needed to compile Rust programs. It may also be installed on a system
  of another host architecture, for cross-compiling to this architecture.
 
-Package: libstd-rust-mozilla-dev-windows
-Section: libdevel
-Architecture: amd64 i386
-Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends:
- gcc-mingw-w64-x86-64-posix [amd64],
- gcc-mingw-w64-i686-posix [i386],
-Conflicts: libstd-rust-dev-windows
-Replaces: libstd-rust-dev-windows
-Build-Profiles: 
-Description: Rust standard libraries - development files
- Rust is a curly-brace, block-structured expression language.  It
- visually resembles the C language family, but differs significantly
- in syntactic and semantic details.  Its design is oriented toward
- concerns of "programming in the large", that is, of creating and
- maintaining boundaries - both abstract and operational - that
- preserve large-system integrity, availability and concurrency.
- .
- It supports a mixture of imperative procedural, concurrent actor,
- object-oriented and pure functional styles.  Rust also supports
- generic programming and meta-programming, in both static and dynamic
- styles.
- .
- This package contains the standard Rust libraries including development files,
- needed to cross-compile Rust programs to the *-pc-windows-gnu target
- corresponding to the architecture of this package.
-
+#Package: libstd-rust-mozilla-dev-windows
+#Section: libdevel
+#Architecture: amd64 i386
+#Multi-Arch: same
+#Depends: ${shlibs:Depends}, ${misc:Depends}
+#Recommends:
+# gcc-mingw-w64-x86-64-posix [amd64],
+# gcc-mingw-w64-i686-posix [i386],
+#Conflicts: libstd-rust-dev-windows
+#Replaces: libstd-rust-dev-windows
+#Build-Profiles: 
+#Description: Rust standard libraries - development files
+# Rust is a curly-brace, block-structured expression language.  It
+# visually resembles the C language family, but differs significantly
+# in syntactic and semantic details.  Its design is oriented toward
+# concerns of "programming in the large", that is, of creating and
+# maintaining boundaries - both abstract and operational - that
+# preserve large-system integrity, availability and concurrency.
+# .
+# It supports a mixture of imperative procedural, concurrent actor,
+# object-oriented and pure functional styles.  Rust also supports
+# generic programming and meta-programming, in both static and dynamic
+# styles.
+# .
+# This package contains the standard Rust libraries including development 
files,
+# needed to cross-compile Rust programs to the *-pc-windows-gnu target
+# corresponding to the architecture of this package.
+#
 #Package: libstd-rust-mozilla-dev-wasm32
 #Section: libdevel
 #Architecture: all
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/libstd-rust-mozilla-1.59.install 

Bug#722923: Fonts used as character sets are not supported

[Sébastien Hinderer]

Dear Olly,

Many thanks for following-up on this!

Olly Betts (2022/07/12 15:26 +1200):
> Did you give up on the idea of working on a patch for this?

I fear so, yes. The step seems too big, taking into account the little
documentation I have on the mapping between font/codepage values and the
UTF8 codes, the difficulty to work on Antiword's code, my unability to
check the output because there is no proper tibetan braille defined at
the moment, it feels quite a big task.

It's perfectly okay to decrease the severity to wishlist and, many
thanks for having added the help tag.

Sébastien.

Bug#1014906: opencl-clang-11: do not release with bookworm

[Sebastian Ramacher]

Source: opencl-clang-11
Version: 11.0.0-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

Bookworm will be released with llvm-toolchains 13, 14 and 15.
llvm-toolchain-11 won't be part of bookworm. So opencl-clang-11 will
also not be part of bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#1014905: spirv-llvm-translator-11: do not release with bookworm

[Sebastian Ramacher]

Source: spirv-llvm-translator-11
Version: 11.0.0-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

Bookworm will be released with llvm-toolchains 13, 14 and 15.
llvm-toolchain-11 won't be part of bookworm. So spirv-llvm-translator-11
will also not be part of bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#1000932: doxygen: Please upgrade to llvm-toolchain-12 or 13

[Sebastian Ramacher]

Control: severity -1 serious

On 2021-12-01 00:10:47 +0100, Sylvestre Ledru wrote:
> Source: doxygen
> Severity: important
> 
> Dear Maintainer,
> 
> As part of the effort to limit the number of llvm packages in the
> archive, it would be great if you could upgrade to -13 (or -12).
> 
> Bookworm won't ship with llvm-toolchain-11

Indeed, so let's raise the severity accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1000916: closed by Debian FTP Masters (reply to Sophie Brun ) (Bug#1000916: fixed in vboot-utils 0~R99-14469.B-1)

[Sebastian Ramacher]

Control: reopen -1
Control: severity -1 serious

Hi Sophie

On 2022-02-14 14:45:03 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:vboot-utils package:
> 
> #1000916: vboot-utils: Please upgrade to llvm-toolchain-12 or 13

The fix for this bug is incomplete. The package still Build-Depends on
libfuzzer-11-dev which is built by llvm-toolchain-11. Please also
upgrade this dependency.

Cheers

> 
> It has been closed by Debian FTP Masters  
> (reply to Sophie Brun ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Sophie Brun 
> ) by
> replying to this email.
> 
> 
> -- 
> 1000916: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000916
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Mon, 14 Feb 2022 14:42:32 +
> From: Debian FTP Masters 
> To: 1000916-cl...@bugs.debian.org
> Subject: Bug#1000916: fixed in vboot-utils 0~R99-14469.B-1
> Reply-To: Sophie Brun 
> Message-Id: 
> 

> Date: Wed, 1 Dec 2021 00:10:01 +0100
> From: Sylvestre Ledru 
> To: sub...@bugs.debian.org
> Subject: vboot-utils: Please upgrade to llvm-toolchain-12 or 13
> Message-ID: 
> 
> Source: vboot-utils
> Severity: important
> 
> Dear Maintainer,
> 
> As part of the effort to limit the number of llvm packages in the
> archive, it would be great if you could upgrade to -13 (or -12).
> 
> Bookworm won't ship with llvm-toolchain-11
> 
> llvm-defaults is now pointing to -13.
> 
> Thanks,
> Sylvestre


-- 
Sebastian Ramacher