Bug#1032691: More rinse/fedora-37 URL problems
Hi - I couldn't install fedora-37 on arm64 today either - the aarch64 location encoded in /etc/rinse/rinse.conf did not exist. I expect what’s going on is that release.fedoraproject.org <http://release.fedoraproject.org/> redirects to one of many mirrors, and both Dima and I landed on a mirror that did not include the specific release/arch combination that we were after. What I’ve done locally in my own /etc/rinse/rinse.conf is hard-code the mirror location: [fedora-37] ... mirror.arm64 = https://ap.edge.kernel.org/fedora/releases/37/Everything/aarch64/os/Packages/ - Ben. -- Prof. Benjamin Burton Computational Geometry & Topology Group School of Mathematics and Physics The University of Queensland, Australia UQ ALLY :: Supporting and celebrating the diversity of sexuality, gender and sex at UQ. Pronouns: He, him, his
Bug#1027943: regina-normal FTBFS with Python 3.11 as default version
Hi Simon, Graham, Thanks both of you for looking into this (and Graham: the upstream patch you found is indeed the right one for this issue). As it happens I have a fix tested and ready to upload but waiting for me to come back from travels (since I didn’t take my private key with me). If it’s okay I might just upload that since I’ve already gone through the usual manual testing (e.g., the GUI, desktop integration, etc.) that I do for these packages. Having said that, thanks again both of you. - Ben. -- Prof. Benjamin Burton Computational Geometry & Topology Group School of Mathematics and Physics The University of Queensland, Australia UQ ALLY :: Supporting and celebrating the diversity of sexuality, gender and sex at UQ. Pronouns: He, him, his
Bug#1013904: rinse: support newer fedora/opensuse and arm64
Package: rinse Version: 3.7 Severity: normal Hi - I’m using rinse for some ongoing porting efforts, and I’ve made some patches that I’m hoping can be incorporated upstream. The patches deal with two main tasks: (1) supporting fedora 32..36 and opensuse 15.3,15.4; and (2) supporting arm64 machines. I’ve filed this as a normal bug rather than wishlist, since all of the fedora/opensuse releases currently supported by rinse are already past their end-of-life (but of course please reclassify as you please). Also, my apologies for filing these as the same bug; however, the patches are a little intertwined. I’ll step through the patches in a moment, but first: you can download the patched rinse using the following apt-lines: deb https://people.debian.org/~bab/rinse unstable/ deb-src https://people.debian.org/~bab/rinse unstable/ The patched rinse will show up as version 3.7+bab.1. The differences are: 1) New package lists for fedora 32, 33, 34, 35, 36, and for opensuse 15.3, 15.4. You can download these individually as *.packages files from https://people.debian.org/~bab/rinse/patches/ . The fedora lists were made in the way you recommend (using repoquery to find a minimal set of packages that includes dnf, yum and rpm). The opensuse lists were made using a similar principle; however, since there is no repoquery on opensuse I wrote a custom perl script that works this out. For opensuse I aimed for a minimal set of packages that includes rpm, zypper, util-linux, gzip, grep, sed and xz. The reason for explicitly naming the additional packages (gzip, sed, grep, xz) is that, if they were not specified here, the dependency analysis was sometimes pulling in busybox variants of these core tools instead, and this was causing other problems further down the road. You can see the script that I used at https://people.debian.org/~bab/rinse/patches/opensuse-core.pl . 2) A new post-install script for fedora >= 32. I put this in fedora-32/post-install.sh, and symlinked the later fedoras back to it. The main difference between the fedora >= 32 script and the fedora <= 28 script is that fedora now uses /etc/yum.repos.d/ for its out-of-the-box repositories, not /etc/yum.conf. I have also switched on GPG checking for the repositories, added a call to update-ca-trust (without which the https repositories were sometimes failing), and added arm64 as an allowed arch (which maps to fedora’s aarch64). You can download this separately from https://people.debian.org/~bab/rinse/patches/fedora-32_post-install.sh . 3) A patched post-install script for opensuse 15.2. For the later opensuse releases (15.3, 15.4), I just symlinked these back to the 15.2 script. The differences are that I switched on GPG checking, I use zypper to reinstall rpm and zypper (since otherwise zypper was getting confused about the status of its core packages); and I added a call to zypper verify (again due to this confusion). You can see the (very short) patch at https://people.debian.org/~bab/rinse/patches/opensuse.diff , or you can download the full updated post-install script from https://people.debian.org/~bab/rinse/patches/opensuse-15.2_post-install.sh . 4) I have added appropriate entries to the list of mirrors for the newer fedora/opensuse releases. Here I have added arm64 lines also, for those releases that support arm64/aarch64. The patch here is https://people.debian.org/~bab/rinse/patches/mirrors.diff . 5) I have updated /usr/sbin/rinse to explicitly support arm64. The patch here is https://people.debian.org/~bab/rinse/patches/arm64.diff . Again, you can get all these patches together by downloading rinse-3.7+bab.1 from the apt-line above on people.debian.org. I have tested this successfully on all combinations of (x86_64, arm64) and (fedora 32..36, opensuse 15.2..15.4), except for opensuse-15.2/arm64 which is not actually supported by opensuse (AFAICT they only added aarch64 with the 15.3 release). I’ve written a lot here, but at the end of the day the patches are quite small; there was not a lot to change at all. Best regards - Ben.
Bug#998455: regina-normal: b-d on python3-all-dev, but not built for all supported Python3 versions
Thanks - there is a new upstream release coming hopefully within the next month, and I will update the build-depends when I push that through. - Ben.
Bug#853639: Fix for the regina-normal FTBFS with gcc 7
Hi Adrian, > A fix for the regina-normal FTBFS with gcc 7 is attached. Having just uploaded the fix that has been sitting on my hard drive while I was on holiday all week, I realised that you had also sent in a patch for this (which of course is the same one-liner as mine). Apologies for the duplicated effort, and thanks for looking into this. - Ben.
Bug#802932: nmu: regina-normal_4.96-2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal nmu regina-normal_4.96-2 . ANY . unstable . -m "Rebuild against boost 1.58." The current regina-normal is built against boost 1.55, which is no longer the default in unstable, and which is now blocking regina-normal from moving into testing. Thanks! - Ben. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#797234: source-highlight, regina-normal and libstdc++6
> That leaves the question: what to do with this bug?
FYI, if a rebuild *is* required then I presume it would be a simple rename from
libsource-highlight4 to libsource-highlight4v5; see the (tested) patch below.
I’m happy to NMU this if the maintainer does not have time (which is why the
changelog entry reads as an NMU).
- Ben.
diff -Nru source-highlight-3.1.8/debian/changelog
source-highlight-3.1.8/debian/changelog
--- source-highlight-3.1.8/debian/changelog 2015-07-15 06:27:18.0
+1000
+++ source-highlight-3.1.8/debian/changelog 2015-10-24 20:57:03.0
+1000
@@ -1,3 +1,10 @@
+source-highlight (3.1.8-1.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Rename library packages for g++5 transition (Closes: #797234)
+
+ -- Ben Burton Sat, 24 Oct 2015 20:56:50 +1000
+
source-highlight (3.1.8-1) unstable; urgency=low
* New upstream release
diff -Nru source-highlight-3.1.8/debian/control
source-highlight-3.1.8/debian/control
--- source-highlight-3.1.8/debian/control 2015-07-14 13:41:56.0
+1000
+++ source-highlight-3.1.8/debian/control 2015-10-24 20:58:32.0
+1000
@@ -21,7 +21,7 @@
Package: libsource-highlight-dev
Section: libdevel
Architecture: any
-Depends: dpkg (>= 1.15.4) | install-info, libboost-dev, libsource-highlight4
(= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: dpkg (>= 1.15.4) | install-info, libboost-dev, libsource-highlight4v5
(= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
Replaces: source-highlight (<< 3.1.4-1)
Description: development files for source highlighting library
These are the development files for the library that underlies the
@@ -30,10 +30,12 @@
The library can be used by other C++ programs to get source code
highlighting capabilities.
-Package: libsource-highlight4
+Package: libsource-highlight4v5
Section: libs
Architecture: any
Depends: libsource-highlight-common, ${misc:Depends}, ${shlibs:Depends}
+Conflicts: libsource-highlight4
+Replaces: libsource-highlight4
Description: source highlighting library
This is the library that underlies the source-highlight program
suite. It converts source code to a document with syntax
diff -Nru source-highlight-3.1.8/debian/libsource-highlight4.install
source-highlight-3.1.8/debian/libsource-highlight4.install
--- source-highlight-3.1.8/debian/libsource-highlight4.install 2013-10-22
22:58:26.0 +1000
+++ source-highlight-3.1.8/debian/libsource-highlight4.install 1970-01-01
10:00:00.0 +1000
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff -Nru source-highlight-3.1.8/debian/libsource-highlight4v5.install
source-highlight-3.1.8/debian/libsource-highlight4v5.install
--- source-highlight-3.1.8/debian/libsource-highlight4v5.install
1970-01-01 10:00:00.0 +1000
+++ source-highlight-3.1.8/debian/libsource-highlight4v5.install
2013-10-22 22:58:26.0 +1000
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
Bug#797234: source-highlight, regina-normal and libstdc++6
So: it turns out that the regina-normal build failure was not because of the libstdc++6 transition, but because source-highlight was built against an old version of libboost-regex. It seems that between August and now, somebody has binNMUed source-highlight to use boost 1.58, and as a result the build failure for regina-normal has gone away (see the notes for #797292, which I have just closed). That leaves the question: what to do with this bug? I’m not sure whether libsource-highlight4 needs a rebuild with gcc5 - I do see lots of references to std::__cxx11::basic_string<…> in the output from “nm -gC”, but someone else would be better placed than me to give an opinion on whether this is enough for a rebuild. - Ben. -- A/Prof Benjamin Burton Computational Geometry & Topology Group School of Mathematics and Physics The University of Queensland, Australia
Bug#797292: regina-normal now builds
close 797292 thanks Okay, so on further digging I believe the problem was related to mixed versions of boost-regex. The build failure that was reported in #797292 used a version of source-highlight that was built against boost 1.55, whereas the regina-normal build itself was using boost 1.58 in regina-normal. This was indeed reported in the build log that was filed with this bug: /usr/bin/ld: warning: libboost_regex.so.1.55.0, needed by /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libsource-highlight.so, may conflict with libboost_regex.so.1.58.0 Since source-highlight has been binNMUed to build against boost 1.58, this issue should have gone away. Indeed, when I try it now on sid, the build succeeds. I’m therefore marking this bug as closed - with the passage of time it has happily fixed itself. - Ben.
Bug#797234: source-highlight library rename
block 797292 by 797234 thanks I’ve confirmed that rebuilding source-highlight with gcc5 fixes the FTBFS in regina-normal. > More details? Wiki page? There is some information at: https://wiki.debian.org/GCC5 https://lists.debian.org/debian-devel-announce/2015/08/msg2.html - Ben. -- A/Prof Benjamin Burton Computational Geometry & Topology Group School of Mathematics and Physics The University of Queensland, Australia
Bug#769700: regina-normal: missing /usr/bin/censuslookup
Package: regina-normal Version: 4.96-1 Severity: important The utility /usr/bin/censuslookup was introduced in the upstream version 4.96 (it provides access to the new fast census lookup facility). However, this utility was inadvertently omitted from the 4.96-1 debian packages. As a result, the census lookup facility does not work at all. Other aspects of regina-normal work fine. The fix is a one-liner: add /usr/bin/censuslookup to debian/regina-normal.install. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604322: Trying to remove kdelibs4c2a from regina-normal
> I removed that line :-/ > Ah.. hmm, okay. Maybe it's related to the docs? I saw that some kde docs were being > generated > The doxygen docs should still be generated, but the KDE docs are part of the KDE build, and should be skipped if --disable-kdeui is passed. Anyway: I'm looking into it now. - b.
Bug#604322: Trying to remove kdelibs4c2a from regina-normal
Hi Lisandro, Thanks for looking into this. The build fails after: > > ># All good! >touch configure-stamp > > with exit status 2. > The problem is the sanity checks in debian/rules, right between configure and touch configure-stamp. (This verifies that all the necessary bits are going to be built.) The solution is to comment out the test for REGINA_BUILD_KDEUI (line 71 in my copy of debian/rules, hopefully somewhere close to there in yours). - Ben.
Bug#615578: RM: regina-normal -- RoQA; kde3-cruft, pseudo-orphaned
> > That would be great. We can tag the bug as help if you do not have a lot of > free time, and maybe somebody will send a patch. (There is some people who > likes picking up this kind of bugs.) > I would like to be able to remove kdelibs4c2a in 3-4 weeks. > Ah, great. I'll try to get to it this week, but if not then NMUs are of course welcome. As noted in the reply above: the only significant change is adding --disable-kdeui to the configure args, which will remove the GUI-related material from the regina-normal binary package. There should still be several binaries that survive (most critically, /usr/bin/regina-python and the associated /usr/lib/regina/python/regina.so), and the other binary packages (regina-normal-dev, regina-normal-doc and regina-normal-mpi) should be unaffected. - b.
Bug#615578: RM: regina-normal -- RoQA; kde3-cruft, pseudo-orphaned
Hmm, actually: If all kde3 apps are being deleted so that kde3/qt3 can go, of course please > go ahead and remove it. > On second though, please don't. If all kde3 apps have to go, I'd prefer to upload a new build without the KDE interface (but still including the mathematical library, python interface and other command-line tools), which is still useful in its own right, and then upload again with a GUI when the kde4 port is done. Essentially, this would just require a ./configure with --disable-kdeui, then ship whatever survives. Please let me know how urgent this is (days, weeks, months). Thanks - Ben.
Bug#615576: O: snappea -- development files for SnapPea hyperbolic 3-manifold tool
Hi, > Package: snappea > Whoever picks this up: I would encourage you to replace this version of snappea (which is old and no longer maintained upstream) with the newer snappy framework: http://www.math.uic.edu/t3m/SnapPy/ - Ben.
Bug#615578: RM: regina-normal -- RoQA; kde3-cruft, pseudo-orphaned
Hi, Please remove regina-normal from the archive. Maintainer (and upstream) > is MIA. > Ben, please, consider porting it to kde 4. > The kde4 port is actively underway; unfortunately this is taking some time (it's happening alongside some other large changes, and regina-normal is a complex package, more than just a standalone app). If all kde3 apps are being deleted so that kde3/qt3 can go, of course please go ahead and remove it. Otherwise I'd be happy for this package to hang around until the port is complete (hopefully March or April, but of course who knows). - Ben.
Bug#574777: decompyle: should this package be removed?
Hi Jakub, While reviewing some packages, your package came up as a possible > candidate for removal from Debian, because: > - upstream is dead; > - there's been no maintainer upload since 2006; > - decompiling byte-code produced by any modern (>= 2.4) Python is not > supported, thus the package is mostly unusable. > Agreed; > If you agree that it should be removed, send the following commands to > cont...@bugs.debian.org (replace nn with this bug's number): > Done. b.
