Bug#1025221: abseil: please consider disabling tests on riscv64
Hi, Sorry, I didn't notice this reply at the time, I did with the recent activity in this bug report. So, as a belated reply to your earlier efforts, I am writing now to thank you for the effort of looking into this at the time, and sorry for my lack of reply then... and now to the specifics: 2022-12-06 17:15 Benjamin Barenblat: Control: owner 1025221 ! Control: tags 1025221 - patch Hi, Manuel, Yesterday, I tried a build on a porterbox with your patch. It looks like disabling parallelism improves the situation but does not completely solve it; absl_mutex_test is still flaky. I’ll continue investigating and see if I can get that test fixed. In the meantime, it looks like a recent binNMU to Abseil on riscv64 has passed the buildds. Does that unblock your work? And to reply to the question, no, when we were in the debian-ports infra it was not a blocker, as we always had the option to disable tests (if need be) and upload to the special suite "unreleased" which allows to have certain changes to the normal building instructions, like disabling tests. Now in the official infra we cannot do that as a last resort, so we're more limited and the packages have to be built "as-is", without any modifications, so as you have seen by the recent pings from other people it is more or a blocker now. As Aurélien and Stephane said, probably makes more sense to make these non-fatal at the moment, like you do in 20230125.3-2 in experimental for mipsel. Not sure if you'd like to go with the current 20220623.1-2 in unstable & testing for the transition, I suppose that by now the upstream version 20230125.3 must be quite stable. In any case we noticed that you joined #debian-riscv IRC channel, so maybe it's best to discuss it there to find the best option for everyone to go forward. Cheers and thanks. -- Manuel A. Fernandez Montecelo
Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive
Hi, On Wed, 29 Mar 2023 at 17:48, Manuel A. Fernandez Montecelo wrote: > > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: aure...@debian.org, m...@debian.org > > Hello FTP team, > > We had conversations requesting different teams (FTP, Release, DSA) their > opinion about adding riscv64 [1] as a new architecture in the main > infrastructure and all teams gave their provisional approval, so we are > submitting this to track progress on this task. > > Could you please tells us if there's any blocker or something else that we > should do? > > > Cheers. > > > [1] https://wiki.debian.org/Ports/riscv64 Gentle ping? We'd like to start with this when possible, the rebuilding of the whole archive will take a while and this is a good moment for us. If there's any blocker, please let us know. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: aure...@debian.org, m...@debian.org Hello FTP team, We had conversations requesting different teams (FTP, Release, DSA) their opinion about adding riscv64 [1] as a new architecture in the main infrastructure and all teams gave their provisional approval, so we are submitting this to track progress on this task. Could you please tells us if there's any blocker or something else that we should do? Cheers. [1] https://wiki.debian.org/Ports/riscv64 -- Manuel A. Fernandez Montecelo
Bug#1025343: z3: Please link against -latomic for "riscv64" arch
On Wed, 1 Feb 2023 at 16:05, Sylvestre Ledru wrote: > > Hello > > Thanks. > > please upload it now :) no need to wait OK, thanks a lot, will do! -- Manuel A. Fernandez Montecelo
Bug#1025343: z3: Please link against -latomic for "riscv64" arch
Control: tags -1 +pending Hi again, 2023-01-15 23:30 Manuel A. Fernandez Montecelo: On Fri, 2 Dec 2022 at 22:45, Manuel A. Fernandez Montecelo wrote: Source: z3 Version: 4.8.12-3 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, The package needs to link against libatomic in this architecture, with the patch attached or an equivalent. I built it successfully on local hardware. Gentle ping? It would be nice to have this patch applied so the package would build successfully in the case of binNMUs, or new revisions of the package that would fix other problems (e.g. future NMUs), etc. I am preparing a NMU (debdiff attached, basically the same as in the initial request), the reason being that riscv64 might be bootstrapped at some point in the next months and z3 is an important package for that, due to LLVM packages depending on it. And I am planning to upload to delayed/5, because in the second deadline of the freeze is very close and so to not get caught up in last-minute queues. The initial request was on Dec 2 with a ping on Jan 15, so I think that it's reasonable to use this delay now. But if there's any problem or concern, and want me to speed-up/delay-longer/cancel the NMU, please speak up. Cheers. -- Manuel A. Fernandez Montecelo diff -Nru z3-4.8.12/debian/changelog z3-4.8.12/debian/changelog --- z3-4.8.12/debian/changelog 2022-10-21 19:24:40.0 +0200 +++ z3-4.8.12/debian/changelog 2023-02-01 13:06:03.0 +0100 @@ -1,3 +1,10 @@ +z3 (4.8.12-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * riscv64: link against -latomic (Closes: #1025343) + + -- Manuel A. Fernandez Montecelo Wed, 01 Feb 2023 13:06:03 +0100 + z3 (4.8.12-3) unstable; urgency=medium * Do not use SSE2 unconditionally on i386 diff -Nru z3-4.8.12/debian/rules z3-4.8.12/debian/rules --- z3-4.8.12/debian/rules 2022-10-21 15:51:13.0 +0200 +++ z3-4.8.12/debian/rules 2023-02-01 13:04:59.0 +0100 @@ -6,6 +6,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CXXFLAGS_MAINT_APPEND = -fPIC -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 +ifeq ($(DEB_HOST_ARCH),riscv64) +export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -Wl,-latomic -Wl,--as-needed +endif + DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) ifneq (,$(shell dh_listpackages -a | grep libz3-jni))
Bug#1024041: mariadb-10.6: FTBFS on riscv64: rocksdb/db/memtable.cc:129: undefined reference to `__atomic_compare_exchange_1'
Hi Otto, On Sat, 21 Jan 2023 at 23:28, Otto Kekäläinen wrote: > > Control: retitle -1 mariadb: FTBFS on riscv64: > rocksdb/db/memtable.cc:129: undefined reference to > `__atomic_compare_exchange_1' to misc functions and files > Control: reassign -1 mariadb > Control: found -1 mariadb-10.6/1:10.6.9-1 > Control: found -1 mariadb/1:10.11.1-1 > > I reviewed recent builds of the new MariaDB 10.11[1] and similar > failures still exist. > > If you have a suggestion for a fix - Merge Requests[2] on Salsa are > very welcome! Not sure I understand or if you missed some of the messages to this bug report, but from what I understand you request a patch to fix the info, and Bo Yu provided a patch on 2022-11-14 on this bug report [1], and in subsequent messages also to this bug report I provided more info that it works when building it locally with the patch, and later I sent another message as a kind of "ping". [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024041#20 If you prefer a MergeRequest in Salsa I suppose that Bo Yu will create one, if it makes things easier for you; if not I'll try to do it in the next days. But yeah, in any case we're very interested in getting this fixed, thanks for your interest! Cheers. -- Manuel A. Fernandez Montecelo
Bug#1025446: php8.2: Please link against libatomic for "riscv64" arch
Hi, On Sun, 4 Dec 2022 at 21:15, Manuel A. Fernandez Montecelo wrote: > > Source: php8.2 > Severity: wishlist > Tags: ftbfs patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.org > > Hi, > > The package still in experimental builds with the changes attached, I built > the > package locally on this architecture, so please include it (or add an > equivalent > solution) in the next uploads, at least before moving to unstable. Gentle ping? There are several packages (PHP modules or similar) waiting with Dep-Wait on a newer version of php8.2, so it would be nice to have this patch applied to have php8.2 building successfully and so avoiding these problems altogether. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1025343: z3: Please link against -latomic for "riscv64" arch
On Fri, 2 Dec 2022 at 22:45, Manuel A. Fernandez Montecelo wrote: > > Source: z3 > Version: 4.8.12-3 > Severity: wishlist > Tags: ftbfs patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org > > Hi, > > The package needs to link against libatomic in this architecture, with the > patch > attached or an equivalent. > > I built it successfully on local hardware. Gentle ping? It would be nice to have this patch applied so the package would build successfully in the case of binNMUs, or new revisions of the package that would fix other problems (e.g. future NMUs), etc. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1024041: mariadb-10.6: FTBFS on riscv64: rocksdb/db/memtable.cc:129: undefined reference to `__atomic_compare_exchange_1'
Hi, On Tue, 15 Nov 2022 at 22:39, Manuel A. Fernandez Montecelo wrote: > > Source: mariadb-10.6 > Version: 1:10.6.10-1 > Followup-For: Bug #1024041 > X-Debbugs-Cc: m...@debian.org, tsu.y...@gmail.com > > Hi, > > @Otto: thanks for paying attention to the riscv64 arch, even if not one of the >main ones [yet] :-) > > > To provide info, with the patch from Bo Yu (thanks for the patch!) I can build > successfully in hardware and in my case the tests pass fine (unless the > skipped > ones cause any worry) It would be nice if the patch could be applied to fix this problem, as this package keeps failing with the same error, and we don't see if there are important regressions in other areas, e.g. failures to compile in later stages, or failing tests, etc. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1026236: tracker: Please increase test timeouts for "riscv64" arch
Source: tracker Version: 3.4.2-1 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org, m...@debian.org Hi, I built this package with the attached changes in the .debdiff. Basically it's setting the timeout multiplier to 3, as one of the tests (23/37: tracker:core / service) takes around 67 seconds. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru tracker-3.4.2/debian/changelog tracker-3.4.2/debian/changelog --- tracker-3.4.2/debian/changelog 2022-12-06 21:51:16.0 + +++ tracker-3.4.2/debian/changelog 2022-12-16 15:11:36.0 + @@ -1,3 +1,10 @@ +tracker (3.4.2-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: test timeouts, use multiplier x3 + + -- Manuel A. Fernandez Montecelo Fri, 16 Dec 2022 15:11:36 + + tracker (3.4.2-1) unstable; urgency=medium * New upstream release diff -Nru tracker-3.4.2/debian/rules tracker-3.4.2/debian/rules --- tracker-3.4.2/debian/rules 2022-12-06 21:51:16.0 + +++ tracker-3.4.2/debian/rules 2022-12-16 15:11:36.0 + @@ -26,4 +26,4 @@ dh_makeshlibs -V -X/usr/lib/$(DEB_HOST_MULTIARCH)/tracker-3.0/ -- -c4 override_dh_auto_test: - dbus-run-session -- dh_auto_test --no-parallel + dbus-run-session -- dh_auto_test --no-parallel -- --timeout-multiplier 3
Bug#1024867: mercurial: FTBFS on riscv64 (test timeout)
Version: 6.3.1-2
Followup-For: Bug #1024867
X-Debbugs-Cc: m...@debian.org
Control: tags -1 ftbfs patch
Hi,
I built it on the porterbox, which is the same as most buildds (HiFive
Unmatched) and slower than the others (except for builders with Qemu VMs, which
are disabled now and probably will remain that way). With the timeout set to
1800, it built fine.
I also built it in another machine locally (HiFive Unleashed clocked at 1GHz, so
slower) and it built successfully.
I attach the .debdiff.
I also detected a typo that it's a bit annoying if you're looking for the
correct string ("Timeout").
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru mercurial-6.2.3/debian/changelog mercurial-6.2.3/debian/changelog
--- mercurial-6.2.3/debian/changelog2022-10-07 14:26:54.0 +0200
+++ mercurial-6.2.3/debian/changelog2022-12-14 22:36:50.0 +0100
@@ -1,3 +1,10 @@
+mercurial (6.2.3-1+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: test failures
+
+ -- Manuel A. Fernandez Montecelo Wed, 14 Dec 2022 21:36:50
+
+
mercurial (6.2.3-1) sid; urgency=medium
* New upstream bugfix release.
diff -Nru mercurial-6.2.3/debian/patches/series
mercurial-6.2.3/debian/patches/series
--- mercurial-6.2.3/debian/patches/series 2022-10-07 13:21:27.0
+0200
+++ mercurial-6.2.3/debian/patches/series 2022-12-14 22:36:50.0
+0100
@@ -6,3 +6,4 @@
deb_specific__disable_libdir_replacement.patch
0005-Tolerate-SIGINT-getting-the-kill-in-test-stdio.py.patch
openssl_3_cipher_tlsv1.patch
+test-timeout-typo.patch
diff -Nru mercurial-6.2.3/debian/patches/test-timeout-typo.patch
mercurial-6.2.3/debian/patches/test-timeout-typo.patch
--- mercurial-6.2.3/debian/patches/test-timeout-typo.patch 1970-01-01
01:00:00.0 +0100
+++ mercurial-6.2.3/debian/patches/test-timeout-typo.patch 2022-12-14
22:36:50.0 +0100
@@ -0,0 +1,13 @@
+Index: mercurial-6.2.3/tests/run-tests.py
+===
+--- mercurial-6.2.3.orig/tests/run-tests.py
mercurial-6.2.3/tests/run-tests.py
+@@ -315,7 +315,7 @@ def Popen4(cmd, wd, timeout, env=None):
+ while time.time() - start < timeout and p.returncode is None:
+ time.sleep(0.1)
+ p.timeout = True
+-vlog('# Timout reached for process %d' % p.pid)
++vlog('# Timeout reached for process %d' % p.pid)
+ if p.returncode is None:
+ terminate(p)
+
diff -Nru mercurial-6.2.3/debian/rules mercurial-6.2.3/debian/rules
--- mercurial-6.2.3/debian/rules2022-10-07 13:21:27.0 +0200
+++ mercurial-6.2.3/debian/rules2022-12-14 22:36:50.0 +0100
@@ -45,7 +45,7 @@
sed -i.deb-backup -e 's/sleep 1/sleep 2/'
$(CURDIR)/tests/test-pull-pull-corruption.t
endif
- http_proxy='' dh_auto_test -- PYTHON=python3 TESTFLAGS="--verbose
--timeout 1440 $(PARALLEL_TEST_JOBS) --blacklist
$(CURDIR)/debian/mercurial.test_blacklist"
+ http_proxy='' dh_auto_test -- PYTHON=python3 TESTFLAGS="--verbose
--timeout 1800 $(PARALLEL_TEST_JOBS) --blacklist
$(CURDIR)/debian/mercurial.test_blacklist"
file-rename 's/\.deb-backup$$//' $(CURDIR)/tests/*
# run blacklisted tests but ignore their results
-cd tests && python3 run-tests.py --verbose `grep ^test
../debian/mercurial.test_blacklist`
Bug#1025129: elpi: Please add support for "riscv64" arch
Hi Julien, On Wed, 30 Nov 2022 at 06:58, wrote: > > I'm going to apply your changes (I already checked them on a porterbox > and committed to salsa) ; but since there's an ongoing big transition, > I'll wait until that has passed. > > There's also a new elpi upstream version I'll want to package, so I > expect in a week or so I'll be able to ask for a transition to the > release team and your change will go in. No problem, theres no rush and that's more than fast enough. Thanks! -- Manuel A. Fernandez Montecelo
Bug#1025446: php8.2: Please link against libatomic for "riscv64" arch
Source: php8.2 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.org Hi, The package still in experimental builds with the changes attached, I built the package locally on this architecture, so please include it (or add an equivalent solution) in the next uploads, at least before moving to unstable. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru php8.2-8.2.0~rc5/debian/changelog php8.2-8.2.0~rc5/debian/changelog --- php8.2-8.2.0~rc5/debian/changelog 2022-10-28 17:55:40.0 + +++ php8.2-8.2.0~rc5/debian/changelog 2022-12-04 09:18:27.0 + @@ -1,3 +1,10 @@ +php8.2 (8.2.0~rc5-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: fix linking against -latomic + + -- Manuel A. Fernandez Montecelo Sun, 04 Dec 2022 09:18:27 + + php8.2 (8.2.0~rc5-1) experimental; urgency=medium * New upstream version 8.2.0~rc5 diff -Nru php8.2-8.2.0~rc5/debian/rules php8.2-8.2.0~rc5/debian/rules --- php8.2-8.2.0~rc5/debian/rules 2022-10-28 17:55:40.0 + +++ php8.2-8.2.0~rc5/debian/rules 2022-12-04 09:18:27.0 + @@ -156,7 +156,12 @@ # Enable producing of debugging information DEB_CFLAGS_MAINT_APPEND += -g -DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +# needs to link explicitly against libatomic on riscv64 +ifneq (,$(filter $(DEB_HOST_ARCH),riscv64)) +DEB_LDFLAGS_MAINT_APPEND += -latomic +endif + +DEB_LDFLAGS_MAINT_APPEND += -Wl,--as-needed export DEB_CFLAGS_MAINT_APPEND export DEB_LDFLAGS_MAINT_APPEND
Bug#1025418: jffi: Please add support for "riscv64" arch
Source: jffi
Version: 1.2.7-11
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please add support this architecture, with the patch attached or an equivalent.
This package built well in the past on riscv64 but it seems that in recent
versions it needs some extra support.
I built the package locally on hardware, it built fine with the patch
0013-Add-support-for-riscv64.patch. Also attached the whole debdiff.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru jffi-1.3.9+ds/debian/changelog jffi-1.3.9+ds/debian/changelog
--- jffi-1.3.9+ds/debian/changelog 2022-12-04 05:45:16.0 +
+++ jffi-1.3.9+ds/debian/changelog 2022-12-04 10:22:42.0 +
@@ -1,3 +1,10 @@
+jffi (1.3.9+ds-4+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: add support for architecture
+
+ -- Manuel A. Fernandez Montecelo Sun, 04 Dec 2022 10:22:42
+
+
jffi (1.3.9+ds-4) unstable; urgency=medium
* Team upload.
diff -Nru jffi-1.3.9+ds/debian/patches/0013-Add-support-for-riscv64.patch
jffi-1.3.9+ds/debian/patches/0013-Add-support-for-riscv64.patch
--- jffi-1.3.9+ds/debian/patches/0013-Add-support-for-riscv64.patch
1970-01-01 00:00:00.0 +
+++ jffi-1.3.9+ds/debian/patches/0013-Add-support-for-riscv64.patch
2022-12-04 10:22:32.0 +
@@ -0,0 +1,44 @@
+Index: jffi-1.3.9+ds/src/main/java/com/kenai/jffi/Platform.java
+===
+--- jffi-1.3.9+ds.orig/src/main/java/com/kenai/jffi/Platform.java
jffi-1.3.9+ds/src/main/java/com/kenai/jffi/Platform.java
+@@ -108,6 +108,8 @@ public abstract class Platform {
+ MIPS(32),
+/** MIPS64EL */
+ MIPS64EL(64),
++ /** RISCV64 */
++RISCV64(64),
+ /** Unknown CPU */
+ UNKNOWN(64);
+
+@@ -250,6 +252,8 @@ public abstract class Platform {
+
+ } else if (Util.equalsIgnoreCase("mips64", archString, LOCALE) ||
Util.equalsIgnoreCase("mips64el", archString, LOCALE)) {
+ return CPU.MIPS64EL;
++} else if (Util.equalsIgnoreCase("riscv64", archString, LOCALE)) {
++return CPU.RISCV64;
+ }
+
+
+Index: jffi-1.3.9+ds/src/main/java/com/kenai/jffi/internal/StubLoader.java
+===
+--- jffi-1.3.9+ds.orig/src/main/java/com/kenai/jffi/internal/StubLoader.java
jffi-1.3.9+ds/src/main/java/com/kenai/jffi/internal/StubLoader.java
+@@ -163,6 +163,8 @@ public class StubLoader {
+ MIPS,
+ /** MIPS 64-bit little endian */
+ MIPS64EL,
++/** RISC-V 64-bit little endian */
++RISCV64,
+ /** Unknown CPU */
+ UNKNOWN;
+
+@@ -233,6 +235,8 @@ public class StubLoader {
+ return CPU.MIPS;
+ } else if (Util.equalsIgnoreCase("mips64", archString, LOCALE) ||
Util.equalsIgnoreCase("mips64el", archString, LOCALE)) {
+ return CPU.MIPS64EL;
++} else if (Util.equalsIgnoreCase("riscv64", archString, LOCALE)) {
++return CPU.RISCV64;
+
+ }
+
diff -Nru jffi-1.3.9+ds/debian/patches/series
jffi-1.3.9+ds/debian/patches/series
--- jffi-1.3.9+ds/debian/patches/series 2022-12-04 05:45:16.0 +
+++ jffi-1.3.9+ds/debian/patches/series 2022-12-04 10:06:03.0 +
@@ -10,3 +10,4 @@
0010-output-test-results-to-console-instead-of-file.patch
0011-Fix-tests-for-32-bit-ARM-armel-and-armhf.patch
0012-Add-support-for-mips.patch
+0013-Add-support-for-riscv64.patch
Index: jffi-1.3.9+ds/src/main/java/com/kenai/jffi/Platform.java
===
--- jffi-1.3.9+ds.orig/src/main/java/com/kenai/jffi/Platform.java
+++ jffi-1.3.9+ds/src/main/java/com/kenai/jffi/Platform.java
@@ -108,6 +108,8 @@ public abstract class Platform {
MIPS(32),
/** MIPS64EL */
MIPS64EL(64),
+ /** RISCV64 */
+RISCV64(64),
/** Unknown CPU */
UNKNOWN(64);
@@ -250,6 +252,8 @@ public abstract class Platform {
} else if (Util.equalsIgnoreCase("mips64", archString, LOCALE) ||
Util.equalsIgnoreCase("mips64el", archString, LOCALE)) {
return CPU.MIPS64EL;
+} else if (Util.equalsIgnoreCase("riscv64", archString, LOCALE)) {
+return CPU.RISCV64;
}
Index: jffi-1.3.9+ds/src/main/java/com/kenai/jffi/internal/StubLoader.java
===
--- jffi-1.3.9+ds.orig/src/main/java/com/kenai/jffi/internal/StubLoader.java
+++ jffi-1.3.9+ds/src/main/java/com/kenai/jffi/internal/StubLoader.java
@@ -163,6 +163,8 @@ public class StubLoader {
MIPS,
/*
Bug#1025411: scilab: Please add support for "riscv64" arch
Source: scilab
Version: 6.1.1+dfsg2-4
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
This is possible after libjogl2-java gained support for riscv64, which happened
in recent days:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025373
https://tracker.debian.org/news/1393347/accepted-libjogl2-java-232dfsg-10-source-into-unstable/
As a suggestion, perhaps the Architecture field should be set to "any".
Missing libjogl2-java or other build-dependencies in some architectures will
make this package to not be buildable there, but otherwise will cause no harm,
no spurious warnings or any other annoying side-effect (AFAIK), while avoiding
having to make changes to the package to support new architectures.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru scilab-6.1.1+dfsg2/debian/changelog
scilab-6.1.1+dfsg2/debian/changelog
--- scilab-6.1.1+dfsg2/debian/changelog 2022-08-16 09:55:44.0 +
+++ scilab-6.1.1+dfsg2/debian/changelog 2022-12-02 20:25:11.0 +
@@ -1,3 +1,10 @@
+scilab (6.1.1+dfsg2-4+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: enable in d/control
+
+ -- Manuel A. Fernandez Montecelo Fri, 02 Dec 2022 20:25:11
+
+
scilab (6.1.1+dfsg2-4) unstable; urgency=medium
* Add patch to disambiguate pause (Closes: #1017283).
diff -Nru scilab-6.1.1+dfsg2/debian/control scilab-6.1.1+dfsg2/debian/control
--- scilab-6.1.1+dfsg2/debian/control 2022-08-16 09:55:44.0 +
+++ scilab-6.1.1+dfsg2/debian/control 2022-12-02 20:25:11.0 +
@@ -109,7 +109,7 @@
Package: scilab-include
# any because of the bug #550243
-Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el
+Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el riscv64
Depends: ${misc:Depends}
Description: Scientific software package for numerical computations (include
files)
Scilab is a matrix-based scientific software package.
@@ -130,7 +130,7 @@
Package: scilab-minimal-bin
-Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el
+Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el riscv64
Depends: ${shlibs:Depends}, scilab-data (= ${source:Version}),
${misc:Depends}, default-jre-headless
Replaces: scilab-bin, scilab-full-bin (<< 5.4.1-3)
@@ -155,7 +155,7 @@
Please install the package "scilab" to have all features.
Package: scilab-full-bin
-Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el
+Architecture: amd64 armhf i386 powerpc s390x arm64 ppc64el riscv64
Depends: ${shlibs:Depends}, scilab-minimal-bin (= ${binary:Version}),
libflexdock-java (>= 1.2.3), libjogl2-java (>= 2.3.2), libjrosetta-java (>=
1.0.1),
libjlatexmath-java (>= 1.0.2), libjlatexmath-fop-java (>= 1.0.2),
Bug#1025373: libjogl2-java: Please add support for "riscv64" arch
Source: libjogl2-java
Version: 2.3.2+dfsg-9
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine with the patch riscv64-port.diff.
Also attached the whole debdiff.
The particular string with its upper and lowercases ("Riscv64") comes from
#1014852, trying to use other combinations doesn't work.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru libjogl2-java-2.3.2+dfsg/debian/changelog
libjogl2-java-2.3.2+dfsg/debian/changelog
--- libjogl2-java-2.3.2+dfsg/debian/changelog 2019-03-02 13:56:52.0
+
+++ libjogl2-java-2.3.2+dfsg/debian/changelog 2022-12-02 21:24:38.0
+
@@ -1,3 +1,12 @@
+libjogl2-java (2.3.2+dfsg-9+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64:
+- enable in d/control
+- add debian/patches/riscv64-port.diff
+
+ -- Manuel A. Fernandez Montecelo Fri, 02 Dec 2022 21:24:38
+
+
libjogl2-java (2.3.2+dfsg-9) unstable; urgency=medium
* Team upload.
diff -Nru libjogl2-java-2.3.2+dfsg/debian/control
libjogl2-java-2.3.2+dfsg/debian/control
--- libjogl2-java-2.3.2+dfsg/debian/control 2019-03-02 13:56:52.0
+
+++ libjogl2-java-2.3.2+dfsg/debian/control 2022-12-02 21:24:38.0
+
@@ -53,7 +53,7 @@
Package: libjogl2-jni
Depends: ${misc:Depends}, ${shlibs:Depends}
-Architecture: amd64 i386 arm64 armhf ppc64el s390x powerpc ppc64
+Architecture: amd64 i386 arm64 armhf ppc64el s390x powerpc ppc64 riscv64
Description: Java bindings for OpenGL API (JNI lib)
The JOGL project hosts the development version of the Java Bindings for
OpenGL (JSR-231), and is designed to provide hardware-supported 3D graphics
diff -Nru libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff
libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff
--- libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff 1970-01-01
00:00:00.0 +
+++ libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff 2022-12-02
21:24:38.0 +
@@ -0,0 +1,82 @@
+Index: libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-jogl.xml
libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
+@@ -1395,6 +1395,12 @@
+
+
+
++
++
++
++
++
++
+
+
+
+@@ -1413,7 +1419,7 @@
+
+
+
+-
++
+
+
+
+Index: libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-nativewindow.xml
libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
+@@ -574,6 +574,12 @@
+
+
+
++
++
++
++
++
++
+
+
+
+@@ -592,7 +598,7 @@
+
+
+
+-
++
+
+
+
+Index: libjogl2-java-2.3.2+dfsg/make/build-newt.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-newt.xml
libjogl2-java-2.3.2+dfsg/make/build-newt.xml
+@@ -546,6 +546,16 @@
+
+
+
++
++
++
++
++
++
++
++
++
+
+
+
+@@ -582,7 +592,7 @@
+
+
+
+-
++
+
+
+
diff -Nru libjogl2-java-2.3.2+dfsg/debian/patches/series
libjogl2-java-2.3.2+dfsg/debian/patches/series
--- libjogl2-java-2.3.2+dfsg/debian/patches/series 2019-03-02
13:56:52.0 +
+++ libjogl2-java-2.3.2+dfsg/debian/patches/series 2022-12-02
21:24:38.0 +
@@ -20,3 +20,4 @@
disable-test-compilation.patch
fix-mesa-detection.diff
java11.patch
+riscv64-port.diff
Index: libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-jogl.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
@@ -1395,6 +1395,12 @@
+
+
+
+
+
+
@@ -1413,7 +1419,7 @@
-
+
Index: libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-nativewindow.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
@@ -574,6 +574,12 @@
+
+
+
+
+
+
@@ -592,7 +598,7 @@
-
+
Index: libjogl2-java-2.3.2+dfsg/make/build-newt.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-newt.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-newt.xml
@@ -546
Bug#1025343: z3: Please link against -latomic for "riscv64" arch
Source: z3 Version: 4.8.12-3 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, The package needs to link against libatomic in this architecture, with the patch attached or an equivalent. I built it successfully on local hardware. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru z3-4.8.12/debian/changelog z3-4.8.12/debian/changelog --- z3-4.8.12/debian/changelog 2022-10-21 17:24:40.0 + +++ z3-4.8.12/debian/changelog 2022-11-28 16:02:35.0 + @@ -1,3 +1,10 @@ +z3 (4.8.12-3+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: link against -latomic + + -- Manuel A. Fernandez Montecelo Mon, 28 Nov 2022 16:02:35 + + z3 (4.8.12-3) unstable; urgency=medium * Do not use SSE2 unconditionally on i386 diff -Nru z3-4.8.12/debian/rules z3-4.8.12/debian/rules --- z3-4.8.12/debian/rules 2022-10-21 13:51:13.0 + +++ z3-4.8.12/debian/rules 2022-11-28 16:02:35.0 + @@ -6,6 +6,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CXXFLAGS_MAINT_APPEND = -fPIC -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 +ifeq ($(DEB_HOST_ARCH),riscv64) +export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -Wl,-latomic -Wl,--as-needed +endif + DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) ifneq (,$(shell dh_listpackages -a | grep libz3-jni))
Bug#1025336: swi-prolog: Please link against -latomic for "riscv64" arch
Source: swi-prolog Version: 8.4.3+dfsg-2 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, The package needs to link against libatomic in this architecture, with the patch attached or an equivalent. I built it locally on hardware, it built fine. (This happened with 8.4.3+dfsg-2, the patch is for 9.0.0). Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru swi-prolog-9.0.0+dfsg/debian/changelog swi-prolog-9.0.0+dfsg/debian/changelog --- swi-prolog-9.0.0+dfsg/debian/changelog 2022-12-02 09:49:17.0 + +++ swi-prolog-9.0.0+dfsg/debian/changelog 2022-12-02 17:40:49.0 + @@ -1,3 +1,10 @@ +swi-prolog (9.0.0+dfsg-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: link against -latomic + + -- Manuel A. Fernandez Montecelo Fri, 02 Dec 2022 17:40:49 + + swi-prolog (9.0.0+dfsg-1) unstable; urgency=medium * New upstream version 9.0.0+dfsg diff -Nru swi-prolog-9.0.0+dfsg/debian/rules swi-prolog-9.0.0+dfsg/debian/rules --- swi-prolog-9.0.0+dfsg/debian/rules 2022-12-02 09:49:17.0 + +++ swi-prolog-9.0.0+dfsg/debian/rules 2022-12-02 17:40:30.0 + @@ -6,6 +6,11 @@ DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk +ifeq ($(DEB_BUILD_ARCH),riscv64) +DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -Wl,-latomic -Wl,--as-needed +export DEB_LDFLAGS_MAINT_APPEND +endif + PLBASENAME := swi-prolog PLBASE := /usr/lib/$(PLBASENAME)/ JNIDIR := /usr/lib/$(DEB_BUILD_MULTIARCH)/jni
Bug#1025241: prometheus: Please increase timeout of tests for "riscv64" arch
Source: prometheus Version: 2.39.1+ds1-2 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hello, This package fails frequently in most of the build machines of this architecture due to timeouts, specially tsdb with 1200 (20 mins). I was building this package with the attached changes and it seems to solve the issue in the same class of machines in which is failing now. In particular in this build it ran the test even before the 1200 timeout, but it's very close, and usually the machines doing the building are more stressed: ok github.com/prometheus/prometheus/tsdb 1183.502s As I said, I solved it with the attached patch, which seems very straightforward way to do it, but feel free to do it in some other way. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru prometheus-2.40.4+ds/debian/changelog prometheus-2.40.4+ds/debian/changelog --- prometheus-2.40.4+ds/debian/changelog 2022-11-30 06:35:44.0 + +++ prometheus-2.40.4+ds/debian/changelog 2022-11-30 23:40:44.0 + @@ -1,3 +1,10 @@ +prometheus (2.40.4+ds-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: increase timeout for tests + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 23:40:44 + + prometheus (2.40.4+ds-1) unstable; urgency=medium * New upstream release (fixes CVE-2022-46146) diff -Nru prometheus-2.40.4+ds/debian/rules prometheus-2.40.4+ds/debian/rules --- prometheus-2.40.4+ds/debian/rules 2022-11-30 06:35:44.0 + +++ prometheus-2.40.4+ds/debian/rules 2022-11-30 23:39:12.0 + @@ -46,6 +46,8 @@ ifeq ($(DEB_HOST_ARCH_CPU),arm) # Tests in armel take way too long, and run out of memory in armhf. TESTFLAGS := -timeout 60m -short +else ifeq ($(DEB_HOST_ARCH_CPU),riscv64) +TESTFLAGS := -timeout 60m else TESTFLAGS := -timeout 20m endif
Bug#1025221: abseil: please consider disabling tests on riscv64
Source: abseil Version: 20220623.1-1 Followup-For: Bug #1025221 User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, 1025221-submit...@bugs.debian.org Control: tags -1 ftbfs patch Control: retitle -1 abseil: please increase timeout or do not run tests in parallel on riscv64 Hello, I was building this package disabling parallelism and it seems to solve the issue. I solved it with the attached patch, but feel free to do it in some other way. The issue is that, due to limitations of the current building machines for the riscv64 arch, it seems that some of the tests reached timeouts and thus fail. Running serially seems to help by giving them more time to run before timing out, or something to that effect. I did not find an obvious way to increase the timeout, at least not without having more complicate patches, if you know how to do it in a simple way I would encourage you to go that way. And maybe by setting parallelism to lower levels, like half of the computing cores would be enough. But at the moment I think that this is an acceptable solution which keeps running the tests and not causing much extra maintenance effort, even if it takes a bit longer to build the package. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru abseil-20220623.1/debian/changelog abseil-20220623.1/debian/changelog --- abseil-20220623.1/debian/changelog 2022-10-18 14:02:49.0 + +++ abseil-20220623.1/debian/changelog 2022-11-30 21:22:35.0 + @@ -1,3 +1,10 @@ +abseil (20220623.1-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: disable parallel checks + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 21:22:35 + + abseil (20220623.1-1) unstable; urgency=medium * New upstream release. diff -Nru abseil-20220623.1/debian/rules abseil-20220623.1/debian/rules --- abseil-20220623.1/debian/rules 2022-10-18 12:37:10.0 + +++ abseil-20220623.1/debian/rules 2022-11-30 21:22:35.0 + @@ -50,8 +50,11 @@ dh_auto_build -Bshared ifeq ($(ABSL_RUN_TESTS),ON) +ifneq ($(filter $(DEB_HOST_ARCH),riscv64),) +TEST_PARALLEL=--no-parallel +endif override_dh_auto_test: - dh_auto_test -Bshared + dh_auto_test -Bshared $(TEST_PARALLEL) endif override_dh_auto_install:
Bug#1024744: grpc: fail to build on riscv64
Source: grpc Version: 1.30.2-4 Followup-For: Bug #1024744 User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.org Control: tags -1 ftbfs patch Hi, > If you have time, please look into this. Sure, grpc 1.51.0 may still > need to link with atomic, but first we need to get abseil work on > riscv64. Yes, it will still need to link against -latomic. The package in its current version in unstable builds with the patch attached, I built the package locally on this architecture, so please include it in the next uploads -- as Gianfranco said, it's critical for LLVM. Regarding grpc 1.51.0 and abseil, we're looking at it in parallel and probably will submit a patch about it in the next days, so I hope that it will be ready by the time that you want to migrate to the newer version. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru grpc-1.30.2/debian/changelog grpc-1.30.2/debian/changelog --- grpc-1.30.2/debian/changelog2022-09-25 18:03:42.0 + +++ grpc-1.30.2/debian/changelog2022-11-30 10:55:30.0 + @@ -1,3 +1,10 @@ +grpc (1.30.2-4+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: build without tests, try to link against -latomic + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 10:55:30 + + grpc (1.30.2-4) unstable; urgency=medium * Import setuptools before distutils in setup.py (closes: #1020116). diff -Nru grpc-1.30.2/debian/rules grpc-1.30.2/debian/rules --- grpc-1.30.2/debian/rules2021-01-13 21:50:31.0 + +++ grpc-1.30.2/debian/rules2022-11-30 10:55:30.0 + @@ -25,7 +25,7 @@ # package maintainers to append LDFLAGS export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc riscv64)) export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed endif diff -Nru grpc-1.30.2/debian/changelog grpc-1.30.2/debian/changelog --- grpc-1.30.2/debian/changelog2022-09-25 18:03:42.0 + +++ grpc-1.30.2/debian/changelog2022-11-30 10:55:30.0 + @@ -1,3 +1,10 @@ +grpc (1.30.2-4+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: build without tests, try to link against -latomic + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 10:55:30 + + grpc (1.30.2-4) unstable; urgency=medium * Import setuptools before distutils in setup.py (closes: #1020116). diff -Nru grpc-1.30.2/debian/rules grpc-1.30.2/debian/rules --- grpc-1.30.2/debian/rules2021-01-13 21:50:31.0 + +++ grpc-1.30.2/debian/rules2022-11-30 10:55:30.0 + @@ -25,7 +25,7 @@ # package maintainers to append LDFLAGS export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc riscv64)) export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed endif
Bug#1025129: elpi: Please add support for "riscv64" arch
Source: elpi
Version: 1.16.7-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, and increasing the timeout.
I only tried with doubling the current timeot, maybe it can do with
significantly less time, but 600 from longer_timeout.patch is already much
higher than the original 90. But if you want I can try and try to get a more
accurate limit.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru elpi-1.16.7/debian/changelog elpi-1.16.7/debian/changelog
--- elpi-1.16.7/debian/changelog2022-10-26 09:11:53.0 +
+++ elpi-1.16.7/debian/changelog2022-11-29 17:27:58.0 +
@@ -1,3 +1,10 @@
+elpi (1.16.7-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Tue, 29 Nov 2022 17:27:58
+
+
elpi (1.16.7-2) unstable; urgency=medium
* Limit the architectures where the package builds,
diff -Nru elpi-1.16.7/debian/control elpi-1.16.7/debian/control
--- elpi-1.16.7/debian/control 2022-10-26 09:11:53.0 +
+++ elpi-1.16.7/debian/control 2022-11-29 17:27:58.0 +
@@ -26,7 +26,7 @@
Homepage: https://github.com/LPCIC/elpi
Package: libelpi-ocaml
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
Depends: ${misc:Depends}, ${ocaml:Depends}, ${shlibs:Depends}
Provides: ${ocaml:Provides}
Recommends: ocaml-findlib
@@ -38,7 +38,7 @@
This package provides the runtime files.
Package: libelpi-ocaml-dev
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
Depends: ${misc:Depends}, ${ocaml:Depends}, ${shlibs:Depends}
Provides: ${ocaml:Provides}
Recommends: ocaml-findlib
@@ -50,7 +50,7 @@
This package provides the dev files.
Package: elpi
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
Depends: libelpi-ocaml (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
diff -Nru elpi-1.16.7/debian/patches/longer_timeout.patch
elpi-1.16.7/debian/patches/longer_timeout.patch
--- elpi-1.16.7/debian/patches/longer_timeout.patch 2022-10-26
09:11:53.0 +
+++ elpi-1.16.7/debian/patches/longer_timeout.patch 2022-11-29
17:27:58.0 +
@@ -2,14 +2,16 @@
Author: Julien Puydt
Forwarded: Debian-specific
elpi.orig/Makefile
-+++ elpi/Makefile
-@@ -24,7 +24,7 @@
+Index: elpi-1.16.7/Makefile
+===
+--- elpi-1.16.7.orig/Makefile
elpi-1.16.7/Makefile
+@@ -24,7 +24,7 @@ help:
INSTALL=_build/install/default
BUILD=_build/default
SHELL:=/usr/bin/env bash
-TIMEOUT=90.0
-+TIMEOUT=600.0
++TIMEOUT=1200.0
PWD=$(shell pwd)
RUNNERS=\
dune \
Bug#1025081: dnsdist: Please add support for "riscv64" arch
Source: dnsdist
Version: 1.7.3-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru dnsdist-1.7.3/debian/changelog dnsdist-1.7.3/debian/changelog
--- dnsdist-1.7.3/debian/changelog 2022-11-01 22:35:46.0 +
+++ dnsdist-1.7.3/debian/changelog 2022-11-28 21:45:40.0 +
@@ -1,3 +1,10 @@
+dnsdist (1.7.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Mon, 28 Nov 2022 21:45:40
+
+
dnsdist (1.7.3-1) unstable; urgency=medium
* New upstream version 1.7.3
diff -Nru dnsdist-1.7.3/debian/control dnsdist-1.7.3/debian/control
--- dnsdist-1.7.3/debian/control2022-11-01 22:35:46.0 +
+++ dnsdist-1.7.3/debian/control2022-11-28 21:45:40.0 +
@@ -31,7 +31,7 @@
Rules-Requires-Root: no
Package: dnsdist
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Pre-Depends: ${misc:Pre-Depends}
Depends: adduser,
${misc:Depends},
Bug#1025032: kicad: Please add support for "riscv64" arch
Hi Carsten, On Tue, 29 Nov 2022 at 08:10, Carsten Schoenert wrote: > > I'm absolutely fine with adding riscv64 as additional supported > architecture, I'm expecting at least one more release of the current > stable 6.x branch before the hard freeze of bookworm will start. If > things getting late I'll upload another version of 6.0.9 with the > riscv64 architecture before. Ack, thanks very much for your explanations and your work :) -- Manuel A. Fernandez Montecelo
Bug#1025039: pdns: Please add support for "riscv64" arch
On Tue, 29 Nov 2022 at 10:32, Chris Hofstaedtler wrote: > > * Manuel A. Fernandez Montecelo [221129 00:42]: > > Perhaps it should just be set to "any" architectures, unlike what I did > > with the > > patch, because it probably builds fine in other architectures too. > > Absolutely not, because it does not build at all on 32bit glibc > archs. Ack, thanks for clarifying. -- Manuel A. Fernandez Montecelo
Bug#1025040: pdns-recursor: Please add support for "riscv64" arch
Source: pdns-recursor
Version: 4.7.3-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
Perhaps it should just be set to "any" architectures, unlike what I did with the
patch, because it probably builds fine in other architectures too.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru pdns-recursor-4.7.3/debian/changelog
pdns-recursor-4.7.3/debian/changelog
--- pdns-recursor-4.7.3/debian/changelog2022-11-01 16:50:18.0
+
+++ pdns-recursor-4.7.3/debian/changelog2022-11-22 17:18:25.0
+
@@ -1,3 +1,10 @@
+pdns-recursor (4.7.3-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Tue, 22 Nov 2022 17:18:25
+
+
pdns-recursor (4.7.3-2) unstable; urgency=medium
* Set explicit architecture list.
diff -Nru pdns-recursor-4.7.3/debian/control pdns-recursor-4.7.3/debian/control
--- pdns-recursor-4.7.3/debian/control 2022-11-01 16:50:18.0 +
+++ pdns-recursor-4.7.3/debian/control 2022-11-22 17:18:25.0 +
@@ -32,7 +32,7 @@
Rules-Requires-Root: no
Package: pdns-recursor
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Pre-Depends: ${misc:Pre-Depends}
Depends: adduser,
dns-root-data,
Bug#1025039: pdns: Please add support for "riscv64" arch
Source: pdns
Version: 4.7.2-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
Perhaps it should just be set to "any" architectures, unlike what I did with the
patch, because it probably builds fine in other architectures too.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru pdns-4.7.2/debian/changelog pdns-4.7.2/debian/changelog
--- pdns-4.7.2/debian/changelog 2022-11-01 14:24:15.0 +
+++ pdns-4.7.2/debian/changelog 2022-11-22 10:46:12.0 +
@@ -1,3 +1,10 @@
+pdns (4.7.2-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Tue, 22 Nov 2022 10:46:12
+
+
pdns (4.7.2-1) unstable; urgency=medium
* New upstream version 4.7.2
diff -Nru pdns-4.7.2/debian/control pdns-4.7.2/debian/control
--- pdns-4.7.2/debian/control 2022-11-01 14:24:15.0 +
+++ pdns-4.7.2/debian/control 2022-11-22 10:46:12.0 +
@@ -40,7 +40,7 @@
Rules-Requires-Root: no
Package: pdns-server
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: adduser,
${misc:Depends},
${shlibs:Depends}
@@ -57,7 +57,7 @@
serve data.
Package: pdns-tools
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: ${misc:Depends},
${shlibs:Depends}
Description: Tools for DNS debugging by PowerDNS
@@ -81,7 +81,7 @@
* saxfr: AXFR zones and show extra information
Package: pdns-ixfrdist
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Pre-Depends: ${misc:Pre-Depends}
Depends: adduser,
${misc:Depends},
@@ -93,7 +93,7 @@
components to work.
Package: pdns-backend-bind
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -109,7 +109,7 @@
of zones needs to be given in a named.conf-style file.
Package: pdns-backend-pipe
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -125,7 +125,7 @@
questions on stdin and returns answers on stdout.
Package: pdns-backend-ldap
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -139,7 +139,7 @@
This package contains the LDAP backend for the PowerDNS nameserver.
Package: pdns-backend-lmdb
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -153,7 +153,7 @@
This package contains the LMDB backend for the PowerDNS nameserver.
Package: pdns-backend-lua2
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -167,7 +167,7 @@
This package contains the Lua2 backend for the PowerDNS nameserver.
Package: pdns-backend-geoip
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -184,7 +184,7 @@
YAML.
Package: pdns-backend-mysql
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -200,7 +200,7 @@
nameserver. It has configurable SQL statements.
Package: pdns-backend-odbc
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (>= ${source:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -215,7 +215,7 @@
nameserver. It has configurable SQL statements.
Package: pdns-backend-pgsql
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
Depends: pdns-server (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
@@ -231,7 +231,7 @@
nameserver. It has configurable SQL statements.
Package: pdns-backend-sqlite3
-Architecture: amd64 arm64 mips64el
Bug#1025033: aqemu: Please add support for "riscv64" arch
Source: aqemu
Version: 0.9.2-3
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
In fact, there doesn't seem to be fundamental reasons for this package to be
restricted to specific architectures, so perhaps it should just be set to "any"
as I did with the patch.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru aqemu-0.9.2/debian/changelog aqemu-0.9.2/debian/changelog
--- aqemu-0.9.2/debian/changelog2020-12-05 21:45:24.0 +
+++ aqemu-0.9.2/debian/changelog2022-11-28 21:27:17.0 +
@@ -1,3 +1,10 @@
+aqemu (0.9.2-4) UNRELEASED; urgency=medium
+
+ * QA upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Mon, 28 Nov 2022 21:27:17
+
+
aqemu (0.9.2-3) unstable; urgency=medium
* QA upload.
diff -Nru aqemu-0.9.2/debian/control aqemu-0.9.2/debian/control
--- aqemu-0.9.2/debian/control 2020-12-05 21:45:24.0 +
+++ aqemu-0.9.2/debian/control 2022-11-28 21:27:17.0 +
@@ -15,11 +15,11 @@
Vcs-Browser: https://salsa.debian.org/debian/aqemu
Package: aqemu
-Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64
x32
+Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
libqt5dbus5,
Bug#1025032: kicad: Please add support for "riscv64" arch
Source: kicad Version: 6.0.9+dfsg-1 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org Hi, Please enable this architecture, with the patch attached or an equivalent. I built it locally on hardware, it built fine just by enabling the architecture in debian/control, no other changes needed. In fact, there doesn't seem to be fundamental reasons for this package to be restricted to specific architectures, so perhaps it should just be set to "any". Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru kicad-6.0.9+dfsg/debian/changelog kicad-6.0.9+dfsg/debian/changelog --- kicad-6.0.9+dfsg/debian/changelog 2022-10-29 11:54:45.0 + +++ kicad-6.0.9+dfsg/debian/changelog 2022-11-22 10:10:48.0 + @@ -1,3 +1,10 @@ +kicad (6.0.9+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add support for riscv64 arch + + -- Manuel A. Fernandez Montecelo Tue, 22 Nov 2022 10:10:48 + + kicad (6.0.9+dfsg-1) unstable; urgency=medium * [e85c0b0] New upstream version 6.0.9+dfsg diff -Nru kicad-6.0.9+dfsg/debian/control kicad-6.0.9+dfsg/debian/control --- kicad-6.0.9+dfsg/debian/control 2022-10-29 11:41:51.0 + +++ kicad-6.0.9+dfsg/debian/control 2022-11-22 10:10:48.0 + @@ -76,7 +76,7 @@ Homepage: https://www.kicad.org Package: kicad -Architecture: any-amd64 any-i386 arm64 armhf mips64el powerpc ppc64 ppc64el +Architecture: any-amd64 any-i386 arm64 armhf mips64el powerpc ppc64 ppc64el riscv64 Depends: libngspice0, python3-wxgtk4.0 (>= 4.2.0+dfsg-1~),
Bug#1023769: efi-reader: Please add support for "riscv64" arch
Hi Steve, On Sun, 13 Nov 2022 at 00:05, Steve McIntyre wrote: > > Hey Manuel! > > On Wed, Nov 09, 2022 at 10:57:56PM +0100, Manuel A. Fernandez Montecelo wrote: > >Source: efi-reader > >Version: 0.16 > >Severity: wishlist > >Tags: ftbfs patch > >User: debian-ri...@lists.debian.org > >Usertags: riscv64 > >X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org > > > >Hi, > > > >Please enable this architecture, with the patch attached or an equivalent. > > > >I built it locally on hardware, it built fine just by enabling the > >architecture > >in debian/control, no other changes needed. > > Are you sure you need to build efi-reader here? It's mostly a no-op > package on the existing arches already, and I'd be surprised if there > is any use for it on on riscv64. Actually I didn't pay much attention to what the program does, I stumbled upon it when trying to find small packages to test building infra and that was it. At the end of the tests I was submitting these requests for several of the packaes. Being part of debian-installer I imagined that it's needed in some circumstances even if it's a tiny --but perhaps important-- part... there's not much info to go by in the descriptions, and I'm not very familiar with the installer other than as a user. So dunno, I think that you're in a better position to decide whether it's needed or not, I'm happy if you prefer to close this report. Cheers! -- Manuel A. Fernandez Montecelo
Bug#1024041: mariadb-10.6: FTBFS on riscv64: rocksdb/db/memtable.cc:129: undefined reference to `__atomic_compare_exchange_1'
Source: mariadb-10.6 Version: 1:10.6.10-1 Followup-For: Bug #1024041 X-Debbugs-Cc: m...@debian.org, tsu.y...@gmail.com Hi, @Otto: thanks for paying attention to the riscv64 arch, even if not one of the main ones [yet] :-) To provide info, with the patch from Bo Yu (thanks for the patch!) I can build successfully in hardware and in my case the tests pass fine (unless the skipped ones cause any worry): -- The servers were restarted 192 times Spent 3579.615 of 1330 seconds executing testcases Completed: All 1005 tests were successful. 152 tests were skipped, 62 by the test itself. -- So I think that the patch is OK and should be applied, and if anything, the tests could be fixed separately if they keep happening. Best regards. -- Manuel A. Fernandez Montecelo
Bug#1024182: ogre-1.9: Do not include in release "bookworm", out of date
Source: ogre-1.9 Version: 1.9.0+dfsg1-12.1 Severity: serious X-Debbugs-Cc: m...@debian.org This package has been outdated for a few years, nowadays 1.12 should be used. It should not be included in the next stable release, bookworm. -- Manuel A. Fernandez Montecelo
Bug#1024176: RM: aqsis -- ROM; unmaintained upstream for many years
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: m...@debian.org Hi, >From the original author: https://github.com/aqsis/aqsis/issues/10 "I think retiring it makes sense, it is so out of date with modern rendering techniques it serves little purpose other than an educational tool for anyone considering writing their own renderer to see how things might have been done in the past. In that example, folks will more likely be interested in the github repo than an installable package." I kept it afloat for a few years adding patches, moving from Qt4 to Qt5 and so on, but the source has been basically unchanged for a decade and does not keep up with library changes until way too late, etc. Also its usage according to popcon dropped dramatically over time, from less than 1% at the best of times to about 0.02% nowadays. So I think that it's time to retire now, not very worth spending time on it to keep it kicking for the lifetime of the next stable release, especially when --according to the main author-- there are better alternatives now. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On Sun, 13 Nov 2022 at 02:00, Guillem Jover wrote: > > Err sorry, the patch was computing the used memory and not the truly > available one! The updated patch should do better. :) Given Aurélien's tests this is a bit redundant, but since I had the building going I let it finish to add more data points... I couldn't replicate the conditions without stopping buildds, but tried in a similar machine to those of the buildds but with 8GB of RAM and 8GB of swap (on nbd) plus some zram. I filled /dev/shm with files from urandom, 7.5GB of them. The machine kept sending those files to swap as it needed RAM for building the kernel, so when it reached the compression phase there was enough memory to use all threads (4), minimum ~1.3GB in the loop deciding how many threads to use, for example: dpkg-deb: building package 'ext4-modules-6.0.0-2-riscv64-di' in 'debian/.debhelper/scratch-space/build-ext4-modules-6.0.0-2-riscv64-di/ext4-modules-6.0.0-2-riscv64-di_6.0.6-2_riscv64.deb'. - initial mt_options.threads=4 -- loop: mt_options.threads=4, mt_memusage=692517284, mt_memlimit=1357987840 - initial mt_options.threads=4 -- loop: mt_options.threads=4, mt_memusage=692517284, mt_memlimit=1355665408 This is with the default: "vm.swappiness = 60". With systems having this value close to zero not sure if the results would be so positive... but I think that at the point of compressing the resulting packages, there had to be quite a lot of free memory from the previous processes of the compiler and available now to use for compression. So I am not sure if the patch would cover absolutely all corner cases, but it think that it would help to solve the known problems in buildds and it's much better than the current calculation of MemAvailable. Cheers and thanks. -- Manuel A. Fernandez Montecelo
Bug#1023870: dpkg: Problems in buildds due to slow compression
Package: dpkg Version: 1.21.9 Severity: normal X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org (Setting initial severity as "normal" because it affects packages built in buildd machines). Hi, The origins of this bug report are because there are sometimes problems building packages in buildds, the compression phase is very slow and sometimes the build is aborted due to inactivity: E: Build killed with signal TERM after 300 minutes of inactivity [1] After some investigation by aurel32 and myself, this was traced back to the commit f8d254943051e085040367d689048c00f31514c3 [2], in which the calculation of the memory that can be used, to determine the number of threads to use, was changed from half of the physical mem to be based on the memory available. For example in buildds with not-so-large amount of RAM, using part of it for tempfs (which is how buildds are set-up), the reported available memory maybe is not very large. For example it could be MemAvailable=2GB for 16GB of physical RAM in the machine. In the dpkg code, for the purposes of the calculation of how much memory can be used, the result appears to be to be half of the MemAvailable [3], so only 1GB. According to the tables in xz man page, for compression the algorithm can use 674MB. So as a result, dpkg-deb uses single-threaded compression, even if it could easily use 2-3 threads and still use only RAM; or use the full number of threads in the machine (e.g. 4 or 8) even if it means swapping out some of the content of tempfs -- which is not a problem in most cases for buildds, specially if using fast disks. As a result of all this, it is taking upwards of 600 mins of CPU time to compress recent linux-image-*-dbg packages in the buildds of riscv64 architecture at the moment, so when using 2 threads of less, it's guaranteed to be aborted. But this also affects other arches and other packages in other ways, at least by making the build needlessly slow in many cases. It's not very clear what could be the solution for this, as the default could be OK for desktops and many machines in which there's plenty of available RAM, but this is not the case of all of our buildds. It might not be possible to detect which is the best from within dpkg. Maybe it could be through a new variable DPKG_DEB_THREADS (similar to the recently added DPKG_DEB_MAX_THREADS) in which the buildds explicitly set the amount of threads that they want. PS: Bug #501456 [4] is possibly a duplicate, or at least the intersection is largish :) [1] https://buildd.debian.org/status/fetch.php?pkg=linux=riscv64=6.1%7Erc3-1%7Eexp1=1667646869=0 [2] https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=f8d254943051e085040367d689048c00f31514c3 [3] At least that's what I got in my tests as value for mt_memlimit, half of the MemAvailable at the time, even if I expected the full amount of MemAvailable when quickly reading the code. But I didn't pay much attention because this detail is not very important in principle: MemAvailable could be very low if tempfs is using more than the physical RAM, it doesn't matter if it's full or half in many cases with low memory. [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501456 Thanks and cheers. -- Manuel A. Fernandez Montecelo
Bug#1023774: breeze-grub: Please add support for "riscv64" arch
Source: breeze-grub
Version: 5.26.0-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
(For that matter, I suppose that all architectures could be enabled, there
doesn't seem to be any reason for this package to be restricted to specific
architectures).
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru breeze-grub-5.26.0/debian/changelog
breeze-grub-5.26.0/debian/changelog
--- breeze-grub-5.26.0/debian/changelog 2022-10-11 13:43:57.0 +
+++ breeze-grub-5.26.0/debian/changelog 2022-11-04 19:19:44.0 +
@@ -1,3 +1,10 @@
+breeze-grub (5.26.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Fri, 04 Nov 2022 19:19:44
+
+
breeze-grub (5.26.0-1) unstable; urgency=medium
[ Aurélien COUDERC ]
diff -Nru breeze-grub-5.26.0/debian/control breeze-grub-5.26.0/debian/control
--- breeze-grub-5.26.0/debian/control 2022-10-02 16:19:33.0 +
+++ breeze-grub-5.26.0/debian/control 2022-11-04 19:19:44.0 +
@@ -14,7 +14,7 @@
Rules-Requires-Root: no
Package: grub-theme-breeze
-Architecture: any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel
any-powerpc any-ppc64 any-ppc64el any-sparc any-sparc64
+Architecture: any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel
any-powerpc any-ppc64 any-ppc64el any-riscv64 any-sparc any-sparc64
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: Breeze theme for GRUB 2
Breeze theme for the GRUB boot loader to fit in with KDE Plasma's
Bug#1023769: efi-reader: Please add support for "riscv64" arch
Source: efi-reader
Version: 0.16
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru efi-reader-0.16/debian/changelog efi-reader-0.16+nmu1/debian/changelog
--- efi-reader-0.16/debian/changelog2018-08-29 10:14:18.0 +
+++ efi-reader-0.16+nmu1/debian/changelog 2022-11-04 19:21:22.0
+
@@ -1,3 +1,10 @@
+efi-reader (0.16+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Fri, 04 Nov 2022 19:21:22
+
+
efi-reader (0.16) unstable; urgency=medium
* Team upload
diff -Nru efi-reader-0.16/debian/control efi-reader-0.16+nmu1/debian/control
--- efi-reader-0.16/debian/control 2018-08-10 19:21:49.0 +
+++ efi-reader-0.16+nmu1/debian/control 2022-11-04 19:21:22.0 +
@@ -8,7 +8,7 @@
Vcs-Git: https://salsa.debian.org/installer-team/efi-reader.git
Package: efi-reader
-Architecture: ia64 amd64 i386 arm64 armhf
+Architecture: ia64 amd64 i386 arm64 armhf riscv64
Depends: ${shlibs:Depends}
Description: Select default values from EFI configuration.
Package-Type: udeb
Bug#1023768: libsdsl: Please add support for "riscv64" arch
Source: libsdsl
Version: 2.1.1+dfsg-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru libsdsl-2.1.1+dfsg/debian/changelog
libsdsl-2.1.1+dfsg/debian/changelog
--- libsdsl-2.1.1+dfsg/debian/changelog 2019-01-09 23:51:44.0 +
+++ libsdsl-2.1.1+dfsg/debian/changelog 2022-11-09 21:22:27.0 +
@@ -1,3 +1,10 @@
+libsdsl (2.1.1+dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo Wed, 09 Nov 2022 21:22:27
+
+
libsdsl (2.1.1+dfsg-2) unstable; urgency=medium
* Refresh packaging (debhelper 12, std-ver 4.3.0)
diff -Nru libsdsl-2.1.1+dfsg/debian/control libsdsl-2.1.1+dfsg/debian/control
--- libsdsl-2.1.1+dfsg/debian/control 2019-01-09 23:51:44.0 +
+++ libsdsl-2.1.1+dfsg/debian/control 2022-11-09 21:22:27.0 +
@@ -15,7 +15,7 @@
Homepage: https://github.com/simongog/sdsl-lite
Package: libsdsl-dev
-Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el s390x
sparc64 x32
+Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el riscv64
s390x sparc64 x32
Multi-Arch: same
Section: libdevel
Depends: libdivsufsort-dev, libsdsl3 (= ${binary:Version}), ${misc:Depends}
@@ -33,7 +33,7 @@
This package installs development files.
Package: libsdsl3
-Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el s390x
sparc64 x32
+Architecture: alpha amd64 arm64 kfreebsd-amd64 mips64el ppc64 ppc64el riscv64
s390x sparc64 x32
Multi-Arch: same
Section: libs
Depends: libjs-d3, ${misc:Depends}, ${shlibs:Depends}
Bug#1023529: subversion: FTBFS: segfault in Python tests with SWIG 4.1.0
Package: subversion
Followup-For: Bug #1023529
X-Debbugs-Cc: m...@debian.org, 1023529-submit...@bugs.debian.org
Hi,
I built a version of the package with the mentioned patch (debdiff attached), it
built correctly and passed all tests.
This was in riscv64, where the problem was detected, but I expect that it would
apply to all arches.
Hope that helps.
--
Manuel A. Fernandez Montecelo
diff -Nru subversion-1.14.2/debian/changelog subversion-1.14.2/debian/changelog
--- subversion-1.14.2/debian/changelog 2022-07-12 16:03:54.0 +0200
+++ subversion-1.14.2/debian/changelog 2022-11-08 10:57:37.0 +0100
@@ -1,3 +1,10 @@
+subversion (1.14.2-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Patch to fix "FTBFS: segfault in Python tests with SWIG 4.1.0" (Closes:
#1023529)
+
+ -- Manuel A. Fernandez Montecelo Tue, 08 Nov 2022 09:57:37
+
+
subversion (1.14.2-3) unstable; urgency=medium
* Re-enable the ability to store plaintext passwords (Closes: #995692)
diff -Nru
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
---
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
1970-01-01 01:00:00.0 +0100
+++
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
2022-11-08 10:57:37.0 +0100
@@ -0,0 +1,61 @@
+From 8ff4cfd06ce554e9df31a088c9d09f45278c6de4 Mon Sep 17 00:00:00 2001
+From: Yasuhito Futatsuki
+Date: Tue, 20 Sep 2022 12:57:06 +
+Subject: [PATCH] swig-py: Fix conditionals by SWIG version and by Python
+ version for proxy code.
+
+We are using different code for proxy object, by Python version and by SWIG
+version. The distinguish between Python 2 and Python 3 was done by SWIG
+macro "SWIGPYTHON_PY3". However, the macro was dropped since SWIG commit
+a343b7e[1], between SWIG 4.0.2 release and upcoming SWIG 4.1.0 release.
+
+As we already dropped support for the combination of SWIG >= 4.0 and Python 2,
+we should detect Python 2 only in SWIG < 4.0 case. So we can rely on the macro
+only in the case.
+
+* subversion/bindings/swig/include/proxy.swg ():
+ Reorder the conditionals distinguish SWIG versions and Python versions,
+ as described above.
+
+Found by: Jitka Plesnikova (jplesnik {_AT_} redhat.com)
+
+Suggested by: Julien Schueller (schueller {_AT_} phimeca.com) [2]
+
+[1]
https://github.com/swig/swig/commit/a343b7e254567a64761bc1be7dc55b7b7424ec52
+[2] https://github.com/swig/swig/issues/2373#issuecomment-1250997124
+
+
+git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1904167
13f79535-47bb-0310-9956-ffa450edef68
+---
+ subversion/bindings/swig/include/proxy.swg | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+Index: subversion-1.14.2/subversion/bindings/swig/include/proxy.swg
+===
+--- subversion-1.14.2.orig/subversion/bindings/swig/include/proxy.swg
subversion-1.14.2/subversion/bindings/swig/include/proxy.swg
+@@ -66,7 +66,6 @@
+ fn()
+
+ %}
+-#if defined(SWIGPYTHON_PY3)
+ #if SWIG_VERSION >= 0x04
+ %pythoncode %{
+ # -classic and -modern options have been dropped and this variable
+@@ -76,7 +75,7 @@
+ _set_instance_attr =
_swig_setattr_nondynamic_instance_variable(object.__setattr__)
+
+ %}
+-#else
++#elif defined(SWIGPYTHON_PY3)
+ %pythoncode %{
+ # SWIG classes generated with -modern do not define this variable
+ try:
+@@ -90,7 +89,6 @@
+ _set_instance_attr = _swig_setattr_nondynamic_method(object.__setattr__)
+
+ %}
+-#endif
+ #else
+ %pythoncode %{
+ # SWIG classes generated with -classic do not define this variable,
diff -Nru subversion-1.14.2/debian/patches/series
subversion-1.14.2/debian/patches/series
--- subversion-1.14.2/debian/patches/series 2022-07-12 16:03:54.0
+0200
+++ subversion-1.14.2/debian/patches/series 2022-11-08 10:57:37.0
+0100
@@ -10,3 +10,4 @@
examples-compile-instructions
workaround_EINVAL_on_kfreebsd
use-python3-as-the-interpreter-now-for-tests-not-python.patch
+8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
Bug#1023338: rakudo: Please add support for "riscv64" arch
Source: rakudo
Version: 2022.07-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine and passed tests just by enabling
the architecture in debian/control, no other changes needed.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru rakudo-2022.07/debian/changelog rakudo-2022.07/debian/changelog
--- rakudo-2022.07/debian/changelog 2022-10-02 17:28:35.0 +0200
+++ rakudo-2022.07/debian/changelog 2022-11-02 11:44:18.0 +0100
@@ -1,3 +1,10 @@
+rakudo (2022.07-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for riscv64
+
+ -- Manuel A. Fernandez Montecelo Wed, 02 Nov 2022 10:44:18
+
+
rakudo (2022.07-2) unstable; urgency=medium
* refresh fix-test patch
diff -Nru rakudo-2022.07/debian/control rakudo-2022.07/debian/control
--- rakudo-2022.07/debian/control 2022-10-02 17:28:35.0 +0200
+++ rakudo-2022.07/debian/control 2022-11-02 11:44:18.0 +0100
@@ -22,7 +22,7 @@
Rules-Requires-Root: no
Package: rakudo
-Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips
mips64el mipsel powerpc ppc64 ppc64el s390x x32
+Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32
Depends: ${misc:Depends},
${moarvm:Depends},
${nqp:Depends},
Bug#1023337: nqp: Please add support for "riscv64" arch
Source: nqp
Version: 2022.07+dfsg-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
Hi,
Please enable this architecture, with the patch attached or an equivalent.
I built it locally on hardware, it built fine and passed tests just by enabling
the architecture in debian/control, no other changes needed.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru nqp-2022.07+dfsg/debian/changelog nqp-2022.07+dfsg/debian/changelog
--- nqp-2022.07+dfsg/debian/changelog 2022-09-26 01:03:49.0 +0200
+++ nqp-2022.07+dfsg/debian/changelog 2022-11-02 11:55:14.0 +0100
@@ -1,3 +1,10 @@
+nqp (2022.07+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add riscv64 support
+
+ -- Manuel A. Fernandez Montecelo Wed, 02 Nov 2022 10:55:14
+
+
nqp (2022.07+dfsg-1) unstable; urgency=medium
* Upload to unstable.
diff -Nru nqp-2022.07+dfsg/debian/control nqp-2022.07+dfsg/debian/control
--- nqp-2022.07+dfsg/debian/control 2022-08-18 01:31:59.0 +0200
+++ nqp-2022.07+dfsg/debian/control 2022-11-02 11:55:14.0 +0100
@@ -19,7 +19,7 @@
Rules-Requires-Root: no
Package: nqp
-Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips
mips64el mipsel powerpc ppc64 ppc64el s390x x32
+Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32
Depends: ${misc:Depends},
${moarvm:Depends},
${shlibs:Depends},
Bug#959498: efibootmgr: Any new progress on this report?
Control: tags -1 + pending Hi, On Mon, 26 Sept 2022 at 19:24, Yifan Xu wrote: > > Dear Maintainer, > > Any new progress on this report? The code is same as the ubuntu version, and > EFI support on riscv will need this package. > > Thank you. > > Yifan Xu It seems that the current source in Salsa [1] already contains the architecture field for riscv64, and another few new ones. To the maintainers: It would be great if you could make a new release, if you need any help from porters please let us know. [1] https://salsa.debian.org/efi-team/efibootmgr/-/blob/debian/debian/control Cheers. -- Manuel A. Fernandez Montecelo
Bug#1016373: deviceinfo: ftbfs on risc64 arch("error: some symbols or patterns disappeared in the symbols file")
Hi again, On Tue, 30 Aug 2022 at 18:24, Manuel A. Fernandez Montecelo wrote: > > Hi, > > On Sat, 30 Jul 2022 at 15:54, Bo YU wrote: > > > > Source: deviceinfo > > Version: 0.1.0-7 > > Severity: normal > > Tags: ftbfs, patch > > User: debian-ri...@lists.debian.org > > Usertags: riscv64 > > X-Debbugs-Cc: debian-ri...@lists.debian.org > > > > Dear deviceinfo Maintainer, > > > > The deviceinfo package has a ftbfs issue on riscv64 arch due to missing > > symbols: > > > Thanks for your report. > > I gave back the package to be built again, as it happened around the > time of the transition from GCC-11 to -12 and other packages like > khtml had the same problems, but were fine and didn't need > modifications after being rebuilt. So let's cross fingers :-) Failed again with symbols errors, so I guess that the patch is needed in this case. https://buildd.debian.org/status/fetch.php?pkg=deviceinfo=riscv64=0.1.0-7=1661877711=0 -- Manuel A. Fernandez Montecelo
Bug#1016373: deviceinfo: ftbfs on risc64 arch("error: some symbols or patterns disappeared in the symbols file")
Hi, On Sat, 30 Jul 2022 at 15:54, Bo YU wrote: > > Source: deviceinfo > Version: 0.1.0-7 > Severity: normal > Tags: ftbfs, patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: debian-ri...@lists.debian.org > > Dear deviceinfo Maintainer, > > The deviceinfo package has a ftbfs issue on riscv64 arch due to missing > symbols: Thanks for your report. I gave back the package to be built again, as it happened around the time of the transition from GCC-11 to -12 and other packages like khtml had the same problems, but were fine and didn't need modifications after being rebuilt. So let's cross fingers :-) -- Manuel A. Fernandez Montecelo
Bug#936777: k3d: Python2 removal in sid/bullseye
Hi, On Sun, 10 Apr 2022 at 22:04, Moritz Mühlenhoff wrote: > > Revisiting this two years later; I really think k3d should be removed now? > Nothing changed upstream and at this point it's uninstallable in unstable > for many other libraries besides Python 2: > > - > The following packages have unmet dependencies: > k3d : Depends: libboost-program-options1.67.0 but it is not installable >Depends: libboost-python1.67.0 but it is not installable >Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not installable >Depends: libcgal13 but it is not installable >Depends: libopenexr24 (>= 2.3.0) but it is not installable > E: Unable to correct problems, you have held broken packages. > - Indeed, I paid attention to your other bug report (sorry but I hadn't seen this yet, terrible months for me and huge backlog) and sent the necessary incantations to control@ to ask for removal, I hope. If upstream keeps inactive there's not much that we can do at this point. Thanks for keeping an eye on this! -- Manuel A. Fernandez Montecelo
Bug#1016983: Should k3d be removed?
Hi Moritz, On Wed, 10 Aug 2022 at 22:33, Moritz Muehlenhoff wrote: > > Source: k3d > Version: 0.8.0.6-8 > Severity: serious > > Your package came up as a candidate for removal from Debian: > > - Python 2 will finally be removed in Bookworm and there's no > upstream porting activity > - Last upload four years ago > - Multiple other FTBFS issue > > If you disagree and want to continue to maintain this package, > please just close this bug (and fix the open issues). > > If you agree with the removal, please reassign to ftp.debian.org > by sending the following commands to cont...@bugs.debian.org: > > -- > severity $BUGNUM normal > reassign $BUGNUM ftp.debian.org > retitle $BUGNUM RM: -- RoM; > thx > -- > > Otherwise I'll move forward and request it's removal in a month. Thanks, I'll ask for removal because upstream is basically dead and hadn't moved when I requested to migrate away from GTK2 and Python2... I very much doubt that there's any advance before the freezes... https://github.com/K-3D/k3d/issues/38 https://github.com/K-3D/k3d/issues/30 Cheers. -- Manuel A. Fernandez Montecelo
Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi, On Thu, 4 Aug 2022 at 18:03, Axel Beckert wrote: > > Hi Manuel, > > TL;DR: Please grant me cwidget team membership on Salsa so we don't > have to NMU it. Or just do an upload of cwidget with the patch from > #1015925. > > I know you're busy with RISC-V and other stuff, but please do me a > small favour and add me to the cwidget team on Salsa, probably via > https://salsa.debian.org/groups/cwidget-team/-/group_members Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to spare in the last few years, and even there I'm lacking :-( I had seen this from pabs but will not have time at least until mid next week, so better if you do it and have permissions in general anyway, as you say. Thanks both of you, pabs and abe, for taking care! -- Manuel A. Fernandez Montecelo
Bug#992309: [Aptitude-devel] Bug#992309: apt: term.log aborts when packages have failures but installation is retried
Hi,
(I know that sometimes some of those who will read this put me in copy
hoping to get a reply from me about other bugs, but in the last couple
of years I cannot cope and my work in Debian is mostly restricted to the
riscv64 port, sorry. I happened to see this by chance, so replying to
it).
2021-08-17 11:43 David Kalnischkies:
On Tue, Aug 17, 2021 at 03:13:20AM +0200, Christoph Anton Mitterer wrote:
I've seen the following already few times, but always used apt via aptitude,
so maybe the problem is actually within that.
What happens is the following:
- I upgrade/install/remove a number of packages.
- Amongt one/several of them there is an error during installation and one
gets a line like:
Errors were encountered while processing:
packagename1
packagename2
...
- At the point, /var/log/apt/term.log ends with the ususal:
Log ended:
- However, aptitude seems to retry once...
A quick look at the code (src/generic/apt/download_install_manager.cc)
suggests aptitude runs 'dpkg --configure -a' explicitly if libapt reports
encountering a failure and as such completely runs outside the control
of libapt and its logging (among many other things).
A quick git blame isn't very conclusive on why that is done, just that
it seems to be done for at least 10 years.
Actually, the oldest reference in git:
commit db949f313eb10b747a875067623b89c47ee2b81d
Author: Daniel Burrows
Date: Sat Oct 1 23:40:49 2005 +
[aptitude @ Import the Subversion repository into darcs.]
The oldest repos in SVN and (I think that other version-control-systems
for some period) are lost, I am afraid.
There's another comment in this commit, although it doesn't really shed
much light into it, just that it's somehow needed:
commit 9e3f959f55bb500f82f690df2e66be052d8e0ae0
Author: Daniel Burrows
Date: Sun Apr 22 16:12:45 2007 +
[aptitude @ Add DPKG_NO_TSTP to the environment when configuring packages
after something failed to install. (Closes: #367052)]
Apparently this is necessary to keep things sane. It would be nice if I
could call on apt to do this, but apt doesn't expose a wrapper around
"dpkg --configure -a".
There are other more recent changes touching this line, but most are not
very relevant or don't add anything new to the reasons why this is
needed.
In 2016 I made another change:
commit e8f0ba7f42e784d4a3886904d1425b642b7d7433
Author: Manuel A. Fernandez Montecelo
Date: Thu Mar 3 00:52:30 2016 +
Fix problem with recent change that prevented to work with local
repositories (Closes: #816537)
Even if we would like to not have to get locks and have to call
fetcher->Run() if no (remote) fetch is needed (see #766122), it is needed
anyway to work with local repositories (see #816537).
In which, for some reason that I cannot explain, included this change:
case pkgPackageManager::Failed:
_error->DumpErrors();
- cerr << _("Failed to perform requested operation on package. Trying to
recover:") << endl;
+ //cout << _("Failed to perform requested operation on package. Trying to
recover:") << endl;
if(system("DPKG_NO_TSTP=1 dpkg --configure -a") != 0) { /* ignore */ }
break;
So presumably at that point, 5 years ago, at least printed a message,
but I am not sure if I committed the above as a mistake when doing other
changes to the same file, or what was the reason for that.
I am not sure if its a good idea to run that always unconditionally, but
then it is likely what a user runs unconditionally manually anyway, and
not much different to what happens if you run things like 'apt install
--fix-broken', as you either luck out or not so…
So perhaps we should indeed offer a way to do this a bit more automatic
for the user. I would first like to hear if the current aptitude devs
have any idea why that is run and their opinion on it though.
(This could be a reassign, but all they could do is removing the line
in question or reassign it back to us as a feature wish, so lets skip
the ping pong for now while thinking about this a bit longer)
aptitude always wanted to be more helpful/opinionated than apt and so
more aggressive with doing these kind of changes without asking, and
perhaps at the time that this was implemented the breakages were
occurring more often and asking was annoying.
As you say, I think that running "dpkg --configure -a" or an equivalent
is the only reasonable thing to do at that point, either automatically
from a tool or asking the user to do it.
Maybe it is a good idea to run first "apt install --fix-broken" to get
it logged in apt's logs, and defauling to "dpkg --configure -a" as last
resort.
And perhaps also asking confirmation about this to the user, or at least
restoring the message warning about this.
So I think that this is only relevant for apt if
Bug#954872: buildd.debian.org: Legends for the graphs on https://buildd.debian.org/stats/ half-gone
Hi,
2020-03-24 19:04 Aurelien Jarno:
On 2020-03-24 18:47, nabijaczleweli wrote:
Package: buildd.debian.org
Severity: normal
Hello,
The legends for the graphs on https://buildd.debian.org/stats/ seem to
be partway gone, mostly affecting the colour and start of the
architecture name.
See the attached graph.png, taken from the site as I write this.
This is a know issue, due to a change in the R packages in Debian
Buster. If someone has good knowledge of R, patches are welcome.
I tried to create a merge request in salsa but could not, for some reason.
I attach a patch that fixes this, at least when downloading the data and
generating the files locally with recent versions of the packages from
unstable.
But if not, it's easy to see how to further tweak the values, based on
the patch.
Hope that helps.
Cheers.
--
Manuel A. Fernandez Montecelo
diff -ur a/graph-ports.R b/graph-ports.R
--- a/graph-ports.R 2020-07-01 01:01:59.514162160 +0200
+++ b/graph-ports.R 2020-07-01 01:02:18.706266654 +0200
@@ -19,7 +19,7 @@
plotwb <- function (file,title,p,linept=85,height=7.5,width=10,pch=1:18) {
bitmap(file=file,type="png16m",width=width,height=height,res=64)
- layout(matrix(c(1,1,2,2),2,2),widths=c(0.85,0.15))
+ layout(matrix(c(1,1,2,2),2,2),widths=c(0.80,0.20))
par(mar=c(5,4,4,2)+0.1)
par(lab=c(10,10,7))
plot(p,type="o",plot.type="single",col=1:18,pch=pch,xlab="date",
@@ -29,7 +29,7 @@
axis(4)
plot.new()
par(plt=c(0,1,0,1))
- legend(-1.2,1, arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)
+ legend('topright', arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)
}
v <- readdata("/srv/wanna-build/etc/graph-ports-data",1)
plotwb("/srv/buildd.debian.org/web/stats/graph-ports.png","What percent is built for each architecture",v,85,7.5,10,".")
diff -ur a/graph.R b/graph.R
--- a/graph.R 2020-07-01 01:01:38.710048877 +0200
+++ b/graph.R 2020-07-01 01:03:00.938496574 +0200
@@ -35,7 +35,7 @@
plotwb <- function (file,title,p,linept=85,height=7.5,width=10,pch=1:18) {
bitmap(file=file,type="png16m",width=width,height=height,res=64)
- layout(matrix(c(1,1,2,2),2,2),widths=c(0.85,0.15))
+ layout(matrix(c(1,1,2,2),2,2),widths=c(0.715,0.285))
par(mar=c(5,4,4,2)+0.1)
par(lab=c(10,10,7))
plot(p,type="o",plot.type="single",col=1:18,pch=pch,xlab="date",
@@ -45,7 +45,7 @@
axis(4)
plot.new()
par(plt=c(0,1,0,1))
- legend(-1.2,1, arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)
+ legend('topright', arch, col=1:18, pch=pch, lwd=2, bg='gray90', cex=1.5)
}
v <- readdata("/srv/wanna-build/etc/graph-data",164)
plotwb("/srv/buildd.debian.org/web/stats/graph.png","What percent is built for each architecture",v,85,7.5,10,".")
signature.asc
Description: PGP signature
Bug#936777: k3d: Python2 removal in sid/bullseye
Hi! Em 26 de mai. de 2020 às 20:43, Moritz Mühlenhoff escreveu: > > On Wed, Sep 04, 2019 at 12:10:39AM +0200, Manuel A. Fernandez Montecelo wrote: > > Control: forwarded -1 https://github.com/K-3D/k3d/issues/38 > > > > Thanks for the report. Asking upstream about their plans and best > > course of action. > > Given upstream's reply at https://github.com/K-3D/k3d/issues/38 this > seems unlikely to get ported, let's remove k3d? Basically I'd like to extend its life in Debian and keep users using this package rather than having to build the version themselves, as long as it doesn't become a big burden for Debian -- when it does sure, let's drop it, and if the moment is now, so be it. This package is in a bad situation with Python2 and GTK dependencies, but this is not the kind of application like a media player or similar for which there are a gazillion alternatives with more or less the same features -- this is a pretty specialized piece of software and migration to some other tool can be a huge undertaking and might not always be possible. If the relevant Python2 packages are going to be removed imminently, that's OK, we can remove it now. And in any case, this package should prevent the removal of Python2 if it's one of the last dependencies. But if Python2 it's to be held for a few months/years because other important/popular packages are not migrated yet (gnat-gps, kodi?), and even if only to keep it for unstable, I'd prefer to remove this package only when Python2 is removed. Cheers and thanks for your work. -- Manuel A. Fernandez Montecelo
Bug#945875: openmw: Crash when saving
2020-03-27 09:29 Alberto Luaces: On 27/3/20 8:26, Bret Curtis wrote: The best way forward in resolving this bug is to get OpenSceneGraph package bumped to 3.6.5 right away. This requires the help of Alberto Fernández, it's package maintainer. https://tracker.debian.org/pkg/openscenegraph Him, OSG 3.6.5 is ready (https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/blob/master/debian/changelog), I'm just waiting for Manuel to upload it. Yep, sorry for the delay, I had told Alberto that I would be available in late March, but... Anyway, uploading to experimental now, so if everything goes well Alberto can move it to unstable in the next days. Cheers! -- Manuel A. Fernandez Montecelo
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
or similar and I failed to notice (which can easily happen, I have not been very active lately on many fronts). For games, most of the cases that I know of in which we have games in contrib is because of free game engines or "clones" that need non-free data from the original games or similar, not "snaps" or flatpaks or similar. (I have the impression that pabs misunderstood the intention and was talking about upstream providing alternatives to snap, not Debian, but let's not enter that territory.) > > If users want to install Snap packages, they can always do so on their own. > > They can. I'm just trying to provide a transition path that will > eventually lead to the main packaging of the updated upstream software. What I am concerned about is that you're susbtituting a normal package for a snap package and people might acquire it by upgrading it without any notice, that's why I am raising the flag. So, as I see it, while you provide a convenience to those who are OK with it, you're providing a semi-hidden *inconvenience* to people who don't want it to happen. I know that your intention is to help those who want to keep Ember installed and are OK with a snap package, but I wanted to raise the flag and protect users from installing stuff without intending it and without much of a notice. At least, I would be surprised if that would happen to me, that's why I am raising it. Cheers. -- Manuel A. Fernandez Montecelo
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Package: ember Version: 0.8.0~snap1 Severity: serious Hello, I don't think taht using this package as an empty shell and a gateway to install the "snap" package [1] is a valid use of the packaging system. Otherwise, if this was an accepted practice, we could start to have many packages which are just a way to install snap packages, which can easily contain security vulnerabilities and install not free software, specially if the version is not restricted in some way. And this not generally expected by users of Debian, IMO. If users want to install Snap packages, they can always do so on their own. So please reconsider and either package the game properly or drop this package altogether. [1] https://salsa.debian.org/games-team/ember/blob/master/debian/ember.preinst Cheers. -- Manuel A. Fernandez Montecelo
Bug#897660: closed by "Gudjon I. Gudjonsson" (reply to gud...@gudjon.org) (qscintilla2: Please update symbols for riscv64)
Em qui., 26 de dez. de 2019 às 21:57, Debian Bug Tracking System escreveu: > -- Forwarded message -- > From: "Gudjon I. Gudjonsson" > To: 897660-d...@bugs.debian.org > Cc: > Bcc: > Date: Thu, 26 Dec 2019 21:30:06 +0100 > Subject: qscintilla2: Please update symbols for riscv64 > Source: qscintilla2 > Version: 2.11.2+dfsg-5 > > Hi Manuel > > Finally qscintilla2 is built for riscv64 so I'm closing your bug. > I hope your bugs will be fixed faster next time. Thanks a lot! -- Manuel A. Fernandez Montecelo
Bug#875075: [openscenegraph] Future Qt4 removal from Buster
Hi, Em sáb, 12 de out de 2019 às 13:23, Sebastiaan Couwenberg escreveu: > > I suggest to first update src:openscenegraph to 3.6. > > Once that's in unstable file bugreports for the src:openscenegraph-3.4 > rdeps to have them migrate to 3.6. I uploaded the new version on Alberto's behalf, initially to experimental. Hoping that it doesn't take too long to pass NEW and that everything goes well, but then the move to unstable can be immediate. Cheers. -- Manuel A. Fernandez Montecelo
Bug#892923: aptitude: After upgrading ncurses, aptitude fails to correctly display dialog windows and align columns
Hi, Em 16 de out de 2019 às 23:10, Sven Joachim escreveu: > > Based on the screenshot Jiri sent in his original bug report, I think > this is #894315 in konsole and #933053 in ncurses-base. Both have been > fixed in the meantime, so I am taking the liberty to close this bug as > well. Thanks for chasing, Sven. Unless Jiri has any objection and can reproduce the problem, I am happy with it. -- Manuel A. Fernandez Montecelo
Bug#939296: RM: razorqt -- ROM; dead upstream, depends on Qt4 which is going to be removed
Package: ftp.debian.org Severity: normal Hi, Please remove razorqt from unstable, it is dead upstream and it depends on Qt4 which is going to be removed. Related bug reports: https://bugs.debian.org/875169 https://bugs.debian.org/784181 Cheers. -- Manuel A. Fernandez Montecelo
Bug#935775: libcwidget4: should not ship files conflicting with libcwidget3v5
Control: tags -1 + pending Hi Sven, Em seg, 26 de ago de 2019 às 20:33, Sven Joachim escreveu: > On 2019-08-26 07:55 +0200, Sven Joachim wrote: > > > Package: libcwidget4 > > Version: 0.5.18-3 > > > > The libcwidget4 package ships its translations under > > /usr/share/locale/*/LC_MESSAGES/libcwidget3.mo. This is bad, because > > these files conflict with the ones from libcwidget3v5, they should be > > named /usr/share/locale/*/LC_MESSAGES/libcwidget4.mo instead. > > > > See bug #655689[1] for the initial discussion about including the soname in > > the translation file names, and why these are currently called > > libcwidget3.mo rather than just libcwidget.mo. > > Attached is a patch against the master branch in cwidget-upstream which > takes care of that, I have not looked what it would take to apply it to > the Debian packaging. Thanks for the fix and the explanations. > Having to change three files for an SONAME bump is not great. Another > option would be to set the domain back to 'cwidget' and ship the > translations in their own package, say libcwidget-l10n. Then both > libcwidget4 and a later libcwidget5 package could declare a relationship > to libcwidget-l10n, probably Recommends. There's been only this one SONAME change in the last decade or so, so I think that we're fine with the current method :) So I will upload this during the afternoon, thanks for the help. -- Manuel A. Fernandez Montecelo
Bug#935615: [Aptitude-devel] Bug#935615: aptitude: FTBFS on amd64
Hi, Em dom, 25 de ago de 2019 às 16:27, Axel Beckert escreveu: > > Hi Manuel, > > Ivo De Decker wrote: > > A binnmu of aptitude in unstable fails on amd64: > > > > https://buildd.debian.org/status/package.php?p=aptitude > > Do you happen to know if any of your recent commits to the master > branch already fixes this issue? I haven't found any which looks > fitting on a first glance... > > If you can pinpoint one or more commits, I can cherry pick them and do > a quick upload to fix this issue. Actually the more direct cause to the build error it's commit 2591a1d9069eb2e75087737c25b41449b68bd248 in cwidget. I worked on it in May/June, along with other changes in cwidget, but then it took a while in the NEW queue to get uploaded to experimental, so the window of opportunity for me to work on it went away... Maybe with that patch to cwdiget is enough, but maybe not; there are more changes needed for Boost for example, not sure what's the default version of boost now, but if not now the adaptation will be needed soon. More in general, what it needs to happen is to move cwidget 0.5.18-1 to unstable (as -2 or whatever), then rebuild aptitude against it (would be a transition, but aptitude is the only package depending on cwidget), and releases cwidget 0.5.19 and aptitude 0.8.12 as well -- it contains fixes for the upcoming apt 1.9 and other things. Maybe I can start by moving cwidget to unstable and either binNMUing or releasing the new aptitude version? Cheers. -- Manuel A. Fernandez Montecelo
Bug#798559: cwidget: Restore old signal handlers after handling the signal
Control: tags -1 + pending -- Manuel A. Fernandez Montecelo
Bug#412830: Ctrl-Z + fg confuses aptitude: down arrow runs reportbug
Control: tags -1 + pending -- Manuel A. Fernandez Montecelo
Bug#802648: [Aptitude-devel] Bug#802648: aptitude: definite loop when searching "youk" in "youtube-dl" package info page
Control: tags -1 + pending 2016-06-12 13:25 Manuel A. Fernandez Montecelo: I've been investigating this again and I believe that it's actually a problem with the cwidget library, that has happened since forever. This happens also for example with devscripts and rhythmbox-plugins, which have a long description which makes the main/first subtree (the one with the package name, the second subtree is "Depends") to also "fill" my terminal (expand more than a screenful vertically), like youtube-dl. It doesn't happen with libwiretap5 even if the description is quite long, for example. I think that it has to do with how the cwidget implementation moves the view to jump to where the term being searched appears, and that gets confused when the contents are off the screen or something similar. The backtrace points to line 854 in ./src/cwidget/widgets/tree.cc with the line: while(curr!=start && !matches(*curr)) and with aptitude's menu_tree.cc, line 82. Searching for "yo" in "youtube-dl" screen doesn't produce the desired effect (I presume), of searching e.g. inside the Description field. When the screen starts at line "zero" [1], with incsearch enabled, "y" jumps to the line below [2], after "yo" jumps to the last line (below [3]), after "you" the same (and at this point it didn't hang yet, one can delete with backspace etc). With "youk" enters the infinite loop. If one presses "yok", or "youk", it also triggers the infinite loop. It will need quite some debugging, and probably a new cwidget release to get this fixed. Marking as pending. I append here the commit message: Avoid endless loop when searching in "package info screen" (Closes: #802648) Long explanation because it took a long while to dig all this info and understand the problem, and if this is recorded it can help to explain many of the problems and circumstances that concur. When the widget in focus is large (mostly a package with a very long description that is larger than the screen; and the view is completely filled by this description and doesn't there are no other tree nodes in focus --like the main package name at the top, or Depends or others in the bottom--), then a search which doesn't lead to other elements of the tree enters in an endless loop. As the original report explains, this is triggered for example with the package "youtube-dl" which contains a long description with many of the websites that it supports, in the "package info screen", and when the scroll is moved 1 line down, so the only thing visible (even in a moderately large screen) is part of this description. When typing "/" to start search and then "you", the page starts to jump for the incremental search (matching for example the first version of the package that appears as node under "Versions of youtube-dl"), but then if a further "k" is typed, as the original reported did (presumably to verify if the program supported sites named "youku" and "youku:show" that appear in the description), it doesn't match any other node in the tree and it entered an endless loop. The code does not support search within this kind of special node, which it could do; but failing that what it should happen instead is that, in the absence of matches, it goes back to the original view. The reason why this happens is not fully understood, the code is messy and difficult to grok. It seems that the loops expect to stop when either there's a match or when "curr == start" (so it went through all elems and didn't find a match), but this never ends up happening, either because the iteration (which involves C++ operators and iterators traversing either hierarchical or flat version of the tree) doesn't really go through all of the nodes or because they are not considered because they are "out of view". The node where the description appears is not a regular node of the tree, it is one bolted with many package related fields like Description and Homepage, but different from the rest of the nodes of the tree which are only package names, versions, dependencies and so on. The code was clearly designed with these simpler nodes in mind, and the node with the Description is clearly an abuse of the concept. So basically the best solution found to avoid the endless loop was to just stop when the loop goes through "end" for second time, if there were no matches. It's not optimal, but acceptable in terms of performance, specially having into account that it's not an operation performed in tight loops and the difference is not noticeable with other searches. A proper solution would mean to really redesign both cwidget and packages using it like aptitude so the info page is not designed as a tree and then riding one of the nodes with all sorts of extra information which is not searchable. Cheers. -- Manuel A. Fernandez Montecelo
Bug#801821: cwidget: string dialogs/editline should allow to put the cursor at the end of the line
Control: tags -1 + pending 2015-10-15 00:24 Manuel A. Fernandez Montecelo: Source: cwidget Severity: wishlist ::dialog::string() or editline should put the cursor at the end of the line by default, or provide a way to achieve that. See aptitude's #613794 for explanation and discussion. Implemented, marking this bug as +pending. -- Manuel A. Fernandez Montecelo
Bug#818046: cwidget: keybindings::get(std::string tag) should use tag as case-insensitive
Control: tags -1 + pending 2016-03-13 02:37 Manuel A. Fernandez Montecelo: Source: cwidget Version: 0.5.17-4 Severity: important When inserting with set() the tag it's stored as uppercase, so get() should do the same transformation, otherwise it's confusing and appears to be buggy. This has been committed for 0.5.19, marking as pending. -- Manuel A. Fernandez Montecelo
Bug#896181: cwidget: [PATCH] Use %p for pointers instead of %x
Control: tags -1 + pending 2018-04-20 16:42 Manuel A. Fernandez Montecelo: Source: cwidget Version: 0.5.17-7 Severity: normal Tags: patch upstream Hi, Attaching patch from Ahmed Charles sent to the mailing list a while ago: https://alioth-lists-archive.debian.net/pipermail/cwidget-devel/2016-March/000251.html Applied now in the upstream branch for 0.5.19. -- Manuel A. Fernandez Montecelo
Bug#929966: g++-8: ICE (SIGILL in collect2) building musescore-snapshot on riscv64
Hi, Em qua, 5 de jun de 2019 às 20:06, Thorsten Glaser escreveu: > > Dear porters, could you please… > > Matthias Klose dixit: > > >Control: tags -1 + moreinfo > > > >please add the preprocessed source. > > … because I’ve just seen this fail in the buildd QA. The machine was in a not very good state, I am giving the package back. If the problem persists I can try to look at it closer during the weekend. Cheers. -- Manuel A. Fernandez Montecelo
Bug#923365: ftgl: FTBFS in sid (LaTeX error)
> Big oops! Sorry, I have now double-checked and the report was based on > a build log dated 2019-02-26, but apparently it took a while for me to > actually submit the bug. The underlying bug in texlive was fixed in > the meantime. No problem, thanks for the re-check :) > The package is sunny everywhere here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ftgl.html It was "cloudy", "stormy" or whatever the appropriate term, until yesterday, I checked when writing my last email. But yeah, better to have a false-positive than to have an undetected FTBFS for months during the freeze, so thanks again for checking and the reporting ;-) -- Manuel A. Fernandez Montecelo
Bug#923365: ftgl: FTBFS in sid (LaTeX error)
Control: tags -1 + moreinfo
Hi Santiago!
2019-02-26 23:28 Santiago Vila:
Package: src:ftgl
Version: 2.4.0-2
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
(Yes, I know that it built ok 4 hours ago, but apparently not anymore)
[...]
debian/rules binary-arch
dh binary-arch
dh_update_autotools_config -a
dh_autoreconf -a
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.auto'.
libtoolize: copying file '.auto/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:31: installing '.auto/compile'
configure.ac:12: installing '.auto/config.guess'
[... snipped ...]
! Missing \cr inserted.
\cr
l.40 \end{DoxyEnumFields}
I'm guessing that you meant to end an alignment here.
! Misplaced \cr.
\cr
l.40 \end{DoxyEnumFields}
I can't figure out why you would want to use a tab mark
or \cr or \span just now. If something like a right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
! Missing \cr inserted.
\cr
l.40 \end{DoxyEnumFields}
(That makes 100 errors; please try again.)
Here is how much of TeX's memory you used:
15019 strings out of 494561
215980 string characters out of 6177454
308954 words of memory out of 500
18251 multiletter control sequences out of 15000+60
61038 words of font info for 84 fonts, out of 800 for 9000
14 hyphenation exceptions out of 8191
53i,16n,92p,802b,557s stack positions out of 5000i,500n,1p,20b,8s
! ==> Fatal error occurred, no output PDF file produced!
make[4]: *** [Makefile:619: stamp-latex] Error 1
make[4]: Leaving directory '/<>/docs'
make[3]: *** [Makefile:519: all-recursive] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:428: all] Error 2
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 "GLUT_LIBS=-lglut -lGLU -lGL -lm" returned exit code 2
make[1]: *** [debian/rules:16: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:13: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
(The above is just how the build ends and not necessarily the most relevant
part)
The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ftgl.html
where you can get a full build log if you need it.
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the BTS web page for this package.
This was due to bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921779 , as mentioned
in the changelog.
Since I saw it marked as closed, I enabled the PDF doc again and it
worked, despite the bug in the documentation generator not having
actually been fixed at the time.
I don't know why it worked, if due to older versions than the ones
affected being used, or something else. The texlive maintainer mentions
"clean up the mess due to delayed acceptance" and closing it for a
second time yesterday, so I don't know what really happened.
Also, the network of mirrors had problems and haven't been updated for a
couple of days, including some buildds, so it's possible that this might
have played a role?
In any case, it built for me at the time of uploading, it built in
almost all buildds except unimportant ones, and I just tested and it
builds for me again locally with git-pbuilder and an up-to-date chrrot,
so I think that everything is fine now?
Thanks for caring!
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em sex, 8 de fev de 2019 às 02:09, Manuel A. Fernandez Montecelo escreveu: > > Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach > escreveu: > > > > > I checked and everything looks all right, but I've been fighting for > > > 1+ hours because it cannot generate the ftgl.pdf documentation. > > > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it > > for me (though with some warnings), using stretch. Does that work > > for you? If so, it must be something in the Debian rules; otherwise > > it seems to be difference between stable and testing which may be > > worth investigating as it may affect others too. What errors do you > > get? > > The compilation doesn't exercise some options if you don't have all > packages installed, like doxygen-gen. > > Most of the build is OK, but pdflatex chokes when genereting the .pdf. > You can see the failure here: > > http://debomatic-amd64.debian.net/distribution#unstable/ftgl/2.3.0-3/buildlog > > Note that the above is for the previous version, so it must have > happened due to changes in other Debian packages. The problem might > be in the doc though, that now fails due to more strict tools that are > not going to be changed -- not sure. > > In any case, I need to get the package built even if these tools fails > in order to get it into buster. Dropping the .pdf is the most > straightforward option to achieve it at this point, unless we can find > the real problem in the next hours, and I cannot look at it until the > weekend... OK, pushed that version. If we get around to fix the problem and in time to include it in Buster, great, if not it's a lesser problem I'd say. BTW I included a patch that I noticed, fixing a duplicated entry in projects_using_ftgl.txt, please try to apply it. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qua, 21 de nov de 2018 às 01:54, Manuel A. Fernandez Montecelo escreveu: > > Hi Evgeny, > > 2018-11-19 23:44 Evgeny Kapun: > >Package: libftgl2 > >Version: 2.3.0-3 > > > >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text > >rendering in Megaglest is broken. Text is shown correctly in menus, but text > >displayed in the game itself is replaced by white rectangles. > > Thanks for the report. > > Any idea of what's going on, Frank? > > For me it works in some menus, there are white squares in others. zaz, > another application using ftgl, seems to work fine, while critterding > also shows white squares. Hi again Evgeny, With the upload of the new upstream 2.4.0-1 I think that this issue will be fixed and this bug will be closed soon. Please let us know or reopen if you still experience similar problems. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach escreveu: > > > I checked and everything looks all right, but I've been fighting for > > 1+ hours because it cannot generate the ftgl.pdf documentation. > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it > for me (though with some warnings), using stretch. Does that work > for you? If so, it must be something in the Debian rules; otherwise > it seems to be difference between stable and testing which may be > worth investigating as it may affect others too. What errors do you > get? The compilation doesn't exercise some options if you don't have all packages installed, like doxygen-gen. Most of the build is OK, but pdflatex chokes when genereting the .pdf. You can see the failure here: http://debomatic-amd64.debian.net/distribution#unstable/ftgl/2.3.0-3/buildlog Note that the above is for the previous version, so it must have happened due to changes in other Debian packages. The problem might be in the doc though, that now fails due to more strict tools that are not going to be changed -- not sure. In any case, I need to get the package built even if these tools fails in order to get it into buster. Dropping the .pdf is the most straightforward option to achieve it at this point, unless we can find the real problem in the next hours, and I cannot look at it until the weekend... -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 7 de fev de 2019 às 22:47, Frank Heckenbach escreveu: > > > The idea of using both RenderDefault() and RenderBasic() as well as > > the flag, would equally work if you have just Render() and the > > behaviour of one render or the other nested in an "if/else" based on > > the flag. Whatever makes more sense to you. I suggested it because > > in that way it is easier to change or patch the packages. > > Creating the two versions would be a lot more work, and in the end > packages need to be patched anyway. > > > Let me know when it's ready, I'll try to upload the new version within > > the same day that you have the new release ready. > > I did it, and briefly tested it with my code. > > I think you can upload it and other packages should see no change in > behaviour for now. I checked and everything looks all right, but I've been fighting for 1+ hours because it cannot generate the ftgl.pdf documentation. I'm thinking about dropping it altogether, not sure if anyone will read this doc in pdf form? What do you think? -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 7 de fev de 2019 às 04:32, Frank Heckenbach
escreveu:
>
> > > My suggestion of 2018-11-25 still stands. But if you want me to do
> > > my part of it, please do your review quickly and tell me soon
> > > (or, if it's indeed necessary for the soft freeze, immediately) to
> > > avoid running out of time.
> >
> > Your plan sounds OK. Changing packages after the release, with time,
> > should be OK. I can submit automatic bug reports for the affected
> > packages.
>
> OK.
>
> > Maybe it would even be possible to have the applications set a global
> > variable, e.g.:
> >
> > enum class Render { Default = 1, Basic };
> > FTGL->setRender(Render renderType);
> >
> > and then the Render() function(s) would dispatch to either
> > RenderDefault() or RenderBasic() versions as appropriate?
>
> I generally don't much like global flags, but in this particular
> case, it might be the least painful approach.
>
> It wouldn't be foolproof. If two pieces of code, e.g. libraries,
> that are used in the same program, use Render() with different
> settings of this flag, one of them would do the wrong thing. (And
> manually changing this flag every time code from the other library
> may be used would be a maintenance nightmare.)
>
> So maybe the following is even easier to implement, while also not
> foolproof:
>
> - No RenderDefault() and RenderBasic(), just Render() as is.
>
> - A flag similar to your proposal (though I wouldn't actually call
> it "Render..."; if we aren't renaming the Render functions, we can
> use a more specific name), such as LegacyOpenGLState, and it can
> be a bool actually.
OK, sounds good. Your name is better, mine it was only an example.
The idea of using both RenderDefault() and RenderBasic() as well as
the flag, would equally work if you have just Render() and the
behaviour of one render or the other nested in an "if/else" based on
the flag. Whatever makes more sense to you. I suggested it because
in that way it is easier to change or patch the packages.
OK to the rest of the message.
Let me know when it's ready, I'll try to upload the new version within
the same day that you have the new release ready.
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qua, 6 de fev de 2019 às 04:15, Frank Heckenbach
escreveu:
>
> > Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> > escreveu:
> > >
> > > According to https://release.debian.org/buster/freeze_policy.html:
> > >
> > > 2019-01-12 - Transition freeze
> > >
> > > Is there still time yet to get a fix in, or is it FUBAR already?
> >
> > Transition freeze means ABI changes in libraries are forbidden. We're
> > almost in soft-freeze now, more info at:
> > https://lists.debian.org/debian-devel-announce/2019/01/msg8.html
>
> So do we have time until the soft freeze on 2019-02-12 (I hope not)
> or the full freeze (2019-03-12) to get a 2.4.0 uploaded?
I believe so, yes, maybe even for the soft freeze (I am not sure how
much the time shortens for migrating packages fixing important bugs,
it varies).
> > I have to review the situation again, I completely swapped it out of
> > my memory.
>
> My suggestion of 2018-11-25 still stands. But if you want me to do
> my part of it, please do your review quickly and tell me soon
> (or, if it's indeed necessary for the soft freeze, immediately) to
> avoid running out of time.
Your plan sounds OK. Changing packages after the release, with time,
should be OK. I can submit automatic bug reports for the affected
packages.
Maybe it would even be possible to have the applications set a global
variable, e.g.:
enum class Render { Default = 1, Basic };
FTGL->setRender(Render renderType);
and then the Render() function(s) would dispatch to either
RenderDefault() or RenderBasic() versions as appropriate?
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach escreveu: > > According to https://release.debian.org/buster/freeze_policy.html: > > 2019-01-12 - Transition freeze > > Is there still time yet to get a fix in, or is it FUBAR already? Transition freeze means ABI changes in libraries are forbidden. We're almost in soft-freeze now, more info at: https://lists.debian.org/debian-devel-announce/2019/01/msg8.html Sorry, I've been very busy since end of November, with unexpected work and family loads. I have to review the situation again, I completely swapped it out of my memory. Assuming that the changes in a new release do not change other behaviour, or that I can cherry pick a targeted fix for this problem, we're still good to go. Cheers, -- Manuel A. Fernandez Montecelo
Bug#913944: flare-game: Loosing skill on load / level up / death
Control: reassign -1 + flare-engine/1.07-1 Control: tags -1 + pending Control: forwarded -1 https://github.com/flareteam/flare-engine/issues/1670 Hi, Em seg, 19 de nov de 2018 às 07:42, Philipp Klaus Krause escreveu: > > Am 19.11.18 um 01:05 schrieb Manuel A. Fernandez Montecelo: > > > > 1.08 has been out for a while already, do you know if there are other > > fixes worth including, or if 1.09 is imminent? > > Even though a few minor bugs have been fixed since the 1.08 release, I > don't now of any plans for a 1.09 release. Sorry for the delay. Re-assigning to the "engine" package where it belongs, and marking as pending due to being fixed in an upload Real Soon Now... -- Manuel A. Fernandez Montecelo
Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Em qua, 9 de jan de 2019 às 23:03, Manuel A. Fernandez Montecelo escreveu: > 2019-01-08 03:11 Faidon Liambotis: > > > >5.1.0-2 was uploaded to unstable shortly before my previous email, so it > >should start appearing on mirrors etc. soon. This upload involves a > >transition, so I'll hold any changes until this plays out. > > What kind of transition? The soname didn't change, I think? (not for > -1 at least). Ah I see that now that I was wrong and now it's libjemalloc2, I somehow missed it :) -- Manuel A. Fernandez Montecelo
Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2019-01-08 03:11 Faidon Liambotis: On Tue, Jan 08, 2019 at 12:35:28AM +0100, Manuel A. Fernandez Montecelo wrote: I am not sure what are your modifications, but I tried with the patch/debdiff attached, compared to 5.1.0-1 (-2 is/was not yet in snapshot or deb.debian.org) and everything went fine: Test suite summary: pass: 43/52, skip: 9/52, fail: 0/52 Hm, interesting! Thanks for testing this -- I'm not sure what went wrong in my setup. Probably something related to qemu-user-static... Yeah, qemu-user is unreliable for some stuff, specially "delicate"/"sophisticated" low-level libraries. That's why we use the much slower qemu-system for buildds. So, I pushed this patch to the master branch in the salsa repo, and also pushed this upstream: https://github.com/jemalloc/jemalloc/pull/1402 5.1.0-2 was uploaded to unstable shortly before my previous email, so it should start appearing on mirrors etc. soon. This upload involves a transition, so I'll hold any changes until this plays out. What kind of transition? The soname didn't change, I think? (not for -1 at least). If it indeed breaks stuff, maybe I made a mistake to upload the new version to "unreleased" for this port. I'll take of this once that's done, but I'm curious to hear what upstream will say in the meantime :) Good, thanks to you! -- Manuel A. Fernandez Montecelo
Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Hi!
2019-01-07 23:15 Faidon Liambotis:
reopen 892295
tags 892295 + help - fixed-upstream patch
thanks
[...]
I uploaded 5.1.0-2 to unstable moments ago, which includes the
aforementioned commit.
Unfortunately, it seems like the build fails due to atomics-related
complications, which judging from similar bug reports, could be fixed by
passing -pthread instead of -lpthread. I filed this upstream[1] and that
seemed like a good idea to them.
1: https://github.com/jemalloc/jemalloc/issues/1401
I then experimented with building with that option on a riscv64
qemu-user-static container locally, but I came across random issues when
running the test suite, like some allocation issues, or processes
hanging etc. The build with the same option on amd64 seems to have
worked fine. I wonder if this has something to do with jemalloc or my
(weirdly emulated) environment, bug regardless... I would love your
help, if you have a spare moment :)
First of all, thanks for taking care.
I am not sure what are your modifications, but I tried with the
patch/debdiff attached, compared to 5.1.0-1 (-2 is/was not yet in
snapshot or deb.debian.org) and everything went fine:
Test suite summary: pass: 43/52, skip: 9/52, fail: 0/52
More info about the build, which I'll proceed to upload to unreleased:
Build Architecture: riscv64
Build Type: full
Build-Space: 763036
Build-Time: 2051
Distribution: unreleased
Host Architecture: riscv64
Install-Time: 40
Job: .../jemalloc/jemalloc_5.1.0-1+0.riscv64.1.dsc
Machine Architecture: riscv64
Package: jemalloc
Package-Time: 2122
Source-Version: 5.1.0-1+0.riscv64.1
Space: 763036
Status: successful
Version: 5.1.0-1+0.riscv64.1
This is on real hardware, I trust that it will also work fine in the
buildds (qemu-system), but if not we can take another look.
Not sure if the patch is correct or it's better to fix it in another
way, I hope that you or upstream can figure that out, or if not we can
iterate over it and try different things.
Hope that helps. Thanks again!
--
Manuel A. Fernandez Montecelo
Index: jemalloc-5.1.0/Makefile.in
===
--- jemalloc-5.1.0.orig/Makefile.in
+++ jemalloc-5.1.0/Makefile.in
@@ -400,7 +400,7 @@ $(objroot)test/unit/%$(EXE): $(objroot)t
$(objroot)test/integration/%$(EXE): $(objroot)test/integration/%.$(O) $(C_TESTLIB_INTEGRATION_OBJS) $(C_UTIL_INTEGRATION_OBJS) $(objroot)lib/$(LIBJEMALLOC).$(IMPORTLIB)
@mkdir -p $(@D)
- $(CC) $(TEST_LD_MODE) $(LDTARGET) $(filter %.$(O),$^) $(call RPATH,$(objroot)lib) $(LJEMALLOC) $(LDFLAGS) $(filter-out -lm,$(filter -lrt -lpthread -lstdc++,$(LIBS))) $(LM) $(EXTRA_LDFLAGS)
+ $(CC) $(TEST_LD_MODE) $(LDTARGET) $(filter %.$(O),$^) $(call RPATH,$(objroot)lib) $(LJEMALLOC) $(LDFLAGS) $(filter-out -lm,$(filter -lrt -pthread -lstdc++,$(LIBS))) $(LM) $(EXTRA_LDFLAGS)
$(objroot)test/integration/cpp/%$(EXE): $(objroot)test/integration/cpp/%.$(O) $(C_TESTLIB_INTEGRATION_OBJS) $(C_UTIL_INTEGRATION_OBJS) $(objroot)lib/$(LIBJEMALLOC).$(IMPORTLIB)
@mkdir -p $(@D)
Index: jemalloc-5.1.0/configure.ac
===
--- jemalloc-5.1.0.orig/configure.ac
+++ jemalloc-5.1.0/configure.ac
@@ -1503,7 +1503,7 @@ if test "x$abi" != "xpecoff" ; then
AC_CHECK_HEADERS([pthread.h], , [AC_MSG_ERROR([pthread.h is missing])])
dnl Some systems may embed pthreads functionality in libc; check for libpthread
dnl first, but try libc too before failing.
- AC_CHECK_LIB([pthread], [pthread_create], [JE_APPEND_VS(LIBS, -lpthread)],
+ AC_CHECK_LIB([pthread], [pthread_create], [JE_APPEND_VS(LIBS, -pthread)],
[AC_SEARCH_LIBS([pthread_create], , ,
AC_MSG_ERROR([libpthread is missing]))])
wrap_syms="${wrap_syms} pthread_create"
diff -Nru jemalloc-5.1.0/debian/changelog jemalloc-5.1.0/debian/changelog
--- jemalloc-5.1.0/debian/changelog 2018-05-26 23:36:03.0 +0200
+++ jemalloc-5.1.0/debian/changelog 2019-01-07 23:28:11.0 +0100
@@ -1,3 +1,10 @@
+jemalloc (5.1.0-1+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: use -pthread
+
+ -- Manuel A. Fernandez Montecelo Mon, 07 Jan 2019 22:28:11
+
+
jemalloc (5.1.0-1) experimental; urgency=medium
* New upstream release.
diff -Nru jemalloc-5.1.0/debian/patches/riscv64-support.dch
jemalloc-5.1.0/debian/patches/riscv64-support.dch
--- jemalloc-5.1.0/debian/patches/riscv64-support.dch 1970-01-01
01:00:00.0 +0100
+++ jemalloc-5.1.0/debian/patches/riscv64-support.dch 2019-01-07
23:28:11.0 +0100
@@ -0,0 +1,26 @@
+Index: jemalloc-5.1.0/Makefile.in
+===
+--- jemalloc-5.1.0.orig/Makefile.in
jemalloc-5.1.0/Makefile.in
+@@ -400,7 +400,7 @@ $(objroot)test/unit/%$(EXE): $(objroot)t
+
+ $(objroot)test/integration/%$(EXE): $(objroot)test/integration/%.$(O)
Bug#917448: razorqt: Please switch Build-Depends to libsensors-dev from libsensors4-dev
2018-12-27 20:57 Aurelien Jarno: Hi Manuel, For when is this scheduled, post-freeze? Technically this can be done as soon as the two packages using versioned build-dependency on libsensors4-dev (razorqt and wmtemp) have been changed. Now I don't plan to push that more than necessary, so I'll send a reminder something like 6 months before the *Bullseyes* freeze, if these two packages haven't been changed at that time. In short you have plenty of time. OK, so if you don't mind the wait, I think that I'd better wait for a few months to see if the usage drops dramatically (e.g. when the new release), or if Qt4 is finally removed, which I thought that it would happen by now. In any case, I'd like to get it removed before Bullseye is released; and if it becomes a problem for libsensors for any reason, I can fix it more actively. It's not too much work, but I'd like to avoid to give the impression that this package is alive by uploading after several years; but at the same time I am still reluctant to remove it from the archive... -- Manuel A. Fernandez Montecelo
Bug#917448: razorqt: Please switch Build-Depends to libsensors-dev from libsensors4-dev
Hi, 2018-12-27 18:53 Aurelien Jarno: Source: razorqt Version: 0.5.2-4 Severity: minor User: aure...@debian.org Usertags: libsensors-dev-transition Dear maintainer, razorqt build-depends on libsensors4-dev, the development package from lm-sensors. For historical reasons the development package is versioned. Following the transition of the library to libsensors5, it makes sense to rename the development package to libsensors-dev. In that regard a "Provides: libsensors-dev" has been added. As razorqt uses a versioned build-depends, it is not enough to replace libsensors4-dev by libsensors-dev in debian/control. However the current build-depends version being satisfied in oldstable, it is safe to just drop the version, and replace it by a simple build-depends on libsensors-dev. Would it be possible to do that in the next upload? For when is this scheduled, post-freeze? I had plans (hopes?) to drop the package without any more uploads by the time that Qt4 was removed, which not sure if it will happen in this cycle, probably not. But this package is dead upstream for years, I only didn't ask for removal because it's got 100~200 users, presumably it's useful for some of them (and I use it from time to time in several systems), and by not removing it's easier to do emergency fixes if needed. Cheers. -- Manuel A. Fernandez Montecelo
Bug#917082: openscenegraph depends and build-depends on cruft packages
Hi, Em sáb, 22 de dez de 2018 às 11:33, peter green escreveu: > > package: openscenegraph > version: 3.2.2+dfsg1-2 > severity: serious > > libopenscenegraph100v5 depends on libcoin80-5 and the openscenegraph source > package bulid-depends on libcoin80-dev. These packages are no longer built by > the coin3 source package. They appear to have been replaced by libcoin80c and > libcoin-dev That must be because of a recent upload to unstable, and that the package names were not preserved, otherwise it would be a matter of binNMUing. So yep, I suppose that we'll hape to change this and hope for the best, in terms of compatibility. Thanks for the heads up, in any case! -- Manuel A. Fernandez Montecelo
Bug#895123: libsdl2-2.0-0: This is normally a bug in some application using the D-Bus library.
Hi, Em sáb, 24 de nov de 2018 às 08:10, develo...@oldunreal.com escreveu: > > Sorry, I assumed the bugtracking system gathered all needed information. > The problem appears on x86_64 when linking a -m32 compiled application > against system provided libsdl2. We have to go back to square one. The text of the original report is empty, and the title "This is normally a bug in some application using the D-Bus library" also doesn't explain what the problem is about. So could you please reformulate the problem? Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Hi Frank,
Em dom, 25 de nov de 2018 às 18:29, Frank Heckenbach
escreveu:
>
> : Perhaps the only sane way out is to add *two* new versions of each
> : rendering function, one with each behaviour, and deprecate the old
> : ones entirely. This will require changes in all applications (if
> : only to select the correct one of the two which should be easy if
> : ones knows which branch of the library they used before), but at
> : least it will be clear at compile time.
>
> That seems to me the best solution indeed. So I can offer this:
>
> - I add these two new versions for all functions involved (quite a
> few); we'd just need to agree about naming ("old" and "new" won't
> do, since in this complicated situation it's not even clear which
> one is old and which one is new; different users will view it
> differently, just like in special relativity ;), also "old" and
> "new" in function names always sounds silly; so perhaps something
> like "RenderBasic" and "RenderDefault" or so ...).
>
> - I deprecate the "Render" functions, adding a special README to
> explain things.
>
> - I change my sources to use "RenderBasic" (or whatever it'll be
> called) and test them. Other users of this fork will have to do
> the same (hopefully after seeing the deprecation warnings and
> reading that README).
>
> - I release 2.4.0 with those changes.
>
> - You put 2.4.0 in Debian. Applications using it will get the
> deprecation warnings, but should otherwise work.
>
> - A bit later, I remove the deprecated functions and release 3.0.0.
>
> - After the release of Buster, you put 3.0.0 in Debian with the
> required transitions.
>
> - Applications using it will break, but fixing them will only
> require changing "Render" to "RenderDefault" in some places
> (which are found by compiler errors). This can also be done before
> you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
> already), so the transition can be smoohter.
>
> Does this sound like a viable plan?
I am not sure if I understand. According to your plan, do the
applications in Debian using ftgl will need to change anything at all
to keep working? Because there's not much time for making changes
before the freeze, I will be quite busy for a couple of weeks at least
(so please excuse delays in replies if they don't arrive in a timely
manner), and changes of this kind usually take months to be
accomplished. It's not like we can commit changes to one or several
git repos and rebuild the packages, it's quite more complex than that.
IMO from the Debian side and for Buster there's no material time for
changes to all packages that depend on fgtl, the only practical
solutions are either to revert the change making some applications
unuseable via extra patch from Debian; or have this transition and
deprecation messages etc. in a way that existing packages don't need
changes at all.
Sorry, but I don't think that anything else works for Buster.
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
t would have to be the old behaviour, yes, because after many years behaving in that way the applications must have learned to adapt or cope, and no one knows that they have to use a different flag or invoke the method with an extra parameter. I realise that maybe this is not what you like because applications will ever remain buggy, but reallistically, some might even be abandoned upstream, so they could remain unusable forever. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Control: tags -1 + serious Hi, Em qua, 21 de nov de 2018 às 02:10, Frank Heckenbach escreveu: > > Hi Evgeny, > > > >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text > > >rendering in Megaglest is broken. Text is shown correctly in menus, but > > >text displayed in the game itself is replaced by white rectangles. > > > > Thanks for the report. > > > > Any idea of what's going on, Frank? > > > > For me it works in some menus, there are white squares in others. zaz, > > another application using ftgl, seems to work fine, while critterding > > also shows white squares. > > That's probably a consequence of a fix made by sammy in 2009(!) > (commit 29603ae: "Remove GL_BLEND tampering. It's the caller > application's responsibility to enable or disable blending"). > > For some reason, that patch (and a few others) hadn't made it into > Debian before and only now got in as a "bycatch" when we > synchronized everything. > > Though it is an incompatible change, it was a necessary one, since > what the library did before was wrong (which prompted a bug report > of my own, #742469 which would solve it for some particular cases > while adding a dependency on GL_GLEXT_PROTOTYPES). So the better > solution is probably the earlier (and now current) one which puts > the responsibility on the caller. > > I had seen the same problem in another test program recently, and in > this case it helped to add the following two lines in an appropriate > place. You can try the same in your code (shouldn't hurt if compiled > with older ftgl versions as well): > > glEnable(GL_BLEND); > glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); > > Or, if you like a better blending function (see my description in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742469), you can > use this instead: > > #define GL_GLEXT_PROTOTYPES > > glEnable(GL_BLEND); > glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, > GL_ONE, GL_ONE_MINUS_SRC_ALPHA); I think that we should revert this change for the time being, though, because if it was working in this way for about a decade and the programs using FTGL worked "fine" despite having some bug there, there's no need to change this now and break applications with only a few weeks to fix this in 15+ other packages before the freeze. Otherwise we have to get the fix in several of this packages, which is way more difficult, specially if not well maintained in Debian, upstream or both. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Hi Evgeny, 2018-11-19 23:44 Evgeny Kapun: Package: libftgl2 Version: 2.3.0-3 After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text rendering in Megaglest is broken. Text is shown correctly in menus, but text displayed in the game itself is replaced by white rectangles. Thanks for the report. Any idea of what's going on, Frank? For me it works in some menus, there are white squares in others. zaz, another application using ftgl, seems to work fine, while critterding also shows white squares. Cheers. -- Manuel A. Fernandez Montecelo
Bug#734170: ftgl: "make clean" fails
Control: tags -1 + moreinfo (Please CC me if you want me to read the reply). Hi Yann, 2014-01-04 16:05 Yann Dirson: Package: libftgl2 Version: 2.1.3~rc5-4 $ debuild clean ... debuild: fatal error at line 1346: couldn't exec fakeroot debian/rules: ... The use of "SUBDIRS" is obviously violating the way automake should be used. Adding "msvc" to SUBDIRS at it probably should is probably enough, given the lack of build targets in this dir. debian/rules was completely revamped in 2.3.0-1 and all of this legacy way to call commands do things was removed in favour of the latest minimalistic dh. I haven't observed it in my builds, when the clean target is invoked automatically by git-buildpackage. That said, I guess that the bug is still present since upstream didn't change much and the problem is with Makefile.am, as far as I understand it. What I don't know is what do you mean with SUBDIRS not being used properly, my knowledge of autotools is quite shallow. Could you please submit a patch so I can forward it upstream? Cheers. -- Manuel A. Fernandez Montecelo
Bug#913944: flare-game: Loosing skill on load / level up / death
Control: tags -1 + fixed-upstream Hi, Em sáb, 17 de nov de 2018 às 12:06, Philipp Klaus Krause escreveu: > > Package: flare-game > Version: 1.07-1 > Severity: normal > Tags: upstream > > In 1.07, when wearing an item that gives a skill bonus, this bonus is > subtracted permanently from a random skill each time a character levels up, > dies or a savegame is loaded. > This makes such items pretty much unuseable; for unsuspecting players they can > quickly make a character equipped with such items unplayable. > > This bug is fixed in the 1.08 upstream release. Right, thanks. 1.08 has been out for a while already, do you know if there are other fixes worth including, or if 1.09 is imminent? Cheers. -- Manuel A. Fernandez Montecelo
Bug#874727: OSG changing VRML renderer away from coin3
Em seg, 5 de nov de 2018 às 07:10, Sebastiaan Couwenberg escreveu: > On 11/5/18 12:45 AM, Manuel A. Fernandez Montecelo wrote: > > 2018-11-04 18:28 Christoph Berg: > >> > >> | Patches for both OSG packages have been submitted to use SGI Inventor > >> | instead of COIN: > >> | > >> | https://bugs.debian.org/912866 (openscenegraph) > >> | https://bugs.debian.org/912867 (openscenegraph-3.4) > > > > I am not totally opposed to that, and thanks to Bas for the patches. > > But it looks to me that the proper solution is something like what > > Bernhard posted just minutes before this message that I am replying to > > (that perhaps Christoph didn't notice, due to the timing): > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727#96 > > Yes, the proper solution is to fix coin3. The OSG patches are meant as > an interim solution to remove the coin3 dependency from the OSG packages > and remove the threat of testing autoremoval. I think that we're not in danger at this point, at least I cannot see anything in the tracker. If the situation becomes more urgent/critical (e.g. due to being closer to the freeze) and I am not available to respond at that time in a reasonable time (2 days to a week, whatever you judge appropriate), please go ahead and fix it, unless co-maintainers (which are main maintainers really) object to it in the meantime. Thanks! -- Manuel A. Fernandez Montecelo
Bug#887712: fixed in ftgl 2.3.0-1
Hi, Em qui, 8 de nov de 2018 às 11:59, IOhannes m zmölnig (Debian/GNU) escreveu: > > (resending) > > my packages are marked for AUTORM by end of november, because they B-D > on ftgl. > i would really like to avoid having them removed from testing. Thanks for the ping, I certainly did miss the initial message, since I'm not listed as maintainer and didn't get sent an email automatically. > On Wed, 31 Oct 2018 10:10:46 +0100 =?UTF-8?Q?IOhannes_m_zm=c3=b6lnig?= > wrote: > > On Sat, 20 Oct 2018 14:49:43 +0000 m...@debian.org (Manuel A. Fernandez > > Montecelo) wrote: > > > Source: ftgl > > > Source-Version: 2.3.0-1 > > > > thanks for doing an upload of ftgl-2.3 to "experimental". > > do you have any plans, to also upload to "unstable" (so all those > > reverse-dependencies that are marked AUTORM won't get kicked out of > > Debian)? is a transition required? So I had plans to upload to unstable, but then noticed that the new upstream maintainer (in copy) changed the SOVERSION. I don't know if there's an actual break in ABI or it was just to set it and be the same as the version of the library, but in fact this will cause a transition, so it's what stopped me from uploading to unstable. I think that I asked Frank about this but didn't get a reply yet, I know that he's been busy with misc things. I suppose that we can either upload to unstable and request a transition slot, and everything will be fine, or check that the ABI didn't change and patch to keep the old SOVERSION. Would you like to help with that? I've been kept busy and without a continous stretch of time to review and deal with the issue properly, also because of other Debian duties, so I'm not sure when I'll be able to deal with that. > > (btw, where is ftgl-2.3.0 upstream? is it the > > https://github.com/ulrichard/ftgl fork?) I don't know why it's so buried in github, but Richard was not interested in being the main maintainer and as discussed in https://github.com/ulrichard/ftgl/pull/9#issuecomment-428309601 the de-facto maintainer is now Frank. Also from https://github.com/ulrichard/ftgl/ main page/README: ftgl is currently hosted at: https://github.com/frankheckenbach/ftgl Current maintainer: Frank Heckenbach Cheers. -- Manuel A. Fernandez Montecelo
Bug#874727: OSG changing VRML renderer away from coin3
Hi, 2018-11-04 18:28 Christoph Berg: Re: To markus 2018-10-05 <20181005080326.gb13...@msg.df7cb.de> > it's a packaging bug - libcoin is statically linked with libexpat, and > the version being used is outdated. So anything that uses libcoin and > libexpat will run into a segfault. > > I am not aware of any other application that uses libcoin. I noticed because PostGIS is affected via postgis B-D -> libsfcgal-dev -> libsfcgal-osg1 -> libopenscenegraph100v5 -> libcoin80v5. Looking at https://udd.debian.org/cgi-bin/autoremovals.cgi there's quite a few packages depending on coin3. So the question whether this affects freecad only or more packages is making quite a difference. There is some indirect progress on this, Sebastiaan Couwenberg has submitted patches to change OSG's VRML renderer to SGI Inventor: | Patches for both OSG packages have been submitted to use SGI Inventor | instead of COIN: | | https://bugs.debian.org/912866 (openscenegraph) | https://bugs.debian.org/912867 (openscenegraph-3.4) I am not totally opposed to that, and thanks to Bas for the patches. But it looks to me that the proper solution is something like what Bernhard posted just minutes before this message that I am replying to (that perhaps Christoph didn't notice, due to the timing): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727#96 I think that it's a better/proper solution because: a) SGI inventor looks like not having new upstream releases for more than a decade (or them not packaged in Debian), thus presumably not a terribly good idea in general to keep packages depending on it b) Fixing a problem with crashes and embedded static expat library in Coin looks like the right thing to do anyway Cheers. -- Manuel A. Fernandez Montecelo
Bug#912617: libsdl2-image: CVE-2018-3977: do_layer_surface code execution vulnerability
Hi, Em dom, 4 de nov de 2018 às 17:28, Chris Lamb escreveu: > > > I suppose that it's better that you go ahead unless they reply > > between now and you reading this e-mail. > > Sure. From this I will go ahead and upload to sid. I've requested > access to the Salsa group so I can push my changes. I was planning to gbp-import-dsc, but if you prefer I'll grant you access, sure. > (I still await the Security Team on stable.) OK, if you need any help please tell. I might not be around much in the next days, but I will try to be responsive. Cheers. -- Manuel A. Fernandez Montecelo
Bug#912618: Bug#912617: libsdl2-image: CVE-2018-3977: do_layer_surface code execution vulnerability
Hi Chris, Em dom, 4 de nov de 2018 às 15:48, Chris Lamb escreveu: > > Hi SDL maintainers & security team, > > > libsdl2-image: CVE-2018-3977: do_layer_surface code execution > > vulnerability > > The attached patches apply cleanly to jessie, stretch and sid > respectfully. (Looks like they reformatted their code later on.) > > I am happy to upload handle jessie, but I can also work on the > stable/sid releases too if you wish; please let me know. I am enjoying a kind of a "long weekend" / mini-holidays, could not work on it so far and will not at least for another 3 or 4 days, and since the rest of the team did not reply to the original report I suppose that it's better that you go ahead unless they reply between now and you reading this e-mail. Thanks the several people involved in the work, both for the report and patches and offer to fix! Cheers. -- Manuel A. Fernandez Montecelo
Bug#912269: gringo: Please update symbols for riscv64
Source: gringo
Version: 5.2.3-2
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hello,
This package builds fine for the riscv64 architecture, but symbols need to be
updated.
I am attaching a patch that shows a debdiff, which is basically that update of
the symbols file using pkgkde-symbolshelper. It built fine in both amd64 and
riscv64 with the new changes.
It would be great if you could include these changes and release a new version
for unstable, at the moment it lives in "unreleased".
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru gringo-5.2.3/debian/changelog gringo-5.2.3/debian/changelog
--- gringo-5.2.3/debian/changelog 2018-07-03 06:23:44.0 +0200
+++ gringo-5.2.3/debian/changelog 2018-10-29 15:03:10.0 +0100
@@ -1,3 +1,10 @@
+gringo (5.2.3-2+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/symbols: update symbols for riscv64
+
+ -- Manuel A. Fernandez Montecelo Mon, 29 Oct 2018 15:03:10
+0100
+
gringo (5.2.3-2) unstable; urgency=medium
* debian/symbols: batchpatch symbols
diff -Nru gringo-5.2.3/debian/symbols gringo-5.2.3/debian/symbols
--- gringo-5.2.3/debian/symbols 2018-07-03 06:23:44.0 +0200
+++ gringo-5.2.3/debian/symbols 2018-10-29 15:02:39.0 +0100
@@ -1,36 +1,36 @@
-# SymbolsHelper-Confirmed: 1 alpha amd64 arm64 armel armhf hppa hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe
ppc64 ppc64el s390x sh4 x32
+# SymbolsHelper-Confirmed: 1 alpha amd64 arm64 armel armhf hppa hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe
ppc64 ppc64el riscv64 s390x sh4 x32
libclingo.so.1 gringo #MINVER#
(optional=templinst)_ZNKSt5ctypeIcE8do_widenEc@Base 1
(optional=templinst)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE4findERKS5_@Base
1
(optional=templinst)_ZNSt10_HashtableINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESaIS8_ENSt8__detail10_Select1stESt8equal_toIS5_ESt4hashIS5_ENSA_18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyENSA_17_Hashtable_traitsILb1ELb0ELb110_M_emplaceIJS8_EEES6_INSA_14_Node_iteratorIS8_Lb0ELb1EEEbESt17integral_constantIbLb1EEDpOT_@Base
1
(optional=templinst|subst)_ZNSt10_HashtableINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESaIS8_ENSt8__detail10_Select1stESt8equal_toIS5_ESt4hashIS5_ENSA_18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyENSA_17_Hashtable_traitsILb1ELb0ELb19_M_rehashE{size_t}RK{size_t}@Base
1
- (optional=templinst|arch=amd64 arm64 armel armhf m68k mips64el ppc64el sh4
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeE{size_t}{size_t}PNS4_10_Hash_nodeIS2_Lb0EEE@Base
1
- (optional=templinst|arch=alpha amd64 arm64 armel armhf hurd-i386 i386 m68k
mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb15eraseENS4_20_Node_const_iteratorIS2_Lb0ELb0EEE@Base
1
- (optional=templinst|arch=alpha amd64 arm64 armel armhf hurd-i386 i386 m68k
mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb19_M_rehashE{size_t}RK{size_t}@Base
1
- (optional=templinst|arch=amd64 arm64 armel armhf hppa ia64 kfreebsd-amd64
m68k mips64el ppc64el sh4
x32|subst)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeE{size_t}{size_t}PNS6_10_Hash_nodeIS4_Lb0EEE@Base
1
- (optional=templinst|arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64el
!ppc64 !ppc64el
!s390x)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb19_M_rehashEjRS1_@Base
1
- (optional=templinst|arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64el ppc64
ppc64el
s390x)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb19_M_rehashEmRKm@Base
1
+ (optional=templinst|arch=amd64 arm64 armel armhf hpp
Bug#906429: closed by Michael Biebl (Bug#906429: fixed in systemd 239-11)
Hi, Em dom, 28 de out de 2018 às 15:51, Debian Bug Tracking System escreveu: > > This is an automatic notification regarding your Bug report > which was filed against the src:systemd package: > > #906429: systemd: Please raise timeout for tests (for riscv64) > > It has been closed by Michael Biebl . > [...] >[ Manuel A. Fernandez Montecelo ] >* Run "meson test" instead of "ninja test" > Upstream developers of meson recommend to run it in this way, because > "ninja test" just calls "meson test", and by using meson directly and > using extra command line arguments it is possible to control aspects of > how the tests are run. >* Increase timeout for test in riscv64. > The buildds for the riscv64 arch used at the moment are slow, so increase > the timeouts for this arch by a factor of 10, for good measure. > (Closes: #906429) It now built successfully for the first time, unmodified: https://buildd.debian.org/status/logs.php?pkg=systemd=riscv64 Ironically, it was built in the slowest of the buildds active at the moment. But it built correctly, passing all the tests and unatteded, which is the important thing. Thanks for merging and uploading! systemd was one of the last two packages preventing "debootstrap" from working straight away (that is, producing useful/self-sufficient chroots without extra steps), due to some packages being in "unreleased" part of the archive rather than all being in the same one. Now only libffi remains. Cheers. -- Manuel A. Fernandez Montecelo
Bug#911792: sdlgfx: autopkgtest regression: seems to run same test over and over again
Hi, Em qua, 24 de out de 2018 às 22:03, Paul Gevers escreveu: > > Source: sdlgfx > Version: 2.0.25-10 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > With a recent upload of sdlgfx the autopkgtest of sdlgfx fails in > testing when that autopkgtest is run with the binary packages of sdlgfx > from unstable. It passes when run with only packages from testing. In > tabular form: Ah, indeed, thanks for the heads-up -- I'll look into it. Cheers. -- Manuel A. Fernandez Montecelo
Bug#895123: libsdl2-2.0-0: This is normally a bug in some application using the D-Bus library.
Control: tags -1 + unreproducible moreinfo Hi, 2018-04-07 10:50 Smirftsch: Package: libsdl2-2.0-0 Version: i386 Severity: important This bug does not contain any description of the problem, can you please provide one? Otherwise this can be closed in a few weeks. Cheers. -- Manuel A. Fernandez Montecelo
Bug#911284: erlang-jiffy: FTBFS on riscv64
Hi, Em qui, 18 de out de 2018 às 09:33, Nobuhiro Iwamatsu escreveu: > > Package: erlang-jiffy > Version: 0.14.11+dfsg-3 > Severity: wishlist > Tags: patch > X-Debbugs-CC: debian-ri...@lists.debian.org > User: debian-ri...@lists.debian.org > Usertags: riscv64 > > Dear Maintainer, > > The version of the package currently FBTFS on the riscv64 port: > > https://buildd.debian.org/status/fetch.php?pkg=erlang-jiffy=riscv64=0.14.11%2Bdfsg-3=1527655002=0 > > - > Compiling c_src/decoder.c > Compiling c_src/encoder.c > Compiling c_src/jiffy.c > Compiling c_src/utf8.c > Compiling c_src/util.c > Compiling c_src/doubles.cc > In file included from c_src/double-conversion/double-conversion.h:31:0, > from c_src/doubles.cc:1: > c_src/double-conversion/utils.h:77:2: error: #error Target > architecture was not detected as supported by Double-Conversion. > #error Target architecture was not detected as supported by > Double-Conversion. > ^ Is this perhaps an embedded library "double-conversion"? I seem to remember a similar one used in Qt/KDE among other places, but I cannot remember the details and cannot check right now. If it is indeed using an embedded library, perhaps it can be made to use the library installed on the system instead of the embedded one, and so we end up with a double-benefit :) Cheers. -- Manuel A. Fernandez Montecelo
Bug#910513: cmake: Please increase timeout of tests for arch riscv64
Source: cmake Version: 3.12.1-1.1 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, This package fails to build due to the timeout limit of the tests, and since it's a very important package, we have to compile it by hand every time with each upload, to include in the "unreleased" suite. Some versions in the past compiled sucessfully, but I suppose that a combination of the addition of some tests or the recent changes that decrease performance in x86_64 play a role in this, since the buildds are running at the moment with qemu-system. Several tests take around and slightly over 2000 that it's the current limit. One of them takes 3500. But just to avoid having similar problems in the near future, I think that it's safest to increase to 5000, to not have to modify again in the near future. So please consider to include this simple patch that I attach, or an equivalent only for riscv64 if you don't want to increase the limit for other arches. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru cmake-3.12.1/debian/changelog cmake-3.12.1/debian/changelog --- cmake-3.12.1/debian/changelog 2018-09-27 17:50:12.0 +0200 +++ cmake-3.12.1/debian/changelog 2018-10-06 15:51:48.0 +0200 @@ -1,3 +1,11 @@ +cmake (3.12.1-1.1+0.riscv64.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * riscv64: increase timeout of tests for compilation in the qemu-system +buildds, from 2000 to 5000 + + -- Manuel A. Fernandez Montecelo Sat, 06 Oct 2018 15:51:48 +0200 + cmake (3.12.1-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru cmake-3.12.1/debian/rules cmake-3.12.1/debian/rules --- cmake-3.12.1/debian/rules 2018-05-19 10:51:17.0 +0200 +++ cmake-3.12.1/debian/rules 2018-10-06 15:51:48.0 +0200 @@ -52,7 +52,7 @@ override_dh_auto_test: # Pass -j1 to "make test" as a workaround, see https://gitlab.kitware.com/cmake/cmake/issues/17165 # The tests are still run in parallel as debhelper pass -jX as ARGS to ctest. - dh_auto_test --buildsystem=cmake -- -j1 ARGS="-E CTestTestUpload --timeout 2000" + dh_auto_test --buildsystem=cmake -- -j1 ARGS="-E CTestTestUpload --timeout 5000" override_dh_auto_clean: dh_auto_clean
