Bug#1042939: RM: python-escript [i386] -- RoQA; FTBFS on i386

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-escr...@packages.debian.org
Control: affects -1 + src:python-escript

Please remove python-escript from i386 where it FTBFS (#1041457).

Kind Regards,

Bas

Bug#1040507: Default GOTOOLCHAIN value in Go1.21

[Shengjing Zhu]

Hi,

As Go1.21 is to be released recently, I'd like to know what value we
shall set for GOTOOLCHAIN env.

The default value is auto, which means it will download the newer
toolchain if go.mod ——_explicitly_ says so. See
https://go.dev/doc/toolchain for details.

Please be aware that it doesn't affect how we build Go packages, as
dh-golang will set GOTOOLCHAIN to local to prevent it from accessing
the network. So here we only discuss the user experience when using
the Go toolchain itself.

At #1040507, users are concerned if the downloaded binaries are
cryptographically verified. Yes, they are verified the same as Go
libraries. If you disable GOSUMDB, it will not be verified, but this
means all the Go libraries are not verified as well and we won't
disable that by default.

Users may have concerns about privacy, but there are already envs like
GOPROXY, which is set to https://proxy.golang.org. I don't see much
value to change GOPROXY to "off" or other values, as it really hurts
the development experience. So if users would change GOPROXY env for
privacy reason, I would expect them to change GOTOOLCHAIN as well.
(Actually if GOPROXY is set to off, go won't download newer
toolchains.)

Also I don't see much security concerns as if upstream does evil in
their binary releases I would be much concerned about their source
which is much harder to audit.

Another thought is we always release very old versions in Debian
stable. For example we just released Debian 12, which has Go1.19, but
Go1.19 is to be EOL in the next few weeks when Go1.21 is released.
Allowing Go to download a newer toolchain by default would just make
such an old version more useful...

I incline to leave the GOTOOLCHAIN value as is, any thoughts?

-- 
Shengjing Zhu

Bug#1042938: ckermit: Several issues with iksd

[John Goerzen]

Package: ckermit
Version: 402~beta08-1
Severity: normal

Hello,

I have enabled iksd in my configuration, and /srv/ftp exists.  I want to use 
anonymous mode.

Initially it added this to /etc/inetd.conf:

kermit  stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/iksd -A 
--initfile:/etc/kermit/iksd-anon.conf --dbfile:/var/run/iksd.db --syslog:5 
--root:/srv/ftp --anonymous:on


However, after connecting, I'd immediately get a "Connection terminated by 
foreign host."  Hmm.

I determined this line allows it to run and even give a login prompt:

kermit  stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/iksd -A  
--dbfile:/var/run/iksd.db --root:/srv/ftp --anonymous:on

Now, "telnet localhost kermit" will connect, and after about a 10-second delay,
display the banner and a username prompt.

However, both "anonymous" and "ftp" usernames produce "access denied".

Within kermit, "iksd localhost" doesn't work at all.  I also tried "iksd
/encrypt:none localhost", and that was no better.

Thanks!

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 ckermit depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u1
ii  libncurses66.4-4
ii  libpam0g   1.5.2-6
ii  libssl33.0.9-1
ii  libtinfo6  6.4-4

Versions of packages ckermit recommends:
ii  openssh-client [ssh-client]  1:9.2p1-2

Versions of packages ckermit suggests:
ii  openbsd-inetd [inet-superserver]  0.20221205-1

-- debconf information:
* ckermit/iksd-anondir: /srv/ftp
* ckermit/iksd: true
  ckermit/iksd-no-inetd:
* ckermit/iksd-anon: true

Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc

[Manphiz]

Nicholas D Steeves  writes:

> Hello,
>
> Would you like to fix this RC bug and adopt the package?
>
>   https://bugs.debian.org/1042911
>
> and the orphan bug is here: #1016558
>
> Best,
> Nicholas
>

Hi Nicolas,

Thanks for reaching out!  Looks like this was caused by the removal of
the obsolete "assoc" package in Emacs 29.1 which had been deprecated
since 24.  I'll try to work on a fix later this week.

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1027168: onetbb: Please add patch to fix FTBFS on sh4

[Petter Reinholdtsen]

[John Paul Adrian Glaubitz 2022-12-28]
> I will forward the patch later after reformating it.

Did you foward the sh4 patch upstream?  I could not find it.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1025779: onetbb: Please add patch to add support for ia64

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/oneapi-src/oneTBB/pull/983

A fix for this was applied upstream in
commit 55b8e1b1671dbc66f7d192e4163a3df2941c7efd 2023-01-09, according to
the upstream pull request.

[M. Zhou]
> I'm not sure whether the latest assembly code in
> https://github.com/oneapi-src/oneTBB/pull/983
> would avoid those segfaults, so tagging this bug
> with moreinfo.

Perhaps you can provide more information now the patched code is
upstream?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

On Wed, Aug 2, 2023 at 8:04 PM Nicholas D Steeves  wrote:
> It's great to hear from you :)

tbh, I'm a bit surprised at a lot of the frustration and surprise i'm
reading - I've replied whenever I've got the email and have tried to
be helpful. It's great to be asked or sent an email, I guess?

> time and energy to review and merge Mateusz's work in the near future?

This is now the 3rd time I've offered to sponsor? Yeah. Again - please
send me an updated DSC I can review that turns it into a regular
upload -- either call it a Team Upload or a normal one and Mateusz -
you can add yourself as an Uploader, please.

I'll also say I'm lowNMU so this could have just been done without me,
but since I'd be sponsoring I don't want to sponsor a NMU against a
package I'm on the Uploaders for.

  Paul

-- 
:wq

Bug#1042937: libsasl2-dev should depend on libssl-dev

[Sergio Durigan Junior]

Source: cyrus-sasl2
Version: 2.1.28+dfsg1-2
Severity: grave

Hi there,

I noticed that the last upload for cyrus-sasl2 removed the md5.h header
file (among other stuff).  As it turns out, /usr/include/sasl/hmac-md5.h
will include  which will make builds using the header
FTBFS.  This is currently the case with OpenLDAP.

I'd like to request that libsasl2-dev depend on libssl-dev so that we
can get a working md5.h.

Thanks,

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


signature.asc
Description: PGP signature

Bug#1042936: scipy autopkg tests fail on armhf in unstable

[Matthias Klose]

Package: src:scipy
Version: 1.10.1-2
Severity: serious
Tags: sid trixie

one failure in the openblas autopkg tst

see https://ci.debian.net/data/autopkgtest/testing/armhf/s/scipy/36350169/log.gz

[...]
1593s === FAILURES 
===
1593s __ TestExpmFrechet.test_fuzz 
___
1593s /usr/lib/python3/dist-packages/scipy/linalg/tests/test_matfuncs.py:795: in 
test_fuzz

1593s assert_allclose(expected_expm, observed_expm, atol=5e-8)
1593s A  = array([[1.29500584e-01, 2.93812784e-02, 
4.06752600e-01],
1593s[1.06990066e+00, 1.92639780e-01, 1.89295833e-01],
1593s[9.04790698e-05, 1.52946804e-01, 9.71213319e-01]])
1593s A_original = array([[4.62247608e-01, 1.04875401e-01, 
1.45188856e+00],
1593s[3.81897135e+00, 6.87620661e-01, 6.75684567e-01],
1593s[3.22961737e-04, 5.45938033e-01, 3.46671049e+00]])
1593s A_original_norm_1 = 5.594283612854939
1593s E  = array([[1.05141771, 0.02556283, 0.30353237],
1593s[0.04803694, 1.38737301, 0.21559779],
1593s[0.33469411, 0.02223573, 0.20598777]])
1593s E_original = array([[3.75299715, 0.0912456 , 1.08344772],
1593s[0.1714661 , 4.95217733, 0.76956845],
1593s[1.19467841, 0.07936964, 0.73526584]])
1593s M  = array([[1.29500584e-01, 2.93812784e-02, 
4.06752600e-01, 1.05141771e+00,

1593s 2.55628339e-02, 3.03532371e-01],
1593s  ...-01],
1593s[0.e+00, 0.e+00, 0.e+00, 9.04790698e-05,
1593s 1.52946804e-01, 9.71213319e-01]])
1593s expected_expm = array([[1.17278791, 0.08410441, 0.36956138],
1593s[1.27548153, 1.27086948, 0.69467426],
1593s[0.12925538, 0.28389489, 2.69125205]])
1593s expected_frechet = array([[1.37086962, 0.16031551, 1.00697241],
1593s[1.71725501, 1.80776158, 1.2305117 ],
1593s[0.73936754, 0.26382299, 0.77190579]])
1593s i  = 79
1593s n  = 3
1593s ntests = 100
1593s observed_expm = array([[1.17278791, 0.08410441, 0.73912276],
1593s[1.27548153, 1.27086948, 0.69467426],
1593s[0.12925538, 0.28389489, 2.69125205]])
1593s observed_frechet = array([[1.37086962, 0.16031551, 1.00697241],
1593s[1.71725501, 1.80776158, 1.2305117 ],
1593s[0.73936754, 0.26382299, 0.77190579]])
1593s rfunc  = numpy.random.mtrand.RandomState object at 0xd0b266a8>
1593s rfuncs = (numpy.random.mtrand.RandomState object at 0xd0b266a8>, of numpy.r...ndomState object at 0xd0b266a8>, numpy.random.mtrand.RandomState object at 0xd0b266a8>)

1593s scale  = 0.2801541468532912
1593s self   = object at 0xcdccc250>

1593s target_norm_1 = 1.567261752814723
1593s /usr/lib/python3.11/contextlib.py:81: in inner
1593s return func(*args, **kwds)
1593s E   AssertionError:
1593s E   Not equal to tolerance rtol=1e-07, atol=5e-08
1593s E
1593s E   Mismatched elements: 1 / 9 (11.1%)
1593s E   Max absolute difference: 0.36956138
1593s E   Max relative difference: 0.5
1593s Ex: array([[1.172788, 0.084104, 0.369561],
1593s E  [1.275482, 1.270869, 0.694674],
1593s E  [0.129255, 0.283895, 2.691252]])
1593s Ey: array([[1.172788, 0.084104, 0.739123],
1593s E  [1.275482, 1.270869, 0.694674],
1593s E  [0.129255, 0.283895, 2.691252]])
1593s args   = (.compare at 
0xcb71a2f8>, array([[1.17278791, 0.08410441, 0.36956138],

1593s[1.275...1, 0.08410441, 0.73912276],
1593s[1.27548153, 1.27086948, 0.69467426],
1593s[0.12925538, 0.28389489, 2.69125205]]))
1593s func   = 
1593s kwds   = {'equal_nan': True, 'err_msg': '', 'header': 'Not 
equal to tolerance rtol=1e-07, atol=5e-08', 'verbose': True}
1593s self   = 0xcffcab50>
1593s === short test summary info 

1593s FAILED ../../tests/test_matfuncs.py::TestExpmFrechet::test_fuzz - 
AssertionEr...
1593s = 1 failed, 1911 passed, 6 skipped, 1653 deselected, 14 xfailed, 1 xpassed 
in 30.57s =

Bug#1042935: sagemath autopkg tests fail on i386 in unstable

[Matthias Klose]

Package: src:sagemath
Version: 9.5-6
Severity: serious
Tags: sid trixie

see 
https://ci.debian.net/data/autopkgtest/testing/i386/s/sagemath/36323965/log.gz

[...]
7183s Total time for all tests: 6888.5 seconds
7183s cpu time: 10109.5 seconds
7183s cumulative wall time: 13105.7 seconds
7183s Features detected for doctesting: 
sage.combinat,sage.geometry.polyhedron,sage.graphs,sage.plot,sage.rings.number_field,sage.rings.real_double,sage.symbolic,sagemath_doc_html,sphinx

7183s Pytest is not installed, skip checking tests that rely on it.
7183s Success: 186 tests failed, up to 200 failures are tolerated
7183s Error: critical test failures (e.g. timeout, segfault, etc.)
7183s make: *** [debian/tests.mk:57: had-few-failures] Error 1

Bug#1042934: pytango autopkg tests fail on amd64 in unstable

[Matthias Klose]

Package: src:pytango
Version: 9.3.6-2.1
Severity: serious
Tags: sid trixie

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pytango/36334683/log.gz

[...]
155s === FAILURES 
===
155s ___ test_subscribe_data_ready_event[Futures] 
___

155s event_device = EventDevice(test/nodb/eventdevice)
155s
155s def test_subscribe_data_ready_event(event_device):
155s results_data_ready_event = []
155s
155s def callback_data_ready(evt):
155s results_data_ready_event.append(evt.ctr)
155s
155s # Subscribe to data ready event
155s eid_data_ready = event_device.subscribe_event(
155s "attr", EventType.DATA_READY_EVENT, callback_data_ready, 
wait=True)
155s assert eid_data_ready == 1
155s # Trigger an event
155s event_device.command_inout("send_data_ready_event", wait=True)
155s # Wait for tango event
155s retries = 20
155s for _ in range(retries):
155s event_device.read_attribute("state", wait=True)
155s if len(results_data_ready_event):
155s break
155s time.sleep(0.05)
155s # Test the event values
155s >   assert results_data_ready_event == [2]
155s E   assert [] == [2]
155s E Right contains one more item: 2
155s E Full diff:
155s E - [2]
155s E ?  -
155s E + []
155s
155s tests/test_event.py:146: AssertionError
155s  Captured stdout setup 
-

155s Ready to accept request
155s  Captured stderr setup 
-

155s Can't create notifd event supplier. Notifd event not available
155s === warnings summary 
===

155s ../../../../usr/lib/python3/dist-packages/tango/utils.py:176
155s   /usr/lib/python3/dist-packages/tango/utils.py:176: DeprecationWarning: 
`np.bool8` is a deprecated alias for `np.bool_`.  (Deprecated NumPy 1.24)

155s CmdArgType.DevBoolean: numpy.bool8,
155s
155s tests/test_client.py:19
155s 
/tmp/autopkgtest-lxc.p9321foh/downtmp/autopkgtest_tmp/tests/test_client.py:19: 
DeprecationWarning: The distutils package is deprecated and slated for removal 
in Python 3.12. Use setuptools or check PEP 632 for potential alternatives

155s from distutils.spawn import find_executable
155s
155s -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
155s === short test summary info 


155s FAILED tests/test_event.py::test_subscribe_data_ready_event[Futures]
155s == 1 failed, 1092 passed, 26 xfailed, 2 warnings in 99.86s (0:01:39) 
===

Bug#1042815: linux-image-6.1.0-10-amd64: Fails to load kernel modules due to bpf/btf issue

[AP]

On Tue, Aug 01, 2023 at 01:44:26PM +0200, Salvatore Bonaccorso wrote:
> > PS: This, I think, is covered in bug 1003965 but my attempt to email into 
> > that bug appears
> > to have failed. If it ever succeeds apologies for the dupe report. :(
> 
> is the assumption that you updated from 6.1.37-1 or 6.1.38-1 to
> 6.1.38-2 (or any of the combinations which did not bump ABI) but did
> not reboot before loading the module correct?

Nope. You're right. This is what happens when you ansiblise everything.

The initial image is with -1, my playbook upgraded it to -2 and tried to use it
and it failed. Just did a manual test and modified my playbook to reboot and
tested that and it works fine after reboot.

So... my bad. Feeling a bit sheepish. Apologies.

Still... downloading and installing a new kernel shouldn't break a live system.

Andrew

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

[Matthias Klose]

Package: src:octave-statistics
Version: 1.6.0-1
Severity: serious
Tags: sid trixie

octave autopkg tests fail in unstable on amd64 (triggered by gcc-13).

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-statistics/36329437/log.gz

Not sure which ones are the regressions, because all failures seem to be marked 
as "known failure".

Bug#1042932: ksshaskpass: Error message from ksshaskpass: QSocketNotifier: Can only be used with threads started with QThread

[Chris Hanson]

Package: ksshaskpass
Version: 4:5.27.5-2
Severity: minor
X-Debbugs-Cc: c...@chris-hanson.org

Dear Maintainer,

This has been happening since I installed Debian shortly after the
release.  I believe it's caused by ksshaskpass and not ssh because the
message goes away when the key is added to the ssh key agent.

I haven't tested this with a different askpass program but I think
it's pretty obvious that this is a qt/kde issue.

FWIW I'm running KDE on Wayland.

Please let me know if you need any other info.

Chris

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/20 CPU threads; PREEMPT)
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 ksshaskpass depends on:
ii  libc6 2.36-9+deb12u1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5wallet-bin  5.103.0-1
ii  libkf5wallet5 5.103.0-1
ii  libkf5widgetsaddons5  5.103.0-1
ii  libqt5core5a  5.15.8+dfsg-11
ii  libqt5widgets55.15.8+dfsg-11
ii  libstdc++612.2.0-14
ii  openssh-client1:9.2p1-2

Versions of packages ksshaskpass recommends:
ii  kwalletmanager  4:22.12.3-1

ksshaskpass suggests no packages.

-- no debconf information

Bug#1042928: Please include example handler for mailto: URIs

[Nicholas D Steeves]

Hi David,

David Bremner  writes:

> Control: severity -1 wishlist

Spoiler, it looks like this may need to be increased.

> Nicholas D Steeves  writes:
>
>> It would be wonderful if elpa-notmuch provided an example handler for
>> mailto: URIs.  Somewhere along the line I seem to have added a custom
>> one; however, for some reason it opens message-mode rather than
>> notmuch-message-mode.  Consequently, messages are not correctly Fcced,
>> and are lost rather than inserted into the correct folder.  Needless
>> to say, they're not indexed either.
>>
>> I'm not sure if I made a dumb mistake, or if this is nontrivial.
>>
>> I think the dh-examples mechanism should be used, because the user may
>> be using emacsclient, or may be using Gnus or some other alternative
>> to Message Mode.
>
> I'm not sure exactly what you want, but it doesn't sound debian
> specific. I'd imagine that your desired example could be included in the
> upstream info / html docs.

I agree that this shouldn't be Debian-specific.

Meanwhile, it seems like this wasn't a dumb mistake of mine.

$ apt-file search notmuch | grep desktop
notmuch: /usr/share/applications/notmuch-emacs-mua.desktop

Given my bug report (the URI with the email body isn't opened in
notmuch-message-mode), I'm not sure if the bug is in bin:notmuch,
bin:elpa-notmuch, or Emacs.

Steps to reproduce:

1. Set Notmuch as the default application for email (or URI handler)
2. Navigate to the BTS in a web browser like Firefox
3. Find a bug, and click on one of the reply links
4. Emacs opens in message-mode rather than notmuch-message-mode

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hello Alexandru,

Thank you for this latest update.  Notes follow inline.  Please count
the TODO items, resolve 4/4, and file an MR.

Alexandru Mihail  writes:

> Hello again, Nicholas !
>
> ---
> debian/copyright:
>
> Files: htpasswd.c htpasswd.1
> Copyright: 1993-1994 Rob McCool 
> Copyright: 1997 Jef Poskanzer 
> License: BSD-2-clause
> Comment: htpasswd* are mostly NCSA licensed. 
>  RobMcCool's copyright was established by examining original NCSA httpd

1. Please indent everything in the Comment: field by a single white space
at the beginning of the line.

> source code mirrored here:
> https://github.com/TooDumbForAName/ncsa-httpd/
> This git repository is a convenient copy of the NCSA HTTPd 1.5.2 source
> code which was verified to be accurate and complete by comparing with a
> WaybackMachine capture of the original NCSA ftp archive found here:
> https://web.archive.org/web/20130120184619/http://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z

Does that link really work?  Are you sure it's not this one?

https://web.archive.org/web/20160619204223/ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z

I'm surprised the WayBack Machine dates that file June 19, 2016--very
curious.

> Portions of htpasswd* were edited by Jef Poskanzer, thus these files
> remain under BSD-2-clause.

The copyright info you've written in this version is immensely improved :)

2. Beyond this, you'll need to add a on every blank line that

 .

so that the paragraphs in the "Comment" field of the "Files: htpasswd.c
htpasswd.1" aren't split by an empty newline; they need to remain part
of the same field.  Nagivate to /usr/share/doc/*/copyright for many
examples.

> NCSA License:
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
  .
> We ask, but do not require, that the following message be included in
> all derived works:
  .
> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
  .
> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.

 /\ It will look something like that (note the new indented periods)

>  debian-legal thread:
> https://lists.debian.org/debian-legal/2023/07/msg1.html
>
> ---
> Nicholas, I've finally found an "original" copy 
> of the httpd 1.5.2 src !! (Mentioned in the text above, it's the very
> long WaybackMachine link).

You have exceptional research skills.

> After diff'ing the github copy and the
> original .tar.Z (also, haven't seen that format in years), they seem to
> match! Thus, I can confirm the github copy is accurate (previously, we
> had no authoritative way to trust the github repo).

Oh man, yeah, hello early days of the internet!  All you need now is
some MIDI files and GIFs.

3. Please note which version of NCSA httpd matches mini-httpd.

>>I'm still not certain that this wiki contributor's position is
>>legally
>>sound everywhere in the world.  For a counter example see:
>>
> https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe
>
> I've read the link and I share your concerns. I'm a bit lost
> here..maybe another question to legal is the right choice ?

While I'm not a lawyer, I believe that the approach we're going with is
more legally defensible around the world than the aspirational public
domain one.  BSD-2-clause is also better understood than NCSA as far as
I know. I'm relieved that work this didn't end up being a pulp novel
situation where someone stumbles onto a dirty rotten secret at the heart
of the origins of the internet while untangling the roots of a project
like this one.  

As an aside, the last release that Robert McCool worked on was v1.3, and
then he left in 1994 [1].

> Thanks for your time and may you have a great day,

You're welcome, you too!  Send me that merge request when you have time.


Cheers,
Nicholas

[1] 
https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html


signature.asc
Description: PGP signature

Bug#1042931: dpkg-dev: dpkg-buildpackage -P option does not work

[Thorsten Glaser]

Package: dpkg-dev
Version: 1.21.22
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I tried to use build profiles for the first time today, and after
running into trouble with pbuilder I tried to run it manually and
found that even that doesn’t work:

$ dpkg-buildpackage -P nocheck
dpkg-buildpackage: error: unknown option or argument nocheck

Use --help for program usage information.



-- Package-specific info:

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-dev depends on:
ii  binutils  2.40.50.20230625-1
ii  bzip2 1.0.8-5+b1
ii  libdpkg-perl  1.21.22
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.36.0-7
ii  tar   1.34+dfsg-1.2
ii  xz-utils  5.4.1-0.2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.10
ii  clang-16 [c-compiler]1:16.0.6-3
ii  fakeroot 1.31-1.2
ii  gcc [c-compiler] 4:12.3.0-1
ii  gcc-11 [c-compiler]  11.4.0-1
ii  gcc-12 [c-compiler]  12.3.0-4
ii  gnupg2.2.40-1.1
ii  gpgv 2.2.40-1.1
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Bug#1042930: pbuilder: --profiles does not work

[Thorsten Glaser]

Package: pbuilder
Version: 0.231
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I tried to use build profiles for the first time today, and I
found out that pbuilder’s --profiles option advertises to
support them, so I ran (via a wrapper and cowbuilder) it with
--hookdir .h --profiles nocheck --build Projekte/openjdk-8_8u382-ga-2.dsc
but the -P option was not passed to dpkg-buildpackage, making the
build fail; the B-D were correctly elided though.


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  debootstrap1.0.123+deb11u1
ii  dpkg-dev   1.20.12

Versions of packages pbuilder recommends:
ii  devscripts  2.21.3+deb11u1
ii  eatmydata   105-9
ii  fakeroot1.25.3-1.1
ii  iproute25.10.0-4
ii  net-tools   1.60+git20181103.0eebece-1
ii  sudo1.9.5p2-3+deb11u1

Versions of packages pbuilder suggests:
ii  cowdancer   0.89
pn  gdebi-core  

-- debconf information:
  pbuilder/mirrorsite: http://mirror.virt.tarent.de/mirror/ubuntu
* pbuilder/rewrite: false
  pbuilder/nomirror:

Bug#1042929: plasma-workspace: plasmashell becomes unresponsive for several minutes when a USB drive is plugged in

[Alex Krusemark]

Package: plasma-workspace
Version: 4:5.27.5-2+b2
Severity: important
X-Debbugs-Cc: akrusem...@posteo.net

Upon plugging in a USB flash drive to the computer, plasmashell (such as the
panel, launcher, and krunner) freezes and become completely unresponsive for
several minutes. During this time I can use programs in open windows and kwin
continues working, but I cannot interact with plasma itself. After a few
minutes, the new disk becomes available and plasmashell usually starts working
again.

I am not sure whether the root cause is in plasmashell, udisks, or somewhere in
between, but of course the shell is not expected to freeze while waiting on a
background job.

While the shell is frozen, it logs this output:

kf.solid.backends.udisks2: Error getting props:
"org.freedesktop.DBus.Error.NoReply" "Did not receive a reply. Possible causes
include: the remote application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the network connection
was broken." for "/org/freedesktop/UDisks2/block_devices/sdi"
file:///usr/share/plasma/plasmoids/org.kde.plasma.devicenotifier/contents/ui/DeviceItem.qml:36:5:
Unable to assign [undefined] to bool


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
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 plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus] 1.14.8-2
ii  dbus-x11 [dbus-session-bus]  1.14.8-2
ii  drkonqi  5.27.5-2
ii  frameworkintegration 5.107.0-1
ii  gdb-minimal [gdb]13.2-1
ii  init-system-helpers  1.65.2
ii  iso-codes4.15.0-1
ii  kactivitymanagerd5.27.5-2
ii  kded55.107.0-1
ii  kinit5.107.0-1
ii  kio  5.107.0-1
ii  kpackagetool55.107.0-1
ii  kwin-common  4:5.27.5-3+b1
ii  libappstreamqt2  0.16.2-1
ii  libc62.37-6
ii  libcolorcorrect5 4:5.27.5-2+b2
ii  libcrypt11:4.4.36-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.13.0+dfsg-1
ii  libgcc-s113.1.0-9
ii  libgps30 3.25-1
ii  libice6  2:1.0.10-1
ii  libicu72 72.1-3
ii  libkf5activities55.107.0-1
ii  libkf5activitiesstats1   5.107.0-1
ii  libkf5archive5   5.107.0-1
ii  libkf5authcore5  5.107.0-1
ii  libkf5baloo5 5.107.0-1
ii  libkf5bookmarks5 5.107.0-1
ii  libkf5calendarevents55.107.0-1
ii  libkf5completion55.107.0-1
ii  libkf5config-bin 5.107.0-1
ii  libkf5configcore55.107.0-1
ii  libkf5configgui5 5.107.0-1
ii  libkf5configwidgets5 5.107.0-2
ii  libkf5coreaddons55.107.0-1
ii  libkf5crash5 5.107.0-1
ii  libkf5dbusaddons55.107.0-1
ii  libkf5declarative5   5.107.0-1
ii  libkf5globalaccel-bin5.107.0-2
ii  libkf5globalaccel5   5.107.0-2
ii  libkf5guiaddons5 5.107.0-1
ii  libkf5holidays5  1:5.107.0-1
ii  libkf5i18n5  5.107.0-1+b1
ii  libkf5iconthemes55.107.0-1+b1
ii  libkf5idletime5  5.107.0-1
ii  libkf5jobwidgets55.107.0-1
ii  libkf5kcmutils5  5.107.0-2
ii  libkf5kexiv2-15.0.0  

Bug#1042928: Please include example handler for mailto: URIs

[David Bremner]

Control: severity -1 wishlist

Nicholas D Steeves  writes:

> It would be wonderful if elpa-notmuch provided an example handler for
> mailto: URIs.  Somewhere along the line I seem to have added a custom
> one; however, for some reason it opens message-mode rather than
> notmuch-message-mode.  Consequently, messages are not correctly Fcced,
> and are lost rather than inserted into the correct folder.  Needless
> to say, they're not indexed either.
>
> I'm not sure if I made a dumb mistake, or if this is nontrivial.
>
> I think the dh-examples mechanism should be used, because the user may
> be using emacsclient, or may be using Gnus or some other alternative
> to Message Mode.

I'm not sure exactly what you want, but it doesn't sound debian
specific. I'd imagine that your desired example could be included in the
upstream info / html docs.

Bug#1006294: bullseye-pu: package knewstuff/5.78.0-4

[Patrick Franz]

Hi,

On Mon, 24 Jul 2023 21:20:41 +0100 Jonathan Wiltshire  
wrote:
[...]
> Please go ahead.

Package has been uploaded.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1006293: bullseye-pu: package plasma-desktop/4:5.20.5-4

[Patrick Franz]

Hi,

On Sun, 30 Jul 2023 14:51:03 +0100 Jonathan Wiltshire  
wrote:
[...]
> Please go ahead.

Package has been uploaded.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Nicholas D Steeves]

Hi Paul,

Paul Tagliamonte  writes:

> I /am/ one of the package maintainers :)
>

It's great to hear from you :)  As one of the maintainers, will you have
time and energy to review and merge Mateusz's work in the near future?
Alternatively, would you be willing to add Mateusz as an Uploader and to
let a mentor review and sponsor the proposed changes?  I'm happy that
you wrote back, because the best solution is collaboration!

Mateusz, I'm supposing that you would be ok with this, because you've
made a number of changes to fluxbox that are not appropriate for an NMU
and that are the domain of a package's maintainers.  Consequently, it
makes it look like you'd like to help with the periodic maintenance of
this package.  Please let us know if this isn't what you want.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3

[Patrick Franz]

Hi,

On Tue, 25 Jul 2023 22:31:30 +0100 Jonathan Wiltshire  
wrote:
> Hi,
> 
> This request was approved but not uploaded in time for the previous 
> point release (11.7). Should it be part of 11.8 in a few weeks time, 
> or abandoned and closed?

Package has been uploaded.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1042928: Please include example handler for mailto: URIs

[Nicholas D Steeves]

Package: elpa-notmuch
Version: 0.37-1
Severity: normal

It would be wonderful if elpa-notmuch provided an example handler for mailto: 
URIs.  Somewhere along the line I seem to have added a custom one; however, for 
some reason it opens message-mode rather than notmuch-message-mode.  
Consequently, messages are not correctly Fcced, and are lost rather than 
inserted into the correct folder.  Needless to say, they're not indexed either.

I'm not sure if I made a dumb mistake, or if this is nontrivial.

I think the dh-examples mechanism should be used, because the user may be using 
emacsclient, or may be using Gnus or some other alternative to Message Mode.

If this sounds uninteresting, please ping me in a few weeks, and then 
periodically, because this a papercut that I'm motivated to look into when I 
have time.

Thanks again for making high volume email tolerable!
Nicholas

Bug#999962: silversearcher-ag: depends on obsolete pcre3 library

[Nicholas D Steeves]

Dear Hajime Mizuno, or whoever might be thinking about salvaging this
package,

The best solution appears to be encouraging and supporting this friendly
fork:

  https://github.com/ggreer/the_silver_searcher/issues/1515

The next best solution appears to be switching to a fork that fixed this
pcre3 issue (and added the new PCRE2 support); however, it's also
currently unmaintained.  Please see the above link for what I believe is
the locus of future community support for The Silver Searcher.


Sincerely,
Nicholas

https://wiki.debian.org/PackageSalvaging


signature.asc
Description: PGP signature

Bug#1040326: RE: RPF jwalk and tabular

[Victor Westerhuis]

Control: retitle 1040326 ITP: rust-jwalk -- Filesystem walk performed in 
parallel with streamed and sorted results
Control: owner 1040326 !

Hi Matthias,

On Tue, 4 Jul 2023 17:14:36 +0200 (CEST) matthias.geiger1...@tutanota.de wrote:

Hi Victor.

Note that the rust teams' policy is only to file bugs for rust crates
if they are binary ones (e.g. /usr/bin/foo).
It's not wrong; you can leave those open for now. Since most members
on the rust team are kinda busy I'd suggest to look into whether you
want to package those crates yourself. Usually it's straightforward;
if you're interested you can look into it here
.

Feel free to ask me or on the debian-rust irc channel if you have any
questions :)

regards,

---
Matthias Geiger (werdahias)


Thanks for the response! My spam filter apparently ate your original message, 
so I only noticed now that I'm trying to package jwalk myself. I'll follow the 
advice and open a MR. I see someone else is already busy packaging tabular, so 
I'll wait for that MR to get merged and for the new package to clear NEW.

--
Groet, Regards,

Victor Westerhuis 

Bug#1042739: O: repetier-host -- host controller for RepRap style 3D printers

[Ying-Chun Liu (PaulLiu)]

Hi Bastian,

I'd like to know why you can orphan my package?

The problem here is repetier-host is still working.
And why it is not upgrading to 2.x.x is because 0.85 is the last open source 
version we can have.
Since 0.95 the upstream choose to close source. So the open source community 
can only use 0.85.

And 0.85 is still working quite well with most of the 3D printers.

Yours,
Paul


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042218: ruby-moneta: FTBFS: ERROR: Test "ruby3.1" failed: cannot load such file -- ox/ox

[Leandro Cunha]

Control: tag -1 pending

Hello,

A fix for this has already been discovered and I've already asked to
upload it for fix. It was already known to me and I apologize for the
delay.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

I /am/ one of the package maintainers :)

On Wed, Aug 2, 2023, 6:37 PM Tong Sun  wrote:

> Retry for Paul.
>
> The NMU is not from me but Mateusz.
>
> Hope you'll be a DM soon @Mateusz, but meanwhile, I concur with Paul,
> don't do NMU, be the package owner and do a normal maintainer upload
> @Mateusz, as you cans see from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927477 that the
> package owner stop responding to people more than 5 years ago.
>
> @Paul, no hurry, take your time, as we've been waiting for more than 8
> years, 
>
> cheers
>
> On Wed, Aug 2, 2023 at 6:25 PM Paul Tagliamonte - paul...@debian.org
> wrote:
> >
> > Happy to review - why a NMU? Let's make it a team upload or you're
> welcome to join as an uploader!
> >
> > I don't see the bug on CC, but please feel free to re add it on your
> reply
> >
> > I'll see about reviewing this later today, but I'd prefer to have this
> be a normal maintainer upload :)
> >
> > Paul
> >
> > On Wed, Aug 2, 2023, 6:20 PM Tong Sun  wrote:
> >>
> >> Thanks Mateusz.
> >>
> >> Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just
> trying to stir up some noise to get you more traction.
> >>
> >> CCing Paul who offered me help last time when I attempted it.
> >>
> >> Thanks everyone!
> >>
> >> On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl
> wrote:
> >>>
> >>> Package: sponsorship-requests
> >>> Severity: important
> >>>
> >>> Dear mentors,
> >>>
> >>> I am looking for a sponsor for my package "fluxbox":
> >>>
> >>>  * Package name : fluxbox
> >>>Version  : 1.3.7-1+nmu1
> >>>Upstream contact : fluxbox maintainers
> >>>  * URL  : https://fluxbox.org
> >>>  * License  : CC-BY-SA-3, Expat
> >>>  * Vcs  : [fill in URL of packaging vcs]
> >>>Section  : x11
> >>>
> >>> The source builds the following binary packages:
> >>>
> >>>   fluxbox - Highly configurable and low resource X11 Window manager
> >>>
> >>> To access further information about this package, please visit the
> following URL:
> >>>
> >>>   https://mentors.debian.net/package/fluxbox/
> >>>
> >>> Alternatively, you can download the package with 'dget' using this
> command:
> >>>
> >>>   dget -x
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc
> >>>
> >>> Changes since the last upload:
> >>>
> >>>  fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
> >>>  .
> >>>* Non-maintainer upload. (See #927477)
> >>>* Upload to unstable, latest upstream version stuck in experimental
> for
> >>>  8 years. (Closes: #969440 #987223)
> >>>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
> >>>* Drop depends on deprecated GTK 2. No longer used. (Closes:
> #967345)
> >>>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS
> with
> >>>  build-system: fix "make check".
> >>>* Bump dh version to 13.
> >>>* Bump Standards-Version to 4.6.2.
> >>>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch
> for
> >>>  replace FbRootWindow::depth with maxDepth. (Closes: #1003798)
> >>>
> >>> Regards,
> >>> --
> >>>   Mateusz Łukasik
> >>>
> >>>
>

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Tong Sun]

Retry for Paul.

The NMU is not from me but Mateusz.

Hope you'll be a DM soon @Mateusz, but meanwhile, I concur with Paul,
don't do NMU, be the package owner and do a normal maintainer upload
@Mateusz, as you cans see from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927477 that the
package owner stop responding to people more than 5 years ago.

@Paul, no hurry, take your time, as we've been waiting for more than 8
years, 

cheers

On Wed, Aug 2, 2023 at 6:25 PM Paul Tagliamonte - paul...@debian.org wrote:
>
> Happy to review - why a NMU? Let's make it a team upload or you're welcome to 
> join as an uploader!
>
> I don't see the bug on CC, but please feel free to re add it on your reply
>
> I'll see about reviewing this later today, but I'd prefer to have this be a 
> normal maintainer upload :)
>
> Paul
>
> On Wed, Aug 2, 2023, 6:20 PM Tong Sun  wrote:
>>
>> Thanks Mateusz.
>>
>> Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just 
>> trying to stir up some noise to get you more traction.
>>
>> CCing Paul who offered me help last time when I attempted it.
>>
>> Thanks everyone!
>>
>> On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl wrote:
>>>
>>> Package: sponsorship-requests
>>> Severity: important
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "fluxbox":
>>>
>>>  * Package name : fluxbox
>>>Version  : 1.3.7-1+nmu1
>>>Upstream contact : fluxbox maintainers
>>>  * URL  : https://fluxbox.org
>>>  * License  : CC-BY-SA-3, Expat
>>>  * Vcs  : [fill in URL of packaging vcs]
>>>Section  : x11
>>>
>>> The source builds the following binary packages:
>>>
>>>   fluxbox - Highly configurable and low resource X11 Window manager
>>>
>>> To access further information about this package, please visit the 
>>> following URL:
>>>
>>>   https://mentors.debian.net/package/fluxbox/
>>>
>>> Alternatively, you can download the package with 'dget' using this command:
>>>
>>>   dget -x 
>>> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc
>>>
>>> Changes since the last upload:
>>>
>>>  fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
>>>  .
>>>* Non-maintainer upload. (See #927477)
>>>* Upload to unstable, latest upstream version stuck in experimental for
>>>  8 years. (Closes: #969440 #987223)
>>>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
>>>* Drop depends on deprecated GTK 2. No longer used. (Closes: #967345)
>>>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS with
>>>  build-system: fix "make check".
>>>* Bump dh version to 13.
>>>* Bump Standards-Version to 4.6.2.
>>>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch for
>>>  replace FbRootWindow::depth with maxDepth. (Closes: #1003798)
>>>
>>> Regards,
>>> --
>>>   Mateusz Łukasik
>>>
>>>

Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures

[Petter Reinholdtsen]

[M. Zhou]
> The issue still exists with armel:
> https://buildd.debian.org/status/package.php?p=onetbb

If so, this is a duplicate of 
https://bugs.debian.org/1042009 >, which is about the armel issue,
and should be closed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures

[M. Zhou]

The issue still exists with armel:
https://buildd.debian.org/status/package.php?p=onetbb

On Wed, 2023-08-02 at 22:46 +0200, Petter Reinholdtsen wrote:
> [M. Zhou]
> > I'm aware of this issue. I'm slightly faster than buildd for
> > toolchain
> > upgrades. The issue will automatically disappear once our amd64
> > buildd
> > migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now.
> 
> Is this still an issue?

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Tong Sun]

Thanks Mateusz.

Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just
trying to stir up some noise to get you more traction.

CCing Paul who offered me help last time when I attempted it.

Thanks everyone!

On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl wrote:

> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "fluxbox":
>
>  * Package name : fluxbox
>Version  : 1.3.7-1+nmu1
>Upstream contact : fluxbox maintainers
>  * URL  : https://fluxbox.org
>  * License  : CC-BY-SA-3, Expat
>  * Vcs  : [fill in URL of packaging vcs]
>Section  : x11
>
> The source builds the following binary packages:
>
>   fluxbox - Highly configurable and low resource X11 Window manager
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/fluxbox/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc
>
> Changes since the last upload:
>
>  fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
>  .
>* Non-maintainer upload. (See #927477)
>* Upload to unstable, latest upstream version stuck in experimental for
>  8 years. (Closes: #969440 #987223)
>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
>* Drop depends on deprecated GTK 2. No longer used. (Closes: #967345)
>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS with
>  build-system: fix "make check".
>* Bump dh version to 13.
>* Bump Standards-Version to 4.6.2.
>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch for
>  replace FbRootWindow::depth with maxDepth. (Closes: #1003798)
>
> Regards,
> --
>   Mateusz Łukasik
>
>
>

Bug#1042682: mongo-c-driver: FTBFS with Sphinx 7.1, docutils 0.20: make[3]: *** [src/libbson/doc/CMakeFiles/bson-html.dir/build.make:554: src/libbson/doc/html/api.html] Error 2

[Roberto C . Sánchez]

tags 1042682 + fixed-upstream pending
thanks

I have confirmed that this is fixed on the upstream master branch
(commit ba5ab6de26a874d33b0abc3d2b46961a69380e7a seems like the most
likely, but I did not bisect to confirm).

When the upstream 1.25.0 release is made and then packaged for Debian,
this fix will land in unstable.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#1042927: postgresql-common: leftover conffiles

[Christoph Anton Mitterer]

Package: postgresql-common
Version: 248
Severity: normal


Hi.

Apparently, postgresql-common before bookworm used to contain a
dpkg conffile:
  /etc/sysctl.d/30-postgresql-shm.conf
which has however been dropped without beeing cleaned up porperly
from existing installations (by using dpkg-maintscript-helper).

# dpkg-query --showformat='${Package}\n${Conffiles}\n' --show  |  awk '/^[^ 
]/{pkg=$1}/ obsolete$/{print pkg,$0}' | cut -d ' ' -f 1-3 | column -t
postgresql-common/etc/sysctl.d/30-postgresql-shm.conf


Could you please do that in a future upgrade?

Beware that the version for dpkg-maintscript-helper rm_conffile is *not*
the version of the package where the conffile was dropped (in the past),
but (see common parameters in the manpage).


Thanks,
Chris.

Bug#1042918: reprotest: FTBFS with tox 4

[Vagrant Cascadian]

Control: tags 1042918 pending

On 2023-08-02, Stefano Rivera wrote:
> I thought we'd managed to avoid this, in #1035645, but we just did the
> transition, and I see reprotest is FTBFS:
...
> py311: commands[0] .pybuild/cpython3_3.11_reprotest/build> 
> .tox/py311/bin/python -m coverage r
> un --omit '.tox/*' --parallel -m py.test tests/
> __path__ attribute not found on 'py' while trying to find 'py.test'
> py311: exit 1 (0.09 seconds) /<>> .tox/py311/bin/python -m 
> coverage run --omit '.
> tox/*' --parallel -m py.test tests/ pid=7370
>   py311: FAIL code 1 (2.31=setup[2.22]+cmd[0.09] seconds)
>   evaluation failed :( (2.36 seconds)
> E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
> /<>/.
> pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini 
> --sitepackages --instal
> lpkg 
> /<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-none-any.whl
>  -e py311 
> dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11 
> --test-tox returned exit code 13
>
>
> I'm guessing you want to replace py.test there with pytest.

Great suggestion! Worked for me locally and in salsa-ci.

Pushed to git:

  
https://salsa.debian.org/reproducible-builds/reprotest/-/commit/3d01047ae75ffc3fc30ad11aeec1a0dd9994d849

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1042926: systemd-zram-generator: vendor configuration file placed in wrong directory

[sx0ojl+ehoojgmz1lmbw]

Package: systemd-zram-generator
Version: 1.1.2-2+b2
Severity: normal
Tags: patch

Dear Maintainer,

Can you please explain why you are placing the configuration file into 
/etc/systemd/zram-generator.conf?

`man zram-generator.conf` says in the section "CONFIGURATION DIRECTORIES AND 
PRECEDENCE" that:

"Files in /etc/ are reserved for the local administrator, who may use this 
logic to override the configuration files installed by vendor packages"

The behavior described in the manpage is typical for systemd packages. The rest 
of that manpage section provides further information.

Currently the systemd-zram-generator package places the vendor configuration 
file (vendor means debian in this case) into /etc/systemd/zram-generator.conf 
instead of placing it in /usr/lib/systemd/zram-generator.conf where other 
vendor configuration files go.

The correct way this should work is that the system administrator (me) creates 
/etc/systemd/zram-generator.conf to override the behavior defined in the vendor 
configuration file /usr/lib/systemd/zram-generator.conf.

This also means that `debsums --changed --config` will no longer complain about 
/etc/systemd/zram-generator.conf being modified when the system administrator 
has to change that file.

Just in case, I attach a patch to place the file in the expected location 
described by the manpage and other systemd documentation.







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

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

Versions of packages systemd-zram-generator depends on:
ii  libc6  2.36-9+deb12u1
ii  libgcc-s1  12.2.0-14
ii  systemd252.12-1~deb12u1

systemd-zram-generator recommends no packages.

systemd-zram-generator suggests no packages.

-- Configuration Files:
/etc/systemd/zram-generator.conf changed:
[zram0]
compression-algorithm = zstd


-- no debconf information
---
 src/zram-generator/debian/systemd-zram-generator.install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/zram-generator/debian/systemd-zram-generator.install 
b/src/zram-generator/debian/systemd-zram-generator.install
index 10e26f7..ec61199 100644
--- a/src/zram-generator/debian/systemd-zram-generator.install
+++ b/src/zram-generator/debian/systemd-zram-generator.install
@@ -1,4 +1,4 @@
 debian/20-zram-generator.conf /etc/modules-load.d
-debian/zram-generator.conf /etc/systemd
+debian/zram-generator.conf /usr/lib/systemd
 units/systemd-zram-setup@.service /lib/systemd/system
 zram-generator.conf.example /usr/share/doc/systemd-zram-generator
-- 
2.39.2

Bug#1042753: nouveau bug in linux/6.1.38-2

[Olaf Skibbe]

Dear Maintainers,

Hereby I would like to report an apparent bug in the nouveau driver in
linux/6.1.38-2.

Running a current debian stable on a Dell Latitude E6510 with a
"NVIDIA Corporation GT218M" graphic card, the monitor turns black
after the grub screen. Also switching to a console (Strg-Alt-F2) shows
just a black screen. Access via ssh is possible.

~# uname -r
6.1.0-10-amd64

demesg shows the following error message:

[3.560153] WARNING: CPU: 0 PID: 176 at 
drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490 
[nouveau]
[3.560287] Modules linked in: sd_mod t10_pi sr_mod crc64_rocksoft cdrom 
crc64 crc_t10dif crct10dif_generic nouveau(+) ahci libahci mxm_wmi i2c_algo_bit 
drm_display_helper libata cec rc_core drm_ttm_helper ttm scsi_mod e1000e 
drm_kms_helper ptp firewire_ohci sdhci_pci cqhci ehci_pci sdhci ehci_hcd 
firewire_core i2c_i801 crct10dif_pclmul crct10dif_common drm crc32_pclmul 
crc32c_intel psmouse usbcore mmc_core crc_itu_t pps_core scsi_common i2c_smbus 
lpc_ich usb_common battery video wmi button
[3.560322] CPU: 0 PID: 176 Comm: kworker/u16:5 Not tainted 6.1.0-10-amd64 
#1  Debian 6.1.38-2
[3.560325] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17 
05/12/2017
[3.560327] Workqueue: nvkm-disp nv50_disp_super [nouveau]
[3.560433] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560538] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 00 48 
83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b c1 e8 03 
41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26
[3.560541] RSP: 0018:9899c048bd60 EFLAGS: 00010246
[3.560542] RAX: 00041eb0 RBX: 88e0209d2600 RCX: 00041eb0
[3.560544] RDX: c079f760 RSI:  RDI: 9899c048bcf0
[3.560545] RBP: 0001 R08: 9899c048bc64 R09: 5b76
[3.560546] R10: 000d R11: 9899c048bde0 R12: ffea
[3.560548] R13: 88e00b39e480 R14: 00044d45 R15: 
[3.560549] FS:  () GS:88e123c0() 
knlGS:
[3.560551] CS:  0010 DS:  ES:  CR0: 80050033
[3.560552] CR2: 7f57f4e90451 CR3: 00018141 CR4: 06f0
[3.560554] Call Trace:
[3.560558]  
[3.560560]  ? __warn+0x7d/0xc0
[3.560566]  ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560671]  ? report_bug+0xe6/0x170
[3.560675]  ? handle_bug+0x41/0x70
[3.560679]  ? exc_invalid_op+0x13/0x60
[3.560681]  ? asm_exc_invalid_op+0x16/0x20
[3.560685]  ? init_reset_begun+0x20/0x20 [nouveau]
[3.560769]  ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560888]  nv50_disp_super_2_2+0x70/0x430 [nouveau]
[3.560997]  nv50_disp_super+0x113/0x210 [nouveau]
[3.561103]  process_one_work+0x1c7/0x380
[3.561109]  worker_thread+0x4d/0x380
[3.561113]  ? rescuer_thread+0x3a0/0x3a0
[3.561116]  kthread+0xe9/0x110
[3.561120]  ? kthread_complete_and_exit+0x20/0x20
[3.561122]  ret_from_fork+0x22/0x30
[3.561130]  

Further information:

$ lspci -v -s $(lspci | grep -i vga | awk '{ print $1 }')
01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M] (rev 
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at e200 (32-bit, non-prefetchable) [size=16M]
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at e000 (64-bit, prefetchable) [size=32M]
I/O ports at 7000 [size=128]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities: 
Kernel driver in use: nouveau
Kernel modules: nouveau

I reported this bug to debian already, see
https://bugs.debian.org/1042753 for context.

With support (thanks Diederik!) I managed to figure out that the cause
was a regression between upstream kernel version 6.1.27 and 6.1.38.

I build a new 6.1.38 kernel with these commits reverted:

62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL
fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode
90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device
5a144bad3e75 nouveau: fix client work fence deletion race

With that kernel the graphic works again.

Please inform me if further tests are required.

Cheers,
Olaf

Bug#1042925: RM: funny-manpages -- RoQA; unmaintained, RC-buggy, not in stable

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: funny-manpa...@packages.debian.org
Affects: src:funny-manpages

Please remove funny-manpages from Debian.

It was removed from Testing many years ago because of a particularly
bad RC bug: https://bugs.debian.org/737395 The final comment on that
bug from 5 years ago includes the package maintainer's opinion that it
is not possible to fix the RC bug. There have been no package uploads
since that date.

Thanks,
Jeremy Bicha

Bug#1042924: RM: opennebula-context -- RoQA; unmaintained, RC-buggy, not in stable

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: opennebula-cont...@packages.debian.org
Affects: src:opennebula-context

Please remove opennebula-context from Debian.

opennebula-context has not been available in Testing for 5 years
because of a failure to fix a trivial RC bug:
https://bugs.debian.org/899908

It appears related to opennebula which was removed from Debian 5 years ago.
https://bugs.debian.org/903743

Thanks,
Jeremy Bicha

Bug#1042923: ITP: ampy -- Utility to interact with a CircuitPython or MicroPython board over a serial connection

[Louis-Philippe Véronneau]

Package: wnpp
Severity: wishlist
Owner: Louis-Philippe Véronneau 


Package name: ampy
Version : 1.1.0
URL : https://github.com/scientifichackers/ampy
License : Expat
Programming Lang: Python
Description : Utility to interact with a CircuitPython or MicroPython board 
over a serial connection.

Ampy is meant to be a simple command line tool to manipulate files and run code 
on a CircuitPython or MicroPython board over its serial connection. With ampy 
you can send files from your computer to the board's file system, download 
files from a board to your computer, and even send a Python script to a board 
to be executed.

I'm planning to maintain this package in the Python Team.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042922: scid: Crash at startup: can't set "tooltip::labelOpts": parent namespace doesn't exist

[Arnaud Meyer]

Package: scid
Version: 1:4.7.4+dfsg1-2
Severity: important
Tags: patch
X-Debbugs-Cc: arnaudme...@gmx.com

Dear Maintainer,

Upon fresh installation, Scid does not run and displays the following
message when run in a terminal:

$ scid
can't set "tooltip::labelOpts": parent namespace doesn't exist
while executing
"set tooltip::labelOpts [list -highlightthickness 0 -relief solid -bd 1  
-background lightyellow -fg black -font $font]"
(in namespace eval "::utils::tooltip" script line 10)
invoked from within
"namespace eval ::utils::tooltip {
  global ::utils::tooltip::font

  if {![info exists font]} {
set font TkDefaultFont
  }

  # Undocumented toolt..."
(file "/usr/share/scid/tcl/utils/tooltip.tcl" line 11)
invoked from within
"source -encoding utf-8 [file nativename [file join $::scidTclDir "$f"]]"
("foreach" body line 2)
invoked from within
"foreach f $tcl_files {
source -encoding utf-8 [file nativename [file join $::scidTclDir "$f"]]
}"
(file "/usr/games/scid" line 674)


The problem appears to come from a very small mistake in line 20 of file
/usr/share/scid/utils:

--- original/tooltip.tcl2023-08-02 22:51:16.416479228 +0200
+++ patch/tooltip.tcl   2023-08-02 22:51:27.480313699 +0200
@@ -17,7 +17,7 @@
 
   # Undocumented tooltip variable that allows users to extend / override
   # label creation options.
-  set tooltip::labelOpts [list -highlightthickness 0 -relief solid -bd 1 \
+  set ::tooltip::labelOpts [list -highlightthickness 0 -relief solid -bd 1 \
   -background lightyellow -fg black -font $font]
 
   proc Set {button msg} {


It also appears this bug was fixed in the new upstream versions.

Thanks,
Arnaud Meyer.


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

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

Versions of packages scid depends on:
ii  libc6   2.37-6
ii  libstdc++6  13.1.0-9
ii  libtcl8.6   8.6.13+dfsg-2
ii  python3 3.11.4-5
ii  scid-data   1:4.7.4+dfsg1-2
ii  tcl 8.6.13
ii  tk  8.6.13
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages scid recommends:
ii  libtk-img  1:1.4.14+dfsg-2
ii  tcl-snack [libsnack2]  2.2.10.20090624+dfsg-1
ii  tcllib 1.21+dfsg-1
ii  tdom   0.9.3-1
ii  texlive-games  2022.20230122-4

Versions of packages scid suggests:
pn  crafty  
pn  glaurung
pn  phalanx 
pn  scid-spell-data | scid-rating-data  
ii  stockfish   15.1-4
pn  toga2   

-- no debconf information
--- original/tooltip.tcl2023-08-02 22:51:16.416479228 +0200
+++ patch/tooltip.tcl   2023-08-02 22:51:27.480313699 +0200
@@ -17,7 +17,7 @@
 
   # Undocumented tooltip variable that allows users to extend / override
   # label creation options.
-  set tooltip::labelOpts [list -highlightthickness 0 -relief solid -bd 1 \
+  set ::tooltip::labelOpts [list -highlightthickness 0 -relief solid -bd 1 \
   -background lightyellow -fg black -font $font]
 
   proc Set {button msg} {

Bug#1042885: / Bug# 1042886 Acknowledgement (initramfs-tools: breaks system boot after bios: initramfs-tools-core, initramfs-tools, zstd, libzstd1)

[CHRISTIAN PETER KISS]

‎Bug#1042885 / Bug# 1042886 

Hello,

as of Bullseye -rt-23 kernel part : 

it seems 
CONFIG_AS_VERSION=23502 
was absent in the kernel config.


this and or 5.10 dev 

fixed the rt-23 bullseye kernel boot

but not the bookworm issue with initrams.


#keypoint verify if this trigger can be the cause of dysfunct mkinitramfs 
initramfs-tools .
i suspect dysfunct zstd 1.54 andor 0.142 initramfstools are  the issue  


n o t  1.48 +0.140 bullseye 


greetings








  Original Message  
From: CHRISTIAN PETER KISS 
Sent: Wednesday, 2 August 2023 14:49
To: car...@deian.org
Subject: Salvatore this Bug#1042885 isforyou : Acknowledgement 
(initramfs-tools: breaks system boot after bios: initramfs-tools-core, 
initramfs-tools, zstd, libzstd1)


  Original Message  
From: Debian Bug Tracking System 
Sent: Wednesday, 2 August 2023 13:54
To: Christian Kiss
Subject: Bug#1042885: Acknowledgement (initramfs-tools: breaks system boot 
after bios: initramfs-tools-core, initramfs-tools, zstd, libzstd1)

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1042885: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042885.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
christianpeterk...@yahoo.com
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
Debian kernel team 

If you wish to submit further information on this problem, please
send it to 1042...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1042885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042885
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1041230: onetbb 2021.9.0-1 FTBFS on multiple release architectures

[Petter Reinholdtsen]

[M. Zhou]
> I'm aware of this issue. I'm slightly faster than buildd for toolchain
> upgrades. The issue will automatically disappear once our amd64 buildd
> migrates to gcc-13. The gcc-12 will lead to the FTBFS you see now.

Is this still an issue?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1042671:

[Nicholas D Steeves]

lu...@mailbox.org writes:

> Hi Nicholas,
>  
> thanks for your quick response and your proposal. I will give it a try in the 
> next days and report back as soon as possible.

You're welcome.  P.S.  Slight correction in the last email: I meant to
write that "Borg 1.2.4" was uploaded during the hard freeze, and not
"Vorta 1.2.4".  'hope that was obvious!


signature.asc
Description: PGP signature

Bug#1042921: rust-glib: feature "log" has disappeared

[Jonas Smedegaard]

Source: rust-glib
Version: 0.17.10-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

rust-glib was upgraded without coordination with reverse dependencies.
Don't do that.  It puts a stress on maintenance of reverse dependencies!

The upgrade patched away feature "log". Don't do that.  Yeah, I can see
that it requires a new package - then package that, don't break reverse
dependencies in Debian!

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTKvpAACgkQLHwxRsGg
ASF5whAAho9hTN1h+vVnX0r9dcYsWAdMSKGGEJU8Gm95dd5OvgAayquIs9KkM+SH
TVpFTNy83VtyJ+pxBNjdmk76bOUJdrgECjD2A1ytgsHKUreoZjXeuB4ukswVqRFn
Ay4WKLjSY5rEh4acrUX2kVbDo3hUn2qz8NrImw0H7zzgOJik4Hpp9nlAX/XPvNDE
9wci98XsmEh/eaHr17HSqF/BZDyXxTgHT6s3vP1WPLKBpBgGjIsSHXLVfiRi1Woj
mng+scm2KlKFtSI5KZ/q1Bj8604yLXFpRvN1hzlnroY9/HTeGJdXJtyETOKV+ESU
/fVMFIK25DyqHA8jfipvyrA7DiSJxc7FTWajPi2bdj+RxTajRM4pSahONrNtI3xx
K88fnDHJEVCgwp4zlRnn7JJsK7dFW1+SEQBW0tH+tXHUquVM+mSu4VIgQTdjGv8j
gNV5dh8j/NtIP2xRrUOYK40OJ+RdgPW5sf2ZtqslN5DH2ZtZTIpcUAVO4ehOF3Ky
AV2VMmKINPpyhyCh30/PB6VD2ImWMz44hrvS20g6yTrq2I/bdIteiqbVR7LjvbFZ
ugFLXiEHl0pWkm33vSEZXnjnZR2g1X/PZVFv9mcoUFE7CeNQEMv4IxsMs5wU8YdE
IGfjrmvKLTI3s3pDsIsNNBvbLvUSXxI6nNcYpfMln8KNu7RZqRM=
=C2MK
-END PGP SIGNATURE-

Bug#1042920: transition: libxlsxwriter

[Boyuan Yang]

Package: release.debian.org
Control: affects -1 + src:libxlsxwriter
X-Debbugs-Cc: libxlsxwri...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: by...@debian.org
Severity: normal

I am looking into the transition from libxlsxwriter4 to libxlsxwriter5 due to
an upstream SONAME bump in the new release.

The build of all reverse-dependencies all passed in my
testing.

* deepin-log-viewer (OK)
* readstat (OK)

Ben file:

(Please reuse 
https://release.debian.org/transitions/html/auto-libxlsxwriter.html )

title = "libxlsxwriter";
is_affected = .depends ~ "libxlsxwriter4" | .depends ~ "libxlsxwriter5";
is_good = .depends ~ "libxlsxwriter5";
is_bad = .depends ~ "libxlsxwriter4";


Thanks,
Boyuan Yang


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

Bug#1042914: [Pkg-utopia-maintainers] Bug#1042914: upower: Release 1.90 to Unstable

[Michael Biebl]

Am 02.08.23 um 19:43 schrieb Jeremy Bícha:

Source: upower
Version: 1.90.2-3
Severity: wishlist

I uploaded the latest libgudev to Unstable but it fails to migrate
because of upower autopkgtest failures.


Thanks for the heads-up.


What do you think about uploading the new upower series to Unstable?


Sure, will do.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042919: r-cran-leidenbase: autopkgtest failure with r-cran-igraph 1.5.0.1-1

[Adrian Bunk]

Source: r-cran-leidenbase
Version: 0.1.18-1
Severity: serious
Control: block 1038700 by -1

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-leidenbase/36306523/log.gz

...
 46s ══ Failed tests 

 46s ── Error ('test-leidenbase.R:43:3'): CPMVertexPartition membership and 
quality ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"CPMVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.5)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:43:2
 46s ── Error ('test-leidenbase.R:61:3'): ModularityVertexPartition membership 
and quality ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"ModularityVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.5)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:61:2
 46s ── Error ('test-leidenbase.R:79:3'): RBERVertexPartition membership and 
quality ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBERVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.5)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:79:2
 46s ── Error ('test-leidenbase.R:97:3'): SignificanceVertexPartition 
membership and quality ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"SignificanceVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.5)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:97:2
 46s ── Error ('test-leidenbase.R:115:3'): SurpriseVertexPartition membership 
and quality ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"SurpriseVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.5)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:115:2
 46s ── Error ('test-leidenbase.R:137:3'): resolution_parameter parameter 
───
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBConfigurationVertexPartition", 
 46s resolution_parameter = 1, seed = 123456)`: REAL() can only be applied 
to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:137:2
 46s ── Error ('test-leidenbase.R:155:3'): num_iter parameter 
───
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBConfigurationVertexPartition", 
 46s num_iter = 5, seed = 123456, resolution_parameter = 0.5)`: REAL() can 
only be applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:155:2
 46s ── Error ('test-leidenbase.R:178:3'): initial_membership parameter 
─
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBConfigurationVertexPartition", 
 46s initial_membership = inimem, seed = 123456, resolution_parameter = 
0.5)`: REAL() can only be applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:178:2
 46s ── Error ('test-leidenbase.R:201:3'): edge_weights parameter 
───
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBConfigurationVertexPartition", 
 46s edge_weights = edgwgt, seed = 123456, resolution_parameter = 0.5)`: 
REAL() can only be applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:201:2
 46s ── Error ('test-leidenbase.R:224:3'): node_sizes parameter 
─
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"RBConfigurationVertexPartition", 
 46s node_sizes = nodsiz, seed = 123456, resolution_parameter = 0.5)`: 
REAL() can only be applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:224:2
 46s ── Error ('test-leidenbase.R:245:3'): modularity and significance return 
values ──
 46s Error in `leidenbase::leiden_find_partition(igraph, partition_type = 
"CPMVertexPartition", 
 46s seed = 123456, resolution_parameter = 0.1)`: REAL() can only be 
applied to a 'numeric', not a 'NULL'
 46s Backtrace:
 46s ▆
 46s  1. └─leidenbase::leiden_find_partition(...) at test-leidenbase.R:245:2
 46s 
 46s [ FAIL 11 | WARN 0 | SKIP 0 | PASS 6 ]
 46s Error: Test failures
 46s Execution halted
 46s autopkgtest [18:09:34]: test 

Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc

[Nicholas D Steeves]

Hello,

Would you like to fix this RC bug and adopt the package?

  https://bugs.debian.org/1042911

and the orphan bug is here: #1016558

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1041378: (no subject)

[Nicola Ferralis]

The most relevant change is in the file:

libavutil/hwcontext_qsv.h

where in ffmpeg 5.1.3 it used to read (line 22):

#include 

while in ffmpeg 6.0:

#include 

That said, simply adding the folder mfx/ in ffmpeg 6.0 leads to a 
compilation error for ffmpeg:


In file included from src/libavfilter/qsvvpp.h:32,
 from src/libavfilter/qsvvpp.c:30:
src/libavutil/hwcontext_qsv.h:22:10: fatal error: mfx/mfxvideo.h: No such file 
or directory
   22 | #include 
  |  ^~~~
compilation terminated.

Bug#1014255: Long lines should also be ignored from non-code text files

[Russ Allbery]

"Dr. Bas Wijnen"  writes:

> Axel writes that README.md and LICENSE are likely valid cases. I
> disagree.  While I (and I expect many developers in Debian) are used to
> using short lines in text files, this is not that common for other
> people. Many will use the automatic word-wrap feature of text editors
> and write a whole paragraph on a single line.

Or, if not a whole paragraph, there are pretty strong arguments for
following https://xkcd.com/1285/ whenever writing in any markup language,
including Markdown, which can lead to long lines for complex sentences.
That's the standard for our projects at my current employer.

-- 
Russ Allbery (r...@debian.org)  

Bug#1039536: Info received (Bug#1039536 closed by Julien Cristau (Re: Bug#1039536: mirror submission for mirror.nasutek.com))

[Michael J. Manley]

Nevermind, both are fixed now, should now have Maintainer and Upstream-mirror 
in trace file.

Should also be updating like it should.

Bug#1042857: coinor-libcbc3.1: Fails to install, conflicts with coinor-libcbc3:amd64

[Pierre Gruet]

On Tue, 1 Aug 2023 23:21:52 +0200 Samuel Thibault  
wrote:

> Package: coinor-libcbc3.1
> Version: 2.10.10+really2.10.10+ds1-2
> Severity: serious
> Justification: Fails to install
>
> Hello,
>
> While upgrading testing today:
>
> Preparing to unpack 
.../coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb ...

> Unpacking coinor-libcbc3.1:amd64 (2.10.10+really2.10.10+ds1-2) ...
> dpkg: error processing archive 
/var/cache/apt/archives/coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb 
(--unpack):
> trying to overwrite '/usr/lib/x86_64-linux-gnu/libCbc.so.3.10.10', 
which is also in package coinor-libcbc3:amd64 2.10.10+ds1-1

> Errors were encountered while processing:
> 
/var/cache/apt/archives/coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb

> needrestart is being skipped since dpkg has failed
>
> I guess there should be some breaks+replace or some renaming?
>
> Samuel
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), 
(500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'buildd-experimental'), (1, 'experimental')

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, arm64
>
> Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages coinor-libcbc3.1 depends on:
> ii coinor-libcgl1 0.60.3+repack1-4
> ii coinor-libclp1 1.17.6-3
> ii coinor-libcoinutils3v5 2.11.4+repack1-2
> ii coinor-libosi1v5 0.108.6+repack1-2
> ii libc6 2.37-6
> ii libgcc-s1 13.1.0-6
> ii libstdc++6 13.1.0-6
>
> coinor-libcbc3.1 recommends no packages.
>
> coinor-libcbc3.1 suggests no packages.
>
>

Bug#1014255: Long lines should also be ignored from non-code text files

[Louis-Philippe Véronneau]

On 2023-08-02 15 h 01, Dr. Bas Wijnen wrote:

Hi,

Axel writes that README.md and LICENSE are likely valid cases. I disagree.
While I (and I expect many developers in Debian) are used to using short lines
in text files, this is not that common for other people. Many will use the
automatic word-wrap feature of text editors and write a whole paragraph on a
single line.

I don't think I should ask upstream to reformat their non-code text files; it's
not a good use of their time, and also they would likely not even do it.

Instead, I hope lintian can avoid emitting this tag for non-code text files (in
particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an
exception: that is code and it shouldn't contain long lines.

I could add overrides, but I don't think this would be an appropriate case for
that. But please let me know if it is.

Thanks,
Bas



Note that the 'very-long-line-length-in-source-file' was marked as 
'experimental' in this commit [1] exactly for that kind of reason.


The default lintian mode doesn't use the 'experimental' tags and I would 
advise you not to include them if this tag is currently bothering you.


[1]: 
https://salsa.debian.org/lintian/lintian/-/commit/899bd1b683c479e166ebd465ff0ad101fbd04ee2


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042918: reprotest: FTBFS with tox 4

[Stefano Rivera]

Source: reprotest
Version: 0.7.25
Severity: serious
Justification: ftbfs

I thought we'd managed to avoid this, in #1035645, but we just did the
transition, and I see reprotest is FTBFS:

I: pybuild base:275: cd 
/<>/.pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini --sitepackages --installpkg 
/<>/.pybuild/cpython3_3.11_reprote
st/reprotest-0.7.25-py3-none-any.whl -e py311 
py311: install_deps .pybuild/cpython3_3.11_reprotest/build> python -I -m pip 
install coverage 
diffoscope pytest
py311: install_package_deps .pybuild/cpython3_3.11_reprotest/build> python -I 
-m pip install d
istro rstr
py311: install_package .pybuild/cpython3_3.11_reprotest/build> python -I -m pip 
install --forc
e-reinstall --no-deps 
/<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-n
one-any.whl
py311: commands[0] .pybuild/cpython3_3.11_reprotest/build> 
.tox/py311/bin/python -m coverage r
un --omit '.tox/*' --parallel -m py.test tests/
__path__ attribute not found on 'py' while trying to find 'py.test'
py311: exit 1 (0.09 seconds) /<>> .tox/py311/bin/python -m 
coverage run --omit '.
tox/*' --parallel -m py.test tests/ pid=7370
  py311: FAIL code 1 (2.31=setup[2.22]+cmd[0.09] seconds)
  evaluation failed :( (2.36 seconds)
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
/<>/.
pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini 
--sitepackages --instal
lpkg 
/<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-none-any.whl
 -e py311 
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11 
--test-tox returned exit code 13


I'm guessing you want to replace py.test there with pytest.

Stefano

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

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

Bug#1042917: rdflib-sqlalchemy: FTBFS with tox 4

[Stefano Rivera]

Source: rdflib-sqlalchemy
Version: 0.5.4-1
Severity: serious
Tags: upstream
Justification: ftbfs

With tox 4, rdflib-sqlalchemy FTBFS with:
   dh_auto_test -O--buildsystem=pybuild
E: pybuild pybuild:388: test: plugin distutils failed with: wheel is required 
to build wheels for distutils/setuptools packages. Build-Depend on 
python3-wheel.
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11 
returned exit code 13

I committed the fix for that to git, but the next issue is:

I: pybuild base:275: cd 
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build; tox -c 
/<>/tox.ini --sitepackages --installpkg 
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
 -e py311 
py311: install_deps .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> python -I 
-m pip install mysqlclient psycopg2 'pytest-cov>=2.5.1' 'pytest>=3.4.0'
py311: install_package_deps .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> 
python -I -m pip install 'SQLAlchemy<2.0.0,>=1.1.4' 'alembic>=0.8.8' 
'rdflib>=4.0' 'six>=1.10.0'
py311: install_package .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> python 
-I -m pip install --force-reinstall --no-deps 
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
py311: commands[0] .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> 
.tox/py311/bin/python setup.py clean --all
running clean
removing '/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build' (and 
everything under it)
removing 'build/bdist.linux-x86_64' (and everything under it)
'build/scripts-3.11' does not exist -- can't clean it
removing 'build'
py311: commands[1] .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> pytest 
--cov=rdflib_sqlalchemy
py311: failed with pytest is not allowed, use allowlist_externals to allow it
  py311: FAIL code 1 (3.06 seconds)
  evaluation failed :( (3.12 seconds)
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build; tox -c 
/<>/tox.ini --sitepackages --installpkg 
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
 -e py311 
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11 
returned exit code 13

The fix here should be as simple as replacing "pytest" with "{envpython} -m 
pytest" in tox.ini

Stefano

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

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

Bug#1042916: Unsatisfiable build-dependency on gtk4 0.16

[Matthias Geiger]

Package: helvum
Severity: grave
Justification: renders package installable
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas.

Yesterday I uploaded the new gtk-rs release which makes helvum uninstallable
as it depends on the no longer present 0.16 versions of the gtk-rs
libraries. The fix is simple, just dropping 2001_gtk.patch should
suffice. Please look into this as it blocks testing migration for gtk-rs
otherwise. 

Thanks,

Matthias

- -- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.2-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
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

Versions of packages helvum depends on:
ii  libc62.36-9
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.76.3-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-4-1   4.10.3+ds-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpipewire-0.3-00.3.65-3

helvum recommends no packages.

helvum suggests no packages.

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmTKqk0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1yMsP9jRViLwDlXoyVxq5wSvWpVB1honZ
TqyTaPVWhjYsEZsWftKjeGWEv1Mf5cHy5A6d9rhXlIj7QIcGRKv9ss3SevQLplL8
7LwPBdQ/TIsPvNBhaHt8tOnTJlqWXT2uyVwHidjcE+UcIYN/QGW51UY2dpPPq4WS
0Qp3UTL8EvyYF0omjQ8/Gdaj7ufNKdcLsCPOMijRkGq2zcU9mIbY4a3lD/xiY4X4
NMD1GtqbFcZF1ND/FrzTQqD0Q8je0NBJzo9TJR2M1mF6ozkZjuM2ZgoVZEGwUWhl
o9kp5+69JxwAhOubPMi29TDpILHiKJfWKDph2S7I1APcjyvLBlCifDhpXVuEu6QA
rH10KWChI6j1nQ6PlcXjfD1fAnfqPLckACm2lkyLejDT3LzTjjQM1dmETepRN7h+
5Ibjxwj5+yIf0gsckru5Lj4VkMi9HRCh86TEvcG1BaS9oz0oir0CcNdw8Ytrnqrn
6+n8p257OBVCfwvLh4dQm0cJ7GyjIF6ojrM7ju0a54jASpA052PCxMM29wgC6riW
jj6weVhryZhdRlk9CJVE0GGMWhy7NjggUL7dQvoF18hevms5om0HHdMIU2uy49zg
dthnaYMLOESW9UlHV564KM/Tz1A7t0vDBdDEvHRjDBVsalu7j09CW/P1urYz3lO9
BU6yB9Q8g+5cMek=
=1f89
-END PGP SIGNATURE-

Bug#1041745: smartd[…]: Device: /dev/nvme0, number of Error Log entries increased from … to …

[Daniel Swarbrick]

This sounds quite similar to this: 
https://github.com/linux-nvme/libnvme/issues/550


Even prior to that bug, I noticed that the smart error log counter would 
increment by one with every reboot. This was not too concerning, but 
when nvme-cli 2.x started to result in (albeit innocent) errors being 
logged each time a "nvme list" command was executed, it became an 
annoyance. As I understand it, it was due to the SSD being fairly old, 
and the firmware only supporting a fairly outdated version of the NVMe 
spec (< 1.2)


At least the _kernel_ should have fixed this, with commit 
https://github.com/torvalds/linux/commit/d7ac8dca938cd60cf7bd9a89a229a173c6bcba87


A fix for nvme-cli (via libnvme) is still being worked on, AFAIK.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039365: Fedora has systemd-unit files for sendmail

[Marco]

Am 02.08.2023 um 18:26:01 Uhr schrieb Andreas Beckmann:

> Maybe we could introduce a sendmail-systemd package to allow running 
> sendmail "the modern way" without breaking "the classic way".
> We probably need to split the sendmail-bin and sendmail-base packages
> to decouple the sysv and sendmailconfig bits from the parts that are
> shared with sendmail-systemd.
> 
> Patches welcome!

Writing the systemd unit is rather easy if not using the Sys V init
script.
I could do that, but other people should it test too.

I could also try to find a way that the systemd unit just calls the
sysvinit script if you are interested.

Bug#1036968: Ubuntu 22.04 includes it

[Hans-Christoph Steiner]

The sound works with Ubuntu 22.04.  This laptop family (Dell XPS) is listed as 
supported by Ubuntu on their site.  It is the same hardware as the Dell XPS 13 Plus:

https://ubuntu.com/certified/202112-29802

The Ubuntu/jammy 22.04 kernel includes this same list of modules as listed in 
kernel.org issue:


https://packages.ubuntu.com/jammy/amd64/linux-buildinfo-5.15.0-78-generic/download

$ grep -i CS35L41 
linux-buildinfo-5.15.0-78-generic_5.15.0-78.85_amd64/usr/lib/linux/5.15.0-78-generic/config 


CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

This machine is setup with Secure Boot, and not setup to sign its own kernels. 
So testing it in Debian would not be easy for me until its shipped in a signed 
kernel.

Bug#1042842: [Pkg-xen-devel] Bug#1042842: network interface names wrong in domU (>10 interfaces)

[zithro]

On 02 Aug 2023 18:09, Valentin Kleibel wrote:

#xen-devel is the IRC Xen channel. I just pinged them, I'll wait.
Depending on their answers, I'll post on the xen-devel mailing list.


thanks for the clarification, looking forward to an answer.


I posted on xen-devel, you can follow from :
https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg00244.html
(Unfortunately, the formatting is weird via html, split the IRC part on 
"- ").


Note that, at first sight, I was told this seems "not-a-Xen" bug (read 
the IRC excerpts).


Our current workaround is to edit the interface names in the domUs 
config to match the wrong sorting. And be extra careful that the 
domUs MACs match the ones we expect on that network.


Via udev (MAC matching) or /etc/network/interfaces ?
I ask because it may help others, while this gets resolved.


We just edited /etc/network/interfaces, as it only affects a few of our 
domUs.
i think udev rules matching the MAC would be a better solution. I just 
didn't take the time to write them and went for the quick and dirty 
solution.


Till it works, "whatever the bottle, till we have the poison" ;)

This link may be useful: https://wiki.debian.org/NetworkInterfaceNames

Bug#1036930: ITP: robtk -- Robin's LV2 UI ToolKit

[snd]

Some more infos on this package:

Robtk facilitates creating LV2 plugins UIs with emphasis to allow 
porting existing GTK+ plugin UIs


Robtk is / will be a build dependency for packages like avldrums.lv2, 
qmidiarp, setbfree and x42-plugins.


Similar to this package is dpf-source. No binaries are build with this 
package.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014255: Long lines should also be ignored from non-code text files

[Dr. Bas Wijnen]

Hi,

Axel writes that README.md and LICENSE are likely valid cases. I disagree.
While I (and I expect many developers in Debian) are used to using short lines
in text files, this is not that common for other people. Many will use the
automatic word-wrap feature of text editors and write a whole paragraph on a
single line.

I don't think I should ask upstream to reformat their non-code text files; it's
not a good use of their time, and also they would likely not even do it.

Instead, I hope lintian can avoid emitting this tag for non-code text files (in
particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an
exception: that is code and it shouldn't contain long lines.

I could add overrides, but I don't think this would be an appropriate case for
that. But please let me know if it is.

Thanks,
Bas

Bug#1042889: vm: autopkgtest fails against Emacs 29.1

[Sean Whitton]

Hello,

On Wed 02 Aug 2023 at 02:49pm +01, Ian Jackson wrote:

> Sean Whitton writes ("Bug#1042889: vm: autopkgtest fails against Emacs 29.1"):
>> vm's autopkgtest fails with Emacs 29.1, which latter is now in sid.
>
> Hi, Sean, as you see we're looking into this.
> I have some questions for you as an Emacs expert:
>
> Is byte-compilation known to be sometimes broken?  Is there a
> recommended approach to problems caused by byte-compilation ?

The bytecompiler tends to get fussier with each Emacs release.
Usually it's worth fixing the problems with the code it identifies.
It's unlikely to be actually broken in a stable release of Emacs.

> We recently did an update to vm in Debian stable, to work around a
> critical problem with Emacs 28 (#1039105).  The autopkgtest which is
> now failing is new - I introduced it to detect future bugs, which it
> seems to have done.
>
> The previous bug was related to byte-compilation and we "fixed" it by
> turning off byte-compilation for at least some of vm's files (in what
> I feel was rather an ad-hoc way, albeit an effective one).
>
> Or to put it another way, is it possible that this is a bug in emacs
> 29.1 and if so what is the best workaround ?

Before disabling anything, it seems worth looking at the code and seeing
if you can figure out why there's a void-variable error being emitted at
all.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1037567: abseil: ftbfs with GCC-13

[Benjamin Barenblat]

I’ve been procrastinating on starting the transition because of some
lingering MIPS issues. I think they’ve all been sorted out, and I just
uploaded my latest work to experimental. If that passes the buildds,
I’ll request a transition slot and do the transition as quickly as
possible.

If waiting on the transition is going to unacceptably delay the riscv64
bootstrap, please let me know. I think I know which patches I would have
to backport to 20220623 to get it to build with GCC 13, so I may be able
to fix this in unstable before the transition completes.

Bug#1042915: please update to 0.24

[Joey Hess]

Package: libghc-aws-dev
Version: 0.22.1-1+b4
Severity: wishlist

Version 0.24 enables new features in git-annex, including anonymous
import from a public bucket.

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN
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 libghc-aws-dev depends on:
ii  ghc [libghc-transformers-dev-0.5.6.2-fc6f3]   9.0.2-4
ii  libc6 2.37-6
ii  libghc-aeson-dev [libghc-aeson-dev-2.0.3.0-6cd28] 2.0.3.0-1+b5
ii  libghc-attoparsec-dev [libghc-attoparsec-dev-0.14.4-9b90  0.14.4-2+b1
1]
pn  libghc-base-dev-4.15.1.0-6a406
ii  libghc-base16-bytestring-dev [libghc-base16-bytestring-d  1.0.2.0-1+b3
ev-1.0.2.0-ab752]
ii  libghc-base64-bytestring-dev [libghc-base64-bytestring-d  1.2.1.0-1+b1
ev-1.2.1.0-ba29f]
ii  libghc-blaze-builder-dev [libghc-blaze-builder-dev-0.4.2  0.4.2.2-1+b3
.2-91bf6]
ii  libghc-byteable-dev [libghc-byteable-dev-0.1.1-8f6f5] 0.1.1-11+b2
pn  libghc-bytestring-dev-0.10.12.1-ced9a 
ii  libghc-case-insensitive-dev [libghc-case-insensitive-dev  1.2.1.0-3+b2
-1.2.1.0-ea097]
ii  libghc-cereal-dev [libghc-cereal-dev-0.5.8.3-8b478]   0.5.8.3-1
ii  libghc-conduit-dev [libghc-conduit-dev-1.3.4.3-84779] 1.3.4.3-1
ii  libghc-conduit-extra-dev [libghc-conduit-extra-dev-1.3.6  1.3.6-1+b4
-c95cb]
pn  libghc-containers-dev-0.6.4.1-31c3b   
ii  libghc-cryptonite-dev [libghc-cryptonite-dev-0.29-99264]  0.29-1+b2
ii  libghc-data-default-dev [libghc-data-default-dev-0.7.1.1  0.7.1.1-6+b3
-6d3b3]
pn  libghc-directory-dev-1.3.6.2-311c9
pn  libghc-exceptions-dev-0.10.4-c14ff
pn  libghc-filepath-dev-1.4.2.1-4459f 
ii  libghc-http-client-tls-dev [libghc-http-client-tls-dev-0  0.3.6.1-1+b3
.3.6.1-2a1f1]
ii  libghc-http-conduit-dev [libghc-http-conduit-dev-2.3.8-f  2.3.8-1+b4
35fc]
ii  libghc-http-types-dev [libghc-http-types-dev-0.12.3-4a0a  0.12.3-5+b1
b]
ii  libghc-lifted-base-dev [libghc-lifted-base-dev-0.2.3.12-  0.2.3.12-4+b3
e0695]
ii  libghc-memory-dev [libghc-memory-dev-0.16.0-89fb0]0.16.0-1+b3
ii  libghc-monad-control-dev [libghc-monad-control-dev-1.0.3  1.0.3.1-1+b3
.1-20361]
pn  libghc-mtl-dev-2.2.2-e3bae
ii  libghc-network-bsd-dev [libghc-network-bsd-dev-2.8.1.0-7  2.8.1.0-3+b2
26d3]
ii  libghc-network-dev [libghc-network-dev-3.1.2.7-bb8a0] 3.1.2.7-1+b3
ii  libghc-old-locale-dev [libghc-old-locale-dev-1.0.0.7-60e  1.0.0.7-10+b3
52]
ii  libghc-resourcet-dev [libghc-resourcet-dev-1.2.6-16c70]   1.2.6-1+b1
ii  libghc-safe-dev [libghc-safe-dev-0.3.19-b4ca4]0.3.19-2+b2
ii  libghc-scientific-dev [libghc-scientific-dev-0.3.7.0-de1  0.3.7.0-1+b2
a8]
ii  libghc-tagged-dev [libghc-tagged-dev-0.8.6.1-38317]   0.8.6.1-1+b3
pn  libghc-text-dev-1.2.5.0-8553e 
pn  libghc-time-dev-1.9.3-bda76   
ii  libghc-unordered-containers-dev [libghc-unordered-contai  0.2.17.0-2+b2
ners-dev-0.2.17.0-1d16d]
ii  libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.2-a50  1.0.2-1+b2
cd]
ii  libghc-vector-dev [libghc-vector-dev-0.12.3.1-f377c]  0.12.3.1-1+b2
ii  libghc-xml-conduit-dev [libghc-xml-conduit-dev-1.9.1.1-e  1.9.1.1-2+b4
d422]
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  zlib1g1:1.2.13.dfsg-1

libghc-aws-dev recommends no packages.

libghc-aws-dev suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1042914: upower: Release 1.90 to Unstable

[Jeremy Bícha]

Source: upower
Version: 1.90.2-3
Severity: wishlist

I uploaded the latest libgudev to Unstable but it fails to migrate
because of upower autopkgtest failures.

What do you think about uploading the new upower series to Unstable?

https://tracker.debian.org/pkg/libgudev
https://autopkgtest.ubuntu.com/packages/upower

Thank you,
Jeremy Bícha

Bug#1037422: spamprobe crashing with emails containing an image attached

[Miguel Angel Varo Giner]

Package: spamprobe
Version: 1.4d-16
Followup-For: Bug #1037422

After upgrading from bullseye to bookworm I've found spamprobe is not
working with some emails. I've found that the emails spamprobe is having
problems with is the ones with images attached (jpg or png). Whenever it
processes one of those emails it fails with:

"caught signal 11: quitting
Aborted"


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

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

Versions of packages spamprobe depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u1
ii  libdb5.3   5.3.28+dfsg2-1
ii  libgcc-s1  12.2.0-14
ii  libgif75.2.1-2.5
ii  libjpeg62-turbo1:2.1.5-2
ii  libpng16-161.6.39-2
ii  libstdc++6 12.2.0-14

Versions of packages spamprobe recommends:
ii  procmail  3.22-27

spamprobe suggests no packages.

-- debconf information:
* spamprobe/db53_upgrade:
  spamprobe/db51_upgrade:

Bug#1042753: nouveau: Screen remains black.

[Diederik de Haas]

On Wednesday, 2 August 2023 18:26:32 CEST Olaf Skibbe wrote:
> I gave it a shot and ran
> 
> # apt install /home/olaf/Patches/*.deb

Just linux-image-6.1.0-0.a.test-amd64-unsigned_6.1.38-2a~test_amd64.deb 
would've been enough, but this works too ;-)

> Result: Booted in the new kernel.
> 
> # uname -r
> 6.1.0-0.a.test-amd64
> 
> Graphics works now.

This is fantastic \o/

> I guess I am supposed to build some more kernels with subsets of
> patches? Any hint where to start?

I looked at them, but there wasn't one that stood out for me.
You could try them one by one, but that'll take quite a while.

So I suggest we move on the the next step/phase: contact the upstream 
developers, who are also the ones who'd make the actual fix.

So I want to ask you to write an email and send that:
To: dri-de...@lists.freedesktop.org
To: nouv...@lists.freedesktop.org
CC: 1042...@bugs.debian.org (optionally)

And then 'paste' in the text of your initial bug report until this part:
[3.561131] ---[ end trace  ]---
I suggest to also include the output of 
`lspci -v -s $(lspci | grep -i vga | awk '{ print $1 }')

Tell them that you found out that it was a regression between upstream kernel 
version 6.1.27 and 6.1.38.

Then explain that you build a new 6.1.38 kernel with these commits reverted:
62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL
fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode
90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device
5a144bad3e75 nouveau: fix client work fence deletion race

And that that made graphics work again.
Referencing https://bugs.debian.org/1042753 for full context may also be 
useful.

They may ask you to only revert a specific commit as they should be able to 
make a proper guess. Or they already know by the context.
With a bit of luck they'll also ask you to try a potential fix. They should be 
able to provide such a fix/patch as one which cleanly applies to 6.1.38.
Or otherwise I can probably help with that.

And you can pass that patch (file) as argument to the `test-patches` script :-)

If you have any questions, feel free to ask them.

Cheers,
   Diederik

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

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

Hi!

> > I am ready to upload mariadb/1:10.11.4-0+deb12u2 as a source-only
> > upload with the requested changes[1] but I guess the previous
> > upload[2] needs to clear the NEW queue first, right?
>
> No, don't worry about that. You have the wrong version there though.

I interpreted this to mean that I should not care about one version
already being in the NEW queue, but go ahead and upload a new version
with the requested fixes now merged in
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/52,
so I did that now. I also made sure this upload now also has debug
builds (which were missing from the previous upload).



```
$ dput ftp-master *.changes
Checking signature on .changes
gpg: /srv/sources/mariadb/mariadb-team/mariadb_10.11.4-0+deb12u1_amd64.changes:
Valid signature from BED8449FCEE8DA88
Checking signature on .dsc
gpg: /srv/sources/mariadb/mariadb-team/mariadb_10.11.4-0+deb12u1.dsc:
Valid signature from BED8449FCEE8DA88
Package includes an .orig.tar.gz file although the debian revision suggests
that it might not be required. Multiple uploads of the .orig.tar.gz may be
rejected by the upload queue management software.
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading mariadb_10.11.4-0+deb12u1.dsc: done.
  Uploading mariadb_10.11.4.orig.tar.gz: done.
  Uploading mariadb_10.11.4-0+deb12u1.debian.tar.xz: done.
  Uploading libmariadb-dev-compat_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadb-dev-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadb-dev_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadb3-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadb3_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadbd-dev_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadbd19-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading libmariadbd19_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-backup-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-backup_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-client-core-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-client-core_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-client-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-client_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-common_10.11.4-0+deb12u1_all.deb: done.
  Uploading mariadb-plugin-connect-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-connect_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading 
mariadb-plugin-cracklib-password-check-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-cracklib-password-check_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-gssapi-client-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-gssapi-client_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-gssapi-server-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-gssapi-server_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading 
mariadb-plugin-hashicorp-key-management-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-hashicorp-key-management_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-mroonga-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-mroonga_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-oqgraph-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-oqgraph_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-provider-bzip2-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-provider-bzip2_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-provider-lz4-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-provider-lz4_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-provider-lzma-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-provider-lzma_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-provider-lzo-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-provider-lzo_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-provider-snappy-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-provider-snappy_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-rocksdb-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-rocksdb_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-s3-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-s3_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-plugin-spider-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-plugin-spider_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-server-10.5_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-server-core-dbgsym_10.11.4-0+deb12u1_amd64.deb:
done.
  Uploading mariadb-server-core_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading mariadb-server-dbgsym_10.11.4-0+deb12u1_amd64.deb: done.
  Uploading 

Bug#1042913: freecad: TechDraw workbench: part corner vertices and circle centers not showing up, unable to attach for draw dimensions

[Luca]

Package: freecad
Version: 0.20.2+dfsg1-4
Severity: important
X-Debbugs-Cc: macgyv...@gmail.com

Dear Maintainer,

   * What led up to the situation?

Opening an old document after upgrading (bullseye -> bookworm) I am unable to
add new dimensions to parts in TechDraw.

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

Tried on newly created document and the behaviour is identical. ToggleFrame
does not make them appear, just shows/hides a dashed frame around my part.
Tried also to increase the Vertex Scale in preferences.

   * What was the outcome of this action?

Everything that I tried was unsuccesful to restore the dots.

   * What outcome did you expect instead?

Corner vertices and circle centers represented as "big" dots are mandatory to
produce a Tech Drawing, without that unfortunately FreeCad is useless for my
daily work.



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

Kernel: Linux 6.1.0-10-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.20-1
ii  graphviz  2.42.2-7+b3

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1042889: vm breakage with Emacs 29

[Dirk Eddelbuettel]

On 2 August 2023 at 14:41, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: vm breakage with Emacs 29"):
| > On 2 August 2023 at 13:17, Ian Jackson wrote:
| > | Hi.  Since you were helpful with #1039105 "Fails to start with Emacs
| > | 28" I thought I would draw your attention to #1042889
| > | "vm: autopkgtest fails against Emacs 29.1" [0]
| > | 
| > | I won't have time to look at this until next week, probably.  Any help
| > | or background research would be greatly appreciated.  We need to fix
| > | this to avoid vm getting autoremoved.
| > | 
| > | I did have a quick look at the test log [1] and the failure looks
| > | genuine.  I suggest we do any further diagnosis in the bug.
| > 
| > The band-aid I found and submitted for #1039105 (ie per Fedora's tracker,
| > "just do not byte compile") seems apt here, no?  I still do not really read
| > (or, for that matter, write) elisp but it seems to complain about byte code.
| > 
| > So I would try two things:
| >  - turn off elisp byte compilation as in #1039105
| 
| The patch from #1039105 is still in the package.

Ok.

| Do we need to add to a list of files in it, or something, do you

That was my hunch.

| think ?  Maybe it would be best to disable byte compilation
| completely.

Yes given the previous bug report and fix ensuring no byte-compilation takes
place for vm may be best. At least until someone (upstream? another dev?)
understand why it breaks vm.

Dirk

| 
| One thing that would be useful would be for someone to try out emacs
| and vm in a sid chroot; that would confirm that this isn't a spurious
| test failure (or confirm that it is).
| 
| Thanks,
| Ian.
| 
| -- 
| Ian JacksonThese opinions are my own.  
| 
| Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
| that is a private address which bypasses my fierce spamfilter.

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

Bug#1042855: openjdk-8: Please consider using libjpeg-dev virtual package as dependency

[Thorsten Glaser]

tags 1042855 + pending
thanks

Dixi quod…

>And libjpeg-dev does not appear in this list.

Ahem. That may be because there’s a real package with that name
in all(?) releases.

I’ll change this.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1042753: nouveau: Screen remains black.

[Olaf Skibbe]

On Wed, 2 Aug 2023 at 01:09, Diederik de Haas wrote:


On Wednesday, 2 August 2023 00:23:16 CEST Olaf Skibbe wrote:



But now I am a little clueless: how do I install this kernel? Any hint?


It should have produced one or more .deb files and you can install a .deb file
like this: `apt install ./.deb`
If you share the output of `ls -lh *.deb` (and/or `ls -lh ../*.deb`) then I
can probably give you more precise instructions.


Sorry, my fault. I searched for .deb files in the subdirectory when I 
thought I searched the home directory. I am familiar with installing a 
.deb file.


So we have:

~/Patches$ l *.deb
-rw-r--r-- 1 olaf olaf  647K  2. Aug 00:02 
linux-compiler-gcc-12-x86_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  1,2M  1. Aug 23:59 
linux-headers-6.1.0-0.a.test-amd64_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  9,4M  1. Aug 21:34 
linux-headers-6.1.0-0.a.test-common_6.1.38-2a~test_all.deb
-rw-r--r-- 1 olaf olaf  7,8M  1. Aug 21:34 
linux-headers-6.1.0-0.a.test-common-rt_6.1.38-2a~test_all.deb
-rw-r--r-- 1 olaf olaf   56M  2. Aug 00:01 
linux-image-6.1.0-0.a.test-amd64-unsigned_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  1,2M  2. Aug 00:02 
linux-image-amd64-signed-template_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  898K  2. Aug 00:01 
linux-kbuild-6.1_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf 1001K  2. Aug 00:01 
linux-kbuild-6.1-dbgsym_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  1,8M  2. Aug 00:02 
linux-libc-dev_6.1.38-2a~test_amd64.deb
-rw-r--r-- 1 olaf olaf  694K  1. Aug 21:34 
linux-support-6.1.0-0.a.test_6.1.38-2a~test_all.deb

I gave it a shot and ran

# apt install /home/olaf/Patches/*.deb

Result:

# aptitude search linux-image | grep ^i
i  linux-image-6.1.0-0.a.test-amd64-unsigned - Linux 6.1 for 64-bit PCs
i A linux-image-6.1.0-10-amd64 - Linux 6.1 for 64-bit PCs (signed)
i  linux-image-6.1.0-9-amd64 - Linux 6.1 for 64-bit PCs (signed)
i  linux-image-amd64 - Linux für 64-Bit-PCs (Metapaket)
i  linux-image-amd64-signed-template - Template for signed linux-image packages 
for amd64

Booted in the new kernel.

# uname -r
6.1.0-0.a.test-amd64

Graphics works now.

I guess I am supposed to build some more kernels with subsets of 
patches? Any hint where to start?


Cheers,
Olaf

Bug#1039365: Fedora has systemd-unit files for sendmail

[Andreas Beckmann]

On 31/07/2023 08.52, Marco wrote:

On Sun, 30 Jul 2023 18:46:11 + Marco  wrote:

On Mon, 26 Jun 2023 08:28:22 + Marco  wrote:

Fedora has some systemd unit files included, maybe these are helpful
here:
https://packages.fedoraproject.org/pkgs/sendmail/sendmail/fedora-rawhide.html#files


Is anybody here working on that issue?
  
It seems that the sysvinit script is being partially generated by

sendmailconfig. Is the goal of Debian to still provide that or to
deprecate sendmailconfig?

If it should be kept, I assume it needs to be changed to native
integrate with systemd without using start-stop-daemon.

Deprecating this sendmailconfig functionality makes integrating with
systemd much easier. Configuring queue runner and daemon mode would be
easier in a special file that is being read by the systemd unit.


I wouldn't go away from sendmailconfig since that would probably break 
the sendmail usage for the people still using sendmail ... and without 
maintainer we have noone to clean up after such breakage ...


Maybe we could introduce a sendmail-systemd package to allow running 
sendmail "the modern way" without breaking "the classic way".
We probably need to split the sendmail-bin and sendmail-base packages to 
decouple the sysv and sendmailconfig bits from the parts that are shared 
with sendmail-systemd.


Patches welcome!


Andreas

Bug#1042912: Links

[Amr Ibrahim]

Upstream desktop file:

https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/experimental/comm/taskcluster/docker/thunderbird-flatpak/org.mozilla.Thunderbird.desktop

Debian desktop file:

https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/experimental/debian/thunderbird.desktop

Bug#1042904: SOLVED: Acknowledgement (libvirt-clients: fail to start VM 'file' driver requires '/dev/vg0/UTM' to be a regular file)

[Daniel]

in xml files not only 'disk type' have to be changed to 'block' but also 
'source' to 'dev'


Can be closed as not a bug
--
Daniel

Bug#1042855: openjdk-8: Please consider using libjpeg-dev virtual package as dependency

[Thorsten Glaser]

Vladimir Petko dixit:

>The attached patch updates control and rules to select libjpeg-dev as a

By the way, no need to patch rules for Ubuntu, just regenerate
debian/control is sufficient. I built the package for PPA with
that.

>I think I found the relevant quote:
>"To specify which of a set of real packages should be the default to
>satisfy a particular dependency on a virtual package, list the real
>package as an alternative before the virtual one." 7.5 Virtual
>Packages - Provides.

Yes, that was the one I was thinking of, and you’re right it
doesn’t apply here, as we don’t care which of them is used
(with the exception of the one we Depends on for dlopen).

The first paragraph of 7.5 makes it clear that we *can* use virtual
packages as B-D. However, virtual-package-names-list.yaml says:

# Packages MUST NOT use virtual package names (except privately, amongst
# a cooperating group of packages) unless they have been agreed upon and
# appear in this list.

And libjpeg-dev does not appear in this list.

>> +  bd_syslibs += libjpeg62-turbo-dev | libjpeg-dev,

| [1] While "Build-Depends", "Build-Depends-Indep" and "Build-Depends-
| Arch" permit the use of alternative dependencies, those are only
| used for the backports suite on the Debian autobuilders. On the
| […]
| While this may limit the usefulness of alternatives in a single
| release, they can still be used to provide flexibility in building
| the same package across multiple distributions or releases, where

This indicates that specifically this was intended to make it
compatible with other distributions; if the other distribution
doesn’t accept alternatives, SOL…

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr

Bug#1042842: network interface names wrong in domU (>10 interfaces)

[Valentin Kleibel]

#xen-devel is the IRC Xen channel. I just pinged them, I'll wait.
Depending on their answers, I'll post on the xen-devel mailing list.


thanks for the clarification, looking forward to an answer.

Our current workaround is to edit the interface names in the domUs 
config to match the wrong sorting. And be extra careful that the domUs 
MACs match the ones we expect on that network.


Via udev (MAC matching) or /etc/network/interfaces ?
I ask because it may help others, while this gets resolved.


We just edited /etc/network/interfaces, as it only affects a few of our 
domUs.
i think udev rules matching the MAC would be a better solution. I just 
didn't take the time to write them and went for the quick and dirty 
solution.


Valentin

Bug#1039365: Fedora has systemd-unit files for sendmail

[Andreas Beckmann]

On 30/07/2023 20.46, Marco wrote:

On Mon, 26 Jun 2023 08:28:22 + Marco  wrote:

Fedora has some systemd unit files included, maybe these are helpful
here:
https://packages.fedoraproject.org/pkgs/sendmail/sendmail/fedora-rawhide.html#files


Is anybody here working on that issue?


As sendmail has no maintainer in Debian, I'm afraid this is not being 
worked on.


I'm happily applying patches (if someone provides them) in QA uploads, 
but it's nearly 20 years since I had sendmail running somewhere (on 
Sparc/Solaris at that time).



Andreas

Bug#1042912: Merge the Debian-specific desktop file with the upstream one

[Amr Ibrahim]

Package: thunderbird
Version: 1:115.0.1-2

Hallo Carsten,

Upstream now provides a desktop file as part of their Flatpak distribution:

https://salsa.debian.org/mozilla-team/thunderbird/-
/blob/debian/experimental/comm/taskcluster/docker/thunderbird-
flatpak/org.mozilla.Thunderbird.desktop

Historically, Debian also has a desktop file:

https://salsa.debian.org/mozilla-team/thunderbird/-
/blob/debian/experimental/debian/thunderbird.desktop

Please merge the contents of both desktop files, and install only the merged
file. (Notice the icon name change in the upstream file;
Icon=org.mozilla.Thunderbird)

A perfect course of action is to propose the Debian changes to upstream so that
you will be able to eventually delete the Debian-specific desktop file, and only
install the upstream one.

Best,
Amr

Bug#1042880: systemd: service with PrivateNetwork=yes fails inside lxc container on bookworm

[Simon McVittie]

Control: retitle -1 systemd: service with PrivateNetwork=yes fails inside lxc 
container on bookworm

On Wed, 02 Aug 2023 at 17:53:30 +0200, Michael Biebl wrote:
> Ok, I can reproduce the issue in a bookworm test VM.
> Upgrading that VM to trixie the issue appears to be gone.

Retitling to reflect that. I think this is still going to be
a practical problem for the autopkgtests of packages like polkitd,
because ci.debian.net runs on stable.

smcv

Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc

[Axel Beckert]

Package: elpa-muse
Version: 3.20+dfsg-7
Severity: serious
X-Debbugs-Cc: a...@debian.org
Control: affects -1 emacs emacs-gtk emacs-lucid emacs-nox emacs-pgtk

Since upgrading to Emacs 29.1, byte-(re-)compilation fails as follows:

[…]
Install elpa-muse for emacs
install/muse-3.20: Handling install of emacsen flavor emacs
install/muse-3.20: byte-compiling for emacs

In toplevel form:
cgi.el:71:2: Warning: Package cl is deprecated
cgi.el:87:13: Warning: Unknown defun property ‘character’

In cgi-decode-string:
cgi.el:94:4: Warning: ‘do’ is an obsolete alias (as of 27.1); use ‘cl-do’ 
instead.
cgi.el:101:15: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ 
instead.
cgi.el:108:17: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ 
instead.

In cgi-decode:
cgi.el:124:6: Warning: ‘flet’ is an obsolete macro (as of 24.3); use either 
‘cl-flet’ or ‘cl-letf’.

In cgi-arguments:
cgi.el:161:13: Warning: ‘loop’ is an obsolete alias (as of 27.1); use ‘cl-loop’ 
instead.

In end of data:
cgi.el:197:16: Warning: the function ‘calendar-current-date’ might not be 
defined at runtime.

In toplevel form:
htmlize-hack.el:12:13: Warning: ‘loop’ is an obsolete alias (as of 27.1); use 
‘cl-loop’ instead.
htmlize-hack.el:17:8: Warning: ‘reduce’ is an obsolete function (as of 27.1); 
use ‘cl-reduce’ instead.

In muse-backlink-insert-hook-func:
muse-backlink.el:264:12: Warning: ‘font-lock-fontify-buffer’ is for interactive 
use only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead.

In end of data:
muse-backlink.el:313:33: Warning: the function ‘muse-make-link’ might not be 
defined at runtime.

In toplevel form:
muse-colors.el:60:2: Warning: custom-declare-variable 
`muse-colors-autogen-headings' docstring has wrong usage of unescaped single 
quotes (use \= or different
 quoting)
muse-colors.el:94:2: Warning: custom-declare-variable 
`muse-colors-inline-image-method' docstring has wrong usage of unescaped single 
quotes (use \= or differ
ent quoting)

In muse-colors-region:
muse-colors.el:577:10: Warning: ‘inhibit-point-motion-hooks’ is an obsolete 
variable (as of 25.1); use ‘cursor-intangible-mode’ or ‘cursor-sensor-mode’ 
instea
d

In muse-unhighlight-region:
muse-colors.el:732:10: Warning: ‘inhibit-point-motion-hooks’ is an obsolete 
variable (as of 25.1); use ‘cursor-intangible-mode’ or ‘cursor-sensor-mode’ 
instea
d

In muse-colors-lisp-tag:
muse-colors.el:775:30: Warning: ‘muse-looking-back’ called with 1 argument, but 
requires 2 or 3

In muse-docbook-markup-paragraph:
muse-docbook.el:233:41: Warning: ‘muse-looking-back’ called with 1 argument, 
but requires 2 or 3

In toplevel form:
muse-html.el:67:2: Warning: custom-declare-variable `muse-html-style-sheet' 
docstring wider than 80 characters
muse-html.el:96:2: Warning: custom-declare-variable `muse-xhtml-style-sheet' 
docstring wider than 80 characters
muse-html.el:399:2: Warning: custom-declare-variable 
`muse-html-meta-content-encoding' docstring has wrong usage of unescaped single 
quotes (use \= or differe
nt quoting)
muse-html.el:421:2: Warning: custom-declare-variable 
`muse-html-src-allowed-modes' docstring has wrong usage of unescaped single 
quotes (use \= or different q
uoting)

In muse-html-markup-paragraph:
muse-html.el:490:6: Warning: ‘muse-looking-back’ called with 1 argument, but 
requires 2 or 3

In muse-html-src-tag:
muse-html.el:670:16: Warning: ‘font-lock-fontify-buffer’ is for interactive use 
only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead.
../../elpa-src/muse-3.20/cgi.el: Warning: Unknown defun property ‘character’
../../elpa-src/muse-3.20/cgi.el: Warning: ‘do’ is an obsolete alias (as of 
27.1); use ‘cl-do’ instead.
../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 
27.1); use ‘cl-incf’ instead.
../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 
27.1); use ‘cl-incf’ instead.
../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 
27.1); use ‘cl-incf’ instead.
../../elpa-src/muse-3.20/cgi.el: Warning: ‘flet’ is an obsolete macro (as of 
24.3); use either ‘cl-flet’ or ‘cl-letf’.
../../elpa-src/muse-3.20/cgi.el: Warning: ‘loop’ is an obsolete alias (as of 
27.1); use ‘cl-loop’ instead.
../../elpa-src/muse-3.20/muse-ipc.el: Warning: ‘return-from’ is an obsolete 
alias (as of 27.1); use ‘cl-return-from’ instead.
../../elpa-src/muse-3.20/muse-ipc.el: Warning: ‘return-from’ is an obsolete 
alias (as of 27.1); use ‘cl-return-from’ instead.

In toplevel form:
muse-ipc.el:50:2: Warning: custom-declare-variable `muse-ipc-ignore-done' 
docstring has wrong usage of unescaped single quotes (use \= or different 
quoting)
muse-ipc.el:80:2: Warning: ‘defun*’ is an obsolete alias (as of 27.1); use 
‘cl-defun’ instead.

In muse-ipc-server-filter:
muse-ipc.el:93:6: Warning: ‘return-from’ is an obsolete alias (as of 27.1); use 
‘cl-return-from’ instead.

In muse-journal-generate-pages:
muse-journal.el:186:24: Warning: value returned from 

Bug#1042910: smuxi-frontend-gnome: no sound on highlight

[Jeremyp3]

Package: smuxi-frontend-gnome
Version: 1.1-1.1
Severity: normal

Dear Maintainer,

since i installed this version, there's no longer the little note when 
you're

highlighted. so i sometimes miss mentions because of this ... there's the
notification but no sound anymore


-- System Information:
Debian Release: bookworm
APT prefers testing
APT policy: (500, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), 
(1, 'experimental')

Architecture: amd64 (x86_64)

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

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

Versions of packages smuxi-frontend-gnome depends on:
ii libdbus-glib2.0-cil 0.6.0-1.1
ii libdbus2.0-cil 0.8.1-2.1
ii libglib2.0-0 2.76.4-4
ii libglib2.0-cil 2.12.40-3.1
ii libgtk2.0-0 2.24.33-2
ii libgtk2.0-cil 2.12.40-3.1
ii liblog4net1.2-cil 1.2.10+dfsg-8
ii libmessagingmenu12.10-cil 1.0.1-1.1
ii libmono-corlib4.5-cil 6.8.0.105+dfsg-3.3
ii libmono-posix4.0-cil 6.8.0.105+dfsg-3.3
ii libmono-system-core4.0-cil 6.8.0.105+dfsg-3.3
ii libmono-system-web4.0-cil 6.8.0.105+dfsg-3.3
ii libmono-system4.0-cil 6.8.0.105+dfsg-3.3
ii librsvg2-common 2.54.5+dfsg-1
ii mono-runtime 6.8.0.105+dfsg-3.3
ii smuxi-engine 1.1-1.1

Versions of packages smuxi-frontend-gnome recommends:
ii mate-notification-daemon [notification-daemon] 1.26.0-1
pn ssh-askpass-gnome | ssh-askpass

smuxi-frontend-gnome suggests no packages.

-- no debconf information

Bug#1042880: systemd: service with PrivateNetwork=yes fails to start inside a lxc container

[Michael Biebl]

Am 02.08.23 um 16:14 schrieb Simon McVittie:

On Wed, 02 Aug 2023 at 13:13:05 +0200, Michael Biebl wrote:

Are you by any chance using unprivileged containers?


I don't know, but not intentionally! My test VM had no special
configuration and no lxc before starting the steps-to-reproduce, so I
was using whatever is the default in bookworm.


Ok, I can reproduce the issue in a bookworm test VM.
Upgrading that VM to trixie the issue appears to be gone.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025559: fwupd: dependency on transitional policykit-1 package

[Simon McVittie]

Control: tags -1 + patch

On Tue, 06 Dec 2022 at 13:22:40 +, Simon McVittie wrote:
> This package has a Depends and/or Build-Depends on the transitional
> package policykit-1, which has been separated into polkitd, pkexec and
> (deprecated) polkitd-pkla packages.

This package doesn't seem to use pkexec, so please consider the attached
patch, also available as
.

It compiles successfully but I have not otherwise tested it.

According to diffoscope, the only differences in the built binary packages
as a result of this change seem to be build paths and Build-IDs.

Thanks,
smcv
>From 03db339d5bffb44460b4c29fa83a6ffb480e0c09 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 2 Aug 2023 15:27:55 +0100
Subject: [PATCH] d/control, d/control.in: Use polkitd instead of transitional
 policykit-1

Closes: #1025559
---
 debian/control| 4 ++--
 debian/control.in | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index c3fb4c313..f0bc2cb75 100644
--- a/debian/control
+++ b/debian/control
@@ -55,7 +55,7 @@ Build-Depends:
 	mingw-w64-tools [amd64 arm64 armhf i386],
 	pandoc,
 	pkg-config,
-	policykit-1 (>> 0.105-14),
+	polkitd,
 	protobuf-c-compiler,
 	python3-gi-cairo,
 	python3-jinja2,
@@ -136,7 +136,7 @@ Depends: ${misc:Depends},
  dbus-x11,
  fwupd,
  gnome-desktop-testing,
- policykit-1,
+ polkitd,
  python3,
  python3-gi,
  python3-requests,
diff --git a/debian/control.in b/debian/control.in
index 85d1af4b4..ad7af9786 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -72,7 +72,7 @@ Depends: ${misc:Depends},
  dbus-x11,
  fwupd,
  gnome-desktop-testing,
- policykit-1,
+ polkitd,
  python3,
  python3-gi,
  python3-requests,
@@ -137,4 +137,4 @@ Description: GObject introspection data for libfwupd
  This package provides the introspection data for libfwupd.
  .
  It can be used by packages using the GIRepository format to generate
- dynamic bindings.
\ No newline at end of file
+ dynamic bindings.
-- 
2.40.1

Bug#1042908: src:hypercorn: fails to migrate to testing for too long: new build dependency not ready to migrate

[Paul Gevers]

Hi,

On Wed, 2 Aug 2023 17:31:30 +0200 Paul Gevers  wrote:
The version in unstable has a 
new Build-Depends, but that package isn't ready to migrate yet.


I hit the send button too fast. Right after sending I noticed that that 
package passed it's tests in unstable, so I triggered a retry for the 
migration tests, which, if I checked correctly, all passed now.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039171: dictd: ships sysv-init script without systemd unit

[Sven Joachim]

On 2023-06-25 23:21 +0100, bl...@debian.org wrote:

> Package: dictd
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service
>
> Dear Maintainer(s),
>
> dictd has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.

The other day I checked my system for init scripts without a
corresponding service file, and found dictd as the only package left.

Since dictd supports both running as a daemon and being started on
demand via inetd, I took the effort to translate the latter option into
systemd socket activation[1], adapting the units from the dicod package
which fulfills the same purpose as dictd.  The three systemd units I
installed on my system are attached.

In the per-connection instance dictd@.service I have set User=dictd.  It
would be possible to do that in dictd.service as well by shipping a
tmpfiles.d(5) snippet that creates a directory (say, /run/dictd)
writable by the dictd user, and changing the PIDFile= option to create
the pid file in that directory rather than directly under /run.  Since
dictd drops privileges very early I did not bother to do that, nor did
I implement any of the proposed hardening features[2].  But that is
certainly something the maintainer should consider.

Occasionally I saw the error message

dictd.service: Failed to parse PID from file /run/dictd.pid: Invalid argument

in the logs, which indicates some kind of race condition I do not fully
understand.  The service worked fine anyway, but I have chosen to enable
dictd.socket instead on my system since that does not require a
permanently waiting daemon, and the answers from the per-connection
instances were pretty much instantaneous.

How all this fits into the existing scheme where debconf and ucf are
used to let users switch between daemon and on-demand activation, and
how the various README files need to be updated, is unclear to me and
really needs to be decided by the maintainer.

Cheers,
   Sven


1. https://0pointer.net/blog/projects/inetd.html
2. https://bugs.debian.org/1032331

[Unit]
Description=Dictd dictionary server daemon
Documentation=man:dictd(8)
After=network.target

[Service]
Type=forking
PIDFile=dictd.pid
EnvironmentFile=-/etc/default/dictd
ExecStart=/usr/sbin/dictd $DICTD_ARGS

[Install]
WantedBy=multi-user.target
[Unit]
Description=Dictd dictionary server socket
Before=dictd.service
Conflicts=dictd.service

[Socket]
ListenStream=2628
Accept=yes

[Install]
WantedBy=sockets.target
[Unit]
Description=Dictd dictionary server per-connection daemon
Documentation=man:dictd(8)

[Service]
EnvironmentFile=-/etc/default/dictd
ExecStart=-/usr/sbin/dictd --inetd $DICTD_ARGS
StandardInput=socket
User=dictd

Bug#1042909: RM: rust-sha3-0.9 -- NVIU; obsolete package, no rdeps

[Alexander Kjäll]

Package: ftp.debian.org
Severity: normal

Hi, please remove this package on all architectures. It is an old rust library
used for transitioning with no reverse dependencies.

Bug#1042723: src:r-cran-tmb: fails to migrate to testing for too long: autopkgtest regression

[Nilesh Patra]

On Mon, 31 Jul 2023 07:59:07 +0200 Paul Gevers  wrote:
> Source: r-cran-tmb
> Version: 1.9.2-1
> Severity: serious
> Control: close -1 1.9.4-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync

This needs fixing in two stages. The error is:

| 38s TMB was built with Matrix version 1.5.4.1
| 38s Current Matrix version is 1.5.3

So rmatrix's new version needs to go to testing, which is currently
1.6.0. So

1. rmatrix 1.6.0 needs to go to testing
2. tmb needs to be rebuilt against rmatrix 1.6.0

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1042908: src:hypercorn: fails to migrate to testing for too long: new build dependency not ready to migrate

[Paul Gevers]

Source: hypercorn
Version: 0.13.2-3
Severity: serious
Control: close -1 0.14.4-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:hypercorn has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The version in unstable has a 
new Build-Depends, but that package isn't ready to migrate yet.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=hypercorn



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042907: Breaks Emacs 29.1 upgrade: haskell.el:30:2: Error: Eager macro-expansion failure: (error "Misplaced t or ‘otherwise’ clause")

[Axel Beckert]

Package: elpa-haskell-mode
Version: 17.2-5
Severity: serious
X-Debbugs-Cc: a...@debian.org
Control: affects -1 emacs emacs-gtk emacs-lucid emacs-nox emacs-pgtk

After upgrading Emacs to 29.1, byte-(re-)compiling fails as follows:

[…]
Install elpa-haskell-mode for emacs
install/haskell-mode-17.2snapshot: Handling install of emacsen flavor emacs
install/haskell-mode-17.2snapshot: byte-compiling for emacs
../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 
'before will match ‘quote’.  If that’s intended, write (before quote) instead.  
Otherwise, don’t quote ‘before’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 'after 
will match ‘quote’.  If that’s intended, write (after quote) instead.  
Otherwise, don’t quote ‘after’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 
'single will match ‘quote’.  If that’s intended, write (single quote) instead.  
Otherwise, don’t quote ‘single’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 
'ghci will match ‘quote’.  If that’s intended, write (ghci quote) instead.  
Otherwise, don’t quote ‘ghci’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 
'cabal-repl will match ‘quote’.  If that’s intended, write (cabal-repl quote) 
instead.  Otherwise, don’t quote ‘cabal-repl’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 
'stack-ghci will match ‘quote’.  If that’s intended, write (stack-ghci quote) 
instead.  Otherwise, don’t quote ‘stack-ghci’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 
'unknown-command will match ‘quote’.  If that’s intended, write 
(unknown-command quote) instead.  Otherwise, don’t quote ‘unknown-command’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 
'option-missing will match ‘quote’.  If that’s intended, write (option-missing 
quote) instead.  Otherwise, don’t quote ‘option-missing’.
../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 
'interactive-error will match ‘quote’.  If that’s intended, write 
(interactive-error quote) instead.  Otherwise, don’t quote ‘interactive-error’.

In toplevel form:
ghci-script-mode.el:20:2: Error: Eager macro-expansion failure: (error 
"Misplaced t or ‘otherwise’ clause")

In haskell-cabal-classify-line:
haskell-cabal.el:363:2: Warning: docstring wider than 80 characters
haskell-cabal.el:363:2: Warning: docstring has wrong usage of unescaped single 
quotes (use \= or different quoting)

In haskell-cabal-enum-targets:
haskell-cabal.el:496:2: Warning: docstring wider than 80 characters

In haskell-cabal-listify:
haskell-cabal.el:701:12: Warning: Case 'before will match ‘quote’.  If that’s 
intended, write (before quote) instead.  Otherwise, don’t quote ‘before’.
haskell-cabal.el:701:12: Warning: Case 'after will match ‘quote’.  If that’s 
intended, write (after quote) instead.  Otherwise, don’t quote ‘after’.
haskell-cabal.el:701:12: Warning: Case 'single will match ‘quote’.  If that’s 
intended, write (single quote) instead.  Otherwise, don’t quote ‘single’.

In haskell-cabal-line-filename:
haskell-cabal.el:926:2: Warning: docstring wider than 80 characters

In haskell-blank-line-p:
haskell-collapse.el:46:9: Warning: ‘point-at-eol’ is an obsolete function (as 
of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.

In haskell-hide-toggle-all:
haskell-collapse.el:95:19: Warning: ‘point-at-bol’ is an obsolete function (as 
of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.

In toplevel form:
haskell-commands.el:652:12: Error: Misplaced t or ‘otherwise’ clause

In toplevel form:
haskell-compile.el:42:2: Warning: custom-declare-variable 
`haskell-compile-cabal-build-command' docstring wider than 80 characters
haskell-compile.el:49:2: Warning: custom-declare-variable 
`haskell-compile-cabal-build-alt-command' docstring wider than 80 characters
haskell-compile.el:56:2: Warning: custom-declare-variable 
`haskell-compile-stack-build-command' docstring wider than 80 characters
haskell-compile.el:63:2: Warning: custom-declare-variable 
`haskell-compile-stack-build-alt-command' docstring wider than 80 characters
haskell-compile.el:70:2: Warning: custom-declare-variable 
`haskell-compile-command' docstring wider than 80 characters
haskell-compile.el:83:2: Warning: custom-declare-variable 
`haskell-compiler-type' docstring wider than 80 characters

In haskell-completions-grab-pragma-prefix:
haskell-completions.el:146:2: Warning: docstring has wrong usage of unescaped 
single quotes (use \= or different quoting)

In haskell-completions-grab-identifier-prefix:
haskell-completions.el:216:2: Warning: docstring has wrong usage of unescaped 
single quotes (use \= or different quoting)

In haskell-completions-grab-prefix:
haskell-completions.el:267:2: Warning: docstring has wrong usage of unescaped 
single quotes (use \= or different quoting)

In haskell-completions--simple-completions:

Bug#1042906: ansible: please package new upstream version 8.x

[Dominik George]

Source: ansible
Version: 7.3.0+dfsg-1
Severity: wishlist

Hi Lee,

Ansible upstream is currently at 8.2.

In order to not having to resort to pip install, an update
of Debian's ansible package would be much appreciated.

Cheers,
Nik

Bug#1042905: Package build can include a core file

[Steve McIntyre]

Source: python-greenlet
Version: 2.0.2-1
Severity: normal
Tags: patch

Hi!

I initially found this doing a rebuild in a derived distro, then
debugged and worked out what's happening. The build-time tests may
generate a core file, depending on the build environment. If that
happens, the core file in included in the .deb output which is clearly
not useful.

It's just luck that the Debian buildds (etc.) don't run "ulimit -c
unlimited" or similar to have triggered this already.

Have an obvious patch to fix this... :-)

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/rules b/debian/rules
index 0a03f62..9be930e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,6 +25,7 @@ override_dh_auto_install:
mv $(CURDIR)/debian/tmp/usr/include/python3.7/ \
$(CURDIR)/debian/tmp/usr/include/python3.7m/ ; \
fi
+   find $(CURDIR)/debian/tmp/ -name core -type f -delete
 
 override_dh_auto_test:
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))

Bug#1042904: libvirt-clients: fail to start VM 'file' driver requires '/dev/vg0/UTM' to be a regular file

[Daniel]

Package: libvirt-clients
Version: 9.0.0-4
Severity: grave
Justification: renders package unusable

The xml configuration file was working well on Debian 11. After 
upgrading to Bookworm I get this error, VM doesn't start:

virsh # start UTM
erreur :Failed to start domain 'UTM'
erreur :internal error: process exited while connecting to monitor: 
2023-08-02T14:13:20.203465Z kvm: -blockdev 
{"driver":"file","filename":"/dev/vg0/UTM","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}: 
'file' driver requires '/dev/vg0/UTM' to be a regular file


Changing driver file to block give on xml validation:

erreur :XML document failed to validate against schema: Unable to 
validate doc against /usr/share/libvirt/schemas/domain.rng

Extra element devices in interleave
Element domain failed to validate content

Attached is the VM xml configuration file. All of our VMs are based on 
LVM disk, we can't use anymore VMs from this server !


-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

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

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

Versions of packages libvirt-clients depends on:
ii libc6 2.36-9+deb12u1
ii libgcc-s1 12.2.0-14
ii libglib2.0-0 2.74.6-2
ii libgnutls30 3.7.9-2
ii libreadline8 8.2-1.3
ii libvirt0 9.0.0-4
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii sensible-utils 0.0.17+nmu1

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
pn libvirt-clients-qemu 
ii libvirt-daemon 9.0.0-4
pn libvirt-login-shell 

-- no debconf information



  UTM
  9dda06a5-689a-4656-9476-145897ede125
  4194304
  4194304
  2
  
hvm
  
  


  
  
  



  
  destroy
  restart
  restart
  


  
  
/usr/bin/kvm

  
  
  
  
  


  
  
  
  


  


  
  


  
  


  
  



  


  


  
  
  
  
  


  
  
  
  
  


  

  


  


  
  




  


  



  
  


  


  


  

  

Bug#1042903: bookworm-pu: package firewalld/1.3.3-1~deb12u1

[Michael Biebl]

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

Hi,

I'd like to make a stable upload for firewalld, fixing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038904

The current version in stable which is affected by this issue is 1.3.0-1
and I'd like to upload 1.3.3-1 as 1.3.3-1~deb12u1 to bookworm to fix
this issue. 1.3.3-1 has been in testing for several weeks with no
reported regression.

The relevant code changes are attached as diff.txt and were generated
via
# git diff debian/1.3.0-1..debian/1.3.3-1 -- src/firewall*


Attached is also the full debdiff for completeness sake.
It contains a lot of autogenerated test code, build system and doc
changes, so for the actual changes, you might refer to diff.txt.

Please let me know, if I can proceed with the upload.

Regards,
Michael

Bug#1025552: calamares: dependency on transitional policykit-1 package

[Simon McVittie]

Control: tags -1 + patch

On Tue, 06 Dec 2022 at 13:16:06 +, Simon McVittie wrote:
> This package has a Depends and/or Build-Depends on the transitional
> package policykit-1, which has been separated into polkitd, pkexec and
> (deprecated) polkitd-pkla packages.

Proposed patch: attached or
https://salsa.debian.org/qt-kde-team/extras/calamares/-/merge_requests/4

Compiled successfully, otherwise untested. Unfortunately calamares'
build isn't reproducible, so I wasn't able to verify that the resulting
binaries are the same.

smcv
>From 95969c3c5fcbade88c040b4946355c9c9e63f27c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 2 Aug 2023 13:03:21 +0100
Subject: [PATCH] Replace transitional build-dependency policykit-1 with
 polkitd

Closes: #1025552
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index df62061..322aead 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,7 @@ Build-Depends: cmake,
os-prober ,
pkg-config,
pkg-kde-tools,
-   policykit-1 ,
+   polkitd ,
python3-dev,
qml-module-qtquick-layouts,
qml-module-qtquick-privatewidgets,
-- 
2.40.1

Bug#1042902: emacs-gtk: system-package-package-manager should be "apt"

[Barak A. Pearlmutter]

Package: emacs-gtk
Version: 1:29.1+1-2
Severity: normal

The global variable system-packages-package-manager (introduced in 29.x)
defaults to "pacman" instead of the more debian-appropriate "apt".