Bug#1085226: barrier: No man page for barrier
Package: barrier Version: 2.4.0+dfsg-3 Severity: normal I spent quite a while trying to get barriers and barrierc to work as those were documented in the man pages. It wasn't until I found the /usr/share/doc/barrier/README.md.gz that I discovered there was a 'barrier' GUI which is a great deal easier to set up/experiment-with and that enabled me to eventually work out that barriers/barrierc weren't working because there is no .pem SSL cert generated (bug #1072091) I should probably have started with the README, but a man page for barrier would have sent me in the right direction to start with. This package is clearly in a bit of a bad way and this just makes it a bit harder to work out what's wrong. Reading the bug reports first would also have helped a lot. -- Wookey
Bug#1016593: Barrier config file stored in a misleading dir
I also note that the man page for barrers says the config is looked for in yet another directory: $HOME/.local/share/barrier/.barrier.conf I've not yet worked out whether it actually checks there. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1085091: josm: OAuth token request process does not work
On 2024-10-14 14:55 +0200, Sebastiaan Couwenberg wrote: > On 10/14/24 2:43 PM, Wookey wrote: > > I have been using josm for many years, and when it was et up it used basic > > auth (name+password). > > That functionality has been withdrawn and now oauth is supposed to be used. > > You need to use OAuth 2.0 now: > > https://josm.openstreetmap.de/wiki/Help/Preferences/Connection#oauth2 > > This is available in the version in bookworm-backports, as OAuth2 support was > introduced in 18650: > > https://josm.openstreetmap.de/ticket/20768#comment:53 > > And support for OAuth 1.0a was removed in 18991: > > https://josm.openstreetmap.de/ticket/22810#comment:25 OK. Thanks. Installing the backports version and using the automatic 'get me a token' button does indeed work fine. (and I just did a load of edits to check it works) It might be useful to leave this bug around until the next stable release so others can discover this. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1085091: josm: OAuth token request process does not work
Source: josm Version: 0.0.svn18646+dfsg-1 Severity: important I have been using josm for many years, and when it was et up it used basic auth (name+password). That functionality has been withdrawn and now oauth is supposed to be used. However I am unable to get this to work, and it seems that this versionof josm is not asking on the right URLs. If I use the 'Authorise now (fully automatic)' button I get: "The automatic process for retrieving an OAuth Access Token from the OSM server failed. Please try again or choose another kind of authorisation process, i.e. semi-automatic or manual authorisation." after clicking on the 'Authorise now' button. If I use the 'Authorise now (semi-automatic)' button, in step 1 when I click on 'retreive request token' it says: "Retrieving an OAuth Request Token from 'https://www.openstreetmap.org/oauth/request_token' failed. And indeed if I go manually to "https://www.openstreetmap.org/oauth/request_token"; I get a 404. So I presume some different URL should be used now? If I click on the help button in that dialog I get "The page En_GB:Help/OAuth does not exist. You can create it here." The text above the 'Retreive Request Token' button says: "Please click on Retrieve Request Token to retrieve an OAuth Request Token from ''." which suggests there there is an unset value that should be appearing in between those single quoes? It's not clear how to fix this. I presume the software is now simply too old for the website. Or more accurately the website has not kept the API going long enough for the software still in use in stable versions, which is poor practise IMHO. Would it really be that hard to keep it working until there was a new stable version that knew about whatever the new URLs are? This is quite a serious problem because JOSM without the ability to upload to OSM isn't really very useful. -- Wookey
Bug#1065416: requesting input on recent posts to #1065416
On 2024-08-16 19:35 +0200, Bastian Blank wrote: > > - Bastian's assertion that the current linux-libc-dev package doesn't > >break anything in the archive, doesn't say anything. These bits > >are just not used by anything in the archive. > > Ah, now we finally get somewhere. All of this is about non-Debian. Breaking "cross-compiling with debian tools on debian" is significant. It's not helpful to characterise that as 'non-Debian'. It's something we've done well for a long time, and is the reason some people use Debian. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1078532: gpxviewer: Add support for more external editors
On 2024-08-12 14:07 +0200, Jochen Sprickerhof wrote: > * Wookey [2024-08-12 12:59]: > > Pull requests are (AIUI) github's proprietary interface. I have have never > > used those and am not keen to start. > > I don't want to force you to use anything proprietary but I fail to see how > they are special. They work the same way as a merge request on Gitlab/Salsa > and are basically just a git branch and work just like a Github issue, > otherwise. An interesting philiosophical question that I shall ponder further. > If you have no intention to look into it, would you be ok if I send your > patch upstream instead? Absolutely. Please do. I think that's easiest for now. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1078532: gpxviewer: Add support for more external editors
On 2024-08-12 06:14 +0200, Jochen Sprickerhof wrote: > * Wookey [2024-08-12 05:07]: > > On 2024-08-12 05:33 +0200, Jochen Sprickerhof wrote: > > > Hi Wookey, > > > > > > thanks for your patch, it looks good to me. Could you please also send it > > > upstream: > > > > > > https://github.com/andrewgee/gpxviewer > > > > I would do, but I can't see how to file a bug there. There is no 'issues' > > button. > > Just send a pull request: > > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork Pull requests are (AIUI) github's proprietary interface. I have have never used those and am not keen to start. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1078532: gpxviewer: Add support for more external editors
On 2024-08-12 05:33 +0200, Jochen Sprickerhof wrote: > Hi Wookey, > > thanks for your patch, it looks good to me. Could you please also send it > upstream: > > https://github.com/andrewgee/gpxviewer I would do, but I can't see how to file a bug there. There is no 'issues' button. There is a gitter.im link, which might be a place to send reports/patches, but I can't work out to sign in/up to that even though it just seems to be matrix/element. Can I just use my existing matrix account? > And maybe even ask for a new release? > > Anyway, feel free to NMU, team upload or even add yourself as a maintainer. OK. Will take a look at that as tuits allow. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1078533: gpxviewer: Packge does not clean properly so a 2nd build fails
Package: gpxviewer Version: 1.1.0-5 Severity: normal Tags: patch I noticed from updating this package that it does not build a second time. The file po/gpxviewer.pot is not cleaned by the build so the rebuild fails. Simple patch attached. -- Wookey diff -Nru gpxviewer-1.1.0/debian/clean gpxviewer-1.1.0/debian/clean --- gpxviewer-1.1.0/debian/clean2022-11-24 16:44:19.0 + +++ gpxviewer-1.1.0/debian/clean2024-08-12 00:07:59.0 +0100 @@ -1,1 +1,2 @@ gpxviewer.egg-info/ +po/gpxviewer.pot
Bug#1078532: gpxviewer: Add support for more external editors
Sorry - there was a typo in that original patch.
Fixed one attached
)' -> ')
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
diff -Nru gpxviewer-1.1.0/debian/changelog gpxviewer-1.1.0/debian/changelog
--- gpxviewer-1.1.0/debian/changelog 2022-11-24 16:44:19.0 +
+++ gpxviewer-1.1.0/debian/changelog 2024-08-12 00:07:59.0 +0100
@@ -1,3 +1,10 @@
+gpxviewer (1.1.0-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for more external editors
+
+ -- Wookey Mon, 12 Aug 2024 00:07:59 +0100
+
gpxviewer (1.1.0-5) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru gpxviewer-1.1.0/debian/patches/add-more-editors.patch gpxviewer-1.1.0/debian/patches/add-more-editors.patch
--- gpxviewer-1.1.0/debian/patches/add-more-editors.patch 1970-01-01 01:00:00.0 +0100
+++ gpxviewer-1.1.0/debian/patches/add-more-editors.patch 2024-08-12 00:07:59.0 +0100
@@ -0,0 +1,14 @@
+Index: gpxviewer-1.1.0/gpxviewer/ui.py
+===
+--- gpxviewer-1.1.0.orig/gpxviewer/ui.py
gpxviewer-1.1.0/gpxviewer/ui.py
+@@ -172,6 +172,9 @@ class MainWindow:
+ programs = {
+ 'josm': N_('JOSM Editor'),
+ 'merkaartor': N_('Merkaartor'),
++'gpsprune': N_('GPSprune'),
++'viking': N_('Viking'),
++'gpsmaster': N_('GPS-Master')
+ }
+ submenu_open_with = Gtk.Menu()
+ for prog, progname in programs.items():
diff -Nru gpxviewer-1.1.0/debian/patches/series gpxviewer-1.1.0/debian/patches/series
--- gpxviewer-1.1.0/debian/patches/series 2022-11-24 16:44:19.0 +
+++ gpxviewer-1.1.0/debian/patches/series 2024-08-12 00:07:59.0 +0100
@@ -1,2 +1,3 @@
0001-Set-default-map-source.patch
0002-Only-set-date-time-label-if-data-is-available.patch
+add-more-editors.patch
signature.asc
Description: PGP signature
Bug#1078532: gpxviewer: Add support for more external editors
Package: gpxviewer
Version: 1.1.0-5
Severity: wishlist
Tags: patch upstream
The two external programs supported by gpxviewer are quite heavyweight
(JOSM and Merkaator). In practice I usually want to use something bit
simpler: GPSprune, Viking or GPSMaster for track editing. So
supporting those seems like a good idea and is very easy to do.
I have included a patch for this.
I could be persuaded to do an NMU for this improved functionality, and
maybe do some other updates at the same time. Any reason not to?
--
Wookey
diff -Nru gpxviewer-1.1.0/debian/changelog gpxviewer-1.1.0/debian/changelog
--- gpxviewer-1.1.0/debian/changelog2022-11-24 16:44:19.0 +
+++ gpxviewer-1.1.0/debian/changelog2024-08-12 00:07:59.0 +0100
@@ -1,3 +1,10 @@
+gpxviewer (1.1.0-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add support for more external editors
+
+ -- Wookey Mon, 12 Aug 2024 00:07:59 +0100
+
gpxviewer (1.1.0-5) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru gpxviewer-1.1.0/debian/patches/add-more-editors.patch
gpxviewer-1.1.0/debian/patches/add-more-editors.patch
--- gpxviewer-1.1.0/debian/patches/add-more-editors.patch 1970-01-01
01:00:00.0 +0100
+++ gpxviewer-1.1.0/debian/patches/add-more-editors.patch 2024-08-12
00:07:59.0 +0100
@@ -0,0 +1,14 @@
+Index: gpxviewer-1.1.0/gpxviewer/ui.py
+===
+--- gpxviewer-1.1.0.orig/gpxviewer/ui.py
gpxviewer-1.1.0/gpxviewer/ui.py
+@@ -172,6 +172,9 @@ class MainWindow:
+ programs = {
+ 'josm': N_('JOSM Editor'),
+ 'merkaartor': N_('Merkaartor'),
++'gpsprune': N_('GPSprune'),
++'viking': N_('Viking'),
++'gpsmaster': N_('GPS-Master)'
+ }
+ submenu_open_with = Gtk.Menu()
+ for prog, progname in programs.items():
diff -Nru gpxviewer-1.1.0/debian/patches/series
gpxviewer-1.1.0/debian/patches/series
--- gpxviewer-1.1.0/debian/patches/series 2022-11-24 16:44:19.0
+
+++ gpxviewer-1.1.0/debian/patches/series 2024-08-12 00:07:59.0
+0100
@@ -1,2 +1,3 @@
0001-Set-default-map-source.patch
0002-Only-set-date-time-label-if-data-is-available.patch
+add-more-editors.patch
Bug#1071160: Fix in stable
Hi all, We'd like to know if there's an update planned for stable too, these could be nasty and are flagging in our security software. If there's anything that we can do to help let us know. Regards Rowan
Bug#832161: can't run
I just downloaded gposmaster 0.64.02 and the jar runs fine on current debian stable: java -jar GpsMaster_0.64.02.jar It does look like a nice package and I agree it has a nicer interface that either GPSprune or qmapshack. I will use it a bit more to see if it really provides enough advantage over the other tools available. It is quite easy to use unpackaged, but as no-one else has got far with this in the last 8 years, I might give it a packaging go sometime if the UI advantages and packaging effort align. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1068709: dose-extra: Typo in /usr/share/doc/dose-extra/README.architecture
Package: dose-extra Version: 7.0.0-1+b2 Severity: minor There is a trivial typo in line 17 of /usr/share/doc/dose-extra/README.architecture "libcduf is the central - in memory - data structure" libcduf->libcudf -- Wookey
Bug#1068288: openjdk-21: bootstrap builds required on armel and armhf
I have bootstrapped openjdk-21 on armhf (via profile nocheck builds for openjdk-20 and 21). This was slow as each build is about 5 hours on the softiron machine I have to hand. jtreg6/7 (which does the tests) being uninstallable until you've got a version of java built against the t64 libraries is why I needed to first build DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -B -Pnocheck -d and then dpkg-buildpackage -B Uploaded just now. For armel I will follow doko's suggestion of building -21 normally in testing then use those binaries to build in unstable as it's only 2 builds, not 3. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1068288: openjdk-21: bootstrap builds required on armel and armhf
On 2024-04-03 00:20 +0200, Sebastian Ramacher wrote: > building openjdk-21 is currently still stuck on openjdk-21 > build-depending on itself: > > https://buildd.debian.org/status/package.php?p=openjdk-21 > > > Somebody did the work to provide boostrap builds of openjdk-17 on armel > and armhf. We need the same for openjdk-21. Yes. I had a look at this. I was hoping to use the openjdk-17 to allow building of openjdk-21. But it doesn't 'just work', because: checking for version string... 21.0.3-ea+7-Debian-1 configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /usr/lib/jvm/java-17-openjdk-armhf is incorrect JDK version (openjdk version "17.0.11-ea" 2024-04-16 OpenJDK Runtime Environment (build 17.0.11-ea+7-Debian-1) OpenJDK Server VM (build 17.0.11-ea+7-Debian-1, mixed mode, sharing)); ignoring configure: (Your Boot JDK version must be one of: 20 21) configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK Now what I'm not sure is whether openjdk-21 _actually_ needs openjdk 20 (or 21), or if it just needs 'java', and has been set to '20 or 21' for reasons of being able to drop -17 in due course. Nor where these things are configured. If it _does_ need -20, then can I build -20 with -17 or -19 with -17 and so on? The advantage of going straight to -21 is that it's not in the archive already and 'just' needs a binary build. and also -21 has had its build-deps modified for t64 dependencies. -20 and -19 haven't been -20 needs -19 (and jtreg7 but one can use -Pnocheck) -19 needs -18 (and jtreg6 but one can use -Pnocheck) So right now I'm not sure what the easiest path is. Can I actually just build -21 with -17 if I can persuade the build system, or will something important break with that much version-skew? can I build -19 with -17 (and appropriate t64 dep updates) (-18 is no longer in the archive so I really hope we don't need to go 18,19,20,21 Clues welcome on the best approach. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 22:30 +, Thorsten Glaser wrote: > >OK, got those. but that's just binaries. It was the source changes I > >was looking for (or did I misunderstand and you didn't actually make > >any of those?), > > Yes, I did not make any source changes. These were the last binaries > from before the t64 transition (I downloaded the .deb files unchanged) > with just control.tar.xz/control changed to allow installation given > the relevant libraries were already rebuilt for t64. OK. I get it now. > > but actually having an openjdk binaries is very useful > >too to satisfy the self-dependency without more faff. > > Yes, that was their purpose. And it worked beatifully. Thanks. armhf and armel uploaded and accepted half an hour ago (armel built by Andrey Rakhmatullin) I'll try doing openjdk-20 next. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-27 15:27 +, Wookey wrote: > On 2024-03-26 22:28 +, Thorsten Glaser wrote: > > > I hacked that, and I tried to do armel and armhf as well but > > dak stopped me, whereas mini-dak was not as strict. > > What was the actual problem with uploading the images you built? Just > not having any corresponding source? Or something more complicated? Answering my own question: There have been a couple of new openjdk-17 uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build (17.0.10+7-1) is out of date. But it does a great job of filling the self-dependency so I can build the current version. So I now have all the pieces (on armhf, not checked armel yet but hopefully it matches) Building now... Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 22:28 +, Thorsten Glaser wrote: > I hacked that, and I tried to do armel and armhf as well but > dak stopped me, whereas mini-dak was not as strict. What was the actual problem with uploading the images you built? Just not having any corresponding source? Or something more complicated? It seems to me you've done all the hard work - we just need to work out how to get those packages into the archive. Maybe that needs a rebuild with corresponding source? Although if we already have the source just making a new changes file with all the right piece in should be enough, should it not? or am I missing something? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 10:35 +, Simon McVittie wrote: > It seems that some of the dependency chains for packages that are still > waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the > default Java version for most architectures and Build-Depends on itself > (with an alternative dependency on openjdk-16, but that no longer exists). > evolution-data-server -> libphonenumber-dev is an example. > > Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow? I looked at this last week, but got stuck because openjdk-17's build-deps included graphviz which was also uninstallable and led to another blocked chain with ghostscript,cups and libgtk2 conflicting about their t64 status. Checking again now, apt still complains: The following packages have unmet dependencies: apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be installed libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be installed But dose now says there is a solution, unlike last week. So it should be possible to get the dependencies in place (without unreasonable jiggery-pokery) and bootstrap it. I'll have another go tomorrow. > Or do maintainers of packages that build both a C/C++ library and Java > bindings from a single source package need to disable its Java bindings > on the affected architectures, either temporarily or permanently? Some of that might still be expedient, but hopefully we can get a t64 java soon and it won't be necessary. We have to do that sooner or later anyway. > openjdk-21 is in a similar situation, build-depending on itself, while > openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. > Presumably once we have a single OpenJDK version that is installable, > it would be possible to step through 18,19,20,21 building each version > with the previous one. I presume the same, but don't actually know how old a java you can use to bootstrap each newer java. Is it always just one version? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1066860: libprelude ftbfs on time_t64 archs
This package FTBFS on armhf and armel as well: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wbad-function-cast -Wcast-qual -Wcast-align -Wnested-externs -Wunused -Wformat -Wformat-security -I./include -I.. -I../src/include -I./libprelude-error -I../libmissing -I../libmissing -I/usr/include/p11-kit-1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/wookey/debian/libprelude-5.2.0=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -c prelude-log.c -fPIC -DPIC -o .libs/prelude-log.o prelude-log.c: In function 'do_log_v': prelude-log.c:51:50: error: incompatible type for argument 1 of 'memmove' 51 | # define PRELUDE_VA_COPY(ap1, ap2) memmove ((ap1), (ap2), sizeof(va_list)) | ^ | | | va_list prelude-log.c:229:9: note: in expansion of macro 'PRELUDE_VA_COPY' 229 | PRELUDE_VA_COPY(bkp, ap); | ^~~ In file included from /usr/include/features.h:490, from /usr/include/arm-linux-gnueabihf/sys/types.h:25, from ../libmissing/sys/types.h:39, from ../libmissing/ftw_.h:20, from ./include/libmissing.h:34, from prelude-log.c:24: /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:1: note: expected 'void *' but argument is of type 'va_list' 34 | __NTH (memmove (void *__dest, const void *__src, size_t __len)) | ^ prelude-log.c:51:57: error: incompatible type for argument 2 of 'memmove' 51 | # define PRELUDE_VA_COPY(ap1, ap2) memmove ((ap1), (ap2), sizeof(va_list)) | ^ | | | va_list prelude-log.c:229:9: note: in expansion of macro 'PRELUDE_VA_COPY' 229 | PRELUDE_VA_COPY(bkp, ap); | ^~~ /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:1: note: expected 'const void *' but argument is of type 'va_list' 34 | __NTH (memmove (void *__dest, const void *__src, size_t __len)) | ^ There are some warnings too Build logs: https://buildd.debian.org/status/fetch.php?pkg=libprelude&arch=armhf&ver=5.2.0-5.3&stamp=1709143897&raw=0 https://buildd.debian.org/status/fetch.php?pkg=libprelude&arch=armel&ver=5.2.0-5.3&stamp=1710726391&raw=0 Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1065787: 64-bit time_t transition: cargo needs manual intervention
On 2024-03-14 22:03 -0700, Otto Kekäläinen wrote: > Hi! > > Is anyone perhaps planning to fix cargo? Yes. We have been working on it this week (e.g. ema built cargo for armhf), but that is not sufficient to unbung the curl->stunnel4->python->crypography->cargo loop. I tried building the patched stunnel4 last night but got stuck on other missing dependencies, and just about everything being uninstallable (and then my wife made me do something else for the rest of the evening). > For example curl isn't building on armel/armhf now and numerous packages > that depend of curl are not building on armel/armhf. We are well aware that this is broken and blocking lots of things. Co-ordinate efforts on the #debian-arm channel. There are plenty of other loops to unbung too. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1062722: qt-qml-models: NMU diff for 64-bit time_t transition
On 2024-02-02 22:34 +, Sergio Durigan Junior wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > qt-qml-models as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). This library is packaged as a dependency of cavewhere. But cavewhere has not yet been uploaded to the archive. It's quite specific and thus has no other reverse dependencies, so in fact it has no dependencies and is currently effectively unused in the archive. Thus there is no need to rename it as part of this transition. A rebuild when it's dependencies (qtbase5-dev, qtbase5-private-dev, qtdeclarative5-dev) are uploaded would be sufficient. I will try and get it to pass the abi-checker and see if it actually changes ABI or not. I suspect not, but qt is complicated so it's possible. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#889036: kazam: When selecting an area, the screen is greyed-out
I just tried this software and got the same problem. This is on Debian 12 (bookworm). My desktop is xfce. It does not have a compositor running. (I had to turn the compositor off because it gives me serious tearing/flashing/sync issues with any window that isn't firefox). I did not get a warning about a compositor when running it from a console. I do get this on startup: $ kazam WARNING Kazam - Failed to correctly detect operating system. /usr/lib/python3/dist-packages/kazam/app.py:145: Warning: value "((GtkIconSize) 32)" of type 'GtkIconSize' is invalid or out of range for property 'icon-size' of type 'GtkIconSize' self.builder.add_from_file(os.path.join(prefs.datadir, "ui", "kazam.ui")) (kazam:3156444): Gtk-WARNING **: 18:52:04.693: Can't set a parent on widget which has a parent (kazam:3156444): Gtk-WARNING **: 18:52:04.702: Can't set a parent on widget which has a parent There are no further messages when blindly selecting the window. The recording 'per window' does not work. I get a black screen with the mouse cursor on it and many ghosts of the cursos as it moves about. Nothing in the actual window is recorded. Recording of the whole screen _does_ work, but it only records the top left-hand quarter of the screen. This will be an issue with the hidpi screen and the fact that GDK_SCALE=2. That should be a different bug report. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1008135: ITP: libbacktrace -- Backtrace library (for C/C++ apps)
I packaged this as a ststic library, but it's policy to provide a dynamic library too if appropriate. So I asked upstream about this. The discussion took place primarily as an upstream github issue: https://github.com/ianlancetaylor/libbacktrace/issues/85 Here is a summary: Wookey: Firstly, I see that it only builds a static library. Is that a technical limitation to do with the backtracing or the way it is intended to be used, (or something to do with there being no ABI-stability guarantees like libiberty) or just a 'no-one asked for a dynamic version yet' thing? Obviously in distro-world we'd normally build a dynamic version (and a static version) and use them as required. So I'm just wondering if there is a reason why I shouldn't do that? Ian Lance taylor: I would be a bit surprised if libbacktrace works as a dynamic library, but maybe it does. I haven't tried it. Discussion continued in issue #85 on github: https://github.com/ianlancetaylor/libbacktrace/issues/85 Ian Lance taylor: The libbacktrace library explicitly supports being invoked from a signal handler, but that most likely won't work if it is linked in as a dynamic library. So in normal use, without additional information, it should be linked statically. My concern is that lazy PLT calls may not work reliably if invoked via a signal handler. I don't know whether this concern is completely valid. It can be obviated by using `-Wl,-z,now` when linking. Carlos Galvez also asked about dynamic linking the library from Boost.Stacktrace, so there are other possible users. (end of summary) It's easy to build the dynamic version of the library as well, but I'm not yet sure if that's a good idea for the debian package, as we use -z,relro by default in debian. I will uploaded a dynamic-only version for now as this has already stalled for more than a year. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#972525: sbuild randomly fails to sign changes file despite valid signature keys
I've been seeing this regularly, and getting hundreds of 'dupload failed' emails as a result (they get sent every 5 mins now after it goes wrong). I've not been keeping records, (because I just bin those hundreds of emails) but it happens most weeks, and I've had two this week (opencv and gnuradio) I'll start collecting info here to see if we can narrow this down a bit. So, latest is opencv_4.6.0+dfsg-13.1~exp1_armel built for experimental on arm-ubc-06 the changes file is Feb 4 03:29 Looking in the build logs I see it was built and uploaded successfully 3hrs later on arm-arm-03 https://buildd.debian.org/status/architecture.php?a=armel&suite=experimental&buildd=buildd_armel-arm-ubc-06 https://buildd.debian.org/status/architecture.php?a=armel&suite=experimental&buildd=buildd_armel-arm-arm-03 The second build started 1hr after the .changes files for the frist one was made, so I guess there is a timeout of 1hr after the log arrives and if there is no uploade by then the buildd assumes failure and schedules another build? I have noticed before that usually by the time I look at the failed upload there is already a new build uploaded. It would be nice if the buildds tidied up after themselves once the build is in the archive and stopped sending tiresome email awaiting a manual clear-up. Once a new build has been issued the old failed upload should be removed. I'm not quite sure exactly what that check should look like. Alternatively we could stop sending very frequent mail to buildd admins, and let the 'are files a week old' script tidy them up in due course. The actual error on the failed log is: Finished at 2024-02-04T03:29:15Z Signature with key '764BC9A1354021955868EF5CC98724D9AA73AAA3' requested: signfile buildinfo /home/buildd/build/opencv_4.6.0+dfsg-13.1~exp1_armel-buildd.buildinfo 764BC9A1354021955868EF5CC98724D9AA73AAA3 gpg: error running '/usr/bin/gpg-agent': exit status 2 gpg: failed to start agent '/usr/bin/gpg-agent': General error gpg: can't connect to the agent: General error gpg: keydb_search failed: No agent running gpg: skipped "764BC9A1354021955868EF5CC98724D9AA73AAA3": No agent running gpg: /tmp/debsign.e1vK8yhj/opencv_4.6.0+dfsg-13.1~exp1_armel-buildd.buildinfo: clear-sign failed: No agent running debsign: gpg error occurred! Aborting Looking in var/log/messages at that time (on arm-ubc-06) We see that some script set to log starts 1 second after sbuild returns, at 03:29:16 and sends no more messages after 03:30:38. So takes 1m22s (82s) to run. Does that indicate the suspected high load which might be making gpg fail? I don't think we log load per se, do we? It has a lot of debs to check so I think it just takes a while. times for running that script in this log for various packages: 16s singular_4.3.2-p10+ds-1.1~exp1_armel 15s redland_1.0.17-3.1~exp1_armel 9s shapetools_1.4pl6-16.1~exp1_armel 9s solvespace_3.1+ds1-3.1~exp1_armel 8s secsipidx_1.3.2-2.1~exp1_armel 8s scamper_20211212-1.2~exp1_armel 6s rttr_0.9.6+dfsg1-6.1~exp1_armel 8s mfem_4.5.2+ds-1.5~exp1_armel 82s opencv_4.6.0+dfsg-13.1~exp1_armel (failed to sign) 15s rhvoice_1.8.0+dfsg-3.1~exp1_armel 5s libposix-2008-perl_0.23-1_armel 4s rust-expectrl_0.7.1-2_armel 5s liblinux-fd-perl_0.016-1_armel 10s swami_2.2.2-2.1~exp1_armel 6s symmetrica_3.0.1+ds-2.1~exp1_armel 9s muffin_5.8.1-2.1~exp1_armel 5s t4kcommon_0.1.1-11.1~exp1_armel 4s netperfmeter_1.9.6-1_armel 6s pidgin-skype_20240122+gitab786a3+dfsg-2_armel 6s tinyframe_0.1.1-4.1~exp1_armel 5s toontag_0.0~git20220105193632.41237ef-2.1~exp1_armhf 4s tse3_0.3.1-6.1~exp1_armel 86s gcc-10_10.5.0-3_armel 5s lomiri-camera-app_4.0.5+dfsg-1_armel 8s opendmarc_1.4.2-4.1~exp1_armel 154s libreoffice_24.2.0-1~bpo12+1_armel 59s gnuradio_3.10.9.2-1.1~exp1_armel(failed to sign) So opencv is not the longest package to process. libreoffice takes quite a lot longer. , gcc-10 slightly longer. But most are way quicker. I have noticed that it's usually larger packages that go wrong. (libreoffice, gcc, binutils, but not always) Not sure if any of this info helps but that's my investigations today. Suggestions for other monitoring, or the best way to work around it by not fixing it, just making it less annoying, welcome. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1061566: urlscan: Man page points to wronly-named README file
Package: urlscan Version: 0.9.9-1 Severity: minor Tags: patch upstream The man page in this page lists the readme in the 'See Also' section. But the filename is wrong. In v0.9.9-1 the man page says: /usr/share/doc/urlscan/README and the file installed is /usr/share/doc/urlscan/README.md.gz This was wrong in 0.8.2-1 too man page still said: /usr/share/doc/urlscan/README but the file installed was: /usr/share/doc/urlscan/README.rst Obviously this isn't a huge deal, but it is annoying to copy-paste the filename and just get an error, then have to investigate. Making them match up would be good. Personally I don't like the way debian gzips small READMEs by default. 'more /usr/share/doc/urlscan/README.md.gz' produces garbage. less and most work, but is saving 4K really worth it here (the original is 7K)? So I'd change the manpage to say /usr/share/doc/urlscan/README.md and prevent the autogzipping. (patch for this attached) But you could just change the manpage to match the filename with the .gz if you prefer. The bit about changing the name (but not the bit about non gzipping) should go upstream as this is an upstream issue. Hope that's helpful. Wookey diff -Nru urlscan-0.9.9/debian/changelog urlscan-0.9.9/debian/changelog --- urlscan-0.9.9/debian/changelog 2022-06-06 22:28:24.0 +0100 +++ urlscan-0.9.9/debian/changelog 2024-01-24 17:12:55.0 + @@ -1,3 +1,10 @@ +urlscan (0.9.9-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Correct README filename in manpage + + -- Wookey Wed, 24 Jan 2024 17:12:55 + + urlscan (0.9.9-1) unstable; urgency=medium * New upstream version 0.9.9 (Closes: #999338) diff -Nru urlscan-0.9.9/debian/patches/fixup-README-filename.patch urlscan-0.9.9/debian/patches/fixup-README-filename.patch --- urlscan-0.9.9/debian/patches/fixup-README-filename.patch1970-01-01 01:00:00.0 +0100 +++ urlscan-0.9.9/debian/patches/fixup-README-filename.patch2024-01-24 17:12:55.0 + @@ -0,0 +1,13 @@ +Index: urlscan-0.9.9/urlscan.1 +=== +--- urlscan-0.9.9.orig/urlscan.1 urlscan-0.9.9/urlscan.1 +@@ -213,7 +213,7 @@ $HOME/.config/urlscan/config.json + Only required if additional or modified palettes or keybindings are desired. + + .SH SEE ALSO +-\fI/usr/share/doc/urlscan/README\fR, ++\fI/usr/share/doc/urlscan/README.md\fR, + \fBurlview\fR(1), + \fBmutt\fR(1) + diff -Nru urlscan-0.9.9/debian/patches/series urlscan-0.9.9/debian/patches/series --- urlscan-0.9.9/debian/patches/series 2022-06-06 22:28:24.0 +0100 +++ urlscan-0.9.9/debian/patches/series 2024-01-24 17:12:55.0 + @@ -1,1 +1,2 @@ 0001-Source-patch-removing-from-binary-package-not-needed.patch +fixup-README-filename.patch diff -Nru urlscan-0.9.9/debian/rules urlscan-0.9.9/debian/rules --- urlscan-0.9.9/debian/rules 2022-06-06 22:28:24.0 +0100 +++ urlscan-0.9.9/debian/rules 2024-01-24 17:12:55.0 + @@ -5,3 +5,6 @@ override_dh_python3: dh_python3 --shebang='/usr/bin/python3' + +override_dh_compress: + dh_compress --exclude README.md
Bug#1061370: gcc-14 ftbfs on armel
On 2024-01-23 09:01 +0100, Matthias Klose wrote: > Package: src:gcc-14 > Version: 14-20240121-1 > Severity: important > Tags: sid trixie ftbfs > X-Debbugs-CC: debian-...@lists.debian.org > > gcc-14 ftbfs on armel. This is a long standing, re-occurring issue which > never has been forwarded and committed by the armel ports to GCC upstream. > Please do it. Why do you want the armel porters to forward this bug upstream, when forwarding bugs upstream is normally the package maintainers job? I mean sure someone could do that, but it's probably not been done so far becuase they thought you would. Is your point that actually it's not just a matter of formwarding - some armel-specific investigation is needed first to work out what's actually wrong? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1061053: httrack: Formatting error on man page
Source: httrack Version: 3.49.4 Severity: minor Tags: patch The text "IMPORTANT NOTE: DANGEROUS OPTION, ONLY SUITABLE FOR EXPERTS USE IT WITH EXTREME CARE" which appears after the '%!' option is formatted as if both lines were further options The attached small patch fixes this. I'm no groff expert so it could possibly be done better, but this certainly fixes the issue so the formatting comes out more or less correct. Wookey -- http://wookware.org/ --- httrack.1.orig 2023-01-14 16:32:49.0 + +++ httrack.1 2024-01-17 03:08:36.724857714 + @@ -456,10 +456,8 @@ .SS Dangerous options: (do NOT use unless you exactly know what you are doing) .IP \-%! bypass built\-in security limits aimed to avoid bandwidth abuses (bandwidth, simultaneous connections) (\-\-disable\-security\-limits) -.IP \-IMPORTANT -NOTE: DANGEROUS OPTION, ONLY SUITABLE FOR EXPERTS -.IP \-USE -IT WITH EXTREME CARE + IMPORTANT NOTE: DANGEROUS OPTION, ONLY SUITABLE FOR EXPERTS + USE IT WITH EXTREME CARE .SS Command\-line specific options: .IP \-V
Bug#1050429: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')
On 2023-11-24 18:58 +, Thorsten Glaser wrote: > Unfortunately, eller is down Eller had to move hosting provider at short notice. It is now racked again but needs network configuration for new location. It will hopefully re-appear by end-Monday. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory
On 2023-11-08 20:10 +0100, Martin Budaj wrote: > On Tue, Nov 7, 2023 at 4:25 PM Wookey wrote: > > > It looks like moving to catch3 and adding: > > target_link_libraries(test PRIVATE Catch2::Catch2WithMain) > > in the test targets should do the trick. > > > > Hi, > > as we still need to maintain Catch2 v2 API compatibility to run CI tests > and builds on older Ubuntu images, we can't simply migrate to v3. Who is building 'latest' Therion on old Ubuntu? And are they getting their sources from the Debian unstable package? Or from Upstream? > For now, I'll just enable using the bundled Catch2 instead of v3 installed > in the system. That's not the right approach for the Debian package, and this bug is about the debian package. Debian unstable has catch 3 in it. We should use it, not an old bundled catch2 copy. Upstream builds and Ubuntu builds can do something different if need be but that's not a good reason for the Debian package not to DTRT. And in general I'd expect current Ubuntu to have catch3 too so using the system version will be appropriate there too. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory
On 2023-10-31 15:31 +0100, Martin Budaj wrote: >Thanks, I'll check it out in a week or so. >Martin We are not the only ones with this problem. This bug: #1054706 and this thread on debian-mentors: https://lists.debian.org/debian-mentors/2023/11/msg00078.html are helpful. Apparently catch2 changed the headers, but then catch 3 changed them back but required a statically-linked library. It looks like moving to catch3 and adding: target_link_libraries(test PRIVATE Catch2::Catch2WithMain) in the test targets should do the trick. More info at https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1041731: Hyphens in man pages
On 2023-10-15 01:30 -0500, G. Branden Robinson wrote: > At 2023-10-14T20:51:27-0600, Antonio Russo wrote: > > Quick background: in the context of Unix usage as documented by > nroff/troff, the dash used at the shell prompt, in text editors, and in > programming language source code is a "minus sign". troff has an em > dash special character as well since the mid-1970s; groff adds an en > dash as well, and furthermore supports user definition of characters > providing access to any other sort of dash that comes down the Unicode > pike. (Not that doing so is a good idea in a man page; see below > regarding a "restricted dialect" of man(7).) > > > Now, depending on your email client and settings, the above will > > appear to be the ravings of an unhinged lunatic who wrote the same > > thing twice, or an unhinged lunatic who slammed their fists onto the > > keyboard. > > This issue does indeed have a history of provoking unhinged lunacy. > > Before we proceed, you might wish to be aware of > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731> and its > proposed remedy. OK. So I read all that, and learned a whole load of stuff I was quite happy not knowing about. However despite reading it all, and especially this bit: "Whenever I've maintained man pages in roff I tend to be precise in > the usage of - and \-, but TBH this has seemed like a lost battle," I was left not actually know what - and \- represent, nor which one I _should_ be using in my man pages. And that seems to be the one thing we should be telling the 'average maintainer'. I think you can consider me representative of the typical maintainer who's intereaction with *roff languages almost entirely takes the form: 'Oh bloody hell I really ought to write a man page for this because upstream is too youthful to have done so - now how the hell does roff/nroff/groff work again' (no I'm not sure which it is I'm actually using, nor how any of this machinery really works, nor where to look for good practice, so I mostly copy existing stuff and DDG for answers, which is less than ideal when it comes to details like this). So this message is mostly a reminder that most people have not been following along at all, so just referring people to bugs like this, which discuss the issue in some detail, is not sufficient for maintainers to stop doign unhelpful things. (Yes I realise I could look it up, but I get the impression that everyone involved in this discusssion assumes people know what '-' and '\-' are so if they are just told to 'use the right one' will do so, and I thought it worth pointing out that that's not correct). Info for your average maintainer needs to go one step back and say "use stringA in this circumstance and stringB in this circumstance. . The reason why it matters is: stuff about hyphen and minus being different and minus being used in commands and cut+pasting being important" Hope that's helpful. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1053649: python3-numpy fails to install due to file clash with python-numpy
Package: python3-numpy Version: 1:1.24.2-1 Severity: important I am upgrading a system (laptop) from bullseye to bookworm. Everything was upgraded fully in bullseye, and all foreign (-dmo) packages removed before starting the upgrade. There were some old packages onthe system, include quite a few pthon-* (python2) packages. I did apt upgrade --without-new-pkgs first (as recomended on debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html) and that went fine, but the subsequent apt full-upgrade failed with: Preparing to unpack .../python3-numpy_1%3a1.24.2-1_amd64.deb ... Unpacking python3-numpy (1:1.24.2-1) ... dpkg: error processing archive /var/cache/apt/archives/python3-numpy_1%3a1.24.2-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/f2py', which is also in package python-numpy 1:1.16.2-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/python3-numpy_1%3a1.24.2-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) trying to remove python-numpy didn't work either: sudo dpkg -r python-numpy dpkg: dependency problems prevent removal of python-numpy: python-gtk2 depends on python-numpy (>= 1:1.13.1). python-gtk2 depends on python-numpy-abi9; however: Package python-numpy-abi9 is not installed. Package python-numpy which provides python-numpy-abi9 is to be removed. python-gtk2 depends on python-numpy (>= 1:1.13.1). python-gtk2 depends on python-numpy-abi9; however: Package python-numpy-abi9 is not installed. Package python-numpy which provides python-numpy-abi9 is to be removed. removing 2 packages together: sudo dpkg -r python-numpy python-gtk2 [sudo] password for tess: (Reading database ... 365279 files and directories currently installed.) Removing python-gtk2 (2.24.0-5.1+b1) ... Removing python-numpy (1:1.16.2-1) ... worked, and then I was able to carry on with apt --fix-broken-install This was a totally normal upgrade (albeit with a few old packages lyng around) , so should have worked. I guess there should be a conflict added to prevent this, which would force the old python-numpy to be removed before the new python3-numpy goes in? Cheers. -- System Information: Debian Release: 12.2 Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python3-numpy depends on: ii libblas3 [libblas.so.3] 3.11.0-2 ii libc62.36-9+deb12u2 ii liblapack3 3.11.0-2 iU python3 3.11.2-1+b1 ii python3-pkg-resources66.1.1-1 ii python3.93.9.2-1
Bug#1052022: ncdu: diff for NMU version 1.19-0.1
Control: tags 1052022 + patch Control: tags 1052022 + pending Dear maintainer, Christian Göttsche has prepared an NMU for ncdu (versioned as 1.19-0.1) (as for the previous 3 versions). This drops a couple of build-fix patches that upstream has adopted and includes the fairly small upstream changes for 1.19. - Fix typo in --exclude-from argument - Add --(enable|disable)-natsort options - Add indicator to apparent size/disk usage selection in the footer I have sponsored this and uploaded it to DELAYED/10. The debdiff is attached. Please feel free to tell me if I should delay it longer. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ diff -Nru ncdu-1.18/ChangeLog ncdu-1.19/ChangeLog --- ncdu-1.18/ChangeLog 2022-12-06 09:45:51.0 + +++ ncdu-1.19/ChangeLog 2023-09-11 20:00:35.0 +0100 @@ -1,3 +1,11 @@ +1.19 - 2023-09-11 + - Fix typo in --exclude-from argument + - Add --(enable|disable)-natsort options + - Add indicator to apparent size/disk usage selection in the footer + +1.18.1 - 2023-02-12 + - Fix build on non-Linux platforms + 1.18 - 2022-12-06 - Fix 'dark-bg' color scheme to actually have a dark background - Backport configuration file support from 2.x diff -Nru ncdu-1.18/configure ncdu-1.19/configure --- ncdu-1.18/configure 2022-12-06 09:47:01.0 + +++ ncdu-1.19/configure 2023-09-11 19:59:45.0 +0100 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.71 for ncdu 1.18. +# Generated by GNU Autoconf 2.71 for ncdu 1.19. # # Report bugs to . # @@ -610,8 +610,8 @@ # Identity of this package. PACKAGE_NAME='ncdu' PACKAGE_TARNAME='ncdu' -PACKAGE_VERSION='1.18' -PACKAGE_STRING='ncdu 1.18' +PACKAGE_VERSION='1.19' +PACKAGE_STRING='ncdu 1.19' PACKAGE_BUGREPORT='proje...@yorhel.nl' PACKAGE_URL='' @@ -1315,7 +1315,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures ncdu 1.18 to adapt to many kinds of systems. +\`configure' configures ncdu 1.19 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1382,7 +1382,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of ncdu 1.18:";; + short | recursive ) echo "Configuration of ncdu 1.19:";; esac cat <<\_ACEOF @@ -1492,7 +1492,7 @@ test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -ncdu configure 1.18 +ncdu configure 1.19 generated by GNU Autoconf 2.71 Copyright (C) 2021 Free Software Foundation, Inc. @@ -1959,7 +1959,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by ncdu $as_me 1.18, which was +It was created by ncdu $as_me 1.19, which was generated by GNU Autoconf 2.71. Invocation command line was $ $0$ac_configure_args_raw @@ -3232,7 +3232,7 @@ # Define the identity of the package. PACKAGE='ncdu' - VERSION='1.18' + VERSION='1.19' printf "%s\n" "#define PACKAGE \"$PACKAGE\"" >>confdefs.h @@ -7317,7 +7317,7 @@ # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by ncdu $as_me 1.18, which was +This file was extended by ncdu $as_me 1.19, which was generated by GNU Autoconf 2.71. Invocation command line was CONFIG_FILES= $CONFIG_FILES @@ -7385,7 +7385,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config='$ac_cs_config_escaped' ac_cs_version="\\ -ncdu config.status 1.18 +ncdu config.status 1.19 configured by $0, generated by GNU Autoconf 2.71, with options \\"\$ac_cs_config\\" diff -Nru ncdu-1.18/configure.ac ncdu-1.19/configure.ac --- ncdu-1.18/configure.ac 2022-12-06 09:46:39.0 + +++ ncdu-1.19/configure.ac 2023-09-11 19:58:01.0 +0100 @@ -1,5 +1,5 @@ -AC_INIT([ncdu],[1.18],[proje...@yorhel.nl]) +AC_INIT([ncdu],[1.19],[proje...@yorhel.nl]) AC_CONFIG_SRCDIR([src/global.h]) AC_CONFIG_HEADERS([config.h]) AM_INIT_AUTOMAKE([foreign std-options subdir-objects]) diff -Nru ncdu-1.18/COPYING ncdu-1.19/COPYING --- ncdu-1.18/COPYING 2022-04-28 10:17:42.0 +0100 +++ ncdu-1.19/COPYING 2023-02-12 07:41:53.0 + @@ -1,4 +1,4 @@ -Copyright (c) 2007-2022 Yoran Heling +Copyright (c) 2007-2023 Yoran Heling Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the diff -Nru ncdu-1.18/debian/changelog ncdu-1.19/debian/changel
Bug#1051879: RFS: ncdu/1.19-0.1 [NMU] -- ncurses disk usage viewer
On 2023-09-13 22:35 +0200, Christian Göttsche wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "ncdu": I have to go to a conference right now, but if no-one has sorted this by Tue next week I can do it for you (I use and enjoy this package). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#918914: Info received (Enabling -fstack-clash-protection for trixie)
On Thu Aug 10 10:49:45 2023, Wookey wrote: > We will do some new archive rebuilds to see what the current status is. That has been done (thanks Lucas) for arm64 and revealed no significant issues. armhf is pending, but local checks show no issues so far. > I've also asked the arm compiler team if there are any known issues with this > feature. There are none. This feature is expected to work fine. (Although it probably hasn't actually been used all that much on arm32 so far - now is the time to turn it on and see if there are any issues in the real world). So we recommend that this is enabled for all 3 arm architectures. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#918914: Enabling -fstack-clash-protection for trixie
On 2023-08-06 23:25 +0200, Moritz Mühlenhoff wrote: > Following the procedure to modify default dpkg-buildflags I propose to > enable -fstack-clash-protection on amd64. The bug for dpkg tracking this > is #918914. > The open question is whether to also enable this for arm64, mips64el, > ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's > consensus among porters of a given arch other than amd64 to also add > the flag, please post a followup to #918914. There is consensus amongst the ARM distro team that this should be turned on for arm64. Our preference is to turn it on for the 32-bit arm arches too. However Ubuntu chose not to enable this on armhf in 2019 after a rebuild test (although it doesn't look significantly worse than arm64 to me on that chart - needs more detailed investigation). We will do some new archive rebuilds to see what the current status is. https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-eoan.html I've also asked the arm compiler team if there are any known issues with this feature. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Source: openjfx Followup-For: Bug #1021894 I was surprised to find that this package was missing on arm64 (making josm uninstallable) so I investigated. 11.0.11+0-1 built OK on 2021-02-03. But 11.0.11+1-3 FTBFS. 11.0.11+0-1 no longer builds either. Failing in: Execution failed for task ':media:buildAVPlugin' ../../../plugins/av/decoder.c:79:5: error: implicit declaration of function 'avcodec_register_all' which seems to be a problem with ffmpeg, but lets ignore that for now - it seems to be fixed with a patch in +1-3 11.0.11+1-3 fails with: [ 28%] Building CXX object Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o Gradle is still running, please be patient... In file included from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:30, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h:46, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h:28, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArithProfile.h:28, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void JSC::ARM64Assembler::replaceWithJump(void*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2576:51: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ 2576 | to = ExecutableAllocator::singleton().getJumpIslandTo(where, to); | ^~~ /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void* JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently(void*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2781:49: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandToConcurrently’ 2781 | return ExecutableAllocator::singleton().getJumpIslandToConcurrently(from, to); | ^~~ /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void JSC::ARM64Assembler::linkJumpOrCall(int*, const int*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:3024:51: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ 3024 | to = ExecutableAllocator::singleton().getJumpIslandTo(bitwise_cast(fromInstruction), to); | ^~~ (Which is actually a different failure point from the one Sebastian posted in this bug) So all this jumpisland stuff comes from webkit's JavaScript JIT. It turns out that this upstream Webkit bug explains what's going on: https://bugs.webkit.org/show_bug.cgi?id=217079 jumpislands allow +-128MB jumps to get to the whole 1GB executable space by having a particular memory layout. And the build should use _either_ the JIT or 'CLOOP', but not both. Applying the patch in that bug (which gates JUMP_ISLANDS on the JIT being enabled, and avoids compiling in a call to dumpJITMemory if JIT is disabled) allows everything to get compiled. However it then fails to link: [100%] Linking CXX shared library ../../lib/libjfxwebkit.so /usr/include/c++/11/ext/new_allocator.h:116: error: undefined reference to 'std::__throw_bad_array_new_length()' collect2: error: ld returned 1 exit status gmake[4]: *** [Source/WebKitLegacy/CMakeFiles/WebKitLegacy.dir/build.make:2237: lib/libjfxwebkit.so] Error 1 Which seems to be a problem with compiling with gcc11/12, but then trying to link to the gcc-libstd++ from gcc10. Removing all the gcc-10 packages from the build environment fixed this. I think this means the package should get a build-conflict on libstdc++-10-dev Also the discussion in the above bug suggests that the JIT should in fact be enabled on debian arm64. It only needs to be turned off on iOS and 64k aarch64 kernel (RHEL). I will test that next. Attached is the debdiff that at least makes the build work again for now. Happy to do an NMU if that's helpful diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog --- openjfx-11.0.11+1/debian/changelog 2023-02-07 14:59:22.0 + +++ openjfx-11.0.11+1/debian/changelog 2023-07-14 11:53:33.0 + @@ -1,3 +1,10 @@ +openjfx (11.0.11+1-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Appl
Bug#1021292: Enabling branch protection on amd64 and arm64
On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote: > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca: > > Hey Moritz, > > > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > > > I think this should rather be applied early after the Bookworm > > > release (and ideally we can also finish off the necessary testing > > > and add -fstack-clash-protection at least for amd64 and other archs > > > which are ready for it (#918914)). > > > > Can we go ahead with the dpkg patch now, any specific tests you had in > > mind before applying it? > > Note that I'm not the one driving this change (I'll start a separate > thread for -fstack-clash-protection in the next days), but the original > request was from Wookey. > Personally I think now at the beginning of the new development cycle > is the ideal time to start this. OK. We're all agreed on that then. Guillem can stick it in the next dpkg upload. I've not yet grokked James' comments above either which maybe imply adjustments to the patch? That's x86 stuff which is not my area of expertise. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1033092: (no subject)
More on this, the autostart works but it only works for increasing in
size, if I decrease it doesn't.
I have found another workaround here
https://superuser.com/questions/1183834/no-auto-resize-with-spice-and-virt-manager
which involves adding a script to watch for display events and trigger
xrandr
#!/bin/sh
sleep 2
xrandr --output "$(xrandr | awk '/ connected/{print $1; exit; }')" --auto
xev -root -event randr | \
grep --line-buffered 'subtype XRROutputChangeNotifyEvent' | \
while read foo ; do \
xrandr --output "$(xrandr | awk '/ connected/{print $1; exit; }')"
--auto
done
Below is the debug log for spice-vdagent when the script isn't in use.
spice-vdagent[1776]: Root size of screen 0 changed to 1920x1080 send 1
spice-vdagent[1776]: display: failed to call GetCurrentState from mutter
over DBUS
spice-vdagent[1776]:error message: Cannot invoke method; proxy is
for the well-known name org.gnome.Mutter.DisplayConfig without an owner,
and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
spice-vdagent[1776]: Unable to find a display id for output index 2)
spice-vdagent[1776]: Unable to find a display id for output index 3)
spice-vdagent[1776]: Sending guest screen resolutions to vdagentd:
spice-vdagent[1776]:display_id=0 - 1920x1080+0+0
spice-vdagent[1776]:display_id=1 - 0x0+0+0
spice-vdagent[1776]: 0x563e06c189e0 sent guest xorg resolution, arg1:
1920, arg2: 1080, size 40
spice-vdagent[1776]: display: failed to call GetCurrentState from mutter
over DBUS
spice-vdagent[1776]:error message: Cannot invoke method; proxy is
for the well-known name org.gnome.Mutter.DisplayConfig without an owner,
and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
spice-vdagent[1776]: Unable to find a display id for output index 2)
spice-vdagent[1776]: Unable to find a display id for output index 3)
spice-vdagent[1776]: Sending guest screen resolutions to vdagentd:
spice-vdagent[1776]:display_id=0 - 1920x1080+0+0
spice-vdagent[1776]:display_id=1 - 0x0+0+0
spice-vdagent[1776]: 0x563e06c189e0 sent guest xorg resolution, arg1:
1920, arg2: 1080, size 40
Bug#1033092: (no subject)
There's a workaround posted on the forums https://forums.debian.net/viewtopic.php?p=774201#p774201 >https://github.com/systemd/systemd/issues/18791 >tl;dr: copy /etc/xdg/autostart/spice-vdagent.desktop to ~/.config/autostart/ then comment out the "X-GNOME-Autostart-Phase" line.
Bug#1033092: (no subject)
Just upgraded from bullseye to bookworm and encountered this, host is on bullseye guest was on bullseye but is now on bookworm, unlike the original reporter adding a spice-vdagent.desktop file does work, the contents are: [Desktop Entry] Exec=/usr/bin/spice-vdagent Icon=dialog-scripts Name=spice-vdagent Path= Type=Application X-KDE-AutostartScript=true Without the desktop file at login spice-vdagent.service and spice-vdagentd.service are both not running. Manually starting them with sudo systemctl start spice-vdagent.service and systemctl start spice-vdagent --user doesn't seem to help the services start but screen resizing doesn't work. Please let me know if you need me to debug further.
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
On 2023-05-16 14:46 +0200, Oliver Reiche wrote: >I'm basically aware of the build dependencies >policy and all of my binary and header-only dependencies are satisfied >from packages. However, my package additionally depends on 11 proto files >(i.e., architecture-independent interface of data encoding [1]) from >google-apis [2] and bazel-remote-apis [3] as a pure build dependency. ... >3. Taking the longer road and package google-apis and bazel-remote-apis >first. This is the right way to fix this. I noticed in 2021 whilst doing tensorflow packaging that quite a few packages were using parts of these but nearly everyone had just embedded some files. We do have parts of the api packaged (e.g ruby-googleapis-common-prootos-types, and there are also ITPs for python-google-api-core and ruby-google-apis-discovery-v1 from jan 2023) but not the whole thing for all the languages. So I started on fixing it properly, and have a build that works for C, C++, java, python3 and ruby, but some language bindings did not build, and clearly I stalled part-way through the process of fixing those. I'm not sure which bindings we actually care about and which we can leave for now. I think I started an email about this somewhere, but am failing to find it right now, so I can't remember exactly where I got to. >However, that raises a few more questions: > a. google-apis is not versioned/tagged upstream. What version would I >use? I've seen that Fedora uses the version string >"0-1.git". I used 0~0-1 to start with. 0~ is a quite a good way of versioning things like this that don't have versions. (that 0~ lets you switch neatly to real versions in the future should they appear). Adding git hashes mostly makes for unreadable versions and doesn't add much IMHO, but we can do that if it's important. > b. Where should proto files be installed to? I know that libprotobuf-dev >puts it in /usr/include, but /usr/share could be also viable. What is the >recommended location? Good question. The right answer may depend on the language. > c. As the file structure of google-apis changes rather frequently, >should there be any prefix, so multiple versions could be installed in >parallel? Debian generally tries to pick a version and make depending packages work with it, rather than try to suport multiple versions unless it really is necessary. I do not have a good feel for what the best approach here is, and would greatly appreciate input from someone more familiar with the codebase on what the best approach in debian might be. >Could you please comment on which option you would suggest to take, and >also briefly address the potential follow-up questions? I suggest we compare notes on this in a specific ITP bug for google-apis. If you have a bit of time to put into this it would be great to actully (finally) get this fixed for the general case. I can provide debian packaging and build expertise to complement your knowledge of google-apis. (and then maybe we can give bazel-remote-apis a very similar treatment). I will put my unfinished project on salsa, file an ITP, and find my notes, then mail you and we can see if we can sort this with a reasonable level of effort. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1035536: codemirror-js: Codemirror 6 is now available
Source: codemirror-js Version: 5.65.0+~cs5.83.9-2 Severity: normal Tags: upstream uscan and the tracking system indicate that v5.65.13 is available, but more significantly codemirror 6 is available too (since june 2022): https://marijnhaverbeke.nl/blog/codemirror-6.html https://discuss.codemirror.net/t/codemirror-6-0-has-been-released/4498 You probably already know this, but I thought it worth filing a bug as tracker.debian.org does not know about v6 so gives a misleading impression about the state of the package with respect to upstream versions. v6 is a complete rewrite but is also the current stable version. It would be good to see it in Debian in the not too distant. What's a bit confusing is exactly where one gets an upstream v6 release from as the project seems to have been split up into multiple repos. -- Wookey
Bug#1034878: meld gives python traceback if run as root
Package: meld Version: 3.22.0-2 Severity: normal I change to root inorder to be able to access some files to diff and ran meld. I got the following traceback: root@mongol:~# meld Traceback (most recent call last): File "/usr/bin/meld", line 463, in sys.exit(main()) ^^ File "/usr/bin/meld", line 458, in main setup_settings() File "/usr/bin/meld", line 317, in setup_settings meld.settings.create_settings() File "/usr/lib/python3/dist-packages/meld/settings.py", line 124, in create_settings _meldsettings = MeldSettings() ^^ File "/usr/lib/python3/dist-packages/meld/settings.py", line 39, in __init__ self.on_setting_changed(settings, 'prefer-dark-theme') File "/usr/lib/python3/dist-packages/meld/settings.py", line 58, in on_setting_changed gtk_settings.props.gtk_application_prefer_dark_theme = prefer_dark ^^ AttributeError: 'NoneType' object has no attribute 'props' ~#meld boot0 boot1 (i.e supplying filenames) gave the same output. meld runs fine when run as the desktop user It should deal more elegantly with this situation. -- Wookey
Bug#1001144: Info received (odbc-mdbtools: Missing dependency on odbcinst)
The attached patch is confirmed as fixing the problem.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
diff -Nru mdbtools-1.0.0+dfsg/debian/changelog mdbtools-1.0.0+dfsg/debian/changelog
--- mdbtools-1.0.0+dfsg/debian/changelog 2021-10-31 14:01:12.0 +
+++ mdbtools-1.0.0+dfsg/debian/changelog 2023-03-02 20:59:21.0 +
@@ -1,3 +1,10 @@
+mdbtools (1.0.0+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add dependency on obdcinst for odbc-mdbtools (Closes:#1001144)
+
+ -- Wookey Thu, 02 Mar 2023 20:59:21 +
+
mdbtools (1.0.0+dfsg-1) unstable; urgency=medium
* New upstream release:
diff -Nru mdbtools-1.0.0+dfsg/debian/control mdbtools-1.0.0+dfsg/debian/control
--- mdbtools-1.0.0+dfsg/debian/control 2021-10-31 13:56:49.0 +
+++ mdbtools-1.0.0+dfsg/debian/control 2023-03-02 20:59:17.0 +
@@ -76,7 +76,7 @@
Multi-Arch: same
Section: libs
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, odbcinst
Recommends: libodbc1
Breaks: libiodbc2 (<< 3.52.7-2+deb7u1),
libmdbodbc1 (<< 0.7.1-1~),
signature.asc
Description: PGP signature
Bug#1001144: odbc-mdbtools: Missing dependency on odbcinst
Package: odbc-mdbtools Version: 1.0.0+dfsg-1+b1 Followup-For: Bug #1001144 I just came across this bug whilst testing -dev packages for ABI changes. This bug makes the package uninstallable and so (as it has been like this for 14 months) I am bumping the bug severity to serious. Missing dependencies violates a 'must' in policy: section 3.5 "Every package must specify the dependency information about other packages that are required for the first to work correctly." I'll do an NMU when I get a mo (next week hopefully) if the maintainer doesn't beat me to it, unless someone knows of a good reason why not. This fix should be accepted for a freeze exception, I think. -- Wookey
Bug#1031664: topparser: Icons are not right
Package: topparser Version: 1.3-2 Severity: minor The 'About' icon is just colour noise. The app icon (in the XFCE 'applications' menu) is missing (red 'X' shown instead) This appears to be because the icon is under icons/hicolor/scalable/ not icons/hicolor/scalable/apps/ -- Wookey
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Just noticed this bug. The discussion in this bug makes me worry that people do not fully understand the implications of enabling 64-bit time and large file system support respectively. It's great to see people starting to care about this issue and fix things (it's overdue), but I'm just chiming in to point out that some care is needed before turning these options on. Debian is in the process of developing a plan for this transition, but has not got very far yet. I have just started a wiki page to cover the issues (and tagged this bug): https://wiki.debian.org/ReleaseGoals/64bit-time https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-de...@lists.debian.org;tag=time64 If tar is currently building without LFS enabled, I'd suggest maybe turning that on, checking things, and uploading before also turning on 64bit time_t. They can be done separately (in that order only). Both have the potential to change file formats and ABIs (although tar is a program not a library so no ABI is exposed). Hopefully upstream has looked at all this carefully and is reasonably sure nothing important will break? For LFS enablement you should be aware that LARGEFILE_SOURCE and FILE_OFFSET_BITS=64 do different things. The former enables both 32 and 64-bit interfaces, the latter chooses the 64-bit interface only. You probably only want the latter. (depending how these are used in the codebase, it may not make any practical difference) For 64-bit time_t enablement you might want to wait for the dpkg standard debian mechanism to appear and use that: https://bugs.debian.org/1030159 You certainly want to be sure that things tar depends on (and expose ABIs or file formats that change) have switched first. Now tar is close to the bottom of the stack so this may well be fine, but it's linked against libacl, libselinux, libc and libpcre2, so we should check those. I am in the process of running abi-compliance-checker over all debian libraries to get a list of ones that expose an ABI change from either enabling LFS or 64bit-time_t. tests so far say: libacl1 is safe (no change) libselinux is unknown (did not build) libpcre2 is unknown (did not build) (I'll take a look at those now as they are pretty fundamental) If you choose to use gnulib, note that it turns 64-bit time on by default if detected in glibc, unless you set a macro to explicitly keep 32-bit time. So in summary, tar is a good candidate for enabling LFS and time64 early but some checks should be done first, unless it is known that there are no external interface changes other than to glibc. I hope that is helpful. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over
On 2023-02-14 16:02 +, Ian Jackson wrote:
> Wookey writes ("Bug#557730: /etc/{protocols,network,services} not schroot's
> to scribble over"):
> > 2) netbase could be installed in base chroots then the problem would not
> > arise (or only arise once).
> >
> A downside is that missing build-dependencies on netbase would no
> longer be detected. One alternative would be to declare netbase
> build-essential. TBH I'm not sure why that hasn't been done already.
Good point. And related to recent debian-devel discussion about bare
build chroots actually being bare so that missing build-deps are
indeed discovered. I don't think that just adding more things to
'essential' is actually helpful here. netbase is not essential,
especially for builds that explicitly mustn't use the (external)
network.
To be fair schroot has a 'config=buildd' setup where /etc/protocols
and /etc/services are not copied over (and configs 'minimal', 'sbuild'
and 'mini-buildd'). The problematic situation is 'config=default' (and
'desktop') where they are. But I use the 'default' setup a lot because
it mounts /home as well and that's hugely helpful for doing various
sort of work, as opposed to a totally-clean sbuild build. And I think
it may be the default for sbuild-createchroot, but I could be wrong
about that.
For nearly everything I do a config without /etc{protocols|services}
but with /home would work great, but none of the supplied configs:
minimal, buildd, mini-buildd, sbuild, default, desktop do that. Do we
really need a 7th config (and if so what should it be
called?). Obviously I can just make one, but the fact that problem
affects people so often with the 'default' config seems to me to be a
problem we should try to fix.
> I have a 4th option:
>
> scroot could create this file by installing and then removing (but not
> purging) a fake netbase.deb ("Version: 0~~). Then, when the new
> netbase appears, the usual conffile mechanism would DTRT, since the
> file would not have been "locally created" (or indeed "locally
> modified").
That is a neat idea.
> The fake netbase.deb could be contained within schroot.deb, in
> /usr/share, so schroot wouldn't need to gain runtime build-deps on
> dpkg tooling.
Except that it has to build this package live in order to contain the
/etc/protocols and /etc/services files from the host
environment. Having these default files with standard contents in a
pre-built .deb is pointless, isn't it?
> > Whilst having the passwd database reflected in the chroot is
> > incredibly useful it's not clear how often the services and protocols
> > are needed, but I assume people do find that functionality useful.
>
> I had a package that failed its build-time tests due to lack of
> /etc/protocols. The missing build-dep was detected in the buildds,
> because my own local sid build chroot has netbase installed, precisely
> because of this bug.
Right, which gets back to having a proper minimal environment used by
sbuild to do a clean build. I have that (and it doesn't mount home,
using the 'sbuild' profile). I use it once things are working
reasonably well to get at least one clean build before uploading. This
bug is a problem in the 'less clean, but more useful' 'default' chroot
environment which is best for diagnostic work and builds of various
sorts where some file persistence (of user files) is needed.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over
Source: schroot Version: 1.6.13-3 Followup-For: Bug #557730 Just discovered this bug from 2009. This problem has been annoying me regularly since about then, and I finally got round to working out what was actually going on, which led me here. The primary practical issue is that builds in the chroot are quite likely to bring in netbase, and that package contains /etc/protocols and /etc/services so when dpkg finds that they are already present in the chroot it stops with: Setting up netbase (6.4) ... Configuration file '/etc/protocols' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** protocols (Y/I/N/O/D/Z) [default=N] ? So I often find that a build has just got stuck at the beginning unless I inject y\ny\n. This has caused endless hassle over the years, and it's a bit sad to see it's not been fixed in 13 years. I always assumed that someone would sort this out at some point and the hassle would go away. There are various ways we could deal with this. Sbuild-createchroot could set 1) Dpkg::Options::force=--force-confnew in its chroots. Are there reasons you might not want to set this in general? People would expect conf changes they made in their chroots to be preserved just the way they are in a normal system. So this seems like it would be intrusive. 2) netbase could be installed in base chroots then the problem would not arise (or only arise once). The problem here is that chroots can be made by many tools, and the usual tools (debootstrap and mmdebstrap) do not put netbase in by default. It would be very easy to make sbuild-createchroot just add --include=netbase to the invocation, and I'm not sure there is any real downside to doing that? Documenting the reason for including this package so that people using other tools to make chroots know it's a good idea would also be easy and helpful. 3) schroot could just not copy those files over. Whilst having the passwd database reflected in the chroot is incredibly useful it's not clear how often the services and protocols are needed, but I assume people do find that functionality useful. The actual issue here is that schroot is copying them over even when they don't exist in the chroot, then the thing that is supposed to be installing them gets tripped up (correctly) by dpkg's checks. So a simple fix that keeps the functionality when it's useful, but stops this breakage, would be to only copy over the files in the nssdatabases list _if they are already present in the chroot_. Possibly that should apply to all the files in the list? I'll see if I can come up with a patch to do that.
Bug#1031193: Acknowledgement (gthumb segfaults on startup)
On 2023-02-13 00:36 +, Debian Bug Tracking System wrote: Having upgraded 1.5Gb of packages since the 8th, and restarted X this issue has gone away. gthumb works fine now. I noticed a couple of other GUI apps that would not start (giving X errors): (therion and aven (survex)). Those use tcltk and wxwindows respectively. But plenty of things _were_ working. I guess there was something wrong in some library/package that has been superseded for Bookworm already so this bug can probably be closed unless a load of other people report the same issue. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#836249: (ITP: cavewhere -- Cave survey processing and visualisation)
Cavewhere has proved problematic to build and package but I think we are nearly there. v1.0 added two new dependencies: asyncfuture and st3c. Turned out st3c didn't do anything that libsquish didn't already do, so it was patched to just use libsquish. Then upstream took that fix. asyncfuture is now packaged, uploaded and in testing. qt-qml-models is packaged, but not uploaded as I've never actually got cavewhere to build against it, so it might be broken. A serious bug in libsquish packaging was found, which broke the cavewhere build, but none of the other dependencies. That has been fixed in time for bookworm. The Cavewhere build now gets further than ever before using system libraries, but the test library build still fails with a c++ issue. Awaiting comment from upstream. So it's missed bookworm, but I think we really are nearly there. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Bug#1030194: abi-dumper: Examples concatenated in man page
Package: abi-dumper Version: 1.2-2 Severity: minor The man page for this page has two examples which should look like this: abi-dumper libTest.so -o ABI.dump abi-dumper Module.ko.debug -o ABI.dump But actually look like this: abi-dumper libTest.so -o ABI.dump abi-dumper Module.ko.debug -o ABI.dump which is quite ocnfusing on first read, until you realise what has gone wrong. Looking at the source I see the manpage is generated from help2man It comes out right if you do 'abi-dumper --help': EXAMPLES: abi-dumper libTest.so -o ABI.dump abi-dumper Module.ko.debug -o ABI.dump So apparently help2man is messing this up. I've not investigated further (to find out why other linefeeds are preserved but this one is lost), but running help2man on the binary just built is a great way to make something un-crossbuildable so maybe just making a manpage once and getting rid of help2man is the best approach here? Help2man is 'handy' but it's also problematic. This isn't a fast-moving project where the man page will go out of date all the time so converting to a simple man page, or packaging-time generation, rather than a build-time generation, would be good for reproducibility and cross-buildability. Would a patch to that effect be accepted? -- Wookey
Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64
On 2022-12-13 22:37 +0100, Guillem Jover wrote: > On Mon, 2022-12-12 at 04:28:29 +0000, Wookey wrote: > As I think I mentioned previously, the problem is that we cannot > currently add it even disabled by default, due to many packages using > «hardening=+all» which has the same effect for these as the option > being enabled by default. Ah yes. Good point. That is unfortunate. If you did point it out already, it had failed to sink in at my end. > What I also mentioned, and as I was expecting there to be pushback on > the new hardening feature, is to perhaps add versioned buildflags > support. I'll post what I've got to debian-dpkg during this week. OK, cheers. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64
The debian-devel thread continued but most responses were not copied to the bug (I've just realised). Possibly this means that you (guillem) didn't see most of the conversation. The bottom line is the security team were very unenthusiastic about enabling this by default because it might produce unexpected changes on security uploads, which is fair enough. Another suggestion was that it should be turned on for x32 too. I was expecting (after that discussion) the 'branch' functionality to be included in the next dpkg upload, just not enabled by default, but it was not included in 1.21.12 Do you disagree or did this just get forgotten? - Forwarded message from Moritz Mühlenhoff - Date: Wed, 26 Oct 2022 20:20:48 +0200 From: Moritz Mühlenhoff To: debian-de...@lists.debian.org Subject: Re: Enabling branch protection on amd64 and arm64 List-Id: Wookey wrote: > So the immediate issue now is whether or not to enable this by default > in bookworm? The majority of packages will not be rebuilt until the release, so if we add this now it means that packages pick up the change when they are rebuilt in stable via a security update or point release. That's not very appealing, independent of the supposed low risk factor. I think this should rather be applied early after the Bookworm release (and ideally we can also finish off the necessary testing and add -fstack-clash-protection at least for amd64 and other archs which are ready for it (#918914)). Cheers, Moritz ----- End forwarded message - Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#627784: x11vnc: the () keys are reported with wrong keycode
I know this bug is old but I just stumbled upon it when trying to
connect to a machine running in KVM on a host connected to via x11vnc.
The workaround Karl suggested worked perfectly the () keys work again.
Attached is the output of "-v -o log.txt -dk -dk" as requested.25/11/2022 22:45:39 passing arg to libvncserver: -rfbauth
25/11/2022 22:45:39 passing arg to libvncserver: /home/rowan/.vnc/passwd
25/11/2022 22:45:39 passing arg to libvncserver: -rfbport
25/11/2022 22:45:39 passing arg to libvncserver: 5901
25/11/2022 22:45:39 passing arg to libvncserver: -listen
25/11/2022 22:45:39 passing arg to libvncserver: 10.222.0.1
Settings:
display::0
authfile: /var/run/sddm/{57e65f09-c010-4438-b2e6-910dba3be915}
subwin: 0x0
-sid mode: 0
clip: null
flashcmap: 0
shiftcmap: 0
force_idx: 0
cmap8to24: 0
8to24_opts: null
24to32: 0
visual: null
overlay:0
ovl_cursor: 1
scaling:0 1. 1.
viewonly: 0
shared: 1
conn_once: 0
timeout:0
ping: 0
inetd: 0
tightfilexfer: 0
http: 0
connect:null
connectfile null
vnc_conn: 1
allow: null
input: null
passfile: null
unixpw: 0
unixpw_lst: null
ssl:null
ssldir: null
ssltimeout -1
sslverify: null
stunnel:0
accept: null
accept: null
gone: null
users: null
using_shm: 1
flipbytes: 0
onetile:0
solid: null
blackout: null
xinerama: 1
xtrap: 0
xrandr: 0
xrandrmode: null
padgeom:null
logfile:log.txt
logappend: 0
flag: null
rm_flag:null
rc_file:""
norc: 0
dbg:0
bg: 0
mod_tweak: 1
isolevel3: 0
xkb:0
skipkeys: null
sloppykeys: 0
skip_dups: 0
addkeysyms: 1
xkbcompat: 0
clearmods: 0
remap: null
norepeat: 0
norepeatcnt:2
nofb: 0
watchbell: 1
watchsel: 1
watchprim: 1
seldir: null
cursor: 1
multicurs: 0
curs_mode: null
arrow: 1
xfixes: 1
alphacut: 240
alphafrac: 0.33
alpharemove:0
alphablend: 1
cursorshape:1
cursorpos: 1
xwarpptr: 0
alwaysinj: 0
buttonmap: null
dragging: 1
ncache: 0
wireframe: 0xff,2,0,32+8+8+8,all,0.15+0.30+5.0+0.125
wirecopy: always
scrollcopy: mouse
scr_area: 6
scr_skip: ##Soffice.bin,##StarOffice,##OpenOffice
scr_inc: ##Nomatch
scr_keys: null
scr_term: null
scr_keyrep: null
scr_parms: 0+64+32+32,0.02+0.10+0.9,0.03+0.06+0.5+0.1+5.0
fixscreen: null
noxrecord: 0
grabbuster: 0
ptr_mode: 2
inputskip: 10
speeds: null
wmdt: null
debug_ptr: 0
debug_key: 2
defer: 20
waitms: 20
wait_ui:2.00
nowait_bog: 0
slow_fb:0.00
xrefresh: 0.00
readtimeout: 20
take_naps: 1
sb: 60
fbpm: 1
dpms: 1
xdamage:0
xd_area: 2
xd_mem:1.000
xcomposite: 1
multiptr: 0
sigpipe:null
threads:0
fs_frac:0.75
gaps_fill: 4
grow_fill: 3
tile_fuzz: 2
snapfb: 0
rawfb: null
pipeinput: null
gui:0
gui_mode: null
noremote: 0
unsafe: 0
privremote: 0
safer: 0
nocmds: 0
deny_all: 0
pid:445831
25/11/2022 22:45:39 x11vnc version: 0.9.16 lastmod: 2019-01-05 pid: 445831
25/11/2022 22:45:39 Using X display :0
25/11/2022 22:45:39 rootwin: 0x769 reswin: 0x41 dpy: 0x86499100
25/11/2022 22:45:39
25/11/2022 22:45:39 -- USEFUL INFORMATION --
25/11/2022 22:45:39
25/11/2022 22:45:39 Wireframing: -wireframe mode is in effect for window moves.
25/11/2022 22:45:39 If this yields undesired behavior (poor response, painting
25/11/2022 22:45:39 errors, etc) it may be disabled:
25/11/2022 22:45:39- use '-nowf' to disable wireframing completely.
25/11/2022 22:45:39- use '-nowcr' to disable the Copy Rectangle after the
25/11/2022 22:45:39 moved window is released in the new position.
25/11/2022 22:45:39 Also see the -help entry for tuning parameters.
25/11/2022 22:45:39 You can press 3 Alt_L's (Left "Alt" key) in a row to
25/11/2022 22:45:39 repaint the screen, also see the -fixscreen option for
25/11/2022 22:45:39 periodic repaints.
25/11/2022 22:45:39
25/11/2022 22:45:39 XFIXES available on display, resetting cursor mode
25/11/2022 22:45:39 to: '-cursor most'.
25/11/2022 22:45:39 to disable this behavior use: '-cursor arrow'
25/11/2022 22:45:39 or '-noxfixes'.
25/11/2022 22:45:39 using XFIXES for cursor drawing.
25/11/2022 22:45:39 GrabServer control via XTEST.
25/11/2022 22:45:39
25/11/2022 22:45:39 Scroll Detection: -scrollcopyrect mode is in effect to
25/11/2022 22:45:39 use RECORD extension to try to detect scrolling windows
25/11/2022 22:45:39 (induced by either user keystroke or mouse input).
25/11/2022 22:45:39 If this yields undesired behavior (poor response, painting
25/11/2022 22:45:39 errors, etc) it may be disabled via: '-noscr'
25/11/2022 22:45:39 Also see the -help entry for tuning parameters.
25/11/2
Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel
On 2022-11-01 08:57 +0500, Akbarkhon Variskhanov wrote: > On Mon, Oct 31, 2022 at 7:02 PM Wookey wrote: > > The description could be more useful. > > "The plugin supports common mathematical operators (+, -, *, /, ^) with > > usual > > precedence rules, and some common functions such as abs(x), sqrt(x), sin(x) > > and cos(x)." > > If it were possible, I wouldn't even write a long description for this > package. I feel like repeating what's already there in the short > description is counter-productive, You may feel that, but I disagree. Good descriptions, both long and short, are important. Imagine somone reading through a list of our thousands of packages (who maybe never have even _heard_ of XFCE) when writing descriptions. The description needs to tell them enough to decide whether or not they might want to install this thing. > and Xfce panel plugins are Xfce > panel plugins. They depend on having xfce4-panel and anyone who's ever > used Xfce knows where their panel is, what their panel has. Besides, > I'm completely lost as to what else I can say here (aka lacking > creativity). It is an Xfce panel plugin (determined by its name > already), provides a calculator functionality on the Xfce panel > (again, it's in the name). Hence, I've been using XFCE daily for 20 years and I'm still asking for a more useful description because I _don't_ know what this package is/does. What you've said above is pretty good, and I've now actually tried it, so I came up with this: "An XFCE desktop panel plugin, which provides a 'paper mode' style calculator as a box in the panel." The important distinction here is between something that launches a desktop calculator or something that provides a box in the panel that will do calculations. It sounds from what you have said that it is the latter (and I have just installed it to check that that is indeed the case). I was actually a lot more excited about it when I thought it was a quick way to keep something like galculator to hand. > > It needs to say what this _is_. Perhaps something like > > "Provides on-screen calculator from toolbar", then details as above. > > would be wrong, and even with corrections, pointless and/or duplicated info. That fact that I got it wrong after reading your ITP and examining the packaging illustrates the need for the description to clarify what the package actually is/does. > Let me contact upstream for their explanation and rationale for > including LGPL in the source tree. That'll be the best way to work out what was intended. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel
On 2022-10-30 21:54 +0500, Akbarkhon Variskhanov wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "xfce4-calculator-plugin": > > * Package name : xfce4-calculator-plugin >Version : 0.7.1-1 >Upstream contact : > https://gitlab.xfce.org/panel-plugins/xfce4-calculator-plugin/-/project_members > * URL : > https://docs.xfce.org/panel-plugins/xfce4-calculator-plugin/start > * License : GPL-2.0+ > * Vcs : [fill in URL of packaging vcs] >Section : xfce Thanks for packaging this. > The source builds the following binary packages: > > xfce4-calculator-plugin - calculator plugin for Xfce panel The description could be more useful. "The plugin supports common mathematical operators (+, -, *, /, ^) with usual precedence rules, and some common functions such as abs(x), sqrt(x), sin(x) and cos(x)." It needs to say what this _is_. Perhaps something like "Provides on-screen calculator from toolbar", then details as above. I'd add Adrian Dimitrov to the copyright list and the package includes the LGPL COPYING.LIB at top level, although it's not obvious if that actually applies to any of the code. If it does then the LGPL should be listed (maybe you already checked this?). Otherwise it looks fine. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1022790: usrmerge: Typo in "convert-usrmerge will not be run automatically" message
Package: usrmerge Version: 33 Severity: minor Installing usrmerge in a chroot gave this error message: Setting up usrmerge (33) ... Warning: overlayfs detected, /usr/lib/usrmerge/convert-usrmerge will not be run automatically. See #1008202 for details. If this is a container then it can be converted by unpacking the image, entering it with chroot(8), installling usrmerge and then repacking the image again. at /usr/lib/usrmerge/convert-usrmerge line 399. E: usrmerge failed. There should not be 3 'l's in 'installling' -- Wookey
Bug#1021292: Enabling branch protection on amd64 and arm64
On 2022-10-25 16:10 +0100, Simon McVittie wrote:
> On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote:
> > These are hardware features (new instructions) that 'tag' pointers and
> > branch targets to make it much harder for malicious code to implement
> > ROP (return oriented programming) and JOP (Jump oriented programming)
> > attacks.
> >
> > They have been implemented on both architectures in such a way that
> > they can be generally enabled and are simply ignored on hardware that
> > doesn't support them (the new instructions are in the NOP space).
>
> Does this have the same restrictions as CET, which gcc briefly enabled
> on x86 by default, but had to roll back[1] and later enable on a smaller
> subset of architectures[2], because the new instructions are only NOPs
> on x86_64 and modern i386, and are non-baseline (illegal instruction)
> on older or more-embedded i386 like the ones in our current i386 baseline?
I'm not sure (I know a lot more about the arm64 side of this than the
amd64 side), but we are only enabling this on amd64, not i386. amd64
binaries don't run on i386 so I don't think any practical issue
actually arises. You have reminded me that I guess it should be turned
on for x32 too.
> If yes, we'll have to be careful to only enable this on architectures
> where our baseline allows it. IIRC, Geode and VIA CPUs are the ones that
> usually cause trouble for i386.
Right, and that's the plan.
The patch looks approx like this:
+# Branch protection
+if ($use_feature{hardening}{branch}) {
+my $flag;
+if ($cpu eq 'arm64') {
+$flag = '-mbranch-protection=standard';
+} elsif ($cpu eq 'amd64') {
+$flag = '-fcf-protection';
+}
+$flags->append($_, $flag) foreach @compile_flags;
+}
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#1021292: Enabling branch protection on amd64 and arm64
I have been in discussion with Guillem about enabling the various branch protection mechanisms available on newer x86 and arm CPUs. These are hardware features (new instructions) that 'tag' pointers and branch targets to make it much harder for malicious code to implement ROP (return oriented programming) and JOP (Jump oriented programming) attacks. They have been implemented on both architectures in such a way that they can be generally enabled and are simply ignored on hardware that doesn't support them (the new instructions are in the NOP space). These features have been enabled in other distros for some time and we've done an archive rebuild of arm64 to check that there was not significant breakage. There is a lot of discussion of the details of this and the pros/cons of enabling this by default in the thread so I will try to keep this mail as a summary and suggest you go read https://lists.debian.org/debian-dpkg/2022/05/msg00022.html and https://lists.debian.org/debian-dpkg/2022/06/msg0.html if you want to know how it works, and all the details. We decided that the best thing to do was create a new hardening flags feature called 'branch' to add to the existing set. This enables -mbranch-protection=standard on arm64, and -fcf-protection on amd64 (yes it would have been nice if the gcc people had used common flags across the arches, but there you go) If/when other arches get similar functionality those would be enabled under this heading too (Are there any already that I don;t know about?) There is a dpkg branch containing this feature here: https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/dpkg-buildflags-feature-branch And a bug to track progress here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292 So the immediate issue now is whether or not to enable this by default in bookworm? It's a significant protection on newish hardware, which those who've worked on it (and I now, having investigated) believe should be on by default. We have a general policy of enabling reaosnably low-cost security features by default, and this is one of those. It's a fairly low-risk thing to do, especially as others have gone before us (Rhel made -fcf-protection the gcc default in 2018, and Suse in Oct 2021. Suse turned on branch-protection=standard (ie BTI+PAC) on arm64 in nov 2020), but it is changing the defaults. Like all dpkg-buildflags it can easily be disabled for a particular package and there is a kernel option to turn it off on a particular machine if issues are encountered (and no doubt we will find a couple). I hope that all makes sense. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021841: setbfree FTCBFS -- multiple reasons
On 2022-10-16 00:39 +0530, Nilesh Patra wrote: > - It uses strip extensively. While for debian systems, simply removing the > strip > call from all makefiles could be OK, since dh_strip will simply take care of > it. > But, it'd be hard to make things upstream-able > if desired at some point. So I sent STRIP to the -strip > for > cross builds. Thanks for fixing this. I have one minor suggestion. > +ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) > +STRIP := strip > +else > +STRIP := $(DEB_HOST_GNU_TYPE)-strip > +export PKG_CONFIG = $(DEB_HOST_GNU_TYPE)-pkg-config > +endif x86_64-linux-gnu-strip is shipped in binutils-x86-64-linux-gnu and so on for other arches, so the above test for setting strip with/without a prefix is not necessary. Just setting: STRIP := $(DEB_HOST_GNU_TYPE)-strip should always work and is a bit neater IMHO. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#992073: shim-signed: restore arm64 support
On 2022-06-28 15:18 +0100, Steve McIntyre wrote: > On Tue, Jun 28, 2022 at 03:08:52PM +0100, Wookey wrote: > >Can we have a progress/blockers update? > > I'm currently testing builds of the latest shim release (15.6) on all > 3 platforms (amd64, i386 and arm64). It now builds reproducibly on > arm64, given a new enough toolchain, so I'll be marking this bug as > closed when I upload. Where are we at with this bug? Mostly Steve trying to find enough tuit's I suspect. Can I do anything to help things along? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021292: dpkg-dev: Please add support for pointer authentication on arm64
On 2022-10-05 23:13 +0200, Guillem Jover wrote: > As mentioned on the thread, I was expecting a thread to be started on > debian-devel, as this changes the current default for both amd64 and > arm64. OK. I clearly dropped all the balls there! I will do that forthwith. Hopefully it will be uncontroversial. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021292: dpkg-dev: Please add support for pointer authentication on arm64
Package: dpkg-dev
Version: 1.19.7
Severity: wishlist
Tags: patch
As discussed in the below-linked thread on dpkg-dev, we should enable PAC and
BTI
on arm64 as a standard hardening flag.
https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
Attached is Guillem's proposed patch which does the trick, updated for
current dpkg (I opened this bug file in June, but forgot to actually
press send, so now updated for the current 1.21.9)
Despite this delay, I hope we can can have this in for bookworm.
--
Wookey
diff -Nru dpkg-1.21.9/debian/changelog dpkg-1.21.9+1/debian/changelog
--- dpkg-1.21.9/debian/changelog2022-07-01 09:25:58.0 +
+++ dpkg-1.21.9+1/debian/changelog 2022-10-04 15:28:43.0 +
@@ -1,3 +1,9 @@
+dpkg (1.21.9+1) unstable; urgency=medium
+
+ * Add 'branch' hardening support for amd64 and arm64
+
+ -- Wookey Tue, 04 Oct 2022 16:28:43 +0100
+
dpkg (1.21.9) unstable; urgency=medium
[ Guillem Jover ]
diff -Nru dpkg-1.21.9/scripts/Dpkg/Vendor/Debian.pm
dpkg-1.21.9+1/scripts/Dpkg/Vendor/Debian.pm
--- dpkg-1.21.9/scripts/Dpkg/Vendor/Debian.pm 2022-06-30 23:46:56.0
+
+++ dpkg-1.21.9+1/scripts/Dpkg/Vendor/Debian.pm 2022-10-04 15:13:28.0
+
@@ -129,6 +129,7 @@
format => 1,
relro => 1,
bindnow => 0,
+branch => 1,
},
);
@@ -364,6 +365,11 @@
# relro not implemented on ia64, hppa, avr32.
$use_feature{hardening}{relro} = 0;
}
+if ($cpu !~ /^(?:amd64|arm64)$/) {
+# On amd64 use -fcf-protection.
+# On arm64 use -mbranch-protection=standard.
+$use_feature{hardening}{branch} = 0;
+}
# Mask features that might be influenced by other flags.
if ($opts_build->has('noopt')) {
@@ -430,6 +436,17 @@
$flags->append('LDFLAGS', '-Wl,-z,now');
}
+# Branch protection
+if ($use_feature{hardening}{branch}) {
+my $flag;
+if ($cpu eq 'arm64') {
+$flag = '-mbranch-protection=standard';
+} elsif ($cpu eq 'amd64') {
+$flag = '-fcf-protection';
+}
+$flags->append($_, $flag) foreach @compile_flags;
+}
+
## Commit
# Set used features to their builtin setting if unset.
diff -Nru dpkg-1.21.9/scripts/t/Dpkg_BuildFlags.t
dpkg-1.21.9+1/scripts/t/Dpkg_BuildFlags.t
--- dpkg-1.21.9/scripts/t/Dpkg_BuildFlags.t 2022-06-18 17:57:44.0
+
+++ dpkg-1.21.9+1/scripts/t/Dpkg_BuildFlags.t 2022-10-04 15:28:06.0
+
@@ -55,6 +55,7 @@
) ],
hardening => [ qw(
bindnow
+branch
format
fortify
pie
Bug#1009733: src:exempi: fails to migrate to testing for too long: FTBFS on armel and armhf
On 2022-05-29 17:53 +0200, Paul Gevers wrote: > Hi, > > On Sat, 16 Apr 2022 00:21:46 +0200 Michael Biebl wrote: > > Dear arm porters, > > > > can you please take a look at this? > > Ping from the Release Team. This package is a key package (so the RC bug > can't be "fixed" by removal from testing). I did take a look at this, but the logs from different builds were quite confusing and it was not at all obvious what the actual problem was. I left it for a mo to deal with somthing easier... I have failed to get back to it so far, and won't for at least another month (on holiday away from computers). Ah, but I see Bernhard has fixed it in the meantime. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#992073: shim-signed: restore arm64 support
On 2022-04-27 13:40 +0100, Steve McIntyre wrote: > I'm hacking on shim right now, setting up local CI etc. to help me > with testing. As soon as I can validate that arm64 stuff is working > correctly now, I'll take out the hacks I added. Give me a few days... Gentle prod Steve. I know how those 'few days' get interrupted. And the offer to help remains, but it probably quicker for you to do this than explain to me what I'd need to do :-) Can we have a progress/blockers update? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1011638: nmap does not rebuild cleanly
Package: nmap Version: 7.92+dfsg2-1 Severity: normal Tags: patch nmap does not clean its build files so if you try to build it a second time the build fails. There is just one file not cleaned: ndiff/INSTALLED_FILES so it is trivialy fixed by adding a file debian/clean containing just one line: ndiff/INSTALLED_FILES -- Wookey -- /dev/null 2022-05-12 20:48:46.60800 + +++ debian/clean2022-05-25 15:41:04.78800 + @@ -0,0 +1 @@ +ndiff/INSTALLED_FILES
Bug#992073: shim-signed: restore arm64 support
Binutils 2.38 now has proper PE/COFF output support for arm64. (And is in unstable and testing.) https://sourceware.org/pipermail/binutils/2022-February/119721.html I think this is the relevant bit: "Support for efi-app-aarch64, efi-rtdrv-aarch64 and efi-bsdrv-aarch64 has been added to objcopy in order to enable UEFI development using binutils." So we should now be able to build shim-signed on arm64 without the hackery that was previously used to simulate this format (and then had to be disabled because it broke things (AIUI)). I'm not sure how much work this is or if anyone else is already working on it? I presume it should be a simplification by removing the previous workarounds and bulding just as we do on x86 now? Happy to have a look if someone gives me some pointers. (A look round the package for an hour was not sufficient for me to work out how shim itself or the various other bits is all put together (shim-signed, shim-helpers--signed etc) and where it needs poking). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#994388: dpkg currently warning about merged-usr systems
On 2022-04-08 09:36 +0200, Wouter Verhelst wrote: > > The dpkg maintainer has chosen not to engage with the TC in #994388, and > now seems to be actively subverting a validly-made TC decision. > > I do believe it reasonable to assume the dpkg maintainer has a point if > he believes that the currently-chosen way of moving forward is harmful. > However, the right way for him to make that point would have been to > engage with the TC, the body constitutionally placed to resolve > conflicts of this manner, not ignoring them and then doing whatever he > wants when the decision inevitably doesn't go his way. > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this > matter. It is not yet too late; That all sounds reasonable, but there is the long-standing issue that Guillem has never accepted that the TC has authority over the project. I forget the details, but given that he does not see it as valid it's not surprising that he is not engaging with it. However he should engage with this dpkg bug. It's an important one. Guillem, I'm sure you see all this as repeating yourself, but we cannot either reach a solution, or determine that one is not possible given current maintainership and TC decisions, without discussing the details. Like Wouter, I am inclined to agree with the dpkg maintainer that the current plan is broken, but I also accept the TC's authority. SFAICT We've made a right mess of this by not applying our usual technical rigour (BICBW - I have not followed all the ins and out of this).. At this point I am more disappointed in the people who keep insisting that 'it mostly works' is good enough, than I am in the bloody-minded dpkg-maintainer. Debian is not a 'mostly works' project. We do things properly - or at least we used to, even if that takes a long time. Some people have cited the multiarch dpkg changes as an example of work on dpkg being difficult. I was quite closely involved in all that and yes it took a long time but it was done right in the end, and it was the dpkg maintainer who insited on it being done right. Yes there was an incompatible syntax change but that was due to Ubuntu releasing with an implementation that was not good enough for upstream. It was annoying at the time but the pain was fairly short and we ended up in a better place in the long term. SFAICT the dpkg maintainer is applying the same rigour here, and the only way to fix this is for people who want to get usrmerge done to engage, with patches. If they want to prove that no patches for the current approach will ever be accepted, that can only be done by engaging further. Yes it will be hard work, but if it's not done we are just stuck. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1008135: ITP: libbacktrace -- Backtrace library (for C/C++ apps)
Package: wnpp Severity: wishlist Owner: Wookey Package name: libbacktrace Version : 1.0 Upstream Author : Ian Lance Taylor URL : https://github.com/ianlancetaylor/libbacktrace License : BSD Programming Lang: C Description : Backtrace library (for C/C++ apps) A library to produce symbolic backtraces for ELF, PE/COFF. Mach-O and XCOFF executables, with DWARF debugging info. i.e. it supports GNU/Linux, *BSD, macOS, Windows, and AIX. . The library relies on the C++ unwind API defined at https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html This API is provided by GCC and clang. This library is a build-dependency of Apache TVM
Bug#1008131: ITP: rang -- Minimal modern c++ library for terminal goodies
Package: wnpp Severity: wishlist Owner: Wookey * Package name: rang Version : 3.2 Upstream Author : Abhinav Gauniyal * URL : https://github.com/agauniyal/rang * License : The Unlicense Programming Lang: C++ Description : c++ terminal colour library Simple header-only library that supports terminal colours on unix and Windows using ansi sequences. Detects if output is a tty, and if colour is supported. Uses c++ iostream objects to do this. . If you need colour support on non-ansi terminals try termdb instead. This package is a build-dependency for Apache TVM
Bug#1007717: Native source package format with non-native version
On 2022-03-16 15:29 +, Ian Jackson wrote: > In practice, the vast majority of packages are maintained in git on > salsa. The maintainers use those git repositories as the PFM. > but almost everyone is already treating git as primary. Is this definitely true? For example: I know I'm not doing this. I did try, and I do have some git repos on salsa, but I've mostly given up with it all and stuck with uscan and tarballs and quilt (and my trusty 'packages' directory). It's much easier for me. (The salsa repos that exist for my packages are not canonical and often stale). I'm sure Ian is right that there is a trend towards git from tarballs and dscs, but I just question whether we know it is 'the vast majority'? Are there really now very few maintainers using the 'classic tooling'? How do we know? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1006139: RM: libdeflate [armhf] -- ROM; does not seem suitable for armhf 'baseline'
Andreas Tille wrote: > it seems this package does not seem suitable for armhf 'baseline'. > It fails to build with > lib/arm/crc32_impl.h:77:1: error: ‘-mfloat-abi=hard’: selected architecture > lacks an FPU That seems an oversimplification. There is usually an FPU (almost always) and a neon unit (usually). The point is that their presence is not guaranteed, so such instructions should not be used without checking the HWCAPS first. So libdeflate should be able to work fine on armhf, but may need enhancing with some fallback functions for FPUless and neonless hardware. I have not yet checked upstream to see if the codebase already supports this or would need work to do so. I will do so and report back. It seems to me that we shouldn't be disabling standard compression libraries on architectures lightly. At the very least some research is in order. It used to work (before version 1.9): https://buildd.debian.org/status/logs.php?pkg=libdeflate&arch=armhf Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#982809: Packaging Godot Engine
Have you looked at all at packaging godot engine itself? I have a need for this, but have not yet looked at how big a job it is. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1004535: ITP: ebusd -- daemon for handling communication with eBUS ('Energy Bus') devices
Package: wnpp
Severity: wishlist
Owner: Wookey
* Package name: ebusd
Version : 21.3
Upstream Author : John Baier
* URL : https://ebusd.eu/
* License : GPL3 or later
Programming Lang: C++
Description : Daemon for handling communication with eBUS ('Energy Bus')
devices
eBUS is a 2-wire serial bus used by some (mostly German-manufactured)
heating, ventilation and solar systems for communication.
The daemon can send, receive, cache and poll for messages, and scan the bus for
devices.
It can log via syslogd, and save messages in human-readbale form.
There is a command-line interface, and a simple HTML interface to allow data
retrieval as JSON
Messages can be published to (and from, if authorised) MQTT topics.
There is an ACL file for optional user authentication.
sysvinit and systemd are supported.
A suitable hardware interface is needed to use this software. Details
of an open interface which supports USB serial, rPi IO, and ethernet
and wifi with suitable modules are on the wiki:
https://adapter.ebusd.eu/index.en.html
Bug#1003248: E: "binary-with-bad-dynamic-table" and W: "elf-error In ELF header" issued for foreign-arch binaries
Package: lintian Version: 2.114.0 Severity: normal I have a package (libopencsd) which has aarch64 elf binaries in some of its test-cases. e.g https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-001/uname.bin/ https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-001/vdso.bin/ Lintian gives both an error and a warning about this file: E: libopencsd source: binary-with-bad-dynamic-table [decoder/tests/snapshots/juno-uname-001/uname.bin] W: libopencsd source: elf-error In ELF header: Reading 1728 bytes extends past end of file for section headers [decoder/tests/snapshots/juno-uname-001/uname.bin] It also gives the warning about another file: W: libopencsd source: elf-error In ELF header: Reading 896 bytes extends past end of file for section headers [decoder/tests/snapshots/juno-uname-001/vdso.bin] nd then complains some more in a similar vein W: libopencsd source: elf-error In ELF header: Section headers are not available! [decoder/tests/snapshots/juno-uname-001/uname.bin] W: libopencsd source: elf-error In ELF header: Section headers are not available! [decoder/tests/snapshots/juno-uname-001/vdso.bin] W: libopencsd source: elf-error In program headers: the dynamic segment offset + size exceeds the size of the file [decoder/tests/snapshots/juno-uname-001/uname.bin] For some reason I don't understand it does not complain about the same binaries in other test-cases: https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-002/uname.bin/ https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-002/vdso.bin/ https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/test-file-mem-offsets/uname.bin/ https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/test-file-mem-offsets/vdso.bin/ I presume that if binutils for the foreign arch was installed this error would not appear. I think that lintian should either install the right tools for running this test on foreign-arch binaries, or it should not try to check foregn-arch binaries. There is a separate issue about whether these files count as 'source-is-missing' binaries, but that's independent of the above issue, which seems to me to be a lintian bug. -- Wookey
Bug#920148: RFP: mapillary-tools -- Useful tools and scripts related to Mapillary
[cc:ing debian-python in case anyone happens to know enough about
python3-contruct to provide some clues]
OK, so it turns out that there are problems packaging pymp4.
It depends on construct, a (nice) library for parsing binary
formats. However said library seems to have little interest in
maintaining any sort of stable API so there have been significant
changes between 2.8, 2.9 and 2.10 (and in fact pymp4 needs 2.8.8 quite
specifically, and doesn't even work with 2.8.16).
2.8.8 is from October 2016 and Debian now has 2.10.x in stable, testing and
unstable.
There is a bug in construct 2.8.8 which means that pymp4 fails 5 out of 30-odd
tests even with that.
A python class moved, so that is trivially fixed with:
--- construct-2.8.8.orig/construct/core.py
+++ construct-2.8.8/construct/core.py
@@ -997,7 +997,7 @@ class Range(Subconstruct):
max = self.max(context) if callable(self.max) else self.max
if not 0 <= min <= max <= sys.maxsize:
raise RangeError("unsane min %s and max %s" % (min, max))
-if not isinstance(obj, collections.Sequence):
+if not isinstance(obj, collections.abc.Sequence):
raise RangeError("expected sequence type, found %s" % type(obj))
if not min <= len(obj) <= max:
raise RangeError("expected from %d to %d elements, found %d" %
(min, max, len(obj)))
But as no-one cares about 2.8.x anyway this fix doesn't help much.
What's really needed is updating pymp4 to use construct 2.10 (or
switch to a more stable library if such a thing exists ('Kaitai
Struct' was mentioned)).
There is an upstream issue for this:
https://github.com/beardypig/pymp4/issues/3
Which I've just added some info to.
2.9 changes the way Strings work: an encoding is always required, and
explicit flavours of padding (left/right, specifiable padding char)
have been removed. pymp4 uses these padding options (specifying spaces
and right-padding), but may still work fine with the remaining default
behaviour of 'PaddedString' (nulls and rightpading). I don't know
enough about either the MP4 format or the codebase to be sure. I did
know up a patch to update to the new string API.
2.9 also loses Embedded bitwise structs. And 2.10 loses 'Embedded' completely.
I have not really managed to work out exactly what 'Embedded' does. I
can't really work out what the difference between putting a bitwise
struct in the middle of a struct and putting an Embedded bitwise
struct in the middle of a struct is. Mostly this is because the online
docs only cover 2.10, not 2.8 so I don't know what the old definition
was. I spent a couple of hours trying to work it out. It's made more
complicated by the fact that construct also switched from 'bits by
default' to 'bytes by default' for efficiency reasons.
I've put a half-arsed patch in the github issue which is probably OK
for the strings part and almost certainly wrong for the Embedded
part. So example I have no idea how to deal with this which selects
one struct depending on a string:
Box = PrefixedIncludingSize(Int32ub, Struct(
"offset" / TellMinusSizeOf(Int32ub),
"type" / Peek(String(4, padchar=b" ", paddir="right")),
Embedded(Switch(this.type, {
b"ftyp": FileTypeBox,
b"styp": SegmentTypeBox,
b"mvhd": MovieHeaderBox,
b"moov": ContainerBoxLazy,
...
b'afrt': HDSFragmentRunBox
}, default=RawBox)),
"end" / Tell
))
changing
-"type" / Peek(String(4, padchar=b" ", paddir="right")),
to
+"type" / Peek(PaddedString(4,"ascii")),
is probably equivalent, but what is the equivalent syntax for choosing
the right struct for the 'type' field according to the 1st 4 bytes of
it, without using 'Embedded'? This was where I decided it was bedtime
and admitted defeat for the time being.
If someone familiar with construct 2.8 to 2.10 upgrades wanted to take
a look at this that would be very helpful. For some things we might
need to know something about the mp4 format too. I'm not sure to what
degree we need to understand the format, or if we can more or less
mechanically update the syntax.
So, for now there is no mapillary-tools in Debian, and without a
response from upstream or some help I'm stuck.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#920148: RFP: python-mapillary-tools -- Useful tools and scripts related to Mapillary
I had a need for this so had a go at packagaing it.
Turns out the the dependency pymp4 is not in debian, so I packaged that too.
However the tests for pymp4 are giving an error "NameError: name
'String' is not defined ", and if you ignore that and build
mapillary-tools anyway you get test errors there, and if you press on
and then try to use it, you hit the same issue:
File "/usr/lib/python3/dist-packages/pymp4/parser.py", line 86, in
"major_brand" / String(4),
NameError: name 'String' is not defined
So something is wrong that needs investigation.
Build log:
Traceback (most recent call last):
File "/home/wookey/packages/mapillary/pymp4/python-pymp4-1.2.0/setup.py",
line 29, in
setup(name="pymp4",
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 153, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.9/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.9/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 223,
in run
self.run_tests()
File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 226,
in run_tests
test = unittest.main(
File "/usr/lib/python3.9/unittest/main.py", line 100, in __init__
self.parseArgs(argv)
File "/usr/lib/python3.9/unittest/main.py", line 147, in parseArgs
self.createTests()
File "/usr/lib/python3.9/unittest/main.py", line 158, in createTests
self.test = self.testLoader.loadTestsFromNames(self.testNames,
File "/usr/lib/python3.9/unittest/loader.py", line 220, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python3.9/unittest/loader.py", line 220, in
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python3.9/unittest/loader.py", line 191, in loadTestsFromName
return self.loadTestsFromModule(obj)
File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 56, in
loadTestsFromModule
tests.append(self.loadTestsFromName(submodule))
File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
File
"/home/wookey/packages/mapillary/pymp4/python-pymp4-1.2.0/tests/test_box.py",
line 21, in
from pymp4.parser import Box
File
"/home/wookey/packages/mapillary/pymp4/python-pymp4-1.2.0/src/pymp4/parser.py",
line 86, in
"major_brand" / String(4),
NameError: name 'String' is not defined
E: pybuild pybuild:355: test: plugin distutils failed with: exit code=1:
python3.9 setup.py test
dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned
exit code 13
make: *** [debian/rules:10: build] Error 25
Running the tool:
$ mapillary_tools
Traceback (most recent call last):
File "/usr/bin/mapillary_tools", line 33, in
sys.exit(load_entry_point('mapillary-tools==0.8.0', 'console_scripts',
'mapillary_tools')())
File "/usr/bin/mapillary_tools", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3.9/dist-packages/mapillary_tools/__main__.py", line 6,
in
from .commands import authenticate
File "/usr/lib/python3.9/dist-packages/mapillary_tools/commands/__init__.py",
line 2, in
from . import process
File "/usr/lib/python3.9/dist-packages/mapillary_tools/commands/process.py",
line 4, in
from ..insert_MAPJson import insert_MAPJson
File "/usr/lib/python3.9/dist-packages/mapillary_tools/insert_MAPJson.py",
line 9, in
from . import image_log, types, processing, error
File "/usr/lib/python3.9/dist-packages/mapillary_tools/processing.py", line
16, in
from .gpx_from_blackvue import gpx_from_blackvue
File "/usr/lib/python3.9/dist-packages/mapillary_tools/gpx_from_blackvue.py",
line 8, in
from pymp4.parser import Box
File "/usr
Bug#881571: gnumeric doesn't scale row-height correctly on imported spreadsheets
Source: gnumeric Version: 1.12.48-1+b2 Followup-For: Bug #881571 I'm seeing the 'wrong row-height' issue on all my spreadsheets, not just ones imported from calc and excel. In a newly-created sheet the font-size is about twice the row-height, just as in the badly-displayed sheets. If I type something into a cell the characters overhang the next row and then when one hits enter the row is resized to fit the just-entered font-size. Clearly the issue wth the 'characters too big for the rows' is related - the default font-szie is much begger than the default row-size. (looks like about twice as big) This may well be related to the fact that I have a HiDPI display here (3840x2160) so various things have had to be tweaked to make charcters and screen elements be sensible sizes. I tried changing GDK_SCALE=1 instead of 2, but that just produce exactly the same effect (fonts twice as tall as rows) with the overall window 1/4 the area. Not sure what to fiddle with next. But this is a serious problem making gnumeric kind of useless for exaisting sheets unless one wants to resize the fonts in every cell -- Wookey
Bug#1001166: gpxviewer: Unable to load gpx file: (IndexError: list index out of range)
Package: gpxviewer
Version: 1.1.0-3
Severity: normal
Dear Maintainer,
If I run gpxviewer (from a console)
then use Open to open the attahed gpx file
I get this error on the console:
$ gpxviewer
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 385, in open_gpx
if self.load_gpx(filename):
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 371, in load_gpx
self.select_trace(next(self.model[0].iterchildren()))
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 339, in
select_trace
gpxto =
row[self.GPX_IDX].segments[-1].points[-1].time.astimezone(tz.tzlocal())
IndexError: list index out of range
the UI stalls on the 'file open' page. I cannot cancel or load another file,
but have to
close the 'file open' dialog to regain control in the UI.
If I try to load it on the command line I get a different error:
$gpxviewer "Bungay beccles.gpx"
Traceback (most recent call last):
File "/usr/bin/gpxviewer", line 48, in
gui = MainWindow(ui_dir="%sui/" % prefix,files=files).main()
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 208, in __init__
self.lazyLoadFiles(files)
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 233, in
lazyLoadFiles
self.load_gpx(filename)
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 371, in load_gpx
self.select_trace(next(self.model[0].iterchildren()))
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 339, in
select_trace
gpxto =
row[self.GPX_IDX].segments[-1].points[-1].time.astimezone(tz.tzlocal())
IndexError: list index out of range
and the program does not start at all.
I have other gpx files that exhibit the same behaviour. But also some that load
OK.
The attached "Knock Fell.gpx" works fine.
Interestingly if I load two files on the command line with the good one first,
then both appear inthe interface.
$ gpxviewer "Knock_Fell.gpx" "LakesStag2.gpx"
Try it with the bad one first and we get the above error:
$ gpxviewer "LakesStag2.gpx" "Knock_Fell.gpx"
Traceback (most recent call last):
File "/usr/bin/gpxviewer", line 48, in
gui = MainWindow(ui_dir="%sui/" % prefix,files=files).main()
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 208, in __init__
self.lazyLoadFiles(files)
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 233, in
lazyLoadFiles
self.load_gpx(filename)
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 371, in load_gpx
self.select_trace(next(self.model[0].iterchildren()))
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 339, in
select_trace
gpxto =
row[self.GPX_IDX].segments[-1].points[-1].time.astimezone(tz.tzlocal())
IndexError: list index out of range
If I load the app 'empty', then a good track, then a bad track. No
error is reported on the console. Both tracks are displayed but the
UI does not centre on the 2nd ('bad') track. Interestingly there is no
console error output when the 'bad' file is loaded after a good one like this.
But clearly tings are not quite right, because the collapsable list does not
sha anything for the 'bad' track, and clicking on the 'proerties button
generates this console error:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 465, in
button_track_properties_clicked
colorseldlg.get_color_selection().set_current_color(OsmGpsMapTracks[0].props.color.to_color())
TypeError: 'NoneType' object is not subscriptable
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gpxviewer/ui.py", line 465, in
button_track_properties_clicked
colorseldlg.get_color_selection().set_current_color(OsmGpsMapTracks[0].props.color.to_color())
TypeError: 'NoneType' object is not subscriptable
and the 'choose a track colour' dialog does not appear.
So it looks like these 'bad' files are in fact loading OK, but something goes
wrong in the parsing for titles or length summaries.
If I load a large (13MB, 1000miles) gpx file (UK to Austria) it takes 11
seconds before the "IndexError: list index out of range"
appears.
-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gpxviewer depends on:
ii gir1.2-osmgpsmap-1.0 1.2.0-1
ii librsvg2-common 2.50.3+dfsg-1
ii python3 3.9.2-3
ii python3-cairo 1.16.2-4+b2
ii python3-dateutil 2.8.1-6
ii python3-gi3.38.0-2
ii python3-gi-cairo 3.38.0-2
ii python3-gpxpy 1.4.2-1
ii python3-matplotlib3.3.4-1
gpxviewer recommends no packages.
gpxviewer suggests no packages.
-- no debconf info
Bug#987544: RFP: envoyproxy -- high performance C++ distributed proxy designed for single services and applications
On 2021-04-25 11:57 +, Jelmer Vernooij wrote: > * Package name: envoyproxy > * URL : http://envoyproxy.io/ I have just been asked about packaging this so was wondering if anyone has done any work on it yet? There are some binaries but no source at https://deb.dl.getenvoy.io/public/deb/debian/dists With installation described at https://www.envoyproxy.io/docs/envoy/latest/start/install#install-envoy-on-debian-gnu-linux I did try posting to envoy-dev about the above packages last week https://groups.google.com/g/envoy-dev/c/39fGcNZx0NM but no response yet. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#998043: armnn: Tests fail with 'illegal instruction' on NEON-less hardware
Package: armnn Version: 20.08 Severity: serious Tags: upstream ftbfs Justification: fails to build from source (but built successfully in the past) armnn has built fine in the past but -10 and -7 both failed to build when the build machine was antheil. Antheil is one of the Marvell armada 32-bit arm boxes. It builds fine on APM and AMD seattle hardware (both arm64 hardware doing 32-bit builds) The build failure turns out to be in the tests, and testing on abel (Marvell porterbox) determines the offending code to be in the UnitTests binary itself. gdb ./build-area/UnitTests ... Program received signal SIGILL, Illegal instruction. __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ./src/profiling/LabelsAndEventClasses.cpp:14 14 ProfilingGuidGenerator LabelsAndEventClasses::m_GuidGenerator; So it's dying in the initialisation code (gdb) disassemble ... > 0xb6d9acf8 <+60>:vmov.i32d8, #0 ; 0x Which is neon code I believe and NEON is an optional extension that shouldn't be used with checking it's present (Armada has MMX2, not NEON). So I think either this test binary sould be built without NEON or there should be a HWCAP check around such usage.
Bug#994275: Reverting breaking changes in debianutils
On 2021-10-24 19:08 +, Clint Adams wrote: > On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote: > > I think causing build failures is enough reason to say this. I don't > > suppose that mine is the only one. Yes those builds are buggy and > > should not do this, and we should make efforts to find out why bazel > > (or possibly the build scripts it is operating on) is/are so crappy, > > but for now I agree that reverting this is the right thing to do. > > > > We have time to do this transition properly and quietly in the > > background, without causing random breakage. A message about a binary > > moving from one package to another does not need to be printed on > > every usage of that binary. Indeed it is actively unhelpful to do so. > > Boyuan packaged GNU which and uploaded it to NEW in August. It is now > October, and neither GNU which nor *BSD which nor any other which > alternative is in unstable. Presumably one of these could have put > a band-aid on your bazel problem, though of course any version of > `which` might output things to stderr for a variety of reasons. That package is the band-aid I am currently using, but (because it has indeed not progressed through NEW yet, which is presumably down to ftpmaster bandwidth) it's a hassle where I have to make sure it is made available in the build environment each time. > Lots of things broke between buster and bullseye. Most of them broke by accident or for good reasons. You broke this semi-deliberately, by deciding not to manage a quiet background transition of the which binary to some other package, but to print a deprecation message and let other people deal with the fallout. OK, maybe you expected the change to be harmless, but you didn't revert it once it became clear that this was not a good way to do the transition. IIUC the tech committee have now told you to do it properly, as a managed transition. Good. > Is the difference that these packages aren't Essential? The difference from where I am standing is the attitude of the maintainer to doing things properly vs causing other people hassle. Nobody is making you remove/move which. If you want to move/remove which then do it in a way that doesn't break other people's stuff (as much as possible). In this case that really isn't hard to do (just wait until GNU which passes NEW, and preferably file bugs on packages that now need to depend on it). I didn't understand why you wanted to make this change in the first place, and I don't understand why you didn't just revert the message when it became clear that it was a problem, and I don't understand why you are still trying to justify your somewhat bloody-minded approach to this (should-have-been) minor issue, even after the tech comittee have agreed that it was not a good approach. Please, just remove the deprecation message, until GNU which is in unstable (like you should have done a couple of months ago, when first asked), then work out how the transition should go such that no-one using which will actually notice or care. Then you can throw away the hated binary :-) and we can all be happy. I understand that it's galling to have the TC tell you to take a different approach, especially when you've doubled-down on your approach, but I'm afraid the TC is correct here, so please, stop arguing, do what's best for the project, and soon enough this will all be over, and we'll all have what we want. And you may (or may not) choose to reflect on the the point that we _could_ have got to exactly the same point without this argument if you'd made different choices. From my personal point of view this is solved short-term the moment the deprecation message is gone in unstable, and long term as soon as GNU which enters unstable. I hope this is my last-ever word on this tiresome subject. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#994275: Draft resolution for reverting changes in debianutils
On 2021-10-13 19:37 -0300, David Bremner wrote: > Sean Whitton writes: > >The which(1) program must not print any deprecation warnings. > > I remain to be convinced on this point. If I understand the issue > correctly the problem is with autopkgtests failing because they were not > expecting output on stderr. It's not just that. Builds fail too. tensorflow now FTBFS in unstable because of this change, and the way bazel deals (or fails to deal) with it. I gave details further up the thread. > I understand that people find the message annoying, and perhaps not that > useful, but I don't think that rises the level justifying overriding a > maintainer. I think causing build failures is enough reason to say this. I don't suppose that mine is the only one. Yes those builds are buggy and should not do this, and we should make efforts to find out why bazel (or possibly the build scripts it is operating on) is/are so crappy, but for now I agree that reverting this is the right thing to do. We have time to do this transition properly and quietly in the background, without causing random breakage. A message about a binary moving from one package to another does not need to be printed on every usage of that binary. Indeed it is actively unhelpful to do so. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#995269: glibc-source: Please enable MTE (heap) checking on arm64
Package: glibc-source Severity: wishlist Tags: patch glibc 2.33 onwards has support for 'Memory Tagging Extension' on arm64. Could you please enable this feature (by setting --enable-memory-tagging in the config). The effect is to add colouring bits into heap pointers so that typical illegal accesses (either temporally or spatially) can be detected and faulted. Glibc just has the userspace heap tagging - there is also corresponding kernel support. The functionality operates on arm ISA 8.5 or later, which has extra instructions to manipulate the tag bits in pointers. The details are explained in https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Memory_Tagging_Extension_Whitepaper.pdf The implementation has been designed so that it is safe to enable in distros (which makes a change!). ifunc and HWCAP are used to link MTE-ready versions of relevant functions on hardware supporting ARMv8.5 instruction set or later. On eailer hardware things will work just as they do now. Here is the (trivial) patch: diff -u debian/sysdeps/arm64.mk~ debian/sysdeps/arm64.mk --- debian/sysdeps/arm64.mk~2021-08-24 14:31:06.0 + +++ debian/sysdeps/arm64.mk 2021-09-28 19:43:58.782118977 + @@ -1,2 +1,2 @@ # configuration options for all flavours -extra_config_options = --enable-multi-arch --enable-static-pie +extra_config_options = --enable-multi-arch --enable-static-pie --enable-memory-tagging -- Wookey
Bug#994836: exim: dpkg fatal error due to Debian-exim in statoverride
ibxcb-render-util0 libxcb-util1 libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1 libxcb1-dev libxdmcp-dev libxerces-c-dev libxerces-c3.2 libxext-dev libxft-dev libxkbcommon-x11-0 libxnvctrl0 libxrender-dev libxss-dev libxt-dev libzimg2 libzstd-dev libzzip-0-13 mpi-default-bin mpi-default-dev ninja-build odbcinst odbcinst1debian2 openjdk-11-jdk openjdk-11-jdk-headless openjdk-11-jre openjdk-11-jre-headless openmpi-bin openmpi-common pkg-config poppler-data proj-data python3-mpi4py python3-vtk9 rpcsvc-proto survex tcl tcl-dev tcl8.6 tcl8.6-dev tex-common texlive-base texlive-binaries texlive-metapost tk tk-dev tk8.6 tk8.6-dev unixodbc-dev vtk9 wx-common wx3.0-headers x11proto-dev xorg-sgml-doctools xtrans-dev The following packages will be upgraded: binutils binutils-aarch64-linux-gnu binutils-common cpp-10 ffmpeg g++-10 gcc-10 gcc-10-base libaec-dev libaec0 libasan6 libatomic1 libavcodec58 libavdevice58 libavfilter7 libavformat58 libavutil56 libbinutils libblas3 libc-bin libc-dev-bin libc6 libc6-dev libcc1-0 libctf-nobfd0 libctf0 libegl1 libgcc-10-dev libgcc-s1 libgfortran5 libgl1 libglib2.0-0 libglvnd0 libglx0 libgnutls-dane0 libgnutls30 libgomp1 libitm1 libjson-c5 liblapack3 liblsan0 liblz4-1 libmariadb3 libnettle8 libnuma1 libogg0 libopenjp2-7 libpostproc55 librubberband2 libsqlite3-0 libstdc++-10-dev libstdc++6 libswresample3 libswscale5 libsz2 libtsan0 libubsan1 libvpx6 libwebp6 libwebpmux3 libx11-6 libx11-xcb1 libxau6 libxcb1 libxext6 libzstd1 66 upgraded, 286 newly installed, 1 to remove and 499 not upgraded. Need to get 512 MB of archives. After this operation, 887 MB of additional disk space will be used. exim is not mentioned in that list. Turns out that the install list doesn't matter. any use of dpkg will hit this statoverride issue. /etc/exim4/passwd.client does exist but is owned by an unknown group. $ll /etc/exim4/passwd.client -rw-r- 1 root 132 204 Nov 4 2020 /etc/exim4/passwd.client And groupno 132 is not used in /etc/group: ... ssl-cert:x:129: avahi-autoipd:x:130: nm-openvpn:x:131: apt-cacher-ng:x:145: sbuild:x:149:wookey01,wookey ... So it does indeed look like the Debian-exim group was removed, but at least one file owned by it, and the statoverride remain. Is that expected? - I presume not. /var/lib/dpkg/info/exim4-base.postinst looks like it creates a Debian-exim user still (although not obviously the group?) $ sudo ls -ld /var/spool/exim4: drwxr-x--- 5 130 132 4096 Dec 9 2020 /var/spool/exim4 so the Debian-exim user is gone too. $ cat /etc/passwd ... nm-openvpn:x:128:131:NetworkManager OpenVPN,,,:/var/lib/openvpn/chroot:/usr/sbin/nologin hplip:x:129:7:HPLIP system user,,,:/var/run/hplip:/bin/false apt-cacher-ng:x:132:145::/var/cache/apt-cacher-ng:/usr/sbin/nologin sbuild:x:133:149:Debian source builder,,,:/var/lib/sbuild:/bin/bash ... I grepped for mentions of Debian-exim in /var/dpkg/info and only found it in exim scripts, so not clear what might have removed it: $ grep Debian-exim /var/lib/dpkg/info/* /var/lib/dpkg/info/exim4-base.postinst /var/lib/dpkg/info/exim4-config.postinst /var/lib/dpkg/info/exim4-config.postrm Anything else I should check? -- Wookey
Bug#861073: NMUing dpkg-cross
On 2021-08-31 21:30 +0200, Helmut Grohne wrote: > Hi wookey, > > you seem to be busy with non-dpkg-cross things and that's fine. The > package has a few filed bugs and other minor issues though and I'm > taking the liberty to NMU it in accordance with the LowNMU list you've > subscribed to. I'm attaching the full .debdiff of the performed changes. Thanks Helmut. I am indeed currently distracted by trying to bottom the Gouffre Berger (tommorrow if things go to plan). Back on the internet around 13th September. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459
On 24/08/2021 07:45, Rafael Laboissière wrote: I am hereby reassigning the Bugs #979458 and #979459, which were assigned to the binary jed and jed-common packages, to the jed source package. I am also merging this two bug reports and rising their severity level to serious. The trivial patch that fixes the problem is attached to this message. Thanks Rafael. I'm away on expedition with negligible internet until 12th Sept, so if anyone wishes to NMU this, that's fine by me. Otherwise it'll get done sometime after I get back. -- Wookey
Bug#991334:
Severity: normal This is not a serious bug and is currently slated to remove monit from testing. Please check for severities here https://www.debian.org/Bugs/Developer#severities It's been rejected upstream I'll let the maintainers here comment on if it should be accepted or rejected here.
Bug#991534: unblock: therion/5.5.7ds1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package therion RC bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991064 fixed diff -Nru therion-5.5.7ds1/debian/changelog therion-5.5.7ds1/debian/changelog --- therion-5.5.7ds1/debian/changelog 2021-02-06 16:24:25.0 + +++ therion-5.5.7ds1/debian/changelog 2021-07-27 00:27:47.0 +0100 @@ -1,3 +1,10 @@ +therion (5.5.7ds1-2) unstable; urgency=medium + +* Allow build with new secure imagemagik (Closes: #991064) + Thanks to Dennis Filder for the patch + + -- Wookey Mon, 26 Jul 2021 23:27:47 + + therion (5.5.7ds1-1) unstable; urgency=medium * New upstream release, including below bugfixes diff -Nru therion-5.5.7ds1/debian/rules therion-5.5.7ds1/debian/rules --- therion-5.5.7ds1/debian/rules 2021-01-04 02:47:31.0 + +++ therion-5.5.7ds1/debian/rules 2021-07-27 00:27:06.0 +0100 @@ -2,6 +2,9 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs export DH_VERBOSE=1 + +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" + %: dh $@ @@ -11,7 +14,10 @@ # We need therion itself to build the samples $(MAKE) therion # create HTML documentation for samples - faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples + mkdir -p debian/tmp/ImageMagick + sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml + faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" samples + rm -Rf debian/tmp/ImageMagick endif $(MAKE) thbook Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/cave.3d and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/cave.3d differ Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/create/create.3d and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/create/create.3d differ Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/ignore/ignore.3d and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/ignore/ignore.3d differ Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/use/use.3d and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/use/use.3d differ (the build-time generated sample .3d files have an embedded timestamp and they differ by 4 bytes (at least on my local build) despite my best efforts to make them match using faketime. Bad for reproducability but otherwise of no significance) unblock therion/5.5.7ds1-2 -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#990641: gpsprune: Cannot load gpx file from OSm route manager (due to blank lines)
Package: gpsprune Version: 20.2-1 Severity: normal Tags: upstream If I generate a gpx file with 'OSM Route manager', specifically the Ceredigion Coast path https://osmrm.openstreetmap.de/relation.jsp?id=1806040 when I try to load it with GPSprune it says: "Error reading file: The processing instruction target matching '[xX][mM][lL]' is not allowed." This is quite a cryptic error. If try 'Import file with GPSbabel' instead I get the somewhat more helpful "GPX Read error: 'XML declaration not at start of document. "File: /tmp/Ceredigion+Coast+Path.gpx" Line: 13 column: 55' Looking at the file (attached) it has 12 leading blank lines. (0x0A unix linefeeds). Looks like GPSprune is expecting the xml header to be on the first line. If you remove those 12 lines then the file loads as expected. Now I presume that GPSprune is following the gpx spec, but perhaps it could be forgiving of leading whitespace? Certainly it could give a more useful error message of the form 'Could not load file : invalid GPX file'. I had a look at the gpx spec, and the schema is here: https://www.topografix.com/GPX/1/1/gpx.xsd but I guess that whether the xml line must be on the very first line is actually part of the XML spec. I failed to find a simple validator I could run to check whether The codebase for OSMRM is here: https://github.com/osmrmhv/osmrmhv/issues so it you are happy that GPSprune is correct to reject this file then I guess I should file an issue there instead. -- Wookey
Bug#990412: pam: PAM doesn't appear to be reading /lib/security
Fair enough, I couldn't find any docs on the policy of /lib/security or any news on it not being scanned in Bullseye, is there something about that somewhere? On 28/06/2021 14:48, Sam Hartman wrote: > control: reassign -1 libpam-yubico > control: severity -1 grave > control: retitle -1 pam_yubico fails to install module in multiarch path > control: found -1 2.23-1 > >>>>>> "Rowan" == Rowan Wookey writes: > > Rowan> It appears that in Bullseye pam isn't checking /lib/security. > > > Rowan> The libpam-yubico package installes a module in /lib/security > Rowan> which when configured without an absolute path pam errors > Rowan> with: > > I think that's a bug in the other package. > The issue is that /lib/security is not a multiarch path. > And so I cannot have both an i386 and amd64 version of the module > installed at the same time. > By this point, we really ought to be supporting multiarch. > > I'm happy to add breaks relationships in pam on broken modules that > don't provide multiarch paths, > but I'd consider this a grave bug on a module that only installs in > /lib/security at this point. >
Bug#917374: Related bug
PAM Bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990412
Bug#990412: pam: PAM doesn't appear to be reading /lib/security
Source: pam Version: 1.4.0-7 Severity: important X-Debbugs-Cc: debianb...@rwky.net Dear Maintainer, It appears that in Bullseye pam isn't checking /lib/security. The libpam-yubico package installes a module in /lib/security which when configured without an absolute path pam errors with: PAM unable to dlopen(pam_yubico.so): /lib/x86_64-linux-gnu/security/pam_yubico.so: cannot open shared object file: No such file or directory This worked fine on Buster, it also works on the latest Ubuntu. lib-pamyubico bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979973 -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#979973: Possibly a bug in PAM
This may not be a bug in this package but instead a bug in pam (which I've reported but not got a bug number for yet). pam should be checking /lib/security for the module. The afore mentioned patch suggests switching to x86_64-linux-gnu whcih is a multi arch directory, if this package is to be converted to multiarch then $(DEB_HOST_MULTIARCH) should be used which can be set using DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) (copied from the pam package rules file) -- Regards Rowan Wookey MSc Comp (Open), CISMP Server Administrator & Programmer Please add ad...@rwky.net to your contacts/email whitelist. My GPG key https://www.rwky.net/admin_at_rwky.net.sig My SSH key https://www.rwky.net/id_rsa.pub
Bug#989669: mali-t76x-x11-driver is not installable (armhf)
On 2021-06-09 22:46 +0300, Andrew M wrote: > The following packages have unmet dependencies: > mali-t76x-x11-driver:armhf : Depends: mali-midgard-dkms:armhf but it is not > installable > E: Unable to correct problems, you have held broken packages. Hmm. Sorry that's not working. The mali binary drivers have now been removed from Debian because they are superseded by the panfrost free driver, and were never much practical use anyway. https://wiki.debian.org/PanfrostLima The binary drivers only ever worked on small subset of hardware because of the way the binary driver was designed. They worked on Firefly boards, and maybe some others but I'm not aware of any demonstrations of that. > but there is mali-midgard-dkms with all architecture and it is installable Hmm, there does seem to be some kind of multiarch problem there. mali-midgard-dkms has always been arch:all. I'm not sure what's gone wrong to produce the failing dependency, but I don't think there is much point investigating at this stage. Sorry. That package too is pending removal. What did you hope to use it for? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#988582: unblock: ne10/1.2.1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ne10
This fixes the RC bug 987643 which meant that it FTBFS in testing/unstable
This was due to a change in the defaults between gcc9 and gcc10 from
-nof-common to -fcommon
Specifying the build flag explicitly in the build gets it building again.
Debdiff attached
unblock ne10/1.2.1-5
diff -Nru ne10-1.2.1/debian/changelog ne10-1.2.1/debian/changelog
--- ne10-1.2.1/debian/changelog 2019-01-07 03:44:54.0 +
+++ ne10-1.2.1/debian/changelog 2021-05-07 04:57:03.0 +0100
@@ -1,3 +1,9 @@
+ne10 (1.2.1-5) unstable; urgency=medium
+
+ * Fix FTBFS with gcc10 (Closes: #987643)
+
+ -- Wookey Fri, 07 May 2021 03:57:03 +
+
ne10 (1.2.1-4) unstable; urgency=medium
* Fix build for armhf (Closes: #905831)
diff -Nru ne10-1.2.1/debian/patches/gcc10-fixes.patch
ne10-1.2.1/debian/patches/gcc10-fixes.patch
--- ne10-1.2.1/debian/patches/gcc10-fixes.patch 2019-01-07 03:44:54.0
+
+++ ne10-1.2.1/debian/patches/gcc10-fixes.patch 2021-05-07 04:57:03.0
+0100
@@ -98,3 +98,20 @@
{
{ 1.0, 0.0 },
{ 0.70711, -0.70711 },
+Index: ne10-1.2.1/CMakeLists.txt
+===
+--- ne10-1.2.1.orig/CMakeLists.txt
ne10-1.2.1/CMakeLists.txt
+@@ -93,10 +93,10 @@ option(NE10_ENABLE_IMGPROC "Build image
+ set(NE10_VERSION 10)
+
+ if(BUILD_DEBUG)
+-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-strict-aliasing -O0 -DDEBUG -g
-Wall -Wno-unused-but-set-variable")
++set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fcommon -fno-strict-aliasing -O0
-DDEBUG -g -Wall -Wno-unused-but-set-variable")
+ message("-- Building type: DEBUG")
+ else(BUILD_DEBUG)
+-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-strict-aliasing -O2 -DNDEBUG")
++set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fcommon -fno-strict-aliasing -O2
-DNDEBUG")
+ message("-- Building type: RELEASE")
+ endif(BUILD_DEBUG)
+
