Bug#1067317: scons: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No suc
On Wed, 20 Mar 2024 22:04:03 +0100 Lucas Nussbaum wrote: Source: scons Version: 4.5.2+dfsg-1 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240319 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. This is unfortunate. The docbook toolchain seems to have always generated a lot of spew from fop, which to the SCons project has seemed "out of our control". Now it seems something has changed so where the java used to throw SEVERE it is now throwing ERROR, thus failing the build - which really has nothing to do with the operation of SCons, which is just a Python package, after all. This is a failure to generate the pdf versions of the docs, which are unused by the deb package, afaict. Relevant part (hopefully): > [ERROR] FOUserAgent - Invalid property value encountered in margin-left="": org.apache.fop.fo.expr.PropertyException: file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-left' (See position 147:8) >/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-left'>org.apache.fop.fo.expr.PropertyException: file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-left' ... > [ERROR] FOUserAgent - Invalid property value encountered in margin-right="": org.apache.fop.fo.expr.PropertyException: file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-right' (See position 147:8) >/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-right'>org.apache.fop.fo.expr.PropertyException: file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-right' >at org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:446) >at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:499) The latest upstream release (4.7.0) tried to provide a way to avoid doing the pdf and Sphinx builds, but it turns out it doesn't do that in a place that the Debian packaging uses anyway. Will make a note to revisit that on our end. Didn't realize the deb directly used the build files in doc/man and doc/user. The quickest way to patch around this would seem to be to comment out or remove the check in doc/man/SConstruct doc/user/SConstrcut which checks for the presence of the 'fop' or 'xep' commands, so that 'has_pdf' remains false, and the pdf build thus isn't attempted at all. I assume you don't need the pdf files, just the scons.1 etc. files? that's all I see copied in https://salsa.debian.org/debian/scons/-/blob/master/debian/rules?ref_type=heads
Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25
On Sun, 18 Sep 2022 09:38:58 -0700 Bill Deegan wrote: SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python 3.10. The latest SCons 4.4.0 is available and works fine with Python 3.10 > The full build log is available from: > http://qa-logs.debian.net/2022/09/17/scons_4.0.1+dfsg-2_unstable.log Specifically, the ActionTests.py unittest file tests for version-specific bytecode strings, so newer Pythons that an SCons version does not know about will always fail that specific test. Current SCons 4.4 understands through Python 3.11.
Bug#914287: lsb-release: please parse /usr/lib/os-release and deprecate /etc/lsb-release
On 11/21/18 9:12 AM, Simon McVittie wrote: > Package: lsb-release > Version: 9.20170808 > Severity: wishlist > > Debian's Python implementation of the LSB-standardized lsb_release > command parses various sources of data, including the non-standardized > configuration file /etc/lsb-release. That file doesn't exist in Debian, > but is typically shipped in base-files by derivatives. It is not "API" > itself, although packages designed for Ubuntu sometimes treat it as > though it was. > > systemd defines a new "API", which has been adopted in Debian even > for non-systemd systems: the /usr/lib/os-release file (formerly > /etc/os-release, which is now a symlink). This "API" is defined in terms > of parsing a text file, not running a Python program, so it's much faster > to use. > > If lsb_release looked at /usr/lib/os-release, then derivatives could edit > that file and /etc/dpkg/origins/default (which they need to do anyway) > and wouldn't usually need to add /etc/lsb-release. /usr/lib/os-release > uses the same subset of shell syntax as /etc/lsb-release. confirming from the LSB viewpoint: lsb_release should look at whatever it needs to to make its determinations, and nothing the other side of lsb_release is in the LSB specification.
Bug#389380: lsb_release doesn't work without /usr
Sorry, I filed this in the wrong bin and never ended up seeing it. Answering to close the loop, the answers just confirm what was assumed. Chris Lawrence wrote: On 9/25/06, Matthias Klose [EMAIL PROTECTED] wrote: Package: lsb-release Version: 3.1-15 Severity: important /bin/lsb_release doesn't work without /usr, so it's kind of useless to put it into /bin. If it's required to live in /bin, then it shouldn't be implemented in python. As far as I can tell, the LSB doesn't require it to be in /bin, although it seems to live there traditionally. Barring objections, I'll move it to /usr/bin. Correct, it's not required to be in /bin. question: is the format of /etc/lsb-release part of the lsb? AFAICT no. Only the format of data output by lsb_release is specified - this is the API to getting the data. /etc/lsb-release is not even required to exist, although it happens to exist in the sample implementation of lsb_release that LSB provides - it's an implementation detail. mats -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
