Bug#1077514: marked as done (survex FTBFS on i386 with gcc 14)

[Olly Betts]

Control: reopen -1
Control: found -1 1.4.10-2

On Mon, Aug 12, 2024 at 03:57:03AM +, Debian Bug Tracking System wrote:
>  + Fixes i386 test failures due to excess precision. (Closes: #1077514)

Unfortunately there's a new issue in a testcase that was added in the
new upstream release.  I'll take a look at what's going on there.

I'm rather loathe to just apply the -ffloat-store hammer as it's really
just hiding problems, and imposes a significant performance overhead,
albeit on platforms which are declining in use.  It doesn't even
fully fix the problem, as you still get rounding at different points
in calculations.

Cheers,
Olly

Bug#1068599: ruby-xapian - still depends on old libruby3.1 after binnmu

[Olly Betts]

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#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory

[Olly Betts]

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#1032398: xapian-core: Risk of database corruption on disk full

[Olly Betts]

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

[Olly Betts]

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#1019781: dolphin-emu: Please transition to wxwidgets3.2

[Olly Betts]

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

[Olly Betts]

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->FindOrCreat

Bug#1019791: stimfit: diff for NMU version 0.16.0-1.2

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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)

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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)

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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
+ 
+@@ 

Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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#1022739: wxwidgets3.0: Do not release with bookworm

[Olly Betts]

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#933438: spek: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

Control: retitle -1 spek: Please transition to wxwidgets3.2

On Tue, Jul 30, 2019 at 10:05:39AM -0400, s...@techie.net wrote:
> Your package appears to be using the wxWidgets GTK 2 implementation.  In 
> Debian, we have had a GTK 3 implementation of wxWidgets for some time.  
> For the bullseye release, the wxWidgets package maintainers plan to 
> remove the GTK 2 version, so we kindly request that you switch your 
> package to use the GTK 3 version.

This transition happened and the GTK-2-using packages of wxwidgets3.0
were removed some time ago.

This bug was closed when spek was removed from unstable - presumably it
was reopened motivated by the ITP for spek (#1007814) to ensure it's
addressed by the reintroduced package, though really it will have to be
addressed because there just isn't a GTK 2 version to build against in
unstable any more.

However we're now in the most of the way through a transition to
wxwidgets3.2 and a bug to ensure a reintroduced package uses that
rather than wxwidgets3.0 does seem useful, so updating the bug to be
for that purpose.

The main build-dependency to use is libwxgtk3.2-dev - if you use
any of the wxWidgets libraries which we have separate binary packages
for you will also need the corresponding libwxgtk-*3.2-dev packages
too.

Transition tracker is:

https://release.debian.org/transitions/html/wxwidgets-3.2.html

Cheers,
Olly

Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable

[Olly Betts]

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

[Olly Betts]

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#1020539: xmlcopyeditor: xml copyeditor fails wxwidgets3.2 sizer checks

[Olly Betts]

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#1015340: xapian-bindings: FTBFS: dh_install: error: missing files, aborting

[Olly Betts]

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#983229: proj transition has started

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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#991064: therion FTBFS with imagemagick with the #987504 change

[Olly Betts]

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#983091: xapian-core FTBFS on i386: test failure

[Olly Betts]

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

[Olly Betts]

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

[Olly Betts]

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#938836: xapian-bindings: Python2 removal in sid/bullseye

[Olly Betts]

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#950402: pinot ftbfs with libexiv2-27

[Olly Betts]

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

[Olly Betts]

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#946018: opencpn: FTBFS due to trying to use removed wx GTK2 flavour

[Olly Betts]

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

[Olly Betts]

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#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Mon, Oct 28, 2019 at 05:15:15PM -0400, Scott Talbert wrote:
> The fpga test failure is also occurring with autopkgtest:
> https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz
> 
> Jussi also mentioned it.  Perhaps it's related to the recent upload of
> fpga-icestorm?

I see meson also FTBFS in reproducible build testing:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html

Given meson already FTBFS in unstable for unrelated reasons and will be
trivial to update to use wxwidgets3.0's GTK3 flavour once that is
addressed, I've made a wxwidgets3.0 upload to drop the GTK2 flavour
packages.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Mon, Oct 28, 2019 at 07:53:24AM +0100, Martin Pitt wrote:
> Olly Betts [2019-10-27 11:52 +1300]:
> > However, then the build fails for me running tests using ccache - the
> > problem is that $HOME is /sbuild-nonexistent under sbuild, which
> > doesn't exist, and cache tries to create its cache under $HOME/.ccache
> > by default.
> 
> I don't have that, but I also have failing tests.

I think this is #935817 - if so it's not tests using ccache that are the
problem, but that meson automatically tries to use ccache if it's
installed, plus mk-sbuild seems to install ccache in chroots.

(That seems a mis-feature to me - the usual ways to use ccache are to
either something like `CC="ccache gcc"`, or to add /usr/lib/ccache to
your PATH ahead of /usr/bin, which both require a concious extra action,
but I think that's a good thing - it's surprising for building some
software to create a persistent hidden directory under your home
directory potentially using a lot of diskspace just because the package
happens to use meson for its build system and you're on a multi-user
system which happens to have ccache installed).

It seems brittle for a build to fail because an extra package is
installed, especially one like ccache which might reasonably have
been added to a chroot to speed up builds.

> > [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1
> > simple/spin.pcf' spin.blif -o spin.asc
> > FAILED: spin.asc 
> > /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf'
> > spin.blif -o spin.asc
> > spin.blif:50: fatal error: invalid formal-actual
> > ninja: build stopped: subcommand failed.
> 
> For me, fpga also fails, but the failure looks different:

I also see that eatmydata seems to cause problems (#917501), which again
is something that might reasonably be in use.  I've been running my
package builds under it for the best part of a decade (including many
NMUs) and this is the first issue I've hit.

I tried temporarily disabling that, but meson still fails to build.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Fri, Oct 25, 2019 at 01:52:31AM +0100, Olly Betts wrote:
> I'll try to sort out my chroots over the weekend, but meanwhile if you
> can get somebody else to sponsor please go for it.

I've rebuilt my build chroots in a larger partition.

However, then the build fails for me running tests using ccache - the
problem is that $HOME is /sbuild-nonexistent under sbuild, which
doesn't exist, and cache tries to create its cache under $HOME/.ccache
by default.

Debian policy says:

| Secondly, required targets may write to
| "/tmp", "/var/tmp" and to the directory specified by the "TMPDIR"
| environment variable, but must not depend on the contents of any of
| these.
|
| This restriction is intended to prevent source package builds creating
| and depending on state outside of themselves, thus affecting multiple
| independent rebuilds.  In particular, the required targets must not
| attempt to write into "HOME".

So the package build really shouldn't assume it can write under the home
directory.

If I add this to debian/rules that avoids that problem:

export CCACHE_DIR=/tmp/ccache

But I still see a number of test failures (sorry about the unhelpful
wrapping):

[58/75] Generating MesonDep2-1.0.gir with a custom command.
FAILED: gir/dep1/dep2/MesonDep2-1.0.gir
/usr/bin/g-ir-scanner -pthread -I/usr/include/gobject-introspection-1.0
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
--no-libtool --namespace=MesonDep2 --nsversion=1.0 --warn-all --output
gir/dep1/dep2/MesonDep2-1.0.gir '-I/<>/test
cases/frameworks/7 gnome/gir/dep1/dep2'
-I/<>/tmpuyjyogvd/gir/dep1/dep2
--filelist=/<>/tmpuyjyogvd/gir/dep1/dep2/7cbf35a@@dep2lib@sha/MesonDep2_1.0_gir_filelist
--include=GObject-2.0 --symbol-prefix=meson --identifier-prefix=Meson
--cflags-begin -DMESON_TEST -fsanitize=address -fno-omit-frame-pointer
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
--cflags-end -lasan --library dep2lib
-L/<>/tmpuyjyogvd/gir/dep1/dep2 --extra-library=gobject-2.0
--extra-library=glib-2.0 --sources-top-dirs '/<>/test
cases/frameworks/7 gnome/subprojects/' --sources-top-dirs
/<>/tmpuyjyogvd/subprojects/
g-ir-scanner: link: x86_64-linux-gnu-gcc -pthread -o
/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0
/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0.o -L.
-Wl,-rpath,. -Wl,--no-as-needed
-L/<>/tmpuyjyogvd/gir/dep1/dep2
-Wl,-rpath,/<>/tmpuyjyogvd/gir/dep1/dep2 -lasan -ldep2lib
-lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic
-lgmodule-2.0 -pthread -lglib-2.0
==19640==ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it
with LD_PRELOAD.
Command
'['/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/MesonDep2-1.0',
'--introspect-dump=/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/functions.txt,/<>/tmpuyjyogvd/tmp-introspect8x4pya0_/dump.xml']'
returned non-zero exit status 1.

(that seems to occur twice?!)

[1/4] ccache cc -Ivalaprog@exe -I. '-I../test cases/failing build/1 vala
c werror' -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always
-pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ
'valaprog@exe/unused-var.c.o' -MF 'valaprog@exe/unused-var.c.o.d' -o
'valaprog@exe/unused-var.c.o' -c '../test cases/failing build/1 vala c
werror/unused-var.c'
FAILED: valaprog@exe/unused-var.c.o 
ccache cc -Ivalaprog@exe -I. '-I../test cases/failing build/1 vala c
werror' -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always
-pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ
'valaprog@exe/unused-var.c.o' -MF 'valaprog@exe/unused-var.c.o.d' -o
'valaprog@exe/unused-var.c.o' -c '../test cases/failing build/1 vala c
werror/unused-var.c'
../test cases/failing build/1 vala c werror/unused-var.c:1:2: error:
#warning "something" [-Werror=cpp]
1 | #warning "something"
  |  ^~~
  ../test cases/failing build/1 vala c werror/unused-var.c: In
  function ‘somelib’:
  ../test cases/failing build/1 vala c werror/unused-var.c:6:7:
  error: unused variable ‘unused_var’ [-Werror=unused-variable]
  6 |   int unused_var;
|   ^~
cc1: all warnings being treated as errors

[5/5] cc  -o bobuser 'bobuser@exe/bobuser.c.o' -Wl,--as-needed
-Wl,--no-undefined -

Bug#922586: FTBFS against opencv 4.0.1 (exp)

[Olly Betts]

On Sat, Oct 26, 2019 at 10:39:47PM +0200, José Luis Blanco-Claraco wrote:
> However, I want to point out that we don't need to wait for
> mrpt-2.0.0, since the current version in unstable (1.5.8) already
> fixes this wxwidgets3.0-gtk3 bug.
> As you said, the problem now is the build issue in mipsel...
> I wrote an email to ftpmasters 12 days ago requesting the deletion of
> mrpt-1.x.x for mipsel, so we could go on quickly ago, but had no
> response yet.

It would need the mipsel build deleting from testing, which is the
domain of the release team, not ftpmaster.  I actually suggested doing
this to the release team on October 18th, but they preferred letting the
AUTORM kick in.

The other option would have been to request a "giveback" - i.e. ask
the mipsel buildd to try again.  I tried to trigger one via the new
self-service giveback mechanism, but my client certificate has expired
and firefox has dropped the feature which used to allow creating one
easily.  Then the auto-opencv transition started before I got around
to creating a new client certificate the hard way.

> Perhaps a patch in debian/control to specify that we want mrpt-1.5.8
> to get built on all archs except mipsel?

That wouldn't help - there's already a mipsel build in testing so
the testing migration will decide not to update if there's no
mipsel build for the new version.  Hence my attempt to get the 
release team to manually remove the mipsel build from testing.

On Sat, Oct 26, 2019 at 10:46:19PM +0200, José Luis Blanco-Claraco wrote:
> Ok, sorry, forgot my last message, you already mentioned the new problem:
> 
> > But now that missing mipsel build can't be addressed without
> > also updating mrpt for auto-opencv because it currently FTBFS in
> > unstable.
> 
> It's a shame, but I think that perhaps I'll just leave mrpt to be
> removed from testing.

I think it's pretty much unavoidable at this point.  But there's
plenty of time before bullseye for it to return.

> Anyway, mrpt-2 comes with many different
> packages so (if I recall it right...) the procedure would be similar,
> it will have to go through the "New queue" (sigh).

An existing source package gaining new binary packages ("binary NEW") is
usually processed more quickly (because it doesn't need a full licensing
review - it's mostly an "is this actually sensible" check).

If something being in binary NEW is blocking progress on a transition
you can usually get it processed sooner by asking nicely in #debian-ftp
and explaining succinctly what the reason is.  I did that for openbabel
and limesuite which were in binary NEW and holding up uploads for the
wxwidgets3.0-gtk transition.

> Right now, addressing all the opencv4 changes in the mrpt-1.x branch
> would take me too much time, which will be better invested in going
> for the 2.0.0 version.

Yes, that sounds sensible.

Cheers,
Olly

Bug#922586: FTBFS against opencv 4.0.1 (exp)

[Olly Betts]

On Thu, Oct 24, 2019 at 12:48:08AM +0200, Gianfranco Costamagna wrote:
> the package is going to get kicked out from testing because of this
> bug soon...

It's actually #933469 which will get it auto-removed from testing in
next few days - the AUTORM for this bug wouldn't kick in for a couple
of weeks (at least based on my understanding of the system).

Unfortunately there was a missing mipsel build (because the buildd ran
out of memory) but the auto-opencv transition started before that was
resolved.  But now that missing mipsel build can't be addressed without
also updating mrpt for auto-opencv because it currently FTBFS in
unstable.

> > This problem is already solved upstream in the forthcoming mrpt-2.0.0
> > version. I'm marking this as "fixed-upstream" in the meanwhile.

It was waiting for mrpt 2.0.0 for wxwidgets3.0-gtk3 that got us into the
current mess of having two entangled transitions on the go for mrpt.  If
we'd just updated the B-Ds of the existing package we'd have got that
out the way weeks (possibly months) ago.  Instead mrpt is now the final
package blocking wxwidgets3.0-gtk3's completion.

I understand it's tempting when you're both upstream maintainer and
Debian maintainer to try to do everything via new upstream releases
(it's a trap I've fallen into myself), but there are situations where
just fixing it in Debian really is the better option.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Thu, Oct 24, 2019 at 10:12:08PM +0100, Olly Betts wrote:
> On Fri, Oct 25, 2019 at 12:02:11AM +0300, Jussi Pakkanen wrote:
> > https://mentors.debian.net/package/meson
> > 
> > Feel free to upload it to the archive.
> 
> Thanks for the quick response.  Building now.

It seems this package requires more diskspace to build than my build
chroot partition has (or perhaps I've just managed to break my chroot
recently).

I'll try to sort out my chroots over the weekend, but meanwhile if you
can get somebody else to sponsor please go for it.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

Control: tags -1 +pending

On Fri, Oct 25, 2019 at 12:02:11AM +0300, Jussi Pakkanen wrote:
> On Thu, Oct 24, 2019 at 11:03 PM Olly Betts  wrote:
> 
> > However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
> > your package has a build-dependency on libwxgtk3.0-dev which doesn't
> > result in any shlib dependencies in the built packages.  If this package
> > is not actually used this build dependency should be dropped; if it's
> > used during the build then you want to update to use
> > libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency,
> > please debug!
> 
> The reason for this is that Meson only needs wxwidgets to build and
> execute its unit tests. They are not installed or used, because we
> only test that people can find and build against wxwidgets libraries.
> 
> I have updated the packaging to use the new package. It can be found in 
> mentors:
> 
> https://mentors.debian.net/package/meson
> 
> Feel free to upload it to the archive.

Thanks for the quick response.  Building now.

> You should note that the FPGA tests don't pass now. This has nothing
> to do with this change, it seems that Icestorm packages are broken in
> some way.

Presumably these are autopkgtests rather than tests run during the
package build?

Cheers,
Olly

Bug#943439: src:asc: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

Package: src:asc
Version: 2.6.1.0-5
Severity: serious
Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition

According to the transition tracker, the wxwidgets3.0-gtk3 transition is
96% and the only remaining blockers are a missing mips64el build of
codelite (currently building) and a missing mipsel build of mrpt (due
for AUTORM from testing on 2019-10-28):

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
your package has a build-dependency on libwxgtk3.0-dev which doesn't
result in any libwxgtk* shlib dependencies in the built packages.

The asc binary package does get a dependency on libwxbase3.0-0v5,
which suggests that your package should actually build-depend on
libwxbase3.0-dev.  However trying a build with that change it fails
due to not finding autotools macros 'AM_OPTIONS_WXCONFIG' and
'AM_PATH_WXCONFIG', so the correct fix is to update your package to
use libwxgtk3.0-gtk3-dev instead.

Let me know if you'd like me to NMU a fix for this.

Cheers,
Olly

Bug#943440: src:grass: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

Package: src:grass
Version: 7.8.0-1
Severity: serious
Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition

According to the transition tracker, the wxwidgets3.0-gtk3 transition is
96% and the only remaining blockers are a missing mips64el build of
codelite (currently building) and a missing mipsel build of mrpt (due
for AUTORM from testing on 2019-10-28):

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
your package has a build-dependency on libwxgtk3.0-dev which doesn't
result in any shlib dependencies in the built packages.  If this package
is not actually used this build dependency should be dropped; if it's
used during the build then you want to update to use
libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency,
please debug!

Let me know if you'd like me to NMU a fix for this.

Cheers,
Olly

Bug#943438: src:icinga2: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

Package: src:icinga2
Version: 2.11.1-2~exp1
Severity: serious
Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition

According to the transition tracker, the wxwidgets3.0-gtk3 transition is
96% and the only remaining blockers are a missing mips64el build of
codelite (currently building) and a missing mipsel build of mrpt (due
for AUTORM from testing on 2019-10-28):

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
your package has a build-dependency on libwxgtk3.0-dev which doesn't
result in any shlib dependencies in the built packages.  If this package
is not actually used this build dependency should be dropped; if it's
used during the build then you want to update to use
libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency,
please debug!

Let me know if you'd like me to NMU a fix for this.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

Package: src:meson
Version: 0.52.0-1
Severity: serious
Justification: blocks the almost-complete wxwidgets3.0-gtk3 transition

According to the transition tracker, the wxwidgets3.0-gtk3 transition is
96% and the only remaining blockers are a missing mips64el build of
codelite (currently building) and a missing mipsel build of mrpt (due
for AUTORM from testing on 2019-10-28):

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
your package has a build-dependency on libwxgtk3.0-dev which doesn't
result in any shlib dependencies in the built packages.  If this package
is not actually used this build dependency should be dropped; if it's
used during the build then you want to update to use
libwxgtk3.0-gtk3-dev instead; if it should result in a shlib dependency,
please debug!

Let me know if you'd like me to NMU a fix for this.

Cheers,
Olly

Bug#933416: filezilla: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Tue, Oct 22, 2019 at 08:32:57AM +1300, Olly Betts wrote:
> https://qa.debian.org/cgi-bin/vcswatch?package=filezilla shows you
> apparently prepared a new upload including a fix for this about 3.5
> weeks ago, but it seems this hasn't actually been uploaded.

I just noticed your previous filezilla uploads were sponsored.  If the
reason this didn't get uploaded yet is just lack of a sponsor I'm happy
to sponsor this upload (unless Gianfranco would prefer to - Cc-ed).

Cheers,
Olly

Bug#933416: filezilla: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

Hi Adrien,

Thanks for you work maintaining filezilla in Debian.

On Tue, Jul 30, 2019 at 10:05:03AM -0400, s...@techie.net wrote:
> Your package appears to be using the wxWidgets GTK 2 implementation.  In
> Debian, we have had a GTK 3 implementation of wxWidgets for some time. 
> For the bullseye release, the wxWidgets package maintainers plan to
> remove the GTK 2 version, so we kindly request that you switch your
> package to use the GTK 3 version.  We have a transition tracker [1]
> setup to track progress.

We're now down to the last 3 packages in this transition.  One of those
is filezilla, and the other two should be resolved by the end of this
month.

https://qa.debian.org/cgi-bin/vcswatch?package=filezilla shows you
apparently prepared a new upload including a fix for this about 3.5
weeks ago, but it seems this hasn't actually been uploaded.

What are your plans for resolving this release-critical bug?

Cheers,
Olly

Bug#933415: openbabel: diff for NMU version 2.4.1+dfsg-5.1

[Olly Betts]

Dear maintainer,

I've uploaded an NMU for openbabel (versioned as 2.4.1+dfsg-5.1) for the
wxwidgets3.0-gtk3 transition.  The debdiff is attached.

Cheers,
Olly
diff -Nru openbabel-2.4.1+dfsg/debian/changelog openbabel-2.4.1+dfsg/debian/changelog
--- openbabel-2.4.1+dfsg/debian/changelog	2019-10-15 18:20:55.0 +1300
+++ openbabel-2.4.1+dfsg/debian/changelog	2019-10-21 08:30:01.0 +1300
@@ -1,3 +1,10 @@
+openbabel (2.4.1+dfsg-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update to use GTK3 flavour of wxwidgets3.0. (Closes: #933415)
+
+ -- Olly Betts   Mon, 21 Oct 2019 08:30:01 +1300
+
 openbabel (2.4.1+dfsg-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru openbabel-2.4.1+dfsg/debian/control openbabel-2.4.1+dfsg/debian/control
--- openbabel-2.4.1+dfsg/debian/control	2019-10-15 18:20:55.0 +1300
+++ openbabel-2.4.1+dfsg/debian/control	2019-10-21 08:30:01.0 +1300
@@ -11,7 +11,7 @@
libcairo2-dev,
libeigen3-dev,
libperl-dev,
-   libwxgtk3.0-dev (>= 3.0.2+dfsg-1ubuntu1),
+   libwxgtk3.0-gtk3-dev,
libxml2-dev,
pkg-config,
python3-all-dev,

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Olly Betts]

On Fri, Oct 18, 2019 at 07:47:01AM +1300, Olly Betts wrote:
> That helped, but qhull_a.h is also included elsewhere without this
> workaround which caused my upload to FTBFS on ppc64el.  I've extended
> the patch to cover that case too and uploaded again.

My second upload built successfully on all release architectures.

Attached is the debdiff for the combined changes from my NMUs.

Cheers,
Olly
diff -Nru 3depict-0.0.22/debian/changelog 3depict-0.0.22/debian/changelog
--- 3depict-0.0.22/debian/changelog 2019-10-05 08:19:56.0 +1300
+++ 3depict-0.0.22/debian/changelog 2019-10-18 07:39:16.0 +1300
@@ -1,3 +1,18 @@
+3depict (0.0.22-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix another problem causing FTBFS on ppc64el.
+
+ -- Olly Betts   Fri, 18 Oct 2019 07:39:16 +1300
+
+3depict (0.0.22-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on ppc64el, new patch: undefine-__POWERPC__.patch
+(Closes: #942113)
+
+ -- Olly Betts   Thu, 17 Oct 2019 16:44:15 +1300
+
 3depict (0.0.22-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 3depict-0.0.22/debian/patches/series 
3depict-0.0.22/debian/patches/series
--- 3depict-0.0.22/debian/patches/series2019-10-05 08:19:56.0 
+1300
+++ 3depict-0.0.22/debian/patches/series2019-10-17 16:47:17.0 
+1300
@@ -2,3 +2,4 @@
 debian-desktop-naming.patch
 lowercase-textdomain.patch
 desktop-category.patch
+undefine-__POWERPC__.patch
diff -Nru 3depict-0.0.22/debian/patches/undefine-__POWERPC__.patch 
3depict-0.0.22/debian/patches/undefine-__POWERPC__.patch
--- 3depict-0.0.22/debian/patches/undefine-__POWERPC__.patch1970-01-01 
12:00:00.0 +1200
+++ 3depict-0.0.22/debian/patches/undefine-__POWERPC__.patch2019-10-18 
07:31:35.0 +1300
@@ -0,0 +1,41 @@
+Description: Undefine __POWERPC__ if wxWidgets defined it
+ Upstream attempts to work around this problem by defining __POWERPC__ to 1
+ but that breaks compilation too.  Undefine instead, to restore us to the state
+ that GCC is in before wxWidgets messes things up, since that's the state Qhull
+ should expect.  
+ .
+ In spatial.cpp, the header is only included to check a type size under __WIN64
+ so there it's simpler to just conditionalise the include.
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/942113
+Forwarded: no
+Last-Update: 2019-10-18
+
+--- a/src/backend/filters/algorithms/convexHull.h
 b/src/backend/filters/algorithms/convexHull.h
+@@ -31,7 +31,12 @@
+   //assigning a value, causing build fail on powerpc
+   #ifdef __POWERPC__
+   #pragma push_macro("__POWERPC__")
+-  #define __POWERPC__ 1
++  // Defining to 1 also causes build to fail on check:
++  // #if __MWERKS__ && __POWERPC__
++  // Undefine instead, to restore us to the state that
++  // GCC is in before wxWidgets messes things up, since
++  // that's the state Qhull should expect.
++  #undef __POWERPC__
+   #endif
+   extern "C"
+   {
+--- a/src/backend/filters/algorithms/spatial.cpp
 b/src/backend/filters/algorithms/spatial.cpp
+@@ -26,7 +26,9 @@
+ #include 
+ #include 
+ 
++#if defined(__WIN64) && !defined(HAVE_SWEEP_HULL)
+ #include 
++#endif
+ 
+ using std::vector;
+ 

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Olly Betts]

On Thu, Oct 17, 2019 at 04:52:58PM +1300, Olly Betts wrote:
> Aha!  wxWidgets "helpfully" defines __POWERPC__ for us on ppc64el, but
> to an empty value.  Then 3depict has a workaround to define it to 1 if
> it is defined, because that empty value breaks Qhull.
> 
> This bug has been open 7 days without a maintainer response now, so
> I'm going to NMU a patch to undefine __POWERPC__ instead, which seems
> a better solution since Qhull won't expect GCC to define it anyway.

That helped, but qhull_a.h is also included elsewhere without this
workaround which caused my upload to FTBFS on ppc64el.  I've extended
the patch to cover that case too and uploaded again.

Cheers,
Olly

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Olly Betts]

Control: tags -1 + pending

On Thu, Oct 17, 2019 at 04:12:35PM +1300, Olly Betts wrote:
> And why does this only cause an error on one architecture?  I downloaded
> and compared the headers in the amd64 and ppc64el libqhull-dev packages
> and they're identical.  If neither __MWERKS__ nor __POWERPC__ are
> defined on ppc64el then the same situation should exist on amd64.  If
> __POWERPC__ *is* defined on ppc64el that could be a difference - I can't
> connect to the ppc64el porterbox to check though.

Aha!  wxWidgets "helpfully" defines __POWERPC__ for us on ppc64el, but
to an empty value.  Then 3depict has a workaround to define it to 1 if
it is defined, because that empty value breaks Qhull.

This bug has been open 7 days without a maintainer response now, so
I'm going to NMU a patch to undefine __POWERPC__ instead, which seems
a better solution since Qhull won't expect GCC to define it anyway.

Cheers,
Olly

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Olly Betts]

On Wed, Oct 16, 2019 at 11:30:47AM +0200, Thierry fa...@linux.ibm.com wrote:
> I've personally always used __powerpc__ .
> Here is my reference, very useful for all arch related defines :
> https://wiki.debian.org/ArchitectureSpecificsMemo

That page documents what's defined by GCC on Debian, but this check is
for the metroworks compiler, so to fix this properly the question is
really what that compiler defines on powerpc platforms.

But looking more closely, I think this probably should be a defined-ness
check:

#if defined __MWERKS__ && defined __POWERPC__

But also, I see this code is in a header from a different package
(libqhull-dev) so it seems this is really a bug in that.

I would reassign, but I'm wondering if I'm missing something here -
qhull was last uploaded in 2017 and ten other packages build-depend on
libqhull-dev, so why aren't they all FTBFS on ppc64el too?

$ reverse-depends -b libqhull-dev
Reverse-Build-Depends
=
* 3depict
* gdal
* getfem++
* gnudatalanguage
* meshlab
* octave
* pcl
* plplot
* pymca
* ros-geometric-shapes
* saga

And why does this only cause an error on one architecture?  I downloaded
and compared the headers in the amd64 and ppc64el libqhull-dev packages
and they're identical.  If neither __MWERKS__ nor __POWERPC__ are
defined on ppc64el then the same situation should exist on amd64.  If
__POWERPC__ *is* defined on ppc64el that could be a difference - I can't
connect to the ppc64el porterbox to check though.  But testing this on
amd64 I get no error anyway:

#if __MWERKS__ && __amd64__

Cheers,
Olly

Bug#933426: mediainfo: diff for NMU version 18.12-2.1

[Olly Betts]

Control: tags 933426 + patch

Dear maintainer,

I've uploaded an NMU for mediainfo (versioned as 18.12-2.1).  A debdiff
of the changes is attached.

Cheers,
Olly
diff -Nru mediainfo-18.12/debian/changelog mediainfo-18.12/debian/changelog
--- mediainfo-18.12/debian/changelog	2018-12-27 20:29:43.0 +1300
+++ mediainfo-18.12/debian/changelog	2019-10-15 15:57:11.0 +1300
@@ -1,3 +1,11 @@
+mediainfo (18.12-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Update to build using libwxgtk3.0-gtk3-dev.
+(Closes: #933426)
+
+ -- Olly Betts   Tue, 15 Oct 2019 15:57:11 +1300
+
 mediainfo (18.12-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru mediainfo-18.12/debian/control mediainfo-18.12/debian/control
--- mediainfo-18.12/debian/control	2018-12-27 20:29:43.0 +1300
+++ mediainfo-18.12/debian/control	2019-10-15 15:57:08.0 +1300
@@ -6,7 +6,7 @@
dh-autoreconf,
libmediainfo-dev (>= 0.7.61),
libzen-dev (>= 0.4.25),
-   libwxgtk3.0-dev,
+   libwxgtk3.0-gtk3-dev,
zlib1g-dev,
pkg-config,
rename

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

Control: tags -1 + pending

On Mon, Oct 14, 2019 at 09:16:36PM +0100, Olly Betts wrote:
> On Mon, Oct 14, 2019 at 09:07:40PM +0100, da...@codelite.co.uk wrote:
> > Yes, I actually uploaded one today (#942313). However that seems to be 
> > broken
> > by libwxsqlite3-3.0-dev, which still Depends on the GTK+2 wx dev package. 
> > As a
> > result both flavours are installed, and Alternatives selects the GTK+2 one.
> > I'll report this bug.
> 
> Oops.  It probably makes more sense for us to just reopen the wx
> transition bug for it (#933470) since that wasn't actually fully
> addressed.  I'll do that.

The libwxsqlite3-3.0-dev has responded quickly and uploaded a fix.

Cheers,
Olly

Bug#933470: wxsqlite3: Incomplete fix for Bug#933470

[Olly Betts]

On Mon, Oct 14, 2019 at 11:35:11PM +0200, László Böszörményi (GCS) wrote:
> On Mon, Oct 14, 2019 at 10:30 PM Olly Betts  wrote:
> > This change was incomplete - libwxsqlite3-3.0-dev still depends on
> > libwxgtk3.0-dev (which should now be libwxgtk3.0-gtk3-dev):
> >
> > https://sources.debian.org/src/wxsqlite3/3.4.1%7Edfsg-4/debian/control/#L46
> Just to be exact sure. All you need is
> s/libwxgtk3.0-dev/libwxgtk3.0-gtk3-dev/ right?

Yes, that should be all that's needed here.

> I can do that with a MU.

That would be great.

Cheers,
Olly

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Mon, Oct 14, 2019 at 09:07:40PM +0100, da...@codelite.co.uk wrote:
> >It's been 2 months now - are you still planning to make a QA upload?
> >I went through a couple of weeks ago and filed bugs suggesting removal
> >of the wxwidgets3.0 rdeps which appeared to be unmaintained, which I
> >included codelite in:
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941616
> >But I didn't make the connection with this thread until I went through
> >checking on the remaining packages today.
> 
> Yes, I actually uploaded one today (#942313). However that seems to be broken
> by libwxsqlite3-3.0-dev, which still Depends on the GTK+2 wx dev package. As a
> result both flavours are installed, and Alternatives selects the GTK+2 one.
> I'll report this bug.

Oops.  It probably makes more sense for us to just reopen the wx
transition bug for it (#933470) since that wasn't actually fully
addressed.  I'll do that.

> > If you're going to fix the package I won't push for removal.
> 
> It would be great if it could be delayed until this is sorted out.

OK, I'll close it since a fix is on the way.

Cheers,
Olly

Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package

[Olly Betts]

On Tue, Aug 13, 2019 at 02:00:43PM +0100, da...@codelite.co.uk wrote:
> Olly Betts wrote:
> >It looks like a newer upstream version addresses this as
> >https://wiki.codelite.org/pmwiki.php/Main/ReleaseNotesCodeLite13 says:
> >
> >| Make CodeLite compile and run against GTK3
> >
> >I think upgrading to a new major upstream version is beyond what I'm
> >comfortable doing in a QA upload.
> >
> >I'm cc-ing David Hart who seems to be part of upstream and made a QA
> >upload to update to a new upstream version earlier this year.
> >
> >David: Are you able to take care of updating to codelite 13.x and
> >switching to GTK3?
> 
> Thank you for the notification. Yes, unless a new maintainer miraculously
> appears, I'll do a QA upload of a GTK3-based codelite 13. I hope I'll
> have time in the next few weeks.

It's been 2 months now - are you still planning to make a QA upload?

I went through a couple of weeks ago and filed bugs suggesting removal
of the wxwidgets3.0 rdeps which appeared to be unmaintained, which I
included codelite in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941616

But I didn't make the connection with this thread until I went through
checking on the remaining packages today.  If you're going to fix
the package I won't push for removal.

Cheers,
Olly

Bug#886835: Should sitplus package be droped from Debian (Was: Bug#886835: sitplus fails to start because GTK+ 2.x and GTK+ 3 in the same process is not supported)

[Olly Betts]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: sitplus -- RoM; very low popcon; broken

On Thu, Oct 10, 2019 at 10:18:51PM +0200, Andreas Tille wrote:
> On Fri, Oct 11, 2019 at 09:07:38AM +1300, Olly Betts wrote:
> > 
> > It's more than a year later - has anyone shown interest in updating
> > sitplus?
> > 
> > If not, I propose to reassign this bug as an RM with ftpmaster.  The
> > package can be updated and reintroduced should somebody step forward
> > to do the work (and a new library package means it would need a trip
> > through NEW either way).
> > 
> > I realise letting go of a package is often not easy, but having a broken
> > package in unstable doesn't benefit anyone, wastes the time of unstable
> > users who try to install it only to discover it doesn't even run, and
> > incurs a cost to people managing transitions - e.g. #915592, #922597,
> > #933424.
>
> Just go for it.  Kind regards, Andreas.

Thanks for the quick confirmation - given that I've marked it as "RoM".

Cheers,
Olly

Bug#886835: Should sitplus package be droped from Debian (Was: Bug#886835: sitplus fails to start because GTK+ 2.x and GTK+ 3 in the same process is not supported)

[Olly Betts]

On Wed, Aug 01, 2018 at 04:26:18PM +1200, Olly Betts wrote:
> On Wed, Jan 10, 2018 at 04:47:48PM +0100, Luis Rivas wrote:
> > On 10 January 2018 at 13:46, Andreas Tille  wrote:
> > > just a note for sitplus:  This package definitely needs more love.
> > > Upstream has released a new version a long time ago but it has split a
> > > separate library which needs to be packaged separately.
> > >
> > > I'm personally lacking the time resources to care for this package.
> > >
> > > Any volunteer or is it possibly better to drop the package at all
> > > if it is not running?
> > 
> > I'm afraid I don't have the time for taking care of this package. So,
> > unless someone else volunteers, probably it's for the better to drop
> > the package for now.
> 
> I suspect this particular issue would be fixed by updating the wxWidgets
> build-dependency from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev (the
> former uses GTK+ 2.x, the latter GTK+ 3.x), though if nobody's able to
> look after the package properly, perhaps it's better to drop it.

It's more than a year later - has anyone shown interest in updating
sitplus?

If not, I propose to reassign this bug as an RM with ftpmaster.  The
package can be updated and reintroduced should somebody step forward
to do the work (and a new library package means it would need a trip
through NEW either way).

I realise letting go of a package is often not easy, but having a broken
package in unstable doesn't benefit anyone, wastes the time of unstable
users who try to install it only to discover it doesn't even run, and
incurs a cost to people managing transitions - e.g. #915592, #922597,
#933424.

Cheers,
Olly

Bug#933440: munipack: diff for NMU version 0.5.11-2.1

[Olly Betts]

Control: tags 933440 + patch
Control: tags 933440 + pending

Dear maintainer,

I've uploaded an NMU for munipack (versioned as 0.5.11-2.1).  The
debdiff is attached.  It's exactly the same as that I debdiff I sent
before except I've touched the date on the debian/changelog entry.

Cheers,
Olly
diff -Nru munipack-0.5.11/debian/changelog munipack-0.5.11/debian/changelog
--- munipack-0.5.11/debian/changelog	2019-01-28 07:45:05.0 +1300
+++ munipack-0.5.11/debian/changelog	2019-10-07 12:09:32.0 +1300
@@ -1,3 +1,10 @@
+munipack (0.5.11-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against GTK+3 flavour of wxWidgets (Closes: #933440)
+
+ -- Olly Betts   Mon, 07 Oct 2019 12:09:32 +1300
+
 munipack (0.5.11-2) unstable; urgency=medium
 
   * Bugfix: ftbfs with ld --as-needed, thx to M. Klose. (Closes: #920426)
diff -Nru munipack-0.5.11/debian/control munipack-0.5.11/debian/control
--- munipack-0.5.11/debian/control	2019-01-25 06:05:50.0 +1300
+++ munipack-0.5.11/debian/control	2019-08-01 13:25:52.0 +1200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Astronomy Team 
 Uploaders: Filip Hroch 
-Build-Depends: debhelper (>= 11), gfortran, g++ (>= 6), libcfitsio-dev, libwxgtk3.0-dev, minpack-dev, liboakleaf-dev
+Build-Depends: debhelper (>= 11), gfortran, g++ (>= 6), libcfitsio-dev, libwxgtk3.0-gtk3-dev, minpack-dev, liboakleaf-dev
 Standards-Version: 4.3.0
 Homepage: http://munipack.physics.muni.cz/
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/munipack

Bug#940687: ucblogo: Missing corresponding source for configure

[Olly Betts]

Source: ucblogo
Version: 6.0+dfsg-2
Severity: serious
Tags: upstream
Justification: Policy 2.1.2

I noticed this comment in debian/rules:

# don't autoreconf, as configure is newer than configure.in
# -> configure.in doesn't contain wxwidgets related checks
dh $@ --without autoreconf

I've checked and this comment still seems to be correct for the current
package in unstable.

But that means we don't actually have the source code for configure,
which is required by DFSG2.

GPL2 (which is upstream's licence) also requires "complete corresponding
machine-readable source code" and includes "the scripts used to control
compilation and installation of the executable" in its definition of
that.

Have you tried asking upstream to fix this configure/configure.in
mismatch?

Cheers,
Olly

Bug#940541: maitreya: Uninstallable due to conflicting dependencies

[Olly Betts]

Source: maitreya
Version: 7.0.7-1+b1
Severity: grave
Justification: renders package unusable

Attempting to install maitreya fails for me using current unstable:

$ sudo apt install maitreya
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 maitreya : Depends: libwxsqlite3-3.0-0 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

This situation is also currently being reported by DOSE, so doesn't
appear to be specific to my machine:

https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/maitreya.html#1a95d695ca0f8daa46500bfee6dc4ee7

Pasting that output here for posterity:

| Package: maitreya
| Scenario: unstable_main
| Date: 2019-09-16 05:00:03
| 
| Architectures: mips64el
| 
| Summary: conflict between libwxsqlite3-3.0-0 and maitreya
| 
| maitreya (7.0.7-1) [PTS] [ctrl]
|↓ libwxsqlite3-3.0-0
| 
| libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl]
|   maitreya (7.0.7-1) [PTS] [ctrl]
|   CONFLICT
| 
| Architectures: amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x
| 
| Summary: conflict between libwxsqlite3-3.0-0 and maitreya
| 
| maitreya (7.0.7-1+b1) [PTS] [ctrl]
|↓ libwxsqlite3-3.0-0
| 
| libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl]
|   maitreya (7.0.7-1+b1) [PTS] [ctrl]
|   CONFLICT

Cheers,
Olly

Bug#940540: codelite: Uninstallable due to conflicting dependencies

[Olly Betts]

Source: codelite
Version: 12.0+dfsg-1
Severity: grave
Justification: renders package unusable

Attempting to install codelite fails for me using current unstable:

$ sudo apt install codelite
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 codelite : Depends: libwxsqlite3-3.0-0 but it is not going to be
 installed
 E: Unable to correct problems, you have held broken packages.

This situation is also currently being reported by DOSE, so doesn't
appear to be specific to my machine:

https://qa.debian.org/dose/debcheck/unstable_main/latest/packages/codelite.html#40d19c199f7ed5a33995d52151783c11

Pasting that output here for posterity:

| Package: codelite
| Scenario: unstable_main
| Date: 2019-09-16 05:00:03
| 
| Architectures: amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, 
s390x
| 
| Summary: conflict between libwxsqlite3-3.0-0 and codelite
| 
| codelite (12.0+dfsg-1) [PTS] [ctrl]
|↓ libwxsqlite3-3.0-0
|   
| libwxsqlite3-3.0-0 (3.4.1~dfsg-4) [PTS] [ctrl]
|   codelite (12.0+dfsg-1) [PTS] [ctrl]
| CONFLICT

Cheers,
Olly

Bug#939740: closed by Olly Betts (Bug#939740: fixed in wxwidgets3.0 3.0.4+dfsg-11)

[Olly Betts]

On Mon, Sep 09, 2019 at 07:24:26PM +0200, Andreas Metzler wrote:
> On 2019-09-09 Debian Bug Tracking System  wrote:
> >  wxwidgets3.0 (3.0.4+dfsg-11) unstable; urgency=medium
> >  .
> >* debian/patches/upstream-changes-since-3.0.4.patch: Add lost entry for
> >  new wxWindow::GetContentScaleFactor() function. (Closes: #939740)

> I have just rebuilt hugin 2019.0.0+dfsg-3 against wxwidgets3.0
> 3.0.4+dfsg-11. It still will not run with wxwidgets3.0 3.0.4+dfsg-9:

Hmm, before uploading I attempted to confirm the fix by doing a test
rebuild of hugin 2019.0.0+dfsg-2 against wxwidgets 3.0.4+dfsg-11 and
then installing the hugin package and checking it with wxwidgets
3.0.4+dfsg-9 installed.

> Nevertheless the resulting binary packages does not have an appropriate
> strict dependency on libwxgtk3.0-gtk3-0v5 (>= 3.0.4+dfsg-10).

But looking at the build log there is indeed not a strict dependency,
so I guess I didn't actually test the scenario I intended to...

Thinking about this more, the thing I fixed was a red herring unless
there's some mechanism for creating a symbols file from the information
in the upstream linker version script, and I don't think there is.

I'll add a shlibs file (manually maintaining a symbols file for a C++
library seems too painful for the benefits it gives).

Cheers,
Olly

Bug#939740: libwxgtk3.0-gtk3-0v5: -10 is not compatible with -9 [symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in file libwx_gtk3u_core-3.0.so.0 with link time reference]

[Olly Betts]

Control: tag -1 +pending

On Sun, Sep 08, 2019 at 12:00:57PM +0200, Andreas Metzler wrote:
> ametzler@argenau:/tmp/HUGIN$ ldd -r /usr/bin/hugin > /dev/null
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  
> (/usr/lib/hugin/libhuginbasewx.so.0.0)
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  
> (/usr/lib/hugin/libicpfindlib.so.0.0)
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  (/usr/bin/hugin)

There's a new entry in the upstream linker version script for this, but
this is the only new symbol since the last upstream release which our
package has cherry-picked the patch for and it looks like I failed to
merge the version-script change for it appropriately.

Thanks for catching this.  I'll make a new upload shortly.

Cheers,
Olly

Bug#914086: closed by Olly Betts (Bug#914086: fixed in wxwidgets3.0 3.0.4+dfsg-6)

[Olly Betts]

Control: reopen -1
Control: found -1 3.0.4+dfsg-6
Control: severity -1 serious

The fix in -6 unfortunately doesn't work as configure doesn't honour
an explicitly set EGREP.  Setting GREP works though so will upload -7
with that.

> Severity: grave
> Justification: renders package unusable

The package is still usable for existing programs built against previous
versions.  It should also work perfectly on a merged-usr system.

Cheers,
Olly

Bug#912343: libxapian30: New term position bugs in 1.4.8

[Olly Betts]

Package: libxapian30
Version: 1.4.8-1
Severity: grave
Tags: upstream
Justification: causes non-serious data loss

There's a bug introduced by the upstream 1.4.8 release with handling
positional data.  It only manifests when positional data is NOT added in
ascending position order, which is probably a fairly rare case, but the
consequences are that the encoded positional data can end up corrupted.

I am currently testing a patch and will upload a new package once I'm
happy with it - probably today or tomorrow.

Cheers,
Olly

Bug#900678: slic3r: Segfaults at start since new wxwidgets.

[Olly Betts]

Control: severity -1 important

On Sat, Sep 29, 2018 at 06:16:05PM +0200, Tobias Frost wrote:
> I think we're seeing https://trac.wxwidgets.org/ticket/17702
> So I will reassign this bug to wxwidgets now...
> As wayland is the default, I increase severity to serious.

The definition of "serious" is:

| a severe violation of Debian policy (roughly, it violates a "must" or
| "required" directive), or, in the package maintainer's or release
| manager's opinion, makes the package unsuitable for release.

I can't think what in policy is violated here, and while the situation
is clearly far from ideal I don't think it makes wxwidgets3.0 unsuitable
for release.

This only affects applications using wxGLCanvas, and only those using
the gtk3 flavour of the library (currently we provide both gtk2 and gtk3
flavours built from the same source package, and gtk2 doesn't directly
support wayland).

If applications want to use the gtk3 flavour and wxGLCanvas they can
automate the workaround by setting "GDK_BACKEND=x11" early on (there are
some code snippets to do this in the upstream ticket), so my opinion
(as a maintainer of the package) is that "important" is a more
appropriate severity here, and I'm lowering the severity (unless a
release manager disagrees).

Fixing the underlying issue requires rewriting the OpenGL support
in the upstream wxWidgets code to not use X11 calls.  Until that
happens, if this remains RC then currently the least awful way we
have to fix this is probably to drop OpenGL support from the gtk3
flavour, and force reverse dependencies currently using the gtk3 flavour
and wxGLCanvas to move back to the gtk2 flavour.  Given there's a
reliable workaround that doesn't seem helpful.

If we could automate "GDK_BACKEND=x11" (or equivalent via the GDK
API) in wxwidgets that would be a neater way to address this until
the upstream code is updated to not require X11, but that seems to
be tricky to do because we don't know if wxGLCanvas will be used
or not at the point where we need to do this.  Forcing X11 for all
apps using the gtk3 flavour of wxwidgets3.0 seems a bad idea.

Cheers,
Olly

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Olly Betts]

On Fri, Oct 05, 2018 at 10:12:15PM +0100, Olly Betts wrote:
> On Fri, Oct 05, 2018 at 06:46:52PM +0200, Sven Joachim wrote:
> > Instead of shlibs.local, you probably want to generate
> > libxapian30.shlibs - see dh_makeshlibs(1).
> 
> Hmm, I thought I'd confirmed this was working, but I guess I checked
> xapian-tools which the shlibs.local would work with.
> 
> Thanks for catching.  I'll upload -4 later today.

Done.  To confirm the fix this time, I installed the new libxapian30
package and checked:

/var/lib/dpkg/info/libxapian30:amd64.shlibs

This now has:

libxapian 30 libxapian30 (>= 1.4.6~)

Cheers,
Olly

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Olly Betts]

On Fri, Oct 05, 2018 at 06:46:52PM +0200, Sven Joachim wrote:
> Instead of shlibs.local, you probably want to generate
> libxapian30.shlibs - see dh_makeshlibs(1).

Hmm, I thought I'd confirmed this was working, but I guess I checked
xapian-tools which the shlibs.local would work with.

Thanks for catching.  I'll upload -4 later today.

> The rebuilds should be scheduled with a dep-wait for libxapian-dev (>=
> 1.4.7-4) if that version indeed fixes the bug (see
> https://release.debian.org/wanna-build.html).

Yes, I know.

It seemed prudent to wait to see it was building OK and give a chance to
catch brown paper bag issues (like the one you spotted) rather than just
lean on dep-wait.  If I'd already filed a binnmu request with a suitable
dep-wait we'd have already pointlessly rebuilt a load of reverse deps.

Cheers,
Olly

Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

[Olly Betts]

On Tue, Oct 02, 2018 at 11:10:46PM +0200, Sven Joachim wrote:
> Indeed, but that needs to be fixed in libxapian30's shlibs file.

Fixed there by xapian-core 1.4.7-3.

> Then aptitude (and other reverse dependencies of libxapian30 that
> might be affected) can be rebuilt to pick up the changed dependency.

I've pulled out a list of the packages which need rebuilding from the
buildinfo files on mirror.ftp-master.d.o (anything built against
libxapian-dev 1.4.6-1 or higher which doesn't already have a suitably
versioned dependency):

07/10/pinot_1.05-2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
07/10/zeitgeist_1.0.1-0.2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
08/08/maildir-utils_1.0-6_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
08/17/baloo-kf5_5.49.0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
08/28/recoll_1.24.1-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
09/06/plasma-desktop_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
09/06/plasma-workspace_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
09/07/aptitude_0.8.11-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
09/29/packagesearch_2.7.9_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
10/02/cyrus-imapd_2.5.11-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
10/03/akonadiconsole_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
10/03/akonadi-search_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
10/04/notmuch_0.28~rc0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
10/05/libsearch-xapian-perl_1.2.25.2-1_kfreebsd-amd64.buildinfo: libxapian-dev 
(= 1.4.7-2),

I'll request rebuilds once 1.4.7-3 has built on most architectures,
and recheck the latest buildinfo files in case anything gets built
against the current libxapian-dev before the new one propagates
everywhere.

Cheers,
Olly

Bug#900678: Processed: reassign 900678 to libwxbase3.0-0v5

[Olly Betts]

Control: reassign -1 libwxgtk3.0-gtk3-0v5

> > reassign 900678 libwxbase3.0-0v5 3.0.4+dfsg-4

That's wrong since libwxbase* is the non-GUI classes.

Apparently this only affects the GTK3 variant (because GTK2 is
X11-only), so libwxgtk3.0-gtk3-0v5 is probably the correct binary
package.

Fixing this requires rewriting the wx code which uses X11 API calls
directly, which will probably take a while.  Applications using
wxGLCanvas and the GTK3 variant of wx should probably apply one of the
workarounds from the upstream ticket for the time being:

https://trac.wxwidgets.org/ticket/17702#comment:12

It doesn't really seem feasible to force GTK3 to use X11 in the wx
package - doing that globally seems a bad idea when the problem is only
when wxGLCanvas is used, and we can't force X11 selectively since we
don't know if wxGLCanvas will be used at the point where we'd need
to force it.

Cheers,
Olly

Bug#897857:

[Olly Betts]

On Fri, Aug 10, 2018 at 10:36:59AM +1200, Michael Hudson-Doyle wrote:
> On Fri, 10 Aug 2018 at 09:37, Olly Betts  wrote:
> > I actually addressed this upstream in SWIG back in May (by fixing the
> > generated code rather than disabling the warning), but there's not
> > been a release in a while.  I'll take a look and see if the fix can be
> > backported to the Debian package.  The potential problem is that it was
> > after clean-up of support for older Python versions, and it seems
> > unhelpful in the wider context for the Debian swig package to generate
> > code which supports a narrower range of Python versions than the
> > corresponding upstream SWIG version.
> 
> Hm yes. On some level it would be fine to only support versions of Python
> supported by Debian, but on another that would be a bit hostile.

Indeed.

The patch needed some adjustment, but that wasn't as painful as I
feared.

I can't easily test it with all the Python versions which SWIG claims to
support (which unbelievably is still 2.0 and up in 1.3.x) but the older
of those don't define METH_O so don't take most of the codepaths this
changes anyway.

I've confirmed my changes address the issue when running the upstream
testsuite with GCC 8 and current Python, and fixed two other new GCC 8
warnings which most SWIG-generated Python bindings will trigger.

Cheers,
Olly

Bug#897857: swig: diff for NMU version 3.0.12-1.2

[Olly Betts]

Control: tags 897857 + patch
Control: tags 897857 + pending

Dear maintainer,

I've prepared an NMU for swig (versioned as 3.0.12-1.2) and uploaded it.

NMU diff is attached.

Cheers,
Olly
diff -Nru swig-3.0.12/debian/changelog swig-3.0.12/debian/changelog
--- swig-3.0.12/debian/changelog	2018-06-18 00:25:41.0 +1200
+++ swig-3.0.12/debian/changelog	2018-08-10 12:48:36.0 +1200
@@ -1,3 +1,15 @@
+swig (3.0.12-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * python-fix-function-cast-warnings.patch: Fix GCC8 warnings in generated
+Python code. (Closes: #897857)
+  * python-fix-gcc8-strncpy-warning.patch: Fix more GCC8 warnings in generated
+Python code.
+  * fix-gcc8-memset-warnings.patch: Fix GCC8 warnings in generated code for
+various languages.
+
+ -- Olly Betts   Fri, 10 Aug 2018 12:48:36 +1200
+
 swig (3.0.12-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch
--- swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch	1970-01-01 12:00:00.0 +1200
+++ swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch	2018-08-10 12:48:36.0 +1200
@@ -0,0 +1,212 @@
+Description: Fix new GCC8 warnings in generated code
+ Backported from upstream git master based on the following ranges of commits:
+ git diff 74345c92^..b229d92f
+ git diff dd26e8a0^..a67eff0a
+ git diff ef1351c7..7ac21f37
+Author: Mike Romberg 
+Origin: upstream
+Last-Updated: 2018-08-10
+
+--- a/Lib/python/pycontainer.swg
 b/Lib/python/pycontainer.swg
+@@ -434,8 +434,8 @@
+ {
+   swig::SwigVar_PyObject item = PySequence_GetItem(_seq, _index);
+   try {
+-	return swig::as(item, true);
+-  } catch (std::exception& e) {
++	return swig::as(item);
++  } catch (const std::invalid_argument& e) {
+ 	char msg[1024];
+ 	sprintf(msg, "in sequence element %d ", (int)_index);
+ 	if (!PyErr_Occurred()) {
+--- a/Lib/python/pystdcommon.swg
 b/Lib/python/pystdcommon.swg
+@@ -107,14 +107,14 @@
+ 
+   template  
+   struct traits_as {
+-static Type as(PyObject *obj, bool throw_error) {
++static Type as(PyObject *obj) {
+   Type v;
+   int res = asval(obj, &v);
+   if (!obj || !SWIG_IsOK(res)) {
+ 	if (!PyErr_Occurred()) {
+ 	  ::%type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
++	throw std::invalid_argument("bad type");
+   }
+   return v;
+ }
+@@ -122,7 +122,7 @@
+ 
+   template  
+   struct traits_as {
+-static Type as(PyObject *obj, bool throw_error) {
++static Type as(PyObject *obj) {
+   Type *v = 0;  
+   int res = (obj ? traits_asptr::asptr(obj, &v) : SWIG_ERROR);
+   if (SWIG_IsOK(res) && v) {
+@@ -134,21 +134,17 @@
+ 	  return *v;
+ 	}
+   } else {
+-	// Uninitialized return value, no Type() constructor required.
+-	static Type *v_def = (Type*) malloc(sizeof(Type));
+ 	if (!PyErr_Occurred()) {
+ 	  %type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
+-	memset(v_def,0,sizeof(Type));
+-	return *v_def;
++	throw std::invalid_argument("bad type");
+   }
+ }
+   };
+ 
+   template  
+   struct traits_as {
+-static Type* as(PyObject *obj, bool throw_error) {
++static Type* as(PyObject *obj) {
+   Type *v = 0;  
+   int res = (obj ? traits_asptr::asptr(obj, &v) : SWIG_ERROR);
+   if (SWIG_IsOK(res)) {
+@@ -157,15 +153,14 @@
+ 	if (!PyErr_Occurred()) {
+ 	  %type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
+-	return 0;
++	throw std::invalid_argument("bad type");
+   }
+ }
+   };
+ 
+   template 
+-  inline Type as(PyObject *obj, bool te = false) {
+-return traits_as::category>::as(obj, te);
++  inline Type as(PyObject *obj) {
++return traits_as::category>::as(obj);
+   }
+ 
+   template  
+--- a/Lib/ruby/rubycontainer.swg
 b/Lib/ruby/rubycontainer.swg
+@@ -183,8 +183,8 @@
+ {
+   VALUE item = rb_ary_entry(_seq, _index );
+   try {
+-	return swig::as(item, true);
+-  } catch (std::exception& e) {
++	return swig::as(item);
++  } catch (const std::invalid_argument& e) {
+ 	char msg[1024];
+ 	sprintf(msg, "in sequence element %d ", _index);
+ 	VALUE lastErr = rb_gv_get("$!");
+@@ -926,7 +926,7 @@
+   VALUE elem = argv[0];
+   int idx = 0;
+   try {
+-	Sequence::value_type val = swig::as( elem, true );
++	Sequence::value_type val = swig::as( elem );
+ 	if ( i >= len ) {
+ 	  $self->resize(i-1, val);
+ 	  return $self;
+@@ -943,7 +943,7 @@
+ 	  }
+ 
+   } 
+-  catch( std::invalid_argument )
++  catch( const std::invalid_argument & )
+ 	{
+ 	  rb_raise( rb_eArgError, "%s",
+ 		Ruby_Format_TypeErro

Bug#897857:

[Olly Betts]

On Thu, Aug 02, 2018 at 09:23:26PM +1200, Michael Hudson-Doyle wrote:
> upstream just "fixed" this by disabling the warning, fwiw

This bug was reported in setools but reassigned to swig - I think you
must mean "setools" by "upstream" there?

I actually addressed this upstream in SWIG back in May (by fixing the
generated code rather than disabling the warning), but there's not
been a release in a while.  I'll take a look and see if the fix can be
backported to the Debian package.  The potential problem is that it was
after clean-up of support for older Python versions, and it seems
unhelpful in the wider context for the Debian swig package to generate
code which supports a narrower range of Python versions than the
corresponding upstream SWIG version.

Ignoring the warning is reasonable.  The code in question does invoke
undefined behaviour, but it should be safe in practice with the calling
conventions used on Linux.

Compiling packages with -Werror seems unwise in general, but I really
wouldn't recommend compiling SWIG-generated code in packages with
-Werror.  We do try upstream to keep the generated code warning-free,
but it's common for new compiler versions to result in new warnings, and
there are cases where it's hard to avoid the warnings (indeed even after
my fix you can still get this warning when keyword argument support is
enabled, because the Python C API inherently relies on casting function
pointers to a different type of function pointer when METH_KEYWORD is
used).

Cheers,
Olly

Bug#886835: Should sitplus package be droped from Debian (Was: Bug#886835: sitplus fails to start because GTK+ 2.x and GTK+ 3 in the same process is not supported)

[Olly Betts]

On Wed, Jan 10, 2018 at 04:47:48PM +0100, Luis Rivas wrote:
> On 10 January 2018 at 13:46, Andreas Tille  wrote:
> > just a note for sitplus:  This package definitely needs more love.
> > Upstream has released a new version a long time ago but it has split a
> > separate library which needs to be packaged separately.
> >
> > I'm personally lacking the time resources to care for this package.
> >
> > Any volunteer or is it possibly better to drop the package at all
> > if it is not running?
> 
> I'm afraid I don't have the time for taking care of this package. So,
> unless someone else volunteers, probably it's for the better to drop
> the package for now.

I suspect this particular issue would be fixed by updating the wxWidgets
build-dependency from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev (the
former uses GTK+ 2.x, the latter GTK+ 3.x), though if nobody's able to
look after the package properly, perhaps it's better to drop it.

Cheers,
Olly

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Olly Betts]

On Thu, Jun 14, 2018 at 11:13:04AM +0200, Jonas Smedegaard wrote:
> Quoting Olly Betts (2018-06-14 04:29:27)
> > On Thu, Jun 14, 2018 at 12:45:38AM +0200, Jonas Smedegaard wrote:
> >> I still like pinot and believe there is a use for it in Debian as 
> >> alternative to extract and tracker.  But evidently it keeps falling 
> >> too low on my priority list :-(
> >> 
> >> Please do adopt it.  Or co-maintain it with me, if you prefer that.
> >
> > Sounds good.  I've made a start on preparing an upload.
> >
> > It looks like the packaging was on collab-maint which has now gone - 
> > do you have a checkout of it handy?  Not vital, but preserving the 
> > history seems useful if it's easy to do.
> 
> https://salsa.debian.org/debian/pinot

Thanks.

I've already made an upload, but it looks like there are some changes
there since the last upload (at least to debian/copyright).  I'll
sort out merging them and doing another upload, though I might let the
first upload migrate to testing first, so at least pinot is back in
testing.

> Thanks a lot for co-maintaining!  Please do tell if you have any 
> questions or disagree with how some stuff was done in the past - or 
> simply change things and inform me, if you prefer (we are in it together 
> - equally!).

I changed from cdbs to dh as you said that was OK on IRC, and together
with moving to debhelper compat 11 that makes for a very simple
debian/rules.

I left the update to gmime 3.0 out of this upload as it seemed better
to prioritise fixing the RC bugs and get a working package back in
testing.

Cheers,
Olly

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Olly Betts]

On Thu, Jun 14, 2018 at 12:45:38AM +0200, Jonas Smedegaard wrote:
> I still like pinot and believe there is a use for it in Debian as 
> alternative to extract and tracker.  But evidently it keeps falling too 
> low on my priority list :-(
> 
> Please do adopt it.  Or co-maintain it with me, if you prefer that.

Sounds good.  I've made a start on preparing an upload.

It looks like the packaging was on collab-maint which has now gone - do
you have a checkout of it handy?  Not vital, but preserving the history
seems useful if it's easy to do.

Cheers,
Olly

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Olly Betts]

On Thu, May 31, 2018 at 12:22:58AM +0200, Sebastian Andrzej Siewior wrote:
> pinot has currently two RC bugs and failed to build during the curl4
> transition / binNMU.
> Does it make sense to add the two patches (Olly pointed to) and upload
> it or would a RM make sense?

Popcon suggests pinot usage is low:

https://qa.debian.org/popcon.php?package=pinot

I'm not sure there's really a direct equivalent though, so it seems
worth uploading with at least the RC fixes.  I can prepare an upload
(or happy for someone else to).

Jonas: Are you still interested in maintaining pinot?  I ask because
it's had RC bugs open for a long time without any maintainer response,
and the last maintainer upload was over five years ago now.

Let me know and if not I can orphan or adopt in my upload.

Cheers,
Olly

Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?

[Olly Betts]

On Sun, Apr 08, 2018 at 11:42:47AM +0300, Niko Tyni wrote:
> On Sat, Apr 07, 2018 at 09:57:15PM +0100, Olly Betts wrote:
> > On Sat, Apr 07, 2018 at 04:20:48PM +0300, Niko Tyni wrote:
> > > So to do this properly it looks like we need something to make
> > > sure the Perl Wx related packages are upgraded in sync. The
> > > virtual package provided by libalien-wxwidgets-perl (currently
> > > wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have
> > > a ready recipe for injecting that.
> > 
> > I'd guess that makes sense, but I don't entirely understand how the
> > libalien-wxwidgets-perl <-> libwx-perl connection works, or why we need
> > a chain of binNMUs after each new upstream wxwidgets3.0 release.
> 
> AIUI Alien::wxWidgets provides information about a wxwidgets installation,
> and libwx-perl uses that to offer machinery for building wxwidgets
> related Perl packages (the Wx::build namespace.)  This build machinery
> embeds the exact wxwidgets version/configuration from Alien::wxWidgets,
> and breaks if those get out of sync. Hence the binNMU requirement. See
> #757855 for the full story.

I've read that ticket already, but I'm not really clear on why it
requires the exact wxWidgets version.  If you built against wxWidgets
3.0.3.1 then the real requirement is $upstream_version >= 3.0.3.1 not
$upstream_version == 3.0.3.1 (or perhaps >= some lower version if there
were no ABI additions since that version).

Is there something more subtle here, or is this effectively an
Alien::wxWidgets upstream design flaw which it's hard for distros to
diverge from?

> Another approach would be to consider this a one time glitch (how often
> are we going to change toolkits anyway?), make libwx-perl Break older
> (gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions,
> and have those packages in turn depend on newer (gtk3 based) libwx-perl
> versions. That should handle it afaics.

If this is only because of the gtk2 to gtk3 switch, then this makes
sense to me.  It's the first time this will have happened since we've
had these two packages, and only the second time in 18 years we've
changed toolkit in the default wxwidgets packages (previously gtk1 to
gtk2).

I see that libwx-scintilla-perl has a BD on libalien-wxwidgets-perl
and seems to actually use it, but it looks like only for build flags
and similar.

Cheers,
Olly

Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

[Olly Betts]

Control: severity -1 normal

On Sat, Apr 07, 2018 at 05:30:19PM +0300, Adrian Bunk wrote:
> On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote:
> > On Sat, 7 Apr 2018, Norbert Lange wrote:
> > 
> > > it appears that the files are installed in a subdirectory,
> > > potentially to avoid confligs with previous versions?
> > > result is that
> > > 
> > > import wx fails with
> > > 
> > > ImportError: No module named wx
> > > 
> > > I havent found a way to configure the installation
> > 
> > The purpose of the python-wxgtk4.0 package is primarily for application
> > developers to use in porting their applications to wxPython 4.0 (Phoenix).
> > There isn't much of a reason otherwise to use the Python 2 version of
> > wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can
> > 'import wx'.
> > 
> > If you really would like to use the Python 2 version, you can do:
> > 
> > PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
> >  python
> > import wx

This doesn't appear to be documented in the package, which it really
should be (probably a brief explanation in the package description, and
more detail in README.Debian).

Maybe it's also worth including a trival wrapper script to set
PYTHONPATH suitably and then exec python.

> Is there a good reason why you are making it harder than necessary to 
> use python-wxgtk4.0 ?

Because wxPython 3.0 already exists for Python 2 as module "wx".  But
wxPython 3.0 doesn't support Python 3 and never will, so there's no
other claimant for module "wx" for Python 3.

wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't
completely compatible with wxPython 3.0, so switching "import wx" to use
that for Python 2 would not work out well.

And a lot of packages use wxPython 3.0, so wxPython 4.0 for Python 2
really needs to be co-installable with wxPython 3.0.

Installing the module as "wx4" or something isn't helpful as that
doesn't match what upstream does, nor how it's packaged for Python 3.

The only reason Scott created this package is to help people maintaining
a wxPython application who want to migrate it to wxPython 4.0 - that
involves both porting it from Python 2 to Python 3 and from wxPython 3.0
to wxPython 4.0.  Rather than having to do both together, with this
package you can port to Python 2 + wxPython 4.0 as an intermediate step.

So I'd say the bug here is really that this isn't clear from the current
packages.

> Python 2 is fully supported by Debian during the lifetime of buster,
> and there are various reasons why many users are stuck with Python 2
> for some more time.

There are, but people sticking with Python 2 are really unlikely to want
to use wxPython 4.0.

Cheers,
Olly

Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?

[Olly Betts]

On Sat, Apr 07, 2018 at 04:20:48PM +0300, Niko Tyni wrote:
> So to do this properly it looks like we need something to make
> sure the Perl Wx related packages are upgraded in sync. The
> virtual package provided by libalien-wxwidgets-perl (currently
> wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have
> a ready recipe for injecting that.

I'd guess that makes sense, but I don't entirely understand how the
libalien-wxwidgets-perl <-> libwx-perl connection works, or why we need
a chain of binNMUs after each new upstream wxwidgets3.0 release.

Presumably just copying libwx-perl's dependencies related to this
across would work?

> It seems probable that other packages (libwx-glcanvas-perl?) are
> similarly affected, but I haven't looked into that.

I'd expect so.  There don't seem to be any others - at least I don't see
any other -perl packages in the transition tracker:

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

> Olly, explicitly copying you as you're handling this transition (thanks
> for that!). Any thoughts on this?

I added dependencies in my recent libwx-scintilla-perl and
libwx-glcanvas-perl uploads to ensure that a gtk3 version of libwx-perl
was used (and from there down the dependency chain it should be OK).

I didn't try to handle preventing combinations of new libwx-perl with
older libwx-scintilla-perl or libwx-glcanvas-perl though since there was
no evidence that such handling was attempted for previous transitions.

> Setting severity to RC initially and marking as a transition blocker,
> but others should feel free to adjust as appropriate.

It would certainly be good to address this somehow, but mostly because
it will ease future transitions.  I'm not sure this really deserves to
block this one as the libwx*-perl collection is now back in step across
all release archs:

https://buildd.debian.org/status/package.php?p=libalien-wxwidgets-perl+libwx-perl+libwx-scintilla-perl+libwx-glcanvas-perl

Also blocking the transition really just means that the wx gtk2 packages
can't be removed, yet doing that if anything improves the situation.

But that's mostly a theoretical point right now as the full transition
is going to take months.

Cheers,
Olly

Bug#828503: pinot: FTBFS with openssl 1.1.0

[Olly Betts]

Control: tag -1 + fixed-upstream patch

Looks like upstream has addressed this (commit message "Catch up with
current glib and OpenSSL"):

https://github.com/FabriceColin/pinot/commit/a932cd1093599e8e26f5e408292faff92daceb74

Cheers,
Olly

Bug#889936: survex: FTBFS with proj 5.0.0

[Olly Betts]

Control: clone -1 -2
Control: reassign -2 libproj13
Control: retitle -2 libproj13: PROJ4 version 5 ignores +vunits
Control: block -1 by -2

On Thu, Feb 08, 2018 at 10:55:00PM +0100, Bas Couwenberg wrote:
> Your package FTBFS due to missing compatibility with Proj 5.0.0:
> 
>  ./csbadsdfix.svx:2: error: Station "1" fixed before CS command first used
>  ./csbadsdfix.svx:3:5: error: Unknown coordinate system
>   *cs EPSG:-1
>   ^~~
>  ./csbadsdfix.svx:4:5: error: Unknown coordinate system
>   *cs ERSI:1234
>   ^
>  ./csbadsdfix.svx:5:5: error: Unknown coordinate system
>   *cs EUR79Z31
>   ^~~~
[...]

This isn't the problem (these testcases are testing that we reject
coordinate systems which aren't valid, so these errors are expected and
correct).

The test failure seems to be actually due to the new PROJ4 ignoring
+vunits entirely and can be reproduced without involving Survex by
using cs2cs:

$ echo 36000 83000 5250|cs2cs +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 
+y_0=-520 +ellps=bessel 
+towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +vunits=ft +to 
+proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-520 +ellps=bessel 
+towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 
36000.0083000.00 5250.00

In older versions this converted the altitude from feet to metres, and
the output was:

36000.0083000.00 1600.20

Cheers,
Olly

Bug#876673: catdoc: diff for NMU version 1:0.95-4.1

[Olly Betts]

Control: tags 876673 + patch
Control: tags 876673 + pending

Dear maintainer,

I've prepared an NMU for catdoc (versioned as 1:0.95-4.1) and uploaded
it under the zero-day NMU rules.

Cheers,
Olly
diff -Nru catdoc-0.95/debian/changelog catdoc-0.95/debian/changelog
--- catdoc-0.95/debian/changelog	2017-09-14 09:03:58.0 +1200
+++ catdoc-0.95/debian/changelog	2017-11-06 11:48:29.0 +1300
@@ -1,3 +1,11 @@
+catdoc (1:0.95-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Restore -lm when linking programs as it's needed for rint() on some
+architectures. Closes: #876673
+
+ -- Olly Betts   Mon, 06 Nov 2017 11:48:29 +1300
+
 catdoc (1:0.95-4) unstable; urgency=medium
 
   * Automated fixes from cme, and some cleanup.
diff -Nru catdoc-0.95/debian/patches/02-Makefile_fixes.patch catdoc-0.95/debian/patches/02-Makefile_fixes.patch
--- catdoc-0.95/debian/patches/02-Makefile_fixes.patch	2017-09-14 09:03:58.0 +1200
+++ catdoc-0.95/debian/patches/02-Makefile_fixes.patch	2017-11-06 11:40:22.0 +1300
@@ -46,18 +46,3 @@
  	$(INSTALL) -m 644 wordview.1 $(installroot)$(mandir)/man1/wordview.1
  distclean: clean
  	$(RM)  Makefile catdoc.1 xls2csv.1 catppt.1 wordview.1
 a/src/Makefile.in
-+++ b/src/Makefile.in
-@@ -77,10 +77,10 @@
- catdoc: $(OBJ)
- 	$(CC)  -o catdoc  $(OBJ) $(LDFLAGS)
- xls2csv: $(OBJXLS)
--	$(CC) -o xls2csv $(OBJXLS) -lm $(LDFLAGS)
-+	$(CC) -o xls2csv $(OBJXLS) $(LDFLAGS)
- 
- catppt: $(OBJPPT)
--	$(CC) -o catppt $(OBJPPT) -lm $(LDFLAGS)
-+	$(CC) -o catppt $(OBJPPT) $(LDFLAGS)
- 
- install: @installtargets@
- install-catdoc:catdoc xls2csv catppt 


signature.asc
Description: PGP signature

Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Thu, Sep 28, 2017 at 10:42:03AM +0200, Christian Beer wrote:
> I'm waiting on the recent upload to unstable on my desktop to test out
> your patch with the debian package. If this is working I would like to
> integrate this upstream. The big difference I see between Olly's patch
> and jengelh's patch is the use of "wxUSE_WEBVIEW" which we need for the
> Windows and Mac version since we don't want to drop webview support
> there.

You probably want to keep using wxWebView on Linux when it's available
too.

I'm afraid I didn't try to make the change optional, which is OK for a
patch in a Debian package, but obviously not suitable for merging
upstream as-is.

Cheers,
Olly

Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

Note: With Debian's BTS you need to Cc the submitter if you want to
ensure they see it - I only saw your reply because I happened to
check in on the bug.

On Wed, Sep 27, 2017 at 11:21:03AM +0200, Christian Beer wrote:
> There is already an upstream PR [1] that replaces wxWebView with
> wxHtmlWindow. Maybe it's better to wait a bit for the PR and then use
> this to patch 7.8.2 on Debian?
> 
> [1] https://github.com/BOINC/boinc/pull/2093

Sigh, I got the impression from Gianfranco that nobody upstream was
working on this, or I wouldn't have spent time on a patch.

Thanks for the link - I've followed up in the ticket above.

If an upstream patch is actually being worked on but needs more time,
we can drop boinc temporarily from testing and then it can reenter once
patched.

Cheers,
Olly

Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

Package: boinc
Version: 7.8.2+dfsg-3
Severity: serious
Tags: sid buster patch
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: oldlibs libwebkitgtk-1.0-0 webkit1
Control: block 790222 by -1

boinc-manager depends on libwxgtk-webview3.0-0v5 which
depends on libwxgtk-webview3.0-0v5 which depends on
libwebkitgtk-1.0-0. libwebkitgtk-1.0-0 is the old webkitgtk library
that suffers from many reported CVEs that have been fixed in
libwebkit2gtk-4.0-37 (src: webkit2gtk ).  The pkg-webkit maintainers
do not intend to release Debian 10 "Buster" with libwebkitgtk-1.0-0.

boinc-manager is the only reverse dependency of libwxgtk-webview3.0-0v5,
and apparently will soon be the only package blocking removal of webkit1.

I've attached a patch which changes boinc-manager to use wxHtmlWindow
instead of wxWebView.  I can build the package with this patch applied,
but I don't know boinc well enough to usefully test its functionality.
wxHtmlWindow is not a full-featured web browser, but hopefully this
gives a usable application - please test it out.

Cheers,
Olly
diff -Nru boinc-7.8.2+dfsg/debian/changelog boinc-7.8.2+dfsg/debian/changelog
--- boinc-7.8.2+dfsg/debian/changelog	2017-09-07 19:41:28.0 +1200
+++ boinc-7.8.2+dfsg/debian/changelog	2017-09-27 11:13:58.0 +1300
@@ -1,3 +1,10 @@
+boinc (7.8.2+dfsg-3exp1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to use wxHtmlWindow instead of wxWebView.
+
+ -- Olly Betts   Wed, 27 Sep 2017 11:13:58 +1300
+
 boinc (7.8.2+dfsg-3exp1) experimental; urgency=medium
 
   * Upload to experimental again, with the boinc-server-* packages.
diff -Nru boinc-7.8.2+dfsg/debian/control boinc-7.8.2+dfsg/debian/control
--- boinc-7.8.2+dfsg/debian/control	2017-09-07 19:41:28.0 +1200
+++ boinc-7.8.2+dfsg/debian/control	2017-09-27 11:13:58.0 +1300
@@ -26,7 +26,6 @@
libsqlite3-dev,
libssl-dev,
libtool,
-   libwxgtk-webview3.0-dev,
libwxgtk3.0-dev,
libxcb-util0-dev,
libxi-dev,
diff -Nru boinc-7.8.2+dfsg/debian/control.in boinc-7.8.2+dfsg/debian/control.in
--- boinc-7.8.2+dfsg/debian/control.in	2017-09-06 18:23:42.0 +1200
+++ boinc-7.8.2+dfsg/debian/control.in	2017-09-27 11:07:10.0 +1300
@@ -26,7 +26,6 @@
libsqlite3-dev,
libssl-dev,
libtool,
-   libwxgtk-webview3.0-dev,
libwxgtk3.0-dev,
libxcb-util0-dev,
libxi-dev,
diff -Nru boinc-7.8.2+dfsg/debian/patches/series boinc-7.8.2+dfsg/debian/patches/series
--- boinc-7.8.2+dfsg/debian/patches/series	2017-09-07 19:36:02.0 +1200
+++ boinc-7.8.2+dfsg/debian/patches/series	2017-09-27 11:13:58.0 +1300
@@ -30,3 +30,4 @@
 fix-underlinking.patch
 static_scientific_apps.patch
 0001-Fix-build-with-new-glibc-2.26.patch
+use-wxhtmlwindow-instead-of-wxwebview.patch
diff -Nru boinc-7.8.2+dfsg/debian/patches/use-wxhtmlwindow-instead-of-wxwebview.patch boinc-7.8.2+dfsg/debian/patches/use-wxhtmlwindow-instead-of-wxwebview.patch
--- boinc-7.8.2+dfsg/debian/patches/use-wxhtmlwindow-instead-of-wxwebview.patch	1970-01-01 12:00:00.0 +1200
+++ boinc-7.8.2+dfsg/debian/patches/use-wxhtmlwindow-instead-of-wxwebview.patch	2017-09-27 11:13:58.0 +1300
@@ -0,0 +1,104 @@
+Description: Use wxHtmlWindow instead of wxWebView
+Author: Olly Betts 
+Forwarded: no
+Last-Update: 2017-09-26
+
+--- a/clientgui/NoticeListCtrl.cpp
 b/clientgui/NoticeListCtrl.cpp
+@@ -50,8 +50,8 @@
+ BEGIN_EVENT_TABLE( CNoticeListCtrl, wxWindow )
+ 
+ @begin CNoticeListCtrl event table entries
+-EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked)
+-EVT_WEBVIEW_ERROR(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnWebViewError)
++EVT_HTML_LINK_CLICKED(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked)
++//EVT_WEBVIEW_ERROR(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnWebViewError)
+ @end CNoticeListCtrl event table entries
+  
+ END_EVENT_TABLE()
+@@ -84,7 +84,7 @@
+ wxWindow::Create( parent, ID_LIST_NOTIFICATIONSVIEW, wxDefaultPosition, wxDefaultSize,
+ wxSUNKEN_BORDER | wxTAB_TRAVERSAL );
+ 
+-m_browser = wxWebView::New( this, ID_LIST_NOTIFICATIONSVIEW );
++m_browser = new wxHtmlWindow( this, ID_LIST_NOTIFICATIONSVIEW );
+ @end CNoticeListCtrl creation
+ 
+ wxBoxSizer *topsizer;
+@@ -238,7 +238,7 @@
+ m_noticesBody += wxT("");
+ // baseURL is not needed here (see comments above) and it
+ // must be an empty string for this to work under OS 10.12.4
+-m_browser->SetPage(m_noticesBody, wxEmptyString);
++m_browser->SetPage(m_noticesBody);
+ }
+ 
+ 
+@@ -248,22 +248,27 @@
+ }
+ 
+ 
+-void CNoticeListCtrl::OnLinkClicked( wxWebViewEvent& event ) {
+-if (event.GetURL().StartsWith(wxT("http://";)) || event.GetURL().StartsWith(wxT(

Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Tue, Sep 26, 2017 at 08:24:06AM -0400, Scott Talbert wrote:
> 
> 
> On September 26, 2017 1:54:34 AM EDT, Olly Betts  wrote:
> >On Mon, Sep 25, 2017 at 10:37:34PM -0400, Scott Talbert wrote:
> >> I would think the person who was trying to use wx.html2 might not
> >> agree with that.
> >
> >"wx.html2" is actually how wxPython wraps webview:
> >
> >| I have put the wxPython verison of them in the wx.html2 module
> >| because the wxWebKit project already produces a wx.webview module for
> >| wxPython.
> >
> >So it's inevitable that wx.html2 is not going to work once webview is
> >disabled in wxWidgets.
> 
> I am fully aware of that.  I just think it would have been better to
> leave it until wxWebview was being removed.

That's imminent anyway.

And the original reporter of #821934 wasn't even using Debian!

Cheers,
Olly

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Tue, Sep 26, 2017 at 08:05:57AM +, Gianfranco Costamagna wrote:
> >Gianfranco: Is there any progress on the boinc front?  If not, I think
> >we just need to do this rather than letting this removal drag on for
> >even longer.
> 
> so, the plan now is to remove boinc from testing?

Or stop it from using webview, e.g. by using wxHtmlWindow instead (as I
suggested months ago).

> what is the plan to fix it BTW? moving to the new webkitgtk and transition to
> gtk3?

I think that's the only way to get webview back, but we need people to
actually do the work to make that happen.  I'm not realistically able to
commit to doing a transition unaided at this point - initial
investigations showed that it's likely to shake out a significant number
of bugs in both wx's GTK+ 3 support and in apps themselves.  It's not
just a case of uploading and binNMUing all rdeps.

As things stand, the plan is probably that there's no webview for buster.

Cheers,
Olly

Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

On Mon, Sep 25, 2017 at 10:37:34PM -0400, Scott Talbert wrote:
> On Tue, 26 Sep 2017, Olly Betts wrote:
> >If we revert the change which added this package apart from one hunk in
> >debian/rules then we get a package set which simply doesn't have
> >wx.html2 (rather than a broken one), which seems good so I've uploaded.
> 
> I would think the person who was trying to use wx.html2 might not agree with
> that.

"wx.html2" is actually how wxPython wraps webview:

| I have put the wxPython verison of them in the wx.html2 module
| because the wxWebKit project already produces a wx.webview module for
| wxPython.

So it's inevitable that wx.html2 is not going to work once webview is
disabled in wxWidgets.

Cheers,
Olly

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Mon, Sep 25, 2017 at 10:37:50PM -0400, Jeremy Bicha wrote:
> Ok, let me give a status update of the webkitgtk removal from Debian Testing:
> 
> $ reverse-depends -r testing src:webkitgtk
> Reverse-Depends
> ===
> * empathy   (for libwebkitgtk-3.0-0)
> * geary (for libwebkitgtk-3.0-0)
> * libwebkit1.1-cil  (for libwebkitgtk-1.0-0)
> * libwxgtk-webview3.0-0v5   (for libwebkitgtk-1.0-0)
> 
> empathy is fixed in unstable but it needs a new upload to probably
> revert to 3.12.14 so that's several days away from being fixed in
> testing.
> geary is fixed in unstable and I expect it to drop off the list in ~ 4 days.
> libwebkit1.1-cil's last reverse dependency is fixed in unstable so
> that can be removed from testing in ~4 days. src:webkit-sharp has no
> reverse-dependencies in testing.
> 
> That leaves wxwidgets3.0 and its 2 rdepends: boinc and
> python-wxgtk-webview3.0. python-wxgtk-webview3.0 has no reverse
> dependencies and I think it sounds like it's going to be dropped now:
> https://bugs.debian.org/876789

Yes, I uploaded to drop that binary package earlier today.

> Therefore, the way I see it, boinc/wxwidgets3.0 is the only remaining
> blocker for removing webkitgtk from Debian Testing.

Thanks for the update.

Gianfranco: Is there any progress on the boinc front?  If not, I think
we just need to do this rather than letting this removal drag on for
even longer.

Cheers,
Olly