Bug#1067501: marked as pending in hipsolver
Control: tag -1 pending Hello, Bug #1067501 in hipsolver 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/rocm-team/hipsolver/-/commit/d51961aa5fc702bd5cf28c95240f85159c3e3801 Shift version of Breaks+Replaces for -dev to -doc move Closes: #1067501 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067501
Bug#1065353: marked as pending in rocsparse
Control: tag -1 pending Hello, Bug #1065353 in rocsparse 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/rocm-team/rocsparse/-/commit/328d612af51ece88548bbdd131648c705a993722 d/control: Add missing Breaks+Replaces for moved examples They are now part of the -doc package. Closes: #1065353 (this message was generated automatically) -- Greetings https://bugs.debian.org/1065353
Bug#1065351: marked as pending in rocblas
Control: tag -1 pending Hello, Bug #1065351 in rocblas 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/rocm-team/rocblas/-/commit/10bafdf7949eba57ae124741cba15e25ccb8beee d/control: Add missing Breaks+Replaces for moved examples They are now part of the -doc package. Closes: #1065351 (this message was generated automatically) -- Greetings https://bugs.debian.org/1065351
Bug#1064629: libamd-comgr2: segfault in rocfft
Hey Cory,
On 2024-02-28 21:16, Cordell Bloor wrote:
> This segfault does seem to be caused by mixing clang-15 and clang-17 in
> the HIP RTC codepath. When libamdhip64 from ROCm 5.6.1 (built with the
> same clang-17 as rocm-compilersupport 6.0+git20231212.4510c28+dfsg-1) is
> used, the segfault disappeared [1].
I think that this also needs to be fixed in bin:hipcc. It currently has
an unversioned Depends on libamdhip64-dev, making it possible to use
clang-17 hipcc with clang-15 libamdhip64-5.
# should also work with s/podman/docker/, of course
$ podman run --rm -it debian:experimental sh -c 'apt update && apt install -s
hipcc/experimental | grep "Inst.*libamdhip64"'
[...]
Inst libamdhip64-5 (5.2.3-13 Debian:unstable [amd64])
Inst libamdhip64-dev (5.2.3-13 Debian:unstable [amd64])
I'd file a bug and fix the dependency in rocm-hipamd myself, but I'm
only 90% confident that I'm not missing something, so wanted to check
first.
If it's indeed missing from bin:hipcc, I guess it should be updated to
libamdhip64-dev (= ${binary:Version})
Discovered when building the newer rocFFT, which only build-depends on
hipcc.
Best,
Christian
> [1]: https://ci.rocm.debian.net/packages/r/rocfft/unstable/amd64+gfx1030/7998/
Bug#1061208: Please upgrade to llvm-toolchain-17
Hi Étienne, On 2024-02-26 19:29, Étienne Mollier wrote: > If that helps, the autoremoval timer is reset each time the RC > critical bug triggering the autoremoval is updated, e.g. when > reporting an evolution of the situation in a new comment. thanks for the info! That's incredible useful to know. Funny how I never realized that this was a thing. Best, Christian
Bug#1061208: Please upgrade to llvm-toolchain-17
Hi Sebastian, writing to you as you bumped the severity to 'serious': could the rT please give us an extension on the autoremoval for this particular bug. The transition from first-filing-to-serious was unusually short notice, and caught us in the middle of our own update of the stack. This affects a key package of our stack, so it's not just about testing this particular package, but the entire stack, and everything else in the archive that depends on it. A fix is in progress. Best, Christian On 2024-01-20 21:59, Sylvestre Ledru wrote: > Source: rocm-hipamd > Severity: important > > Dear Maintainer, > > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -17. > > This package depends on 15.
Bug#1057265: cron: Uncheck return values of set*id() family functions
Hi Jeffrey, On 2023-12-02 11:39, Jeffrey Bencteux wrote: > Hi, > > Both setuid() and setgid() return values are not checked in cron's code used > to execute user-provided commands: This issue was reported as CVD-2006-2607 and fixed a long time ago. Here's the relevant patch: https://sources.debian.org/src/cron/3.0pl1-162/debian/patches/fixes/Check-privilege-drop-results-CVE-2006-2607.patch/ Are you perhaps looking at the unpatched source? Best, Christian
Bug#1050618: Invalid bug
Version: 5.5.1-1 Closing this bug, as it is invalid. rocrand never failed, according to the CI logs (even the linked one).
Bug#1051293: Acknowledgement (rocfft: soft lockup with gfx1034)
Control: severity -1 important I'm downgrading this bug, as the suite successfully completed on another Navi24 device [1]. No longer RC, this should allow migration to testing again. Best, Christian [1] https://lists.debian.org/debian-ai/2023/10/msg00044.html
Bug#1052954: marked as pending in rccl
Control: tag -1 pending Hello, Bug #1052954 in rccl 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/rocm-team/rccl/-/commit/b936acd42edaa2c278c693477add9c7d2560ef05 Filter cf-protection hardening from device code Fixes a FTBFS with dpkg >= 1.22 Closes: #1052954 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052954
Bug#1052968: marked as pending in hipcub
Control: tag -1 pending Hello, Bug #1052968 in hipcub 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/rocm-team/hipcub/-/commit/97247d25e7b4574622959e4d55a52b968a4f3dc6 Filter cf-protection hardening from device code Fixes a FTBFS with dpkg >= 1.22 Closes: #1052968 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052968
Bug#1051293: rocfft: soft lockup with gfx1034
Source: rocfft Version: 5.5.0-4 Severity: grave Justification: Can crash the host autopkgtests for rocfft triggered a soft lockup when run with an 6500 XT (gfx1034, Navi24). This is very probably a kernel issue, but I'm filing this bug here until we have actually identified the root cause, after which it can be reassigned.
Bug#1050618: rocrand: failing autopkgtests on gfx1030
Source: rocrand Version: 5.5.1-1 Severity: serious The tests from ci.rocm.debian.net failed on gfx1030 [1]. I'm filing this RC bug to prevent migration to testing. [1] https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1030/r/rocrand/83/log.gz
Bug#1045688: marked as pending in rocm-device-libs
Control: tag -1 pending Hello, Bug #1045688 in rocm-device-libs 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/rocm-team/rocm-device-libs/-/commit/a5eaa27183773abeba027d5f121407b13b587a63 Add libzstd-dev to Build-Depends Resolves a FTBFS. The last successful build is 11 months ago and didn't use this directly according to the build log, so I guess something in the toolchain changed. Closes: #1045688 (this message was generated automatically) -- Greetings https://bugs.debian.org/1045688
Bug#1038139: debci-worker: Process leaks authentication data via amqp-tools
On 2023-06-16 17:56, Antonio Terceiro wrote: > Note that the variable where you inserted a username and password is > calle debci_amqp_server, and was never supposed to be used for putting a > password in plain text. I think this is where the documentation of the --amqp option threw me off, from debci(1): --amqp amqp://[user:password@]hostname[:port] > For the c.d.n deployment we use SSL client certificates for > authentication, and that's why the variables debci_amqp_cacert, > debci_amqp_cert, debci_amqp_key are there. Yeah, I was guessing as much. I just wanted to make sure that in the case of only the server certificate + client auth/pass, there's a safer way to do that. > IMO that is no different from any other program that takes a url as a > command line parameter: you can pass a URL containing a username and > password, but then that's on you. Indeed. I only mentioned it since it's not entirely obvious for a first-time debci user that the debci_amqp_server config option is passed on via CLI to some other utility, rather than consumed by a library, or similar. Best, Christian
Bug#1038139: debci-worker: Process leaks authentication data via amqp-tools
Package: debci Version: 3.6 Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Hi, When using authentication in AMQP connections, the username and password supplied in the --url option to amqp-consume resp. amqp-publish are exposed in the proces list, see #1037322: $ pgrep -a ampq-consume 62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue A patch has been accepted upstream to read the username and password from a file. I assume this will make its way into ampq-tools soon. Unless I'm mistaken, debci will need to be updated for this, e.g. by adding a debci_amqp_pwfile config option + NEWS entry suggesting that people migrate to this new option. I'd be happy to file an MR for this, once ampq-tools has been fixed. Best, Christian -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debci depends on: ii adduser 3.118 pn amqp-tools ii curl7.88.1-7~bpo11+2 ii dctrl-tools 2.24-3+b1 ii debian-archive-keyring 2021.1.1+deb11u1 ii debootstrap 1.0.128+nmu2~bpo11+1 ii devscripts 2.22.2~bpo11+1 pn distro-info ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 ii jq 1.6-2.1 ii libjs-bootstrap 3.4.1+dfsg-2 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 pn libjs-jquery-flot pn moreutils ii netcat-openbsd 1.217-3 pn parallel ii patchutils 0.4.2-1 pn retry ii rsync 3.2.7-1~bpo11+1 ii ruby1:2.7+2 pn ruby-activerecord pn ruby-bunny pn ruby-erubi pn ruby-kaminari-activerecord pn ruby-pg pn ruby-sinatra pn ruby-sinatra-contrib pn ruby-sqlite3 pn ruby-thor pn sudo Versions of packages debci recommends: ii systemd-timesyncd [time-daemon] 252.5-2~bpo11+1 Versions of packages debci suggests: pn apt-cacher-ng
Bug#1037322: amqp-tools: Process leaks authentication data
Control: tag -1 fixed-upstream On 2023-06-11 12:28, Christian Kastner wrote: > Package: amqp-tools > Version: 0.11.0-1 > Severity: grave > Tags: security > Forwarded: https://github.com/alanxz/rabbitmq-c/issues/575 > > When passing authentication data with either --password or --url, the > data is exposed in the process list, where it can be seen by any user. > > Example: > $ pgrep -a ampq-consume > 62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue > > This is an upstream issue. I've filed a pull request upstream that adds > an option --authfile with which authentication data can be read from a file. A patch for this has been merged upstream: https://github.com/alanxz/rabbitmq-c/commit/463054383fbeef889b409a7f843df5365288e2a0 Best, Christian
Bug#1037322: amqp-tools: Process leaks authentication data
Package: amqp-tools Version: 0.11.0-1 Severity: grave Tags: security Forwarded: https://github.com/alanxz/rabbitmq-c/issues/575 When passing authentication data with either --password or --url, the data is exposed in the process list, where it can be seen by any user. Example: $ pgrep -a ampq-consume 62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue This is an upstream issue. I've filed a pull request upstream that adds an option --authfile with which authentication data can be read from a file. Best, Christian
Bug#1034476: librocprim-dev: Missing Depends on libamdhip64-dev
Package: librocprim-dev Version: 5.3.3-3 Severity: serious librocprim-dev needs libamdhip64-dev, but this dependency is missing from the package.
Bug#1032677: libamdhip64-5: Missing dependency on libamd-comgr2
Package: libamdhip64-5 Version: 5.2.3-5 Severity: serious When working on rocrand, I noticed that the rocrand libraries did not work without libamd-comgr2 installed. Cordell Bloor pointed out that libamd-comgr2 is essential to any library that contains GPU kernels, and the calls are likely to be made through libhipamd64-5. libamd-comgr2 is dynamically loaded, which is why dh_shlibdeps did not discover it.
Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?
(debian-ai, apologies for re-sending, I hit the wrong reply button.) On 2023-03-08 18:21, Simon McVittie wrote: > There is *a* version of llvm-toolchain-15 in bookworm, version 1:15.0.6-4, > which is used by the rocm-hipamd_5.2.3-1 and mesa_22.3.3-1 in bookworm. > I'm not suggesting that 1:15.0.6-4 should be *removed*. What I'm asking > here is whether it's intended to be upgraded to 1:15.0.7-1 (or presumably > a later version where #1029010 has been fixed), or kept at 1:15.0.6-4 Are the upstream differences between 15.0.6 and 15.0.7 that big? I think for rocm-hipamd, the main issue is that 5.2.3-5 depends on libclang-rt-15-dev, which was introduced to unstable by means of a package split in 1:15.0.7-1. I'm pretty sure rocm-hipamd could live with the version in bookworm, but it would need a new upload to change the dependency to reflect the pre-split view. In fact, we almost went so far as to implement just that, but we let it as-is after all, because we assumed that #1029010 would be resolved in due time, one way or another. Best, Christian
Bug#1026001: libpam-cap: file conflict with package libcap2-bin
On 2022-12-13 06:02, Christoph Anton Mitterer wrote: > On installation there is a file conflict: > Unpacking libpam-cap:amd64 (1:2.66-1) over (1:2.63-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-B9lzYA/08-libpam-cap_1%3a2.66-1_amd64.deb (--unpack): > trying to overwrite '/usr/share/man/man5/capability.conf.5.gz', which is > also in package libcap2-bin 1:2.63-1 > > Which is however resolved after libcap2-bin has been upgraded and > when one tries to install the former again. > > Guess a missing Replaces? You guessed correct. Thanks for pointing this out. Fix will be uploaded soon. Best, Christian
Bug#1025957: libcap-dev is wrongly marked Multi-Arch: same
Hi Helmut, you're quick! On 2022-12-12 15:17, Helmut Grohne wrote: > Package: libcap-dev > Version: 1:2.63-1 > Severity: serious > Jutsification: fails to install with an unpack errror > User: helm...@debian.org > Usertags: rebootstrap > > Coinstalling libcap-dev fails: > > | Unpacking libcap-dev:amd64 (1:2.63-1) ... > | dpkg: error processing archive > /var/cache/apt/archives/libcap-dev_1%3a2.63-1_amd64.deb (--unpack): > | trying to overwrite shared '/usr/lib/libcap2/tests/cap_test', which is > different from other instances of package libcap-dev:amd64 > | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > | Errors were encountered while processing: > | /var/cache/apt/archives/libcap-dev_1%3a2.63-1_amd64.deb > | E: Sub-process /usr/bin/dpkg returned an error code (1) I noticed this myself only too late -- lintian flagged all of these errors, but I had a bug in my workflow, and only source package checks were performed. > I suppose that the test binaries were recently added to the -dev > package. There are basically three ways of dealing with this: > > a) Drop Multi-Arch: same. This is a little inconvenient for some users, >but is really something we can do. Most cross builds will continue >working in the absence of Multi-Arch: same. > > b) Move those test binaries to architecture-dependent paths. This is what I did whilst preparing the 2.66 upload. I was going to wait for 2.63 to migrate, but might as well just push that now. > c) Move those test binaries to a different package. An obvious candidate >would be a new package libcap-tests. Prior art: dbus-tests. If you >do, it would be awesome to support the noinsttest build profile. Thanks for the prior art on that, I was unsure how to handle that. It definitely feels cleaner than shipping this with libcap-dev. I'll wait for 2.66 to migrate to testing first. Best, Christian
Bug#990026: Aaargh!
On 2022-03-08 21:58, Christian Kastner wrote: > I'll upload an NMU. Ah, pulling the newest source from Salsa, I saw Georges' @debian.org address. Apologies! In that case, please NMU it yourself (as you've already prepared the changelog). Best, Christian
Bug#990026: Aaargh!
Hi, FYI, cron is looking for a new maintainer, see #984736, so I guess that is why there hasn't been any activity yet. On 2021-06-22 16:52, Wouter Verhelst wrote: > Whoever wrote that patch should be slapped around the head with a copy > of RFC3696. As evident from the header, that patch was taken from cronie, RedHat's fork of cron-4.1. cronie is much more actively maintained than our own cron, which is a fork of Vixie cron... from 1993. > Go read it. Now, please. Understand it. Internalize it. Then update your > data verification code so that all valid email addresses will be > accepted. > > But first remove the "save_p" function from the cron implementation. It > is broken, and the fix may otherwise take too long, I suppose. The safe_p function and its use of were introduced in upstream, that is ISC cron 4.1 (from 2004), the basis for most cron daemons (cronie, OpenBSD's version, and others). On 2021-07-13 11:15, Georges Khaznadar wrote: > Hello, as bug #990026 got no update for three weeks, I uploaded a fix to > our salsa repository, which allows characters like "=" and "/" in e-mail > addresses. > > I add the patch as an attachment. I'll upload an NMU. Best, Christian
Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi, On 2022-02-16 11:57, John Paul Adrian Glaubitz wrote: > Hello! > > On 2/16/22 11:36, Graham Inggs wrote: >> Is anyone able to help with the bus error on armhf please? > > Bus errors are normally easy to spot. Just run the code in question through > GDB and see where it crashes. Then look at the backtrace with the debug > symbols installed. > > Usually it's a result of bad pointer arithmetics which should definitely be > fixed as such operations usually violate the C/C++ standards. > > I can have quick look. one of these errors has been reported in the past, and I already did some analysis way back then: https://github.com/scikit-learn/scikit-learn/issues/16443 Check the last comment. The relevant Cython code doesn't look wrong, so I guess the problem is with the binary result produced during build, as you point out. Best, Christian
Bug#984709: yubikey-luks: Stop exposing challenge in process list
On 08.03.21 20:26, Markus Frosch wrote: > Thanks for reporting, haven't been following upstream for a while since I > don't > use the package actively anymore. Admittedly, this particular information was somewhat buried. > Due to lack of time, I'll upload a minimal patch for now. Feel free to join in > maintaining. Sounds good. Best, Christian
Bug#984709: yubikey-luks: Stop exposing challenge in process list
Package: yubikey-luks Version: 0.5.1+29.g5df2b95-5 Severity: grave Justification: confidential information leak Tags: security Hi, Looking at the upstream yubikey-luks repository, I noticed what seems to be an important recent fix, namely for the password (used as the yubikey challenge) being exposed in the process list: https://github.com/cornelinux/yubikey-luks/pull/63 This affects stable, too. The fix from the PR seems simple enough, it just changes four LOC. I looked at the (non-whitespace, non-documentation) diff between our current version and HEAD, and it's not that big. Perhaps the RT would be even be willing to ACK an update to HEAD. Best, Christian
Bug#977067: Bug#977060: cwltool FTBFS with pytest 6
Hi, On 11.02.21 15:20, Nilesh Patra wrote: > On Sun, 7 Feb 2021 22:08:58 +0100 =?utf-8?Q?=C3=89tienne?= Mollier > wrote: >> I tried to reproduce the bug by building igdiscover 0.11-3 using >> sbuild in a clean Sid chroot which did include pytest 6: >> >> $ schroot -c unstable-amd64-sbuild -d / \ >> -- apt-cache show python3-pytest \ >> | grep Version: >> Version: 6.0.2-2 > > > According to last reproducible build result[1] shows that it is building > successfully on January 31, 2021 (~52 days after this bug was reported) > However there are a few FTBFS entries in there as well. So probably this is > an occasional failure? > > [1]: > https://tests.reproducible-builds.org/debian/history/amd64/igdiscover.html I tried N=1 build, and this time it succeeded. But Nilesh is right, reproducible builds failed occasionally, with the errors as I reported above. It looks as if some of the tests are flaky. Now, because these failures are not a pytest issue, I don't think this bug is valid any longer -- pytest 6 compatibility was the goal, and it is present. Please feel free to downgrade and retitle for the flakiness issue. Best, Christian
Bug#979300: sabnzbdplus autopkgtests fail with pytest 6
Source: sabnzbdplus Version: 3.1.1+dfsg-1 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, sabnzbdplus autopkgtests fail with pytest 6 in unstable. The problem seems to be the -k expression used to exclude particular tests: > ERROR: Wrong expression passed to '-k': tests and not ( > test_publicipv4 or test_extract_pot or > test_functional_downloads ortest_happyeyeballs or > test_internetspeed or test_permissions_450 or > test_http_params_etc or test_daemonizing > ): at column 210: unexpected character " > " The syntax accepted by -k has changed, see https://docs.pytest.org/en/stable/changelog.html#id101
Bug#979297: python-llfuse FTBFS with pytest 6
Source: python-llfuse Version: 1.3.6+dfsg-2 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, python-llfuse FTBFS with pytest 6 in unstable: > ERRORS > > _ ERROR at setup of test_inquire_bits > __ > Traceback (most recent call last): > File "/<>/test/pytest_checklogs.py", line 135, in > pytest_runtest_setup > check_output(item) > File "/<>/test/pytest_checklogs.py", line 131, in check_output > check_test_log(item.catch_log_handler) > AttributeError: 'Function' object has no attribute 'catch_log_handler' > ERROR at teardown of test_inquire_bits > > Traceback (most recent call last): > File "/<>/test/pytest_checklogs.py", line 141, in > pytest_runtest_teardown > check_output(item) > File "/<>/test/pytest_checklogs.py", line 131, in check_output > check_test_log(item.catch_log_handler) > AttributeError: 'Function' object has no attribute 'catch_log_handler' > === warnings summary > === > /<>/test/util.py:67 > /<>/test/util.py:67 > /<>/test/util.py:67: PytestUnknownMarkWarning: Unknown > pytest.mark.uses_fuse - is this a typo? You can register custom marks to > avoid this warning - for details, see > https://docs.pytest.org/en/stable/mark.html > return pytest.mark.uses_fuse() > > -- Docs: https://docs.pytest.org/en/stable/warnings.html > === short test summary info > > ERROR ../../../test/test_api.py::test_inquire_bits - AttributeError: > 'Functio... > ERROR ../../../test/test_api.py::test_inquire_bits - AttributeError: > 'Functio... > !! stopping after 2 failures > !!! > 2 warnings, 2 errors in 0.06s > = This has been fixed upstream: https://github.com/libfuse/libfuse/issues/510
Bug#979294: python-ase autopkgtests fail with pytest 6
Source: python-ase
Version: 3.20.1-1
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
python-ase autopkgtests with pytest 6 in unstable. Apparently, something
is trying to write to /usr/lib/:
> File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
> _multicall
> res = hook_impl.function(*args)
> File "/usr/lib/python3/dist-packages/_pytest/stepwise.py", line 122, in
> pytest_sessionfinish
> self.config.cache.set("cache/stepwise", [])
> File "/usr/lib/python3/dist-packages/_pytest/cacheprovider.py", line 151,
> in set
> self.warn("could not create cache path {path}", path=path)
> File "/usr/lib/python3/dist-packages/_pytest/cacheprovider.py", line 90, in
> warn
> warnings.warn(
> pytest.PytestCacheWarning: could not create cache path
> /usr/lib/python3/dist-packages/ase/test/.pytest_cache/v/cache/stepwise
In the previous debci run (with pytest 4.6.11), this was only warned about:
> /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:127
> /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:127:
> PytestCacheWarning: could not create cache path
> /usr/lib/python3/dist-packages/ase/test/.pytest_cache/v/cache/nodeids
> self.warn("could not create cache path {path}", path=path)
It seems as this has become a hard failure.
Bug#979291: xonsh autopkgtests fail with pytest 6
Source: xonsh Version: 0.9.24+dfsg-2 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, xonsh autopkgtests with pytest 6 in unstable because it uses a deprecated feature that will be removed soon, and that, by default, considered an error in pytest 6. The fragment of the CI the error log below has more details. > ERRORS > > ERROR collecting test session > _ > /usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__ > return self._hookexec(self, self.get_hookimpls(), kwargs) > /usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec > return self._inner_hookexec(hook, methods, kwargs) > /usr/lib/python3/dist-packages/pluggy/manager.py:83: in > self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall( > /usr/lib/python3/dist-packages/xonsh/pytest_plugin.py:44: in > pytest_collect_file > return XshFile(path, parent) > /usr/lib/python3/dist-packages/_pytest/nodes.py:95: in __call__ > warnings.warn(NODE_USE_FROM_PARENT.format(name=self.__name__), > stacklevel=2) > E pytest.PytestDeprecationWarning: Direct construction of XshFile has been > deprecated, please use XshFile.from_parent. > E See > https://docs.pytest.org/en/stable/deprecations.html#node-construction-changed-to-node-from-parent > for more details. > === short test summary info > > ERROR - pytest.PytestDeprecationWarning: Direct construction of XshFile has > ... > Interrupted: 1 error during collection > > === 1 error in 0.07s > ===
Bug#979290: pytest-mpi autopkgtests fail with pytest 6
Source: pytest-mpi Version: 0.4-2 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, pytest-mpi autopkgtests fail with pytest 6 in unstable. From the CI log below, for some reason, the test gets aborted at some point: > Testing with python3.9: > = test session starts > == > platform linux -- Python 3.9.1, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 > rootdir: /tmp/autopkgtest.zQV9kC/build.XJA/src > plugins: mpi-0+unknown > collected 13 items > > docs/markers.rst . [ > 7%] > docs/usage.rst ..[ > 23%] > tests/test_fixtures.py ... [ > 46%] > tests/test_markers.py .FF..Fatal Python error: Aborted > > Current thread 0x7fa7514af740 (most recent call first): > File "/usr/lib/python3.9/subprocess.py", line 1752 in _execute_child > File "/usr/lib/python3.9/subprocess.py", line 947 in __init__ > File "/usr/lib/python3/dist-packages/_pytest/pytester.py", line 1193 in > popen > File "/usr/lib/python3/dist-packages/_pytest/pytester.py", line 1234 in run > File "/tmp/autopkgtest.zQV9kC/build.XJA/src/tests/conftest.py", line 44 in > runpytest_subprocess > File "/tmp/autopkgtest.zQV9kC/build.XJA/src/tests/conftest.py", line 52 in > runpytest > File "/tmp/autopkgtest.zQV9kC/build.XJA/src/tests/test_markers.py", line > 113 in test_mpi_xfail_under_mpi > File "/usr/lib/python3/dist-packages/_pytest/python.py", line 180 in > pytest_pyfunc_call > File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in > _multicall > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in > _hookexec > File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in __call__ > File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1570 in > runtest > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 153 in > pytest_runtest_call > File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in > _multicall > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in > _hookexec > File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in __call__ > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 247 in > > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 294 in > from_call > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 246 in > call_runtest_hook > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 207 in > call_and_report > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 117 in > runtestprotocol > File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 100 in > pytest_runtest_protocol > File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in > _multicall > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in > _hookexec > File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in __call__ > File "/usr/lib/python3/dist-packages/_pytest/main.py", line 321 in > pytest_runtestloop > File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in > _multicall > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in > _hookexec > File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in __call__ > File "/usr/lib/python3/dist-packages/_pytest/main.py", line 296 in _main > File "/usr/lib/python3/dist-packages/_pytest/main.py", line 240 in > wrap_session > File "/usr/lib/python3/dist-packages/_pytest/main.py", line 289 in > pytest_cmdline_main > File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in > _multicall > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in > File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in > _hookexec > File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in __call__ > File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 157 > in main > File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 180 > in console_main > File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 7 in > File "/usr/lib/python3.9/runpy.py", line 87 in _run_code > File "/usr/lib/python3.9/runpy.py", line 197 in _run_module_as_main > .bash: line 1: 1425 Aborted $py -m pytest -p pytester > autopkgtest [23:28:58]: test command1: ---]
Bug#979288: ffc autopkgtests fail with pytest 6
Source: ffc Version: 2019.2.0~git20200123.6b621eb-3 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, ffc autopkgtests with pytest 6 in unstable because it uses a deprecated feature that will be removed soon, and that, by default, considered an error in pytest 6. The fragment of the CI the error log below has more details. > ERRORS > > ERROR collecting test session > _ > /usr/lib/python3.9/importlib/__init__.py:127: in import_module > return _bootstrap._gcd_import(name[level:], package, level) > :1030: in _gcd_import > ??? > :1007: in _find_and_load > ??? > :986: in _find_and_load_unlocked > ??? > :680: in _load_unlocked > ??? > /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:170: in > exec_module > exec(co, module.__dict__) > uflacs/crosslanguage/conftest.py:234: in > ??? > /usr/lib/python3/dist-packages/_pytest/fixtures.py:1358: in fixture > warnings.warn(FIXTURE_POSITIONAL_ARGUMENTS, stacklevel=2) > E pytest.PytestDeprecationWarning: Passing arguments to pytest.fixture() as > positional arguments is deprecated - pass them as a keyword argument instead. > === short test summary info > > ERROR .. - pytest.PytestDeprecationWarning: Passing arguments to > pytest.fixtu... > Interrupted: 1 error during collection > > === 1 error in 0.42s > ===
Bug#979286: gitsome autopkgtests fail with pytest 6
Source: gitsome Version: 0.8.0+ds-4 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, gitsome autopkgtests fail with pytest 6 in unstable because of changes to the use of TerminalWriter. See https://docs.pytest.org/en/stable/changelog.html#id60 The CI error log below has more details. > == 2 passed, 1 skipped, 39 warnings in 0.94s > === > run: OK > autopkgtest [06:35:40]: test test: ---] > autopkgtest [06:35:40]: test test: - - - - - - - - - - results - - - - - - - > - - - > test FAIL stderr: > /usr/lib/python3/dist-packages/_pytest/compat.py:340: > PytestDeprecationWarning: The TerminalReporter.writer attribute is > deprecated, use TerminalReporter._tw instead at your own risk. > autopkgtest [06:35:40]: test test: - - - - - - - - - - stderr - - - - - - - > - - - > /usr/lib/python3/dist-packages/_pytest/compat.py:340: > PytestDeprecationWarning: The TerminalReporter.writer attribute is > deprecated, use TerminalReporter._tw instead at your own risk. > See > https://docs.pytest.org/en/stable/deprecations.html#terminalreporter-writer > for more information. > return getattr(object, name, default) > autopkgtest [06:35:40]: summary > test FAIL stderr: > /usr/lib/python3/dist-packages/_pytest/compat.py:340: > PytestDeprecationWarning: The TerminalReporter.writer attribute is > deprecated, use TerminalReporter._tw instead at your own risk.
Bug#979285: docopt autopkgtests fail with with pytest 6
Source: docopt Version: 0.6.2-2.2 Severity: serious User: pyt...@packages.debian.org Usertags: pytest-v6 Hi, docopt autopkgtests fail with pytest 6 in unstable because it uses a deprecated feature that will be removed soon, and that, by default, considered an error in pytest 6. The fragment of the CI error log below has more details. > ERRORS > > ERROR collecting test session > _ > /usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__ > return self._hookexec(self, self.get_hookimpls(), kwargs) > /usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec > return self._inner_hookexec(hook, methods, kwargs) > /usr/lib/python3/dist-packages/pluggy/manager.py:83: in > self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall( > conftest.py:14: in pytest_collect_file > return DocoptTestFile(path, parent) > /usr/lib/python3/dist-packages/_pytest/nodes.py:95: in __call__ > warnings.warn(NODE_USE_FROM_PARENT.format(name=self.__name__), > stacklevel=2) > E pytest.PytestDeprecationWarning: Direct construction of DocoptTestFile > has been deprecated, please use DocoptTestFile.from_parent. > E See > https://docs.pytest.org/en/stable/deprecations.html#node-construction-changed-to-node-from-parent > for more details. > === short test summary info > > ERROR - pytest.PytestDeprecationWarning: Direct construction of > DocoptTestFi... > Interrupted: 1 error during collection > > === 1 error in 0.08s > === > autopkgtest [06:22:29]: test unittests: ---] > autopkgtest [06:22:30]: test unittests: - - - - - - - - - - results - - - - > - - - - - - > unittestsFAIL non-zero exit status 2
Bug#976995: Error importing plugin "pytest_tornasync": No module named 'pytest_tornasync'
Control: severity -1 important Tags: -1 unreproducible Hi Julien, I'm downgrading because the pytest currently does work with hundreds of packages, implying that it cannot be (generally) unusable. On Wed, 09 Dec 2020 21:08:39 +0100 Julien Puydt wrote: > I was trying to update another package in the Debian Python Team, and > couldn't understand why its testsuite failed with the above error. > > After some failed poking around, I put the following in a file named > test_foo.py: > > def test_foo(): > pass This works fine in a clean environment on my end. > PS: the full trace is: > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", > line 572, in import_plugin > __import__(importspec) > ModuleNotFoundError: No module named 'pytest_tornasync' That's looking for the tornasync plugin [1], which is not available in Debian. I assume that your source package needs this in one way or another, and it is failing because of this. Could you try to run your test_foo.py above in some other directory? If it works, I recommend checking the upstream source for tornasync, and which part of the tests require it. [1] https://pypi.org/project/pytest-tornasync/ Best, Christian
Bug#975412: elementpath breaks python-xmlschema autopkgtest: lots of errors
Control: notfound -1 elementpath/2.0.4-1 Control: reassign -1 python-xmlschema On 11/21/20 9:50 PM, Paul Gevers wrote: > Source: elementpath, python-xmlschema > Control: found -1 elementpath/2.0.4-1 > Control: found -1 python-xmlschema/1.2.2-2 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of elementpath the autopkgtest of python-xmlschema > fails in testing when that autopkgtest is run with the binary packages > of elementpath from unstable. It passes when run with only packages from > testing. In tabular form: > >passfail > elementpathfrom testing2.0.4-1 > python-xmlschema from testing1.2.2-2 > all others from testingfrom testing This appears to have been caused by xmlschema. I just updated it to 1.3.1, it built fine, and autopkgtest also ran without issues. The fix will be uploaded shortly. Thanks, Christian
Bug#973816: qemu-sbuild-utils
Source: qemu-sbuild-utils Version: 0.1 Severity: serious X-Debbugs-CC: jo...@debian.org The sbuild maintainers raised the valid point that it might be better to incorporate large parts of this software in src:sbuild, in which case this package should not enter bullseye. So until this question is resolved, an RC bug is filed so that this package does not migrate.
Bug#965354: bcolz: FTBFS with newer python3-numpydoc
Control: retitle -1 bcolz: FTBFS with newer python3-sphinx On Mon, 20 Jul 2020 09:51:26 +0200 Christian Kastner wrote: > Source: bcolz > Version: 1.2.1+ds2-5 > Severity: serious > Justification: FTBFS
Bug#965362: numpydoc: please make the build reproducible
On 2020-07-20 11:22:16 +0100 "Chris Lamb" wrote: > Whilst working on the Reproducible Builds effort [0] we noticed that > numpydoc could not be built reproducibly. > > This is because it includes a junit-results.xml and .coverage file > from the test run. (The latter file should have been detected by the > package-contains-python-coverage-file Lintian tag FYI.) This was caused by me again, for the same silly reason as in #968557 (broken alias for lintian). I only now saw this bug. Sorry about that. Fix will be uploaded shortly.
Bug#965362: marked as pending in numpydoc
Control: tag -1 pending Hello, Bug #965362 in numpydoc 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/python-team/modules/numpydoc/-/commit/627063a3a5c88b74b9bc8a7b6ac587ca8e508221 Remove .coverage and junit-results.xml from build result Closes: #965362 (this message was generated automatically) -- Greetings https://bugs.debian.org/965362
Bug#968410: python3-setuptools: ModuleNotFoundError: No module named '_distutils_hack'
Package: python3-setuptools Version: 49.3.1-1 Severity: grave Justification: Package is unusable The most recent upload broke something badly, setuptools can no longer be imported: $ python3 -c 'import setuptools' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 8, in import _distutils_hack.override # noqa: F401 ModuleNotFoundError: No module named '_distutils_hack' -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-setuptools depends on: ii python33.8.2-3 ii python3-distutils 3.8.5-1 ii python3-pkg-resources 49.3.1-1 python3-setuptools recommends no packages. Versions of packages python3-setuptools suggests: pn python-setuptools-doc -- debconf-show failed
Bug#965354: bcolz: FTBFS with newer python3-numpydoc
Source: bcolz
Version: 1.2.1+ds2-5
Severity: serious
Justification: FTBFS
Hi,
bcolz FTBFS on amd64 with an updated version of python3-numpydoc.
Here is the tail of the build log. The error seems to originate
during the build of the documentation:
PYTHONPATH=/<>/.pybuild/cpython3_3.8_bcolz/build \
http_proxy='127.0.0.1:9' sphinx-build -N docs/
debian/bcolz-doc/usr/share/doc/bcolz-doc/html/
Running Sphinx v2.4.3
making output directory... done
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 7 source files that are out of date
updating environment: [new config] 7 added, 0 changed, 0 removed
reading sources... [ 14%] defaults
reading sources... [ 28%] index
reading sources... [ 42%] install
reading sources... [ 57%] intro
reading sources... [ 71%] opt-tips
reading sources... [ 85%] reference
Exception occurred:
File "/usr/lib/python3/dist-packages/numpydoc/docscrape.py", line 324, in
_parse_see_also
raise ParseError("%s is not a item name" % line)
numpydoc.docscrape.ParseError: cparams.setdefaults() is not a item name in
"cparams(clevel=None, shuffle=None, cname=None, quantize=None)\n\nClass to host
parameters for compression and other filters.\n\nParameters\n--\nclevel
: int (0 <= clevel < 10)\nThe compression level.\nshuffle : int\nThe
shuffle filter to be activated. Allowed values are\nbcolz.NOSHUFFLE (0),
bcolz.SHUFFLE (1) and bcolz.BITSHUFFLE (2). The\ndefault is
bcolz.SHUFFLE.\ncname : string ('blosclz', 'lz4', 'lz4hc', 'snappy', 'zlib',
'zstd')\nSelect the compressor to use inside Blosc.\nquantize : int (number
of significant digits)\nQuantize data to improve (lossy) compression. Data
is quantized using\nnp.around(scale*data)/scale, where scale is 2**bits,
and bits is\ndetermined from the quantize value. For example, if
quantize=1, bits\nwill be 4. 0 means that the quantization is
disabled.\n\nIn case some of the parameters are not passed, they will be\nset
to a default (see `setdefaults()` method).\n\nSee
also\n\ncparams.setdefaults()"
The full traceback has been saved in /tmp/sphinx-err-ec7z35mu.log, if you want
to report the issue to the developers.
Please also report this if it was a user error, so that a better error message
can be provided next time.
A bug report can be filed in the tracker at
. Thanks!
make[1]: Leaving directory '/<>'
make[1]: *** [debian/rules:22: override_dh_auto_install] Error 2
make: *** [debian/rules:17: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit
status 2
Bug#955054: marked as pending in pygments
Control: tag -1 pending Hello, Bug #955054 in pygments 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/python-team/modules/pygments/-/commit/1c2457565eced489b16a59834a7a09806dd25ba1 Add Adapt-conf.py-for-sphinx-2.0.patch Resolves a FTBFS with the new sphinx. (Closes: #955054) (this message was generated automatically) -- Greetings https://bugs.debian.org/955054
Bug#955081: marked as pending in deap
Control: tag -1 pending Hello, Bug #955081 in deap 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/python-team/modules/deap/-/commit/4b6a0899db3b58784e5bf8a440289933785f24cf Add Adapt-conf.py-for-sphinx-2.0.patch Resolves a FTBFS with the new sphinx. (Closes: #955081) (this message was generated automatically) -- Greetings https://bugs.debian.org/955081
Bug#951222: scikit-learn breaks python-skbio autopkgtest: skbio.stats.distance._permdisp.permdisp
Control: reassign -1 python-skbio On 2020-02-12 20:00:16 +0100 Paul Gevers wrote: > With a recent upload of scikit-learn the autopkgtest of python-skbio > fails in testing when that autopkgtest is run with the binary packages > of scikit-learn from unstable. It passes when run with only packages > from testing. In tabular form: >passfail > scikit-learn from testing0.22.1+dfsg-1 > python-skbio from testing0.5.5-3 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of scikit-learn to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? As indicated in a previous reply, the test case itself runs fine with scikit-learn 0.22.2.post1+dfsg-5 (and even earlier) when called through pytest. It's only when python-skbio's internal test runner is called that the test fails. Therefore, one can probably safely assume that the issue must originate there. Furthermore, as python-skbio was already removed from testing and therefore, a newer scikit-learn won't be an issue there, I'm reassigning this to python-skbio only, so that scikit-learn can migrate.
Bug#951222: scikit-learn breaks python-skbio autopkgtest: skbio.stats.distance._permdisp.permdisp
On 2020-02-13 09:31:54 +0100 Andreas Tille wrote: > Control: tags -1 upstream > Control: forwarded -1 https://github.com/biocore/scikit-bio/issues/1693 > > > Due to the nature of this issue, I filed this bug report > > against both packages. Can you please investigate the situation and > > reassign the bug to the right package? > > I admit I'm not sure what package needs to be fixed but in any case I've > forwarded the issue to python-skbio upstream to make them aware of this. > My observation is that responses to bug reports of scikit-bio github are > not to be expected in a short time frame. I'm also not sure whether the > upstream tag / forward for python-skbio might hide the issue from > scikit-learn maintainers view - I have no idea where the issue really > needs to be fixed. I've been working on fixing the open issues of src:scikit-learn, and looked into this bug. This is odd. When executing the failing test code manually, the output is just as expected (p = 0.35). The output is also just as expected when the test suite is run at build time [1], as all tests pass. It's only when autopkgtest invokes the tests that this test fails. At build time, tests are simply run (by pybuild) with, python3.x -m pytest whereas the autopkgtest calls python3 -m skbio.test so I assume it has something to do with the latter. I did not investigate this further, I just reported this back upstream to the referenced GitHub issue. [1] https://buildd.debian.org/status/fetch.php?pkg=python-skbio=amd64=0.5.5-7=1582910349=0
Bug#950317: libsvm: autopkgtest regression: test depends on non-existing package svm-tools
Control: tag -1 pending On 31.01.20 11:33, Paul Gevers wrote: > Source: libsvm > Version: 3.24+ds-2 > X-Debbugs-CC: debian...@lists.debian.org > Severity: serious > User: debian...@lists.debian.org > Usertags: fails-always > > Dear maintainers, > > With a recent upload of libsvm you added an autopkgtest to libsvm, > great. However, it fails. I copied some of the output at the bottom of > this report. It seems you made a typo in your test depends. I think you > want to test your own package libsvm-tools. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=libsvm > > https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsvm/4067123/log.gz > > E: Unable to locate package svm-tools >
Bug#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
On 19.01.20 11:06, PICCA Frederic-Emmanuel wrote: > Hello, if it is like for my ufo-core package, this could be due to a script > file with a shebang using python instead of python3 I just tested this and indeed, there were scripts with said python in the shebang. Changing this to python3 fixed the build. Thank you very much for this hint!
Bug#936924: libsvm: Python2 removal in sid/bullseye - reopen 936924
On 19.01.20 03:23, Sandro Tosi wrote:
> This bug was closed, but the package has still some dependencies towards
> Python2 packages, in details:
>
> (binary:libsvm-tools)Depends->python:any
>
> Re-opening, so that they can be taken care of.
I believe I am missing something; could you expand on this?
I can't find any remnants of Python2 in the package.
In the control file, the binary package only depends on
${python3:Depends}, and this is substituded with
$ grep python3 debian/libsvm-tools.substvars
python3:Depends=python:any
Bug#936924: Moving libsvm to Debian Science team
On 11.01.20 06:09, Andreas Tille wrote: > On Fri, Jan 10, 2020 at 11:45:15PM +0100, Christian Kastner wrote:> Strange. > I did not intentionally set the branch protection. Hope it > works now. Pushing worked after this, thanks. I test-rebuilt all packages with build dependencies on libsvm packages, and most of them built successfully. Here are the issues I encountered: * src:pymvpa2 Can't be built because of removed Python 2 dependencies, and without a Python3 package will itself be removed eventually, I guess * src:openms FTBFS, but for unrelated reasons (#943450, issue with new doxygen) * src:python-sklearn FTBFS because of 3 test suite errors, but also does so with libsvm-3.21+ds-1.2, with the exact same errors. The errors do not seem to be related to libsvm, eg [1]. I'm working on an updated version of python-sklearn, so I'll look into that separately. [1] https://github.com/scikit-learn/scikit-learn/pull/12890 As the three issues above are not directly related to the new version of libsvm, I saw no reason to stall any longer, so I went ahead and tagged and uploaded 3.24+ds-1. Thanks, all, for the collaboration!
Bug#936924: Moving libsvm to Debian Science team
Hi all, On 10.01.20 15:33, Chen-Tse Tsai wrote: > Yes, my changes are merged. I checked the package and everything looks pretty good. I just added some minor polishing of my own. Very surprisingly, not a single symbol has changed since 3.21 -- no additions, no removals, no changes. It looks as we will be spared a transition! @Andreas: I can't push my changes to master, I get a protected branch error. Could you please grant me the necessary privileges? > I won't be able to work on it in the next few days. Thanks for your > help! If you want, it would be great to add you as an Uploader since you > know these packages really well. Done! There's a lintian info about a missing JAR, but I suspect that has more to do with the symlink from libsvm-java pointing to libsvm3-java. I added a simple autopkgtest and it passed. Seeing as the symbols didn't change a bit, I can see no reason why this couldn't be uploaded as-is, but I'm tired and I'd like to check it again tomorrow with a fresh pair of eyes, lest we break something. Christian
Bug#936924: Moving libsvm to Debian Science team
On 10.01.20 11:07, Andreas Tille wrote: > since my upload was a bit questionable this gives us the chance > to discuss it again. What option would you prefer: > >1. I just re-upload what is in Git right now to new queue >2. Somebody who feels more competent takes over >3. Something else I dropped the ball on this when I got back from the holidays, but I can look into it now. Chen-Tse, is your work already in the git repo on Salsa?
Bug#936924: Moving libsvm to Debian Science team
On 2019-12-25 18:08, Chen-Tse Tsai wrote: > Thanks Andreas and Christian for the updates/comments. I agree that I > should have been more verbose in the changelog. I'm tracing all the > commits to learn more about packaging. I was playing with gbp for > updating upstream. I really like how it works with git! No worries, my > time was not wasted anyway. If you like gbp, then it's already a team win :-) > > I talked to Christian briefly about the symbol file. He added one for > liblinear4. I have a question about this file. The symbol file I > generated looks a bit different from liblinear4.symbols, in which > several lines start with (c++) and contain the exact parameters. I > couldn't figure out how to make dpkg-gensymbols produce this. Yeah, the C++ symbols generated are the mangled versions. You need to unmangle them by piping the generated file through c++filt, and then add the (c++) prefix to tell dpkg-gensymbols about this. The UsingSymbolsFiles [1] page has a practical example on the bottom. The c++filt(1) and dpkg-gensymbols(1) man pages have theoretical background on this, but TBH, I don't think it's needed. There are voices that say that symbols files for C++ libraries are overly hard to maintain, but in case of this specific upstream, I didn't have a negative experience, and it did help me detect breaking changes a few times. [1] https://wiki.debian.org/UsingSymbolsFiles
Bug#936924: Moving libsvm to Debian Science team
On 2019-12-25 10:59, Andreas Tille wrote: > Kind regards > >Andreas. I've re-read my original message and feel that I was overly harsh. I was irritated about the rushed upgrade as in private communication with Chen-Tse, I highlighted precisely the possible complexity of this upgrade and how it should be performed properly -- but, that was private communication. Apologies.
Bug#936924: Moving libsvm to Debian Science team
Andreas, what are you doing? On 2019-12-25 07:52, Andreas Tille wrote: > On Tue, Dec 24, 2019 at 10:39:55AM -0500, Chen-Tse Tsai wrote: >> I just submitted a PR for dropping python2 dependencies: >> https://salsa.debian.org/science-team/libsvm/merge_requests/1 >> >> Any comment is appreciated. I'll be working on upgrading to new upstream. > > Looks very good! I injected the patch by Helmut Grohne (#862234) as well. 24 files changed, but debian/changelog only contains two entries. Nothing about changes to debhelper compat level, patches, etc. It would have been far more helpful to Chen-Tse (and thus to the team) to supply feedback on this. Looking at Salsa, you also imported the new upstream version 3.24 an hour ago, something that Chen-Tse said just before that he would be working on? Is he wasting his time now? Furthermore, I indicated previously that after 3 years, we will almost certainly need a transition (upstream's versioning does not reflect SOVER. We arrived at liblinear4 from liblinear1 entirely from Debian builds discovering backwards-incompatible changes). Did you check this before updating to 3.24? Can you please not rush things like this? This package has been sitting there for 3 years, a few Christmas Holiday days more or less will not make a difference. I (who happens to maintain another package by the same upstream) offered to help from the 27th; this could have waited until then and would have profited from doing so.
Bug#936924: Moving libsvm to Debian Science team
Hi all, Regarding liblinear: I thought I already set the Maintainer to Debian Science Team, I guess I missed it. On 2019-12-21 20:11, Chen-Tse Tsai wrote: > I've created an account on Salsa. > > Do you think we should remove cdbs and use another build system > instead? Please let me know if you have any suggestion. I'm not > familiar with other build systems. Yep, the Debian Policy was updated and recommends dh now. @Andreas: Chen-Tse and I discussed upgrading the package in October (I think), but both did not have the time back then. I could also help with some work starting on the 27th or so. As src:liblinear and src:libsvm have the same upstream, they are quite similar WRT to building, so src:liblinear (which is up to date) might have some helpful ideas. Given that the last libsvm update was a while ago, I wouldn't be surprised if a transition were necessary.
Bug#850692: pyrit: failed with 'BitEnumField' object has no attribute 'names'
Hi all, first of all, apologies for the late reply. I moved in February, and I'm still in the process of settling in. I have still to unpack my development machine... On 2017-02-14 09:39, Raphael Hertzog wrote: > On Mon, 09 Jan 2017, Sophie Brun wrote: >> AttributeError: 'BitEnumField' object has no attribute 'names' > [...] >> Consider joining the pkg-security team, we could co-maintain pyrit there: >> https://wiki.debian.org/Teams/pkg-security I would very much be interested in moving this to pkg-security. Even further -- if anyone is interested in taking over as primary maintainer, I'd be happy to step down, as I am no longer an active user of pyrit. Otherwise, I'll continue maintaining it. > you haven't replied to this bug in more than a month. Someone upgraded it > to RC severity because the package FTBFS actually. > > So we should handle it promptly now. In the pkg-security team, we're > willing to help you on this package... please reply and let us know how to > proceed. Please go ahead and upload anything you want/need. I don't think I will be able to implement any changes myself prior to 2017-03-04. If anyone could cake a look at #855166 (a new FTBFS), that would be great. Otherwise I'll do that on the upcoming weekend. > If I don't hear back from you, I'll assume that it's ok to move the > package to pkg-security. Full ACK on moving to pkg-security. Regards, Chrsitian signature.asc Description: OpenPGP digital signature
Bug#834674: pyevolve: FTBFS in testing (Format: "jpeg" not recognized)
Control: reassign -1 graphviz
Control: merge -1 827806
Hi Santiago,
On 2016-08-18 00:21, Santiago Vila wrote:
> Traceback (most recent call last):
> File "pyevolve_ex19_gp.py", line 85, in
> main_run()
> File "pyevolve_ex19_gp.py", line 82, in main_run
> graph.write_jpeg('tree.png', prog='dot')
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1746, in
> lambda path, f=frmt, prog=self.prog: self.write(path, format=f, prog=prog)
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1851, in write
> fobj.write(self.create(prog, format))
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1961, in create
> status, stderr_output))
> pydot.InvocationException: Program terminated with status: 1. stderr follows:
> Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps
> fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg
> svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
This is caused by a dependency. Merging with previous reports.
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized
On 2016-07-03 12:30, László Böszörményi (GCS) wrote: > In that clean chroot, may you rebuild -13 from source? Then install > it still in that chroot and see the output of 'dot'. You were right: with a rebuilt -13, jpeg is no longer present in 'device', either: device : canon cmap cmapx cmapx_np dot eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg signature.asc Description: OpenPGP digital signature
Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized
On 2016-07-03 09:26, László Böszörményi (GCS) wrote: > Hi Christian, > > On Sat, Jul 2, 2016 at 10:05 PM, Christian Kastner <c...@debian.org> wrote: >> On 2016-07-02 22:03, Christian Kastner wrote: >>> Support for jpeg seems to have disappeared in graphviz 2.38.0-14: >>> >>> $ dot -Tjpeg >>> Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np >>> dot eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps >>> ps2 svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib > Was it part of the 'Format' output? Do you still see advertised jpeg > support via 'loadimage' when you issue 'dot -v notexist'? Relevant output from -13: device : canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg pdf pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz vrml wbmp x11 xdot xdot1.2 xdot1.4 xlib loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg xbm Relevant output from -14: device : canon cmap cmapx cmapx_np dot eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg Note that jpeg disappeared from 'device', but is still listed in 'loadimage'. >>> With 2.38.0-13, everything is still fine. > Do you still have it in your apt cache or how did you get the > binaries? I downloaded them from snapshot.debian.org. Yesterday, I just downgraded the package, but today I used a clean chroot. $ for package in graphviz libcdt5 libcgraph6 libgvc6 libxdot4 libvgpr2; \ do \ debsnap --destdir . -a amd64 $package 2.38.0-13; \ done > I may try to test those during DebConf'16, but please note > I've serious network problems. I got an USB WiFi card for my laptop, > which is said to work correctly in a desktop machine. But in my > laptop, after a minute (maybe less) it fails to connect to anything. > Nothing related in the logs. If I renew my IP (ifdown / ifup), I get > an other minute of network. This kills me and makes even simple > internet browsing hard. :( Sorry to hear that :-/ >> This is probably related to #827675. > Can be. I've the sources for -13 and -14 locally and I've rebuilt -13 > in a mostly clean chroot. After downgrading to it, I still get the > 'jpeg' format not recognized error. This strengthens me in that it's > not a problem in graphviz itself, but an underlying library. Maybe > related to the Jasper (JPEG2000 support) removal[1]? Strange. As I said, above test against was done against a clean -13 chroot. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized
On 2016-07-02 22:03, Christian Kastner wrote: > Support for jpeg seems to have disappeared in graphviz 2.38.0-14: > > $ dot -Tjpeg > Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np dot > eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 > svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib > > With 2.38.0-13, everything is still fine. This is probably related to #827675. signature.asc Description: OpenPGP digital signature
Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized
Control: reassign -1 graphviz
Hi Laszlo,
On 2016-06-21 11:59, Chris Lamb wrote:
> Source: pyevolve
> Version: 0.6~rc1+svn398+dfsg-9
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> pyevolve fails to build from source in unstable/amd64:
>
> [..]
> Traceback (most recent call last):
> File "pyevolve_ex19_gp.py", line 85, in
> main_run()
> File "pyevolve_ex19_gp.py", line 82, in main_run
> graph.write_jpeg('tree.png', prog='dot')
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1746, in
> lambda path, f=frmt, prog=self.prog: self.write(path, format=f,
> prog=prog)
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1851, in write
> fobj.write(self.create(prog, format))
> File "/usr/lib/python2.7/dist-packages/pydot.py", line 1961, in create
> status, stderr_output))
> pydot.InvocationException: Program terminated with status: 1. stderr
> follows: Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np
> dot eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps
> ps2 svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
Support for jpeg seems to have disappeared in graphviz 2.38.0-14:
$ dot -Tjpeg
Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np dot
eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg
svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
With 2.38.0-13, everything is still fine.
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
Bug#823880: libsvm : binary files in source package
Control: severity -1 minor Hi Dominique, On 2016-05-10 01:52, Dominique Belhachemi wrote: > Package: libsvm > Version: 3.12-1.1 > Severity: serious > > The source package contains binary files, see > > https://sources.debian.net/src/libsvm/3.12-1.1/windows/ > https://sources.debian.net/src/libsvm/3.12-1.1/java/ I think there is a misunderstanding here: binaries per se are not a violation of the Policy (which would indeed warrant a "serious" severity). They are only a violation when the source is not provided. See eg the following lintian tags with severity of just "pedantic": * source-contains-prebuilt-windows-binary * source-contains-prebuilt-java-object In this particular case, the files in windows/ and java/ are just pre-built binaries provided by upstream as a convenience to the user. They are built from the very same source (see eg: Makefile.win). Of course, it would better to repack and not include these at all, but this is a minor issue. > v3.12 is from 2012, please consider an update to a recent version ( > https://github.com/cjlin1/libsvm/releases ) Chen-Tse and I are already working on this. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#809167: cron: Cron Daemon Use-After-Free Vulnerability May Cause Local Root Privilege Escalation
Hi, thank you for your report. I've already spent a good amount of time analyzing the potential impact of this flaw, but I would like to refrain from further public comments until I have discussed this with security@d.o. Thanks, Christian On 2015-12-27 19:57, Cron Daemon Use-After-Free Vulnerability May Cause Local Root Privilege Escalation wrote: > Package: cron > Version: 3.0pl1-127+deb8u1 > Severity: critical > Tags: security > Justification: root security hole > > > Hi Debian Security Team: > > I recently started to read the source code of Cron / Crontab and I think I > found a vulnerability in that. [...] signature.asc Description: OpenPGP digital signature
Bug#804426: gitinspector: FTBFS: ImportError: No module named unittest2
Control: tag -1 confirmed pending Hi Chris, On 2015-11-08 12:51, Chris Lamb wrote: > Dear Maintainer, > > gitinspector fails to build from source in unstable/amd64: > > == > ERROR: tests.test_comment (unittest.loader.ModuleImportFailure) > -- > ImportError: Failed to import test module: tests.test_comment > Traceback (most recent call last): > File "/usr/lib/python2.7/unittest/loader.py", line 254, in > _find_tests > module = self._get_module_from_name(name) > File "/usr/lib/python2.7/unittest/loader.py", line 232, in > _get_module_from_name > __import__(name) > File "tests/test_comment.py", line 23, in > import unittest2 > ImportError: No module named unittest2 thank you for the report. I added python-unittest2 to Build-Depends. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#787542: Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
Hi all, On 2015-06-03 00:02, Cyril Brulebois wrote: Michael Biebl bi...@debian.org (2015-06-02): Control: block -1 by 782475 Am 02.06.2015 um 18:11 schrieb Cyril Brulebois: libudev1-udeb depends on missing libcap2. I suspect the easiest would be to drop libcap2 support from the udeb build. An alternative would be to try and add a udeb in libcap2. I'd rather have the former happen, so Unfortunately, the libcap dependency is not really optional, i.e. it can not be turned off with a --disable-libcap configure switch. Yeah, I tried to briefly look at debian/rules and configure.ac… While we could try and hack the build system and ifdeffing this code out, I'd much prefer if we didn't have to do that and simply build a udeb for libcap Matthias already provided a patch for that [1]. @Christian, you mentioned that you were ok with this patch and wanted to include this in your next upload. Would be great if you can proceed with the upload now that v220 is in unstable which depends on it. Since Christian mentioned in his reply a fix might land this weekend, I'm fine with getting an extra udeb (provided it's small enough, which shouldn't be much of an issue for such a lib), especially since this has been tested in a derivative beforehands. Sorry for the delay, I was AFK until just now. I've prepared a quick upload consisting of only Matthias' patch, minus the superfluous d/shlibs.local as discussed in Michael's follow-up to the patch. I do still need a sponsor, though. For whomever is willing to act as such, a source package can be obtained from the following link, http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc or, alternatively, via the git repo git://anonscm.debian.org/collab-maint/libcap2.git using gbp. Please let me know if there is anything else I can do. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#783683: cron started with -f (foreground), killing processes on restart
Hi, On 2015-06-06 21:33, Christoph Berg wrote: Re: Christian Kastner 2015-05-03 554626d8.4090...@kvr.at I'd strongly opt to change the KillMode as mentioned above. #debian-devel seems to agree, so I'm upgrading this bug to RC. (critical as it's killing random processes) A particular reason why the current behavior is bad is that it is common practise to start user daemons using @reboot cronjobs. I was wondering what the use case for this was, but that seems plausible. Regardless, I committed a fix for the sole fact that it's a significant deviation from past behavior, as you pointed out. I've prepared packages for both jessie and unstable. I had hoped to see this fixed in today's point release. What happened with the jessie package? I'm afraid I couldn't get a hold of Javier regarding an upload. I myself don't have upload rights yet. I meant to take care of this before I went AFK for the weekend, but I forgot about this :-/ If an upload to jessie-p-u is still a possibility and you'd like to sponsor, a package for jessie has been prepared on the jessie branch. It was already ACKed by the RT, see #785573. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787542: Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
Hi again, On 2015-06-07 23:22, Cyril Brulebois wrote: Christian Kastner deb...@kvr.at (2015-06-07): Sorry for the delay, I was AFK until just now. I've prepared a quick upload consisting of only Matthias' patch, minus the superfluous d/shlibs.local as discussed in Michael's follow-up to the patch. I do still need a sponsor, though. For whomever is willing to act as such, a source package can be obtained from the following link, http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc or, alternatively, via the git repo git://anonscm.debian.org/collab-maint/libcap2.git using gbp. Please let me know if there is anything else I can do. I've just tried to build your package, to rebuild systemd and d-i afterwards but it failed with: | dh_makeshlibs -plibcap2 --add-udeb=libcap2-udeb -- -c4 | dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below | dpkg-gensymbols: warning: debian/libcap2/DEBIAN/symbols doesn't match completely debian/libcap2.symbols | --- debian/libcap2.symbols (libcap2_1:2.24-9_amd64) | +++ dpkg-gensymbols1MqufS 2015-06-07 23:13:54.633114251 +0200 | @@ -1,4 +1,5 @@ | libcap.so.2 libcap2 #MINVER# | + __cap_lookup_name@Base 1:2.24-9 | _cap_names@Base 1:2.10 | _libcap_strdup@Base 1:2.10 | cap_clear@Base 1:2.10 | dh_makeshlibs: failing due to earlier errors | debian/rules:50: recipe for target 'override_dh_makeshlibs' failed This doesn't happen with 1:2.24-8. Trying to build it a while ago led to no warnings, but (re)building it now introduces this new symbol. Probably due to some toolchain update (that I didn't investigate). I looked into this and I can reproduce the issue. In one of the Makefiles, there's a test for the presence of gperf(1), and if so, stuff happens, and the above symbol eventually gets added. Having -9 introduce the -c4 flag makes the warning become a fatal error, since the default behaviour (level 1 in dpkg-gensymbols, called by dh_makeshlibs) is warn only. It's somewhat fun to see how this function is constructed by the way. ;) Well put :-) More seriously, I'm not sure it should be exposed in the shared library, so you may want to unexpose it instead of just adding it to the symbols file. With regards to the cause listed above, I'd rather just disable this feature entirely, and (possibly, if it makes sense) add gperf as a B-D at a later point, and then deal with the symbol as you recommend. Either way resolves the current nondeterminism in the build, which is at the moment what bothers me the most, TBH. Would you like me to prepare a 1:2.24-10 with such a fix ASAP (which would be tomorrow)? Or is the above info enough for you to deal with this issue for the moment? Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787542: Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
On 2015-06-02 19:48, Michael Biebl wrote: Am 02.06.2015 um 18:11 schrieb Cyril Brulebois: libudev1-udeb depends on missing libcap2. I suspect the easiest would be to drop libcap2 support from the udeb build. An alternative would be to try and add a udeb in libcap2. I'd rather have the former happen, so Unfortunately, the libcap dependency is not really optional, i.e. it can not be turned off with a --disable-libcap configure switch. While we could try and hack the build system and ifdeffing this code out, I'd much prefer if we didn't have to do that and simply build a udeb for libcap Matthias already provided a patch for that [1]. @Christian, you mentioned that you were ok with this patch and wanted to include this in your next upload. Would be great if you can proceed with the upload now that v220 is in unstable which depends on it. Yeah, I dropped the ball a bit here... I'll take care of this over the weekend. Regards, Christian Cheers, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782475 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785484: systemd: on Raspberry pi B+, several essential services fail, including systemd-logind
control: tag -1 moreinfo Hi everyone, Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker: Hello, as I got the same problem on my raspberry, probably I can give some details. This is the situation I started: - put 2015-05-05-raspbian-wheezy.img on SD-card and booted - changed sources.list and did the upgrade - appended systemd.debug-shell to /boot/cmdline.txt - reboot On 2015-05-18 19:47, Michael Biebl wrote: Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker: For some reason it looks like /etc/init.d/cgroup-bin is still installed even cgroup-bin is a transitional package. That looks, like /etc/init.d/cgroup-bin is an obsolete conffile which is not automatically cleaned up on upgrades. TBH, having only somewhat recently taken over as maintainer of this package, I'm not very familiar with its earlier history. But TTBOMK, cgroup-bin never shipped an /etc/init.d/cgroup-bin file. See for example its contents in wheezy [1], or the TODO item [2] created by the previous maintainer. This needs to be done manually on upgrades. See https://wiki.debian.org/DpkgConffileHandling and especially the dh_installdeb/dpkg-maintscripts-helper man pages. One should also not forget to run update-rc.d cgroup-bin remove. Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker: By purging just cgroup-bin I got expected booting again. Is /etc/init.d/cgroup-bin still around? If yes, then it's probably just bailing out early because it cannot find the necessary executables, so no harm done. But then it must have been placed there manually. If no, then the purge must indeed have removed it, but as the Debian version does not ship this file, I assume this is a peculiarity of the Raspbian version of this package? cgroup-bin[455]: Kernel lacks cgroups or memory controller not available, not starting cgroups. ... (warning). systemd[1]: Failed to create cgroup /system.slice/ntp.service: No such file or directory systemd[481]: Failed at step CGROUP spawning /etc/init.d/ntp: No such file or directory Regards, Christian [1] https://packages.debian.org/wheezy/armel/cgroup-bin/filelist [2] https://sources.debian.net/src/libcgroup/0.41-6/debian/cgroup-tools.TODO/ signature.asc Description: OpenPGP digital signature
Bug#783683: cron started with -f (foreground), killing processes on restart
Control: tag -1 + confirmed pending On 2015-05-03 15:33, Christoph Berg wrote: Re: To Joerg Morbitzer 2015-05-03 20150503125807.ga3...@msg.df7cb.de I'd strongly opt to change the KillMode as mentioned above. #debian-devel seems to agree, so I'm upgrading this bug to RC. (critical as it's killing random processes) A particular reason why the current behavior is bad is that it is common practise to start user daemons using @reboot cronjobs. I was wondering what the use case for this was, but that seems plausible. Regardless, I committed a fix for the sole fact that it's a significant deviation from past behavior, as you pointed out. I've prepared packages for both jessie and unstable. Thanks, Alexandre and Christoph, for your analysis and solution! Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781050: libcap2-bin: removes confile it doesnt own
Hi again, sorry for the delay. On 2015-03-24 00:02, Holger Levsen wrote: I think it's also a question of ordering: if libpam-cap is updated first and and libcap2-bin is removed second, things go well. If libcap2-bin is removed first and libpam-cap second, you will encounter the problem. I intend to revert that specific change for jessie, and reopen #768229 (obsolete conffile). The unblock pre-approval request #781448 has all the details. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
Hi Andreas,
On 2015-03-14 01:56, Andreas Beckmann wrote:
On 2015-03-13 23:49, Christian Kastner wrote:
Would you by chance be available for sponsoring? (No problem if not, but
if yes, please wait for an updated debdiff as the RT approved another
one-line fix.)
I'm not sure that this is the correct approach for capability.conf -
it's not an obsolete conffile, it has moved to libpam-cap instead (which
it Recommends)
The rm_conffile is fine as long as libpam-cap is not installed, but I'm
not sure whether this runs smoothly if libpam-cap is upgraded at the
same time ...
It turns out you were right, again.
While the above indeed worked fine in all of my local tests (which, as
stated in #44, I did for all possible combinations), apparently there
are constellations possible where the rm_conffile leads to a removal
when it shouldn't.
Such a case was reported as #781050. I prepared a package which reverts
the rm_conffile, so the obsolete conffile will just be accepted for now.
The unblock bug #781448 has a longer rationale for this decision.
I even added some workarounds in piuparts for a related issue (a
conffile was disappearing sometimes, but never from the reference
chroot) - since I didn't really see a fault in your packages:
case ${PIUPARTS_OBJECTS%%=*} in
kismet|\
tshark|\
wireshark|\
wireshark-common|\
wireshark-dbg|\
libcap2-bin)
# libcap2-bin/wheezy is part of the minimal
chroot and recommends libpam-cap
# a conffile moved from libcap2-bin/squeeze to
libpam-cap/wheezy
log_debug
apt-get install -yf libpam-cap
;;
Please consideres this as a heads-up that once the above change enters
unstable with 1:2.24-8, you may or may not need to re-introduce the
work-around above.
Regards,
Christian
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781050: libcap2-bin: removes confile it doesnt own
Hi, On 2015-03-29 15:57, Christian Kastner wrote: On 2015-03-24 00:02, Holger Levsen wrote: I think it's also a question of ordering: if libpam-cap is updated first and and libcap2-bin is removed second, things go well. If libcap2-bin is removed first and libpam-cap second, you will encounter the problem. I intend to revert that specific change for jessie, and reopen #768229 (obsolete conffile). The unblock pre-approval request #781448 has all the details. I have uploaded a .dsc with the approved changes here: http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-8.dsc Would any of you be available for sponsoring an upload to unstable? Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781050: libcap2-bin: removes confile it doesnt own
Control: tag -1 + moreinfo Hi Holger, I'm having problems reproducing this. I just tried upgrading in pristine wheezy VMs (a) with libcap2-bin (b) with libcap2-bin + libpam-cap installed, and I didn't encounter this issue. On 2015-03-23 21:06, Holger Levsen wrote: to fix #768229 (conffile not removed), you added code to do that in the postinst script of libcap2-bin. Unfortunatly, this confile is owned by libpam- cap nowaways, and thus upgrades from wheezy to jessie now get a missing /etc/security/capability.conf file if _only_ libcap2-bin is installed, then /etc/security/capability.conf is superfluous, so this shouldn't be an issue. and thisquestion during upgrades: Setting up libpam-cap:amd64 (1:2.24-7) ... OK, but in this case, we don't have libcap2-bin, but libcap2-bin + libpam-cap instead. Configuration file `/etc/security/capability.conf' == Deleted (by you or by a script) since installation. == Package distributor has shipped an updated version. This is the part that puzzles me. capability.conf only gets rm_conffile'd in the most recent version, but in none of my tests does this trigger the above. I'll need to investigate some more... Regards, Christian What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** capability.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing libpam- cap:amd64 (--configure): -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
Control: tag -1 + confirmed pending On 2015-03-13 16:33, Andreas Beckmann wrote: during a test with piuparts I noticed your package fails to upgrade from 'lenny' to 'squeeze' to 'wheezy' to 'jessie'. Its predecessor 'libcap-bin' installed fine in 'lenny', and was kept installed during the upgrades to 'squeeze' and 'wheezy', but the upgrade to 'jessie' eventually pulled in libcap2-bin (which was not installed previously) which failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. It looks as if the transition from libcap-bin to libcap2-bin was not handled properly. libcap-bin disappeared after lenny, so whatever was still depending on that should have been switched to libcap2-bin in squeeze. It's odd that this issue hasn't been reported before. I assume your test used a somewhat minimal system where libcap2-bin only gets pulled in via systemd, but gnome-keyring already pulled libcap2-bin in for wheezy, so you'd think at least one user would have hit this earlier... Anyhoo, adding Breaks+Replaces seems to be the simplest solution, so I'll prepare a fix with that. Thanks, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
On 2015-03-14 01:56, Andreas Beckmann wrote: On 2015-03-13 23:49, Christian Kastner wrote: Would you by chance be available for sponsoring? (No problem if not, but if yes, please wait for an updated debdiff as the RT approved another one-line fix.) I'm not sure that this is the correct approach for capability.conf - it's not an obsolete conffile, it has moved to libpam-cap instead (which it Recommends) Yeah, that was my first thought, too. But not removing it in libcap2-bin would still leave it around if libpam-cap were not to be installed (which is apparently not that uncommon), and that can't be right either. Then, see below. The rm_conffile is fine as long as libpam-cap is not installed, but I'm not sure whether this runs smoothly if libpam-cap is upgraded at the same time ... Oh, I forgot to mention this. I too was concerned about this so I tested this with a jessie VM, and it worked fine. (Note 1: 2.19-3 is the version from squeeze, before the split) (Note 2: capability.conf was updated in the package between versions) 1. locally unchanged capability.conf: a. libcap2-bin/2.19-3 - libcap2-bin/2.24-7, no libpam-cap = removed b. likewise, but installing libpam-cap = newer version 2. locally changed capability.conf: a. libcap2-bin/2.19-3 - libcap2-bin/2.24-7, no libpam-cap = .dpkg-bak b. likewise, but installing libpam-cap = triggers dpkg question 2.b. is the only place were information could be lost, but that didn't happen. That said, the versioning in the maintscript is wrong as well. This needs to be the version where the rm_conffile call was added (plus suffix '~' Yep, sorry about that. I uploaded a new version to mentors. It is the same as the previous one save for the fixed version number in libcap2-bin.maintscript. What do you think? Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
On 2015-03-13 23:22, Andreas Beckmann wrote: libcap2-bin had Conflicts: libcap-bin upto wheezy, this (and a corresponding Replaces) should return for jessie, it can go away afterwards, since the default (straight forward) upgrade paths should be covered. Oh, I didn't notice that earlier Conflicts. So the transition was somewhat considered, and just removed prematurely. In #780432 [1] a fix using Breaks+Replaces was already approved. To maybe avoid another iteration, would you be satisfied with this? Would you by chance be available for sponsoring? (No problem if not, but if yes, please wait for an updated debdiff as the RT approved another one-line fix.) Regards, Christian [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780432 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780411: libcap2-bin: missing Breaks+Replaces: libcap-bin
On 2015-03-13 23:38, Andreas Beckmann wrote:
Would you by chance be available for sponsoring? (No problem if not, but
if yes, please wait for an updated debdiff as the RT approved another
one-line fix.)
No problem, I can sponsor. Throw it onto mentors.d.net once ready and
send me the link.
Here it is (debdiff attached for convenience):
https://mentors.debian.net/package/libcap2
(Please ignore the watch file error, I will fix it after jessie is
released).
Thanks,
Christian
diff -Nru libcap2-2.24/debian/changelog libcap2-2.24/debian/changelog
--- libcap2-2.24/debian/changelog 2014-09-25 01:43:17.0 +0200
+++ libcap2-2.24/debian/changelog 2015-03-13 22:51:45.0 +0100
@@ -1,3 +1,13 @@
+libcap2 (1:2.24-7) unstable; urgency=medium
+
+ * debian/libcap2-bin.maintscript:
+- Remove obsolete conffile capability.conf. Closes: #768229
+ * debian/control:
+- Add Breaks+Replaces for libcap-bin. libcap-bin was removed after lenny,
+ but the transition to libcap2-bin was not fully handled. Closes: #780411
+
+ -- Christian Kastner deb...@kvr.at Fri, 13 Mar 2015 21:28:23 +0100
+
libcap2 (1:2.24-6) unstable; urgency=medium
* debian/rules:
diff -Nru libcap2-2.24/debian/control libcap2-2.24/debian/control
--- libcap2-2.24/debian/control 2014-09-25 01:43:17.0 +0200
+++ libcap2-2.24/debian/control 2015-03-13 22:51:45.0 +0100
@@ -20,6 +20,8 @@
Depends:
${shlibs:Depends},
${misc:Depends},
+Breaks: libcap-bin
+Replaces: libcap-bin
Recommends: libpam-cap
Description: POSIX 1003.1e capabilities (utilities)
Libcap implements the user-space interfaces to the POSIX 1003.1e capabilities
diff -Nru libcap2-2.24/debian/libcap2-bin.maintscript
libcap2-2.24/debian/libcap2-bin.maintscript
--- libcap2-2.24/debian/libcap2-bin.maintscript 1970-01-01 01:00:00.0
+0100
+++ libcap2-2.24/debian/libcap2-bin.maintscript 2015-03-13 22:51:45.0
+0100
@@ -0,0 +1 @@
+rm_conffile /etc/security/capability.conf 1:2.22-1.1 libcap2-bin
Bug#762465: sudo: Include future-timestamp patch for jessie
On 2015-03-01 20:50, Bdale Garbee wrote: Christian Kastner deb...@kvr.at writes: All of the RC fixes have been in unstable for a while now, so an upload to t-p-u could be negotiated now with the RT. If you'd like me to take care of that, please let me know. Go for it. I'm likely to remain too busy to work on it much for the next week or so. Submitted as #779523. I'll report back as soon as I receive any news. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762465: sudo: Include future-timestamp patch for jessie
Hi, On Mon, 20 Oct 2014 21:29:56 + Bdale Garbee bd...@gag.com wrote: sudo (1.8.11p1-2) unstable; urgency=low . * patch from Jakub Wilk to fix 'ignoring time stamp from the future' messages, closes: #762465 The above bug has been bumped to serious, making it RC. In case this is justified, I created an updated debdiff including the above fix with the other pending RC fixes. See attached. All of the RC fixes have been in unstable for a while now, so an upload to t-p-u could be negotiated now with the RT. If you'd like me to take care of that, please let me know. Regards, Christian sudo_1.8.10p3-1+deb8u2.dsc Description: Binary data
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-02-22 07:43, Michael Gilbert wrote: On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote: It's not backed up in jessie or later. The backup/md5sum stuff is preceeded by a test for and old version less than 1.7.4p4-4, so in wheezy and later, all the md5sum stuff is ignored during upgrades. It is most certainly backed up in jessie or later. That happens during install rather than upgrade, which you describe below anyway. That's why I said during upgrades here. However, the backup code is accidentally triggered when switching between sudo and sudo-ldap, because switching is not upgrading (in the dpkg sense), and the version test above does not account for this scenario: preinst $ dpkg --compare-versions le 1.7.4p4-4 echo oops oops The solution I propose to modify /etc/sudoers so that it has a different checksum, which prevents the incorrect backup. Please see attached This has one nasty side effect: when upgrading from wheezy to jessie, anyone with a changed /etc/sudoers will be asked a conffile question, because both the local and the maintainer's version changed. That is true for conffiles in general, but will not be the case for sudo because its *.preinst moves /etc/sudoers for lenny/squeeze/wheezy out of the way to /etc/sudoers.pre-conffile. Nope. The move on install happens only if the md5sum matches one of the package maintainer's versions, so when user did _not_ change /etc/sudoers. If the user changed /etc/sudoers, the the md5sum no longer matches, ergo no move. Then local and maintainer version divert from the previous maintainer version, and a conffile question has to be asked. I just verified this by upgrading from a deb8u1 jessie version, with a changed /etc/sudoers, to your proposed version. I was asked what to do. Modifying sudoers so that it has a checksum can't be right, because the code where the checksum is relevant shouldn't have been reached in the first place (in wheezy or later). It is possible that the user removed the package, then installed it later. In wheezy and later, where /etc/sudoers already is a conffile, that is entirely for dpkg to handle, not for the *.preinst scripts. Anything in the *.preinst is exclusively for when upgrading from squeeze. The = 1.7.4p4-4 check is meant to ensure that, but it's buggy as it does not handle the install case properly. This needs to be fixed regardless. My argument is that this is also what's causing the bug we are discussing right now. Fixing the --compare-versions above does precisely that -- the md5sum stuff is never even reached. With that approach the check is now not reached in cases where it should. Could you elaborate which cases these are? Perhaps my patch is just incomplete. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-02-22 17:50, Michael Gilbert wrote: On Sun, Feb 22, 2015 at 6:35 AM, Christian Kastner wrote: In wheezy and later, where /etc/sudoers already is a conffile, that is entirely for dpkg to handle, not for the *.preinst scripts. Anything in the *.preinst is exclusively for when upgrading from squeeze. So, the more I think about it, isn't this the real problem? The *.preinst scripts mess with wheezy's /etc/sudoers even though it should only be managed by dpkg. Precisely[*]. In fact, if we assume that the squeeze-jessie upgrade path (skipping wheezy) is not supported, the *.preinst scripts become completely unnecessary and could be dropped entirely, because the wheezy-jessie upgrade case is handled just like any other conffile. However, the simple one-line-fix I proposed should have the very same effect whilst being less intrusive and more accomodating: * On install the code *.preinst code is skipped unconditionally (because old-version isn't set), and * On upgrade it's skipped in wheezy and later (because the old-version is newer than 1.7.4p4-4). The install case also covers the switch-between-sudo,sudo-ldap case, which triggered this bug. Regards, Christian [*] not to take someone else's credit: it was Andreas who correctly identified the actual problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-02-22 02:05, Michael Gilbert wrote: On Fri, Feb 6, 2015 at 7:02 PM, Christian Kastner wrote: I've looked into this now, and I believe that the --compare-versions issue and the chown/chmod issue is all there is to this bug. I have attached a new debdiff (v2) with fixes for both. I reviewed your proposed changes, but I don't think it's the right approach. The origin of the problem is that the md5sum of /etc/sudoers is the same for wheezy and later, so the logic intended to back it up only for wheezy ends up incorrectly backing it up in jessie and later too. It's not backed up in jessie or later. The backup/md5sum stuff is preceeded by a test for and old version less than 1.7.4p4-4, so in wheezy and later, all the md5sum stuff is ignored during upgrades. However, the backup code is accidentally triggered when switching between sudo and sudo-ldap, because switching is not upgrading (in the dpkg sense), and the version test above does not account for this scenario: preinst $ dpkg --compare-versions le 1.7.4p4-4 echo oops oops The solution I propose to modify /etc/sudoers so that it has a different checksum, which prevents the incorrect backup. Please see attached. This has one nasty side effect: when upgrading from wheezy to jessie, anyone with a changed /etc/sudoers will be asked a conffile question, because both the local and the maintainer's version changed. Modifying sudoers so that it has a checksum can't be right, because the code where the checksum is relevant shouldn't have been reached in the first place (in wheezy or later). Fixing the --compare-versions above does precisely that -- the md5sum stuff is never even reached. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-02-07 01:02, Christian Kastner wrote: I have tested this patch in a number of combinations, including (but not limited to): sudo (squeeze) - sudo (jessie) upgrade sudo-ldap (squeeze) - sudo-ldap (jessie) upgrade Works as intended. An unchanged /etc/sudoers gets replaced with the new version, a changed sudoers will cause the user to be asked what to do. sudo (jessie)- sudo (jessie+deb8u2) upgrade sudo-ldap (jessie)- sudo-ldap (jessie+deb8u2) upgrade Same result as in the previous case. sudo (jessie+deb8u2) - sudo-ldap (jessie+deb8u2) switch sudo-ldap (jessie+deb8u2) - sudo (jessie+deb8u2) switch In case it helps, here are the simple steps I used to create test environments for the above tests: $sudo vmdebootstrap \ --owner `whoami` \ --arch amd64 \ --mirror http://fast.mirror/debian \ --distribution squeeze \ --image squeeze.img \ --size 1g \ --serial-console Repeat for jessie. The wheezy case is identical to jessie but has to be addressed separately from this RC blocking bug. qemu-system-x86_64 \ -enable-kvm \ -m 256 \ -monitor none \ -nographic \ -serial stdio \ -snapshot \ squeeze.img Source package and binary packages for amd64 can be found here: http://www.kvr.at/debian/pool/main/s/sudo/ (Note that I changed the Distribution from t-p-u to unstable because I didn't want to muck with my reprepro setup just for this.) Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
Hi, On 2015-02-07 01:02, Christian Kastner wrote: I've looked into this now, and I believe that the --compare-versions issue and the chown/chmod issue is all there is to this bug. I have attached a new debdiff (v2) with fixes for both. I have tested this patch in a number of combinations, including (but not limited to): sudo (squeeze) - sudo (jessie) upgrade sudo-ldap (squeeze) - sudo-ldap (jessie) upgrade Works as intended. An unchanged /etc/sudoers gets replaced with the new version, a changed sudoers will cause the user to be asked what to do. sudo (jessie)- sudo (jessie+deb8u2) upgrade sudo-ldap (jessie)- sudo-ldap (jessie+deb8u2) upgrade Same result as in the previous case. sudo (jessie+deb8u2) - sudo-ldap (jessie+deb8u2) switch sudo-ldap (jessie+deb8u2) - sudo (jessie+deb8u2) switch /etc/sudoers always gets carried over. There is no scenario where the user might have to be asked, as the package versions (and the sudoers they supply) are identical, and the user's changed version therefore trumps the default version. did anyone get the chance to confirm my results yet? Bdale, once such a confirmation (or another fix) is in, how would you like to proceed? I could help with the RT communication again Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-02-18 22:32, Bdale Garbee wrote: Christian Kastner deb...@kvr.at writes: Bdale, once such a confirmation (or another fix) is in, how would you like to proceed? I could help with the RT communication again Sure. I'm willing to merge a patch and do uploads, but need to know which path they want me to use since the sudo in unstable has diverged From the one in jessie, I'm assuming it will be t-p-u again, as 1.8.10p3-1+deb8u2. The debdiff I attached is already prepared accordingly. and there's another new upstream release I plan to upload to unstable soon'ish. Oh, I forgot: as this also affects unstable, once a second confirmation comes in that the proposed fix is good, it should be applied there, too. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
Control: tags -1 + patch Hi again, On 2015-01-30 10:27, Christian Kastner wrote: On 2015-01-30 00:19, Andreas Beckmann wrote: Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo and once it gets around to installing ist conffile it notices that this has not changed from the known md5sum, so no attempt is made to upgrade the missing conffile. OK, you're right. It's not a matter of moving /etc/sudoers.pre-conffile back; the issue is that (at least on wheezy and above) it should not have been moved aside in the first place. The error appears to be (as you say) in sudo.preinst and sudo-ldap.preinst, specifically that the --compare-versions check does not account for the case when old-version is empty, which will always be the case when switching between sudo and sudo-ldap. I've looked into this now, and I believe that the --compare-versions issue and the chown/chmod issue is all there is to this bug. I have attached a new debdiff (v2) with fixes for both. I have tested this patch in a number of combinations, including (but not limited to): sudo (squeeze) - sudo (jessie) upgrade sudo-ldap (squeeze) - sudo-ldap (jessie) upgrade Works as intended. An unchanged /etc/sudoers gets replaced with the new version, a changed sudoers will cause the user to be asked what to do. sudo (jessie)- sudo (jessie+deb8u2) upgrade sudo-ldap (jessie)- sudo-ldap (jessie+deb8u2) upgrade Same result as in the previous case. sudo (jessie+deb8u2) - sudo-ldap (jessie+deb8u2) switch sudo-ldap (jessie+deb8u2) - sudo (jessie+deb8u2) switch /etc/sudoers always gets carried over. There is no scenario where the user might have to be asked, as the package versions (and the sudoers they supply) are identical, and the user's changed version therefore trumps the default version. Andreas, what do you think? Regards, Christian diff -Nru sudo-1.8.10p3/debian/changelog sudo-1.8.10p3/debian/changelog --- sudo-1.8.10p3/debian/changelog 2015-01-19 06:56:53.0 +0100 +++ sudo-1.8.10p3/debian/changelog 2015-02-07 00:25:55.0 +0100 @@ -1,3 +1,15 @@ +sudo (1.8.10p3-1+deb8u2) testing-proposed-updates; urgency=medium + + * Non-maintainer upload. + * In the preinst scripts, in the code concerning the pre-conffile-era +/etc/sudoers handling, make sure that dpkg --compare-versions actually has +two versions to compare. This is not the case when switching between sudo +and sudo-ldap (of the same version), so that code was accidentally being +triggered. Closes: #776137 + * Make sure that /etc/sudoers exists before attempting to chown/chmod it + + -- Christian Kastner deb...@kvr.at Sat, 07 Feb 2015 00:18:21 +0100 + sudo (1.8.10p3-1+deb8u1) testing-proposed-updates; urgency=medium * Non-maintainer upload. diff -Nru sudo-1.8.10p3/debian/sudo-ldap.postinst sudo-1.8.10p3/debian/sudo-ldap.postinst --- sudo-1.8.10p3/debian/sudo-ldap.postinst 2014-09-14 18:26:06.0 +0200 +++ sudo-1.8.10p3/debian/sudo-ldap.postinst 2015-02-07 00:27:42.0 +0100 @@ -28,8 +28,10 @@ fi # make sure sudoers has the correct permissions and owner/group -chown root:root /etc/sudoers -chmod 440 /etc/sudoers +if [ -f /etc/sudoers ];then +chown root:root /etc/sudoers +chmod 440 /etc/sudoers +fi # create symlink to ease transition to new path for ldap config # if old config file exists and new one doesn't diff -Nru sudo-1.8.10p3/debian/sudo-ldap.preinst sudo-1.8.10p3/debian/sudo-ldap.preinst --- sudo-1.8.10p3/debian/sudo-ldap.preinst 2014-09-14 18:26:06.0 +0200 +++ sudo-1.8.10p3/debian/sudo-ldap.preinst 2015-02-07 00:26:45.0 +0100 @@ -2,7 +2,7 @@ case $1 in install|upgrade) -if dpkg --compare-versions $2 le 1.7.4p4-4; then +if [ -n $2 ] dpkg --compare-versions $2 le 1.7.4p4-4; then SUDOERS=/etc/sudoers diff -Nru sudo-1.8.10p3/debian/sudo.postinst sudo-1.8.10p3/debian/sudo.postinst --- sudo-1.8.10p3/debian/sudo.postinst 2014-09-14 18:26:06.0 +0200 +++ sudo-1.8.10p3/debian/sudo.postinst 2015-02-07 00:27:18.0 +0100 @@ -22,8 +22,10 @@ fi # make sure sudoers has the correct permissions and owner/group -chown root:root /etc/sudoers -chmod 440 /etc/sudoers +if [ -f /etc/sudoers ];then +chown root:root /etc/sudoers +chmod 440 /etc/sudoers +fi # if we've gotten this far .. remove the saved, unchanged old sudoers file rm -f /etc/sudoers.pre-conffile diff -Nru sudo-1.8.10p3/debian/sudo.preinst sudo-1.8.10p3/debian/sudo.preinst --- sudo-1.8.10p3/debian/sudo.preinst 2014-09-14 18:26:06.0 +0200 +++ sudo-1.8.10p3/debian/sudo.preinst 2015-02-07 00:26:57.0 +0100 @@ -2,7 +2,7 @@ case $1 in install|upgrade) -if dpkg --compare-versions $2 le 1.7.4p4-4; then +if [ -n $2 ] dpkg --compare-versions $2 le
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
Control: tags -1 - patch On 2015-01-30 00:19, Andreas Beckmann wrote: On 2015-01-29 23:16, Christian Kastner wrote: Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo and once it gets around to installing ist conffile it notices that this has not changed from the known md5sum, so no attempt is made to upgrade the missing conffile. OK, you're right. It's not a matter of moving /etc/sudoers.pre-conffile back; the issue is that (at least on wheezy and above) it should not have been moved aside in the first place. The error appears to be (as you say) in sudo.preinst and sudo-ldap.preinst, specifically that the --compare-versions check does not account for the case when old-version is empty, which will always be the case when switching between sudo and sudo-ldap. Consequently, /etc/sudoers always gets moved during a switch. I'll try a new fix that works both the pre-conffile and conffile case next week (unless someone else beats me to it). Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
Hi Andreas, I'm not quite sure we're on the same page yet, but I'm also not 100% confident that I'm in the right. So here are some additional thoughts: On 2015-01-29 09:31, Andreas Beckmann wrote: And while switching sudo-sudo-ldap the following happens: sudo gets removed, conffile remains sudo-ldap.preinst gets called with no previous version, so the conffile handling is activated - the md5sum matches that one from wheezy and therefore /etc/sudoers is moved aside It's moved aside if, and only if, /etc/sudoers is the pristine package version. So if it's moved to /etc/sudoers.pre-conffile, we know that 1. The conffile has not been modified by the user 2. The conffile has not been deleted by the user Furthermore, the only reason it is being moved is to avoid a modified conffile dialogue when the file was, in fact, not modified. sudo-ldap replaces sudo and takes over a deleted conffile I don't think so... see above: if it had been deleted (in the sense that the user rm -f'ed it), /etc/sudoers.pre-conffile would not exist (md5sum mismatch of /etc/sudoers). this is not reinstated - per policy sudo-ldap.postinst explodes on the deleted conffile. There's two cases here: Case 1: If it had been deleted (by the user), then postinst would indeed fail at the chown. Part A. of my patch addresses this issue. Case 2: if /etc/sudoers but /etc/sudoers.pre-conffile exists, then we know that we have an untouched conffile that was only temporarily moved just to avoid a modified conffile dialogue. So it must be moved back. Part B. of my patch does this. could you try how switching between sudo and sudo-ldap works if the wheezy md5sum is removed from teh preinst? With my patch applied, I tried various combinations of: 1. not touching /etc/sudoers 2. modifying /etc/sudoers 3. deleting /etc/sudoers whilst switching back-and-forth between sudo and sudo-ldap, and all did the right thing. 1. /etc/sudoers is the package maintainer's version 2. /etc/sudoers is the user-modified version 3. /etc/sudoers does not exist (and a warning is issued) Thoughts? Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
I just noticed that I completely overlooked your other comments to my original mail. Sorry about that! On 2015-01-29 09:31, Andreas Beckmann wrote: On 2015-01-28 23:56, Christian Kastner wrote: This is the first problem. It is of course possible for this file to be generally absent (it's a conffile, and the user might have forcefully removed it), so this chown should be guarded by a test for existence. Is sudo useful at all if /etc/sudoers is missing? No, but if it's missing, then the user must have removed it, and policy compels us to honor that decision. 3. Later on, there is an attempted to remove the temporarily renamed /etc/sudoers.pre-conffile mentioned above: # if we've gotten this far .. remove the saved, unchanged old sudoers file rm -f /etc/sudoers.pre-conffile that is an *old* pristine sudoer that was not a conffile Yes, this is tricky. It's not a conffile from the *old* sudo's POV. It is very much a conffile from the *new* sudo's POV, and therefore the user-preservation semantics apply (I'd say). This I don't understand. Why remove it? This file can only exist because of step 1. above, and if it exists, the purpose was to just temporarily move it out of the way to avoid a conffile-change question. Why is it being removed now? Shouldn't it just be moved back in step 2.? dpkg should have installed a new sudoers (that is now a conffile) Well, if the old sudoers md5sum matches what is in postinst, then either (a) installing the new one or (b) temporarily-renaming-and-switching the old one have the same effect, except that (a) has the unwanted modified conffile dialogue. And if the old sudoers md5sum does not match what is in postinst, sudoers has user modifications. Albeit from a time before sudoers was a conffile; but if I upgraded from squeeze to wheezy, I would absolutely expect my sudoers to be preserved regardless of that. the .pre-conffile is a backup that should be restored in failed-upgrade or removed in postinst, so the intention is right, just the preinst should not have touch a conffile Please find attached a debdiff against the version in t-p-u that A. Makes the chmod/chown conditional on the existence of /etc/sudoers maybe its better to explode here if sudoers does not exist - I assume sudo will be nonfunctional without it See above (user must have deleted it, we must comply with that) B. When /etc/sudoers.pre-conffile exists, moves it back to /etc/sudoers. This is done unconditionally since the very existence of /etc/sudoers.pre-conffile implies that it is the pristine package version (recall the md5sum check above). So the user did not delete or change /etc/sudoers, and we want it back. there was never the intention to restore this in a pre-conffile to conffile upgrade case ... I think this can be reduced to the (a) or (b) case I listed above. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
On 2015-01-29 21:25, Andreas Beckmann wrote: just to make notation clear /etc/sudoers is a *configuration file*, i.e. rules of preserving user changes apply since wheezy it is also a *conffile* i.e. shipped with the package at /etc/sudoers and managed by dpkg, not to be touched by maintainer scripts before it was managed by maintainer scripts True. But as you observed in your initial report, the same bug can be triggered in a clean jessie environment, where the configuration file / conffile distinction is not a factor. As you reported: on a fresh jessie host, install sudo, and switch to sudo-ldap (or vice versa). The bug will present itself. the tricky part is to get a smooth upgrade patch from the pre-conffile stage to a conffile * with preserving user chnages * without asking useles questions I think the real bug is still that pre-conffile handling is applied to a conffile by listing the wheezy md5sum The way I see the problem, a solution for the pure-jessie case will also be a solution for the wheezy case. if dpkg installs a conffile for the first time there are three possibilities: * the file does not exist - trivial: install and record it * the file exists and is the same as being installed - record it * the file exists but is different: ask And the patch I proposed works with all these cases. But that is all beside the point, because the conffile is not being installed for the first time. The problem manifests itself during a switch, so we have a pre-existing conffile. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory
Control: tags -1 + patch On Sat, 24 Jan 2015 12:05:52 +0100 Andreas Beckmann a...@debian.org wrote: The upgrade to jessie with sudo-ldap/jessie went smooth, and thereafter I wanted to switch to sudo/jessie, which failed due to missing /etc/sudoers, the problem is reproducible in plain jessie, too: # apt-get install sudo snip WARNING: /etc/sudoers not present! chown: cannot access '/etc/sudoers': No such file or directory dpkg: error processing package sudo (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: sudo E: Sub-process /usr/bin/dpkg returned an error code (1) The problem stems from the solution used to avoid an unnecessary action prompt for a conffile change when in fact there was no change. See bugs #636049, #612532, #660594. 1. Each respective preinst checks, via md5sum, if /etc/sudoers has changed. Iff not, it is moved to a temporary location at /etc/sudoers.pre-conffile. 2. Each respective postinst checks whether /etc/sudoers is present, and warns if it isn't (see WARNING quoted above). 3. Then follows an unconditional chown of /etc/sudoers, and when this fails, postinst aborts because of set -e. This is the first problem. It is of course possible for this file to be generally absent (it's a conffile, and the user might have forcefully removed it), so this chown should be guarded by a test for existence. 3. Later on, there is an attempted to remove the temporarily renamed /etc/sudoers.pre-conffile mentioned above: # if we've gotten this far .. remove the saved, unchanged old sudoers file rm -f /etc/sudoers.pre-conffile This I don't understand. Why remove it? This file can only exist because of step 1. above, and if it exists, the purpose was to just temporarily move it out of the way to avoid a conffile-change question. Why is it being removed now? Shouldn't it just be moved back in step 2.? Please find attached a debdiff against the version in t-p-u that A. Makes the chmod/chown conditional on the existence of /etc/sudoers B. When /etc/sudoers.pre-conffile exists, moves it back to /etc/sudoers. This is done unconditionally since the very existence of /etc/sudoers.pre-conffile implies that it is the pristine package version (recall the md5sum check above). So the user did not delete or change /etc/sudoers, and we want it back. I'm confident that change A. is correct and necessary, but change B. depends on whether I understood the problem the code is trying to solve correctly! I tested this with various combinations (pristine, changed, deleted /etc/sudoers), and TTBOMYK the result is policy-conform. Additional testing would be highly appreciated, though. Regards, Christian diff -Nru sudo-1.8.10p3/debian/changelog sudo-1.8.10p3/debian/changelog --- sudo-1.8.10p3/debian/changelog 2015-01-19 06:56:53.0 +0100 +++ sudo-1.8.10p3/debian/changelog 2015-01-28 23:46:41.0 +0100 @@ -1,3 +1,13 @@ +sudo (1.8.10p3-1+deb8u2) testing-proposed-updates; urgency=medium + + * Non-maintainer upload. + * Make sure that /etc/sudoers exists before attempting to chown/chmod it. + * When switching between sudo and sudo-ldap, move an unchanged, temporarily +renamed /etc/sudoers back to its original location to complete the switch. +Closes: #776137 + + -- Christian Kastner deb...@kvr.at Wed, 28 Jan 2015 23:39:59 +0100 + sudo (1.8.10p3-1+deb8u1) testing-proposed-updates; urgency=medium * Non-maintainer upload. diff -Nru sudo-1.8.10p3/debian/sudo-ldap.postinst sudo-1.8.10p3/debian/sudo-ldap.postinst --- sudo-1.8.10p3/debian/sudo-ldap.postinst 2014-09-14 18:26:06.0 +0200 +++ sudo-1.8.10p3/debian/sudo-ldap.postinst 2015-01-28 23:39:55.0 +0100 @@ -8,6 +8,11 @@ rm /etc/alternatives/sudo fi +# if the saved, unchanged old sudoers file exists, move it back +if [ -f /etc/sudoers.pre-conffile ];then +mv /etc/sudoers.pre-conffile /etc/sudoers +fi + # complain if no sudoers file is present if [ ! -f /etc/sudoers ];then echo WARNING: /etc/sudoers not present!; @@ -28,8 +33,10 @@ fi # make sure sudoers has the correct permissions and owner/group -chown root:root /etc/sudoers -chmod 440 /etc/sudoers +if [ -f /etc/sudoers ];then +chown root:root /etc/sudoers +chmod 440 /etc/sudoers +fi # create symlink to ease transition to new path for ldap config # if old config file exists and new one doesn't @@ -37,9 +44,6 @@ ln -s ldap/ldap.conf /etc/sudo-ldap.conf fi -# if we've gotten this far .. remove the saved, unchanged old sudoers file -rm -f /etc/sudoers.pre-conffile - # make sure we have a sudo group [ -n `getent group sudo` ] exit 0 # we're finished if there is a group sudo: diff -Nru sudo-1.8.10p3/debian/sudo.postinst sudo-1.8.10p3/debian/sudo.postinst --- sudo-1.8.10p3/debian/sudo.postinst 2014-09-14 18:26:06.0 +0200 +++ sudo
Bug#739676: systemd-user PAM config breaks some libpam-* modules
Hi Martin, On 2015-01-21 11:35, Martin Pitt wrote: On both my Debian sid and my Ubuntu system, the only difference between common-session and common-session-noninteractive is that the latter does not include libpam-systemd. Generally speaking, I believe (but haven't verified) that this will be the case for all packages where the Debian PAM meta-config sets the following flag: Session-Interactive-Only: yes I found that in src:systemd/debian/pam-configs/systemd. At least, that would explain the difference you observed. Thus on a system which does *not* use any additional pam module, this should effectively be a no-op change and thus quite safe. Yep! For the systemd-user PAM config, the move to -noninteractive only does one thing, namely to drop the implied pam_systemd. By re-adding it explicitly to the config (patch v2), the result on such systems must be a no-op. Indeed installing libpam-mount only adds itself to common-session, not to common-session-noninteractive. So with this change we would get the desired effect. Yep. Rephrased, this means that on systems that *do* use additional PAM modules, this change would drop ops, but those ops shouldn't have been there in the first place. systemd-user should not call pam_mount, pam_script, etc. This does not affect the user; the frontend PAM sessions started by login, lightdm, and so on all @include common-session. This is only about systemd-user session triggered in the background. So it really should be safe. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739676: systemd-user PAM config breaks some libpam-* modules
On 2015-01-20 19:28, Felipe Sateler wrote: For reference, the inclusion of common-session is a local debian patch[1]. The original file referenced system-auth, which apparently debian does not use. [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/patches/Adjust-systemd-user-pam-config-file-for-Debian.patch?id=ec748d6eba35516597182ee24d7095a9c9cf415e From a quick look, system-auth is just Red Hat's name for the same mechanism. Both files serve the same purpose -- group common stuff in a single file which can be @included by others. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775588: [Pkg-haskell-maintainers] Bug#775588: darcs: Missing copyright information
On 2015-01-18 13:52, Joachim Breitner wrote:
Am Samstag, den 17.01.2015, 19:39 +0100 schrieb Christian Kastner:
The copyright information and the license terms for the files
src/Crypt/*
is missing from debian/copyright.
I wonder: Since it is a mix of GPL and BSD, we are effectively
distributing it under the GPL. Shouldn’t be be sufficient to stat that
in a single
Files: *
section?
Perhaps I misunderstood something, but to be clear: some files are
distributed under the GPL, and some under a BSD license. The combination
thereof doesn't change this, there is no dual-licensing or
license-mixing here. To emphasize this, I would
* add a new Files: section for the BSD sha2.{c,h} files, and
* either create a new Files: section for SHA256.hs, or
* merge it with the Files: *, if the referred GPL version is
determined to be the same.
As mentioned, haskel-hashed-storage already does something similar:
http://sources.debian.net/src/haskell-hashed-storage/0.5.10-4/debian/copyright/#L32
The only thing that's not clear to be is which specific version of the
GPL is being referred to in SHA256.hs, so one would probably have to ask
the author.
Regards,
Christian
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775588: [Pkg-haskell-maintainers] Bug#775588: darcs: Missing copyright information
On 2015-01-18 15:09, Joachim Breitner wrote:
Well, that’s how the files are distributed to Debian. But that doesn’t
mean that Debian cannot re-license them all under the GPL... At least I
thought that BSD code can generally be relicensed under the GPL.
Oh, now I understand what you mean.
What you're thinking of it compatibility, and yes, the BSD licenses are
considered compatible to the GPL, so GPL code can link to BSD code (and
be distributed together, etc.).
But only the current copyright holders have the power to relicense the
work, so the sha2.{c,h} files remain BSD no matter where they are included.
Regards,
Christian
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
