Bug#1032517: nginx settings deleted on upgrade
On Wed, 08 Mar 2023 13:47:47 +0100 Ralf Jung wrote: > Package: nginx > Version: 1.22.1-7 > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > > last weekend I did an "apt upgrade" of my system as usual, asking apt to > prune configuration files for packages that are being uninstalled. > Now I realize that my nginx stopped working, and it turns out its > configuration files are just completely gone. > Look like the recent package reorganization went wrong and actually deletes > configuration under certain conditions -- that's pretty bad. > Package updates shouldn't cause a loss of configuration files, even when > pruning packages that are not present any more. > > Kind regards, > Ralf > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_USER > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages nginx depends on: > ii debconf [debconf-2.0] 1.5.82 > ii iproute2 6.1.0-1 > ii libc6 2.36-8 > ii libcrypt1 1:4.4.33-2 > ii libpcre2-8-0 10.42-1 > ii libssl3 3.0.8-1 > ii zlib1g 1:1.2.13.dfsg-1 > > nginx recommends no packages. > > Versions of packages nginx suggests: > ii fcgiwrap 1.1.0-14 > pn nginx-doc > ii ssl-cert 1.1.2 > > -- Configuration Files: > /etc/nginx/fastcgi.conf [Errno 2] No such file or directory: > '/etc/nginx/fastcgi.conf' > /etc/nginx/fastcgi_params [Errno 2] No such file or directory: > '/etc/nginx/fastcgi_params' > /etc/nginx/koi-utf [Errno 2] No such file or directory: '/etc/nginx/koi-utf' > /etc/nginx/koi-win [Errno 2] No such file or directory: '/etc/nginx/koi-win' > /etc/nginx/mime.types [Errno 2] No such file or directory: > '/etc/nginx/mime.types' > /etc/nginx/nginx.conf [Errno 2] No such file or directory: > '/etc/nginx/nginx.conf' > /etc/nginx/proxy_params [Errno 2] No such file or directory: > '/etc/nginx/proxy_params' > /etc/nginx/scgi_params [Errno 2] No such file or directory: > '/etc/nginx/scgi_params' > /etc/nginx/sites-available/default [Errno 2] No such file or directory: > '/etc/nginx/sites-available/default' > /etc/nginx/snippets/fastcgi-php.conf [Errno 2] No such file or directory: > '/etc/nginx/snippets/fastcgi-php.conf' > /etc/nginx/snippets/snakeoil.conf [Errno 2] No such file or directory: > '/etc/nginx/snippets/snakeoil.conf' > /etc/nginx/uwsgi_params [Errno 2] No such file or directory: > '/etc/nginx/uwsgi_params' > /etc/nginx/win-utf [Errno 2] No such file or directory: '/etc/nginx/win-utf' > Отправлено с iPhone
Bug#1034367: marked as done (v2ray geoip data has problematic license)
Your message dated Mon, 24 Apr 2023 01:49:01 + with message-id and subject line Bug#1034367: fixed in golang-v2ray-core 4.34.0-9 has caused the Debian Bug report #1034367, regarding v2ray geoip data has problematic license to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1034367: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034367 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: v2ray From https://lists.debian.org/debian-legal/2023/02/msg4.html V2Fly project provides a geoip data file in https://github.com/v2fly/geoip. The license is declared as CC-BY-SA-4.0 but it uses the data from GeoLite2, which is licensed under an EULA https://www.maxmind.com/en/geolite2/eula. The EULA looks like not a free license. Debian packages the data file in the v2ray package. And Debian marks the data as MIT which is also wrong. Could you please check the license? Also, there is now libloc packages for this that should be free. For example, libloc-database should provide a free, compatible version of the geoip database. --- End Message --- --- Begin Message --- Source: golang-v2ray-core Source-Version: 4.34.0-9 Done: Roger Shimizu We believe that the bug you reported is fixed in the latest version of golang-v2ray-core, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1034...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Roger Shimizu (supplier of updated golang-v2ray-core package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 23 Apr 2023 18:34:48 -0700 Source: golang-v2ray-core Architecture: source Version: 4.34.0-9 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Roger Shimizu Closes: 1034367 Changes: golang-v2ray-core (4.34.0-9) unstable; urgency=medium . * Remove geoip data and test code due to license (Closes: #1034367). Checksums-Sha1: c6e4d5d471b0fa8475765fb37c60b1b9a4f386e0 2595 golang-v2ray-core_4.34.0-9.dsc 0a1f61f69172f868bc1c4978157dc2780d3c74fb 21872 golang-v2ray-core_4.34.0-9.debian.tar.xz fedeccdf0d6a668d6f882b2c397f99b69baab37c 6209 golang-v2ray-core_4.34.0-9_source.buildinfo Checksums-Sha256: 733ed27282de47ca6a13b347a95fc7f03a40df8f027c3fd8efb75948d67d3227 2595 golang-v2ray-core_4.34.0-9.dsc bc042e6809ec061e567facd14a7c8d55d812cd113f3b0deb6f09c71882fae2d4 21872 golang-v2ray-core_4.34.0-9.debian.tar.xz f2f1200bfc3e3742fbac1b0bed323adcdeba620d038b9a4cd9813905cf48bcd5 6209 golang-v2ray-core_4.34.0-9_source.buildinfo Files: a61cb20b9c6e55f895107391d0a0889c 2595 devel optional golang-v2ray-core_4.34.0-9.dsc 7f98875d8e65820d2111a84d76bdc54e 21872 devel optional golang-v2ray-core_4.34.0-9.debian.tar.xz ab1f926e4c26ddeffecd8f0612e870ec 6209 devel optional golang-v2ray-core_4.34.0-9_source.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCgAuFiEECjKtvoA5m+cWOFnspHhrDacDNKgFAmRF3NIQHHJvc2hAZGVi aWFuLm9yZwAKCRCkeGsNpwM0qHjmD/4olSbOYBFZ1nPQpANnvMqBjMSBjRmXeKPS T6A8PFJDozgfsUYgsbW+4XqnZQ2HFLI4LjGz/AowM+TbYVjvLvjUg3YzB31uLt6x MEG2LQFAlVjVWSuv9yUk3h3RSTnF25KCRvIEy1J4O1Pus3qEsvUyrDCqwjg1s08I +qz2PBZ3rWHSsqQlAIoTtFRwAOYuc7JtEa+IW/S/B+MiP2G/JAO00WK7lsjtPCuv NaB/Fsp29eW4sE8FYKGps30DtWIxcQ/2fS/azROzUjn8FO2sgotRlfo4u1GNqaup UUkwvAn9I3M0Yq2YlpQYSMipDaOK1tRrLwkSQXTlVM9Wi2qilbC9+PsYjT1rx4EE +0EmvWnuvct8lCL6rwpyXm00gg+QVfgULGseg9k4KT14gZ128FyyI5t9a6iI8a3E cCwsYiRMICfe1qeStsFx3c9kP0iq7nmBe5BnMoTy7sdyOFgujnjeAyPCpU1ieJMV 2aTSEh1ZTLCLbhmj7yqhcKdwefKOfkET8a8fOVTUAxgrlCxApt6xZlit7Su8EDfQ hPlz3tCxmSxfmNL+HmFF7Ug3kAceoUxjBxfu5sH8M8UtiP9R3evljU8m5uxDDFmo ln8MI/BlqvbFMz8aPYNPhmZ+PU5MUNHT7uxAINnLnLi8Wy/of9nHxI/EJzzqEOP5 dwlaQWGquQ== =luNg -END PGP SIGNATURE End Message ---
Bug#1034367: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1034367 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/d204696ce754ee8605f97bb277b23bcda5f1b0da Prepare to release 4.34.0-9 Remove geoip data and test code due to license Closes: #1034367 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034367
Processed: Bug#1034367 marked as pending in golang-v2ray-core
Processing control commands: > tag -1 pending Bug #1034367 [v2ray] v2ray geoip data has problematic license Added tag(s) pending. -- 1034367: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034367 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.
Package: singular Version: 1:4.3.1-p3+ds-1 Severity: serious Justification: rc-policy - "Packages must be buildable within the same release" singular build-depends on python3-brial. python3-brial recently added a dependency on python3-sage making it uninstallable on many architectures. As a result singular can no longer be built on those architectures. I had a look at the build log and grepped the source tree and could find no evidence of singular actually using brial. I also was able to successfully build the package locally without python3-brial installed. So I think the appropriate course of action would be to remove the build-dependency. If I get no response I will likely NMU this next weekend, but I'd really like a second opinion if possible. See also: bugs 1033878 and 1034443
Bug#1020246: Not an active maintainer, but
AFAIK, both armel and armfh are low-powered/"slow" arches, but i386 is surprising. Maybe due to memory limits? I wonder if tests shouldn't simply be restricted to amd64, arm64, ppc64el and s390x? This should give it enough of architecture heterogeneity to catch any problems that simply do not appear on amd64 (mainstream arch) (yes, I've been bitten by this in one package of mine). This would be a cheap fix (one entry in the control file). Thoughts? (Anyone?) It seems this bug is the only one that prevents it from entering testing (and it's a leaf package). regards, iustin
Processed: severity of 1034236 is important
Processing commands for cont...@bugs.debian.org: > severity 1034236 important Bug #1034236 [mpd] mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system Severity set to 'important' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 1034236: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034236 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
On 23/04/2023 21:07, Paul Gevers wrote: Can you point to a discussion where we might draw the conclusion that this is common practice or consensus? I *personally* [no hats on] find that distinction a bit weird although I can see how we would come to it and also why. No, I can't point to a discussion. I vaugely remember hearing it from a more experianced developer (possiblly a release team member) on IRC years ago. But it has been consistent with how I have seen bugs handled in practice over my years in Debian. It's also consistent with how britney behaves or at least did until very recently. My understanging is that britney performs architecture checks on all release architectures where a package is built for arch specific packages, but only performs architecture checks on a small subset of architectures (when I first started with Debian it was i386 only, I think now it's amd64 and arm64, maybe also i386) for arch all packages. I have vauge reccollections of a document descirbing the different behaviour for arch all packages in britney as a "hack", so I presume this is something that started as a hack and then just became the status quo. If you wanted your package in testing and it was arch specific you had to make sure it was installable on all architectures where it was built, but if it was arch all you did not (and often could not). I have seen people ask the release team for exceptions when their arch-all package is not installable on one of the architectures where arch all packages are checked but I can't recall ever seeing such a request for an arch-specific package. And when I look at https://qa.debian.org/dose/debcheck/testing_main/index.html this seems to back up my observation. That does leave the question of how brial with this bug migrated to testing in the first place. Whether there was a recent intentional change in britney, whether there was a bug/glitch, or whether it was forced in (and if-so who forced it). This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. Ack. And I agree with this approach. However, we are *also* in the Hard Freeze, so RC bugs reports have more severe results if not treated swiftly. Agreed, given where we are in the Freeze, enough time has passed to file a rc bug against singular with an expression of intent to NMU. I'll do that later today. I also hereby announce that I intend to NMU brial if I don't get a maintainer response soon. (I am assuming Paul is posting as a release team member and not as a maintainer of the package, if that is wrong please speak up)
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: severity ! important On Fri, Apr 21, 2023 at 03:24:25PM +0200, Geoffroy Youri Berret wrote: > Le 11/04/2023 à 23:52, Florian Schlichting a écrit : > > […] > > I think we should take a step back and think about how a freshly > > installed mpd package should look like. I think it may actually be a > > feature that the system mpd.service is not enabled and started on a > > fresh install. On most desktop/laptop machines, leaving the system > > service off and enabling the user service is probably the better thing > > to do. How long has dh-installsystemd been disregarding our unit files? > > We may want to add --no-enable when we apply that patch. > > > > So I think in the case of mpd, perhaps nothing is severely broken > > currently and this bug doesn't require fixing for bookworm. Instead, it > > can perhaps be downgraded and fixed with the next regular upload, after > > the release? > > I agree, this is the best thing to do. > The package is not broken enough to require a fix, it's actually not really > broken it's only not enabling/starting system unit which, I believe, is not > the main use of MPD anyway. Since we agree, I don't think we need to wait any further and can get ourselves off the release-critical bugs list right away :-) Let's fix this first thing in trixie, and also add an override for dh_installsystemd --no-enable Florian
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, On 23-04-2023 21:24, Peter Michael Green wrote: That works in some cases, but it's a bad option here for two reasons. 1. It would create a build-dependency loop between brial and sagemath. Which isn't practical problem as long as there is a proper build profile involved, right? But given point 2, I think both the point and this is argument are moot. 2. It would mean that other binary packages built from the brial source package had their architecture list unnecessarily limited. Aha, I missed that detail. There are more arch: binaries build by src:brial. > Technically I even think that this isn't a bug in python3-brial. One of the criteria (indeed the first on the list) for grave is "makes the package in question unusable or mostly so". I consider that a package that cannot be installed is unusable. If I follow that reasoning than about 850 arch:all binaries also have RC bugs: https://qa.debian.org/dose/debcheck/testing_main/1682226002/some.html My understanding has always been that for source packages that build multiple binaries, the test of "is the package unusable" is applied for each binary package individually and that for packages that are built separately for multiple architectures (not arch all packages) it is applied for each architecture individually. I don't think that is officially written down anywhere though. Can you point to a discussion where we might draw the conclusion that this is common practice or consensus? I *personally* [no hats on] find that distinction a bit weird although I can see how we would come to it and also why. This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. Ack. And I agree with this approach. However, we are *also* in the Hard Freeze, so RC bugs reports have more severe results if not treated swiftly. If the maintainer of brial came back and said that the fix for bug 1033878 was wrong, and that python3-brial could in-fact be made usable on all architectures then there would. [missing words?] Yes, sure. However, looking at the stack trace in that bug, I agree that the dependency is the most logical solution. Ensuring python3-brial to be useful without that dependency will require patching the code by the looks of it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
On 23/04/2023 19:19, Paul Gevers wrote: I claim this is wrong. Would python3-sage one day build on more architectures, this list would need manual updating. Instead of hard-coding the list, it's better to ensure the build doesn't happen or fails on architectures where python3-sage is not available. E.g. by build-depending (ideally with a build profile indicating that the *build* itself works; I suggest ). That works in some cases, but it's a bad option here for two reasons. 1. It would create a build-dependency loop between brial and sagemath. 2. It would mean that other binary packages built from the brial source package had their architecture list unnecessarily limited. > Technically I even think that this isn't a bug in python3-brial. One of the criteria (indeed the first on the list) for grave is "makes the package in question unusable or mostly so". I consider that a package that cannot be installed is unusable. My understanding has always been that for source packages that build multiple binaries, the test of "is the package unusable" is applied for each binary package individually and that for packages that are built separately for multiple architectures (not arch all packages) it is applied for each architecture individually. I don't think that is officially written down anywhere though. This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. If the maintainer of brial came back and said that the fix for bug 1033878 was wrong, and that python3-brial could in-fact be made usable on all architectures then there would. On the other hand whatever changes were made in singular we would still have unusable python3-brial packages. So I started out with a bug against python3-brial.
Processed: fixed 1000050 in 3.0.4-2, found 1000050 in 3.0.8-1
Processing commands for cont...@bugs.debian.org:
> fixed 150 3.0.4-2
Bug #150 {Done: Tobias Frost } [src:modsecurity]
modsecurity: depends on obsolete pcre3 library
Marked as fixed in versions modsecurity/3.0.4-2.
> found 150 3.0.8-1
Bug #150 {Done: Tobias Frost } [src:modsecurity]
modsecurity: depends on obsolete pcre3 library
Marked as found in versions modsecurity/3.0.8-1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
150: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=150
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: fixed 1033496 in 6.1.1+dfsg2-6~exp1
Processing commands for cont...@bugs.debian.org: > fixed 1033496 6.1.1+dfsg2-6~exp1 Bug #1033496 [scilab] scilab: cannot start scilab at all Bug #1033997 [scilab] scilab-6.1.1+dfsg2-5: scilab and xcos unable to launch. Error dialog say onfiguration file is corrupted. Marked as fixed in versions scilab/6.1.1+dfsg2-6~exp1. Marked as fixed in versions scilab/6.1.1+dfsg2-6~exp1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1033496: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033496 1033997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033997 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: modsecurity: depends on obsolete pcre3 library
Processing control commands: > fixed -1 3.0.8-2 Bug #150 [src:modsecurity] modsecurity: depends on obsolete pcre3 library Marked as fixed in versions modsecurity/3.0.8-2. > severity -1 serious Bug #150 [src:modsecurity] modsecurity: depends on obsolete pcre3 library Severity set to 'serious' from 'important' > affects -1 libnginx-mod-http-modsecurity Bug #150 [src:modsecurity] modsecurity: depends on obsolete pcre3 library Added indication that 150 affects libnginx-mod-http-modsecurity > close -1 Bug #150 [src:modsecurity] modsecurity: depends on obsolete pcre3 library Marked Bug as done -- 150: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=150 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, all, On Sat, 15 Apr 2023 15:33:04 +0100 Peter Green wrote: * The architecture list of python3-brial needs to be limited to architectures where python3-sage is available. I claim this is wrong. Would python3-sage one day build on more architectures, this list would need manual updating. Instead of hard-coding the list, it's better to ensure the build doesn't happen or fails on architectures where python3-sage is not available. E.g. by build-depending (ideally with a build profile indicating that the *build* itself works; I suggest ). Technically I even think that this isn't a bug in python3-brial. Assuming the dependency is real and unavoidable, than being uninstallable is bug in the depending on package, but not an RC one. * The build-dependency of singular on python3-brial needs to be either removed or limited to architectures where python3-sage is available This seems to be your real issue. Why file the bug against python3-brial? * Removal of the old python3-brial packages needs to be requested. Assuming something is done to prevent the binaries from building, then yes, obviously. However, why would we consider arch: uninstallable packages different than arch:all uninstallable packages if the reason is the same: depending on a binary that's not build on some arch. Do our tools have different expectations for them? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034760: modsecurity: FTBFS on all archs except amd64/i386
Source: modsecurity Version: 3.0.8-2 Severity: serious Tags: ftbfs patch Justification: FTBFS Hi, as you already know, modsecurity FTBFS on almost all archs, except amd64 and i386: It fails to find libpcre2 on those archs. It seems that the shipped pcre2.m4 is broken: When using pkg-config to locate the library, it uses PCRE2_POSSIBLE_LIB_NAMES="pcre2 pcre2-8" however, the pkg-config name is *lib*pcre2(-8) On amd64/i386 some fallback mechansism eventually finds the library, this is why it works there. Possibly, on Debian, only pkg-config should be used? (Another observation: It finds the headers on the broken archs, so it seems it does not use pkg-config for determining the include paths? This seems dangerous, if pkg-config is mixed with some heurisitcs?) The attached patch makes autoconf happy at least on arm64, likely also on the other archs: Index: modsecurity-3.0.8/build/pcre2.m4 === --- modsecurity-3.0.8.orig/build/pcre2.m4 +++ modsecurity-3.0.8/build/pcre2.m4 @@ -4,7 +4,7 @@ dnl CHECK_PCRE2(ACTION-IF-FOUND [, ACTIO AC_DEFUN([PROG_PCRE2], [ # Possible names for the pcre2 library/package (pkg-config) -PCRE2_POSSIBLE_LIB_NAMES="pcre2 pcre2-8" +PCRE2_POSSIBLE_LIB_NAMES="libpcre2 libpcre2-8" # Possible extensions for the library PCRE2_POSSIBLE_EXTENSIONS="so so0 la sl dll dylib so.0.0.0" -- tobi
Bug#1033617: marked as done (libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev)
Your message dated Sun, 23 Apr 2023 17:04:43 + with message-id and subject line Bug#1033617: fixed in openexr 3.1.5-5 has caused the Debian Bug report #1033617, regarding libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1033617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033617 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libopenexr-dev Version: 3.1.5-4 Severity: serious Justification: Policy 7.4 X-Debbugs-Cc: me+debian-b...@banananet.work Dear Maintainer, I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4 due to a file conflict with the package libilmbase-dev on version 2.5.4-1. I tried with apt & aptitude as well. Both want to replace libilmbase-dev with libopenexr-dev in a single execution of them, but fail to do that in a way that dpkg allows that (tries first to install the new package and then uninstall the old one). Currently I see no other solution than removing the old one first aside with all packages depending it on it, and then installing the new one with all packages which were removed before. They already have a "Breaks" & a "Replace" relationship, which seems to be right, but I assume adding a "Conflicts" relation will fix that, for "Breaks" "dpkg will refuse to allow the package […] to be unpacked unless the broken package is deconfigured first", while for "Conflicts" it says that "dpkg will refuse to allow them to be unpacked on the system at the same time". I marked this bug as serious as I think, even if another solution may be found, that still a Conflicts field on this package referring to the older one may be required unless that is not possible. However, I'm not 100% sure, so feel free to change the severity. Maybe I just ran into this problem due to other circumstances a stable user will not run into. Also I assume that if this configuration will be released into bookworm, others will having problems as well. Best Regards, Felix Stupp -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (550, 'testing'), (500, 'testing-security'), (400, 'stable-updates'), (400, 'stable-security'), (400, 'stable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.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 libopenexr-dev depends on: pn libilmbase-dev ii libopenexr252.5.7-1 libopenexr-dev recommends no packages. libopenexr-dev suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: openexr Source-Version: 3.1.5-5 Done: Matteo F. Vescovi We believe that the bug you reported is fixed in the latest version of openexr, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1033...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Matteo F. Vescovi (supplier of updated openexr package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 23 Apr 2023 18:46:33 +0200 Source: openexr Architecture: source Version: 3.1.5-5 Distribution: unstable Urgency: medium Maintainer: Debian PhotoTools Maintainers Changed-By: Matteo F. Vescovi Closes: 1033617 Changes: openexr (3.1.5-5) unstable; urgency=medium . * Team upload. . [ Andreas Metzler ] * Make versioning of libilmbase-dev Breaks/Replaces binNMU-safe. (Closes: #1033617) . [ Matteo F. Vescovi ] * debian/control: S-V bump 4.6.1 -> 4.6.2 (no changes needed) Checksums-Sha1: a3271e75b408348cb310e5b1f5777eaedfe9c363 2636 openexr_3.1.5-5.dsc 41401f851a653801b4c50a4236be8c6e872a7a4d 18176 openexr_3.1.5-5.debian.tar.xz 8cbd8d306a9a2c904c83bde2349f362b7e004652 7868 openexr_3.1.5-5_source.buildinfo Checksums-Sha256: 86abb11e85a2f651a6d6a84f757ae5d506f34daad74709492b44ab985dd6e3cb 2636 openexr_3.1.5-5.dsc
Processed: fixed 997084 in 3:4.7.6+~4.1.0-3
Processing commands for cont...@bugs.debian.org: > fixed 997084 3:4.7.6+~4.1.0-3 Bug #997084 [src:node-handlebars] node-handlebars: FTBFS: build hangs Marked as fixed in versions node-handlebars/3:4.7.6+~4.1.0-3. > thanks Stopping processing here. Please contact me if you need assistance. -- 997084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997084 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: scilab: cannot start scilab at all
Processing control commands: > tags -1 fixed-in-experimental Bug #1033496 [scilab] scilab: cannot start scilab at all Bug #1033997 [scilab] scilab-6.1.1+dfsg2-5: scilab and xcos unable to launch. Error dialog say onfiguration file is corrupted. Added tag(s) fixed-in-experimental. Added tag(s) fixed-in-experimental. -- 1033496: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033496 1033997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033997 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1033496: scilab: cannot start scilab at all
Control: tags -1 fixed-in-experimental Hello, You submitted bugs about scilab not being able to start: I found the cause, which is linked to the default JVM switching from openjdk-11 to openjdk-17. I was able to fix this: the version of scilab in Debian experimental, 6.1.1+dfsg2-6~exp1, is now starting correctly. I will see if I can get an exception and ship this corrected version in Debian Bookworm, as we are quite advanced in the freezing process of Bookworm. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1034752: embeds non-free headers
Source: gluegen2 Version: 2.3.2-9 Severity: serious Tags: fixed-in-experimental Dear Maintainer, Non-free header files are present in the source of gluegen2, see for instance in make/stub_includes/jni/jni.h: * Copyright 2006 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. Removing these headers and using these of the jdk instead requires some extra work in the rdep libjogl2-java, but it is done in experimental. Best, -- Pierre
Bug#1034751: python-xmlschema: accesses internet during build
Source: python-xmlschema Version: 1.10.0-5 Severity: serious Justification: Policy §4.9 Policy §4.9 states: 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. Running "wget http://example.com; to check if network access is available violates this rule. Furthermore, our buildds have network access and thus this check succeeds and the package downloads files during the build. Cheers -- Sebastian Ramacher
Bug#1034748: marked as done (PlanetarySystemStacker does not work anylonger)
Your message dated Sun, 23 Apr 2023 09:49:39 +
with message-id
and subject line Bug#1034748: fixed in planetary-system-stacker
0.8.32~git20221019.66d7558-2
has caused the Debian Bug report #1034748,
regarding PlanetarySystemStacker does not work anylonger
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1034748: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034748
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: planetary-system-stacker
Version: 0.8.32~git20221019.66d7558-1
Severity: grave
Due to a recent change in numpy, the planetary-system-stacker does not
work anylong and crashes during start:
Traceback (most recent call last):
File "/usr/bin/PlanetarySystemStacker", line 33, in
sys.exit(load_entry_point('planetary-system-stacker==0.9.3',
'console_scripts', 'PlanetarySystemStacker')())
File "/usr/bin/PlanetarySystemStacker", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File
"/usr/lib/python3/dist-packages/planetary_system_stacker/planetary_system_stacker.py",
line 64, in
from workflow import Workflow
File "/usr/lib/python3/dist-packages/planetary_system_stacker/workflow.py", line
40, in
from stack_frames import StackFrames
File "/usr/lib/python3/dist-packages/planetary_system_stacker/stack_frames.py",
line 33, in
from numpy import int as np_int
ImportError: cannot import name 'int' from 'numpy'
(/usr/lib/python3/dist-packages/numpy/__init__.py)
--- End Message ---
--- Begin Message ---
Source: planetary-system-stacker
Source-Version: 0.8.32~git20221019.66d7558-2
Done: Thorsten Alteholz
We believe that the bug you reported is fixed in the latest version of
planetary-system-stacker, which is due to be installed in the Debian FTP
archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1034...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Alteholz (supplier of updated
planetary-system-stacker package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 23 Apr 2023 09:35:45 +0200
Source: planetary-system-stacker
Architecture: source
Version: 0.8.32~git20221019.66d7558-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Astronomy Team
Changed-By: Thorsten Alteholz
Closes: 1034748
Changes:
planetary-system-stacker (0.8.32~git20221019.66d7558-2) unstable;
urgency=medium
.
* adapt to new version of numpy (Closes: #1034748)
Checksums-Sha1:
19611b7d7935cf16ffbd9cde604709d791a9724e 2502
planetary-system-stacker_0.8.32~git20221019.66d7558-2.dsc
ecc340d9262e28f2be51cf98d491abfa22418ffa 30182076
planetary-system-stacker_0.8.32~git20221019.66d7558.orig.tar.xz
9e0708a932e329994b0ad95db16a709c6d39b57b 3088
planetary-system-stacker_0.8.32~git20221019.66d7558-2.debian.tar.xz
fe0f518d092d72a67ff8955d62dea6e948adfb93 16254
planetary-system-stacker_0.8.32~git20221019.66d7558-2_amd64.buildinfo
Checksums-Sha256:
4002909285fcfd7a3a8ed6d9d40959ae219f1de1a925efa0fc95cf223e5a8374 2502
planetary-system-stacker_0.8.32~git20221019.66d7558-2.dsc
3f9fb0c98200fb6d07f51645aa7a7e4778b3112de3fd4c8a45066fe3dec22e6a 30182076
planetary-system-stacker_0.8.32~git20221019.66d7558.orig.tar.xz
9cbed7ecbb495d8cce3b8259f2b53b031c9062d9015010616c20ab2fa6a83fb2 3088
planetary-system-stacker_0.8.32~git20221019.66d7558-2.debian.tar.xz
1b85f1e128a03e7f395250cccb4eb6cdb04d130b3adac9a24c1b4222e6433bda 16254
Processed: tagging 965794
Processing commands for cont...@bugs.debian.org: > tags 965794 + pending Bug #965794 [python3-ooolib] python-ooolib: Removal of obsolete debhelper compat 5 and 6 in bookworm Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 965794: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965794 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034629: closing 1034629
close 1034629 thanks
Bug#1034748: PlanetarySystemStacker does not work anylonger
Package: planetary-system-stacker
Version: 0.8.32~git20221019.66d7558-1
Severity: grave
Due to a recent change in numpy, the planetary-system-stacker does not
work anylong and crashes during start:
Traceback (most recent call last):
File "/usr/bin/PlanetarySystemStacker", line 33, in
sys.exit(load_entry_point('planetary-system-stacker==0.9.3',
'console_scripts', 'PlanetarySystemStacker')())
File "/usr/bin/PlanetarySystemStacker", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File
"/usr/lib/python3/dist-packages/planetary_system_stacker/planetary_system_stacker.py",
line 64, in
from workflow import Workflow
File "/usr/lib/python3/dist-packages/planetary_system_stacker/workflow.py", line
40, in
from stack_frames import StackFrames
File "/usr/lib/python3/dist-packages/planetary_system_stacker/stack_frames.py",
line 33, in
from numpy import int as np_int
ImportError: cannot import name 'int' from 'numpy'
(/usr/lib/python3/dist-packages/numpy/__init__.py)
Processed: closing 1034629
Processing commands for cont...@bugs.debian.org:
> close 1034629
Bug #1034629 {Done: Jochen Sprickerhof }
[pdf-presenter-console] pdf-presenter-console: pdfpc terminates with symbol
lookup error
Bug 1034629 is already marked as done; not doing anything.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1034629: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034629
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
Wow, thanks everyone for tracking this down so quickly! I'm going to close it, since it was due to non-debian packages.
Processed: bump severity
Processing commands for cont...@bugs.debian.org:
> severity 918774 serious
Bug #918774 {Done: Nilesh Patra } [liblasi0] liblasi0:
response to missing system glyphs no longer works correctly
Severity set to 'serious' from 'important'
> stop
Stopping processing here.
Please contact me if you need assistance.
--
918774: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918774
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
