Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

[Dr. Burkard Lutz]

Am Samstag, dem 30.03.2024 um 11:43 -0700 schrieb Dima Kogan:
> "Dr. Burkard Lutz"  writes:
> 
> > The actual version ("0.34") is the first which contains all desired
> > functions, and after extensive testing I hope that there are only
> > minor bugs left.
> 
> Thanks for explaining.
> 
> 
> > Therfore I decided to make an attempt for publishing it on debian.
> > Should I rename it to "0.10"?
> 
> No. 0.34 is fine. I just wanted to understand the state of things
> 
> 
> > Now you can see the project under the following address:
> > https://gitlab.com/b.lutz1/galvani I changed the group name to
> > "galvani" but the path to the project remained the same.
> 
> OK. Excellent. A distro-agnostic location to host the upstream
> version
> control is desirable. You do your development there, and when you're
> ready to release, you should make a tag. Currently there aren't any:
> 
>   https://gitlab.com/b.lutz1/galvani/-/tags
> 
> To indicate which commit, exactly is being released, you should make
> a
> tag called 'v0.34' or '0.34' or something like that.
> 
I created 2 tags (v0.34 and v0.34-2, the later for some corrections I
had to make in the debian-directory).

> Once you make a tab, gitlab will create a tarball with your sources
> at
> that tag. This is your "release tarball".
> 
I created a release on gitlab. Should I create it on salsa too?

> The debianization repo should live on salsa. Generally you have 3
> branches:
> 
> - "pristine-tar" contains the release tarballs
> 
> - "upstream" contains the unpacked upstream sources. Each upstream
>   release is one commit
> 
> - "master" branches off "upstream"; contains the debianization
> 
I created the branch pristine-tar (took me some time to find out how it
works ...). The master-branch ist called "main" in my repository. Is
that ok?

> This isn't the "best" way to do it, but it's how most packages are
> set
> up. Look around on salsa; you'll see this layout everywhere. The
> "gbp"
> tool is useful to manipulate the debianized repo. In particularly,
> you
> can import new release tarballs with
> 
>   gbp import-orig --pristine-tar whatever.tar.gz
> 
> The upstream release tarball location is encoded in the debian/watch
> file. The "uscan" tool is used to interpret this file, and to see if
> new
> release tarballs are available, and to download them. In order for
> this
> to work, debian/watch has to be written properly. This is described
> here:
> 
>   https://wiki.debian.org/debian/watch
> 
> It looks like gitlab keeps changing their file layout, so you'll need
> to
> play with it until
> 
>   uscan --verbose --report-status
> 
> sees your tarball.
> 
I corrected my debian/watch. It works now properly.

> 
> > I saw that you are a member of debian-science-team. Did you have
> > some
> > time so far to have a look at my project? Do you think debian-
> > science-
> > team could be interested in that project?
> 
> Yes. Joining a team is what you usually want. It doesn't mean that
> somebody else will fix all your problems (you're still the primary
> maintainer), but it's a signal that if a team member wants to fix
> stuff
> while you're not available, you're ok with that.
> 
> debian-science is a fine place for this. Follow the policy:
> 
>   https://science-team.pages.debian.net/policy/
> 
> Mostly it means that you put your debianization into their
> subdirectory
> on salsa:
> 
>   https://salsa.debian.org/science-team/
> 
> And that you set the team to be the Maintainer and yourself as the
> Uploader. Read the policy.
> 
> 
> > I'm looking for a sponsor to publish the project on debian. Can you
> > perhaps help me in that issue?
> 
> Sure. Try to make a debianized repository as I described above, and
> let
> me know when you're done. Or if you need help.

Perhaps you could check if everthing is fine:
https://salsa.debian.org/blutz/galvani
https://gitlab.com/b.lutz1/galvani

I'm looking forward to join the debian-science-team with my project. I
read the policy. What to do now? Sign in and/or subsribe to the mailing
list?

Regards

Bug#960729: More issues trying to create an Ubuntu focal image

[Paride Legovini]

Control: tags -1 pending

Fixed in master by:

https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/315

Bug#1068360: [Pkg-samba-maint] Bug#1068360: samba-gpupdate should be in samba-common-bin

[Michael Tokarev]

04.04.2024 10:42, Patrick Hibbs:

Package: samba
Version: 2:4.17.12+dfsg-0+deb12u1
Severity: wishlist
X-Debbugs-Cc: hibbsncc1...@gmail.com

Dear Maintainer,

I noticed that the group policy tool (/usr/sbin/samba-gpupdate) in Debian is
stored in the samba package. This seems to be a poor choice of placement as
group policies are expected to be applied on all domain joined hosts, and you
can join a domain with just the samba-common-bin and sssd-ad packages, but the
samba package is only installed if the SMB file server component is required.


How would you join a computer without main samba component to a domain, and how
would you process group policy in this case?

/mjt

Bug#1068647: python-pot: autopkgtest regression on i386 with NumPy 1.26.4

[Timo Röhling]

Source: python-pot
Version: 0.9.3+dfsg-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package has a autopkgtest regression on i386 with NumPy 1.26.4. 
Hopefully relevant excerpt from test log at
https://ci.debian.net/data/autopkgtest/testing/i386/p/python-pot/45030103/log.gz
follows:


  207s === FAILURES 
===
  207s ___ test_solve_sample_methods[numpy-{'method': 'gaussian'}] 

  207s
  207s nx = 
  207s method_params = {'method': 'gaussian'}
  207s
  207s @pytest.mark.parametrize("method_params", 
lst_method_params_solve_sample)
  207s def test_solve_sample_methods(nx, method_params):
  207s
  207s n_samples_s = 20
  207s n_samples_t = 7
  207s n_features = 2
  207s rng = np.random.RandomState(0)
  207s
  207s x = rng.randn(n_samples_s, n_features)
  207s y = rng.randn(n_samples_t, n_features)
  207s a = ot.utils.unif(n_samples_s)
  207s b = ot.utils.unif(n_samples_t)
  207s
  207s xb, yb, ab, bb = nx.from_numpy(x, y, a, b)
  207s
  207s sol = ot.solve_sample(x, y, **method_params)
  207s solb = ot.solve_sample(xb, yb, ab, bb, **method_params)
  207s
  207s # check some attributes (no need )
  207s assert_allclose_sol(sol, solb)
  207s
  207s sol2 = ot.solve_sample(x, x, **method_params)
  207s if method_params['method'] not in ['factored', 'lowrank']:
  207s >   np.testing.assert_allclose(sol2.value, 0)
  207s
  207s test/test_solvers.py:419:
  207s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
  207s
  207s args = (.compare at 0xf0b37e88>, 
array(8.8817842e-16), array(0))
  207s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to 
tolerance rtol=1e-07, atol=0', 'verbose': True}
  207s
  207s @wraps(func)
  207s def inner(*args, **kwds):
  207s with self._recreate_cm():
  207s >   return func(*args, **kwds)
  207s E   AssertionError:
  207s E   Not equal to tolerance rtol=1e-07, atol=0
  207s E
  207s E   Mismatched elements: 1 / 1 (100%)
  207s E   Max absolute difference: 8.8817842e-16
  207s E   Max relative difference: inf
  207s Ex: array(8.881784e-16)
  207s Ey: array(0)
  207s
  207s /usr/lib/python3.12/contextlib.py:81: AssertionError


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmYT6yAACgkQzIxr3RQD
9MoOQQ/+N1NSlnHlih5jhMBGkClnHTDpLmz8UBBdjnYoqEjQnz/SoBazuViOLd6Z
+eLeUJ8N26fsfe67eiNoVqD4ugEfMNItAq74BMQF2XF2vYVqPztLmxUwQpBrGVkD
oUOQTWos/iJCn8ITMLj+8cYl7EW99UYgh/4shhnbIhKvsKui0fnNqN+sri7gfiAX
om6UJddYkTsQmEGCTkqKgqGqZc70N9Se+mpGFngfhQXFEgQblWIn/HkahnBBp3fJ
dGTbjlT401snZ+81E/h2Ltdz3a0pQ05lN7KoJv03hy18UlToYZDcjDZMc4xIwQNG
SetjCn5+Lfm2NeXwrJ+iYNB+yc3Z4/P03VljuMJfo9pZAeNMnkyMJzQxSDLpeluV
3DeI7KQjAs/y5B/LDtvjPCUcDOoKesYcTDOyDAXRgs1Pu3WwUU5Yi7HmPgKJefmz
UXbnvsOdWgB1UQBX9rh5CKK0VHEb8ZhSZK3EuWjbiel467xml8ic2UYhr3iKadYt
a5H3nfjau1wxoGt2lkH6oOUC19A+iJXQYEZXCM9BWIZC12A6SGsBRrfcxS0jrTGs
Dg5ddnoEreJ7hAWyJHZPbbob/ITLsEKh62js7OH5zLhg2nzT/qXQCwKiDla1lhGY
jn9KxRMnV23CDMGjU2JPeImN9ha2ifVZ1zo/RRzXTu2bw3sHrVs=
=ypga
-END PGP SIGNATURE-

Bug#1068646: pyorbital: autopkgtest regression on i386 with NumPy 1.26.4

[Timo Röhling]

Source: pyorbital
Version: 1.8.2-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

the pyorbital package has an autopkgtest regression on i386 only with
NumPy 1.26.4. Hopefully relevant excerpt from test log at
https://ci.debian.net/data/autopkgtest/testing/i386/p/pyorbital/45030100/log.gz
follows:


  127s === FAILURES 
  ===
  127s _ TestGetObserverLook.test_basic_dask 
__
  127s
  127s self = 
  127s
  127s def test_basic_dask(self):
  127s """Test with dask array inputs"""
  127s from pyorbital import orbital
  127s import dask.array as da
  127s sat_lon = da.from_array(self.sat_lon, chunks=2)
  127s sat_lat = da.from_array(self.sat_lat, chunks=2)
  127s sat_alt = da.from_array(self.sat_alt, chunks=2)
  127s lon = da.from_array(self.lon, chunks=2)
  127s lat = da.from_array(self.lat, chunks=2)
  127s alt = da.from_array(self.alt, chunks=2)
  127s azi, elev = orbital.get_observer_look(sat_lon, sat_lat,
  127s   sat_alt, self.t,
  127s   lon, lat, alt)
  127s >   np.testing.assert_allclose(azi.compute(), self.exp_azi)
  127s
  127s /usr/lib/python3/dist-packages/pyorbital/tests/test_orbital.py:259:
  127s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
  127s
  127s args = (.compare at 0xf0c0cf28>, 
array([[331.00275902, 330.95954165, 180.,  86.4354...00275902, 
330.95954165, 180.,  86.435411  ],
  127s[330.91642994, 180.,   0., 273.232073  ]]))
  127s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to 
tolerance rtol=1e-07, atol=0', 'verbose': True}
  127s
  127s @wraps(func)
  127s def inner(*args, **kwds):
  127s with self._recreate_cm():
  127s >   return func(*args, **kwds)
  127s E   AssertionError:
  127s E   Not equal to tolerance rtol=1e-07, atol=0
  127s E
  127s E   Mismatched elements: 1 / 8 (12.5%)
  127s E   Max absolute difference: 14.03624347
  127s E   Max relative difference: 0.07797913
  127s Ex: array([[331.002759, 330.959542, 180.  ,  86.435411],
  127s E  [330.91643 , 165.963757,   0.  , 273.232073]])
  127s Ey: array([[331.002759, 330.959542, 180.  ,  86.435411],
  127s E  [330.91643 , 180.  ,   0.  , 273.232073]])
  127s
  127s /usr/lib/python3.11/contextlib.py:81: AssertionError
  127s _ TestGetObserverLook.test_basic_numpy 
_
  127s
  127s self = 
  127s
  127s def test_basic_numpy(self):
  127s """Test with numpy array inputs"""
  127s from pyorbital import orbital
  127s azi, elev = orbital.get_observer_look(self.sat_lon, self.sat_lat,
  127s   self.sat_alt, self.t,
  127s   self.lon, self.lat, 
self.alt)
  127s >   np.testing.assert_allclose(azi, self.exp_azi)
  127s
  127s /usr/lib/python3/dist-packages/pyorbital/tests/test_orbital.py:243:
  127s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
  127s
  127s args = (.compare at 0xf0abaf28>, 
array([[331.00275902, 330.95954165, 180.,  86.4354...00275902, 
330.95954165, 180.,  86.435411  ],
  127s[330.91642994, 180.,   0., 273.232073  ]]))
  127s kwds = {'equal_nan': True, 'err_msg': '', 'header': 'Not equal to 
tolerance rtol=1e-07, atol=0', 'verbose': True}
  127s
  127s @wraps(func)
  127s def inner(*args, **kwds):
  127s with self._recreate_cm():
  127s >   return func(*args, **kwds)
  127s E   AssertionError:
  127s E   Not equal to tolerance rtol=1e-07, atol=0
  127s E
  127s E   Mismatched elements: 1 / 8 (12.5%)
  127s E   Max absolute difference: 14.03624347
  127s E   Max relative difference: 0.07797913
  127s Ex: array([[331.002759, 330.959542, 180.  ,  86.435411],
  127s E  [330.91643 , 165.963757,   0.  , 273.232073]])
  127s Ey: array([[331.002759, 330.959542, 180.  ,  86.435411],
  127s E  [330.91643 , 180.  ,   0.  , 273.232073]])
  127s
  127s /usr/lib/python3.11/contextlib.py:81: AssertionError
  127s __ TestGetObserverLook.test_xarray_with_dask 
___
  127s
  127s self = 
  127s
  127s def test_xarray_with_dask(self):
  127s """Test with xarray DataArray with dask array as inputs"""
  127s from pyorbital import orbital
  127s import dask.array as da
  127s import xarray as xr
  127s
  127s def _xarr_conv(input):
  127s 

Bug#1063077: syslog-ng: identified for time_t transition but no ABI in shlibs

[Attila Szalay]

Ok. I re-checked the patch and realized that I checked the only wrong
module (the only one which is arch all and not any).

So my apologies for the fuzz and will apply the patch with the
appropriate changes.

But here my original reply too:

I admit that I joined late to this conversation. But my complain is not
about the time_t change.

My complain is the contradiction between two thing:
1. https://wiki.debian.org/binNMU says that I should declar[e]
dependency between an arch: all to an arch: any package: Depends: foo
(>= ${source:Version}), foo (<< ${source:Version}.1~)

2. The bug report ask to depend on 'syslog-ng-core (=
$${binary:Version})'

This two is contradict and because syslog-ng complies with the binNMU
request, I really reluctant to change that. Especially because in that
case another ticket will be created in no-time to revert it.

This is from the proposed changelog:
+  * Adjust shlibs for syslog-ng-core to use a strict versioned depends;
+previously, modules used >=, << dependencies which did not account for
+the possibility of ABI skew in a binNMU, which is exactly what happens
+with the 64-bit time_t transition.

And my question is again, is the rules really changed or we bend the
rules just because of one transition?

On Fri, 2024-04-05 at 15:15 +0200, Bernd Zeimetz wrote:
> Hi Attila,
> 
> On Fri, 2024-04-05 at 09:47 +0100, Attila Szalay wrote:
> > Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU
> > should
> > be careful
> 
> I think you are confusing binNMUs and NMUs.
> See https://wiki.debian.org/binNMU
> 
> They are handled more or less automatic as soon as a rebuild is
> needed
> for a transition.
> 
> You might want to read the bug report again, it basically says that
> no
> NMU will be uploaded, but you package will break if you don't apply
> the
> attached patch. And the binNMU that will most likely break it will
> happen.
> 
> The way how the time_t change happens was discussed for a *long*
> time,
> you are a bit late with complaints.
> 
> 
> Bernd
> 
> 

Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1

[Dennis van Dok]

I've uploaded a new version since unstable is already at 1.128-1.

Bug#1068645: RM: rust-lazy-regex-proc-macros -- ROM; content already present in rust-lazy-regex package

[James McCoy]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: rust-lazy-regex-proc-mac...@packages.debian.org
Control: affects -1 + src:rust-lazy-regex-proc-macros
User: ftp.debian@packages.debian.org
Usertags: remove

rust-lazy-regex-proc-macros should not have been packaged, since it was
already provided by the rust-lazy-regex package.

Bug#1068479: cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

[Marvin Renich]

* José Luis González  [240407 15:00]:
> reopen 1068479
> thanks
> 
> Hi all,
> 
> Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a
> look at my recent bug reports to libreoffice-writer and his replies.
> 
> In this one:
> 
> > Am 06.04.24 um 11:03 schrieb Rene Engelhard:
> > > Am 06.04.24 um 00:34 schrieb José Luis González:
> > >> The setting for spacing between paragraphs is missing in the spacing
> > >> and indentation tab of the paragraph dialog.
> > >
> > > ?
> > >
> > >  It's definitely there. Format -> Paragraph has spacing "after/before".
> 
> I meant spacing between paragraphs, not spacing after and before
> paragraphs. The report was crystal clear.
> 
> The difference, for those who didn't realize is space after paragraph
> happens always, and between only between them, being the regular
> separation between paragraphs (the other is formatting, and isn't
> useful as a substitute because it adds something undesirable at the end
> of the document or between paragraphs and other kinds of block
> elements).
> 

First, please carefully consider the reply from Pierre-Elliott Bécue.
The tone of your email is way out of line.  If this is the way you
regularly communicate, I would not be surprised that Rene closes your
bug reports.

It is clear to me from your quote of Rene's response that Rene honestly
believed he was answering your question and the bug should be closed.
Politely expressing the difference between the current behavior and what
you were asking for, and at the same time reopening the bug (at a proper
severity), would have been appropriate.  It should have been done in the
bug tracker and _not_ on this list.  I've set Reply-To to the bug report
only.

I don't use libreoffice daily, but I do use it.  If this is a case that
lowriter already has a way to obtain "between" spacing, but it is just
not in the proper dialog box, then this is a "normal" bug at most,
possibly "minor".  However, I don't believe lowriter ever had such a
feature.  If this is the case, the severity is "wishlist", and not
higher.  (If it does have this feature, I would personally be interested
in how to do it!)

In no way would I consider this an "important" bug, and absolutely not
"serious" or RC.

All missing or not-yet-implemented features might be considered to have
a "major effect on usability" by someone, but in almost all cases, such
a feature request is still only a "wishlist" bug.  Please don't confuse
the difference between how you would like the software to behave and how
it is currently designed to behave as being anything more than a feature
request, regardless of how important you believe the feature is.

...Marvin

Bug#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

[Sanjoy Mahajan]

Package: gnutls-bin
Version: 3.8.5-1
Severity: normal
X-Debbugs-Cc: none, Sanjoy Mahajan 
File: /usr/bin/gnutls-cli

After dist-upgrading today, exim4 could no longer talk to my usual
outgoing mail server.  I reproduced the problem using just gnutls-cli.
The problem started after today's upgrade of the various gnutls
packages.  They were upgraded from 3.8.4-2 to 3.8.5-1.

The following command with the given input lines reproduces the problem:

  $ gnutls-cli -V -d 9 --starttls --crlf --port 587 -V outgoing.mit.edu
  EHLO randomhost
  STARTTLS
  ctrl-D [to send EOF]

It fails with "*** Fatal error: The encryption algorithm is not supported."

(I haven't tried it with other outgoing servers, but this one definitely
shows the problem.)

The problem goes away after downgrading the relevant packages to 3.8.4-2 :

  # apt install gnutls-bin=3.8.4-2 gnutls-doc=3.8.4-2 
libgnutls-dane0t64=3.8.4-2 libgnutls-openssl27t64=3.8.4-2 
libgnutls28-dev=3.8.4-2 libgnutls30t64=3.8.4-2

(My sources.list includes the snapshots repos

  deb [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20240329T213539Z/ unstable main
  deb-src [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20240329T213539Z/ unstable main

)

The lines around the fatal error message with 3.8.5-1 are:

  |<4>| HSK[0x5632451d5260]: SERVER HELLO DONE (14) was received. Length 0[0], 
frag offset 0, frag length: 0, sequence: 0
  |<3>| ASSERT: ../../lib/buffers.c[get_last_packet]:1130
  |<3>| ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1374
  |<3>| ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_encrypt]:773
  |<3>| ASSERT: ../../../lib/auth/rsa.c[_gnutls_gen_rsa_client_kx]:288
  |<3>| ASSERT: ../../lib/kx.c[_gnutls_send_client_kx_message]:379
  |<3>| ASSERT: ../../lib/handshake.c[handshake_client]:3183
  *** Fatal error: The encryption algorithm is not supported.
  |<5>| REC: Sending Alert[2|80] - Internal error
  |<5>| REC[0x5632451d5260]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
  |<9>| ENC[0x5632451d5260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
  |<5>| REC[0x5632451d5260]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
  *** Handshake has failed
  |<5>| REC[0x5632451d5260]: Start of epoch cleanup
  |<5>| REC[0x5632451d5260]: End of epoch cleanup
  |<5>| REC[0x5632451d5260]: Epoch #0 freed
  |<5>| REC[0x5632451d5260]: Epoch #1 freed


I've kept my packages at 3.8.4-2 for now,n but I can do more debug tests
if needed (by upgrading, testing, and downgrading).

-Sanjoy


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

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

Versions of packages gnutls-bin depends on:
ii  libc6   2.37-15.1
ii  libgnutls-dane0t64  3.8.5-1
ii  libgnutls30t64  3.8.5-1
ii  libtasn1-6  4.19.0-3+b2

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

Bug#1068643: meep needs an update for Python 3.12

[Matthias Klose]

Package: src:meep
Version: 1.25.0-2
Severity: important
Tags: sid trixie patch
User: debian-pyt...@lists.debian.org
Usertags: python3.12

meep (and probably dependent packages) need an update for Python 3.12, 
e.g. no distutils anymore in 3.12.

Bug#987943: www.debian.org: Developers Reference: Sphinx search non-functional: searchindex.js missing

[Thomas Lange]

> On Mon, 8 Apr 2024 00:35:46 +0200, Holger Wansing  
> said:

>> Can be viewed at 
>> 

>> (also with a different html theme, BTW)
>> 
The search works for me. Thanks a lot.

-- 
regards Thomas

Bug#1068411: bookworm-pu: package schleuder/4.0.3-7+deb12u1

[Georg Faerber]

On 24-04-06 22:31:03, Jonathan Wiltshire wrote:
> Please go ahead.

Uploaded, thank you.

Bug#1068642: No intuitive way to debug/edit/fix defaults for file types

[Eduard Bloch]

Package: xdg-utils
Version: 1.1.3-4.1
Severity: normal
File: /usr/bin/xdg-open

Hi,

sorry for making this lengthy, but this is first-hand user experience.
If TL;DR is wanted, please scroll down to the summary section.

This issue has bothered me for a while and I had to report it
eventually. I have a mixed system here, not just one single DE. And
xdg-open is apparently used in many applications. And the behavior on
folders puzzled me:

 - xdg-open .  --> opens VS Code
 - xdg-open /tmp  --> opens QDirStat

And the manual of xdg-open does not give me any clue on how to
investigate or modify it. Which UI tool can I use? Which CLI tool may I
use?

The first idea was to use xdg-settings. That tool does NOT HELP ME AT
ALL. I can get and check and set something, but WHAT? There is no "list"
sub-command in that utility.

Okay, so I had to check the internet. Found out about MimeType and found
code.desktop and qdirstat.desktop, and found the mime types
inode/directory and inode/mountpoint . So I had to read further to
create $HOME/.local/share/applications/thunar.desktop which is based on
the packaged version, and I added this into it:

$ grep Mime $HOME/.local/share/applications/thunar.desktop
MimeType=inode/directory;inode/mountpoint;

Expected result:

- the change should be picked up
- the preferred version in user's home should be used

Actual result:

$ xdg-open /var/tmp
[main 2024-04-04T10:41:10.001Z] update#setState idle
[main 2024-04-04T10:41:11.720Z] Extension host with pid 1431582 exited with 
code: 0, signal: unknown.
[main 2024-04-04T10:41:11.728Z] [UtilityProcess id: 1, type: fileWatcher, pid: 
1431552]: crashed with code 15 and reason 'killed'

And it still opens it with code, not thunar. And what is this
fileWatcher being killed? So, assuming that it might use a user service
for all operations, I have applied "systemctl --user restart xdg..." on
all services. Result: no luck, nothing has changed.

So eventually I hat do dig further, after finding out that those are
just shell scripts, which brings us to "xdg-mime query default
inode/directory" returning code.desktop.

And only after bash-x-ing this I have learned about the existence of
defaults.list file. And I still had no idea how to create or modify it.

So I had to use SO again and found 
https://unix.stackexchange.com/questions/36380/how-to-properly-and-easily-configure-xdg-open-without-any-environment#59088

And only after creating the file with the following I get to my actual
target.

[Default Applications]
inode/directory=thunar.desktop
inode/mountpoint=thunar.desktop


So, my summary, what would I expect:

- the manpages shall document the related configuration files, at least
  briefly
- default.list should have a manpage (no user should be forced to use
  web sources for such basic knowledge)
- the MimeType of the user's desktop files probably should be considered
  first, and the system versions later
- there should be some kind of verbosity switch, which would print
  relevant information along the decision making, without having to dig
  through all the shell debug log.

Best regards,
Eduard.

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.34-1
ii  libnet-dbus-perl   1.2.0-2+b2
ii  libx11-protocol-perl   0.56-9
ii  x11-utils  7.7+6+b1
ii  x11-xserver-utils  7.7+10+b1

xdg-utils suggests no packages.

-- no debconf information

--
 Noch freiwillige Tester für svn-inject und svn-uupdate hier?
 Wenn du mir erklärst, was das is ;)
 Greek0: Dope für Maintainer, echt guter Stoff.

Bug#1068637: apt does not always install Recommends

[Vincent Lefevre]

On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote:
> On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> > The lvm2 package is installed, but not thin-provisioning-tools,
> > though lvm2 recommends it. This can yield a broken system:
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> > 
> > the fix of this bug being
> > 
> >* Make lvm2 recommend thin-provisioning-tools. (closes: #857142)
> 
> That's a packaging bug. If the tool is mandatory for correct behavior
> of the system it should be a Depends.

It is not mandatory in all cases, but it some cases. In any case,
the "Recommends:" must be honored.

> In this particular instance you're getting bit by time_t transition
> issues and Recommends disappear on you (even if they may be satisfiable
> it may simply be easier to break the Recommends for apt than to figure
> out the right solution).

No, lvm2 was installed before the time_t transition. It actually
affects plain bookworm installations (on a machine where I installed
Debian 12.1 on 2023-10-07); you can see with the attached
"dpkg --get-selections" output I had at that time.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
accountsservice install
acl install
adduser install
adwaita-icon-theme  install
aisleriot   install
alsa-topology-conf  install
alsa-ucm-conf   install
alsa-utils  install
anacron install
analog  install
apache2 install
apache2-bin install
apache2-datainstall
apache2-doc install
apache2-utils   install
apg install
apparmorinstall
appstream   install
apt install
apt-config-iconsinstall
apt-listchanges install
apt-utils   install
aspell  install
aspell-en   install
at-spi2-common  install
at-spi2-coreinstall
avahi-autoipd   install
avahi-daemoninstall
baobab  install
base-files  install
base-passwd install
bashinstall
bash-completion install
bc  install
bind9-dnsutils  install
bind9-host  install
bind9-libs:amd64install
bluetooth   install
bluez   install
bluez-obexd install
bogofilter  install
bogofilter-bdb  install
bogofilter-common   install
boltinstall
brasero-common  install
bsdextrautils   install
bsdutilsinstall
bubblewrap  install
busybox install
bzip2   install
ca-certificates install
cdrdao  install
cheese  install
cheese-common   install
chrome-gnome-shell  install
coinor-libcbc3:amd64install
coinor-libcgl1:amd64install
coinor-libclp1:amd64install
coinor-libcoinmp1v5:amd64   install
coinor-libcoinutils3v5:amd64install
coinor-libosi1v5:amd64  install
colord  install
colord-data install
console-setup   install
console-setup-linux install
coreutils 

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Santiago Vila]

Just for the record: I finally used this, in line with the original proposal:

Replaces: dialog (<< 1.3-20240307-1~)
Breaks: dialog (<< 1.3-20240307-1~)

Thanks.

Bug#1068637: apt does not always install Recommends

[Julian Andres Klode]

Control: severity -1 wishlist

On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> Package: apt
> Version: 2.7.14
> Severity: serious
> 
> The lvm2 package is installed, but not thin-provisioning-tools,
> though lvm2 recommends it. This can yield a broken system:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> 
> the fix of this bug being
> 
>* Make lvm2 recommend thin-provisioning-tools. (closes: #857142)

That's a packaging bug. If the tool is mandatory for correct behavior
of the system it should be a Depends.

Now back to the topic, this is not a release critical bug in APT. APT
installs any Recommends with easily satisfiable dependencies. Recommends
will get broken easily if there's large scale dependency issues like
now.

This works out well if you Recommend an Architecture: all package and
it Depends on packages that are not available on all architectures -
it is just being skipped on those.

In this particular instance you're getting bit by time_t transition
issues and Recommends disappear on you (even if they may be satisfiable
it may simply be easier to break the Recommends for apt than to figure
out the right solution).

However I do agree with you and I've already set this a couple of times
before that I want to move away from treating Recommends as optional
dependencies that we want to satisfy as many of as we can.

My proposal is quite simple:

 Recommends that point to an existing real package are promoted to
 Depends, except that you may remove them by explicit action (remove
 them after install, mark them for removal before installing, or if
 it is unsatisfied in the installed package it remains unsatisfied).

 This applies to the entire or group. If you Recommends: real | virtual,
 the recommends may also be satisfied by the virtual package.

I do not know what the behavior should be for Recommends exclusively
n virtual packages, I feel like promoting them could have unforeseen
issues, people think less about them than real packages.

Ultimately this may be a bit challenging to implement but I didn't
actually get around to looking at it yet, and it certainly will take
some time to sort out the uninstallabilities this introduces in the
archive especially on niche architectures where Architecture: all
packages are Recommended but not installable.

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

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Santiago Vila]

Ok. This is a little bit subtle.

I naively tried to simplify the fields by using this:

Replaces: dialog (<< 1.3-20240307)
Breaks: dialog (<< 1.3-20240307)

But this actually means upstream version 1.3, debian revision 20240307,
not upstream 1.3-20240307.

I guess I should use 1.3-20240307-0 at minimum.

Thanks.

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Christian Franke]

Jonathan Wiltshire wrote:

...
Thanks. The bug #1050288 isn't fixed in unstable according to the BTS,
which is a requirement. What's the status?


The problem described in #1050288 does not longer occur since NSIS 3.09. 
The problem appeared in Debian 12 because the Mingw-w64 toolchain now 
enables ASLR (and therefore emits relocation information) by default but 
NSIS does not support relocation information. NSIS upstream addressed 
this in the build recipes of 3.09.


I could confirm that this has the desired effect:
In the smartmontools project, we use a Debian 12 based docker image for 
reproducible CI builds (https://builds.smartmontools.org/). After 
forcibly upgrading NSIS to 3.09 from Debian trixie, the problem 
disappeared. Here the related commit:

https://github.com/smartmontools/docker-build/commit/9b231f0

Therefore I guess that #1050288 is also fixed in unstable.

--
Regards,
Christian

Bug#1068641: plasma-mobile: Record Screen doesn't work, creates 0 byte files

[Russell Coker]

Package: plasma-mobile
Version: 5.27.10-1
Severity: normal

When the end of recording is selected if there isn't a ~/Videos
directory then nothing is created.  If the directory exists then it
creates a 0 byte file.

This is on a Librem5.

-- System Information:
Debian Release: trixie/sid
Architecture: arm64 (aarch64)

Kernel: Linux 6.6-librem5 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages plasma-mobile depends on:
ii  bluedevil  4:5.27.10-1
ii  breeze-icon-theme  4:5.107.0-1
ii  fonts-mplus063+git20221017+ds-1
ii  fonts-oxygen   4:5.4.3-4
ii  kio5.107.0-1+b1
ii  kpackagetool5  5.107.0-1+b1
ii  kpeople-vcard  0.1-3+b1
ii  libc6  2.37-15
ii  libkf5configcore5  5.107.0-1+b1
ii  libkf5configgui5   5.107.0-1+b1
ii  libkf5configwidgets5   5.107.0-2+b1
ii  libkf5coreaddons5  5.107.0-1+b1
ii  libkf5i18n55.107.0-1+b1
ii  libkf5kiocore5 5.107.0-1+b1
ii  libkf5kiogui5  5.107.0-1+b1
ii  libkf5kiowidgets5  5.107.0-1+b1
ii  libkf5modemmanagerqt6  5.107.0-1+b1
ii  libkf5networkmanagerqt65.107.0-1
ii  libkf5notifications5   5.107.0-1+b1
ii  libkf5package5 5.107.0-1+b1
ii  libkf5plasma5  5.107.0-1+b1
ii  libkf5quickaddons5 5.107.0-1+b1
ii  libkf5service-bin  5.107.0-1+b1
ii  libkf5service5 5.107.0-1+b1
ii  libkf5waylandclient5   4:5.107.0-1+b1
ii  libkf5windowsystem55.107.0-1+b1
ii  libkworkspace5-5   4:5.27.10-3
ii  libqt5core5a   5.15.10+dfsg-7
ii  libqt5dbus55.15.10+dfsg-7
ii  libqt5gui5 5.15.10+dfsg-7
ii  libqt5qml5 5.15.10+dfsg-2+b1
ii  libqt5quick5   5.15.10+dfsg-2+b1
ii  libqt5widgets5 5.15.10+dfsg-7
ii  libstdc++6 14-20240201-3
ii  maliit-keyboard2.3.1-4
ii  milou  4:5.27.10-1
ii  pipewire   1.0.3-1
ii  plasma-nano5.27.10-1
ii  plasma-nm  4:5.27.10-1
ii  plasma-pa  4:5.27.10-1
ii  plasma-settings23.01.0-1
ii  plasma-workspace   4:5.27.10-3
ii  plasma-workspace-wayland   4:5.27.10-3
ii  powerdevil 4:5.27.10-1
ii  qml-module-org-kde-activities  5.107.0-1+b1
ii  qml-module-org-kde-bluezqt 5.107.0-2
ii  qml-module-org-kde-kio 5.107.0-1+b1
ii  qml-module-org-kde-kirigami-addons-labs-mobil  0.9.0-1+b1
eform
ii  qml-module-org-kde-kirigami2   5.107.0-1+b1
ii  qml-module-org-kde-kquickcontrols  5.107.0-1+b1
ii  qml-module-org-kde-people  5.107.0-1+b1
ii  qml-module-org-kde-pipewire5.27.10-1
ii  qml-module-org-kde-qqc2breezestyle 5.27.10-1
ii  qml-module-qtfeedback  5.0~git20180903.a14bd0b-5+b1
ii  qml-module-qtquick-localstorage5.15.10+dfsg-2+b1
ii  xdg-desktop-portal-kde 5.27.10-1

Versions of packages plasma-mobile recommends:
ii  kde-config-mobile-networking  4:5.27.10-1
ii  plasma-mobile-tweaks  5.27.10-1

plasma-mobile suggests no packages.

-- debconf-show failed

Bug#1068640: clevis-initramfs: clevis early boot DNS fail, no resolv.conf created by ipconfig

[anon2529]

Package: clevis-initramfs
Version: 19-2
Severity: normal
X-Debbugs-Cc: spamthath...@gmail.com

The early boot fails to unlock a volume automatically. We get a
prompt to unlock a volume (it's a swap volume) but clevis is
unable to unlock it automatically because it cannot resolve
the Tang server's hostname.

Please unlock disk luks-9594b5ea-9494-4c53-9344-9fcba158914b:
IP-Config: enp0s3 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: enp0s3 complete (dhcp from 192.168.1.1):
 address: 192.168.1.117broadcast: 192.168.1.255netmask: 255.255.255.0
 gateway: 192.168.1.1  dns0 : 192.168.1.1  dns1   : 0.0.0.0
 domain : lan
 rootserver: 192.168.1.1 rootpath:
 filename  :

Workaround / Debugging info:

If I use 'break=mount' I can make it work using these steps:

1. Append 'break=mount' to the kernel boot parameters.
2. Enter 'ipconfig enp0s3' to let ipconfig configure networking.
   This mimicks what normally happens during the early boot if we
   use clevis.
3. Manually create a resolv config:
   echo 'nameserver 192.168.1.1' > /etc/resolv.conf
4. Enter 'exit' to continue the early boot.
5. Observe that clevis is now able to unlock the volume
   automatically.

Good to know: /etc/resolv.conf did NOT exist before step 3,
so it seems that 'ipconfig' doesn't create it. Even though it
shows us that it gets DNS information from the DHCP server,
it doesn't appear to do anything with that information.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: 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 clevis-initramfs depends on:
ii  clevis-luks  19-2
ii  initramfs-tools  0.142

clevis-initramfs recommends no packages.

clevis-initramfs suggests no packages.

-- no debconf information

Bug#1068639: RFS: redict/7.3.0-1 [ITP] -- Persistent key-value database with network interface (metapackage)

[Maytham Alsudany]

Package: sponsorship-requests
Severity: wishlist
Control: block 1068129 by -1

Dear mentors,

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

 * Package name : redict
   Version  : 7.3.0-1
   Upstream contact : Drew DeVault 
 * URL  : https://redict.io/
 * License  : MIT, LGPL-3.0-only
 * Vcs  : https://salsa.debian.org/redict-team/redict
   Section  : database

The source builds the following binary packages:

  redict - Persistent key-value database with network interface (metapackage)
  redict-sentinel - Persistent key-value database with network interface 
(monitoring)
  redict-server - Persistent key-value database with network interface
  redict-tools - Persistent key-value database with network interface (client)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/redict/redict_7.3.0-1.dsc

Changes for the initial release:

 redict (7.3.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1068129)

Regards,



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

Bug#1068638: RFP: mount-zip -- FUSE file system for ZIP archives (read-only)

[Fab Stz]

Package: wnpp
Severity: wishlist

* Package name: mount-zip
  Version : 1.0.12
  Upstream Contact: François Degros
* URL : https://github.com/google/mount-zip
* License : GPL3
  Programming Lang: C++
  Description : FUSE file system for ZIP archives (read-only)

This package provides an alternative to fuse-zip. Compared to fuse-zip, it
seams reading performance is improved, but write mode was dropped.
Version 1.0.0 was forked from fuse-zip 0.7.2

mount-zip is a tool allowing to open, explore and extract ZIP archives.

mount-zip mounts a ZIP archive as a read-only FUSE file system, which can then
be explored and read by any application.

mount-zip aspires to be an excellent ZIP mounter. It starts quickly, uses
little memory, decodes encrypted files, and provides on-the-go decompression
and caching for maximum efficiency.

The mount point should be an empty directory. If the mount point doesn't exist
yet, mount-zip creates it first. If no mount point is provided, mount-zip
creates one in the same directory as the ZIP archive.

///


It provides an alternative to fuse-zip. Compared to fuse-zip, it seams reading
performance is improved, but write mode was dropped.

This can be useful when short on space and we don't want to unzip the file but
still access its content on the fly, for example on gitlab ci runners, or any
docker/CI instance.

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Santiago Vila]

El 8/4/24 a las 9:18, Helmut Grohne escribió:

Package: libdialog-dev
Version: 1.3-20240307-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + dialog

libdialog-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the
packages
  * dialog
* 1.3-20201126-1 as present in bullseye
* 1.3-20230209-1 as present in bookworm
* 1.3-20240101-1 as present in trixie
  * libdialog-dev/1.3-20240307-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation.


Thanks for the report. libdialog-dev has:

Replaces: dialog (<< 1.3-20240307)
Breaks: dialog (<< 1.3-20240307)

Is this really not enough?
Is Policy up to date regarding this?

(Cc: Sven, who was helping with the package split).

Thanks.

Bug#1068637: apt does not always install Recommends

[Vincent Lefevre]

Package: apt
Version: 2.7.14
Severity: serious

The lvm2 package is installed, but not thin-provisioning-tools,
though lvm2 recommends it. This can yield a broken system:

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

the fix of this bug being

   * Make lvm2 recommend thin-provisioning-tools. (closes: #857142)

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-listchanges-main "listchanges.conf";
Dir::Etc::apt-listchanges-parts "listchanges.conf.d";
Dir::Etc::apt-file-main "apt-file.conf";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::solvers "";
Dir::Bin::solvers:: "/usr/lib/apt/solvers";
Dir::Bin::planners "";
Dir::Bin::planners:: "/usr/lib/apt/planners";
Dir::Bin::dpkg "/usr/bin/dpkg";
Dir::Bin::gzip "/bin/gzip";
Dir::Bin::bzip2 "/bin/bzip2";
Dir::Bin::xz "/usr/bin/xz";
Dir::Bin::lz4 "/usr/bin/lz4";
Dir::Bin::zstd "/usr/bin/zstd";
Dir::Bin::lzma "/usr/bin/xz";

Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support

[Christoph Martin]

Hi Sebastian,

the packages are already removed from testing and unstable.
Where do you see a problem?

Regards
Christoph

Am 07.04.24 um 13:21 schrieb Sebastian Ramacher:

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: nfs-gane...@packages.debian.org, sramac...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:nfs-ganesha
Control: block 1065470 by -1
Control: clone -1 -2
Control: clone -1 -3
Control: retitle -2 RM: nfs-ganesha-grace [armel armhf i386] -- NBS; ceph 
dropped 32 bit support
Control: retitle -3 RM: nfs-ganesha-rgw [armel armhf i386] -- NBS; ceph dropped 
32 bit support

  nfs-ganesha (4.3-6) unstable; urgency=medium
  .
* only configure with ceph for some 64bit archs

So please remove the old nfs-ganesha-ceoph, nfs-ganesha-rados-grace, and
nfs-genesha-rgw binaries from armel, armhf and i386.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068636: lincity-ng: conflict with older lincity-ng-data

[Marc Glisse]

Package: lincity-ng
Version: 2.10.1-1
Severity: normal

Dear Maintainer,

`apt upgrade` failed with

Unpacking lincity-ng (2.10.1-1) over (2.9.0-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-msgcqU/39-lincity-ng_2.10.1-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/icons/hicolor/128x128/apps/lincity-ng.png', 
which is also in package lincity-ng-data 2.9.0-1

(a simple `apt -f install` fixes it)

If the file was really supposed to change package (was it?), you need to
declare suitable breaks/conflicts/replaces/etc control fields.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-debug'), (500, 'testing'), 
(400, 'stable-security'), (400, 'stable'), (50, 'unstable-debug'), (50, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf

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

Versions of packages lincity-ng depends on:
ii  libc62.37-15
ii  libgcc-s114-20240201-3
ii  libgl1   1.7.0-1
ii  libphysfs1   3.0.2-6
ii  libsdl2-2.0-02.30.0+dfsg-1
ii  libsdl2-gfx-1.0-01.0.4+dfsg-5
ii  libsdl2-image-2.0-0  2.8.2+dfsg-1
ii  libsdl2-mixer-2.0-0  2.8.0+dfsg-1
ii  libsdl2-ttf-2.0-02.22.0+dfsg-1
ii  libstdc++6   14-20240201-3
ii  libxml2  2.9.14+dfsg-1.3+b2
ii  lincity-ng-data  2.10.1-1
ii  zlib1g   1:1.3.dfsg-3+b1

lincity-ng recommends no packages.

lincity-ng suggests no packages.

-- no debconf information

Bug#1068635: screen FTCBFS: pty.c:338:7: error: implicit declaration of function ‘openpty’; did you mean ‘OpenPTY’? [-Werror=implicit-function-declaration]

[Helmut Grohne]

Source: screen
Version: 4.9.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

screen fails to cross build from source:

| mips64el-linux-gnuabi64-gcc -c -I. -I..  -Wdate-time -D_FORTIFY_SOURCE=2 
-DETCSCREENRC='"/etc/screenrc"' 
-DSCREENENCODINGS='"/usr/share/screen/utf8encodings"' -DHAVE_CONFIG_H 
-DGIT_REV=\"\" \
|  -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wno-unused-parameter 
-Wno-missing-field-initializers -D_GNU_SOURCE ../pty.c
| ../pty.c: In function ‘OpenPTY’:
| ../pty.c:338:7: error: implicit declaration of function ‘openpty’; did you 
mean ‘OpenPTY’? [-Werror=implicit-function-declaration]
|   338 |   if (openpty(, , TtyName, NULL, NULL) != 0)
|   |   ^~~
|   |   OpenPTY

The real cause here is that screen exercises a non-standard code path
due to configure time misdetection. It skips the SVR4 /dev/ptmx check in
cross compilation and directly falls back to openpty, which apparently
no longer works.

The "test -c /dev/ptmx" is conditionalized to not being performed during
cross compilation and doing it there would be confusing build and host.
However, AC_CHECK_FILE exists for this very purpose. During native
compilation, it becomes a simple test and during cross compilation it
becomes a hard failure where a user must supply the check result. Then
also supplying the result makes screen cross buildable again. I'm
attaching a patch for your convenience.

Note that with this patch applied, crossqa.debian.net will always
report screen as failed, because it does not supply this check result.
If you want to do this explicitly, you may add the following snippet to
d/rules:

ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
ifeq ($(DEB_HOST_ARCH_OS),linux)
export ac_cv_file__dev_ptmx = yes
endif
endif

Or you may leave this to the builder at your choice, but there is no
sane way to detect this during build.

Helmut
--- screen-4.9.1.orig/configure.ac
+++ screen-4.9.1/configure.ac
@@ -756,10 +756,10 @@
 fi
 fi
 
-if test "$cross_compiling" = no ; then
+AC_CHECK_FILE([/dev/ptmx])
 AC_CHECKING(for SVR4 ptys)
 sysvr4ptys=
-if test -c /dev/ptmx ; then
+if test "x$ac_cv_file__dev_ptmx" = xyes ; then
 AC_TRY_LINK([
 #include 
 ], [
@@ -767,7 +767,6 @@
 ],[AC_DEFINE(HAVE_SVR4_PTYS)
 sysvr4ptys=1])
 fi
-fi
 
 AC_CHECK_FUNCS(getpt)
 

Bug#1068610: dico: binary-all FTBFS

[Helmut Grohne]

Control: tags -1 + patch

Hi Adrian,

On Mon, Apr 08, 2024 at 02:03:01AM +0300, Adrian Bunk wrote:
> Source: dico
> Version: 2.11-4
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: Helmut Grohne 

Thank you for notifying me. Mea culpa. Patch attached.

> https://buildd.debian.org/status/logs.php?pkg=dico=all
> 
> ...
>debian/rules execute_after_dh_installsystemd
> make[1]: Entering directory '/<>'
> ln -s dicod.service debian/dicod/`test -e 
> debian/dicod/lib/systemd/system/dicod.service || echo 
> usr/`lib/systemd/system/dictd.service
> ln: failed to create symbolic link 
> 'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory
> make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1

Helmut
diff --minimal -Nru dico-2.11/debian/changelog dico-2.11/debian/changelog
--- dico-2.11/debian/changelog  2024-03-01 12:57:59.0 +0100
+++ dico-2.11/debian/changelog  2024-04-08 09:21:47.0 +0200
@@ -1,3 +1,10 @@
+dico (2.11-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix indep-only FTBFS arising from #1054187. (Closes: #1068610)
+
+ -- Helmut Grohne   Mon, 08 Apr 2024 09:21:47 +0200
+
 dico (2.11-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dico-2.11/debian/rules dico-2.11/debian/rules
--- dico-2.11/debian/rules  2023-11-20 17:26:32.0 +0100
+++ dico-2.11/debian/rules  2024-04-08 09:21:31.0 +0200
@@ -48,5 +48,5 @@
mkdir -p $(TEST_HOME)
HOME=$(TEST_HOME) dh_auto_test || cat dicod/tests/testsuite.log
 
-execute_after_dh_installsystemd:
+execute_after_dh_installsystemd-arch:
ln -s dicod.service debian/dicod/`test -e 
debian/dicod/lib/systemd/system/dicod.service || echo 
usr/`lib/systemd/system/dictd.service

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Helmut Grohne]

Package: libdialog-dev
Version: 1.3-20240307-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + dialog

libdialog-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the
packages
 * dialog
   * 1.3-20201126-1 as present in bullseye
   * 1.3-20230209-1 as present in bookworm
   * 1.3-20240101-1 as present in trixie
 * libdialog-dev/1.3-20240307-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1068628: screenshots from Bookworm and Unstable

[Russell Coker]

I've attached screenshots showing the problem on Stable 0.11.3-2 and Unstable 
0.11.3+~0.9.2+~1.0.0+~0.3.0-2 .

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1

[Maytham Alsudany]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cj...@packages.debian.org
Control: affects -1 + src:cjson

[ Reason ]
CVE-2023-50472, CVE-2023-50471

[ Impact ]
Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c

[ Tests ]
Upstream's test continue to pass, and they have also added new tests to
cover this security issue.

[ Risks ]
Minimal, no change to API. Only minimal changes were made to fix this
security issue.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
- Set myself as Maintainer (I am adopting the package, #1067510)
- Bump Standards-Version to 4.6.2
- Add Build-Depends-Package to symbools
- Backport upstream's patch to 'add NULL checkings'.
  Upstream adds a few more if statements to avoid the segmentation
  fault, and thus resolve the security vulnerability.

[ Other info ]
If you can spare the time, could you please upload this for me? (I need
a sponsor, #1068624.) I'm also still waiting for someone to give me
access to the Salsa repo.

Thanks,
Maytham
diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
--- cjson-1.7.15/debian/changelog   2021-08-29 23:30:06.0 +0300
+++ cjson-1.7.15/debian/changelog   2024-04-03 06:57:10.0 +0300
@@ -1,3 +1,13 @@
+cjson (1.7.15-1+deb12u1) bookworm-security; urgency=medium
+
+  * Update Maintainer field
+  * Bump Standards-Version to 4.6.2 (no changes)
+  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
+(Closes: #1059287)
+  * Add Build-Depends-Package to symbols
+
+ -- Maytham Alsudany   Wed, 03 Apr 2024 06:57:10 +0300
+
 cjson (1.7.15-1) unstable; urgency=medium
 
   * New upstream release 1.7.15.
diff -Nru cjson-1.7.15/debian/control cjson-1.7.15/debian/control
--- cjson-1.7.15/debian/control 2021-08-29 23:29:57.0 +0300
+++ cjson-1.7.15/debian/control 2024-04-03 06:38:29.0 +0300
@@ -1,10 +1,10 @@
 Source: cjson
 Section: libs
 Priority: optional
-Maintainer: Boyuan Yang 
+Maintainer: Maytham Alsudany 
 Build-Depends: cmake, debhelper-compat (= 13)
 Rules-Requires-Root: no
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Homepage: https://github.com/DaveGamble/cJSON
 Vcs-Git: https://salsa.debian.org/debian/cjson.git
 Vcs-Browser: https://salsa.debian.org/debian/cjson
diff -Nru cjson-1.7.15/debian/gbp.conf cjson-1.7.15/debian/gbp.conf
--- cjson-1.7.15/debian/gbp.conf1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/gbp.conf2024-04-03 06:56:58.0 +0300
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru cjson-1.7.15/debian/libcjson1.symbols 
cjson-1.7.15/debian/libcjson1.symbols
--- cjson-1.7.15/debian/libcjson1.symbols   2021-08-29 23:28:57.0 
+0300
+++ cjson-1.7.15/debian/libcjson1.symbols   2024-04-03 06:57:10.0 
+0300
@@ -1,4 +1,5 @@
 libcjson.so.1 libcjson1 #MINVER#
+* Build-Depends-Package: libcjson-dev
  cJSON_AddArrayToObject@Base 1.7.5
  cJSON_AddBoolToObject@Base 1.7.5
  cJSON_AddFalseToObject@Base 1.7.5
diff -Nru cjson-1.7.15/debian/patches/0001-add-null-checkings.patch 
cjson-1.7.15/debian/patches/0001-add-null-checkings.patch
--- cjson-1.7.15/debian/patches/0001-add-null-checkings.patch   1970-01-01 
03:00:00.0 +0300
+++ cjson-1.7.15/debian/patches/0001-add-null-checkings.patch   2024-04-03 
06:51:36.0 +0300
@@ -0,0 +1,101 @@
+Origin: backport, 
https://github.com/DaveGamble/cJSON/commit/60ff122ef5862d04b39b150541459e7f5e35add8
+From: Peter Alfred Lee 
+Bug: https://github.com/DaveGamble/cJSON/issues/803
+Bug: https://github.com/DaveGamble/cJSON/issues/802
+Bug-Debian: https://bugs.debian.org/1059287
+Acked-by: Maytham Alsudany 
+Subject: [PATCH] add NULL checkings (#809)
+ * add NULL checks in cJSON_SetValuestring
+ Fixes #803(CVE-2023-50472)
+ .
+ * add NULL check in cJSON_InsertItemInArray
+ Fixes #802(CVE-2023-50471)
+ .
+ * add tests for NULL checks
+ add tests for NULL checks in cJSON_InsertItemInArray and cJSON_SetValuestring
+
+--- a/cJSON.c
 b/cJSON.c
+@@ -401,7 +401,12 @@
+ {
+ char *copy = NULL;
+ /* if object's type is not cJSON_String or is cJSON_IsReference, it 
should not set valuestring */
+-if (!(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++if ((object == NULL) || !(object->type & cJSON_String) || (object->type & 
cJSON_IsReference))
++{
++return NULL;
++}
++/* return NULL if the object is corrupted */
++if (object->valuestring == NULL)
+ {
+ return NULL;
+ }
+@@ -2260,7 +2265,7 @@
+ {
+ cJSON *after_inserted = NULL;
+ 
+-if (which < 0)
++if (which < 0 || newitem == NULL)
+ {
+ return false;
+ }
+@@ -2271,6 +2276,11 @@
+ return 

Bug#1068632: dh-exec-install - dh_missing fails when using arch or indep

[Craig Small]

Package: dh-exec
Version: 0.29
Severity: normal

In a multi-binary package, if there is a dh-exec-install .install or .manpages 
file for
one of the packages, then these files are not carried across and logged
for dh_install so dh_missing fails if you use the other type of build.

For example, on the same source you have arch package foo and indep
package foo-data and foo-data uses dh-exec, when building a
arch-dependent (e.g. dpkg-buildpackage -B) will cause this issue.

dh_install gets the renamed/moved file but cannot find it so doesn't
log that file as not-installed (for the indep package).
dh_missing sees the file in the original spot, notes there is not
log for it and errors.

So for a indep package when building a binary package what happens is:
 * dh-exec-install-rename says "I moved A to B" but doesn't
 * dh_install cannot find B so ignores it
 * dh_missing finds A and complains

The fix is for dh-exec-install-rename to only change the file
name/location if it actually does the work and use the original
filename otherwise.

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

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

Versions of packages dh-exec depends on:
ii  debhelper 13.15.3
ii  libc6 2.37-15
ii  libdpkg-perl  1.22.4
ii  libpipeline1  1.5.7-1+b2
ii  perl  5.38.2-3

dh-exec recommends no packages.

dh-exec suggests no packages.

-- no debconf information

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: Bug#1068045: libssl3: breaks YAPET

[Kurt Roeckx]

There might be a related change that doesn't allow restarting the operation 
with the same context without setting things up again.

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Colin Watson]

On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote:
> On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:
> > util-linux upstream provides three binary objects to be built:
> > - liblastlog2.so
> > - pam_lastlog2.so
> > - lastlog2 (program)
> >
> > Debian's PAM policy says to put PAM modules into their own package,
> > thus libpam-lastlog2. liblastlog2.so would go into the
> >
> liblastlog2(-0) package. The lastlog2 program either into its own
> > lastlog2 package, or elsewhere.
> >
> 
> Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
> pam modules start with the prefix pam_*.

The file names do, but the package names almost always start with
"libpam-".  (Also, Debian package names may not contain "_".)

  $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
^libpam-
  68
  $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^pam-
  1

And the Debian PAM mini-policy says:

  1) Packages should use the naming scheme of `libpam-' (eg.
  libpam-ldap).

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions

[dada007]

Package: src:linux
Version: 6.6.15-2
Severity: important
X-Debbugs-Cc: peter_malmb...@proton.me

Dear Maintainer,

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

   * What led up to the situation? has been the same problem since kernel 6.5
came out, just opening a browser with or another app makes the screen go black,
like it is switching mode or graphics card or something. Not all apps give this
problem, but many.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I had an earlier report with this bug. I came in contact
with Diederik de Haas, he told me to install apt install ./linux-
image-6.5.0-0-rt-amd64_6.5~rc4-1~exp1_amd64.deb, I did and with that kernel
there was no problem. But i guess it never got upstreamed to the next real
kernel?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 6.6.15-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP 
PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04)

** Command line:
BOOT_IMAGE=/@/boot/vmlinuz-6.6.15-amd64 
root=UUID=00297711-9793-4a3f-a31c-69218142f224 ro rootflags=subvol=@ quiet 
splash radeon.cik_support=0 amdgpu.cik_support=1

** Not tainted

** Kernel log:
[   10.611214] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:0a:00.6/sound/card3/input24
[   10.611289] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:0a:00.6/sound/card3/input25
[   10.611359] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:0a:00.6/sound/card3/input26
[   10.611436] input: HD-Audio Generic Line Out as 
/devices/pci:00/:00:08.1/:0a:00.6/sound/card3/input27
[   10.611503] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:0a:00.6/sound/card3/input28
[   10.659401] iwlwifi :08:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, 
REV=0x340
[   10.659503] thermal thermal_zone0: failed to read out thermal zone (-61)
[   10.673357] kvm_amd: TSC scaling supported
[   10.673362] kvm_amd: Nested Virtualization enabled
[   10.673363] kvm_amd: Nested Paging enabled
[   10.673371] kvm_amd: Virtual VMLOAD VMSAVE supported
[   10.673372] kvm_amd: Virtual GIF supported
[   10.673373] kvm_amd: LBR virtualization supported
[   10.682670] MCE: In-kernel MCE decoding enabled.
[   10.697049] intel_rapl_common: Found RAPL domain package
[   10.697053] intel_rapl_common: Found RAPL domain core
[   10.787286] iwlwifi :08:00.0: Detected RF HR B3, rfid=0x10a100
[   10.851852] iwlwifi :08:00.0: base HW address: bc:f1:71:6c:11:f0
[   10.867989] iwlwifi :08:00.0 wlp8s0: renamed from wlan0
[   10.895296] usbcore: registered new interface driver snd-usb-audio
[   11.080494] usb 1-5: new full-speed USB device number 5 using xhci_hcd
[   11.172639] audit: type=1400 audit(1712565019.953:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=870 comm="apparmor_parser"
[   11.176469] audit: type=1400 audit(1712565019.957:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=868 comm="apparmor_parser"
[   11.183464] audit: type=1400 audit(1712565019.961:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=867 comm="apparmor_parser"
[   11.196905] audit: type=1400 audit(1712565019.977:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=860 
comm="apparmor_parser"
[   11.198612] audit: type=1400 audit(1712565019.977:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=861 
comm="apparmor_parser"
[   11.199010] audit: type=1400 audit(1712565019.977:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=861 comm="apparmor_parser"
[   11.224027] audit: type=1400 audit(1712565020.001:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=866 
comm="apparmor_parser"
[   11.224242] audit: type=1400 audit(1712565020.005:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=866 
comm="apparmor_parser"
[   11.224587] audit: type=1400 audit(1712565020.005:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=866 
comm="apparmor_parser"
[   11.234804] audit: type=1400 audit(1712565020.013:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=872 comm="apparmor_parser"
[   11.491882] usb 1-5: New USB device found, idVendor=8087, idProduct=0029, 
bcdDevice= 0.01
[   11.491887] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   11.513914] Bluetooth: hci0: Bootloader revision 0.3 

Bug#1068630: rsync: update to version 3.3.0

[antonio]

Package: rsync
Version: 3.2.7-1+b2
Severity: wishlist
X-Debbugs-Cc: antde...@gmail.com

Dear Maintainer,
can you update to the latest version?

https://github.com/RsyncProject/rsync

Thanks,
Antonio


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.4-1-liquorix-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsync depends on:
ii  init-system-helpers1.66
ii  libacl12.3.2-1
ii  libc6  2.37-15.1
ii  liblz4-1   1.9.4-2
ii  libpopt0   1.19+dfsg-1+b1
ii  libssl3t64 3.2.1-3
ii  libxxhash0 0.8.2-2+b1
ii  libzstd1   1.5.5+dfsg2-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-7
ii  zlib1g 1:1.3.dfsg-3.1

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client   1:9.7p1-4
ii  openssh-server   1:9.7p1-4
ii  python3  3.11.8-1
pn  python3-braceexpand  

-- Configuration Files:
/etc/default/rsync changed [not included]

-- no debconf information

Bug#1068629: jtreg7: please vendor jtreg7 dependencies to avoid the backporting overhead

[Vladimir Petko]

Source: jtreg7
Version: 7.3.1+1-1
Severity: wishlist

Dear Maintainer,

jtreg7 depends on newer versions of the Java packages such as junit4, junit5,
hamcrest, etc. Updating them in the stable releases will require significant
effort.

Vendoring the dependencies introduces a pattern of packaging that is not
sanctioned or otherwise frowned upon by other teams within Debian.

Vendored dependencies might introduce security vulnerabilities if not updated
promptly.

jtreg7  only purpose is to run the openjdk tests, and the package is not
security-sensitive, so embedding the package might not be a concern.

OpenJDK receives regular updates in stable releases and often requires an
updated jtreg package to run tests.

Vendoring dependencies can be an acceptable compromise to avoid introducing
additional complexity into the openjdk updates release process.


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

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

Bug#1068628: nheko: missing some emoji for verification

[Russell Coker]

Package: nheko
Version: 0.11.3-2
Severity: normal

This affects version 0.11.3+~0.9.2+~1.0.0+~0.3.0-2 in Unstable too.

About half the emoji are missing in verification, it's a cosmetic issue as
the names of the items are there, but it's annoying.

I'll attach the screenshots in the next message.

-- System Information:
Debian Release: 12.5
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/18 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages nheko depends on:
ii  gstreamer1.0-nice   0.1.21-1
ii  gstreamer1.0-qt51.22.0-5+deb12u1
ii  libc6   2.36-9+deb12u4
ii  libcmark0.30.2  0.30.2-6
ii  libcpp-httplib0.11  0.11.4+ds-1+deb12u1
ii  libcurl48.5.0-2
ii  libevent-core-2.1-7 2.1.12-stable-8
ii  libevent-pthreads-2.1-7 2.1.12-stable-8
ii  libfmt9 9.1.0+ds1-2
ii  libgcc-s1   13.1.0-9
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-bad1.0-0   1.22.0-4+deb12u5
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  liblmdb00.9.24-1
ii  libolm3 3.2.13~dfsg-1
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5dbus5 5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5keychain1 0.13.2-5
ii  libqt5multimedia5   5.15.8-2
ii  libqt5multimedia5-plugins   5.15.8-2
ii  libqt5network5  5.15.8+dfsg-11
ii  libqt5qml5  5.15.8+dfsg-3
ii  libqt5quick55.15.8+dfsg-3
ii  libqt5svg5  5.15.8-3
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libre2-920220601+dfsg-1+b1
ii  libspdlog1.10 [libspdlog1.10-fmt9]  1:1.10.0+ds-0.4
ii  libssl3 3.0.11-1~deb12u2
ii  libstdc++6  13.1.0-9
ii  libxcb-ewmh20.4.1-1.1
ii  libxcb1 1.15-1
ii  qml-module-qt-labs-animation5.15.8+dfsg-3
ii  qml-module-qt-labs-platform 5.15.8+dfsg-2
ii  qml-module-qt-labs-settings 5.15.8+dfsg-3
ii  qml-module-qtgraphicaleffects   5.15.8-2
ii  qml-module-qtmultimedia 5.15.8-2
ii  qml-module-qtquick-controls25.15.8+dfsg-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-3
ii  qml-module-qtquick-particles2   5.15.8+dfsg-3
ii  qml-module-qtquick-window2  5.15.8+dfsg-3
ii  qml-module-qtquick2 5.15.8+dfsg-3

Versions of packages nheko recommends:
ii  ca-certificates20230311
pn  fonts-noto-color-emoji 
pn  kimageformat-plugins   
ii  qt5-image-formats-plugins  5.15.8-2

Versions of packages nheko suggests:
pn  gstreamer1.0-vaapi  

-- debconf-show failed

Bug#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

affects 1068377 + magnum
thanks

Chris Lamb wrote:

> Whilst working on the Reproducible Builds effort [0], we noticed that
> python-oslo.messaging could not be built reproducibly.

The underlying bit of code is actually also causing src:magnum to be
unreproducible as well.


Regards,

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

Bug#1042262: cumin: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Riccardo Coccioli]

Pyparsing upstream finally made the v3.1.2 release the other day with the
fix. So I guess once that lands in unstable it should be ok.


On Sat, Apr 6, 2024 at 12:30 AM Antoine Beaupré  wrote:

> On 2023-07-27 13:04:22, Riccardo Coccioli wrote:
> > I've checked the issue and opened a bug upstream to pyparsing [1] as this
> > is indeed a regression.
> > Running CI on cumin I've also found that pylint is reporting new issues
> > related to pyparsing code, for which I've opened a separate bug upstream
> > [2].
> >
> > [1] https://github.com/pyparsing/pyparsing/issues/502
> > [2] https://github.com/pyparsing/pyparsing/issues/501
>
> Hi!
>
> Thanks for this! It looks like those are fixed upstream, do we need to
> update pyparsing to 3.1.2 to fix this bug or what's the next step?
>
> (upstream 502 is fixed in 3.1.1, in unstable, but 501 is only in
> 3.1.2...)
>
> a.
>
> --
> Sous le projecteur, on ne voit pas les autres.
> - Félix Leclerc
>

Bug#1068560: "Recommends: thin-provisioning-tools" is insufficient or unnecessary

[Vincent Lefevre]

Control: reopen -1

On 2024-04-08 09:35:35 +0200, Bastian Blank wrote:
> On Sun, Apr 07, 2024 at 11:39:12AM +0200, Vincent Lefevre wrote:
> > Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> > lvm2 currently has "Recommends: thin-provisioning-tools".
> > But in new Debian installations, lvm2 is installed without
> > this package. If thin-provisioning-tools is really expected
> > to be installed by default, something else needs to be done.
> > Otherwise this Recommends is just unnecessary.
> 
> It is necessary to implement the cache and thin parts.

So, if it is necessary, you need to make sure that it is installed.
I repeat: thin-provisioning-tools is *not* installed by default,
contrary to lvm2. The "Recommends:" does *nothing* for core packages
like lvm2.

For instance, on a machine recently installed (which was the status
just after the installation):

disset:~> dpkg -s lvm2
Package: lvm2
Status: install ok installed
[...]

disset:~> dpkg -s thin-provisioning-tools
dpkg-query: package 'thin-provisioning-tools' is not installed and no 
information is available

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

Bug#1068543: [Pkg-swan-devel] Bug#1068543: strongswan: isolation-machine autopkgtest fails: starter IS NOT RUNNING

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2024-04-07 at 10:39 +0200, Paul Gevers wrote:
> Your package has an autopkgtest, great. I recently added support for 
> isolation-machine tests on ci.debian.net for amd64 and added your 
> package to the list to use that. However, it fails. Can you please 
> investigate the situation and fix it? I copied some of the output at the 
> bottom of this report.

Hi Paul,

thanks for the report. I might try to investigate a bit but at that point
honestly I don't have much clue what happens.

Could you please provide a bit more context in the bug report so we have a bit
more data? Because at that point I didn't really ask for anything and you're
making your problem my problem, which doesn't feel really fair, to be honest.
And if enabling isolation-machine breaks the test, then maybe isolation-
machine needs to be fixed, or just not enabled? I cant say for sure but it
looks like the easiest way for me.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYTpxEACgkQ3rYcyPpX
RFubwAf7BLanLdiDs0ERBersGiLzc0+SF2Fxid7d2k4hfANYpBNvGYuM4PHwP4Up
Pizj69Ayh8tjyB0lwb0v5cnX83BLPHCVyTvIuql+HazdbnZL9/rvntPocZ9T8fr/
ecJA1X+kE3Y2Q9xhI1Q1eiCJwpkoiam3Uz4IleazoWCl/2+/cOcqRApYK7y5HGpt
Jl2CD3gCNtxiY+R2ExyrzQHvdXlSPkn92gVwcrrF4G+vsiS75fKIDaPA5KQTIPHl
zHNgX2Maw+kqKpc/2hQM5Hx5rMNsnU5ugFLSVov8jmgt3vXz4AuKgHQwiSfZbS2+
VBCgM/oAOtChVK3S/v8uxn4srKdfbg==
=CEmc
-END PGP SIGNATURE-

Bug#1068626: libdwarf-dev: please provide CMake files

[Andrius Merkys]

Package: libdwarf-dev
Version: 20210528-1

Hello,

dwarfutils seem to contain CMake files needed to find libdwarf using 
CMake's find_library(). However, these files do not seem to be installed 
into the libdwarf-dev binary package. It might be because the package is 
currently built using configure, and CMake files would be built when 
building with CMake buildsystem.


I am working on packaging coot [1] which uses find_library() to locate 
libdwarf. Could you please check if it is possible to include CMake 
files in libdwarf-dev?


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

Andrius

Bug#1068627: teem: please add support for loong64

[wuruilong]

Source: teem
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The teem package compiles incorrectly on the loong64 architecture, 
the attached patch solves this problem and has been verified to compile 
successfully

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- a/teem-1.12.0~20160122/debian/rules 2022-06-23 00:57:46.0 +
+++ b/teem-1.12.0~20160122/debian/rules 2024-04-08 07:54:44.355153371 +
@@ -23,7 +23,7 @@
 ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386))
   export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
 endif
-ifneq (,$(filter $(DEB_HOST_ARCH_CPU), arm64 powerpc ppc64 ppc64el riscv64 
s390x))
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU), arm64 loong64 powerpc ppc64 ppc64el 
riscv64 s390x))
   export DEB_CFLAGS_MAINT_APPEND = -ffp-contract=off
 endif
 

Bug#1068625: python3-sphinxcontrib.httpdomain: SyntaxWarning: invalid escape sequence '\s'

[Julian Gilbey]

Package: python3-sphinxcontrib.httpdomain
Version: 1.8.0-3
Severity: normal
Tags: patch

When installing this package in unstable (so it is byte-compiled by
python3.12), the following warning appears:

/usr/lib/python3/dist-packages/sphinxcontrib/autohttp/flask_base.py:82: 
SyntaxWarning: invalid escape sequence '\s'
  rcomp = re.compile("^\s*.. :quickref:\s*(?P.*)$")

Patch: either the regexp needs to be a raw string (r"^\s*.. [...]"),
or the two backslashes need quoting ("^\\s*.. [...]").

Best wishes,

   Julian

Bug#1068624: RFS: cjson/1.7.15-1+deb12u1 -- Ultralightweight JSON parser in ANSI C

[Maytham Alsudany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : cjson
   Version  : 1.7.15-1+deb12u1
   Upstream contact : https://github.com/DaveGamble/cJSON/issues
 * URL  : https://github.com/DaveGamble/cJSON
 * License  : MIT, Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/cjson
   Section  : libs

The source builds the following binary packages:

  libcjson-dev - Ultralightweight JSON parser in ANSI C (development files)
  libcjson1 - Ultralightweight JSON parser in ANSI C

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cjson/cjson_1.7.15-1+deb12u1.dsc

Changes since the last upload:

 cjson (1.7.15-1+deb12u1) bookworm; urgency=medium
 .
   * Update Maintainer field
   * Bump Standards-Version to 4.6.2 (no changes)
   * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
 (Closes: #1059287)
   * Add Build-Depends-Package to symbols

Kind regards,
Maytham


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

Bug#1068623: Right patch

[Christian Marillat]

On 08 avril 2024 07:15, "Debian Bug Tracking System"  
wrote:

Here is the right patch (missing !m68k)

diff -Nru mpg123-1.32.6/debian/libmpg123-0t64.symbols 
mpg123-1.32.6/debian/libmpg123-0t64.symbols
--- mpg123-1.32.6/debian/libmpg123-0t64.symbols 2024-04-05 23:18:03.0 
+0200
+++ mpg123-1.32.6/debian/libmpg123-0t64.symbols 2024-04-08 09:05:11.0 
+0200
@@ -136,4 +136,4 @@
  mpg123_volume_change@Base 1.6.2
  mpg123_volume_change_db@Base 1.30.0
 (arch=i386 hurd-i386)#include "libmpg123-0t64.symbols.32bit.in"
-(arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
+(arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
diff -Nru mpg123-1.32.6/debian/libsyn123-0t64.symbols 
mpg123-1.32.6/debian/libsyn123-0t64.symbols
--- mpg123-1.32.6/debian/libsyn123-0t64.symbols 2024-04-05 23:17:58.0 
+0200
+++ mpg123-1.32.6/debian/libsyn123-0t64.symbols 2024-04-08 09:05:11.0 
+0200
@@ -32,14 +32,14 @@
  syn123_resample_incount@Base 1.26.0
  syn123_resample_inexpect@Base 1.26.0
  syn123_resample_intotal64@Base 1.32.3
- (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_intotal@Base 
1.26.2
+ (arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
  (arch=i386 hurd-i386)syn123_resample_intotal_32@Base 1.26.2
  syn123_resample_intotal_64@Base 1.26.0
  syn123_resample_maxincount@Base 1.26.0
  syn123_resample_maxrate@Base 1.26.0
  syn123_resample_out@Base 1.32.3
  syn123_resample_total64@Base 1.32.3
- (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_total@Base 
1.26.2
+ (arch=!armel !armhf !hppa !mipsel !powerpc !m68k !sh4 
!x32)syn123_resample_total@Base 1.26.2
  (arch=i386 hurd-i386)syn123_resample_total_32@Base 1.26.2
  syn123_resample_total_64@Base 1.26.0
  syn123_setup_filter@Base 1.26.0

Bug#1068594: [pkg-gnupg-maint] Bug#1068594: gpg: 100% CPU endless loop after mkdir /etc/gnupg/gpg.conf

[Sune Stolborg Vuorela]

Control: tags -1 fixed-upstream
Control: reassign -1 libgpg-error0

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=2dc93cfecc7a7b22fd08365a789b8c6c4b8cc36c;hp=92f874e7d1150c44d8c5d4d5e2c2ddf5299e1064

Fixed upstream.

/Sune

On Sunday, April 7, 2024 7:48:07 PM CEST Valentin Hilbig wrote:
> Package: gpg
> Version: 2.4.5-1
> Severity: important
> X-Debbugs-Cc: debian-bug-re...@03.softkill.org
> 
> Dear Maintainer,
> 
> following creates an endless loop:
> 
> sudo apt install gpg
> sudo mkdir -p /etc/gnupg/gpg.conf
> gpg --version
> 
> Afterwards gpg becomes unusable system wide.
> To create the directory you usually need privileges, however my expectation
> is, that some empty directory like shown above should never do this type of
> harm!
> 
> I mark this important, as this loop affects all gpg processes system wide
> and hence might be used to create a DoS if somebody somehow manages
> to create this file as a directory instead.
> 
> Also the path /etc/gnupg/gpg.conf is not documented in man gpg.
> Undocumented paths should not be exploitable to create harm.
> Hence my expectation is that
> 
> - this file should be documented
> - there should be a way to ignore this file such that gpg does not access
> this file - gpg should ignore errors this file if it is unreadable (like
> being a directory)
> 
> I do not have any expectation about what happens when this is a file which
> includes errors.  This should be part of the documentation.
> 
> I tried to report this upstream, but failed, as I was unable to register.
> 
> The bug affects stable, unstable and experimental and was tested on a VM.
> 
> 
> -- System Information:
> Debian Release: 12.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64
> (x86_64)
> 
> Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to C.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 gpg depends on:
> ii  gpgconf  2.4.5-1
> ii  libassuan0   2.5.5-5
> ii  libbz2-1.0   1.0.8-5+b1
> ii  libc62.36-9+deb12u4
> ii  libgcrypt20  1.10.3-2
> ii  libgpg-error01.46-1
> ii  libnpth0t64  1.6-3.1
> ii  libreadline8t64  8.2-4
> ii  libsqlite3-0 3.40.1-2
> ii  zlib1g   1:1.2.13.dfsg-1
> 
> Versions of packages gpg recommends:
> ii  gnupg  2.4.5-1
> 
> gpg suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-gnupg-maint mailing list
> pkg-gnupg-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnupg-maint


-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1067916: FTBFS: tests failed

[Andrey Rakhmatullin]

On Mon, Apr 08, 2024 at 12:58:13AM +, tony mancill wrote:
> This may be a naive question, but since we're dealing with a syscall
> that passes a timespec, is there a minimum kernel version required for
> the time_t 64 userspace?
I've never heard anything about this.

> In any event, I'm not sure about the next steps here.  Any suggestions?
> Should I work with DSA to try to get a porter box with a newer kernel to
> confirm that that resolves the issue with the test?  (I think this would
> have eventual implications for the buildds.)
I would ask in a more public place (as I'm not sure there is a dedicated
t64 place which the t64 experts read). Also you can try making a qemu VM
and try different kernels there.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency

[Raphaël Halimi]

Le 07/04/2024 à 19:34, Michael Biebl a écrit :

As you correctly noticed, this is a bug/fault in debootstrap.
I don't think individual packages should work around that, so I'm 
included to close this as wontfix (or reassign/merge to debootstrap).


Fair enough, I understand. Do you want me to reassign it ?

Fwiw, you might use an alternative debootstrap tool like mmdebstrap 
which works properly in that regard.


I didn't know about this tool. Thanks for the tip :)

Regards,

--
Raphaël Halimi

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Iker Pedrosa]

Hi,

On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:

> Hi,
>
> * Iker Pedrosa  [240403 09:43]:
> > Hi Chris,
> >
> > I have some questions regarding your proposal:
> >
> >- What is the difference between liblastlog2 and libpam-lastlog2
> >binaries? Upstream util-linux only provides one binary (lastlog2) so
> this
> >confuses me.
>
> util-linux upstream provides three binary objects to be built:
> - liblastlog2.so
> - pam_lastlog2.so
> - lastlog2 (program)
>
> Debian's PAM policy says to put PAM modules into their own package,
> thus libpam-lastlog2. liblastlog2.so would go into the
>
liblastlog2(-0) package. The lastlog2 program either into its own
> lastlog2 package, or elsewhere.
>

Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
pam modules start with the prefix pam_*.

Everything else sounds good.


>
> >- Did you consider using a systemd service to upgrade from lastlog to
> >lastlog2 data?
>
> No, I did not consider this, as I wasn't aware of any
> implementations for this. Does u-l upstream ship such a service?
>

Yes,
https://github.com/util-linux/util-linux/blob/master/misc-utils/lastlog2-import.service.in


>
> > This way when the distribution is updated to the next
> >version you can also remove the lastlog binary and all its
> dependencies. In
> >addition, you can use "--disable-lastlog" in shadow to stop building
> this
> >binary.
>
> Chris
>
>

-- 

Iker Pedrosa

Senior Software Engineer, Identity Management team

Red Hat 

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb

Bug#1068623: mpg123: FTBFS Wrong architectures in symbols file

[Christian Marillat]

Source: mpg123
Version: 1.32.6-2
Severity: important

Dear Maintainer,

These symbols files :

debian/libmpg123-0t64.symbols
debian/libsyn123-0t64.symbol

Contains the wrong architecture name for ppc instead of powerpc and missing m68k

The patch below fix this issue.

Build tested for powerpc arch.

Christian

,
| diff -Nru mpg123-1.32.6/debian/libmpg123-0t64.symbols 
mpg123-1.32.6/debian/libmpg123-0t64.symbols
| --- mpg123-1.32.6/debian/libmpg123-0t64.symbols   2024-04-08 
08:49:49.0 +0200
| +++ mpg123-1.32.6/debian/libmpg123-0t64.symbols   2024-04-05 
23:18:03.0 +0200
| @@ -136,4 +136,4 @@
|   mpg123_volume_change@Base 1.6.2
|   mpg123_volume_change_db@Base 1.30.0
|  (arch=i386 hurd-i386)#include "libmpg123-0t64.symbols.32bit.in"
| -(arch=!armel !armhf !hppa !mipsel !powerpc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
| +(arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)#include 
"libmpg123-0t64.symbols.t64.in"
| diff -Nru mpg123-1.32.6/debian/libsyn123-0t64.symbols 
mpg123-1.32.6/debian/libsyn123-0t64.symbols
| --- mpg123-1.32.6/debian/libsyn123-0t64.symbols   2024-04-08 
08:50:08.0 +0200
| +++ mpg123-1.32.6/debian/libsyn123-0t64.symbols   2024-04-05 
23:17:58.0 +0200
| @@ -32,14 +32,14 @@
|   syn123_resample_incount@Base 1.26.0
|   syn123_resample_inexpect@Base 1.26.0
|   syn123_resample_intotal64@Base 1.32.3
| - (arch=!armel !armhf !hppa !mipsel !powerpc !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
| + (arch=!armel !armhf !hppa !mipsel !ppc !sh4 
!x32)syn123_resample_intotal@Base 1.26.2
|   (arch=i386 hurd-i386)syn123_resample_intotal_32@Base 1.26.2
|   syn123_resample_intotal_64@Base 1.26.0
|   syn123_resample_maxincount@Base 1.26.0
|   syn123_resample_maxrate@Base 1.26.0
|   syn123_resample_out@Base 1.32.3
|   syn123_resample_total64@Base 1.32.3
| - (arch=!armel !armhf !hppa !mipsel !powerpc !sh4 
!x32)syn123_resample_total@Base 1.26.2
| + (arch=!armel !armhf !hppa !mipsel !ppc !sh4 !x32)syn123_resample_total@Base 
1.26.2
|   (arch=i386 hurd-i386)syn123_resample_total_32@Base 1.26.2
|   syn123_resample_total_64@Base 1.26.0
|   syn123_setup_filter@Base 1.26.0
`


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

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

Bug#1068622: colobot: please add support for loong64

[wuruilong]

Source: colobot
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The colobot package compiles incorrectly on the loong64 architecture, the 
attached patch solves this problem and has been verified to compile successfully

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- a/colobot-0.2.1/debian/rules2021-09-01 16:10:16.0 +
+++ b/colobot-0.2.1/debian/rules2024-04-08 03:30:32.971012456 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 # Hippomocks doesn't support some Debian architectures
-HIPPOMOCKS_BROKEN_ARCHS=armel armhf arm64 mips mips64el mipsel
+HIPPOMOCKS_BROKEN_ARCHS=armel armhf arm64 loong64 mips mips64el mipsel 
 
 include /usr/share/dpkg/architecture.mk
 

Bug#1066055: re: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Fab Stz]

FWIW:
 - I created an issue upstream at [1]
 - rust-symphonia is required by czkawka #1032030 (+ MR at [2])

[1] https://github.com/pdeljanov/Symphonia/issues/254
[2] https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/583

Bug#1068621: ITP: bisect-ppx -- Code coverage for OCaml and ReScript

[Bo YU]

Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: bisect-ppx
  Version : 2.8.3 
  Upstream Contact: Anton Bachin 
Leonid Rozenberg 
* URL : https://github.com/aantron/bisect_ppx
* License : MIT
  Programming Lang: OCaml
  Description : Code coverage for OCaml and ReScript


Bisect-ppx helps you test thoroughly. It is a small preprocessor
that inserts instrumentation at places in your code, such as if-then-else and
match expressions. After you run tests, Bisect-ppx gives a nice HTML report
showing which places were visited and which were missed.

Usage is simple - add package bisect-ppx when building tests, run your tests,
then run the Bisect-ppx report tool on the generated visitation files."

The package is a dependency of sail[0] also. I will package it and
maintianit under Debian OCaml team.

[0]: https://bugs.debian.org/1065419


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1068620: rust-nix: please add support for loong64

[wuruilong]

Source: rust-nix
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The rust-nix package compiles incorrectly on the loong64 architecture, 
the attached patch solves this problem and has been verified to compile 
successfully

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 rust-nix (0.26.2-1) unstable; urgency=medium
 .
   * Team upload.
   * Package nix 0.26.2 from crates.io using debcargo 2.6.0
   * Skip test_recvmm2 on s390x, it seems to be flaky there.
   * Skip a couple of tests that seem prone to hangs in my local testing.
Author: Peter Michael Green 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: https://github.com/nix-rust/nix/pull/2045
Reviewed-By: 
Signed-Off-By: heiher
Last-Update: 2024-04-08

--- rust-nix-0.26.2.orig/src/sys/ioctl/linux.rs
+++ rust-nix-0.26.2/src/sys/ioctl/linux.rs
@@ -42,7 +42,8 @@ mod consts {
 target_arch = "x86_64",
 target_arch = "aarch64",
 target_arch = "riscv32",
-target_arch = "riscv64"
+target_arch = "riscv64",
+target_arch = "loongarch64"
 ))]
 mod consts {
 #[doc(hidden)]

Bug#1063982: setuptools-scm: autopkgtest regression with pytest 8

[Timo Röhling]

* Andrey Rakhmatullin  [2024-04-07 17:13]:

This works in a current sid chroot, both build-time tests and autopkgests.
Timo, do you think we can close this or does something else need to be
checked?
pytest 8.1 fixed a few regressions, so it is likely that either that 
or another fix in a dependent package has repaired the tests. Please 
go ahead and close the bug.



Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Andrius Merkys]

Hi Nilesh,

On 2024-04-07 15:28, Nilesh Patra wrote:

Assistance required with maintaining the singularity-container package.


I am not offering help with singularity-container, but do you by any 
chance know why apptainer is not packaged for Debian? I cannot find a 
wnpp bug.


Thanks for caring about singularity-container.

Andrius