Bug#1016720: RFS: analog/2:6.0.17-2 [ITA] -- web server log analyzer

[Lourisvaldo Figueredo Junior]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: analog
   Version : 2:6.0.17-2
   Upstream Author : [fill in name and email of upstream]
 * URL : https://www.c-amie.co.uk/software/analog
 * License : BSD-4-clause, PCRE, zlib, libpng, GPL-2+, public-domain, 
GD
 * Vcs : https://salsa.debian.org/debian/analog
   Section : web

The source builds the following binary packages:

  analog - web server log analyzer

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/analog/
analog_6.0.17-2.dsc

Changes since the last upload:

 analog (2:6.0.17-2) unstable; urgency=medium
 .
   * New maintainer. (Closes: #674866)
   * debian/control: bumped Std-Ver to 4.6.1.
   * debian/patches/06_fix-pcre-version.patch: created to make analog work with
 new version of PCRE. (Closes: #17)

Regards,

Lourisvaldo Figueredo Junior



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

Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)

[Helge Kreutzmann]

Hello Martin,
thanks for your speedy reply.

Especially when asking things related to sgt-puzzles, please keep Ben
in CC:.

On Sat, Aug 06, 2022 at 12:23:48AM +0200, Martin Quinson wrote:
> the short answer is that po4a-gettextize is not intended to be used on a 
> regular
> basis. It's only intended for the first run when you want to convert an 
> existing
> translation to the po-based workflow. Once it's done, you're supposed to use
> po4a-updatepo to create an empty PO file. Even better, you should use po4a
> directly instead of the deprecated atomic commands.

Ok, so this would be incorrect usage in sgt-puzzles? It did work for
the past ~ 13 years. Then it might be helpful to add a note that
certain use cases are not working anymore.

Should this bug be cloned to sgt-puzzles for updating its
infrastructure?

> The extra spaces that you see are intended to help the gettextization process,
> as explained in the po4a-gettextize manpage.

At least I don't fully understand this text, even though I translated
it. (See below)

> I'm not sure of how I can help you here. What piece of documentation should be
> updated?

   •   In some case, po4a adds a space at the end of either the original or 
the translated strings. This is because every string must be deduplicated 
during the gettextize process. Imagine that a string appearing several times
   unmodified in the original, but is translated in differing way, or 
that different paragraphs are translated in the exact same way.

   Without deduplication, such case would break the gettexization 
algorithm, as it is a simple one to one pairing between the msgids of both the 
master and the localized files. Since one of the PO files would miss an entry
   (that would be reported as duplicate, with two references), the 
pairing would fail.

What is missing here is how and when these strings are merged back, i.e. what 
the 
translator or package maintainer should do to get to the desired
situation (i.e. each string only appearing once). 

   Since po4a uses the entry type ("title" or "plain paragraph", etc) 
to detect whether the parsing streams got desynchronized, similar issues could 
occur if two identical entries (same content but differing type) of the
   master file are translated in the exact same way in the localized 
file. po4a would detect a fake desyncronization in such case.

   In most cases, the extra space added by po4a to deduplicate the 
strings has no impact on the formatting. Strings are fuzzied anyway, and 
msgmerge will probably match the strings accordingly afterward.

Could you add an example here? I.e. like I did below with my example?
In your text above (in the e-mail) you state that you should use 
po4a-updatepo or po4a, here you mention msgmerge. Probably clarifying 
this would help as well.

> Thanks for using po4a,

Sure, for translators/translations its a great piece of software. 

> Mt
> 
> Le vendredi 05 août 2022 à 16:02 +0200, Helge Kreutzmann a écrit :
> > Package: po4a
> > Version: 0.67-2
> > Severity: normal
> > Tags: upstream
> > X-Debbugs-Cc: Ben Hutchings 
> > 
> > 
> > I'm the translator of the German translation for the documentation of
> > sgt-puzzles. It is a Debian-only patch at the moment for the halibut
> > based sources.
> > 
> > A few days ago Ben (the Debian maintainer) updated the package and
> > requested me to update the German translation. While doing so he
> > noticed a strange change in po4a behaviour:
> > 
> > (Some) strings, which are repeated (because the same text appears in
> > multiple places in the documentation resp. many man pages) are
> > inserted several times into de.po, except that an increasing number of
> > spaces is added, i.e.
> > 
> > "dog" would become
> > "dog"
> > "dog "
> > "dog  "
> > "dog   "
> > and so on.
> > 
> > While updating the German translation of po4a I remember translating 
> > something along these lines, though I did not fully understand its 
> > meaning.
> > 
> > This behaviour defeats part of the idea of the po format. Unless the
> > orginal author indicates this, identical strings in the original text
> > should be translated identical as well. 
> > 
> > Now for some reason po4a makes identical strings artificially different. 
> > 
> > In the toy example above, this could become:
> > "Hund"
> > "Rüde "
> > "Gerüstklammer  "
> > "Schlepphaken   " 
> > …
> > 
> > So now the same string is translated differently *and* the
> > translation receives also (varying) additional trailing spaces. (As a
> > translator, you usually reproduce space at the beginning and end). 
> > 
> > In this toy example this might be noticed easily, but usually po4a is
> > used for (longer) paragraphs - and translators might not realize they
> > already translated them and would retranslate them - additional work
> > and, as stated above, potentially inconsistent translations.
> > 
> > Thus please revert to the previous behaviour of po4a *or* ensure 

Bug#1014732: logrotate: daily mail “error: state file /var/lib/logrotate/status is world-readable and thus…”

[Thorsten Glaser]

Dixi quod…

>I got a new version of logrotate on multiple systems due to the
>security/point release, and since then I get, every night, from
>all of them, this:

After a while, I can now say it’s only once for every system,
but I had upgraded several in waves and over nights, so the
eMails spread out enough for me to think it was occurring for
every system every night.

I guess someone forgot a chmod in postinst or something. The
proposed patch is certainly overkill if not even wrong.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1016719: dask: test_query_with_meta fails on 32 bit arches

[Drew Parsons]

Source: dask
Version: 2022.02.0+dfsg-1
Severity: normal
Control: forwarded -1 https://github.com/dask/dask/issues/8620

dask 2022.02.0 is failing two CI tests on 32 bit arches (armhf, i386), 
one in test_query_with_meta, the other in test_categorize_info

The test_query_with_meta error is reported upstream at
https://github.com/dask/dask/issues/8620

The test_categorize_info error was dealt with upsteam with your patch
applied in https://github.com/dask/dask/pull/8851 which should be
applied in the 2022.04.0 release.

Since we've got the pyarrow dependency getting in the way of upgrading
to the more recent dask releases as noted in Bug#1013080, should we pull
in the PR#8851 patch to debian/patches to fix test_categorize_info ?







_ test_query_with_meta _

db = 'sqlite:tmp/tmp61ugakdn.'

def test_query_with_meta(db):
from sqlalchemy import sql

data = {
"name": pd.Series([], name="name", dtype="str"),
"age": pd.Series([], name="age", dtype="int"),
}
index = pd.Index([], name="number", dtype="int")
meta = pd.DataFrame(data, index=index)

s1 = sql.select(
[sql.column("number"), sql.column("name"), sql.column("age")]
).select_from(sql.table("test"))
out = read_sql_query(s1, db, npartitions=2, index_col="number", 
meta=meta)
# Don't check dtype for windows https://github.com/dask/dask/issues/8620
>   assert_eq(out, df[["name", "age"]], check_dtype=sys.platform != "win32")

/usr/lib/python3/dist-packages/dask/dataframe/io/tests/test_sql.py:443: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

a =name  age
number  
0 Alice   33
1   Bob   40
2 Chris   22
3  Dora   16
4 Edith   53
5   Francis   30
6   Garreth   20
b =name  age
number  
0 Alice   33
1   Bob   40
2 Chris   22
3  Dora   16
4 Edith   53
5   Francis   30
6   Garreth   20
check_names = True, check_dtype = True, check_divisions = True
check_index = True, scheduler = 'sync', kwargs = {}

def assert_eq(
a,
b,
check_names=True,
check_dtype=True,
check_divisions=True,
check_index=True,
scheduler="sync",
**kwargs,
):
if check_divisions:
assert_divisions(a, scheduler=scheduler)
assert_divisions(b, scheduler=scheduler)
if hasattr(a, "divisions") and hasattr(b, "divisions"):
at = type(np.asarray(a.divisions).tolist()[0])  # numpy to 
python
bt = type(np.asarray(b.divisions).tolist()[0])  # scalar 
conversion
assert at == bt, (at, bt)
assert_sane_keynames(a)
assert_sane_keynames(b)
a = _check_dask(
a, check_names=check_names, check_dtypes=check_dtype, 
scheduler=scheduler
)
b = _check_dask(
b, check_names=check_names, check_dtypes=check_dtype, 
scheduler=scheduler
)
if hasattr(a, "to_pandas"):
a = a.to_pandas()
if hasattr(b, "to_pandas"):
b = b.to_pandas()
if isinstance(a, (pd.DataFrame, pd.Series)):
a = _maybe_sort(a, check_index)
b = _maybe_sort(b, check_index)
if not check_index:
a = a.reset_index(drop=True)
b = b.reset_index(drop=True)
if isinstance(a, pd.DataFrame):
>   tm.assert_frame_equal(
a, b, check_names=check_names, check_dtype=check_dtype, **kwargs
E   AssertionError: Attributes of DataFrame.iloc[:, 1] (column 
name="age") are different
E   
E   Attribute "dtype" are different
E   [left]:  int32
E   [right]: int64

/usr/lib/python3/dist-packages/dask/dataframe/utils.py:562: AssertionError
_ test_categorize_info _

@pytest.mark.skipif(not PANDAS_GT_120, reason="need newer version of 
Pandas")
def test_categorize_info():
# assert that we can call info after categorize
# workaround for: https://github.com/pydata/pandas/issues/14368
from io import StringIO

pandas_format._put_lines = put_lines

df = pd.DataFrame(
{"x": [1, 2, 3, 4], "y": pd.Series(list("aabc")), "z": 
pd.Series(list("aabc"))},
index=[0, 1, 2, 3],
)
ddf = dd.from_pandas(df, npartitions=4).categorize(["y"])

# Verbose=False
buf = StringIO()
ddf.info(buf=buf, verbose=True)
expected = (
"\n"
"Int64Index: 4 entries, 0 to 3\n"
"Data columns (total 3 columns):\n"
" #   Column  Non-Null Count  Dtype\n"
"---  --  --  -\n"
" 0   x   4 

Bug#949248: Charity Donation

[MacKenzie Scott]

Hi,
  My name is MacKenzie Scott Tuttle; I'm a philanthropist and founder of one of 
the largest private foundations in the world. I'm on a mission to give it all 
away as I believe in ‘giving while living.’ I always had the idea that never 
changed in my mind — that wealth should be used to help each other, which has 
made me decide to donate to you. Kindly acknowledge this message and I will get 
back to you with more details.

Visit the web page to know more about me: 
https://www.nytimes.com/2022/04/10/business/mackenzie-scott-charity.html

Regards,
MacKenzie Scott Tuttle.

Bug#1008578: buster-pu: golang-github-russellhaering-goxmldsig/0.0~git20170911.b7efc62-1+deb10u1

[Thorsten Alteholz]

On Fri, 5 Aug 2022, Adam D. Barratt wrote:

Please go ahead.


... and uploaded.

Thanks!
 Thorsten

Bug#1009076: buster-pu: minidlna/1.2.1+dfsg-2+deb10u3

[Thorsten Alteholz]

On Fri, 5 Aug 2022, Adam D. Barratt wrote:

Please go ahead; sorry for the delay.


... and uploaded.

Thanks!
 Thorsten

Bug#1009251: buster-pu: fribidi/1.0.5-3.1+deb10u2

[Thorsten Alteholz]

On Fri, 5 Aug 2022, Adam D. Barratt wrote:

Please go ahead; sorry for the delay.


... and uploaded.

Thanks!
 Thorsten

Bug#1010380: buster-pu: flac/1.3.2-3+deb10u2

[Thorsten Alteholz]

On Fri, 5 Aug 2022, Adam D. Barratt wrote:


Please go ahead; sorry for the delay.


... and uploaded.

Thanks!
 Thorsten

Bug#1016718: binfmt_elf: May fail to load executable with no static data next to BSS

[Ben Hutchings]

Source: linux
Version: 5.19-1~exp1
Severity: normal
Tags: upstream

I'm doing some test builds of klibc
 and found a
regression for arm64.  What changed is binutils, and I've reported
bug #1016717 there, but it seems to be triggering an existing bug in
the kernel.

Loading some of klibc's test programs (getoptlong.shared,
malloctest2.shared, setjmptest.shared, sigint.shared) fails, with
execve() returning EFAULT.  This happens past the point of no return,
so the kernel kills the process with SIGSEGV.

The reason for this seems to be that:

1. All of these programs have a BSS section but not a data section.
2. The BSS section is not page-aligned (it now starts at 0xffe8).
3. binfmt_elf assumes that a non-page-aligned BSS section is placed
   immediately after a writable data section in memory, and tries to
   clear memory from the start of the BSS section up to the page
   boundary.
4. In this case, there is no data section and no file mapping before
   the BSS, so this results in an EFAULT.  This happens past the point
   of no return, so the kernel kills the process.

With older versions of binutils, the BSS section was still misaligned
on arm64 but started within the same 4K page as another section.

binfmt_elf should check whether it created a mapping before a non-
aligned BSS section; if not then it should round down the start of the
zero mapping instead of trying to clear part of a mapping that's not
there.

Ben.

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

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

Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)

[Martin Quinson]

Hello,

the short answer is that po4a-gettextize is not intended to be used on a regular
basis. It's only intended for the first run when you want to convert an existing
translation to the po-based workflow. Once it's done, you're supposed to use
po4a-updatepo to create an empty PO file. Even better, you should use po4a
directly instead of the deprecated atomic commands.

The extra spaces that you see are intended to help the gettextization process,
as explained in the po4a-gettextize manpage.

I'm not sure of how I can help you here. What piece of documentation should be
updated?

Thanks for using po4a,
Mt

Le vendredi 05 août 2022 à 16:02 +0200, Helge Kreutzmann a écrit :
> Package: po4a
> Version: 0.67-2
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: Ben Hutchings 
> 
> 
> I'm the translator of the German translation for the documentation of
> sgt-puzzles. It is a Debian-only patch at the moment for the halibut
> based sources.
> 
> A few days ago Ben (the Debian maintainer) updated the package and
> requested me to update the German translation. While doing so he
> noticed a strange change in po4a behaviour:
> 
> (Some) strings, which are repeated (because the same text appears in
> multiple places in the documentation resp. many man pages) are
> inserted several times into de.po, except that an increasing number of
> spaces is added, i.e.
> 
> "dog" would become
> "dog"
> "dog "
> "dog  "
> "dog   "
> and so on.
> 
> While updating the German translation of po4a I remember translating 
> something along these lines, though I did not fully understand its 
> meaning.
> 
> This behaviour defeats part of the idea of the po format. Unless the
> orginal author indicates this, identical strings in the original text
> should be translated identical as well. 
> 
> Now for some reason po4a makes identical strings artificially different. 
> 
> In the toy example above, this could become:
> "Hund"
> "Rüde "
> "Gerüstklammer  "
> "Schlepphaken   " 
> …
> 
> So now the same string is translated differently *and* the
> translation receives also (varying) additional trailing spaces. (As a
> translator, you usually reproduce space at the beginning and end). 
> 
> In this toy example this might be noticed easily, but usually po4a is
> used for (longer) paragraphs - and translators might not realize they
> already translated them and would retranslate them - additional work
> and, as stated above, potentially inconsistent translations.
> 
> Thus please revert to the previous behaviour of po4a *or* ensure that
> identical text is shown only once in the *.po(t) files.
> 
> In case you want to investigate yourself, do the following in
> unstable:
> 
> apt-get source sgt-puzzles
> cd sgt-puzzles-20191231.79a5378/
> make -f debian/rules build
> make -f Makefile.doc update-po
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.18.15 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to de_DE.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages po4a depends on:
> ii  gettext 0.21-6
> ii  libpod-parser-perl  1.65-1
> ii  libsgmls-perl   1.03ii-37
> ii  libsyntax-keyword-try-perl  0.27-1
> ii  libyaml-tiny-perl   1.73-1
> ii  opensp  1.5.2-13+b2
> ii  perl    5.34.0-5
> 
> Versions of packages po4a recommends:
> ii  liblocale-gettext-perl 1.07-4+b2
> ii  libterm-readkey-perl   2.38-1+b3
> ii  libtext-wrapi18n-perl  0.06-9
> ii  libunicode-linebreak-perl  0.0.20190101-1+b4
> 
> po4a suggests no packages.
> 
> -- no debconf information
> 

-- 
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.



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

Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case

[Guilhem Moulin]

Hi Sean,

On Sun, 31 Jul 2022 at 13:45:29 -0700, Sean Whitton wrote:
> So, the PARTUUID= source is being mapped to a /dev/mapper source, which
> I think is the work of the fix for #902943.  It's the same for UUID=.
> 
> The problem is that /dev/mapper/loop0p2 is valid only on the
> image-building host, and not on the host that will actually try to boot
> the image.  Indeed, that's the whole reason I am using a PARTUUID, so
> that it will stay valid.  So it looks like the fix for #902943 has
> broken this sort of use case.  It would be great to have some way to
> cause the PARTUUID to be passed through unchanged.

It appears we can remove our ugly lvm2 handling logic: lvm2 ≥2.03.15-1
has removed its initramfs-tools script and instead relies solely on udev
rules.  And your report was good timing since lvm2 2.03.15-1 was
uploaded in the beginning of July :-)

Could you please double check that


https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6
 and

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/e03fcc0d3e3285b4e72208f40a4ac59db3022b48

suit your use case?  (No need to build the package, you can just patch
the initramfs hook and boot script in /usr/share/initramfs-tools.)  Note
that if you have LVM devices that need to be activated at early boot
stage you'll need lvm2 from Bookworm/sid.

cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1010708: cryptsetup: init script doesn't appear to do anything with force-start due to masked systemd services

[Guilhem Moulin]

Control: severity -1 minor

On Sat, 07 May 2022 at 17:40:34 -0400, Andres Salomon wrote:
> Calling the init script with 'force-start' was how I used to start the
> volume and get prompted for a password, but on a newer system with
> systemd, that doesn't _appear_ to work any more:

The init scripts are masked by systemd but you should be able to run
`cryptdisks_start 8tb` or `systemd-cryptsetup@8tb.service` to map the
volume.

> It would be good if /etc/init.d/cryptsetup either warned about the
> masked systemd service, and/or the cryptsetup postinst scripts
> deleted or prompted the user about the symlinks.

That would boil to overriding the systemd maintainers and I'm not going
to do that :-]

> Unless /etc/init.d/cryptsetup force-start is deprecated, of course!
> But README.Debian still describes using the init script.

Fair enough, I'll add a mention to systemd there.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1016715: modem-manager-gui: Assertion when XDG_CURRENT_DESKTOP is not set

[Wolfram Sang]

Package: modem-manager-gui
Version: 0.0.20
Severity: minor
Tags: patch upstream

Dear Maintainer,

for some reason, my system using i3wm does not have XDG_CURRENT_DESKTOP
set. This leads to a critical assertion when starting modem-manager-gui.
While this is no problem because the program still starts, it is easy
enough to fix, so here is a patch for it. I did not send it to upstream,
because there doesn't seem to be an active upstream anymore.

All the best,

   Wolfram

-- 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/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages modem-manager-gui depends on:
ii  libayatana-appindicator3-1  0.5.90-5
ii  libc6   2.33-7
ii  libcairo2   1.16.0-6
ii  libgdbm61.23-1
ii  libgdk-pixbuf-2.0-0 2.42.8+dfsg-2
ii  libglib2.0-02.70.3-1
ii  libgtk-3-0  3.24.34-1
ii  libgtkspell3-3-03.0.10-1
ii  mobile-broadband-provider-info  20210805-1
ii  modemmanager1.18.10-1
ii  network-manager 1.38.2-1
ii  policykit-1 0.105-31.1+b1
ii  ppp 2.4.9-1+1

Versions of packages modem-manager-gui recommends:
ii  modem-manager-gui-help  0.0.20-4
pn  yelp

Versions of packages modem-manager-gui suggests:
pn  evolution-data-server  
pn  libindicate5 | libmessaging-menu0  
ii  libnotify4 0.8.1-1
From: Wolfram Sang 
Date: Tue, 2 Aug 2022 17:32:53 +0200
Subject: avoid assertion when XDG_CURRENT_DESKTOP is not set

---
 src/addressbooks.c | 2 +-
 src/main.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/addressbooks.c b/src/addressbooks.c
index ff9c423..fd28285 100644
--- a/src/addressbooks.c
+++ b/src/addressbooks.c
@@ -979,7 +979,7 @@ mmgui_addressbooks_t 
mmgui_addressbooks_new(mmgui_event_ext_callback callback, m
addressbooks->gnomecontacts = NULL;

/*GNOME code path*/
-   if (g_strrstr(desktop, "GNOME") != NULL) {
+   if (desktop && g_strrstr(desktop, "GNOME") != NULL) {
if (mmgui_libpaths_cache_check_library_version(libcache, 
"libebook-1.2", 12, 3, 0)) {
/*Open module*/
addressbooks->ebookmodule = 
g_module_open(mmgui_libpaths_cache_get_library_full_path(libcache, 
"libebook-1.2"), G_MODULE_BIND_LAZY);
diff --git a/src/main.c b/src/main.c
index 733a190..2e31d13 100644
--- a/src/main.c
+++ b/src/main.c
@@ -2035,7 +2035,7 @@ static void 
mmgui_main_tray_icon_build(mmgui_application_t mmguiapp)
desktop = getenv("XDG_CURRENT_DESKTOP");

/*Indicator*/
-   if (g_strrstr(desktop, "GNOME") != NULL) {
+   if (desktop && g_strrstr(desktop, "GNOME") != NULL) {
iconfilepath = g_build_filename(RESOURCE_SYMBOLIC_ICONS_DIR, 
"modem-manager-gui-symbolic.svg", NULL);
} else {
iconfilepath = g_build_filename(RESOURCE_PNG_ICONS_DIR, 
"modem-manager-gui.png", NULL);

Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-08-05 at 22:23 +0200, Alexandre Rossi wrote:
> Hi,
> 
> > > > Thanks. Can you attach the debdiff between the current version
> > > > in
> > > > buster and the proposed one to this bug?
> > > 
> > > Here it is.
> > > 
> > 
> > Apologies for letting this sit for so long without a follow-up.
> 
> No worries.
> 
> > We're in the process of arranging the final point release for
> > buster,
> > as support for it moves to the new LTS team.
> > 
> > Is this something you're still interested in updating in buster?
> 
> Yes, I even still have the built package ready for upload on
> mentors.d.o .
> 

In that case please feel free to get it uploaded, bearing in mind the
time constraints mentioned.

Regards,

Adam

Bug#1016586: bpftool: Dump of jited version of the BPF program requires libbfd support

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 2022-08-03 at 18:01 +0200, Emmanuel Fleury wrote:
[...]
> I suppose that the support for BPF must be add to libbfd in the binutils-dev 
> package by default.
> 
> Feel free to ask for more details if I was not clear in my report.

We don't and can't link with libbfd because of licence incompatibility.
Sorry.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


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

Bug#1016714: arch-install-scripts: Include pacstrap in arch-install-scripts since pacman is now in Debian

[Ben Westover]

Hello,

On 8/5/22 16:39, Unit 193 wrote:
Yep, that's the plan.  I was waiting on pacman-package-manager to pass 
NEW before I did the changes, so I haven't picked up the new version yet.


Perfect. It just passed NEW about three hours ago, so it's not on many 
mirrors yet. A source-only reupload should be occurring soon to get the 
package built on buildds so it can migrate to testing.


I plan to only have pacman-package-manager in suggests though as that's 
not what I use arch-install-scripts for myself, and I presume others 
likewise.


That sounds like a good idea. pacstrap also requires a mirrorlist file, 
which I don't see a point to package in Debian, so putting it in 
Suggests is a good idea since pacstrap will be a more "advanced" use.


It would be perfect to put "Closes: #1016714" in the changelog entry of 
your new version, so this bug will be automatically closed upon release.


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016714: arch-install-scripts: Include pacstrap in arch-install-scripts since pacman is now in Debian

[Unit 193]

Howdy,

On Fri, 5 Aug 2022, Ben Westover wrote:


Dear Maintainer,

pacstrap is currently not included in the arch-install-scripts package for 
Debian, which makes sense since it uses pacman. However, pacman as of today 
is in Debian as the package pacman-package-manager, so now it should be 
possible for pacstrap to be added.


Version 26 of arch-install-scripts was also released last week, so it's 
currently a good time to update and include pacstrap at the same time.


Yep, that's the plan.  I was waiting on pacman-package-manager to pass 
NEW before I did the changes, so I haven't picked up the new version yet.


I plan to only have pacman-package-manager in suggests though as that's 
not what I use arch-install-scripts for myself, and I presume others 
likewise.



~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?

[Alexandre Rossi]

Hi,

> > > Thanks. Can you attach the debdiff between the current version in
> > > buster and the proposed one to this bug?
> > 
> > Here it is.
> > 
> 
> Apologies for letting this sit for so long without a follow-up.

No worries.

> We're in the process of arranging the final point release for buster,
> as support for it moves to the new LTS team.
> 
> Is this something you're still interested in updating in buster?

Yes, I even still have the built package ready for upload on mentors.d.o .

Alex

Bug#1016708: thunderbird: Thunderbird 102 doesn't recognize installed hunspell and myspell dictionaries

[Carsten Schoenert]

Hello Michael,

Am 05.08.22 um 21:14 schrieb Michael Meier:


I've just installed Thunderbird 102.
Now it doesn't recognize anymore the installed hunspell and myspell
dictionaries for spellchecking. If they aren't supported anymore by
thunderbird, then they should be removed from the recommended list.


an Add-ons installed? What happens if you disable all Add-ons?
Is that happen too if you start with a new profile?
Does this behavior also happen if you use pre-build upstream binary?

Please note also the hints within the Debian wiki.

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

--
Regards
Carsten

Bug#1016714: arch-install-scripts: Include pacstrap in arch-install-scripts since pacman is now in Debian

[Ben Westover]

Package: arch-install-scripts
X-Debbugs-Cc: kwestover...@gmail.com
Version: 25-1
Severity: minor

Dear Maintainer,

pacstrap is currently not included in the arch-install-scripts package 
for Debian, which makes sense since it uses pacman. However, pacman as 
of today is in Debian as the package pacman-package-manager, so now it 
should be possible for pacstrap to be added.


Version 26 of arch-install-scripts was also released last week, so it's 
currently a good time to update and include pacstrap at the same time.


Thanks,
--
Ben Westover

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.18.0-3-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006182: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-03-26 at 10:20 +0300, Dmitry Shachnev wrote:
> Hi all, and sorry for delay.
> 
> On Fri, Mar 18, 2022 at 12:34:33PM +0100, Emilio Pozuelo Monfort
> wrote:
> > On 18/03/2022 12:28, Adam D. Barratt wrote:
> > > On Fri, 2022-03-18 at 12:24 +0100, Emilio Pozuelo Monfort wrote:
> > > > There are a couple of CVEs open (one of them a no-dsa, DOS
> > > > one).
> > > > Perhaps they
> > > > can be addressed in this update as well, provided the patches
> > > > (which
> > > > seem rather
> > > > small) are fine for the buster version?
> > > > 
> > > > I know the deadline for the point release is just around the
> > > > corner,
> > > > so if
> > > > there's not enough time to address those then that'd be
> > > > alright.
> > > 

Please go ahead with the updated version.

We're in the process of organising the final point release for buster, 
as support for it transitions over to the LTS team, so if you would
still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#1006550: buster-pu: package tiff/4.1.0+git191117-2~deb10u4

[Adam D. Barratt]

On Sat, 2022-03-19 at 16:43 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2022-02-27 at 18:01 +0100, László Böszörményi wrote:
> > A security update of tiff for issues not warrant a DSA but still
> > would
> > be good to have fixed.
> > 
> 
> Please go ahead; thanks.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#999430: buster-pu: package publicsuffix/20211109.1735-0+deb10u1

[Adam D. Barratt]

On Mon, 2021-11-29 at 20:45 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2021-11-10 at 16:31 -0500, Daniel Kahn Gillmor wrote:
> > Please consider an update to publicsuffix in debian buster.
> > 
> > This package reflects the state of the network, and keeping it
> > current is useful for all the packages that depend on it.
> > 
> 
> Please go ahead.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#998390: buster-pu: package ruby-activeldap/5.2.2-2+deb10u1

[Adam D. Barratt]

On Sat, 2022-03-19 at 16:37 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2021-11-03 at 15:19 +0100, Daniel Leidert wrote:
> > There is an open bug report about ruby-activeldap missing a
> > dependency on
> > ruby-builder. This issue is only present in Buster and the fix is
> > quite easy.
> > 
> 
> Please go ahead; sorry for the delay.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#995905: Packaged version of opencolorio 2.1.2

[William Wilson]

I have packaged opencolor 2.1.2 and built it successfully in a PPA.
https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+packages

In order to fix the docs built I had to override the PYTHONPATH variable
manually rather than relying on the cmake module. This had to do with how
the quotation marks were being added around "PYTHONPATH=..." causing the
builder to try to execute a file named PYTHONPATH=... rather than setting
it as an environment variable. To resolve the imath conflict, I used the
flag `-DOCIO_USE_OPENEXR_HALF=ON` in override_dh_auto_configure. I also had
to add a patch to import cstrings.

Please let me know if any changes are needed to this packaging to get this
package uploaded.

Thank you,

William

Bug#991628: buster-pu: package pillow/5.4.1-2+deb10u2

[Adam D. Barratt]

On Sat, 2021-12-04 at 17:49 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2021-07-29 at 09:54 +0100, Neil Williams wrote:
> > Fix for CVE-2021-34552 (#991293) is mitigated by FORTIFY_SOURCE, so
> > this upload targets proposed-updates instead of security after
> > discussion with Moritz.
> > 
> > Other pending CVEs in pillow for buster have been set to ignored
> > as 
> > the patches would be too intrusive in buster due mainly to binary 
> > changes in the test suite support files.
> > 
> > Debdiff is attached.
> > 
> >  pillow (5.4.1-2+deb10u3) buster; urgency=medium
> >  .
> >* Non-maintainer upload by the Security Team.
> 
> That seems inaccurate.
> 
> >[ Moritz Mühlenhoff ]
> >* CVE-2020-35653 CVE-2020-35655 CVE-2021-27921 CVE-2021-27922
> >  CVE-2021-27923 CVE-2021-25290 CVE-2021-25292 CVE-2021-28677
> >  CVE-2021-28678
> >  .
> >[ Neil Williams ]
> >* CVE-2021-34552
> > 
> 
> I'd prefer more verbose changelog entries, but please go ahead.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#990739: buster-pu: package iptables-netflow/2.3-5+deb10u1

[Adam D. Barratt]

On Sat, 2021-12-04 at 17:55 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2021-07-06 at 02:45 +0200, Axel Beckert wrote:
> > an API change in the Linux kernel 4.19.194-1 uploaded with the
> > Buster
> > 10.10 stable minor update caused a regression in
> > iptables-netflow-dkms/2.3-5 built from the iptables-netflow source
> > package. The upstream API change happened in 4.19.191:
> > 
> > - modules: mark ref_module static
> > 
> 
> Please go ahead, thanks.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#952960: buster-pu: package ruby-factory-girl-rails/4.7.0-1+deb10u1

[Adam D. Barratt]

On Tue, 2020-03-03 at 19:03 +, Adam D. Barratt wrote:
> Control: tags -1 +confirmed -moreinfo
> 
> On Mon, 2020-03-02 at 18:59 +0100, Daniel Leidert wrote:
> > Package: release.debian.org
> > Followup-For: Bug #952960
> > 
> > I've uploaded the fix to unstable and updated the diff (Vcs* fields
> > changed, see attached).
> > 
> 
> Thanks, please go ahead.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#990372: buster-pu: package feature-check/0.2.2-3

[Adam D. Barratt]

On Sun, 2021-07-18 at 18:32 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2021-06-27 at 18:10 +0300, Peter Pentchev wrote:
> > This is a pre-approval request for feature-check/0.2.2-3+deb10u1 to
> > fix the #990276 RC bug already fixed in unstable.
> > 
> > [ Reason ]
> > See #990276 (https://bugs.debian.org/990276): Version comparisons
> > may
> > return the wrong result.
> > 
> > [ Impact ]
> > If the feature-check command-line tool is used by other programs to
> > make sure that an installed program has a recent enough version of
> > a supported feature, the checks may fail for some versions
> > containing
> > non-numeric characters (pre-release, patch, etc).
> > 
> 
> Please go ahead; sorry for the delay.

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Adam D. Barratt]

On Fri, 2021-03-26 at 09:22 +0100, Salvatore Bonaccorso wrote:
> Hi Moritz,
> 
> On Fri, Jul 31, 2020 at 10:25:13AM +0200, Salvatore Bonaccorso wrote:
> > Hi Moritz,
> > 
> > On Tue, Jan 28, 2020 at 10:43:25PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Wed, 2019-11-27 at 11:18 +0100, Moritz Schlarb wrote:
> > > > Fixes CVE-2019-14857 (Open redirect in logout url when using
> > > > URLs
> > > > with backslashes) by improving validation of the post-logout
> > > > URL
> > > > parameter (backported from upstream, see 
> > > > https://salsa.debian.org/debian/libapache2-mod-
> > > > auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375)
> > > > 
> > > 
> > > Please go ahead; sorry for the delay.
> > 
> > Friendly ping on the acknowledgement from Adam. Moritz did you
> > recieved it? Can you upload for the 10.6 point release?
> 
> Friendly ping for the inclusion in the 10.10 point release. Did you
> got the above conversation?

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#942464: Fwd: Re: Bug#941626: Bug#942464: buster-pu: package haveged/1.9.1-7

[Adam D. Barratt]

On Wed, 2019-11-06 at 12:02 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> Control: tags 941626 - confirmed
> 
> Apparently I copied the wrong side of the clone...

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#1016712: RM: gfbgraph -- RoM; unmaintained, uses old libsoup2.4

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: gfbgr...@packages.debian.org

gfbgraph needs to be ported to the new librest 1.0 API and libsoup3.

GNOME stopped using gfbgraph because of this issue so this library has
no reverse dependencies and doesn't really have an upstream
maintainer.

Thank you,
Jeremy Bicha

Bug#977028: buster-pu: package sane-backends/1.0.27-3.2

[Adam D. Barratt]

On Sat, 2021-01-16 at 18:08 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2020-12-10 at 09:44 +0100, Jörg Frings-Fürst wrote:
> > The udev rule to change the owner/group of usb scanners are not
> > included.
> > 
> > [ Impact ]
> > Scanner working only as root
> > 
> > [ Risks ]
> > Trivial. The same rule are included in older sane-backends
> > releases.
> > The same rule is working in bullseye
> [...]
> >  * Fix missing udev rules (Closes: #941038)
> >- New debian/99-libsane.rules.
> 
> The metadata for that bug does not include a fixed version, and
> implies
> that it affects the package in unstable. That seems to be in direct
> contradiction to your comment in the "risks" section above.
> 
> Assuming that this is simply an oversight, please add an appropriate
> fixed version to #941038 and go ahead.
> 

Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.

Regards,

Adam

Bug#987941: buster-pu: package pacemaker/2.0.1-5+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-06-10 at 22:09 +0200, wf...@niif.hu wrote:
> On Wed, 09 Jun 2021 09:17:26 +0200 wf...@niif.hu wrote:
> 
> > Andreas kindly provided further refinements for his patch in
> > #985173.
> > I'll update this stable update request with the new debdiff
> > shortly.
> 

I'm not hugely happy that this has ended up not being in stretch, to be
quite honest.

We're in the process of organising the final point release for buster,
as support for it moves over to the LTS team, so please go ahead.

+A new upstream release instroduced as security update 1.1.24-
0+deb9u1 in

s/instroduced/introduced/

Regards,

Adam

Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet

[Guillem Jover]

Hi Simon!

On Fri, 2022-07-08 at 20:40:01 +0200, Simon Josefsson wrote:
> Guillem Jover  writes:
> > We'd need to send a mail to debian-devel, announcing the transition,
> > to check whether there's any objection. I can prepare something during
> > the weekend.

Which I did, and there didn't seem to be objections to the actual plan.

> >> 2) Is it required for 1) that the netkit-telnet package is removed from
> >> Debian?  Maybe the package could live on and ship 'netkit-telnet'
> >> instead of the 'telnet' package?  Perhaps that package could continue to
> >> live on in unstable, but never ship with a future release in favor of
> >> inetutils-telnet.
> >
> > That's something I was wondering, after you adopted netkit-telnet. If
> > you'd like to keep the netkit packages, then renaming the binary packages
> > would be the way to go, yes. If so, then we have two options, either
> > netkit keeps the telnet/telnetd packages and turns them into
> > transitional dummy packages pointing at the inetutils ones, and then
> > ships the real things in netkit- namespaced ones, or src:inetutils
> > takes them over, which does not require going through NEW, but then
> > the src:netkit-telnet might get garbage collected. But given that it
> > would need to go through NEW anyway, that might be the quickest way to
> > go about it.
> 
> I'm open to anything here -- my idea with adopting netkit-telnet it was
> to be able to control the transition.

Sure. As per the plan on debian-devel, whenever you have some time, could
you prepare the netkit-telnet update targeting experimental, which
renames the binary packages to be prefixed with netkit-*? Then once these
get ACCEPTED from NEW, we can coordinate the upload of netkit-telnet and
inetutils into unstable.

> I'm happy to co-maintain netkit-telnet with you on salsa, if you have
> ideas how that package should evolve.

Thanks for the offer, although I think I'd rather not maintain more
abandoned upstream packages. :)

> >> Similar thoughts applies to inetutils-telnetd vs netkit-telnetd too, but
> >> I wanted to start with something simple so I chose inetutils-telnet.
> >> Since telnet and telnetd is shipped from the same netkit-telnet source
> >> package, it may that if 2) is involved above, something needs to happen
> >> to inetutils-telnetd too, and then so be it.
> >
> > I'm fine with doing this step-wise or wholesale. If doing telnetd at
> > the same time might look like blocking telnet, then we can start with
> > just that one, but that would require going through NEW twice, which
> > does not look ideal.
> >
> > Given the above open questions, I think I'm just going to update to
> > the latest upstream now, and then we can check how to proceed in the
> > coming days.
> 
> It is easier to do one thing at a time, so if starting with only telnet
> gets us going anywhere, I'm in favor of that.

As you probably saw, after some thought, it seemed like doing both
seemed fine.

I'm going to be filing the bug reports mentioned in the mail to
debian-devel, and prepare an inetutils branch for the switch during
the weekend.

Thanks,
Guillem

Bug#1016711: libthrust: flaky autopkgtest

[Timo Röhling]

Source: libthrust
Version: 1.16.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

the autopkgtest suite on amd64 has spurious timeouts:
https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libthrust/24362266/log.gz

> autopkgtest [12:57:19]:  summary
> cmake_find_package_Thrust PASS (superficial)
> run_testsuite_CPP_C++17_g++-12 PASS (superficial)
> run_testsuite_CPP_C++17_g++-11 FLAKY non-zero exit status 8
> run_testsuite_CPP_C++17_g++-10 PASS (superficial)
> run_testsuite_CPP_C++14 FLAKY non-zero exit status 8
> run_testsuite_TBB_C++17 PASS (superficial)
> compile_testsuite_CPP_CUDA_C++17_cuda-g++ FAIL timed out
> compile_testsuite_TBB_CUDA_C++17_cuda-g++ FAIL timed out
> compile_testsuite_CPP_CUDA_C++17_g++-11 FLAKY non-zero exit status 2
> compile_testsuite_TBB_CUDA_C++17_g++-11 FLAKY non-zero exit status 2
> compile_testsuite_CPP_CUDA_C++17_g++-10 SKIP exit status 77 and marked as 
> skippable
> compile_testsuite_TBB_CUDA_C++17_g++-10 SKIP exit status 77 and marked as 
> skippable


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmLtbxEACgkQ+C8H+466
LVmrxQv+Ieyzf5slRYzevaK/pzwGhZG7OnXktlG5b97bmjS0Pf1TKr8GTvmpGHYd
7WSM2i8F1BGvhy2aV+IITuCIFow6tn8OXjl/F/xA/Njv9oHyqDJ8bHmCrC4xqdiU
WUyphRLD0BacA1174Dqhj4pt7zJDM/n6RAtWw/ePiIXbU3PGcdjtu9sUMJ3U6501
lv+GbOd1ul4XBF+BXHDRPNP5SgPgLCgr+La7QNDNleroTxsXT/lVlHgWP0jlrDhk
hlHTPw/v84RkmYNVQt439PirhqTQKmhve3ZqtaSw76GwmusJWb3uDpG/7mYxauzK
QXMFR9C6zc2BXbO8Q7Q0fEoNauB4annA23+V7xWsDBQAiYg92kKUgeMwRCKx62XN
lAfGHt/EaSSaHS0tdBe1crEqOo75EFmXZoFw1w4NJ6c/00jYJD2VVeLeOCojOGrR
egVnpT34W1Grn2w4XnQ+wN+faqYbChOJFJ3+bESft4/u5JGUZ7ygOP267q/Rm+JY
frYI6WPo
=tUvq
-END PGP SIGNATURE-

Bug#1016710: zlib: CVE-2022-37434

[Salvatore Bonaccorso]

Source: zlib
Version: 1:1.2.11.dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:1.2.11.dfsg-1
Control: found -1 1:1.2.11.dfsg-2+deb11u1

Hi,

The following vulnerability was published for zlib.

CVE-2022-37434[0]:
| zlib through 1.2.12 has a heap-based buffer over-read or buffer
| overflow in inflate in inflate.c via a large gzip header extra field.
| NOTE: only applications that call inflateGetHeader are affected. Some
| common applications bundle the affected zlib source code but may be
| unable to call inflateGetHeader (e.g., see the nodejs/node reference).


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-37434
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37434
[1] 
https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1
[2] https://github.com/ivd38/zlib_overflow

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?

[Adam D. Barratt]

On Wed, 2021-05-26 at 11:20 +0200, Alexandre Rossi wrote:
> Hi,
> 
> > Thanks. Can you attach the debdiff between the current version in
> > buster and the proposed one to this bug?
> 
> Here it is.
> 

Apologies for letting this sit for so long without a follow-up.

We're in the process of arranging the final point release for buster,
as support for it moves to the new LTS team.

Is this something you're still interested in updating in buster?

Regards,

Adam

Bug#964176: buster-pu: package gajim/1.1.3-2+deb10u1

[Adam D. Barratt]

On Fri, 2020-07-03 at 09:12 +0200, Martin wrote:
> I like to update gajim to the latest 1.1.x stable release in
> buster, while bullseye will move to 1.2.x.
> 
> 1.1.3-2 has been been in testing for nearly one year and has not
> shown any regressions compared to the current version in stable,
> 1.1.2-2.
> 

Apologies for somehow letting this sit so long without a response. :-/

We're in the process of preparing the final point release for buster,
as support for it moves over to the LTS team.

I think that an update of this size probably no longer makes sense for
buster, but wanted to check your thoughts before closing the request.

Regards,

Adam

Bug#1016709: pd-lib-builder: provide a dh-sequence-pdlibbuilder

[IOhannes m zmoelnig]

Source: pd-lib-builder
Version: 0.6.0-1
Severity: wishlist

Many pd-externals use pd-lib-builder, and the d/rules look all very similar.
It would be great if we could use dh to remove the duplicate work.

1. check if the make-based build system actually uses Makefile.pdlibbuilder
2. add 'PDLIBBUILDER_DIR=/usr/share/pd-lib-builder/ prefix=/usr 
pkglibdir=$(pkglibdir)'
   to the dh_auto_(clean|build|test|install) invocations
3. autofix permissions of pd-externals
4. possibly remove the extraneous LICENSE.txt files that come with Pd

Also, once we have puredata64 in Debian, this would:
- check which binary package variants are built ('pd-*' vs 'pd64-*)
- automatically build both package kinds (if so requested), using different
  flags

And there should be something like ${Pd:Depends} and ${Pd64:Depends}

check out the dh-sequence-kf5 how to switch the dh-buildsystem via a sequence

Bug#988850: buster-pu: package thunar/1.8.17-1

[Adam D. Barratt]

On Thu, 2021-05-20 at 15:25 +0200, Yves-Alexis Perez wrote:
> this is a pre-approval request for updating Thunar in stable, from
> 1.8.4
> to 1.8.17.
> 
> The context is the recently found vulnerability CVE-2021-32563
> (#988394), which has been fixed in 1.8.17.
> 
> With my security team hat on, I don't think it really desserves a DSA
> with an isolated fix, but (with my Xfce maintainer hat on) I think it
> would make sense to fix it in a point update, along with the various
> bugfixes and translation updates that Thunar had since the freeze.
> 

Apologies for the long delay in this getting a response.

We're in the process of preparing the final point release for buster,
as support transitions over to the LTS team.

Is this still something you'd be interested in fixing in buster?

Regards,

Adam

Bug#941158: Taking over ownership of ITP

[Ole Streicher]

Control: owner -1 !

As discussed by personal mail, I will take over this.

Cheers

Ole

Bug#1010060: buster-pu: package mutt/1.10.1-2.1+deb10u6

[Salvatore Bonaccorso]

Hi Adam,

On Fri, Aug 05, 2022 at 07:40:39PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2022-04-23 at 15:04 +0200, Salvatore Bonaccorso wrote:
> > I prepared an update for mutt, fixing CVE-2022-1328, a buffer-
> > overflow
> > in uudecoder.
> > 
> 
> Please go ahead; sorry for the delay.

Thank you, uploaded!

Regards,
Salvatore

Bug#1016708: thunderbird: Thunderbird 102 doesn't recognize installed hunspell and myspell dictionaries

[Michael Meier]

Package: thunderbird
Version: 1:102.1.0-1
Severity: normal
X-Debbugs-Cc: schissdra...@rmm.li

I've just installed Thunderbird 102.
Now it doesn't recognize anymore the installed hunspell and myspell
dictionaries for spellchecking. If they aren't supported anymore by
thunderbird, then they should be removed from the recommended list.


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

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

Versions of packages 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.2-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-8
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-2
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-7
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-2
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.81-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.16.0-1
ii  libstdc++6   12.1.0-7
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.1-2
ii  libx11-xcb1  2:1.8.1-2
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-3
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-de-ch-frami [hunspell-dictionary]  1:7.2.0-2
ii  hunspell-en-gb [hunspell-dictionary]1:7.2.0-2
ii  hunspell-en-us [hunspell-dictionary]1:2020.12.07-2
ii  hunspell-es [hunspell-dictionary]   1:7.2.0-2
ii  myspell-fr-gut [myspell-dictionary] 1:1.0-32.2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.6-1
ii  fonts-lyx 2.3.6.1-1
ii  libgssapi-krb5-2  1.20-1

-- no debconf information

Bug#1008578: buster-pu: golang-github-russellhaering-goxmldsig/0.0~git20170911.b7efc62-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-03-28 at 21:50 +, Thorsten Alteholz wrote:
> The attached debdiff for golang-github-russellhaering-goxmldsig
> fixes 
> CVE-2020-7711 in Buster. This CVE has been marked as no-dsa by the 
> security team.
> 

Please go ahead.

Regards,

Adam

Bug#987039: buster-pu: package dojo/1.14.2+dfsg1-1+deb10u3

[Adam D. Barratt]

On Fri, 2021-04-16 at 09:49 +0200, Yadd wrote:
> dojo/dijit is vulnerable to cross-site-scripting (#97,
> CVE-2020-4051).
> 

Apologies for not getting back to this sooner.

[...]
>  This update should minimally affect production applications:
>  * The behavior of existing links with HTML content will be unchanged
>  * Existing links that are edited and saved will be filtered (this is
> only if
>the link is edited, other content within the editor can be edited
> without
>affecting the link)
>  * Newly created links will be filtered by default
>  * For production code to continue working as-is with new data the
> application
>code will have to be updated to specify `true` for the
> `LinkDialog` plugin's
>`allowUnsafeHtml` option
> 

Do we have any idea what the likely size of the impact of that last
comment is? "continue working as-is with new data" seems a little
unclear.

Regards,

Adam

Bug#987538: buster-pu: package node-end-of-stream/1.4.1-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-04-25 at 12:02 +0200, Yadd wrote:
> node-end-of-stream test is RC-buggy. This little patch workaround
> this
> bug which seems not related to node-end-of-stream itself
> 

Please go ahead.

Regards,

Adam

Bug#1009065: buster-pu: package dropbear/2018.76-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-04-06 at 21:26 +0200, Guilhem Moulin wrote:
> CVE-2019-12953: Dropbear 2011.54 through 2018.76 has an inconsistent
> failure delay that may lead to revealing valid usernames.  This is a
> different issue than CVE-2018-15599.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1008163: buster-pu: package node-minimist/1.2.0-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-03-23 at 12:45 +0100, Yadd wrote:
> node-minimist is vulnerable to a prototype pollution not totally
> fixed
> by CVE-2020-7598 patch (pushed in 1.2.5-1 and 1.2.0-1+deb10u1)
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1008154: buster-pu: package node-node-forge/0.8.1~dfsg-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-03-23 at 11:29 +0100, Yadd wrote:
> node-node-forge signature verification code is lenient in checking
> the digest
> algorithm structure. This can allow a crafted structure that steals
> padding
> bytes and uses unchecked portion of the PKCS#1 encoded message to
> forge a
> signature when a low public exponent is being used. The issue has
> been
> addressed in `node-forge` version 1.3.0.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1016707: nodejs: ftbfs on riscv64 because of a failing test

[Jérémy Lal]

Package: nodejs
Version: 18.6.0+dfsg-5
Severity: important

The idea is to ignore those failures until they are resolved by upstream v8 
riscv team,
CPU Profiling is really not a core feature of nodejs.

not ok 3046 sequential/test-cpu-prof-drained
  ---
  duration_ms: 3.98
  severity: fail
  exitcode: 1
  stack: |-
Dispatching message { "id": 1, "method": "Profiler.enable" }
Receive CPU profile message
{"id":1,"result":{}}
Dispatching message { "id": 2, "method": "Profiler.start" }
Receive CPU profile message
{"id":2,"result":{}}
Dispatching message { "id": 3, "method": "Profiler.setSamplingInterval", 
"params": { "interval": 50 } }
Receive CPU profile message
{"id":3,"error":{"code":-32000,"message":"Cannot change sampling interval 
when profiling."}}

node:assert:124
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

null !== 0

at Object. 
(/<>/test/sequential/test-cpu-prof-drained.js:36:10)
at Module._compile (node:internal/modules/cjs/loader:1120:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1174:10)
at Module.load (node:internal/modules/cjs/loader:998:32)
at Module._load (node:internal/modules/cjs/loader:839:12)
at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:17:47 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: null,
  expected: 0,
  operator: 'strictEqual'
}


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 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 nodejs depends on:
ii  libc6   2.33-8
ii  libnode108  18.6.0+dfsg-5

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   18.6.0+dfsg-5

Versions of packages nodejs suggests:
ii  npm  8.15.1~ds1-1

-- no debconf information

Bug#1009076: buster-pu: minidlna/1.2.1+dfsg-2+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-04-06 at 21:49 +, Thorsten Alteholz wrote:
> The attached debdiff for minidlna fixes CVE-2022-26505 in Buster.
> This
> CVE has been marked as no-dsa by the security team.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1010060: buster-pu: package mutt/1.10.1-2.1+deb10u6

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-04-23 at 15:04 +0200, Salvatore Bonaccorso wrote:
> I prepared an update for mutt, fixing CVE-2022-1328, a buffer-
> overflow
> in uudecoder.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1009652: buster-pu: package nvidia-graphics-drivers/418.226.00-3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-04-13 at 18:26 +0200, Andreas Beckmann wrote:
> I'd like to update nvidia-graphics-drivers in buster to the final
> upstream release. It has reached EoL in 03/2022, that should be
> documented with a NEWS entry (as we had done with the 340xx legacy
> driver 2 years ago).
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1009251: buster-pu: fribidi/1.0.5-3.1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-04-09 at 23:03 +, Thorsten Alteholz wrote:
> 
> The attached debdiff for fribidi fixes CVE-2022-25308, CVE-2022-25309 
> and
> CVE-2022-25310 in Buster. These CVEs have been marked as no-dsa by
> the
> security team.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1016706: transition: GNOME 43 mega libsoup3 transition

[Jeremy Bicha]

Package: release.debian.org
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

As requested, I am filing this bug early but I still need to do local
rebuilds and testing.

GNOME 43 is switching its core apps and libraries to use libsoup3
instead of libsoup2.4. This isn't a simple switch since other
libraries use libsoup. Apps won't run if they are linked against both
libsoup2.4 and libsoup3. The transition ends up entangling several
library transitions together.

My initial guess for involved libraries are:
evolution-data-server
geoclue-2.0
geocode-glib
gnome-online-accounts
grilo
gssdp
libdmapsharing
libgweather4
librest
libtimezonemap
snapd-glib
tracker

Some of these libraries bump the soname for the transition. Many
don't. Therefore, I don't have a complete ben file for all affected
packages.

I think that I'll do like the phodav transition [1] and try to add
some Breaks where an app links against more than one affected library.
That's an effort to try to avoid apps being broken by an incomplete
upgrade.

The Budgie and Cinnamon desktops are also affected by this transition.

Note that libsoup2.4 will still be in Debian for the Debian 12 release.

[1] https://discourse.gnome.org/t/phodav-transition-notes/10483

Thank you,
Jeremy Bicha

Bug#1010380: buster-pu: flac/1.3.2-3+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-04-29 at 22:33 +, Thorsten Alteholz wrote:
> The attached debdiff for flac fixes CVE-2021-0561 in Buster. This
> CVE 
> has been marked as no-dsa by the security team.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1011030: buster-pu: package htmldoc/1.9.3-1+deb10u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-05-15 at 20:32 +0200, Håvard Flaget Aasen wrote:
> Fixes three CVE's CVE-2022-24191, CVE-2022-27114 and CVE-2022-28085
> 
> [ Reason ]
> One minor issue, two unimportant, still nice to have them all fixed
> at
> the same time.
> 
> [ Impact ]
> Images is now limited to 4GiB of memory usage (37837x37837 pixels).
> Shouldn't really be any issue.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1010388: buster-pu: package node-ejs/2.5.7-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-04-30 at 10:23 +0200, Yadd wrote:
> node-ejs is vulnerable to server-side template injection
> (CVE-2022-29078, #1010359) and probably to prototype pollution.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1010858: buster-pu: package unrar-nonfree/1:5.6.6-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2022-05-12 at 02:31 +0900, yokota wrote:
> CVE-2022-30333 is directory traversal vulnerability.
> It write to files during an extract operation on outside of
> extraction
> directory.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1015243: buster-pu: package commons-daemon/1.0.15-8

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-07-18 at 11:49 +0200, Chris Hofstaedtler wrote:
> Running a java daemon using jsvc and the JVM from (old)stable does
> not
> work. It appears no java programs inside Debian still use jsvc,
> otherwise people would have noticed earlier. This is bug #935336,
> and I want to fix it in oldstable (this bug) and stable (to be
> filed).
> 
> [ Impact ]
> 
> jsvc just does not work except if on upgrades one keeps the JVM from
> oldoldstable (openjdk 8).
> 

Please go ahead.

Regards,

Adam

Bug#1012048: buster-pu: package composer/1.8.4-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-05-29 at 12:37 +0200, David Prévot wrote:
> I’d like to address CVE-2022-24828 that has been tagged as no-dsa.
> Some
> people may also wish to see #989315 fixed (it was reported twice), as
> well as #955485, and the fixes are trivial, so I’m proposing a fix
> for
> them too.
> 

Please go ahead. Sorry for the delay.

Regards,

Adam

Bug#1011943: buster-pu: package php-guzzlehttp-psr7/1.4.2-0.1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-05-27 at 14:23 +0200, David Prévot wrote:
> The security team asked me to address #1008236 [CVE-2022-24775] via a
> point release, so here I am.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1016198: buster-pu: package gif2apng/1.9+srconly-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-07-29 at 08:57 +0200, Håvard F.Aasen wrote:
> This upload fixes three CVE's;
> * CVE-2021-45909, Closes: #1002668:
>   heap based buffer overflow in the DecodeLZW
> * CVE-2021-45910, Closes: #1002667:
>   heap-based buffer overflow within the main function
> * CVE-2021-45911, Closes: #1002687:
>   heap based buffer overflow in processing of delays in the main
> function
> 

Please go ahead.

Regards,

Adam

Bug#1016705: RM: golang-github-audriusbutkevicius-kcp-go -- ROM; un-needed, upstream repo pruned

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian...@lists.debian.org, utka...@debian.org

Hi,

golang-github-audriusbutkevicius-kcp-go has no reverse-depends, and its
upstream repo also seems removed (https://github.com/AudriusButkevicius/kcp-go)
Furthermore, it appears to be a fork of golang-github-xtaci-kcp (in the archive)
and the former does not seem to be of any use.

The current maintainer(uploader) of the package(in X-debbugs-cc) has ACK'ed the
removal -- I checked with them over private message.

Best,
Nilesh

Bug#1016517: menu bar reappeared

[Erwan David]

Menu bar reappeared after a reboot... Might have been a library mismatch 
or something like that.



PS : I do not know how to close the bug

Bug#1016704: flameshot: broken flameshot icon

[Roy Sindre Norangshol]

Package: flameshot
Version: 12.1.0-1
Severity: minor
X-Debbugs-Cc: roy.sin...@norangshol.no

Dear Maintainer,

After installing flameshot and starting it from the command line, it
spams a message to either stdout or stderr after program exit.

Simply try to start `flameshot --gui` and exit, it will print the
following messages twice in the terminal:

qt.svg: Invalid path data; path truncated.
qt.svg: Invalid path data; path truncated.


It looks like latest upstream has a regression fix done for this issue
or related issue: https://github.com/flameshot-org/flameshot/issues/2684

I expect the program not to print this message to stdout/stderr after
program exit.
pick

-- 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-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flameshot depends on:
ii  hicolor-icon-theme  0.17-2
ii  libc6   2.33-8
ii  libgcc-s1   12.1.0-7
ii  libqt5core5a5.15.4+dfsg-4
ii  libqt5dbus5 5.15.4+dfsg-4
ii  libqt5gui5  5.15.4+dfsg-4
ii  libqt5network5  5.15.4+dfsg-4
ii  libqt5svg5  5.15.4-2
ii  libqt5widgets5  5.15.4+dfsg-4
ii  libstdc++6  12.1.0-7

Versions of packages flameshot recommends:
ii  grim1.4.0+ds-2
ii  xdg-desktop-portal-gtk  1.14.0-1

Versions of packages flameshot suggests:
ii  ca-certificates  20211016
ii  openssl  3.0.5-1

-- debconf-show failed

Bug#939904: Bug#930735: WireGuard: Add resolvconf as optional dependency

[Luca Boccassi]

On Mon, 09 Sep 2019 19:14:46 -0400 Daniel Kahn Gillmor
 wrote:
> Control: clone 930735 -1
> Control: reassign -1 src:systemd
> Control: severity -1 wishlist
> Control: blocks 930735 with -1
> Control: retitle -1 systemd should ship resolvconf symlink in some
package
> Control: affects -1 + wireguard-tools
> 
> Hi Willem--
> 
> Thanks for the followup.
> 
> It sounds to me like there is still no great suggestion on how to
make
> this work smoothly, or a clear consensus on what we should do to
ensure
> that the DNS = directive works for wg-quick :(
> 
> On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> > If resolvectl is symlinked to resolvconf this also should work. But
the
> > symlinked is not on my system. Even with resolvectl available.
> 
> For most modern debian systems, this seems like the simplest
approach,
> but i don't think it's safe to assume it will work automatically yet.
> 
> Perhaps the systemd source package could ship a systemd-resolvconf
> binary package that (a) enables and runs the systemd-resolved service
> automatically, and (b) ships the symlink from /sbin/resolvconf to
> resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
> (similar to how openresolv does).
> 
> I note that the systemd binary package already ships a resolvconf
> manpage as a symlink to the resolvectl manpage, but it puts it in
> section 1 of the manual, instead of section 8, so it doesn't manage
to
> conflict with resolvconf or openresolv.  that's a little bit weird
too :/
> 
> I'm cloning this wireguard bug report to the systemd source package
to
> see whether this suggestion is something they'd be willing to
consider.
> Debian systemd maintainers -- feel free to suggest an alternate
> resolution if you have one you'd prefer.
> 
> If systemd would do that, then i'd be willing to add a new control
line
> for wireguard-tools as something like this:
> 
>    Recommends: systemd-resolvconf | resolvconf
> 
> Does this seem like a plausible suggestion?  This sort of system
> integration across multiple potentially conflicting packages is a bit
of
> a pain point in Debian, and it's not clear how to make it work
sensibly
> and easily for everyone.

Hi,

systemd-resolved is now in experimental as a new package, and if there
are no huge breakages (it has provides/conflicts/replaces: resolvconf
and installs the symlinks) it will make it to unstable too at some
point soon. So the plan to add the Recommends you mentioned sounds good
to me.

-- 
Kind regards,
Luca Boccassi


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

Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

[Chris Hofstaedtler]

Hi,

* Eugene Losowski-Gallagher  [220804 
18:48]:
> Hi Chris,
> 
> Thank you for the prompt to test against sid.
> I just tested and can confirm that it works.

Thanks for checking!

Chris

Bug#1016703: mkdocs-material: Please package recent version

[Carsten Schoenert]

Package: mkdocs-material
Version: 8.2.5-1
Severity: wishlist

Hello Sandro,

could you please consider to package the recent upstream version of
mkdocs-material?

Could you also please (re)close the issue #1008691 by the newer version
within the new changelog entry?

As Paul Grevers explained to me has the BTS a problem if a bug report
has the same version marked fixes as the report has been open against before.
That's currently the reason the package isn't midrating to testing.

Thanks!

Regards
Carsten

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

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

Bug#1002572: git-send-email: Adds spurious space to address name containing a dot

[Jakub Wilk]

* Alejandro Colomar , 2021-12-24, 13:37:

$ git format-patch -o patches/send/ -1 HEAD --to='Foo V. Bar '
$ git send-email patches/send/0013-Static-optimize-index-iteration.patch
patches/send/0001-foo.patch
To whom should the emails be sent (if anyone)?
Message-ID to be used as In-Reply-To for the first email (if any)?
(mbox) Adding cc: Alejandro Colomar  from line 'From: 
Alejandro Colomar '
(mbox) Adding to: "Foo V . Bar"  from line 'To: Foo V. Bar 
'


git-send-email uses Mail::Address for address parsing. This module is 
responsible for inserting extra spaces:


  $ perl 'use Mail::Address; @m = Mail::Address->parse("J.R. Hacker 
"); say @m[0]->format;'
  "J . R . Hacker" 

I'm not sure this is going to be fixed in Mail::Address though. The 
module's man page has "all bugs are features; go away" vibes...


Maybe git-send-email could switch to something else? For example, 
Lintian uses Email::Address::XS, which does the right thing:


  $ perl -E 'use Email::Address::XS "parse_email_addresses"; @m = parse_email_addresses("J.R. 
Hacker "); say @m[0]->format;'
  "J.R. Hacker" 

--
Jakub Wilk

Bug#1011456: ipv6toolkit: Update the package

[Octavio Alvarez]

On 23/05/22 05:00, Sophie Brun wrote:

Is it possible the update the package to include the latest upstream
changes? > I noticed that upstream has not made any tagged release since 2014 
but
they mentioned a version 2.1 in the CHANGES.TXT


As of today, Upstream version numbers can't be trusted. Please see [1] 
and [2].


I expect this to improve soon, as per comments in the issues.


If it can help, we (Kali developers) have updated the package last year [1].
It was named differently in Kali so we never noticed that the package
already exists in Debian. We just found out thanks to a bug report [2].
We will now use the package from Debian.


Thanks for bringing this up. Upstream should make a release soon and I 
will update Debian's package asap. This should bring Debian's up to par 
or ahead of Kali's so Kali's could be reliably dropped after that.


My only worry is the shebang patch you have [3] which reverts Upstream's 
[4] for issue [5]. If I follow Upstream, this change would be dropped. 
Is this OK with you?


Thanks,
Octavio.

[1] https://github.com/fgont/ipv6toolkit/issues/62

[2] https://github.com/fgont/ipv6toolkit/issues/77

[3] 
https://gitlab.com/kalilinux/packages/ipv6-toolkit/-/blob/kali/master/debian/patches/change-shebang-perl.patch


[4] 
https://github.com/fgont/ipv6toolkit/commit/f9ba6cec648b7f085d4c302f10e1a6a1202fff9d


[5] https://github.com/fgont/ipv6toolkit/pull/50

Bug#983138: ypserv: path to "bash" varies on usrmerge system

[Vagrant Cascadian]

On 2022-08-05, Vagrant Cascadian wrote:
> On 2022-08-05, Francesco P. Lovergine wrote:
>> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
>>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
 The configure script sets the BASH variable to /bin/sh when run on a
 usrmerge system, resulting in the pwupdate script differing between
 builds:

   
 https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html

   ./usr/lib/yp/pwupdate

   #!/bin/bash
   vs.
   #!/bin/sh
>>>
>>>In general, the Debian technical committee resolution
>>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
>>>treating this class of bug as release-critical for Debian 12.
>>>
>>>However, without knowing anything about the specifics of this package,
>>>I'm unsure whether this specific bug is RC or not: will the pwupdate
>>>script still work correctly with a purely POSIX shell like dash? If it
>>>does not, then the severity of this bug should be raised to serious.
>>>
>>>Regardless of whether this is RC or not, it would be great to have it fixed
>>>for Debian 12. Vagrant's patch looks appropriate.
>>>
>>>Thanks,
>>>smcv
>>
>> The patch looks good enough to fix the pwupdate generation. In any case, the
>> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks 
>> indifferent.
>
> Given that it's the BASH variable, I figured using /bin/bash would make
> more sense and allow consistent builds.
>
> Oddly, it appears to be build reproducibly currently even though no
> source changes happened between bullseye and bookworm (both currently
> version 4.1-2):
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ypserv.html


> So something changed back in March ... the toolchain? The reproducible
> builds infrastructure? hrm.

From some local testing, this doesn't actually appear to be a usrmerge
issue, but a /bin/sh -> /bin/bash vs. /bin/sh -> /bin/dash issue.


I'm not sure why the reproducible builds infrastructure doesn't catch
this, will look into it...


Regardless, the patch would make the package build reproducibly, and
would be great to apply.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016702: metadata-cleaner: Please package 2.2.3

[Jeremy Bicha]

Source: metadata-cleaner
Version: 2.2.1-2
Severity: wishlist
X-Debbugs-CC: peyma...@posteo.net

There has been a new upstream release:
https://gitlab.com/rmnvgr/metadata-cleaner/-/releases

Thank you,
Jeremy Bicha

Bug#1016594: RFS: anonip/1.1.0-1 [ITP] -- Anonymize IP-addresses in log-files

[Alexander Reichle-Schmehl]

tags 1016594 +pending
thanks

* Alexander Reichle-Schmehl  [220803 21:26]:
> I am looking for a sponsor for my package "anonip":

Uwe Kleine-König kinldy reviewed the package and sponsored the upload.


Best regards,
  Alexander

Bug#1016691: [Pkg-javascript-devel] Bug#1016691: pkgjs-depends: please include version for inspected package

[Yadd]

Hi,

Thanks for those reports, I'll do that during the next days (I'm not at home so 
lower activity).

Cheers,
Yadd

Le 5 août 2022 13:09:53 GMT+02:00, Jonas Smedegaard  a écrit :
>Source: pkg-js-tools
>Version: 0.14.32
>Severity: normal
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Output of pkgjs-depends includes version for each dependency, but
>inspected package itself is listed without version.
>
>Please include version for the inspected package as well.
>
> - Jonas
>
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLs+n4ACgkQLHwxRsGg
>ASFU4A/9HRkAlt8dXcke/+uVXv6g5PHvPsSXqYIP42Jd8X8F4q5bc3Irjln+6nbo
>O+iRnlaVtqHXtHoPrIR8ipC6/YfHhFoYBIOwp7nDn+SouBB9jbUMPC4ZKi/tlr18
>Mu0Val+bfq9zPmo0QOK/AYaWszIuEdwNU/Bjw3kTnz+ihdloRrFfce/+5o7sFHvx
>y2CiJmmDycmv8mPO5hmNQx4wJV5RDqZm1PUiAfS9uO1psp2/Hckb0KklIjsRNqMT
>He3vZscFjpFM66ijbKwS6fK1dMdrNWrca87o2uzdfwSrrkPv3+SgYaxjP5Iq66b8
>zGAX46TSlUkKkoPgpPgYWoJMdK6FmrnPR6my/ow/+Kz2Ih2Y/Zk/kjsvjn1Z/tNk
>WVPpQBFttkU5x7w1+Gxu97s4ZLK80iJ5OePtdQledj+DpahtmInEs9pX/Zgg+bta
>Ie2AUJ0QmCSYOIAC+Qxw1kr5dxlfOvt5CjqMJTx05lQYtFzRDW0TZujnrDqv2AbZ
>saAo+Q+2BAvvLGJNWsSvXESjcphrDzEbefox+N7UFL7qamRKyTeGRUJ1c7xCG4hQ
>xfmYK7zBgc8QZrZ4Is+UYTh1wwbYJ9CkPvXwUfZ578B4eE/b+GsALzdoMnBBDpJJ
>6zN9wgOa6ugOJGaNJtocE8LxrKCIho64mGHq4TP4M50MWon+OBQ=
>=bCQi
>-END PGP SIGNATURE-
>
>-- 
>Pkg-javascript-devel mailing list
>pkg-javascript-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#1016700: Kwrite does not show emoji fonts properly

[David Michael Smith]

Package: kwrite
Version: 4:22.04.3-1
Severity: important
X-Debbugs-Cc: sidic...@gmail.com

When copying text that contains emojis from other software (such as Libreoffice
writer) the Emojis show in kwrite as square boxes instead of showing properly.
Such as copy/paste the thumbs up / thumbs down emoji from Emojipedia.org



-- 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/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
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)

Versions of packages kwrite depends on:
ii  ktexteditor-katepart  5.94.0-4
ii  libc6 2.33-8
ii  libkf5configcore5 5.94.0-4
ii  libkf5configgui5  5.94.0-4
ii  libkf5configwidgets5  5.94.0-1
ii  libkf5coreaddons5 5.94.0-1
ii  libkf5crash5  5.94.0-1
ii  libkf5dbusaddons5 5.94.0-1
ii  libkf5i18n5   5.94.0-1+b1
ii  libkf5parts5  5.94.0-1
ii  libkf5texteditor5 5.94.0-4
ii  libkf5widgetsaddons5  5.94.0-2
ii  libkf5xmlgui5 5.94.0-1+b1
ii  libqt5core5a  5.15.4+dfsg-4
ii  libqt5gui55.15.4+dfsg-4
ii  libqt5widgets55.15.4+dfsg-4
ii  libstdc++612.1.0-7

kwrite recommends no packages.

kwrite suggests no packages.

-- no debconf information

Bug#983138: ypserv: path to "bash" varies on usrmerge system

[Vagrant Cascadian]

On 2022-08-05, Francesco P. Lovergine wrote:
> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
>>On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
>>> The configure script sets the BASH variable to /bin/sh when run on a
>>> usrmerge system, resulting in the pwupdate script differing between
>>> builds:
>>>
>>>   
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
>>>
>>>   ./usr/lib/yp/pwupdate
>>>
>>>   #!/bin/bash
>>>   vs.
>>>   #!/bin/sh
>>
>>In general, the Debian technical committee resolution
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
>>treating this class of bug as release-critical for Debian 12.
>>
>>However, without knowing anything about the specifics of this package,
>>I'm unsure whether this specific bug is RC or not: will the pwupdate
>>script still work correctly with a purely POSIX shell like dash? If it
>>does not, then the severity of this bug should be raised to serious.
>>
>>Regardless of whether this is RC or not, it would be great to have it fixed
>>for Debian 12. Vagrant's patch looks appropriate.
>>
>>Thanks,
>>smcv
>
> The patch looks good enough to fix the pwupdate generation. In any case, the
> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks 
> indifferent.

Given that it's the BASH variable, I figured using /bin/bash would make
more sense and allow consistent builds.

Oddly, it appears to be build reproducibly currently even though no
source changes happened between bullseye and bookworm (both currently
version 4.1-2):

  https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ypserv.html


So something changed back in March ... the toolchain? The reproducible
builds infrastructure? hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016699: knot-resolver: Fails autopkgtest on ppc64el

[Dan Bungert]

Package: knot-resolver
Version: 5.4.4-1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Dear Maintainer,

Unfortunately, the recent -4 change to remove ppc64el builds was incomplete.
There is another entry, later in the control file.

-Dan

Bug#991859: Is a different opinion about a license a case for the ctte?

[Gunnar Wolf]

Sam Hartman dijo [Tue, Aug 02, 2022 at 09:17:57AM -0600]:
>  
>  TL;DR: you don't have any recourse that is appropriate for this
>  situation.
>  All the hammers are bigger than your nail.

Well, hammers usually _are_ bigger than nails, otherwise... ;-)

But anyways...

>  The secretary ruled that the CT cannover overrule a delegate acting in
>  their delegated responsibility,
>  so no the CT cannot overrule ftpmaster.

Thanks for bringing this ruling up, Sam. Usually we do feel required
to answer to any questions brought up to us, although we have often
"decided not to take action" (or decided not to rule, but explicitly)
in the past.

>  The CT could give advice to ftpmaster, especially if ftpmaster requested
>  that advice.
>  I'd expect the CT would be reluctant to give non-technical advice.
>
>  The CT could set *technical policy* and I'd expect delegates would
>  generally be expected to follow reasonable technical policy established
>  by the CT or be accountable to the DPL and membership at large.
>  However, I don't really think that license standards are technical
>  enough to be technical policy.
>
>  ftpmaster could establish an appeals procedure.

Yes, that was more or less my line of thought upon first reading
Andreas' mail. I do not think licensing advice is the kind of advice
the TC is supposed to give. We do have a delegated body whose
authority is acknowledged by the whole project. And although we could
advice them to act differently, they can decide to ignore our
advice. So, if a licensing disagreement came up, the only real
resource IMO would be a GR. And I feel that would be too much for the
simple case you are presenting here.

Greetings,

Bug#1016697: RFS: diodon/1.13.0-1 -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: diodon
   Version : 1.13.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : LGPL-3+, GPL-2+, LGPL-2.1+
 * Vcs : 
https://git.launchpad.net/~diodon-team/+git/debian-packaging

   Section : utils

The source builds the following binary packages:

  diodon - GTK+ Clipboard manager
  libdiodon0 - GTK+ Clipboard manager (main library)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  diodon-dev - GTK+ Clipboard manager (development files)

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.13.0-1.dsc


Changes since the last upload:

 diodon (1.13.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Bump Standards-Version to 4.6.1.

Regards,

Bug#1016696: gnome-keyring: Seahorse unable to import certificates

[Marcelo Laia]

Package: gnome-keyring
Version: 42.1-1
Severity: normal

Dear Maintainer,

When trying to import a certificate into seahorse/gnome-keyring, seahorse GUI
application shows the 'import' button is grayish. While mouse hovering the
"import" button shows the message "Cannot import because there are no
compatible importers".

Because that problem, it's not possible to digitally sign documents with
LibreOffice.


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

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

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-2
ii  dbus-x11 [dbus-session-bus]   1.14.0-2
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gcr   3.41.1-1
ii  init-system-helpers   1.64
ii  libc6 2.33-8
ii  libgck-1-03.41.1-1
ii  libgcr-base-3-1   3.41.1-1
ii  libgcrypt20   1.10.1-2
ii  libglib2.0-0  2.72.3-1
ii  libsystemd0   251.3-1
ii  p11-kit   0.24.1-1
ii  pinentry-gnome3   1.2.0-2

Versions of packages gnome-keyring recommends:
ii  gnome-keyring-pkcs11  42.1-1
ii  libpam-gnome-keyring  42.1-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)

[Helge Kreutzmann]

Package: po4a
Version: 0.67-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: Ben Hutchings 


I'm the translator of the German translation for the documentation of
sgt-puzzles. It is a Debian-only patch at the moment for the halibut
based sources.

A few days ago Ben (the Debian maintainer) updated the package and
requested me to update the German translation. While doing so he
noticed a strange change in po4a behaviour:

(Some) strings, which are repeated (because the same text appears in
multiple places in the documentation resp. many man pages) are
inserted several times into de.po, except that an increasing number of
spaces is added, i.e.

"dog" would become
"dog"
"dog "
"dog  "
"dog   "
and so on.

While updating the German translation of po4a I remember translating 
something along these lines, though I did not fully understand its 
meaning.

This behaviour defeats part of the idea of the po format. Unless the
orginal author indicates this, identical strings in the original text
should be translated identical as well. 

Now for some reason po4a makes identical strings artificially different. 

In the toy example above, this could become:
"Hund"
"Rüde "
"Gerüstklammer  "
"Schlepphaken   " 
…

So now the same string is translated differently *and* the
translation receives also (varying) additional trailing spaces. (As a
translator, you usually reproduce space at the beginning and end). 

In this toy example this might be noticed easily, but usually po4a is
used for (longer) paragraphs - and translators might not realize they
already translated them and would retranslate them - additional work
and, as stated above, potentially inconsistent translations.

Thus please revert to the previous behaviour of po4a *or* ensure that
identical text is shown only once in the *.po(t) files.

In case you want to investigate yourself, do the following in
unstable:

apt-get source sgt-puzzles
cd sgt-puzzles-20191231.79a5378/
make -f debian/rules build
make -f Makefile.doc update-po


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

Kernel: Linux 5.18.15 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages po4a depends on:
ii  gettext 0.21-6
ii  libpod-parser-perl  1.65-1
ii  libsgmls-perl   1.03ii-37
ii  libsyntax-keyword-try-perl  0.27-1
ii  libyaml-tiny-perl   1.73-1
ii  opensp  1.5.2-13+b2
ii  perl5.34.0-5

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-4+b2
ii  libterm-readkey-perl   2.38-1+b3
ii  libtext-wrapi18n-perl  0.06-9
ii  libunicode-linebreak-perl  0.0.20190101-1+b4

po4a suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1002600: Firefox ESR crashes on pre-SSE2 CPUs

[Alexis Murzeau]

Le 05/08/2022 à 12:32, karogyoker999 a écrit :
> I've tested the proposed patch below:
> https://github.com/amurzeau/debian-autobuild/releases/tag/firefox-esr%2F91.12.0esr-1%2Bnosse1_deb11u1
> 
> I've tested it on an Athlon XP 2600+ (Barton) with 3GB RAM.
> 
> Everything seems fine. I can even play videos on youtube with smooth
> sound and if I play the videos at 144p then I basically get a
> slideshow, but that's fine for this machine :)
> 
> Tested slither.io and I could 'play'. It was unplayable due to CPU
> bottleneck, but from software side it worked.
> 
> I also tested WebRTC via https://networktest.twilio.com/ and it was
> working. Except the video-chat part, as firefox-esr doesn't have
> webcam support (based on the report at html5test.com).
> 
> The only downside of this patch is that Pentium 4's with SSE2 will be
> somewhat slower, but at least it will work on all 32 bit CPU's, not
> just P4's.
> 
> The alternative is adding the sse2-support package as a dependency for
> firefox-esr and use epiphany-browser instead of firefox-esr for i386
> Debian installations by default.
> 
> Thank you for the fix. I hope it gets merged soon.
> 

I saw your other mails, thanks for your tests and feedback :) 

I've modified slithly the [PR] around webrtc to use WEBRTC_ARCH_X86_64
instead of #undef'ing WEBRTC_ARCH_X86_FAMILY to avoid impacting x86-64.

Otherwise it is the same.

PR: https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/6

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#1016688: dieharder -h segfaults

[Dirk Eddelbuettel]

On 5 August 2022 at 13:20, Milan Broz wrote:
| Actually this patch is better, just displays usage and also check upper 
boundary (another segault with -d 10 ...)
| 
| 
https://github.com/mbroz/dieharder/commit/7d60208c8a8beabe6d3d5a88399b83ebf03240a5

Thanks for both. I will try to fold these in.

It looks like the repo at github is not in great shape in the sense that I
once tried to use it to back the Debian builds ... but that I now also use
https://salsa.debian.org/edd/dieharder for that (what a mess I made...)

The Salsa repo is a minor update ahead. I may just force-push (at least the
main branch) from it to GitHub (to have a proper 'upstream' at GitHub).

It's all a little "unusual" because rgb has some "unusual" development
practices and have been somewhat "unusually quiet" too.

I will try to clean this up over the weekend.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1016694: packages.debian.org uses favicon with white shadow

[Alexander Reichle-Schmehl]

Package: www.debian.org
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?
I switched my browser to use dark theme and access packages.debian.org with it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I switched my browser to use dark theme and access packages.debian.org with it.

   * What was the outcome of this action?
I saw that it uses a favicon with a white grop shadown looking really ugly.

   * What outcome did you expect instead?
To see a just red favicon just like the one of www.debian.org or wiki.debian.org


See the attached screenshot of my open tabs showing from left to right
packages.debian.org (with an ugly favicon), www.debian.org and wiki.debian.org.


Best regards,
  Alexander


-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Bug#1016693: davfs2: shutdown/reboot hangs when mount.davfs is not setuid and a davfs volume is left mounted

[Samuel Thibault]

Package: davfs2
Version: 1.6.1-1
Severity: normal

Hello,

Not making /usr/sbin/mount.davfs setuid has a problematic consequence:
if I run

$ sudo mount /net/foo
$ sudo reboot

the reboot stays stuck for 90s, waiting for mount.davfs to exit.

In the syslog, we can see 

août 05 13:46:03 begin mount.davfs[19302]: pid 19302, got signal 15
août 05 13:46:03 begin mount.davfs[19302]: unmounting /net/foo

so it did get the SIGTERM signal from systemd and ran /bin/umount
/net/foo, but stracing that shows:

20189 umount2("/net/foo", 0)   = -1 EPERM (Operation not permitted)
20189 write(2, "umount: ", 8)   = 8
20189 write(2, "/net/foo: must be superuser to unmount", 38) = 38

That is because mount.davfs is running as user davfs2, not as root, and
thus cannot actually trigger the umount of /net/foo, and things stay
stuck there until 90s later, when systemd gets impatient and sends a
SIGKILL.

Adding the uid=davfs2 option to /etc/fstab allows the umount to work and
thus fix the 90s delay, but davfs should automatically add that option
when it is not already defined, to avoid the davfs2-vs-root incoherency
above.

Samuel

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

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

Versions of packages davfs2 depends on:
ii  adduser 3.123
ii  cdebconf [debconf-2.0]  0.263
ii  debconf [debconf-2.0]   1.5.79
ii  libc6   2.33-8
ii  libneon27   0.32.2-1+b1

davfs2 recommends no packages.

davfs2 suggests no packages.

-- Configuration Files:
/etc/davfs2/secrets [Errno 13] Permission non accordée: '/etc/davfs2/secrets'

-- debconf information:
* davfs2/new_user: true
* davfs2/user_name: davfs2
* davfs2/new_group: true
* davfs2/suid_file: false
* davfs2/non_root_users_confimed:
* davfs2/group_name: davfs2

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1016688: Acknowledgement (dieharder -h segfaults)

[Milan Broz]

Actually this patch is better, just displays usage and also check upper 
boundary (another segault with -d 10 ...)

https://github.com/mbroz/dieharder/commit/7d60208c8a8beabe6d3d5a88399b83ebf03240a5

Bug#1016692: pkgjs-depends: please include total amount of missing dependencies

[Jonas Smedegaard]

Source: pkg-js-tools
Version: 0.14.32
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Resolved data is listed as a directed graph.  That's nice to get a feel
of the complexity of the packaging task.  Would be quite helpful as well
to have the total count of missing NPM modules.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLs+9MACgkQLHwxRsGg
ASE+pRAArQoiN0NAnrGdtAUsNFxI8HCwjuKbU4Tqi9uTxII92C9X5p+kK3hsCKMn
3ZAsfIltd5cPVEMdLomGYrRPpsdWW8XNUGwZKPgGRVWwkMFvTS6gzTycxKEVaaOn
RVZCU1jK2Mr2NNA2HC3pvswmG3a3pqhrTqT8F3ziLWHWf1KU38FGdlMRB04ocs7O
l/wh7M0iArIh73xJcZpBVn9FNkYlUGkq2SDxZgF59ffXvV3yHcR6PDI6oZ8fA+lQ
BeUxWiaLqVUYGC8fad5BAjov9kSXC+JV7KXFtPps6NUHB9ccxWpSPDlmHPjq7osi
aMPbJpN6zinvXFumBMwZBXTv9RYW7vYSRFUq6613nFPBLUmy6e3HpKdl5WNtdyoJ
vuHamdbTDdwFiyx5TbQ3gxnfWpJ5A/uRbBSTia3miVlYdqRx8s1Ds6eLe/Bh587o
fhvupaBCbwgiTe87Bg+eCjmvnIUiEBIdZIsX+C8K8+O40TzyzjPT4mkPPgKPzIuK
56uV0j0KGYD7ZnGFKivoFL8exB3xN1IWUGuV3pmIPTjPXQ63nYNVmuY4XO3WP/wW
Z2vNK7Ad02QbjBtTd0AVFZC1zj7oE/JfMLHL9ZfOUlGeHfk6AaNBVnnNzuCAeOeU
uV6OejM7zMQkohTd8R+4gXFzXKdFUMLQeMaSaG1V0doD2TbLSFM=
=fZKl
-END PGP SIGNATURE-

Bug#1016691: pkgjs-depends: please include version for inspected package

[Jonas Smedegaard]

Source: pkg-js-tools
Version: 0.14.32
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Output of pkgjs-depends includes version for each dependency, but
inspected package itself is listed without version.

Please include version for the inspected package as well.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLs+n4ACgkQLHwxRsGg
ASFU4A/9HRkAlt8dXcke/+uVXv6g5PHvPsSXqYIP42Jd8X8F4q5bc3Irjln+6nbo
O+iRnlaVtqHXtHoPrIR8ipC6/YfHhFoYBIOwp7nDn+SouBB9jbUMPC4ZKi/tlr18
Mu0Val+bfq9zPmo0QOK/AYaWszIuEdwNU/Bjw3kTnz+ihdloRrFfce/+5o7sFHvx
y2CiJmmDycmv8mPO5hmNQx4wJV5RDqZm1PUiAfS9uO1psp2/Hckb0KklIjsRNqMT
He3vZscFjpFM66ijbKwS6fK1dMdrNWrca87o2uzdfwSrrkPv3+SgYaxjP5Iq66b8
zGAX46TSlUkKkoPgpPgYWoJMdK6FmrnPR6my/ow/+Kz2Ih2Y/Zk/kjsvjn1Z/tNk
WVPpQBFttkU5x7w1+Gxu97s4ZLK80iJ5OePtdQledj+DpahtmInEs9pX/Zgg+bta
Ie2AUJ0QmCSYOIAC+Qxw1kr5dxlfOvt5CjqMJTx05lQYtFzRDW0TZujnrDqv2AbZ
saAo+Q+2BAvvLGJNWsSvXESjcphrDzEbefox+N7UFL7qamRKyTeGRUJ1c7xCG4hQ
xfmYK7zBgc8QZrZ4Is+UYTh1wwbYJ9CkPvXwUfZ578B4eE/b+GsALzdoMnBBDpJJ
6zN9wgOa6ugOJGaNJtocE8LxrKCIho64mGHq4TP4M50MWon+OBQ=
=bCQi
-END PGP SIGNATURE-

Bug#895150: cinnamon-screensaver-command: Crashes and hangs when unable to grab the keyboard/mouse

[Fabio Fantoni]

cinnamon-screensaver had important changes time ago and other 
improvements also in 5.4.1 
(https://github.com/linuxmint/cinnamon-screensaver/pull/410)


can someone test and tell me if the issue is still present in latest 
version please?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#895152: cinnamon-screensaver: cinnamon-screesaver-command only locks the screen the first time it is called

[Fabio Fantoni]

cinnamon-screensaver had important changes time ago and other 
improvements also in 5.4.1 
(https://github.com/linuxmint/cinnamon-screensaver/pull/410)


can someone test and tell me if the issue is still present in latest 
version please?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016690: http-parser: Apply nodejs 10.x patch for CVE-2020-8287

[Simon Chopin]

Package: http-parser
Severity: normal
Tags: security patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: scho...@ubuntu.com

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

  * d/p/cve-2020-8287.patch: cherry-picked from upstream PR to address
CVE-2020-8287

The upstream PR in question: https://github.com/nodejs/http-parser/pull/530/

Thanks for considering the patch.

Cheers,
Simon

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports'), (50, 'jammy-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-43-lowlatency (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru http-parser-2.9.4/debian/patches/cve-2020-8287.patch 
http-parser-2.9.4/debian/patches/cve-2020-8287.patch
--- http-parser-2.9.4/debian/patches/cve-2020-8287.patch1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.9.4/debian/patches/cve-2020-8287.patch2022-08-05 
12:24:59.0 +0200
@@ -0,0 +1,76 @@
+From b89c40dee9817e0ceb53e12937f7609b217278ed Mon Sep 17 00:00:00 2001
+From: Fedor Indutny 
+Date: Wed, 18 Nov 2020 20:50:21 -0800
+Subject: [PATCH] http: unset `F_CHUNKED` on new `Transfer-Encoding`
+Origin: Upstream PR (from nodejs) 
https://github.com/nodejs/http-parser/pull/530
+
+Duplicate `Transfer-Encoding` header should be a treated as a single,
+but with original header values concatenated with a comma separator. In
+the light of this, even if the past `Transfer-Encoding` ended with
+`chunked`, we should be not let the `F_CHUNKED` to leak into the next
+header, because mere presence of another header indicates that `chunked`
+is not the last transfer-encoding token.
+
+CVE-ID: CVE-2020-8287
+PR-URL: https://github.com/nodejs-private/node-private/pull/235
+Reviewed-By: Fedor Indutny 
+---
+ http_parser.c |  7 +++
+ test.c| 26 ++
+ 2 files changed, 33 insertions(+)
+
+diff --git a/http_parser.c b/http_parser.c
+index 9be003e7..e9b2b9e8 100644
+--- a/http_parser.c
 b/http_parser.c
+@@ -1344,6 +1344,13 @@ size_t http_parser_execute (http_parser *parser,
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
+ parser->uses_transfer_encoding = 1;
++
++/* Multiple `Transfer-Encoding` headers should be treated as
++ * one, but with values separate by a comma.
++ *
++ * See: https://tools.ietf.org/html/rfc7230#section-3.2.2
++ */
++parser->flags &= ~F_CHUNKED;
+   }
+   break;
+ 
+diff --git a/test.c b/test.c
+index 3f7c77b3..2e5a9ebd 100644
+--- a/test.c
 b/test.c
+@@ -2154,6 +2154,32 @@ const struct message responses[] =
+   ,.body= "2\r\nOK\r\n0\r\n\r\n"
+   ,.num_chunks_complete= 0
+   }
++#define HTTP_200_DUPLICATE_TE_NOT_LAST_CHUNKED 30
++, {.name= "HTTP 200 response with `chunked` and duplicate Transfer-Encoding"
++  ,.type= HTTP_RESPONSE
++  ,.raw= "HTTP/1.1 200 OK\r\n"
++ "Transfer-Encoding: chunked\r\n"
++ "Transfer-Encoding: identity\r\n"
++ "\r\n"
++ "2\r\n"
++ "OK\r\n"
++ "0\r\n"
++ "\r\n"
++  ,.should_keep_alive= FALSE
++  ,.message_complete_on_eof= TRUE
++  ,.http_major= 1
++  ,.http_minor= 1
++  ,.status_code= 200
++  ,.response_status= "OK"
++  ,.content_length= -1
++  ,.num_headers= 2
++  ,.headers=
++{ { "Transfer-Encoding", "chunked" }
++, { "Transfer-Encoding", "identity" }
++}
++  ,.body= "2\r\nOK\r\n0\r\n\r\n"
++  ,.num_chunks_complete= 0
++  }
+ };
+ 
+ /* strnlen() is a POSIX.2008 addition. Can't rely on it being available so
diff -Nru http-parser-2.9.4/debian/patches/series 
http-parser-2.9.4/debian/patches/series
--- http-parser-2.9.4/debian/patches/series 2020-12-20 10:29:46.0 
+0100
+++ http-parser-2.9.4/debian/patches/series 2022-08-05 12:21:07.0 
+0200
@@ -5,5 +5,7 @@
 
cherry-pick.v2.9.4-8-ge13b274.allow-content-length-and-transfer-encoding-chunked.patch
 cherry-pick.v2.9.4-9-g4f15b7d.fix-sizeof-http-parser-assert.patch
 
+cve-2020-8287.patch
+
 # Debian-specific
 debian.improve-installation.patch

Bug#1015787: zycore-c: please add support for riscv64

[Bo YU]

Source: zycore-c
Version: 1.1.0-4
Followup-For: Bug #1015787

Hi, 

I have opened an issue for it:
https://github.com/zyantific/zycore-c/issues/48

It has passed its test suite from my view:

```
...
100% tests passed, 0 tests failed out of 3
```
But not sure these test cases will cover on new arch or not also.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1016687:

[Florian Zwoch]

Looks like in new Mesa you will have to explicitly enable codec
support for the ones that are patent encumbered:

option(  'video-codecs',  type : 'array',  value : [],  choices: [
'vc1dec', 'h264dec', 'h264enc', 'h265dec', 'h265enc'  ],  description
: 'List of patent encumbered codecs to build support for. Distros
might want to consult their legal department before enabling these.
This is used for all video APIs (vaapi, vdpau, vulkan). Non-patent
encumbered codecs will be enabled by default.')

Bug#1016689: pkg-js-tools: broken manpages: Can't locate Cache/FileCache.pm in @INC

[Jonas Smedegaard]

Source: pkg-js-tools
Version: 0.14.32
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Installed manpages pkgjs-depends.1.gz and pkgjs-easy-to-update.1.gz
contain the following:

CAN'T(1)  User Commands 
 CAN'T(1)

NAME
   Can't - pkgjs-easy-to-update

DESCRIPTION
   Can't  locate  Cache/FileCache.pm in @INC (you may need to install the 
Cache::FileCache module) (@INC con‐
   tains:lib/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0
   /usr/lib/x86_64-linux-gnu/perl5/5.34  /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base
   /usr/lib/x86_64-linux-gnu/perl/5.34/usr/share/perl/5.34
/usr/local/lib/site_perl)at lib/De‐
   bian/PkgJs/Cache.pm line 13.

Can't locate Cache/FileCache.pm in @INC (you may 
nee.Ad.ugt.uo.stin.2s.0t.2a.2ll the Cache::FileCache module) (@INC
contai.Cn.As.N:.'Tl.(i.1b.) /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/
lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/
5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at 
lib/Debian/PkgJs/Cache.pm line 13.


Please ensure that all libraries needed to render the manpages are
available during build.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLs8Z4ACgkQLHwxRsGg
ASFOrhAAnrWgtQfHEwkeqE+G/41JIYYZ3axmUTBYBJt0Y9cClNFGHUc2+5qoKGHm
YCF0XQ7nh0MxBYZOOvxz843dyR/9HyFClEABCQB0WIVBO7f0bSi07dUZ/uh0hbvH
0YjEb3wVeWuD1jboowOrpOvUvkzAsOQoMS9XVareFG0/5VwYu+c5oQcQwiwfMdjC
J7zwXS1kF6wVJ62sRb5v4PgQWeVaOXUNz/gvBlgSmAOvZeZooI3Rdv9t0DuXdldW
Wd1EWhVYfZIiQ1xpwImajR5MMZKALOcj4vmK4TBkdhYIRegVmp7ZHR3rKblWOFrM
dwCLcwWQi8kTGu7QNF3iITuHVq/VP0klX2r5vB12Sssgzs9bUTXElEsNGWr5qzdV
wDHqGRmkgytAAyjPamMHTA65QDrwSEjYp1IIvoLQ7cbZ1nkwzcI6CpqV2cR/W3FU
oO2F+/Wf1MovihB6oh8wL7Hd8fuHgt68h3cczDWe/Wpf7vvlLG7PDW1ZcUIlzx9I
oIAUYwjtQenkJguS2WBUGlBSdini04Hc2Av7Gxj15v1pxmhPOrtIBV5w5hJuiB68
lbmNCrFMTVe16TBKI26xcm78d9CdZQXSkLiTt2kEjDzPhO3tM9UAlwbQm5JSJiVP
eIZX0C18jsMDWPJ2vkj1wjOdTMzogJ2bpRAjz84TqJEeE/v/oas=
=F11R
-END PGP SIGNATURE-

Bug#1002600: Firefox ESR crashes on pre-SSE2 CPUs

[karogyoker999]

I've tested the proposed patch below:
https://github.com/amurzeau/debian-autobuild/releases/tag/firefox-esr%2F91.12.0esr-1%2Bnosse1_deb11u1

I've tested it on an Athlon XP 2600+ (Barton) with 3GB RAM.

Everything seems fine. I can even play videos on youtube with smooth
sound and if I play the videos at 144p then I basically get a
slideshow, but that's fine for this machine :)

Tested slither.io and I could 'play'. It was unplayable due to CPU
bottleneck, but from software side it worked.

I also tested WebRTC via https://networktest.twilio.com/ and it was
working. Except the video-chat part, as firefox-esr doesn't have
webcam support (based on the report at html5test.com).

The only downside of this patch is that Pentium 4's with SSE2 will be
somewhat slower, but at least it will work on all 32 bit CPU's, not
just P4's.

The alternative is adding the sse2-support package as a dependency for
firefox-esr and use epiphany-browser instead of firefox-esr for i386
Debian installations by default.

Thank you for the fix. I hope it gets merged soon.

Bug#1016688: dieharder -h segfaults

[Milan Broz]

Package: dieharder
Version: 3.31.1.2-1+b1
Severity: normal

Dear Maintainer,

dieharder utility segfaults if standalone help (-h) option is used.

$ dieharder -h
Segmentation fault (core dumped)

Fix is trivial, see patch here
https://github.com/mbroz/dieharder/commit/3323d0d5ec0350f977d6dbe0fb20f6e7e4ad0e8a

(I can do pull request if you prefer.)

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

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

Versions of packages dieharder depends on:
ii  libc6  2.33-8
ii  libdieharder3  3.31.1.2-1+b1
ii  libgsl27   2.7.1+dfsg-3

dieharder recommends no packages.

dieharder suggests no packages.

-- no debconf information

Bug#1014391: scilab: CVE-2022-30045 incorrect memory handling in ezml support leading to a heap out-of-bounds read

[Sylvestre Ledru]

Le 05/08/2022 à 11:43, Neil Williams a écrit :

On Mon, 1 Aug 2022 18:25:04 +0200 Sylvestre Ledru  wrote:

Hello,

Le 05/07/2022 à 11:19, Neil Williams a écrit :

Source: scilab
Version: 6.1.1+dfsg2-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for scilab.

CVE-2022-30045[0]:
| An issue was discovered in libezxml.a in ezXML 0.8.6. The function
| ezxml_decode() performs incorrect memory handling while parsing
| crafted XML files, leading to a heap out-of-bounds read.


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-30045
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30045

Please adjust the affected versions in the BTS as needed.



While Scilab indeed ships ezxml.c, I am not sure how this can be exploited.

The code is probably only used to load scicos/xcos schema.
https://github.com/scilab/scilab/blob/b0937f19e4b8ddf416ca9a9a433bcbbd3f4ef2c0/scilab/modules/scicos/src/c/ezxml.c


Am I right in thinking that XCOS Schema can be provided by third-parties/users?
( 
https://github.com/scilab/scilab/blob/master/scilab/contrib/xcos_toolbox_skeleton/help/en_US/available_blocks.xml
 )

What would the effect be of a crash during parsing a corrupt XCOS Schema loaded 
via a help file, for example?




I think the XML parsing is done elsewhere

But anyway, I proposed a fix upstream:

https://gitlab.com/scilab/scilab/-/merge_requests/1

Cheers

S