Bug#1092987: help finding hosting
https://github.com/hashicorp/vagrant/issues/13571#issuecomment-2597468213 > We are currently running with the workaround of setting VAGRANT_SERVER_URL to "https://vagrantcloud.com/api/v2/vagrant";. FWIW, updated vagrant packages for Fedora will be available soon with internal code changes to reflect the change in url avoiding the need for workaround.
Bug#1092987: help finding hosting
F-Droid still relies on the Debian Vagrant boxes. We are working on migrating away from them, but I'd rather not rush it. Seems like we could find some alternate official hosting for them as a quick workaround. Both Debian and F-Droid are plugged into a substantial network of mirrors. Perhaps it makes sense to plug into that? Like I think we could easily get hosting from OSUOSL.
Bug#1089621: xen: Invalid copyright years "2022-present"
On 12/20/24 03:49, Sean Whitton wrote: > Hello, > > On Thu 19 Dec 2024 at 10:47pm +01, Hans van Kranenburg wrote: > >> I learned a few things from doing that, but it was also pretty mind >> numbing. Apparently, in the end, the text "Copyright: 2002-present Keir >> Fraser and/or many others" is something I came up with myself, as some >> sort of ultimate summary of all the things I had encountered. And, >> probably because I thought the field was mandatory to have... :O > > Thanks for looking. > > As I said, just replacing it with 'Copyright: 2002-2024' and updating it > once a year would solve this bug. Clear. Then I'll indeed do at least that for now. Thanks, Hans
Bug#1089621: xen: Invalid copyright years "2022-present"
Hi, On 12/10/24 03:51, Sean Whitton wrote: > Source: xen > Version: 4.17.3+36-g54dacb5c02-1 > Severity: serious > Justification: Policy 2.3, 4.5, 12.5 > X-Debbugs-CC: ftpmas...@debian.org > > Dear maintainer, > > Copyright 2022-present Keir Fraser and/or many others" > > is not a valid copyright claim. Copyright is always time-limited, so it > simply does not make sense to say "-present". > > Also, our copyright format is already implicitly "and/or" for names > under a given stanza, so it should be just "and", I think. > > If you're reproducing this from the upstream sources because that's > what they typed and the GPL requires you to reproduce copyright claims, > then please take this up with them. > > If this is something that someone came up with for Debian purposes, > please use > > Copyright: 2002-2024 Keir Fraser and many others Yes, this needs some more improvement indeed. The upstream Copyright situation is quite mad: https://salsa.debian.org/xen-team/debian-xen/-/blob/experimental/COPYING If I had to summarize this in two words, it would be "Good Luck!". :) "Most files in this repository are licensed" jadija and there are tons of exceptions scattered around everywhere, have fun discovering them. There's not even a Copyright statement in COPYING, by the way. Also not in xen/COPYING. So, this is all a bit confusing for me. Almost two years ago, I tried to rewrite d/copyright from scratch, because the previous version was even more incorrect: https://salsa.debian.org/xen-team/debian-xen/-/commit/72298af566e256afc26a569f39d778b42d68277e I learned a few things from doing that, but it was also pretty mind numbing. Apparently, in the end, the text "Copyright: 2002-present Keir Fraser and/or many others" is something I came up with myself, as some sort of ultimate summary of all the things I had encountered. And, probably because I thought the field was mandatory to have... :O A few days ago, I have been looking around at existing tooling to help analyzing the upstream source tree. I ended up trying cme / scan-copyrights which on first try results in a ~3750 line file with 761 different entries...: https://salsa.debian.org/xen-team/debian-xen/-/commit/dfaea02db1f014ee4c821d3ae9422b410d45fb03 It also shows "Copyright: no-info-found", so maybe that's the answer to what should be mentioned instead? Also, if anyone has tips about this... or the best helper tools to use... appreciated. Or if you know someone who works on one of those tools... Just point them to src:xen as the ultimate terror test package. :) .oO(Well, all jokes aside... It's clear that if we want a fully correct d/copyright file, which can also still be maintained over time, there is probably no other sane way to do that than having something automated that can help.) Hans
Bug#1084238: marked as pending in android-platform-art
Control: tag -1 pending Hello, Bug #1084238 in android-platform-art 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/android-tools-team/android-platform-art/-/commit/1d03b4045f3b332bece8bc665eceda73f1b465bb patch fix: 'Filter' function shadowing its own template parameter (Closes: #1084238) (this message was generated automatically) -- Greetings https://bugs.debian.org/1084238
Bug#1072129: original failure was on amd64 not arm64
Maybe updating this to the latest upstream would fix it? 15 is now available. Also, I noticed that the original reporter built on amd64 while rosh's different results were from arm64.
Bug#1061842: marked as pending in sdkmanager
Control: tag -1 pending Hello, Bug #1061842 in sdkmanager 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/packages/sdkmanager/-/commit/c193e579f7cf7fa5839d3fdf19e1b7122c88029b add looseversion dep that dh missed (Closes: #1061842) (this message was generated automatically) -- Greetings https://bugs.debian.org/1061842
Bug#1061842: didn't pick up looseversion from setup.py
I see the problem now: looseversion is defined in setup.py, but somehow debhelper didn't figure that out. Perhaps it is because of the more complicated declaration: install_requires=[ "argcomplete", "requests > 2.12.2, != 2.18.0", "urllib3<2", 'looseversion; python_version>="3.12"', ],
Bug#1073001: fixed upstream
It is fixed upstream: https://github.com/buildbot/buildbot/commit/291df50dc3f27adb47a001fc154cf4c55490687e
Bug#1062209: should not block migration to testing
control: severity -1 normal Thanks for reporting! In the Android Tools case, the shared libs and packages that use them are packaged together, often from the same source package, so I can't see why we'd need special versions of it. And when we need to, we can use strictly versioned depends, so it should be fine. I'm going to set the bug to normal for now.
Bug#1062105: should not block migration to testing
control: severity -1 normal Thanks for reporting! In the Android Tools case, the shared libs and packages that use them are packaged together, often from the same source package, so I can't see why we'd need special versions of it. And when we need to, we can use strictly versioned depends, so it should be fine. I'm going to set the bug to normal for now.
Bug#1060985: prewikka: FTBFS: ModuleNotFoundError: No module named 'six'
tags 1060985 patch thanks Looks like the package has a missing build dependency on python3-six. Builds successfully with the attached patch. -- mvh / best regards Hans Joachim Desserud http://desserud.orgdiff --git a/debian/control b/debian/control index 403eaea..59746b8 100644 --- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13), python3-setuptools, python3-babel, python3-lesscpy, +python3-six, gettext, Standards-Version: 4.6.0 Homepage: https://www.prelude-siem.org/
Bug#1036386: tools-deps-clojure: FTBFS without network access
Source: tools-deps-clojure
Version: 0.16.1264-2
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
Dear Maintainer,
tools-deps-clojure currently fails to build on Sid. It looks like the
tests attempt to clone the upstream repository and then it fails:
Testing clojure.tools.deps.extensions.test-git
Cloning: https://github.com/clojure/tools.deps.git
FAIL in (canonicalize-errors) (test_git.clj:72)
expected: (thrown-with-msg? ExceptionInfo #"Library
io.github.clojure/tools.deps has coord with missing sha"
(ext/canonicalize (quote io.github.clojure/tools.deps) #:git{:tag
"tools.deps.alpha-0.5.317"} {}))
actual: #error {
:cause "Unable to clone
/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps\nfatal:
unable to access 'https://github.com/clojure/tools.deps.git/': Could not
resolve host: github.com\n"
:data {:args ("git" "clone" "--quiet" "--mirror"
"https://github.com/clojure/tools.deps.git";
"/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps"),
:exit 128, :out "", :err "fatal: unable to access
'https://github.com/clojure/tools.deps.git/': Could not resolve host:
github.com\n"}
:via
[{:type clojure.lang.ExceptionInfo
:message "Unable to clone
/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps\nfatal:
unable to access 'https://github.com/clojure/tools.deps.git/': Could not
resolve host: github.com\n"
:data {:args ("git" "clone" "--quiet" "--mirror"
"https://github.com/clojure/tools.deps.git";
"/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps"),
:exit 128, :out "", :err "fatal: unable to access
'https://github.com/clojure/tools.deps.git/': Could not resolve host:
github.com\n"}
:at [clojure.tools.gitlibs.impl$git_clone_bare invokeStatic
"impl.clj" 103]}]
:trace
I saw this when building locally on Sid,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/tools-deps-clojure.html
also has additional information.
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1036385: python-aioredlock: FTBFS due to missing build dependency python3-setuptools
Source: python-aioredlock
Version: 0.7.3-1
Severity: serious
Justification: FTBFS
Tags: ftbfs sid
Dear Maintainer,
python-aioredlock currently fails to build with the following error
message:
dh clean --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.11 setup.py clean
Traceback (most recent call last):
File "/build/python-aioredlock-0.7.3/setup.py", line 4, in
from setuptools import find_packages, setup
ModuleNotFoundError: No module named 'setuptools'
E: pybuild pybuild:388: clean: plugin distutils failed with: exit
code=1: python3.11 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.11
returned exit code 13
make: *** [debian/rules:4: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned exit
status 2
After adding python3-setuptools to build dependencies the package builds
successfully without any other issues
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount
Package: usrmerge Version: 25 Severity: serious I have some VPSes which are based on Xen, so the kernel comes from the host, and the VPS has no kernel installed. /lib/modules is mounted but not via /etc/fstab. When trying to upgrade from bullseye to bookworm, I get: Preparing to unpack .../archives/usrmerge_35_all.deb ... Unpacking usrmerge (35) ... Setting up usrmerge (35) ... FATAL ERROR: /lib/modules/ is a mount point. Probably this system is using User Mode Linux. To continue the conversion please: - replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab - reboot - try again E: usrmerge failed. dpkg: error processing package usrmerge (--configure): installed usrmerge package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: usrmerge E: Sub-process /usr/bin/dpkg returned an error code (1) Here is some more info which should hopefully be helpful: # umount /lib/modules/ umount: /lib/modules/: target is busy. # lsof /lib/modules COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd-u 1145 root memREG 0,20 1503845 /lib/modules/5.10.104/modules.symbols.bin systemd-u 1145 root memREG 0,20 3224788 /lib/modules/5.10.104/modules.alias.bin systemd-u 1145 root memREG 0,20 119456 10 /lib/modules/5.10.104/modules.dep.bin systemd-u 1145 root memREG 0,20 76634 /lib/modules/5.10.104/modules.builtin.bin # ps -ef|grep 1145 root 1145 1 0 09:29 ?00:00:00 /lib/systemd/systemd-udevd root 16599 25980 0 10:11 pts/100:00:00 grep 1145 # dpkg -l linux* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=== un linux-kernel-log-daemon (no description available) ii linux-libc-dev:amd646.1.20-1 amd64Linux support headers for userspace development # mount |grep /lib modules on /lib/modules type tmpfs (rw,relatime,size=102400k,mode=700) # cat /etc/fstab /dev/xvda1 / xfs defaults0 0 proc/proc procdefaults0 0 #
Bug#1033833: unknown-horizons: Fails to start Couldn't open content/fonts/Unifont.ttf
Package: unknown-horizons Version: 2019.1-5 Severity: grave Dear Maintainer, When attempting to run uknown-horizons it fails with the following error message: $ unknown-horizons Discovered old settings file, auto-upgrading: 1 -> 38 Traceback (most recent call last): File "/usr/games/unknown-horizons", line 381, in main() File "/usr/games/unknown-horizons", line 122, in main ret = horizons.main.start(options) File "/usr/lib/python3/dist-packages/horizons/main.py", line 171, in start horizons.globals.fife.init() File "/usr/lib/python3/dist-packages/horizons/engine/engine.py", line 181, in init self._setting.apply() File "/usr/lib/python3/dist-packages/horizons/engine/settings.py", line 91, in apply change_language(language) File "/usr/lib/python3/dist-packages/horizons/i18n/__init__.py", line 163, in change_language horizons.globals.fife.pychan.loadFonts(fontdef) File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 98, in loadFonts for font in Font.loadFromFile(filename): ^^^ File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 82, in loadFromFile fonts.append(Font(font, lambda key, default=None: fontXMLFile.get(font, key, default))) ^ File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 52, in __init__ self.font = get_manager().createFont(self.source, self.size) File "/usr/lib/python3/dist-packages/fife/extensions/pychan/internal.py", line 176, in createFont return self.hook.create_font(path,size,glyphs) ^^^ fife.fife.CannotOpenFile: _[CannotOpenFile]_ , File couldn't be opened :: content/fonts/Unifont.ttf (Couldn't open content/fonts/Unifont.ttf) The root problem is a missing font or font format. I tried a simple rebuild of the package, but it had no effect. Looks like the font path is part of the source code, so might be more font references with similar issues. Also reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/unknown-horizons/+bug/2011358 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/3 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 unknown-horizons depends on: ii fonts-unifont 1:15.0.01-2 ii python3 3.11.2-1 ii python3-enet0.0~vcs.2022.12.26.git-0.2+b1 ii python3-fife0.4.2-5+b1 ii python3-future 0.18.2-6 ii python3-yaml6.0-3+b2 unknown-horizons recommends no packages. unknown-horizons suggests no packages. -- no debconf information -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1029668: confirmed
I'm having the same problem on bookworm, for me, I'm using the default eog viewer. There is a new upstream version of libheif available (v1.15.1), there is still time to upload that to bookworm. I'm a DD and I could do an NMU if that is helpful
Bug#1011567: needs com.sun.javadoc migration
Looks like doclava would need to be ported to use the API that replaces com.sun.javadoc: https://docs.oracle.com/en/java/javase/11/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration If someone does the migration, I can take care of the packaging updates.
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Roger, it is great to see your progress on android-platform-tools. Are you thinking of trying to get it into bookworm? If so, let me know how I can help. It would be really valuable to have there, but I don't know how much work it'll be.
Bug#1012103: upstream still uses java8
Doclava, which does not work with Java newer than 11. Upstream still builds it with java8. As in Android 13 still uses java8 in the build. Is there any hope?
Bug#1030728: Subject: FTBFS: tests fail, requiring network access
Source: biojava6-live
Version: 6.1.0+dfsg-3
Severity: serious
Tag: ftbfs patch
Dear Maintainer,
biojava6-live currently fails to build from source with test failures:
[ERROR] Failures:
[ERROR] FileDownloadUtilsTest$URLMethods.pingGoogleOK:161 expected:
but was:
The attached patch disables this and another test which require network
access. With these disabled, the package built successfully.
For more details, see either the build log from reproducible builds or
when the package was synced to Ubuntu
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biojava6-live.html
https://launchpad.net/ubuntu/+source/biojava6-live/6.1.0+dfsg-3/+build/25558013
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Disable tests which require network access
Disable two tests which require network access when running.
To be honest, I don't see exactly how TestJmolSymmetryScriptGenerator ends up
calling network resources. I did see that when running the test suite with it
enabled it will send a request to https://models.rcsb.org/ presumably fetching
the models.
---
--- biojava6-live-6.1.0+dfsg.orig/biojava-core/src/test/java/org/biojava/nbio/core/util/FileDownloadUtilsTest.java
+++ biojava6-live-6.1.0+dfsg/biojava-core/src/test/java/org/biojava/nbio/core/util/FileDownloadUtilsTest.java
@@ -12,6 +12,7 @@ import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.file.Files;
+import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
@@ -156,6 +157,7 @@ class FileDownloadUtilsTest {
class URLMethods {
final String availableUrl = "https://www.google.com";;
+ @Disabled("Requires network access")
@Test
void pingGoogleOK(){
assertTrue(FileDownloadUtils.ping(availableUrl, 1000));
--- biojava6-live-6.1.0+dfsg.orig/biojava-structure-gui/src/test/java/org/biojava/nbio/structure/symmetry/TestJmolSymmetryScriptGenerator.java
+++ biojava6-live-6.1.0+dfsg/biojava-structure-gui/src/test/java/org/biojava/nbio/structure/symmetry/TestJmolSymmetryScriptGenerator.java
@@ -39,6 +39,7 @@ import org.biojava.nbio.structure.symmet
import org.biojava.nbio.structure.symmetry.core.SymmetryPerceptionMethod;
import org.biojava.nbio.structure.symmetry.jmolScript.JmolSymmetryScriptGeneratorDn;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
/**
@@ -50,6 +51,7 @@ public class TestJmolSymmetryScriptGener
public void setUp() {
}
+@Ignore
@Test
public void testPolygon() throws IOException, StructureException {
Structure struc = StructureIO.getStructure("4hhb");
@@ -64,4 +66,4 @@ public class TestJmolSymmetryScriptGener
String expected = "draw polyhedronD30 line{30.02,-39.95,0.59}{29.24,-0.53,40.00}{30.02,38.89,0.59}{30.80,-0.53,-38.82}{30.02,-39.95,0.59}{-30.00,-39.95,-0.60}{-30.79,-0.53,38.81}{-30.00,38.89,-0.60}{-29.22,-0.53,-40.01}{-30.00,-39.95,-0.60}width 0.45 color [x42ffd9] off;draw polyhedronD31 line{29.24,-0.53,40.00}{-30.79,-0.53,38.81}width 0.45 color [x42ffd9] off;draw polyhedronD32 line{30.02,38.89,0.59}{-30.00,38.89,-0.60}width 0.45 color [x42ffd9] off;draw polyhedronD33 line{30.80,-0.53,-38.82}{-29.22,-0.53,-40.01}width 0.45 color [x42ffd9] off;";
assertEquals(expected, poly);
}
-}
\ No newline at end of file
+}
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
Source: ruby-puppetserver-ca-cli Version: 2.4.0-1 Severity: serious Tag: ftbfs Dear Maintainer, ruby-puppetserver-ca-cli currently fails to build from source with test failures. Example: 1) Puppetserver::Ca::Action::Enable infracrl does not print the help output if called correctly Failure/Error: FileUtils.chown(@user, @group, path) ArgumentError: can't find user for puppet # ./lib/puppetserver/ca/utils/file_system.rb:96:in `write_file' # ./lib/puppetserver/ca/utils/file_system.rb:23:in `write_file' # ./lib/puppetserver/ca/action/enable.rb:109:in `create_infra_crl_chain' # ./lib/puppetserver/ca/action/enable.rb:75:in `enable_infra_crl' # ./lib/puppetserver/ca/action/enable.rb:53:in `run' # ./spec/puppetserver/ca/action/enable_spec.rb:34:in `block (5 levels) in ' # ./spec/utils/ssl.rb:248:in `with_ca_in' # ./spec/puppetserver/ca/action/enable_spec.rb:28:in `block (4 levels) in ' # ./spec/puppetserver/ca/action/enable_spec.rb:27:in `block (3 levels) in ' For more details see the log from reproducible builds https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-puppetserver-ca-cli.html (I have also verified the issue with pbuilder on my local Sid system) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/3 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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1026571: jnlp-servlet: FTBFS: src/classes/jnlp/sample/servlet/JnlpResource.java:47: error: cannot find symbol
Fwiw, java.util.jar.Pack200 was removed in JDK 14 and is thus missing when building with JDK 17. https://openjdk.org/jeps/367 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1026608: jcommander: FTBFS: JCommander.java:45: error: malformed HTML
tags 1026608 patch
thanks
See the attached patch which resolves the HTML errors to generate the
JavaDoc and make the package build successfully.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Fix HTML errors in Javadoc causing build failures
Remove tags, not part of HTML5
Replace <> wrapping author emails
Drop <> around generic T which is mistaken for HTML tag
Resolved based on how it was solved upstream:
https://github.com/cbeust/jcommander/commit/c31f983ae8f56a5b06f502009dfb32baa2be96f1
https://github.com/cbeust/jcommander/commit/7b46f253f625c91b47ef7e0780c01ffd357f4cd2
---
Origin: upstream,
Forwarded: not-needed
Last-Update: 2022-12-21
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/Parameter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/Parameter.java
@@ -69,15 +69,15 @@ public @interface Parameter {
boolean password() default false;
/**
- * The string converter to use for this field. If the field is of type List
- * and not listConverter attribute was specified, JCommander will split
+ * The string converter to use for this field. If the field is of type List
+ * and not listConverter attribute was specified, JCommander will split
* the input in individual values and convert each of them separately.
*/
Class> converter() default NoConverter.class;
/**
* The list string converter to use for this field. If it's specified, the
- * field has to be of type List and the converter needs to return
+ * field has to be of type List and the converter needs to return
* a List that's compatible with that type.
*/
Class> listConverter() default NoConverter.class;
@@ -103,7 +103,7 @@ public @interface Parameter {
boolean variableArity() default false;
/**
- * What splitter to use (applicable only on fields of type List). By default,
+ * What splitter to use (applicable only on fields of type List). By default,
* a comma separated splitter will be used.
*/
Class splitter() default CommaParameterSplitter.class;
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/IParameterValidator.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/IParameterValidator.java
@@ -21,7 +21,7 @@ package com.beust.jcommander;
/**
* The class used to validate parameters.
*
- * @author Cedric Beust
+ * @author Cedric Beust <ced...@beust.com>
*/
public interface IParameterValidator {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/IStringConverter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/IStringConverter.java
@@ -33,7 +33,7 @@ package com.beust.jcommander;
*/
public interface IStringConverter {
/**
- * @return an object of type created from the parameter value.
+ * @return an object of type T created from the parameter value.
*/
T convert(String value);
}
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/JCommander.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/JCommander.java
@@ -42,7 +42,7 @@ import java.util.concurrent.CopyOnWriteA
* or an instance of Iterable. In the case of an array or Iterable, JCommander will collect
* the \@Parameter annotations from all the objects passed in parameter.
*
- * @author Cedric Beust
+ * @author Cedric Beust <ced...@beust.com>
*/
public class JCommander {
public static final String DEBUG_PROPERTY = "jcommander.debug";
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/MissingCommandException.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/MissingCommandException.java
@@ -21,7 +21,7 @@ package com.beust.jcommander;
/**
* Thrown when a command was expected.
*
- * @author Cedric Beust
+ * @author Cedric Beust <ced...@beust.com>
*/
@SuppressWarnings("serial")
public class MissingCommandException extends ParameterException {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/ParameterException.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/ParameterException.java
@@ -22,7 +22,7 @@ package com.beust.jcommander;
* The main exception that JCommand will throw when something goes wrong while
* parsing parameters.
*
- * @author Cedric Beust
+ * @author Cedric Beust <ced...@beust.com>
*/
@SuppressWarnings("serial")
public class ParameterException extends RuntimeException {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/ResourceBundle.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/ResourceBundle.java
@@ -26,7 +26,7 @@ import java.lang.annotation.Target;
/**
* @deprecated use @Parameters
*
- * @author Cedric Beust
+ * @author Cedric Beust <ced...@beust.com>
*/
@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({ TYPE })
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/SubParameter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/S
Bug#1026163: Uses Java 11
The main reason puppetdb fails to build with JDK 17 is a check in project.clj which only allows Java 8 or 11. However, this has recently been expanded to allow Java 17 in upstream [1] and should be part of the 7.12.0 release. So upgrading the package should hopefully resolve this. Somewhat unrelated but I did notice that several other puppet-related packages, at least https://tracker.debian.org/pkg/puppetlabs-http-client-clojure https://tracker.debian.org/pkg/trapperkeeper-metrics-clojure https://tracker.debian.org/pkg/trapperkeeper-webserver-jetty9-clojure have similar checks which will fail with Java 17. They don't seem to have newer upstream versions though, and I don't know if additional changes in the code would be required for these to support Java 17. [1] https://github.com/puppetlabs/puppetdb/blob/main/project.clj#L281 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1026617: libjt400-java: FTBFS: [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:149: error: reference to Record is ambiguous
tags 1026617 patch thanks [javac] both class com.ibm.as400.access.Record in com.ibm.as400.access and class java.lang.Record in java.lang match [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:1375: error: reference to Record is ambiguous Looks like the ambiguity stems from the new Record class introduced in new JDKS which hit when rebuilt with JDK 17. See the attached patch which adds an explicit import to the "local" Record class, which has been the one imported up until now. With this patch in place, the package builds successfully again on Debian Sid. -- mvh / best regards Hans Joachim Desserud http://desserud.orgDescription: Explicit import for Record Since this code predates java.lang.Record in the JDK, I'm going to assume it refers to its own class --- Forwarded: no Last-Update: 2022-12-21 --- libjt400-java-9.4.orig/src/com/ibm/as400/data/RecordFormatDocument.java +++ libjt400-java-9.4/src/com/ibm/as400/data/RecordFormatDocument.java @@ -14,6 +14,7 @@ package com.ibm.as400.data; import com.ibm.as400.access.*; +import com.ibm.as400.access.Record; import java.io.File; import java.io.FileOutputStream; --- libjt400-java-9.4.orig/src/com/ibm/as400/data/RfmlRecordFormat.java +++ libjt400-java-9.4/src/com/ibm/as400/data/RfmlRecordFormat.java @@ -26,6 +26,7 @@ import java.util.TimeZone; import java.util.Vector; import com.ibm.as400.access.*; +import com.ibm.as400.access.Record; /**
Bug#1026258: FTBFS: missing build dependency and failing tests
Source: ormar
Version: 0.12.0-1
Severity: serious
Tag: ftbfs
Dear Maintainer,
ormar currently fails to build from source for two reasons. The first is
several error message like these when running the test suite:
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_fastapi/test_skip_reverse_models.py:8: in
from starlette.testclient import TestClient
/usr/lib/python3/dist-packages/starlette/testclient.py:16: in
import httpx
E ModuleNotFoundError: No module named 'httpx'
_ ERROR collecting tests/test_fastapi/test_wekref_exclusion.py
_
(Taken from the build log when the package got synced to Ubuntu, but
I've also reproduced this on Sid
https://launchpadlibrarian.net/638906557/buildlog_ubuntu-lunar-amd64.ormar_0.12.0-1_BUILDING.txt.gz)
These errors are the easy part, it simply needs
python3-httpx
added as a build dependency. With this in place, the build result
changes from 19 errors to 2 failing tests. I don't know why they are
failing though, whether it is due to api changes in the test client
used, or the functionality of the package.
=== FAILURES
===
__ test_all_endpoints
__
def test_all_endpoints():
client = TestClient(app)
with client as client:
item = {
"name": "test",
"categories": [{"name": "test cat"}, {"name": "test
cat2"}],
}
response = client.post("/items/", json=item)
item_check = Item(**response.json())
assert item_check.id is not None
assert item_check.categories[0].id is not None
no_pk_item = client.get(f"/items/{item_check.id}",
json=item).json()
E TypeError: TestClient.get() got an unexpected keyword
argument 'json'
tests/test_fastapi/test_excluding_fields.py:118: TypeError
__ test_all_endpoints
__
def test_all_endpoints():
client = TestClient(app)
with client as client:
response = client.post("/categories/", json={"name": "test
cat"})
category = response.json()
response = client.post(
"/items/", json={"name": "test", "id": 1, "category":
category}
)
item = Item(**response.json())
assert item.pk is not None
response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0] == item
item.name = "New name"
response = client.put(f"/items/{item.pk}", json=item.dict())
assert response.json() == item.dict()
response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"
response = client.get("/items/raw/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"
assert items[0].category.name is None
response = client.get(f"/items/{item.pk}")
new_item = Item(**response.json())
assert new_item == item
response = client.delete(f"/items/{item.pk}")
assert response.json().get("deleted_rows", "__UNDEFINED__")
!= "__UNDEFINED__"
response = client.get("/items/")
items = response.json()
assert len(items) == 0
client.post("/items/", json={"name": "test_2", "id": 2,
"category": category})
response = client.get("/items/")
items = response.json()
assert len(items) == 1
item = Item(**items[0])
response = client.delete(f"/items/{item.pk}",
json=item.dict())
E TypeError: TestClient.delete() got an unexpected keyword
argument 'json'
tests/test_fastapi/test_more_reallife_fastapi.py:150: TypeError
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1026257: FTBFS: more network tests in node-zx
Source: node-zx
Version: 7.1.1+~cs6.7.23-1
Severity: serious
Tag: ftbfs patch
Dear Maintainer,
node-zx currently fails to build with the following error messages:
FAIL deps "installDeps() loader works via JS API"
Cannot find package 'cpy' imported from
/build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js
FAIL deps "installDeps() loader works via CLI"
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'lodash' imported from
/build/node-zx-7.1.1+~cs6.7.23/zx-kdsc9wx1fn.mjs
Did you mean to import lodash/lodash.js?
at new NodeError (node:internal/errors:393:5)
at packageResolve (node:internal/modules/esm/resolve:860:9)
at moduleResolve (node:internal/modules/esm/resolve:909:20)
at defaultResolve (node:internal/modules/esm/resolve:1124:11)
at nextResolve (node:internal/modules/esm/loader:163:28)
at ESMLoader.resolve (node:internal/modules/esm/loader:841:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
at ModuleWrap.
(node:internal/modules/esm/module_job:76:40)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
at Object.handler
(file:///build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js:35:12)
exit code: 1
(See
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-zx.html
for more details)
I was able to reproduce the same error message when building in pbuilder
on my local Sid system. Turns out there's a couple of tests which call
`npm install` and verify the results which breaks when the network is
not available.
After expanding and applying the patch to disable network tests, the
package builds successfully.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/patches/drop-network-test.patch b/debian/patches/drop-network-test.patch
index cf5cd17..905f6a8 100644
--- a/debian/patches/drop-network-test.patch
+++ b/debian/patches/drop-network-test.patch
@@ -1,7 +1,7 @@
Description: drop network test
Author: Yadd
Forwarded: not-needed
-Last-Update: 2022-11-07
+Last-Update: 2022-12-17
--- a/test/cli.test.js
+++ b/test/cli.test.js
@@ -37,3 +37,24 @@ Last-Update: 2022-11-07
test('echo() works', async () => {
let stdout = ''
let log = console.log
+--- a/test/deps.test.js
b/test/deps.test.js
+@@ -21,7 +21,7 @@ const test = suite('deps')
+
+ $.verbose = false
+
+-test('installDeps() loader works via JS API', async () => {
++test.skip('installDeps() loader works via JS API', async () => {
+ await installDeps({
+ cpy: '9.0.1',
+ 'lodash-es': '4.17.21',
+@@ -30,7 +30,7 @@ test('installDeps() loader works via JS
+ assert.instance((await import('lodash-es')).pick, Function)
+ })
+
+-test('installDeps() loader works via CLI', async () => {
++test.skip('installDeps() loader works via CLI', async () => {
+ let out =
+ await $`node build/cli.js --install <<< 'import _ from "lodash" /* @4.17.15 */; console.log(_.VERSION)'`
+ assert.match(out.stdout, '4.17.15')
+
Bug#1026255: FTBFS: error: invalid flag: -html4
Source: junit5-system-exit
Version: 1.1.2-3
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
junit5-system-exit currently fails to build from source with the
following error message:
Starting process 'command
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''. Working directory:
/build/1st/junit5-system-exit-1.1.2 Command:
/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc
@/build/1st/junit5-system-exit-1.1.2/build/tmp/javadoc/javadoc.options
Successfully started process 'command
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''
error: invalid flag: -html4
1 error
(for details see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/junit5-system-exit.html)
I was able to reproduce this on my Sid system, and the package built
successfully when replacing the flag, see the attached patch.
Based on the output from javadoc, this option now seems to be the
default
-html5Generate HTML 5 output. This option is no longer
required.
so alternatively the javadoc section can be trimmed down. Another thing
is that I haven't checked when the html5 option was introduced or when
it replaced html4. It builds successfully with the current JDK, but it
might introduced problems when backporting the package in the future. I
don't know if this is a concern.
Regardless, the attached patch should fix the build issue or serve as
the base for a better fix :)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Replace html4 option with html5
The html4 option has been removed/replaced in newer JDKs, causing a build
failure.
---
Forwarded: no
--- junit5-system-exit-1.1.2.orig/build.gradle
+++ junit5-system-exit-1.1.2/build.gradle
@@ -74,6 +74,6 @@ publishing {
javadoc {
if(JavaVersion.current().isJava9Compatible()) {
-options.addBooleanOption('html4', true)
+options.addBooleanOption('html5', true)
}
}
Bug#1026083: Security: XSS bug in Loofah
Package: ruby-loofah Version: 2.19.0-1 Severity: serious control: affects -1 ruby-loofah/2.1.0 control: affects -1 ruby-loofah/2.7.0+dfsg-1 control: tags -1 fixed-upstream security help An XSS issue has been discovered in Loofah: https://github.com/flavorjones/loofah/security/advisories/GHSA-228g-948r-83gx It is fixed in the upstream release v2.19.1.
Bug#1025887: FTBFS: ambiguous method call
Source: biojava4-live
Version: 4.2.12+dfsg-7
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
biojava4-live currently fails to build with the following error message:
compile:
[mkdir] Created dir:
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/build.xml:86:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 483 source files to
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:239:
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem fs =
FileSystems.newFileSystem(m_zipFile, null)) {
[javac] ^
[javac] both method newFileSystem(Path,ClassLoader) in FileSystems
and method newFileSystem(Path,Map) in FileSystems match
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:296:
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem zipfs =
FileSystems.newFileSystem(zipFile, null)) {
[javac]^
[javac] both method newFileSystem(Path,ClassLoader) in FileSystems
and method newFileSystem(Path,Map) in FileSystems match
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use or override a deprecated API that
is marked for removal.
[javac] Note: Recompile with -Xlint:removal for details.
[javac] Note:
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/MetalBondConsumer.java
uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
(see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biojava4-live.html
for details)
When casting the null value to match one of the signatures this resolves
the build error. See the attached patch. I wasn't able to find the exact
upstream commit to reference since the file has been moved around, but
the patch is based on latest upstream and how they have chosen to
resolve the issue.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Add explicit cast to fix ambiguos method call error
Taken from upstream to match expected method call
https://github.com/biojava/biojava/blob/master/biojava-structure/src/main/java/org/biojava/nbio/structure/chem/ZipChemCompProvider.java
---
Origin: upstream
Forwarded: not-needed
Last-Update: 2022-12-11
--- biojava4-live-4.2.12+dfsg.orig/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
+++ biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
@@ -236,7 +236,7 @@ public class ZipChemCompProvider impleme
final String filename = "chemcomp/" + recordName+".cif.gz";
// try with resources block to read from the filesystem.
- try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, null)) {
+ try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, (ClassLoader)null)) {
Path cif = fs.getPath(filename);
if (Files.exists(cif)) {
@@ -293,7 +293,7 @@ public class ZipChemCompProvider impleme
*/
// Copy in each file.
- try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, null)) {
+ try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, (ClassLoader)null)) {
Files.createDirectories(pathWithinArchive);
for (File f : files) {
if (!f.isDirectory() && f.exists()) {
Bug#1025753: FTBFS: Java compilation error (cannot find symbols)
Source: jruby-openssl Version: 0.9.21-4 Severity: serious Tags: ftbfs Dear Maintainer, jruby-openssl currently fails to build with the following error message: [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[74,25] cannot find symbol symbol: class ChannelDescriptor location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[75,25] cannot find symbol symbol: class ChannelStream location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[76,25] cannot find symbol symbol: class FileExistsException location: package org.jruby.util.io [INFO] 3 errors Tested in pbuilder on my Sid system. Same error seemed to happen when the package got synced to Ubuntu [1] Btw, looks like the problematic imports are gone in latest upstream [2] so this might be resolved by upgrading to newer release :) [1] https://launchpad.net/ubuntu/+source/jruby-openssl/0.9.21-4/+build/24611214 [2] https://github.com/jruby/jruby-openssl/blob/master/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1025440: FTBFS: fails to compile with Java errors
Source: starjava-ttools Version: 3.4.7-2 Severity: serious Tags: ftbfs Dear Maintainer, starjava-ttools fails to build from source, see https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/starjava-ttools.html for detailed log output. The main errors seem to be com.sun.* imports. I've also seen the same build failure when the package got synced to Ubuntu (https://launchpad.net/ubuntu/+source/starjava-ttools/3.4.7-2/+build/24622556) as well as locally on my Sid system. Not sure what might have changed since the package got uploaded in the first place. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1007977: [Android-tools-devel] Bug#1007977: android-platform-system-core: builds adb which is also built (at a higher version) by android-platform-tools
Right, this is an ongoing, incomplete migration. Anything that is built in android-platform-tools should be removed from android-platform-system-core or any other android-platform-* packages. We welcome contributions there!
Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it
Hi, after updating libsane1 yesterday xsane works as expected. Georg
Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it
Scanimage fails starting the scan, too. The result of "scanimage -d epson2:libusb:002:005 --format png -o /home/georg/unsinn.png" is "scanimage: sane_start: Operation not supported". Georg
Bug#988477: [Pkg-xen-devel] Bug#988477: Acknowledgement (xen-hypervisor-4.14-amd64: xen dmesg shows (XEN) AMD-Vi: IO_PAGE_FAULT on sata pci device)
severity 988477 normal tags 988477 + moreinfo + upstream - bullseye-ignore thanks Hi! On 6/13/21 3:58 PM, Imre Szőllősi wrote: > i tested on 4th hw > > 4. asus m4n78 pro, phenom ii x4 905e, md raid1, 2x samsung 1TB 860evo, > lvm: problem does not appear > > as i see, not all mb/chipset/sata pcie device affected Thanks for your report, and for trying out different combinations of hardware. While doing a short internet search about the problems you're seeing while using AMD ryzen, sata, nvme and iommu, I suspect this problem does not have a lot to do with Xen specifically, but more with the hardware and its firmware. This also means that it's not a Debian packaging problem, and it cannot be fixed by me (or the Debian Xen team). If you want to research this problem more, I can maybe be of some help by providing suggestions. Still, you will have to do all of the actual work, since I do not have your hardware here. The first thing I would suggest is to try reproduce the problem when booting with just Linux without Xen, and then trying the dbench test. If you don't actually need to directly pass-through hardware to a Xen guest, you can also try disabling iommu, or researching other iommu= options that can serve as a workaround. In any case, further reports will need to have more detailed information. For example, instead of "there are a lot of messages", provide a text attachment with a piece of logging that shows these messages. I'm tagging this bug 'moreinfo' now, since it will depend on your availability and abilities to work on it to have it advance. Have fun, Hans van Kranenburg
Bug#988287: FTBFS due to test failures
Source: rally-openstack Version: 2.0.0-2 Severity: serious Justification: FTBFS in unstable Tags: ftbfs Dear Maintainer, rally-openstack currently fails to build on Debian Sid with test failures: (...) ERROR tests/unit/task/scenarios/zaqar/test_utils.py - dns.resolver.NoResolver... ERROR tests/unit/task/ui/charts/test_osprofilerchart.py - dns.resolver.NoReso... ERROR tests/unit/verification/tempest/test_config.py - dns.resolver.NoResolve... ERROR tests/unit/verification/tempest/test_context.py - dns.resolver.NoResolv... ERROR tests/unit/verification/tempest/test_manager.py - dns.resolver.NoResolv... !! Interrupted: 180 errors during collection !!! 180 errors in 61.15s (0:01:01) make[1]: *** [debian/rules:25: override_dh_auto_install] Error 2 See also https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rally-openstack.html for more details. -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#983697: FTBFS: Failing tests
Source: trapperkeeper-webserver-jetty9-clojure Version: 4.1.0-2 Severity: serious Justification: FTBFS in unstable Tags: ftbfs Dear Maintainer, The latest version of trapperkeeper-webserver-jetty9-clojure currently fails to build due to failing tests: ... Ran 86 tests containing 588 assertions. 10 failures, 0 errors. Tests failed. make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1 make[1]: Leaving directory '/build/1st/trapperkeeper-webserver-jetty9-clojure-4.1.0' make: *** [debian/rules:11: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 See also https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/trapperkeeper-webserver-jetty9-clojure.html for more information -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/3 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#982046: marked as pending in golang-github-avast-apkverifier
Control: tag -1 pending Hello, Bug #982046 in golang-github-avast-apkverifier reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-avast-apkverifier/-/commit/10b6ee64330ddc9a90328db8e6b5de650c0f8d1e autopkgtest needs ca-certificates (Closes: #982046) (this message was generated automatically) -- Greetings https://bugs.debian.org/982046
Bug#973082: confirmed
Great! Then it sounds like it should be included. It is a Python Team package and the source code is on salsa, so feel free to go ahead and upload.
Bug#973082: confirmed
Do the tests pass with this patch?
Bug#980644: [Android-tools-devel] Bug#980644: android-sdk-platform-tools-common: no Multi-Arch annotation prevents adb upgrade
Control: severity -1 normal Right now, we can only commit to supporting the arches that upstream supports (amd64 and arm64), so I'm downgrading the severity. I could never wrap my head around the Multi-Arch: stuff. I would accept a merge request on salsa for this, if it passes in gitlab-ci.
Bug#972377: can't reproduce
can't reproduce
Bug#975747: reopen the close to work around BTS bug
Control: reopen -1
Bug#977912: This is due to aapt's linking error.
Control: reassign -1 aapt Control: merge 977023 977912 This is due to aapt's linking error. The fdroidserver tests rely on aapt.
Bug#975747: this is actually fixed
Control: fixed -1 1:10.0.0+r36-1 Control: fixed -1 1:10.0.0+r36-2 Control: fixed -1 1:10.0.0+r36-3 Control: fixed -1 1:10.0.0+r36-4
Bug#979329: I think I have a fix
Control: tags -1 pending confirmed This is also confirmed by CI: https://salsa.debian.org/android-tools-team/android-platform-system-core/-/jobs/1310262 Testing a fix here: https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1314158
Bug#973082: confirmed
Control: tags -1 help confirmed In Python 3.9, the plistlib was changed to no longer have the internal data structure plistlib.Data, which biplist relied on. Here's a potential fix: https://github.com/unified-font-object/ufoNormalizer/pull/74/files
Bug#972377: can't reproduce
Control: fixed -1 1.6.1-2 I can't reproduce this, perhaps it was fixed by the upgrade to Python 3.9. For example: https://salsa.debian.org/python-team/packages/pyasn/-/pipelines/214872
Bug#976891: Unable to find next sigaction in signal chain
Now fastboot and aapt build and link but both report this error:
Unable to find next sigaction in signal chain
Looks like some dynamically loaded code is missing, the error is in
sigchainlib/sigchain.cc:
static void lookup_next_symbol(T* output, T wrapper, const char* name) {
void* sym = dlsym(RTLD_NEXT, name); // NOLINT glibc triggers
cert-dcl16-c with RTLD_NEXT.
if (sym == nullptr) {
sym = dlsym(RTLD_DEFAULT, name);
if (sym == wrapper || sym == sigaction) {
fatal("Unable to find next %s in signal chain", name);
}
}
*output = reinterpret_cast(sym);
}
Bug#976891: update
fastboot is getting pretty close to working on amd64: https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1297944
Bug#963058: upstream only supports x86
Control: severity -1 wishlist Control: retitle -1 port android-platform-art to ARM, etc.
Bug#963058: [Android-tools-devel] Bug#963058: still ftbfs on arm64
It looks like upstream does not support anything but x86, and they've added assembly code. So unless someone steps up to port that to ARM, the ARM binaries will be removed.
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
also, it looks like libunwindstack uses asm and there isn't any for ARM. So if someone wants to keep the arm packages, they'll need to figure that out. I have zero asm skills.
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
Roger Shimizu: On Wed, Dec 30, 2020 at 3:46 AM Hans-Christoph Steiner wrote: Ok, I fixed the dependency issue, now it gets reliably to the point rosh gets to: Thanks for fixing the build dependency issue! I fixed a few other issues (operator script & mterp generation, etc), and pushed to rosh/refine branch. Current build breaking point is the same as previous one. I tried to use different c++ library, such as libstdc++-8-dev, and clang-9, but seems no help. I have android-platform-art building as a stage1 now, so I'm working again on android-platform-system-core. I haven't found where these symbols are supposed to come from: clang++ fastboot/bootimg_utils.cpp fastboot/fastboot.cpp fastboot/fastboot_driver.cpp fastboot/fs.cpp fastboot/main.cpp fastboot/socket.cpp fastboot/tcp.cpp fastboot/udp.cpp fastboot/usb_linux.cpp fastboot/util.cpp fs_mgr/liblp/builder.cpp fs_mgr/liblp/images.cpp fs_mgr/liblp/partition_opener.cpp fs_mgr/liblp/reader.cpp fs_mgr/liblp/utility.cpp fs_mgr/liblp/writer.cpp -o fastboot/fastboot -g -O2 -fdebug-prefix-map=/build/android-platform-system-core-10.0.0+r36=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -std=gnu++2a -fpermissive -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -UDEBUG -I/usr/include/android -DPLATFORM_TOOLS_VERSION='"28.0.2"' -Iinclude -Imkbootimg/include/bootimg -Iadb -Ibase/include -Idemangle/include -Idiagnose_usb/include -Ifs_mgr/include -Ifs_mgr/include_fstab -Ifs_mgr/liblp/include -I/usr/include/android -I/usr/include/android/f2fs_utils -I/usr/include/android/openssl -Ilibsparse/include -Ilibziparchive/include -Wl,-z,relro -Wl,-z,now -fPIC -Wl,-rpath=/usr/lib/x86_64-linux-gnu/android -Wl,-rpath-link=. -L. -lziparchive -lsparse -lbase -lcutils -ladb -lutils -lssl -lcrypto -L/usr/lib/x86_64-linux-gnu/android -lart -l7z -lunwind /usr/bin/ld: /tmp/utility-794e29.o: in function `android::fs_mgr::GetDescriptorSize(int, unsigned long*)': ./fs_mgr/liblp/utility.cpp:49: undefined reference to `get_block_device_size' /usr/bin/ld: ./libbacktrace.so.0: undefined reference to `typeinfo for art_api::dex::DexFile' Check my forks for the most current commits: https://salsa.debian.org/eighthave/android-platform-art https://salsa.debian.org/eighthave/android-platform-system-core .hc
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
Hans-Christoph Steiner: It looks like the clean build stops before the error you reported: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335 In file included from runtime/runtime.cc:53: runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found #include "asm_defines.h" ^~~ 1 error generated. make[2]: *** [debian/libart.mk:473: runtime/runtime.o] Error 1 My guess is that the Makefile dependency rules are wrong, since the target that builds asm_defines.h works fine when manually run. If you use your own fork, and force-push commits to your fork's master branch, it'll run the CI jobs, which are totally clean builds each time. Ok, I fixed the dependency issue, now it gets reliably to the point rosh gets to: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291535 .hc
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
It looks like the clean build stops before the error you reported: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335 In file included from runtime/runtime.cc:53: runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found #include "asm_defines.h" ^~~ 1 error generated. make[2]: *** [debian/libart.mk:473: runtime/runtime.o] Error 1 My guess is that the Makefile dependency rules are wrong, since the target that builds asm_defines.h works fine when manually run. If you use your own fork, and force-push commits to your fork's master branch, it'll run the CI jobs, which are totally clean builds each time.
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
As far as I know, the blocker for fastbook is android-platform-art. It
has a crazy upstream build system. Right now, it almost building, but
the build is currently dying on this error:
clang++ -o runtime/compiler_filter.o -g -O2
-fdebug-prefix-map=/build/android-platform-art-10.0.0+r36=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -c
-std=gnu++17 -Wno-invalid-offsetof -Wno-invalid-partial-specialization
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -fno-rtti
-fstrict-aliasing -fvisibility=protected -fno-omit-frame-pointer
-Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -I/usr/include/android -UDEBUG
-Umips -DART_BASE_ADDRESS_MAX_DELTA=0x100
-DART_BASE_ADDRESS_MIN_DELTA=-0x100 -DART_BASE_ADDRESS=0x6000
-DART_DEFAULT_COMPACT_DEX_LEVEL=fast -DART_DEFAULT_GC_TYPE_IS_CMS
-DART_ENABLE_ADDRESS_SANITIZER=1 -DART_ENABLE_CODEGEN_arm
-DART_ENABLE_CODEGEN_arm64 -DART_ENABLE_CODEGEN_mips
-DART_ENABLE_CODEGEN_mips64 -DART_ENABLE_CODEGEN_x86
-DART_ENABLE_CODEGEN_x86_64 -DART_FRAME_SIZE_LIMIT=1736
-DART_READ_BARRIER_TYPE_IS_BAKER=1 -DART_STACK_OVERFLOW_GAP_arm=8192
-DART_STACK_OVERFLOW_GAP_arm64=8192 -DART_STACK_OVERFLOW_GAP_mips=16384
-DART_STACK_OVERFLOW_GAP_mips64=16384
-DART_STACK_OVERFLOW_GAP_x86_64=8192 -DART_STACK_OVERFLOW_GAP_x86=8192
-DART_USE_READ_BARRIER=1 -DBUILDING_LIBART=1 -DIMT_SIZE=43
-DUSE_D8_DESUGAR=1 -I. -I/usr/include/android/nativehelper
-I/usr/include/valgrind -Icmdline -Iruntime -Iruntime/generated
-Ilibartbase -Ilibartpalette/include -Ilibdexfile -Ilibelffile
-Ilibprofile -Isigchainlib -I/usr/include/android
-Itools/cpp-define-generator -Idebian/out runtime/compiler_filter.cc
In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:22:
In file included from runtime/base/locks.h:25:
In file included from libartbase/base/atomic.h:27:
In file included from libartbase/base/macros.h:24:
/usr/include/android/android-base/thread_annotations.h:139:42: error:
'acquire_capability' attribute requires arguments whose type is
annotated with 'capability' attribute; type here is 'std::mutex'
[-Werror,-Wthread-safety-attributes]
ScopedLockAssertion(std::mutex& mutex) ACQUIRE(mutex) {}
^
/usr/include/android/android-base/thread_annotations.h:57:37: note:
expanded from macro 'ACQUIRE'
THREAD_ANNOTATION_ATTRIBUTE__(acquire_capability(__VA_ARGS__))
^
In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:23:
libartbase/base/mem_map.h:71:35: error: 'requires_capability' attribute
requires arguments whose type is annotated with 'capability' attribute;
type here is 'bool' [-Werror,-Wthread-safety-attributes]
MemMap(MemMap&& other) noexcept REQUIRES(!MemMap::mem_maps_lock_);
^
/usr/include/android/android-base/thread_annotations.h:51:37: note:
expanded from macro 'REQUIRES'
A full build log is available here:
https://salsa.debian.org/android-tools-team/android-platform-art/-/jobs/1274438
Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
Thanks for jumping in Roger! I reviewed it with cdesai, and we thought those libraries were not used on the "host" version, only when built as part of Android OS. I do think libfec would be useful if someone wants to package adbd for Debian. The Google Android Tools builds do not include adbd for the host, only for the Android OS. Right now, the only blocker I know about is the assembler code in android-platform-art, which Michel and I are working on now.
Bug#976718: [Android-tools-devel] Bug#976718: fastboot is completely broken
Control: severity -1 normal Control: retitle -1 fastboot 10.0.0+r36 not buildable There is a chance that fastboot won't make it into Bullseye, even though the rest of android-platform-system-core will. In that case, fastboot would be removed entirely. This script is a migration helper, so I'm downgrading the severity. If fastboot is important to you, we welcome contributions!
Bug#976109: [Pkg-xen-devel] Bug#976109: xen: CVE-2020-29040
Hi, On 11/29/20 8:50 PM, Salvatore Bonaccorso wrote: > Source: xen > Version: 4.14.0+80-gd101b417b7-1 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for xen. > > CVE-2020-29040[0]: > | An issue was discovered in Xen through 4.14.x allowing x86 HVM guest > | OS users to cause a denial of service (stack corruption), cause a data > | leak, or possibly gain privileges because of an off-by-one error. > | NOTE: this issue is caused by an incorrect fix for CVE-2020-27671. Yes, there's also a limited number of cases in which this is possible, and you just left that text out, which makes it sound a lot more horrible: "Only x86 HVM guests which have physical devices passed through to them can leverage the vulnerability.". I suspect that if anyone today is using Debian testing to run Xen and also is passing through devices is doing that to test performance use cases and not to untrusted guests. > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. Yes, it will off course be included in next upload. Hans
Bug#966912: fixed in 1:10.0.0+r36-1
Control: fixed -1 1:10.0.0+r36-1 Oops, forgot to mark it in the changelog
Bug#968965: [Pkg-xen-devel] Bug#968965: xen: FTBFS woes in sid
On 11/20/20 8:02 PM, Hans van Kranenburg wrote: > So, > > On 9/21/20 4:16 PM, Hans van Kranenburg wrote: >> [...] >> > [...] > >8 > > dh_install: warning: Cannot find (any matches for) > "usr/lib/debug/usr/lib/xen-*/boot/*" (tried in ., debian/tmp) > > dh_install: warning: xen-utils-4.14 missing files: > usr/lib/debug/usr/lib/xen-*/boot/* > dh_install: error: missing files, aborting > > >8 > > I can only find CONFIG_PV_SHIM=n in the build log. What is going on > here? Attached is the build log. Ok, this probably has something to do with upstream commit 8845155c83 "pvshim: make PV shim build selectable from configure" (Xen 4.12) which causes the shim not to be built during our i386 build any more. In Xen 4.11 we have commit a516bddbd3 "tools/firmware/Makefile: CONFIG_PV_SHIM: enable only on x86_64". The part of this file that this patch changes is removed in the above mentioned commit. Because all of this is such a big mess, I just tried to revert 8845155c83 and then do 0b898ccc2 and a516bddbd3 on top of the previous code again. And, yes, now it goes through, and ./usr/lib/xen-4.14/boot/xen-shim is included in the i386 package. At least we have a workaround now. > My WIP branch is here (including the make-patches commit, it's ready to > build). I also forwarded the thing to latest stable-4.14. Again at: > https://salsa.debian.org/xen-team/debian-xen/-/commits/knorrie/4.14/ I'll rerun both the amd64 and i386 build here and actually boot the amd64 packages in a test environment. If success, then I'm going to try put this in experimental again so we can see if it all succeeds on the buildds. Then after final review we should be able to upload to unstable beginning next week. K
Bug#968965: xen: FTBFS woes in sid
On 11/21/20 5:40 AM, Elliott Mitchell wrote:
> On Fri, Nov 20, 2020 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>> So,
>>
>> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
>>> [...]
>>>
>>> gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname
>>> -Wl,libxentoolcore.so.1 -shared -Wl,--version-script=libxentoolcore.map
>>> -o libxentoolcore.so.1.0 handlereg.opic
>>> /usr/bin/ld: i386:x86-64 architecture of input file `handlereg.opic' is
>>> incompatible with i386 output
>>> /usr/bin/ld: handlereg.opic: file class ELFCLASS64 incompatible with
>>> ELFCLASS32
>>> /usr/bin/ld: final link failed: file in wrong format
>>> collect2: error: ld returned 1 exit status
>>
>> This one is caused by "debian/rules: Combine shared Make args". I
>> reverted that change for now.
>>
>> [...]
>
> I was going to type, "That can't be true! Both sections are identical,
> so that commit *couldn't* have done it!"
>
> Being the careful sort, look closer. Look closer. Then realize if one
> reads fast they look identical, but they're getting *slightly* different
> values for ${XEN_TARGET_ARCH}. Mainly for $(make_args_xen),
> ${XEN_TARGET_ARCH} gets $(xen_arch_$(flavour)), but for
> $(make_args_tools), ${XEN_TARGET_ARCH} gets $(xen_arch_$(DEB_HOST_ARCH)).
>
> Three of us and we didn't spot that difference. Should still combine
> ${XEN_COMPILE_ARCH} which remains identical for both values.
Ok, I will make it a partial revert and add the above information about it.
Thanks.
Hans
Bug#972041: not a showstopper
Control: severity -1 normal I don't think packages should be kicked of testing for this issue since things are working. We will update as needed if the ABI in question changes in future updates.
Bug#959904: marked as pending in android-platform-system-tools-hidl
Control: tag -1 pending Hello, Bug #959904 in android-platform-system-tools-hidl 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/android-tools-team/android-platform-system-tools-hidl/-/commit/df6aa1b8a65011b9161b8230709fa65bbf17b944 Correct patches to resolve FTBFS Bug (Closes: #959904) (this message was generated automatically) -- Greetings https://bugs.debian.org/959904
Bug#968965: [Pkg-xen-devel] Bug#968965: Bug#968965: xen: FTBFS in sid
notfixed -1 xen/4.14.0-1~exp1 reopen found -1 xen/4.14.0-1~exp1 thanks Hi, On 9/4/20 1:55 PM, Hans van Kranenburg wrote: > > On 8/24/20 7:03 PM, Gianfranco Costamagna wrote: >> Source: xen >> Version: 4.11.4+24-gddaaccbbab-1 >> Severity: serious >> >> Hello, looks like xen is FTBFS because of some bd-uninstallable python >> package and a gcc-10 related build failure. > > [...] Well, it seems we have more FTBFS, let's reuse this bug number to track it again? https://buildd.debian.org/status/package.php?p=xen&suite=experimental --->8--- arm64 --->8--- gcc -MMD -MP -MF ./.mem_access.o.d -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -Wvla -pipe -D__XEN__ -include /<>/xen/include/xen/config.h -Wa,--strip-local-absolute -mcpu=generic -mgeneral-regs-only -I/<>/xen/include -fno-stack-protector -fno-exceptions -fno-asynchronous-unwind-tables -fcf-protection=none -Wnested-externs '-D__OBJECT_FILE__="mem_access.o"' -c mem_access.c -o mem_access.o mem_access.c: In function ‘p2m_mem_access_check’: mem_access.c:227:6: note: parameter passing for argument of type ‘const struct npfec’ changed in GCC 9.1 227 | bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec) | ^~~~ --->8--- armhf --->8--- gcc -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MP -MF .xenpmd.o.d -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Werror -I/<>/tools/xenpmd/../../tools/xenstore/include -I/<>/tools/xenpmd/../../tools/include -c -o xenpmd.o xenpmd.c xenpmd.c: In function ‘get_next_battery_file’: xenpmd.c:92:37: error: ‘%s’ directive output may be truncated writing between 4 and 2147483645 bytes into a region of size 271 [-Werror=format-truncation=] 92 | #define BATTERY_STATE_FILE_PATH "/tmp/battery/%s/state" | ^~~ xenpmd.c:117:52: note: in expansion of macro ‘BATTERY_STATE_FILE_PATH’ 117 | snprintf(file_name, sizeof(file_name), BATTERY_STATE_FILE_PATH, | ^~~ xenpmd.c:92:51: note: format string is defined here 92 | #define BATTERY_STATE_FILE_PATH "/tmp/battery/%s/state" | ^~ In file included from /usr/include/stdio.h:867, from xenpmd.c:35: /usr/include/arm-linux-gnueabihf/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 24 and 2147483665 bytes into a destination of size 284 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~ 68 |__bos (__s), __fmt, __va_arg_pack ()); |~ xenpmd.c:91:36: error: ‘%s’ directive output may be truncated writing between 4 and 2147483645 bytes into a region of size 271 [-Werror=format-truncation=] 91 | #define BATTERY_INFO_FILE_PATH "/tmp/battery/%s/info" |^~ xenpmd.c:114:52: note: in expansion of macro ‘BATTERY_INFO_FILE_PATH’ 114 | snprintf(file_name, sizeof(file_name), BATTERY_INFO_FILE_PATH, | ^~ xenpmd.c:91:50: note: format string is defined here 91 | #define BATTERY_INFO_FILE_PATH "/tmp/battery/%s/info" | ^~ In file included from /usr/include/stdio.h:867, from xenpmd.c:35: /usr/include/arm-linux-gnueabihf/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 23 and 2147483664 bytes into a destination of size 284 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~ 68 |__bos (__s), __fmt, __va_arg_pack ()); |~ --->8--- i386 --->8--- gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname -Wl,libxentoolcore.so.1 -shared -Wl,--version-script=libxentoolcore.map -o libxentoolcore.so.1.0 handlereg.opic /usr/bin/ld: i386:x86-64 architecture of input file `handlereg.opic' is incompatible with i386 output /usr/bin/ld: handlereg.opic: file class ELFCLASS64 incompatible with ELFCLASS32 /usr/bin/ld: final link failed: file in wrong format collect2: error: ld returned 1 exit status Hans
Bug#968965: [Pkg-xen-devel] Bug#968965: xen: FTBFS in sid
make[5]: *** [/build/xen-4.11.4+24-gddaaccbbab/tools/../tools/Rules.mk:253: > subdir-install-xenstore] Error 2 > make[5]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools' > make[4]: *** [/build/xen-4.11.4+24-gddaaccbbab/tools/../tools/Rules.mk:248: > subdirs-install] Error 2 > make[4]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools' > make[3]: *** [Makefile:74: install] Error 2 > make[3]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools' > make[2]: *** [Makefile:127: install-tools] Error 2 > make[2]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab' > make[1]: *** [debian/rules:202: override_dh_auto_build] Error 2 > make[1]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab' > make: *** [debian/rules:150: build] Error 2 > dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > I: copying local configuration Hans
Bug#951246: genetic: build-depends on non-existing package
Hello genetic build-depends on python3-multiprocess, which does not exist in the archive. Looks like this is now available as part of https://tracker.debian.org/pkg/multiprocess So I suppose the only thing now holding back genetic is a missing source-only upload. -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#966071: FTBFS: tests require network access
Source: python-email-validator
Version: 1.1.1-2
Severity: serious
Tags: ftbfs
Dear Maintainer,
When attempting to build python-email-validator 1.1.1-2 locally, it
fails with the following test failures:
tests/test_main.py ...FFF.
[100%]
=== FAILURES
===
test_deliverability_no_records
def test_deliverability_no_records():
assert validate_email_deliverability('example.com',
'example.com') == {'mx': [(0, '')], 'mx-fallback': None}
E AssertionError: assert {'unknown-del...y': 'timeout'} == {'mx':
[(0, ''...llback': None}
E Left contains 1 more item:
E {'unknown-deliverability': 'timeout'}
E Right contains 2 more items:
E {'mx': [(0, '')], 'mx-fallback': None}
E Use -v to get the full diff
tests/test_main.py:254: AssertionError
__ test_deliverability_found
___
def test_deliverability_found():
response = validate_email_deliverability('gmail.com',
'gmail.com')
assert response.keys() == {'mx', 'mx-fallback'}
E AssertionError: assert dict_keys(['u...iverability']) == {'mx',
'mx-fallback'}
E Use -v to get the full diff
tests/test_main.py:259: AssertionError
__ test_deliverability_fails
___
def test_deliverability_fails():
domain = 'xkxufoekjvjfjeodlfmdfjcu.com'
with pytest.raises(EmailUndeliverableError, match='The domain
name {} does not exist'.format(domain)):
validate_email_deliverability(domain, domain)
E Failed: DID NOT RAISE 'email_validator.EmailUndeliverableError'>
tests/test_main.py:270: Failed
= 3 failed, 44 passed in 45.39 seconds
=
Based on the error messages, it looks like these tests require
network access.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-1-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64
Hi, On Wed, 15 Jul 2020 20:52:40 -0700 Sarah Newman wrote: > On 7/7/20 8:13 PM, Ben Hutchings wrote: > > Control: reassign -1 src:linux > > Control: tag -1 moreinfo > > > > On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote: > >> Package: linux-signed-amd64 > >> Version: 4.19.0-9-amd64 > >> > >> We've had two separate reports now of debian buster users running > >> 4.19.0-9-amd64 who experienced serious file system corruption. > > > > Which version? (I.e. what does "uname -v" or > > "dpkg -s linux-image-4.19.0-9-amd64" say?) > > > >> - Both were using ext3 > >> - Both are running Xen HVM, but I do not have reason to believe this to be > >> related > > [...] I have servers which run 4.19.118-2 as dom0 kernel and a Xen 4.11.4-1 rebuild for Buster. One example is a smallish 6-server cluster that got a reboot cycle 48 days ago. It contains a few heavily loaded domUs with 4.19.118 or 4.19.131 based kernels. No problems or disk corruption or anything is seen yet. dom0 filesystem is ext4, domUs use a mix of ext4 and btrfs (over iscsi). So, no ext3 anywhere. We haven't got bug reports against Debian Xen packages in the BTS about this. I have not yet tried to make an ext3 fs on a block device in a test domU and then have it do things with the fs and reboot it now and then. If wanted, I can do that and see if there's any problem after a week or two. Just to add chaos to help correlating. FWIW, Hans
Bug#961702: git breaks fdroidserver autopkgtest: Failed to parse line: ' git config pull.rebase false
Control: notfound -1 fdroidserver/1.1.7-1
Control: found -1 python3-git/3.1.1-1
I can't find any possible reference in fdroidserver, or in python3-git
for that matter. My guess is that the issue is caused by python3-git
failing to parse something that was added in the most recent git. So
I'm reassigning this to python3-git since the stacktrace shows the issue
happening pretty deep inside python3-git, and the fdroidserver code does
not call `git config` in anyway that I can figure out.
Paul Gevers:
> Source: git, fdroidserver
> Control: found -1 git/1:2.27.0~rc2-1
> Control: found -1 fdroidserver/1.1.7-1
> 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 git the autopkgtest of fdroidserver fails in
> testing when that autopkgtest is run with the binary packages of git
> from unstable. It passes when run with only packages from testing. In
> tabular form:
>
>passfail
> gitfrom testing1:2.27.0~rc2-1
> fdroidserver from testing1.1.7-1
> 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 git 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?
>
> 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=git
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fdroidserver/5667747/log.gz
>
> CRITICAL: Unknown exception found!
> Traceback (most recent call last):
> File "/usr/bin/fdroid", line 170, in
> main()
> File "/usr/bin/fdroid", line 165, in main
> raise e
> File "/usr/bin/fdroid", line 146, in main
> mod.main()
> File "/usr/lib/python3/dist-packages/fdroidserver/server.py", line
> 759, in main
> push_binary_transparency(BINARY_TRANSPARENCY_DIR,
> File "/usr/lib/python3/dist-packages/fdroidserver/server.py", line
> 584, in push_binary_transparency
> local.pull('master')
> File "/usr/lib/python3/dist-packages/git/remote.py", line 812, in pull
> res = self._get_fetch_info_from_stderr(proc, progress)
> File "/usr/lib/python3/dist-packages/git/remote.py", line 708, in
> _get_fetch_info_from_stderr
> output.extend(FetchInfo._from_line(self.repo, err_line, fetch_line)
> File "/usr/lib/python3/dist-packages/git/remote.py", line 708, in
>
> output.extend(FetchInfo._from_line(self.repo, err_line, fetch_line)
> File "/usr/lib/python3/dist-packages/git/remote.py", line 292, in
> _from_line
> raise ValueError("Failed to parse line: %r" % line)
> ValueError: Failed to parse line: ' git config pull.rebase false #
> merge (the default strategy)'
>
Bug#961088: bug confirmed
Hi, I have the same problem with an HP Officejet 7310 AIO: sane-find-scanner reports: "found USB scanner (vendor=0x03f0 [HP], product=0x4211 [Officejet 7300 series]) at libusb:002:012" but "scanimage -L" fails: "No scanners were identified." Unfortunately, I wasn't able to downgrade to 3.20.3+dfsg0-2. There are (too) many dependencies, and I couldn't find the 3.20.3 packages on the Debian servers). A fix or a workaround would be very much appreciated. Regards and thanks for your efforts, HG
Bug#955695: 1.5.2 has different error
I'm trying to build Manas Kashyap's 1.5.2 update, and got a different error. And gradle/wrapper/gradle-wrapper.properties says gradle 5.2.1, so it looks like they might have added some new gradle tricks Included projects: [root project 'com.ibm.wala', project ':com.ibm.wala-repository', project ':com.ibm.wala.cast', project ':com.ibm.wala.cast.java', project ':com.ibm.wala.cast.test', project ':com.ibm.wala.core', project ':com.ibm.wala.dalvik', project ':com.ibm.wala.scandroid', project ':com.ibm.wala.shrike', project ':com.ibm.wala.tests.ide_feature', project ':com.ibm.wala.tests_feature', project ':com.ibm.wala.util', project ':com.ibm.wala_feature', project ':com.ibm.wala.cast.test:smoke_main', project ':com.ibm.wala.cast.test:xlator_test', project ':com.ibm.wala.cast:cast'] Keep-alive timer started Adding Debian repository to project 'com.ibm.wala' Adding Debian repository to project 'com.ibm.wala-repository' Adding Debian repository to project 'com.ibm.wala.cast' Adding Debian repository to project 'com.ibm.wala.cast.java' Adding Debian repository to project 'com.ibm.wala.cast.test' Adding Debian repository to project 'com.ibm.wala.core' Adding Debian repository to project 'com.ibm.wala.dalvik' Adding Debian repository to project 'com.ibm.wala.scandroid' Adding Debian repository to project 'com.ibm.wala.shrike' Adding Debian repository to project 'com.ibm.wala.tests.ide_feature' Adding Debian repository to project 'com.ibm.wala.tests_feature' Adding Debian repository to project 'com.ibm.wala.util' Adding Debian repository to project 'com.ibm.wala_feature' Adding Debian repository to project 'smoke_main' Adding Debian repository to project 'xlator_test' Adding Debian repository to project 'cast' Evaluating root project 'com.ibm.wala' using build file '/build/wala-1.5.2/build.gradle'. Compiling build file '/build/wala-1.5.2/build.gradle' using SubsetScriptTransformer. Compiling build file '/build/wala-1.5.2/build.gradle' using BuildScriptTransformer. FAILURE: Build failed with an exception. * Where: Build file '/build/wala-1.5.2/build.gradle' line: 35 * What went wrong: A problem occurred evaluating root project 'com.ibm.wala'. > Could not find method named() for arguments [test] on task set of type org.gradle.api.internal.tasks.DefaultTaskContainer.
Bug#955695: probably because of libsmali-java update from 2.3.3 to 2.4
My guess is that this issue was caused by the libsmali-java update from 2.3.3 to 2.4. Hopefuilly its a small fix.
Bug#938108: [Pkg-xen-devel] Bug#938108: python-pyxenstore: Python2 removal in sid/bullseye
On 5/9/20 9:57 PM, Moritz Mühlenhoff wrote: > On Sat, May 09, 2020 at 02:36:24AM +0200, Thomas Goirand wrote: >> On 5/8/20 9:35 PM, Moritz Mühlenhoff wrote: >>> On Fri, Aug 30, 2019 at 07:45:40AM +, Matthias Klose wrote: >>>> Package: src:python-pyxenstore >>>> Version: 0.0.2-1 >>>> Severity: normal >>>> Tags: sid bullseye >>>> User: debian-pyt...@lists.debian.org >>>> Usertags: py2removal >>>> >>>> Python2 becomes end-of-live upstream, and Debian aims to remove >>>> Python2 from the distribution, as discussed in >>>> https://lists.debian.org/debian-python/2019/07/msg00080.html >>>> >>>> Your package either build-depends, depends on Python2, or uses Python2 >>>> in the autopkg tests. Please stop using Python2, and fix this issue >>>> by one of the following actions. >>> >>> Hi, >>> python-pyxenstore is dead upstream and there are no reverse deps, let's >>> remove? >>> >>> Cheers, >>> Moritz >> >> By all means, yes, remove this. >> I believe it is in Debian when I attempted to package XCP (aka: xen-api, >> aka xen-server, etc.), and that's long gone from Debian. > > Ack, I've just filed an RM bug. (seeing it happening) Also ACK from me. A while ago this confused me because I initially thought this was a binary package produced by src:xen, but it was not. At some point (I think it was our latest IRL work together day of the Debian Xen team) I realized that it really was not, and from that POV, I can confirm that it is not used by anything in there. Thanks, Hans
Bug#960125: closing 960125
Ah, I saw the other bug report but didn't look too much into it since it had a different error message. So I missed the date it was fixed and tested with the previous cmake version locally. Now that cmake is updated, it builds as expected. Sorry about the noise :) --- mvh / best regards Hans Joachim Desserud http://desserud.org Den 2020-05-09 21:24, skrev Jochen Sprickerhof: # done by fixing #959064 in cmake close 960125 thanks
Bug#960126: FTBFS: No cached version of :osmosis-core-0.47.2: available for offline mode.
Source: mapsforge Version: 0.13.0+dfsg.1-2 Severity: serious Tags: ftbfs Dear Maintainer, mapsforge 0.13.0+dfsg.1-2 currently fails to build: All input files are considered out-of-date for incremental task ':mapsforge-map:compileJava'. Compiling with JDK Java compiler API. :mapsforge-poi:compileJava (Thread[Task worker for ':' Thread 10,5,main]) completed. Took 0.717 secs. :mapsforge-map:compileJava (Thread[Task worker for ':' Thread 3,5,main]) completed. Took 2.081 secs. FAILURE: Build failed with an exception. * What went wrong: Could not resolve all files for configuration ':mapsforge-map-writer:compileClasspath'. Could not resolve :osmosis-core-0.47.2:. Required by: project :mapsforge-map-writer > No cached version of :osmosis-core-0.47.2: available for offline mode. > No cached version of :osmosis-core-0.47.2: available for offline mode. > No cached version of :osmosis-core-0.47.2: available for offline mode. For more details see https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mapsforge.html I suppose it fails to find the osmosis jars now that it has been updated to 0.48.0-1. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#960125: Subject: FTBFS: collect2: error: ld returned 1 exit status
Source: ignition-transport Version: 8.0.0+dfsg-3 Severity: serious Tags: ftbfs Dear Maintainer, ignition-transport 8.0.0+dfsg-3 currently fails to build: Run Build Command(s):/usr/bin/make cmTC_64ca3/fast && make[2]: Entering directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' /usr/bin/make -f CMakeFiles/cmTC_64ca3.dir/build.make CMakeFiles/cmTC_64ca3.dir/build make[3]: Entering directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_64ca3.dir/src.c.o /usr/bin/cc -g -O2 -ffile-prefix-map=/build/1st/ignition-transport-8.0.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCMAKE_HAVE_LIBC_PTHREAD -o CMakeFiles/cmTC_64ca3.dir/src.c.o -c /build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c Linking C executable cmTC_64ca3 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_64ca3.dir/link.txt --verbose=1 /usr/bin/cc -g -O2 -ffile-prefix-map=/build/1st/ignition-transport-8.0.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCMAKE_HAVE_LIBC_PTHREAD -Wl,-z,relro -Wl,-z,now CMakeFiles/cmTC_64ca3.dir/src.c.o -o cmTC_64ca3 /usr/bin/ld: CMakeFiles/cmTC_64ca3.dir/src.c.o: in function `main': ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create' /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:12: undefined reference to `pthread_detach' /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:13: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/cmTC_64ca3.dir/build.make:87: cmTC_64ca3] Error 1 make[3]: Leaving directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' make[2]: *** [Makefile:121: cmTC_64ca3/fast] Error 2 make[2]: Leaving directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' See also https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ignition-transport.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#936790: keysync: Python2 removal in sid/bullseye
Moritz Mühlenhoff: > On Fri, Aug 30, 2019 at 07:22:02AM +, Matthias Klose wrote: >> Package: src:keysync >> Version: 0.2.2-2 >> Severity: normal >> Tags: sid bullseye >> User: debian-pyt...@lists.debian.org >> Usertags: py2removal >> >> Python2 becomes end-of-live upstream, and Debian aims to remove >> Python2 from the distribution, as discussed in >> https://lists.debian.org/debian-python/2019/07/msg00080.html >> >> Your package either build-depends, depends on Python2, or uses Python2 >> in the autopkg tests. Please stop using Python2, and fix this issue >> by one of the following actions. > > There's no update at https://dev.guardianproject.info/issues/2478.html > at all, let's remove keysync? Works for me. .hc
Bug#951925: flare-engine FTBFS: Could NOT find SDL2
Fwiw, https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/flare-engine.html seems to build successfully. I'm don't see this build failure on my local Sid system either. Maybe it got resolved after library changes in the meantime? -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#954395: binfmt went away
Control: severity -1 important This is most likely due to binfmt support being removed from the autopkgtest runner. Java CLI executables require the Linux binfmt_misc kernel module to be loaded for a .JAR to find the java executable.
Bug#894284: blocked by Kotlin
Once kotlin is in Debian, then we can use newer upstream versions, which support the latest JDK.
Bug#953818: python-paver: should this package be removed?
Please remove! Sandro Tosi: > Package: python-paver > Severity: serious > > Hello, > i believe this package should be removed: > > * python2-only > * while upstream has released a py3k compatible version (and several others in > between the one in the archive), the debian maintainer didnt upload this > package since late 2013 > * no rdeps > * extremely low popcon > > if i dont hear back within a week to keep this package, i'll file for its > removal. > > Regards, > Sandro > > -- System Information: > Debian Release: 10.0 > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages python-paver depends on: > ii libjs-jquery 3.3.1~dfsg-3 > ii python2.7.16-1 > > python-paver recommends no packages. > > python-paver suggests no packages. >
Bug#951281: FTBFS: /usr/bin/ld: cannot find -lpthreads
Source: widelands Version: 1:20-1 Severity: serious Justification: ftbfs Tags: ftbfs Dear Maintainer, Widelands currently fails to build in Sid with the following error message: ... /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_893c8.dir/link.txt --verbose=1 /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/widelands-20=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create -Wl,-z,relro -rdynamic CMakeFiles/cmTC_893c8.dir/CheckFunctionExists.c.o -o cmTC_893c8 -lpthreads /usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/cmTC_893c8.dir/build.make:87: cmTC_893c8] Error 1 make[3]: Leaving directory '/build/widelands-20/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' make[2]: *** [Makefile:121: cmTC_893c8/fast] Error 2 make[2]: Leaving directory '/build/widelands-20/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DWL_INSTALL_BASEDIR=/usr/share/games/widelands -DWL_INSTALL_BINDIR=games -DWL_INSTALL_DATADIR=/usr/share/games/widelands/data -DWL_INSTALL_PREFIX=/usr -DOPTION_BUILD_WEBSITE_TOOLS=OFF -DCMAKE_BUILD_TYPE=Release .. returned exit code 1 make[1]: *** [debian/rules:14: override_dh_auto_configure] Error 25 make[1]: Leaving directory '/build/widelands-20' make: *** [debian/rules:10: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I suspect the important part is "/usr/bin/ld: cannot find -lpthreads", which I suppose might be due to some underlying library change though I haven't figured it out. Saw the same error message when the package was rebuilt in Ubuntu, and I guess other packages using -lpthreads might suffer the same fate. Tried rebuilding the current upstream development version to see if it had a fix, but ran into a separate issue. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#950937: hw-probe: FTBFS due to missing build dependency help2man
Package: hw-probe Version: 1.4-1 Severity: serious Tags: ftbfs Dear Maintainer, hw-probe currently fails to build with the following error message: debian/rules override_dh_installdocs make[1]: Entering directory '/build/hw-probe-1.4' help2man --include=debian/hw-probe.1.in --output=debian/hw-probe.1 --no-info debian/hw-probe/usr/bin/hw-probe make[1]: help2man: Command not found After adding help2man to the list of build dependencies, it built successfully. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hw-probe depends on: pn acpica-tools pn curl ii dmidecode 3.2-3 ii hdparm 9.58+ds-4 pn hwinfo ii libwww-perl6.43-1 ii lm-sensors 1:3.6.0-2 ii lsb-release11.1.0 ii mesa-utils 8.4.0-1+b1 ii pciutils 1:3.6.4-1 ii perl [libdigest-sha-perl] 5.30.0-9 ii perl-base 5.30.0-9 pn smartmontools ii usbutils 1:012-2 ii x11-utils 7.7+4 Versions of packages hw-probe recommends: ii alsa-utils 1.2.1-1 pn cpuid pn edid-decode pn ethtool ii fdisk 2.34-0.1 pn i2c-tools ii iw 5.4-1 pn mcelog pn memtester pn pnputils pn sysstat ii upower 0.99.11-1 pn vainfo pn vdpauinfo pn vulkan-utils ii wireless-tools 30~pre9-13+b1 ii x11-xserver-utils 7.7+8 pn xinput hw-probe suggests no packages. -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#950911: FTBFS: missing build-dependency python3-nose
Source: python-deeptools Version: 3.3.2+ds-1 Severity: serious Tags: ftbfs Dear Maintainer, python-deeptools currently fails to build with the following error message: debian/rules override_dh_auto_test make[1]: Entering directory '/build/python-deeptools-3.3.2+ds' PYTHONPATH=/build/python-deeptools-3.3.2+ds nosetests3 -x -v -s deeptools /bin/sh: 1: nosetests3: not found After adding `python3-nose` to build-dependencies, it built successfully. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#947944: xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-20
On 1/7/20 11:34 PM, Hans van Kranenburg wrote: > [...] > > Today I have finally been working on this. The result is that I at least > have a new (WIP) version for buster. I'm running it on a dom0 right now > and did smoke testing, live migrate, restarting domUs etc. It just works > (tm). > > This was the easy part, most of the work was assembling the changelog by > copy-pasting things. I cross-checked with your list (below), which is > nice, since we can check that way that the info from different points of > view is the same (except for one entry it is). > > https://salsa.debian.org/xen-team/debian-xen/commits/knorrie/buster-security > > Now the interesting part begins, which is not so much about the stable > security update, but more about what to do with unstable. We currently > still have the same Xen version in unstable and in Buster. > > So, the most logical thing, which I mentioned before would be to have > 4.11.3+24-g14b62ab3e5-1 in unstable and 4.11.3+24-g14b62ab3e5-1~deb10u1 > in stable. Ok, this will just be ok, since I was confused about the python-pyxenstore package, and thought it was a by-product from our src:xen. This is not the case, it's a separate thing. So, false alarm. > [...] That means that the original plan will suffice for now. The whole python2 situation will be resolved when we prepare Xen 4.13 or 4.14, or whichever one will be the Bullseye one. The result: https://salsa.debian.org/xen-team/debian-xen/tree/knorrie/unstable https://salsa.debian.org/xen-team/debian-xen/tree/knorrie/buster-security I just built and tested both of the resulting piles of packages, on buster and on a bullseye dom0. All looks fine, I can live migrate, restart things etc etc... So, next step is getting things uploaded to the right place. Hans
Bug#947944: xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-20
Hi, Today I have finally been working on this. The result is that I at least have a new (WIP) version for buster. I'm running it on a dom0 right now and did smoke testing, live migrate, restarting domUs etc. It just works (tm). This was the easy part, most of the work was assembling the changelog by copy-pasting things. I cross-checked with your list (below), which is nice, since we can check that way that the info from different points of view is the same (except for one entry it is). https://salsa.debian.org/xen-team/debian-xen/commits/knorrie/buster-security Now the interesting part begins, which is not so much about the stable security update, but more about what to do with unstable. We currently still have the same Xen version in unstable and in Buster. So, the most logical thing, which I mentioned before would be to have 4.11.3+24-g14b62ab3e5-1 in unstable and 4.11.3+24-g14b62ab3e5-1~deb10u1 in stable. However... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938843 And on Dec 15, python-pyxenstore REMOVED from testing So, I guess we're not supposed to upload something new to unstable that includes this package again and/or uses python 2. Also, we of course do not like a situation where the package in stable has a newer version number than the one in unstable. Checkmate... We (as in, Debian Xen team, which is Ian and I who are currently active) haven't been working on getting the latest greatest Xen into unstable for Bullseye yet. The most recent Xen release (4.13) includes python3 support which fixes that issue, but getting that in means we have to actively start working on newer packages now. This mostly means reserving a few days to work on it, since it's not a really trivial undertaking. Another ducttape-option is to put the same thing in unstable again, while stripping out python-pyxenstore from the control file, since it's not a required package for the average usecase. Still, xen-utils-4.11 contains a bunch of python 2 files, which apparently are still under the radar. I'm thinking out loud here, and am curious about what you and Ian can come up with. On 1/2/20 3:57 PM, Salvatore Bonaccorso wrote: > [...] > > There are several CVEs open for xen up to unstable, compiling a list > from the information from the security-tracker it looks those below. > > Any progress in getting those fixed at least for unstable already? > > CVE-2018-12207[0]: check, XSA-304 > CVE-2019-11135[1]: check, XAS-305 > CVE-2019-18420[2]: check, XSA-296 > CVE-2019-18421[3]: check, XSA-299 > CVE-2019-18422[4]: check, XSA-303 > CVE-2019-18423[5]: check, XSA-301 > CVE-2019-18424[6]: check, XSA-302 > CVE-2019-18425[7]: check, XSA-298 > CVE-2019-19577[8]: check, XSA-311 > CVE-2019-19578[9]: check, XSA-309 > CVE-2019-19579[10]: check, XSA-306 > CVE-2019-19580[11]: check, XSA-310 > CVE-2019-19581[12]: check, XSA-307 > CVE-2019-19582[13]: check, XSA-307 > CVE-2019-19583[14]: check, XSA-308 In the changelog, I also have a fix for: XSA-295 CVE-2019-17349 CVE-2019-17350 https://xenbits.xen.org/xsa/advisory-295.html > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. I also added a commit to put in the CVE numbers in previous changelog entries: https://salsa.debian.org/xen-team/debian-xen/commit/0ee295f5caf6178f64febeb976d7ea968e44a191 Is this ok/wanted/great/what-you-like? Because, regularly, the numbers are not available yet when we push out the update. Thanks, Hans van Kranenburg
Bug#944898: FTBFS: missing build-dependency python3-setuptools-scm
Source: python-dnaio
Version: 0.4-1
Severity: serious
Dear Maintainer,
python-dnaio currently fails to build from source with the following
error message:
No local packages or working download links found for setuptools_scm
Traceback (most recent call last):
File "setup.py", line 86, in
"Topic :: Scientific/Engineering :: Bio-Informatics"
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
144, in setup
_install_setup_requires(attrs)
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
139, in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 720, in
fetch_build_eggs
replace_conflicting=True,
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
782, in resolve
replace_conflicting=replace_conflicting
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1065, in best_match
return self.obtain(req, installer)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1077, in obtain
return installer(requirement)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 787, in
fetch_build_egg
return cmd.easy_install(req)
File
"/usr/lib/python3/dist-packages/setuptools/command/easy_install.py",
line 698, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution
for Requirement.parse('setuptools_scm')
E: pybuild pybuild:341: clean: plugin distutils failed with: exit
code=1: python3.7 setup.py clean
(see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-dnaio.html
for more details)
After adding `python3-setuptools-scm` to build-depdendencies it built
successfully in pbuilder on my local system.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-2-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 50b63d5..703ce98 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: debhelper-compat (= 12),
python3,
python3-dev,
python3-setuptools,
+ python3-setuptools-scm,
python3-pytest,
python3-xopen,
cython3
Bug#932311: python-geneimpacts: FTBFS missing dependency to run testsuite
Source: python-geneimpacts
Version: FTBFS missing dependency to run testsuite
Severity: serious
Tags: patch
Dear Maintainer,
python-geneimpacts currently fails to build in Sid with the following
error message:
I: pybuild base:217: python3.7 setup.py test
running test
Searching for nose
Note: Bypassing https://pypi.org/simple/nose/ (disallowed host; see
http://bit.ly/2hrImnY for details).
Couldn't find index page for 'nose' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Note: Bypassing https://pypi.org/simple/ (disallowed host; see
http://bit.ly/2hrImnY for details).
No local packages or working download links found for nose
error: Could not find suitable distribution for
Requirement.parse('nose')
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1:
python3.7 setup.py test
Looks like this is due to python3-nose missing, it built successfully
after adding this dependency
(see the attached patch). I also took the liberty of adjusting the Salsa
links since the urls
they point to atm doesn't seem to work.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index bacbd05..6effc7a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,15 @@ Section: science
Priority: optional
Maintainer: Debian Med Packaging Team
Uploaders: Steffen Moeller
-Build-Depends: debhelper (>= 11), dh-python, python3-all, python3-setuptools
+Build-Depends: debhelper (>= 11),
+ dh-python,
+ python3-all,
+ python3-nose,
+ python3-setuptools
Standards-Version: 4.3.0
Homepage: https://github.com/brentp/geneimpacts
-Vcs-Browser: https://salsa.debian.org/med-team/geneimpacts
-Vcs-Git: https://salsa.debian.org/med-team/geneimpacts.git
+Vcs-Browser: https://salsa.debian.org/med-team/python-geneimpacts
+Vcs-Git: https://salsa.debian.org/med-team/python-geneimpacts.git
#Testsuite: autopkgtest-pkg-python
Package: python3-geneimpacts
Bug#932085: grub-common: Grub can't load initrd for Xen after upgrade to Buster
On 7/14/19 11:43 PM, Colin Watson wrote: > On Sun, Jul 14, 2019 at 01:27:23PM -0700, Slava Kryvel wrote: >> After upgrade from Debian 9.9 to Debian 10 I have got unbootable system. >> >> I'm using Xen hypervisor, which was also upgraded from 4.8 to 4.11 >> during OS upgrade. >> UEFI is enabled. >> >> After upgrade was finished, I was unable to boot again to Xen kernel. >> But normal Debian kernel was still bootable. > > [...] > > I'm CCing a few folks who've contributed to GRUB's Xen support in one > way or another in the recent past; hopefully at least one of them can > help here? Just to be transparent here, not all possible functionality is tested by the package maintainers (currently Ian and me) before throwing a new package into Debian. This is simply not practically feasible for us. [0] We rely on the upstream tests to know that the upstream Xen code will probably work. For Debian specific things, we do test our own use cases, but e.g. UEFI is not one of them. For this, we rely on active users to report problems and help solving them. So, yes, things like this can happen. Thanks for reporting this. Next step would be to follow Rogers instructions, and provide config dumps, serial console output etc... We're certainly available to include changes / etc to fix things, given proper information / testing reports from the user. But, the user has to actively help to make that happen. Hans van Kranenburg (with Debian Xen team hat on) [0] https://alioth-lists.debian.net/pipermail/pkg-xen-devel/2018-October/007438.html
Bug#929905: autoremoval of fdroidserver
Control: severity 929905 important Please keep it in buster, I would like to go the point release route.
Bug#929129: [Pkg-xen-devel] Bug#929129: closed by Hans van Kranenburg (Bug#929129: fixed in xen 4.11.1+92-g6c33308a8d-1)
On 6/19/19 4:43 PM, Wiebe Cazemier wrote: > This is an update to the unstable release. What is one running Debian > stable (9), with Xen Hypervisor 4.8, to do? This is not meant as a middle finger to users of stable. All of the bug numbers will be closed twice, also by the 4.8 upload, which also has to mention them. This is confusing, however the automated behaviour after uploading any of them is to close the bug with that report. At least the 4.11 is out now, last thing I heard about 4.8 was that there are issues compiling the current 4.8-stable upstream branch in Stretch, and that's quite an important prerequisite for continuing. :| Ian needs to work on that. I will see if I can manipulate them a bit. All the other ones mentioned in the changelog should also have the info that it's found in current version in stable attached to them, so that the version graph shows both. Hans
Bug#928727: FTBFS: ImportError: No module named twisted.python.failure
Source: python-tblib
Version: 1.4.0-1
Severity: serious
Tags: ftbfs
Dear Maintainer,
python-tblib currently fails to build from source with the following
error message:
ERRORS
___ ERROR collecting
.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py ___
tests/test_issue30.py:5: in
from twisted.python.failure import Failure
E ImportError: No module named twisted.python.failure
___ ERROR collecting
.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py ___
ImportError while importing test module
'/build/1st/python-tblib-1.4.0/.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python2.7/dist-packages/_pytest/python.py:450: in
_importtestmodule
mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python2.7/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
/usr/lib/python2.7/dist-packages/_pytest/assertion/rewrite.py:294: in
load_module
six.exec_(co, mod.__dict__)
/usr/lib/python2.7/dist-packages/six.py:709: in exec_
exec("""exec _code_ in _globs_, _locs_""")
:1: in
???
tests/test_issue30.py:5: in
from twisted.python.failure import Failure
E ImportError: No module named twisted.python.failure
(see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-tblib.html
for more details)
I got the same error message when attempting to build it on my Sid
system.
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#924591: this requires linking in libsparse, which is from Android sources
Theodore Ts'o: > On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote: >> Hans-Christoph Steiner: >>> Theodore Ts'o: >>>> So your choice --- we can either reassign this bug back to fastboot or >>>> android-sdk-platforms-tools, or I can downgrade the severity of this >>>> bug for e2fsprogs down to wishlist[1]. Let me know how you want to >>>> handle this. >>>> >>>> [1] This is because I view this both as a "feature request" and "bugs >>>> that are very difficult to fix due to major design considerations" >>>> (per https://www.debian.org/Bugs/Developer#severities), not to mention >>>> that it's going to affect a miniscule fraction of the e2fsprogs >>>> package's users. >>> >>> Makes sense to me. I'm fine with this being done post-Buster or as a >>> custom mke2fs in android-platform-system-core. >> >> So the bottom line here is that the ext4 formatting support in fastboot >> remains broken in Buster, right? That would be very unfortunate and a >> regression compared to Stretch. > > I'm not sure whether or not Stretch was using the old-style > make_ext4fs from AOSP, or was including the mke2fs from AOSP, but yes, > it sounds like it's a regression from stretch. I'm not sure how many > Debian users are using the Debian-native fastboot versus using the > version from the Google SDK or the AOSP binaries, though. > > It does seem that if this is considered high priority, the most > straightforward way to address this bug is going to be to include > building mke2fs from AOSP and placing it in > /usr/lib/android-sdk/platform-tools/mke2fs. I know some folks on the > android tools teams aren't excited with that approach, but that > probably is the best thing to do if you want to address this in > Buster. That approach sounds fine for buster. The only question in my mind is who will do the work... I don't really know how fastboot in stretch provided the mke2fs support, but judging by the dependencies, it might have been that fastboot used to do the formatting itself, based on being linked to android-libext4-utils and android-libsparse. The buster version of fastboot is clearly calling mk2efs, which in AOSP is built from an inline e2fsprogs fork. .hc
Bug#924591: this requires linking in libsparse, which is from Android sources
Theodore Ts'o: > On Thu, Apr 18, 2019 at 09:32:06PM +0200, Hans-Christoph Steiner wrote: >> >> One possibility would be including libsparse as a patch, it doesn't >> change a lot: >> https://android.googlesource.com/platform/system/core/+log/master/libsparse >> >> But it depends on Android's libbase and libz-host. > > This might be "serious" bug from the fastboot package's perspective, > but there's no way in heck the release time is going to consider this > a bug that is "serious" priority for e2fsprogs. > > More to the point, there's now way in the world I (or the release and > installer teams) are going to make e2fsprogs, which is an > "important=yes" package with priority "required" drag in the > android-libsparse, android-libbase, and zlib1g packages. > > So the way you changed android-sdk-platforms-tools to use /sbin/mke2fs > was a really bad choice, especially this while we are in release > freeze for Buster. There's no way in the world we are going to make a > change like this to a package like e2fsprogs which is used by the > installer at this point. > > If we had more time, and if android-libsparse-dev shipped a static > library, we could have considered statically linking in > android-libsparse, android-libbase, and libz --- and see if they would > bloat the mke2fs and debugfs binaries by only a minimal amount. > > This would also require making changes to e2fsprogs configure and > Makefiles, since currently we only have support for linking in > libsparse in the AOSP build files. The reason for this is historical; > at the time when the intern working with Android team was working on > replace Android's make_ext4fs program with mke2fs and e2droid, there > was no distribution that was shipping libsparse, and trying to make > libsparse available to Linux desktop environments was *way* beyond the > scope of the Intern's project and time availability. > > We can work on this trying to find a solution post-Buster --- either > using static linking, or *possibly* figuring out a way to optionally > use dlopen() to pull in libsparse for sparse_io.c, much like the way > libss optionally pulls in the readline library using dlopen at > runtime, back when we cared about making mke2fs fit on a two 1.44 MiB > boot/root install floppies. :-) > > Alternatively, you can build your own version of mke2fs using the > libsparse from AOSP. If you want a solution that might make it in > during the Buster release freeze, that's probably the short-term > solution I would suggest. > > So your choice --- we can either reassign this bug back to fastboot or > android-sdk-platforms-tools, or I can downgrade the severity of this > bug for e2fsprogs down to wishlist[1]. Let me know how you want to > handle this. > > Cheers, > > - Ted > > [1] This is because I view this both as a "feature request" and "bugs > that are very difficult to fix due to major design considerations" > (per https://www.debian.org/Bugs/Developer#severities), not to mention > that it's going to affect a miniscule fraction of the e2fsprogs > package's users. Makes sense to me. I'm fine with this being done post-Buster or as a custom mke2fs in android-platform-system-core. .hc
Bug#924591: this requires linking in libsparse, which is from Android sources
One possibility would be including libsparse as a patch, it doesn't change a lot: https://android.googlesource.com/platform/system/core/+log/master/libsparse But it depends on Android's libbase and libz-host.
Bug#924591: this requires linking in libsparse, which is from Android sources
Even though buster's e2fsprogs includes support for android_sparse in the source code, it requires linking against libsparse, which is in android-libsparse. That means making e2fsprogs Build-Depend on android-libsparse-dev.
