Bug#1068464: deal.ii: FTBFS: libgmp not linked, libdeal.ii.g.so.9.5.1: error: undefined reference to '__gmpn_neg'
Control: tags -1 unreproducible Control: close -1 Hi Drew, I've rebuilt deal.ii in the course of the opencascade transition, and I cannot reproduce this FTBFS; petsc 3.20 is now in unstable too, and the binNMU has been done ~4 days ago, also without the failure you've seen. Buildds works too... Therefore, I'm closing this bug as non-reproducible. (it can be reopened of course if it reappears.) -- tobi
Bug#1070377: frr: CVE-2024-34088
Control: tags -1 fixed-upstream Control: forwarded -1 https://github.com/FRRouting/frr/pull/15674 Upstream has merged a fix.
Bug#1071473: transition: opencascade
Hi Emilio, thanks for the head up! opencascade is now in unstable and has built for all archs except riscv64, where the buildds are just busy right now and as they are currently building huge packages, this could last a few days. I think a strategic Dep-Wait will help :) Level2 : - f3d and kicad could use a binNMU, with a Dep-Wait on libocct-data-exchange-dev (>= 7.8.1) - freecad, netgen has been (team) uploaded. - horizon-eda and slic3r-prusa are both in DELAYED/2. Level3 : - gmsh has been team uploaded. Level4: - deal.ii will be team-uploaded soon. Thanks! -- tobi On Wed, May 22, 2024 at 08:50:35AM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 19/05/2024 23:08, Tobias Frost wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: opencasc...@packages.debian.org > > Control: affects -1 + src:opencascade > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: block 1071284 by -1 > > Control: block 1071223 by -1 > > Control: block 1071470 by -1 > > Control: block 1071451 by -1 > > Control: block 1071471 by -1 > > > > Hi Release team, > > > > opencascade has a new release with breaking ABI, upstream versionied them as > > 7.8. The transition tracker [1] correctly picked it up already after the > > upload > > to experimental. > > > > [1] https://release.debian.org/transitions/html/auto-opencascade.html > > > > building the reverse depenencies most FTBFS due to library naming changes, > > but I was able to come up with patches for most, but they will require > > sourceful > > uploads. Freecad will require either backporting the upstream fixes or > > package > > a new upstream snapshot. > > > > This is the result of the compilation tests: > > > > Dependency level 2: > > > > f3d ✔ > > freecad (sid only) FTBFS, fixed in upstream git. > > horizon-eda patch available, #1071284 > > kicad ✔ > > netgen patch available, #1071223 > > slic3r-prusa (sid only) patch available, #1071470 > > > > Dependency level 3: > > gmshpatch available, #1071451 > > > > Dependency level 4: > > deal.ii patch available, #1071471 > > Will you help upload those fixes? Perhaps through delayed NMUs or team > uploads? If so, go ahead. > > Cheers, > Emilio signature.asc Description: PGP signature
Bug#1071470: slic3r-prusa: diff for NMU version 2.7.4+dfsg-1.1
Control: tags 1071470 + pending Dear maintainer, I've prepared an NMU for slic3r-prusa (versioned as 2.7.4+dfsg-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru slic3r-prusa-2.7.4+dfsg/debian/changelog slic3r-prusa-2.7.4+dfsg/debian/changelog --- slic3r-prusa-2.7.4+dfsg/debian/changelog 2024-04-18 07:26:21.0 +0200 +++ slic3r-prusa-2.7.4+dfsg/debian/changelog 2024-05-24 22:12:57.0 +0200 @@ -1,3 +1,11 @@ +slic3r-prusa (2.7.4+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with opencasacade 7.8.1 (Closes: #1071470) and +add a versioned B-D on it. + + -- Tobias Frost Fri, 24 May 2024 22:12:57 +0200 + slic3r-prusa (2.7.4+dfsg-1) unstable; urgency=medium * [3cddded] New upstream version 2.7.4+dfsg diff -Nru slic3r-prusa-2.7.4+dfsg/debian/control slic3r-prusa-2.7.4+dfsg/debian/control --- slic3r-prusa-2.7.4+dfsg/debian/control 2024-04-18 07:26:21.0 +0200 +++ slic3r-prusa-2.7.4+dfsg/debian/control 2024-05-24 22:12:57.0 +0200 @@ -20,11 +20,11 @@ libheatshrink-dev, libnanosvg-dev, libnlopt-cxx-dev | libnlopt-dev (<< 2.4.2+dfsg-5~), - libocct-data-exchange-dev, - libocct-draw-dev, - libocct-foundation-dev, - libocct-modeling-algorithms-dev, - libocct-visualization-dev, + libocct-data-exchange-dev (>=7.8.1+dfsg1), + libocct-draw-dev (>=7.8.1+dfsg1), + libocct-foundation-dev (>=7.8.1+dfsg1), + libocct-modeling-algorithms-dev (>=7.8.1+dfsg1), + libocct-visualization-dev (>=7.8.1+dfsg1), libopenvdb-dev (>= 5.0), libopenvdb-tools, libpng-dev, diff -Nru slic3r-prusa-2.7.4+dfsg/debian/patches/occt-7.8.patch slic3r-prusa-2.7.4+dfsg/debian/patches/occt-7.8.patch --- slic3r-prusa-2.7.4+dfsg/debian/patches/occt-7.8.patch 1970-01-01 01:00:00.0 +0100 +++ slic3r-prusa-2.7.4+dfsg/debian/patches/occt-7.8.patch 2024-05-24 22:12:57.0 +0200 @@ -0,0 +1,18 @@ +diff --git a/src/occt_wrapper/CMakeLists.txt b/src/occt_wrapper/CMakeLists.txt +index d8dd8e1..d27055f 100644 +--- a/src/occt_wrapper/CMakeLists.txt b/src/occt_wrapper/CMakeLists.txt +@@ -22,11 +22,8 @@ generate_export_header(OCCTWrapper) + find_package(OpenCASCADE REQUIRED) + + set(OCCT_LIBS +-TKXDESTEP +-TKSTEP +-TKSTEP209 +-TKSTEPAttr +-TKSTEPBase ++TKDESTEP ++TKDESTL + TKXCAF + TKXSBase + TKVCAF diff -Nru slic3r-prusa-2.7.4+dfsg/debian/patches/series slic3r-prusa-2.7.4+dfsg/debian/patches/series --- slic3r-prusa-2.7.4+dfsg/debian/patches/series 2024-04-18 07:26:21.0 +0200 +++ slic3r-prusa-2.7.4+dfsg/debian/patches/series 2024-05-24 22:12:57.0 +0200 @@ -8,3 +8,4 @@ Disable-preset-update-and-version-check-by-default.patch Patch-tests-for-Catch2-v3-compatibility.patch Explicit-wxWidgets-initializers.patch +occt-7.8.patch signature.asc Description: PGP signature
Bug#1071643: horizon-eda: diff for NMU version 2.6.0-2.1
Control: tags 1071643 + pending Dear maintainer, I've prepared an NMU for horizon-eda (versioned as 2.6.0-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. (note: the previous patch was by accident reversed.) Regards. diff -Nru horizon-eda-2.6.0/debian/changelog horizon-eda-2.6.0/debian/changelog --- horizon-eda-2.6.0/debian/changelog 2024-05-22 17:31:22.0 +0200 +++ horizon-eda-2.6.0/debian/changelog 2024-05-24 20:52:05.0 +0200 @@ -1,3 +1,10 @@ +horizon-eda (2.6.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS, add missing B-D on cppzmq-dev. Closes: #1071643 + + -- Tobias Frost Fri, 24 May 2024 20:52:05 +0200 + horizon-eda (2.6.0-2) unstable; urgency=medium * Fix build depend diff -Nru horizon-eda-2.6.0/debian/control horizon-eda-2.6.0/debian/control --- horizon-eda-2.6.0/debian/control 2024-05-22 17:30:29.0 +0200 +++ horizon-eda-2.6.0/debian/control 2024-05-24 20:52:01.0 +0200 @@ -9,7 +9,7 @@ libglm-dev, libgit2-dev, libcurl4-gnutls-dev, libocct-data-exchange-dev, libdxflib-dev (>> 3.17.0), libarchive-dev, libzip-dev, libglib2.0-dev, libpodofo-dev, python3-cairo-dev, libosmesa6-dev, - dh-python + dh-python, cppzmq-dev Standards-Version: 4.4.0 Homepage: https://horizon-eda.org/ Rules-Requires-Root: no signature.asc Description: PGP signature
Bug#1071643: horizon-eda: Missing build dependency on cppzmq-dev
Source: horizon-eda Followup-For: Bug #1071643 Control: tags -1 patch I can confirm that the version in sid FTBFS, and all that needs is adding the B.D. (Trivial) patch attached. To speed up the opencascade transistion, I'll NMU this in DELAYED/2. -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#1071643: horizon-eda: Missing build dependency on cppzmq-dev
Source: horizon-eda Followup-For: Bug #1071643 (patch attached now) -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 diff -Naur horizon-eda-2.6.0/debian/control horizon-eda-2.6.0-bak/debian/control --- horizon-eda-2.6.0/debian/control2024-05-24 20:14:57.641114565 +0200 +++ horizon-eda-2.6.0-bak/debian/control2024-05-24 20:14:28.444689829 +0200 @@ -9,7 +9,7 @@ libglm-dev, libgit2-dev, libcurl4-gnutls-dev, libocct-data-exchange-dev, libdxflib-dev (>> 3.17.0), libarchive-dev, libzip-dev, libglib2.0-dev, libpodofo-dev, python3-cairo-dev, libosmesa6-dev, - dh-python, cppzmq-dev + dh-python Standards-Version: 4.4.0 Homepage: https://horizon-eda.org/ Rules-Requires-Root: no
Bug#1071223: Opencascade transition starts now
Control: severity -1 serious The transistion (#1071473) has been confirmed and I'll upload opencascade 8.1 to unstable soon, making those bugs RC. I will either team upload (science team) or NMU the packages to have a speedy transition. -- tobi
Bug#1071473: transition: opencascade
now, there is also a patch for freecad (#1071283)
Bug#1064340: Re: Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply
On Tue, May 21, 2024 at 05:15:09PM +0800, handsome_feng wrote: > Hi, > > > > The NMU has not been incorporated. > Sorry, I didn't quite understand this point. Did someone request an NMU? I stand correctred, it was not a NMU, but the changelog entry for 3.0.3.1-1 was not in d/changelog.
Bug#1071283: src:freecad: FTBFS with opencascade 7.8.1
Package: freecad Followup-For: Bug #1071283 Control: tags -1 ftbfs patch Backported upstream patch attached. (Testing is not yet completed, but it compiles with the new opencascade) -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/8 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), LANGUAGE=en_US:en 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.21.2+dfsg1-1+b3 Versions of packages freecad recommends: ii calculix-ccx2.21-1 ii graphviz2.42.2-9+b1 ii python3-opencamlib 2023.01.11-5 Versions of packages freecad suggests: pn povray -- no debconf information
Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply
Control: tags -1 moreinfo Hi, - The NMU has not been incorporated. - There are undocumented changes. Some are very confusing. - Why the move from github to gitlab? - Why the uploaders change? Is this authorized? - Upstream Contact Changed from a team email to your mail? What's going on here? - There is neither a response for #1070113, nor has it been adressed. (It seems also that all documents moved aways from English to Chinese?) -- tobi On Tue, Feb 20, 2024 at 03:53:24PM +0800, xibowen wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "kylin-nm": > > * Package name : kylin-nm >Version : 4.0.0.0-1 >Upstream contact : xibowen > * URL : https://gitee.com/openkylin/kylin-nm > * License : GPL-2+, BSD-3-clause, GPL-3+ > * Vcs : https://gitee.com/openkylin/kylin-nm >Section : utils > > The source builds the following binary packages: > > kylin-nm - Gui Applet tool for display and edit network simply > kylin-nm-plugin - Gui Applet plugin for display and edit network simply > kylin-nm-plugin-dev - Gui Applet development for display and edit network > simply > libkylin-nm-base - Gui lib for display and edit network simply > libkylin-nm-base-dev - Gui lib development for display and edit network > simply > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/kylin-nm/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/k/kylin-nm/kylin-nm_4.0.0.0-1.dsc > > Changes since the last upload: > > kylin-nm (4.0.0.0-1) unstable; urgency=medium > . >* New upstream release. > > This package is depended on ukui-greeter and ukui-screensaver. > > Regards, > -- > xibowen
Bug#1067595: RFS: psocksxx/1.1.1-5 -- psocksxx is a C++ wrapper for POSIX sockets
Control: tags -1 moreinfo On Sun, Mar 24, 2024 at 10:23:53AM +0100, Jörg Frings-Fürst wrote: > psocksxx (1.1.1-5) unstable; urgency=medium > . > * debian/control: > - Fix git URL. Hi Jörg, can you provide a secure URL for VCS-Git, please? Thanks! -- tobi
Bug#1071473: transition: opencascade
Package: release.debian.org Severity: normal X-Debbugs-Cc: opencasc...@packages.debian.org Control: affects -1 + src:opencascade User: release.debian@packages.debian.org Usertags: transition Control: block 1071284 by -1 Control: block 1071223 by -1 Control: block 1071470 by -1 Control: block 1071451 by -1 Control: block 1071471 by -1 Hi Release team, opencascade has a new release with breaking ABI, upstream versionied them as 7.8. The transition tracker [1] correctly picked it up already after the upload to experimental. [1] https://release.debian.org/transitions/html/auto-opencascade.html building the reverse depenencies most FTBFS due to library naming changes, but I was able to come up with patches for most, but they will require sourceful uploads. Freecad will require either backporting the upstream fixes or package a new upstream snapshot. This is the result of the compilation tests: Dependency level 2: f3d ✔ freecad (sid only) FTBFS, fixed in upstream git. horizon-eda patch available, #1071284 kicad ✔ netgen patch available, #1071223 slic3r-prusa (sid only) patch available, #1071470 Dependency level 3: gmshpatch available, #1071451 Dependency level 4: deal.ii patch available, #1071471 -- Cheers, tobi signature.asc Description: PGP signature
Bug#1071471: src:deal.ii: FTBFS with opencascade 7.8
Source: deal.ii Severity: important Tags: patch ftbfs Dear maintainer, deal.ii FBTFS with opencascade 7.8, which renames a few libraries. Attached patch fixes the FTBFS, unfortunatly it is not backward compatible and it should only be applied after the transistion has been started. -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- a/cmake/modules/FindDEAL_II_OPENCASCADE.cmake +++ b/cmake/modules/FindDEAL_II_OPENCASCADE.cmake @@ -69,8 +69,8 @@ # These seem to be pretty much the only required ones. set(_opencascade_libraries TKBO TKBool TKBRep TKernel TKFeat TKFillet TKG2d TKG3d TKGeomAlgo - TKGeomBase TKHLR TKIGES TKMath TKMesh TKOffset TKPrim TKShHealing TKSTEP - TKSTEPAttr TKSTEPBase TKSTEP209 TKSTL TKTopAlgo TKXSBase + TKGeomBase TKHLR TKDEIGES TKMath TKMesh TKOffset TKPrim TKShHealing TKDESTEP + TKDESTL TKTopAlgo TKXSBase ) set(_libraries "")
Bug#1071470: src:slic3r-prusa: FTBFS with opencasacade 7.8.1
Source: slic3r-prusa Severity: important Tags: patch ftbfs Dear maintainer, the new opencascade version 7.8.1 changes some library names, making slic3r-prusa fail. The attached patch fixes the compilation issue. (Source is gentoo, https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a345e202892c9358921d7a70cd54624bf17e42c) -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff --git a/src/occt_wrapper/CMakeLists.txt b/src/occt_wrapper/CMakeLists.txt index d8dd8e1..d27055f 100644 --- a/src/occt_wrapper/CMakeLists.txt +++ b/src/occt_wrapper/CMakeLists.txt @@ -22,11 +22,8 @@ generate_export_header(OCCTWrapper) find_package(OpenCASCADE REQUIRED) set(OCCT_LIBS -TKXDESTEP -TKSTEP -TKSTEP209 -TKSTEPAttr -TKSTEPBase +TKDESTEP +TKDESTL TKXCAF TKXSBase TKVCAF
Bug#1071451: src:gmsh: FTBFS with new opencascade 7.8.1
Source: gmsh Severity: important Tags: patch ftbfs Dear maintainer, gmsh FTBFS with the new opencascade 7.8.1 as the CMakeLists.txt missed to list one library, and therefore many symbols are not resolved at build time: Excerpt of build log: /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `STEPCAFControl_Reader::STEPCAFControl_Reader()' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `STEPCAFControl_Reader::ChangeReader()' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `HeaderSection_FileDescription::SetImplementationLevel(opencascade::handle const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `APIHeaderSection_MakeHeader::FdValue() const' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `HeaderSection_FileName::SetTimeStamp(opencascade::handle const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `APIHeaderSection_MakeHeader::APIHeaderSection_MakeHeader(int)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `HeaderSection_FileName::SetOriginatingSystem(opencascade::handle const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `StepData_StepModel::AddHeaderEntity(opencascade::handle const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `HeaderSection_FileName::SetPreprocessorVersion(opencascade::handle const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `StepData_StepModel::Header() const' collect2: error: ld returned 1 exit status /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `STEPCAFControl_Reader::Transfer(opencascade::handle const&, Message_ProgressRange const&)' /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `HeaderSection_FileName::SetName(opencascade::handle const&)' collect2: error: ld returned 1 exit status /usr/bin/ld: libgmsh.so.4.12.2: undefined reference to `STEPControl_Writer::Write(char const*)' make[4]: *** [CMakeFiles/t13_cpp.dir/build.make:190: t13_cpp] Error 1 make[4]: Leaving directory '/build/gmsh-4.12.2+ds1/debian/build' make[3]: *** [CMakeFiles/Makefile2:1759: CMakeFiles/t13_cpp.dir/all] Error 2 make[4]: *** [CMakeFiles/t14_cpp.dir/build.make:190: t14_cpp] Error 1 make[4]: Leaving directory '/build/gmsh-4.12.2+ds1/debian/build' The attached patch makes the packages compile here locally - the patch *should* be backward compatible with the older opencascade currently in sid. -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -1331,7 +1331,7 @@ if(FREETYPE_FOUND) if(OCC_VERSION AND OCC_VERSION VERSION_GREATER_EQUAL "7.8.0") set(OCC_CAF_LIBS_REQUIRED -TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService TKCDF) +TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService TKCDF TKDESTEP ) else() set(OCC_CAF_LIBS_REQUIRED TKXDESTEP TKXDEIGES TKXCAF TKLCAF TKVCAF TKCAF TKV3d TKService TKCDF)
Bug#1071284: src:horizon-eda: FTBFS with opencascade 7.8.1
Source: horizon-eda
Followup-For: Bug #1071284
Now with attachement :)
-- System Information:
Debian Release: trixie/sid
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/8 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),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Fix FTBFS with opencacscade 7.8
Author: Tobias Frost
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071284
Last-Update: 2024-05-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/Makefile
+++ b/Makefile
@@ -1036,7 +1036,7 @@
INC_OCE ?= -isystem /opt/opencascade/inc/ -isystem /mingw64/include/oce/
-isystem /usr/include/oce -isystem /usr/include/opencascade -isystem
${CASROOT}/include/opencascade -isystem ${CASROOT}/include/oce -isystem
/usr/local/include/OpenCASCADE
INC_PYTHON = $(shell $(PKG_CONFIG) --cflags python3 py3cairo)
OCE_LIBDIRS = -L/opt/opencascade/lib/ -L${CASROOT}/lib
-LDFLAGS_OCE = $(OCE_LIBDIRS) -lTKSTEP -lTKernel -lTKXCAF -lTKXSBase -lTKBRep
-lTKCDF -lTKXDESTEP -lTKLCAF -lTKMath -lTKMesh -lTKTopAlgo -lTKPrim -lTKBO
-lTKShHealing -lTKBRep -lTKG3d
+LDFLAGS_OCE = $(OCE_LIBDIRS) -lTKDESTEP -lTKernel -lTKXCAF -lTKXSBase
-lTKBRep -lTKCDF -lTKDESTEP -lTKLCAF -lTKMath -lTKMesh -lTKTopAlgo -lTKPrim
-lTKBO -lTKShHealing -lTKBRep -lTKG3d
ifeq ($(OS),Windows_NT)
LDFLAGS_OCE += -lTKV3d
endif
@@ -1117,7 +1117,7 @@
$(BUILDDIR)/horizon.so: $(OBJ_PYTHON) $(OBJ_SHARED) $(OBJ_SHARED_OCE)
$(ECHO) " $@"
- $(QUIET)$(CXX) $^ $(LDFLAGS) $(INC) $(CXXFLAGS) $(shell $(PKG_CONFIG)
--libs $(LIBS_COMMON) python3 glibmm-2.4 giomm-2.4 cairomm-1.0 py3cairo libpng
libarchive) -lpodofo $(OCE_LIBDIRS) -lTKXDESTEP -lOSMesa -shared -o $@
+ $(QUIET)$(CXX) $^ $(LDFLAGS) $(INC) $(CXXFLAGS) $(shell $(PKG_CONFIG)
--libs $(LIBS_COMMON) python3 glibmm-2.4 giomm-2.4 cairomm-1.0 py3cairo libpng
libarchive) -lpodofo $(OCE_LIBDIRS) -lTKDESTEP -lOSMesa -shared -o $@
$(OBJDIR)/%.o: %.c
$(QUIET)$(MKDIR) $(dir $@)
Bug#1071284: src:horizon-eda: FTBFS with opencascade 7.8.1
Source: horizon-eda Followup-For: Bug #1071284 Control: tags -1 +patch Patch attached that makes it compile with opencascade 7.8.1. It is unfortunatly not backward-compatible with older opencascade. -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1071433: src:horizon: Builds with quiet rules
Source: horizon-eda Severity: normal Dear maintainer, the package has hardcoded quiet rules in its Makefile. This makes debugging compilation errors harder - like the current opencascade transistion - and is also a Policy violation (§4.9) The package build should be as verbose as reasonably possible, except where the terse tag is included in DEB_BUILD_OPTIONS (see debian/rules and DEB_BUILD_OPTIONS). This makes life easier for porters and bug squashers more generally, who can look at build logs for possible problems. To accomplish this, debian/rules should pass to the commands it invokes options that cause them to produce verbose output. The attached patch fixes this, but does not implement terse: --- a/Makefile +++ b/Makefile @@ -1003,7 +1003,7 @@ PICOBJDIR= $(BUILDDIR)/picobj GENDIR = $(BUILDDIR)/gen MKDIR= mkdir -p -QUIET= @ +QUIET= ECHO = @echo # Object files @@ -1036,7 +1036,7 @@ -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices
On Sat, May 18, 2024 at 09:42:56PM +0200, Fabio Fantoni wrote: > On Thu, 16 May 2024 12:47:44 +0200 Tobias Frost wrote: > > > > > > * Don't fixed: P: imsprog source: > > > package-uses-old-debhelper-compat-version 12 - I want to maintain > > > compatibility for |Jammy| and |Focal| releases. > > > > If you package for different distributions, let me recommend me to utilize > > dedicated branches for those, for example by following the DEP14 proposal; > > this will allow to optimize for the different Debian derivates. > > > > For a Debian upload, please use a acutal compat level; >12 has a lots of > > benefits. > > Hi, I think compat 12 is not too old and can be keeped for now to make > possible to do unofficial build and individual build (any people also > without experience) on multiple Debian versions and derivatives still > supported easier and faster using debian/latest. I disagree. Uploads to Debian are aimed for the next stable, not for old releases, therefore they should follow the current best practices, and this is not compat 12. DEP14 is designed to cater older (and other distributions), this would be a compromise. Also, debhelper is very often backported to older released, so many people will not even need to change back to an older compat level. Even Jammie and Focal have debhelper 13 available. IMHO There is no reason to stay at 12; while others might, I'll certainly will not sponsor level 12. > About creation of other packaging branches following DEP14 I think is good > only for official build (for example possible official backports), but > before I think is good update the package to 1.3.9-1 before consider doing > official backports and don't backports of 1.3.2-1. DEP14 is not only for backports, but also for other distributions, like Ubuntu, -- tobi
Bug#983365: linphone-desktop: chat messages
Control: severity -1 important This bugs seems to be at least partially fixed, at least it seems that the messages are now showing up, so this bug should no longer be RC. (If I'm wrong, severity can be readjusted if needed) -- tobi
Bug#1071283: src:freecad: FTBFS with opencascade 7.8.1
Package: freecad Version: 0.21.2+dfsg1-1 Followup-For: Bug #1071283 Control: tags -1 ftbfs fixed-upstream Seems so that there is an upstream fix: https://github.com/FreeCAD/FreeCAD/pull/11909/commits/8d94e48921be080de4e0b44abeb642d57d38512f (The patch does not apply cleanly to the version currently in sid, but as the PR has been merged upstream, I think this is fixed upstream.) -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en 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.21.2+dfsg1-1+b3 Versions of packages freecad recommends: ii calculix-ccx2.21-1 ii graphviz2.42.2-9+b1 ii python3-opencamlib 2023.01.11-5 Versions of packages freecad suggests: pn povray -- no debconf information
Bug#1071223: negen: Will FTBFS with next opencascade version 7.8.1
Source: netgen
Followup-For: Bug #1071223
Control: tags -1 ftbfs patch
Attached a patch that makes netgen compile.
Taken from upstream, see forwarded information.
--
tobi
-- System Information:
Debian Release: trixie/sid
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/8 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),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Fix for FTBFS with opencascade 7.8.1
Taken from upstream, with addtional bits (linkage) from the upstream bug.
and one addtional include removed.
Bug: https://github.com/NGSolve/netgen/issues/170
Origin:
https://github.com/NGSolve/netgen/commit/486c7d9bcb950dfb33c2a59b68eca3e720af4107
>From 6b89d2cf6203272d04d2738f145bc01b49d75186 Mon Sep 17 00:00:00 2001
From: "Hochsteger, Matthias"
Date: Wed, 6 Mar 2024 16:29:11 +0100
Subject: [PATCH] Compatibility with Opencascade 7.8
---
libsrc/meshing/basegeom.cpp | 13 +++--
libsrc/meshing/basegeom.hpp | 8
libsrc/occ/occ_edge.cpp | 5 -
libsrc/occ/occ_edge.hpp | 1 -
libsrc/occ/occ_face.cpp | 5 -
libsrc/occ/occ_face.hpp | 1 -
libsrc/occ/occ_solid.hpp| 2 --
libsrc/occ/occ_vertex.cpp | 5 -
libsrc/occ/occ_vertex.hpp | 1 -
libsrc/occ/occgeom.cpp | 7 ---
10 files changed, 7 insertions(+), 41 deletions(-)
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -377,25 +377,20 @@
TKGeomAlgo
TKGeomBase
TKHLR
- TKIGES
TKLCAF
TKMath
TKMesh
TKOffset
TKPrim
- TKSTEP
- TKSTEP209
- TKSTEPAttr
- TKSTEPBase
- TKSTL
+ TKDESTL
TKService
TKShHealing
TKTopAlgo
TKV3d
TKVCAF
TKXCAF
- TKXDEIGES
- TKXDESTEP
+ TKDEIGES
+ TKDESTEP
TKXSBase
TKernel
)
--- a/libsrc/meshing/basegeom.cpp
+++ b/libsrc/meshing/basegeom.cpp
@@ -568,12 +568,13 @@
auto & identifications = mesh.GetIdentifications();
-std::map vert2meshpt;
+Array vert2meshpt(vertices.Size());
+vert2meshpt = PointIndex::INVALID;
for(auto & vert : vertices)
{
auto pi = mesh.AddPoint(vert->GetPoint(), vert->properties.layer);
tree.Insert(mesh[pi], pi);
-vert2meshpt[vert->GetHash()] = pi;
+vert2meshpt[vert->nr] = pi;
mesh[pi].Singularity(vert->properties.hpref);
mesh[pi].SetType(FIXEDPOINT);
@@ -585,8 +586,8 @@
for(auto & vert : vertices)
for(auto & ident : vert->identifications)
-identifications.Add(vert2meshpt[ident.from->GetHash()],
-vert2meshpt[ident.to->GetHash()],
+identifications.Add(vert2meshpt[ident.from->nr],
+vert2meshpt[ident.to->nr],
ident.name,
ident.type);
@@ -600,8 +601,8 @@
auto edge = edges[edgenr].get();
PointIndex startp, endp;
// throws if points are not found
-startp = vert2meshpt.at(edge->GetStartVertex().GetHash());
-endp = vert2meshpt.at(edge->GetEndVertex().GetHash());
+startp = vert2meshpt[edge->GetStartVertex().nr];
+endp = vert2meshpt[edge->GetEndVertex().nr];
// ignore collapsed edges
if(startp == endp && edge->GetLength() < 1e-10 * bounding_box.Diam())
--- a/libsrc/meshing/basegeom.hpp
+++ b/libsrc/meshing/basegeom.hpp
@@ -68,7 +68,6 @@
Transformation<3> primary_to_me;
virtual ~GeometryShape() {}
-virtual size_t GetHash() const = 0;
virtual bool IsMappedShape( const GeometryShape & other, const
Transformation<3> & trafo, double tolerance ) const;
};
@@ -320,13 +319,6 @@
throw Exception("Base geometry get tangent called");
}
-virtual size_t GetEdgeIndex(const GeometryEdge& edge) const
-{
- for(auto i : Range(edges))
-if(edge.GetHash() == edges[i]->GetHash())
- return i;
- throw Exception("Couldn't find edge index");
-}
virtual void Save (const filesystem::path & filename) const;
virtual void SaveToMeshFile (ostream & /* ost */) const { ; }
};
--- a/libsrc/occ/occ_edge.cpp
+++ b/libsrc/occ/occ_edge.cpp
@@ -53,11 +53,6 @@
throw Exception(ToString("not implemented") + __FILE__ + ":" +
ToString(__LINE__));
}
-size_t OCCEdge::GetHash() const
-{
- return edge.HashCode(std::numeric_limits::max());
-}
-
void OCCEdge::ProjectPoint(Point<3>& p, EdgePointGeomInfo* gi) const
{
auto pnt = ng2occ(p);
--- a/libsrc/occ/occ_edge.hpp
+++ b/libsrc/occ/occ_edge.hpp
@@ -36,7 +36,6 @@
Bug#1071284: src:horizon-eda: FTBFS with opencascade 7.8.1
Source: horizon-eda Severity: important Tags: ftbfs horizon-eda fails to build ; it seems has hardcoded library names in its build system and as opencascade has 7.8.1 slightly changed them (eg s/TKXDESTEP/-TKDESTEP/) horizon-eda FTBFS now: build/horizon.so /usr/bin/ld.gold: error: cannot find -lTKXDESTEP collect2: error: ld returned 1 exit status make[2]: *** [Makefile:1120: build/horizon.so] Error 1 make[2]: Leaving directory '/build/horizon-eda-2.5.0' make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2 make[1]: Leaving directory '/build/horizon-eda-2.5.0' make: *** [debian/rules:17: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package PS: Please make the build verbose. Currently it only shows e.g build/picobj/src/canvas3d/canvas_mesh.o build/picobj/src/canvas3d/background_renderer.o build/picobj/src/canvas3d/wall_renderer.o build/picobj/src/canvas3d/cover_renderer.o build/picobj/src/canvas3d/face_renderer.o build/picobj/src/canvas3d/point_renderer.o build/picobj/src/canvas/gl_util.o but it should output the commands for compiling, see policy 4.9 The package build should be as verbose as reasonably possible, except where the terse tag is included in DEB_BUILD_OPTIONS (see debian/rules and DEB_BUILD_OPTIONS). This makes life easier for porters and bug squashers more generally, who can look at build logs for possible problems. To accomplish this, debian/rules should pass to the commands it invokes options that cause them to produce verbose output. For example, the build target should pass --disable-silent-rules to any configure scripts. See also Binaries. -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1071283: src:freecad: FTBFS with opencascade 7.8.1
Package: freecad Version: 0.21.2+dfsg1-1 Severity: important Tags: ftbfs freecad fails to build with opencascade 7.8.1, which is now in experimental. (Once the transistion starts, this bug will become RC.) snippet attached: [ 0%] Linking CXX shared library ../../../lib/libSMDS.so cd /build/freecad-0.21.2+dfsg1/debian/build-py3/src/3rdParty/salomesmesh && /usr/bin/cmake -E cmake_link_script CMakeFiles/SMDS.dir/link.txt --verbose=1 /usr/lib/ccache/c++ -fPIC -Wall -Wextra -Wno-write-strings -g -O2 -ffile-prefix-map=/build/freecad-0.21.2+dfsg1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -fpermissive -I/usr/include/python3.11 -flto -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable -Wno-unused-but-set-variable -Wno-comment -Wno-unused-parameter -Wno-empty-body -Wno-pedantic -Wno-unused-result -Wno-cast-function-type -Wno-maybe-uninitialized -Wno-missing-field-initializers -O2 -g -DNDEBUG -L/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-flto -shared -Wl,-soname,libSMDS.so -o ../../../lib/libSMDS.so CMakeFiles/SMDS.dir/src/SMDS/SMDS_BallElement.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Downward.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_EdgePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FaceOfEdges.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FacePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_IteratorOfElements.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_LinearEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Mesh.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Mesh0DElement.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshCell.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshElement.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshElementIDFactory.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshFace.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshGroup.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshIDFactory.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshNode.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshNodeIDFactory.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshObject.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshVolume.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_PolygonalFaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_PolyhedralVolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Position.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticFaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticVolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_SpacePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_UnstructuredGrid.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VertexPosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeOfFaces.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeTool.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VtkCellIterator.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VtkEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VtkFace.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VtkVolume.cpp.o CMakeFiles/SMDS.dir/src/SMDS/Utils_SALOME_Exception.cpp.o CMakeFiles/SMDS.dir/src/SMDS/chrono.cpp.o CMakeFiles/SMDS.dir/src/SMDS/duplicate.cpp.o -L/usr/lib/x86_64-linux-gnu/hdf5/serial -L/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu/hdf5/serial:/usr/lib/x86_64-linux-gnu/openmpi/lib: -lhdf5 -lmpi_cxx -lmpi -lTKIGES -lTKSTL /usr/lib/x86_64-linux-gnu/libTKXSBase.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKOffset.so.7.8.1 -lTKSTEPBase -lTKSTEPAttr -lTKSTEP209 -lTKSTEP /usr/lib/x86_64-linux-gnu/libTKFeat.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKBin.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKBinL.so.7.8.1 -lTKXDESTEP -lTKXDEIGES /usr/lib/x86_64-linux-gnu/libTKMeshVS.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKRWMesh.so.7.8.1 /usr/lib/x86_64-linux-gnu/libvtkFiltersVerdict-9.1.so.9.1.0 /usr/lib/x86_64-linux-gnu/libvtkIOMPIParallel-9.1.so.9.1.0 /usr/lib/x86_64-linux-gnu/libvtkInteractionStyle-9.1.so.9.1.0 /usr/lib/x86_64-linux-gnu/libvtkRenderingFreeType-9.1.so.9.1.0 /usr/lib/x86_64-linux-gnu/libvtkRenderingOpenGL2-9.1.so.9.1.0 /usr/lib/x86_64-linux-gnu/libTKFillet.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKBool.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKXCAF.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKVCAF.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKCAF.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKBO.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKPrim.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKLCAF.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKCDF.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKV3d.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKMesh.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKShHealing.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKHLR.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKTopAlgo.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKGeomAlgo.so.7.8.1 /usr/lib/x86_64-linux-gnu/libTKBRep.so.7.8.1
Bug#1071223: negen: Will FTBFS with next opencascade version 7.8.1
Source: netgen Severity: important Tags: ftbfs Dear maintainers, I've just uploaded opencascade 7.8.1 to experimental (currently sitting in NEW waiting for ftp master approval) Unfortunatly, netgen fails with the new version, as there are ABI changes (e.g dropped header files.) [ 48%] Building CXX object CMakeFiles/nglib.dir/libsrc/occ/Partition_Loop3d.cxx.o /usr/bin/c++ -DFFMPEG -DHAVE_DLFCN_H -DHAVE_FREEIMAGE -DHAVE_FREETYPE -DHAVE_OPENGL_EXT -DHAVE_RAPIDJSON -DHAVE_TBB -DHAVE_TK -DHAVE_XLIB -DJPEGLIB -DMETIS -DNETGEN_PYTHON -DNG_MPI4PY -DNG_PYTHON -DOCCGEOMETRY -DOCC_CONVERT_SIGNALS -DPARALLEL -DPYBIND11_SIMPLE_GIL_MANAGEMENT -D__STDC_CONSTANT_MACROS -Dnglib_EXPORTS -I/build/netgen-6.2.2401+dfsg1/obj-x86_64-linux-gnu -I/build/netgen-6.2.2401+dfsg1 -I/build/netgen-6.2.2401+dfsg1/include -I/build/netgen-6.2.2401+dfsg1/libsrc -I/build/netgen-6.2.2401+dfsg1/libsrc/include -I/usr/include/python3.11 -I/usr/lib/python3/dist-packages/mpi4py/include/mpi4py -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /usr/include/opencascade -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/build/netgen-6.2.2401+dfsg1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -std=gnu++17 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/nglib.dir/libsrc/occ/Partition_Loop3d.cxx.o -MF CMakeFiles/nglib.dir/libsrc/occ/Partition_Loop3d.cxx.o.d -o CMakeFiles/nglib.dir/libsrc/occ/Partition_Loop3d.cxx.o -c /build/netgen-6.2.2401+dfsg1/libsrc/occ/Partition_Loop3d.cxx In file included from /build/netgen-6.2.2401+dfsg1/libsrc/occ/Partition_Loop3d.jxx:29, from /build/netgen-6.2.2401+dfsg1/libsrc/occ/Partition_Loop3d.ixx:10, from /build/netgen-6.2.2401+dfsg1/libsrc/occ/Partition_Loop3d.cxx:14: /build/netgen-6.2.2401+dfsg1/libsrc/occ/Partition_Loop3d.hxx:32:13: fatal error: TopTools_OrientedShapeMapHasher.hxx: No such file or directory 32 |#include | ^ compilation terminated. -- tobi -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/8 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), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices
Hi, thanks for working on the package! > Hello, Tobias! > I've done some work on the bugs :) > > In version v1.3.9: > > * Fixed: There is a spelling error "copyed" in in 99-CH341.rules. > * Fixed (metadata changed): W: imsprog: > appstream-metadata-missing-modalias-provide > usr/lib/udev/rules.d/99-CH341.rules > * Fixed: As you are upstream, you could wrap README.md at 80 chars per > line :) > * Fixed: src:imsprog: Does not rebuild qt language files > > * Don't fixed: P: imsprog source: > package-uses-old-debhelper-compat-version 12 - I want to maintain > compatibility for |Jammy| and |Focal| releases. If you package for different distributions, let me recommend me to utilize dedicated branches for those, for example by following the DEP14 proposal; this will allow to optimize for the different Debian derivates. For a Debian upload, please use a acutal compat level; >12 has a lots of benefits. -- tobi > Please check this package and send me Lintian's warnings. > Regards, Mikhail
Bug#1070991: RFS: libcdio-paranoia/10.2+2.0.2-1 -- audio CD reading utility which includes extra data verification features
Hi Phillippe, a short review: - package could use some modernization: - it is still using d/compat, at the very old level 11 - d/copyright is not dep5 Would be cool if you could update those parts. -- tobi On Sun, May 12, 2024 at 05:45:13PM +0200, Philippe SWARTVAGHER wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "libcdio-paranoia": > > * Package name : libcdio-paranoia >Version : 10.2+2.0.2-1 >Upstream contact : [fill in name and email of upstream] > * URL : https://www.gnu.org/software/libcdio/ > * License : [fill in] > * Vcs : https://salsa.debian.org/debian/libcdio-paranoia >Section : libs > > The source builds the following binary packages: > > libcdio-cdda-dev - library to read and control digital audio CDs > (development files) > libcdio-cdda2t64 - library to read and control digital audio CDs > libcdio-paranoia-dev - library to read digital audio CDs with error > correction (development files) > libcdio-paranoia2t64 - library to read digital audio CDs with error > correction > cd-paranoia - audio CD reading utility which includes extra data > verification features > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/libcdio-paranoia/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/libc/libcdio-paranoia/libcdio-paranoia_10.2+2.0.2-1.dsc > > Changes since the last upload: > > libcdio-paranoia (10.2+2.0.2-1) unstable; urgency=medium > . >[ Debian Janitor ] >* Remove constraints unnecessary since buster (oldstable): > + Build-Depends: Drop versioned constraint on libcdio-dev. > + libcdio-cdda-dev: Drop versioned constraint on libcdio-dev in > Depends. > + libcdio-paranoia-dev: Drop versioned constraint on libcdio-dev > in Depends. > + cd-paranoia: Drop versioned constraint on libcdio-utils in Replaces. > + cd-paranoia: Drop versioned constraint on libcdio-utils in Breaks. > . >[ Philippe SWARTVAGHER ] >* d/control: update Build-Depends packages, as suggested by Lintian >* New upstream release > - Drop all patches (applied upstream). > - Closes: #981017. >* Bump Standards-Version to 4.7.0 (no change) >* Add patches to fix typos > > Regards, > -- > Philippe >
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
Control: tags -1 moreinfo Hi Joachim, On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote: > > An updated 0.8.5-1 has been uploaded. It's nice that you've picked up my suggestions regarding the README.md… However, recycling upstream version numbers (as upstream) should be avoided, as there are now two 0.8.5 in the world. Please avoid that. The watch file is not working: tobi@gondor:~/workspace/deb/mentors/JoachimZobel/vzlogger/debcheckout/vzlogger$ uscan --force-download uscan warn: In directory ., downloading https://github.com/volkszaehler/vzlogger/releases/download/v0.8.5/vzlogger-0.8.5.tar.gz failed: 404 Not Found uscan warn: No upstream tarball downloaded. No further processing with mk_origtargz ... (Tagging moreinfo because of the watchfile.) > Sincerely, > Joachim >
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote: > (forgotten cc) > > Am Freitag, dem 03.05.2024 um 18:50 +0200 schrieb Tobias Frost: > > reviewing your new package: > > > > - d/changelog > > - generally documents only changes to the packaging, not "upstream" > changes > > (the entry "Fixed logrotate conf user name" is an upstream > change.) > > There are exceptions, like if it a very noteworthy change, but > this > > is one isn't in that category. > > - When packaging a new upstream version, you say so in the > changelog. > > (Like first changelog entry: > > * New upstream version. > > ) > > - There are undocumented changes, for example the change to the > > Standard-Version. > > > > Done. > > > A nitpick on d/rules: > > I'm a fan of declarative syntax, so I'd replace the dh_clean > override > > with specifing the file to be deleted in the file d/clean. (If you > feel > > different about this, it is ok to ignore my nitpicking) > > Done, thx. > > > Remarks on Readme.md: > > - It cointains only information not relevant when the user is > > installing the binary package (like how to build, how to install > and > > where to find the packages), so it should not be installed into > > the binary package. > > Not exactly. There is the important line "Our packages are built with > MQTT support, but without OMS support.". In addition it is a moving > target. So I'd prefer to keep it as now. This information would go into the long description of the package, (README.md is not available pre-install, and this is something the user wants to knowbeforehand; using README.md for this purpose is very unusal in Debian.) > > - "Debian" is written with a captial "D". > > Done. > > > - The sentence "Unfortunately Debian armhf packages do not > > run on Raspberry Pi 1 although the architecture on the RPi is > named armhf. > > Using Raspian armhf packages fixes that." is a bit hard to parse, > a > > bit off: > > - Raspberry Pi 1 is supported by the Debian armel architecture, > so people > > running (real) Debian on the Pi 1 need to use "armel" not > "armhf". > > - Paspian has been renamed to Raspberry Pi OS, so the naming > should > > maybe be also updated. > > Done. During the discussion more changes were added. > > > Maybe this should be separated into a Debian and Raspberry Pi OS > > section? (They are different distributions anyways…) > > The handling is very similar from the users perspective. > > > > > Some parts already mentioned for the previous upload, would be great > if > > you could start tackling them: > > > > As you are involved with upstream: > > The manpage, initfile, systemd service file should probably be > included in the > > upstream part, it is not only useful for Debian alone. > > > > It is currently under discussion if other installation methods are > still needed. I'd still say README.md shouldn't end up in the binary package, as it only covers installation topics, which are irrelevant to our users. > > Linitian: (I've pre-filtered them a bit already on those that should > be > > investigaged. If harderning is working now, override the linitian I: > tag.) > > I: vzlogger source: debian-rules-parses-dpkg-parsechangelog > [debian/rules:15] > > I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] > > I: vzlogger: systemd-service-file-missing-documentation-key > [usr/lib/systemd/system/vzlogger.service] > > P: vzlogger source: trailing-whitespace [debian/changelog:10] > > P: vzlogger source: trailing-whitespace [debian/changelog:4] > > P: vzlogger source: trailing-whitespace [debian/control:17] > > P: vzlogger source: trailing-whitespace [debian/control:40] > > P: vzlogger source: trailing-whitespace [debian/rules:45] > > X: vzlogger: systemd-service-file-missing-hardening-features > [usr/lib/systemd/system/vzlogger.service] > > X: vzlogger source: upstream-metadata-file-is-missing > > All done except for upstream-metadata-file-is-missing. I don't think > this is of much use for a service. > > An updated 0.8.5-1 has been uploaded. > > Sincerely, > Joachim
Bug#1070983: supertuxkart: symbol lookup error: undefined symbol
Control: reassign -1 src:shaderc Control: affects -1 src:supertuxkart Control: fixed -1 2023.8-1 Hi Bernd, It seems that that symbol is missing in libshaderci [1] , and it seems that it is in version 2023.8-1 (which is currently only in unstable.) So, if you feel comfortable pull in that package from unstable, you will be able to play the game. Reassignin to shaderc, and CC'ing the maintainer of shaderc, maybe they have an idea what's going and can check if something has to be done (maybe to make it migrate to testing…) [1] LD_WARN=1 /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libshaderc.so.1 /lib/x86_64-linux-gnu/libshaderc.so.1: symbol lookup error: /lib/x86_64-linux-gnu/libshaderc.so.1: undefined symbol: _ZTVN8spvtools5utils5TimerE -- tobi On Sun, May 12, 2024 at 02:49:06PM +0200, Bernd Dau wrote: > Package: supertuxkart > Version: 1.4+dfsg-4 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: b...@zockertown.de > > Dear Maintainer, > > Trying to start supertuxkart from console brings this as answer, after last > full-upgrade > > supertuxkart: symbol lookup error: /lib/x86_64-linux-gnu/libshaderc.so.1: > undefined symbol: _ZTVN8spvtools5utils5TimerE > This is my first bugreort, hope it is ok. > Tanks and have a nice day > Bernd, aka bed > > -- System Information: > Debian Release: trixie/sid > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.7.12-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), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages supertuxkart depends on: > ii libangelscript2.35.1t64 2.35.1+ds-3.1 > ii libbluetooth35.71-1 > ii libc62.38-10 > ii libcurl3t64-gnutls 8.7.1-5 > ii libfreetype6 2.13.2+dfsg-1+b4 > ii libgcc-s114-20240330-1 > ii libharfbuzz0b8.3.0-2+b1 > ii libjpeg62-turbo 1:2.1.5-3 > ii libmbedcrypto7t642.28.8-1 > ii libmcpp0 2.7.2-5.1 > ii libopenal1 1:1.23.1-4+b1 > ii libpng16-16t64 1.6.43-5 > ii libsdl2-2.0-02.30.2+dfsg-1 > ii libshaderc1 2023.2-1 > ii libsqlite3-0 3.45.3-1 > ii libsquish0 1.15-3+b1 > ii libstdc++6 14-20240330-1 > ii libvorbisfile3 1.3.7-2 > ii supertuxkart-data1.4+dfsg-4 > ii zlib1g 1:1.3.dfsg-3.1 > > supertuxkart recommends no packages. > > supertuxkart suggests no packages. > > -- no debconf information >
Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system
On Sun, May 12, 2024 at 02:34:15PM +0200, Preuße, Hilmar wrote: > On 11.05.2024 09:08, Tobias Frost wrote: > > Hi, > > > Please also announce the NMU / RFS to the package maintainer, > > preferable as bug reported against it. Thanks! > > > The package is flagged as LowNMU [1], which says: > > "You don't need to contact the maintainers beforehand, and you don't need to > use a delayed upload queue. If the package maintainer or maintainer group is > active, it is polite to let them have a stab at fixing the problem first." > > Given the fact that the last upload was 3.5 years ago I'd assume that the > maintainers group is non-active. Hence I did not inform them. LowNMU just says you can upload into DELAYED/0, or directly, but not that communication is not needed beforehand. It explictly says [1]: "at any time, as long as the NMU procedure in the Debian Developer's Reference is otherwise followed" The Developers Reference [2] explictly says: "Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC). So, no, announcing the NMU is not optional, it is the bare minimum. [1] https://wiki.debian.org/LowThresholdNmu [2] > Hilmar > > [1] https://tracker.debian.org/pkg/nq > -- > -- > sigfault > -- tobi signature.asc Description: PGP signature
Bug#1070890: qabc: [src:qabc] VCS-* in d/control is not pointing to the packaging repository
Source: qabc Severity: minor Dear Maintainer, during review I've seen that VCS-* is pointing to the upstream repo, according to Policy §5.6.26 "The purpose of the following fields is to indicate a publicly accessible repository where the Debian source package is developed." -- IOW where the debian package is maintained. (It seems you are just missing to sepcify the branch, see Policy for details how to do that.) -- tobi
Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs
Hi Xiyue, when packaging a git snapshot, I feel this should be indicated in the upstream version that it is based on the old one, something like + In your case I'd 20210802+git20231023 as upstream version. Long time ago I did something like that for dhewm3, you can see the watch file here: https://salsa.debian.org/games-team/dhewm3/-/blob/debian/1.5.0+git20181221+dfsg-1/debian/watch?ref_type=tags (not marking moreinfo, as other people might see that differently.) -- tobi On Sun, Apr 21, 2024 at 10:02:48AM -0700, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "lua-mode": > > * Package name : lua-mode >Version : 20231023~git-1 >Upstream contact : immerrr > * URL : https://github.com/immerrr/lua-mode > * License : GPL-3+ > * Vcs : https://salsa.debian.org/emacsen-team/lua-mode >Section : lisp > > The source builds the following binary packages: > > elpa-lua-mode - Emacs major-mode for editing Lua programs > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/lua-mode/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20231023~git-1.dsc > > Changes since the last upload: > > lua-mode (20231023~git-1) unstable; urgency=medium > . >* Sync to latest upstream snapshot (d074e41) >* Drop the patch applied upstream and reorder the remaining patch >* Update upstream license to GPL-3+ following upstream change >* Add a missing upstream copyright holder > > Regards, > -- > Xiyue Deng >
Bug#1068724: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.
Control: reopen -1 Control: forcemerge 1069696 -1 Hi Chen, In future, please do not file new RFS bugs, instead modify the existing one until a package has been sponsored. (forcemerge: FTR, the new one is #1069696, let that one be the leading one) -- tobi On Tue, Apr 09, 2024 at 06:53:58PM +, Chen, Xingyu wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "gensync": > > * Package name : gensync >Version : 2.0.5-1 >Upstream contact : project> > * URL : https://github.com/nislab/gensync > * License : > * Vcs : [fill in URL of packaging vcs] >Section : libs > > The source builds the following binary packages: > > gensync - a library for efficient synchronization of data over a network. > Gensync is a library that uses many different syncing algorithms to sync data > between two nodes in a network. These algorithms include IBLTs, CPISyncs, > HashSyncs, Cuckoo Syncs, and more. > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/gensync/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc > > Changes for the initial release: > > gensync (2.0.5-1) UNRELEASED; urgency=medium > . >* Initial release (Closes: #) > > Regards, > -- > Kevin Chen >
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote: > Control: block -1 by 1067525 > > this fix need to go to unstable because elogind 255.4.1 is already > there, but runit-services depends on runit > 2.1.2-56 (unstable is at > 2.1.2-54) so 1067525 needs to be uploaded first or together with this > one, otherwise runit-services is not installable Ok, just saw that one. Please note that this fact must be stated in d/changelog, something like "Upload to unstable." -- tobi > On Tue, 16 Apr 2024 09:30:08 +0200 Lorenzo wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "runit-services": > > > > * Package name : runit-services > >Version : 0.7.2 > >Upstream contact : [fill in name and email of upstream] > > * URL : [fill in URL of upstream's web site] > > * License : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0 > > * Vcs : > >https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section > > : admin > > > > The source builds the following binary packages: > > > > runit-services - UNIX init scheme with service supervision > > (services) > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/runit-services/ > > > > Alternatively, you can download the package with 'dget' using this > > command: > > > > dget -x > > > > https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc > > > > Git repo: > > > > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads > > > > Changes since the last upload: > > > > runit-services (0.7.2) unstable; urgency=medium > > . > >* Fix elogind service (Closes: #1069075) > > > > Regards, > > Lorenzo > > > > >
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
Control: tags -1 moreinfo Hi Lorenzo, the last uploads where to experimental, this one targets unstable but that is not mentioned in the changelog, so I guess this was accidential? -- tobi On Tue, Apr 16, 2024 at 09:30:08AM +0200, Lorenzo wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "runit-services": > > * Package name : runit-services >Version : 0.7.2 >Upstream contact : [fill in name and email of upstream] > * URL : [fill in URL of upstream's web site] > * License : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0 > * Vcs : >https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section > : admin > > The source builds the following binary packages: > > runit-services - UNIX init scheme with service supervision (services) > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/runit-services/ > > Alternatively, you can download the package with 'dget' using this > command: > > dget -x > > https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc > > Git repo: > > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads > > Changes since the last upload: > > runit-services (0.7.2) unstable; urgency=medium > . >* Fix elogind service (Closes: #1069075) > > Regards, > Lorenzo >
Bug#1069696: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.
Control: tags -1 moreinfo Hi Chen, please take a look at [1] -- the page indicates a lots of problems with your package, especially the lintian errors, warnings and informational tags. That means your package is not yet ready to be reviewed in depth. Please fix those linitian erros, then remove the moreinfo tag. As you seems to be upstream, please read https://wiki.debian.org/UpstreamGuide Cheers, -- tobi [1] https://mentors.debian.net/package/gensync/ On Mon, Apr 22, 2024 at 09:43:03PM +, Chen, Xingyu wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "gensync": > > * Package name : gensync >Version : 2.0.5-1 >Upstream contact : Kevin Chen > * URL : https://github.com/nislab/gensync-lib > * License : GPL > * Vcs : >Section : libs > > The source builds the following binary packages: > > gensync - a library for efficient synchronization of data over a network. > Gensync is a library that uses many different syncing algorithms to sync data > between two nodes in a network. These algorithms include IBLTs, CPISyncs, > HashSyncs, Cuckoo Syncs, and more. > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/gensync/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc > > Changes for the initial release: > > gensync (2.0.5-1) UNRELEASED; urgency=medium > . >* Initial release (Closes: #1069684) > > Regards, > -- > Kevin Chen > >
Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices
Control: tags -1 moreinfo Hi Mikhail, Thanks for the update. There is one thing I'd like to fixed: The qm language files needs to be recreated at build time. As you are upstream, you can incoorporate that change upstream (and drop the binary files from your tarball) There is a spelling error "copyed" in in 99-CH341.rules. Linitian to be checked (verified and if not a false positive fixed otherwise overriden) W: imsprog: appstream-metadata-missing-modalias-provide usr/lib/udev/rules.d/99-CH341.rules (likekly false positive) I: imsprog: hardening-no-bindnow [usr/bin/IMSProg] I: imsprog: hardening-no-bindnow [usr/bin/IMSProg_editor] P: imsprog source: package-uses-old-debhelper-compat-version 12 P: imsprog source: trailing-whitespace [debian/changelog:12] As you are upstream, please consider signing your tarballs: X: imsprog source: debian-watch-does-not-check-openpgp-signature [debian/watch] As you are upstream, you could wrap README.md at 80 chars per line :) X: imsprog source: very-long-line-length-in-source-file 577 > 512 [README.md:103] -- tobi On Sat, Apr 27, 2024 at 02:19:07PM +0300, Михаил Медведев wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "imsprog": > > * Package name : imsprog >Version : 1.3.7-1 >Upstream contact : Mikhail medvedeve-ink-rea...@yandex.ru > * URL :https://github.com/bigbigmdm/IMSProg > * License : GPL-2+, GPL-3+, LGPL-2.1 > * Vcs :https://github.com/bigbigmdm/IMSProg/ >Section : devel > > The source builds the following binary packages: > > imsprog - Linux chip programmer for CH341a devices > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/imsprog/ > > Alternatively, you can download the package with 'dget' using this command: > > dget > -xhttps://mentors.debian.net/debian/pool/main/i/imsprog/imsprog_1.3.7-1.dsc > > Changes since the last upload: > > imsprog (1.3.7-1) unstable; urgency=medium > . >* New upstream release > > Regards, > -- > Mikhail Medvedev
Bug#1070883: src:imsprog: Does not rebuild qt language files
Source: imsprog Severity: important Dear Maintainer, When reviewing #1069942 I saw the the build process does not redbuilt the qt language files. In Debian it is important to rebuild everything from source, that includes those files. (As you are upstream, you could incoorpoate this into your build system and then drop the qm files from the tarball, which will everyone allow to benefit from this)
Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system
Please also announce the NMU / RFS to the package maintainer, preferable as bug reported against it. Thanks! On Sat, May 04, 2024 at 02:19:00PM +0200, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: > Control: block -1 by 1005961 > > On 03.05.2024 23:45, Christoph Biedl wrote: > > Hi, > > > That would be necessary - although I don't know how to solve this in a > > sensible way. > > > > Sorry for disturbing your best intentions to bring nq back in shape - > > but this problem will not disappear by ignoring it. > > > Completely agree. Let's see if there are reactions for the re-opened bug. > > Hilmar > -- > sigfault >
Bug#1052029: c-evo-dh: depends on deprecated GTK 2
Severity: -1 important Hi Peter, please bring this issue to the attention of upstream to get it working using gtk3 or qt. I agree with Bastian that we should avoid making the GTK2 problem space bigger. -- tobi On Sun, 17 Sep 2023 15:39:48 +0100 Peter B wrote: > On 16/09/2023 11:31, Bastian Germann wrote: > > Please consider switching to lcl=qt5 to build with qt5 interface. > > Please rename c-evo-dh-gtk2 to c-evo-dh when implementing this. We really > > do not need to know the toolkit that it uses by looking at the pkg name. > > Hi Bastian, > > Lazarus can build packages against various toolkits, and if more than one is viable, > building those gives users some choice, as they all have various quirks. > The toolkit in the package name allows that differentiation. > > C-evo-dh will build against all supported Lazarus toolkits, however, > gtk3 & fpgui builds crash on startup, and qt5 & qt6 have corrupted graphics. > gtk2 is the only Linux toolkit version that currently runs OK. > > C-evo-dh has been intentionally packaged to allow co-installation of multiple front-ends. > I will certainly include others when they become viable. > I tested the Qt6 build today with Lazarus 3.0RC1, but have the same display issues as with Qt5. > gtk3 is being worked on upstream. That may become a possibility. > > Cheers, > Peter > > > signature.asc Description: PGP signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote: > On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote: > > [DEFAULT] > debian-branch = gnuabordo/latest > debian-tag = gnuabordo/%(version)s Please let me suggest to use DEP14 for branch naming: https://dep-team.pages.debian.net/deps/dep14/ -- tobi
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On Mon, May 06, 2024 at 04:31:26PM +0200, Daniel Gröber wrote: > Hi Lucas, > d/changelog: > > lsm (1.0.21-1) unstable; urgency=medium > > . > > * New upstream release (Closes: #1041221) > > * Usrmerge compliance (Closes: #1054086) > > Could be more specific. "Use dh_installsystemd to install units" maybe? > > > * Package rename > > Use imperative in changelogs and be more specific: "Rename package to > 'foolsm' to stay consistent with upstream" or some such. > > > - Added transitional package for renaming process > > More specific please. I'd go with straight prose and not bullet-points > myself. Say: "The old 'lsm' package is now transitional and installs the > new 'foolsm' package. > > > - Debian package was modified after upstream project rename. > > I'm not sure what you're trying to tell me here? > > > * debian/watch updated > > * debian/patches/ cleaned out > > IMO these are implied. Ofc. we're going to do that when we update a package > in Debian so while these would make good git commits I don't think they > should be in d/changelog since that's mostly user-facing. > > Maybe that's just my git sensibilities showing and it's perfectly > appropriate to note this in d/changelog for the old dsc focused workflow? > Feel free to rebuttle this point. > d/changelog should reflect all changes made to the packaging, so if d/watch and d/patches are changed, it should be mentioned in d/changelog However, the changelog should say "WHY" something has changed. Do "d/watch updated" should be improved to "updated d/watch due to $x" or like. Same for d/parchs: Explain the why - for example "patch abc.patch has been removed, applied upstream". -- tobi
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
Control: tags -1 moreinfo Hi Joachim, reviewing your new package: - d/changelog - generally documents only changes to the packaging, not "upstream" changes (the entry "Fixed logrotate conf user name" is an upstream change.) There are exceptions, like if it a very noteworthy change, but this is one isn't in that category. - When packaging a new upstream version, you say so in the changelog. (Like first changelog entry: * New upstream version. ) - There are undocumented changes, for example the change to the Standard-Version. A nitpick on d/rules: I'm a fan of declarative syntax, so I'd replace the dh_clean override with specifing the file to be deleted in the file d/clean. (If you feel different about this, it is ok to ignore my nitpicking) Remarks on Readme.md: - It cointains only information not relevant when the user is installing the binary package (like how to build, how to install and where to find the packages), so it should not be installed into the binary package. - "Debian" is written with a captial "D". - The sentence "Unfortunately Debian armhf packages do not run on Raspberry Pi 1 although the architecture on the RPi is named armhf. Using Raspian armhf packages fixes that." is a bit hard to parse, a bit off: - Raspberry Pi 1 is supported by the Debian armel architecture, so people running (real) Debian on the Pi 1 need to use "armel" not "armhf". - Paspian has been renamed to Raspberry Pi OS, so the naming should maybe be also updated. Maybe this should be separated into a Debian and Raspberry Pi OS section? (They are different distributions anyways…) Some parts already mentioned for the previous upload, would be great if you could start tackling them: As you are involved with upstream: The manpage, initfile, systemd service file should probably be included in the upstream part, it is not only useful for Debian alone. Linitian: (I've pre-filtered them a bit already on those that should be investigaged. If harderning is working now, override the linitian I: tag.) I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15] I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] P: vzlogger source: trailing-whitespace [debian/changelog:10] P: vzlogger source: trailing-whitespace [debian/changelog:4] P: vzlogger source: trailing-whitespace [debian/control:17] P: vzlogger source: trailing-whitespace [debian/control:40] P: vzlogger source: trailing-whitespace [debian/rules:45] X: vzlogger: systemd-service-file-missing-hardening-features [usr/lib/systemd/system/vzlogger.service] X: vzlogger source: upstream-metadata-file-is-missing -- Cheers, tobi On Fri, Apr 26, 2024 at 10:37:26PM +0200, Joachim Zobel wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "vzlogger": > > * Package name : vzlogger > Version : 0.8.5-1 > Upstream contact : Joachim Zobel > * URL : > http://wiki.volkszaehler.org/software/controller/vzlogger > * License : GPL-3.0-or-later > * Vcs : https://github.com/volkszaehler/vzlogger/tree/debian > Section : net > > The source builds the following binary packages: > > vzlogger - program for logging measurements of smart meters > > To access further information about this package, please visit the following > URL: > > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc > > Changes since the last upload: > > * Fixed logrotate conf user name > * Fixed passing of hardening flags to cmake > > Regards, > -- > Joachim Zobel > signature.asc Description: PGP signature
Bug#1067648: freeciv-client-qt: segfault upon connect to a server in ___pthread_mutex_lock
Control: tags -1 unreproducible moreinfo Hi Jeffrey, I can't reproduce your issue, sorry. (I've tested against a local server - version 3.1.0 and 3.1.1) and I can connect without problems.) I've just uploaded 3.1.1, maybe retry with that version once it is availble in the archives? (It might well be that this is caused by the ongoing time64 transistion) Cheers, tobi
Bug#1044151: Re: Bug#1044151: gnome-shell-extension-autohidetopbar: Fails to build source after successful build
Contol: tags -1 -pending The fix broke stuff, so I reverted the previous attempt. -- tobi On Sun, 13 Aug 2023 17:49:56 + Tobias Frost wrote: > Control: tags -1 pending > > Thanks Lucas for the report. > > I've fixed it already on salsa and with the next upload this will be solved > >
Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st
On Sun, Apr 14, 2024 at 01:40:30PM +0200, Daniel Baumann wrote: > Hi Tobias, > > On 4/14/24 10:14, Tobias Frost wrote: > > * Package name: gnome-shell-extension-vertical-workspaces > > this is already included in src:gnome-shell-extensions-extra. Thanks for noticing… As I have the package ready, I'd like to propose to maintain it as new package, would that be ok for you? (If you wish, we can co-maintain as well.) Cheers, -- tobi > Regards, > Daniel
Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st
Package: wnpp Severity: wishlist Owner: Tobias Frost X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gnome-shell-extension-vertical-workspaces Version : (tbd, likely a git snapshot) Upstream Contact: GdH * URL : https://github.com/G-dH/vertical-workspaces * License : GPL-3.0 Programming Lang: Javascript Description : A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically stacked workspaces. A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically stacked workspaces. Features: - Vertically or horizontally stacked workspaces - Adjust position, orientation, scale and visibility of overview content - Customizable profiles offer predefined configurations for GNOME 3.xx, GNOME 40+ and another 2 custom layouts - 2 overview modes with static windows/workspace. The Static Workspace option allows you to use dash like a dock with auto-hide, but with all advantages of the activities overview - Support for secondary monitors, workspace thumbnails can be placed on the opposite side than on the primary monitor - Wallpaper background with adjustable blur effect and brightness in the overview - Custom Dash icon size and on-click/scroll behavior - Optional workspace isolated Dash - Dash background transparency and corner radius adjustments - Adjustable app grid icon size, number of columns and rows, content, optional active and draggable icons in folder preview in optional 3x3 grid - Custom search view width, app results icons size and number of result lists rows, improved app search - Workspace thumbnails can show background wallpaper and labels (always or on mouse hover) with combination of workspace index, workspace name, name of the current application and current window title - Title captions of window previews moved into the preview (originally beneath the preview) and can be set as always visible. Adjustable window preview icon - Static background in workspace switcher (outside overview). Keeps Conky below, DING desktop icons stay visible (if not covered by windows) - Control over transition animations, including speed - Recent files search provider with Ctrl + Space hotkey - Supports WSP (Window search provider) extension with Space hotkey that allows quick window navigation - Supports ESP (Extensions search provider) with Ctrl + Shift + Space hotkey that allows to search for installed extensions, open their settings and enable or disable them - Reorder workspaces in overview using Shift + Scroll or Shift + Page Up/Down - Adds Force Quit, Close Windows on Current Workspace and Move Windows to Current Workspace items to app icon menu. The latter action can be activated using Shift + click on app icon - Change notification banners and OSD popups position - Window attention handler options can activate the attention-demanding window immediately or silence its notification - Optional position of the hot corner that can follow the dash and expand to hot edge - Super key double-press options - Supports WTMB (Window Thumbnails) extension that allows you to create Picture-in-Picture thumbnail of the window by clicking on its preview in the overview (secondary mouse buttons or window preview icon) This is a replacement for gnome-shell-extension-vertical-overview, which is dead-uptream and will stop working with GNOME 45. gnome-shell-extension-vertical-overview will be removed from Debian once this package is ready.
Bug#1068590: steam-installer: Impossible installation
Am 7. April 2024 15:39:03 UTC schrieb Serge Kilimoff : >Package: steam-installer >Version: 1:1.0.0.79~ds-2 >Severity: grave >Justification: renders package unusable >X-Debbugs-Cc: serge.kilim...@gmail.com > >Dear Maintainer, > >when I try to install the package I get the following error : > >The following packages have unmet dependencies: > libgl1-mesa-dri:i386 : Depends: libllvm17t64:i386 but it is not installable >E: Unable to correct problems, you have held broken packages. > > >-- System Information: >Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable') >Architecture: amd64 (x86_64) >Foreign Architectures: i386 > >Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT) >Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, >TAINT_UNSIGNED_MODULE >Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr >Shell: /bin/sh linked to /usr/bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages steam-installer depends on: >ii debconf [debconf-2.0] 1.5.86 >pn steam-libs >pn steam-libs-i386 >ii zenity 4.0.1-1+b1 > >steam-installer recommends no packages. > >steam-installer suggests no packages. > Control: close -1 this is due to the active time_t transition and will sort itself out once it has been finished. unfortunately there is nothing that can be done atm, so closing. (you might want to check if you can install it when tracking testing, but no guarantees)
Bug#1036388: tagging 1036388
Control: tags -1 +unreproducible +moreinfo Control: close -1 thanks As this bugs are only collecting spam and despite asking for more details the bug submitter did not provide them, closing this bugs as not actionable. (They are also marked as fixed with the version in stable.) (They can be reopened if needed, so no damage done.) -- tobi
Bug#1068534: RM: minetest [ppc64el riscv64] -- ROM; no longer builds on archs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: minet...@packages.debian.org Control: affects -1 + src:minetest User: ftp.debian@packages.debian.org Usertags: remove Upstream no longer supports building using the system-wide lua, so minetest will only build on platforms where lua-jit is available. This RM request will remove the binary packages for those archs where luagit is not available Thanks! -- tobi
Bug#1068436: transmission RFS
On Sat, Apr 06, 2024 at 06:43:08PM +, Barak A. Pearlmutter wrote: > Well, given that the main maintainer dropped themselves from the > debian/control file, I think the package can be freely adopted, > keeping Leo Antunes on of course in case he reappears. I'll drop the > two of them a note asking for objections, and assuming there are none, > I'd suggest we go ahead with that. What do you think? This would be: > > Maintainer: Leo Antunes > Uploaders: Alexandre Rossi , >Barak A. Pearlmutter > > and would allow "proper" uploads, not just NMUs. Note that the package is in the debian namespace on salsa. No need to NMU, team-uploads can be done by everyone. [1] [1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group -- tobi
Bug#1055064: ITP: libsilkit4 -- library for connecting software-in-the-loop environments
Control: tags -1 wontfix Control: close -1 Details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055448#19: Quote: sorry for the long wait. It took some time to fix all problems and synchronize efforts within Vector. Unfortunately, we do not have a plan for community contributions in the short/midterm. This might change in the future, we (the SIL Kit team) just cannot say when it will be happening. For now, we have made the decision to post pone our efforts to package SIL Kit within the Debian archive. Instead, we will shift development completely to the public Github repo and try to grow the community with the goal to accept patches in the future. I think the best is to close this ITP and revisit it once this is not oly stamped wit a Open Source license, but also living the principles of FOSS. On Mon, 30 Oct 2023 15:32:15 + =?iso-8859-1?Q?Kr=E4mer=2C_Jan?= wrote: > Package: wnpp > Severity: wishlist > > * Package name : libsilkit4 > Version : 4.0.37 > Upstream Author : Vector Informatik GmbH > * URL : https://github.com/vectorgrp/sil-kit > * License : MIT > Programming Lang: C++ > Description : library for connecting software-in-the-loop environments > > > The Vector SIL Kit is an open-source library for connecting Software- in-the-Loop Environments. One of the design goals of SIL Kit is to easily connect different third-party tools, such as emulators (such as QEMU), virtual machines and simulation tools. The goal of having this package within the Debian Package ecosystem is to provide users of SIL Kit an easy and unified way of installing and updating their installation of SIL Kit. > > We (Vector Informatik GmbH) would offer to package and maintain SIL Kit (libsilkit4). I (Jan Kraemer, jan.krae...@vector.com) would be the primary contact/proposed maintainer. But since we are new to the Debian community we are looking for a sponsor. > > >
Bug#1035312: minetest: New upstream version available (5.7.0)
On Thu, 7 Sep 2023 00:36:32 +0200 tuxayo wrote: > On Sun, 23 Jul 2023 10:10:17 +0200 Tobias Frost wrote: > > --> we will need to use the bundled lua. > > As a blanket solution yes. But IIUC it seems running the tests can tell > if a given Debian version is affected: > > https://github.com/minetest/minetest/issues/12778#issuecomment-1250255332 > > Effects you can expect if the test fails: Minetest continues to work > mostly normally, but memory leaks can happen and error handling might > not work correctly in edge cases. > > Cheers, > > -- > tuxayo > For documentatoon: minetest FTBFS with system-lua, upstream enforces it in their CMakeLists.txt: > CMake Error at src/CMakeLists.txt:718 (message): > It looks like you're trying to build Minetest using a system-wide > Lua > installation. This is no longer supported because PUC Lua cannot > interoperate with C++ correctly. Read src/unittest/test_lua.cpp for > technical details. > (and if that check is disabled, it will FTBFS later.) I'm disabling archs where lua-jit is not possible, as the bundled lua *might* (not verified!) have security issues unhandled and we're only loosing ppc64el in the set of release archtitecures. [1] [1]https://github.com/minetest/minetest/issues/12778#issuecomment-1251597494 -- tobi
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
On Fri, Apr 05, 2024 at 09:49:58PM +0200, Aurelien Jarno wrote: > On 2024-04-04 22:38, Bill Allombert wrote: > > On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote: > > > I'm not sure what I think about that. We have a general escape hatch > > > already for non-free packages in Policy 2.2.3 that says they may not fully > > > comply with Policy, which may be sufficient. > > > > But precisely, we _do_ want non-free packages that are built on the > > autobuilders > > to comply with this requirement. So we do not want 2.2.3 to apply in that > > specific case. It seems cleaner to say that the requirement only apply if > > Autobuild: yes is declared. > > If we go that route, here is a proposed alternative patch: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,7 +338,8 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > +Except for packages in the non-free archive with the ``Autobuild`` > +control field unset or set to ``no``, required targets must not attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. Seconded as well. (I think the other version is fine too; Another thought: Can't (some) non-free non-autobuildable be tought not do download at build time? I think it should be encouraged to download only if there is no other way…) -- tobi > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: > Hi, > > On 2024-04-03 12:37, Philipp Kern wrote: > > Hi, > > > > On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote: > > > On 2024-04-02 09:21, Sean Whitton wrote: > > > > Hello, > > > > > > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > > > > > > > The debian policy, section 4.9, forbids network access for packages in > > > > > the main archive, which implicitly means they are authorized for > > > > > packages in contrib and non-free (and non-free-firmware once #1029211 > > > > > is > > > > > fixed). > > > > > > > > > > This gives constraints on the build daemons infrastructure and also > > > > > brings some security concerns. Would it be possible to extend this > > > > > restriction to all archives? > > > > > > > > We need to know if this is going to break existing packages and allow > > > > some input from their maintainers. Are you able to prepare a list of > > > > the affected packages? > > > > > > Fair enough. I can work on that, but help would be welcome as my > > > resources are limited. > > > > I did a test rebuild of contrib, non-free and non-free-firmware packages > > in sid with both stable sbuild schroot and unshare backends and could > > not find a difference in build success (i.e. what failed failed in both, > > what succeeded succeeded in both). > > Thanks Philipp. Following that result, please find a patch proposal: > > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -338,9 +338,9 @@ > For example, the build target should pass ``--disable-silent-rules`` > to any configure scripts. See also :ref:`s-binaries`. > > -For packages in the main archive, required targets must not attempt > -network access, except, via the loopback interface, to services on the > -build host that have been started by the build. > +Required targets must not attempt network access, except, via the > +loopback interface, to services on the build host that have been started > +by the build. > > Required targets must not attempt to write outside of the unpacked > source package tree. There are two exceptions. Firstly, the binary > > Regards > Aurelien LGTM, Seconded. > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)
Control: fixed -1 0.9.1-2 correction: this has been fixed even in 0.9.1-2 already
Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)
Control: fixed -1 1 0.9.1-2 correction: this has been fixed even in 0.9.1-2 already
Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)
Control: fixed -1 1.0-1
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. -- tobi On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: > > Em 06/03/2024 05:49, Daniel Gröber escreveu: > > Hi Lucas, > > > > On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: > >>> Are you sure you want to change the source package name? Doing so fractures > >>> the history of the package on tracker.d.o and it's not really necessary. > >> The upstream has changed software name but it's a good point about > >> tracker.d.o. > > Right, so users will try to `apt install foolsm` in the future, but the > > source package name is largeley irellevant to them. > > > >>> Quick package review: > >>> > >>> - d/postinst: I don't think it's useful to print the message about editing > >>> the config. I've only seen packages do that in special circumstances, do > >>> you have a justification for it being necessary here? > >> Really, really not. I really would like improve that, I guess to write good > >> doc and manual pages is enough. > > I would argue users (sysadmins in this case) are going to be familiar with > > the concept of having to configure a package before it becomes useful and > > while the daemon not being started at package installation is > > unconventional in Debian automatic config reloading is by far not universal > > so any config change to make lsm useful is going to elicit a restart > > anyway. > > > > So I just don't see why we'd want a conspicuous message telling people what > > they already know :) > > > >>> - You declare Replaces+Conflicts on lsm but you don't seem to take any > >>> care for the new binary package to actually be compatible with the old > >>> one since the config location changed. > >> I'm in doubt, when the old config exist, if set dpkg to copy the old config > >> from old location to the new one or if I just print/show up a message to > >> users notifying about path update requirement. > > I think an automatic upgrade is the way to go in this case as long as the > > config format is still fully compatible to the old lsm-1.0.4, but since > > copying will leave cruft behind for the user to cleanup manually I think we > > should mv the config. > > > >> If it's good/allowed do the copy, it could be applied in postinst. I think > >> print/show up message is rightest way. > > Consider that people upgrade Debian systems for many, many years without > > reinstalling. So every bit of cruft we leave behind due to transitions such > > as this accumulates. I don't see a technical need for not doing so in this > > case so I think we should clean up behind ourselves and move the config to > > the new location. > > > > You should then absoluteley print a message in the log to note this fact, > > but perhaps not as conspicuously as you're printing the "configure me" > > message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice > > since the package(s) involved should be obvious from the filenames. > > Just uploaded to mentors again, now the update occur smoothly. > > > > > > --Daniel > > Thanks for taking time on testing update.
Bug#1067127: marked as done (RFS: emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake sources)
Control: reopen -1 Control: retitle -1 RFS: emacs-cmake-mode/3.29.0+ds-1 [Team] -- Emacs major mode for editing CMake sources Control: forcemerge -1 1067530 > Date: Sat, 23 Mar 2024 00:15:55 -0700 > From: Xiyue Deng > To: 1067127-d...@bugs.debian.org > Subject: Re: Bug#1067127: Acknowledgement (RFS: > emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake > sources) > User-Agent: Gnus/5.13 (Gnus v5.13) > > 3.29.0 has just been released. Will send a new RFS. Please do not open new RFS when the old one has not been sponsored. Instead, use the old one and update it accordingly. Thanks! > -- > Xiyue Deng
Bug#1067426: Package sponsorship request Qucs-S
Control: tags -1 moreinfo Hi Vadim, On Thu, Mar 21, 2024 at 04:56:43PM +0300, Vadim Kuznetsov wrote: > Package: sponsorship-requests > Severity: normal > > I am looking for a sponsor for my package "qucs-s": > > * Package name : qucs-s > Version : 24.1.0-1 > Upstream contact : Vadim Kuznetsov > * URL : https://github.com/ra3xdh/qucs_s > * License : GPL-2.0 > * Vcs : https://github.com/ra3xdh/qucs_s.git > Section : electronics| Some pointers to get started with packaging for Debian, so that it can be included in Debian: https://mentors.debian.net/intro-maintainers/ As you are upstream: https://wiki.debian.org/UpstreamGuide I've had a brief view at the debian/ directory on your repository, and there will be a bit work required to make your package suitable for inclusion into Debian, for example you'll need a debian/copyright file. I didn't look into further details, but I suggest to upload your package to mentors.debian.net, as this has already some QA built in and will help you to identify problems with your package, for example from the linitian tool. Then, when ready, remove the "moreinfo" tag from this bug report to get a proper review of the package. You'll also need to file a ITP bug (use "reportbug wnpp" to get a template). ITP stands for "Itent to Package" and declares that *you* want to package and maintain your package. (RFP as mentioned by Peter stands for Request To Package, that means you ask if someone else wants to package and maintain it, however, that needs someone volunteering, so it might never happen.)apt -- Cheers, tobi
Bug#1064027: RFS: mercurial-evolve/11.1.1-1
can you upload your dsc to mentors? TIA! On Thu, 15 Feb 2024 22:46:21 +0100 Georges Racinet wrote: > Package: sponsorship-requests > Severity: normal > X-Debbugs-Cc: andrew.shad...@collabora.co.uk, jcris...@debian.org > > Dear uploaders, > > I have pushed a new version 11.1.1-1 of the mercurial-evolve package to > https://salsa.debian.org/python-team/packages/mercurial-evolve > > Note that the previous version, 10.5.3, does not work with > the current Mercurial version (6.6) in unstable. > > Is anyone available to upload it to the archive? > > Thank you so much, > > Cc Andrew, who did the previous uploads, and Julien, who is the Mercurial > package maintainer. > > G. Racinet. > >
Bug#1066974: freecad: package got copletely removed from Debian testing
On Sat, Mar 16, 2024 at 10:04:34AM -0500, Kurt Kremitzki wrote: > The current status of this: > > - the Path workbench has a test which checks string equality on > generated vs expected G-code for an operation. On the i386 arch only, > the produced G-code is not what is expected, although it is > consistent. In a G-code viewer, what is produced is visually > identical, just with an increased number of arcs of shorter length. > I've patched this test with a special-case check to use a different > "expected" string id the arch is i386, and this works, even if not > elegant; the further yak-shaving needed has been discussed with > upstream. I think this is a feasible way forward. (I'd also not focus too much on i386, as this architecture is showing it's age and hardware supporting only i386 must be quite ancient in 2024, especially when doing CAD on it.) Said that, I think it makes sense to keep it working on a best effort basis, but this should not be a blocker for the other archs. IOW, I think your patch/approach is more than appropiate. > > - on armel, it seems FEM workbench tests are failing, but it isn't > enough to e.g. disable that workbench, because then the failures just > pop up elsewhere. I've repeated this "disable test, different test > segfaults elsewhere" pattern about 5 times. It seems like, for some > reason, the armel builds are no longer viable. It isn't ideal, but > FreeCAD is probably not getting much use on the arch, so it may be > that it ought to be removed from the architecture. I agree, armel is not the target audience for a CAD system, it is like i386, just worse by magintudes in terms of perfomance/usablity. > I would appreciate some feedback on these 2 items. I could do an > upload with a patch for the Path test and request armel removal if > nobody has any better suggestions or reservations about this approach. IMHO a sane solution. Thanks for caring! > Thanks, > Kurt signature.asc Description: PGP signature
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
Control: tags -1 moreinfo On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote: > tags 1065193 - moreinfo > thanks > > Hi Tobias, > > > > Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost: > > Hi Jörg, > > > > "debcheckout libhx" still gives me 4.17-1 as head. > > > > After looking at your repo, I think I should point you to DEP-14 > > as a recommended git layout for packaging. > > As the branch name indicates you are using per-package-revision > > branches: > > IMHO It makes little sense to have one branch per debian package > > version/revision; (I had a similiar discussion on vzlogger lately, > > so to avoid repetiions: #1064344#28) > > > > Please clarify how you want to manage the package in git, as > > this needs to be reflected in d/control's VCS-* fields correctly. > > (this is now blocking the upload.) > > I have been using Vincent Driessen's branching model and the corresponding git > extension gitflow-avh for at least 7 years with Debian and for a long time at > work. > > The default branch is master and development takes place in the develop > branch. > > The release candidates are managed in the branch release. The extension > debian/debian-version is used as a tag during the transfer. > > The master branch always contains the last published executable version to > which > the git tag in debian/control points. > a> The procedure is described in the README.debian. ok, won't further argue about how to organize your git repo, but I can only tell the Debian perspective: It is breaking expectations as a debcheckout libhx does today NOT give me a state that represents the package in unstable. VCS-Git specifies where the (package) development is happening [1]. [1] Policy 5.6.26 But as I am not using the git repo as base for the sponsoring, lets put that topic to rest. > > > > (The current fields say the package is maintained in the default branch > > of your repo. I see a debian/ directory there, but that one is missing > > released (it is at 4.17-1, while unstable is at 4.19-1.1) > > > > The review is based on the .dsc, timestamped on mentors.d.n > > 2024-03-17 12:00 > > > > d/changelog is *STILL* changing history for the 4.19-1 changelog > > block. (This issue must be fixed before upload.) > > > > I think these were artifacts because my changes to the NMU were not adopted. > Has > been corrected. No it has not. I expect old changelog entries to be *identical* to the ones that have been uploaded, and they still are not, so I fear we are talking past each other. Please let me know what you think that you have fixed, so that we can spot the different expectations. For my perspective: This is the diff from debian/changelog from the current version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45 You are still rewriting history (second hunk of this diff), this hunk should not exists. diff -Naur archive/libhx-4.19/debian/changelog mentors/libhx-4.23/debian/changelog --- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100 +++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100 @@ -1,3 +1,17 @@ +libhx (4.23-1) unstable; urgency=medium + + * New upstream release (Closes: #1064734). + * Add debian/.gitignore + * Remove not longer needed debian/libhx-dev.lintian-overrides. + * Fix debian/libhx32t64.lintian-overrides. + * debian/copyright: +- Add 2024 to myself. + * debian/control: +- Readd BD dpkg-dev (>= 1.22.5). + Thanks to Tobias Frost + + -- Jörg Frings-Fürst Sun, 17 Mar 2024 15:23:31 +0100 + libhx (4.19-1.1) unstable; urgency=medium * Non-maintainer upload. @@ -9,11 +23,8 @@ * New upstream release. - Refresh symbols files. - * Remove empty debian/libhx-dev.symbols. - * debian/rules: -- Remove build of libhx-dev.symbols. - -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 + -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 libhx (4.14-1) unstable; urgency=medium
Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C
Control: tags -1 moreinfo Hi itd, (Policy requires that the "Maintainer" has "their correct name and a working email address", see Policy §3.3. I know that there are exceptions, but I'm not sure about the conditions they require (for DMs/DDs, at least DAM needs to know your name, but I don't know the rules for Debian Contributors. Due to that, I will not sponsor this package, but I can certainly review the package.) On Sun, Mar 17, 2024 at 12:17:52PM +0100, itd wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "batsignal": > > * Package name : batsignal >Version : 1.8.0-1 >Upstream contact : https://github.com/electrickite/batsignal > * URL : https://github.com/electrickite/batsignal > * License : ISC > * Vcs : https://salsa.debian.org/itd/batsignal >Section : utils > > The source builds the following binary packages: > > batsignal - Lightweight battery daemon written in C > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/batsignal/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/b/batsignal/batsignal_1.8.0-1.dsc > > Changes for the initial release: > > batsignal (1.8.0-1) unstable; urgency=medium > . >* Initial release. Inital releases needs an ITP bug. Please file one and add the appropiate Closes: # stanca. > I would like to move the Vcs to /debian/batsignal, whenever that is > convenient. Let me know your salsa username and I'll make that happen. A short, possibly incomplete review: - d/copyright: I suggest to have the same license for debian/* as for upstream, as this eases forwarding patches etc. Though ISC is considered by the FSF to be compatible with the GPL, this is likely fine too to keep it at is is. - d/watch / this dsc uscan download this: c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1 batsignal_1.8.0.orig.tar.gz your dsc contains: d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b batsignal_1.8.0.orig.tar.xz when constructing your dsc, please make sure to use the same file as uscan would produce. (I've verified that the content of both orig files is identical) Package looks good, otherwise. Make sure to remove the moreinfo tag when the above issues are fixed. Cheers, -- tobi > Regards, > -- itd >
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
Hi Jörg, "debcheckout libhx" still gives me 4.17-1 as head. After looking at your repo, I think I should point you to DEP-14 as a recommended git layout for packaging. As the branch name indicates you are using per-package-revision branches: IMHO It makes little sense to have one branch per debian package version/revision; (I had a similiar discussion on vzlogger lately, so to avoid repetiions: #1064344#28) Please clarify how you want to manage the package in git, as this needs to be reflected in d/control's VCS-* fields correctly. (this is now blocking the upload.) (The current fields say the package is maintained in the default branch of your repo. I see a debian/ directory there, but that one is missing released (it is at 4.17-1, while unstable is at 4.19-1.1) The review is based on the .dsc, timestamped on mentors.d.n 2024-03-17 12:00 d/changelog is *STILL* changing history for the 4.19-1 changelog block. (This issue must be fixed before upload.) Thanks for re-adding the B-D on dpkg-dev. So, please elaborate on the git issue (so that the correct VCS-* can be confirmed or specified) , and fix the rewriting history part, and I'll upload Remove the moreinfo tag when ready. Cheers, -- tobi On Sun, Mar 17, 2024 at 01:48:57PM +0100, Jörg Frings-Fürst wrote: > Hello Tobias, > > thanks for your review. > > > Am Donnerstag, dem 14.03.2024 um 17:53 +0100 schrieb Tobias Frost: > > Control: tags -1 moreinfo > > > > Hi Jörg, > > > > d/copyright: > > you are changing history: > > > > diff -Naur archive/libhx-4.19/debian/changelog > > new/libhx-4.23/debian/changelog > > (...) > > * debian/rules: > > - Remove build of libhx-dev.symbols. > > > > - -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 > > + -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 > > > > libhx (4.14-1) unstable; urgency=medium > > > > - you git repository seems to missing commits. a debcheckout libhx > > gives me 4.17-1 in d/changelog. > > Sorry, that's my mistake. > > > > > - please don't drop the Build-Depends: dpkg-dev (>= 1.22.5), the > > time_t transition requires it, > > > > Ok. I have add it. > > > -- > > tobi > > > > CU > Jörg > > -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://git.jff.email/cgit/ > > Skype:jff-skype@jff.email > Jami: joergfringsfuerst > Telegram: @joergfringsfuerst > Matrix: @joergff:matrix.snct-gmbh.de > > My wish list: > - Please send me a picture from the nature at your home. > > > >
Bug#1064605: [ftpmas...@ftp-master.debian.org: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED]
On Sun, Mar 17, 2024 at 01:46:39PM +0100, Geert Stappers wrote: > > Hi, > > > In an attempt to express my appreciation for working rustup in Debian, > this forwarded message. > > - Forwarded message from Debian FTP Masters - > > Date: Sun, 17 Mar 2024 11:32:47 + > From: Debian FTP Masters > To: Debian Rust Maintainers , > t...@debian.org, Zixing Liu > Subject: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED > > > > rustup_1.26.0-5.dsc: Refers to non-existing file 'rustup_1.26.0.orig.tar.xz' > Perhaps you need to include the file in your upload? > > If the orig tarball is missing, the -sa flag for dpkg-buildpackage will be > your friend. The problem was the the sponsoree's dsc included a different orig.tar, (identical in content, but compressed with xz; If I'd had to guess maybe gbp created that one.) I've reuploaded alrady with the one using the one in the archives, so this should(tm) appear soon. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > > > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > > > - End forwarded message - > > > > > Regards > Geert Stappers > Should be working on making it possible to be ready > for the next RFS for rustup > -- > Silence is hard to parse >
Bug#1065197: RFS: cevomapgen/31-1 [ITP] -- External Map Generator for C-Evo
Control: tags -1 moreinfo Hi Peter, (There was also #1040494, which seems not to have been sponsored. In this case, please reopen the old RFS bug and don't file new bugs.) Here's a very short review, (including copyright review) - lintian: - Comments should be directly over the overriden tag, otherwise the override justification is not correctly picked up - O: cevomapgen: no-manual-page [usr/games/cevomapgen] I disagree this should be overriden, and I disagree that gui programs don't need a manpage. - d/copyright I see that there are files with years from 1999-2023 and one 2024. Please review your d/copyright file and record the years correctly. -- tobi On Fri, Mar 01, 2024 at 07:53:12PM +, Peter Blackman wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "cevomapgen": > > * Package name : cevomapgen > Version : 31-1 > Upstream contact : Peter Blackman > * URL : https://sourceforge.net/projects/cevomapgen/ > * License : GPL-3+ > * Vcs : https://salsa.debian.org/PeterB/cevomapgen > Section : games > > The source builds the following binary packages: > > cevomapgen - External Map Generator for C-Evo > > > cevomapgen is a tool for use with c-evo-dh > https://tracker.debian.org/pkg/c-evo-dh > a strategy game with some similarities to Freeciv > > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/cevomapgen/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/c/cevomapgen/cevomapgen_31-1.dsc > > Changes for the initial release: > > cevomapgen (31-1) unstable; urgency=medium > . > * Initial release (Closes: #1035747) > > Regards, > -- > Peter Blackman >
Bug#1065197: RFS: cevomapgen/31-1 [ITP] -- External Map Generator for C-Evo
> The source builds the following binary packages: > > cevomapgen - External Map Generator for C-Evo > > cevomapgen is a tool for use with c-evo-dh > https://tracker.debian.org/pkg/c-evo-dh Would it make sense to call it also c-evo-mapgen, to use the same scheme as the game package?
Bug#1065682: RFS: c-evo-dh/1.11-1 -- Empire Building Game (data files), C-evo: Distant Horizon
Control: tags -1 moreinfo Hi Peter, Some review - source packages do not have a Description: field, only binary packages. - note that changing previous d/changelog entries should be only done in rare circumtances, for example annotating CVEs to earlier uploads, not known then. I don't see the necassity for that history rewriting here, so please don't do that. Additional confusion can arise, if you change the timestamp of historical changelog entries. Don't do that either. Please revert those changes. Cheers, -- tobi On Fri, Mar 08, 2024 at 08:58:59PM +, Peter B wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "c-evo-dh": > > * Package name : c-evo-dh > Version : 1.11-1 > Upstream contact : Peter > * URL : https://sourceforge.net/projects/c-evo-eh/ > * License : CC0-1.0, GPL-2+, CC-BY-SA-3.0-US, CC-BY-3.0 > * Vcs : https://salsa.debian.org/PeterB/c-evo-dh > Section : games > > The source builds the following binary packages: > > c-evo-dh-gtk2 - Empire Building Game (GTK2), C-evo: Distant Horizon > c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon > c-evo-dh-data - Empire Building Game (data files), C-evo: Distant Horizon > > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/c-evo-dh/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.11-1.dsc > > > Changes since the last upload: > > c-evo-dh (1.11-1) unstable; urgency=medium > . > * New Upstream Release > * Missing change in changlog for (1.10-1) > * Update d/copyright date > * Drop lintian override on missing man page for libexec binary > * Add source package description in d/control > * Strip trailing whitespace from d/c-evo-dh-gtk2.install > > Regards, > -- > Peter Blackman >
Bug#1066079: RFS: ddclient/3.11.2-1 -- address updating utility for dynamic DNS services
Control: tags -1 moreinfo Hi Richard, On Tue, Mar 12, 2024 at 12:52:09AM -0700, Richard Hansen wrote: > * Package name : ddclient >Version : 3.11.2-1 >Upstream contact : https://github.com/ddclient/ddclient > * URL : https://ddclient.net > * License : GPL-2.0+, Artistic or GPL-1+, Apache-2.0 > * Vcs : https://salsa.debian.org/debian/ddclient >Section : net > > > ddclient (3.11.2-1) unstable; urgency=medium > . >* Add curl build dependency to enable the -curl argument >* Suggest curl The package now "Depends" on curl, not "Suggests" it. As this conflicts with the d/ch entry, can you clarify? >* Bump Standards-Version to 4.6.2 (no changes needed) >* gbp.conf: Rename branches and tags to match current convention >* gbp.conf: Set upstream-vcs-tag (for import-orig) >* New upstream version 3.11.2 >* Refresh patches >* Update dependencies >* Use dh_installchangelogs to install ChangeLog.md >* debian/copyright: Set Upstream-Contact to project URL >* debian/copyright: Update copyright year for debian/* There are more changes, undocumented, like droping some B-Ds. Please expand on the "why" a change is made over the "what", as this helps reviewing. > Regards, -- Cheers, tobi
Bug#1065442: RFS: shaderc/2023.8-1 [RC] -- Library API for accessing glslc functionality - shared libraries
Hi Philippe, Seems so that upstream has released a new version last week, but as you package looks fine, lets upload that one first ;) d/copyright: - upstream years needs to include at least 2023 (e.g for glslc/test/option_fpreserve_bindings.py) - kokoro needs also 2023 for Google. Otherwise, it looks fine to me, and fixing the RC bugs has priority, so uploaded. Please fix the copyright years for the next upload nethertheless and take a look at the lintian stuff, for example if usr/bin/glslc needs hardening and whether it makes sense to install the examples into the -dev packagse, as well as there are two typos mentioned by linitan. Thanks for your contribution to Debian! -- cheers, tobi On Mon, Mar 04, 2024 at 09:19:57PM +0100, Philippe SWARTVAGHER wrote: > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "shaderc": > > * Package name : shaderc >Version : 2023.8-1 >Upstream contact : David Neto > * URL : https://github.com/google/shaderc/ > * License : Apache-2.0, BSD-3-clause > * Vcs : https://salsa.debian.org/debian/shaderc >Section : libs > > The source builds the following binary packages: > > glslc - Command line compiler for GLSL/HLSL to SPIR-V > libshaderc-dev - Library API for accessing glslc functionality - > static libraries and headers > libshaderc1 - Library API for accessing glslc functionality - shared > libraries > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/shaderc/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2023.8-1.dsc > > Changes since the last upload: > > shaderc (2023.8-1) unstable; urgency=medium > . >* New upstream release > - Refresh patches > - Add patch to fix name of Python interpreter > - Fix FTBFS (Closes: #1058397) > - Refresh d/glslc.lintian-overrides >* Fix linking of libshaderc.so, add autopkgtest (Closes: #1029939) >* Add obj-x86_64-linux-gnu to d/clean >* Use printf instead of echo to generate build-version.inc. Thanks to > Vagrant Cascadian! (Closes: #1035324) >* Build-Depends on pkgconf instead of pkg-config >* d/copyright: update copyright year > > Regards, > -- > Philippe >
Bug#864255: Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags 864255 pending Hi Joachim, uploaded. Thanks for your contribution to Debian! As this is a new package, it will be in the NEW queue [1] until the package is accepted by the FTP masters. (As we are done with the RFS, I'll close the RFS bug with this mail too) Cheers, -- tobi [1] https://wiki.debian.org/NewQueue signature.asc Description: PGP signature
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote: > libhx (4.23-1) experimental; urgency=medium Note: the dsc file targets unstable, not experimental. The review was using unstable as target. -- tobi
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
Control: tags -1 moreinfo Hi Jörg, d/copyright: you are changing history: diff -Naur archive/libhx-4.19/debian/changelog new/libhx-4.23/debian/changelog (...) * debian/rules: - Remove build of libhx-dev.symbols. - -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 + -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 libhx (4.14-1) unstable; urgency=medium - you git repository seems to missing commits. a debcheckout libhx gives me 4.17-1 in d/changelog. - please don't drop the Build-Depends: dpkg-dev (>= 1.22.5), the time_t transition requires it, -- tobi On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote: > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "libhx": > > Package name : libhx > Version : 4.23-1 > Upstream contact : Jan Engelhardt > URL : https://inai.de/projects/libhx/ > License : LGPL-2.1+, WTFPL-2+, GPL-2+ > Vcs : https://git.jff.email/cgit/libhx.git > Section : libs > > The source builds the following binary packages: > > libhx32t64 - C library providing queue, tree, I/O and utility functions > libhx-dev - Development files for libhx > libhx-doc - Documentation files for libhx > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/libhx/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/libh/libhx/libhx_4.23-1.dsc > > or from > > git https://git.jff.email/cgit/libhx.git?h=release%2Fdebian%2F4.23-1 > > > > Changes since the last upload: > > libhx (4.23-1) experimental; urgency=medium > . > * New upstream release (Closes: #1064734). > * Add debian/.gitignore > * Remove not longer needed debian/libhx-dev.lintian-overrides. > * Fix debian/libhx32t64.lintian-overrides. > * debian/copyright: > - Add 2024 to myself. > > > > CU > > Jörg > > > -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://git.jff.email/cgit/ > > Skype:jff-skype@jff.email > Jami: joergfringsfuerst > Telegram: @joergfringsfuerst > Matrix: @joergff:matrix.snct-gmbh.de > > My wish list: > - Please send me a picture from the nature at your home. > > > >
Bug#1065374: RFS: sane-backends/1.3.0-1 -- API development library for scanners
Control: tags -1 moreinfo Hi Jörg, isfdtype(3) says the header you need to include is #include #include Any reason why you don't include the header but use a forward declaration instead? -- tobi
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim && dpkg --compare-versions $2 le-nl 0.8.3 \ && dpkg --compare-versions $2 ge 0.8.2; then - $2 might be empty, you need to quote it: use "$2" otherwise dpkg will fail: $ dpkg --compare-versions $empty le-nl 0.8.3 dpkg: error: --compare-versions takes three arguments: Type dpkg --help for help about installing and deinstalling packages [*]; Use 'apt' or 'aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Options marked [*] produce a lot of output - pipe it through 'less' or 'more' ! -- tobi
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -1 moreinfo Hi Joachim approaching upload :) beside the remark on postinst below, packaging is looking good already. d/copyright: - minor thing, please write in d/copyright "GPL-3.0-or-later" as license indicator, as this makes it clearer. - the debian/ directory - change the year to 2023-2024 -modules/GetGitRevisionDescription.cmake* is undocumented and licensed under modules/GetGitRevisionDescription.cmake (copyright review done) On Thu, Mar 07, 2024 at 06:02:56AM +0100, Joachim Zobel wrote: > Control: tags -moreinfo > > Hi Tobias. > > Thanks for looking into the package. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > d/source/lintian-overrides > > - delete the overrides, seems to be some remnant of earlier packaging. > > > > d/DEBIAN_RELEASE.txt > > - delete this file; the information contained in this files would not > >be a process how to create a package for Debian. (and if you need a > >file describing certain unusal aspects of the Debian packaging, it > >would be README.source (see Debian Policy §4.14) > >I recommend checking out git-buildpackage: > >https://honk.sigxcpu.org/piki/projects/git-buildpackage/ > >https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ > >- remove Debian_release.patch -- this is not needed, you work with > >your debian/ directory and evolve it, you do not patch it when you > >create a new version. > > > > d/control > > - specify Rules-Require-Root > > - you manually depend on libsml1. Can you expand why this is needed? > > - Build-Depend: s/pkg-config/pkgconf > > - remove versions from the versioned build dependencies, if the > >debpendency is already fulfilled in oldstable: > >- libjson-c-dev, libcurl4-openssl-dev, > > > > > > d/postinst / postrm > > - When you create a user, it should start with "_" - see policy 9.2.1 > >- Another option might be using systemd's DynamicUser feature to > > create the user at runtime. (bonus: some hardening for free.) > >- there's systemd-sysuser (works also without systemd as init system) > > to use sysusers.d > >- do not delete users/groups on package removal. > > All changes have been done. In addition the repository has been moved > to DEP-14 layout. Thanks! I see that you've decided to migrate the user. However, you should do so only when the package is upgraded from an old version, which had the old name, to avoid collisions down the road. your postinst needs a conditional based on the old version, (which is be passed to postinst.) Those might be helpful: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html# https://www.debian.org/doc/debian-policy/ap-flowcharts.html deb-postinst(5) Example for how to check for the required version using dpkg --compare-version: https://codesearch.debian.net/show?file=pam-pgsql_0.7.3.2-1%2Fdebian%2Fpostinst=32 -- tobi signature.asc Description: PGP signature
Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading
On Sun, Mar 10, 2024 at 04:25:16PM +0100, Tobias Frost wrote: Maybe this needs a bit more expansion: > Having two sources of packages is bad too, I'd suggest to stop > distribution your own packages, at least make sure not to use the same > exact same version/revision, so that there will be clear from looking on > the version only that this was from your archives. Otherwise, I'll > envise chaos. Make sure that the version in your archives sort earlier > than the one in Debian's as this sould be the canonical source of the > Debian packages. Such a versioning scheme is also used for backports, > you can look there how it is done. If you ship packages yourself, you should ensure that if people installing from Debian archives they will get the Debian package not yours, at least if the version in the Debian archive is not of an older version. This is similar to the procedure when doing a backport, the backport version is always "older" than then the version in testing, so that when testing becomes stable the proper package from now-stable is installed, updating the backports package. An easy way is to append "~" to your upstream package's revision, as this will always sort earlier, eg. "7.20-3~" -- tobi
Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading
Control: tags -1 moreinfo Hi John, thanks for the fixes you've already applied, but the package needs more work to be Debian compliant. On Wed, Feb 28, 2024 at 11:10:58AM +1100, John Zaitseff wrote: > Control: retitle -1 trader/7.20-2 -- simple game of interstellar trading > Control: tags -1 - moreinfo > > Dear Tobias, > > Thank you very much for your feedback on my RFS for Star Traders, > and apologies for not replying sooner -- it's been a bit of a crazy > week around here... > > You (or anyone else) can see my latest Git tree at the following > URL; this tree reflects the changes I've made as a result of your > email: > > https://www.zap.org.au/git-browser/trader.git/tree/?h=with-debian > git clone https://git.zap.org.au/git/trader.git -b with-debian > > I do have a few questions and observations about your comments: > > > d/control: > > - Please remove all versions from the versioned build depends that > > are fulfiled already since oldstable, e.g gettext and automake. > > Good catch! This is what happens when one maintains a Debian > package outside the distro since 2011... > > Given that the Git tag for package version 7.20-1 already exists > (and has been distributed!), I've released the new package as > 7.20-2, with the entry for 7.20-1 removed as it has not been > uploaded to Debian. Well, the first Debian revision should be -1, and I wonder why you are repeating that mistake with -3? At least that one should have been kept at -2. To avoid confusion, a "-1" with the suite "UNRELEASED" could been added to the changelog, so that people know what's happening. In future, don't bump the Debian revision unless it has been sponsored. Having two sources of packages is bad too, I'd suggest to stop distribution your own packages, at least make sure not to use the same exact same version/revision, so that there will be clear from looking on the version only that this was from your archives. Otherwise, I'll envise chaos. Make sure that the version in your archives sort earlier than the one in Debian's as this sould be the canonical source of the Debian packages. Such a versioning scheme is also used for backports, you can look there how it is done. Regarding the revision -3: You write "New upstream relases", that is wrong, or at least you are using the terminology wrong. A new upstream release must have a new upstream version , and a new orig.tar corresponding to the new upstream version. Yours are the same. To have a way out, and as you are upstream, how's about cutting a new upstream release, e.g 7.21 and package it as 7.21-1 ? > I'm retitling this bug report to suit. If you > prefer, I can close this RFS and open a new one. You did it right, you don't file new RFS bugs if the previous one hasn't been sponsored. > You can now download the updated package by running: > > dget -x > https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-2.dsc (Please utilize mentors, mentors has some diagnositics that helps analyzing/reviewing the package, e.g lintian output.) > > - Your VCS-Git link git:// is not using an encrypted link, but the > > site supports https://. Please use https. > > Done. > > > d/copyright: > > - the directory lib/ has files which are not documented in > > d/copyright; (They have a different license and copyright) > > - same for the m4 macros > > Hmm. The files (in lib and m4) that are not my own are mostly from > the Gnulib GNU Portability Library. Rather tedious and quite a bit > of work, but I've updated the debian/copyright file to suit. > I find it interesting that you're the first Debian developer to pick > up on this: previous sponsors of the package were okay with it the > way it was. Perhaps you're more thorough! If it leads to a better > Debian package, I don't mind. > > However, I note from section 2.3 of the Debian policy manual: > > Thus, the copyright information for files in the source package > which are only part of its build process, such as autotools files, > need not be included in /usr/share/doc/PACKAGE/copyright, because > those files do not get installed into the binary package. > > My reading of that suggests there is no need to include copyright > stanzas for files in the m4 directory. Is this understanding > correct? Well, I'm used to that that they should be also documented and probably I'm more strict than other on this; Ok, then leave them alone... > This is what I've added to debian/copyright -- is this okay? > > Files: lib/* > Copyright: 1987-2024, Free Software Foundation, Inc. > License: GPL-3+ > Comment: >Some files in this directory (from the Gnulib GNU Portability Library) >are licensed by the Free Software Foundation under LGPL-2.1+; other >files are under GPL-2+. When combined with the remaining files from the >same Gnulib library, these inherit the overall GPL-3+ licence. no, that's not ok. you need to document the copyright *verbatim*, that is
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
On Tue, Feb 27, 2024 at 06:50:56AM +0100, Joachim Zobel wrote: > Hi. > > Thanks for taking the time to review my package. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > d/postinst / postrm > > - When you create a user, it should start with "_" - see policy > > 9.2.1 > This has been implemented and is on its way, see > https://github.com/volkszaehler/vzlogger/pull/628 > > It was a bit complicated because I need to rename an existing user. > There are installations of the existing native package. I am therefore > unsure if it is good to do this. Going by the letter which is > "When maintainers choose a new hardcoded or dynamically generated > username" the username has already been choosen when the > debian/vzlogger.init script was created. > > Since it is a now or never situation and since the number of existing > installations is still low I tend to rename the user. Any opinions are > appreciated. If you think the existing user base is large enough, you can also migrate the username, if you detect in your postinst script that you are upgrading from an version with the old username. (This code could then be dropped in trixie+1, assuming the package will be in trixie, of course) > Sincerely, > Joachim >
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim, On Sat, Feb 24, 2024 at 06:37:02PM +0100, Joachim Zobel wrote: > Hi. > > I'll reply to the DEP-14 issue while working on the others. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > > https://github.com/volkszaehler/vzlogger.git > > > > > > on branch debian-0.8.3-1. > > > > (There is no such branch on that repo, but a "debian" one.) > > Sorry, forgot to merge that. > > > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for > > recommendation how to layout the repository used for packaging, I'd > > even recommend to use an extra repository for the packaging. > > I know about DEP-14 and actually tried it. I found it however very > inconvenient to use and I think this is because it is inappropriate for > the current situation. Sorry, I don't get what you mean. Why is it inappropiate? Putting DEP14 (branch names[1]) aside, Debian packagaing is supposed to be "linear", you work on a package, upload it, and the next iteration you base your work on the already uploaded version. It makes no sense to have a branch for every Debian package revision, because once it has been uploaded it will become immuteable, you cannot reupload the same revesion, the upload will be rejected. We *tag* Debian package releases to mark them, and when the next one is ready, it will be based on the old revision, so it is more natural to continue on that branch. Also, you are supposed to note the branch in VCS-Git where packaging is happening, and this is _a_ branch (that's singular!), see the Debian Policy for extra reasoning. [1] which are only getting important if you need to manage different Debian release suites or backports on top. the scheme /, e.g debian/unstable is meant to aid here. note: you cannot have branches "debian" _and_ "debian/$suite", because git won't allow that. If you use "debian" as branch, this will make it harder to deploy DEP14 later. > The package is maintained in the upstream repository as a native > package (by me). This is necessary because Debian packages are built as > part of the upstream releases. So all packaging changes happen upstream > first. If you are in control of upstream packaging, well, frankly, than you are in control to do things propoerly upstream. The first thing is: stop building native packages. Native packages are the wrong approach 99% of the time. [2] This will also save you a lot of time, you won't need to maintain two flavours. (As Debian packages need to follow Debian rules and not upstream rules, a native package will not be acceptable for Debian.) The upstream guide discourages to have a debian/ directory in the upstream main branch [3], but if you do, and base your packaging on it. Having a debian directory in "main" and another branch, especially if they are divereged, will only confuse people. (and they might to need to work on your package, e.g if there is a need for an NMU.) So pick one. [2] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native [3] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source, third paragraph. > The changes that are later needed to turn an upstream native > release into a Debian release are few and won't change much over time. > So a patch makes sense IMHO. As said, native is wrong anyways, but the packaging directory should be orthogonal to the upstream version, as the upstream version needs also to work on non-Debian systems, don't they? > This situation can change when vzlogger reaches stable (and as a result > reaches Raspbian). At that point maintaining a package in the upstream > repo is no longer necessary. This sounds wrong. Either you package in an dedicated repository, or you don't. That is orthogonal to whether the package is in Debian or not. > For now I would prefer to use the suggested release workflow (which I > am already using for libsml, where the situation is the same). tracker.d.o is unhappy: "The VCS repository is not up to date, push the missing commits." Your process breaks tooling in Debian. It is broken. > I am > aware that the DEP-14 layout works well if upstream is not doing > package maintenance and I am not generally against it. It is not significant for DEP-14 whether upstream is doing package maintaince or not. In your instance,
Bug#1062832: opencascade: NMU diff for 64-bit time_t transition
On Fri, Mar 01, 2024 at 12:00:43AM -0800, Steve Langasek wrote: > Hello, > > > I'm currently preparing the transistion to the next opencascade > > version that require new packages anyway, as upstream does not > > handle SONAMES very well. This NMU will only make me additional work. > > So, when do you intend that transition to land? opencascade has > reverse-dependencies in the archive, and rebuilds of any of those packages > *now* will result in ABI skew and breakage. Fair enough, go ahead with upload, I'll tackle the new upstream version later. (Appologies for the mess, plans on my side didn't work out) -- tobi > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -1 moreinfo Hi Joachim, review based on the dsc containing: Checksums-Sha256: 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 vzlogger_0.8.3.orig.tar.gz c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 vzlogger_0.8.3-1.debian.tar.xz It is only a partial review, especially I did not do a d/copyright review yet. Please check my remarks and remove the moreinfo tag when ready. On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "vzlogger": > > * Package name : vzlogger > Version : 3.1-4 > Upstream contact : Joachim Zobel > * URL : http://wiki.volkszaehler.org/software/controller/vzlogger > * License : GPL-3 > * Vcs : https://github.com/volkszaehler/vzlogger > Section : net > > The source builds the following binary packages: > > vzlogger - program to read measurements from smart meters and log them > to Influxdb or forward them via MQTT. > > vzlogger is a tool to read and log measurements of a wide variety of > smart meters and sensors. It supports various commonly used protocols > such as s0, d0, sml, oms and others. It can write these data to an > Influxdb, forward them via MQTT, make them available via HTTP or eport > them to a volkszaehler.org middleware. > > The package is maintained in the upstream repository. Upstream (which I > am part of) currently builds native packages. These are patched (a > switch from native to quilt, a different changelog and a version >= 3.0 > for the dependency on openssl) to make them more suitable for debian. > The package is therefore availabe in the upstream repo Yeah, format 3.0 quilt is the way, it is not a native package. > https://github.com/volkszaehler/vzlogger.git > > on branch debian-0.8.3-1. (There is no such branch on that repo, but a "debian" one.) Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for recommendation how to layout the repository used for packaging, I'd even recommend to use an extra repository for the packaging. > Alternatively, you can download thepackage with 'dget' using this > command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc > > Regards, > -- > Joachim Zobel As you are upstream: https://wiki.debian.org/UpstreamGuide d/source/lintian-overrides - delete the overrides, seems to be some remnant of earlier packaging. d/DEBIAN_RELEASE.txt - delete this file; the information contained in this files would not be a process how to create a package for Debian. (and if you need a file describing certain unusal aspects of the Debian packaging, it would be README.source (see Debian Policy §4.14) I recommend checking out git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ - remove Debian_release.patch -- this is not needed, you work with your debian/ directory and evolve it, you do not patch it when you create a new version. d/control - specify Rules-Require-Root - you manually depend on libsml1. Can you expand why this is needed? - Build-Depend: s/pkg-config/pkgconf - remove versions from the versioned build dependencies, if the debpendency is already fulfilled in oldstable: - libjson-c-dev, libcurl4-openssl-dev, d/postinst / postrm - When you create a user, it should start with "_" - see policy 9.2.1 - Another option might be using systemd's DynamicUser feature to create the user at runtime. (bonus: some hardening for free.) - there's systemd-sysuser (works also without systemd as init system) to use sysusers.d - do not delete users/groups on package removal. As you are involved with upstream: The manpage, initfile, systemd service file should probably be included in the upstream part, it is not only useful for Debian alone. Linitian emits: W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config (>= 0.25) => pkgconf W: vzlogger: groff-message troff::5: warning: cannot select font 'CB' [usr/share/man/man8/vzlogger.8.gz:1] I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12] I: vzlogger: file-references-package-build-path [usr/bin/vzlogger] I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a] I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger] I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] I: vzlogger source: unused-override odd-historical-debian-changelog-version *0.3.4-rc1* [debian/source/lintian-overrides:2] P: vzlogger source: capitalization-in-override-comment odd-historical-debian-changelog-version debian Debian [debian/source/lintian-overrides:1] P: vzlogger source: silent-on-rules-requiring-root
Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading
Control: tags -1 moreinfo Hi, some review: d/control: - Please remove all versions from the versioned build depends that are fulfiled already since oldstable, e.g gettext and automake. - Your VCS-Git link git:// is not using an encrypted link, but the site supports https://. Please use https. d/copyright: - the directory lib/ has files which are not documented in d/copyright; (They have a different license and copyright) - same for the m4 macros embedded code copies: - gnulib is packaged for Debian, any reason why you don't use the packaged version? - there are m4 macros from autoconf-archive. Please check if you can use the ones from the package autoconf-archive. Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata d/changelog - d/changelog's purpose is to document changed to the packageing, generaly not to document upstream changes, so I'd cut that down to: trader (7.20-1) unstable; urgency=low * New upstream release. * Updated to Debian Policy 4.6.2 (no changes). - lintian findings: W: trader: groff-message troff::133: warning: macro 'mR' not defined [usr/share/man/man6/trader.6.gz:1] I: trader source: public-upstream-key-not-minimal has 16 extra signature(s) for keyid 0D254111C4EE569B [debian/upstream/signing-key.asc] I: trader source: vcs-field-uses-insecure-uri Git git://git.zap.org.au/data/git/trader.git -b with-debian P: trader source: source-contains-autogenerated-gperf-data [lib/iconv_open-hpux.h] P: trader source: source-contains-autogenerated-gperf-data [lib/iconv_open-irix.h] P: trader source: source-contains-autogenerated-gperf-data [lib/iconv_open-osf.h] P: trader source: source-contains-autogenerated-gperf-data [lib/iconv_open-solaris.h] P: trader source: source-contains-autogenerated-gperf-data [lib/iconv_open-zos.h] Cheers, -- tobi On Wed, Jan 31, 2024 at 10:59:26AM +1100, John Zaitseff wrote: > Hi, Bastian et al., > > > > > 7.19-1 was never uploaded to Debian, so please remove it from > > > > the changelog. > > > > > > Would this still be the case even though I _did_ release it on > > > The ZAP Group Australia's repository? If so, how would I > > > preserve the changes listed for v7.19 -- should I just add them > > > as part of the 7.20-1 changelog entry? > > > > Yes, you should do that. Alternatively, you can upload 7.19-1 > > before uploading 7.20-1. > > I have removed the changelog entry for 7.19-1; the entry for 7.20-1 > now reads: > > trader (7.20-1) unstable; urgency=low > >* New upstream release: changed documentation (history of the game), > updated Swedish, Norwegian Bokmål, French, German, Serbian, Esperanto, > Romanian, Polish and Ukrainian translations. >* Incorporates changes made to previous upstream release (not uploaded > to Debian): new Polish, Romanian and Ukrainian translations, renamed > AppStream metainfo and desktop files. >* Require at least Gettext 0.21 and Automake 1.16 for building. >* Updated to Debian Policy 4.6.2 (no changes). > > Could you (or someone) now sponsor the package? The original link > now points to the updated package: > > dget -x > https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-1.dsc > > Yours truly, > > John Zaitseff > > -- > John Zaitseff ╭───╮ Email: j.zaits...@zap.org.au > The ZAP Group │ Z │ GnuPG: 0x0D254111C4EE569B > Australia Inc. ╰───╯ https://www.zap.org.au/~john/ >
Bug#1064354: steam-installer: Unable to install steam-installer
Control: tags -1 moreinfo Hi Wesley, On Tue, Feb 20, 2024 at 01:24:30PM -0400, Wesley Schwengle wrote: (...) > I've also tried to install it by executing: > > sudo dpkg --add-architecture i386 > > to no avail. (...) > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), > (10, 'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), > (10, 'oldoldstable'), (10, 'stable'), (10, 'oldstable') > Architecture: amd64 (x86_64) You system information indicates that the i386 archictecure has NOT been added, as I would expect a "Foreign Architectures: i386" in the System Information" section. Please recheck if the addition of the architecutre has worked, and remember you'll need to apt update afterwards, Checking in a chroot, I get the exact error message as you are getting, when there is _no_ i386 architecture added, but after adding it and after apt-update, steam-installer can be installed. -- Cheers, tobi
Bug#1056284: nss: CVE-2023-5388
Control: tags -1 fixed-upstream patch Upstream Patch: https://hg.mozilla.org/projects/nss/rev/196716d8377ab427e326f20bff2d026e90ac69e2 Cheers, -- tobi
Bug#1063704: RFS: tiny-initramfs/0.1-5.1 [NMU] [RC] -- Minimalistic initramfs implementation (automation)
Hi Victor, uploaded to DELAYED/5 and sent the nmudiff to the package. Thanks for your contributions to Debian! Cheers, -- tobi On Sun, Feb 11, 2024 at 12:10:48PM +0100, Victor Westerhuis wrote: > Package: sponsorship-requests > Severity: important > X-Debbugs-Cc: christ...@iwakd.de > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dear mentors, > > I am looking for a sponsor for "tiny-initramfs". The current version of > the package is unusable with kernel packages with version 6.6.3-1~exp1 > or greater, because it does not support compressed modules. This NMU > contains a targeted fix to enable support for XZ compressed modules. > > I opened bug #1063142 6 days ago, so far without response from Christian > Seiler, the maintainer. According to > https://contributors.debian.org/contributor/chris_se/ Christian has not > been active in Debian since 2021. That's why I decided to propose this > NMU. > > The below VCS URL is no longer active. The packaging was already > imported in Salsa at https://salsa.debian.org/debian/tiny-initramfs and > I'm testing some bigger packaging changes in my fork at > https://salsa.debian.org/viccie30/tiny-initramfs. > > * Package name : tiny-initramfs >Version : 0.1-5.1 >Upstream contact : Christian Seiler > * URL : https://github.com/chris-se/tiny-initramfs/ > * License : GPL-2+, GPL-3+ > * Vcs : > https://anonscm.debian.org/cgit/collab-maint/tiny-initramfs.git >Section : utils > > The source builds the following binary packages: > > tiny-initramfs - Minimalistic initramfs implementation (automation) > tiny-initramfs-core - Minimalistic initramfs implementation (core tools) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/tiny-initramfs/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/t/tiny-initramfs/tiny-initramfs_0.1-5.1.dsc > > Changes since the last upload: > > tiny-initramfs (0.1-5.1) unstable; urgency=high > . >* Non-maintainer upload. >* Decompress kernel modules included in initramfs. (Closes: #1063142) > > - -- > Vriendelijke groet, Kind regards, > > Victor Westerhuis > > -BEGIN PGP SIGNATURE- > > iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXIqzgTHHZpY3RvckB3 > ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+3QGD/90vFeAtsjTVWxw/W88+KV9WWp5HS4S > t380m73WMciSqK8tA94xiem+6kwVkgTr5VeKvNPKBiRhlhkXVAJiqoVmg9xTY7oh > bmOb9vghXCQ81+KINiE9gkBzYHdeTF+OLalN0Vjwn1R1yvQFNgi7uB/bArfR4qv8 > ytFzoqwFYURfuyVV5H+l5xhOl0q1BsNeShGQQGIhtH6rDvNhBdHIN6CAXMHkwIV8 > E1SAxVTvK2oSW7tU6wCYlwG2pXmPsFxRwjDE1l4gL3mjm0yRbfjMP8h9e7AfKVSf > 9GD88xrNGPxsKGFgEfCkm4ndzoF3JqypIjpI8Xw8Zm/OHnrVobxAI84zvJB1tCeX > fOYmO3HHOPzNDecJ6idWGddjXdjuQDGepbT/ZJ3qzxIPaCCPBMkGLrkmfM+sb1eg > voRhYA36Fen1sM75rBbEx6b+tWhnb8b/lVmVHI553FhQoo+Off0/vaQGzVKf+AEw > O5hU6e8BpPaAB8XyLYpehm1+fhO4MMf6jDhK+a7kFeHugPNL92GbnKKcbR5yVcoU > TqlXYyU1rULqALU8fozYIm/pfZm9iPrCxe23Cj3ziJ0cRBteOe8L9FV+pzr8F5Q2 > 72JIYsJ3Q24tLVuLVyFzYVyR2Yp778+bz6bcj+b0C1mY9HmbnkaVrc0/q/R/KVMb > 01fIJEX7ZkkTAg== > =cfoH > -END PGP SIGNATURE- >
Bug#1063142: tiny-initramfs: diff for NMU version 0.1-5.1
Control: tags 1063142 + pending
Dear maintainer,
I've sponsore an NMU, prepared by Victor Westerhuis, for tiny-initramfs
(versioned as 0.1-5.1) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
Regards.
diff -Nru tiny-initramfs-0.1/debian/changelog tiny-initramfs-0.1/debian/changelog
--- tiny-initramfs-0.1/debian/changelog 2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/changelog 2024-02-11 11:48:39.0 +0100
@@ -1,3 +1,10 @@
+tiny-initramfs (0.1-5.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Decompress kernel modules included in initramfs. (Closes: #1063142)
+
+ -- Victor Westerhuis Sun, 11 Feb 2024 11:48:39 +0100
+
tiny-initramfs (0.1-5) unstable; urgency=medium
[ Free Ekanayaka ]
diff -Nru tiny-initramfs-0.1/debian/control tiny-initramfs-0.1/debian/control
--- tiny-initramfs-0.1/debian/control 2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/control 2024-02-05 11:33:39.0 +0100
@@ -24,7 +24,7 @@
Package: tiny-initramfs-core
Architecture: linux-any
Multi-Arch: foreign
-Depends: cpio, ${shlibs:Depends}, ${misc:Depends}
+Depends: cpio, xz-utils, ${shlibs:Depends}, ${misc:Depends}
Built-Using: ${Built-Using}
Description: Minimalistic initramfs implementation (core tools)
A very minimalistic initramfs implementation for booting Linux
diff -Nru tiny-initramfs-0.1/debian/extra/functions tiny-initramfs-0.1/debian/extra/functions
--- tiny-initramfs-0.1/debian/extra/functions 2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/extra/functions 2024-02-05 11:33:39.0 +0100
@@ -208,9 +208,18 @@
fi
/sbin/modprobe --all --ignore-install --set-version="${VERSION}" --quiet --show-depends "$@" | \
awk '$1 == "insmod" { print; }' | while read dummy_type mod_file mod_options ; do
-mod_name=${mod_file##*/}
+mod_name=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\1/')
+mod_compression=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\2/')
if ! grep -q ^/"${mod_name}" "${initramfs_dir}/modules" ; then
- cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+ if [ "$mod_compression" = .xz ] ; then
+xzcat "${mod_file}" > "${initramfs_dir}/${mod_name}"
+ elif [ -z "$mod_compression" ] ; then
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+ else
+echo "$0: WARNING: unable to determine compression for modules while adding modules" >&2
+echo "YOUR SYSTEM MIGHT NOT BOOT WITH THIS INITRAMFS." >&2
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+ fi
printf "%s\n" "/${mod_name}${mod_options:+ $mod_options}" >> "${initramfs_dir}/modules"
fi
done
signature.asc
Description: PGP signature
Bug#1057098: RFS: runit/2.1.2-57 -- system-wide service supervision
Control: tags -1 moreinfo (This time sending to the correct bug ;-) Hi Lorenzo, the warning of unmerged systems will stop booting soon MUST be in Debian.NEWS, preinst is the wrong place and it will be very likely missed. NEWS is a well-known mechanism to convey important information. On the other hand, is this warning acutally required? Once this will get a real issue, Depend: on usr-is-merged and you should be set. If you cannot tell when that is, enforce it now, as non-merged systems are no longer supported anyway. There is a lintian warning: W debian-news-entry-has-unknown-version 2.1.2-14 [usr/share/doc/getty-run/NEWS.Debian.gz:1] Possibly this NEWS file can go, the version is older than old-old-stable. Small additional information: With https://lists.debian.org/debian-devel-announce/2022/09/msg1.html usrmerge is enforced on all installations. TL:DR: init-system-helpers is Essential: Yes, so you can already now Depend: on usr-is-merged if you want to make sure. (That will also cover where people held init-systems-helpers to an older -- tobi
Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)
Control: tags -1 -moreinfo (note: I replied to the wrong bug, the remarks should have gone to #1057098) I'll bounce them to the right bug after correction this mail.
Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)
On Sun, Feb 11, 2024 at 11:16:02AM +0100, Tobias Frost wrote: > Hi Lorenzo, > > the warning of unmerged systems will stop booting soon MUST > be in Debian.NEWS, preinst is the wrong place and it will be > very likely missed. NEWS is a well-known mechanism to convey > important information. > > On the other hand, is this warning acutally required? Once this will > get a real issue, Depend: on usr-is-merged and you should > be set. If you cannot tell when that is, enforce it now, as non-merged > systems are no longer supported anyway. Small additional information: With https://lists.debian.org/debian-devel-announce/2022/09/msg1.html usrmerge is enforced on all installations. TL:DR: init-system-helpers is Essential: Yes, so you can already now Depend: on usr-is-merged if you want to make sure. (That will also cover where people held init-systems-helpers to an older version) -- tobi
Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)
Control: tags -1 moreinfo Hi Lorenzo, the warning of unmerged systems will stop booting soon MUST be in Debian.NEWS, preinst is the wrong place and it will be very likely missed. NEWS is a well-known mechanism to convey important information. On the other hand, is this warning acutally required? Once this will get a real issue, Depend: on usr-is-merged and you should be set. If you cannot tell when that is, enforce it now, as non-merged systems are no longer supported anyway. There is a lintian warning: W debian-news-entry-has-unknown-version 2.1.2-14 [usr/share/doc/getty-run/NEWS.Debian.gz:1] Possibly this NEWS file can go, the version is older than old-old-stable. -- tobi On Fri, Feb 02, 2024 at 07:05:41PM +0100, Lorenzo wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "runit-services": > > * Package name : runit-services >Version : 0.7.1 >Upstream contact : [fill in name and email of upstream] > * URL : [fill in URL of upstream's web site] > * License : GPL-2.0+, BSD-3-Clause, CC0-1.0, GPL-3+ > * Vcs : >https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section > : admin > > The source builds the following binary packages: > > runit-services - UNIX init scheme with service supervision (services) > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/runit-services/ > > Alternatively, you can download the package with 'dget' using this > command: > > dget -x > > https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.1.dsc > > Git repo: > > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads > > Changes since the last upload: > > runit-services (0.7.1) experimental; urgency=medium > . >* Fix piuparts failure in package removal > (Closes: #1062682) >* update years in copyright.in and > regenerate d/copyright > Regards, > Lorenzo >
Bug#1061559: RFS: fpart/1.6.0-1
On Fri, Jan 26, 2024 at 01:12:54PM +0100, Ganael Laplanche wrote: > fpart (1.6.0-1) unstable; urgency=low > >* New upstream release >* debian/control > - Bump Standards-Version to 4.6.2 (no changes required) >* debian/copyright > - Bump copyright dates >* debian/rules > - Enable hardening > (dsc checked with timestamp:2024-01-25 12:10) Hi, d/control says still 4.6.0, in contrast to the changelog entry. However, this is easy to fix (and as the repo is in the Debian group) I've made this change for you in the repository and uploaded the version accordingly. I've also added the tag in the repo. NOTE: The tags for the upstream versions are missing in the repo. PLEASE push your tags! -- Cheers, tobi
Bug#1063492: openvswitch: CVE-2023-3966: Invalid memory access in Geneve with HW offload
Control: tags -1 fixed-upstream According to this announcment [1], CVE-2023-3966 and CVE-2023-5366 are fixed with versions Latest stable: https://www.openvswitch.org/releases/openvswitch-3.2.2.tar.gz Current LTS series: https://www.openvswitch.org/releases/openvswitch-2.17.9.tar.gz Other: https://www.openvswitch.org/releases/openvswitch-3.1.4.tar.gz https://www.openvswitch.org/releases/openvswitch-3.0.6.tar.gz [1] https://mail.openvswitch.org/pipermail/ovs-announce/2024-February/000338.html As sid has currently a git snapshot, it is not clear to me if that has been fixed there too. On Thu, 08 Feb 2024 22:35:46 +0100 Salvatore Bonaccorso wrote: > Source: openvswitch > Version: 3.3.0~git20240118.e802fe7-3 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > Control: found -1 3.1.0-2 > > Hi, > > The following vulnerability was published for openvswitch. > > CVE-2023-3966[0]: > | Invalid memory access in Geneve with HW offload > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2023-3966 > https://www.cve.org/CVERecord?id=CVE-2023-3966 > [1] https://www.openwall.com/lists/oss-security/2024/02/08/3 > [2] https://mail.openvswitch.org/pipermail/ovs-dev/2024-February/411702.html > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore > >
Bug#1062832: opencascade: NMU diff for 64-bit time_t transition
Please hold this NMU.
I'm currently preparing the transistion to the next opencascade
version that require new packages anyway, as upstream does not
handle SONAMES very well. This NMU will only make me additional work.
Thanks.
On Sat, Feb 03, 2024 at 03:53:29PM -0300, Lucas Kanashiro wrote:
> Source: opencascade
> Version: 7.6.3+dfsg1-7
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> opencascade as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time. Therefore I have prepared a 0-day NMU for opencascade
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP. Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.2.0-39-generic (SMP w/32 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> 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)
> diff -Nru opencascade-7.6.3+dfsg1/debian/changelog
> opencascade-7.6.3+dfsg1/debian/changelog
> --- opencascade-7.6.3+dfsg1/debian/changelog 2023-05-23 04:45:56.0
> -0300
> +++ opencascade-7.6.3+dfsg1/debian/changelog 2024-02-03 15:42:50.0
> -0300
> @@ -1,3 +1,10 @@
> +opencascade (7.6.3+dfsg1-7.1) experimental; urgency=medium
> +
> + * Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition.
> +
> + -- Lucas Kanashiro Sat, 03 Feb 2024 15:42:50 -0300
> +
> opencascade (7.6.3+dfsg1-7) unstable; urgency=medium
>
>* Update broken symlink /usr/bin/occt-draw to new version
> diff -Nru opencascade-7.6.3+dfsg1/debian/control
> opencascade-7.6.3+dfsg1/debian/control
> --- opencascade-7.6.3+dfsg1/debian/control2023-05-14 06:02:22.0
> -0300
> +++ opencascade-7.6.3+dfsg1/debian/control2024-02-03 15:42:50.0
> -0300
> @@ -27,16 +27,17 @@
> Homepage: https://www.opencascade.com/
> Rules-Requires-Root: no
>
> -Package: libocct-foundation-7.6
> +Package: libocct-foundation-7.6t64
> +Provides: ${t64:Provides}
> Architecture: any
> Multi-Arch: same
> Section: libs
> Depends: ${misc:Depends},
> ${shlibs:Depends}
> Pre-Depends: ${misc:Pre-Depends}
> -Breaks: libocct-foundation-7.4,
> +Breaks: libocct-foundation-7.6 (<< ${source:Version}),
> libocct-foundation-7.4,
> libocct-foundation-7.5,
> -Replaces: libocct-foundation-7.4,
> +Replaces: libocct-foundation-7.6, libocct-foundation-7.4,
>libocct-foundation-7.5,
> Description: OCCT module underlying all other OCCT classes
> Open CASCADE Technology is a suite for 3D surface and solid modeling,
> @@ -56,8 +57,8 @@
> Architecture: any
> Multi-Arch: same
> Section: libdevel
> -Depends: libocct-foundation-7.6 (<< ${binary:Version}+1~),
> - libocct-foundation-7.6 (>= ${binary:Version}),
> +Depends: libocct-foundation-7.6t64 (<< ${binary:Version}+1~),
> + libocct-foundation-7.6t64 (>= ${binary:Version}),
> ${misc:Depends}
> Conflicts: liboce-foundation-dev
> Breaks: occt-misc (<< 7.6.3+dfsg1-4~)
> @@ -71,16 +72,17 @@
> This package contains the headers and symlinks for libraries shipped by
> libocct-foundation.
>
> -Package: libocct-modeling-data-7.6
> +Package: libocct-modeling-data-7.6t64
> +Provides: ${t64:Provides}
> Architecture: any
> Multi-Arch: same
> Section: libs
> Depends: ${misc:Depends},
>
Bug#1061908: cppdb: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 12:45:20AM +, mwhud...@debian.org wrote:
> Source: cppdb
> Followup-For: Bug #1061908
>
> Apologies, thanks to operator error (i.e. I messed up) the diff attached to
> this bug is not the one that was uploaded to experimental. Please see the
> patch
> attached to this message.
Please commit it to the repository.
A NMU out of the blue is already unfriendly enough, please don't push
the work to clean up to me. Thanks.
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-15-generic (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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)
> diff -Nru cppdb-0.3.1+dfsg/debian/changelog cppdb-0.3.1+dfsg/debian/changelog
> --- cppdb-0.3.1+dfsg/debian/changelog 2021-10-19 14:21:37.0 +
> +++ cppdb-0.3.1+dfsg/debian/changelog 2024-01-30 09:50:40.0 +
> @@ -1,3 +1,10 @@
> +cppdb (0.3.1+dfsg-9.1~exp1) experimental; urgency=medium
> +
> + * Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition.
> +
> + -- Michael Hudson-Doyle Tue, 30 Jan 2024 09:50:40
> +
> +
> cppdb (0.3.1+dfsg-9) unstable; urgency=medium
>
>[ Ondřej Nový ]
> diff -Nru cppdb-0.3.1+dfsg/debian/control cppdb-0.3.1+dfsg/debian/control
> --- cppdb-0.3.1+dfsg/debian/control 2021-10-19 14:07:26.0 +
> +++ cppdb-0.3.1+dfsg/debian/control 2024-01-30 09:50:40.0 +
> @@ -18,11 +18,11 @@
> Section: libdevel
> Architecture: any
> Multi-Arch: same
> -Depends: libcppdb-mysql0 (= ${binary:Version}),
> - libcppdb-odbc0 (= ${binary:Version}),
> - libcppdb-postgresql0 (= ${binary:Version}),
> - libcppdb-sqlite3-0 (= ${binary:Version}),
> - libcppdb0 (= ${binary:Version}),
> +Depends: libcppdb-mysql0t64 (= ${binary:Version}),
> + libcppdb-odbc0t64 (= ${binary:Version}),
> + libcppdb-postgresql0t64 (= ${binary:Version}),
> + libcppdb-sqlite3-0t64 (= ${binary:Version}),
> + libcppdb0t64 (= ${binary:Version}),
> ${misc:Depends}
> Description: SQL Connectivity Library (development files)
> CppDB is an SQL connectivity library that is designed to provide platform
> and
> @@ -46,15 +46,18 @@
> .
> This package contains the development files.
>
> -Package: libcppdb0
> +Package: libcppdb0t64
> +Provides: ${t64:Provides}
> +Replaces: libcppdb0
> +Breaks: libcppdb0 (<< ${source:Version})
> Architecture: any
> Multi-Arch: same
> Pre-Depends: ${misc:Pre-Depends}
> Depends: ${misc:Depends}, ${shlibs:Depends}
> -Suggests: libcppdb-mysql0,
> - libcppdb-odbc0,
> - libcppdb-postgresql0,
> - libcppdb-sqlite3-0
> +Suggests: libcppdb-mysql0t64,
> + libcppdb-odbc0t64,
> + libcppdb-postgresql0t64,
> + libcppdb-sqlite3-0t64
> Description: SQL Connectivity Library (core library)
> CppDB is an SQL connectivity library that is designed to provide platform
> and
> Database independent connectivity API similarly to what JDBC, ODBC and other
> @@ -77,7 +80,10 @@
> .
> This package contains the core library
>
> -Package: libcppdb-mysql0
> +Package: libcppdb-mysql0t64
> +Provides: ${t64:Provides}
> +Replaces: libcppdb-mysql0
> +Breaks: libcppdb-mysql0 (<< ${source:Version})
> Architecture: any
> Multi-Arch: same
> Pre-Depends: ${misc:Pre-Depends}
> @@ -104,7 +110,10 @@
> .
> This package contains the MySQL backend
>
> -Package: libcppdb-sqlite3-0
> +Package: libcppdb-sqlite3-0t64
> +Provides: ${t64:Provides}
> +Replaces: libcppdb-sqlite3-0
> +Breaks: libcppdb-sqlite3-0 (<< ${source:Version})
> Architecture: any
> Multi-Arch: same
> Pre-Depends: ${misc:Pre-Depends}
> @@ -131,7 +140,10 @@
> .
> This package contains the sqlite3 backend
>
> -Package: libcppdb-postgresql0
> +Package: libcppdb-postgresql0t64
> +Provides: ${t64:Provides}
> +Replaces: libcppdb-postgresql0
> +Breaks: libcppdb-postgresql0 (<< ${source:Version})
> Architecture: any
> Multi-Arch: same
> Pre-Depends: ${misc:Pre-Depends}
> @@ -158,7 +170,10 @@
> .
> This package contains the PostgreSQL backend
>
> -Package: libcppdb-odbc0
> +Package: libcppdb-odbc0t64
> +Provides: ${t64:Provides}
> +Replaces: libcppdb-odbc0
> +Breaks: libcppdb-odbc0 (<< ${source:Version})
> Architecture: any
> Multi-Arch: same
> Pre-Depends: ${misc:Pre-Depends}
> diff -Nru cppdb-0.3.1+dfsg/debian/libcppdb0.install
> cppdb-0.3.1+dfsg/debian/libcppdb0.install
> --- cppdb-0.3.1+dfsg/debian/libcppdb0.install 2018-04-05 19:10:53.0
> +
> +++ cppdb-0.3.1+dfsg/debian/libcppdb0.install 1970-01-01 00:00:00.0
> +
> @@ -1 +0,0 @@
> -usr/lib/*/libcppdb.so.*
> diff -Nru
