Bug#839546: apt upgrade wants to install packages that apt autoremove will remove
On Sat, Oct 01, 2016 at 11:15:28PM +0300, Sami Liedes wrote: > apt upgrade lists some packages as new packages that will be > installed, but at the same time lists those packages as "automatically > installed and no longer required". [...] > Note that all of the NEW packages that will be installed are also in > the autoremoveable list (contrary to what apt says, those packages are > not yet installed). I'm seeing what appears to be the same problem, so this bug still seems to be present: root@gemse:~# apt upgrade The following packages were automatically installed and are no longer required: libqt6network6t64 libqt6opengl6t64 libqt6openglwidgets6t64 libqt6xml6t64 Use 'apt autoremove' to remove them. Installing dependencies: libqt6network6t64 libqt6opengl6t64 libqt6openglwidgets6t64 libqt6xml6t64 Not upgrading: htmldoc libcanberra-pulse libnode-dev libnode109 nodejs octave octave-common octave-dev Summary: Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 8 Download size: 1,201 kB Space needed: 4,552 kB / 1,749 GB available Continue? [Y/n] n Abort. root@gemse:~# apt autoremove Summary: Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 8 root@gemse:~# apt --version apt 2.9.2 (amd64) If there's stuff I can usefully prod to help debug what's causing this please let me know. Cheers, Olly
Bug#1068599: ruby-xapian - still depends on old libruby3.1 after binnmu
On Sun, Apr 07, 2024 at 08:22:37PM +0100, Peter Michael Green wrote: > The following lines in the build log look like a likely culprit. > > > # The module(s) are linked against libruby2.x but use none of its > > # symbols, so there's no dependency generated. That's unhelpful for > > # users and for transitions (https://bugs.debian.org/816775) so > > # generate a suitable dependency. > > # > > # If RUBY_VERSIONS is 2.1 2.2 2.3, Depends: libruby2.3|libruby2.1 > > |libruby2.2 > > echo "ruby:Depends=libruby3.1" \ > > >> debian/ruby-xapian.substvars Yes, thanks for identifying that. We can't rely on the automated machinery (see ticket linked above if you want the gory details) but the ruby team (quite reasonably) wanted a dependency and suggested essentially what we do now. We could just hardcode t64 here, but probably better to try to extract the actual library from the matching ruby version's dependencies so we don't have to do this for future suffix changes (the next librubyX.Y to be packaged won't need it). This works, but maybe there's a better way: dpkg -s ruby3.1|sed -n 's/^Depends:.*\(libruby3.1[a-z0-9]*\).*/\1/p;d' I'll try to get a fix uploaded in the next day or two. Cheers, Olly
Bug#1064475: lists.debian.org: missing recent posts in search indices.
Thanks for reporting this. On Sat, Mar 09, 2024 at 06:29:22PM +, James Addison wrote: > Running a search for 'python removal' on the 'testing-changes' mailing list, > ordered by most-recent-first, currently lacks any results from this year. > > > https://lists.debian.org/cgi-bin/search?P=python+removal=and=Gdebian-testing-changes=0=100=python%09removal=Gdebian-testing-changes%7E.%7E%7E0 There are currently 7 shards in the lists database, but only the first 6 were listed to be searched. It looks like indexing is working fine, except it started a new shard and failed to update the list to search. I've manually fixed this and now the search above gives me a top result of: Testing removal summary 2024-03-10 (Sunday) I really need to resolve why this didn't happen automatically or else this will go wrong again in the future. Cheers, Olly
Bug#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory
On Wed, Nov 08, 2023 at 08:10:26PM +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. > 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. > > For now, I'll just enable using the bundled Catch2 instead of v3 installed > in the system. Note that doing so violates a "should" in Debian Policy: 4.13. Embedded code copies == Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don’t have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. [17] If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. [18] If you (as upstream) are going to have a bundled code copy of catch, you could just bundle catch3 instead. Cheers, Olly
Bug#1008092: antiword: Possible related RedHat-reported buffer overflow
On Tue, Oct 10, 2023 at 12:12:49AM +0100, Tj wrote: > A package search on the RedHat bugzilla shows other reports including > tracking bugs for the referenced (security) bug #2064638. > > https://bugzilla.redhat.com/buglist.cgi?component=antiword=Fedora Doesn't seem promising - there's no useful public info there, but https://bugzilla.redhat.com/show_bug.cgi?id=2064735 says: | This CVE Bugzilla entry is for community support informational | purposes only as it does not affect a package in a commercially | supported Red Hat product. Refer to the dependent bugs for status of | those individual community products. Reads to me like "this doesn't affect RHEL so we aren't interested". The public bugs at least seem to have just been closed without a fix being applied. > It might be worth contacting Adrian Reber for info on this. If you think it'll help please do. Cheers, Olly
Bug#1008092: antiword: Possible unsanitised input data
On Mon, Oct 09, 2023 at 10:57:46PM +0100, Tj wrote: > As requested here's a summary of one potential unsanitised input data > issue that may be leading to this (or other) error(s). > > `vSetSummaryInfoOLE()` calls `pucAnalyseSummaryInfoHeader()` that does: > > `if (!bReadBuffer(pFile, ... aucBuffer, ...) ... return aucBuffer;` > > and then calls `vAnalyseSummaryInfo(pucBuffer)` > > - there-in if `ulOffset` is especially large the following: > > `tPropType = (size_t)ulGetLong(ulOffset, aucBuffer);` > > could be outside of `aucBuffer` since the size of the buffer is not > passed to this function and therefore cannot be checked. Thanks. It looks like it needs to return tLength along with aucBuffer and check accesses against that. I'll take a look at doing that. It'd still be helpful to have the "vAnalyseSummaryInfo.poc.doc" file to reproduce the reported crash as without that we can't test any fix actually addresses the bug reported here. I've cc-ed the reporter - hopefully they'll see it this time and provide that file. Cheers, Olly
Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation
Package: mate-panel Version: 1.27.1-2 Severity: normal Frequently (but not every time) I unhibernate I get a pop up telling me that mate-clock has crashed. I do at least get the option to restart it, and doing so has always worked so far. I'm seeing this on two different machines now, and both i386 and amd64. It's taken me a while to sit down and work out how to get a useful backtrace, but I think it must have started with the update to 1.27.1-1 or 1.27.1-2. (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7fa842435472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7fa84276d5dd in () #5 0x in () I read that as it's already aborting when it segfaults, so maybe that's not helpful in knowing the root cause. I'm happy to debug further if someone tells me what to try. Cheers, Olly -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-panel depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii libatk1.0-0 2.49.91-2 ii libc62.37-10 ii libcairo21.17.8-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-1 ii libgtk-3-0 3.24.38-5 ii libgtk-layer-shell0 0.8.1-1 ii libice6 2:1.0.10-1 ii libmate-desktop-2-17 1.26.1-1 ii libmate-menu21.26.0-3 ii libmate-panel-applet-4-1 1.27.1-2 ii libmateweather1 1.26.0-1.1 ii libpango-1.0-0 1.51.0+ds-2 ii librda0 0.0.5-1.1 ii libsm6 2:1.2.3-1 ii libwayland-client0 1.22.0-2.1 ii libwnck-3-0 43.0-3 ii libx11-6 2:1.8.6-1 ii libxrandr2 2:1.5.2-2+b1 ii mate-desktop 1.26.1-1 ii mate-menus 1.26.0-3 ii mate-panel-common1.27.1-2 ii mate-polkit 1.26.1-4 mate-panel recommends no packages. mate-panel suggests no packages. -- no debconf information
Bug#1033052: eviacam quits with "cvCreateCameraCapture doesn't support legacy API anymore"
Control: forwarded -1 https://github.com/cmauri/eviacam/issues/22 Control: severity -1 serious I'm raising the severity since important is defined as "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone", but this bug means the eviacam package is completely unusable to everyone. https://github.com/cmauri/eviacam/pull/38 (which has been merged upstream but isn't in a release yet) may fix this, but I haven't attempted to test this ( Cheers, Olly
Bug#1023519: python3-wxgtk4.0: Windows do not follow "dark" mode in Gnome
Control: forwarded -1 https://github.com/wxWidgets/wxWidgets/pull/23764 On Mon, Jul 17, 2023 at 11:19:15AM -0400, Scott Talbert wrote: > While evaluating this issue, > it seems even a lot of native Gnome/GTK apps do not even provide a dark mode > (e.g., even the gtk-demo application doesn't). So it seems there is a lot > of work still to be done here. It looks like this has been implemented upstream very recently. There seem to be follow-on changes happening still (which also means it's not a single patch to cherry-pick), so probably we just pick this up in the next upstream release once it's stabilised. Cheers, Olly
Bug#1050238: wxwidgets3.2: FTBFS: testsuite issues
On Tue, Aug 22, 2023 at 03:40:57PM +0200, Aurelien Jarno wrote: > It appears that the failing tests are already filtered on some > architectures, would it be possible to do the same on riscv64 until we > have time to investigate the issue? The following patches enables the > package to build successfully: > > --- wxwidgets3.2-3.2.2+dfsg/debian/rules > +++ wxwidgets3.2-3.2.2+dfsg/debian/rules > @@ -9,13 +9,13 @@ > ifneq (,$(filter $(DEB_HOST_ARCH), alpha mips64el riscv64 s390x)) > TEST_FILTER += ~[special-file] > endif > -ifneq (,$(filter $(DEB_HOST_ARCH), hppa mips64el ppc64 s390x sparc64 x32)) > +ifneq (,$(filter $(DEB_HOST_ARCH), hppa mips64el ppc64 riscv64 s390x sparc64 > x32)) > TEST_GUI_FILTER += ~WebView > endif > ifneq (,$(filter $(DEB_HOST_ARCH), i386)) > TEST_GUI_FILTER += ~wxImage::ChangeColours > endif > -ifneq (,$(filter $(DEB_HOST_ARCH), mips64el sparc64)) > +ifneq (,$(filter $(DEB_HOST_ARCH), mips64el riscv64 sparc64)) > TEST_GUI_FILTER += ~wxImage::Paste > endif I don't know the background to these test failures, but extending them for a new arch is clearly reasonable. If this is blocking progress for you please feel free to NMU the change above - otherwise we can include this in the next upload. Cheers, Olly
Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)
On Wed, Jun 07, 2023 at 09:27:13PM +0100, Olly Betts wrote: > I think it'd be good to check with upstream if the "experimental" marker > is out-dated, or still accurate, and if it's still accurate what the > downsides of this are. I've opened a ticket: > > https://github.com/wxWidgets/wxWidgets/issues/23619 Upstream confirms it's not experimental any more and will update the docs. They did note that not only does it not work under Wayland, but also that it may not be possible to make it work there. Cheers, Olly
Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)
Control: reassign -1 source:wxwidgets3.2 On Wed, Jun 07, 2023 at 09:49:19AM -0400, Scott Talbert wrote: > I think it would be okay to enable xtest support even though it doesn't work > under Wayland. I think it'd be good to check with upstream if the "experimental" marker is out-dated, or still accurate, and if it's still accurate what the downsides of this are. I've opened a ticket: https://github.com/wxWidgets/wxWidgets/issues/23619 > However, this type of change doesn't seem appropriate for a > stable release (it's possible it might even cause an ABI change), so we'd > have to make it unstable after bookworm is released (this weekend?!). Thus, > the bug should be reassigned to wxwidgets3.2. Oh, I missed that this was reported in wxwidgets3.0 - thanks for spotting. I agree this should be reassigned - wxwidgets3.0 is gone from bookworm and newer and I really can't see the release team agreeing to enabling a new optional feature in a stable or oldstable update (and one of their criteria is severity important or higher). So we can only target addressing this for trixie at this point, so we can take the time to check with upstream. If it requires an ABI bump we'd need to do a transition so that's a key question. Cheers, Olly
Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)
On Tue, Jun 06, 2023 at 02:12:50PM -0400, Maxim Cournoyer wrote: > I researched the problem and found that the feature I wanted was implemented > using XTest, which is detected at wxWidgets' build time [1]. Looking at the > Debian > package dependencies, I found it did *not* depend on the libxtst6 package. > > [1] https://github.com/wxWidgets/wxWidgets/issues/17530 Have you actually tested a wx build with this enabled? Comments in that ticket suggest that XTest doesn't work on Wayland and "Wayland is used by default in Debian 10 and newer" (10 is buster, the current stable release right now which is about to become oldstable): https://wiki.debian.org/Wayland It looks like there isn't a Wayland-specific implementation in the source and src/unix/uiactionx11.cpp uses X11-specific functions so building with --with-xtest may not really solve your problem. Forcing use of X11 for the app may help, e.g.: GDK_BACKEND=x11 ./myapp (The debian wx packages currently effectively do the above automatically if wxGLCanvas is used as the current support for wxGLCanvas on Wayland has some problems - hopefully we can eliminate that soon, but it seemed the least risky fix for the bullseye release.) >* What was the outcome of this action? > > This bug/wishlist report. Hilarious, but more useful answers to these questions would be a short python script to allow us to easily check if wx.UIActionSimulator is working as you expect or not (e.g. currently this script produces no output, with working support it should output "..."). > wx.UIActionSimulator from wxPython/wxWidgets should produce key inputs > instead of nothing. It should work like it does on Guix System. I notice that configure --help describes this feature as "experimental": --enable-uiactionsimuse wxUIActionSimulator (experimental) That might be an outdated status though. Cheers, Olly
Bug#1033082: bullseye-pu: package xapian-core/1.4.18-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: xapian-c...@packages.debian.org Control: affects -1 + src:xapian-core [ Reason ] This is a targetted fix for a potential database corruption if switching the new revision live fails with ENOSPC but the recovery process does NOT get ENOSPC: https://bugs.debian.org/1032398 It looks like all previous 1.4.x releases are affected. This is a regression compared to Xapian 1.2.x (which was in jessie). The fix here is taken from upstream's 1.4.22 release and is the simplest way to address the problem: simply reread the current version file from disk which means the in memory state will match the previously committed state. [ Impact ] This can result in corrupted databases for users if their partition fills up while indexing. It doesn't happen every time, but it's definitely been hit by one notmuch user on Debian, and likely explains a smattering of reports of database corruption over the years. [ Tests ] There's a pretty thorough upstream testsuite for xapian-core. The specific scenario of ENOSPC isn't currently tested by that, but we've exercised it by hand by injecting an ENOSPC failure using strace, which reliably triggers corruption without the patch and no corruption with it. The fix was include in the upstream 1.4.22 release which was released 2023-02-02 (6 weeks ago) and uploaded to unstable the same day - there haven't been any reports of issue with it. [ Risks ] This is a really low risk change. It only touches the code path taken when a commit operation fails to write to disk, and does a more complete reset of state in that case. The rollback being done here is actually more complicated than necessary (the multiple tables are now committed together atomically, but used to be committed one-by-one which required extra care to roll-back). That's been cleaned up on upstream git master, but I've gone for the simpler and less invasive fix from upstream 1.4.x. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in stable [*] the issue is verified as fixed in unstable [ Changes ] The change switches from calling a function which attempts to roll-back the in-memory state directly (but gets it wrong in this situation) to one which resets the in-memory state to what it would be if the database was opened afresh. Cheers, Olly diff -Nru xapian-core-1.4.18/debian/changelog xapian-core-1.4.18/debian/changelog --- xapian-core-1.4.18/debian/changelog 2021-02-24 07:33:41.0 +1300 +++ xapian-core-1.4.18/debian/changelog 2023-03-17 11:20:07.0 +1300 @@ -1,3 +1,15 @@ +xapian-core (1.4.18-3+deb11u1) bullseye; urgency=medium + + * debian/patches/fix-db-corruption-on-ENOSPC.patch: New patch to +fix potential database corruption if switching the new revision +live fails with ENOSPC but the recovery process does NOT get ENOSPC. +The fix here is taken from upstream's 1.4.22 release and is the simplest +way to address the problem: simply reread the current version file +from disk which means the in memory state will match the previously +committed state. Closes: #1032398 + + -- Olly Betts Fri, 17 Mar 2023 11:20:07 +1300 + xapian-core (1.4.18-3) unstable; urgency=medium * debian/rules: Workaround testcase sensitivity to excess precision by diff -Nru xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch --- xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 1970-01-01 12:00:00.0 +1200 +++ xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 2023-03-17 11:20:07.0 +1300 @@ -0,0 +1,40 @@ +commit 90f7a35483b4cf7dd848c34634803bf28f95081d +Author: Olly Betts +Date: Wed Jan 25 11:40:44 2023 +1300 + +Fix recovery from failed commit + +If renaming to switch the new version file live fails (e.g. due to +ENOSPC) we discard the changes, try to write and switch to a different +new version file with an increased revision (on failure of this too we +close the database), and throw DatabaseError. + +Unfortunately the roll-back of state is not complete, and if switching +to the different new version file succeeds that bad state persists on +disk. + +Thanks to Uwe Kleine-König for reporting and coming up with the idea +to reproduce using strace to inject a rename() failure - this is a +simple reproducer: + +rm -rf enospc.db +strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db < INSTALL +xapian-check enospc.db + +No automated regression test for this yet as this doesn't trivially +fit into the existing testsuite framework, but we ought to have +tests using fault injection. + +(cherry picked f
Bug#1032398: xapian-core: Risk of database corruption on disk full
Source: xapian-core Version: 1.4.18-3 Severity: critical Tags: patch upstream Justification: causes serious data loss Control: fixed -1 1.4.22-1 Xapian database corruption on disk full is possible. It doesn't happen in every case as ENOSPC needs to happen on a particular operation during the commit but then not happen on a repeat attempt at that operation. Filing systems with more complex freespace handling may be more susceptible to this (it was reported on btrfs). Only glass databases are affected - the commit code for the older chert format is significantly different. I've filed this with severity based on the worst case where the data in the Xapian database is not simply an index of data from elsewhere. This is the situation for user-applied tags in notmuch, for example. In many cases the Xapian database is an index of data stored elsewhere so can be recreated from scratch (albeit this may take some time). This was fixed upstream in 1.4.22, which is the version now in unstable and testing. It looks like all previous 1.4.x releases are affected. I'm intending to submit a stable update for this, and will see if the LTS team are interested too. The upstream patch is a single line change: https://git.xapian.org/?p=xapian;a=commitdiff;h=9f9aad17893bde4acb3a98e60dde397c346fcd9a Details from upstream commit message: If renaming to switch the new version file live fails (e.g. due to ENOSPC) we discard the changes, try to write and switch to a different new version file with an increased revision (on failure of this too we close the database), and throw DatabaseError. Unfortunately the roll-back of state is not complete, and if switching to the different new version file succeeds that bad state persists on disk. Thanks to Uwe Kleine-König for reporting upstream and coming up with the idea to reproduce using strace to inject a rename() failure - this is a simple reproducer: rm -rf enospc.db strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db < INSTALL xapian-check enospc.db Cheers, Olly
Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1
On Sat, Jan 14, 2023 at 12:07:21AM +0100, Bastian Germann wrote: > I have just tested the patch and uploaded it as-is as NMU to DELAYED/10. Thanks for the testing. I'm not super happy that you've uploaded an NMU that appears to have been done by me though: https://ftp-master.debian.org/deferred/eviacam_2.1.4-2.1_source.changes I did provide a candidate patch, but I'm not able to provide follow up support for your NMU because eviacam doesn't even start up with the webcam I have access to. All I can do is forward any follow up I get about it to you, which just seems to be creating an unnecessary job for me. Cheers, Olly
Bug#986739: is it possible to package new upstream "snapshot" ?
Hi Jérémy, On Mon, Dec 05, 2022 at 09:31:45AM +0100, Jérémy Lal wrote: > as a Debian Games Team maintained package, I could do a team upload > very soon. Are you still intending to upload dolphin-emu? In order to be in the bookworm release it would need to reenter testing by 2023-02-12: https://release.debian.org/testing/freeze_policy.html#summary I think a package needs to actually *migrate* by that cut-off date, so the upload deadline is really 2/5/10 days earlier depending on whether there are autopkgtests, etc. Cheers, Olly
Bug#1019781: dolphin-emu: Please transition to wxwidgets3.2
On Wed, Sep 14, 2022 at 03:42:14PM -0400, s...@techie.net wrote: > Please transition dolphin-emu from wxwidgets3.0 to wxwidgets3.2. I've been looking through the handful of packages which are still using wxwidgets3.0 with an eye to seeing if any can usefully be NMUed to help them reenter testing before the release freeze. I see in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986739#5 : | (upstream switched to QT5 3 years ago) That comment is dated 2021-04-10 so it's actually more like 5 years ago now. That's long enough ago that the code is likely to need changes for wx3.2 so it seems most sensible to address this bug by packaging a recent snapshot from upstream (or convincing upstream to make a release) which would eliminate the wxwidgets dependency. Updating to newer upstream code also seems like probably it's the best way to address most of the other open RC bugs. Cheers, Olly
Bug#1019841: amule: Please transition to wxwidgets3.2
Control: tags 1019841 + patch
> tags 1019841 - patch
> # there are no traces of a patch here
I added the patch tag because Scott's most recent comment linked to
patch in a github PR.
Anyway, I've taken that patch, simplified it a bit (since we only need
to support wx3.2 here and it's easier to inspect the patch without all
the version conditionalisation), and also made it suppress wxSizerFlags
runtime checks - the patch in the PR had fixes for some instances, but
I still managed to trigger one and it seems best for our purposes to
just suppress them (which restores the situation to how it is when
built with wx3.0).
I've attached nmudiff output.
I've only tested with with networking disabled - it ideally
needs a test from someone who actually uses the package.
Cheers,
Olly
diff -Nru amule-2.3.3/debian/changelog amule-2.3.3/debian/changelog
--- amule-2.3.3/debian/changelog 2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/changelog 2023-01-09 13:00:46.0 +1300
@@ -1,3 +1,10 @@
+amule (1:2.3.3-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update to use wxwidgets3.2 - new patch wx3.2.patch; Closes: #1019841
+
+ -- Olly Betts Mon, 09 Jan 2023 13:00:46 +1300
+
amule (1:2.3.3-2) unstable; urgency=medium
* rebuild to pick up libcrypto++8; Closes: #995282, #995285
diff -Nru amule-2.3.3/debian/control amule-2.3.3/debian/control
--- amule-2.3.3/debian/control 2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/control 2023-01-09 08:59:01.0 +1300
@@ -16,8 +16,8 @@
libpng-dev,
libreadline-dev,
libupnp-dev (>= 1:1.6.24-4~),
- libwxgtk3.0-gtk3-dev,
- wx3.0-i18n,
+ libwxgtk3.2-dev,
+ wx3.2-i18n,
zlib1g-dev,
Standards-Version: 4.5.1
Homepage: http://www.amule.org
diff -Nru amule-2.3.3/debian/patches/series amule-2.3.3/debian/patches/series
--- amule-2.3.3/debian/patches/series 2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/patches/series 2023-01-09 09:02:35.0 +1300
@@ -2,3 +2,4 @@
use_xdg-open_as_preview_default.diff
version_check.diff
#libupnp1.8.patch
+wx3.2.patch
diff -Nru amule-2.3.3/debian/patches/wx3.2.patch amule-2.3.3/debian/patches/wx3.2.patch
--- amule-2.3.3/debian/patches/wx3.2.patch 1970-01-01 12:00:00.0 +1200
+++ amule-2.3.3/debian/patches/wx3.2.patch 2023-01-09 13:00:46.0 +1300
@@ -0,0 +1,461 @@
+Description: Fixes for wxWidgets 3.2 compatibility
+ Largely based on patch from Mr Hyde in
+ https://github.com/amule-project/amule/pull/168
+Author: Olly Betts
+Bug: https://github.com/amule-project/amule/issues/340
+Bug-Debian: https://bugs.debian.org/1019841
+Forwarded: no
+Last-Update: 2023-01-09
+
+--- a/src/ColorFrameCtrl.cpp
b/src/ColorFrameCtrl.cpp
+@@ -61,7 +61,7 @@
+ /
+ void CColorFrameCtrl::SetFrameBrushColour(const wxColour& colour)
+ {
+- m_brushFrame = *(wxTheBrushList->FindOrCreateBrush(colour, wxSOLID));
++ m_brushFrame = *(wxTheBrushList->FindOrCreateBrush(colour, wxBRUSHSTYLE_SOLID));
+
+ Refresh(FALSE);
+ } // SetFrameColor
+@@ -70,7 +70,7 @@
+ /
+ void CColorFrameCtrl::SetBackgroundBrushColour(const wxColour& colour)
+ {
+- m_brushBack = *(wxTheBrushList->FindOrCreateBrush(colour, wxSOLID));
++ m_brushBack = *(wxTheBrushList->FindOrCreateBrush(colour, wxBRUSHSTYLE_SOLID));
+
+ // clear out the existing garbage, re-start with a clean plot
+ Refresh(FALSE);
+--- a/src/DownloadListCtrl.cpp
b/src/DownloadListCtrl.cpp
+@@ -850,7 +850,7 @@
+ dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_HIGHLIGHTTEXT));
+ dc->SetPen( colour.Blend(65).GetPen() );
+ } else {
+- dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX), wxSOLID)));
++ dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX), wxBRUSHSTYLE_SOLID)));
+ dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT));
+ dc->SetPen(*wxTRANSPARENT_PEN);
+ }
+@@ -1413,7 +1413,7 @@
+ dc->DrawLine( rect.x, rect.y + 2, rect.x + width, rect.y + 2 );
+
+ // Draw the green line
+- dc->SetPen( *(wxThePenList->FindOrCreatePen( crProgress , 1, wxSOLID ) ));
++ dc->SetPen( *(wxThePenList->FindOrCreatePen( crProgress , 1, wxPENSTYLE_SOLID ) ));
+ dc->DrawLine( rect.x, rect.y + 1, rect.x + width, rect.y + 1 );
+ }
+ }
+--- a/src/GenericClientListCtrl.cpp
b/src/GenericClientListCtrl.cpp
+@@ -660,7 +660,7 @@
+ dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_HIGHLIGHTTEXT));
+ dc->SetPen( colour.Blend(65).GetPen() );
+ } else {
+- dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::
Bug#1019791: stimfit: diff for NMU version 0.16.0-1.2
Dear maintainer, I've prepared an NMU for stimfit (versioned as 0.16.0-1.2) and uploaded it to unstable as per the NMU guidelines in the devref: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines The package built with wxWidgets 3.2 without changes (the patch suggested in #1019791 related to sip.h inclusion doesn't apply cleanly to the version of the source in the package, but doesn't seem to be required anyway). Given I'm NMUing, it seemed best to make the minimal changes required rather than updating to the suggested tag, but maybe a maintainer should look into that. Cheers, Olly diff -Nru stimfit-0.16.0/debian/changelog stimfit-0.16.0/debian/changelog --- stimfit-0.16.0/debian/changelog 2022-03-25 08:29:58.0 +1300 +++ stimfit-0.16.0/debian/changelog 2023-01-05 10:56:35.0 +1300 @@ -1,3 +1,10 @@ +stimfit (0.16.0-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Update to wxwidgets3.2. (Closes: #1019791) + + -- Olly Betts Thu, 05 Jan 2023 10:56:35 +1300 + stimfit (0.16.0-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru stimfit-0.16.0/debian/control stimfit-0.16.0/debian/control --- stimfit-0.16.0/debian/control 2022-03-25 08:29:25.0 +1300 +++ stimfit-0.16.0/debian/control 2023-01-05 10:55:47.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Christoph Schmidt-Hieber Uploaders: Yaroslav Halchenko -Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config +Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config Standards-Version: 3.9.8 Homepage: http://www.stimfit.org
Bug#1019772: freespace2-launcher-wxlauncher: Please transition to wxwidgets3.2
Control: tags -1 + patch On Wed, Sep 14, 2022 at 03:42:14PM -0400, s...@techie.net wrote: > Please transition freespace2-launcher-wxlauncher from wxwidgets3.0 to > wxwidgets3.2. Just a friendly note to highlight that this package needs to re-enter testing to make it into bookworm, and that the release freeze cut-off for re-entering testing is 2023-02-12: https://release.debian.org/testing/freeze_policy.html#summary I think a package needs to actually *migrate* by that cut-off date, so the upload deadline is really 2/5/10 days earlier depending on whether there are autopkgtests, etc. Best to upload well before that if possible as there can be delays, especially if some other maintainers are frantically uploading to try to get in before the freeze. It looks like minor changes are required for wxwidgets3.2 compatibility and there's a patch which looks plausible submitted upstream (reviewed but not yet merged): https://github.com/scp-fs2open/wxLauncher/pull/173 Are you able to make an upload? I can try to find time to NMU, but I don't have the non-free files required to fully test this package. Cheers, Olly
Bug#1019769: opencpn: Please transition to wxwidgets3.2
Just a friendly note to highlight that opencpn needs to re-enter testing to make it into bookworm, and that the release freeze cut-off for re-entering testing is 2023-02-12: https://release.debian.org/testing/freeze_policy.html#summary I think a package needs to actually *migrate* by that cut-off date, so the upload deadline is really 2/5/10 days earlier depending on whether there are autopkgtests, etc. Best to upload well before that if possible as there can be delays, especially if some other maintainers are frantically uploading to try to get in before the freeze. On Wed, Oct 26, 2022 at 01:12:18PM +0200, Alec Leamas wrote: > Opencpn has a plugin universe. For that reason, we cannot just update the > existing version 5.6.2 to wxWidgets 3.2 since it would break the plugin ABI. > > The plan is to update the wxWidget version when packaging the upcoming > version 5.8.0. This is slated for bookworm, and should be uploaded before > Christmas. Any problems with this plan? Looking at the upstream website, it seems this release hasn't happened yet. I'm looking at NMUing the small number of packages which haven't transitioned to wx3.2 yet, but I don't think I can usefully NMU in this case due to the plugin ABI situation - that really needs a maintainer to decide what to do. Cheers, Olly
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
On Wed, Dec 28, 2022 at 12:55:20PM -0500, Scott Talbert wrote: > On Tue, 27 Dec 2022, Chow Loong Jin wrote: > > Alright, I'll leave the slic3r-prusa as-is then. I'm guessing that a > > binNMU will take care of things when we get there. > > wxwidgets3.2 has been rebuilt in unstable with EGL support disabled. The > release team skipped the binNMU of slic3r-prusa due to bug #1025827. If you > upload the (already merged) fix for that bug, that should take care of this > rebuild for slic3r-prusa too. Just a friendly note to highlight that slic3r-prusa needs an upload to re-enter testing, and the release freeze cut-off for re-entering testing is 2023-02-12: https://release.debian.org/testing/freeze_policy.html#summary I think a package needs to actually *migrate* by that cut-off date, so the upload deadline is really 2/5/10 days earlier depending on whether there are autopkgtests, etc. Best to upload well before that if possible as there can be delays, especially if some other maintainers are frantically uploading to try to get in before the freeze. The blockers on the wx3.2 side should now be resolved, but the FTBFS in #1025827 needs fixing. A fix for that seems to have already been merged to the git repo, so this just needs an upload. A maintainer upload would be best as there's nothing specific to wxwidgets3.2 to do. Cheers, Olly
Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1
On Wed, Nov 09, 2022 at 11:44:29PM +, Olly Betts wrote: > On Wed, Nov 09, 2022 at 04:49:33PM +0100, Cesar Mauri wrote: > > I've just merged a PR that add support for OpenCV 4.6.0 and (hopefully) > > fixes the camera error > > > > https://github.com/cmauri/eviacam/tree/master > > Great. Will there be a new upstream release soon? Just a friendly note to highlight that eviacam needs updating to wxwidgets3.2 to re-enter testing, and the release freeze cut-off for re-entering testing is 2023-02-12: https://release.debian.org/testing/freeze_policy.html#summary I think a package needs to actually *migrate* by that cut-off date, so the upload deadline is really 2/5/10 days earlier depending on whether there are autopkgtests, etc. Best to upload well before that if possible as there can be delays, especially if some other maintainers are frantically uploading to try to get in before the freeze. I can't test the patch I attached earlier due to the other bug. If that bug is specific to some webcams/systems I could NMU the patch without testing if you think that's useful (let me know). I'm hesitant to try applying the PR too as I'm not at all familiar with this package, - it seems better for the maintainer to do that. Cheers, Olly
Bug#1019837: treesheets: diff for NMU version 1:1.0.2-1.1
Control: tags 1019837 + patch Dear maintainer, I've prepared an NMU for treesheets (versioned as 1:1.0.2-1.1) and uploaded it to unstable as per the NMU guidelines in the devref: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines The package built with wxWidgets 3.2 without changes, and seems to run without problems (I worked through the tutorial it loads by default, and tried to exercise various windows from the menus). I'll open an MR on salsa with the changes too. Cheers, Olly diff -Nru treesheets-1.0.2/debian/changelog treesheets-1.0.2/debian/changelog --- treesheets-1.0.2/debian/changelog 2019-12-01 10:56:34.0 +1300 +++ treesheets-1.0.2/debian/changelog 2023-01-05 06:46:35.0 +1300 @@ -1,3 +1,10 @@ +treesheets (1:1.0.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Update to use wxwidgets3.2. (Closes: #1019837) + + -- Olly Betts Thu, 05 Jan 2023 06:46:35 +1300 + treesheets (1:1.0.2-1) unstable; urgency=medium * New upstream release. diff -Nru treesheets-1.0.2/debian/control treesheets-1.0.2/debian/control --- treesheets-1.0.2/debian/control 2019-12-01 05:24:15.0 +1300 +++ treesheets-1.0.2/debian/control 2023-01-05 06:46:21.0 +1300 @@ -4,8 +4,7 @@ Maintainer: Ximin Luo Build-Depends: debhelper (>= 9), cmake, - libwxgtk3.0-gtk3-dev, - wx3.0-headers, + libwxgtk3.2-dev, imagemagick Standards-Version: 4.3.0 Homepage: http://strlen.com/treesheets/
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
On Wed, Dec 21, 2022 at 11:21:03AM +0800, Chow Loong Jin wrote: > I've fixed the segfault by applying the patch from [1], but there's one > issue remaining -- PrusaSlicer fails to initialize GLEW due to [2], > resulting in the plater screen not showing up, same as this SuperSlicer > issue[3]. > > I've also attempted to roll PrusaSlicer back to wxwidgets3.0 Please don't do that. We're really close to eliminating wxwidgets3.0 now, and we're not planning to include it in the bookworm release. We're going to switch to --disable-glcanvasegl in wxwidgets3.2 which should solve the incompatibilities with GLEW which seem to be the problem here. However that's an ABI breaking change affecting any packages using wxwidgets3.2's OpenGL APIs so it needs coordinating with the release team - Scott is currently working on that. Cheers, Olly
Bug#1019808: marked as pending in openbabel
On Thu, Oct 27, 2022 at 09:07:42AM +, Andrius Merkys wrote: > Control: tag -1 pending > > Hello, > > Bug #1019808 in openbabel reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/debichem-team/openbabel/-/commit/9a875ec27408d6d399f0e69b20fd8f019eed646e This transition is now down to just 3 packages needing updating (one of which accidentally got uploaded over the weekend based on a pre-transition version so we should be down to 2 packages soon). This bug has been tagged as "pending" for over a month now - please could a maintainer make an upload of openbabel soon? Or if there's a problem with the update then please update this bug so we know what the status is. Cheers, Olly
Bug#1019810: golly: diff for NMU version 3.3-1.1
Control: tags 1019810 + patch Dear maintainer, I've prepared an NMU for golly (versioned as 3.3-1.1) and uploaded it to unstable as per the NMU guidelines in the devref: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines The package built with wxWidgets 3.2 without changes, and seems to run without problems (I tried to exercise all the windows and dialogs I could find). Cheers, Olly diff -Nru golly-3.3/debian/changelog golly-3.3/debian/changelog --- golly-3.3/debian/changelog 2019-12-02 13:40:25.0 +1300 +++ golly-3.3/debian/changelog 2022-11-26 08:12:59.0 +1300 @@ -1,3 +1,11 @@ +golly (3.3-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Switch to use wxwidgets3.2 (Closes: #1019810) + * Drop patch 0005-wxwidgets-inmature-yet.patch which is no longer required. + + -- Olly Betts Sat, 26 Nov 2022 08:12:59 +1300 + golly (3.3-1) unstable; urgency=medium * New upstream. diff -Nru golly-3.3/debian/control golly-3.3/debian/control --- golly-3.3/debian/control 2019-12-02 13:40:25.0 +1300 +++ golly-3.3/debian/control 2022-11-26 07:12:30.0 +1300 @@ -2,8 +2,7 @@ Section: games Priority: optional Maintainer: NIIBE Yutaka -Build-Conflicts: libwxgtk2.6-dev -Build-Depends: debhelper-compat (= 12), libwxgtk3.0-gtk3-dev, perl, libperl-dev, zlib1g-dev, dh-lua +Build-Depends: debhelper-compat (= 12), libwxgtk3.2-dev, perl, libperl-dev, zlib1g-dev, dh-lua Standards-Version: 4.4.1 Homepage: http://golly.sourceforge.net/ Vcs-Git: https://salsa.debian.org/debian/golly.git diff -Nru golly-3.3/debian/patches/0005-wxwidgets-inmature-yet.patch golly-3.3/debian/patches/0005-wxwidgets-inmature-yet.patch --- golly-3.3/debian/patches/0005-wxwidgets-inmature-yet.patch 2019-12-02 13:40:25.0 +1300 +++ golly-3.3/debian/patches/0005-wxwidgets-inmature-yet.patch 1970-01-01 12:00:00.0 +1200 @@ -1,21 +0,0 @@ -Description: Add -D__WX_GTK20__ until wxWidgets will be fixed -Author: NIIBE Yutaka -Last-Update: 2019-12-02 - -Index: golly/gui-wx/configure/m4/wxwin.m4 -=== golly.orig/gui-wx/configure/m4/wxwin.m4 -+++ golly/gui-wx/configure/m4/wxwin.m4 -@@ -295,9 +295,9 @@ AC_DEFUN([WX_CONFIG_CHECK], - WX_CXXFLAGS_ONLY=$WX_CFLAGS - else - dnl we have CPPFLAGS included in CFLAGS included in CXXFLAGS -- WX_CPPFLAGS=`$WX_CONFIG_WITH_ARGS --cppflags $4` -- WX_CXXFLAGS=`$WX_CONFIG_WITH_ARGS --cxxflags $4` -- WX_CFLAGS=`$WX_CONFIG_WITH_ARGS --cflags $4` -+ WX_CPPFLAGS="`$WX_CONFIG_WITH_ARGS --cppflags $4` -D__WXGTK20__" -+ WX_CXXFLAGS="`$WX_CONFIG_WITH_ARGS --cxxflags $4` -D__WXGTK20__" -+ WX_CFLAGS="`$WX_CONFIG_WITH_ARGS --cflags $4` -D__WXGTK20__" - - WX_CFLAGS_ONLY=`echo $WX_CFLAGS | sed "s@^$WX_CPPFLAGS *@@"` - WX_CXXFLAGS_ONLY=`echo $WX_CXXFLAGS | sed "s@^$WX_CFLAGS *@@"` diff -Nru golly-3.3/debian/patches/series golly-3.3/debian/patches/series --- golly-3.3/debian/patches/series 2019-12-02 13:40:25.0 +1300 +++ golly-3.3/debian/patches/series 2022-11-26 07:15:15.0 +1300 @@ -1,5 +1,4 @@ 0001-Build-Add-libs.patch 0002-dont-include-tilda-files.patch # 0003-automake-subdir-obj.patch -0005-wxwidgets-inmature-yet.patch 0006-python2-support-removal.patch
Bug#1019830: codeblocks: Please transition to wxwidgets3.2
On Fri, Nov 18, 2022 at 11:06:07AM +0800, Bo YU wrote: > On Fri, Nov 18, 2022 at 3:34 AM Olly Betts wrote: > > Looking at upstream's SVN history I can see changes for wx3.2 > > compatibility so it looks like they're on top of this. > > > > Therefore I'd suggest trying an upstream SVN snapshot rather than > > wasting energy trying to address issues upstream have likely already > > been solved. > > Sorry, I forget to update here. I have feedbacked this to upstream: > https://forums.codeblocks.org/index.php/topic,25076.0.html (reply #10) Thanks. Upstream says there: | I suggest you to pick the current trunk code (r13000), it is not a | release but it is more stable than 20.03 So they're explicitly saying that r13000 is a better option than what's currently in testing and unstable. > Maybe the upstream will release stable version before sid freeze, so we can > wait some time to see what happens. The problem with waiting until shortly before the freeze to update a package to use wxwidgets3.2 is that we get very little time to address any problems that crop up from the transition, so it's really much better to update earlier - in this case to r13000. If upstream make a release before the freeze it should be an easy update from r13000 to that; if they don't then we release with r13000, which is better than 20.03 anyway. Cheers, Olly
Bug#1019830: codeblocks: Please transition to wxwidgets3.2
On Sun, Oct 30, 2022 at 03:52:13PM +0800, Bo YU wrote: > I have tried to build the package with libwxgtk3.2-dev, but > unfortunately, it fails: [snip] > Could you help to have a look? Looking at upstream's SVN history I can see changes for wx3.2 compatibility so it looks like they're on top of this. Therefore I'd suggest trying an upstream SVN snapshot rather than wasting energy trying to address issues upstream have likely already been solved. Cheers, Olly
Bug#1019776: openmsx-catapult: diff for NMU version 18.0-2.1
Control: tags 1019776 + patch Dear maintainer, I've prepared an NMU for openmsx-catapult (versioned as 18.0-2.1) and uploaded it to unstable as per the NMU guidelines in the devref: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines The patch for wxWidgets 3.2 compatibility was cherry-picked from upstream. Cheers, Olly diff -Nru openmsx-catapult-18.0/debian/changelog openmsx-catapult-18.0/debian/changelog --- openmsx-catapult-18.0/debian/changelog 2022-10-12 05:11:57.0 +1300 +++ openmsx-catapult-18.0/debian/changelog 2022-11-10 15:40:43.0 +1300 @@ -1,3 +1,11 @@ +openmsx-catapult (18.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Update to build with wxwidgets-3.2 (new patch +wx3.2-compat.patch) (Closes: #1019776) + + -- Olly Betts Thu, 10 Nov 2022 15:40:43 +1300 + openmsx-catapult (18.0-2) unstable; urgency=medium * Mark test as flaky. Closes: #1020832, #1020833 diff -Nru openmsx-catapult-18.0/debian/control openmsx-catapult-18.0/debian/control --- openmsx-catapult-18.0/debian/control 2022-06-14 07:40:20.0 +1200 +++ openmsx-catapult-18.0/debian/control 2022-11-10 15:40:02.0 +1300 @@ -2,7 +2,7 @@ Section: otherosfs Priority: optional Maintainer: Bas Wijnen -Build-Depends: debhelper (>= 10), docbook-to-man, libwxgtk3.0-gtk3-dev, libxml2-dev, python3 +Build-Depends: debhelper (>= 10), docbook-to-man, libwxgtk3.2-dev, libxml2-dev, python3 Standards-Version: 4.6.1 Homepage: http://openmsx.org diff -Nru openmsx-catapult-18.0/debian/patches/series openmsx-catapult-18.0/debian/patches/series --- openmsx-catapult-18.0/debian/patches/series 2020-08-13 01:11:17.0 +1200 +++ openmsx-catapult-18.0/debian/patches/series 2022-11-10 15:40:43.0 +1300 @@ -1,3 +1,4 @@ hardening buildflags desktop-file +wx3.2-compat.patch diff -Nru openmsx-catapult-18.0/debian/patches/wx3.2-compat.patch openmsx-catapult-18.0/debian/patches/wx3.2-compat.patch --- openmsx-catapult-18.0/debian/patches/wx3.2-compat.patch 1970-01-01 12:00:00.0 +1200 +++ openmsx-catapult-18.0/debian/patches/wx3.2-compat.patch 2022-11-10 15:40:43.0 +1300 @@ -0,0 +1,469 @@ +Description: Fixes for compatibility with wxWidgets 3.2 +Author: Olly Betts +Bug-Debian: https://bugs.debian.org/1019776 +Forwarded: https://github.com/openMSX/wxcatapult/pull/44 +Last-Update: 2022-11-10 + +diff --git a/dialogs/about.wxg b/dialogs/about.wxg +index 90a7688..a99a8d5 100644 +--- a/dialogs/about.wxg b/dialogs/about.wxg +@@ -30,7 +30,6 @@ + + wxHORIZONTAL + +-wxALIGN_CENTER_HORIZONTAL + 0 + 1 + +@@ -55,7 +54,6 @@ + + wxHORIZONTAL + +-wxALIGN_CENTER_HORIZONTAL + 0 + 1 + +@@ -80,7 +78,6 @@ + + wxHORIZONTAL + +-wxALIGN_CENTER_HORIZONTAL + 0 + 2 + +diff --git a/dialogs/audiocontrols.wxg b/dialogs/audiocontrols.wxg +index 92386fd..929cf13 100644 +--- a/dialogs/audiocontrols.wxg b/dialogs/audiocontrols.wxg +@@ -14,7 +14,7 @@ + wxVERTICAL + Mixer + +-wxEXPAND|wxALIGN_CENTER_HORIZONTAL|wxALIGN_CENTER_VERTICAL ++wxEXPAND + 0 + 1 + +@@ -22,7 +22,7 @@ + + wxHORIZONTAL + +-wxALIGN_CENTER_HORIZONTAL|wxALIGN_CENTER_VERTICAL ++wxALIGN_CENTER_VERTICAL + 0 + 1 + +@@ -58,7 +58,7 @@ + + wxVERTICAL + +-wxLEFT|wxRIGHT|wxALIGN_CENTER_VERTICAL ++wxLEFT|wxRIGHT + 5 + 1 + +@@ -68,7 +68,7 @@ + + + +-wxLEFT|wxRIGHT|wxALIGN_CENTER_VERTICAL ++wxLEFT|wxRIGHT + 5 + 1 + +@@ -78,7
Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1
On Wed, Nov 09, 2022 at 04:49:33PM +0100, Cesar Mauri wrote: > I've just merged a PR that add support for OpenCV 4.6.0 and (hopefully) > fixes the camera error > > https://github.com/cmauri/eviacam/tree/master Great. Will there be a new upstream release soon? Cheers, Olly
Bug#1019806: marked as pending in sooperlooper
On Tue, Sep 20, 2022 at 09:18:52PM +, Dennis Braun wrote: > Control: tag -1 pending > > Hello, > > Bug #1019806 in sooperlooper reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/multimedia-team/sooperlooper/-/commit/f8994f33f1dbfae2d7f4820f7c35af60b14501db > > > Transition to wxWidgets 3.2 (Closes: #1019806) > This was tagged "pending" 7 weeks ago, but hasn't been uploaded yet. Could one of the maintainers please make an upload soon? I see recent uploads were sponsored - if lack of a sponsor is the blocker I can sponsor. Cheers, Olly
Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1
Control: tags 1019790 + patch
Dear maintainer,
I've managed to build eviacam using wxwidgets3.2 with a couple of minor
changes (patch attached).
However I can't test my patched build because eviacam doesn't start
(I'm guessing it doesn't like my webcam for some reason) - starting it I
get:
$ eviacam
[ERROR:0@0.016] global ./modules/core/src/persistence.cpp (505) open Can't open
file: '/usr/share/eviacam/haarcascade_frontalface_default.xml' in read mode
[ERROR:0@0.017] global ./modules/core/src/persistence.cpp (505) open Can't open
file: '/usr/share/opencv/haarcascades/haarcascade_frontalface_default.xml' in
read mode
[ERROR:0@0.017] global ./modules/core/src/persistence.cpp (505) open Can't open
file: '/usr/share/OpenCV/haarcascades/haarcascade_frontalface_default.xml' in
read mode
[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, name =
'User Controls', type = 6
[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id =
0x00980001, name = 'User Controls'
[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x009A0001, name =
'Camera Controls', type = 6
[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id =
0x009A0001, name = 'Camera Controls'
(eviacam:184091): Gtk-CRITICAL **: 10:24:53.628: gtk_box_gadget_distribute:
assertion 'size >= 0' failed in GtkScrollbar
[ WARN:0@3.768] global ./modules/videoio/src/videoio_c.cpp (15)
cvCreateCameraCapture cvCreateCameraCapture doesn't support legacy API anymore.
$
I also get the same error for the version already in unstable.
Please can you test with my patch, and upload if it works.
Cheers,
Olly
diff -Nru eviacam-2.1.4/debian/changelog eviacam-2.1.4/debian/changelog
--- eviacam-2.1.4/debian/changelog 2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/changelog 2022-11-09 10:14:08.0 +1300
@@ -1,3 +1,11 @@
+eviacam (2.1.4-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/control: Update to build with wxwidgets-3.2 (new patch
+wx3.2-compat.patch) (Closes: #1019790)
+
+ -- Olly Betts Wed, 09 Nov 2022 10:14:08 +1300
+
eviacam (2.1.4-2) unstable; urgency=medium
* Team upload
diff -Nru eviacam-2.1.4/debian/control eviacam-2.1.4/debian/control
--- eviacam-2.1.4/debian/control 2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/control 2022-11-09 10:05:50.0 +1300
@@ -7,7 +7,7 @@
libopencv-dev (>= 2.0),
libpng-dev,
libv4l-dev,
- libwxgtk3.0-gtk3-dev,
+ libwxgtk3.2-dev,
libgtk-3-dev,
libxext-dev,
libxtst-dev,
diff -Nru eviacam-2.1.4/debian/patches/series eviacam-2.1.4/debian/patches/series
--- eviacam-2.1.4/debian/patches/series 2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/patches/series 2022-11-09 10:14:08.0 +1300
@@ -1 +1,2 @@
new-opencv.patch
+wx3.2-compat.patch
diff -Nru eviacam-2.1.4/debian/patches/wx3.2-compat.patch eviacam-2.1.4/debian/patches/wx3.2-compat.patch
--- eviacam-2.1.4/debian/patches/wx3.2-compat.patch 1970-01-01 12:00:00.0 +1200
+++ eviacam-2.1.4/debian/patches/wx3.2-compat.patch 2022-11-09 10:14:08.0 +1300
@@ -0,0 +1,29 @@
+Description: Fixes for compatibility with wxWidgets 3.2
+Author: Olly Betts
+Bug-Debian: https://bugs.debian.org/1019790
+Forwarded: no
+Last-Update: 2022-11-08
+
+--- a/src/wviacam.cpp
b/src/wviacam.cpp
+@@ -598,7 +598,8 @@
+ case (wxLANGUAGE_SPANISH_GUATEMALA):
+ case (wxLANGUAGE_SPANISH_HONDURAS):
+ case (wxLANGUAGE_SPANISH_MEXICAN):
+- case (wxLANGUAGE_SPANISH_MODERN):
++ // Same value as wxLANGUAGE_SPANISH in wx3.2:
++ // case (wxLANGUAGE_SPANISH_MODERN):
+ case (wxLANGUAGE_SPANISH_NICARAGUA):
+ case (wxLANGUAGE_SPANISH_PANAMA):
+ case (wxLANGUAGE_SPANISH_PARAGUAY):
+--- a/src/viacamcontroller.cpp
b/src/viacamcontroller.cpp
+@@ -230,7 +230,7 @@
+
+ wxSingleChoiceDialog choiceDlg(
+ NULL, _("Choose the camera to use"), _T("Enable Viacam"), strArray,
+-(char**)NULL, wxDEFAULT_DIALOG_STYLE | wxOK | wxCANCEL | wxCENTRE);
++(void**)NULL, wxDEFAULT_DIALOG_STYLE | wxOK | wxCANCEL | wxCENTRE);
+
+ if (choiceDlg.ShowModal ()!= wxID_OK) return NULL;
+
Bug#1019829: pgn2web: diff for NMU version 0.4-3.1
Control: tags 1019829 + patch Dear maintainer, I've prepared an NMU for pgn2web (versioned as 0.4-3.1) and uploaded it to unstable as per the NMU guidelines in the devref: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines Cheers, Olly diff -Nru pgn2web-0.4/debian/changelog pgn2web-0.4/debian/changelog --- pgn2web-0.4/debian/changelog 2019-10-17 08:13:27.0 +1300 +++ pgn2web-0.4/debian/changelog 2022-11-07 12:06:09.0 +1300 @@ -1,3 +1,11 @@ +pgn2web (0.4-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Update to build with wxwidgets-3.2 (new patch +wx3.2-compat.patch) (Closes: #1019829) + + -- Olly Betts Mon, 07 Nov 2022 12:06:09 +1300 + pgn2web (0.4-3) unstable; urgency=medium * debian/control: diff -Nru pgn2web-0.4/debian/control pgn2web-0.4/debian/control --- pgn2web-0.4/debian/control 2019-10-17 08:13:27.0 +1300 +++ pgn2web-0.4/debian/control 2022-11-07 11:58:56.0 +1300 @@ -2,7 +2,7 @@ Section: web Priority: optional Maintainer: Jose G. López -Build-Depends: debhelper-compat (= 12), libwxgtk3.0-gtk3-dev +Build-Depends: debhelper-compat (= 12), libwxgtk3.2-dev Standards-Version: 4.4.1 Rules-Requires-Root: no Homepage: http://sourceforge.net/projects/pgn2web/ diff -Nru pgn2web-0.4/debian/patches/series pgn2web-0.4/debian/patches/series --- pgn2web-0.4/debian/patches/series 2019-10-17 08:13:27.0 +1300 +++ pgn2web-0.4/debian/patches/series 2022-11-07 12:05:17.0 +1300 @@ -2,3 +2,4 @@ makefile.patch install-location.patch wx3.0-compat.patch +wx3.2-compat.patch diff -Nru pgn2web-0.4/debian/patches/wx3.2-compat.patch pgn2web-0.4/debian/patches/wx3.2-compat.patch --- pgn2web-0.4/debian/patches/wx3.2-compat.patch 1970-01-01 12:00:00.0 +1200 +++ pgn2web-0.4/debian/patches/wx3.2-compat.patch 2022-11-07 12:06:04.0 +1300 @@ -0,0 +1,17 @@ +Description: Fixes for compatibility with wxWidgets 3.2 +Author: Olly Betts +Bug-Debian: https://bugs.debian.org/1019829 +Forwarded: no +Last-Update: 2022-11-06 + +--- pgn2web-0.4.orig/gui.cpp pgn2web-0.4/gui.cpp +@@ -367,7 +367,7 @@ void p2wFrame::do_layout() + buttonsSizer->Add(convertButton, 0, wxALL, 5); + buttonsSizer->Add(quitButton, 0, wxALL, 5); + rootSizer->Add(buttonsSizer, 0, +- wxLEFT|wxRIGHT|wxBOTTOM|wxALIGN_CENTER_HORIZONTAL|wxADJUST_MINSIZE, 5); ++ wxLEFT|wxRIGHT|wxBOTTOM|wxALIGN_CENTER_HORIZONTAL, 5); + rootPanel->SetAutoLayout(true); + rootPanel->SetSizer(rootSizer); + panelSizer->Add(rootPanel, 1, wxEXPAND, 0);
Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers
severity 1019833 serious thanks (I raised the severity of most of these yesterday, but missed packages where an upload to experimental has closed the bug while it's not yet fixed in unstable.) Accounting for packages which are fixed in experimental or in git we're now under 30 packages left to do, so raising the severity to "serious". Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Please start to investigate making this transition if you haven't already. In most cases it's proving to be an easy update, but in minority of cases where there are obstacles it's much better to find that out sooner rather than later. Cheers, Olly
Bug#1022739: wxwidgets3.0: Do not release with bookworm
Source: wxwidgets3.0 Version: 3.0.5.1+dfsg-5 Severity: serious Justification: Opinion of package maintainer We have packages of wxwidgets3.2 in unstable and testing, and a transition is well under way: https://release.debian.org/transitions/html/wxwidgets-3.2.html The last upstream release of wxwidgets3.0 was 2½ years ago, and there's very little upstream interest in bugs in it now. Keeping wxwidgets3.0 for another release cycle without upstream support doesn't seem a good idea, so opening an RC bug. Cheers, Olly
Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers
severity 1019823 serious severity 1019775 serious severity 1019768 serious severity 1019812 serious severity 1019835 serious severity 1019769 serious severity 1019799 serious severity 1019827 serious severity 1019808 serious severity 1019830 serious severity 1019762 serious severity 1019829 serious severity 1019791 serious severity 1019818 serious severity 1019792 serious severity 1019776 serious severity 1019784 serious severity 1019828 serious severity 1019819 serious severity 1019804 serious severity 1019814 serious severity 1019805 serious severity 1019841 serious severity 1019772 serious severity 1019790 serious severity 1019824 serious severity 1019773 serious severity 1019783 serious severity 1019806 serious severity 1019839 serious severity 1019765 serious severity 1019837 serious severity 1019810 serious severity 1019782 serious severity 1019781 serious severity 1019779 serious thanks Accounting for packages which are fixed in experimental or in git we're now under 30 packages left to do, so raising the severity to "serious". Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Please start to investigate making this transition if you haven't already. In most cases it's proving to be an easy update, but in minority of cases where there are obstacles it's much better to find that out sooner rather than later. Cheers, Olly
Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable
On Wed, Oct 12, 2022 at 10:40:29PM +0200, László Böszörményi (GCS) wrote: > On Wed, Oct 12, 2022 at 10:36 PM Olly Betts wrote: > > On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote: > > > The following packages have unmet dependencies: > > > libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is > > > to be installed > > > E: Unable to correct problems, you have held broken packages > > > > The problem here is due to this in debian/control in the source package: > [...] > > (We've also resolved the only such package in Debian already, but this > > may be relevant for downstream distros such as Ubuntu if they have > > packages we don't.) > [...] > > Happy to NMU a fix for this. > Thanks, but libwxsqlite3-3.0-dev is about to stay for a little > longer. Then a fixed package is already uploaded and waiting to be > accepted. I see, but that's really not the right fix. We went through this last time too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741730;msg=79 Cheers, Olly
Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable
title -1 libwxsqlite3-3.0-dev: not coinstallable
On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote:
> The following packages have unmet dependencies:
> libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is to
> be installed
> E: Unable to correct problems, you have held broken packages
The problem here is due to this in debian/control in the source package:
Package: libwxsqlite3-3.0-dev
Depends: ${misc:Depends}, libwxsqlite3-3.2-dev
Architecture: all
Priority: optional
Section: oldlibs
Description: transitional package
This is a transitional package. It can safely be removed.
Package: libwxsqlite3-3.2-dev
Architecture: any
Multi-Arch: same
Section: libdevel
Depends:
libsqlite3-dev,
libwxgtk3.2-dev,
libwxsqlite3-3.2-0 (= ${binary:Version}),
${misc:Depends}
Recommends:
pkg-config
Suggests:
wxsqlite3-doc
Breaks: libwxsqlite3-3.0-dev
Replaces: libwxsqlite3-3.0-dev
Description: Development files for wxSQLite3
wxSQLite3 is a C++ wrapper around the public domain SQLite 3.x database
and is specifically designed for use in programs based on the wxWidgets
3.0 library.
.
This package contains the development files for wxSQLite3.
It isn't useful to have a transitional package for libwxsqlite3-3.0-dev
which pulls in libwxsqlite3-3.2-dev - anything which BDs on
libwxsqlite3-3.0-dev will need a source-ful upload to bump it's
wxwidgets build dependencies (typically libwxgtk3.0-gtk3-dev to
libwxgtk3.2-dev).
A package which B-Ds on libwxsqlite3-3.0-dev and libwxgtk3.0-gtk3-dev
but pulls in libwxsqlite3-3.2-dev and libwxgtk3.0-gtk3-dev won't build
(or at least not correctly).
(We've also resolved the only such package in Debian already, but this
may be relevant for downstream distros such as Ubuntu if they have
packages we don't.)
Also, it's not helpful for libwxsqlite3-3.2-dev to break and replace
libwxsqlite3-3.0-dev unless libwxsqlite3-3.2-dev and the
libwxsqlite3-3.0-dev currently in testing genuinely aren't
co-installable. The lists of installed files don't overlap at least:
https://packages.debian.org/bookworm/amd64/libwxsqlite3-3.0-dev/filelist
https://packages.debian.org/sid/amd64/libwxsqlite3-3.2-dev/filelist
So I think the solution here is to drop the "Package:
libwxsqlite3-3.0-dev" paragraph entirely and drop these from
libwxsqlite3-3.2-dev:
Breaks: libwxsqlite3-3.0-dev
Replaces: libwxsqlite3-3.0-dev
Happy to NMU a fix for this.
Cheers,
Olly
Bug#1019801: xmlcopyeditor: Please transition to wxwidgets3.2
Control: reopen -1 Control: found -1 1.3.0.0-1 Control: severity -1 important Resent to not -maintonly. Thanks, but I don't think that was the problem - rather I'd used the control@bugs.d.o syntax but hadn't Cc-ed control@. I'm not sure control@ actually supports -1 for the bug number in this context though (it seems it would have to infer it by looking for NNN@bugs.d.o in To: or CC:) so I probably was trying for "Control:" pseudo-headers as above. Cheers, Olly
Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support
On Sat, Sep 24, 2022 at 09:50:10PM +0100, Olly Betts wrote: > On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote: > > wxwidgets and glew disagree over EGL support, glew is built without, > > wxwidgets (since 3.2) with. > > > > That causes problems (crashes, "Unable to init glew library") in > > software using glew and wxwidgets. Google finds multiple instances, I > > know about hugin. FWIW, these are the packages which seem to depend on both wx and glew (just based on checking dependencies): hugin megaglest qutemol scorched3d darkradiant limesuite The last two have already switched to wx3.2 in unstable and testing, but I don't see reports in the BTS of glew-related problems, and didn't see any issues from a quick test myself. At least with darkradiant I did get what looked like a GL rendered pane to appear - I'm not sure I actually exercised any GL code with limesuite (it seems to need some hardware I don't have to be useful). Cheers, Olly
Bug#1019786: closed by Debian FTP Masters (reply to Laszlo Boszormenyi (GCS) ) (Bug#1019786: fixed in wxsqlite3 3.4.1~dfsg-6)
Control: reopen -1 Control: notfixed -1 3.4.1~dfsg-6 Control: found -1 3.4.1~dfsg-6 On Sat, Sep 24, 2022 at 10:53:31PM +0200, László Böszörményi (GCS) wrote: > On Mon, Sep 19, 2022 at 7:48 AM Olly Betts wrote: > > It appears that there's now only a single reverse dependency, codelite, > > which is orphaned so I've updated it and uploaded to experimental too. > > Please take care of it for Sid as well. Done. However, the updated wxsqlite3 source package still has a build-dependency on libwxgtk3.0-gtk3-dev: Build-Depends: debhelper-compat (= 13), doxygen, libsqlite3-dev (>= 3.15), libwxgtk3.2-dev, libwxgtk3.0-gtk3-dev You're meant to replace the dependency on the old version, not update to depend on both old and new! You should be able to just drop the old B-D. This will block the wxwidgets-3.2 transition, so reopening. Cheers, Olly
Bug#1019786: closed by Debian FTP Masters (reply to Laszlo Boszormenyi (GCS) ) (Bug#1019786: fixed in wxsqlite3 3.4.1~dfsg-6)
On Sat, Sep 24, 2022 at 10:53:31PM +0200, László Böszörményi (GCS) wrote: > On Mon, Sep 19, 2022 at 7:48 AM Olly Betts wrote: > > > wxsqlite3 (3.4.1~dfsg-6) experimental; urgency=medium > [...] > > Thanks for the upload to experimental. > Recently I uploaded it to Sid. Great. > > It appears that there's now only a single reverse dependency, codelite, > > which is orphaned so I've updated it and uploaded to experimental too. > Please take care of it for Sid as well. Your upload doesn't seem to have reached the mirrors yet, but I will do once I can build against it. Cheers, Olly
Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support
On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote: > wxwidgets and glew disagree over EGL support, glew is built without, > wxwidgets (since 3.2) with. > > That causes problems (crashes, "Unable to init glew library") in > software using glew and wxwidgets. Google finds multiple instances, I > know about hugin. > > While I have submitted this against glew and Cc'd wxwidgets maintainers > I do not know whether the proper solution is for building glew with EGL > or for building wxwidgets with --disable-glcanvasegl. AIUI, wxWidgets needs EGL for wxGLCanvas to work under Wayland. With 3.0, we had a hack in place to force use of X11 if the wx GL library was loaded: https://sources.debian.org/src/wxwidgets3.0/3.0.5.1%2Bdfsg-5/debian/patches/force-x11-for-wxgl.patch/ That was better than not working, but doesn't seem a desirable long term solution. Cheers, Olly
Bug#1020546: lintian: spelling-error-in-binary moans about valid HTML entity name (curren)
Package: lintian Version: 2.115.3 Severity: normal I get: I: xapian-omega: spelling-error-in-binary curren current [usr/bin/omindex] That's not a spelling error though, it's from a list of HTML entity names ( is "¤"): https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references I'd suggest removing "curren" from the list. Cheers, Olly -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.38.90.20220713-2 ii bzip2 1.0.8-5+b1 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-9 ii gpg 2.2.39-1 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.11.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-4 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.32-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.05-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.124-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.001+ds-1 ii libsereal-encoder-perl 5.001+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-2 ii libtext-levenshteinxs-perl 0.03-5 ii libtext-markdown-discount-perl 0.13-1+b1 ii libtext-xslate-perl 3.5.9-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-2 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b3 ii liburi-perl 5.12-1 ii libwww-mechanize-perl 2.15-1 ii libwww-perl 6.67-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1 ii libyaml-libyaml-perl0.84+ds-1 ii lzip [lzip-decompressor]1.23-4 ii lzop1.04-2 ii man-db 2.10.2-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.34.0-5 ii t1utils 1.41-4 ii unzip 6.0-27 ii xz-utils5.2.5-2.1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.38.90.20220713-2 ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1020539: xmlcopyeditor: xml copyeditor fails wxwidgets3.2 sizer checks
Package: xmlcopyeditor Version: 1.2.1.3-4.3 Severity: serious Justification: makes the package in question unusable or mostly so X-Debbugs-Cc: s...@techie.net Since the update to use wxwidgets3.2, xmlcopyeditor pops up "An assertion failed!" dialogs on startup, with similar messages on stderr: $ xmlcopyeditor ./src/common/sizer.cpp(2258): assert "CheckSizerFlags(!((flags) & (wxALIGN_CENTRE_VERTICAL)))" failed in DoInsert(): wxALIGN_CENTRE_VERTICAL will be ignored in this sizer: only horizontal alignment flags can be used in vertical sizers DO NOT PANIC !! If you're an end user running a program not developed by you, please ignore this message, it is harmless, and please try reporting the problem to the program developers. You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to suppress all such checks when running this program. If you're the developer, simply remove this flag from your code to avoid getting this message. You can also call wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, but this is strongly not recommended. This is because wx3.2 added consistency checks to sizer flag use and moans when there are flags which don't make sense (which previously were quietly ignored). There seem to be two assertions that fail. This fixes one of them: diff -ru ../xmlcopyeditor-1.2.1.3/src/commandpanel.cpp xmlcopyeditor-1.2.1.3/src/commandpanel.cpp --- ../xmlcopyeditor-1.2.1.3/src/commandpanel.cpp 2014-09-06 13:54:53.0 +1200 +++ xmlcopyeditor-1.2.1.3/src/commandpanel.cpp 2022-09-21 16:23:36.927423010 +1200 @@ -135,7 +135,7 @@ bottomSizer->Add ( outputSizer, 0, wxLEFT | wxRIGHT | wxALIGN_CENTER_VERTICAL, sizerOffset ); mainSizer = new wxBoxSizer ( wxVERTICAL ); - mainSizer->Add ( commandEdit, 0, wxLEFT | wxRIGHT | wxALIGN_CENTER_VERTICAL | wxEXPAND, sizerOffset ); + mainSizer->Add ( commandEdit, 0, wxLEFT | wxRIGHT | wxEXPAND, sizerOffset ); mainSizer->Add ( bottomSizer ); I didn't locate the other one from a quick look (the backtrace in the dialog doesn't show any locations in xmlcopyeditor's code, even with the dbgsym installed). It's possible there are further problems if any sizers are built on demand rather than at startup - I did a quick run through the menus and didn't hit any, but I'm not an active user of this app. Cheers, Olly -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xmlcopyeditor depends on: ii libaspell15 0.60.8-4+b1 ii libc6 2.34-8 ii libexpat1 2.4.8-2 ii libgcc-s1 12.2.0-3 ii libpcre32:8.39-14 ii libstdc++6 12.2.0-3 ii libwxbase3.2-0 3.2.1+dfsg-1 ii libwxgtk3.2-0 3.2.1+dfsg-1 ii libxerces-c3.2 3.2.3+debian-3+b1 ii libxml2 2.9.14+dfsg-1+b1 ii libxslt1.1 1.1.35-1 xmlcopyeditor recommends no packages. xmlcopyeditor suggests no packages. -- no debconf information
Bug#1019786: closed by Debian FTP Masters (reply to Laszlo Boszormenyi (GCS) ) (Bug#1019786: fixed in wxsqlite3 3.4.1~dfsg-6)
On Sun, Sep 18, 2022 at 06:03:32PM +, Debian Bug Tracking System wrote: > Closes: 1019786 > Changes: > wxsqlite3 (3.4.1~dfsg-6) experimental; urgency=medium > . >* Transition to wxwidgets3.2 (closes: #1019786). >* Mark wxsqlite3-doc Multi-Arch foreign. Thanks for the upload to experimental. Updating wxsqlite3 to a new wxWidgets release series requires a mini-transition as reverse dependencies need updating to match - e.g. see https://bugs.debian.org/750619 for the wxsqlite transition we did for the wxWidgets 2.8 -> 3.0 transition. It appears that there's now only a single reverse dependency, codelite, which is orphaned so I've updated it and uploaded to experimental too. Cheers, Olly
Bug#1015198: better search results
On Wed, Aug 10, 2022 at 09:17:02AM +0200, Thomas Lange wrote: > in #1015198 I also reported useless search results > similar to #658227 (still open since 2012). Sorting by date is unlikely to help #658227 - it would prefer the newest documents which mention the DFSG, and the social contract page was created a long time ago, and presumably changes very rarely. Interestingly it's not just our search which struggles with the DFSG case. Testing with a couple of popular web search engines in a private window (to try to minimise any bias from previous searches, etc, though there are likely geographical and maybe other variations still): On duckduckgo (which I think is currently bing underneath), "Diabetic Foot Study Group" is top. Second is the wikipedia page for "our" DFSG. First d.o hit is https://wiki.debian.org/DFSGLicenses at #5, second d.o hit is the social contract page which isn't until #10. Google ranks the wikipedia page top, first d.o hit is https://people.debian.org/~bap/dfsg-faq.html at #3 and the social contract page is #4. I suspect it doesn't help that the canonical "right answer" here is actually a page which is primarily about the "Debian Social Contract" (that's the page title and top heading, and what's talked about most in the initial part of the page which it's likely search engines put extra weight on). > I found this in the xapian docs. Do you think this would be the best > solution to get the results sorted by date? I'm not sure if it would > be easy to index all our html documents by date, since the time stamps > on the files do not reflect the date of the last modification of the > content. Do you know of any other solutions? That's the most efficient way to sort by date, but requires extra work at index time. You can also store the date in a "value slot" and sort by that, which is easier at index time, but slower at search time. The last modified date is actually already available to sort by behind the scenes - here's what it looks like for your `debconf` example: https://search.debian.org/?q=debconf=100=en=-0 Note that paging through results doesn't preserve this sort setting because the template wasn't written expecting this, so I've set it to show 100 results, which are dominated by WNPP reports, translation reports, etc. Aside from such auto-generated documents (which could probably be excluded or penalised in the ranking), last modified isn't entirely helpful anyway - we don't want a page about debconf 10 to beat the one about debconf 22 just because someone recently fixed a typo or updated a link on the old page. Sorting by creation date probably doesn't really help either. The Social Contract page was created long ago, but the most recent Debconf page fairly recently so neither ascending nor descending is good across the two cases you've highlighted. I suspect boosting based on some link analysis within d.o would help a lot - both the social contract page and the latest debconf page will tend to have more incoming links compared to other pages matching the same terms, and the various autogenerated pages are unlikely to be linked to a lot from elsewhere. I did some initial work on that at Debconf 16, but ran out of time and sadly haven't managed to get back to it since. Cheers, Olly
Bug#1015340: xapian-bindings: FTBFS: dh_install: error: missing files, aborting
On Tue, Jul 19, 2022 at 04:32:41PM +0200, Antonio Terceiro wrote: > > dh_install: warning: Cannot find (any matches for) > > "usr/lib/python3*/*-packages/xapian/*.so" (tried in debian/tmp, debian/tmp) > > > > dh_install: warning: python3-xapian missing files: > > usr/lib/python3*/*-packages/xapian/*.so > > dh_install: warning: Cannot find (any matches for) > > "usr/lib/python3*/*-packages/xapian/*.py" (tried in debian/tmp, debian/tmp) > > > > dh_install: warning: python3-xapian missing files: > > usr/lib/python3*/*-packages/xapian/*.py > > dh_install: error: missing files, aborting > > make[1]: *** [debian/rules:363: override_dh_auto_install] Error 25 I think this must be because of: | python3-defaults (3.10.5-1) unstable; urgency=medium | | * Bump version to 3.10.5. | * Remove Python 3.9 as a supported version. | | -- Matthias Klose Sun, 17 Jul 2022 12:02:10 +0200 Should be easy to fix if so. Cheers, Olly
Bug#722923: Fonts used as character sets are not supported
Control: severity -1 wishlist Control: tags -1 +help On Fri, Sep 20, 2013 at 04:15:29PM +0200, Sébastien Hinderer wrote: > Hello Olly, thanks for your e-mail. > > > I'm not expecting absolute proof, but it'd be good to test it on a > > selection of word documents, and compare output with and without > > the patch. > > Okay, will do once the patch is ready, which as I said will not happen > shortly because it's a lot of work. Did you give up on the idea of working on a patch for this? > > It might be worth trying some of the other options (if you haven't > > already). > > So far I tried catdoc and maybe wordview, which were not more > successful. > > > wv has a command line extractor (wvText), which in my experience handles > > some files better than antiword (and others less well). Sadly it isn't > > actively maintained upstream either these days (last release was just > > under 3 years ago). ISTR antiword is faster than wvText. > > > > There's wv2, but that doesn't come with a command line tool - it's > > just a library. That's also not active upstream (last release nearly 4 > > years ago). > > > > There's also unoconv which uses libreoffice to do the extraction - that > > means the extraction code is actively maintained upstream, and it seems > > to work with most files I've tried. The downside is it is rather slow > > and memory hungry, and I've found it randomly fails sometimes. I think > > the issues stem from trying to remote control libreoffice, which of > > course thinks it's a GUI application rather than a command line tool > > or library. > > Will give a new look to all these, thanks. I think libreoffice also > misses the conversion. There's also now lloconv as an alternative way to use libreoffice to convert files. But I checked lloconv and wvText and they produce similar output to antiword with your example file, so it seems none of the available tools on Linux handle such files. > I don't knowbutthis font-as-codepag trick > seemsnot very well supported. It looks as if people aremostly unaware of > the problem. Perhaps i's because it has been used only for exotic fonts > such as tibetan and sanskrit ones. I know it used to be used in a more limited way for Maori which has macrons on some vowels - in the days of 8-bit character sets it was common to instead use vowels with umlauts and a font which displayed these as macrons. This variant of the trick is less problematic though as most characters match and the ones which don't are at least visually similar to the correct character. However font-as-codepage really doesn't seem a very common trick, so I'm lowering the severity to wishlist. I've also tagged it "help" so it's more discoverable as a bug looking for a patch. Cheers, Olly
Bug#1008092: antiword: Buffer overflow in the vAnalyseSummaryInfo function in summary.c in Antiword 0.37
Control: tag -1 +moreinfo
Control: severity -1 normal
On Thu, Mar 24, 2022 at 04:00:23AM +, Olly Betts wrote:
> On Tue, Mar 22, 2022 at 06:56:23PM +0800, Jieyong Ma @ tdhxkj.com wrote:
> > Backtraces:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") at
> > summary.c:225
> > 225 switch (tPropID) {
>
> That seems a surprising line to segfault on as there's no dereference
> happening. Maybe optimisation has lead to misleading debug line numbers
> though.
>
> > (gdb) bt
> > #0 0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001")
> > at summary.c:225
> > #1 vSetSummaryInfoOLE (pFile=0x68f2e0, pFile@entry=0x37,
> > pPPS=0x7fffbb10, pPPS@entry=0x68f2e0, aulBBD=0x68fb00,
> > aulBBD@entry=0x7fffbb80, tBBDLen=55, tBBDLen@entry=37,
> > aulSBD=aulSBD@entry=0x68fe80, tSBDLen=tSBDLen@entry=2)
> > at summary.c:628
> > #2 0x00449bcf in vSet8SummaryInfo (pFile=0xff7f013c,
> > pFile@entry=0x68f2e0, pPPS=0x692a08, pPPS@entry=0x7fffbb10, aulBBD=0xb,
> > aulBBD@entry=0x68fb00, tBBDLen=10, tBBDLen@entry=55, aulSBD=0x692820,
> > aulSBD@entry=0x68fe80,
> > tSBDLen=29113347658312010, tSBDLen@entry=2, aucHeader=0x2 > Cannot access memory at address 0x2>) at summary.c:686
> > #3 0x00442126 in vGetPropertyInfo (pFile=pFile@entry=0x68f2e0,
> > pPPS=0x7fffbb10, pPPS@entry=0x7fffbb00,
> > aulBBD=aulBBD@entry=0x68fb00, tBBDLen=, tBBDLen@entry=55,
> > aulSBD=0x68fe80, aulSBD@entry=0x68fb00,
> > tSBDLen=2, tSBDLen@entry=0, aucHeader=0x7fffbb80 "\354\245\301",
> > iWordVersion=8) at properties.c:145
> > #4 0x00458464 in iInitDocumentOLE (pFile=,
> > pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at
> > wordole.c:792
> > #5 0x004552fb in iInitDocument (pFile=,
> > pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at
> > wordlib.c:325
> > #6 0x0044ce1f in bWordDecryptor (pFile=pFile@entry=0x68f2e0,
> > lFilesize=lFilesize@entry=28672, pDiag=0x68fac0) at word2text.c:665
> > #7 0x00403ef3 in bProcessFile (szFilename=) at
> > main_u.c:214
> > #8 main (argc=2, argv=0x7fffe558) at main_u.c:310
> >
> > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2064638
>
> "Red Hat Bugzilla – Bug Access Denied"
I still can't access this bug report.
I assume that's where `vAnalyseSummaryInfo.poc.doc` can be found (you
didn't attach it to this bug report), so all I have to go on is the
backtrace which points to a line where there's no dereference.
There aren't any patches in Fedora that we don't have an equivalent of,
except for antiword-0.32-fix-flags.patch which isn't relevant to us:
https://src.fedoraproject.org/rpms/antiword/tree/rawhide
There doesn't seem to be a CVE for this (only ones from 2005 and 2014):
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=antiword
So as it stands, I don't see I can do anything useful with your report.
> There's no active upstream for antiword so someone needs to come up with
> a patch. If someone already has that'd be helpful (and better for the
> various Linux distros to all use the same fix than each come up with
> their own).
This is also very much still true.
Tagging appropriately. I've lowered the severity since failing to
process a single example file is not "a bug which has a major effect on
the usability of a package, without rendering it completely unusable to
everyone".
As best I can make out this is a segfault while reading, so there
doesn't seem there's a security implication either.
Cheers,
Olly
Bug#916189: xapian-bindings: please package Lua bindings
Control: tags +help On Tue, Dec 11, 2018 at 04:03:41AM +, Eric Wong wrote: > I noticed Lua bindings are provided with Xapian upstream; > but there's no Debian package for it. > > I'm not a Lua programmer, yet, but the availability of Xapian > bindings would influence my choice to try it. I've not packaged any Lua modules for Debian before, and never seem to find the time to try to sort this out. I've tagged the bug "help" in the hope that some Debian Lua packaging expert might step in here... Cheers, Olly
Bug#919903: Package wxWidgets 3.1
Control: reassign 919903 wnpp Control: retitle 919903 ITP: wxwidgets3.2 -- wxWidgets Cross-platform C++ GUI toolkit Control: owner 919903 s...@techie.net wxWidgets 3.1 has finally evolved into the stable wxWidgets 3.2.0 release. Scott Talbert is already working on packaging it, so converting this into an ITP bug and making him the owner. Cheers, Olly
Bug#1008092: antiword: Buffer overflow in the vAnalyseSummaryInfo function in summary.c in Antiword 0.37
On Tue, Mar 22, 2022 at 06:56:23PM +0800, Jieyong Ma @ tdhxkj.com wrote:
> Backtraces:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") at
> summary.c:225
> 225 switch (tPropID) {
That seems a surprising line to segfault on as there's no dereference
happening. Maybe optimisation has lead to misleading debug line numbers
though.
> (gdb) bt
> #0 0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") at
> summary.c:225
> #1 vSetSummaryInfoOLE (pFile=0x68f2e0, pFile@entry=0x37,
> pPPS=0x7fffbb10, pPPS@entry=0x68f2e0, aulBBD=0x68fb00,
> aulBBD@entry=0x7fffbb80, tBBDLen=55, tBBDLen@entry=37,
> aulSBD=aulSBD@entry=0x68fe80, tSBDLen=tSBDLen@entry=2)
> at summary.c:628
> #2 0x00449bcf in vSet8SummaryInfo (pFile=0xff7f013c,
> pFile@entry=0x68f2e0, pPPS=0x692a08, pPPS@entry=0x7fffbb10, aulBBD=0xb,
> aulBBD@entry=0x68fb00, tBBDLen=10, tBBDLen@entry=55, aulSBD=0x692820,
> aulSBD@entry=0x68fe80,
> tSBDLen=29113347658312010, tSBDLen@entry=2, aucHeader=0x2 access memory at address 0x2>) at summary.c:686
> #3 0x00442126 in vGetPropertyInfo (pFile=pFile@entry=0x68f2e0,
> pPPS=0x7fffbb10, pPPS@entry=0x7fffbb00, aulBBD=aulBBD@entry=0x68fb00,
> tBBDLen=, tBBDLen@entry=55, aulSBD=0x68fe80,
> aulSBD@entry=0x68fb00,
> tSBDLen=2, tSBDLen@entry=0, aucHeader=0x7fffbb80 "\354\245\301",
> iWordVersion=8) at properties.c:145
> #4 0x00458464 in iInitDocumentOLE (pFile=,
> pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at
> wordole.c:792
> #5 0x004552fb in iInitDocument (pFile=,
> pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at
> wordlib.c:325
> #6 0x0044ce1f in bWordDecryptor (pFile=pFile@entry=0x68f2e0,
> lFilesize=lFilesize@entry=28672, pDiag=0x68fac0) at word2text.c:665
> #7 0x00403ef3 in bProcessFile (szFilename=) at
> main_u.c:214
> #8 main (argc=2, argv=0x7fffe558) at main_u.c:310
>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2064638
"Red Hat Bugzilla – Bug Access Denied"
There's no active upstream for antiword so someone needs to come up with
a patch. If someone already has that'd be helpful (and better for the
various Linux distros to all use the same fix than each come up with
their own).
Cheers,
Olly
Bug#1004811: survex: FTBFS with ffmpeg 5.0
Control: tags -1 + fixed-upstream On Tue, Feb 01, 2022 at 11:19:04PM +0100, Sebastian Ramacher wrote: > survex FTBFS with ffmpeg 5.0 in experimental: I've pushed a fix for this upstream (commit 44c4b7054885c2a5f25692547bf45fa33bcba1e8). It looks like there are a huge number of packages still blocking the transition so my plan is to just pick up this fix with the next upstream release in the interests of avoiding creating more things to do for myself. Cheers, Olly
Bug#1000890: libwxbase3.0-0v5: wxStandardPaths::GetDocumentsDir should not return a quoted string
On Tue, Nov 30, 2021 at 11:53:23AM -0800, Norman Rasmussen wrote:
> --- a/src/unix/stdpaths.cpp
> +++ b/src/unix/stdpaths.cpp
> @@ -260,6 +260,8 @@ wxString wxStandardPaths::GetDocumentsDir() const
> value.Replace(wxT("$HOME"), homeDir);
> value.Trim(true);
> value.Trim(false);
> +// Remove quotes
> +value.Replace("\"", "", true /* replace all */);
> if (!value.IsEmpty() && wxDirExists(value))
> return value;
> else
>
> While I don't really agree with _how_ the quotes are removed (the string
> should be unquoted like wxFileConfig does with FilterInValue instead of
> just stripping all of the quotes)
Indeed, the code around here will get various corner cases wrong.
Have you tried to get upstream to address this?
> I would like this part of the
> upstream commit to be backported to the current Debian package so that
> the returned value is useable (and I don't want to wait for a new stable
> release of wxWidgets).
I'd strongly encourage you to get this backported upstream to the
WX_3_0_BRANCH. That way it's fixed for everybody in the next 3.0.x
release.
If we only fix this in Debian, people will need to work around
this in their application code anyway for Linux distros not derived from
Debian.
(And then we can cherry-pick from WX_3_0_BRANCH - I'm just much more
hesitant to cherry pick fixes that aren't backported upstream.)
Cheers,
Olly
Bug#983229: proj transition has started
On Tue, Oct 26, 2021 at 05:35:48AM +0200, Sebastiaan Couwenberg wrote: > PROJ 8.2.0 is scheduled for release next week, just wait for that. Oh, I see this has been uploaded. I'll try to sort out updating the survex package to use it. Cheers, Olly
Bug#997909: xapian-bindings: FTBFS with ruby3.0: diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or directory
On Tue, Oct 26, 2021 at 06:34:06PM -0300, Antonio Terceiro wrote:
> > rb=debian/tmp`/usr/bin/ruby3.0 -rrbconfig -e 'puts
> > RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
> > for v in 2.7; do \
> > if [ "$v" != "3.0" ] ; then \
> > set -e; \
> > rb_old=debian/tmp`/usr/bin/ruby$v -rrbconfig -e 'puts
> > RbConfig::CONFIG["vendorlibdir"]'`/xapian.rb; \
> > diff "$rb_old" "$rb"; \
> > rm -rf "$rb_old" debian/tmp/usr/share/doc/xapian-bindings-ruby$v; \
> > fi; \
> > done; \
> > mv "$rb" debian/tmp/usr/lib/ruby/vendor_ruby
> > diff: debian/tmp/usr/lib/ruby/vendor_ruby/3.0.0/xapian.rb: No such file or
> > directory
> > make[1]: *** [debian/rules:359: override_dh_auto_install] Error 2
I strongly suspect (but haven't yet tested) that the problem is simply
this hard-coded reference to the Ruby version starting `2.` in
debian/rules:
RUBY_VERSIONS := $(shell ruby -rruby_debian_dev -e 'print
RubyDebianDev::RUBY_CONFIG_VERSION.values.grep(/^2\.[1-9]/).join(" ")')
I'll test the obvious fix there when I get a chance, but I know the
upstream code builds and works with Ruby 3.0, so please don't let
xapian-bindings hold up starting the transition.
Cheers,
Olly
Bug#983229: proj transition has started
On Tue, Oct 26, 2021 at 05:35:48AM +0200, Sebastiaan Couwenberg wrote: > PROJ 8.2.0 is scheduled for release next week, just wait for that. OK. > You also mentioned in the upstream issue that you need a solution for other > users who cannot upgrade to PROJ 8.2.0, did you give up on that and made > 8.2.0 a hard requirement? I'd certainly prefer not to hard require PROJ >= 8.2.0, but I don't see a good way to allow that without a lot of conditionalisation on PROJ version. It's not just the C code - there are some differences in the testsuite due to things like newer PROJ correcting for the vertical datum and older PROJ not. Maybe bumping the upstream minor version for the PROJ 8.2.0 compatible version would be a good approach - then people who don't have easy access to PROJ 8.2.0 have an obvious older Survex version to use, and any important bug fixes can be backported without having to add an extra version component. Cheers, Olly
Bug#983229: proj transition has started
On Fri, Oct 22, 2021 at 06:36:53AM +0200, Sebastiaan Couwenberg wrote: > The proj transition has started, raising the severity accordingly. As I noted in the upstream ticket (which I know you are subscribed to) Survex requires a fix to make proj_factors() actually usable in the "new PROJ" world. According to the doc change in the patch and the milestone set, this will be in PROJ 8.2.0: https://github.com/OSGeo/PROJ/pull/2868 There isn't a sensible workaround I can see, so if you want to push through the transition before 8.2.0 is out, please apply the above patch to the proj package. Cheers, Olly
Bug#953912: pinot: Switch from deprecated to
Control: tags -1 + fixed-upstream On Sat, Mar 14, 2020 at 07:13:21PM +0100, Guillem Jover wrote: > It looks like this is the only header used by this package from libattr, > so you should be able to drop the dependency on libattr entirely, as > glibc should be providing all that is needed now. I forwarded your report to the upstream author (via private email) and they've applied your proposed fix to upstream git (commit d3d357a51e8d8317a9e89960878424ddc30580cf). There's a 1.2.0 release planned for the near future, so packaging that once it is out should address this. Cheers, Olly
Bug#951559: pinot FTCBFS: uses the build architecture pkg-config
Control: tags -1 + fixed-upstream On Tue, Feb 18, 2020 at 06:10:38AM +0100, Helmut Grohne wrote: > please consider applying the attached patch to fix the > issue with calling pkg-config and close this bug when doing so. I forwarded your report to the upstream author (via private email) and they've applied your proposed patch to upstream git (commit 24c0ea7eb84e495d90ce4cec8d4c5532d7dff937). > After applying it, pinot fails the "if gio can sniff png" check, > because it cannot be performed during cross building. Would it be ok for > you to pass either --enable-gio or --disable-gio to configure to remove > the need for running the test? The "if gio can sniff png" check was removed upstream a few weeks ago by commit 514f1f4ebac59ef9f81c9fb6aa01638aae9ef30f. There's a 1.2.0 release planned for the near future, so packaging that once it is out should address all the issues you reported. Cheers, Olly
Bug#955937: pinot: Depends on deprecated dbus-glib
Control: tags -1 + fixed-upstream On Sun, Apr 05, 2020 at 03:19:35PM +0100, s...@debian.org wrote: > For most purposes, the recommended replacement for dbus-glib is the > GDBus family of APIs in GLib, found in . I forwarded your report to the upstream author (via private email) and it's been addressed in upstream git (commit 6bea48c1dea7f37e8830c1a62dc4e9c3133a5856). There's a 1.2.0 release planned for the near future, so packaging that once it is out will address this. Cheers, Olly
Bug#991064: therion FTBFS with imagemagick with the #987504 change
On Fri, Jul 16, 2021 at 06:44:49PM +0200, Dennis Filder wrote: > The attached patch seems to allow the "Converting images" step to > succeed. I ran this only once though. This looks reasonable to me (as an uploader of the package). Wookey: Are you able to upload? I'm seriously lacking in spare time currently. If not and someone wants to NMU, please go for it. Cheers, Olly
Bug#985642: xapian-core FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck
Hi Helmut, On Sun, Mar 21, 2021 at 09:24:19AM +0100, Helmut Grohne wrote: > xapian-core fails to cross build from source, because it fails running > tests despite passing DEB_BUILD_OPTIONS=nocheck. Please consider > applying the attached patch to fix that. Sorry about this - I converted debian/rules to use dh recently, but in doing so I dropped the "nocheck" handling because dh now takes care of that ... except I missed that this only happens in compat level >= 13 which I avoided using as it makes backporting harder right now. I'm happy to patch (or for you to NMU) but is this an appropriate change in a key package for this level of the freeze? Policy says supporting DEB_BUILD_OPTIONS is "recommended" which is equivalent to "should" so it's not clearly RC. I'm guessing you already know the release team's opinion on such things. Cheers, Olly
Bug#983091: xapian-core FTBFS on i386: test failure
On Tue, Feb 23, 2021 at 10:22:39PM +0200, Adrian Bunk wrote: > On Tue, Feb 23, 2021 at 07:52:42PM +0000, Olly Betts wrote: > >... > > As you note, on i386 the test was only run with the SSE build before > > the recent debian/rules modernisation, but that doesn't explain why > > m68k now fails. Looking at older m68k logs, it seems the testsuite > > wasn't being run, though I'm not seeing why not. > >... > > m68k and sh4 are building with nocheck. > > nocheck handling was lost in the debian/rules rewrite. I dropped that handling as I thought dh_auto_test now handled it by default, but checking the docs I see that is only on in compat level 13 and up (which I avoided to aid backporting.) Thanks for the pointer. Cheers, Olly
Bug#983091: xapian-core FTBFS on i386: test failure
On Sat, Feb 20, 2021 at 07:24:52PM +, Olly Betts wrote: > On Fri, Feb 19, 2021 at 11:36:46AM +0200, Adrian Bunk wrote: > > With the old debian/rules the test was only run with > > the SSE build. > > > > If exact results are required and the x87 excess precision is unwanted, > > test with the non-SSE build can be fixed with: > > > > --- debian/rules.old2021-02-18 15:12:59.097207579 + > > +++ debian/rules2021-02-18 15:13:51.537168694 + > > @@ -51,6 +51,10 @@ > > > > export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) > > > > +ifneq (,$(filter $(DEB_HOST_ARCH), i386 m68k)) > > +export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store > > +endif > > + > > # For i386 and *-i386. > > ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386) > > XAPIAN_BUILD_SSE := 1 > > Thanks for the report, and for tracking this down to excess precision. > > The upstream code is meant to address excess precision in the small > number of places where it matters but I guess there's a newer instance > that hasn't been caught before, or a newer testcase uncovers an existing > problem (or perhaps newer GCC optimises differently and that's uncovered > this.) > > The SSE2 build will get used by more i386 systems, so the overhead > from -ffloat-store won't affect many there at least, but it is a bit of > heavy hammer. I'll take a look and see if I can fix this in a more > targetted way. If not applying this for bullseye seems reasonable. > Or we could change the tests back to run just for the SSE2 build for > now - in real world use exact results are rarely a requirement, but > performance often is. Investigating on i386 I found that all the failures apart from ordecay1 appear to actually be from the effects of excess precision on testcase code itself (and looking at the m68k log, ordecay1 actually passes there.) As you note, on i386 the test was only run with the SSE build before the recent debian/rules modernisation, but that doesn't explain why m68k now fails. Looking at older m68k logs, it seems the testsuite wasn't being run, though I'm not seeing why not. I think given where we are in the bullseye freeze the least invasive change here makes sense, which is to not run the tests for the i386 non-SSE build (they are run for the SSE build, which is the build which gets used on SSE2-capable machines, which is most of them) or on m68k (which isn't ideal, but it isn't a release architecture currently.) This essentially restores the testing situation to what it was prior to my modernisation of debian/rules in the previous upload. Longer term, sorting out ordecay1 and the testsuite issues (perhaps building the testsuite with -ffloat-store on affected platforms.) Cheers, Olly
Bug#983091: xapian-core FTBFS on i386: test failure
On Fri, Feb 19, 2021 at 11:36:46AM +0200, Adrian Bunk wrote: > With the old debian/rules the test was only run with > the SSE build. > > If exact results are required and the x87 excess precision is unwanted, > test with the non-SSE build can be fixed with: > > --- debian/rules.old 2021-02-18 15:12:59.097207579 + > +++ debian/rules 2021-02-18 15:13:51.537168694 + > @@ -51,6 +51,10 @@ > > export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) > > +ifneq (,$(filter $(DEB_HOST_ARCH), i386 m68k)) > +export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store > +endif > + > # For i386 and *-i386. > ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386) > XAPIAN_BUILD_SSE := 1 Thanks for the report, and for tracking this down to excess precision. The upstream code is meant to address excess precision in the small number of places where it matters but I guess there's a newer instance that hasn't been caught before, or a newer testcase uncovers an existing problem (or perhaps newer GCC optimises differently and that's uncovered this.) The SSE2 build will get used by more i386 systems, so the overhead from -ffloat-store won't affect many there at least, but it is a bit of heavy hammer. I'll take a look and see if I can fix this in a more targetted way. If not applying this for bullseye seems reasonable. Or we could change the tests back to run just for the SSE2 build for now - in real world use exact results are rarely a requirement, but performance often is. Cheers, Olly
Bug#934386: wxScrolled flickers when the horizontal scrollbar is active and GTK3 is used
On Sun, Dec 01, 2019 at 10:08:49AM +0100, Gunter Königsmann wrote: > After an > > export GTK_IM_MODULE=xim > > the combination GTK3.0, wxWidgets and any ribbon, nearly any list view > and all scrolled windows flicker real bad. At least if the CPU power > doesn't allow for a repaint before the data arrives at the screen. > Examples of flickering things are wxWidget's scroll and the ribbon sample. > > After an > > export GTK_IM_MODULE=ibus > > the flicker is completely gone. It seems xim support in GTK3 is known to be buggy and GTK upstream say: the recommended fix is not to use xim https://gitlab.gnome.org/GNOME/gtk/-/issues/2560#note_757143 Support for xim has been removed completely in the development branch which is leading to GTK4: support for the xim input method has been removed in favor of IBus https://blog.gtk.org/2020/02/13/gtk-3-98/ Cheers, Olly
Bug#904664: msgconvert mbox output issues
On Thu, Jul 26, 2018 at 01:30:56PM +0200, Matus UHLAR - fantomas wrote: > 1. the "From " line contains full "From: " header, while it's supposed to > contain only the address, without < and > brackets, with one space > separating address and date (two spaces are used now). I've fixed this in Debian and submitted the patch upstream. > 2. output lines are end with CR-LF characters. CR's should be stripped, at > leasst on unix systems. > > I have compared output with and without --mbox and the only differences are > - From line > - mime boundaries > - new lines. > > Since the 2nd problem seems to come from Email::Sender::Transport::Mbox, I > believe that package could be avoided, and mbox files can be written to > single file starting each mail with "From address RFC822-date" and ending > with empty line. This same issue had also been reported upstream, but upstream believes the current behaviour is correct so I think you need to take it up with them if you disagree: https://github.com/mvz/email-outlook-message-perl/issues/13#issuecomment-616044853 Writing mbox isn't quite as simple as you suggest - e.g. extra care is needed for lines starting "From " in the message body. If this really is wrong then it would be better to get it fixed in Email::Sender::Transport::Mbox (as upstream suggests above) - that would benefit other users of it. Cheers, Olly
Bug#969012: libemail-outlook-message-perl: Fix charset handling
Package: libemail-outlook-message-perl Version: 0.919-1 Severity: normal Tags: patch upstream Forwarded: https://github.com/mvz/email-outlook-message-perl/pull/15 This module doesn't currently handle the "Internet Code Page" property, nor use the appropriate default of "CP1252". Instead charset="UTF-8" is always used for text/plain, and no charset is specified for text/html. I came up with a patch to address this some time ago and sent it upstream, and it was merged back in April. There's not been an upstream release since, but given upstream have applied the patch I think we should apply it in Debian. As things stand the module gets things wrong unless the content is actually in ASCII or UTF-8, and while that's probably true of most RFC822 email, it seems that a lot of mail from Outlook uses CP1252. I'm an uploader for the package and I'm planning to prepare an upload shortly - this bug is really to document the situation clearly. Cheers, Olly
Bug#968812: antiword: segfault due to an invalid read in vAnalyseDocumentSummaryInfo
On Fri, Aug 21, 2020 at 02:36:28PM +, Luca Borzacchiello wrote: > running antiword with the attached file leads to an invalid read, > causing a segfault. There's no longer an active upstream for antiword. So while fuzzing it is great and all, much more useful would be working on patches to fix the bugs you find by doing it. Cheers, Olly
Bug#964820: libwxgtk3.0-gtk3-0v5: AUI caption text is dark on a dark background
On Sat, Jul 11, 2020 at 11:31:51AM +0200, Michel Le Bihan wrote: > I opened https://github.com/wxWidgets/wxWidgets/pull/1946. It is still > very ugly, but at least the AUI caption text is readable. This has now been applied upstream as: https://github.com/wxWidgets/wxWidgets/commit/aae96a430609bacfa546f0a872cf1a94e8a0b073 Scott: Do you want to take care of this? Cheers, Olly
Bug#964820: libwxgtk3.0-gtk3-0v5: AUI caption text is dark on a dark background
On Fri, Jul 10, 2020 at 10:47:14PM +0200, Michel Le Bihan wrote: > In dark GTK themes the caption background correctly changes to the dark color, > but the text stays black resulting in it being unreadable. The text color > should also change. > > I opened a PR upstream https://github.com/wxWidgets/wxWidgets/pull/1791 and my > changes got merged in > https://github.com/AliKet/wxWidgets/commit/1e25f0d966b7539fee93a67671f7834db38c3d5c. > I think that this change should be backported to the version of wxWidgets in > testing because currently some wxWidgets apps are barely usable with a dark > GTK > theme. Has this patch been backported to upstream's WX_3_0_BRANCH branch? It's been so long since this branched that most patches against upstream master won't cleanly apply to 3.0.x, so while you've linked to a patch for this, that patch isn't actually usable as-is for the package because it doesn't apply cleanly: $ wget https://github.com/AliKet/wxWidgets/commit/1e25f0d966b7539fee93a67671f7834db38c3d5c.diff [...] $ patch -p1 < 1e25f0d966b7539fee93a67671f7834db38c3d5c.diff patching file src/aui/auibar.cpp Hunk #1 succeeded at 89 (offset 2 lines). Hunk #2 succeeded at 155 (offset 11 lines). Hunk #3 succeeded at 314 (offset -20 lines). Hunk #4 succeeded at 334 (offset -20 lines). Hunk #5 FAILED at 363. Hunk #6 succeeded at 432 (offset -25 lines). Hunk #7 succeeded at 451 (offset -25 lines). Hunk #8 FAILED at 501. Hunk #9 succeeded at 680 (offset -44 lines). 2 out of 9 hunks FAILED -- saving rejects to file src/aui/auibar.cpp.rej can't find file to patch at input line 130 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/src/aui/barartmsw.cpp b/src/aui/barartmsw.cpp |index 7958f810db2..878aafce5ae 100644 |--- a/src/aui/barartmsw.cpp |+++ b/src/aui/barartmsw.cpp -- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored patching file src/aui/dockart.cpp Hunk #1 FAILED at 324. 1 out of 1 hunk FAILED -- saving rejects to file src/aui/dockart.cpp.rej It's probably OK that src/aui/barartmsw.cpp doesn't exist from a Debian perspective, as from the name it's MSW-specific, but the failed hunks need sorting out. But overall I'd encourage getting this fixed in upstream's WX_3_0_BRANCH first (or linking to that commit if it's already backported). That way this gets fixed for all distros, not just Debian-based ones. Cheers, Olly
Bug#890873: Issue no longer present
On Sun, Mar 29, 2020 at 06:32:53PM -0700, Felix Lechner wrote: > Not sure if Olly's problem with wxwidgets3.0 was related, but it ran > fine. That log is attached as well. I suspect it wasn't, but I think I didn't get a chance to investigate as it didn't recur. Cheers, Olly
Bug#938836: xapian-bindings: Python2 removal in sid/bullseye
On Fri, Mar 27, 2020 at 10:33:33AM -0400, Sandro Tosi wrote: > i think we're ready to drop python-xapian: the only 2 remaining rdeps > are not in testing (because are RC anyway), so please do remove > python-xapian at your earliest convenience (please note we're also > going to proceed with the removal of python-sphinx, since > python-xapian is now the only remaining rdep in testing). OK, will do. Cheers, Olly
Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc
On Sat, Mar 21, 2020 at 06:12:48PM -0400, Sandro Tosi wrote: > > Having pondered, I'd suggest we just leave xapian-bindings as-is > > until you're at the point of dropping python2 support from sphinx and > > then I'll drop the sphinx-generated docs for the python2 bindings > > from the Debian package entirely. > > we're finally in the single digit number of reverse dependencies for > python-sphinx Are you sure? dak rm thinks: Checking reverse dependencies... # Broken Depends: funkload: funkload-doc sphinx-patchqueue: python-sphinx-patchqueue # Broken Build-Depends: brian: python-sphinx dh-virtualenv: python-sphinx dipy: python-sphinx (>= 1.0) django-ratelimit: python-sphinx funkload: python-sphinx ganeti: python-sphinx (>= 1.0.7+dfsg) ghc: python-sphinx iptables-converter: python-sphinx iptables-optimizer: python-sphinx (>= 1.2.3) krb5: python-sphinx llvm-toolchain-6.0: python-sphinx llvm-toolchain-7: python-sphinx (>= 1.3.6) mini-buildd: python-sphinx (>= 1.1.3) nipype: python-sphinx (>= 0.6) pebl: python-sphinx pycassa: python-sphinx pymvpa2: python-sphinx pynifti: python-sphinx pypy: python-sphinx (>= 1.0.7+dfsg) pypy3: python-sphinx (>= 1.0.7+dfsg) python-neuroshare: python-sphinx (>= 1.0.7+dfsg) python-pysqlite2: python-sphinx (>= 0.6.1) python-versuchung: python-sphinx renpy: python-sphinx sphinx-patchqueue: python-sphinx vmm: python-sphinx xapian-bindings: python-sphinx Cheers, Olly
Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc
On Sat, Mar 14, 2020 at 05:35:14PM -0400, Sandro Tosi wrote: > This will help us in reducing the reverse dependencies of > bin:python-sphinx, so that we can introduce a python3-only sphinx > version in unstable. Having pondered, I'd suggest we just leave xapian-bindings as-is until you're at the point of dropping python2 support from sphinx and then I'll drop the sphinx-generated docs for the python2 bindings from the Debian package entirely. If anyone still wants to look at them they are at least available online. And maybe we'll be ready to remove the python2 bindings before then anyway (there weren't very many rdeps left last time I looked). Cheers, Olly
Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc
On Sat, Mar 14, 2020 at 05:59:42PM -0400, Sandro Tosi wrote: > > The Python2 and Python3 bindings don't have exactly the same API (mostly > > due to Unicode handling differences, but also the Python3 bindings don't > > include various backward-compatibility features with older versions of > > the Python2 bindings) > > does the documentation access the bindings source code at build time? > if not, you can still use only python3-sphinx to build both doc > versions (and still ship them separately). It does - that's why it requires both versions of sphinx rather than just running allowing one to be specified. Cheers, Olly
Bug#953949: xapian-bindings: please split out python-xapian-doc and use only python3-sphinx to build doc
Control: tags -1 wontfix On Sat, Mar 14, 2020 at 05:35:14PM -0400, Sandro Tosi wrote: > from what i can see, xapian-bindings builds its documentation twice, one for > the > python2 bindings (and install that in bin:python-xapian) and one for the > python3 > bindings (and install that in bin:python3-xapian). > > this is usually un-necessary, and the convention is to create a separate > package > to contain the documentation, in this case python-xapian-doc. So please split > out such a package to contain the documentation for the python bindings in a > single place, and that the same time, please only use python3-sphinx to build > the documentation. The Python2 and Python3 bindings don't have exactly the same API (mostly due to Unicode handling differences, but also the Python3 bindings don't include various backward-compatibility features with older versions of the Python2 bindings) A single set of docs doesn't really work as the Python3 bindings docs aren't a good replacement for the Python2 bindings docs. It this seems to fall outside your "usually un-necessary" hence tagging as wontfix. Cheers, Olly
Bug#951076: abi-compliance-checker: Invalid use of Perl "next"
On Tue, Feb 11, 2020 at 08:36:43AM +1300, Olly Betts wrote:
> I've noticed this message repeatedly appearing in the ci.debian.net logs:
>
> Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line
> 10171.
>
> That's the "next" in this function:
>
> sub exec_helper(@)
> {
> my ($reader, $writer) = @_;
> do {
> chomp($line = <$reader>);
> next if (!$line);
> if ($line eq 'exit') {
> exit(0);
> }
> system($line);
> print $writer "$? $!\n";
> } while(1);
> }
>
> This is a quirk of Perl - "next" doesn't work in a "do { ... } while"
> like "continue" in C/C++ does because it's really a "do { ... }" block
> with a while applied.
>
> "perldoc perlsyn" suggests just doubling the braces on the loop, but in
> this case a clearer fix (untested) is probably to rewrite the loop in
> the form: "while(1) { ... }"
>
> The actual current effect of "next" here seems to be to terminate the
> loop. That seems problematic on the face of it, but in practice I
> think the only cases where it would trigger are an entirely empty line or
> "0" with no newline, both of which would mean the end of the input
> stream.
Oh, except that there's a chomp() first, so it seems we'll exit early
if we read a blank line or a line containing only "0". I guess those
are unlikely as this seems to be reading commands to execute.
> But maybe the loop should terminate at the end of the input stream,
> since otherwise it seems this loop will never terminate if the stream
> ends without "exit" being received. So perhaps the better fix is:
>
> if (!$line || $line eq 'exit') {
> exit(0);
> }
So this won't work as-is.
The problematic code is from a patch we're applying:
https://sources.debian.org/src/abi-compliance-checker/2.3-0.2/debian/patches/oom-exec-helper.patch/
Cc-ing Steve Langasek as the author of that patch.
Cheers,
Olly
Bug#951076: abi-compliance-checker: Invalid use of Perl "next"
Package: abi-compliance-checker
Version: 2.3-0.2
Severity: normal
I've noticed this message repeatedly appearing in the ci.debian.net logs:
Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 10171.
That's the "next" in this function:
sub exec_helper(@)
{
my ($reader, $writer) = @_;
do {
chomp($line = <$reader>);
next if (!$line);
if ($line eq 'exit') {
exit(0);
}
system($line);
print $writer "$? $!\n";
} while(1);
}
This is a quirk of Perl - "next" doesn't work in a "do { ... } while"
like "continue" in C/C++ does because it's really a "do { ... }" block
with a while applied.
"perldoc perlsyn" suggests just doubling the braces on the loop, but in
this case a clearer fix (untested) is probably to rewrite the loop in
the form: "while(1) { ... }"
The actual current effect of "next" here seems to be to terminate the
loop. That seems problematic on the face of it, but in practice I
think the only cases where it would trigger are an entirely empty line or
"0" with no newline, both of which would mean the end of the input
stream.
But maybe the loop should terminate at the end of the input stream,
since otherwise it seems this loop will never terminate if the stream
ends without "exit" being received. So perhaps the better fix is:
if (!$line || $line eq 'exit) {
exit(0);
}
Cheers,
Olly
Bug#675122: iceweasel: Mibbit.com is being used as a "handler service" for IRC links.
Control: reassign -1 firefox Control: found -1 72.0.1-1 On Tue, May 29, 2012 at 11:45:15PM +0100, Andrew Wigglesworth wrote: >* What led up to the situation? > > I clicked on an "IRC link". ie. a irc:// style link. > >* What was the outcome of this action? > > I was offered use of a proprietary, secret code, "software as a > service" service for IRC called Mibbit ar Mibbit.com. This is still the case in the current firefox package. > It is also a service permanently banned at Freenode. See: > http://blog.freenode.net/2009/06/new-freenode-webchat-and-why-to-use-it/ This ban is still in place - if you click to use mibbit for a freenode channel via an irc: links it fails with: syn Connections via mibbit are no longer supported on freenode. You may wish to consider using http://webchat.freenode.net instead. Further information over at http://bit.ly/19JILF syn KILL: syn. syn| [0] mmm, [1] (Facility Blocked) Even ignoring concerns about promoting non-free network services, this makes mibbit a poor default for handling irc: links. Cheers, Olly
Bug#950739: xapian-bindings: Fails to build against ruby2.7
Control: tags -1 +pending On Wed, Feb 05, 2020 at 12:05:22PM -0300, Lucas Kanashiro wrote: > We are planning to start the ruby2.7 transition and your package failed > to build against ruby2.7. Check the full build log here: > > https://people.debian.org/~kanashiro/ruby2.7/builds/5/xapian-bindings/xapian-bindings_1.4.12-3+rebuild1580867044_amd64-2020-02-05T01:44:06Z.build The problems all look to be in SWIG-generated code. SWIG was patched for Ruby 2.7 support last month, but there hasn't been a SWIG release since 21 Aug 2019 so I'll work on patching the generated code for now. It looks like the only thing that actually needs fixing right now may be adding a cast to (rb_gvar_setter_t*) - testing that now. Cheers, Olly
Bug#950402: pinot ftbfs with libexiv2-27
Control: tags -1 +pending On Thu, Feb 06, 2020 at 05:17:37AM +, peter green wrote: > This build failure is fixed by upstream commit > faaa552de9ec099184d131c08b76ae0b1ce4f5ec Thanks for identifying this - will upload shortly. I'll also suggest to upstream it's time they made a new release (it's been more than 4.5 years since the last one). Cheers, Olly
Bug#945722: pinot: Python2 removal in sid/bullseye - reopen 945722
On Sat, Jan 18, 2020 at 09:58:15PM -0500, Sandro Tosi wrote: > This bug was closed, but the package has still some dependencies towards > Python2 packages, in details: > > (binary:pinot)Recommends->python-docutils > > Re-opening, so that they can be taken care of. The dependency is actually: Recommends: [...] python3-docutils | python-docutils [...] This really doesn't seem to justify RC severity to me. Cheers, Olly
Bug#919903: Package wxWidgets 3.1
On Mon, Dec 23, 2019 at 06:21:53PM -0500, John Scott wrote: > > It's not ABI stable, so it's just not suitable for packaging. Every new > > 3.1.x release would mean a transition for everything built against it. > > Even if we only uploaded to experimental with the aim to support local > > builds, a new upload would break everyone's locally built applications. > > Upstream appears adamant that it's ready to deploy: > > Please notice that while 3.1.3 is officially a “development” version because > > it is not fully compatible with the “stable” 3.0.x, the list of backwards > > incompatible changes is very short, so you shouldn’t have any problems > > updating to this version from 3.0.x in practice, and you’re encouraged to > > use this release, including in production. It's frustrating that upstream have invented this strange concept of a development version for use in production, and I've pointed out that it doesn't work for distros which ship binary packages to them. I've also tried to encourage them to start a new stable release series more frequently. 3.1.x is perhaps ready to deploy in a world where it's fine to build all your own dependencies and statically link them into your app which you ship direct to users, but that's a different world to Debian. > I hope you'll reconsider uploading to experimental. You're asking the package maintainers to take on a significant amount of extra work here, and I don't see that putting a non-ABI stable package into experimental is useful enough to justify that effort. People who really want to try a development version of wxWidgets (or anything else) can always build it for themselves. Then they get to decide when to update to the next 3.1.x and have to rebuild all their applications with the new version. > It appears that my trouble with wxMaxima is probably fixed in > wxWidgets 3.1.2 and I'd like to give it a try. If I'm following, this issue which made you want to try 3.1.x turned out to already be fixed in Debian unstable some months ago anyway, so the presence of an experimental package would if anything just have distracted. Cheers, Olly
Bug#938834: wxpython3.0: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 938834 + py2keep thanks On Fri, Aug 30, 2019 at 10:22:11PM +0100, Olly Betts wrote: > user debian-pyt...@lists.debian.org > usertags 938836 + py2keep I just spotted that I typoed the bug number here (938836 is another package I maintain which also should be py2keep for now). See quote below for rationale: > On Fri, Aug 30, 2019 at 07:58:50AM +, Matthias Klose wrote: > > - Convert your Package to Python3. This is the preferred option. In > > case you are providing a Python module foo, please consider dropping > > the python-foo package, and only build a python3-foo package. Please > > don't drop Python2 modules, which still have reverse dependencies, > > just document them. > > The migration path is to wxpython4.0, but upstream did a complete > rewrite and it's not a drop in replacement. > > > - If the package has still many users (popcon >= 300), or is needed to > > build another package which cannot be removed, document that by > > adding the "py2keep" user tag (not replacing the py2remove tag), > > using the debian-pyt...@lists.debian.org user. Also any > > dependencies on an unversioned python package (python, python-dev) > > must not be used, same with the python shebang. These have to be > > replaced by python2/python2.7 dependencies and shebang. > > popcon is 14342. Cheers, Olly
Bug#935141: wxmaxima: assertion failure with multiple monitors
On Mon, Aug 19, 2019 at 11:08:55PM -0400, John Scott wrote: > I'm having this issue both with 19.01.2-1 and 19.07.0-1. Backtraces and > screenshots are from the latter. Can you reproduce this with wxmaxima 19.07.0-1.1 (the version currently in unstable and testing)? That's the version that switched to using the GTK3 flavour of wxWidgets. I have multiple monitors and I can't reproduce with this version, though I use Mate not GNOME 3 so it could be something specific to the desktop environment. Cheers, Olly
Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)
Shouldn't this discussion be in bug #922067 (and not Cc-ed to me - I have no interest in winpdb beyond it having been a blocker for a wxpython transition over 5 years ago)? This bug was providing the debdiff for an NMU I did back then. There's been a maintainer upload since (1.4.8-3) which incorporated my changes but missed closing this bug, which Scott recently spotted and tidied up. Cheers, Olly
Bug#946855: Therion still fails on old proj dependency; loch fixed in upstream
Control: tags -1 +pending On Tue, Dec 17, 2019 at 01:55:54AM +, Olly Betts wrote: > On Mon, Dec 16, 2019 at 04:33:58PM +0100, Benedikt Hallinger wrote: > > It would be nice to recompile the package including the latest > > upstream sources, thank you! > > We usually update to the latest upstream sources only when upstream make > a release (since that's a strong signal that it's "ready"). If we start > pulling arbitrary snapshots from upstream git where we have to worry > about there being changes which might not yet be ready, so in between > we would usually apply a targetted fix for a problem. A handy illustration of why we do that popped up today: https://mailman.speleo.sk/pipermail/therion/2019-December/008086.html > So we can probably apply the tiny patch from > https://github.com/therion/therion/pull/151 but it would really make > sense for upstream to make an actual release. Upload with this patch applied on its way. Cheers, Olly
Bug#946855: Therion still fails on old proj dependency; loch fixed in upstream
On Mon, Dec 16, 2019 at 04:33:58PM +0100, Benedikt Hallinger wrote: > Hello, i just wanted to inform you that therion still fails with the proj > issue[1] on my system when installing from the new package 5.4.4ds1-4. > > Also the loch glx issue[2] was fixed recently in upstream (Olly did a patch > on this in the last deb package which is obsoleted by Stachos upstream fix. > > It would be nice to recompile the package including the latest > upstream sources, thank you! We usually update to the latest upstream sources only when upstream make a release (since that's a strong signal that it's "ready"). If we start pulling arbitrary snapshots from upstream git where we have to worry about there being changes which might not yet be ready, so in between we would usually apply a targetted fix for a problem. So we can probably apply the tiny patch from https://github.com/therion/therion/pull/151 but it would really make sense for upstream to make an actual release. Cheers, Olly
Bug#926922: kodi: Please package new upstream release
On Fri, Apr 12, 2019 at 11:13:51AM +0200, Bálint Réczey wrote: > The 18.1 version is out and the package is in the works: > https://salsa.debian.org/multimedia-team/kodi > > I can't upload it yet even to experimental because flatbuffers is not > in the archive yet. Just to note that's no longer a blocker, as of about a week ago: https://tracker.debian.org/pkg/flatbuffers (It needs a source-only upload to migrate to testing, but it's available in unstable). Cheers, Olly
Bug#946018: opencpn: FTBFS due to trying to use removed wx GTK2 flavour
Source: opencpn Version: 4.8.8+dfsg.2-1 Severity: grave Justification: renders package unusable opencpn build-depends on libwxgtk3.0-dev, but that's been dropped (there are still some crufty remnants in unstable, but libwxgtk3.0-dev is no longer built by the wxwidgets3.0 source package, and isn't installable in unstable). The removal happened while opencpn was in NEW, so it's never built since being accepted, hence the grace severity - as-is this package is not usable by anyone simply because there's no build of it to install! As well as updating libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, the B-D on libgtk2.0-dev will need updating to libgtk-3-dev. I suspect libgdk-pixbuf2.0-dev will too. There may also be code changes needed to update for API changes between GTK2 and GTK3 if opencpn upstream isn't GTK3 ready. Sorry to be the bearer of bad news. Cheers, Olly
Bug#945345: therion: Missing build-dep on python; build-depend on python3 instead
On Fri, Nov 22, 2019 at 11:30:00PM -0800, Steve Langasek wrote: > Rather than adding a build-dependency on python, which is deprecated, I have > attached a patch which moves the invocation to python3 instead and added a > build-dependency on python3. I do wish upstream would pick a scripting language. There are scripts in python, perl and tcl. Feel free to NMU your fix. Cheers, Olly
Bug#875827: wx-config does not work when --host is passed
Control: reassign -1 libwxgtk3.0-gtk3-dev/3.0.4+dfsg-1 Reassigning - the GTK2 flavour packages are gone from testing and only present in unstable due to a handful of untransitioned rdeps. On Thu, Sep 14, 2017 at 11:03:08PM +0200, Helmut Grohne wrote: > Package: libwxgtk3.0-dev > Version: 3.0.3.1+dfsg-1 > Tags: upstream > Forwarded: https://trac.wxwidgets.org/ticket/12698 > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:mediainfo > > I figured that mediainfo fails to cross build from source, because it > does not find wxWidgets. It invokes wx-config as: > > wx-config --host=$DEB_HOST_GNU_TYPE --unicode=yes --static=no base > --version > > That fails whereas it works after dropping --host: > > | $ WXDEBUG=1 wx-config --host=powerpc64le-linux-gnu --unicode=yes > --static=no base --version > | > | input parameters = base > | libs parameters = > | optional-libs parameters = > | input options = host > | host = powerpc64le-linux-gnu > | yes/no options= unicode static > | unicode = yes > | static = no > | flag options = > | output options= version > | version = yes > | query options = > | > | prefix = '/usr' > | exec_prefix = '/usr' > | wxconfdir= '/usr/lib/powerpc64le-linux-gnu/wx/config' > | m_host = 'powerpc64le-linux-gnu-?' > | m_toolkit= '[^-]+' > | m_widgetset = '(univ)?' > | m_chartype = 'unicode' > | m_debugtype = '(debug|release)' > | m_flavour= '(-[^-]+)?' > | m_version= '[0-9]+\.[0-9]+' > | m_linkage= '' > | configmask = > '^powerpc64le-linux-gnu-?-[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$' > | this config = 'gtk2-unicode-3.0' > | > | must delegate to an alternate config > | potential delegates (0): > | > | Warning: No config found to match: > ^powerpc64le-linux-gnu-?-[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$ > |in /usr/lib/powerpc64le-linux-gnu/wx/config > | If you require this configuration, please install the desired > | library build. If this is part of an automated configuration > | test and no other errors occur, you may safely ignore it. > | You may use wx-config --list to see all configs available in > | the default prefix. > | > | $ WXDEBUG=1 wx-config --unicode=yes --static=no base --version > | > | input parameters = base > | libs parameters = > | optional-libs parameters = > | input options = > | yes/no options= unicode static > | unicode = yes > | static = no > | flag options = > | output options= version > | version = yes > | query options = > | > | prefix = '/usr' > | exec_prefix = '/usr' > | wxconfdir= '/usr/lib/powerpc64le-linux-gnu/wx/config' > | m_host = '' > | m_toolkit= '[^-]+' > | m_widgetset = '(univ)?' > | m_chartype = 'unicode' > | m_debugtype = '(debug|release)' > | m_flavour= '(-[^-]+)?' > | m_version= '[0-9]+\.[0-9]+' > | m_linkage= '' > | configmask = '^[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$' > | this config = 'gtk2-unicode-3.0' > | > | using this config > | 3.0.3 > | user supplied libs: '' > | fetching lib flags for: '' > | retrieved: ldflags = > | wxlibs = > | alllibs = > | > | using libs: ' ' > | using_gui = yes > | > | $ > > I believe that mediainfo's use of --host is reasonable and wx-config > should handle the native --host just fine. I noticed the upstream bug this is forwarded too was closed as invalid way back in 2011. It seems unlikely upstream will fix this without prodding, so we probably should reopen the upstream bug and provide an explanation for why this should work. But reviewing your report I'm confused. Is this really a cross-build or not? You say "native --host", which seems to imply it's not really a cross-build but a native build with --host=`./config.guess` or something similar, and that is indeed what the upstream bug report this bug is forwarded to is complaining doesn't work. But looking at mediainfo's ./Project/GNU/GUI/wxwin.m4 it seems we must be triggering this conditional appending: if test "$cross_compiling" = "yes"; then wx_config_args="$wx_config_args --host=$host_alias" fi So it seems that mediainfo's configure script thinks we are cross-compiling. I checked the crossqa logs for mediainfo, but they show a failure due to libzen, not wx: configure: error: libzen configuration is not found http://crossqa.debian.net/build/mediainfo_18.12-2.1_ppc64el_20191016050307.log Cheers, Olly
Bug#894663: transition: wxwidgets3.0
On Fri, Oct 25, 2019 at 09:27:48AM +1300, Olly Betts wrote: > On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote: > > * mrpt was updated but the build failed on mipsel due to running out of > > memory and it's now entangled in auto-opencv. But it's due for AUTORM > > on 2019-10-28 so that should resolve itself within a week. > > No change here. The AUTORM happened for mrpt. > However, checking with "dak rm" on coccia, I discovered four packages > which build-depend on libwxgtk3.0-dev but without a resulting runtime > dependency. I've filed bugs against these and set them as blocking this > bug. They should at least be easy to address. Fixes for these extra four have now been uploaded and checking again: olly@coccia:~$ dak rm -Rn -b libwxgtk3.0-dev [...] # Broken Depends: wxsvg: libwxsvg-dev wxwidgets3.0: libwxgtk-media3.0-dev # Broken Build-Depends: amule: libwxgtk3.0-dev codeblocks: libwxgtk3.0-dev cubicsdr: libwxgtk3.0-dev objcryst-fox: libwxgtk3.0-dev pcsx2: libwxgtk3.0-dev sooperlooper: libwxgtk3.0-dev treesheets: libwxgtk3.0-dev ucblogo: libwxgtk3.0-dev wxsvg: libwxgtk3.0-dev Which is just the packages which are only in unstable, so aren't blockers. The codeblocks maintainers never responded, but taffit is preparing an update to the latest upstream release so that at least should be off the list fairly soon. I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I think we can consider this transition complete. I'll leave actually closing this bug to someone on the release team in case I've missed something. Upstream wx are making noises about actually releasing 3.2 early next year, so we may have another wx transition before bullseye. We've managed to prune many of the rdeps which are inactive upstream and unmaintained in Debian, so the next one should hopefully be less work. Cheers, Olly
Bug#921136: lintian: hardening-no-fortify-functions possible false positive
On Tue, Oct 29, 2019 at 11:05:02PM -0400, Scott Talbert wrote: > On Wed, 30 Oct 2019, Olly Betts wrote: > > > The same issue applies to memcpy() which is why it's deliberately from > > lintian's list: > > > > https://sources.debian.org/src/lintian/2.31.0/data/binaries/hardened-functions/?hl=6#L6 > > > > Presumably wmemcpy() is simply much less widely used than memcpy(), and > > that's the only reason it's not also omitted already. > > Thanks for the details, Olly. So, what you're saying is that wmemcpy should > be excluded from hardened-functions? Yes. Probably wmemset and wmemmove should be too. The history of this seems to be in #673112 (don't be misled by the bug title!) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112#67 suggests that perhaps recvfrom, recv and read ought to be as well. The whole approach seems a bit flawed though - the hardening-no-fortify-functions description says: | Either there are no potentially unfortified functions called by any | routines, all unfortified calls have already been fully validated at | compile-time, or the package was not built with the default Debian | compiler flags defined by dpkg-buildflags One of the first two cases seems to often be true for a lot of C++ code. I thought I read ages ago about an idea to record the hardening flags as notes in the compiled files, which seemed a much more satisfactory approach, but I guess nothing ever came of it. Cheers, Olly
Bug#921136: lintian: hardening-no-fortify-functions possible false positive
Control: tags -1 -moreinfo
On Sat, Feb 16, 2019 at 12:26:36AM +0100, Chris Lamb wrote:
> I will thus leave this bug as "moreinfo" awaiting input from others.
What's presumably happening here is that the size of the destination
buffer and size of the copy are known, so it's clear at compile time
that the compile can't overflow.
E.g.:
$ cat wmemcpy-test.cc
#include
wchar_t buf[10];
void f(const wchar_t* p, int n) {
#ifdef FIXED_LENGTH
(void)n;
wmemcpy(buf, p, 6);
#else
wmemcpy(buf, p, n);
#endif
}
$ g++ -Wall -W -D_FORTIFY_SOURCE=2 -O2 -S wmemcpy-test.cc -o -
.file "wmemcpy-test.cc"
.text
.p2align 4
.globl _Z1fPKwi
.type _Z1fPKwi, @function
_Z1fPKwi:
.LFB26:
.cfi_startproc
movslq %esi, %rdx
movl$10, %ecx
movq%rdi, %rsi
leaqbuf(%rip), %rdi
jmp __wmemcpy_chk@PLT
.cfi_endproc
.LFE26:
.size _Z1fPKwi, .-_Z1fPKwi
.globl buf
.bss
.align 32
.type buf, @object
.size buf, 40
buf:
.zero 40
.ident "GCC: (Debian 9.2.1-8) 9.2.1 20190909"
.section.note.GNU-stack,"",@progbits
But if the lengths are both known:
$ g++ -Wall -W -D_FORTIFY_SOURCE=2 -DFIXED_LENGTH -O2 -S wmemcpy-test.cc -o -
.file "wmemcpy-test.cc"
.text
.p2align 4
.globl _Z1fPKwi
.type _Z1fPKwi, @function
_Z1fPKwi:
.LFB26:
.cfi_startproc
movq%rdi, %rsi
movl$6, %edx
leaqbuf(%rip), %rdi
jmp wmemcpy@PLT
.cfi_endproc
.LFE26:
.size _Z1fPKwi, .-_Z1fPKwi
.globl buf
.bss
.align 32
.type buf, @object
.size buf, 40
buf:
.zero 40
.ident "GCC: (Debian 9.2.1-8) 9.2.1 20190909"
.section.note.GNU-stack,"",@progbits
The key difference here is:
< jmp __wmemcpy_chk@PLT
---
> jmp wmemcpy@PLT
The same issue applies to memcpy() which is why it's deliberately from
lintian's list:
https://sources.debian.org/src/lintian/2.31.0/data/binaries/hardened-functions/?hl=6#L6
Presumably wmemcpy() is simply much less widely used than memcpy(), and
that's the only reason it's not also omitted already.
Cheers,
Olly
