Bug#1019890: ITP: oxdna-cuda -- coarse-grained simulation software for DNA, RNA, and related systems

[Andrius Merkys]

Hi Constantine,

On 2022-09-15 19:03, Constantine Evans wrote:
> oxDNA is a simulation code that was initially conceived as an
> implementation of the coarse-grained DNA model introduced by
> T. E. Ouldridge, J. P. K. Doye and A. A. Louis. It has been since
> reworked and it is now an extensible simulation+analysis framework. It
> natively supports DNA, RNA, Lennard-Jones and patchy particle
> simulations of different kinds on both single CPU cores and NVIDIA
> GPUs.

This sounds interesting. oxDNA could be a great addition to DebiChem or
Debian Med teams.

> oxDNA has CUDA and CPU simulation backends. I've only made a package
> so far including CUDA support, which would thus need to go in
> contrib, because I primarily use the CUDA backend, and have mostly
> seen others using it and presenting results with it.  It also has two
> python libraries, oxpy and oxDNA_analysis_tools, which I have packaged
> as separate binary packages.>
> I have not made a serious Debian package before, and would need a
> sponsor for this; I'd plan to upload it to mentors.  Like much
> research software, it was not built with standard system-wide
> installation as a priority, and has needed some tweaking to its
> build process in that regard, but it is reasonably simple, and the
> upstream authors are responsive to changes to make things easier.

I have never worked with packaging CUDA software. Since it cannot be
built on buildd, I suppose all uploads will have to source+binary. It is
interesting how this works with sponsoring, in particular who (you or
sponsor) will have to build the binaries for upload.

By the way, what would be the binary compatibility of the CUDA package?
I.e., what is the range of CUDA versions that could use the binary
package without rebuilding it from source?

Best,
Andrius

Bug#1019912: fonts-babelstone-han: 15.0.2-1 is actually 14.0.5-1

[Wenbin Lv]

Package: fonts-babelstone-han
Version: 15.0.2-1
Severity: normal

Dear maintainer,

The BabelStoneHan.ttf files in fonts-babelstone-han_14.0.5-1_all.deb and
fonts-babelstone-han_15.0.2-1_all.deb are identical.

Thanks,
Wenbin Lv

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

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

-- no debconf information

Bug#1019526: gnome-control-center: color management broken after update, segfault

[Li ShXlin]

On Sun, 11 Sep 2022 12:48:08 +0500 Alexandr Podgorniy
 wrote:
> Package: gnome-control-center
> Version: 1:43~rc-2
> Severity: normal
> X-Debbugs-Cc: sca...@scaledteam.ru
> 
> Color management menu in gnome-control-center led to segfault. Also,
color
> management broken in entire system, applications ignore color
profiles.
> 
> GDB says folowing:
> 
> Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation
fault.
> cc_color_device_set_expanded (color_device=0x0, expanded=1) at
> ../panels/color/cc-color-device.c:161
> warning: Source file is more recent than executable.
> 161   if (color_device->expanded == expanded)
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER,
TAINT_OOT_MODULE
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 gnome-control-center depends on:
> ii  accountsservice   22.08.8-1
> ii  apg   2.2.3.dfsg.1-5+b2
> ii  colord    1.4.6-1
> ii  desktop-base  11.0.3
> ii  desktop-file-utils    0.26-1
> ii  gnome-control-center-data 1:43~rc-2
> ii  gnome-desktop3-data   43~alpha-3
> ii  gnome-settings-daemon 43~rc-1
> ii  gsettings-desktop-schemas 43~alpha-1
> ii  libaccountsservice0   22.08.8-1
> ii  libadwaita-1-0    1.2~beta-1
> ii  libc6 2.34-7
> ii  libcairo2 1.16.0-6
> ii  libcolord-gtk4-1  0.3.0-3
> ii  libcolord2    1.4.6-1
> ii  libcups2  2.4.2-1+b1
> ii  libepoxy0 1.5.10-1
> ii  libfontconfig1    2.13.1-4.4
> ii  libgcr-base-3-1   3.41.1-1
> ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
> ii  libglib2.0-0  2.73.3-3
> ii  libgnome-bg-4-2   43~alpha-3
> ii  libgnome-bluetooth-ui-3.0-13  42.3-3
> ii  libgnome-desktop-4-2  43~alpha-3
> ii  libgnome-rr-4-2   43~alpha-3
> ii  libgnutls30   3.7.7-2
> ii  libgoa-1.0-0b 3.45.2-2
> ii  libgoa-backend-1.0-1  3.45.2-2

I also lose the night light.
:(

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi,

Alberto Garcia wrote on Wed, Aug 17, 2022 at 10:31:22AM +:
> Thanks, I just forwarded the bug upstream, I'll try to reproduce it
> myself this or next week.

I've also been observing similar crashes on aarch64 bullseye package
and using bookworm is not an option for me (thanks to proprietary
drivers...)


The traces are slightly different:

/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7cfdfaa0 in __GI_abort () at abort.c:79
#2  0x7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:741
#3  0x80a2d5a8 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0x80a08ea0 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:592
#5  0x83c06550 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x820e8d1c in preconnectTo () at 
../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735
#7  0x81fc62f4 in 
callMemberFunctionImpl
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, 0, 1> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:125
#8  callMemberFunction
 >, WebKit::NetworkResourceLoadParameters&&), 
std::tuple >, 
WebKit::NetworkResourceLoadParameters>, std::integer_sequence > () at ../Source/WebKit/Platform/IPC/HandleMessage.h:131
#9  handleMessage
 >, WebKit::NetworkResourceLoadParameters&&)> () at 
../Source/WebKit/Platform/IPC/HandleMessage.h:196
#10 didReceiveNetworkConnectionToWebProcessMessage () at 
DerivedSources/WebKit/NetworkConnectionToWebProcessMessageReceiver.cpp:479
#11 0x822543d0 in dispatchMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1134
#12 0x82254768 in dispatchOneIncomingMessage () at 
../Source/WebKit/Platform/IPC/Connection.cpp:1203
#13 0x80a2bf40 in operator() () at ../Source/WTF/wtf/Function.h:82
#14 performWork () at ../Source/WTF/wtf/RunLoop.cpp:133
#15 0x80a85190 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:80
#16 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:79
#17 0x80a84524 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#18 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#19 0x7d551ab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x7d551e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#21 0x7d5521b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#22 0x80a84b20 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#23 0x822280d8 in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:70
#24 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:96
#25 0x7cfdfe18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xf1c90058, init=, fini=,
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#26 0x00400874 in _start ()


/usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x99831aa0 in __GI_abort () at abort.c:79
#2  0x9c2dcc50 in WTFCrashWithInfo(int, char const*, char const*, int) 
() at WTF/Headers/wtf/Assertions.h:741
#3  0x9d27f5a8 in captureStackTrace () at 
../Source/WTF/wtf/StackTrace.cpp:79
#4  0x9d25aea0 in WTFReleaseLogStackTrace () at 
../Source/WTF/wtf/Assertions.cpp:592
#5  0xa0458550 in internalError () at 
../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
#6  0x9edead30 in internallyFailedLoadTimerFired () at 
../Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:495
#7  0x9d2d723c in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#8  __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#9  0x9d2d6524 in operator() () at 
../Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#10 __invoke () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#11 0x99da3ab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0x99da3e5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#13 0x99da41b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#14 0x9d2d6b20 in run () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#15 0x9eea47c4 in run () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:70
#16 AuxiliaryProcessMain () at 
../Source/WebKit/Shared/AuxiliaryProcessMain.h:96
#17 0x99831e18 in __libc_start_main (main=0x400878 <__wrap_main>, 
argc=3, argv=0xf7b85168, init=, fini=,
rtld_fini=, stack_end=) at 
../csu/libc-start.c:308
#18 0x00400874 in _start ()



hopefully the root of the problem is the same and having debug symbols
installed will help pinpoint 

Bug#1019764: ctsim: Please transition to wxwidgets3.2

[Scott Talbert]

On Thu, 15 Sep 2022, Andreas Tille wrote:


Control: tags -1 help

Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net:

Please transition gentle from wxwidgets3.0 to wxwidgets3.2.


I would like to support this but I have no idea about wxwidgets.


For most packages, the transition should be as simple as changing
Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.


Unfortunately this is not enouth in this case.


Some
packages may require small patches; I'm happy to help with those (and
I have some already from working on this transition in Fedora
already).


I've tagged the bug help and hope you can commit the patches needed.

Here you can find the compile issues in Salsa CI

  https://salsa.debian.org/med-team/ctsim/-/jobs/3238687


Here you go:
https://salsa.debian.org/med-team/ctsim/-/merge_requests/1

Scott

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Guillem Jover]

On Wed, 2022-09-14 at 17:31:16 +0200, Santiago Ruano Rincón wrote:
> Yeah, sorry. I lately realised not all the packages would autoreconf
> during building time.
> 
> So silencing these warnings would make sense.

Please consider implementing a way to be able to conditionally re-enable
locally these warnings so that we can try to hunt down and fix those,
otherwise we might end up hitting these once we revert the silencing,
for example for code paths that are not commonly exercised.

I've mentioned this on the upstream bug report, but it would be nicer
if you could coordinate a way upstream might be happy with, say using
a specific environment variable or similar.

Thanks,
Guillem

Bug#1019903: RM: golang-gopkg-macaroon-bakery.v2 -- ROM; superseded

[Mathias Gibbens]

Package: ftp.debian.org
Severity: normal

  Please remove golang-gopkg-macaroon-bakery.v2. It has been superseded
by golang-github-go-macaroon-bakery-macaroon-bakery. This package was a
dependency for building LXD, but both the lxd and golang-github-
canonical-candid packages have been updated to use version 3 of the
library which was packaged in golang-github-go-macaroon-bakery-
macaroon-bakery. There are no build rdeps of golang-gopkg-macaroon-
bakery.v2-dev in unstable.

Thanks,
Mathias


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

Bug#927989: RFA: terminaltables -- Python library for printing tables to the console

[Carl Suster]

Hi Daniel,

Please go ahead! It would make sense to also take on colorclass 
(https://bugs.debian.org/929658) at the same time since it's a dependency of 
terminaltables.

I pushed updates to git for both packages to track the new upstream forks, but 
didn't attempt to package new upstream versions. Feel free to remove me from 
the Uploaders.

Cheers,
Carl

On 16/9/22 09:17, Daniel Baumann wrote:

> Hi Carl,
>
> I'm maintaining all of the dbi packages (mycli, pglci, etc.) in Debian,
> which use terminaltables. I'm happy to also take care about
> terminaltables if that's fine with you.
>
> Regards,
> Daniel

Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO

[Stuart Young]

There's been no new RC release from Mesa since rc3, which was 4 weeks ago.

I think they're overdue for one.


On Fri, 16 Sept 2022 at 02:03, Leandro Cunha 
wrote:

> Hi,
>
> Yes, I reported it to upstream and it's an issue that went undetected
> until I take action like this. And the upload (I don't know if it was
> accidental) to an unstable version of rc (release candidate) helped to
> discover that there were issues that needed attention. Thanks to Karol
> who took the necessary attention to solve the problem. And fixed
> upstream and upstream tags are already added. Upload only for pending
> fix now. I have no information if a new version of rc has been
> released.
>
> --
> Cheers,
> Leandro Cunha
>
>

-- 
Stuart Young (aka Cefiar)

Bug#1019326: ucf: grep warning "stray \ before /" due to incorrect use of perl's \Q...\E

[Vincent Lefevre]

On 2022-09-15 17:11:49 +0200, Paul Gevers wrote:
> On Wed, 7 Sep 2022 14:28:57 +0200 Vincent Lefevre 
> wrote:
> > outputs "ab\/cd". \Q...\E is designed for reuse by Perl, not for grep.
> 
> not for grep without the -P option (not saying that's the right solution).

Note that there would be a potential issue by using the -P option: it
is not standard. If this is chosen, the ucf package should probably
depend on "grep" (currently required, but this would be safer) and
use the full pathname /bin/grep to avoid a possible grep builtin.

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

Bug#927989: RFA: terminaltables -- Python library for printing tables to the console

[Daniel Baumann]

Hi Carl,

I'm maintaining all of the dbi packages (mycli, pglci, etc.) in Debian,
which use terminaltables. I'm happy to also take care about
terminaltables if that's fine with you.

Regards,
Daniel

Bug#1019889: When brltty is upgraded, could brltty.postinstl honor START_IN_INITRAMFS?

[Samuel Thibault]

Control: tags -1 + pending

Sebastien Hinderer, le jeu. 15 sept. 2022 18:00:56 +0200, a ecrit:
> In /etc/default/brltty the variable START_IN_INITRAMFS controls whether
> brltty is embedded in ramfs or not.
> 
> If this still works, would it be possible that brltty.postinst honoors this
> variable and runs update-initramfs -u automatically when the package
> is upgraded?

Indeed!  It should have been so for years...  Now pushed.

Thanks for the report,
Samuel

Bug#1019899: trivially to trigger traceback

[Lee Garrett]

Package: lookatme
Version: 2.3.0-1
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi, it's trivally to trigger a traceback with lookatme:

---
$ lookatme README.md 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lookatme/__main__.py", line 139, in main
pres.run()
  File "/usr/lib/python3/dist-packages/lookatme/pres.py", line 141, in run
self.tui = lookatme.tui.create_tui(self, start_slide=start_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 364, in create_tui
tui = MarkdownTui(pres, start_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 222, in __init__
self.prep_pres(self.pres, start_idx)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 235, in prep_pres
self.update()
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 307, in update
self.update_body()
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 277, in 
update_body
rendered = self.slide_renderer.render_slide(self.curr_slide)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 75, in 
render_slide
raise res
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 105, in run
res = self.do_render(to_render, slide_num)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 157, in do_render
self._render_tokens(tokens)
  File "/usr/lib/python3/dist-packages/lookatme/tui.py", line 175, in 
_render_tokens
render_token = getattr(lam_md, f"render_{token['type']}")
AttributeError: module 'lookatme.render.markdown_block' has no attribute 
'render_close_html'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/lookatme", line 33, in 
sys.exit(load_entry_point('lookatme==2.3.0', 'console_scripts', 
'lookatme')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/lookatme/__main__.py", line 141, in main
number = pres.tui.curr_slide.number + 1
AttributeError: 'NoneType' object has no attribute 'curr_slide'
---

it would be great to have it instead give some helpful output if it's not happy
with the markdown file.

Greetings,
Lee


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

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

Versions of packages lookatme depends on:
ii  libjs-sphinxdoc  3.4.3-2
ii  python3  3.9.2-3
ii  python3-click7.1.2-1
ii  python3-marshmallow  3.10.0-1
ii  python3-mistune  0.8.4-4
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-urwid2.1.2-1
ii  python3-yaml 5.3.1-5

lookatme recommends no packages.

lookatme suggests no packages.

-- no debconf information

Bug#1010955: uscan: configure multiple signature verification

[Daniel Kahn Gillmor]

Control: affects 1010955 + src:gnupg2 src:pinentry

On Sat 2022-05-14 07:55:36 +0200, Andreas Metzler wrote:
> The latest gnutls tarballs have multiple signatures. I would like
> to have uscan succeed if at least one of signatories is listed in
> debian/upstream/signing-key.asc. Uscan currently requires all signatures
> to verify with no way to configure differently afaict.

Andreas is correct here that it only makes sense to require one valid
signature for uscan's verification to succeed.  Requiring every
discovered signature to be valid is a mistake.  For example, it means
that projects that start publishing an OpenPGP v5 signature (when
rfc4880bis is finally released) alongside their OpenPGP v4 signatures
will fail to be validated.

The same failings happen for GnuPG and related projects like Pinentry,
which typically have multiple signers attesting to each release.

I think Andreas is wrong to argue that this should be configurable.  If
anything, the correct move here is to have uscan be satisfied as long as
it finds *any* valid signature from any key in the keyring located in
debian/upstream/signing-key.asc.

Here's another way of looking at it: consider a malicious network
adversary capable of interposing themselves and tampering with either
the tarball or the signature -- it is trivial (and unavoidable) that the
adversary can make a good signature fail; just fiddle some bits in the
signature or the tarball.  What we critically want to avoid is for them
to be able to make a bad signature appear good.

But note that if we believe every supplied signature must be good when a
multiple signature is supplied, and one signature is from an unknown
party, then a network attacker can simply *remove* the unknown
signature, and the remaining signatures will all pass, converting a
"bad" multi-sig into a "good" single-sig.  The threat model for this
approach is clearly muddled!

By permitting a single signature from any signer to validate, we are not
increasing the capabilities of the attacker at all.  we're simply making
the system more robust, and enabling upstream developers to smoothly
migrate to new keys by signing with both keys for a period of time.

On the off chance that some upstream project wants debian to ensure that
*multiple* signers have indeed endorsed a release, then it's possible
that uscan would want some configurability -- the debian maintainer
would want to indicate that *at least N signatures from distinct signers
in the known keyring* are present in the signature bundle, for example.
But i know of no active projects that take this position at the moment,
so making such a configurable option is entirely gravy at this point.

It's more important that uscan *succeed* when at least one valid
signature is found.

  --dkg


signature.asc
Description: PGP signature

Bug#1019393: hdf5 breaks libsis-jhdf5-java autopkgtest: Could not initialize class

[Pierre Gruet]

Control: tags -1 + confirmed

Hello,

The issue showing up in the tests is the native library cannot be loaded 
properly. Some symbols (at least HDfprintf) cannot be found. I can 
investigate next week.


Surprisingly, using sbuild and working in the chroot after the failure 
of the tests, running

debian/rules override_dh_auto_build
debian/rules override_dh_auto_test
leads to all the tests passing...

Cheers,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995477: cppman: error: no such table: cppreference.com_keywords

[Jakub Wilk]

* ChangZhuo Chen , 2022-09-16 04:11:
if anyone has legacy database, it will have no ${source}_keywords table 
error.


The only database I had was the one shipped by this package, i.e.:
/usr/lib/python3/dist-packages/cppman/lib/index.db

I tried "cppman -r", but that didn't help much:

   $ cppman -r

   $ cppman std::unique_ptr
   No manual entry for std::unique_ptr 


   $ sqlite3 ~/.cache/cppman/index.db .dump
   PRAGMA foreign_keys=OFF;
   BEGIN TRANSACTION;
   CREATE TABLE IF NOT EXISTS "cplusplus.com" (id INTEGER NOT NULL PRIMARY KEY, 
title VARCHAR(255) NOT NULL UNIQUE, url VARCHAR(255) NOT NULL UNIQUE);
   CREATE TABLE IF NOT EXISTS "cplusplus.com_keywords" (id INTEGER NOT NULL, keyword 
VARCHAR(255), FOREIGN KEY(id) REFERENCES "cplusplus.com"(id));
   CREATE TABLE IF NOT EXISTS "cppreference.com" (id INTEGER NOT NULL PRIMARY 
KEY, title VARCHAR(255) NOT NULL UNIQUE, url VARCHAR(255) NOT NULL UNIQUE);
   CREATE TABLE IF NOT EXISTS "cppreference.com_keywords" (id INTEGER NOT NULL, keyword 
VARCHAR(255), FOREIGN KEY(id) REFERENCES "cppreference.com"(id));
   COMMIT;

--
Jakub Wilk

Bug#1019898: RFP: python-ipv8 -- Python implementation of Tribler's IPv8 p2p-networking layer

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: python-ipv8
  Version : 0.1
  Upstream Author :   Technical University Delft contributors
* URL : https://git.freecumextremist.com/themusicgod1/py_ipv8
* License : LGPLv3
  Programming Lang: python
  Description : IPv8 aims to provide authenticated communication with
privacy

The IPv8 library allows you to interface with the existing Dispersy network
( #1019895)  to build your own applications.  This project has been
evacuated from NSA/Microsoft Github.

It is a hard prerequisite for tribler ( #836852 )

Bug#995477: cppman: error: no such table: cppreference.com_keywords

[陳昌倬]

control: severity -1 important

The problem is broken backward compatibility. Please rebuild index via
`cppman -r` to fix the problem.


Detail:

cppman setup ${source}_keywords table in [0]. However, this feature does
not support migrating old database into new one. So if anyone has legacy
database, it will have no ${source}_keywords table error.


[0] 
https://github.com/aitjcize/cppman/commit/40692dc43289022eec6cef379683741afb22ad3c


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1019878: Please disable -mtune=native for "parisc" too

[Jochen Sprickerhof]

Hi José,

* José Luis Blanco-Claraco  [2022-09-15 21:51]:

On Thu, Sep 15, 2022 at 2:06 PM Helge Deller  wrote:

Reason is, that we have build servers which run either a 32- or 64-bit kernel,
and the 32-bit ones report "parisc" for "uname -m" instead of "parisc64".


Ah, that explains a lot about those hppa failures! :-)

A fix has been pushed upstream, and as a d/patch to the gbp repo:
 https://salsa.debian.org/robotics-team/mrpt
so it could be uploaded to close this one...


Please disable -mtune=native on all archs. Buildd could be arbitrary new 
CPUs and it would result in crashing executables. Also -O3 is debatable. 
You can get the recommend Debian flags with:


$ dpkg-buildflags

And debhelper should set them automatically for cmake projects.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Aurelien Jarno]

Hi,

On 2022-09-15 20:59, debian-bug-rep...@p0358.net wrote:
> > The first thing would be to provide the output of /proc/cpuinfo
> 
> Pasting below (please **NOTE** that "avx2" would normally be there, but is
> currently missing due to this kernel option `clearcpuid=293` with which I
> booted the PC now -- I can **100%** confirm "avx2" was there before, but
> don't want to reboot for now to remove this kernel flag):
> 
> # cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 60
> model name  : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
> stepping: 3
> microcode   : 0x12
> cpu MHz : 2394.664
> cache size  : 3072 KB
> physical id : 0
> siblings: 4
> core id : 0
> cpu cores   : 2
> apicid  : 0
> initial apicid  : 0
> fpu : yes
> fpu_exception   : yes
> cpuid level : 13
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
> nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
> ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt xsave avx f16c
> rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi
> flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid xsaveopt
> dtherm arat pln pts
> vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb
> flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
> bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
> mds swapgs itlb_multihit srbds
> bogomips: 4789.10
> clflush size: 64
> cache_alignment : 64
> address sizes   : 39 bits physical, 48 bits virtual
> power management:

Thanks.

> > If you believe the issue is due to AVX2, clearcpuid won't help, as it
> > just clear the corresponding flags from the kernel point of view, but
> > the cpuid instruction will just continue to behave the same. The way to
> > do disable that features at the glibc level is to set the GLIBC_TUNABLES
> > environment variable to "glibc.cpu.hwcaps=-AVX2_Usable".
> 
> This works! Indeed the clearcpuid flags itself on its own did nothing as you
> mentioned too. This workaround is great to know then for the time being.

Great, that's narrowing down the problem.

> > Same from there due to ASLR. It seems to fail in at least two different
> > locations. Do you have some extra lines around, sometimes the kernel
> > dump the addresses around the instruction pointer?
> 
> Generally these lines all followed similar pattern, and there was nothing
> printed below or after, just this single line per crash. I will paste a few
> more below. Isn't the "+15a000" the relative offset in libc .so though? It

The +15a000 is the size of the libc.so.6 mapping in the virtual memory.

> does seem like an oddly round number, but I loaded the library in IDA
> disassembler and the instructions at this offset do seem to be related to
> AVX2 (linking screenshot which I also pasted on the linked GitHub issue)
> (the highlighted instruction in gray seems to be the one at this
> aforementioned offset):
> https://user-images.githubusercontent.com/5182588/190256853-29ae80aa-0089-4da2-a430-990e2693d15c.png
> 
> If my above hypithesis is correct, then I looked at the mother function in
> x-refs and it does seem to be defined in rtld_global_ro table, and its name
> is "__strncmp_avx2". Was something changed in this function between the
> updates?
> 
> Pasting more kernel lines:
> kernel: [852124.361775] traps: dhclient[1583381] trap invalid opcode
> ip:7fe19118051d sp:7ffee6e36238 error:0 in libc-2.31.so[7fe191044000+15a000]
> kernel: [852124.468314] traps: nft[1583398] trap invalid opcode
> ip:7fe3418fe51d sp:7fff11342df8 error:0 in libc-2.31.so[7fe3417c2000+15a000]
> kernel: [852124.572700] traps: systemd-shutdow[1377424] trap invalid opcode
> ip:7fde88b724ad sp:7ffc13767028 error:0 in libc-2.31.so[7fde88a3a000+15a000]
> kernel: [  270.477024] traps: bun[2055] trap invalid opcode ip:2e363f4
> sp:7ffe2320d640 error:0 in bun[2a6f000+2ce2000]
> kernel: [  279.884807] traps: systemd[2115] trap invalid opcode
> ip:7faf645ec4ad sp:7ffe12e06c48 error:0 in libc-2.31.so[7faf644b4000+15a000]
> kernel: [  299.637575] traps: bun[2296] trap invalid opcode ip:2e363f4
> sp:7ffd0c0bc9c0 error:0 in bun[2a6f000+2ce2000]
> kernel: [  331.036417] traps: bash[2462] trap invalid opcode ip:7ff42840051d
> sp:7ffd34ad7278 error:0 in libc-2.31.so[7ff4282c4000+15a000]
> kernel: [  357.184428] traps: bash[2652] trap invalid opcode ip:7f717873751d
> sp:7fffd34c8848 error:0 in libc-2.31.so[7f71785fb000+15a000]
> kernel: [  645.517556] traps: bash[3508] trap invalid opcode ip:7f4b6ee8851d
> sp:7ffd74beb6e8 error:0 in libc-2.31.so[7f4b6ed4c000+15a000]
> kernel: [  876.760209] traps: bash[4225] 

Bug#1019896: smarty4: CVE-2018-25047: smarty_function_mailto - JavaScript injection in eval function

[Salvatore Bonaccorso]

Source: smarty4
Version: 4.1.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/smarty-php/smarty/issues/454
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:smarty3 3.1.45-1
Control: retitle -2 smarty3: CVE-2018-25047: smarty_function_mailto - 
JavaScript injection in eval function
Control: found -2 3.1.39-2+deb11u1
Control: found -2 3.1.39-2

Hi,

The following vulnerability was published for smarty4.

CVE-2018-25047[0]:
| In Smarty before 3.1.47 and 4.x before 4.2.1,
| libs/plugins/function.mailto.php allows XSS. A web page that uses
| smarty_function_mailto, and that could be parameterized using GET or
| POST input parameters, could allow injection of JavaScript code by a
| user.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-25047
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25047
[1] https://github.com/smarty-php/smarty/issues/454
[2] 
https://github.com/smarty-php/smarty/commit/f1f7ee6e34c14a8a9dfa5c6ef894d39277a93938
 (v3.1.47)
[3] 
https://github.com/smarty-php/smarty/commit/55ea25d1f50f0406fb1ccedd212c527977793fc9
 (v4.2.1)

Regards,
Salvatore

Bug#1019895: RFP: dispersy -- A database designed for P2P-like scenarios

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist

* Package name: dispersy
  Version : 21
  Upstream Author :   Technical University Delft contributors including
Boudewijn Schoon
* URL : https://git.freecumextremist.com/themusicgod1/dispersy
* License : LGPLv3
  Programming Lang: python
  Description : A database designed for P2P-like scenarios
The elastic database system. A database designed for P2P-like scenarios,
where potentially millions of computers send database updates around.
(Evacuated from NSA/Microsoft Github)

It is a hard prerequisite for tribler ( #836852 )

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Rene Engelhard]

Hi,

Am 15.09.22 um 15:50 schrieb Paul Gevers:

On 15-09-2022 09:26, Paul Gevers wrote:
I am trying to schedule autopkgtests in unstable on amd64 for all 
source packages that have one.


And the first results are coming in. I'm not sure how to proceed 
though, see below.


Lucas, are you in the position to do an archive rebuild to check for 
the grep warnings (see full history at [1]). When you submit bugs, 
can you please file them as important, as apparently upstream wants 
to turn these warnings into failures in the future, but in Debian 
Santiago is going to silence the warning soon, so FTBFS due to this 
isn't an RC problem on the short term.


I wonder if this is going to be useful. The first couple of hits I 
inspected, the warning didn't occur in the autopkgtest itself, but 
during installation of required packages.



Packages using ucf, yes.

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



E.g.
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/26114550/log.gz 

shows the warning while running update-perl-sax-parsers during 
installation libxml-sax-perl


and
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-lib-pq/26114898/log.gz 


shows the warning while installing postgresql-common

A lot of tests use postgresql, so weeding that out isn't going to be 
trivial.


Any ideas? (I'll of course file bugs against postqresql-common and 
whatever contains update-perl-sax-parsers, but I'll need more 
automation for the rest) 


Doesn't make sense imho, as neither has a bug and it's actually ucf in 
many cases doing the grep in question.


Regards,


Rene

Bug#1019811: treeviewx: Please transition to wxwidgets3.2

[Andreas Tille]

Control: tags -1 help

Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net:
> Please transition gentle from wxwidgets3.0 to wxwidgets3.2.

I would like to support this but I have no idea about wxwidgets.
 
> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.

Unfortunately this is not enouth in this case.

> Some
> packages may require small patches; I'm happy to help with those (and
> I have some already from working on this transition in Fedora
> already).

I've tagged the bug help and hope you can commit the patches needed.

Here is the link to Salsa CI

   https://salsa.debian.org/med-team/treeviewx/-/jobs/3238712

Kind regards
 
   Andreas.

-- 
http://fam-tille.de

Bug#1019857: fetchmail: Running as root is discouraged / no mailservers have been specified

[Timo van Roermund]

Thanks, László.

The issue indeed seems to be gone after disabling the systemd service.

Best regards,

Timo

Bug#1019764: ctsim: Please transition to wxwidgets3.2

[Andreas Tille]

Control: tags -1 help

Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net:
> Please transition gentle from wxwidgets3.0 to wxwidgets3.2.

I would like to support this but I have no idea about wxwidgets.
 
> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.

Unfortunately this is not enouth in this case.

> Some
> packages may require small patches; I'm happy to help with those (and
> I have some already from working on this transition in Fedora
> already).

I've tagged the bug help and hope you can commit the patches needed.

Here you can find the compile issues in Salsa CI

   https://salsa.debian.org/med-team/ctsim/-/jobs/3238687


Kind regards
 
   Andreas.

-- 
http://fam-tille.de

Bug#1019809: gentle: Please transition to wxwidgets3.2

[Andreas Tille]

I forgot to mention the salsa CI link where you can find the compile issues:

https://salsa.debian.org/med-team/gentle/-/jobs/3238666

Am Thu, Sep 15, 2022 at 09:18:39PM +0200 schrieb Andreas Tille:
> Control: tags -1 help
> 
> Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net:
> > Please transition gentle from wxwidgets3.0 to wxwidgets3.2.
> 
> I would like to support this but I have no idea about wxwidgets.
>  
> > For most packages, the transition should be as simple as changing
> > Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.
> 
> Unfortunately this is not enouth in this case.
> 
> > Some
> > packages may require small patches; I'm happy to help with those (and
> > I have some already from working on this transition in Fedora
> > already).
> 
> I've tagged the bug help and hope you can commit the patches needed.
> 
> Kind regards
>  
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#1019809: gentle: Please transition to wxwidgets3.2

[Andreas Tille]

Control: tags -1 help

Am Wed, Sep 14, 2022 at 03:42:14PM -0400 schrieb s...@techie.net:
> Please transition gentle from wxwidgets3.0 to wxwidgets3.2.

I would like to support this but I have no idea about wxwidgets.
 
> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.

Unfortunately this is not enouth in this case.

> Some
> packages may require small patches; I'm happy to help with those (and
> I have some already from working on this transition in Fedora
> already).

I've tagged the bug help and hope you can commit the patches needed.

Kind regards
 
   Andreas.

-- 
http://fam-tille.de

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[debian-bug-report]

> The first thing would be to provide the output of /proc/cpuinfo

Pasting below (please **NOTE** that "avx2" would normally be there, but 
is currently missing due to this kernel option `clearcpuid=293` with 
which I booted the PC now -- I can **100%** confirm "avx2" was there 
before, but don't want to reboot for now to remove this kernel flag):


# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping: 3
microcode   : 0x12
cpu MHz : 2394.664
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good 
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
movbe popcnt xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase 
tsc_adjust smep erms invpcid xsaveopt dtherm arat pln pts
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad 
ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid 
unrestricted_guest ple
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds

bogomips: 4789.10
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping: 3
microcode   : 0x12
cpu MHz : 2400.000
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good 
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
movbe popcnt xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase 
tsc_adjust smep erms invpcid xsaveopt dtherm arat pln pts
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad 
ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid 
unrestricted_guest ple
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds

bogomips: 4789.10
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping: 3
microcode   : 0x12
cpu MHz : 2400.000
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good 
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
movbe popcnt xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase 
tsc_adjust smep erms invpcid xsaveopt dtherm arat pln pts
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad 
ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid 
unrestricted_guest ple
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds

bogomips: 4789.10
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz
stepping: 3
microcode   : 0x12
cpu MHz : 2400.000
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid 

Bug#1019894: ITP: golang-sourcehut-rockorager-tcell-term -- TODO

[Robin Jarry]

Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-sourcehut-rockorager-tcell-term
  Version : 0.1.0-1
  Upstream Author : Tim Culverhouse 
* URL : https://git.sr.ht/~rockorager/tcell-term
* License : expat
  Programming Lang: Go
  Description : A virtual terminal widget for tcell

tcell-term implements the native tcell Widget interface.

This is a new dependency for aerc.

Bug#1019549: fetchmail: can't accept options while a background fetchmail is running.

[GCS]

Control: tags -1 -moreinfo

Hi Helge,

On Wed, Sep 14, 2022 at 10:09 PM Helge Kreutzmann  wrote:
> On Tue, Sep 13, 2022 at 08:05:50PM +0200, László Böszörményi (GCS) wrote:
> >  Yes, this is for the initscripts.
>
> Ok, but this is not clear and it used to work until very recently.
 Yup, with 6.4.33-1 the systemd user retrieval service accidentally
enabled. It's a parallel system next to initscripts.

> > # systemctl --global disable fetchmail
> Removed "/etc/systemd/user/default.target.wants/fetchmail.service".
 This fixes it and I'm going to upload a package which fixes this issue.

> So I suppose when "START_DAEMON=no" then the above commands need to
> be issued in the postinst?
 Nope, it's for fetchmail itself only.

Fixed package which no longer enables systemd service for users is on its way.
Thanks for the feedback,
Laszlo/GCS

Bug#1019857: fetchmail: Running as root is discouraged / no mailservers have been specified

[GCS]

Hi,

On Thu, Sep 15, 2022 at 1:57 AM T.A. van Roermund  wrote:
> I'm getting the following messages in the syslog:
>
> Sep 15 01:03:21 systemd[1]: Starting LSB: init-Script for system wide 
> fetchmail daemon...
> Sep 15 01:03:21 fetchmail[2245]: Starting mail retriever agent: fetchmail.
> Sep 15 01:03:21 systemd[1]: Started LSB: init-Script for system wide 
> fetchmail daemon.
> Sep 15 01:03:21 fetchmail[2263]: starting fetchmail 6.4.33 daemon
> Sep 15 01:03:25 fetchmail[2310]: fetchmail: WARNING: Running as root is 
> discouraged.
[...]
> It seems that this started a few days ago, after upgrading fetchmail from 
> version 6.4.32-1 to 6.4.33-1.
 You are using the normal initscript for retrieving emails. But in the
background the systemd service got enabled with 6.4.33-1 and you need
to disable it by hand:
$ systemctl --user disable fetchmail.service
$ systemctl --user stop fetchmail.service
# systemctl --global disable fetchmail
The last command needs to run as root.

Going to upload an updated package which no longer enables the systemd
service file.

Sorry for the inconvenience,
Laszlo/GCS

Bug#1019425: dkms 3.0.6-2 not signing modules

[Tomas Janousek]

Hi,

On Wed, Sep 14, 2022 at 09:52:22PM +0200, Holger Schröder wrote:

The patch does not work for me. The modules are signed again with the
patch but at boot time they are not accepted and I end up at the
initramfs prompt. zfs module not loaded in my case.


Note that there have been several changes committed upstream related to 
signing modules on Debian/Ubuntu: https://github.com/dell/dkms/compare/v3.0.6...master


Specifically, 
https://github.com/dell/dkms/commit/8d60956f6dcda0679066954215eb8be4045413b4 
and 
https://github.com/dell/dkms/commit/3ca52f8769bdf7ebdc83735355fff7c5c0664152 
look relevant here. Might be worth testing that in preference to the 
patch posted here.


--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Aurelien Jarno]

Hi,

On 2022-09-15 01:37, debian-bug-rep...@p0358.net wrote:
> Package: libc6
> Version: 2.31-13+deb11u4
> Severity: critical
> 
> Dear Maintainer,
> 
> After an upgrade to version +deb11u4 on my system running Haswell
> (4th gen Intel Core) CPU, most of the programs including bash or dpkg
> are immediately crashing with SIGILL. The problem seems to be caused/
> related to AVX2 and changes made to some functions utilizing this
> instruction set. I don't know much about Debian bug reporting, so forgive me
> any mistakes I've made.
> The issue is on both host, LXC and Docker.
> I have described more on this link:
> https://github.com/debuerreotype/docker-debian-artifacts/issues/175
> where I also linked my coredump from example program and described stuff
> more thoroughly.

First of all, sorry about the issue, it should not have slipped in a
stable release. Unfortunately I am not able to reproduce the issue. I
have tried on 3rd gen or 5th gen Intel Core CPUs, but failed to
reproduce it. Therefore I will need your help to understand the issue.

The first thing would be to provide the output of /proc/cpuinfo

> Coredump link directly just in case: 
> https://github.com/debuerreotype/docker-debian-artifacts/files/9569748/core.bash.10.2663c40e671041e6b40c882a70b83c3f.1480736.166318582400.zip

Unfortunately I am not able to use this core dump to get the instruction
that trigger the SIGILL, even after installing debug symbols packages.


> Also log lines from kernel:
> kernel: [834669.721253] traps: dpkg[1455373] trap invalid opcode
> ip:7fa39701951d sp:7ffc4ad26e58 error:0 in libc-2.31.so[7fa396edd000+15a000]
> kernel: [834669.732958] traps: dpkg[1455374] trap invalid opcode
> ip:7f529ca9551d sp:7fffb6f0a238 error:0 in libc-2.31.so[7f529c959000+15a000]
> kernel: [834669.840128] traps: dpkg[1455375] trap invalid opcode
> ip:7f1874cc951d sp:7fffc2c2f5d8 error:0 in libc-2.31.so[7f1874b8d000+15a000]
> kernel: [834669.907918] traps: dpkg[1455378] trap invalid opcode
> ip:7f3b4f8d851d sp:7fff3ec970f8 error:0 in libc-2.31.so[7f3b4f79c000+15a000]
> kernel: [834712.152139] traps: passwd[1455693] trap invalid opcode
> ip:7fefee4b52b7 sp:7cb506b8 error:0 in libc-2.31.so[7fefee37d000+15a000]

Same from there due to ASLR. It seems to fail in at least two different
locations. Do you have some extra lines around, sometimes the kernel
dump the addresses around the instruction pointer?

> Not sure what exactly might be causing the issue, but if these changes
> aren't pulled, potentially anyone with this or similar CPU as me will
> upgrade and end up with bricked system.

The changes that are in this stable release have been (or at least were
supposed to, given the bug you reported) in testing/sid for a few
months. Are you able to do a test with debian sid, for instance in
docker?

> I will proceed to try using `clearcpuid=293` kernel flag myself, but
> consider how many distros depend on Debian, live CDs etc, with people unable
> to figure out why their system became useless, unable to trace the source,
> and blaming it just on Linux...

If you believe the issue is due to AVX2, clearcpuid won't help, as it
just clear the corresponding flags from the kernel point of view, but
the cpuid instruction will just continue to behave the same. The way to
do disable that features at the glibc level is to set the GLIBC_TUNABLES
environment variable to "glibc.cpu.hwcaps=-AVX2_Usable".
 
Regards
Aurelien

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

Bug#1019704: poedit: Error msg on startup (wxwidgets3.2 regression?)

[Boyuan Yang]

Hi,

在 2022-09-15星期四的 17:01 +0200，Andreas Rönnquist写道：
> On Tue, 13 Sep 2022 13:52:58 -0400 Boyuan Yang  wrote:
> > Thanks for uploading poedit for wxwidgets3.2 transition. However, the
> > rebuilt poedit would show the following error message as a popup window
> > when
> > opening a .PO file:
> > 
> > can't open file '/org/gtk/libgtk/icons/16x16/actions/text-x-generic.png'
> > (error 2: no such file or directory)
> > Failed to load image from file
> > "/org/gtk/libgtk/icons/16x16/actions/text-x-
> > generic.png"
> > 
> 
> Hi -
> 
> I cannot reproduce this - neither on Xfce, nor on Gnome.
> 
> Could you please give more details on how you open the .po file, and when
> the
> dialog appears? Simply opening poedit, and the selecting "Browse files"
> in the dialog that is presented, and then selecting the file?
> 
> I am guessing that it could be that the image file is missing from the
> GTK theme you are using - but this is only a guess - what GTK theme
> and icon theme are you using? And what desktop environment?
> 
> Also, that path looks a bit strange if it starts with "/org", if it is
> a full path, doesn't it?


Good catch. I am using gnome-shell with Xorg, and I could only reproduce it
with some icon theme choices, such as "Breeze" or "Papirus".

I did some debugging, and seems that the reason is that these icon themes
did not provide "text-x-generic.png", but "text-x-generic.svg" instead. When
using the Papirus icon theme, after performing the following action, the
error would be gone:


sudo cp /usr/share/icons/Adwaita/16x16/mimetypes/text-x-generic.png
/usr/share/icons/Papirus/16x16/mimetypes/text-x-generic.png
sudo update-icon-caches /usr/share/icons/Papirus


I am not sure whether it is a regression from wxwidgets3.2 or the icon theme
yet.

Thanks,
Boyuan Yang



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

Bug#1019748: error: package "encoding/binary" without types was imported

[Shengjing Zhu]

Control: tags -1 moreinfo

On Wed, Sep 14, 2022 at 10:42 PM Vignesh Raman
 wrote:
>
> Source: golang-github-klauspost-compress
> Version: 1.15.4+ds1-1
> Severity: normal
> Tags: ftbfs
> X-Debbugs-Cc: vignesh.ra...@collabora.com
>
> Dear Maintainer,
>
> When building golang-github-klauspost-compress with golang-1.18 the below 
> error is seen,
>
> src/github.com/klauspost/compress/zstd/blockdec.go
> stringer: internal error: package "encoding/binary" without types was 
> imported from "github.com/klauspost/compress/zstd"
>
> Please could you look into this. Thanks.

Please attach the full log, instead of some snippets...

Anyway, I think it's because you used an older version of
golang-golang-x-tools which is not compatible with golang-1.18.

-- 
Shengjing Zhu

Bug#1019891: mycli: Always crashes at runtime because the module 'sqlglot' is missing

[Daniel Baumann]

tag 1019891 + pending
thanks

On 9/15/22 18:25, François Gannaz wrote:
> Here is the upstream commit that added this dependency:
> https://github.com/dbcli/mycli/commit/b8411836350923528ecdb0c92f22d26d012c1c89

indeed, I missed that - thanks for reporting!

> I couldn't find 'sqlglot' anywhere among the Debian packages, so I
> suppose there is no easy workaround for this missing dependency.

I've packaged sqlglot and uploaded it.. it has to wait in the NEW queue
though.

In the meanwhile you can build the package from here:

https://git.progress-linux.org/users/daniel.baumann/debian/packages/sqlglot/

Regards,
Daniel

Bug#1019892: tftp-hpa: NMU 5.2+20150808-1.3

[Bastian Germann]

Source: tftp-hpa
Severity: wishlist

I have just uploaded a NMU to enable the transition fron tftp to tftp-hpa.
The debdiff is enclosed.diff -u tftp-hpa-5.2+20150808/debian/changelog 
tftp-hpa-5.2+20150808/debian/changelog
--- tftp-hpa-5.2+20150808/debian/changelog
+++ tftp-hpa-5.2+20150808/debian/changelog
@@ -1,3 +1,10 @@
+tftp-hpa (5.2+20150808-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace tftp instead of conflicting to help with #1019286.
+
+ -- Bastian Germann   Thu, 15 Sep 2022 19:01:12 +0200
+
 tftp-hpa (5.2+20150808-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u tftp-hpa-5.2+20150808/debian/control 
tftp-hpa-5.2+20150808/debian/control
--- tftp-hpa-5.2+20150808/debian/control
+++ tftp-hpa-5.2+20150808/debian/control
@@ -11,7 +11,7 @@
 Package: tftp-hpa
 Architecture: linux-any kfreebsd-any
 Depends: ${shlibs:Depends}
-Conflicts: tftp
+Replaces: tftp
 Description: HPA's tftp client
  Trivial File Transfer Protocol (TFTP) is a file transfer protocol, mainly to
  serve boot images over the network to other machines (PXE).

Bug#1007025: git-multimail 1.6.0 package review

[Antoine Beaupré]

On 2022-09-15 17:32:33, Antoine Beaupré wrote:
> Hi!
>
> I've done a quick review of the 1.6.0 package on salsa as of commit
> d5bd184a1cf73b752f80dea46d8080493a5e663b.

[...]

> Also, I didn't quite follow the work on the test cases, but why did you
> replace pep8 by pycodestyle in the patch in debian/patches? The patch
> itself doesn't actually explain the *why* (it explains the "what" but we
> typically want more than this...)

I have just found you have reported this upstream in:

https://github.com/git-multimail/git-multimail/issues/221

... which is great! Could you also open a PR against the repository and
link that in the patch?

You might want to review the patch tagging guidelines as well, as this
is the kind of things it answers:

https://dep-team.pages.debian.net/deps/dep3/

Finally, one fundamental issue with this package is that, as you
correctly identified, it's unmaintained upstream. If we do ship it in
Debian, maybe we'd want to keep it out of stable until that is settled?

a.
-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Bug#1007025: git-multimail 1.6.0 package review

[Antoine Beaupré]

Hi!

I've done a quick review of the 1.6.0 package on salsa as of commit
d5bd184a1cf73b752f80dea46d8080493a5e663b.

It looks like there's some leftover stuff in debian/copyright, i would
remove this:

modified   debian/copyright
@@ -2,8 +2,6 @@ Format: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: git-multimail
 Upstream-Contact: Matthieu Moy 
 Source: https://github.com/git-multimail/git-multimail
-#
-# Please double check copyright with the licensecheck(1) command.
 
 Files: *
 Copyright: 2014-2022, Matthieu Moy 

Also, I didn't quite follow the work on the test cases, but why did you
replace pep8 by pycodestyle in the patch in debian/patches? The patch
itself doesn't actually explain the *why* (it explains the "what" but we
typically want more than this...)

It seems like you have README.rst both in debian/rules and
debian/docs. Either one of those should be sufficient, and you should
remove the other. Same with the launcher in
python3-git-multimail.install vs debian/rules.

I'm also surprised we need that launcher at all. Normally, the
`setup.py` wrapper has a scripts= stanza which should install the
upstream one, why do we do it differently?

I would also name the binary package `git-multimail` instead of
`python3-git-multimail`, since we don't really care that much that the
thing is written in python, since it's not a library.

I think that's what I have for now. I haven't double-checked the
upstream branch to see if it matches the upstream repo I have here, but
that would be my next step before uploading... just a formality to make
sure everything matches up.

Thanks for working on this package!
-- 
The greatest crimes in the world are not committed by people breaking
the rules but by people following the rules. It's people who follow
orders that drop bombs and massacre villages.
- Banksy


signature.asc
Description: PGP signature

Bug#1019888: pipewire 0.3.57-1: no/crackling sound if pavucontrol is open, 0.3.56-1 is fine

[Dylan Aïssi]

Hi Clément,

Le jeu. 15 sept. 2022 à 17:33, Clément Hermann  a écrit :
>
> I'm a happy user of pipewire since a few month.
>

Glad to see a happy user :-)

> I believe this is an upstream regression:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2671 (fixed in
> 0.3.58 it seems, but I didn't test it).

Thanks for opening this bug with the solution!

> Disclaimer: I have a fairly fine-tuned configuration for low audio
> latency, for pro audio apps (recording, routing, etc). It might make
> things worse in this case. So while I considered tagging this `Important`
> I refrained from doing so, I might be in a corner case.

I am interesting in having more feedback from this kind of configuration!

>
> Please, can we get 0.3.58 sooner rather than later?

I plan to upload the new version tomorrow.

> That said, can I suggest decorellate system changes and upgrading to
> latest upstream release first so this is fixed?

That is a very good suggestion :-) next time I will make invasive
changes in a separate branch.

Best,
Dylan

Bug#1019891: mycli: Always crashes at runtime because the module 'sqlglot' is missing

[François Gannaz]

Package: mycli
Version: 1.26.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading the package `mycli`, the command fails to run.

❯ mycli
Traceback (most recent call last):
  File "/usr/bin/mycli", line 33, in 
sys.exit(load_entry_point('mycli==1.26.1', 'console_scripts',
'mycli')()) File "/usr/bin/mycli", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in
load module = import_module(match.group('module'))
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in
import_module return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in
_find_and_load_unlocked File "", line 688,
in _load_unlocked File "", line
883, in exec_module File "", line 241, in
_call_with_frames_removed File
"/usr/lib/python3/dist-packages/mycli/main.py", line 27, in 
import sqlglot ModuleNotFoundError: No module named 'sqlglot'

Here is the upstream commit that added this dependency:
https://github.com/dbcli/mycli/commit/b8411836350923528ecdb0c92f22d26d012c1c89

I couldn't find 'sqlglot' anywhere among the Debian packages, so I
suppose there is no easy workaround for this missing dependency.

Thank you for maintaining this.
Regards,

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mycli depends on:
ii  python3 3.10.6-1
ii  python3-cli-helpers 2.2.1-1
ii  python3-click   8.0.3-1
ii  python3-configobj   5.0.6-5
ii  python3-cryptography3.4.8-2
ii  python3-pkg-resources   59.6.0-1.2
ii  python3-prompt-toolkit  3.0.31-1
ii  python3-pyaes   1.6.1-4
ii  python3-pygments2.12.0+dfsg-2
ii  python3-pymysql 1.0.2-2
ii  python3-pyperclip   1.8.2-2
ii  python3-sqlparse0.4.2-1
ii  python3-tabulate0.8.9-1
ii  python3-terminaltables  3.1.0-4

mycli recommends no packages.

mycli suggests no packages.

-- no debconf information

Bug#1019889: When brltty is upgraded, could brltty.postinstl honor START_IN_INITRAMFS?

[Sebastien Hinderer]

Package: brltty
Version: 6.5-3+b1
Severity: wishlist

In /etc/default/brltty the variable START_IN_INITRAMFS controls whether
brltty is embedded in ramfs or not.

If this still works, would it be possible that brltty.postinst honoors this
variable and runs update-initramfs -u automatically when the package
is upgraded?

Many thanks!

Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO

[Leandro Cunha]

Hi,

Yes, I reported it to upstream and it's an issue that went undetected
until I take action like this. And the upload (I don't know if it was
accidental) to an unstable version of rc (release candidate) helped to
discover that there were issues that needed attention. Thanks to Karol
who took the necessary attention to solve the problem. And fixed
upstream and upstream tags are already added. Upload only for pending
fix now. I have no information if a new version of rc has been
released.

-- 
Cheers,
Leandro Cunha

Bug#1019888: pipewire 0.3.57-1: no/crackling sound if pavucontrol is open, 0.3.56-1 is fine

[Clément Hermann]

Package: pipewire
Version: 0.3.57-1

Tags: fixed-upstream

Dear pipewire maintainers,

I'm a happy user of pipewire since a few month, however since the
upgrade to 0.3.57, no node can output sound if pavucontrol is open.

When pavucontrol is open, pipewire log show the following error message

(3-4/second):
```
spa.alsa: hw:sofhdadsp: snd_pcm_avail after recover: Broken pipe
```

Starting pavucontrol after the node starts playing works a little
better: there is sound, but it's choppy.

Closing pavucontrol makes the sound working again.
Downgrading pipewire to the 0.3.56-1 version fixes it as well.

I believe this is an upstream regression: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2671 (fixed in 
0.3.58 it seems, but I didn't test it).


Disclaimer: I have a fairly fine-tuned configuration for low audio
latency, for pro audio apps (recording, routing, etc). It might make
things worse in this case. So while I considered tagging this `Important`
I refrained from doing so, I might be in a corner case.

The Gnome sound parameter menu works fine (but you can't enable/disable
device profiles with it, hence my usage of pavucontrol even when I'm not
using recording apps).

Please, can we get 0.3.58 sooner rather than later?

I see there are a lot of changes in the work, and I understand you want 
to get them right,
as well as discuss them maybe, especially with the conversation going on 
currently about pipewire.


That said, can I suggest decorellate system changes and upgrading to 
latest upstream release first so this is fixed?


Thanks :)


PS: if anyone reading this needs to downgrade on **sid**, the easy way is

- adding the right snapshot in apt list from snapshots.d.o:
https://snapshot.debian.org/archive/debian/20220720T032429Z/
contrib non-free`

- and downgrade like this:

`export pwver=0.3.56-1; apt install 
{pipewire{,-alsa,-bin,-jack,-pulse},libspa-0.2-{modules,bluetooth,jack},libpipewire-0.3{-0,-modules},gstreamer1.0-pipewire}=$pwver`


do *not* do this on testing, at least not blindly, you'd need to get the 
right snapshot first ;)



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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

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

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

--
nodens

Bug#1019326: ucf: grep warning "stray \ before /" due to incorrect use of perl's \Q...\E

[Paul Gevers]

Hi,

On Wed, 7 Sep 2022 14:28:57 +0200 Vincent Lefevre  
wrote:

outputs "ab\/cd". \Q...\E is designed for reuse by Perl, not for grep.


not for grep without the -P option (not saying that's the right solution).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019704: poedit: Error msg on startup (wxwidgets3.2 regression?)

[Andreas Rönnquist]

On Tue, 13 Sep 2022 13:52:58 -0400 Boyuan Yang  wrote:
> Thanks for uploading poedit for wxwidgets3.2 transition. However, the
> rebuilt poedit would show the following error message as a popup window when
> opening a .PO file:
> 
> can't open file '/org/gtk/libgtk/icons/16x16/actions/text-x-generic.png'
> (error 2: no such file or directory)
> Failed to load image from file "/org/gtk/libgtk/icons/16x16/actions/text-x-
> generic.png"
> 

Hi -

I cannot reproduce this - neither on Xfce, nor on Gnome.

Could you please give more details on how you open the .po file, and when the
dialog appears? Simply opening poedit, and the selecting "Browse files"
in the dialog that is presented, and then selecting the file?

I am guessing that it could be that the image file is missing from the
GTK theme you are using - but this is only a guess - what GTK theme
and icon theme are you using? And what desktop environment?

Also, that path looks a bit strange if it starts with "/org", if it is
a full path, doesn't it?


-- Andreas Rönnquist
gus...@debian.org

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

One more factor that may be relevant. This is a really old Debian install.
It was first installed sometime in 2014 and thus would have used Wheezy .
So, it's been upgraded from Wheezy > Jessie > Stretch > Buster > Bullseye.

/var/lib/samba/usershares contains files dated from January 2015 through
September 13, 2022

-rw-r--r-- 1 root sambashare 104 Jan 17  2015 backups



On Thu, Sep 15, 2022 at 10:16 AM Jason Wittlin-Cohen <
jwittlinco...@gmail.com> wrote:

>
>
> On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen <
> jwittlinco...@gmail.com> wrote:
>
>> -- Forwarded message --
>>
>>> From: Michael Tokarev 
>>> To: Jason Cohen , 1019545-d...@bugs.debian.org
>>> Cc:
>>> Bcc:
>>> Date: Thu, 15 Sep 2022 13:17:28 +0300
>>> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
>>> /var/lib/samba results in repeated panic or segfault after upgrading from
>>> Buster to Bullseye
>>> 11.09.2022 19:28, Jason Cohen wrote:
>>> > Package: samba
>>> > Version: 2:4.16.4+dfsg-2~bpo11+1
>>> > Severity: normal
>>> >
>>> > Dear Maintainer,
>>> >
>>> > *** Reporter, please consider answering these questions, where
>>> appropriate ***
>>> >
>>> > * What led up to the situation?
>>> >
>>> > I upgraded my system from Buster to Bullseye.  As part of that
>>> process, Samba was upgraded to 4.16.4. After the upgrade, I began receiving
>>> emails reporting a Panic or segfault in Samba everytime a user tried to
>>> access a file share after going idle.
>>>
>>> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
>>> bullseye-backports.
>>> It's okay, it is just that from your statement one might conclude that
>>> upgrade to bullseye
>>> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
>>> installed samba from
>>> backports.
>>>
>>> Also note that across-release upgrades has never been supported in
>>> debian. You can upgrade
>>> from buster version to bullseye version and only after that you can
>>> upgrade to bookworm
>>> version (which is what the bullseye-backport essentially is), but not
>>> from buster directly
>>> to bookworm.
>>>
>>
>> Yes, that's correct. When I upgraded from Buster to Bullseye, the version
>> in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
>> installed the bullseye-backports version to see if it would rectify the
>> issue, but it didn't.
>>
>> Start-Date: 2022-08-31  22:50:37
>> Commandline: apt install -t bullseye-backports samba
>> Requested-By: jason (1000)
>> Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
>> 2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
>> 0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
>> (2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
>> python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
>> python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
>> (2.3.1-2+b1, 2.3.3-4~bpo11+1)
>> End-Date: 2022-08-31  22:52:40
>>
>>
>>>
>>> Tho, I don't think this matters here, - it is just a side note.
>>>
>>> > * What exactly did you do (or not do) that was effective (or
>>> >   ineffective)?
>>> >
>>> > After enabling debug logging, I saw that the panic/segfault was
>>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
>>> failed. Permission denied."
>>> >
>>> > In order to fix the issue, I changed the file ownership of all files
>>> in the above directory to root:sambashare and added my user (jason) to the
>>> sambashare group. After making these changes, the errors went away. I am
>>> reporting this as it's a change in behavior. I did not experience these
>>> segfaults in Buster.  It appears that the expected ownership of this
>>> directory changed, causing my issue.
>>>
>>> That's lovely. It is definitely a bug that samba *crashes* when
>>> usershare dir is not accessible.
>>>
>>> But I don't know if this is actually a bug in the behavior change as you
>>> describe. It seems to
>>> be, but the thing is that usershare permission model always worked like
>>> this. At least as far
>>> as I know.
>>>
>>> In 4.16 I changed the way how usershare directory is handled during
>>> install indeed, with this
>>> commit:
>>>
>>>
>>> 

Bug#1019886: ITP:php-orchestral-testbench-core -- help write tests for your Laravel package

[Katharina Drexel]

Package: wnpp

* Package name: php-orchestral-testbench-core 
  Upstream Author : Mior Muhammad Zaki 
* License : MIT
  Description : Testing Helper for Laravel Development
 Testbench Component is a simple package that has been designed to help you
 write tests for your Laravel package.

Regards
Katharina
-- 

Bug#1018957: mmdebstrap fails in proot mode

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Christoph Groth (2022-09-15 16:31:18)
> Johannes Schauer Marin Rodrigues wrote:
> 
> > Yes. This is because if you just run "mmdebstrap --unshare-helper
> > /usr/sbin/chroot" then it will do nothing else then do a chroot into
> > the given directory. Since you cannot create any device nodes as the
> > unshared user, /dev/null is missing. You can either bind-mound
> > /dev/null and all the other device nodes from the outside yourself or
> > you can use another trick and enter a chroot tarball like this:
> >
> > mmdebstrap --variant=custom --skip=update \
> > --setup-hook='tar-in chroot.tar /' \
> > --customize-hook='chroot "$1" bash' \
> > unstable /dev/null
> 
> Hmm, I tried the above only now and it fails with the following output
> 
> I: automatically chosen mode: unshare

in unshare mode, mknod cannot work. So if you try to "tar-in" a tarball with
device nodes, then you will get that failure. You can remove all entries of the
tarball that are device nodes by puttin mmtarfilter into the pipeline like
this:

mmdebstrap unstable | mmtarfilter --path-exclude='/dev/*' > chroot.tar

> I: chroot architecture amd64 is equal to the host's architecture
> I: automatically chosen format: tar
> I: using /tmp/mmdebstrap.ZYXCWIX0Ip as tempdir
> I: running special hook: tar-in chroot.tar /
> tar: ./dev/console: Cannot mknod: Operation not permitted
> tar: ./dev/full: Cannot mknod: Operation not permitted
> tar: ./dev/null: Cannot mknod: Operation not permitted
> tar: ./dev/ptmx: Cannot mknod: Operation not permitted
> tar: ./dev/random: Cannot mknod: Operation not permitted
> tar: ./dev/tty: Cannot mknod: Operation not permitted
> tar: ./dev/urandom: Cannot mknod: Operation not permitted
> tar: ./dev/zero: Cannot mknod: Operation not permitted
> tar: Exiting with failure status due to previous errors
> E: hookhelper failed: E: tar failed
> E: special hook failed with exit code 512
> I: removing tempdir /tmp/mmdebstrap.ZYXCWIX0Ip...
> 
> The file chroot.tar was created by
> 
>   mmdebstrap unstable chroot.tar
> 
> And the following also works
> 
>   mmdebstrap --customize-hook='chroot "$1" /bin/bash' unstable /dev/null

If you use the "tar-in" method with the automatically selected unshare mode,
then you do not need the device nodes, because they will automatically be
bind-mounted by mmdebstrap once the --customize-hook is run.

You can also read the mmdebstrap man page for "mmtarfilter
--path-exclude='/dev/*'" examples.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1018957: mmdebstrap fails in proot mode

[Christoph Groth]

Johannes Schauer Marin Rodrigues wrote:

> Yes. This is because if you just run "mmdebstrap --unshare-helper
> /usr/sbin/chroot" then it will do nothing else then do a chroot into
> the given directory. Since you cannot create any device nodes as the
> unshared user, /dev/null is missing. You can either bind-mound
> /dev/null and all the other device nodes from the outside yourself or
> you can use another trick and enter a chroot tarball like this:
>
> mmdebstrap --variant=custom --skip=update \
> --setup-hook='tar-in chroot.tar /' \
> --customize-hook='chroot "$1" bash' \
> unstable /dev/null

Hmm, I tried the above only now and it fails with the following output

I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.ZYXCWIX0Ip as tempdir
I: running special hook: tar-in chroot.tar /
tar: ./dev/console: Cannot mknod: Operation not permitted
tar: ./dev/full: Cannot mknod: Operation not permitted
tar: ./dev/null: Cannot mknod: Operation not permitted
tar: ./dev/ptmx: Cannot mknod: Operation not permitted
tar: ./dev/random: Cannot mknod: Operation not permitted
tar: ./dev/tty: Cannot mknod: Operation not permitted
tar: ./dev/urandom: Cannot mknod: Operation not permitted
tar: ./dev/zero: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors
E: hookhelper failed: E: tar failed
E: special hook failed with exit code 512
I: removing tempdir /tmp/mmdebstrap.ZYXCWIX0Ip...

The file chroot.tar was created by

  mmdebstrap unstable chroot.tar

And the following also works

  mmdebstrap --customize-hook='chroot "$1" /bin/bash' unstable /dev/null

Any suggestions?


signature.asc
Description: PGP signature

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen 
wrote:

> -- Forwarded message --
>
>> From: Michael Tokarev 
>> To: Jason Cohen , 1019545-d...@bugs.debian.org
>> Cc:
>> Bcc:
>> Date: Thu, 15 Sep 2022 13:17:28 +0300
>> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
>> /var/lib/samba results in repeated panic or segfault after upgrading from
>> Buster to Bullseye
>> 11.09.2022 19:28, Jason Cohen wrote:
>> > Package: samba
>> > Version: 2:4.16.4+dfsg-2~bpo11+1
>> > Severity: normal
>> >
>> > Dear Maintainer,
>> >
>> > *** Reporter, please consider answering these questions, where
>> appropriate ***
>> >
>> > * What led up to the situation?
>> >
>> > I upgraded my system from Buster to Bullseye.  As part of that process,
>> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
>> reporting a Panic or segfault in Samba everytime a user tried to access a
>> file share after going idle.
>>
>> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
>> bullseye-backports.
>> It's okay, it is just that from your statement one might conclude that
>> upgrade to bullseye
>> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
>> installed samba from
>> backports.
>>
>> Also note that across-release upgrades has never been supported in
>> debian. You can upgrade
>> from buster version to bullseye version and only after that you can
>> upgrade to bookworm
>> version (which is what the bullseye-backport essentially is), but not
>> from buster directly
>> to bookworm.
>>
>
> Yes, that's correct. When I upgraded from Buster to Bullseye, the version
> in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
> installed the bullseye-backports version to see if it would rectify the
> issue, but it didn't.
>
> Start-Date: 2022-08-31  22:50:37
> Commandline: apt install -t bullseye-backports samba
> Requested-By: jason (1000)
> Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
> 2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
> 0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
> (2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
> python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
> python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
> (2.3.1-2+b1, 2.3.3-4~bpo11+1)
> End-Date: 2022-08-31  22:52:40
>
>
>>
>> Tho, I don't think this matters here, - it is just a side note.
>>
>> > * What exactly did you do (or not do) that was effective (or
>> >   ineffective)?
>> >
>> > After enabling debug logging, I saw that the panic/segfault was
>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
>> failed. Permission denied."
>> >
>> > In order to fix the issue, I changed the file ownership of all files in
>> the above directory to root:sambashare and added my user (jason) to the
>> sambashare group. After making these changes, the errors went away. I am
>> reporting this as it's a change in behavior. I did not experience these
>> segfaults in Buster.  It appears that the expected ownership of this
>> directory changed, causing my issue.
>>
>> That's lovely. It is definitely a bug that samba *crashes* when usershare
>> dir is not accessible.
>>
>> But I don't know if this is actually a bug in the behavior change as you
>> describe. It seems to
>> be, but the thing is that usershare permission model always worked like
>> this. At least as far
>> as I know.
>>
>> In 4.16 I changed the way how usershare directory is handled during
>> install indeed, with this
>> commit:
>>
>>
>> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5
>>
>> This means I only create this dir and specify its permissions only at
>> first install, not every
>> install.  But again, this is not really relevant.
>>
>> Now, I don't know which permissions/ownership you files *had* before you
>> changed them.  Please
>> note how this directory is being created:
>>
>> install -d -m 1770 -g sambashare /var/lib/samba/usershares
>>
>> The "1" "sticky" bit tells the kernel to use the same group for all
>> subdirectories and files
>> created within. So you should not need to change the group ownership in
>> the first place. 

Bug#1019883: grep 3.8 warns for potential PCRE regexps without -P

[Paul Gevers]

Package: postgresql-common
Version: 243
Control: clone -1 -2 -3
Control: reassign -2 php8.1-common 8.1.7-1
Control: reassign -3 libxml-sax-perl 1.02+dfsg-3

Dear maintainer,

Recently grep was updated in unstable to upstream release 3.8. You may 
have already noticed that that's a bit of a bumpy ride because grep 
emits new warnings. One of the warnings has already been disabled in 
Debian (see bug #1019335), but others are currently still enabled (see 
bug #1019724). The later bug is about the warning for usage of 
backslashes without defined characters following the backslash. So, this 
is a heads up (the warning will be suppressed soon). Your package emits 
these warning during installation. If upstream grep continues with their 
plan, this might become an error in the future. But, what's more, it 
suggests that something else than the current grep command might have 
been intended.


Could you please investigate?

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-lib-pq/26114898/log.gz

Setting up postgresql-common (243) ...
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before -


https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-riddle/26114780/log.gz

Setting up php8.1-common (8.1.7-1) ...
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /


https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/26114550/log.gz

Setting up libxml-sax-perl (1.02+dfsg-3) ...
update-perl-sax-parsers: Registering Perl SAX parser XML::SAX::PurePerl 
with priority 10...
update-perl-sax-parsers: Updating overall Perl SAX parser modules info 
file...

grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019882: ITP: r-cran-optimparallel -- parallel version of the L-BFGS-B optimization method

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-optimparallel -- parallel version of the L-BFGS-B 
optimization method
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-optimparallel
  Version : 1.0
  Upstream Author : Florian Gerber
* URL : https://cran.r-project.org/package=optimParallel
* License : GPL-2+
  Programming Lang: GNU R
  Description : parallel version of the L-BFGS-B optimization method
 Provides a parallel version of the L-BFGS-B method of optim(). The main
 function of the package is optimParallel(), which has the same usage and
 output as optim(). Using optimParallel() can significantly reduce the
 optimization time.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-optimparallel

Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye

[Michael Tokarev]

15.09.2022 16:58, Jason Wittlin-Cohen wrote:
[]

I chose a snapshot from August 22nd as that was well before I touched any 
permissions or ownership in /var/lib/samba.

8/22/22 var/lib/sambashare:

-rw-r--r-- 1 root root        95 Jun 11  2021 data

So, the user and group ownership is root. "data" was the share causing me problems, and it's the primary share that I access from my Windows systems. 
I think I know why the permissions were wrong. This share, as well as several others, are created by ZFS.  They are not listed in smb.conf.


These shares are created by the following zfs dataset property:

jason@storage-server:~$ zfs get sharesmb data
NAME  PROPERTY  VALUE     SOURCE
data  sharesmb  on        local

The shares listed in smb.conf had correct permissions.  For example:

-rw-r--r-- 1 root sambashare 137 Mar 28  2015 backups1_documents

9/15/22 var/lib/sambashare:

-rw-r--r-- 1 root sambashare  95 Jun 11  2021 data

So, I changed ownership from root:root to root:sambashare. Permissions look 
identical.


This changed nothing. The "data" file can be read by anyone, since
it has identical read permissions for group and for others, so it
doesn't matter which group it is.  Unless ZFS adds its own semantics
for standard Unix rwx model.  With regular filesystem it would have
worked exactly the same either way.

I might be a good idea to capture an strace output of smbd process
when it reported the permission problem.


The other difference is that my user, jason, was not added to the sambashare 
group as of the 8/22/22 snapshot:

8/22/22 /etc/groups:
sambashare:x:121:

9/15/22 /etc/groups:
sambashare:x:121:jason


This, as I mentioned before, is only relevant for *adding* new user shares,
but not for accessing already existing shares. Members of sambashare group
are able to *add* new entries (regular files describing share definitions)
to this directory.

I hope this helps. It appears the behavior I saw was due to the root:root ownership used by ZFS to create shares.  For whatever reason, this worked in 
Buster but caused the crashes once I upgraded to the stable-sec or bullseye-backports versions in Bullseye.


I tried various combinations of permissions here locally, - I can't
reproduce the crashes, but I do see the warning about being unable to
access files within this usershares/ dir in some cases (which are normal
and harmless).

But I don't use and don't have ZFS.

/mjt

Bug#1019881: flash-kernel: please add A20-OLinuXino_MICRO-eMMC configuration

[Daniel Serpell]

Source: flash-kernel
Version: 3.106
Severity: wishlist
Tags: patch

Dear maintainer.

The attached patch adds a configuration for A20-OLinuXino_MICRO-eMMC intoa the
flash-kernel database. This was tested on real hardware, both the deb into a
working system and with the udeb into debian-installer did a sucessfull
installation.

Regards,

Daniel.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
diff -ur flash-kernel-3.106/db/all.db flash-kernel-3.106-dsc/db/all.db
--- flash-kernel-3.106/db/all.db2022-04-22 19:48:49.0 -0400
+++ flash-kernel-3.106-dsc/db/all.db2022-09-15 10:52:06.800664764 -0300
@@ -1268,6 +1268,13 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+Machine: Olimex A20-OLinuXino-MICRO-eMMC
+Kernel-Flavors: armmp armmp-lpae
+Boot-Script-Path: /boot/boot.scr
+DTB-Id: sun7i-a20-olinuxino-micro-emmc.dtb
+U-Boot-Script-Name: bootscr.sunxi
+Required-Packages: u-boot-tools
+
 Machine: Olimex A33-OLinuXino
 Kernel-Flavors: armmp armmp-lpae
 Boot-Script-Path: /boot/boot.scr

Bug#1019872: remove unused scripts

[Thomas Lange]

For the record:

The function setDiffstat in diffstat.js cannot work, since it uses a
non existing domain. Therefore the code in stattrans.pl using
.onClick="setDiffstat
can be removed.

On our webserver I cannot find any occurence of
onClick="setDiffstat..." in any html file.
It seems that the code (see above) in stattrans.pl is not used

-- 
regards Thomas

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

-- Forwarded message --

> From: Michael Tokarev 
> To: Jason Cohen , 1019545-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 15 Sep 2022 13:17:28 +0300
> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
> /var/lib/samba results in repeated panic or segfault after upgrading from
> Buster to Bullseye
> 11.09.2022 19:28, Jason Cohen wrote:
> > Package: samba
> > Version: 2:4.16.4+dfsg-2~bpo11+1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> > * What led up to the situation?
> >
> > I upgraded my system from Buster to Bullseye.  As part of that process,
> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
> reporting a Panic or segfault in Samba everytime a user tried to access a
> file share after going idle.
>
> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
> bullseye-backports.
> It's okay, it is just that from your statement one might conclude that
> upgrade to bullseye
> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
> installed samba from
> backports.
>
> Also note that across-release upgrades has never been supported in debian.
> You can upgrade
> from buster version to bullseye version and only after that you can
> upgrade to bookworm
> version (which is what the bullseye-backport essentially is), but not from
> buster directly
> to bookworm.
>

Yes, that's correct. When I upgraded from Buster to Bullseye, the version
in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
installed the bullseye-backports version to see if it would rectify the
issue, but it didn't.

Start-Date: 2022-08-31  22:50:37
Commandline: apt install -t bullseye-backports samba
Requested-By: jason (1000)
Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1)
End-Date: 2022-08-31  22:52:40


>
> Tho, I don't think this matters here, - it is just a side note.
>
> > * What exactly did you do (or not do) that was effective (or
> >   ineffective)?
> >
> > After enabling debug logging, I saw that the panic/segfault was
> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
> failed. Permission denied."
> >
> > In order to fix the issue, I changed the file ownership of all files in
> the above directory to root:sambashare and added my user (jason) to the
> sambashare group. After making these changes, the errors went away. I am
> reporting this as it's a change in behavior. I did not experience these
> segfaults in Buster.  It appears that the expected ownership of this
> directory changed, causing my issue.
>
> That's lovely. It is definitely a bug that samba *crashes* when usershare
> dir is not accessible.
>
> But I don't know if this is actually a bug in the behavior change as you
> describe. It seems to
> be, but the thing is that usershare permission model always worked like
> this. At least as far
> as I know.
>
> In 4.16 I changed the way how usershare directory is handled during
> install indeed, with this
> commit:
>
>
> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5
>
> This means I only create this dir and specify its permissions only at
> first install, not every
> install.  But again, this is not really relevant.
>
> Now, I don't know which permissions/ownership you files *had* before you
> changed them.  Please
> note how this directory is being created:
>
> install -d -m 1770 -g sambashare /var/lib/samba/usershares
>
> The "1" "sticky" bit tells the kernel to use the same group for all
> subdirectories and files
> created within. So you should not need to change the group ownership in
> the first place. If
> you had to, it means this sticky bit hasn't been there in your case.
> Which, in turn, means
> some local modification you did, probably.
>
> Either way, after you actually changed the 

Bug#992995: mail-expire: Add support to skip new or unread marked mails

[Eduard Bloch]

Hallo,
* Eduard Bloch [Tue, Sep 06 2022, 10:03:24AM]:

> Dev branch: 
> https://salsa.debian.org/blade/mail-expire/-/commits/feat-992995-status-filter

Well okay, once I started implementing the actual code, it became
obvious that this way of filtering does not make much sense. I.e.
separating including/excluding/date filter into different categories gets
overcomplicated and at the same time it limits user's options to combine
them properly.

Instead, I would use something like following, i.e. attaching the
additionial filtering wishes directly to the age specification. Details
as following or see the latest git changes, link above. This obviously
does not cover all corner cases but IMHO it's good enough for all
usecases I came up with.

So you could specify something like:

mail-expire 1,Recent maildir-foo --filter 100,NonRecent --filter 50,Seen 
--filter 7,Deleted
# "never" expire New/Recent mails, after 100 days the spotted ones, after 50
# days the already read mails, and the deleted ones after a week

Opinions?

SYNOPSIS
   mail-expire AGE-IN-DAYS[,FILTERFLAG,...] FILES...
...
   The filter parameter can be extended with additional filter 
specifications (see --filter in options), also multiple alternative filters can 
be specified using options.

   --filter=DAYS,FILTERFLAG,FILTERFLAG,...
   Specifies additional filter(s), with the minimum age in days, and 
optional status flags which turn on or off the consideration of the message for 
expiration. Multiple filters are possible.

   Possible filter flags are: Seen, Recent, Answered, Flagged, Draft, 
Deleted. The meaning can also be inverted by prepending "Not" (like: NotSeen).

   The meaning of Seen and Recent may vary depending on the mail 
storage format and the client editing message metadata.  For Maildir, Recent 
means "still in NEW space" or marked with IMAP "R" flag, and Seen is "MUA marked
   the message as actually read".

Best regards,
Eduard.

Bug#1019833: hugin: Please transition to wxwidgets3.2

[Andreas Metzler]

Control: forwarded -1 https://bugs.launchpad.net/hugin/+bug/1989723

On 2022-09-14 s...@techie.net wrote:
> Source: hugin
> Severity: normal
> Control: block 1019416 by -1

> Hi,

> Please transition hugin from wxwidgets3.0 to wxwidgets3.2.

> wxWidgets 3.2 (a new API/ABI stable release) has been released a few
> months ago and is now packaged in unstable as wxwidgets3.2. Upstream
> has stopped supporting wxWidgets 3.0, so the Debian wx team would
> like to migrate all wx package users to wxwidgets3.2 for bullseye,
> with the plan to remove wxwidgets3.0 before release.

> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some
> packages may require small patches; I'm happy to help with those (and
> I have some already from working on this transition in Fedora
> already).

> Thanks, Scott 

While hugin builds fine against the newer wxWidgets, it does not work
but aborts on startup.

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#1019724: warning: stray \ before - causes autopkgtest failure

[Paul Gevers]

Hi all,

On 15-09-2022 09:26, Paul Gevers wrote:
I am trying to schedule autopkgtests in unstable on amd64 for all source 
packages that have one.


And the first results are coming in. I'm not sure how to proceed though, 
see below.


Lucas, are you in the position to do an archive rebuild to check for the 
grep warnings (see full history at [1]). When you submit bugs, can you 
please file them as important, as apparently upstream wants to turn 
these warnings into failures in the future, but in Debian Santiago is 
going to silence the warning soon, so FTBFS due to this isn't an RC 
problem on the short term.


I wonder if this is going to be useful. The first couple of hits I 
inspected, the warning didn't occur in the autopkgtest itself, but 
during installation of required packages.


E.g.
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/26114550/log.gz
shows the warning while running update-perl-sax-parsers during 
installation libxml-sax-perl


and
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-lib-pq/26114898/log.gz
shows the warning while installing postgresql-common

A lot of tests use postgresql, so weeding that out isn't going to be 
trivial.


Any ideas? (I'll of course file bugs against postqresql-common and 
whatever contains update-perl-sax-parsers, but I'll need more automation 
for the rest) Lucas, do you need to and if so how do you normally handle 
such cases for the rebuilds?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018914: suricata: FTBFS with libbpf 1.0.0

[Sascha Steinbiss]

Hi Sudip,


suricata FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:

util-ebpf.c: In function 'EBPFLoadFile':
util-ebpf.c:375:17: error: implicit declaration of function 
'bpf_program__set_socket_filter'; did you mean 'bpf_program__set_log_level'? 
[-Werror=implicit-function-declaration]
   375 | bpf_program__set_socket_filter(bpfprog);
   | ^~
   | bpf_program__set_log_level
util-ebpf.c:377:17: error: implicit declaration of function 
'bpf_program__set_xdp'; did you mean 'bpf_program__set_type'? 
[-Werror=implicit-function-declaration]
   377 | bpf_program__set_xdp(bpfprog);
   | ^~~~
   | bpf_program__set_type



Thanks for reporting this. This issue is likely due to libbpf 1.0.0 
removing previously deprecated functions, which are still used in 
Suricata's eBPF code. I have found a backwards-compatible fix and am 
currently in contact with upstream.


Best regards
Sascha

Bug#1019880: u-boot: please, build A20-OLinuXino_MICRO-eMMC configuration into u-boot-sunxi

[Daniel Serpell]

Source: u-boot
Version: 2021.01+dfsg-5
Severity: wishlist
Tags: patch

Dear maintainer.

The attached patch builds the configuration for A20-OLinuXino_MICRO-eMMC into
the u-boot-sunxi package. This was tested on real hardware.

Without this, you are unable to use the internal flash included in the board.

Regards,

Daniel.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
diff -ru u-boot-2022.07+dfsg/debian/bin/u-boot-install-sunxi 
u-boot-2022.07+dfsg+dsc/debian/bin/u-boot-install-sunxi
--- u-boot-2022.07+dfsg/debian/bin/u-boot-install-sunxi 2022-04-25 
14:15:00.0 -0400
+++ u-boot-2022.07+dfsg+dsc/debian/bin/u-boot-install-sunxi 2022-09-15 
09:55:07.039177913 -0300
@@ -32,6 +32,7 @@
"Olimex A20-OLinuXino-LIME2") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2" ;;
"Olimex A20-OLinuXino-LIME2-eMMC") 
TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2-eMMC" ;;
"Olimex A20-Olinuxino Micro") 
TARGET="/usr/lib/u-boot/A20-OLinuXino_MICRO" ;;
+   "Olimex A20-OLinuXino-MICRO-eMMC") 
TARGET="/usr/lib/u-boot/A20-OLinuXino_MICRO-eMMC" ;;
"Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
"Olimex A64-Olinuxino-eMMC") 
TARGET="/usr/lib/u-boot/a64-olinuxino-emmc" ;;
"Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
diff -ru u-boot-2022.07+dfsg/debian/targets.mk 
u-boot-2022.07+dfsg+dsc/debian/targets.mk
--- u-boot-2022.07+dfsg/debian/targets.mk   2022-06-30 16:30:55.0 
-0400
+++ u-boot-2022.07+dfsg+dsc/debian/targets.mk   2022-09-15 09:57:24.521225219 
-0300
@@ -451,6 +451,10 @@
   u-boot-sunxi_platforms += A20-OLinuXino_MICRO
   A20-OLinuXino_MICRO_targets := u-boot-sunxi-with-spl.bin uboot.elf
 
+  # Daniel Serpell 
+  u-boot-sunxi_platforms += A20-OLinuXino_MICRO-eMMC
+  A20-OLinuXino_MICRO-eMMC_targets := u-boot-sunxi-with-spl.bin uboot.elf
+
   # Karsten Merker 
   u-boot-sunxi_platforms += A20-Olimex-SOM-EVB
   A20-Olimex-SOM-EVB_targets := u-boot-sunxi-with-spl.bin uboot.elf

Bug#959972: Obsolete binaries?

[Hefee]

Hey,

> On Bullseye (11.5), needrestart seems to think that nextcloud-desktop is
> using (or trying to use) an obsolete binary. One solution would be to
> provide a backport.
> 
> With nextcloud-desktop running, needrestart reports that my user is
> running an outdated binary. Shut it down, and needrestart no longer
> reports the obsolete binary.

this sounds like an bug of needrestart and not about the old version. As 
needrestart checks only if there is a binary that is using an outdated 
library. This is not about any newer version available for a binary.

regards,

hefee

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

Bug#959972: nextcloud-desktop: Please provide a backport for buster

[Hefee]

Hey,

> It would be nice to let users of buster enjoy the improvements since 2.6

I won't do the backport. Others need to do the work. Normally backporting is 
not much work and a good starting point to learn packaging. If anyone needs 
help feel free to ask me!  I will sponser and support it.

regards,

hefee

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

Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory

[Andreas Metzler]

On 2022-09-14 Paul Wise  wrote:
> On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:

>> Is there a way to find all packages built against broken dh-fortran-
>> mod so all affected packages can be rebuilt?

> I am not sure of the correct regex, but the binary package control
> search should work, if it doesn't then you need a local mirror:

> https://binarycontrol.debian.net/?q=%2Fusr%2Flib%2F%5C%24multiarch%2Ffortran%2Fgfortran=

Thank you, I have justed filed a binNMU request #1019876 for the
remaining 4 source packages.

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#1019879: ITP: ppx-hash -- ppx writer generating hash functions

[julien . puydt]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Julien Puydt 
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org
Severity: wishlist

* Package name: ppx-hash
  Version : 0.15.0
  Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/ppx_hash
* License : Expat
  Programming Lang: OCaml
  Description : ppx writer generating hash functions
 This package provides a ppx writer generating hash functions
 from type expressions and definitions

I plan to support it within the Debian Ocaml Maintainers team ; it's a
dep for a Coq-related package I'm targetting.

Cheers,

J.Puydt

Bug#1019878: Please disable -mtune=native for "parisc" too

[Helge Deller]

Package: mrpt
Version: 1:2.5.3+ds-2
Tags: ftbfs, hppa

You added a check in CMakeLists.txt for parisc64 to disable uasge of 
-mtune=native.
Please enhance this check to include "parisc" as well.
Reason is, that we have build servers which run either a 32- or 64-bit kernel,
and the 32-bit ones report "parisc" for "uname -m" instead of "parisc64".
See:
https://buildd.debian.org/status/fetch.php?pkg=mrpt=hppa=1%3A2.5.3%2Bds-2=1663229594=0

Thanks,
Helge--- debian/rules.org	2022-08-17 06:09:55.850853504 +
+++ debian/rules	2022-08-17 06:10:21.906723720 +
@@ -13,6 +13,8 @@
 CFLAGS := $(shell dpkg-buildflags --get CPPFLAGS; dpkg-buildflags --get CFLAGS)
 CXXFLAGS := $(shell dpkg-buildflags --get CPPFLAGS; dpkg-buildflags --get CXXFLAGS)
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
+CFLAGS   += -D_LARGE_FILE_SOURCE=1  -D_FILE_OFFSET_BITS=64
+CXXFLAGS += -D_LARGE_FILE_SOURCE=1  -D_FILE_OFFSET_BITS=64
 export CFLAGS
 export CXXFLAGS
 export LDFLAGS

Bug#1019877: Please update libldac to a newer upstream snapshot

[Amr Ibrahim]

Package: libldac

Hello,

It seems that libldac has not been updated for two years.

This is a friendly reminder to update libldac to a newer upstream snapshot if 
you see fit.

Best,
Amr

Bug#1019876: nmu: atlas-ecmwf_0.30.0-3

[Andreas Metzler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: ametz...@bebt.de, dh-fortran-...@packages.debian.org

Hello,

according to 
https://binarycontrol.debian.net/?q=%5Ermdir+--ignore-fail-on-non-empty+%2Fusr%2Flib%2F%5C%24multiarch%2Ffortran%2Fgfortran=
there are still 4 packages built with broken dh-fortran-mod.

nmu atlas-ecmwf_0.30.0-3 . ANY . unstable . -m "Rebuild with fixed 
dh-fortran-mod (See #1019050)"
nmu cdo_2.0.6-2 . ANY . unstable . -m "Rebuild with fixed dh-fortran-mod (See 
#1019050)"
nmu petsc_3.17.4+dfsg1-1 . ANY . unstable . -m "Rebuild with fixed 
dh-fortran-mod (See #1019050)"
nmu slepc_3.17.2+dfsg1-2 . ANY . unstable . -m "Rebuild with fixed 
dh-fortran-mod (See #1019050)"

TIA, cu Andreas

Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye

[Michael Tokarev]

15.09.2022 13:17, Michael Tokarev wrote:
...

Now, I don't know which permissions/ownership you files *had* before you 
changed them.  Please
note how this directory is being created:

    install -d -m 1770 -g sambashare /var/lib/samba/usershares

The "1" "sticky" bit tells the kernel to use the same group for all 
subdirectories and files
created within. So you should not need to change the group ownership in the 
first place. If
you had to, it means this sticky bit hasn't been there in your case. Which, in 
turn, means
some local modification you did, probably.


This is ofc incorrect, sticky bit has nothing to do with the group
ownership.

Now, the files *within* /var/lib/samba/usershares/ dir should belong to whatever
user/group who created them, definitely not to root:sambashare. More, if these
belong to root, usershare owner only (default yes) will prevent 
removing/modifying
shares by using `net usershare' command.  Only this directory itself should 
belong
to group sambashare.

And your user definitely should have write access to this directory in order to 
*add*
share definitions by using `net usershare add' etc commands.  Not for *using* 
the
already defined shares but to *add* them.


Either way, after you actually changed the ownership/permission bits, it's 
impossible to
see what the actual problem was.


I still don't know which ownership/permissions you did have.  I tried to 
replicate
this issue, - I can trigger this warning in the smbd logfile:

[2022/09/15 14:06:28.521611,  0] 
../../source3/param/loadparm.c:3454(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/data failed. 
Permission denied

but there's no crashes, it is just a warning.

So it must be something specific to your configuration.

/mjt

Bug#1003397:

[Nobuhiro Iwamatsu]

Hi Daichi,

2022年9月7日(水) 23:09 Daichi Fukui :
>
> Hello Iwamatsu-san,
>
> I have drafted a source package for debugbreak.
> Kindly find the URL below for the latest source package (Upload #3).
> https://mentors.debian.net/package/debugbreak/
>
> I would appreciate it if you review the source package.
>

Thanks updating package.
I just upload. if you have a iusse about this package, let me know.

Best regards,
   Nobuhiro

Bug#1014120: libowfat FTBFS: ln: failed to create hard link 'libowfat/buffer.h'

[Bastian Germann]

Am 15.09.22 um 03:35 schrieb Bo YU:

It was the new issue:


When that is fixed, the buildds are going to bump into this one again.
No need to reference unrelated issues.

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Moritz Schlarb]

Hi everyone,

I'd be happy to help with this package, too.
Please also add me to the Salsa group when possible.

Regards,
Moritz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019875: node-unicode-data: Update for Unicode 15

[Jeremy Bicha]

Source: node-unicode-data
Version: 0~20211027+git243f19e8-4
Severity: wishlist
Control: forwarded -1
https://github.com/node-unicode/node-unicode-data/commits/main

Please update node-unicode for Unicode 15.

unicode-data 15 was just uploaded to Debian Unstable.

It looks like node-unicode-data has been updated upstream already.
https://github.com/node-unicode/node-unicode-data/commits/main

Thank you,
Jeremy Bicha

Bug#1014853: please remove luajit2 on ppc64el now

[Paul Gevers]

Control: retitle -1 RM: luajit2 [ppc64el] -- ROP; segfaults

Hi,

On Wed, 13 Jul 2022 11:07:07 +0200 Paul Gevers  wrote:

All ppc64el reverse dependencies of luajit have been removed from
testing. I think it's best to remove all luajit related binaries on 
ppc64el now, so please remove:


src:luajit, src:luajit2, src:aegisub, src:luakit, src:snort and
src:uwsgi-plugin-luajit from ppc64el.


If my dak command and rmadison commands didn't fail me, I think the only 
thing left to do is removal of luajit2 on ppc64el. luajit and luajit2 
stopped building on ppc64el and all reverse (build) dependencies were 
already removed on that architecture.


Paul

elbrus@coccia:~$ dak rm --no-action -RB luajit2 --architecture=ppc64el
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libluajit2-5.1-2 | 2.1-20220411-5 | ppc64el
libluajit2-5.1-dev | 2.1-20220411-5 | ppc64el
   luajit2 | 2.1-20220411-5 | ppc64el

Maintainer: Debian Lua Team 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
lua-resty-core: lua-resty-core
lua-resty-lrucache: lua-resty-lrucache

# Broken Build-Depends:
libnginx-mod-http-lua: libluajit2-5.1-dev
sysbench: libluajit2-5.1-dev

Dependency problem found.


paul@mulciber ~ $ rmadison -s testing -s unstable sysbench 
libnginx-mod-http-lua lua-resty-lrucache lua-resty-core
libnginx-mod-http-lua | 1:0.10.21-2   | unstable   | source, amd64, 
arm64, armel, armhf, i386, mips64el, mipsel, s390x

lua-resty-core| 0.1.23-5  | unstable   | source, all
lua-resty-lrucache| 0.13-7| unstable   | source, all
sysbench  | 1.0.20+ds-5   | unstable   | source, amd64, 
arm64, armel, armhf, i386, mips64el, s390x



paul@mulciber ~/debian-maint/ci.d.n-config $ rmadison luajit luajit2 
libluajit-5.1-2 libluajit2-5.1-2 libluajit-5.1-dev libluajit-5.1-common 
libluajit2-5.1-common libluajit2-5.1-dev  -s unstable
libluajit-5.1-2   | 2.1.0~beta3+git20220320+dfsg-4.1 | unstable   | 
amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x

libluajit-5.1-common  | 2.1.0~beta3+git20220320+dfsg-4.1 | unstable   | all
libluajit-5.1-dev | 2.1.0~beta3+git20220320+dfsg-4.1 | unstable   | 
amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x
libluajit2-5.1-2  | 2.1-20220411-5   | unstable   | 
ppc64el
libluajit2-5.1-2  | 2.1-20220411-5.1 | unstable   | 
amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x

libluajit2-5.1-common | 2.1-20220411-5   | unstable   | all
libluajit2-5.1-common | 2.1-20220411-5.1 | unstable   | all
libluajit2-5.1-dev| 2.1-20220411-5   | unstable   | 
ppc64el
libluajit2-5.1-dev| 2.1-20220411-5.1 | unstable   | 
amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x
luajit| 2.1.0~beta3+git20220320+dfsg-4.1 | unstable   | 
source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x
luajit2   | 2.1-20220411-5   | unstable   | 
source, ppc64el
luajit2   | 2.1-20220411-5.1 | unstable   | 
source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019874: python3-specutils: FTBFS on riscv64, segfault in Fortran library

[Blair Noctis]

Package: python3-specutils
Version: 1.8.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: n...@sail.ng

Dear Maintainer,

This package currently fails a test on riscv64 (buildd log [1]):

> specutils/io/asdf/tags/tests/test_spectra.py .   [  
> 1%]
> specutils/io/default_loaders/tests/test_apogee.py sss[  
> 1%]
> specutils/io/default_loaders/tests/test_jwst_reader.py . [  
> 5%]
> xsss.[  
> 6%]
> specutils/manipulation/model_replace.py Fatal Python error: Segmentation fault
> 
> Current thread 0x003fa5ed5010 (most recent call first):
>   File "/usr/lib/python3/dist-packages/scipy/linalg/_basic.py", line 464 in 
> solve_banded
>   File "/usr/lib/python3/dist-packages/scipy/interpolate/_cubic.py", line 781 
> in __init__
>   File 
> "/<>/.pybuild/cpython3_3.10/build/specutils/manipulation/model_replace.py",
>  line 171 in _interpolate_spline
>   File 
> "/<>/.pybuild/cpython3_3.10/build/specutils/manipulation/model_replace.py",
>  line 155 in _compute_spline_values
>   File 
> "/<>/.pybuild/cpython3_3.10/build/specutils/manipulation/model_replace.py",
>  line 79 in model_replace
>   File "", 
> line 1 in 

segfault happened when `solve_banded` called into a runtime chosen variant of
LAPACK procedure `gtsv`, which in local testing was `dgtsv`.

1:
https://buildd.debian.org/status/fetch.php?pkg=specutils=riscv64=1.8.0-1=1661681347=0

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

-- 
Regards,
Blair Noctis




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019873: liblemonldap-ng-portal-perl: Authentication fails with LDAP+2FA

[Yadd]

Package: liblemonldap-ng-portal-perl
Version: 2.0.15+ds-1
Severity: important
Tags: upstream

According to
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2796
Lemonldap::NG portal is unusable when users try to authenticate using
LDAP and a second factor.

Upstream is going to publish a new release soon

Bug#909323: zathura: Blocks in full width mode.

[Dietrich Clauss]

Package: zathura
Followup-For: Bug #909323

After upgrade to Bullseye, I'm no longer able to trigger this bug.  It
seems that it has been fixed.

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 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 zathura depends on:
ii  libc62.31-13+deb11u4
ii  libcairo21.16.0-5
ii  libgirara-gtk3-3 0.3.5-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libmagic11:5.39-3
ii  libpango-1.0-0   1.46.2-3
ii  libseccomp2  2.5.1-1+deb11u1
ii  libsqlite3-0 3.34.1-3
ii  libsynctex2  2020.20200327.54578-7
ii  zathura-pdf-poppler  0.3.0-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  firefox-esr [www-browser]  91.13.0esr-1~deb11u1
ii  links [www-browser]2.21-1+b1
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  w3m [www-browser]  0.5.3+git20210102-6
pn  zathura-cb 
pn  zathura-djvu   
pn  zathura-ps 

-- no debconf information

Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck

[Philip Hands]

Vagrant Cascadian  writes:

> On 2022-09-14, Philip Hands wrote:
>> Vagrant Cascadian  writes:
>>
 but also
 (given that the tests will have passed during the normal build) the tests
 failing during the varied build seems unlikely to be identifying faults 
 that are
 worth fixing, and so is just a waste of cycles.
>>>
>>> How do you know weather the bugs it is identifying are worth fixing? It
>>> could also identify non-deterministic failures, or failures triggered by
>>> specific build environment configurations...
>>
>> The point is that if the package is reproducible, then the fact that its
>> tests fail when run in a weird environment (that may never be found in
>> the wild) seems rather likely to be finding errors in the tests rather
>> than errors in the program that gets shipped.
>
> Fair point! 
>
>> Of course, if the package is not reproducible, the tests may well fail
>> because the package ends up containing new bugs that are only present in
>> the variant-built package, but then its also going to show up as
>> non-reproducible, so does that really make a difference?
>
> True, though it may make things harder to verify reproducibility in
> practice, especially if it is a fairly "normal" variation that triggers
> the issue...
>
>
> It is a balancing act...
>
> I guess I'd be fine with the defaults to go either way, but it would be
> important to be able to enable or disable however this gets implemented.

Absolutely.  That's why I was requesting that it be a variation in its
own right, since that should allow one to specify:

  --variations=-nocheck

and get a normal (with checks) build in the varied scenario.

BTW If someone can give me a hint where in the code one would define
such a variation I'll cheerfully give it a go myself, but sadly it seems
that my python is too weak to find the right spot for myself.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1015853: sbuild: fails to use foreign --extra-package

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + moreinfo

Hi,

On Fri, 22 Jul 2022 14:58:22 +0200 Helmut Grohne  wrote:
> Antonio attempted cross building a ruby extension with a custom gem2deb
> and tried doing so with sbuild --extra-package. Apparently, that didn't
> work out.
> 
> I tried:
> 
> sbuild --host=arm64 -d unstable --extra-package=./hostname_..._arm64.deb 
> hostname
> 
> This is kinda stupid, I know, but we see this:
> 
> | Err:4 file:/build/hostname-emvq9a/resolver-5aZssX/apt_archive ./ Packages
> |   Could not open file 
> /build/hostname-emvq9a/resolver-5aZssX/apt_archive/./Packages - open (13: 
> Permission denied)
> 
> In particular, my foreign hostname wasn't installed.
> 
> I think Antonio has found a bug.

there is a bug, yes. I am able to create a situation in which I see that line
in my log.

But I cannot reproduce the failure to install a foreign architecture binary
package passed via --extra-package. I chose src:hello to test this. I first
bumped the version with `dch -i` and then cross-built it normally to produce
hello_2.10-2.1_arm64.deb. I then added "hello:arm64 (=2.10-2.1)" to the
Build-Depends and rebuilt again with
--extra-package=/tmp/hello_2.10-2.1_arm64.deb and I get this:

Get:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages [630 B]
Err:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages
  Could not open file 
/build/hello-OnCNa2/resolver-xXDWfu/apt_archive/./Packages - open (13: 
Permission denied)
Get:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages [969 B]
[...]
Get:2 file:/<>/resolver-xXDWfu/apt_archive ./ hello 2.10-2.1 [58.2 kB]
[...]
Selecting previously unselected package hello:arm64.
Preparing to unpack .../076-hello_2.10-2.1_arm64.deb ...
Unpacking hello:arm64 (2.10-2.1) ...
[...]
Setting up hello:arm64 (2.10-2.1) ...

So yes, there is an error message from apt (no idea why it is produced yet) but
the package gets installed.

Do you have a full build log of your build failure?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19

[Emanuele Rocca]

Hi,

On 15/09 02:35, Z Y wrote:
> During testing systemtap 4.7 with kernel 5.19, I found it can't resolve
> some global variables of nginx.
> However systemtap 4.7 can resolve them if test with kernel 5.10.

Which variables exactly? Can you share a sample script reproducing the
issue?

Thanks for the bug report!

  Emanuele

Bug#1019872: remove unused scripts

[Thomas Lange]

Package: www.debian.org
Severity: normal


On IRC we had a discussion if the script
english/devel/website/stats/anoncvs-cors is still used. It seems that
more parts concerning the translations stats are not needed any more.



< Mrfai> Is this script used anywere:
english/devel/website/stats/anoncvs-cors ? I cannot find anything and would 
like to remove it
< Mrfai> There's only a link to 
http://webwml.alioth.debian.org/cgi-bin/anoncvs-cors in diffstat.js but I think 
this function is not used any more.
< pabs> `git grep` says stattrans.pl emits calls to setDiffstat in the onClick 
attribute of a  tag
< pabs> Mrfai: I think the onclick=setDiffstat can probably just be replaced 
with  or maybe the compare URLs 
< pabs> hmm, it wants diffstats not full patches...
< pabs> if the exact functionality is still wanted, then maybe the script could 
migrate to cgi.debian.org
< pabs> probably best to ask debian-i18n if the diffstat is useful
< Mrfai> pabs: But I cannot find any reference of this onlick in the html files.
< Mrfai> I did this:
< Mrfai> ...@wolkenstein:/srv/www.debian.org/www/international$ grep -r 
setDiffstat .
< Mrfai> And it found nothing
< pabs> I'm looking at stattrans again
< pabs> hmm, the Diffstat column is definitely present 
https://www.debian.org/devel/website/stats/en
< pabs> seems the diffstat link is only shown if "!defined $status_db{$lang}"
< pabs> which looks like the english/international/l10n/data/status.* files
< pabs> seems english/international/l10n/scripts/gen-files.pl creates those 
files
< pabs> those files do exist on wolkenstein
< pabs> they are symlinks to /srv/www.debian.org/cron/datafiles/status.*
< pabs> Sledge's a3fcc21a7c098056a557a095178aee9f752d6059 deleted a previous 
use of diffstat stuff, adding git command-lines instead, so it sounds like the 
web team 
wants translators to manually do diffstats 
themselves, so I guess delete the diffstat column and all the supporting 
infrastructure

Bug#1014573: sbuild-debian-developer-setup: Add option to use a specific mirror instead of apt-cacher-ng

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + help moreinfo

Hi Ben,

Quoting Michael Stapelberg (2022-09-15 08:57:47)
> On Wed, 14 Sept 2022 at 08:10, Johannes Schauer Marin Rodrigues 
>  wrote:
> > On Fri, 08 Jul 2022 02:35:50 -0400 Ben Westover 
> > wrote:
> > > wrote: I was trying to create an Ubuntu schroot for sbuild using the
> > > command sbuild-debian-developer-setup --distribution=ubuntu --suite=jammy
> > > and debootstrap failed because it tried to use apt-cacher-ng, which
> > > doesn't work for Ubuntu if you're on Debian, and vice versa. This would
> > > be solved with an option that can specify the mirror to use in place of
> > > apt-cacher-ng.  Alternatively, sbuild-debian-developer-setup could do a
> > > sanity check on apt-cacher-ng, and if it fails, switch to
> > > http://deb.debian.org/debian or http://archive.ubuntu.com/ubuntu.
> >
> > I'm going to take care of the other sbuild-debian-developer-setup related
> > bugs in the bts (#1014574 and #1006135 -- I am going to comply with both
> > requests unless you have any objections). In turn, could you take care
> > about this bug?
> Unfortunately I don’t have time to do any development on
> sbuild-debian-developer-setup, so I can’t help with this bug.
> 
> Maybe Ben can try and send a patch?

the package has "debian" in its name so I think it's fair to assume that a
setup for ubuntu is not in its default scope.

But maybe you can prepare a sensible patch and either send it to this bug or as
a merge request on https://salsa.debian.org/debian/sbuild as suggested by
Michael?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019593: hp-plugin: Failure to download plugin

[martin f krafft]

Regarding the following, written by "Brian Potkin" on 2022-09-14 at 23:10 Uhr 
+0100:
On unstable libsane1 installs the recommended sane-airscan. This 
gives driverless scanning, which is supported by your deice. Color 
me perplexed! Please give


scanimage -L 
airscan-discover


This makes me hopeful. However, I've shoved the printer into a VLAN 
of its own given how much bloody traffic I saw it generate out of 
nothing, and so now of course DNS-SD doesn't work out of the box, 
and I have not figured out how to coax it into submission yet.


But I'll give this a shot soon. Driverless printing and scanning! 
Wow!


Thanks,

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"in the figure of the president, george w. bush, the incompetence,

 stupidity, and sheer inhumanity that characterize so much of
 america's money-mad corporate elite find their quintessentially
 repulsive expression."
 -- journalist, aftermath of katrina

Bug#1019334: Webkit2gtk - Bug Report

[Alberto Garcia]

Control: tags -1 moreinfo

On Wed, Sep 07, 2022 at 04:14:20PM +0200, Henning Sprang wrote:

> I have massive problems with Webbrowsers constantly crashing as soon
> as I do anything serious on webpages with JavaSCript in them.

Does it happen with all of them?

What exact CPU model do you have? (see 'model name' in /proc/cpuinfo).

Try also running epiphany from a terminal like this:

$ JavaScriptCoreUseJIT=0 epiphany

Does it also crash?

Berto

Bug#790750: Franz Schrober hat eine Empfehlung für den folgenden Link ausgesprochen

[Touhid Muntashir]

Schon ausprobiert? https://bit.ly/3QNHKHn

Bug#761045: Erstaunliche Lösung, die Franz Schrober mit Ihnen teilen möchte

[Touhid Muntashir]

 agieren! https://8909c.app.link/inYVGddQjtb

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Emilio Pozuelo Monfort]

On 14/09/2022 15:42, Santiago R.R. wrote:

El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió:

On 13/09/2022 16:46, Sylvain Beucler wrote:

Hi,

IIUC this is about fixing 2 non-security bugs, that were introduced
prior to buster's initial release.

I personally don't think this fits the LTS project scope.
Maybe other LTS members will have a different opinion.


We've had bugfix updates from time to time. They are rare, but not
forbidden. This should go in a buster suite rather than buster-security, but
since there's no such suite for LTS, having it in buster-security is the
lesser evil. Of course we shouldn't flood -security with bug fixes, if that
was necessary we should consider keeping $stable open and handled by the LTS
team (but that doesn't seem necessary at this point).

In this case, since the update has been prepared and looks sensible, I'll go
ahead with the upload if nobody objects.



Thanks, Emilio. Also consider
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15

Haven't tested yet myself. But I suppose I should apply it in unstable.


For buster I'd rather use what was proposed for buster-pu, as that's also what 
is in bullseye.


Cheers,
Emilio

Bug#1017993: reverse dependencies

[Paul Gevers]

Hi Samuel,

On Fri, 26 Aug 2022 18:05:41 + (UTC) Thorsten Alteholz 
 wrote:

Control: tags -1 + moreinfo

Hi Samuel,

there are reverse dependencies that needs to be taken care of:


Checking reverse dependencies...
# Broken Depends:
bully: bully
forensics-all: forensics-all
mdk3: mdk3
mdk4: mdk4
wifite: wifite

# Broken Build-Depends:
wifite: aircrack-ng


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


   Thorsten


You may have missed the question from Thorsten as I don't see you in the 
TO or CC. Can you have a look? aircrack-ng is out-of-sync between 
unstable and testing due to this.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019849: python3-virtualenv: Please do not depend on python3-pip

[stefanor]

Hi Benjamin (2022.09.15_07:26:00_+)
> This looks like an accident. Probably coming from the upstream's Python
> packaging metadata. Thanks for catching it!

Oh, no, spoke too soon. This was added manually for pip 20.  Possibly
for the pip seeder?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1019849: python3-virtualenv: Please do not depend on python3-pip

[Stefano Rivera]

Hi Benjamin (2022.09.14_22:04:46_+)
> It's not apparent why this dependency was added, since
> python3-virtualenv now depends on *both* python3-pip and
> python-pip-whl.  And the basic functionality, at least, of
> /usr/bin/virtualenv works correctly after forcibly removing the
> python3-pip package.

This looks like an accident. Probably coming from the upstream's Python
packaging metadata. Thanks for catching it!

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Paul Gevers]

Hi Santiago, Lucas,

On 14-09-2022 17:31, Santiago Ruano Rincón wrote:

Note that the release team issued a block for now:

https://release.debian.org/britney/hints/jcristau

and proposed to test with a archive rebuild before introducing it again.



Dear Release Team, just to be sure of being on the same page: if you are
proposing to rebuild the whole archive, should I wait before silencing
the warnings, for being able to (mass-)bug filing?


I am trying to schedule autopkgtests in unstable on amd64 for all source 
packages that have one.


Lucas, are you in the position to do an archive rebuild to check for the 
grep warnings (see full history at [1]). When you submit bugs, can you 
please file them as important, as apparently upstream wants to turn 
these warnings into failures in the future, but in Debian Santiago is 
going to silence the warning soon, so FTBFS due to this isn't an RC 
problem on the short term.


Santiago, please keep the grep with warning in unstable until either all 
tests are finished or we abort this plan.


Paul

[1] https://bugs.debian.org/1019724


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019871: minetest: Please, update to new version 5.6.0

[david]

Package: minetest
Version: 5.5.0+dfsg+~1.9.0mt4+dfsg-2
Severity: minor

Dear Maintainer,

The rest of Linux distributions have updated it ;)

Thank you.

-- 
David

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 minetest depends on:
ii  libc6 2.34-7
ii  libcurl3-gnutls   7.85.0-1
ii  libfreetype6  2.12.1+dfsg-3
ii  libgcc-s1 12.2.0-1
ii  libgl11.5.0-1
ii  libgmp10  2:6.2.1+dfsg1-1
ii  libjpeg62-turbo   1:2.1.2-1
ii  libjsoncpp25  1.9.5-4
ii  libleveldb1d  1.23-3
ii  libluajit-5.1-2   2.1.0~beta3+git20220320+dfsg-4.1
ii  libncursesw6  6.3+20220423-2
ii  libopenal11:1.19.1-2
ii  libpng16-16   1.6.37-5
ii  libpq514.5-1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.39.3-1
ii  libstdc++612.2.0-1
ii  libtinfo6 6.3+20220423-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.8.1-2
ii  libxxf86vm1   1:1.1.4-1+b2
ii  libzstd1  1.5.2+dfsg-1
ii  minetest-data 5.5.0+dfsg+~1.9.0mt4+dfsg-2
ii  zlib1g1:1.2.11.dfsg-4.1

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
pn  minetestmapper   

-- no debconf information

Bug#1014573: sbuild-debian-developer-setup: Add option to use a specific mirror instead of apt-cacher-ng

[Michael Stapelberg]

Thanks for taking care of the other bugs!

Unfortunately I don’t have time to do any development on
sbuild-debian-developer-setup, so I can’t help with this bug.

Maybe Ben can try and send a patch?

On Wed, 14 Sept 2022 at 08:10, Johannes Schauer Marin Rodrigues <
jo...@debian.org> wrote:

> Hi Michael,
>
> On Fri, 08 Jul 2022 02:35:50 -0400 Ben Westover 
> wrote:
> > I was trying to create an Ubuntu schroot for sbuild using the command
> > sbuild-debian-developer-setup --distribution=ubuntu --suite=jammy and
> > debootstrap failed because it tried to use apt-cacher-ng, which doesn't
> work
> > for Ubuntu if you're on Debian, and vice versa. This would be solved
> with an
> > option that can specify the mirror to use in place of apt-cacher-ng.
> > Alternatively, sbuild-debian-developer-setup could do a sanity check on
> > apt-cacher-ng, and if it fails, switch to http://deb.debian.org/debian
> or
> > http://archive.ubuntu.com/ubuntu.
>
> I'm going to take care of the other sbuild-debian-developer-setup related
> bugs
> in the bts (#1014574 and #1006135 -- I am going to comply with both
> requests
> unless you have any objections). In turn, could you take care about this
> bug?
>
> Thanks!
>
> cheers, josch



-- 
Best regards,
Michael

Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19

[Z Y]

Package: systemtap
Version: 4.7-1

Package: linux-image-amd64
Version: 5.19.6

During testing systemtap 4.7 with kernel 5.19, I found it can't resolve
some global variables of nginx.
However systemtap 4.7 can resolve them if test with kernel 5.10.

According to output below, systemtap 4.7-1 is only tested with kernel
version from 2.6.32 to 5.18-rc3

% stap -V
> Systemtap translator/driver (version 4.7/0.187, Debian version 4.7-1)
> Copyright (C) 2005-2022 Red Hat, Inc. and others
> This is free software; see the source for copying conditions.
> tested kernel versions: 2.6.32 ... 5.18-rc3
> enabled features: AVAHI BPF LIBSQLITE3 NLS NSS
>
>
> % apt policy linux-image-amd64
> linux-image-amd64:
>   Installed: 5.19.6-1
>   Candidate: 5.19.6-1
>   Version table:
>  *** 5.19.6-1 990
> 990 http://cdn-aws.deb.debian.org/debian testing/main amd64
> Packages
> 100 /var/lib/dpkg/status
>  5.18.16-1~bpo11+1 100
> 100 http://cdn-aws.deb.debian.org/debian stable-backports/main
> amd64 Packages
>  5.10.140-1 500
> 500 http://cdn-aws.deb.debian.org/debian stable/main amd64
> Packages
>  5.10.136-1 500
> 500 http://cdn-aws.deb.debian.org/debian-security
> stable-security/main amd64 Packages
>  4.19+105+deb10u16 500
> 500 http://cdn-aws.deb.debian.org/debian oldstable/main amd64
> Packages
> 500 http://cdn-aws.deb.debian.org/debian-security
> oldstable/updates/main amd64 Packages
>
> % apt policy systemtap
> systemtap:
>   Installed: 4.7-1
>   Candidate: 4.7-1
>   Version table:
>  *** 4.7-1 990
> 990 http://cdn-aws.deb.debian.org/debian testing/main amd64
> Packages
> 100 /var/lib/dpkg/status
>  4.4-2 500
> 500 http://cdn-aws.deb.debian.org/debian stable/main amd64
> Packages
>  4.0-1 500
> 500 http://cdn-aws.deb.debian.org/debian oldstable/main amd64
> Packages
>

With Regards
Yibin

Bug#1019868: godot: ftbfs on riscv64 ("undefined reference to `__atomic_compare_exchange_1'")

[Bo YU]

Source: godot
Version: 3.2.3-stable-1
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The package has a ftbfs issue due to:

usr/include/c++/11/bits/atomic_base.h:571: undefined reference to 
`__atomic_compare_exchange_1'


The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=godot=riscv64=3.2.3-stable-1=1635495260=0

The patch attached is to fix the issue and I have tested it on my
local real riscv64 hardware.

please let me know if there are any issues.

-- 
Regards,
--
  Bo YU

diff -Nru godot-3.2.3-stable/debian/rules godot-3.2.3-stable/debian/rules
--- godot-3.2.3-stable/debian/rules 2020-10-28 12:56:05.0 +
+++ godot-3.2.3-stable/debian/rules 2020-10-28 12:56:05.0 +
@@ -7,6 +7,11 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+# Link with libatomic on riscv64
+ifeq ($(DEB_HOST_ARCH),riscv64)
+   export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
 override_dh_clean:
dh_clean
scons -c


signature.asc
Description: PGP signature