Bug#999883: wordgrinder FTCBFS: multiple issues

[Helmut Grohne]

Hi,

On Thu, Nov 18, 2021 at 10:40:01PM +0100, David Given wrote:
> Thanks --- yes, that needs fixing. Unfortunately, while wearing my upstream
> hat, I've rewritten the build system, but I've applied some changes to make
> it honour variables like CC and PKG_CONFIG. The diff is here, if you're
> interested: https://github.com/davidgiven/wordgrinder/pull/181/files

Thank you for the quick reply. That looks like quite an improvement.

> The new version's not packaged for Debian yet as there are still some
> upstream fixes to be done.

We have many packages that fail to cross build. Take your time. Please
just close this bug with your next upload as it takes a significant step
in the right direction. I see cross build bugs as patch communication
vehicles and not as requests for you to make things work. So if it still
fails, bug closure will put it to my desk and I'll file another patch.
That way we can iterate easily. Please keep in mind that I deal with
~1000 similar bugs concurrently.

> Is there actually a formal spec for the expected interface that polite
> Makefiles should honour to make cross building possible? And can you point
> me at the Debian tools you're using to do these checks?

The interface to Makefiles is very inconsistent unfortunately. At this
time, we're trying to deduce the most commonly used conventions from
existing practice. There seem to be two major routes:

A) Pass all the tools. The most important/common variables are:
   * CC
   * CXX
   * PKG_CONFIG
   * Also CFLAGS/CXXFLAGS and sometimes CPPFLAGS are frequent.
   More rarely, you can suffix all of the above with _FOR_BUILD to
   compile something for the build architecture (to be able to run it).
B) Use the variable CROSS_COMPILE and prepend it to all the host tools.
   For a native build CROSS_COMPILE is empty or unset. An invocation of
   CC becomes ${CROSS_COMPILE}${CC} and likewise for every other tool.

dh_auto_build implements the former strategy and it certainly is the
most common one. dh_auto_build does not pass the _FOR_BUILD variants,
but you can use /usr/share/dpkg/buildtools.mk to export them.

Automated checks are performed at http://crossqa.debian.net/. A view of
wordgrinder is available at http://crossqa.debian.net/src/wordgrinder.
If you upload your package, it should automatically be tested within a
week or you can schedule a build yourself.

Hope this helps. In any case, cross porters are here to help. Feel free
to contact debian-cr...@lists.debian.org for help at any time.

Helmut

Bug#971783: mate-volume-control-status-icon dies here too

[Maxime G.]

Hi Mike.

Thanks for your reply about 1.26.

But it seems that the project don't want to take on this.

https://github.com/mate-desktop/mate-media/issues/159
https://github.com/mate-desktop/mate-media/issues/167
https://github.com/mate-desktop/mate-media/issues/109
https://github.com/mate-desktop/mate-media/issues/148
https://github.com/mate-desktop/mate-media/issues/137
https://github.com/mate-desktop/mate-media/issues/104
https://github.com/mate-desktop/mate-media/issues/89

This is problematic because we use this little icon a lot.

Thanks.
Max.

Bug#998172: packages.debian.org: missing security updates for bullseye

[Paul Wise]

Control: reassign -1 www.debian.org
Control: user www.debian@packages.debian.org
Control: usertags -1 + packages
Control: retitle -1 packages.debian.org: missing security updates for bullseye
Control: forcemerge 992258 -1

On Fri, 19 Nov 2021 08:17:25 +0100 Andreas Beckmann wrote:

> That's not a valid pseudo package. Reassigning to whohas, the maintainer 
> probably knows best the actual data source used by whohas.

It looks like the issue is that Martin-Éric Racine has security updates
installed for firefox-esr-l10n-fi but packages.d.o does not have info
about security updates for bullseye but does for buster and stretch.

This has already been reported before:

   https://bugs.debian.org/992258

This is the data source used by whohas:

   
https://packages.debian.org/search?keywords=firefox-esr-l10n-fi=names=all=all

At the current time this page contains this:

   Package firefox-esr-l10n-fi

   * stretch (oldoldstable) (localization): Finnish language package for 
Firefox ESR
 78.15.0esr-1~deb9u1 [security]: all
   * buster (oldstable) (localization): Finnish language package for Firefox ESR
 78.15.0esr-1~deb10u1 [security]: all
   * bullseye (stable) (localization): Finnish language package for Firefox ESR
 78.14.0esr-1~deb11u1: all
   * bookworm (testing) (localization): Finnish language package for Firefox ESR
 78.14.0esr-1: all
   * sid (unstable) (localization): Finnish language package for Firefox ESR
 91.3.0esr-1: all
   * experimental (localization): Finnish language package for Firefox ESR
 91.1.0esr-1: all

The Debian archive API indicates these versions:

   $ rmadison -u debian firefox-esr-l10n-fi
   firefox-esr-l10n-fi | 52.8.1esr-1~deb8u1   | oldoldoldstable  | all
   firefox-esr-l10n-fi | 68.10.0esr-1~deb9u1  | oldoldstable | all
   firefox-esr-l10n-fi | 78.14.0esr-1~deb10u1 | oldstable| all
   firefox-esr-l10n-fi | 78.14.0esr-1~deb11u1 | stable   | all
   firefox-esr-l10n-fi | 78.14.0esr-1 | testing  | all
   firefox-esr-l10n-fi | 78.14.0esr-1 | unstable | all
   firefox-esr-l10n-fi | 78.15.0esr-1~deb11u1 | proposed-updates | all
   firefox-esr-l10n-fi | 91.0.1esr-1  | experimental | all
   firefox-esr-l10n-fi | 91.1.0esr-1  | experimental | all
   firefox-esr-l10n-fi | 91.2.0esr-1  | unstable | all
   firefox-esr-l10n-fi | 91.3.0esr-1  | unstable | all

A chdist with apt metadata for everything below testing has these:

   $ chdist old apt policy firefox-esr-l10n-fi
   firefox-esr-l10n-fi:
 Installed: (none)
 Candidate: 78.15.0esr-1~deb11u1
 Version table:
78.15.0esr-1~deb11u1 500
   500 https://deb.debian.org/debian-security stable-security/main 
amd64 Packages
   500 https://deb.debian.org/debian proposed-updates/main amd64 
Packages
78.15.0esr-1~deb10u1 500
   500 https://deb.debian.org/debian-security oldstable/updates/main 
amd64 Packages
78.15.0esr-1~deb9u1 500
   500 https://deb.debian.org/debian-security oldoldstable/updates/main 
amd64 Packages
78.14.0esr-1~deb11u1 500
   500 https://deb.debian.org/debian stable/main amd64 Packages
78.14.0esr-1~deb10u1 500
   500 https://deb.debian.org/debian oldstable/main amd64 Packages
68.10.0esr-1~deb9u1 500
   500 https://deb.debian.org/debian oldoldstable/main amd64 Packages
52.9.0esr-1~deb9u1 500
   500 https://deb.debian.org/debian-security oldoldstable/updates/main 
amd64 Packages

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Johannes Schauer Marin Rodrigues]

Control: affects -1 mmdebstrap

Hi,

Quoting Dimitri John Ledkov (2021-11-15 14:54:36)
> > Please point out what you plan to do about this change in debootstrap so
> > that I can adapt the mmdebstrap autopkgtest accordingly.
> 
> I did notice the mmdebstrap autopkgtest regression. [...]

this bug has now been open and RC for 10 days. Those are 10 days in which I
will not notice any other possible regression in mmdebstrap because its
autopkgtest fails early. Until I know how you plan to address this bug I cannot
fix the problem in mmdebstrap because any possible fix would only be able to
migrate after debootstrap with whatever solution is chosen to this bug
migrates. So please either:

 a) decide that this bug is not RC and thus let debootstrap with its current
 behaviour migrate to testing or

 b) tell me what other solution you see in the bug -- i can even contribute a
 patch if you tell me how you want this bug solved

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#994057: #994057,libegl-mesa0: 21.2.1-2 with intel graphic card produces artifact on firefox-esr

[Michael Weghorn]

Hello,

On 09/11/2021 03.45, Patrick Häcker wrote:

I tested the Mesa upstream version from https://gitlab.freedesktop.org/mesa/
mesa/-/tree/main and can confirm the broken version there, too.

However: I didn't get any artifacts with mesa-21.3.0-rc4. I didn't bisect that
as mesa-21.2.5 has the artifacts and it does not matter which rc fixes it.

So we probably need our pinning in /etc/apt/preferences

Package: libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0
Pin: version 21.2.*
Pin-Priority: -1

for some more days until 21.3.0 is released and if that gets packaged quickly,
the problem should probably be gone soon.


thanks. I can confirm my issues are gone after upgrading to 21.3.0~rc5-1 
from experimental.


Kind regards,
Michael

Bug#993301: prototypejs: FTBFS

[Andreas Beckmann]

Control: severity -1 normal

On 18/11/2021 20.24, Bastien ROUCARIES wrote:

The source is https://github.com/prototypejs/prototype/tree/master and



I can rebuild prototypejs/1.7.1-3.1 in sid and bullseye without
problems. What errors do you encounter?



Yes but this not prefered source of modification...


Without a reproducible FTBFS I'm downgrading the severity.


Sée thé salsa tree un order to understand why i need rake


Which repository are you talking about?


Andreas

Bug#1000156: roundcube: XSS vulnerability in handling attachment filename extension in MIME type mismatch warnings

[Salvatore Bonaccorso]

Hi,

On Thu, Nov 18, 2021 at 07:25:02PM +0100, Guilhem Moulin wrote:
> Source: roundcube
> Severity: important
> Tags: security
> Control: found -1 1.3.16+dfsg.1-1~deb10u1
> Control: found -1 1.4.11+dfsg.1-4
> Control: fixed -1 1.5.0+dfsg.1-1
> 
> In a recent post roundcube webmail upstream has announced the
> following security fixes:
> 
>  * Fix XSS issue in handling attachment filename extension in mimetype
>mismatch warning
>  * Fix possible SQL injection via some session variables
> 
> sid/bookworm's 1.5.0+dfsg.1-2 is not affected.  Upstream fixes for LTS
> branches:
> 
> 1.4.x 
> https://github.com/roundcube/roundcubemail/commit/faf99bf8a2b7b7562206fa047e8de652861e624a
>   
> https://github.com/roundcube/roundcubemail/commit/c8947ecb762d9e89c2091bda28d49002817263f1
> 1.3.x 
> https://github.com/roundcube/roundcubemail/commit/7d7b1dfeff795390b69905ceb63d6391b5b0dfe7
>   
> https://github.com/roundcube/roundcubemail/commit/ee809bde2dcaa04857a919397808a7296681dcfa

CVEs are assigned as follows (by MITRE):

CVE-2021-44025 for th XSS issue

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44025

CVE-2021-44026 for the SQL injection.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44026

Regards,
Salvatore

Bug#998172: packages.debian.org: reports incorrect info to 'whohas'

[Andreas Beckmann]

Control: reassign -1 whohas

On Sun, 31 Oct 2021 13:48:42 +0200 =?utf-8?q?Martin-=C3=89ric_Racine?=
 wrote:
> Package: packages.debian.org

That's not a valid pseudo package. Reassigning to whohas, the maintainer 
probably knows best the actual data source used by whohas.


Andreas

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Yao Wei]

Hi,

On Fri, Nov 19, 2021 at 03:31:49PM +0900, Osamu Aoki wrote:
> Can you tell us XDG_CURRENT_DESKTOP under sway?

medicalwei@torchic:~$ echo $XDG_SESSION_DESKTOP 
sway

> One thing I feel odd is "GLFW_IM_MODULE=ibus".
> 
> Why not like?
> 
> * GLFW_IM_MODULE=fcitx5
> * GLFW_IM_MODULE=fcitx
> 
> The upstrean web site has confusing comments.
> 
> Does fcitx5 and ibus use compatible API?

fcitx5 implements ibus dbus interface so fcitx5 is compatible with that
setup.

Also, GLFW in kitty only has implementation for ibus dbus interface, so
using values other than ibus does not work.

You can check by the code search:

  https://github.com/kovidgoyal/kitty/search?q=GLFW_IM_MODULE

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#1000178: llvmlite: FTBFS with Python 3.10

[Graham Inggs]

Source: llvmlite
Version: 0.37.0-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

llvmlite FTBFS with Python 3.10 as a supported version [1].  I've
copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=llvmlite


I: pybuild base:237: python3.10 setup.py clean
Traceback (most recent call last):
  File "/<>/setup.py", line 55, in 
_guard_py_ver()
  File "/<>/setup.py", line 52, in _guard_py_ver
raise RuntimeError(msg.format(cur_py, min_py, max_py))
RuntimeError: Cannot install on Python version 3.10.0; only versions
>=3.7,<3.10 are supported.
E: pybuild pybuild:354: clean: plugin distutils failed with: exit
code=1: python3.10 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.10 3.9"
returned exit code 13
make: *** [debian/rules:10: clean] Error 25

Bug#1000163: phast FTBFS: pcre.h: No such file or directory

[Andreas Tille]

Hi Adrian,

Am Thu, Nov 18, 2021 at 11:13:33PM +0200 schrieb Adrian Bunk:
> Source: phast
> Version: 1.6+dfsg-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=phast=1.6%2Bdfsg-2
> 
> ...
> /<>/src/../include/phast/stringsplus.h:27:10: fatal error: 
> pcre.h: No such file or directory
>27 | #include 
>   |  ^~~~
> compilation terminated.
> make[4]: *** [Makefile:13: phast_list_of_lists.o] Error 1

Just for the sake of interest:  If this would not have built in my own
pbuilder chroot I would not have considered uploading.  Well, I could
have checked Salsa CI first but it seems my assumption "builds in
pbuilder so it builds in autobuilders and CI" is wrong.  Any idea how I
can track down this?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Osamu Aoki]

Hi,

On Fri, 2021-11-19 at 10:43 +0800, Yao Wei wrote:
> On Fri, Nov 19, 2021 at 10:50:22AM +0900, Osamu Aoki wrote:
> > 
> > Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested.  What 
> > do you
> > get on sway system who try to use kitty?
> 
> Hi,
> 
> I am currently using sway without desktop manager. I am able to use
> fcitx5 on kitty in sway after setting GLFW_IM_MODULE=ibus, and if that
> variable is unset the IM is not operable in kitty.
> 
> Regarding to the concern of the upstream developr, I don't observe
> performance hit after setting the variable. The only question I am having
> is that whether we should set that variable in im-config because that
> seems to be only used in kitty and nowhere else.
> 
> The followings are the package versions I was testing with:
> 
>   fcitx5  5.0.9-2
>   kitty   0.19.3-1
>   sway1.5.1-2
> 
> Best regards,
> Yao Wei


Can you tell us XDG_CURRENT_DESKTOP under sway?

One thing I feel odd is "GLFW_IM_MODULE=ibus".

Why not like?

* GLFW_IM_MODULE=fcitx5
* GLFW_IM_MODULE=fcitx

The upstrean web site has confusing comments.

Does fcitx5 and ibus use compatible API?

Osamu

Bug#999828: grass-gui: Some tools (v.import; v.in.ogr; r.import) do not start on GUI

[Tomás Senabre González]

Thanks Bas for your quick reply,
You have not given me time to perform the tests you asked me to do. I 
also asked the OSGeo group, and they informed me that this error was 
resolved in the next version.


Greetings and thanks for everything

El 17/11/21 a las 14:13, Sebastiaan Couwenberg escribió:

Control: tags -1 pending

On 11/17/21 12:41, Sebastiaan Couwenberg wrote:

On 11/17/21 11:21, Tomas Senabre wrote:

To Reproduce
Just launch these tools (v.import; v.in.ogr; r.import) from the GUI 
or from command console. I get errors in the console like this:


This works correctly with 7.8.6 on Debian unstable.


   File "/usr/lib/grass78/gui/wxpython/core/utils.py", line 675, in
_parseFormats
 key, name = map(lambda x: x.strip(), line.strip().rsplit(':', -1))
ValueError: too many values to unpack (expected 2)
OnInit returned false, exiting...


That looks like this issue:

  https://github.com/OSGeo/grass/pull/1226

Can you confirm that the commits from that issue fixes the problem for 
you as well?


Confirmed the issue in a bullseye VM and the fix when the changes from 
PR 1226 are applied.


A stable update has been prepared to fix the issue in bullseye.

Kind Regards,

Bas



--
Tomás Senabre González

Bug#1000000: fixed in phast 1.6+dfsg-2

[Andreas Tille]

Hi,

Am Thu, Nov 18, 2021 at 11:12:12PM +0200 schrieb Adrian Bunk:
> On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote:
> >...
> > For the Debian package you could drop use_debian_packaged_libpcre.patch and
> > use the embedded copy to not block the prce3 removal in Debian.
> 
> As a general comment, this would be a lot worse than keeping pcre3.

Since I agree here I started (! not working yet!) with a patch[2].  I
remember that upstream - who has basically stopped development if I
remember correctly - was not even happy, that we replace the code copy.
Thus I assume that they are not very interested in providing a pcre2
patch and we are on our own.

> If any copy of this library should be used at all in bookworm,
> it should be provided by src:pcre3.

I agree and I assume we will need this.  Several packages that received
this bug report are not actively developed any more but used by our
users.  So it might be that we need to work on this ourselves and this
needs time (and knowledge).
 
> Switching from src:pcre3 to an older vendored copy would likely create 
> additional security vulnerabilities for our users,[1] even with only one 
> user in bookworm shipping it security supportable in src:pcre3 would be 
> better than hiding vulnerabilities through vendoring.

+1

Kind regards

Andreas.
 
> [1] https://security-tracker.debian.org/tracker/source-package/pcre3
[2] 
https://salsa.debian.org/med-team/phast/-/blob/master/debian/patches/pcre2.patch
 

-- 
http://fam-tille.de

Bug#999543: devscripts: uscan crash with cmus package

[Yadd]

Le 18/11/2021 à 21:47, Christian Marillat a écrit :
> reopen 999543
> thanks
> 
> On 18 nov. 2021 19:24, Yadd  wrote:
> 
>> Hi,
> 
> Hi,
> 
>> uscan 2.21.5 now fails when filenamemangle regex doesn't match upstream
>> filename. This avoids some conflicts with GitHub downloads (which names
>> all files "v"): a previously downloaded file can be modified
>> when more than one download is done.
> 
> I'm sorry but this is a bug, uscan must not crash.
> 
> Here I've 485 sources to scan and uscan leaves 300 sources not
> scanned.

This is risky to uscan 300 GitHub sources with such filenamemangles: one
download could overwrite a previously downloaded file. I'm using this
for the thousands JS broken packages (already more than 300 fixed):

  perl -i -pe
's#filenamemangle=s/\.\*\\\/v\?\(\[\\d\\.\-\]\+\)\\\.tar\\\..z\/(node-.*)-\$1\.tar\.gz/#filenamemangle=s/.*?(\\d[\\d\\.-]*\@ARCHIVE_EXT\@)/$1-\$1/#'
debian/watch

Anyway, I added a --no-fail option in this MR:
https://salsa.debian.org/debian/devscripts/-/merge_requests/246

Bug#1000177: memlockd: conffiles not removed: /etc/memlockd.cfg /etc/default/memlockd

[Paul Wise]

Package: memlockd
Version: 1.3-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=memlockd ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
memlockd: obsolete-conffile /etc/memlockd.cfg
memlockd: obsolete-conffile /etc/default/memlockd
 /etc/memlockd.cfg 829b25475bb483525cb00bbf5d4f68f3 obsolete
 /etc/default/memlockd 65446dbae5065d303d0bbf538882a6f8 obsolete

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages memlockd depends on:
ii  adduser  3.118

memlockd recommends no packages.

memlockd suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990763: [debian-mysql] Bug#990763:

[Otto Kekäläinen]

Hello Etes!

Please follow up on this bug report or we can't do anything than close
the issue as invalid.

On Sun, Aug 8, 2021 at 7:15 PM Daniel Black  wrote:
>
> Hi,
>
> MDEV-25394 is dissimilar. It is in InnoDB while this appears to be in
> the optimizer code.
>
> A new 10.3.31 is coming soon
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/273217
>
> The optimizer related fixes in the two version since 10.3.29 are:
> https://jira.mariadb.org/issues/?jql=fixVersion%20%20in%20(10.3.30%2C%2010.3.31)%20and%20component%20%3D%20Optimizer
>
> Looking at these bugs I can't see anything that looks particularly equivalent.
>
> So in summary, we do need more information to resolve this. Ideally
> this should be a new MDEV project bug on https://jira.mariadb.org/.
>
> The information that would be most useful is:
> * the query that caused this. This should of been in the log
> * `SHOW CREATE TABLE {tablename}` for the table is the query.
> * EXPLAIN EXTENDED {query}; SHOW WARNINGS
>
> The stack trace shows this is occurring as a prepared statement. If
> you are willing to risk the availability of the server running this as
> a non-prepared statement straight from the mariadb command line that
> would be useful as a test point.
>
> If the core file is still available/reproducible the following
> additional resolution of the stack traces that will aid MariaDB staff.
>
>  cat >>/etc/apt/sources.list.d/debug.list <<'EOT'
> deb http://deb.debian.org/debian-debug buster-debug main contrib non-free
> EOT
>
>  apt-get install -y gdb mariadb-server-core-10.3-dbg
>
> gdb /usr/sbin/mysqld core
>
> thread apply all bt full
>
> The dbg symbols and gdb resolution can be on a different server or
> even in a container that can access the core.
>
> If this contains confidential information like tablenames (its
> unlikely to contain table contents) of your client you can use
> https://mariadb.com/kb/en/meta/mariadb-ftp-server/ to make this only
> available to MariaDB people for the purpose of debugging this issue.
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#991839: [debian-mysql] Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance

[Otto Kekäläinen]

Control: tags -1 moreinfo

Jeremy, please follow up on your bug report or we won't be able to help you.

On Tue, Aug 3, 2021 at 1:39 PM Daniel Black  wrote:
>
> Jeremy,
>
> You are correct in that this is due to one of the hardening directives
> in the service file Protect{Home,System} or PrivateDevices that is
> trying to be applied before the kernel/system has completed the
> underlying mounts on which they depend.
>
> Without these hardening directives, and without
> PermissionsStartOnly=true and all of the ExecStartPre= directives the
> system is pretty secure as the mysqld/mariadbd process is run under
> the non-privileged mysql user which ordinary cannot perform the
> restricted items. Being a tiny VM I'm assuming this is the only
> services there.
>
> systemd-analyze dump (hint from
> https://freedesktop.org/wiki/Software/systemd/Debugging/#reportingsystemdbugs-
> Information to Attach to a Bug Report) may include some timing
> information of services to verify. The logs since boot `journalctl -b`
> might give enough information to see what ordering is happening at
> boot.
>
> kernel argument systemd.log_level=debug will include more information
> in the mariadb.service journal `journalctl -u mariadb.service
> --priority=7` such that the specific mount/system call might be able
> to be identified. systemd.log_level=debug will probably make the
> journalctl -b too verbose to read

Bug#999738: runtime deps on -dev library symlinks not caught

[Felix Lechner]

Hi Bdale,

On Thu, Nov 18, 2021 at 2:20 PM Bdale Garbee  wrote:
>
> I don't know if lintian already tries to parse any scheme source.

We do not, currently.

> just close this as I don't think it's worth chasing.

For now, I would like to offer you this research tag. [1] The output
will not appear on our website or be shown to any users, but you could
(relatively soon) access archive-wide results via our JSON interface.
[2] We would then try to refine the tag for public consumption
together.

What do you think, please?

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/merge_requests/382
[2] https://lintian.debian.org/query

Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it

[Ross Boylan]

Package: bacula-director-pgsql
Version: 9.4.2-2+deb10u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   My 2nd attempt to install bacula after initial failure of
   Bug#1000174.
   Because of that, configuration asks lower-priority questions.
   I requested password based login and gave a FQDN for the PG server.
   I get to this screen
 │ Please provide the password for the postgres account with which this package 
should perform administrative actions.   │ 
 │  
 │ 
 │ For a standard PostgreSQL installation, a database password is not required, 
since authentication is done at the system   │ 
 │ level.   
 │ 
 │  
 │ 
 │ Password of your database's administrative user:
  
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Left the password field blank.  That's my only choice, since I
   never set it during PG setup (that is, when I installed PG, months
 ago).  I hit OK. 
   
   * What was the outcome of this action?
   | Empty passwords unsupported with PostgreSQL |
   with the only choice being OK, which takes me back to prior screen.

   * What outcome did you expect instead?
   That the configuration would accept my omission of the password
   since the earlier step recommended it!  And that the omission
   would be possible, since I do have the standard setup in which it
   is not set.

Comment: The host name I set for the PG database is an alias for the
same machine on which I'm installing bacula.  It's unclear to me if
that will confuse the installer and subsequent operations about
whether it's the same.  I did accept the default tcp/ip communication
with the database.

Next step: I'm not sure.  Several alternatives:
1. tell the setup not to use dbconfig and clean things up afterward.
2. enter a bogus password to get past this step and hope it will be
ignored.
3. set a real password for the postgres user and then enter that.


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

Kernel: Linux 4.19.0-18-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bacula-director-pgsql depends on:
iu  bacula-common-pgsql   9.4.2-2+deb10u1
iu  dbconfig-pgsql2.0.11+deb10u1
ii  debconf [debconf-2.0] 1.5.71+deb10u1
iu  postgresql-client 11+200+deb10u4
ii  postgresql-client-11 [postgresql-client]  11.14-0+deb10u1

Versions of packages bacula-director-pgsql recommends:
ii  postgresql  11+200+deb10u4

Versions of packages bacula-director-pgsql suggests:
ii  gawk  1:4.2.1+dfsg-1

-- no debconf information

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Yao Wei]

On Fri, Nov 19, 2021 at 10:50:22AM +0900, Osamu Aoki wrote:
> Hmmm...I see.  This is worrying
> 
> Anyway, situation of enabling IM needs help from someone understanding GLFW 
> related
> backend keyboard input handling.  The successful user seem to use "sway" for 
> Desktop
> management.  Is there any other programs using similar backend.
> 
> If problem is happening with backend using xim, that is likely the situation 
> just
> like GTK.  But this seems to indicate otherwise.
> 
> Anyway, those who seems having trouble setting up ibus or fcitx5 didn't set up
> environment variable properly.  There are too much noise.  So we need 
> feedback from
> good tester reporting situation with versions involved (ibus, fcitx5, ...)
> 
> Current in testing are:
> 
> kitty   0.19.3-1
> ibus1.5.25-3
> fcitx5  5.0.9-2
> sway1.5.1-2
> 
> 
> (fcitx   1:4.2.9.8-3)
> 
> > > I am not sure what is "the other way around"?
> > 
> > The purpose of im-config is to make sure that an IM framework — if 
> > present — is launched and configured by default.
> > 
> > > So for wayland ready IM (ibus and fcitx5?) it may be right to set
> > > such setting.
> > 
> > Please remember that im-config doesn't do anything in case of IBus on a 
> > GNOME desktop, but we defer to GNOME's mechanisms for launching and 
> > configuring IBus.
> 
> Yes.  I plan to keep it this way for GNOME.
> 
> Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested.  What 
> do you
> get on sway system who try to use kitty?

Hi,

I am currently using sway without desktop manager. I am able to use
fcitx5 on kitty in sway after setting GLFW_IM_MODULE=ibus, and if that
variable is unset the IM is not operable in kitty.

Regarding to the concern of the upstream developr, I don't observe
performance hit after setting the variable. The only question I am having
is that whether we should set that variable in im-config because that
seems to be only used in kitty and nowhere else.

The followings are the package versions I was testing with:

  fcitx5  5.0.9-2
  kitty   0.19.3-1
  sway1.5.1-2

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#997719: libvirt-python: FTBFS: ERROR: failed virDomainGetMessages

[Stefano Rivera]

Hi Lucas (2021.10.24_07:40:18_-0400)

Looks like a mismatch between libvirt-python and libvirt itself, that
would be resolved by upgrading it to version 7.6.0 (or later).

SR

Bug#997363: libtorrent-rasterbar: FTBFS: configure: error: *** A compiler with support for C++17 language features is required.

[Stefano Rivera]

Presumably resolved in 2.0.0 in NEW, that doesn't use autoconf any more.

SR

Bug#984256: nextepc: ftbfs with GCC-11

[Steve Langasek]

Package: nextepc
Version: 0.3.10+nods-4.1
Followup-For: Bug #984256
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Hi Ruben,

Please find attached a patch for this issue.  It has been uploaded to Ubuntu
to fix the build failure there.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru nextepc-0.3.10+nods/debian/patches/gcc-11.patch 
nextepc-0.3.10+nods/debian/patches/gcc-11.patch
--- nextepc-0.3.10+nods/debian/patches/gcc-11.patch 1969-12-31 
16:00:00.0 -0800
+++ nextepc-0.3.10+nods/debian/patches/gcc-11.patch 2021-11-18 
17:50:37.0 -0800
@@ -0,0 +1,27 @@
+Description: fix build failure with gcc-11.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/984256
+Last-Update: 2021-11-18
+
+Index: nextepc-0.3.10+nods/lib/core/test/testatomic.c
+===
+--- nextepc-0.3.10+nods.orig/lib/core/test/testatomic.c
 nextepc-0.3.10+nods/lib/core/test/testatomic.c
+@@ -100,7 +100,7 @@
+ 
+ static void test_casptr_equal_nonnull(abts_case *tc, void *data)
+ {
+-int a, b;
++int a = 0, b = 0;
+ void *target_ptr = 
+ void *old_ptr;
+ 
+@@ -111,7 +111,7 @@
+ 
+ static void test_casptr_notequal(abts_case *tc, void *data)
+ {
+-int a, b;
++int a = 0, b = 0;
+ void *target_ptr = 
+ void *old_ptr;
+ 
diff -Nru nextepc-0.3.10+nods/debian/patches/series 
nextepc-0.3.10+nods/debian/patches/series
--- nextepc-0.3.10+nods/debian/patches/series   2021-01-23 14:35:09.0 
-0800
+++ nextepc-0.3.10+nods/debian/patches/series   2021-11-18 17:49:29.0 
-0800
@@ -5,3 +5,4 @@
 0005-Set-install-dir-for-freediameter-libs.patch
 0006-Fix-big-endian-bug.patch
 0007-Patch-deprecated-sys-sysctl.h-problem.patch
+gcc-11.patch

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Osamu Aoki]

Hi,
\
On Thu, 2021-11-18 at 16:09 +0100, Gunnar Hjalmarsson wrote:
> On 2021-11-18 15:29, Osamu Aoki wrote:
> > On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
> > > Reading  makes me
> > > still hesitate, though. If I understand it correctly, the principal
> > > kitty developer has intentionally not enabled IME input by default
> > > due to claimed efficiency issues and bugs.
> > 
> > I am not sure which comment are you talking...
> 
> https://github.com/kovidgoyal/kitty/issues/469#issuecomment-419406438

Hmmm...I see.  This is worrying

Anyway, situation of enabling IM needs help from someone understanding GLFW 
related
backend keyboard input handling.  The successful user seem to use "sway" for 
Desktop
management.  Is there any other programs using similar backend.

If problem is happening with backend using xim, that is likely the situation 
just
like GTK.  But this seems to indicate otherwise.

Anyway, those who seems having trouble setting up ibus or fcitx5 didn't set up
environment variable properly.  There are too much noise.  So we need feedback 
from
good tester reporting situation with versions involved (ibus, fcitx5, ...)

Current in testing are:

kitty   0.19.3-1
ibus1.5.25-3
fcitx5  5.0.9-2
sway1.5.1-2


(fcitx   1:4.2.9.8-3)

> > I am not sure what is "the other way around"?
> 
> The purpose of im-config is to make sure that an IM framework — if 
> present — is launched and configured by default.
> 
> > So for wayland ready IM (ibus and fcitx5?) it may be right to set
> > such setting.
> 
> Please remember that im-config doesn't do anything in case of IBus on a 
> GNOME desktop, but we defer to GNOME's mechanisms for launching and 
> configuring IBus.

Yes.  I plan to keep it this way for GNOME.

Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested.  What do 
you
get on sway system who try to use kitty?

> > Tell us how this all fit together.
> 
> +1
> 

Bug#889197: ITA: golang-github-yohcop-openid-go - OpenID 2.0 implementation in Go

[Mathias Gibbens]

retitle 889197 ITA: golang-github-yohcop-openid-go - OpenID 2.0 implementation 
in Go
owner !
block 998752 by 889197
thanks

  I will adopt this package, as it's a dependency for packaging golang-
github-canonical-candid, which is in turn a dependency for LXD.

Mathias


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

Bug#940360: ITA: golang-github-go-ldap-ldap

[Mathias Gibbens]

retitle 940360 ITA: golang-github-go-ldap-ldap
owner 940360 !
block 998752 by 940360
thanks

  I will adopt this package, as it's a dependency for packaging golang-
github-canonical-candid, which is in turn a dependency for LXD.

Mathias


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

Bug#998039: ITP: makedeb -- The modern packaging tool for Debian archives.

[Guillem Jover]

[ Sorry, have not seen this up to now as the Debian BTS does not
  automatically CC people, that needs to be done explicitly. ]

Hi!

On Thu, 2021-11-04 at 08:44:57 -0700, LEO PUVILLAND wrote:
> What do you mean by hardcoded dependencies?

AFAICS with makedeb you hardcode f.ex. shared libraries in the
dependencies such as in:

  https://mpr.hunterwittenborn.com/cgit/aur.git/tree/PKGBUILD?h=polybar#n10

instead of both inferring the package name the libraries used come
from, and retrieving the correct versioned dependency information from
the shlibs and/or symbols files. (See the man pages for dpkg-shlibdeps,
deb-shlibs, deb-symbols and deb-src-symbols).

This means these can end up from encoding incorrect dependency
relationships that can cause linker errors, to segfaults due to ABI
requirements not fulfilled. Or simply require mass manual updates when
the SONAME is bumped but the API is preserved, which would otherwise
only require a rebuild.

Many of the debhelper tooling contains code implementing policies and
integration that is expected from packages that are installed on Debian
systems.

> > This also implies much
> > of the current automatic handling found in, say, debhelper and related
> > tools is skipped, which does not look would make it easier to generate
> > properly integrated packages.
> 
> makedeb doesn't use the native debian format and I believe that's a design
> choice, instead it uses the alternate PKGBUILD format, inspired by Arch
> Linux. I looked at the issues you mentioned and I can see your point.
> However, isn't one of the core principles of Linux freedom of choice? This
> is simply another way to package for Debian.

Sure, I understand that, and can see the appeal for some people coming
from the Arch Linux world. But that still will just not produce fully
and correctly integrated Debian packages.

I don't think freedom of choice is a core principles of Linux (the
kernel? :), nor the FOSS movement. People might want that, and that's
fair, but we should never forget that more choice can also bring more
confusion, worse user experience, etc. In this case I think upstream
should clearly note all limitations with this approach, and start by
not stating this is “the modern packaging tool for Debian”. :)

Including (currently) this in Debian, to me gives the impression this
packaging method will give results of similar quality and integration
as packaging with native tools, which seems undesirable, TBH.

Thanks,
Guillem

Bug#996270: false positive custom-library-search-path

[Felix Lechner]

Control: reopen -1

Hi,

On Thu, Nov 18, 2021 at 3:51 PM Michael Biebl  wrote:
>
> E custom-library-search-path RUNPATH /usr/lib/x86_64-linux-
> gnu/NetworkManager/1.32.12 [usr/lib/x86_64-linux-
> gnu/NetworkManager/1.32.12/libnm-device-plugin-bluetooth.so]

The subfolder is not named after the package name (due to camel case).
Should I allow all subfolders?

Kind regards
Felix Lechner

Bug#1000175: python3-lz4tools is empty

[Adrian Bunk]

Package: python3-lz4tools
Version: 1.3.1.1-4
Severity: grave

$ dpkg -L python3-lz4tools
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python3-lz4tools
/usr/share/doc/python3-lz4tools/changelog.Debian.gz
/usr/share/doc/python3-lz4tools/copyright
$

Bug#905071: ITP: golang-github-juju-names -- A package to deal with juju names (services, units, machines, etc)

[Mathias Gibbens]

retitle 905071 ITP: golang-github-juju-names -- A package to deal with juju 
names (services, units, machines, etc)
owner 905071 !
block 768073 by 905071
block 905071 by 940381
thanks

* Package name: golang-github-juju-names
  Version : 4.0.0-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/names
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : A package to deal with juju names (services, units, 
machines, etc)

 This package provides helpers for handling Juju entity names.

  I spoke with Clément who is fine with me taking up this ITP, so
setting owner to myself.

Mathias


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

Bug#1000174: bacula-director-pgsql: setup fails with "Unrecognized role option"

[Ross Boylan]

Package: bacula-director-pgsql
Version: 9.4.2-2+deb10u1
Severity: normal

Dear Maintainer,

I left the severity at normal because I suspect there is an easy
work-around; the problem actually leaves the package uninstalled or at
least not operable, and so it might be considered more serious.

   * What led up to the situation?
   Installing the bacula package onto a system with postgres already
   present, but no prior bacula installation.
   Opted for the PG based backend.
   Elected the default dbconfig controlled setup.
   Entered eiXu7Boo{z'a as the password for the database (twice)
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I plan to retry with a password that does not include the ' character.

   * What was the outcome of the original actions?
   With the original password the installer (aptitude) showed the
   following:
   ERROR: unrecognized role option "a" LINE 1: CREATE USER "bacula"
   WITH PASSWORD 'eiXu7Boo{z\'a' ^ .  It offers several options for
   how to proceed, with the caution that some may leave bacula inoperable.

   * What outcome did you expect instead?
   That a PG account with the password I gave would be created.

My theory is that, despite the \ that was stuffed before it, the
second ' was parsed as ending the password and the a that followed it
was taken to be a role option.

The root cause may lie with another package, maybe dbconfig
or the PG client libs.  Feel free to reassign.

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


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

Kernel: Linux 4.19.0-18-amd64 (SMP w/8 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bacula-director-pgsql depends on:
iu  bacula-common-pgsql   9.4.2-2+deb10u1
iu  dbconfig-pgsql2.0.11+deb10u1
ii  debconf [debconf-2.0] 1.5.71+deb10u1
iu  postgresql-client 11+200+deb10u4
ii  postgresql-client-11 [postgresql-client]  11.14-0+deb10u1

Versions of packages bacula-director-pgsql recommends:
ii  postgresql  11+200+deb10u4

Versions of packages bacula-director-pgsql suggests:
ii  gawk  1:4.2.1+dfsg-1

-- no debconf information

Bug#996270: false positive custom-library-search-path

[Michael Biebl]

Looks like this is not fully fixed yet. Just saw this for the network-
manager package [1] 

E custom-library-search-path RUNPATH /usr/lib/x86_64-linux-
gnu/NetworkManager/1.32.12 [usr/lib/x86_64-linux-
gnu/NetworkManager/1.32.12/libnm-device-plugin-bluetooth.so]

E custom-library-search-path RUNPATH /usr/lib/x86_64-linux-
gnu/NetworkManager/1.32.12 [usr/lib/x86_64-linux-
gnu/NetworkManager/1.32.12/libnm-device-plugin-wwan.so]


Should we reopen this bug report or open a new one?


[1] https://lintian.debian.org/sources/network-manager


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

Bug#1000173: lldb-11: lldb --python-path prints the wrong path

[Lawrence D'Anna]

Package: lldb-11
Version: 1:11.0.1-2
Severity: normal
X-Debbugs-Cc: la...@elder-gods.org

Dear Maintainer,

lldb --python-path prints the wrong path.  

It prints /usr/lib/lib/python3/dist-packages, but it should be

/usr/lib/python3/dist-package
or perhaps
/usr/lib/llvm-11/lib/python3/dist-packages/

This is because debian packaging scripts built it with

-DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-11

So lldb expects that liblldb will be installed at 
/usr/lib/llvm-11/lib/liblldb.so.1
but this has been moved to /lib/x86_64-linux-gnu/liblldb-11.so.1 and replaced 
with a symlink.

The way lldb finds its python path is essentially 
$(dirname $(dirname $path_to_liblldb))/lib/python3/dist-packages

see: ScriptInterpreterPython::ComputePythonDir, 
ScriptInterpreterPython::GetPythonDir
https://github.com/llvm/llvm-project/blob/7c5ecc8b7e1bcd1b02eafeba9bbf3d5bc50d72c5/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp#L394



-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.47-linuxkit (SMP w/5 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lldb-11 depends on:
ii  libc62.31-13+deb11u2
ii  libclang-cpp11   1:11.0.1-2
ii  libedit2 3.1-20191231-2+b1
ii  libgcc-s110.2.1-6
ii  liblldb-11   1:11.0.1-2
ii  libllvm111:11.0.1-2
ii  libncurses6  6.2+20201114-2
ii  libstdc++6   10.2.1-6
ii  libtinfo66.2+20201114-2
ii  llvm-11-dev  1:11.0.1-2
ii  python3-lldb-11  1:11.0.1-2

lldb-11 recommends no packages.

lldb-11 suggests no packages.

-- no debconf information

Bug#999815: cryptsetup - build-depends on removed package.

[Guilhem Moulin]

On Thu, 18 Nov 2021 at 23:13:59 +0100, Christian Göttsche wrote:
> A quick test build without those two build-dependencies resulted in
> identical binary packages.

They are currently pulled transitively by libdevmapper-dev, so removing
them from the explicit Build-Depends doesn't yield a different build
environment.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Thomas Dickey]

On Thu, Nov 18, 2021 at 08:15:15PM +0100, Sven Joachim wrote:
> On 2021-11-17 20:21 -0500, Thomas Dickey wrote:
> 
> > On Wed, Nov 17, 2021 at 05:16:52PM +0100, Sven Joachim wrote:
> >> Control: reassign -1 ncurses-base 6.3-1
> >>
> >> On 2021-11-17 01:11 +0100, Josh Triplett wrote:
> >>
> >> > I just confirmed that upgrading *only* ncurses-base causes the issue to
> >> > appear, and downgrading *only* ncurses-base causes the issue to
> >> > disappear.
> >>
> >> Thanks, that makes sense.  For me it is broken in bookworm already, but
> >> others have seen it only after upgrading ncurses to 6.3-1. For the
> >> reference, the relevant change in ncurses is this:
> >>
> >> ,
> >> | 20210925
> >> |  + add smglp and smgrp to vt420+lrmm, to provide useful data for the
> >> |"tabs" +m option -TD
> >> `
> >
> > yes - I implemented left/right margins in xterm in 2012 (patch #279)
> > (not quite as long ago as repeat_char).
> >
> > however, the left/right margin feature was present earlier:
> >
> > REV:1.730   terminfo.src2019/05/18 18:58:45   tom
> >
> >add vt420 left/right margins for xterm-new
> >
> > +# Left/right margins are supported in xterm since patch #279 (2012/05/10)
> > +vt420+lrmm|VT420 left/right margins,
> > +   mgc=\E[?69l, smglr=\E[?69h\E[%i%p1%d;%p2%ds,
> >
> >> The neovim developers have pushed a workaround:
> >>
> >> https://github.com/neovim/neovim/issues/16238
> >
> > ...which seems enough to fix their issue
> > (they're checking if $XTERM_VERSION is set)
> 
> Aha, this also explains why I experienced the problem even with older
> ncurses-base, I had started gnome-terminal from xterm!
> 
> > Since the feature was already present in a different form,
> > it seems that neovim is the only widespread user of this.
> 
> Quite likely.
> 
> >> I am not quite sure what to do with this in ncurses.  As long as the
> >> problem only affects neovim and VTE based terminal emulators I am
> >> inclined to ignore it, but if it turns out to be more widespread I could
> >> back out the new feature, like I did in #933053.
> >
> > I don't see that it's necessary.
> 
> Yes, I think a versioned Breaks against neovim should be sufficient,
> once a fixed neovim package is available.
> 
> > By the way, #933053 is kind of stale - likely there's no sufficiently
> > old systems with broken vte libraries to appease.
> 
> Unfortunately there is at least one unfixed terminal emulator around,
> #930037 and the corresponding upstream bug in mosh are still open.

that may take a while (unless someone knowledgeable about terminals
helps -- the mosh developers aren't in that category, as I can see
from reading its source-code).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#999980: proftpd-dfsg: depends on obsolete pcre3 library

[Hilmar Preuße]

Control: forwarded -1 https://github.com/proftpd/proftpd/issues/1353

Am 18.11.2021 um 12:49 teilte Matthew Vernon mit:

Hi,


Your package still depends on the old, obsolete PCRE3[0] libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, I
would like to remove the pcre3 libraries from Debian, preferably in
time for the release of Bookworm.


Forwarded to upstream for now.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998455: regina-normal: b-d on python3-all-dev, but not built for all supported Python3 versions

[Benjamin Burton]

Thanks - there is a new upstream release coming hopefully within the next 
month, and I will update the build-depends when I push that through.

- Ben.

Bug#1000172: gnome-shell: Mouse hangs long when moving over sidepages of Show Applications page

[Gert van de Kraats]

Package: gnome-shell
Version: 41.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

Problem occurs at the Show Applications page.
If the mouse moved over the slideSidePages at the left or the right of
the page with application icons, it hangs about 15 to 30 seconds,
before the arrow and a row of icons of the next page are shown.

This also occurs at the left slideSidePage of the first Applications page,
where
no arrow and icons will be showed,
and at the right slideSidePage of the last Applications page, which also
remains black.
Also switching to next-page with icons is very slow.

Problem is caused by updateFadeForNavigation, which requests fading,
which apparently is too heavy for the graphics card i915, causing 
switching to

software rendering.

Nov 7 00:34:11 debian org.gnome.Shell.desktop[16778]: ENTER FALLBACK 1:
Program
Nov 7 00:34:24 debian org.gnome.Shell.desktop[16778]: LEAVE FALLBACK Program
Nov 7 00:34:24 debian org.gnome.Shell.desktop[16778]: ENTER FALLBACK 1:
Program
Nov 7 00:34:40 debian org.gnome.Shell.desktop[16778]: LEAVE FALLBACK Program

A solution could be to bypass updateFadeForNavigation if animation is 
disabled.
No functionality is lost, mouse-movement and page-switching is very fast 
then.


Normally I use dual monitor above each other with dash at the left side 
(dash-

to-dock)

In that case you always have to pass the slideSide Page to click on an
application-icon.

Suggested, working patch:

--- gnome-shell-js_org/ui/appDisplay.js 2021-11-18 20:49:25.349628824 +0100
+++ gnome-shell-js/ui/appDisplay.js 2021-11-18 21:04:20.145982445 +0100
@@ -349,6 +349,8 @@
}

_updateFadeForNavigation() {
+ if (!St.Settings.get().enable_animations)
+ return;
const fadeMargin = new Clutter.Margin();
const rtl = this.get_text_direction() === Clutter.TextDirection.RTL;
const showingNextPage = this._pagesShown & SidePages.NEXT;


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

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

Versions of packages gnome-shell depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-2
ii evolution-data-server 3.42.1-1
ii gir1.2-accountsservice-1.0 0.6.55-3
ii gir1.2-atk-1.0 2.36.0-2
ii gir1.2-atspi-2.0 2.42.0-2
ii gir1.2-gcr-3 3.40.0-3+b1
ii gir1.2-gdesktopenums-3.0 41.0-2
ii gir1.2-gdkpixbuf-2.0 2.42.6+dfsg-2
ii gir1.2-gdm-1.0 41.0-3
ii gir1.2-geoclue-2.0 2.5.7-3
ii gir1.2-glib-2.0 1.70.0-2
ii gir1.2-gnomebluetooth-1.0 3.34.5-4
ii gir1.2-gnomedesktop-3.0 41.1-1
ii gir1.2-graphene-1.0 1.10.6+dfsg1-2
ii gir1.2-gstreamer-1.0 1.18.5-1
ii gir1.2-gtk-3.0 3.24.30-3
ii gir1.2-gtk-4.0 4.4.1+ds1-2
ii gir1.2-gweather-3.0 40.0-5
ii gir1.2-ibus-1.0 1.5.25-2
ii gir1.2-mutter-9 41.1-1
ii gir1.2-nm-1.0 1.32.12-1
ii gir1.2-nma-1.0 1.8.32-1
ii gir1.2-pango-1.0 1.48.10+ds1-1
ii gir1.2-polkit-1.0 0.105-31
ii gir1.2-rsvg-2.0 2.50.7+dfsg-2
ii gir1.2-soup-2.4 2.74.1-1
ii gir1.2-upowerglib-1.0 0.99.13-1
ii gir1.2-webkit2-4.0 2.34.1-1
ii gjs 1.70.0-3
ii gnome-backgrounds 41.0-1
ii gnome-settings-daemon 41.0-2
ii gnome-shell-common 41.1-1
ii gsettings-desktop-schemas 41.0-2
ii gstreamer1.0-pipewire 0.3.40-1
ii libatk-bridge2.0-0 2.38.0-2
ii libatk1.0-0 2.36.0-2
ii libc6 2.32-4
ii libcairo2 1.16.0-5
ii libecal-2.0-1 3.42.1-1
ii libedataserver-1.2-26 3.42.1-1
ii libgcr-base-3-1 3.40.0-3+b1
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libgirepository-1.0-1 1.70.0-2
ii libgjs0g 1.70.0-3
ii libgles2 1.3.4-2+b1
ii libglib2.0-0 2.70.1-1
ii libglib2.0-bin 2.70.1-1
ii libgnome-autoar-0-0 0.4.0-1
ii libgnome-desktop-3-19 41.1-1
ii libgraphene-1.0-0 1.10.6+dfsg1-2
ii libgtk-3-0 3.24.30-3
ii libgtk-4-1 4.4.1+ds1-2
ii libical3 3.0.11-2
ii libjson-glib-1.0-0 1.6.6-1
ii libmutter-9-0 41.1-1
ii libnm0 1.32.12-1
ii libpango-1.0-0 1.48.10+ds1-1
ii libpangocairo-1.0-0 1.48.10+ds1-1
ii libpolkit-agent-1-0 0.105-31
ii libpolkit-gobject-1-0 0.105-31
ii libpulse-mainloop-glib0 15.0+dfsg1-2
ii libpulse0 15.0+dfsg1-2
ii libsecret-1-0 0.20.4-2
ii libsystemd0 249.5-2
ii libwayland-server0 1.19.0-2+b1
ii libx11-6 2:1.7.2-2+b1
ii libxfixes3 1:5.0.3-2
ii python3 3.9.7-1

Versions of packages gnome-shell recommends:
ii bolt 0.9.1-2
ii chrome-gnome-shell 10.1-5
ii gdm3 41.0-3
ii gkbd-capplet 3.26.1-1+b1
ii gnome-control-center 1:41.1-1
ii gnome-menus 3.36.0-1
ii gnome-user-docs 41.0-1
ii ibus 1.5.25-2
ii iio-sensor-proxy 3.0-2
ii switcheroo-control 2.4-3
ii unzip 6.0-26

Versions of packages gnome-shell suggests:
ii gir1.2-malcontent-0 0.10.1-1
pn gir1.2-telepathyglib-0.12 
pn gir1.2-telepathylogger-0.2 
ii gnome-shell-extension-prefs 41.1-1

Versions of packages gnome-session depends on:
ii gnome-session-bin 40.1.1-3
ii gnome-session-common 40.1.1-3
ii gnome-settings-daemon 41.0-2

Versions of packages gnome-session suggests:
ii 

Bug#999738: runtime deps on -dev library symlinks not caught

[Bdale Garbee]

Felix Lechner  writes:

> Do you have the output of 'readelf --all --wide' [1] for one of those
> binaries?

The elf library binaries delivered by the package actually look fine.

Digging further, it appears the problem cases are all in guile code,
where the function dynamic-link is handed a token like 'libglib-2.0':

(define libglib (dynamic-link "libglib-2.0"))

This guile code gets "compiled" on the first invocation of the
application and cached in ~/.cache/guile.  The problem is that at
runtime, that function call results in an attempt to load
'libglib-2.0.so' which fails if the -dev package isn't installed. 

I'm fixing those with Makefile.am changes like:

  -LIBGLIB=libglib-2.0
  +LIBGLIB := $(shell /sbin/ldconfig -p | awk '/libglib-2.0.so\./ { print $$1 
}')

That changes the guile code to look like:

(define libglib (dynamic-link "libglib-2.0.so.0"))

which works as desired at runtime, since that symlink is provided by the
binary library package.

So .. I'm not sure how good the return on investment of trying to add a
test for this in lintian would be.  Talking to upstream about it, the
approach I'm using in Makefile.am seems credible and they make just take
that in.  There's no indication the dynamic-link function in guile is
going to get any "smarter", so Makefile.am is probably the right place
to fix the problem.

> Your condition involves sonames that I believe are customarily
> provided by links in '-dev' installables instead of regular shared
> library packages.

Exactly.

> What do you think, please? Thanks!

I don't know if lintian already tries to parse any scheme source.  If
not, just close this as I don't think it's worth chasing.  If it does,
we could perhaps add a test for the dynamic-link function being handed a
token without '.so.0' in it, or something?

Bdale


signature.asc
Description: PGP signature

Bug#1000171: xmlcopyeditor: Please migrate to automatic debug packages

[Boyuan Yang]

Source: xmlcopyeditor
Version: 1.2.1.3-4.1
Severity: normal
Tags: sid bookworm
X-Debbugs-CC: mir...@debian.org

Dear Debian xmlcopyeditor package maintainer,

Your package manually creates xmlcopyeditor-dbg package. Please consider
migrating to automatic debug packages as described in
https://wiki.debian.org/AutomaticDebugPackages . Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#1000170: Not compatible with experimental xserver-xorg-core 21.1.1

[Yuri D'Elia]

Package: xserver-xorg-video-dummy
Version: 1:0.3.8-1+b1
Severity: normal

xserver-xorg-video-dummy depends on xorg-video-abi-24, but the new
release of xorg 21.1 on experimental provides xorg-video-abi-25

Bug#999906: After upgrade to Debian Bullseye, I am not able to burn DVDs.

[Thomas Schmitt]

Hi,

i am the developer of libburn, which serves underneath xfburn and xorriso.
(No need to Cc: me, as i have now subscribed to this bug.)

--

Quite obviously this report is attributed to the wrong package.
But it is not obvious which one would actually be the right one.

The overall Debian system and the Linux kernel have not much stake
in speed setting of DVD burners or burn success. To blame would rather
be the backends, growisofs under K3B and libburn under the others.
growisofs did not change in a decade. The jump from libburn-1.5.0 in
Debian 10 to libburn-1.5.2 in Debian 11 isn't much suspicious either.
Other distros use it since more than a year earlier.

Please show your xorriso command line and the messages which you get at
the end of the run. (No need to show the many progress messages prefixed
by UPDATE. Everything else might be of interest. Most the very start and
the very end of the run.)

If you can afford experiments with rebooting, then it would be interesting
to see whether you get better results from a Debian 10 Live ISO.
E.g. pick your favorite desktop version from:
  
https://cdimage.debian.org/mirror/cdimage/archive/10.11.0-live/amd64/iso-hybrid/
put it onto a USB stick:
  https://www.debian.org/CD/faq/#write-usb
and after booting install xorriso like
  sudo apt-get update
  sudo apt-get install xorriso

(Disclaimer: I did not test whether the 10.11.0 ISOs have apt-get.)


Have a nice day :)

Thomas

Bug#1000169: gufw: Does not start

[Witold Baryluk]

Package: gufw
Version: 20.04.1-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: witold.bary...@gmail.com

It is broken:

root@debian:~# gufw
/usr/bin/gufw: line 2: [: =: unary operator expected
ls: cannot access '/usr/lib/python*/site-packages/gufw/gufw.py': No such file 
or directory
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:3421888): Gtk-CRITICAL **: 21:47:05.154: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:3421888): Gdk-CRITICAL **: 21:47:05.154: gdk_keymap_get_for_display: 

Bug#1000168: ITP: qt6-webview -- Qt 6 WebView module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-webview
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2+
  Programming Lang: C++
  Description : Qt 6 WebView module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Qt WebView provides a way to display web content in a QML application.

Bug#999883: wordgrinder FTCBFS: multiple issues

[David Given]

Thanks --- yes, that needs fixing. Unfortunately, while wearing my upstream
hat, I've rewritten the build system, but I've applied some changes to make
it honour variables like CC and PKG_CONFIG. The diff is here, if you're
interested: https://github.com/davidgiven/wordgrinder/pull/181/files

The new version's not packaged for Debian yet as there are still some
upstream fixes to be done.

Is there actually a formal spec for the expected interface that polite
Makefiles should honour to make cross building possible? And can you point
me at the Debian tools you're using to do these checks?


On Thu, 18 Nov 2021 at 06:24, Helmut Grohne  wrote:

> Source: wordgrinder
> Version: 0.8-1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> wordgrinder fails to cross build from source for multiple reasons. It
> starts with wordgrinder running plain make without passing any cross
> tools. That part is best solved by using dh_auto_build. Then, the
> makefile runs a build.lua script that hard codes the build architecture
> pkg-config. PKG_CONFIG support should be added to both Makefile and
> build.lua. Beyond that, it strips with the build architecture strip. In
> addition to breaking cross compilation, that approach also breaks
> generation of -dbgsym packages as well as DEB_BUILD_OPTIONS=nostrip. It
> is best to defer stripping to dh_strip and that happens to fix the cross
> build aspect as well.
>
> The attached patch fixes all of the issues mentioned above. However, it
> does not make cross builds succeed as the test suite fails. Cross builds
> do pass nocheck via DEB_BUILD_OPTIONS, but wordgrinder does not honour
> that. So the next step is adding nocheck support.
>
> Anyway, please consider applying the attached patch as an incremental
> step and close this bug when doing so even without adding nocheck
> support.
>
> Helmut
>

Bug#1000167: ITP: qt6-websockets -- Qt 6 WebSockets module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-websockets
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2
  Programming Lang: C++
  Description : Qt 6 WebSockets module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

QtWebSockets is a pure Qt implementation of WebSockets - both client
and server.

Bug#979098: Bug#995843: abook: complete d/copyright file

[Jochen Sprickerhof]

Hi Rhonda,

I've seen that you pushed some commits to your repo and Salsa, great :).
Do you still plan to upload them to Debian (tesing removal would be 
tomorrow)?


I've also seen that you force pushed away some commits.. just wondering.

And yes I would be happy if you add me to the repo members, thanks!

Jochen

* Rhonda D'Vine  [2021-11-02 12:54]:

   Hey Jochen,

resolving would need to enhance the copyright file so that it fulfills
all the required information.  Bastian already did a good job and likely
the patch provided should be sufficient for that.  I haven't gotten
around yet to upload that, but plan to do so in the next few days.

I likely will move the packaging from my private git instance to salsa,
and if you are still interested I can add you to the repository indeed.

Thanks for your interest,
Rhonda


* Jochen Sprickerhof  [2021-11-02 08:20:15 CET]:

Hi Rhonda,

abook is marked for autoremoval in two days due to this bug, can you comment
on how to resolve it?

I would be happy to help maintain abook, if you need help.

Cheers Jochen

* Bastian Germann  [2021-10-13 14:40]:
> Control: tags -1 patch
>
> Hi,
>
> A copyright file for abook with the necessary fixes for this bug is enclosed.
> Please include it in a new package revision.
>
> Thanks,
> Bastian

> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: abook
> Upstream-Contact: Jaakko Heinonen 
> Source: http://abook.sourceforge.net/
>
> Files: *
> Copyright: 2005, Jaakko Heinonen 
> Comment: No license version is specified for most of the code.
> Some GPL-2+ files make the project as a whole GPL-2+.
> License: GPL-2+
>
> Files: abook.1 abookrc.5
> Copyright: Alan Ford 
> License: GPL-2+
>
> Files: aclocal.m4 config.rpath Makefile.in m4/*
> Copyright: (see individual files)
> Comment: Some files come with the disclaimer, some do not.
> License: FSFULLR
>
> Files: config.guess config.sub
> Copyright: 1992-2013 Free Software Foundation, Inc.
> License: GPL-3+ with Autoconf exception
>
> Files: depcomp
> Copyright: 1999-2013 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: getname.c
> Copyright: This code was taken from hypermail
>   modified by Jaakko Heinonen 
>   .
>   For strcpymax() function:
>   Copyright (C) 1994, 1995 Enterprise Integration Technologies Corp.
>   VeriFone Inc./Hewlett-Packard. All Rights Reserved.
> Comment: See https://bugs.debian.org/979098 for details on assuming GPL-2+
> License: GPL-2+
>
> Files: getopt*
> Copyright: 1987-1997 Free Software Foundation, Inc.
> License: LGPL-2+
>
> Files: install-sh
> Copyright: 1994 X Consortium
> License: X11
>
> Files: ldif.c
> Copyright: 1992-1996 Regents of the University of Michigan.
> Comment: adapted to use with abook by JH 
> License: Michigan
> Redistribution and use in source and binary forms are permitted
> provided that this notice is preserved and that due credit is given
> to the University of Michigan at Ann Arbor. The name of the University
> may not be used to endorse or promote products derived from this
> software without specific prior written permission. This software
> is provided ``as is'' without express or implied warranty.
>
> Files: mbswidth.?
> Copyright: 2000-2002 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: misc.c
> Copyright: Jaakko Heinonen
>   1994 Lars Wirzenius
> Comment: BSD-2-clause covers the getaline() function.
> License: GPL-2+ and BSD-2-clause
>
> Files: missing
> Copyright: 1996-2013 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: po/fr.po po/it.po po/sv.po
> Copyright: 2005 Free Software Foundation, Inc.
> License: GPL-2+
>
> Files: vcard.c
> Copyright: 2012, Raphaël Droz 
> License: GPL-2+
>
> Files: views.c
> Copyright: Cedric Duval
> License: GPL-2+
>
> Files: xmalloc.c
> Copyright: 2005 Jaakko Heinonen
> License: BSD-2-clause
>
> Files: debian/*
> Copyright: 2000, Alan Ford 
>   2003, Rhonda D'Vine 
>   2015, Denis Briand 
> License: WTFPLv2
>
> License: GPL-2+
>This program is free software; you can redistribute it and/or modify
>it under the terms of the GNU General Public License as published by
>the Free Software Foundation; either version 2 of the License, or
>(at your option) any later version.
>.
>This program is distributed in the hope that it will be useful,
>but WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>GNU General Public License for more details.
>.
>You should have received a copy of the GNU General Public License
>along with this program; if not, write to the Free Software
>Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>MA 02110-1301 USA.
>.
> On Debian GNU/Linux systems, the complete text of the GNU General
> Public License version 2 can be found in `/usr/share/common-licenses/GPL-2',
> later versions can be found 

Bug#1000160: firmware: failed to load nouveau/nvc3_fuc084 and nvc3_fuc084d

[Sven Joachim]

On 2021-11-18 21:10 +0100, Tomas Senabre wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.17-1
> Severity: normal
> Tags: upstream
>
> I continually receive failure messages to load the firmware:
>
> [ 4138.126756] nouveau :03:00.0: firmware: failed to load
> nouveau/nvc3_fuc084 (-2)
> [ 4138.126762] nouveau :03:00.0: Direct firmware load for
> nouveau/nvc3_fuc084 failed with error -2
> [ 4138.126771] nouveau :03:00.0: firmware: failed to load
> nouveau/nvc3_fuc084d (-2)
> [ 4138.126773] nouveau :03:00.0: Direct firmware load for
> nouveau/nvc3_fuc084d failed with error -2
> [ 4138.126774] nouveau :03:00.0: msvld: unable to load firmware data
> [ 4138.126776] nouveau :03:00.0: msvld: init failed, -19

The firmware in question is not distributable, you would have to extract
it from the NVidia blob.  Unless you intend to do video decoding with
your card, you can safely ignore these errors.

https://nouveau.freedesktop.org/VideoAcceleration.html

This is a kernel problem, BTW.  The package you reported it against is
not even used.

Cheers,
   Sven

Bug#1000166: ITP: qt6-webengine -- Qt 6 WebEngine module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-webengine
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2
  Programming Lang: C++
  Description : Qt 6 WebEngine module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Qt WebEngine provides functionality for rendering regions of dynamic
web content.

Bug#999952: suricata: depends on obsolete pcre3 library

[Sascha Steinbiss]

Hi Matthew,

thanks for letting us know.

> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
[...]

Suricata upstream is aware of this [0] and have merged support for PCRE2
[1] into the latest upstream version 7.0 which hopefully will be in
Debian before the bookworm release. I will make sure to update the
dependencies as soon as this hits unstable, so you will have one package
less to worry about.

Cheers
Sascha


[0] https://redmine.openinfosecfoundation.org/issues/3194
[1] https://github.com/OISF/suricata/pull/6414

Bug#1000165: xdmf FTBFS with more than one supported python3 version

[Adrian Bunk]

Source: xdmf
Version: 3.0+git20190531-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=xdmf=3.0%2Bgit20190531-8%2Bb1

...
   dh_missing -a -O--buildsystem=cmake
dh_missing: warning: usr/lib/python3.10/xdmf/Xdmf.py exists in debian/tmp but 
is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/Xdmf.py")
dh_missing: warning: usr/lib/python3.10/xdmf/XdmfCore.py exists in debian/tmp 
but is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/XdmfCore.py")
dh_missing: warning: usr/lib/python3.10/xdmf/XdmfUtils.py exists in debian/tmp 
but is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/XdmfUtils.py")
dh_missing: warning: usr/lib/python3.10/xdmf/__Xdmf.so exists in debian/tmp but 
is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/__Xdmf.so")
dh_missing: warning: usr/lib/python3.10/xdmf/__XdmfCore.so exists in debian/tmp 
but is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/__XdmfCore.so")
dh_missing: warning: usr/lib/python3.10/xdmf/__XdmfUtils.so exists in 
debian/tmp but is not installed to anywhere (related file: 
"debian/tmp/usr/lib/python3.9/xdmf/__XdmfUtils.so")
dh_missing: error: missing files, aborting

Bug#1000164: ITP: qt6-webchannel -- Qt 6 WebChannel module

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-webchannel
  Version : 6.2.1
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-3 with Qt-1.0 exception
  Programming Lang: C++
  Description : Qt 6 WebChannel module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

The Qt WebChannel module offers Qt applications a seamless way to
publish QObjects for interaction with HTML/JavaScript clients.

Bug#1000000: fixed in phast 1.6+dfsg-2

[Adrian Bunk]

On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote:
>...
> For the Debian package you could drop use_debian_packaged_libpcre.patch and
> use the embedded copy to not block the prce3 removal in Debian.

As a general comment, this would be a lot worse than keeping pcre3.

If any copy of this library should be used at all in bookworm,
it should be provided by src:pcre3.

Switching from src:pcre3 to an older vendored copy would likely create 
additional security vulnerabilities for our users,[1] even with only one 
user in bookworm shipping it security supportable in src:pcre3 would be 
better than hiding vulnerabilities through vendoring.

> Kind Regards,
> 
> Bas

cu
Adrian

[1] https://security-tracker.debian.org/tracker/source-package/pcre3

Bug#1000163: phast FTBFS: pcre.h: No such file or directory

[Adrian Bunk]

Source: phast
Version: 1.6+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=phast=1.6%2Bdfsg-2

...
/<>/src/../include/phast/stringsplus.h:27:10: fatal error: pcre.h: 
No such file or directory
   27 | #include 
  |  ^~~~
compilation terminated.
make[4]: *** [Makefile:13: phast_list_of_lists.o] Error 1

Bug#997877:

[Michael Hudson-Doyle]

I think an update to 3.3.5 will fix this. I have no idea how hard mailman3
upstream updates are :)

Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop

[Jamie Zawinski]

I don't understand why you are having trouble logging with 6.02. Did you launch 
it as xscreensaver -v -log log.txt?

Investigating this in 5.x will not be helpful, because the flow of control is 
completely different with 6.x's new security model.

Bug#1000162: ima-evm-utils: FTBFS with no internet connection

[Bastian Germann]

Source: ima-evm-utils
Severity: serious
Version: 1.3.2-2.1

Hey,

Your package fails to build from scratch in an environment with no internect 
connection.
Please check the buildd logs for this.

Thanks,
Bastian

Bug#999632: r-bioc-isoformswitchanalyzer FTBFS: ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available

[Steffen Möller]

On 14.11.21 08:47, Andreas Tille wrote:

Control: blocked -1 by 995252

Hi Steffen


ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available for package 
‘IsoformSwitchAnalyzeR’

r-bioc-tximeta is in Debian and just needs to be mentioned in
Build-Depends.  However, Git seems not to be up to date so please push.

Seems like we have a race condition. I dumped my local one and
routine-updated what was in salsa.


What is the status of r-bioc-drimseq?  I have not found it in new neither
did I found any mentioning it on the maintainers list.


g...@salsa.debian.org:r-pkg-team/r-bioc-drimseq.git

Seems like I had not uploaded it. Just upgraded it to a newer version
and sent it away.


PS: Please use a chroot when building your packages.


I typically do. For the ones with build dependencies in the NEW queue I
once had my own local repository but at some point stopped doing that.

Steffen

Bug#1000147: radicale: Non-working init script

[Jonas Smedegaard]

Quoting Elliott Mitchell (2021-11-18 20:54:58)
> On Thu, Nov 18, 2021 at 07:26:50PM +0100, Jonas Smedegaard wrote:
> > Quoting Elliott Mitchell (2021-11-18 16:45:58)
> > > Appears the documentation for `start-stop-daemon` is misleading or 
> > > wrong, and the "--exec" option is needed if "--startas" is given a 
> > > pathname.
> > 
> > This sounds like a bug in start-stop-daemon: please report against 
> > the package dpkg which seems to provide start-stop-daemon, and 
> > provide more details on how it fails to work.
> > 
> > > Might be this is an issue for me, but not others since the 
> > > "radicale" user's shell had been set to `/bin/false`.  As this is 
> > > strongly recommended security hardening, the radicale package 
> > > should work with a system setup this way.
> > 
> > Not sure what you are saying here, but seems a separate issue (even 
> > if affecting the other one).
> > 
> > If you mean to say that using shell /usr/sbin/nologin for radicale 
> > account is strongly discouraged, then please file a separate 
> > bugreport about that - preferably with more details, as that is not 
> > obvious to me.
> > 
> > Also, please file a separate bugreport if you believe radicale 
> > should work with custom shell setting and fails to do so (but works 
> > without such change).  Because I agree that should work, and am 
> > surprised if it doesn't (but I don't use sysV init system myself so 
> > cannot easily test).
> 
> My guess is this could be a documentation problem for 
> `start-stop-daemon`.
> 
> Based upon observed behavior, I suspect "--exec" changes to the 
> appropriate user and then does an execve() of the specified 
> executeable. Whereas "--startas" is instead executing the shell of the 
> specified user with arguments as specified.
> 
> The latter requires the shell be valid.  Unless there is an 
> overwhelmingly important reason for the radicale user's shell to be 
> valid, it should instead be `/bin/false`.  This though requires use of 
> "--exec".
> 
> Since Radicale appears to function properly when started with "--exec" 
> that seems a vastly superior approach (doesn't result in security 
> concerns).

Thanks for the additional info.

You continue posting to same bugreport despite my urging you to file as 
a separate one.  I take that as indication that you do not consider this 
relevant to track on its own, and I will respect that.


 - Jonas

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

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

signature.asc
Description: signature

Bug#984401: vtk7: ftbfs with GCC-11

[Steve Langasek]

Package: vtk7
Version: 7.1.1+dfsg2-10
Followup-For: Bug #984401
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Please find attached a patch which has been uploaded to Ubuntu to fix this
build failure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch 
vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch
--- vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch1969-12-31 
16:00:00.0 -0800
+++ vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch2021-11-18 
09:30:28.0 -0800
@@ -0,0 +1,53 @@
+Description: gcc-11 compatibility
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/984401
+Last-Update: 2021-11-18
+
+Index: vtk7-7.1.1+dfsg2/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
+===
+--- vtk7-7.1.1+dfsg2.orig/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
 vtk7-7.1.1+dfsg2/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
+@@ -52,7 +52,7 @@
+ XdmfErrorMessage("Cannot Receive Message of Length = " << 
Msg->Length);
+ return(XDMF_FAIL);
+ }
+-if(Msg->Data <= 0 ){
++if(!Msg->Data){
+ XdmfErrorMessage("Cannot Receive Message into Data Buffer = " << 
Msg->Length);
+ return(XDMF_FAIL);
+ }
+@@ -66,7 +66,7 @@
+ XdmfErrorMessage("Cannot Send Message of Length = " << Msg->Length);
+ return(XDMF_FAIL);
+ }
+-if(Msg->Data <= 0 ){
++if(!Msg->Data){
+ XdmfErrorMessage("Cannot Send Message from Data Buffer = " << 
Msg->Length);
+ return(XDMF_FAIL);
+ }
+Index: vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchyPrivate.h
+===
+--- vtk7-7.1.1+dfsg2.orig/Rendering/Label/vtkLabelHierarchyPrivate.h
 vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchyPrivate.h
+@@ -66,7 +66,7 @@
+ {
+ }
+ 
+-bool operator () ( const vtkIdType& a, const vtkIdType& b )
++bool operator () ( const vtkIdType& a, const vtkIdType& b ) const
+ {
+   if (0 == this->Hierarchy)
+   {
+Index: vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchy.cxx
+===
+--- vtk7-7.1.1+dfsg2.orig/Rendering/Label/vtkLabelHierarchy.cxx
 vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchy.cxx
+@@ -525,7 +525,7 @@
+   {
+   public:
+ bool operator()(const vtkHierarchyNode & a,
+-const vtkHierarchyNode & b)
++const vtkHierarchyNode & b) const
+ {
+   if (a.Level != b.Level)
+   {
diff -Nru vtk7-7.1.1+dfsg2/debian/patches/series 
vtk7-7.1.1+dfsg2/debian/patches/series
--- vtk7-7.1.1+dfsg2/debian/patches/series  2020-12-15 11:51:51.0 
-0800
+++ vtk7-7.1.1+dfsg2/debian/patches/series  2021-11-18 09:28:09.0 
-0800
@@ -23,3 +23,4 @@
 mysq8_my_bool.patch
 3edc0de2b04ae1e100c229e592d6b9fa94f2915a.patch
 581d9eb874b2b80a3fb21c739a96fa6f955ffb5e.patch
+gcc-11.patch

Bug#1000161: [RFP] himalaya - A Command Line Interface for Mail Management

[Lionel Dricot]

Package: wnpp
Severity: wishlist

Himalaya is a command line interface to manage emails, providing an easy to
configure CLI API to handle emails over multiple backends.

homepage: https://github.com/soywod/himalaya

license : BSD 3-clause "revised"

Bug#1000160: firmware: failed to load nouveau/nvc3_fuc084 and nvc3_fuc084d

[Tomas Senabre]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.17-1
Severity: normal
Tags: upstream

I continually receive failure messages to load the firmware:

[ 4138.126756] nouveau :03:00.0: firmware: failed to load
nouveau/nvc3_fuc084 (-2)
[ 4138.126762] nouveau :03:00.0: Direct firmware load for
nouveau/nvc3_fuc084 failed with error -2
[ 4138.126771] nouveau :03:00.0: firmware: failed to load
nouveau/nvc3_fuc084d (-2)
[ 4138.126773] nouveau :03:00.0: Direct firmware load for
nouveau/nvc3_fuc084d failed with error -2
[ 4138.126774] nouveau :03:00.0: msvld: unable to load firmware data
[ 4138.126776] nouveau :03:00.0: msvld: init failed, -19


System description:

~$ dmesg | grep nvidia
[5.758958] audit: type=1400 audit(1637254492.947:7): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=737
comm="apparmor_parser"
[5.758962] audit: type=1400 audit(1637254492.947:8): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod"
pid=737 comm="apparmor_parser"

~$ lspci | grep VGA
03:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000]
(rev a1)

OS: Debian GNU/Linux 11 (bullseye) x86_64
Host: 0606AD5 ThinkStation S30
Kernel: 5.10.0-9-amd64
Resolution: 1920x1200, 1680x1050 Twin Display
DE: Xfce 4.16
CPU: Intel Xeon E5-1607 0 (4) @ 3.000GHz
GPU: NVIDIA Quadro 2000
Memory: 3698MiB / 32064MiB

Thanks for your help
Tomas





-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF106GL [Quadro 
2000] [10de:0dd8] (rev a1)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 673 Jul 17 18:33 72-wacom-options.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.70-1 (2021-09-30)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 77039 Nov 18 20:08 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 6.147] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[ 6.147] Build Operating System: linux Debian
[ 6.147] Current Operating System: Linux luna 5.10.0-9-amd64 #1 SMP Debian 
5.10.70-1 (2021-09-30) x86_64
[ 6.147] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-9-amd64 
root=UUID=d1e1a232-915b-4a5c-9f1b-1c03f1688679 ro quiet
[ 6.147] Build Date: 13 April 2021  04:07:31PM
[ 6.147] xorg-server 2:1.20.11-1 (https://www.debian.org/support) 
[ 6.147] Current version of pixman: 0.40.0
[ 6.147]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 6.147] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 6.147] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 18 17:54:53 
2021
[ 6.153] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 6.153] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 6.161] (==) No Layout section.  Using the first Screen section.
[ 6.161] (==) No screen section available. Using defaults.
[ 6.161] (**) |-->Screen "Default Screen Section" (0)
[ 6.161] (**) |   |-->Monitor ""
[ 6.162] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 6.162] (==) Automatically adding devices
[ 6.162] (==) Automatically enabling devices
[ 6.162] (==) Automatically adding GPU devices
[ 6.162] (==) Max clients allowed: 256, resource mask: 0x1f
[ 6.166] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 6.166]Entry deleted from font path.
[ 6.171] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 6.171] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 6.171] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 6.171] (II) Loader magic: 0x558b4f382e40
[ 6.171] (II) Module ABI versions:
[ 6.171]X.Org ANSI C Emulation: 0.4
[ 6.171]X.Org Video Driver: 24.1
[ 6.172]X.Org XInput 

Bug#989192: diffoscope: Differences in file lists are repeated at each depth level

[Chris Lamb]

tags 989192 + pending
thanks

Fixed in Git, pending upload:

  https://salsa.debian.org/reproducible-builds/diffoscope/commit/


Regards,

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

Bug#1000147: radicale: Non-working init script

[Elliott Mitchell]

On Thu, Nov 18, 2021 at 07:26:50PM +0100, Jonas Smedegaard wrote:
> 
> Quoting Elliott Mitchell (2021-11-18 16:45:58)
> > Appears the documentation for `start-stop-daemon` is misleading or 
> > wrong, and the "--exec" option is needed if "--startas" is given a 
> > pathname.
> 
> This sounds like a bug in start-stop-daemon: please report against the 
> package dpkg which seems to provide start-stop-daemon, and provide more 
> details on how it fails to work.
> 
> 
> > Might be this is an issue for me, but not others since the "radicale" 
> > user's shell had been set to `/bin/false`.  As this is strongly 
> > recommended security hardening, the radicale package should work with 
> > a system setup this way.
> 
> Not sure what you are saying here, but seems a separate issue (even if 
> affecting the other one).
> 
> If you mean to say that using shell /usr/sbin/nologin for radicale 
> account is strongly discouraged, then please file a separate bugreport 
> about that - preferably with more details, as that is not obvious to me.
> 
> Also, please file a separate bugreport if you believe radicale should 
> work with custom shell setting and fails to do so (but works without 
> such change).  Because I agree that should work, and am surprised if it 
> doesn't (but I don't use sysV init system myself so cannot easily test).

My guess is this could be a documentation problem for
`start-stop-daemon`.

Based upon observed behavior, I suspect "--exec" changes to the
appropriate user and then does an execve() of the specified executeable.
Whereas "--startas" is instead executing the shell of the specified
user with arguments as specified.

The latter requires the shell be valid.  Unless there is an
overwhelmingly important reason for the radicale user's shell to be
valid, it should instead be `/bin/false`.  This though requires use of
"--exec".

Since Radicale appears to function properly when started with "--exec"
that seems a vastly superior approach (doesn't result in security
concerns).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#981139: #981139 should be fixed downstream

[Pete Heist]

This should be the right fix to pull in. I'd also be glad to see it:

https://github.com/FRRouting/frr/pull/8876

Bug#1000159: dnsproxy listen unnecessary UDP port

[Marcos Talau]

Package: dnsproxy
Version: 1.16-0.1
Severity: important
X-Debbugs-Cc: mar...@talau.info
Control: forwarded -1 https://github.com/awaw/dnsproxy/issues/1

Hi there,

When dnsproxy starts it unnecessary listens to a random UDP port on all
interfaces. This opened port is not required to dnsproxy do their job.
If someone connects on that port it's possible to send unwanted DNS
answers to dnsproxy, these answers can be forwarded to the client, but
an attacker needs to know the DNS ID used by the client and the DNS ID
used by dnsproxy.


Regards,
mt


signature.asc
Description: PGP signature

Bug#993301: prototypejs: FTBFS

[Bastien ROUCARIES]

Le mer. 17 nov. 2021 à 13:02, Andreas Beckmann  a écrit :

> Control: tag -1 moreinfo
>
> On Mon, 30 Aug 2021 12:23:22 + "=?utf-8?q?Bastien_Roucari=C3=A8s?="
>  wrote:
> > Source: prototypejs
> > Severity: serious
> > Justification: 4
> >
> > Dear Maintainer,
> >
> > The source is https://github.com/prototypejs/prototype/tree/master and
> need
> > rake for building...
> >
> > So FTBFS
>
> I can rebuild prototypejs/1.7.1-3.1 in sid and bullseye without
> problems. What errors do you encounter?
>

Yes but this not prefered source of modification...

> There is a new upstream release 1.7.3 (from 2015) available on github.
> Does that version fail?
>
> And how is this related to rake?
>
Sée thé salsa tree un order to understand why i need rake

>
>
> Andreas
>

Bug#1000157: pampi FTBFS: pyuic5: No such file or directory

[Adrian Bunk]

Source: pampi
Version: 1.1+dfsg1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pampi=all=1.1%2Bdfsg1-2=1637082767=0

...
make[3]: Entering directory '/<>/pampi/libs'
pyuic5 main.ui -o ui_main.py
make[3]: pyuic5: No such file or directory
make[3]: *** [Makefile:11: ui_main.py] Error 127

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Sven Joachim]

On 2021-11-17 20:21 -0500, Thomas Dickey wrote:

> On Wed, Nov 17, 2021 at 05:16:52PM +0100, Sven Joachim wrote:
>> Control: reassign -1 ncurses-base 6.3-1
>>
>> On 2021-11-17 01:11 +0100, Josh Triplett wrote:
>>
>> > I just confirmed that upgrading *only* ncurses-base causes the issue to
>> > appear, and downgrading *only* ncurses-base causes the issue to
>> > disappear.
>>
>> Thanks, that makes sense.  For me it is broken in bookworm already, but
>> others have seen it only after upgrading ncurses to 6.3-1. For the
>> reference, the relevant change in ncurses is this:
>>
>> ,
>> | 20210925
>> |+ add smglp and smgrp to vt420+lrmm, to provide useful data for the
>> |  "tabs" +m option -TD
>> `
>
> yes - I implemented left/right margins in xterm in 2012 (patch #279)
> (not quite as long ago as repeat_char).
>
> however, the left/right margin feature was present earlier:
>
> REV:1.730   terminfo.src2019/05/18 18:58:45   tom
>
>add vt420 left/right margins for xterm-new
>
> +# Left/right margins are supported in xterm since patch #279 (2012/05/10)
> +vt420+lrmm|VT420 left/right margins,
> + mgc=\E[?69l, smglr=\E[?69h\E[%i%p1%d;%p2%ds,
>
>> The neovim developers have pushed a workaround:
>>
>> https://github.com/neovim/neovim/issues/16238
>
> ...which seems enough to fix their issue
> (they're checking if $XTERM_VERSION is set)

Aha, this also explains why I experienced the problem even with older
ncurses-base, I had started gnome-terminal from xterm!

> Since the feature was already present in a different form,
> it seems that neovim is the only widespread user of this.

Quite likely.

>> I am not quite sure what to do with this in ncurses.  As long as the
>> problem only affects neovim and VTE based terminal emulators I am
>> inclined to ignore it, but if it turns out to be more widespread I could
>> back out the new feature, like I did in #933053.
>
> I don't see that it's necessary.

Yes, I think a versioned Breaks against neovim should be sufficient,
once a fixed neovim package is available.

> By the way, #933053 is kind of stale - likely there's no sufficiently
> old systems with broken vte libraries to appease.

Unfortunately there is at least one unfixed terminal emulator around,
#930037 and the corresponding upstream bug in mosh are still open.

Cheers,
   Sven

Bug#998156: contains non-DFSG-free files

[Ryan Kavanagh]

On Thu, Nov 18, 2021 at 12:44:21PM -0600, Henry Cejtin wrote:
> Has there ben any progress on getting MLton packaged for Debian?

Yes. The sticking point is that mlton requires itself or smlnj to
compile itself. The current version of mlton in the archives has been
uninstallable for years, so I've been trying to use smlnj to bootstrap
mlton. This has required some changes to the source and it's still not
completely there.

> Is there anything I can do to help?

The right path forward is probably for me to file an issue against the
Github mlton project, and then we can discuss fixing the
smlnj-to-bootstrap-mlton issues there.

Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#999889: rsyslog: init script is missing

[Kacper Gutowski]

Today I noticed rsyslogd runs linked with deleted libraries after 
upgrade, so I tried to restart it the standard way:


$ sudo service rsyslog restart
rsyslog: unrecognized service

This really should have been mentioned upfront in the NEWS.Debian file 
instead of just silently breaking things for everyone who doesn't use 
systemd with no single word of explanation. But as I just discovered by 
a happy accent, the init script is now maintained separately in the 
orphan-sysvinit-scripts package. Thanks for the #998340 at least.


-k

Bug#1000148: lintian: improbable-bug-number-in-closes needs updating

[Mattia Rizzolo]

On Thu, Nov 18, 2021 at 10:37:51AM -0800, Felix Lechner wrote:
> Unfortunately, that would make Lintian's output variable over time. Do
> we really need the upper bound (or the whole tag)?

I don't care about the moving output, but I do find the tag useful.

It saved me several times when I obviously typoed a bug number, so
please do keep it.

If I had to suggest a new static upper bound I'd recommend 1.5M though,
not 2M ^^

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#998156: contains non-DFSG-free files

[Henry Cejtin]

Has there ben any progress on getting MLton packaged for Debian?
Is there anything I can do to help?

I haven't seen anything since Matthew Fluet's response.

On Sat, Oct 30, 2021 at 10:39 PM Ryan Kavanagh  wrote:
>
> Package: mlton
> Version: 20100608-5.1
> Severity: serious
> Tags: upstream
> X-Debbugs-Cc: r...@debian.org
>
> Since at least oldoldoldstable, the mlton sources have included non-free 
> files.
> In particular, the tarball lib/ckit-lib/ckit.tgz contains the files
> ckit/src/parser/util/error.sml and ckit/src/parser/util/error-sig.sml.  These
> files are:
>
> (*
>  * Copyright (c) 1996 by Satish Chandra, Brad Richards, Mark D. Hill,
>  * James R. Larus, and David A. Wood.
>  *
>  * Teapot is distributed under the following conditions:
>  *
>  * You may make copies of Teapot for your own use and modify those copies.
>  *
>  * All copies of Teapot must retain our names and copyright notice.
>  *
>  * You may not sell Teapot or distributed Teapot in conjunction with a
>  * commercial product or service without the expressed written consent of
>  * the copyright holders.
>  *
>  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
>  * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
>  *
>  *)
>
> The restriction on distribution in conjunction with a commercial product
> or service is in violation of point 6 of the DFSG.
>
> See also the related bug against SML/NJ:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998154
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mlton depends on:
> ii  mlton-compiler  20130715-3
> ii  mlton-doc   20130715-3
> ii  mlton-tools 20130715-3
>
> mlton recommends no packages.
>
> mlton suggests no packages.
>
> -- no debconf information
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#1000148: lintian: improbable-bug-number-in-closes needs updating

[Felix Lechner]

Hi,

On Thu, Nov 18, 2021 at 8:42 AM Christoph Berg  wrote:
>
> bug numbers are growing mostly linearly

Perhaps not surprising, people file slightly more bugs when the
economy is weak. (See chart in the attachments.)

> base the warning on the current date.

Unfortunately, that would make Lintian's output variable over time. Do
we really need the upper bound (or the whole tag)?

Kind regards
Felix Lechner


Bug Number vs Filing Date.pdf
Description: Adobe PDF document
Filing Date,Bug Number
11/12/99,"50,004"
06/07/01,"100,000"
06/14/02,"150,000"
07/04/03,"200,000"
05/20/04,"250,000"
03/17/05,"300,000"
01/26/06,"350,000"
11/23/06,"400,000"
11/07/07,"450,000"
09/24/08,"500,000"
10/06/09,"550,000"
10/12/10,"600,000"
11/25/11,"650,000"
02/07/13,"700,000"
05/31/14,"750,000"
09/25/15,"800,000"
01/03/17,"850,000"
05/24/18,"900,000"
01/28/20,"950,000"
11/18/21,"1,000,000"

Bug#995337: sssd-krb5: Please backport upstream patch fixing offline ccache creation

[Thomas Walker]

Hi maintainers... I wanted to give this a bump as it has been a couple of 
months.  At the time that I opened the request, sssd had not had an official 
releaese with this patch included but it is now present in 2.6.0 (and 2.6.1).

I can, of course, carry this patch internally if need be, but I was hoping that 
Debian would include it as smartcard based auth when in offline mode will not 
work without it (it creates a ccache for the user owned by root).

Thank you!

Bug#1000107: exim4: depends on obsolete pcre3 library

[Andreas Metzler]

On 2021-11-18 Matthew Vernon  wrote:
> Source: exim4
> Severity: important
> User: matthew-pcre...@debian.org
> Usertags: obsolete-pcre3

> Dear maintainer,

> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
[...]

This is fixed in upstream GIT master, the next upstream feature release
should include the fix, well in time for bookworm.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1000156: roundcube: XSS vulnerability in handling attachment filename extension in MIME type mismatch warnings

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security
Control: found -1 1.3.16+dfsg.1-1~deb10u1
Control: found -1 1.4.11+dfsg.1-4
Control: fixed -1 1.5.0+dfsg.1-1

In a recent post roundcube webmail upstream has announced the
following security fixes:

 * Fix XSS issue in handling attachment filename extension in mimetype
   mismatch warning
 * Fix possible SQL injection via some session variables

sid/bookworm's 1.5.0+dfsg.1-2 is not affected.  Upstream fixes for LTS
branches:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/faf99bf8a2b7b7562206fa047e8de652861e624a
  
https://github.com/roundcube/roundcubemail/commit/c8947ecb762d9e89c2091bda28d49002817263f1
1.3.x 
https://github.com/roundcube/roundcubemail/commit/7d7b1dfeff795390b69905ceb63d6391b5b0dfe7
  
https://github.com/roundcube/roundcubemail/commit/ee809bde2dcaa04857a919397808a7296681dcfa

-- 
Guilhem.

[0] 
https://roundcube.net/news/2021/11/12/security-updates-1.4.12-and-1.3.17-released


signature.asc
Description: PGP signature

Bug#1000155: O: pinpoint -- hacker-friendly presentation program

[Antonio Terceiro]

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

I'm orphaning the pinpoint package.

The package description is:
 Pinpoint is a simple presentation tool that uses a plain text file as input.
 It supports specifying the text position, styling the text, using images or
 videos as background for slides, embedding commands to be run on specific
 slides, a speaker view window, and other nice features.

There is no upstream development currently going on, and there are some
pretty bag bugs that happen from time to time (it's not easy to
reproduce them consistently).

I no longer use pinpoint, and don't have the motivation to work on it
anymore. I'm uploading the last bits I had done a long time ago, from
the last time I tried to use it.


signature.asc
Description: PGP signature

Bug#1000154: ITP: ruby-rantly -- Ruby Imperative Random Data Generator and Quickcheck

[Antonio Terceiro]

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

* Package name: ruby-rantly
  Version : 2.0.0
  Upstream Author : Ana María Martínez Gómez, Howard Yeh, Anthony Bargnesi, 
Eric Bischoff

* URL : https://github.com/rantly-rb/rantly
* License : MIT (Expat)
  Programming Lang: Ruby
  Description : Ruby Imperative Random Data Generator and Quickcheck

You can use Rantly to generate random test data, and use its Test::Unit
extension for property-based testing. Rantly is basically a recursive
descent interpreter, each of its method returns a random value of some
type (string, integer, float, etc.).  debian/control

I'm packaging this as a build dependency for a new version of
ruby-moneta. It seems like a pretty useful library.


signature.asc
Description: PGP signature

Bug#996202: systemd - EFI Secure Boot for systemd-boot

[Julian Andres Klode]

On Thu, Nov 18, 2021 at 05:02:59PM +0100, Michael Biebl wrote:
> Am 18.11.21 um 16:58 schrieb Julian Andres Klode:
> > On Thu, Nov 18, 2021 at 04:26:47PM +0100, Michael Biebl wrote:
> > > 
> > > Am 18.11.21 um 15:21 schrieb Julian Andres Klode:
> > > > we have recently discussed the matter of systemd-boot in
> > > > an upstream shim review gathering.
> > > 
> > > Is this discussion public? Can you share it?
> > 
> > We unfortunately do not have a written record of it.
> 
> private cabal, eh :-)
> 
> > > > * systemd-boot does not use current ways of communicating with
> > > > shim
> > > > 
> > > > * There was some concern over general quality
> > > 
> > > Has this been passed along to the systemd maintainers?
> > > If so, what's their take on this? If not, could you forward your
> > > findings/concerns to upstream, please?
> > 
> > It's not really my place, that's a discussion for other people
> > to have, and I don't have all the details.
> 
> Well, who if not you? I mean you said you are (part of) shim upstream?
> If you reject it, it would be good to actually have a bit more details then
> just meh, not going to happen.
> 
> That doesn't feel right.
> 

I understand how you feel, but I don't have anything to add at
the moment. I did not raise those two concerns, and I don't know
enough details to follow through on them.

I'm not sure if the people who have looked into it want to bother
actually proactively filing reports rather than wait for the situation
where a distro wants to have a grub-free, systemd-boot shim.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1000153: RM: python-gntp -- ROM; archived upstream; unused

[Jeroen Ploemen]

Package: ftp.debian.org
Severity: normal

Please remove python-gntp: archived upstream, no reverse (build-)
dependencies, low single digit popcon score.

Thanks!


pgpxdk5KcXi1S.pgp
Description: OpenPGP digital signature

Bug#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Timo Aaltonen]

Source: cyrus-sasl2
Severity: important

Hi

As you can see from the CI results

https://ci.debian.net/packages/f/freeipa/unstable/amd64/

since 2021-11-04 and up the tests fail on installing the client with 
this error:


Cannot connect to the server due to generic error: Insufficient access: 
SASL(-4): no mechanism available: No worthy mechs found (Unknown 
authentication method)


I narrowed down the changed packages and the list includes 
libsasl2-modules-gssapi-mit. I verified that upgrading this package (and 
libsasl2-modules) broke my test system with the same error, everything 
else was upgraded earlier to current sid and that state worked fine.


Since the changes to cyrus-sasl2 can't be causing this, maybe there's 
some issue with building it with current gcc? I'll try building it with 
gcc-10 next.



--
t

Bug#999985: pound: depends on obsolete pcre3 library

[Carsten Leonhardt]

Hi Robert,

apparently the pcre library (named pcre3 in Debian) is obsolete and it
is recommended to switch to pcre2. See the Debian bug report below.

"Bookworm" is the next Debian release, which is planned for 2023. "In
time for the release of Bookworm" would probably mean a removal from the
development version of Debian in 2022. As Ubuntu and probably other
Debian derivatives base themselves on Debian's development version, this
might affect those distributions earlier than 2023.

Regards

Carsten


Matthew Vernon  writes:

> Source: pound
> Severity: important
> User: matthew-pcre...@debian.org
> Usertags: obsolete-pcre3
>
> Dear maintainer,
>
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
>
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/
>
> Many large projects that use PCRE have made the switch now (e.g. git,
> php); it does involve some work, but we are now at the stage where
> PCRE3 should not be used, particularly if it might ever be exposed to
> untrusted input.
>
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00176.html
>
> Regards,
>
> Matthew [0] Historical reasons mean that old PCRE is packaged as
> pcre3 in Debian 

Bug#1000151: certbot.service: please provide some logs in journal

[Alexandre Rossi]

Package: python-certbot
Version: 1.18.0-1
Severity: minor
Tags: patch

Dear Maintainer,

certbot.service leaves no info in the journal except for errors.

oct. 26 00:44:01 volyova systemd[1]: Starting Certbot...
oct. 26 00:44:03 volyova systemd[1]: certbot.service: Succeeded.

Certificate not due for renewal is also an interesting info.

nov. 16 00:44:01 volyova systemd[1]: Starting Certbot...
nov. 16 00:44:02 volyova certbot[772070]: Saving debug log to 
/var/log/letsencrypt/letsencrypt.log
nov. 16 00:44:02 volyova certbot[772070]: - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - -
nov. 16 00:44:02 volyova certbot[772070]: Processing 
/etc/letsencrypt/renewal/example.net.conf
nov. 16 00:44:02 volyova certbot[772070]: - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - -
nov. 16 00:44:02 volyova certbot[772070]: Cert not yet due for renewal
nov. 16 00:44:02 volyova certbot[772070]: - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - -
nov. 16 00:44:02 volyova certbot[772070]: The following certificates are not 
due for renewal yet:
nov. 16 00:44:02 volyova certbot[772070]:   
/etc/letsencrypt/live/example.net/fullchain.pem expires on 2022-02-06 (skipped)
nov. 16 00:44:02 volyova certbot[772070]: No renewals were attempted.
nov. 16 00:44:02 volyova certbot[772070]: - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - -

The patch:

--- a/debian/certbot.service
+++ b/debian/certbot.service
@@ -4,5 +4,5 @@ 
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
 Documentation=https://certbot.eff.org/docs
 [Service]
 Type=oneshot
-ExecStart=/usr/bin/certbot -q renew
+ExecStart=/usr/bin/certbot --non-interactive renew
 PrivateTmp=true

Thanks,

Alex

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

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

Bug#1000150: Spurious message 'cannot open folder tags:/'

[Oliver Sander]

I forgot to mention that the following message are printed
at the command line when the message widget opens:

[17::40:54.472] unknown: PostingDB::open MDB_NOTFOUND: No matching key/data 
pair found
[17::40:54.472] unknown: PositionDB::open MDB_NOTFOUND: No matching key/data 
pair found
[17::40:54.472] unknown: DocumentDB::open docterms MDB_NOTFOUND: No matching 
key/data pair found
[17::40:54.472] unknown: DocumentDB::open docfilenameterms MDB_NOTFOUND: No 
matching key/data pair found
[17::40:54.472] unknown: DocumentDB::open docxatrrterms MDB_NOTFOUND: No 
matching key/data pair found
[17::40:54.472] unknown: IdTreeDB::open MDB_NOTFOUND: No matching key/data pair 
found
[17::40:54.472] unknown: IdFilenameDB::open MDB_NOTFOUND: No matching key/data 
pair found
[17::40:54.472] unknown: DocumentTimeDB::open MDB_NOTFOUND: No matching 
key/data pair found
[17::40:54.472] unknown: DocumentDataDB::open MDB_NOTFOUND: No matching 
key/data pair found
[17::40:54.472] unknown: DocumentIdDB::open indexingleveldb MDB_NOTFOUND: No 
matching key/data pair found
[17::40:54.472] unknown: DocumentIdDB::open failediddb MDB_NOTFOUND: No 
matching key/data pair found
[17::40:54.472] unknown: MTimeDB::open MDB_NOTFOUND: No matching key/data pair 
found
[17::40:54.472] unknown: dbis is invalid
[17::40:54.472] unknown: tag fetch failed: "Failed to open the database"
[17::40:54.472] unknown: "tags:/" list() invalid url
[17::40:54.472] unknown: "Ordner tags:/ lässt sich nicht öffnen."



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#876201: ITA: dnsproxy -- proxy for DNS queries

[Marcos Talau]

retitle 876201 ITA: dnsproxy -- proxy for DNS queries
owner 876201 Marcos Talau 


signature.asc
Description: PGP signature

Bug#999588: cpufetch: Floating point exception

[Axel Beckert]

Hi,

clay stan wrote:
> Axel Beckert  于2021年11月13日周六 上午5:39写道：
> > On one Xen DomU (i.e. a Xen guest VM; not the system I'm writing this
> > bug report on) running Debian Testing, I get the following error when
> > running cpufetch:
> >
> > # cpufetch
> > Floating point exception
[…]
> I have updated this package to the latest upstream version:
> 1.0+git20211101+a5b321a9668f-3
> Can you test it again and tell me the result? thanks

Well, this is weird and might have been like this before, but if so, I
didn't notice it:

It seems to be random if it works or crashes with a Floating point
exception. So, no, not really fixed although it sometimes seems so.

Some examples in chronological order:

As root:

# cpufetch

   
 

  Name: 
 Intel Core i7 920
  
Microarchitecture: Nehalem
  Technology:   
 45nm
  Max Frequency:
 Unknown
  Cores:
 1 cores (HT disabled)
  AVX:  
 No
  FMA:  
 No
  L1i Size: 
 32KB
  L1d Size: 
 32KB
  L2 Size:  
 256KB
  L3 Size:  
 8MB
  Peak Performance: 
 Unknown
  
  
   
 
# cpufetch --style legacy
Floating point exception
# cpufetch --style legacy

   ###@
   ##@##@
  ###@  ###@
  ##@ ###@Name: 
 Intel Core i7 920
 ##@ ##@  
Microarchitecture: Nehalem
 ##@ ##@  Technology:   
 45nm
  @##@##@##@  Max Frequency:
 Unknown
#@   ##@   @   #@   #@##@##@  Cores:
 1 cores (HT disabled)
   #@##@   ##@##@  ##@###@  ###@  ##@##@  AVX:  
 No
  #@ ##@   ##@##@  ##@##@##@  ##@   ##@   FMA:  
 No
 #@  ##@   ##@##@  ##@#@  ##@ ###@L1i Size: 
 32KB
 #@  ##@   ##@##@  ##@##@ ##@   @ L1d Size: 
 32KB
 #@   #@   ##@##@   @  @   #@  ##@L2 Size:  
 256KB
 ##@  L3 Size:  
 8MB
  ##@ Peak Performance: 
 Unknown
  ###@###@
@   #@
  #@   ###@
  ##@
#

As user:

$ cpufetch
[1]31108 floating point exception  cpufetch
$ cpufetch

  
  
  
  Name: 
 Intel Core i7 920
  
Microarchitecture: Nehalem
  Technology:   
 45nm
  Max Frequency:
 Unknown
  Cores:
 1 cores (HT disabled)
  AVX:  
 No
  FMA:  
 No
  L1i Size: 
 32KB
  L1d Size: 
 32KB
  L2 Size:  
 256KB
  L3 Size:  
 8MB
  Peak 

Bug#1000140: Acknowledgement (ruby-moneta: FTBFS: mysqld fails to start)

[Antonio Terceiro]

Control: retitle -1 ruby-moneta: FTBFS: mysqld fails to start on tmpfs
Control: severity -1 important

I perceived that this is triggered by my sbuild/schroot setup building
packages with a tmpfs overlay (union-overlay-directory=/dev/shm), so
this does not happen always. I'm thus downgrading the severity of this
bug.


signature.asc
Description: PGP signature

Bug#1000147: radicale: Non-working init script

[Jonas Smedegaard]

Control: retitle -1 radicale: sysV init script broken: option --daemon not 
supported

Hi Elliott,

Quoting Elliott Mitchell (2021-11-18 16:45:58)
> The init script `/etc/init.d/radicale` which is included with the 
> 3.0.6-3 package failed to start Radicale for me.
> 
> Radicale's "--daemon" option was apparently removed with 3.0.6-3.
> Attempting to use the "--daemon" option resulted in an error.
> `start-stop-daemon`'s "-b" option was able to work around this.

Indeed: Support is gone since upstream release 3.0.0.

Thanks for the details - replaced now.

Since I don't use SysV init myself (I use uWSGI for Radicale), it would 
be helpful if you could test and give feedback here when the upcoming 
3.0.6-6 release enters Debian unstable (likely later today).  Please do 
tell if you need me to backport to bookworm or bullseye for your 
testing.


> Appears the documentation for `start-stop-daemon` is misleading or 
> wrong, and the "--exec" option is needed if "--startas" is given a 
> pathname.

This sounds like a bug in start-stop-daemon: please report against the 
package dpkg which seems to provide start-stop-daemon, and provide more 
details on how it fails to work.


> Might be this is an issue for me, but not others since the "radicale" 
> user's shell had been set to `/bin/false`.  As this is strongly 
> recommended security hardening, the radicale package should work with 
> a system setup this way.

Not sure what you are saying here, but seems a separate issue (even if 
affecting the other one).

If you mean to say that using shell /usr/sbin/nologin for radicale 
account is strongly discouraged, then please file a separate bugreport 
about that - preferably with more details, as that is not obvious to me.

Also, please file a separate bugreport if you believe radicale should 
work with custom shell setting and fails to do so (but works without 
such change).  Because I agree that should work, and am surprised if it 
doesn't (but I don't use sysV init system myself so cannot easily test).


Thanks for your bugreport,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1000148: lintian: improbable-bug-number-in-closes needs updating

[Andrius Merkys]

On 2021-11-18 18:38, Christoph Berg wrote:
> The overengineered solution would be to exploit the fact that bug
> numbers are growing mostly linearly, and base the warning on the
> current date.

Fair point!

Andrius

Bug#914247: Please move library to /usr/lib

[Simon McVittie]

Control: tags -1 + trixie

On Tue, 20 Nov 2018 at 22:38:21 +0100, Michael Biebl wrote:
> since late-mounted /usr is no longer supported, the artifical split
> between /lib and /usr/lib no longer is really useful.
> Therefor please consider moving the libraries to /usr/lib.

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 please
don't make this change at the moment: there's a risk of it disrupting
the transition to merged-/usr.

Thanks,
smcv

Bug#1000150: Spurious message 'cannot open folder tags:/'

[Oliver Sander]

Subject: kate: Spurious message 'cannot open folder tags:/'
Package: kate
Version: 4:21.08.2-1
Severity: normal

Disclaimer: this is most likely not a bug in kate, but I don't know
what package to assign this bug report to.  Please reassign appropriately.

Every time I open the 'file open' dialog in kate or a number of other
KDE apps such as kile or okular, I get a little error widget saying

  'Cannot open folder tags:/'

(My own translation: My German GUI actually says

  'Ordner tags:/ lässt sich nicht öffnen.'

)

If I click on the OK button the 'file open' dialog appears, and there
are no further problems.



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

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

Versions of packages kate depends on:
ii  kate5-data   4:21.08.2-1
ii  kio  5.86.0-1
ii  ktexteditor-katepart 5.86.0-1
ii  libc62.32-4
ii  libkf5bookmarks5 5.86.0-1
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configgui5 5.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5crash5 5.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5guiaddons5 5.86.0-1
ii  libkf5i18n5  5.86.0-1
ii  libkf5iconthemes55.86.0-1
ii  libkf5kiocore5   5.86.0-1
ii  libkf5kiofilewidgets55.86.0-1
ii  libkf5kiogui55.86.0-1
ii  libkf5kiowidgets55.86.0-1
ii  libkf5newstuff5  5.86.0-3
ii  libkf5parts5 5.86.0-1
ii  libkf5plasma55.86.0-1
ii  libkf5service-bin5.86.0-1
ii  libkf5service5   5.86.0-1
ii  libkf5syntaxhighlighting55.86.0-1
ii  libkf5texteditor55.86.0-1
ii  libkf5textwidgets5   5.86.0-1
ii  libkf5wallet-bin 5.86.0-1
ii  libkf5wallet55.86.0-1
ii  libkf5widgetsaddons5 5.86.0-1
ii  libkf5windowsystem5  5.86.0-1
ii  libkf5xmlgui55.86.0-1
ii  libkuserfeedbackcore11.0.0-3
ii  libkuserfeedbackwidgets1 1.0.0-3
ii  libqt5concurrent55.15.2+dfsg-12
ii  libqt5core5a 5.15.2+dfsg-12
ii  libqt5dbus5  5.15.2+dfsg-12
ii  libqt5gui5   5.15.2+dfsg-12
ii  libqt5sql5   5.15.2+dfsg-12
ii  libqt5widgets5   5.15.2+dfsg-12
ii  libqt5xml5   5.15.2+dfsg-12
ii  libstdc++6   11.2.0-10
ii  plasma-framework 5.86.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.86.0-1
ii  qml-module-qtquick-layouts   5.15.2+dfsg-8
ii  qml-module-qtquick2  5.15.2+dfsg-8

Versions of packages kate recommends:
ii  sonnet-plugins  5.86.0-1

Versions of packages kate suggests:
pn  darcs
pn  exuberant-ctags  
ii  git  1:2.33.0-1
ii  khelpcenter  4:21.08.0-1
ii  konsole-kpart4:21.08.2-1
pn  mercurial
ii  subversion   1.14.1-3+b1

-- no debconf information




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#999591: cpufetch: no output on a Thinkpad A31 running Sid i386

[Axel Beckert]

Hi,

clay stan wrote:
> I have updated this package to the latest upstream version:
> 1.0+git20211101+a5b321a9668f-3
> Can you test it again and tell me the result? thanks

This issue is still present:

$ dpkg -l cpufetch
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=>
iU  cpufetch   1.0+git20211101+a5b321a9668f-3 i386 Simple yet fancy 
CPU architecture fetchin>
$ cpufetch
$

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

Bug#1000082: glib2.0: depends on obsolete pcre3 library

[Matthew Vernon]

Hi,

On 18/11/2021 14:10, Simon McVittie wrote:

On Thu, 18 Nov 2021 at 11:49:04 +, Matthew Vernon wrote:

Your package still depends on the old, obsolete PCRE3[0] libraries
(i.e. libpcre3-dev).


As I'm sure you're already aware, in the case of GLib this is something
that needs to be resolved upstream, and is not appropriate to change as
a Debian patch.


I agree; I expect many of these bugs will need fixing upstream; but it's 
useful for Debian both to track our collective progress in getting to 
the point where we can ditch pcre3, and I think useful to raise 
awareness with upstreams about the need to move to pcre2.



Christian Persch has apparently done a proof-of-concept port to PCRE2, but
has not shared the result in any obvious way, so the next step would be for
someone to either persuade Christian to share the resulting branch, or
reimplement it.


It would be great if Christian could publish his branch for review (and 
hopefully incorporation into Glib) :) Do you think he'd likely respond 
positively to you asking him to do so?


Thanks,

Matthew

Bug#986591: attack of the hyphens

[Marc Lehmann]

Package: fbreader
Version: 0.12.10dfsg2-4
Followup-For: Bug #986591

Dear Maintainer,

in my case, the bug is caused by pango's auto-hyphenation feature (which
was adeed and enabled by default, causing a lot of similar breakage in
other software), but the underlying cause is using uninitialised memory,
which is why it is happening randomly.

I fixed this by initialising the PangoAnalysis struct in
zlibrary/ui/src/gtk/view/ZLGtkPaintContext.cpp, in the constrcutor
(ZLGtkPaintContext::ZLGtkPaintContext), by adding:

  myAnalysis = PangoAnalysis ({0});

This might be a problem elsewhere in the code, which I haven't
investigated, as with this fix, fbreader becomes usable again.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 fbreader depends on:
ii  libc62.31-13+deb11u2
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libsqlite3-0 3.34.1-3
ii  libstdc++6   10.2.1-6
ii  libzlcore0.130.12.10dfsg2-4
ii  libzltext0.130.12.10dfsg2-4
ii  libzlui-gtk  0.12.10dfsg2-4

Versions of packages fbreader recommends:
ii  sensible-utils  0.0.14

fbreader suggests no packages.

Bug#1000148: lintian: improbable-bug-number-in-closes needs updating

[Christoph Berg]

Re: Andrius Merkys
> improbable-bug-number-in-closes is false-positive now since bug numbers
> have just hit 100. The problem could be fixed (for example) by replacing
> 
> max-bug = 100
> 
> with
> 
> max-bug = 200
> 
> in /usr/share/lintian/data/changelog-file/bugs-number.

The overengineered solution would be to exploit the fact that bug
numbers are growing mostly linearly, and base the warning on the
current date.

https://wiki.debian.org/90thBugContest

Christoph

Bug#999588: cpufetch: Floating point exception

[clay stan]

Axel Beckert  于2021年11月13日周六 上午5:39写道：
>
> Package: cpufetch
> Version: 0.98-1+b1
>
> On one Xen DomU (i.e. a Xen guest VM; not the system I'm writing this
> bug report on) running Debian Testing, I get the following error when
> running cpufetch:
>
> # cpufetch
> Floating point exception
>
> Details about the CPU:
>
> # cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 26
> model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
> stepping: 5
> microcode   : 0x11
> cpu MHz : 2673.428
> cache size  : 8192 KB
> physical id : 0
> siblings: 1
> core id : 1
> cpu cores   : 1
> apicid  : 3
> initial apicid  : 3
> fpu : yes
> fpu_exception   : yes
> cpuid level : 11
> wp  : yes
> flags   : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr 
> sse sse2 ht syscall nx lm constant_tsc rep_good nopl cpuid tsc_known_freq pni 
> ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm dtherm ida
> bugs: null_seg cpu_meltdown spectre_v1 spectre_v2 
> spec_store_bypass l1tf mds swapgs itlb_multihit
> bogomips: 5346.81
> clflush size: 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
> Trying to strace the call:
>
> # strace cpufetch
> execve("/usr/bin/cpufetch", ["cpufetch"], 0x7fff81e838d0 /* 23 vars */) = 0
> brk(NULL)   = 0x55b19526b000
> openat(AT_FDCWD, "/usr/lib/olla/libolla.so", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\n\0\0\0\0\0\0"..., 
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=6728, ...}) = 0
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7fce2cea7000
> mmap(NULL, 2102064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
> 0x7fce2cca5000
> mprotect(0x7fce2cca7000, 2093056, PROT_NONE) = 0
> mmap(0x7fce2cea6000, 4096, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fce2cea6000
> close(3)= 0
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=80036, ...}) = 0
> mmap(NULL, 80036, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce2cc91000
> close(3)= 0
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3, 
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\177\2\0\0\0\0\0"..., 832) 
> = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1839168, ...}) = 0
> mmap(NULL, 1852480, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
> 0x7fce2cacc000
> mprotect(0x7fce2caf2000, 1658880, PROT_NONE) = 0
> mmap(0x7fce2caf2000, 1347584, PROT_READ|PROT_EXEC, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7fce2caf2000
> mmap(0x7fce2cc3b000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 
> 3, 0x16f000) = 0x7fce2cc3b000
> mmap(0x7fce2cc87000, 24576, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7fce2cc87000
> mmap(0x7fce2cc8d000, 13376, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce2cc8d000
> close(3)= 0
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> read(3, 
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\\21\0\0\0\0\0\0"..., 832) = 
> 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=18688, ...}) = 0
> mmap(NULL, 20752, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce2cac6000
> mmap(0x7fce2cac7000, 8192, PROT_READ|PROT_EXEC, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fce2cac7000
> mmap(0x7fce2cac9000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
> 0x3000) = 0x7fce2cac9000
> mmap(0x7fce2caca000, 8192, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fce2caca000
> close(3)= 0
> mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7fce2cac3000
> arch_prctl(ARCH_SET_FS, 0x7fce2cac3740) = 0
> mprotect(0x7fce2cc87000, 12288, PROT_READ) = 0
> mprotect(0x7fce2caca000, 4096, PROT_READ) = 0
> mprotect(0x55b1947b7000, 4096, PROT_READ) = 0
> mprotect(0x7fce2ced3000, 4096, PROT_READ) = 0
> munmap(0x7fce2cc91000, 80036)   = 0
> brk(NULL)   = 0x55b19526b000
> brk(0x55b19528c000) = 0x55b19528c000
> openat(AT_FDCWD, "/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq", 
> O_RDONLY) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
> read(3, "0\n", 8192)= 2
> close(3)= 0
> sched_setaffinity(0, 128, [0])  = 0
> --- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x55b1947aeb06} ---
> +++ 

Bug#999591: cpufetch: no output on a Thinkpad A31 running Sid i386

[clay stan]

I have updated this package to the latest upstream version:
1.0+git20211101+a5b321a9668f-3
Can you test it again and tell me the result? thanks

Kind regards
Clay Stan

Axel Beckert  于2021年11月13日周六 上午6:24写道：
>
> Package: cpufetch
> Version: 0.98-1+b1
>
> Hi,
>
> on one system running Debian Sid i386, a Thinkpad A31, cpufetch gives no
> output at all:
>
> 26/1/0 root@loadrunner:pts/4 23:06:54 [~] # cpufetch
> 27/1/0 root@loadrunner:pts/4 23:08:33 [~] # cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 15
> model   : 2
> model name  : Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz
> stepping: 4
> microcode   : 0x20
> cpu MHz : 1200.000
> cache size  : 512 KB
> physical id : 0
> siblings: 1
> core id : 0
> cpu cores   : 1
> apicid  : 0
> initial apicid  : 0
> fdiv_bug: no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 2
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov 
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts cpuid pti
> bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
> mds swapgs itlb_multihit
> bogomips: 3596.79
> clflush size: 64
> cache_alignment : 128
> address sizes   : 36 bits physical, 32 bits virtual
> power management:
>
> 28/0/0 root@loadrunner:pts/4 23:08:38 [~] # strace cpufetch
> execve("/usr/bin/cpufetch", ["cpufetch"], 0xbfc16420 /* 23 vars */) = 0
> brk(NULL)   = 0x240f000
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0xb7f34000
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=225163, ...}) = 0
> mmap2(NULL, 225163, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7efd000
> close(3)= 0
> openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", 
> O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> read(3, 
> "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\361\1\0004\0\0\0"..., 
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=2013884, ...}) = 0
> mmap2(NULL, 2023192, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d0f000
> mprotect(0xb7d2c000, 1880064, PROT_NONE) = 0
> mmap2(0xb7d2c000, 1409024, PROT_READ|PROT_EXEC, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0xb7d2c000
> mmap2(0xb7e84000, 466944, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
> 0x175000) = 0xb7e84000
> mmap2(0xb7ef7000, 16384, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0xb7ef7000
> mmap2(0xb7efb000, 7960, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7efb000
> close(3)= 0
> set_thread_area({entry_number=-1, base_addr=0xb7f35140, limit=0x0f, 
> seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, 
> seg_not_present=0, useable=1}) = 0 (entry_number=6)
> mprotect(0xb7ef7000, 8192, PROT_READ)   = 0
> mprotect(0x447000, 4096, PROT_READ) = 0
> mprotect(0xb7f67000, 4096, PROT_READ)   = 0
> munmap(0xb7efd000, 225163)  = 0
> brk(NULL)   = 0x240f000
> brk(0x243)  = 0x243
> brk(0x2431000)  = 0x2431000
> openat(AT_FDCWD, "/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq", 
> O_RDONLY) = 3
> read(3, "180\n", 128)   = 8
> read(3, "", 128)= 0
> close(3)= 0
> brk(0x243)  = 0x243
> openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
> read(3, "0\n", 8192)= 2
> close(3)= 0
> exit_group(1)   = ?
> +++ exited with 1 +++
> 29/1/0 root@loadrunner:pts/4 23:09:21 [~] #

Bug#918075: Enabling new 2.6/2.7 dar features

[John Goerzen]

Hi again Laszlo,

I thought I would revisit the conversation in 918075.  Since then, 
I think we have had additional features in 2.7.x.  At the moment, 
I believe this is a list of things we could support in dar on 
Debian but aren't:


zstd compression
lz4 compression
multithreading
delta compression (librsync)
remote repository (libcurl)
argon2 hashing (libargon)
Python library

Necessary libraries for all of these except multithreading are in 
Debian already.


If I might summarize the situation:

- There is concern that some of these libraries are not available 
 in static versions in Debian, and thus dar_static can't be built 
 with them.


- On the other hand, we are now at a point where Debian's dar is 
 incapable of extracting quite a few archives made by dar on 
 other platforms (or locally-compiled dar).  dar_static is of 
 little use if it can't unpack the archive anyhow.  zstd and 
 delta compression, in particular, are two quite compelling 
 features that we are lacking.


I propose:

1) Packaging up threadar

2) Pick one of:

2a) Enabling all libraries in the dynamic version, and as many as 
possible in the static version, and document the situation;


2b) Take an approach like exim4-daemon-heavy vs. 
exim4-daemon-light, and provide a dar-light and a dar-heavy binary 
package, which differ in what libraries are linked in.


2c) Enable all libraries in the dynamic version, and drop 
dar-static entirely.


I volunteer to do the work.  I would be happy to package up and 
maintain threadar, and to send you patches for dar, be a 
co-maintainer for dar, or take over maintaining dar, whatever you 
may prefer.


As for which option 2 we choose, my preference is 2c, followed by 
2a.  I think that a light vs. heavy package is overkill in this 
situation (exim did this because the "heavy" package really did 
bring in significant heavy libraries like SQL and such).


Comparing with other similar packages on the system:

- GNU tar, at /bin/tar, is dynamically linked but calls external 
 archivers as a separate process and therefore doesn't link them 
 in.


- bsdtar, at /usr/bin/bsdtar, is dynamically linked and has a very 
 similar set of libraries it would use compared to dar.  bsdtar's 
 own libarchive is linked in, as well as liblz4, libzstd, libbz2, 
 liblzma, libacl, etc.  bsdtar is a multi-archive program, 
 supporting multiple flavors of tar, pax, cpio, shar, iso9660, 
 zip, ar, mtree, 7z, cab, lha, rar, warc, and xar, so it is quite 
 capable of creating formats that can't be extraced by standard 
 Debian base system tools.


- fsarchiver has its own format, and its linking approach is like 
 bsdtar.  dynamically-linked only, links libbz2, liblzo2, liblz4, 
 libzstd, liblzma, libgcrypt, etc.


- p7zip uses a linking approach similar to GNU tar, dynamic only

- unrar is dynamic only

- cpio is dynamic only

- afio is dynamic only

- borgbackup is Python-only and also depends on libzstd1

- rdiff-backup is Python-only and also depends on librsync2

- duplicity is Python-only and also depends on librsync2

So what I'm trying to say here is that I can't find any other 
backup/archiving tool on Debian that limits itself to what is 
possible in a static binary, or even ships a static binary in the 
first place.  Given the existence of Debian Live images, it should 
be easy enough for someone wanting to be able to extract a dar 
archive to make that happen even with a completely wiped system. 
All of these other tools make that assumption as well.


Ultimately, I don't want Debian's dar to be unable to unpack dar 
archives because we are restricting the feature set so tightly to 
what we can put in dar-static.


Thanks,

John