Bug#1071181: Removing packages from rollback distributions fails
On Wed, 2024-05-15 at 15:53 +0200, Magnus Holmgren wrote: > Package: mini-buildd > Version: 2.0.15~bpo12+1 > > Sorry if I should have discussed this elsewhere before reporting a bug, but > there is no mailing list for mini-buildd, is there? It seems like it has to > be > a bug, although it's surprising that nobody has reported it yet. Sorry if > it's > been fixed in 2.2 already, but I can't find anything relevant in the > changelog. yes, there is no mailing list. Bug report is prefectly fine... > Anyway, I'm getting 400 Bad Request (No such source: Source 'package_version' > not found in 'repo-dist-suite-rollback4' distribution) when trying to remove a ups, good find. Seems that feature is hardly ever used ;) This was actually introduced in 2.0.x, and is still in 2.2.x. Will add test case and fix asap. Thx! S signature.asc Description: This is a digitally signed message part
Bug#906747: reprepro does not accept built files on includedsc
On Sat, 25 Aug 2018 13:25:24 +0200 Marc Haber wrote: > severity #906747 normal > thanks > > I now think that this is actually a reprepro issue, and it only applies (...) > My beef against mini-buildd is therefore reduced to the fact that it > once more hides the actual error message in the logs, and that I > cannot access the built packages for manual testing since they're killed > off as soon as the error happens. fwiw: This went to control@ only, pasting here again for convenience/explanation: retitle 906747 Please keep build data (even if installation finally fails) fixed 906747 2.0.0 thanks Since 2.0.0, all build data is kept in a resp. builds directory (including potentially built binary packages), and can be downloaded via HTTP. Builds data expires after 5 days (or, for 2.2.x, by default after 5 days). For expert debugging, m-b-debug-build may be used to help analyze faild builds (while the build data is still there). Hth, S signature.asc Description: This is a digitally signed message part
Bug#1070111: mini-buildd wishlist: configurable periodic jobs (or: don't keep complete build results for a full year)
Hi Magnus, On Tue, 2024-04-30 at 11:40 +0200, Magnus Holmgren wrote: > Package: mini-buildd > Severity: wishlist > coded. Perhaps you've already planned to add some configurability in the > future, but more specifically I'd like to talk about the "Expire no imminent plans to make cron jobs configurable, however expire times for event and build directories are configurable in upcoming 2.2.x. Hth! S signature.asc Description: This is a digitally signed message part
Bug#1069586: Chromium native Wayland support broken
Some more tests confirm the following: --ozone-platform=waylandworks --ozone-platform-hint=wayland does not work Regards Stephan
Bug#1069586: Chromium native Wayland support broken
Workaround: If you are stuck Chromium using native Wayland support, you can reset it with the following steps: 1. Log out GNOME on Wayland session and log in with Gnome on Xorg session. 2. Launch Chromium. 3. Enter chrome://flags into URL bar and reset the setting “Preferred Ozone platform” to “Default”. 4. Log out and log in again with Wayland session. Regards Stephan
Bug#1069586: Chromium native Wayland support broken
Package: chromium Version: 124.0.6367.60-1~deb12u1 Since the last update, Chromium does work with native Wayland. It is starting up, but it is displaying an invisible window. It is listed in the window switchers (Alt+Tab), Gnome Shell etc., but invisible. Note: The default configuration uses X11 via XWayland and is working. The setting can be managed via command line arguments or by typing chrome://flags into the URL bar (filter for ozone). Available settings: default -> X11works auto-> Wayland if available does not work x11 works wayland does not work I have been using Chromium with native Wayland for many months without problems until the last update. I reproduced this with a completely new browser profile. Regards Stephan
Bug#1068024: Or remove xz altogether?
Maybe the people who criticized xz back in the day for being an amateur project implementing a defective file format were right all along? https://www.nongnu.org/lzip/xz_inadequate.html Regards Stephan
Bug#1066126: RFA: rust-enum-unitary -- Trait and macro for unitary enums - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-unit...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-unitary I request an adopter for the rust-enum-unitary package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-unitary crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066127: RFA: rust-kmon -- Interactive kernel monitor that combines dmesg and kmod
Package: wnpp Severity: normal X-Debbugs-Cc: rust-k...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-kmon I request an adopter for the rust-kmon package. If you adopt this package, please remove me from the uploaders list. The package description is: kmon is an interactive kernel monitor for the terminal. It can insepct and load kernel modules, and it can monitor kernel activity. It basically combines dmesg and kmod into one application. Note that is probably needs to run as root.
Bug#1066125: RFA: rust-enum-iterator-derive -- Procedural macro to iterate over the variants of a field-less enum - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-iterator-der...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-iterator-derive I request an adopter for the rust-enum-iterator-derive package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-iterator-derive crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066124: RFA: rust-enum-iterator -- Tools to iterate over the variants of a field-less enum - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-enum-itera...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-enum-iterator I request an adopter for the rust-enum-iterator package. If you adopt this package, please remove me from the uploaders list. The package description is: This package contains the source for the Rust enum-iterator crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1066123: RFA: rust-colorsys -- Module for color conversion and mutation - Rust source code
Package: wnpp Severity: normal X-Debbugs-Cc: rust-color...@packages.debian.org, debian-r...@lists.debian.org, stephanlach...@debian.org Control: affects -1 + src:rust-colorsys I request an adopter for the rust-colorsys package. If you adopt this package, please remove me from the uploaders list. The package description is: Works with RGB(a)( as hexadecimal too), HSL(a), CMYK color models and with ANSI color codes . This package contains the source for the Rust colorsys crate, packaged by debcargo for use with cargo and dh-cargo.
Bug#1063563: ghostscript: ps2epsi fails with Error: /undefined in /finddevice
Package: ghostscript Version: 10.02.1~dfsg-3 Severity: normal The version 10.0.0~dfsg-10 works and produces the expected output. 10.01.2~dfsg-1 works as well. 10.02.1~dfsg-3 does not: $ ps2epsi hvosc-doc_sch.ps hvosc-doc_sch.eps Error: /undefined in /finddevice Operand stack: (bit) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1944 1 3 %oparray_pop 1943 1 3 %oparray_pop 1928 1 3 %oparray_pop 1801 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:746/1123(ro)(G)-- --dict:0/20(G)-- --dict:99/200(L)-- Current allocation mode is local Current file position is 4836 GPL Ghostscript 10.02.1: Unrecoverable error, exit code 1 Is this similar to bug #1003926 ? -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.21-falbala (SMP w/20 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages ghostscript depends on: ii libc62.37-15 ii libgs10 10.0.0~dfsg-10 ghostscript recommends no packages. ghostscript suggests no packages. -- no debconf information
Bug#1063076: asio: binary-any FTBFS
Ah shit, ftp-masters reject my new version to DEFERRED without notifying me but email. Thanks for the pointer, will fix it ASAP. Cheers, Stephan
Bug#1018679: libmsgpack-dev: Remove "Depends: libmsgpack-cxx-dev"
Hi James, I saw that you wrote patches for rocblas and dials, thanks a lot for this! Both have been uploaded since then. Since this were the last blockers, can we go ahead with this transition? Cheers, Stephan
Bug#1061497: msgpack-cxx: Please update to 6.1.0
Hi James, thanks for your swift replay and thanks for the bug report! I was not aware of it. Regarding the transition, the only missing package according to #1018679 is autobahn-cpp (#1019114), which is orphaned. However, there are indeed new packages that have appeared since then that depend on libmsgpack-dev: - neovim - dials - tmate-ssh-server - libdata-messagepack-stream-perl - tamte - rocblas - groonga - webdis - neovim-qt - libdata-messagepack-perl I did a quick codesearch via https://codesearch.debian.net/search?q=msgpack.hpp to find out which of those packages actually depend on msgpack-cxx: - ring - rocblas - dials - libdata-messagepack-stream-perl (unsure) Is there anything I can do to help speed up this transition? Given that number of affected packages is quite small, I don't think a forceful transition for the C++ library would be a problem (that is, removing libmsgpack-cxx-dev from libmsgpack-dev and updating msgpack-cxx). I am willing to invest time in writing bug reports and patches if you think this is doable before Feb 29th. Cheers, Stephan
Bug#1061497: msgpack-cxx: Please update to 6.1.0
Package: msgpack-cxx Severity: wishlist X-Debbugs-Cc: james...@debian.org, stephanlach...@debian.org Hi, would it be possible to upload msgpack 6.1.0 to Debian unstable soon? It would be nice to have the v6 API in Ubuntu 24.04 LTS, for which the import freeze is on the 29th February. I can also upload it as NMU if you want. Cheers, Stephan -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059861: molly-guard: Poweroff doesnt' work anymore
Package: molly-guard
Version: 0.8.3
Severity: normal
Dear Maintainer,
since the package change for this stupid usermerge bullshit the command
poweroff doesn’t work anymore. Halt is still working, but doesn’t
poweroff the system.
osgiliath:~# poweroff
E: unsupported command: poweroff.no-molly-guard
[stse@osgiliath]: ls -l /usr/sbin/poweroff*
lrwxrwxrwx 1 root root 30 22. Dez 23:23 /usr/sbin/poweroff ->
../lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root 4 6. Dez 16:02 /usr/sbin/poweroff.no-molly-guard ->
halt
[02.01.24 15:33] ~
[stse@osgiliath]: ls -l /usr/sbin/halt*
lrwxrwxrwx 1 root root30 22. Dez 23:23 /usr/sbin/halt ->
../lib/molly-guard/molly-guard
-rwxr-xr-x 1 root root 22792 6. Dez 16:02 /usr/sbin/halt.no-molly-guard
For now I will deinstall the package.
Many greetings,
Stephan
-- System Information:
Debian Release: trixie/sid
APT prefers oldstable-updates
APT policy: (900, 'oldstable-updates'), (900, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.9 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages molly-guard depends on:
ii procps 2:4.0.4-2
molly-guard recommends no packages.
molly-guard suggests no packages.
-- no debconf information
--
|If your life was a horse, you'd have to shoot it.|
Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
On Sat, 30 Dec 2023 12:47:48 + Colin Watson wrote: > I also feel that something security-critical like this that's > labelled by upstream as "still experimental" probably shouldn't > be in a Debian release. It is written in Go. The problem of Go library support in Debian should also be considered for a security-critical tool like this. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking Regards signature.asc Description: This is a digitally signed message part
Bug#1057967: fixed in linux 6.1.67-1
Hereby I confirm that linux-image-6.1.0-16-amd64 (6.1.67-1) from bookworm-proposed-updates fixed the problems for me. Regards Stephan signature.asc Description: This is a digitally signed message part
Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable
Hello everybody Unfortunately, I can confirm the same problems for 2014 Macbook Pro (Intel CPU and graphics). At first I thought the network problem was due to the proprietary Broadcom WLAN driver because network connectivity was the most obvious problem. However, the problems persisted after removing all proprietary (broadcom-sta) and custom (facetimehd) kernel modules. Regards Stephan signature.asc Description: This is a digitally signed message part
Bug#1057843: Guidelines for affected users
Are there any guidelines for affected users who already updated before they got the warning? Interesting questions for affected users: - Is it safe to assume that other filesystems (like BTRFS) are not affected? - Does this cause filesystem corruption or only file corruption? - Does this affect metadata or only file contents? - Is there a way to detect corrupted files? - If metadata is not affected, is it safe to assume that all files with a modification date older than the update are fine? - Does it help to shut down services (such as Apache) or the whole machine until the fix is available?
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
Package: orphan-sysvinit-scripts Version: 0.15 Severity: wishlist Dear Maintainer, the mdadm maintainer has dropped the initscript without warning: mdadm (4.2+20230227-1) experimental; urgency=medium * Removing sysvinit scripts in favour of systemd units: - properly checkrestart mdmonitor (Closes: #815834). - no update-rc.d warnings anymore (Closes: #822354). - properly shutdown (Closes: #829621). - making /etc/default/mdadm obsolete for most things (Closes: #850180). * Removing cron jobs in favour of systemd timers: - daily checks also work if system is not always on (Closes: #889978). Even the cronjob is gone. Can you please take over the missing files? Many greetings, Stephan -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (900, 'oldstable-updates'), (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.1 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages orphan-sysvinit-scripts depends on: ii ucf 3.0043+nmu1 orphan-sysvinit-scripts recommends no packages. orphan-sysvinit-scripts suggests no packages. -- no debconf information -- |If your life was a horse, you'd have to shoot it.|
Bug#1054750: reuse: FTBFS: make: *** [debian/rules:4: binary] Error 1
Caused by dh-python #1055008
Bug#1055008: dh-python tries to remove LICENSES folder causing FTBFS
Package: dh-python
Version: 6.20231025
Severity: important
X-Debbugs-Cc: stephanlach...@debian.org
A recent change in dh-python [1] causes an FTBFS in reuse [2].
In particular, this is the error that causes the FTBFS:
```
dh_python3 -O--buildsystem=pybuild
Traceback (most recent call last):
File "/usr/bin/dh_python3", line 292, in
main()
File "/usr/bin/dh_python3", line 218, in main
fix_locations(package, interpreter, SUPPORTED, options)
File "/usr/share/dh-python/dhpython/fs.py", line 51, in fix_locations
share_files(srcdir, dstdir, interpreter, options)
File "/usr/share/dh-python/dhpython/fs.py", line 117, in share_files
share_files(fpath1, fpath2, interpreter, options)
File "/usr/share/dh-python/dhpython/fs.py", line 100, in share_files
os.remove(fpath1)
IsADirectoryError: [Errno 21] Is a directory:
'debian/reuse/usr/lib/python3.11/dist-packages/reuse-2.1.0.dist-info/LICENSES'
```
The following lines cause this bug:
```python3
if i.startswith(('LICENCE', 'LICENSE', 'COPYING', 'NOTICE', 'AUTHORS')):
os.remove(fpath1)
```
Instead of just blindly removing `fpath1`, it should be checked if this is a
file or a folder, and if it is a folder then `rmtree(fpath1)` should be called.
Alternatively a better file matching could be done (e.g. by checking the
filename before the file extension properly using pathlib).
Regards,
Stephan
[1]: https://salsa.debian.org/python-team/tools/dh-
python/-/commit/87907e588d1fc1ed52c5af4b9a7bded6327d
[2]: https://bugs.debian.org/1054750
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.9-x64v3-xanmod1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-python depends on:
ii python3 3.11.4-5+b1
ii python3-distutils 3.11.5-1
ii python3-setuptools 68.1.2-2
dh-python recommends no packages.
Versions of packages dh-python suggests:
ii dpkg-dev 1.22.0
pn flit
ii libdpkg-perl 1.22.0
pn python3-build
pn python3-installer
ii python3-wheel 0.41.2-1
-- no debconf information
Bug#1054621: lutris: new dependencies
The new dependencies are marked as hard dependencies from upstream, we just mirror their debian packaging with as little adjustments as possible. I unfortunately do not have the time to look into whether the dependencies are actually hard or not. If you have the time, feel free to open an issue upstream and resolve the issue there. Regards, Stephan
Bug#1053526: /etc/init.d/shiny-server without effect
Package: shiny-server Version: 1.5.20.1002-1 Dear Sirs and Madams, I just noticed by accident that in bookworm (12.1) with the versions mentioned above, "/etc/init.d/shiny-server start" or "/etc/init.d/shiny-server stop" are without any effect (silent and nothing happens). This can apparently be changed to work "normally" by replacing DAEMON=shiny-server ... with ... DAEMON=/usr/bin/shiny-server ... in /etc/init.d/shiny-server. At least for me it works; it seems to be related to this discussion: https://github.com/rstudio/shiny-server/issues/23 Best Stephan smime.p7s Description: Kryptografische S/MIME-Signatur
Bug#1052822: mini-buildd: FTBFS: make[1]: *** [debian/rules:11: override_dh_auto_build] Error 25
Hi Lucas, On Tue, 2023-09-26 at 14:43 +0200, Lucas Nussbaum wrote: > Source: mini-buildd > Version: 2.0.8 > Severity: serious (..) > During a rebuild of all packages in sid, your package failed to build > on amd64. (..) > Relevant part (hopefully): > > make[1]: Entering directory '/<>' (..) > > hostname: Name or service not known is ``hostname [-f]`` not working in the build environment? I see that ``m-b-self-signed-cerificate --help`` fails, which would add up. Also, 2.0.8 was a source-only upload and already 'got thru' previously. Hth! Stephan signature.asc Description: This is a digitally signed message part
Bug#1052459: mini-buildd: Problems with unnecessarily doubled slashes
Hi Magnus,
On Fri, 2023-09-22 at 15:37 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Version: 2.0.7~bpo12+1
>
> mini-buildd requires (in Archive.clean) that all archive URLs end in
> a slash.
> Yet it (always?) adds another slash before 'dists' (e.g.
> Archive.ReleaseFile(f"{archive.url}/dists/{self.codename}/") in
> Source.mbd_check). With behaving servers, this shouldn't be a
hmm yes, that's indeed unnecessary ;). Fix pending.
Thx!
Stephan
signature.asc
Description: This is a digitally signed message part
Bug#1052421: ITP: control -- Python Control Systems Library
Hi, please go with python-control for the source package name. This is required for consistency with https://repology.org/. Regards, Stephan On Fri, Sep 22, 2023 at 12:30 AM Kurva Prashanth wrote: > > On 2023-09-21 23:50, Christoph Biedl wrote: > > Kurva Prashanth wrote... > > > >> * Package name: control > >> Version : 0.9.4 > >> Upstream Author : >> > > >> * URL : http://python-control.org/ > > > > While I cannot judge whether this package is a sensible addition to > > Debian - I strongly ask you to re-consider the package name as "control" > > can apply to many different areas, and is therefore not helping when > > trying to figure if that package helps in a particular situation. > > Also, as there's the debian/control file in each source package, this > > will create some confusion and possibly even to users asking you for > > help with their packaging. > > > > Just from the above website, perhaps something like > > python-feedback-control-systems or a bit shorter variant would be more > > appropriate. I might be wrong. > > > > Christoph > I get what you're saying. Yes, "control" is a bit too general in deb > source packages. Your suggestion of "python-feedback-control-systems" > makes sense, and we'll I change package name. > > Regards, > Kurva Prashanth >
Bug#1050339: RFP: python-annotated-types -- metadata objects for python annotations
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org * Package name: python-annotated-types Version : 0.5.0 Upstream Contact: Zac Hatfield-Dodds * URL : https://github.com/annotated-types/annotated-types/ * License : MIT Programming Lang: Python Description : metadata objects for python annotations >From GitHub: PEP-593 added typing.Annotated as a way of adding context-specific metadata to existing types, and specifies that Annotated[T, x] should be treated as T by any tool or library without special logic for x. This package provides metadata objects which can be used to represent common constraints such as upper and lower bounds on scalar values and collection sizes, a Predicate marker for runtime checks, and descriptions of how we intend these metadata to be interpreted. In some cases, we also note alternative representations which do not require this package. Not really important to me, but python3-iminuit has a possible test case using this package.
Bug#1035506: please update libliftoff
Thanks, uploaded
Bug#1035921: postgresql-13-postgis-3: Inverted x-y-coordinates for EPSG:31466 when transforming coordinates since 3.1.1+dfsg-1+deb11u1
Package: postgresql-13-postgis-3
Version: 3.1.1+dfsg-1+deb11u1
Severity: important
Dear Maintainer,
after applying the minor update from 3.1.1+dfsg-1 to 3.1.1+dfsg-1+deb11u1 the
transformation
of coordinates for EPSG:31466 no longer works correctly, the values for x and
y are inverted which broke applications on a production server relying on the
correct order.
This behaviour was probably a unwanted side effect of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031392
The steps to reproduce this issue are:
- create a test "bullseye" system (e.g. in vagrant)
- ensure the system is up to date:
`sudo apt update && sudo apt upgrade`
- install Postgres with the PostGIS extensions:
`sudo apt install -y postgresql-13-postgis-3`
- create a test database:
`sudo -u postgres createdb -E UTF8 -T template0 test_db`
- create the PostGIS extension on the test database:
`sudo -u postgres psql -c "CREATE EXTENSION IF NOT EXISTS postgis;" test_db`
- start `psql` and transform a test point from epsg:3857 to epsg:31466
```
sudo -u postgres psql -d test_db
psql (13.10 (Debian 13.10-0+deb11u1))
Type "help" for help.
test_db=# select ST_AsEWKT(ST_Transform(ST_GeomFromEWKT('SRID=3857;POINT(730249
6518693)'), 31466));
st_asewkt
SRID=31466;POINT(5586868.886276492 2539841.4544491787)
(1 row)
```
The expected output as from
- PostgresQL 11 with PostGIS 2.5.1+dfsg-1 from Debian Sources
- PostgresQL 11 with PostGIS 2.5.5+dfsg-1.pgdg100+2 from PostgreSQL Sources
- PostgresQL 13 with PostGIS 3.1.1+dfsg-1 from Debian Sources
- PostgresQL 13 with PostGIS 3.3.2+dfsg-1.pgdg110+1 from PostgreSQL Sources
is:
```
sudo -u postgres psql -d test_db
psql (13.10 (Debian 13.10-1.pgdg110+1))
Type "help" for help.
[test_db] # select
ST_AsEWKT(ST_Transform(ST_GeomFromEWKT('SRID=3857;POINT(730249 6518693)'),
31466));
st_asewkt
SRID=31466;POINT(2539841.4544491787 5586868.886276492)
(1 row)
```
As one can see, the point values are inverted.
-- System Information:
Debian Release: 11.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
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 postgresql-13-postgis-3 depends on:
ii libc62.31-13+deb11u6
ii libgcc-s110.2.1-6
ii libgdal283.2.2+dfsg-2+deb11u2
ii libgeos-c1v5 3.9.0-1
ii libjson-c5 0.15-2
ii libpcre3 2:8.39-13
ii libproj197.2.1-1
ii libprotobuf-c1 1.3.3-1+b2
ii libsfcgal1 1.3.9-2
ii libstdc++6 10.2.1-6
ii libxml2 2.9.10+dfsg-6.7+deb11u4
ii postgresql-1313.10-0+deb11u1
ii postgresql-13-postgis-3-scripts 3.1.1+dfsg-1+deb11u1
postgresql-13-postgis-3 recommends no packages.
Versions of packages postgresql-13-postgis-3 suggests:
pn postgis
-- no debconf information
Bug#1031410: Closing p-u requests for fixes included in 11.7
Hi,
after further investigation this looks more like a bug in the backport.
At first I thought the change was about flipping x and y for all
coordinate systems except those containing "lat/lon", which did not make
much sense to me, but I would have been willing to accept this.
But apparently this flip is only in this PostGIS 3.1.1+dfsg-1+deb11u1
version, earlier and later PostGIS versions correctly return x as x and
y as y.
For this query:
SELECT
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry,
3857), 31466));
the following versions correctly return x=2539841,y=5586869:
- PostgresQL 11 with PostGIS 2.5.1+dfsg-1 from Debian Sources
- PostgresQL 11 with PostGIS 2.5.5+dfsg-1.pgdg100+2 from PostgreSQL Sources
- PostgresQL 13 with PostGIS 3.1.1+dfsg-1 from Debian Sources
- PostgresQL 13 with PostGIS 3.3.2+dfsg-1.pgdg110+1 from Debian Sources
Only
- PostgresQL 13 with PostGIS 3.1.1+dfsg-1+deb11u1 from Debian Sources
incorrectly returns x=5586869,y=2539841
Should I file another bug report for this?
Regards,
Stephan Großberndt
Bug#1031410: Closing p-u requests for fixes included in 11.7
Hi,
at our company we were quite surprised by this seemingly minor update
3.1.1+dfsg-1+deb11u1, because it completely broke an application: Due to
the change the x and y axis are now inverted when converting coordinates
to EPSG 31466:
Before (this output is from 11.19, but was like this on 13 before as well):
SELECT geometry,ST_AsGeoJSON(ST_Transform(ST_SetSRID(geometry, 3857),
31466)) FROM osm_car_sharing_node LIMIT 1;
geometry |
st_asgeojson
+
010120110F04F0844A1349264120ED527FE9DD5841 |
{"type":"Point","coordinates":[2539841.86185744,5586869.51937972]}
(1 row)
Now:
SELECT geometry, ST_AsGeoJSON(ST_Transform(ST_SetSRID(geometry, 3857),
31466)) FROM osm_car_sharing_node LIMIT 1;
-[ RECORD 1
]+--
geometry | 010120110F04F0844A1349264120ED527FE9DD5841
st_asgeojson |
{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[5586869.519378289,2539841.861857439]}
I understand the rationale for the change in general, but in my opinion
such a major change really should not be part of such a minor update.
Is there an option to fix this apart from changing all queries?
Regards,
Stephan Großberndt
Bug#1035506: New upstream version 0.4.0
On Thu, 4 May 2023 12:26:28 +0200 Guido =?iso-8859-1?Q?G=FCnther?= wrote: > There's a new upstream version 0.4.1 > > https://gitlab.freedesktop.org/emersion/libliftoff/-/tags/v0.4.1 > > Would be great to have that in experimental as current sway, wlroots > requires it. > Cheers, > -- Guido Hi Guido, unfortunately I'm massively overworked right now, so I will not upload anything before the freeze ends. But feel free to to update it yourself, the Salsa repo is here: https://salsa.debian.org/debian/libliftoff Should be straight forward. Cheers, Stephan
Bug#1035468: scummvm: Dart game in "Lost Files of Sherlock Holmes" is unplayable
Package: scummvm Version: 2.7.0+dfsg-1 Severity: normal Dear Maintainer, Game: The Lost Files of Sherlock Holmes - The Case of the Serrated Scalpel At the pub Moongate you have to defeat several persons in a dart game to get further information (this will lead to a dead end, but first time players won’t know that). Here is a picture of the dart game: https://www.giantbomb.com/a/uploads/square_medium/0/9408/714967-984238260_00.gif (at least a part of it). If you press the return key, the green line will start to grow to the horizontal position you want to have until you press the return key again. The same then goes for the vertical position. In newer scummvm versions the green line will grow so fast that you can’t really control the right stop positions anymore. So it is quite impossible to win the game. Everything else is working fine. It is working fine in scummvm version 2.5.0, but not in 2.6.0. I don’t know if this is the same problem, but I tried the game „Lands of Lore - The Throne of Chaos” with 2.7.0 (instead of Dosbox). Here everything that flies (arrows, attack spells) is moving much faster than in Dosbox. Everything else is working fine. Many greetings, Stephan Seitz -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (900, 'testing-security'), (900, 'stable-updates'), (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.1 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages scummvm depends on: ii liba52-0.7.4 0.7.4-20 ii libasound2 1.2.8-1+b1 ii libc6 2.36-9 ii libcurl3-gnutls7.88.1-9 ii libfaad2 2.10.1-1 ii libflac12 1.4.2+ds-2 ii libfluidsynth3 2.3.1-2 ii libfreetype6 2.12.1+dfsg-4 ii libfribidi01.0.8-2.1 ii libgif75.2.1-2.5 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libieee1284-3 0.2.11-14 ii libjpeg62-turbo1:2.1.5-2 ii libmad00.15.1b-10.1+b1 ii libmpeg2-4 0.5.1-9 ii libogg01.3.5-3 ii libpng16-161.6.39-2 ii libsdl2-2.0-0 2.26.4+dfsg-1 ii libsdl2-net-2.0-0 2.2.0+dfsg-2 ii libsndio7.01.9.0-0.3+b2 ii libspeechd20.11.4-2 ii libstdc++6 12.2.0-14 ii libtheora0 1.1.1+dfsg.1-16.1+b1 ii libvorbis0a1.3.7-1 ii libvorbisfile3 1.3.7-1 ii scummvm-data 2.7.0+dfsg-1 ii zlib1g 1:1.2.13.dfsg-1 scummvm recommends no packages. Versions of packages scummvm suggests: ii beneath-a-steel-sky 0.0372-8 pn drascula ii flight-of-the-amazon-queen 1.0.0-9 pn lure-of-the-temptress ii timidity2.14.0-8.1 -- no debconf information -- | Stephan SeitzE-Mail: s...@rootsland.net | |If your life was a horse, you'd have to shoot it.|
Bug#1034098: reportbug: gamemode needs policykit-1 as a dependency
Hi Safir, thanks for the report. Can you open a MR on Salsa with this change? https://salsa.debian.org/games-team/gamemode Regards, Stephan
Bug#1033519: debootstrap: Fails to bootstrap wheezy (please symlink script as 'archived', like squeeze)
Package: debootstrap Version: 1.0.128+nmu2 Severity: wishlist Dear Maintainer, wheezy is archived, but script (unlike, f.e. squeeze) still links to sid: --- ls -l /usr/share/debootstrap/scripts/wheezy /usr/share/debootstrap/scripts/squeeze lrwxrwxrwx 1 root root 4 Oct 19 00:49 /usr/share/debootstrap/scripts/squeeze -> etch lrwxrwxrwx 1 root root 3 Oct 19 00:49 /usr/share/debootstrap/scripts/wheezy -> sid --- [i.e., bootstrap w/o special parameters for mirror (archived) and key file (removed) will fail.] Please symlink wheezy like squeeze. Thx! Stephan -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages debootstrap depends on: ii wget 1.21.3-1+b2 Versions of packages debootstrap recommends: ii arch-test 0.20-1 ii debian-archive-keyring 2023.2 ii gnupg 2.2.40-1 Versions of packages debootstrap suggests: ii binutils 2.40-2 pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2020.06.17.1-1 ii xz-utils 5.4.1-0.2 ii zstd 1.5.4+dfsg2-5 -- no debconf information
Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.
Hi Safir, thanks for the details. However I'm not sure if this is related to GOverlay. Can you reproduce this with just `mangohud --dlsym glxgears`? Cheers, Stephan
Bug#1032486: goverlay: Please add libglu1-mesa as a runtime dependency.
Hi Safir, can you provide more details why libglu1-mesa is required by GOverlay? I don't see any hints for it upstream. Regards, Stephan
Bug#1030392: ITP: python-moddb -- python module to scrape the ModDB.com website
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: python-moddb Version : 0.8.1 Upstream Contact: Clement Julia * URL : https://github.com/ClementJ18/moddb/ * License : MIT Programming Lang: python Description : python module to scrape the ModDB.com website Dependency for upcoming lutris version. Will be maintained in Games Team.
Bug#1029969: ITP: clad -- automatic differentiation for C/C++
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: clad Version : 1.1 Upstream Contact: Vassil Vassilev * URL : https://github.com/vgvassilev/clad * License : LGPL-3.0 Programming Lang: C, C++ Description : automatic differentiation for C/C++ Clad enables automatic differentiation (AD) for C++. It is based on LLVM compiler infrastructure and is a plugin for Clang compiler. Clad is based on source code transformation. Given C++ source code of a mathematical function, it can automatically generate C++ code for computing derivatives of the function. It supports both forward-mode and reverse-mode AD. Clad has extensive coverage of modern C++ features and a robust fallback and recovery system in place. Will maintain in the science team. Feature for ROOT.
Bug#1017679: RM: llvm-toolchain-13 -- ROM; Limit the number of llvm versions
Please don't remove LLVM 13 - ROOT [1] finally updated to LLVM 13 [2]. This allows to build ROOT without the builtin LLVM copy, which dramatically reduces build time and also brings Debian packaging of ROOT a lot closer to reality. I consider ROOT to be quite an important package considering it is unavoidable in HEP and upstream is open to make changes so that ROOT can get an official Debian package. If LLVM 13 would be removed before ROOT makes a transition to a newer LLVM version this would make the packaging efforts mostly useless. Note that I don't care about trixie for now, just please don't remove it from unstable after the bookworm release. Cheers, Stephan [1]: https://bugs.debian.org/981113 [2]: https://github.com/root-project/root/pull/10294
Bug#967941: Bug appeared again
This bug appears back some time ago. For some months, video thumbnails failed to generate on multiple of my machines. Since then, I was trying to figure out the cause. It only seemed to affect h264, but not all videos were affected. I even had multiple videos saved from Youtube, some were generating thumbnails, others were not. I could not find any difference in the codec parameters. Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer worked to prevent this bug. Does this option have any downsides? Regards signature.asc Description: This is a digitally signed message part
Bug#1016722: cvmfs sponor
Hi Benda, sorry for the late reply, I just didn't have time to look into it. I am not able to build it from Salsa since I can't find the proper source tarball - [1] does not seem to work. Could you write a `debian/watch file` (see [2] for details) for easy downloading of the source tarball? Otherwise I think you should remove the unused externals in the `externals` folder - you can do this via `debian/copyright` (see e.g. [3], multiple lines allowd) Cheers, Stephan [1]: https://ecsft.cern.ch/dist/cvmfs/cvmfs-2.9.4/source.tar.gz [2]: https://manpages.debian.org/unstable/devscripts/uscan.1.en.html [3]: https://salsa.debian.org/science-team/root/-/blob/193bb0bd05fd2da77549a8938d79301ca70a7466/debian/copyright#L5
Bug#1028207: ITP: vkroots -- framework for writing Vulkan layers that takes all the complexity away
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org * Package name: vkroots Version : git Upstream Contact: Joshua Ashton * URL : https://github.com/Joshua-Ashton/vkroots * License : Apache-2.0 OR MIT Programming Lang: C++ Description : framework for writing Vulkan layers that takes all the complexity away Required for latest gamescope. Will be maintained under the Games Team.
Bug#1027669: RFP: jworldwindearth -- Java visual interface for NASA WorldWind SDK
Package: wnpp Severity: wishlist * Package name: jworldwindearth Version : 0.9.0 Upstream Contact: Name * URL : https://github.com/sbodmer/JWorldWindEarth * License : GPL Programming Lang: Java Description : Java visual interface for NASA WorldWind SDK Example implementation for the NASA Java WorldWind SDK. This project aims to be a "reference" app which shows all the available layers of the SDK in an easy and visual manner (sort of a Google Earth alternative). All layers writers are encouraged to integrate their work in this application so that we have a centralised app showing all the powerful features of the WorldWind SDK.
Bug#1026843: Not suitable for testing yet (due to outstanding migration tests)
Package: mini-buildd Version: 1.9.112 Severity: serious While working quite well already on a new setup, some crucial testing has not yet been fully done yet -- especially * migration tests (i.e., upgrading an existing installation from 1.0.x->2.0.x) * new 'setup' system's maintenance facilities I.e., I don't recommend upgrading production systems just yet, please wait for a proper 2.0.x release. Thanks! Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages mini-buildd depends on: ii adduser3.129 ii debconf [debconf-2.0] 1.5.80 ii debootstrap1.0.128+nmu2 ii devscripts 2.22.2 ii dirmngr2.2.40-1 ii dpkg-dev 1.21.13 ii gnupg 2.2.40-1 ii init-system-helpers1.65.2 ii python33.10.6-3 ii python3-mini-buildd1.9.112 ii python3-pyftpdlib 1.5.7-2 ii reprepro 5.3.1-1 ii sbuild 0.84.2 ii schroot1.6.13-3+b1 ii sudo 1.9.11p3-2 ii sysvinit-utils [lsb-base] 3.06-2 ii zstd 1.5.2+dfsg-1 Versions of packages mini-buildd recommends: ii arch-test0.19-1 ii autopkgtest 5.27 ii lintian 2.115.3 ii mini-buildd-doc 1.9.112 ii piuparts 1.1.5 ii python3-apt 2.5.0 Versions of packages mini-buildd suggests: ii binfmt-support 2.2.2-2 ii btrfs-progs 6.0.2-1 ii debian-archive-keyring 2021.1.1 ii haveged 1.9.14-1+b1 ii lvm22.03.16-2 ii openssl 3.0.7-1 ii qemu-user-static1:7.2+dfsg-1 ii ubuntu-keyring 2020.06.17.1-1 -- Configuration Files: /etc/default/mini-buildd changed [not included] /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: '/etc/sudoers.d/mini-buildd-sudoers' -- debconf information excluded
Bug#1026215: python3-openssl: Fails using deprecated SSL_CTX_set_ecdh_auto which ultimately has been removed w/ p-cryptography 38
Package: python3-openssl Version: 21.0.0-1 Severity: important Dear Maintainer, since p-cryptography 38 hit unstable, this fails somewhere here File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 674, in __init__ using SSL_CTX_set_ecdh_auto, which is deprecated w/ at least openssl3 afaiu, and python3-cryptography 38 seem to to have that binding now removed for good. Newest release versions of pyopenssl have this depcrecated call just removed, so maybe updating upstream is the way to go here. Hth, and thanks! Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages python3-openssl depends on: ii python3 3.10.6-3 ii python3-cryptography 38.0.4-1 ii python3-six 1.16.0-4 python3-openssl recommends no packages. Versions of packages python3-openssl suggests: pn python-openssl-doc pn python3-openssl-dbg -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/python3/dist-packages/OpenSSL/SSL.py (from python3-openssl package)
Bug#937049: mini-buildd: Python2 removal in sid/bullseye
Hi Bastian, On Tue, 2022-11-29 at 21:09 +0100, Bastian Germann wrote: > Why don't you move the experimental to unstable now? well, some crucial tests (especially on upgrading) are unfortunately still pending. Uploading to unstable always marked "ok to use" in that respect, however... > The unstable mini.buildd version is not usable but is now the last reverse > dependency of python-setuptools > (sphinx and nuitka only have it as optional alternatives). as it seems to cause big pain elsewhere, I will prepare the next upload (within "days" ;) for unstable (with a blocking RC bug if need be). Hth! S signature.asc Description: This is a digitally signed message part
Bug#1023945: Mozilla and Microsoft acted
Please note that Mozilla and Microsoft have removed the certificates now. It is probably now appropriate to follow Mozilla. Google's and Apple's reaction is still open. Regards signature.asc Description: This is a digitally signed message part
Bug#1024770: libpcsclite1: multi-arch installation not possible
Hello, > > libpcsclite-dev includes a Python 3 script: pcsc-spy. Hence the dependency on > python3. > Since it is a Recommends: and not a Depends: you should be able to install > libpcsclite-dev:arm64 even if the dependency is not satisfied. Ahh, that was the clue! apt install --no-install-recommends works as expected: apt install libpcsclite-dev:arm64 --no-install-recommends Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: libpcsclite1:arm64 Suggested packages: pcscd:arm64 Recommended packages: python3:arm64 The following NEW packages will be installed: libpcsclite-dev:arm64 libpcsclite1:arm64 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 135 kB of archives. After this operation, 312 kB of additional disk space will be used. Do you want to continue? [Y/n] > But you will then have another problem since libpcsclite-dev and > libpcsclite-dev:arm64 will both try to install the same files: > /usr/bin/pcsc-spy > /usr/include/PCSC/debuglog.h > /usr/include/PCSC/ifdhandler.h > /usr/include/PCSC/pcsclite.h > /usr/include/PCSC/reader.h > /usr/include/PCSC/winscard.h > /usr/include/PCSC/wintypes.h > /usr/share/man/man1/pcsc-spy.1.gz > > How do you propose to fix that? You fix it by not fixing it. It is already fixed. dpkg contains some magic that deals with it. AFAIK, as long as the files are binary-identical between multiple architectures of the same packages, no conflict will occur. Debian has some excellent multi-arch and cross compilation support! From https://wiki.debian.org/Multiarch/Implementation: > /!\ Note that any files in /usr/share or /etc must be byte-for-byte identical > across architectures, otherwise file conflicts will result! This means, in > particular, that any gzip-compressed files > must be compressed with -n to avoid embedded timestamps. This seems to extend to other files, too. To verify: dpkg -S /usr/include/PCSC/winscard.h libpcsclite-dev:armhf, libpcsclite-dev:i386, libpcsclite-dev:arm64, libpcsclite-dev:amd64: /usr/include/PCSC/winscard.h The Recommends: was a bit unexpected as I thought it was a Depends:, so this one is not really a bug. I was able to install the required packages now and compilation works :) This one is not really a bug then. Thanks a lot! -- Mit freundlichen Grüßen / Best regards Stephan Brunner Matrix: @boomer41:boomer41.net PGP: 5FB325E81E548282D458A65114A30C9CE3AE4CE2 signature.asc Description: This is a digitally signed message part
Bug#1024770: libpcsclite1: multi-arch installation not possible
Package: libpcsclite1 Version: 1.9.1-1 Severity: minor When trying to install libpcsclite-dev, and therefore libpcsclite1, via multi-arch (host is x86-64), e.g. apt install libpcsclite-dev libpcsclite-dev:arm64 , the installation would break the system. See the output below. I wanted to install this package to my build host, which does cross compilation for some architectures in an CI environment. I am using Debian 11 on x86-64. Latest updates installed as of 2022-11-24. Example output of the apt install example above: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: distro-info-data iso-codes libffi-dev libmpdec3 libncurses-dev libpfm4 libpython3-stdlib libpython3.9-minimal libpython3.9-stdlib libtinfo-dev libz3-dev llvm-11 llvm-11-runtime lsb-release python-apt-common python3-certifi python3-chardet python3-debconf python3-debian python3-httplib2 python3-idna python3-pkg-resources python3-pygments python3-requests python3-six python3-urllib3 Use 'apt autoremove' to remove them. The following additional packages will be installed: libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9- minimal:arm64 libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64 uuid-runtime zlib1g:arm64 Suggested packages: gpm:arm64 pcscd:arm64 python3-doc:arm64 python3-tk:arm64 python3-venv:arm64 python3.9-venv:arm64 python3.9-doc:arm64 binutils:arm64 The following packages will be REMOVED: apt-listchanges llvm-11-dev llvm-11-tools python3 python3-apt python3-debianbts python3-minimal python3-pycurl python3-pysimplesoap python3-reportbug python3-yaml python3.9 python3.9-minimal reportbug The following NEW packages will be installed: libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 libpcsclite-dev:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9-minimal:arm64 libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64 uuid-runtime zlib1g:arm64 0 upgraded, 24 newly installed, 14 to remove and 0 not upgraded. Need to get 8,185 kB of archives. After this operation, 202 MB disk space will be freed. Do you want to continue? [Y/n] ^C signature.asc Description: This is a digitally signed message part
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
This seems related: https://bugs.debian.org/1024701 Regards signature.asc Description: This is a digitally signed message part
Bug#1024701: libphonenumber8 update breaks evolution
From changelog: libphonenumber (8.12.57+ds-1+b1) sid; urgency=low, binary-only=yes * Binary-only non-maintainer upload for amd64; no source changes. * Rebuild against libicu72 -- amd64 / i386 Build Daemon (x86-csail-01) Wed, 09 Nov 2022 09:06:01 + signature.asc Description: This is a digitally signed message part
Bug#1024701: libphonenumber8 update breaks evolution
Evolution gives the following confusing error message. $ evolution evolution: symbol lookup error: /lib/x86_64-linux-gnu/libebook- contacts-1.2.so.4: undefined symbol: _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE However, libebook-contacts has not changed recently. Regards signature.asc Description: This is a digitally signed message part
Bug#1024701: libphonenumber8 update breaks evolution
Package: libphonenumber8 Version: 8.12.57+ds-1+b2 Severity: serious After updating libphonenumber8 from version 8.12.57+ds-1+b1 to version 8.12.57+ds-1+b2 in Debian Sid, Gnome Evolution fails to launch. Downgrading to the previous version (still in Bookworm) fixes the issue. Regards signature.asc Description: This is a digitally signed message part
Bug#1022900: fixed in linux 6.0.8-1
I am happy to confirm that with Linux kernel 6.0.8-1 in Debian Sid, the issue is fixed. Regards
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Yesterday, kernel 6.0.8 was released with a number of EFI fixes. I have compiled the vanilla kernel and I am happy to confirm that it solves the issue. Regards
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Update for completeness: The EFI patches have not made it into 6.0.7. As expected, 6.0.7 from Debian still has the problem. New EFI patches have been merged into master on November 4. I hope to find them in 6.0.8 or 6.1. Then I will test again. Regards
Bug#1023656: snmpd crashes while processing network interfaces
Package: snmpd Version: 5.9+dfsg-4+deb11u1 Severity: important Dear Maintainer, We have come across multiple situations in which snmpd would seemingly randomly crash on a large number of production systems, whereas only Debian 11 is affected. The root cause of this seems to be a race condition that is triggered when a network interface disappears during its processing. While this case may sound unlikely we have seen frequent crashes on systems running (short-lived) docker containers, which get veth network interfaces added and removed in short time frames. It turns out that this issue is known upstream ([0]) and fixed in 5.9.3 as available from Debian testing. A backport of net-snmp 5.9.3 to bullseye without any further adjustments fixed the issue for us and we have since been unable to reproduce the issue. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) [0] https://github.com/net-snmp/net-snmp/issues/107
Bug#1020595: marked as pending in tomlplusplus
On Mon, 7 Nov 2022 16:22:54 +0100 Bastian Germann wrote: > What is the status of this? Is Stephan still intending to sponsor > tomlplusplus? I currently lack time for Debian work. I would still do it before the freeze since I also need to upload some other things before that, but if you have the capacity please go ahead. Regards, Stephan
Bug#937049: mini-buildd: Python2 removal in sid/bullseye
Hi Moritz, On Fri, 2022-10-28 at 00:12 +0200, Moritz Mühlenhoff wrote: > Am Fri, Aug 30, 2019 at 07:26:40AM + schrieb Matthias Klose: > > Package: src:mini-buildd > > Version: 1.0.41 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > How close is the 2.x branch in experimental from being a replacement? > python2 will be dropped in bookworm and also removed from the archive. it's taking way too long already ;), but I am still quite confident to be able to upload to unstable this year, i.e., before Debian freeze/bookworm. Hth! S
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Some updates. linux-image-6.0.0-2-amd64 6.0.6-2 does not fix the bug. In the upstream bug, a new set of new patches were mentioned which should address this issue. I expect them to be merged into version 6.0.7. New patches regarding EFI: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=urgent I will not apply any patches manually but just wait for the coming releases instead. Anyone who has this issue right now can boot into kernel 5.19 as a workaround. Regards
Bug#1023164: ITP: libtomlplusplus -- TOML config file parser and serializer for C++17
Duplicate of #1020595 [1]. Cheers, Stephan [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020595
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Sice the latest vanilla kernel does not work, I have filed an upstream bug. https://bugzilla.kernel.org/show_bug.cgi?id=216640 Regards
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
For completeness: The problem persists with the new kernel in Sid. > 6.0.0-2-amd64 / Debian 6.0.5-1 (2022-10-28) x86_64 GNU/Linux
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Some more information: linux-image-5.19.0-2-amd64/now 5.19.11-1 (not affected) linux-image-6.0.0-1-amd64/now 6.0.2-1+b1 (affected) linux-image-6.0.0-2-amd64/unstable,now 6.0.3-1 (affected) linux-image-6.0.5/now 6.0.5-1 (custom vanilla kernel build, affected) Other relevant package versions (no recent changes): efibootmgr/unstable,now 17-1 efivar/unstable,now 37-6 libefivar1/unstable,now 37-6 grub-common/unstable,now 2.06-4 grub-efi-amd64/unstable,now 2.06-4 grub-efi-amd64-bin/unstable,now 2.06-4 grub-efi-amd64-signed/unstable,now 1+2.06+4 grub2-common/unstable,now 2.06-4 Feel free to ask for more information, logs or additional tests. Regards
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
I have now compiled and booted vanilla kernel 6.0.5. “efibootmgr -o” is not working. I double-checked that with kernel 5.19.11 (Debian), it is working fine. Regards
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
I have installed the package “linux-source”, applied the patch, compiled and booted it. The patch alone does not appear to fix the issue. (“efibootmgr -o” still not working.) Maybe I find time to try vanilla kernel 6.0.5 on the weekend. Regards Stephan
Bug#1022900: grub-install, efibootmgr etc. not working with new kernel
Package: src:linux Version: 6.0.3-1 When I boot with kernel 6.0.x, grub-install, efibootmgr etc. keep failing. With kernel 5.19.x it works on the same machine with the same userland. Hardware: MacBookPro11,1, Intel(R) Core(TM) i7-4578U CPU @ 3.00GHz I am not sure if this app is Apple specific. I recommend developers to test grub-install and efibootmgr on other hardware setups. grub-install: info: copying `/usr/lib/shim/shimx64.efi.signed' -> `/boot/efi/EFI/debian/shimx64.efi'. grub-install: info: copying `/usr/lib/grub/x86_64-efi- signed/grubx64.efi.signed' -> `/boot/efi/EFI/debian/grubx64.efi'. grub-install: info: copying `/usr/lib/shim/mmx64.efi.signed' -> `/boot/efi/EFI/debian/mmx64.efi'. grub-install: info: copying `/usr/lib/shim/fbx64.efi.signed' -> `/boot/efi/EFI/debian/fbx64.efi'. grub-install: info: copying `/usr/lib/shim/BOOTX64.CSV' -> `/boot/efi/EFI/debian/BOOTX64.CSV'. grub-install: info: copying `/boot/grub/x86_64-efi/load.cfg' -> `/boot/efi/EFI/debian/grub.cfg'. grub-install: info: Registering with EFI: distributor = `debian', path = `\EFI\debian\shimx64.efi', ESP at hostdisk//dev/sda,gpt1. grub-install: info: executing modprobe efivars 2>/dev/null. grub-install: info: setting EFI variable Boot. grub-install: warning: Cannot set EFI variable Boot. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Invalid argument. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Invalid argument. grub-install: error: failed to register the EFI boot entry: Invalid argument. Regards
Bug#312552: unrar-free: request for RAR 3.0 format support
On Wed, 13 Oct 2021 10:56:38 +0200 Bastian Germann wrote: > There is a new upstream version with RAR 3.0 and RAR 5.0 support via > libarchive. > A debdiff for that version is included. Does anyone plan to upload version >= 0.1.0? If not, I would be willing to do an NMU. Cheers, Stephan
Bug#1021912: Patch available
There is a patch available in the Arch community: https://github.com/archlinux/svntogit-community/blob/master/broadcom-wl-dkms/repos/community-x86_64/015-linux600.patch Quick and dirty solution until the patch is included in Debian (use at own risk): 1. Download 015-linux600.patch (raw file) 2. # cd /usr/src/broadcom-.../src/wl/sys/ 3. # patch wl_cfg80211_hybrid.c < /path/to/015-linux600.patch 4. # dpkg-reconfigure broadcom-sta-dkms Regards
Bug#1020294: reuse: rejects custom license name as invalid
Hi Ansgar, sorry for the late reply - this seems like an upstream issue to me, can you forward it please? [1] Cheers, Stephan PS: I've seen your mail about adding REUSE headers to other projects, really nice! I hope one day we can create d/copyright on the fly with REUSE... [1]: https://github.com/fsfe/reuse-tool/issues/new
Bug#1018459: Maintainer proposed patch to remove dep
Hi Felix, I'm terribly sorry that I didn't find the time to upload this earlier - I'm glad you found another sponsor. Please feel free to annoy me with pings in the future so that I don't forget things like this :) Cheers, Stephan
Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17
Hi Andrea, I find this library interesting as well, ping me if you need a sponsor. Cheers, Stephan On Sat, Sep 24, 2022 at 12:03 AM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > * Package name: tomlplusplus > Version : 3.2.0 > Upstream Author : Mark Gillard au> > * URL : https://marzer.github.io/tomlplusplus/ > * License : MIT/Expat > Programming Lang: C++ > Description : TOML config parser and serializer for C++17 > > Features: > - - Supports the latest TOML release (v1.0.0), plus optional support for > some > unreleased TOML features > - - Passes all tests in the toml-test suite > - - Supports serializing to JSON and YAML > - - Proper UTF-8 handling (incl. BOM) > - - C++17 (plus some C++20 features where available, e.g. experimental > support > for char8_t strings) > - - Doesn't require RTTI > - - Works with or without exceptions > - - Tested on Clang (6+), GCC (7+) and MSVC (VS2019) > - - Tested on x64, x86 and ARM > > I've used this library in the past, and I was surprised to find out that > it is > not available in Debian. > > > -BEGIN PGP SIGNATURE- > > iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYy4sExQcYW5kcmVhQHBh > cHBhY29kYS5pdAAKCRBKkgiiRVB3p7IMAP9BKJ8/B6nrKHvKzREXrz8n2nqxGRr5 > Yuc+QCCNtjOL0wD+IWVXon6q2S5n4SUSMqRzAWw0zJXc7OppfpTaKzk7cgQ= > =dCnP > -END PGP SIGNATURE- > >
Bug#1019961: ITP: fast-float -- Implementation of the C++ from_chars functions for float and double types
While short on time, I have a interest in rapidyml, so you can try to ping me. Also maybe ask Gürkan Myczko (CC). Regards, Stephan
Bug#1019716: cron: does not check for timezone changes except during DST events or init
Package: cron
Version: 3.0pl1-137
Severity: normal
Tags: patch
X-Debbugs-Cc: stephan.marc.garl...@gmail.com
Dear Maintainer,
Please see the writeup for this bug at:
https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8ed15e35b193d
In short, if the timezone for a system is changed while cron is running,
and the timezone change is _not_ due to a DST event, cron is unaware of
the change and will continue using the old `GMToff` value until it is
restarted.
While this seems like a bizarre edge case, and it is, it happened to me
via moving, booting up my server rack, realizing the timezone needed to
be modified, and then not restarting the server. I noticed afterwards
that a daily cronjob I have ran one hour late.
The supplied patch fixes this, although I am cognizant of the fact that
this may be intended behavior. I'm willing to modify it to include an
optional flag (default: false) to set this behavior.
-- Package-specific info:
--- EDITOR:
--- /usr/bin/editor:
/usr/bin/nvim
--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab
--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Dec 23 2021 /var/spool/cron
--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Sep 11 15:53 /var/spool/cron/crontabs
--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Sep 11 21:13 /etc/cron.d
--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Sep 11 06:34 /etc/cron.daily
--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.hourly
--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.monthly
--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.weekly
-- System Information:
Debian Release: 11.5
APT prefers stable
APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500,
'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
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 cron depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii init-system-helpers 1.60
ii libc62.31-13+deb11u4
ii libpam-runtime 1.4.0-9+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii lsb-base 11.1.0
ii sensible-utils 0.0.14
Versions of packages cron recommends:
pn default-mta | mail-transport-agent
Versions of packages cron suggests:
pn anacron
pn checksecurity
ii logrotate 3.18.0-2+deb11u1
Versions of packages cron is related to:
pn libnss-ldap
pn libnss-ldapd
pn libpam-ldap
pn libpam-mount
pn nis
pn nscd
-- no debconf information
diff --git a/cron.c b/cron.c
index 613e7bf..7b0b69c 100644
--- a/cron.c
+++ b/cron.c
@@ -372,9 +372,9 @@ set_time(int initialize)
/* We adjust the time to GMT so we can catch DST changes. */
tm = *localtime();
+GMToff = get_gmtoff(, );
if (initialize || tm.tm_isdst != isdst) {
isdst = tm.tm_isdst;
- GMToff = get_gmtoff(, );
Debug(DSCH, ("[%d] GMToff=%ld\n",
getpid(), (long)GMToff))
}
Bug#1019487: libembree-dev should depend on libtbb-dev
Package: libembree-dev Version: 3.13.4+dfsg-1 Severity: important Tags: patch X-Debbugs-Cc: stephanlach...@debian.org During a rebuild of VecGeom, I noticed that it fails from Embree: ``` CMake Error at /usr/lib/x86_64-linux-gnu/cmake/embree-3.13.4/embree- config.cmake:53 (FIND_PACKAGE): By not providing "FindTBB.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "TBB", but CMake did not find one. Could not find a package configuration file provided by "TBB" with any of the following names: TBBConfig.cmake tbb-config.cmake Add the installation prefix of "TBB" to CMAKE_PREFIX_PATH or set "TBB_DIR" to a directory containing one of the above files. If "TBB" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:388 (find_package) -- Configuring incomplete, errors occurred! ``` This can be simply fixed by adding libtbb-dev to the build dependencies. However, this dependency should be added to libembree-dev. Cheers, Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libembree-dev depends on: ii libembree3-3 3.13.4+dfsg-1 libembree-dev recommends no packages. Versions of packages libembree-dev suggests: pn embree-tools -- no debconf information
Bug#1017716: ITP: muon-meson -- Meson-compatible build system
Hi Andrea, I would ofc sponsor this when it is ready to upload. Wrt to the executable name: have you talked to upstream yet? I'm sure Debian isn't the only distro that has the muon problem, and I'm sure the maintainer would not like to see this program having different names on different distros. Maybe it also makes sense to talk to upstream KDE if they might consider renaming the executable (even though it is dead, I think everyone could tag a minor release with such a change). I think we should definitely avoid that muon has a non-standard binary name. It is used e.g. as meson build files formatter in certain IDE extensions, and they will not be aware of this. Regards, Stephan On Fri, Aug 19, 2022 at 2:00 PM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: muon-meson > Version : git HEAD > Upstream Author : Stone Tickle > * URL : https://muon.build > * License : GPL-3.0 > Programming Lang: C > Description : Meson-compatible build system > > muon is an implementation of the Meson build system in c99 with > minimal dependencies. > . > It uses libpkgconf for dependency discovery, and is close to > feature-complete with the core of Meson for C and C++. > > While still not "stable", muon is capable of compiling quite complex C and > C++ > projects, and being written in C99 it can greatly help with > bootstrappability > when compared to Meson's dependency on a Python interpreter and standard > library. > > The upstream name is "muon", but this package and /usr/bin/ name is already > used by KDE Muon, a [dead] synaptic alternative. > > I'm not sure how to handle this conflict; naming the Debian package "muon- > meson" or "muon-build" seems fine, but renaming the "muon" binary might be > less > desirable. > > [dead]: https://www.reddit.com/r/kde/comments/wrnuq3/is_muon_dead/ > >
Bug#1018223: ITP: zarchive -- Library for creating and reading zstd-compressed file archives
Hi Andrea, I would love to see cemu in Debian, so I'll gladly sponsor zarchive and cemu once you think it is ready to review. Regards, Stephan On Sat, Aug 27, 2022 at 1:00 PM Andrea Pappacoda wrote: > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: zarchive > Version : 0.1.1 > Upstream Author : Exzap > * URL : https://github.com/Exzap/ZArchive > * License : MIT-0 > Programming Lang: C++ > Description : Library for creating and reading zstd-compressed file > archives > > ZArchive is yet another file archive format. Think of zip, tar, 7z, etc. > but > with the requirement of allowing random-access reads and supporting > compression. > > This is a dependency of cemu, see #1018037 > >
Bug#1018459: Maintainer proposed patch to remove dep
Hi Felix, Thank you for quickly taking care of this, please ping me again when the new version is ready to upload. Cheers, Stephan On Tue, Aug 30, 2022 at 7:24 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi, > > > > I just got into contact with the upstream maintainer. > He already proposed a patch to remove this dependency and is willing to > cut a new release after we tested this. > > Then I’ll bump the version and close the bug (via Stephan). > > > > [1] https://github.com/purcell/airspeed/issues/59 > > -- > > Siemens AG, Linux Expert Center > Otto-Hahn-Ring 6, 81739 München, Germany > > >
Bug#1017594: cppzmq-dev: missing Replaces
As per policy: > This usage of Replaces only takes effect when both packages are at > least partially on the system at once. It is not relevant if the > packages conflict unless the conflict has been overridden. If I get this paragraph right, this will never happen since cppzmq breaks zeromq3 << 4.3.4-3 anyway and a) zeromq3 has no dependency on cppzmq at all b) cppzmq is in a different source package, so dpkg will upgrade zeromq3 and then install cppzmq At least I had no installation problems. Let me know if I got this wrong. Regards, Stephan
Bug#1017432: horizon-eda: zmq.hpp now in cppzmq-dev
Source: horizon-eda Version: 2.2.0-1 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: stephanlach...@debian.org The zmq.hpp header moved from libzmq3-dev to cppzmq-dev. To fix this just replace libzmq3-dev with cppzmq-dev in d/control. Regards, Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, ah ok, I thought maybe you just missed the mail. Anyway, of course I can ping users of the headers as I introduced the new package. Regards, Stephan On Mon, Aug 15, 2022 at 6:51 PM László Böszörményi (GCS) wrote: > Hi Stephan, > > On Mon, Aug 15, 2022 at 5:27 PM Stephan Lachnit > wrote: > > Sorry to annoy you, but please upload a new version of zeromq3, without > it cppzmq is uninstallable. > Wanted to ping users of those header files to update their build > dependencies. But then please do it yourself as you ship those files > now. > > Regards, > Laszlo/GCS >
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, Sorry to annoy you, but please upload a new version of zeromq3, without it cppzmq is uninstallable. Regards, Stephan
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi Laszlo, cppzmq was accepted [1], so you can proceed with uploading zeromq3. Cheers and thanks for maintaining zeromq, Stephan [1] https://tracker.debian.org/pkg/cppzmq
Bug#1016722: ITP: cvmfs -- The CernVM File System
Hi, that would be very useful to have indeed! I looked at this very briefly and figured it is probably not trivial to package, so good luck. Let me know if you need a sponsor or any other help for this. Cheers, Stephan On Sat, Aug 6, 2022 at 8:18 AM Yachen Wang wrote: > Package: wnpp > Severity: wishlist > Owner: Yachen Wang > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: cvmfs > Version : 2.9.4 > Upstream Author : CernVM Administrator (cvmadmin) < > cernvm.administra...@cern.ch> > * URL : https://github.com/cvmfs/cvmfs > * License : BSD 3-Clause, MIT, CC0-1.0, Apache-2.0 > Programming Lang: C++, Go > Description : The CernVM File System > > The CernVM File System provides a scalable, reliable and low-maintenance > software distribution service. It was developed to assist High Energy > Physics (HEP) collaborations to deploy software on the > worldwide-distributed computing infrastructure used to run data processing > applications. > > Although cvmfs is already packaged by cern, it will be more convenient > to deploy related software if distributed by Debian. > >
Bug#1016470: RFP: muon-meson -- an implementation of the meson build system
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org * Package name: muon-meson Version : any Upstream Author : https://git.sr.ht/~lattis/ * URL : https://muon.build/ * License : GPL v3 Programming Lang: C99 Description : an implementation of the meson build system muon is an implementation of the meson build system in c99 with minimal dependencies. It is interesting because it has some features that meson does not: - muon analyze - a static analyzer for meson.build files. Capable of doing type inference, checking unused variables, undeclared variables, etc. - muon fmt_unstable - a meson.build code formatter - An interactive stepping debugger with the dbg() function. muon is close to feature-complete with the core of meson for C and C++ (but still in early development IMHO). I think it should be fairly easy to package due to using meson and the minimal dependencies, but I won't put the time into packaging it (yet).
Bug#972785: zeromq3: Include cmake files for cppzmq
Hi, I want to tackle this issue again - I really want to package cppzmq as a separate package. Besides the already mentioned reason for not needing to patch downstream build systems, there is also the advantage that you can actually see from apt which version of cppzmq is in Debian. Also, I added pkg-config support. While yes, cppzmq is header only and you don't __need__ a pkg-config lookup, it is much simpler to just add `dependency(cppzmq)` than to check for the headers and depend on libzmq. Additionally I have added an autopkgtest, which is a nice bonus. Anyway, the change is relatively easy: I already have the packaging done in Salsa [1] and filled an ITP [2]. As I am a DD I can upload and maintain it, the only thing I need from you Laszlo is to remove zmq.hpp and zmq_addon.hpp from the binary package and add cppzmq in Suggests (which should be very low effort). I think it is also a good idea to write a NEWS entry so that users will know about the change, though I think this is not that important if you don't want to put in that much effort. To do the migration, I would first put cppzmq in NEW (after your ok), and after it has been accepted in NEW you would upload the new version of zeromq3. Overall I think the transition will be less painful than patching build systems downstream (and annoying Debian users that write software using the CMake files). [1]: https://salsa.debian.org/debian/cppzmq [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016347
Bug#1016347: ITP: cppzmq -- C++ bindings for libzmq (headers)
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org, gor...@chronitis.net, g...@debian.org * Package name: cppzmq Version : 4.8.1 Upstream Author : Gudmundur Adalsteinsson * URL : https://github.com/zeromq/cppzmq * License : MIT Programming Lang: C++ Description : C++ bindings for libzmq (headers) This package constains the default C++ headers for libzmq. The two headers (zmq.hpp and zmq_addon.hpp) are currently already contained in libzmq3-dev (src:zeromq3). However, the package does not provide the CMake packaging scripts. Also, there is a pending pull request to add a pkg-config file, so it makes sense to split this into a separate package. There was already an discussion to separate the headers in #972785 [2], but nothing happened from there. The packaging is done at https://salsa.debian.org/debian/cppzmq. [1]: https://github.com/zeromq/cppzmq/pull/564 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972785
Bug#989085: ITP: gamescope -- micro-compositor for games
Update: packaging is now available at https://salsa.debian.org/games-team/gamescope. Almost done, I will probably upload it next week :) Cheers, Stephan
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Uploaded as well! (Comment on shtab ITP applies here as well) Cheers, Stephan On Mon, Jul 4, 2022 at 12:30 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi Stephan, > > > > Thanks for the review. I changed the name of the package, renamed the > project on salsa and cut the release. > > This one should be ready to be uploaded. > > > > Happy Coding! > > Felix > > > > *From:* Stephan Lachnit > *Sent:* Sunday, July 3, 2022 11:43 AM > *To:* Moessbauer, Felix (T CED SES-DE) > *Cc:* 1013...@bugs.debian.org > *Subject:* Re: Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful > templating engine compatible with Velocity for Java > > > > Hi Felix, > > > > Looking good as well. Please also rename the source to python-airspeed and > do a dch -r, then I'll upload. > > > > Cheers, > > Stephan > > > > On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit > wrote: > > Hi Felix, > > > > If there is nobody else, I can sponsor this as well. Will try to find some > time on Sunday to review your work :) > > > > Cheers, > > Stephan > > > > On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > > Dear maintainers, > > the initial packaging for python3-airspeed is now ready at [1] and has a > green salsa CI. > It should be ready for a review. > > @Stephan: Would you like to sponsor this package as well? > > [1] https://salsa.debian.org/python-team/packages/airspeed > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fairspeed=05%7C01%7Cfelix.moessbauer%40siemens.com%7C12c8e91803f2425eac3408da5cd8728d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924381944910507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hIHf6BGVN6PYFT%2FBhgmHAl5ksLaKuKxjMC%2BPTfYIOoA%3D=0> > > Best regards, > Felix Moessbauer > Siemens AG > >
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Thanks, uploaded! FYI: you might be interested in running lintian with `lintian --pedantic -I -E`, there are some optional things that are relatively easy to fix (but none are important if you lack the time). Also, you might want to add the Debian CI running pytest, it is really easy: https://salsa.debian.org/python-team/packages/python-headerparser/-/blob/debian/latest/debian/tests/pytest. Again not really important, you can also just do it when there is a new release. Cheers, Stephan On Mon, Jul 4, 2022 at 12:32 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Hi Stephan, > > > > Thanks for the review. I changed the name of the package, renamed the > project on salsa and cut the release. > > This one should be ready to be uploaded. > > > > PS: Looks like the repology site currently has some TLS issues. > > > > Happy Coding! > > Felix > > > > *From:* Stephan Lachnit > *Sent:* Sunday, July 3, 2022 11:35 AM > *To:* Moessbauer, Felix (T CED SES-DE) > *Cc:* 1012...@bugs.debian.org > *Subject:* Re: ITP: shtab -- generator for shell tab completion files for > python projects > > > > Hi Felix, > > > > The package is looking good so far, I only request one change, namely > renaming the source package from shtab to python-shtab. The reason for this > prefix is that else repology.org > <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frepology.org%2F=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LzOv7h88VjrbLZ6L%2B32Jc0CL8PIM4xCNU68LQAWJeC8%3D=0> > won't be able to map the package automatically. > > > > Cheers, > > Stephan > > > > On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit > wrote: > > Hi Felix, > > > > I will take a look at the package sometime next week. I'm currently > packing my stuff to move to Geneva, so I don't really have that much time > right now. Feel free to ping though in case I forget :) > > > > Cheers, > > Stephan > > > > On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > > Dear maintainers, > > the initial packaging of shtab is implemented in [1] and should be ready > for a review. > > @stephan It would be great if you could sponsor this package. > We talked about that at Debian Reunion Hamburg. > > [1] https://salsa.debian.org/python-team/packages/shtab > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fpython-team%2Fpackages%2Fshtab=05%7C01%7Cfelix.moessbauer%40siemens.com%7C4fc331a448bf41d9ddef08da5cd74b31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637924377004473576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IJNiSmE%2BPaFs4RfhI9SftWKZkaL2lD4StdeaDTXO6iE%3D=0> > > Best regards, > Felix Moessbauer > Siemens AG > >
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Felix, Looking good as well. Please also rename the source to python-airspeed and do a dch -r, then I'll upload. Cheers, Stephan On Thu, Jun 30, 2022 at 9:19 AM Stephan Lachnit wrote: > Hi Felix, > > If there is nobody else, I can sponsor this as well. Will try to find some > time on Sunday to review your work :) > > Cheers, > Stephan > > On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > >> Dear maintainers, >> >> the initial packaging for python3-airspeed is now ready at [1] and has a >> green salsa CI. >> It should be ready for a review. >> >> @Stephan: Would you like to sponsor this package as well? >> >> [1] https://salsa.debian.org/python-team/packages/airspeed >> >> Best regards, >> Felix Moessbauer >> Siemens AG >> >
Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects
Hi Felix, The package is looking good so far, I only request one change, namely renaming the source package from shtab to python-shtab. The reason for this prefix is that else repology.org won't be able to map the package automatically. Cheers, Stephan On Wed, Jun 22, 2022 at 9:25 PM Stephan Lachnit wrote: > Hi Felix, > > I will take a look at the package sometime next week. I'm currently > packing my stuff to move to Geneva, so I don't really have that much time > right now. Feel free to ping though in case I forget :) > > Cheers, > Stephan > > On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix < > felix.moessba...@siemens.com> wrote: > >> Dear maintainers, >> >> the initial packaging of shtab is implemented in [1] and should be ready >> for a review. >> >> @stephan It would be great if you could sponsor this package. >> We talked about that at Debian Reunion Hamburg. >> >> [1] https://salsa.debian.org/python-team/packages/shtab >> >> Best regards, >> Felix Moessbauer >> Siemens AG >> >
Bug#1007742: ITP: solo2 -- command line interface for SoloKeys Solo 2 security key
Thanks for the update! I'm a bit limited with free time, but I've done Rust packaging before, so maybe I'll take a look at one of those when I have time. So updates on the ITP would be welcome :) Regards and thanks for your work, Stephan On Sun, Jul 3, 2022 at 11:19 AM Philip Rinn wrote: > Hi Stephan, > > On 03.07.22 at 11:07, Stephan Lachnit wrote: > > I would love to sponsor this. Are there any updates on packaging? Your > > Salsa repository is empty. > > great. I'm currently packaging the enormous amount of dependencies. I do > this with the rust team, so sponsoring it not an issue at the moment. > > The approximate dependency tree which I try to package is > > solo2 v0.2.0 > ├── anyhow v1.0.58 (in debian) > > ├── atty v0.2.14 (in debian) > > ├── chrono v0.4.19 (in debian) > > ├── clap v3.2.5 (in debian) > > ├── clap_complete v3.2.1 (in debian) > > ├── ctrlc v3.2.2 (in debian) > > ├── data-encoding v2.3.2 (in debian) > > ├── dialoguer v0.9.0 > > │ ├── console v0.15.0 > > │ │ ├── libc v0.2.126 (in debian) > > │ │ ├── once_cell v1.12.0 (in debian) > > │ │ ├── regex v1.5.6 (in debian) > > │ │ ├── terminal_size v0.1.17 (in debian) > > │ │ └── unicode-width v0.1.9 (in debian) > > │ ├── lazy_static v1.4.0 (in debian) > > │ ├── tempfile v3.3.0 (in debian) > > │ └── zeroize v1.4.3 (in debian) > > ├── flexiber v0.1.0 > > │ └── delog v0.1.4 > > │ └── log v0.4.17 (in debian) > > ├── getrandom v0.2.7 (in debian) > > ├── hex v0.4.3 (in debian) > > ├── hex-literal v0.3.4 (in debian) > > ├── hidapi v1.4.1 > > │ └── libc v0.2.126 (in debian) > > │ [build-dependencies] > > │ ├── cc v1.0.73 (in debian) > > │ └── pkg-config v0.3.25 (in debian) > > ├── indicatif v0.16.2 (in debian) > > ├── iso7816 v0.1.0 > > │ ├── delog v0.1.4 > > │ │ └── log v0.4.17 (in debian) > > │ └── heapless v0.7.14 > > │ ├── hash32 v0.2.1 > > │ │ └── byteorder v1.4.3 (in debian) > > │ ├── spin v0.9.3 > > │ │ └── lock_api v0.4.7 (in debian) > > │ └── stable_deref_trait v1.2.0 (in debian) > > │ [build-dependencies] > > │ └── rustc_version v0.4.0 (in debian) > > ├── lazy_static v1.4.0 (in debian) > > ├── log v0.4.17 (in debian) > > ├── lpc55 v0.1.1 > > │ ├── aes v0.7.5 > > │ │ ├── cfg-if v1.0.0 (in debian) > > │ │ ├── cipher v0.3.0 > > │ │ │ └── generic-array v0.14.5 (in debian) > > │ │ ├── cpufeatures v0.2.2 (in debian) > > │ │ └── opaque-debug v0.3.0 (in debian) > > │ ├── anyhow v1.0.58 (in debian) > > │ ├── atty v0.2.14 (in debian) > > │ ├── base64 v0.13.0 (in debian) > > │ ├── bitflags v1.3.2 (in debian) > > │ ├── chrono v0.4.19 (in debian) > > │ ├── clap v3.2.5 (in debian) > > │ ├── ctr v0.8.0 > > │ │ └── cipher v0.3.0 > > │ │ └── generic-array v0.14.5 (in debian) > > │ ├── delog v0.1.4 > > │ │ └── log v0.4.17 (in debian) > > │ ├── enum-iterator v0.7.0 > > │ │ └── enum-iterator-derive v0.7.0 > > │ │ ├── proc-macro2 v1.0.40 (in debian) > > │ │ ├── quote v1.0.20 (in debian) > > │ │ └── syn v1.0.98 (in debian) > > │ ├── hex v0.4.3 (in debian) > > │ ├── hidapi v1.4.1 > > │ │ └── libc v0.2.126 (in debian) > > │ │ [build-dependencies] > > │ │ ├── cc v1.0.73 (in debian) > > │ │ └── pkg-config v0.3.25 (in debian) > > │ ├── hmac v0.12.1 (in debian) > > │ ├── indicatif v0.16.2 (in debian) > > │ ├── lazy_static v1.4.0 (in debian) > > │ ├── log v0.4.17 (in debian) > > │ ├── nom v7.1.1 (in debian) > > │ ├── oid-registry v0.2.0 > > │ │ └── der-parser v6.0.1 (in debian) > > │ ├── pem-parser v0.1.1 > > │ │ ├── regex v1.5.6 (in debian) > > │ │ └── rustc-serialize v0.3.24 (in debian) > > │ ├── pkcs11 v0.5.0 > > │ │ ├── libloading v0.5.2 > > │ │ │ [build-dependencies] > > │ │ │ └── cc v1.0.73 (in debian) > > │ │ └── num-bigint v0.2.6 > > │ │ ├── num-integer v0.1.45 (in debian) > > │ │ └── num-traits v0.2.15 (in debian) > > │ │ [build-dependencies] > > │ │ └── autocfg v1.1.0 (in debian) > > │ ├── pkcs11-uri v0.1.3 > > │ │ ├── anyhow v1.0.58 (in debian) > > │ │ ├── log v0.4.17 (in debian) > > │ │ ├── percent-encoding v2.1.0 (in debian) > > │ │ ├── pkcs11 v0.5.0 > > │ │ │ ├── libloading v0.5.2 > > │ │ │ │ [build-dependencies] > > │ │
Bug#1007742: ITP: solo2 -- command line interface for SoloKeys Solo 2 security key
Hi Philip, I would love to sponsor this. Are there any updates on packaging? Your Salsa repository is empty. Cheers, Stephan
Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java
Hi Felix, If there is nobody else, I can sponsor this as well. Will try to find some time on Sunday to review your work :) Cheers, Stephan On Wed, Jun 29, 2022 at 4:53 PM Moessbauer, Felix < felix.moessba...@siemens.com> wrote: > Dear maintainers, > > the initial packaging for python3-airspeed is now ready at [1] and has a > green salsa CI. > It should be ready for a review. > > @Stephan: Would you like to sponsor this package as well? > > [1] https://salsa.debian.org/python-team/packages/airspeed > > Best regards, > Felix Moessbauer > Siemens AG >
