Bug#752604: xbmc: better logging with timestamps
Control: tags -1 + fixed-upstream Control: forwarded https://github.com/xbmc/xbmc/pull/15457 On Thu, Jun 26, 2014 at 10:42:01PM +0200, Bálint Réczey wrote: > OK, reopening it. I'm not sure if adding the date would be accepted by > upstream since there may plenty of scripts expecting only the time of > day timestamp. This was fixed upstream in version 18.1: https://github.com/xbmc/xbmc/commit/dc013552b0710b60146bf5693938dbb22bbff3dd Cheers, Olly
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
On Mon, Aug 12, 2019 at 12:29:30PM -0400, Scott Talbert wrote: > On Mon, 12 Aug 2019, Gunter Königsmann wrote: > > GDK_BACKEND was already set to x11 due to my debugging. If I unset the > > environment variable the problem disappears => Logged in into a > > non-wayland session and the problem appeared again. > > OK, so just to confirm: the problem occurs with X11 but NOT with Wayland? If so, there's clearly more to it that just wxDC::Clear() not working under X11 with GTK3 - I'm not running wayland and my patched drawing sample showed wxDC::Clear() working. Cheers, Olly
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
Control: forwarded -1 https://trac.wxwidgets.org/ticket/18463 On Sun, Aug 11, 2019 at 11:18:11PM -0400, Scott Talbert wrote: > On Sun, 11 Aug 2019, Olly Betts wrote: > > So I'm afraid I don't seem to be able to reproduce your problem. > > > > Please can you come up with a small reproducer (upstream like a patch > > against one of their samples) and file a bug upstream? > > Gunter did file a bug upstream: > https://trac.wxwidgets.org/ticket/18463 If you file an upstream bug too, please mark the Debian bug as forwarded to it, or if you don't know how, at least mention the upstream bug. Otherwise you have us wasting effort, which is rather disrespectful of our time. Cheers, Olly
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
Control: tag -1 unreproducible
On Sat, Aug 10, 2019 at 04:51:08PM +0200, Gunter Königsmann wrote:
> If a draw context is used and wxWidgets 3.0 (3.1 isn't affected, but
> isn't packaged with debian as it is the development version) uses GTK3
> the background is likely not to be cleared before a redraw as
> wxDC::Clear() doesn't work under these circumstances.
I tried to reproduce your bug by patching the drawing sample in the wx
source code using the attached patch, but it seems to work fine for me.
If you cd to the drawing subdirectory and run:
make -f makefile.unx WX_PORT=gtk3
Then double-check that it's linked to the GTK3 version:
ldd drawing|grep libwx_gtk
And then run it:
./drawing
This prints "Clear()" to the console (so we are running the patched
code) but the window doesn't have a hatching on the background. If
you remove the dc.Clear() just after where I've patched and rerun
the make command above then the window has hatching over it. So
clearly wxDC::Clear() is working in this case.
So I'm afraid I don't seem to be able to reproduce your problem.
Please can you come up with a small reproducer (upstream like a patch
against one of their samples) and file a bug upstream?
Cheers,
Olly
diff --git a/samples/drawing/drawing.cpp b/samples/drawing/drawing.cpp
index b0715c08..3149ca13 100644
--- a/samples/drawing/drawing.cpp
+++ b/samples/drawing/drawing.cpp
@@ -1574,6 +1574,13 @@ void MyCanvas::Draw(wxDC& pdc)
if ( m_clip )
dc.SetClippingRegion(100, 100, 100, 100);
+{
+dc.SetPen(*wxBLACK_PEN);
+for ( int i = 0; i < 400; i++ )
+dc.DrawLine(i*5, 0, 0, i*5);
+}
+
+printf("Clear()\n");
dc.Clear();
if ( m_owner->m_textureBackground )
Bug#934386: wxScrolled flickers when the horizontal scrollbar is active and GTK3 is used
On Sat, Aug 10, 2019 at 04:51:10PM +0200, Gunter Königsmann wrote: > If something is drawn by wxWidgets and is horizontally scrollable if > wxWidgets uses GTK3 it is likely to flicker on redraw. > > Upstream bug report: https://trac.wxwidgets.org/ticket/18462. The > problem is reproducible by the maintainer of wxWidgets. It doesn't > happen in wxWidgets3.1, which (as it is a development version) isn't > packaged with debian. Do either of the suggestions pcor makes on the upstream ticket help? Cheers, Olly
Bug#934096: codelite: Please rebuild against wxWidgets GTK 3 package
My previous mail bounced: > The original message was received at Thu, 8 Aug 2019 23:15:48 GMT > from polaris-out.tmomail.net [208.54.152.156] > >- The following addresses had permanent fatal errors - > <+13054505829/TYPE=p...@icmms1.sun5.lightsurf.net> > (reason: 550 Invalid MM4 Format) > >- Transcript of session follows - > ... while talking to [127.0.0.1]#localhost: > >>> DATA > <<< 550 Invalid MM4 Format > 554 5.0.0 Service unavailable > Reporting-MTA: dns; sv1p-gen-icm-app015.sun5.lightsurf.net > Arrival-Date: Thu, 8 Aug 2019 23:15:48 GMT > > Final-Recipient: RFC822; +13054505829/TYPE=p...@icmms1.sun5.lightsurf.net > Action: failed > Status: 5.2.0 > Remote-MTA: DNS; [127.0.0.1]#localhost > Diagnostic-Code: SMTP; 550 Invalid MM4 Format > Last-Attempt-Date: Thu, 8 Aug 2019 23:15:49 GMT It's not clear from the bounce message, but I think the bounce must have been from trying to deliver to David. Sending this to it's recorded in the ticket that we probably didn't manage to contact him, but Cc-ing David in case it was a temporary glitch. David: If this does get through, please see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934096#12 Cheers, Olly
Bug#933450: fityk: Please rebuild against wxWidgets GTK 3 package
On Thu, Aug 08, 2019 at 12:13:34AM +1000, Stuart Prescott wrote: > Unfortunately, fityk does not yet appear to be ready to make that switch, > with > the following in included in the code: > > https://github.com/wojdyr/fityk/blob/master/wxgui/app.cpp#L11 > > #ifdef __WXGTK3__ > #error "Not everything is working with wxGTK3. Use default wxGTK instead, " \ >"based on GTK+2. If you want to test it, just remove this #error." > #endif > > I have tried running fityk with wxGTK3 but haven't yet worked out what works > and what does not. I'll write to upstream to seek advice. git blame shows that check was added 5 years ago: https://github.com/wojdyr/fityk/blame/master/wxgui/app.cpp#L11 There have been a lot of GTK3-related fixes in wxGTK since then so I'd expect it to work much better now. Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 06:14:45AM +0100, Olly Betts wrote: > On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote: > > I don't have a hidpi display and don't know if it's possible to simulate > > one. I don't run Gnome either... > > Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can > simulate with e.g. GDK_SCALE=2 in the environment. Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround the problem when using a hidpi display? Presumably that results in any non-OpenGL content in the window being smaller than ideal, but probably it's like that anyway if one sticks with GTK2. Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 12:14:30AM -0400, Scott Talbert wrote: > On Thu, 1 Aug 2019, Tobias Frost wrote: > > > I could get Gnome to offer me the scaling issue on my Desktop PC with a > > full HD monitor, so maybe that is a possiblity. > > > > Some obervations on the bug: > > Only the drawing seems to be botched. Mouse coordinates seem to be > > matching with the window area, so e.g to select an object in slic3r you > > would have put the mouse in the middle of the window area, not in the middle > > where it is rendered. IOW, it seems that the coordinates to be rendered > > are somewhere not using the scaling factor… > > > > PS: https://github.com/prusa3d/PrusaSlicer/issues/864 seems related, > > and it seems to be fixed^Wbetter in wxwidgets 3.1 … > > Okay, so I think I better understand this problem now. It seems that all of > these applications are using wxGLCanvas. When using OpenGL, apparently it > operates on physical pixels, so when setting the dimensions of the GL > viewport, the scale factor of the display has to be factored in. Thus, > darkradiant (and these other applications) will have to use the scale factor > when calling glViewport(). Does this affect anything using wxGLCanvas? Or does it depend on how the viewport is set or something? I don't have a hidpi display and don't know if it's possible to simulate one. I don't run Gnome either... > Now, the harder part is getting the current scale factor. In wx 3.1, you > can call GetContentScaleFactor(). However, in wx 3.0, this always returns > 1. In order to fix that, we would need at least part of this commit: > https://github.com/wxWidgets/wxWidgets/commit/f95fd11e08482697c3b0c0a9d2ccd661134480ee#diff-40dd4b5e2cdfa858afee852fae756e01 > However, I don't know if that would cause an ABI change - does adding a new > override of a C++ function change ABI? If so, then we would probably need > some other way of solving this. This is discussed here: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B | You can... | [...] | reimplement virtual functions defined in the primary base class | hierarchy (that is, virtuals defined in the first non-virtual base | class, or in that class's first non-virtual base class, and so forth) if | it is safe that programs linked with the prior version of the library | call the implementation in the base class rather than the derived one. | This is tricky and might be dangerous. Think twice before doing it. | Alternatively see below for a workaround. | | Exception: if the overriding function has a covariant return type, | it's only a binary-compatible change if the more-derived type has | always the same pointer address as the less-derived one. If in | doubt, do not override with a covariant return type. So if the compiler has optimised the call for an already built application, it would still get a scale factor of 1.0. Not terrible in isolation, but if there are multiple calls and only some are optimised that would probably be problematic. We could plan to binNMU affected programs, but that's not ideal (and doesn't help for non-packaged applications built by users). To address it just within Debian, we could potentially add a new non-virtual method to return this for 3.0.x, and patch affected applications to call that method instead until 3.2.x. Or maybe see if upstream think it's worth finding a way to address? Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote: > I don't have a hidpi display and don't know if it's possible to simulate > one. I don't run Gnome either... Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can simulate with e.g. GDK_SCALE=2 in the environment. Cheers, Olly
Bug#919903: Package wxWidgets 3.1
tags -1 wontfix thanks On Sun, Jan 20, 2019 at 05:24:50PM +0100, Yuri D'Elia wrote: > It would be helpful to have a package for the 3.1.* release (currently > 3.1.2) of wxWidgets for development purposes, even if that just targets > experimental. It's not ABI stable, so it's just not suitable for packaging. Every new 3.1.x release would mean a transition for everything built against it. Even if we only uploaded to experimental with the aim to support local builds, a new upload would break everyone's locally built applications. People who want to use 3.1.x are better off doing a local install from upstream sources as then they have control of when they upgrade to a new 3.1.x. Once 3.1.x turns into 3.2.0, upstream promises ABI stability and then we can usefully package it. > Although still considered "development" and not 100% compatible with > 3.0, wx 3.1 includes a plethora of bug fixes that forced me to upgrade > for development. Please encourage upstream to backport fixes for such bugs to 3.0.x. In most cases can pick up backported fixes and add them to the Debian packaging fairly easily (no need to wait for upstream to make the next 3.0.x release). Cheers, Olly
Bug#894663: transition: wxwidgets3.0
On Sun, Sep 30, 2018 at 10:09:28AM +0100, Olly Betts wrote: > On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote: > > Are we planning to complete this transition > > in buster (transition deadline being 2019-01-05) or it is fine if this > > transition is first completed in bullseye ? > > I'd still love to complete it for buster, but I suspect we may well not > manage to get all the remaining rdeps moved over. > > We never actually got around to filing bugs against rdeps, but perhaps > we should to encourage them to move where there aren't any blockers. Now that we're post-release, Scott Talbert has filed bugs and the transition is progressing well (we've gone from 17% to 41% in just a week). Please can you re-enable export for this transition so that it appears in tracker.d.o, etc? I've attached a patch which should be suitable. Cheers, Olly diff --git a/config/ongoing/wxwidgets3.0-gtk3.ben b/config/ongoing/wxwidgets3.0-gtk3.ben index 27a9e072..525b0a4f 100644 --- a/config/ongoing/wxwidgets3.0-gtk3.ben +++ b/config/ongoing/wxwidgets3.0-gtk3.ben @@ -3,4 +3,3 @@ is_affected = .depends ~ /libwxgtk(-media)?3\.0-0v5/ | .depends ~ /libwxgtk(-med is_good = .depends ~ /libwxgtk(-media)?3\.0-gtk3-0v5/; is_bad = .depends ~ /libwxgtk(-media)?3\.0-0v5/; notes = "#894663"; -export = false;
Bug#900678: wxwidgets3.0: wxGLCanvas doesn't work with Wayland
I've just uploaded wxwidgets3.0 3.0.4+dfsg-9 which includes a patch so the user should at least now get an error message instead of a segfault (patch originally from Scott Talbert): | wxGLCanvas is only supported on X11 currently. You may be able to | work around this by setting environment variable GDK_BACKEND=x11 before | starting your program. Cheers, Olly
Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package
On Thu, Aug 01, 2019 at 05:53:40PM +0200, Tobias Frost wrote: > On Wed, Jul 31, 2019 at 02:32:00PM -0400, Scott Talbert wrote: > > On Wed, 31 Jul 2019, Tobias Frost wrote: > > > > > A quick Thought: Would there be a possiblity to have at least an message > > > printed out on wayland before crashing emitted from wxwidgets? like a > > > warning "you are using GLCanvas under wayland, this app will crash!" > > > > Yes, in fact, I've upstreamed such a fix. I thought I had included that > > patch in Debian, but it appears that I have not. We can definitely do that. > > Cool. That would definitly help the users, especially if we can give > them a pointer how to get it working. I've just uploaded wxwidgets3.0 3.0.4+dfsg-9 which backports all relevant fixes from the upstream WX_3_0_BRANCH including this patch. So you should now get a message which says: | wxGLCanvas is only supported on X11 currently. You may be able to | work around this by setting environment variable GDK_BACKEND=x11 before | starting your program. I suspect this upload doesn't fix your hidpi problem, but it would be useful to check this and any other outstanding wx issues to make sure we aren't wasting time on issue upstream already fixed but just didn't get around to releasing. Cheers, Olly
Bug#933440:
On Fri, Aug 02, 2019 at 06:50:16PM +0200, Filip Hroch wrote: > > > > > Perhaps post a backtrace and maybe somebody can help? > > The crash can be encountered during startup, when a FITS file [1] > is passed as an argument. This is the second regular way for the > launch: users can pass the file, or double click in a graphical > file manager: I can't seem to reproduce this - I get a window appearing with a plausible looking image and histogram. Output to the terminal is: $ xmunipack --verbose munipack-data-m27/m27_01R.fits Debug: MuniView::HduSelect 0 Debug: MuniDisplayCanvas constructor.. Debug: Median=2938.00 MAD=29.01 Black=2912.00 Qlight=902.301575 n=5968 Debug: Median=2938.00 MAD=29.01 Black=2912.00 Qlight=902.301575 n=5968 Debug: hist: 2856.00 3373.00 32 16.156250 2940.00 32768 Debug: stat: 33.00 2937.00 17696 2860.00 11 Debug: MuniDisplayCanvas::OnRenderFinish 1 Debug: MuniDisplayCanvas::OnRenderFinish 0 Debug: MuniDisplayCanvas::StopRendering() > * The uncertainty is also confirmed by Valgrind. If I run under valgrind no problems are reported. > I used a development branch, which is configured as I just adjusted "Build-Depends:" of the package currently in unstable and rebuilt. Perhaps the problem is specific to the development branch? I've attached the debdiff for the package I built. Cheers, Olly
Bug#933440:
On Wed, Jul 31, 2019 at 12:25:26PM +0200, Filip Hroch wrote: > Currently, while building itself is clean, the compiled > xmunipack binary mysteriously crashes. It seems to work for me, though maybe it only crashes on some particular action I didn't try. Perhaps post a backtrace and maybe somebody can help? Cheers, Olly
Bug#933471: ctsim: Please rebuild against wxWidgets GTK 3 package
Control: tags 933471 + patch
Andreas Tille writes:
> Would you be able to propose a patch?
Attached.
I checked this builds and that the resultant binary package debdiff
against the version in unstable looks sensible, but I haven't attempted
to test running the result as I don't know anything about computed
tomography.
I suspect the configure probes could be simplified further by unifying
the handling for wxWin too so wx-config is used for that too (then the
wx_gtk and wx_mac variables could probably go away) but I resisting
touching that.
Cheers,
Olly
diff -Nru ctsim-6.0.2/debian/changelog ctsim-6.0.2/debian/changelog
--- ctsim-6.0.2/debian/changelog 2018-04-26 02:44:10.0 +1200
+++ ctsim-6.0.2/debian/changelog 2019-08-01 12:44:48.0 +1200
@@ -1,3 +1,11 @@
+ctsim (6.0.2-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build against GTK+3 flavour of wxWidgets (Closes: #933471)
++ New patch: improve-configure-wx-probes.patch
+
+ -- Olly Betts Thu, 01 Aug 2019 12:44:48 +1200
+
ctsim (6.0.2-2) unstable; urgency=medium
* cme fix dpkg-control
diff -Nru ctsim-6.0.2/debian/control ctsim-6.0.2/debian/control
--- ctsim-6.0.2/debian/control 2018-04-26 02:44:10.0 +1200
+++ ctsim-6.0.2/debian/control 2019-08-01 11:34:29.0 +1200
@@ -9,7 +9,7 @@
libreadline-dev,
libgl1-mesa-dev,
libglu1-mesa-dev,
- libwxgtk3.0-dev,
+ libwxgtk3.0-gtk3-dev,
ctn-dev,
libpng-dev
Standards-Version: 4.1.4
diff -Nru ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch
--- ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch 1970-01-01 12:00:00.0 +1200
+++ ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch 2019-08-01 12:44:48.0 +1200
@@ -0,0 +1,74 @@
+Description: Improve configure probes related to wxWidgets
+ Determine wxGTK vs wxMac by looking at output of wx-config --cppflags
+ rather than probing for particular libraries, the names of which can
+ vary (for example, depending on the GTK+ major version in use).
+ .
+ Don't hard code --version=3.0 in wx-config arguments. That way the
+ user can specify a different version via alternatives or explicitly on the
+ configure command line, e.g.:
+ .
+ ./configure wxconfig='/usr/bin/wx-config --version=3.1'
+ .
+ Remove probes for GTK and glib, which don't seem to be needed.
+Author: Olly Betts
+Bug-Debian: https://bugs.debian.org/933471
+Forwarded: no
+Last-Update: 2019-08-01
+
+--- a/configure.ac
b/configure.ac
+@@ -71,21 +71,15 @@
+ AC_CHECK_LIB(readline, main, [readline=true;
+ AC_DEFINE([HAVE_READLINE],1,[Readline library])],
+ [readline=false], [-lcurses])
+-wxwin=false
+-AC_CHECK_LIB(gtk-x11-2.0, main, [hasx11gtk2=true], [])
+-if test "x$hasx11gtk2" = "x" ; then
+- AC_MSG_NOTICE([Does not have X11 GTK2])
+- AC_DEFUN([AM_PATH_GLIB_2_0], [])
+- AC_DEFUN([AM_PATH_GTK_2_0], [])
+-fi
+-if test "$hasx11gtk2" = "true" ; then
+- AM_PATH_GLIB_2_0(2.0.0,,AC_MSG_ERROR(You should get glib 2.0.0 or better.))
+- AM_PATH_GTK_2_0(2.0.0,havegtk_am=yes,havegtk_am=no)
+- CFLAGS="${CFLAGS} ${g76GTK_CFLAGS} ${GLIB_CFLAGS}"
++wxwin=true
++case `$wxconfig --cppflags 2> /dev/null` in
++ *-D__WXGTK__*) wx_gtk=true ;;
++ *-D__WXMAC__*) wx_mac=true ;;
++ "") wxwin=false ;;
++esac
++if test "$wxwin" = true ; then
++ AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])
+ fi
+-
+-AC_CHECK_LIB(wx_gtk2u_core-3.0, main, [wxwin=true; wx_gtk=true; AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])], [], [-L/usr/lib64 -L/usr/lib ${GTK_LIBS} ${GLIB_LIBS} ])
+-AC_CHECK_LIB(wx_mac_core-3.0, main, [wxwin=true; wx_mac=true; AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])])
+ AC_CHECK_LIB(fftw3, fftw_malloc, [fftw=true; AC_DEFINE(HAVE_FFTW,1,[FFTW library])], [fftw=false], [-L/usr/lib64 -L/usr/lib])
+ AC_CHECK_LIB(GL, main, [libgl=true], [libgl=false], [-L/usr/X11R6/lib -L/usr/X11R6/lib64])
+ AC_CHECK_LIB(pthread, main, [pthread=true], [pthread=false])
+@@ -384,12 +378,7 @@
+if test "$debug" = "true"; then
+ wxdebug="--debug"
+fi
+- if test "x$wx_gtk" != "x" ; then
+- ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --version=3.0 --libs std,gl` ${GTK_LIBS} ${GLIB_LIBS}"
+-
+- elif test "x$wx_mac" != "x" ; then
+-ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --version=3.0 --libs std,gl`"
+- fi
++ ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --libs std,gl`"
+ fi
+ fi
+ if test "$wxwin" = "true" ; then
+@@ -462,8 +451,8 @@
+
+ if test "$wxwin" = "true" ; then
+ if test "$wx_gtk" = "true" -o "$w
Bug#933471: ctsim: Please rebuild against wxWidgets GTK 3 package
On Wed, Jul 31, 2019 at 11:54:51AM +0200, Andreas Tille wrote:
> I think I have solved the issue below in Git despite I'm very curious
> why I need to add a hack[1] to make sure all header files will be found
> properly.
You really should always run wx-config --cflags and put the result in
CXXFLAGS (or whatever equivalent the build system has).
In some cases you might get away with not doing that, but not here -
the libwxgtk3.0-dev and libwxgtk3.0-gtk3-dev packages are parallel
installable so the appropriate header search path needs to be specified
to the compiler.
> Unfortunately there is another build issue which I consider undependent
> from the wxgtk migration (not sure, may be its related anyway or may be
> its a gcc-9 issue?):
ctsim's configure.ac shows it probing directly for wx libraries:
| AC_CHECK_LIB(wx_gtk2u_core-3.0, main, [wxwin=true; wx_gtk=true;
AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])], [], [-L/usr/lib64 -L/usr/lib
${GTK_LIBS} ${GLIB_LIBS} ])
That library name is specific to a GTK2 build, but really these checks
should be done via wx-config (or one of the macros from wxwin.m4 which
call wx-config behind the scenes).
I also notice direct probing for GTK2 in there:
| AM_PATH_GTK_2_0(2.0.0,havegtk_am=yes,havegtk_am=no)
I'm not sure why that's done - a quick grep turned up no includes of gtk
headers, and havegtk_am's value never seems to be used. But it probably
needs removing or updating to GTK3 if it's actually needed.
Cheers,
Olly
Bug#900890: jugglemaster is dead upstream
Control: severity -1 serious On Wed, Jun 06, 2018 at 02:06:02PM +0200, Helmut Grohne wrote: > * After buster is released, raise severity of this bug to serious to >kick it out of testing. [...] > If you happen to read this after buster without severity serious, I > likely forgot and am happy if someone else does that. OK - we're now at this stage, so I've raised the severity. > * If nobody complains, request removal from Debian. > > If you happen to read this as someone porting jugglemaster to a newer > library version (e.g. ffmpeg/wx/aa). Please speak up in this bug before > performing the porting to avoid useless work. I'm happy to consider an > accelerated deprecation if the need arises. I'm also happy to consider > keeping it longer provided that it does not slow down any library > transitions. We're trying to move wx dependencies to using the GTK3 build of wx (see #933452). In many cases just updating the B-Ds should be enough, but each package updated really needs testing so now seems a good time to get jugglemaster out of testing (assuming you still plan not to have it in bullseye). Cheers, Olly
Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package
On Tue, Jul 30, 2019 at 01:57:08PM -0400, Scott Talbert wrote: > I'll look into adding the blocking indications to the tracking bug, but > admittedly, I'm not very good with the BTS (and documentation isn't the > best). I've just run a "bts" command to mark all the open "please rebuild" bugs as blocking the transition bug. > On Tue, 30 Jul 2019, Tobias Frost wrote: > > FTR, darkradiant is also affected by #900678. > > I'm not sure that we can afford to wait for a fix for #900678. There is no > movement upstream on that and it's more than just a fix - rather wxGLCanvas > needs to be ported to something like EGL instead of GLX. I can send you a > patch that adds the workaround to use X for you to consider. Although forcing X under GTK3 is a workaround, it's really no worse than sticking with GTK2 - the GTK2 build only works because GTK2 doesn't support Wayland directly at all, and so there use of X is implicitly forced. Cheers, Olly
Bug#900678: slic3r: Segfaults at start since new wxwidgets.
On Wed, Oct 10, 2018 at 09:26:17AM +1300, Olly Betts wrote: > 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. It occurs to me that we could add the code to force X11 so that it activates when the libwx_gtk3u_gl-3.0.so is loaded. If the app is linked to that library that makes it very likely wxGLCanvas will be used, and if it isn't linked to that library, it won't be. I tend to think this is probably better handled by adding workaround code to affected apps though - they'll need it to work under Wayland on other distros after all. Cheers, Olly
Bug#930335: unblock: therion/5.4.3ds1-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package therion.
This fixes a "Severity: important" bug in a "Priority: optional"
package, which is a regression from the version in stretch:
https://bugs.debian.org/930289
The diff is small so I've already uploaded to unstable as suggested by
the freeze policy. The package has successfully built for all release
architectures, and the autopkgtest is passing.
Debdiff against 5.4.3ds-5 (currently in testing) attached.
unblock therion/5.4.3ds1-6
Cheers,
Olly
diff -Nru therion-5.4.3ds1/debian/changelog therion-5.4.3ds1/debian/changelog
--- therion-5.4.3ds1/debian/changelog 2019-03-06 10:41:20.0 +1300
+++ therion-5.4.3ds1/debian/changelog 2019-06-10 12:33:11.0 +1200
@@ -1,3 +1,11 @@
+therion (5.4.3ds1-6) unstable; urgency=medium
+
+ * debian/patches/fix-epsg-esri-cs.patch: Fix coordinate system handling when
+more than one coordinate system is specified using an EPSG or ESRI code.
+(Closes: #930289)
+
+ -- Olly Betts Mon, 10 Jun 2019 12:33:11 +1200
+
therion (5.4.3ds1-5) unstable; urgency=medium
* debian/patches/fix-svg-export-segfault.patch: Fix segmentation fault when
diff -Nru therion-5.4.3ds1/debian/patches/fix-epsg-esri-cs.patch
therion-5.4.3ds1/debian/patches/fix-epsg-esri-cs.patch
--- therion-5.4.3ds1/debian/patches/fix-epsg-esri-cs.patch 1970-01-01
12:00:00.0 +1200
+++ therion-5.4.3ds1/debian/patches/fix-epsg-esri-cs.patch 2019-06-10
12:33:11.0 +1200
@@ -0,0 +1,292 @@
+Subject: [PATCH] New EPSG CS handling bugfix.
+ Therion 5.4.3 uses the wrong coordinate system if more than one
+ coordinate system is specified using an EPSG or ESRI code (the function
+ in question returns a pointer to a static variable which gets
+ overwritten if called again).
+Origin: upstream
+Author: Stacho Mudrak
+Bug-Debian: https://bugs.debian.org/930289
+Last-Update: 2019-06-10
+
+---
+ thconfig.cxx | 8
+ thcs.cxx | 4
+ thcs.h | 2 ++
+ thdataobject.cxx | 21 ++---
+ thexpmap.cxx | 4 ++--
+ thexpmodel.cxx | 12 ++--
+ thexptable.cxx | 2 +-
+ thexpuni.cxx | 12 ++--
+ 8 files changed, 35 insertions(+), 30 deletions(-)
+
+diff --git a/thconfig.cxx b/thconfig.cxx
+index 8af4192..d359829 100644
+--- a/thconfig.cxx
b/thconfig.cxx
+@@ -843,7 +843,7 @@ double thconfig::get_outcs_convergence()
+ {
+ double x, y, z;
+ if (this->get_outcs_center(x, y, z)) {
+-return thcsconverg(thcs_get_data(this->outcs)->params, x, y);
++return thcsconverg(thcs_get_params(this->outcs), x, y);
+ } else {
+ return 0.0;
+ }
+@@ -853,8 +853,8 @@ double thconfig::get_cs_convergence(int cs)
+ {
+ double x, y, z, lx, ly, lz;
+ if (this->get_outcs_center(x, y, z)) {
+-thcs2cs(thcs_get_data(this->outcs)->params, thcs_get_data(cs)->params, x,
y, z, lx, ly, lz);
+-return thcsconverg(thcs_get_data(cs)->params, lx, ly);
++thcs2cs(thcs_get_params(this->outcs), thcs_get_params(cs), x, y, z, lx,
ly, lz);
++return thcsconverg(thcs_get_params(cs), lx, ly);
+ } else {
+ return 0.0;
+ }
+@@ -868,7 +868,7 @@ bool thconfig::get_outcs_mag_decl(double year, double &
decl)
+ return false;
+ if ((year < double(thgeomag_minyear)) || (year > double(thgeomag_minyear +
thgeomag_step * (thgeomag_maxmindex + 1
+ return false;
+- thcs2cs(thcs_get_data(this->outcs)->params, "+proj=latlong +datum=WGS84",
x, y, z, lon, lat, alt);
++ thcs2cs(thcs_get_params(this->outcs), "+proj=latlong +datum=WGS84", x, y,
z, lon, lat, alt);
+ decl = thgeomag(lat, lon, alt, year);
+ return true;
+ }
+diff --git a/thcs.cxx b/thcs.cxx
+index 67b7514..6d565bb 100644
+--- a/thcs.cxx
b/thcs.cxx
+@@ -108,6 +108,10 @@ const char * thcs_get_name(int cs)
+ return csstr;
+ }
+
++std::string thcs_get_params(int cs) {
++ return std::string(thcs_get_data(cs)->params);
++}
++
+ const thcsdata * thcs_get_data(int cs) {
+ static thcsdata rv;
+ static char params[200];
+diff --git a/thcs.h b/thcs.h
+index 7906b53..cda4abc 100644
+--- a/thcs.h
b/thcs.h
+@@ -36,6 +36,8 @@ const char * thcs_get_name(int cs);
+
+ const thcsdata * thcs_get_data(int cs);
+
++std::string thcs_get_params(int cs);
++
+ void thcs_add_cs(char * id, char * proj4id, size_t nargs, char ** args);
+
+ #endif
+diff --git a/thdataobject.cxx b/thdataobject.cxx
+index c136adb..b6a038f 100644
+--- a/thdataobject.cxx
b/thdataobject.cxx
+@@ -423,11 +423,10 @@ void thdataobject::convert_cs(char * src_x, char *
src_y, double & dst_x, double
+ };
+
+ // 1. Conversion to numbers.
+- const thcsdata * csdata = thcs_get_data(this->cs);
+ int sv;
+ double tx(0.0), ty(0.0), tz(0.0), dst_z(0.0);
+ bool initcs(false);
+- if ((this->cs != TTCS_LOCAL) && csda
Bug#930289: therion quietly uses the wrong coordinate system
Package: therion Version: 5.4.3ds1-5 Severity: important Tags: upstream patch fixed-upstream Therion 5.4.3 uses the wrong coordinate system if more than one coordinate system is specified using an EPSG or ESRI code (the function in question returns a pointer to a static variable which gets overwritten if called again). This bug is a regression introduced upstream in 5.4.3 (as an unfortunate side-effect of eliminating an embedded copy of PROJ, which is something I'd been encouraging upstream to do) The bug can be worked around by specifying coordinate systems in a different way, but is rather problematic because there's usually no indication that wrong coordinate system has been used apart from getting incorrect answers out. It's fixed upstream in 5.4.4 by: https://github.com/therion/therion/commit/7a30b61b64223602c428e1ba2f70d3f84e52843c Cheers, Olly
Bug#929052: sffview FTCBFS: non-standard compiler variable
Control: forwarded -1 https://sourceforge.net/p/sfftools/tickets/1/ On Thu, May 16, 2019 at 10:23:40PM +0200, Helmut Grohne wrote: > On Thu, May 16, 2019 at 09:09:10PM +0100, Olly Betts wrote: > > I think it makes more sense to patch the upstream Makefile to use CXX > > instead of CC (we already patch it to support CXXFLAGS, etc). I should > > probably try to push that patch upstream, though upstream isn't very > > active. > > I concur that renaming the variable is a better solution. It would help > other distributions as well. Now filed upstream. > > This doesn't seem suitable for unstable during the freeze, but I'll > > upload to experimental. Feel free to NMU to unstable once we're > > unfrozen if I don't get to it. > > I concur that this is not freeze material (and that should be obvious > from the chosen severity). I don't think an experimental upload is > necessary here. Just make sure that you close this bug if you make > progress. Doing so will trigger a retest on my end (once it reaches > unstable) and I can reopen in case it still doesn't work. I've already uploaded. I wanted to test the amended patch built before pushing it upstream, so it was almost no extra work to make an upload of the build. Cheers, Olly
Bug#929052: sffview FTCBFS: non-standard compiler variable
On Thu, May 16, 2019 at 06:07:26AM +0200, Helmut Grohne wrote: > sffview fails to cross build from source, because it uses a non-standard > compiler variable CC for the C++ compiler. dh_auto_build passes a C > compiler there and that does not work well. The attached patch renames > the C++ compiler. Please consider applying it or using CXX in the > upstream build system. I think it makes more sense to patch the upstream Makefile to use CXX instead of CC (we already patch it to support CXXFLAGS, etc). I should probably try to push that patch upstream, though upstream isn't very active. This doesn't seem suitable for unstable during the freeze, but I'll upload to experimental. Feel free to NMU to unstable once we're unfrozen if I don't get to it. Cheers, Olly
Bug#923902: unblock: therion/5.4.3ds1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package therion.
This fixes a severity: important bug in a package of priority: extra:
https://bugs.debian.org/923737
The diff is small and clean so I've already uploaded to unstable as
suggested by the freeze policy. The package has successfully built for
all release architectures, and the autopkgtest is passing.
Debdiff against 5.4.3ds-4 (currently in testing) attached.
unblock therion/5.4.3ds1-5
Cheers,
Olly
diff -Nru therion-5.4.3ds1/debian/changelog therion-5.4.3ds1/debian/changelog
--- therion-5.4.3ds1/debian/changelog 2019-02-08 09:23:36.0 +1300
+++ therion-5.4.3ds1/debian/changelog 2019-03-06 10:41:20.0 +1300
@@ -1,3 +1,10 @@
+therion (5.4.3ds1-5) unstable; urgency=medium
+
+ * debian/patches/fix-svg-export-segfault.patch: Fix segmentation fault when
+producing SVG output. (Closes: #923737)
+
+ -- Olly Betts Wed, 06 Mar 2019 10:41:20 +1300
+
therion (5.4.3ds1-4) unstable; urgency=medium
* debian/tests/therion: Give up trying to compare output images for now -
diff -Nru therion-5.4.3ds1/debian/patches/fix-svg-export-segfault.patch
therion-5.4.3ds1/debian/patches/fix-svg-export-segfault.patch
--- therion-5.4.3ds1/debian/patches/fix-svg-export-segfault.patch
1970-01-01 12:00:00.0 +1200
+++ therion-5.4.3ds1/debian/patches/fix-svg-export-segfault.patch
2019-03-06 10:41:20.0 +1300
@@ -0,0 +1,31 @@
+Subject: [PATCH] fix segfault while generating SVG
+ std::map::erase(ITOR) invalidates ITOR, but returns an iterator pointing after
+ the removed element (either to the next element or an end iterator if that was
+ the last element).
+Origin: upstream
+Author: mbudaj
+Last-Update: 2019-03-06
+
+---
+ thepsparse.cxx | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/thepsparse.cxx b/thepsparse.cxx
+index cf574cf..087886b 100644
+--- a/thepsparse.cxx
b/thepsparse.cxx
+@@ -386,9 +386,11 @@ void MP_data::print_svg (ofstream & F, string
unique_prefix) {
+ }
+ // nemoze ist do predch. cyklu, lebo zmazanie smernika
+ // urobi chaos
+-for (map::iterator I = gstate.clippathdepth.begin();
+-I!= gstate.clippathdepth.end(); I++) {
+- if (I->second < 0) gstate.clippathdepth.erase(I);
++{auto I = gstate.clippathdepth.begin();
++ while (I!= gstate.clippathdepth.end()) {
++if (I->second < 0) I = gstate.clippathdepth.erase(I);
++else I++;
++ }
+ }
+ tmpclip = gstate.clippathdepth;
+ gstate = GSTATE_stack.back();
diff -Nru therion-5.4.3ds1/debian/patches/series
therion-5.4.3ds1/debian/patches/series
--- therion-5.4.3ds1/debian/patches/series 2019-01-09 09:14:45.0
+1300
+++ therion-5.4.3ds1/debian/patches/series 2019-03-06 10:41:20.0
+1300
@@ -1,3 +1,4 @@
10doc-fixes.patch
80debianise-makefiles.patch
90debianise-loch-makefile.patch
+fix-svg-export-segfault.patch
signature.asc
Description: PGP signature
Bug#923739: RM: apache-mod-auth-ntlm-winbind -- RoQA; Orphaned, dead upstream, insecure protocol
BTW, there don't seem to be any rdeps (I checked with dak rm). Cheers, Olly
Bug#923739: RM: apache-mod-auth-ntlm-winbind -- RoQA; Orphaned, dead upstream, insecure protocol
Package: ftp.debian.org Severity: normal I think it's time we dropped apache-mod-auth-ntlm-winbind. It's been orphaned in Debian for just over 3 years (I was the last maintainer). It's not been updated upstream for many years. I can't easily check exactly when as the upstream SVN repo which actually had the latest version seems to have gone away, and their git mirror seems to be missing the 16 most recent commits, but the packaged source is more than 8 years old and the git mirror's most recent change is from 2007-11-08. There are problems with NTLM's design which mean it's just not secure enough especially given the computing power that's now easily available to an attacker. Wikipedia has a summary: https://en.wikipedia.org/wiki/NT_LAN_Manager#Weakness_and_Vulnerabilities HTTP Negotiate Auth offers a more secure replacement option, provided you're able to run it over https. But thanks to LE https certificates can be had for free now. I didn't request removal when I orphaned the package in case it was still useful to someone in particular circumstances, but that was just over 3 years ago and the likelihood of that will have decreased still further. Cheers, Olly signature.asc Description: PGP signature
Bug#923737: therion: Segfault when producing SVG output
Package: therion Version: 5.4.3ds1-4 Severity: important Tags: patch On the upstream therion list Andrew Atkinson reported that SVG output fails with therion from Debian testing: > Using 5.4.3ds1-4 on Debian testing > > The thconfig.thc at > > http://www.cave-registry.org.uk/svn/WookeyCatchment/SludgePit/ > > works fine for pdf map output, but if I try to output svg a file is > produced that does not display in any of the svg programs I have. It > also does not finishing compiling giving a red ERROR in xtherion > > The log file just seems to stop [...] Full version at: https://mailman.speleo.sk/pipermail/therion/2019-February/007490.html Upstream has fixed this (it turns out to be due to a segfault): https://github.com/therion/therion/commit/947e9454814cb3c55d838bc45e52b832e752579a This makes the therion unusable for anyone wanting to produce SVG output, so it would be good to get this fixed for buster. Cheers, Olly
Bug#921912: libwxbase3.0-0v5-dbg: No buster libwxbase3.0-0v5-dbg
On Sun, Feb 10, 2019 at 01:38:18PM -0800, Ralf-Peter Rohbeck wrote: > On 2/10/19 12:12 PM, Olly Betts wrote: > > On Sat, Feb 09, 2019 at 09:29:10PM -0800, Ralf-Peter wrote: > > > I tried to debug a Wxwindows application but when I installed the > > > debug symbols, libwxbase3.0-0v5 was downgraded to the stretch version: > > The debug symbols are now in libwxbase3.0-0v5-dbgsym. > > > > Sounds like you have both stretch and buster in your sources list, hence > > the unhelpful behaviour when you try to install a package which isn't > > in buster. > > Nope, it's not there: > > root@tp:~# apt-cache search libwxbase3.0-0v5 > libwxbase3.0-0v5 - wxBase library (runtime) - non-GUI support classes of > wxWidgets toolkit > libwxbase3.0-0v5-dbg - debugging symbols for the wxBase library > root@tp:~# apt-cache search libwxbase3.0-0v5-dbgsym > root@tp:~# Then you probably haven't configured the apt source for them - see: https://wiki.debian.org/SourcesList#Debug_Symbol_Packages Cheers, Olly
Bug#917022: no multiarch support for wxrc
On Thu, Dec 27, 2018 at 11:37:28PM -0500, Scott Talbert wrote: > On Fri, 21 Dec 2018, Tomasz Słodkowicz wrote: > > wxrc (command line compiler for wxWidgets XML resources) binary is > > installed in /usr/bin. This blocks installing the same package with > > different architecture - required for cross compile. This can be moved > > to /usr/lib/ as described at > > https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages. > > > > I'm trying to install this on an amd64 host: > > apt-get install libwxgtk-webview3.0-dev:armhf wx-common > > I'm wondering if instead we could just mark wx-common as Multi-Arch: > foreign? Probably, assuming the other files in there are safe too. I have been repeatedly bitten by unwanted consequences from previous multi-arch changes to wx and other packages, but marking it as foreign seems less likely to cause problems than trying to move binaries around with the freeze looming. Cheers, Olly
Bug#914086: closed by Olly Betts (Bug#914086: fixed in wxwidgets3.0 3.0.4+dfsg-6)
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#914086: /usr/lib/*/wx/config/*: potentially broken if built on a merged-/usr system and run on a non-merged-/usr system
On Mon, Nov 19, 2018 at 02:56:18PM -0500, Scott Talbert wrote: > On Mon, 19 Nov 2018, Olly Betts wrote: > > On Mon, Nov 19, 2018 at 08:32:28AM +, Simon McVittie wrote: > > > This bug can probably be fixed by passing EGREP="/bin/grep -E" as an > > > additional command-line argument when invoking configure. > > > > That was my thought too. > > > > It would be nicer to address upstream, but I don't really see a way to > > do that cleanly short of rewriting it to just use shell built-ins, which > > seems like a lot of work as it's a hairy beast. > > Or we could just patch wx-config to set EGREP to "grep -E" (without the > path)? > > https://salsa.debian.org/freewx-team/wx/blob/wx3.0-debian/wx-config.in#L92 If you mean as an upstream patch, then you need to worry about systems where a suitable grep isn't on PATH (or where the PATH set when configure was run isn't the same as the PATH set when wx-config gets run). If you mean as a debian-specific patch, that means we get to carry a patch indefinitely. If it can be cleanly addressed by passing an extra option to configure that seems better to me. We can rely on "/bin/grep" continuing to work, it's just that "/usr/bin/grep" only works when /usr == / (and presumably whichever autoconf macro it is searches PATH and /usr/bin is before /bin on the default PATH so it finds /usr/bin/grep first). Cheers, Olly
Bug#914086: /usr/lib/*/wx/config/*: potentially broken if built on a merged-/usr system and run on a non-merged-/usr system
On Mon, Nov 19, 2018 at 08:32:28AM +, Simon McVittie wrote: > Recent tests on tests.reproducible-builds.org use unmerged /usr for the > first build and merged /usr for the second, as a way to detect some > issues in this class. Thanks for the report. $EGREP is used by the script, and changing it to point to a path that doesn't exists leads to wx-config failing with an error such as: Warning: No config found to match: /usr/bin/wx-config --cppflags in /usr/lib/x86_64-linux-gnu/wx/config I'd actually spotted this (also via reproducible-builds) yesterday but only after I made the recent upload. Unless any of the current buildds has a merged /usr I suggest we let that upload migrate to testing and then fix this. > This bug can probably be fixed by passing EGREP="/bin/grep -E" as an > additional command-line argument when invoking configure. That was my thought too. It would be nicer to address upstream, but I don't really see a way to do that cleanly short of rewriting it to just use shell built-ins, which seems like a lot of work as it's a hairy beast. Cheers, Olly
Bug#913085: stretch-pu: package xapian-core/1.4.3-2+deb9u3
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
I'd like to fix https://bugs.debian.org/912883 in stretch.
If changes to a new database which don't modify the termlist table
are committed, then a block which has been allocated to be the root
block in the termlist table gets leaked. This case is triggered by
notmuch - the result is a database which is slightly larger than
it would otherwise be, but works fine *except* that consistency
checking with xapian-check/Database::check() detects there's an
unused block not on the freelist and reports this as
"DatabaseCorruptError" - this tends to alarm users.
While tracking down the above problem, I found a second case where
blocks can be leaked when cancel_transaction() is called. I haven't
seen reports of this affecting anyone but the fix is trivial enough
that it seems worth fixing this as well.
* This bug is already fixed in unstable (also in testing and
stretch-backports)
* The bug is of severity "important"
* Bug meta-data is up to date
* The fix is minimal and includes a detailed changelog entry
* A source debdiff of the proposed change is attached
* The proposed package is versioned correctly (+deb9u3)
* The patch was in upstream release 1.4.6 and has been in Debian
unstable and testing for around 4 months. It has been confirmed as
fixing the problem with notmuch. The patch includes regression
tests. The proposed update passes the extensive upstream testsuite
which runs during the package build.
* The update was built in a stretch chroot
* This isn't a security issue so does not need coordination with the
security team
Cheers,
Olly
diff -Nru xapian-core-1.4.3/debian/changelog xapian-core-1.4.3/debian/changelog
--- xapian-core-1.4.3/debian/changelog 2018-08-13 18:19:13.0 +1200
+++ xapian-core-1.4.3/debian/changelog 2018-11-05 07:47:57.0 +1300
@@ -1,3 +1,11 @@
+xapian-core (1.4.3-2+deb9u3) stretch; urgency=medium
+
+ * fix-freelist-leaks.patch: Fix leaks of freelist blocks in corner cases
+which then get reported as "DatabaseCorruptError" by Database::check().
+ (Closes: #912883)
+
+ -- Olly Betts Mon, 05 Nov 2018 07:47:57 +1300
+
xapian-core (1.4.3-2+deb9u2) stretch; urgency=medium
* fix-glass-cursor-bug.patch: Fix glass backend bug with long-lived cursors
diff -Nru xapian-core-1.4.3/debian/patches/fix-freelist-leaks.patch
xapian-core-1.4.3/debian/patches/fix-freelist-leaks.patch
--- xapian-core-1.4.3/debian/patches/fix-freelist-leaks.patch 1970-01-01
12:00:00.0 +1200
+++ xapian-core-1.4.3/debian/patches/fix-freelist-leaks.patch 2018-11-05
07:47:51.0 +1300
@@ -0,0 +1,97 @@
+--- a/backends/glass/glass_table.cc
b/backends/glass/glass_table.cc
+@@ -1640,6 +1640,7 @@
+ /* writing - */
+ SET_REVISION(p, revision_number + 1);
+ C[0].set_n(free_list.get_block(this, block_size));
++ C[0].rewrite = true;
+ }
+ } else {
+ /* using a root block stored on disk */
+@@ -1855,9 +1856,7 @@
+ }
+ }
+
+-if (Btree_modified) {
+- faked_root_block = false;
+-}
++faked_root_block = false;
+ }
+
+ void
+@@ -1946,6 +1945,13 @@
+ item_count = root_info.get_num_entries();
+ faked_root_block = root_info.get_root_is_fake();
+ sequential = root_info.get_sequential();
++const string & fl_serialised = root_info.get_free_list();
++if (!fl_serialised.empty()) {
++ if (!free_list.unpack(fl_serialised))
++ throw Xapian::DatabaseCorruptError("Bad freelist metadata");
++} else {
++ free_list.reset();
++}
+
+ Btree_modified = false;
+
+--- a/tests/api_backend.cc
b/tests/api_backend.cc
+@@ -1555,3 +1555,23 @@
+ TEST_EQUAL(mset.get_matches_estimated() % 10, 0);
+ return true;
+ }
++
++/// Regression test for glass bug fixed in 1.4.6 and 1.5.0.
++DEFINE_TESTCASE(nodocs1, transactions && !remote) {
++{
++ Xapian::WritableDatabase db = get_named_writable_database("nodocs1");
++ db.set_metadata("foo", "bar");
++ db.commit();
++ Xapian::Document doc;
++ doc.add_term("baz");
++ db.add_document(doc);
++ db.commit();
++}
++
++size_t check_errors =
++ Xapian::Database::check(get_named_writable_database_path("nodocs1"),
++ Xapian::DBCHECK_SHOW_STATS, );
++TEST_EQUAL(check_errors, 0);
++
++return true;
++}
+--- a/tests/api_transdb.cc
b/tests/api_transdb.cc
+@@ -1,7 +1,7 @@
+ /** @file api_transdb.cc
+ * @brief tests requiring a database backend supporting transactions
+ */
+-/* Copyright (C) 2006,2009 Olly Betts
++/* Copyright (C) 2006,2009,2018 Olly Betts
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as pub
Bug#912883: libxapian30: freelist block leaks which are reported as corruption
Control: fixed -1 1.4.6-1 On Mon, Nov 05, 2018 at 07:09:04AM +1300, Olly Betts wrote: > Both of these were fixed in upstream xapian-core 1.4.7 - the combined > patch is attached. It was actually 1.4.6 that fixed this. Cheers, Olly
Bug#912883: libxapian30: freelist block leaks which are reported as corruption
Package: libxapian30
Version: 1.4.3-2+deb9u1
Severity: important
Tags: patch upstream
If changes to a new database which don't modify the termlist table
are committed, then a block which has been allocated to be the root
block in the termlist table gets leaked. This case is triggered by
notmuch - the result is a database which is slightly larger than
it would otherwise be, but works fine *except* that consistency
checking with xapian-check/Database::check() detects there's an
unused block not on the freelist and reports this as
"DatabaseCorruptError" - this tends to alarm users.
While tracking down the above problem, I found a second case where
blocks can be leaked when cancel_transaction() is called.
Both of these were fixed in upstream xapian-core 1.4.7 - the combined
patch is attached.
Cheers,
Olly
diff --git a/xapian-core/backends/glass/glass_table.cc b/xapian-core/backends/glass/glass_table.cc
index 7342f7496c48..1669431b6c6c 100644
--- a/xapian-core/backends/glass/glass_table.cc
+++ b/xapian-core/backends/glass/glass_table.cc
@@ -1639,6 +1639,7 @@ GlassTable::read_root()
/* writing - */
SET_REVISION(p, revision_number + 1);
C[0].set_n(free_list.get_block(this, block_size));
+ C[0].rewrite = true;
}
} else {
/* using a root block stored on disk */
@@ -1853,9 +1854,7 @@ GlassTable::flush_db()
}
}
-if (Btree_modified) {
- faked_root_block = false;
-}
+faked_root_block = false;
}
void
@@ -1944,6 +1943,13 @@ GlassTable::cancel(const RootInfo & root_info, glass_revision_number_t rev)
item_count = root_info.get_num_entries();
faked_root_block = root_info.get_root_is_fake();
sequential = root_info.get_sequential();
+const string & fl_serialised = root_info.get_free_list();
+if (!fl_serialised.empty()) {
+ if (!free_list.unpack(fl_serialised))
+ throw Xapian::DatabaseCorruptError("Bad freelist metadata");
+} else {
+ free_list.reset();
+}
Btree_modified = false;
diff --git a/xapian-core/tests/api_backend.cc b/xapian-core/tests/api_backend.cc
index a520be112286..a6d97742865f 100644
--- a/xapian-core/tests/api_backend.cc
+++ b/xapian-core/tests/api_backend.cc
@@ -1666,3 +1666,23 @@ DEFINE_TESTCASE(checkatleast4, backend) {
TEST_EQUAL(mset.size(), 0);
return true;
}
+
+/// Regression test for glass bug fixed in 1.4.6 and 1.5.0.
+DEFINE_TESTCASE(nodocs1, transactions && !remote) {
+{
+ Xapian::WritableDatabase db = get_named_writable_database("nodocs1");
+ db.set_metadata("foo", "bar");
+ db.commit();
+ Xapian::Document doc;
+ doc.add_term("baz");
+ db.add_document(doc);
+ db.commit();
+}
+
+size_t check_errors =
+ Xapian::Database::check(get_named_writable_database_path("nodocs1"),
+Xapian::DBCHECK_SHOW_STATS, );
+TEST_EQUAL(check_errors, 0);
+
+return true;
+}
diff --git a/xapian-core/tests/api_transdb.cc b/xapian-core/tests/api_transdb.cc
index eda0a6ef5936..32eede143f5a 100644
--- a/xapian-core/tests/api_transdb.cc
+++ b/xapian-core/tests/api_transdb.cc
@@ -1,7 +1,7 @@
/** @file api_transdb.cc
* @brief tests requiring a database backend supporting transactions
*/
-/* Copyright (C) 2006,2009 Olly Betts
+/* Copyright (C) 2006,2009,2018 Olly Betts
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -126,3 +126,24 @@ DEFINE_TESTCASE(canceltransaction2, transactions) {
return true;
}
+
+/// Regression test for glass bug fixed in 1.4.6 and 1.5.0.
+DEFINE_TESTCASE(canceltransaction3, transactions && !remote) {
+{
+ Xapian::WritableDatabase db = get_named_writable_database("canceltransaction3");
+ db.begin_transaction();
+ Xapian::Document doc;
+ doc.add_term("baz");
+ db.add_document(doc);
+ db.cancel_transaction();
+ db.add_document(doc);
+ db.commit();
+}
+
+size_t check_errors =
+ Xapian::Database::check(get_named_writable_database_path("canceltransaction3"),
+Xapian::DBCHECK_SHOW_STATS, );
+TEST_EQUAL(check_errors, 0);
+
+return true;
+}
signature.asc
Description: PGP signature
Bug#912370: xapian-bindings breaks xapers autopkgtest
Control: reassign -1 xapian-core Control: found -1 xapian-core/1.4.8-1 Control: retitle -1 xapian-core: shlibs automatic update rule missing dependency Control: severity -1 serious Control: affects -1 xapian-bindings xapers On Tue, Oct 30, 2018 at 11:11:02PM +, Olly Betts wrote: > At first glance it looks like > there's a problem with xapian-core's shlibs but I'll dig into this more > in a bit and reassign as appropriate. That is indeed the problem. It's (since a few weeks ago) automatically generated based on the upstream shared library version information, but the rule to do that didn't get run automatically for the 1.4.8 update - looks like it needs a suitable dependency adding. Reassigning to xapian-core. Cheers, Olly
Bug#912370: xapian-bindings breaks xapers autopkgtest
Thanks for the report. On Tue, Oct 30, 2018 at 08:01:41PM +0100, Paul Gevers wrote: > Currently this regression is contributing to the delay of the migration > of xapian-bindings to testing [1]. Due to the nature of this issue, I > filed this bug report against both packages. Can you please investigate > the situation and reassign the bug to the right package? If needed, > please change the bug's severity. The failures are due to: ImportError: /usr/lib/python3/dist-packages/xapian/_xapian.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6Xapian8Document15remove_postingsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEjjj That method was added in xapian-core 1.4.8 so this looks like a xapian-bindings/xapian-core mismatch. At first glance it looks like there's a problem with xapian-core's shlibs but I'll dig into this more in a bit and reassign as appropriate. Cheers, Olly
Bug#912343: libxapian30: New term position bugs in 1.4.8
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#911631: nmu: rdeps of xapian-core round 3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu This is a second follow-up to my previous request binnmu request: https://bugs.debian.org/910549 Since then, packagesearch 2.7.10 was uploaded to unstable with amd64 binaries built against an out-of-date xapian-core (1.4.7-2, rather than 1.4.7-4 which fixed the issue that required these binNMUs). nmu packagesearch_2.7.10 . amd64 . -m 'Rebuild against libxapian30 with dependency in shlibs' dw packagesearch_2.7.10 . amd64 . -m 'libxapian-dev (>= 1.4.7-4)' Cheers, Olly P.S. for the maintainer of packagesearch: Ben, please ensure your build chroot is up-to-date (it must have been 2 weeks or more out of date for this to happen). Also, there's no need to be uploading binaries unless the package needs to go through NEW (which would also have avoided this happening in this case) - see: https://wiki.debian.org/SourceOnlyUpload signature.asc Description: PGP signature
Bug#911357: nmu: rdeps of xapian-core round 2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu This is a follow-up to my previous request binnmu request: https://bugs.debian.org/910549 Unfortunately I failed to include any epochs on the version numbers for the packages (because the epoch isn't present in the .buildinfo filenames I was working from) so new binnmu requests are needed for packages with an epoch in their version numbers. Also a kfreebsd-i386 build of doxygen built using an older libxapian-dev has been uploaded since my previous request. nmu plasma-desktop_4:5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-desktop_4:5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu plasma-workspace_4:5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-workspace_4:5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadiconsole_4:18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadiconsole_4:18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadi-search_4:18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadi-search_4:18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu doxygen_1.8.13-10 . kfreebsd-i386 . -m 'Rebuild against libxapian30 with dependency in shlibs' dw doxygen_1.8.13-10 . kfreebsd-i386 . -m 'libxapian-dev (>= 1.4.7-4)' Cheers, Olly signature.asc Description: PGP signature
Bug#910549: nmu: xapian-core_1.4.7-2
On Mon, Oct 08, 2018 at 12:29:54PM +1300, Olly Betts wrote: > The new xapian-core was uploaded close to two days ago and has > now built everywhere except kfreebsd-*. It's now built everywhere. > I'll recheck in a week in case there any further binary uploads built > against the old xapian-core, and follow-up with another request if > necessary. No further uploads which used the old libxapian-dev. There's been a notmuch upload using the new libxapian-dev, so notmuch no longer needs a binnmu. Here's a revised list for convenience: nmu pinot_1.05-2 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw pinot_1.05-2 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu zeitgeist_1.0.1-0.2 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw zeitgeist_1.0.1-0.2 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu maildir-utils_1.0-6 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw maildir-utils_1.0-6 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu baloo-kf5_5.49.0-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw baloo-kf5_5.49.0-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu recoll_1.24.1-3 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw recoll_1.24.1-3 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu plasma-desktop_5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-desktop_5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu plasma-workspace_5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-workspace_5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu aptitude_0.8.11-3 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw aptitude_0.8.11-3 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu packagesearch_2.7.9 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw packagesearch_2.7.9 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu cyrus-imapd_2.5.11-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw cyrus-imapd_2.5.11-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadiconsole_18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadiconsole_18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadi-search_18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadi-search_18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu libsearch-xapian-perl_1.2.25.2-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw libsearch-xapian-perl_1.2.25.2-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' Cheers, Olly
Bug#900678: slic3r: Segfaults at start since new wxwidgets.
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#910549: nmu: xapian-core_1.4.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Upstream xapian-core 1.4.6 added C++11 move constructors and move assignment operators when code using the xapian API is built with a C++11 or newer compiler, which GCC in unstable is by default. The compiler will very likely find places to use the move versions implicitly, so a package built against libxapian-dev >= 1.4.6-1 is unlikely to work with libxapian30 << 1.4.6.1 due to missing symbols. We'll often get away with this because the packages will generally be upgraded together, so that's probably why there's not been a flood of reports. This breakage was reported by a user who tried to perform a large upgrade by separately upgrading aptitude first: https://bugs.debian.org/910110 1.4.7-4 adds the appropriate dependency to libxapian30.shlibs, so any packages built against libxapian-dev 1.4.6-1 to 1.4.7-3 inclusive should be rebuilt so they automatically depend on libxapian30 (>= 1.4.6-1~) instead of just libxapian30. I've extracted a list of such packages based on the buildinfo files on mirror.ftp-master.d.o (thanks to pabs for suggesting this): nmu pinot_1.05-2 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw pinot_1.05-2 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu zeitgeist_1.0.1-0.2 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw zeitgeist_1.0.1-0.2 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu maildir-utils_1.0-6 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw maildir-utils_1.0-6 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu baloo-kf5_5.49.0-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw baloo-kf5_5.49.0-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu recoll_1.24.1-3 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw recoll_1.24.1-3 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu plasma-desktop_5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-desktop_5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu plasma-workspace_5.13.5-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw plasma-workspace_5.13.5-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu aptitude_0.8.11-3 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw aptitude_0.8.11-3 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu packagesearch_2.7.9 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw packagesearch_2.7.9 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu cyrus-imapd_2.5.11-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw cyrus-imapd_2.5.11-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadiconsole_18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadiconsole_18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu akonadi-search_18.08.1-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw akonadi-search_18.08.1-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu notmuch_0.28~rc0-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw notmuch_0.28~rc0-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' nmu libsearch-xapian-perl_1.2.25.2-1 . ANY . -m 'Rebuild against libxapian30 with dependency in shlibs' dw libsearch-xapian-perl_1.2.25.2-1 . ANY . -m 'libxapian-dev (>= 1.4.7-4)' The new xapian-core was uploaded close to two days ago and has now built everywhere except kfreebsd-*. I'll recheck in a week in case there any further binary uploads built against the old xapian-core, and follow-up with another request if necessary. Cheers, Olly signature.asc Description: PGP signature
Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"
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"
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"
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#892453: therion: Please use 'pkg-config' to find FreeType 2
Control: tags -1 + fixed-upstream On Thu, Mar 08, 2018 at 10:52:30PM +1100, hugh.mcmas...@outlook.com wrote: > If this bug is not resolved prior to the release of FreeType 2.9.1, > your package may FTBFS. Therion upstream recently fixed this in git master: https://github.com/therion/therion/issues/110 What's the likely timescale on FreeType 2.9.1 in unstable? Wondering if we can just pick up the change next time there's an upstream therion release. Cheers, Olly
Bug#894663: transition: wxwidgets3.0
On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote: > What is the status on this? Less progress than I'd like. Partly that's down to my not finding the time to push this along, but there are also two bugs which affect the GTK3 wx build but not the GTK2 one: OpenGL support doesn't work under wayland unless you force GTK3 to use X11 (#904753) - GTK2 doesn't support wayland, so essentially is always forcing X11 here. There's a coordinate overflow issue (#906060) which looks like it is probably not in wx itself, but in cairo or some other layer. The GTK2 build doesn't use those layers. The first can be worked around, but I don't think there's a known way to work around the second. > Are we planning to complete this transition > in buster (transition deadline being 2019-01-05) or it is fine if this > transition is first completed in bullseye ? I'd still love to complete it for buster, but I suspect we may well not manage to get all the remaining rdeps moved over. We never actually got around to filing bugs against rdeps, but perhaps we should to encourage them to move where there aren't any blockers. Cheers, Olly
Bug#900678: Processed: reassign 900678 to libwxbase3.0-0v5
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#909223: libwxbase3.0-0v5: crash in wxFont::Create with gnuplot-qt: corrupted double-linked list
Thanks for your bug report. On Wed, Sep 19, 2018 at 11:47:08PM +0200, Vincent Lefevre wrote: > gnuplot-qt crashed, see attached backtrace. I didn't get any error > message, but the backtrace shows "corrupted double-linked list": > > [...] > #3 0x7f1f2a52ae0a in malloc_printerr (str=str@entry=0x7f1f2a62c3d6 > "corrupted double-linked list") at malloc.c:5350 > #4 0x7f1f2a52e386 in _int_malloc (av=av@entry=0x7f1f2a663c40 > , bytes=bytes@entry=32) at malloc.c:3926 > #5 0x7f1f2a52f7dd in __GI___libc_malloc (bytes=32) at malloc.c:3065 > #6 0x7f1f2a8ccfa8 in operator new(unsigned long) () at > /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > #7 0x7f1f2c702944 in wxFont::Create(int, wxFontFamily, wxFontStyle, > wxFontWeight, bool, wxString const&, wxFontEncoding) > (this=this@entry=0x7fffe5eaf8f0, pointSize=10, > family=family@entry=wxFONTFAMILY_SWISS, style=style@entry=wxFONTSTYLE_NORMAL, > weight=weight@entry=wxFONTWEIGHT_NORMAL, underlined=underlined@entry=false, > face=..., encoding=wxFONTENCODING_SYSTEM) at ../src/gtk/font.cpp:304 > [...] This is saying that glibc detected malloc heap corruption when wxWidgets tried to allocate memory. However that doesn't tell us anything about what caused that corruption - it's likely due to something writing off the end or start of an allocated block, or writing to an block that's already been released. That bad code could be in wxWidgets but it could just as easily be in another library that's in use, or in gnuplot itself. > This is not reproducible. Perhaps a race condition or memory corruption > that does not always produce a crash. I'm afraid that makes it very hard for us to usefully do anything, since we don't even know what software the bug is in. If it's something that happens sporadically I'd suggest you try habitually running gnuplot under a malloc debugger (e.g. valgrind if the slowdown is tolerable), and hope that catches the corruption as it happens. Cheers, Olly
Bug#908981: libetonyek: Please package tools
On Wed, Sep 19, 2018 at 08:07:30AM +0200, Rene Engelhard wrote: > On Mon, Sep 17, 2018 at 11:34:08AM +1200, Olly Betts wrote: > > Please add a libetonyek-tools binary package which includes these > > command line tools. > > Given that needs NEW it's not very likely I am doing it without needing > NEW anyway for an other reason... It would be binary-NEW though, which typically gets processed much more quickly than new source packages - last time I went through binary-NEW it was accepted the same day! I guess otherwise you're saying I'd need to wait for an upstream ABI bump - is one likely before buster? If not, I guess I'll have to look at packaging these tools in a separate source package, which doesn't seem very sensible overall. Cheers, Olly
Bug#908981: libetonyek: Please package tools
Source: libetonyek Version: 0.1.8-1 Severity: normal Thanks for packaging libetonyek. The upstream sources include some useful command line tools under src/conv such as "key2text". The current packaging builds these tools, but then fails to actually include them in a binary package. There's even an unused libetonyek-tools.install, though the contents seem to have just been copied from the libvisio packaging: https://sources.debian.org/src/libetonyek/0.1.8-1/debian/libetonyek-tools.install/ Please add a libetonyek-tools binary package which includes these command line tools. Cheers, Olly
Bug#907676: autopkgtests fail with LO 6.1 because LibreOfficeKit writes to stderr
On Fri, Aug 31, 2018 at 11:18:37AM +0200, Olivier Tilloy wrote: > Looks like I was too fast in assuming that Debian suffered the same > issue as observed on Ubuntu. > > Tests seem to pass at > https://ci.debian.net/packages/l/lloconv/unstable/amd64/, no output > observed on stderr. Except for one test run on 2018-08-24 03:42:33 UTC > (https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lloconv/872144/log.gz). > I wonder what changed between that test run and the next one that > passed. Not the version of libreoffice in any case. I see this message locally in some cases on Debian unstable - e.g. it's present with my example here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906715#20 But I don't get it if I run the autopkgtest commands locally. It's unclear to me what triggers it. Ideally we wouldn't spew useless messages to stderr, but that's really down to libreoffice and I don't think we want to get into trying to filter its stderr output (and throwing it all away seems unhelpful). So I'd agree that adding allow-stderr makes sense. I'll add it in the next upload (also happy for someone to NMU this fix). Cheers, Olly
Bug#906715: ITP: lloconv -- command line document converter using libreofficekit
On Mon, Aug 20, 2018 at 10:10:16AM +0200, Félix Sipma wrote: > Are you aware of "libreoffice --convert-to pdf --outdir . document.doc"? Yes. > It seems to work well, so I'm not sure what lloconv brings to the table :-). It's faster for a start - on a random .doc I have to hand: $ time lloconv disclosure.doc tmp.pdf No language whitelisted, turning off the language support. real0m0.431s user0m0.369s sys 0m0.069s $ time libreoffice --convert-to pdf --outdir . disclosure.doc > /dev/null real0m0.670s user0m0.548s sys 0m0.098s If you're just converting a single document then either is likely fine, but for converting a lot of documents the extra overhead often starts to matter. You can batch convert many files to a single format with --convert-to, but lloconv's server mode allows reusing a single LibreOfficeKit instance to perform conversions to any formats you want. A batch conversion with --convert-to also needs enough scratch space for all the output files, whereas an lloconv in server mode can be used to process files on demand. With lloconv you can specify options to the conversion (maybe --convert-to supports that too, but if so it seems to be undocumented). Sadly the LibreOfficeKit options are also rather poorly documented. I know of "SkipImages" (which is handy if you just want to extract text for indexing for example) as that's mentioned in the LOK headers, but if you can figure out the names I think this should allow setting options that you can set when exporting by hand. Also lloconv seems to be more reliable - on the trivial testcase from the autopkgtest in the lloconv package, libreoffice --convert-to gives a blank PDF for no obvious reason: $ echo 'foohello world' > in.html $ libreoffice --convert-to pdf --outdir . in.html [...] $ pdftotext in.pdf $ ls -l in.txt -rw-r--r-- 1 olly olly 1 Aug 21 08:46 in.txt Cheers, Olly
Bug#906715: ITP: lloconv -- command line document converter using libreofficekit
Package: wnpp Severity: wishlist Owner: Olly Betts * Package name: lloconv Version : 6.1.0 Upstream Author : Olly Betts * URL : https://gitlab.com/ojwb/lloconv * License : MPL-2.0 Programming Lang: C++ Description : command line document converter using LibreOfficeKit A command line document format converter which uses LibreOffice (via its LibreOfficeKit API) to do all the hard work. It should support the same formats which LibreOffice does. LibreOfficeKit was formerly known as liblibreoffice, hence the name "lloconv".
Bug#906088: stretch-pu: package xapian-core/1.4.3-2+deb9u2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu I'd like to fix https://bugs.debian.org/906007 in stretch. The glass backend (the default disk-based backend in Xapian 1.4.x) has a bug with long-lived cursors on a table in a WritableDatabase which can get into an invalid state, typically leading to a DatabaseCorruptError being thrown with the message: Db block overwritten - are there multiple writers? But in fact the on-disk database is not corrupted - it's just that the cursor in memory has got into an inconsistent state. It looks like we'll always detect the inconsistency before it can cause on-disk corruption but it's hard to be completely certain. The usage patterns of notmuch can trigger this bug (at least two different notmuch users have hit it, and both reported 1.4.7 fixed their problems). It's also been encountered by at least one other person in their own code (they provided a cut-down reproducer that helped pin it down). * This bug is already fixed in unstable (also in testing and stretch-backports) * The bug is of severity "important" * Bug meta-data is up to date * The fix is minimal and includes a detailed changelog entry * A source debdiff of the proposed change is attached * The proposed package is versioned correctly (+deb9u2) * The patch came from upstream release 1.4.7 and has been in unstable and testing for more than three weeks. The backported version 1.4.7-1~bpo9+1 has been confirmed as fixing the bug by affected users. The proposed update passes the extensive upstream testsuite which runs during the package build. * The update was built in a stretch chroot I'll upload the package shortly as per the updated workflow for stable updates. Cheers, Olly diff -Nru xapian-core-1.4.3/debian/changelog xapian-core-1.4.3/debian/changelog --- xapian-core-1.4.3/debian/changelog 2018-07-06 09:52:48.0 +1200 +++ xapian-core-1.4.3/debian/changelog 2018-08-13 18:19:13.0 +1200 @@ -1,3 +1,12 @@ +xapian-core (1.4.3-2+deb9u2) stretch; urgency=medium + + * fix-glass-cursor-bug.patch: Fix glass backend bug with long-lived cursors +on a table in a WritableDatabase which could incorrectly lead to +DatabaseCorruptError being thrown when the database was actually OK. +(Closes: #906007) + + -- Olly Betts Mon, 13 Aug 2018 18:19:13 +1200 + xapian-core (1.4.3-2+deb9u1) stretch; urgency=medium * Fix MSet::snippet() to escape HTML in all cases (CVE-2018-499). diff -Nru xapian-core-1.4.3/debian/patches/fix-glass-cursor-bug.patch xapian-core-1.4.3/debian/patches/fix-glass-cursor-bug.patch --- xapian-core-1.4.3/debian/patches/fix-glass-cursor-bug.patch 1970-01-01 12:00:00.0 +1200 +++ xapian-core-1.4.3/debian/patches/fix-glass-cursor-bug.patch 2018-08-13 18:17:34.0 +1200 @@ -0,0 +1,63 @@ +Description: Fix glass bug with WritableDatabase cursors + A long-lived cursor on a table in a WritableDatabase could get into + an invalid state, which typically resulted in a DatabaseCorruptError + being thrown with the message: + . + Db block overwritten - are there multiple writers? + . + But in fact the on-disk database is not corrupted - it's just that + the cursor in memory has got into an inconsistent state. It looks + like we'll always detect the inconsistency before it can cause on-disk + corruption but it's hard to be complete certain. + . + The bug is in code to rebuild the cursor when the underlying table + changes in ways which require that. That's a fairly rare occurrence + (with my C++ reproducer it happens 99 times out of 5000 commits). + . + In chert the equivalent code just marks the cursor's blocks as not yet + read, but in glass cursor blocks are reference counted and shared so we + can't simply do that as it could affect other cursors sharing the same + blocks. + . + So instead the glass code was leaving them with the contents they + previously had, except for copying the current root block from the + table's "built-in cursor". After the rebuild we seek the cursor to the + same key it was on before, and that mostly works because we follow down + each level in the Btree from the new root, except it can happen that the + old cursor contained a block number which has since been released and + reallocated, and in that case the block doesn't get reread and we try to + use its old contents, which violates the rule that a parent can't be + younger than its child and causes the exception. + . + This commit fixes this by simply resetting the rebuilt cursor to match + the current "built-in cursor" at all levels (not just the root), which + is cheap because of the reference counting. + . + Reported with a reproducer by Sylvain Taverne. Confirmed by David + Bremner as fixing a problem in notmuch without a reduced reproducer. +Author: Olly Betts +Bug-Debian: https://bugs.debian.org/906007 +Origin: upstream +Forwarded: ht
Bug#906007: libxapian30: Cursor handling bug in glass backend
Package: libxapian30 Version: 1.4.3-2+deb9u1 Severity: important Tags: patch upstream Control: fixed -1 1.4.7-1 The glass backend (the default disk-based backend in Xapian 1.4.x) has a bug with long-lived cursors on a table in a WritableDatabase which can get into an invalid state, typically leading to a DatabaseCorruptError being thrown with the message: Db block overwritten - are there multiple writers? But in fact the on-disk database is not corrupted - it's just that the cursor in memory has got into an inconsistent state. It looks like we'll always detect the inconsistency before it can cause on-disk corruption but it's hard to be completely certain. The bug is in code to rebuild the cursor when the underlying table changes in ways which require that, which is a fairly rare occurrence to start with, and only triggers when a block in the cursor has been released, reallocated, and we tried to load it in the cursor at the same level - the cursor wrongly assumes it has the current version of the block. The usage patterns of notmuch can trigger this bug (at least two different notmuch users have hit it, and both reported 1.4.7 fixed their problems). It's also been encountered by at least one other person in their own code (they provided a cut-down reproducer that helped pin it down). This bug was fixed in upstream 1.4.7 which was released and packaged for Debian 3.5 weeks ago - no issues have been reported with the fix. https://git.xapian.org/?p=xapian;a=commitdiff;h=70266397a517e213977f49c5b7c2c91389c88879 I'm intending to propose fixing this in stretch. Cheers, Olly
Bug#897857:
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
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, );
+ 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, ) : 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, ) : 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_TypeError( "",
Bug#897857:
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#905126: www.debian.org: Website search box unhelpful for common names (e.g. Buster) in certain character sets
On Wed, Aug 01, 2018 at 01:41:24PM +0200, Laura Arjona Reina wrote:
> On Tue, 31 Jul 2018 21:40:18 +0800 Jonathan Wiltshire
> wrote:
> > A number of search languages end up with no results for contextually
> > common search terms, for example "debian" or "buster".
> >
> > To reproduce:
> > - use the search box for the term "buster" in English. There are a
> >number of results including release information, news items and
> >errata.
> > - set the language to Vietnamese, Chinese or similar and search again
> > - there are no results.
>
> I can reproduce that. However, searching in Vietnamese for "Debian" or
> "Buster" shows results.
>
> E.g. the search for "Buster" in Vietnamese produces this link as first
> match:
>
> https://www.debian.org/releases/index.vi.html
> 100% relevant, matching: buster
>
> Interestingly, it says "matching: buster" (smallcaps, but I searched for
> Buster)
>
> If I search for "buster" (with quotes), I also get the results.
The matching isn't case-sensitive (but capitalising a word in the query
suppresses stemming, as does putting it in quotes).
> The relevant code in the Debian website about this bug is in the file
> webwml/english/search.xml.in, that I think it just sends the search term
> to the search engine (which is in search.debian.org):
>
> <:my $ext = lc('$(CUR_ISO_LANG)'); $ext =~ s/-/_/;
> print
> 'template="https://search.debian.org/cgi-bin/omega?P={searchTerms}HITSPERPAGE={count?}DB='.$ext.'[CN:-cn:][TW:-tw:][HK:-hk:]"/>';
> :>
It looks to me like the problem is there's no explicit stemmer mapping
for zh-cn so it uses the English stemmer, but that stemmer wasn't used
at index time. Those mappings are in:
/srv/search.debian.org/xapian/templates/inc/stemmer
(At least on wolkenstein - the host key for search.d.o doesn't seem
to match for me so I didn't look there yet - probably I need to update
my debian hosts list. The setup is that search.debian.org is
cgi-grnet-01.debian.org, but the indexing actually happens on
wolkenstein.debian.org and the databases replicated to the front-end
machine).
I'm not sure how the stemmer mapping file is generated, but I'll look
into it today if I can. I think we should be able to just specify a
default of "none" but I suspect this file is generated so I need to
fix the script not just the current output.
> I couldn't find a canonical repository or pseudopackage related to
> search.debian.org. For what I've search, it is a "a slightly patched
> xapian-omega instance". I've logged in the machine and the code there
> has two remote repositories. I'm CC'ing Raphael Geissert (shown as
> contact for comments in the search result pages) and Olly Betts (shown
> as the author of the last commits in the repo that is currently deployed
> in search.debian.org). I hope they can help or tell us how to proceed.
Thanks for looping me in.
I think that "slightly patched" is out of date and we've been using the
standard xapian-omega package for some time now.
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)
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#904753: python3-wxgtk4.0: wx.glcanvas.GLCanvas causes segfault
On Fri, Jul 27, 2018 at 03:24:51PM +0100, David Miguel Susano Pinto wrote: > The GLCanvas class from wx causes a segfault. This bug was not > present in Debian Jessie [...] wxpython4.0 isn't available in Jessie (and 4.0 was a complete rewrite, so comparing with wxpython3.0 is rather meaningless). Cheers, Olly
Bug#904116: clang-6.0: Memory sanitiser false positives
Package: clang-6.0
Version: 1:6.0.1-2
Severity: normal
The attached reduced testcase gives a false positive with memory
sanitiser:
Uninitialized bytes in __interceptor_memcmp at offset 0 inside [0x7ffc2bd76598,
1)
==16008==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7fe07c37b069 in std::__cxx11::basic_string, std::allocator >::compare(char const*) const
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x120069)
#1 0x49a6be in bool std::operator==,
std::allocator >(std::__cxx11::basic_string,
std::allocator > const&, char const*)
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.h:6075:20
#2 0x49a612 in bool std::operator!=,
std::allocator >(std::__cxx11::basic_string,
std::allocator > const&, char const*)
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/basic_string.h:6113:22
#3 0x49a3f9 in main
/home/olly/git/xapian-1.4/xapian-core/tests/memsanfalsepositive.cc:5:41
#4 0x7fe07bee0b16 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
#5 0x41e349 in _start
(/home/olly/git/xapian-1.4/xapian-core/tests/a.out+0x41e349)
SUMMARY: MemorySanitizer: use-of-uninitialized-value
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x120069) in
std::__cxx11::basic_string, std::allocator
>::compare(char const*) const
Exiting
I suspect the problem might be that libstdc++ needs to be built with
memory sanitiser too - the documentation at
https://clang.llvm.org/docs/MemorySanitizer.html#limitations notes:
| MemorySanitizer requires that all program code is instrumented. This
| also includes any libraries that the program depends on, even libc.
| Failing to achieve this may result in false reports.
(I get what appears to be the same error if I use clang-7
1:7~svn331965-1 instead, but since that seems to be an SVN snapshot
version, I've reported this against the stable release version).
Cheers,
Olly
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages clang-6.0 depends on:
ii binutils 2.31.1-1
ii libc62.27-5
ii libc6-dev2.27-5
ii libclang-common-6.0-dev 1:6.0.1-2
ii libclang1-6.01:6.0.1-2
ii libgcc-7-dev 7.3.0-26
ii libgcc1 1:8.1.0-11
ii libjsoncpp1 1.7.4-3
ii libllvm6.0 1:6.0.1-2
ii libobjc-7-dev7.3.0-26
ii libstdc++-7-dev 7.3.0-26
ii libstdc++6 8.1.0-11
Versions of packages clang-6.0 recommends:
ii libomp-dev6.0.1-1
ii llvm-6.0-dev 1:6.0.1-2
ii python2.7.15-3
Versions of packages clang-6.0 suggests:
pn clang-6.0-doc
pn gnustep
pn gnustep-devel
-- no debconf information
#include
inline std::string foo(std::string s) { return s; }
int main(int, char**) { return foo("x") != "x"; }
Bug#903088: stretch-pu: package xapian-core/1.4.3-2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
This proposed update fixes CVE-2018-0499, an incomplete HTML escaping
bug in xapian-core.
I've discussed with the security-team and they proposed fixing this via
the imminent stretch point release.
The Debian bug is https://bugs.debian.org/902886 which has severity
important and is already fixed in unstable by version 1.4.6-1.
The patch was in an upstream release and vulnerability disclosure 4 days
ago and has been in unstable for 3 days now, without any problems
reported to the BTS or to upstream.
A source debdiff of the proposed update xapian-core 1.4.3-2+deb9u1 is
attached. I've already uploaded this (in line with the updated SPU
workflow).
Cheers,
Olly
diff -Nru xapian-core-1.4.3/debian/changelog xapian-core-1.4.3/debian/changelog
--- xapian-core-1.4.3/debian/changelog 2017-04-06 06:48:18.0 +1200
+++ xapian-core-1.4.3/debian/changelog 2018-07-06 09:52:48.0 +1200
@@ -1,3 +1,10 @@
+xapian-core (1.4.3-2+deb9u1) stretch; urgency=medium
+
+ * Fix MSet::snippet() to escape HTML in all cases (CVE-2018-499).
+New patch: cve-2018-0499-mset-snippet-escaping.patch (Closes: #902886)
+
+ -- Olly Betts Fri, 06 Jul 2018 09:52:48 +1200
+
xapian-core (1.4.3-2) unstable; urgency=medium
* Fix incorrect results for unweighted AND with certain subqueries (new
diff -Nru
xapian-core-1.4.3/debian/patches/cve-2018-0499-mset-snippet-escaping.patch
xapian-core-1.4.3/debian/patches/cve-2018-0499-mset-snippet-escaping.patch
--- xapian-core-1.4.3/debian/patches/cve-2018-0499-mset-snippet-escaping.patch
1970-01-01 12:00:00.0 +1200
+++ xapian-core-1.4.3/debian/patches/cve-2018-0499-mset-snippet-escaping.patch
2018-07-06 09:52:24.0 +1200
@@ -0,0 +1,110 @@
+Description: Fix incomplete HTML escaping in MSet::snippet()
+ Characters <, > and & were escaped in some cases, but not all - this patch
+ adds escaping in the missing cases. This issue has been allocated
+ CVE-2018-0499.
+Author: Olly Betts
+Bug-Debian: https://bugs.debian.org/902886
+Origin: upstream
+Last-Update: 2018-07-06
+
+--- a/queryparser/termgenerator_internal.cc
b/queryparser/termgenerator_internal.cc
+@@ -432,6 +432,27 @@ SnipPipe::done()
+ }
+ }
+
++inline void
++append_escaping_xml(const char* p, const char* end, string& output)
++{
++while (p != end) {
++ char ch = *p++;
++ switch (ch) {
++ case '&':
++ output += "";
++ break;
++ case '<':
++ output += "";
++ break;
++ case '>':
++ output += "";
++ break;
++ default:
++ output += ch;
++ }
++}
++}
++
+ inline bool
+ SnipPipe::drain(const string & input,
+ const string & hi_start,
+@@ -465,7 +486,7 @@ SnipPipe::drain(const string & input,
+
+ if (punc) {
+ // Include end of sentence punctuation.
+- output.append(input.data() + best_end, i.raw());
++ append_escaping_xml(input.data() + best_end, i.raw(), output);
+ } else {
+ // Append "..." or equivalent if this doesn't seem to be the start
+ // of a sentence.
+@@ -523,8 +544,7 @@ SnipPipe::drain(const string & input,
+ while (i != Utf8Iterator()) {
+ unsigned ch = *i;
+ if (Unicode::is_wordchar(ch)) {
+- const char * p = input.data() + best_begin;
+- output.append(p, i.raw() - p);
++ append_escaping_xml(input.data() + best_begin, i.raw(), output);
+ best_begin = i.raw() - input.data();
+ break;
+ }
+@@ -537,22 +557,9 @@ SnipPipe::drain(const string & input,
+ if (phrase_len) output += hi_start;
+ }
+
+-while (best_begin != word.term_end) {
+- char ch = input[best_begin++];
+- switch (ch) {
+- case '&':
+- output += "";
+- break;
+- case '<':
+- output += "";
+- break;
+- case '>':
+- output += "";
+- break;
+- default:
+- output += ch;
+- }
+-}
++const char* p = input.data();
++append_escaping_xml(p + best_begin, p + word.term_end, output);
++best_begin = word.term_end;
+
+ if (phrase_len && --phrase_len == 0) output += hi_end;
+
+--- a/tests/api_snippets.cc
b/tests/api_snippets.cc
+@@ -313,3 +313,23 @@ DEFINE_TESTCASE(snippet_empty, backend) {
+
+ return true;
+ }
++
++/// Check snippets escape HTML/XML suitably.
++DEFINE_TESTCASE(snippet_html_escape, backend) {
++Xapian::Enquire enquire(get_database("apitest_simpledata"));
++enquire.set_query(Xapian::Query("foo"));
++
++Xapian::MSet mset = enquire.g
Bug#902886: CVE-2018-0499: HTML escaping bug
Package: libxapian30
Version: 1.4.5-1
Severity: important
Tags: security patch upstream
I spotted an HTML escaping bug in Xapian::MSet::snippet() while working
on the code. This issue has been assigned CVE-2018-0499 by the security
team.
This bug is fixed by yesterday's upstream release 1.4.6 which I'm
intending to upload to unstable very shortly. The attached patch should
be suitable for fixing this in older 1.4.x releases (1.2.x isn't
affected).
Cheers,
Olly
diff --git a/xapian-core/queryparser/termgenerator_internal.cc b/xapian-core/queryparser/termgenerator_internal.cc
index 7fa807db6064..fece98554ebb 100644
--- a/xapian-core/queryparser/termgenerator_internal.cc
+++ b/xapian-core/queryparser/termgenerator_internal.cc
@@ -432,6 +432,27 @@ SnipPipe::done()
}
}
+inline void
+append_escaping_xml(const char* p, const char* end, string& output)
+{
+while (p != end) {
+ char ch = *p++;
+ switch (ch) {
+ case '&':
+ output += "";
+ break;
+ case '<':
+ output += "";
+ break;
+ case '>':
+ output += "";
+ break;
+ default:
+ output += ch;
+ }
+}
+}
+
inline bool
SnipPipe::drain(const string & input,
const string & hi_start,
@@ -465,7 +486,7 @@ SnipPipe::drain(const string & input,
if (punc) {
// Include end of sentence punctuation.
- output.append(input.data() + best_end, i.raw());
+ append_escaping_xml(input.data() + best_end, i.raw(), output);
} else {
// Append "..." or equivalent if this doesn't seem to be the start
// of a sentence.
@@ -523,8 +544,7 @@ SnipPipe::drain(const string & input,
while (i != Utf8Iterator()) {
unsigned ch = *i;
if (Unicode::is_wordchar(ch)) {
- const char * p = input.data() + best_begin;
- output.append(p, i.raw() - p);
+ append_escaping_xml(input.data() + best_begin, i.raw(), output);
best_begin = i.raw() - input.data();
break;
}
@@ -537,22 +557,9 @@ SnipPipe::drain(const string & input,
if (phrase_len) output += hi_start;
}
-while (best_begin != word.term_end) {
- char ch = input[best_begin++];
- switch (ch) {
- case '&':
- output += "";
- break;
- case '<':
- output += "";
- break;
- case '>':
- output += "";
- break;
- default:
- output += ch;
- }
-}
+const char* p = input.data();
+append_escaping_xml(p + best_begin, p + word.term_end, output);
+best_begin = word.term_end;
if (phrase_len && --phrase_len == 0) output += hi_end;
diff --git a/xapian-core/tests/api_snippets.cc b/xapian-core/tests/api_snippets.cc
index 4c9296f88d84..70f6afac28bf 100644
--- a/xapian-core/tests/api_snippets.cc
+++ b/xapian-core/tests/api_snippets.cc
@@ -313,3 +313,23 @@ DEFINE_TESTCASE(snippet_empty, backend) {
return true;
}
+
+/// Check snippets escape HTML/XML suitably.
+DEFINE_TESTCASE(snippet_html_escape, backend) {
+Xapian::Enquire enquire(get_database("apitest_simpledata"));
+enquire.set_query(Xapian::Query("foo"));
+
+Xapian::MSet mset = enquire.get_mset(0, 0);
+
+Xapian::Stem stem;
+
+const char *input = "#include to use libfoo";
+TEST_STRINGS_EQUAL(mset.snippet(input, 12, stem),
+ "...foo.h to...");
+
+input = " takes the address of foo";
+TEST_STRINGS_EQUAL(mset.snippet(input, strlen(input), stem),
+ "foo takes the address of foo");
+
+return true;
+}
signature.asc
Description: PGP signature
Bug#833692: pinot: links GPLv2+ code with OpenSSL
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
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
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?
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
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?
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#894663: transition: wxwidgets3.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition There are now packages with a GTK3 build of wxwidgets3.0, and these have just migrated to testing. We'd like to start to encourage dependent packages to switch to this instead of the GTK2 build. The GTK2 and GTK3 flavours coexist so dependent packages can move over individually and we don't need a transition slot, but it would be useful to have a transition tracker set up to help track progress. We've already switched a few source packages. The list of remaining affected source packages is: 0ad 3depict 4pane aegisub amule audacity bochs bossa cba chipw codeblocks codelite ctsim cubicsdr darkradiant delaboratory dolphin-emu ebook2cwgui erlang espeakedit eviacam filezilla fityk flamerobin freedink-dfarc freedv freespace2-launcher-wxlauncher/contrib fwknop-gui gentle ginkgocadx gnudatalanguage gnuplot golly gspiceui hugin icinga2 jugglemaster kicad lamarc libwx-glcanvas-perl libwx-perl libwx-scintilla-perl limesuite maitreya mathgl mediainfo megaglest mriconvert mrpt munipack objcryst-fox openbabel openmsx-catapult openyahtzee passwordsafe pcsx2 pgadmin3 pgn2web plee-the-bear plplot poedit qutemol rapidsvn saga sandboxgamemaker/contrib scorched3d scummvm-tools silverjuke sitplus slic3r-prusa sooperlooper spatialite-gui spek springlobby stimfit stx-btree thuban tintii treesheets treeviewx trustedqsl ucblogo usbprog wxastrocapture wxhexeditor wxmaxima wxsqlite3 xchm xmlcopyeditor The procedure for updating these is to update the BDs to use the wxgtk*3.0-gtk3-dev package(s) instead of wxgtk*3.0-dev, check that the package still builds OK, and then check that the result works OK. (There's also wxpython3.0 which has already been switched but is waiting to clear binary-NEW.) Cheers, Olly Ben file: title = "wxwidgets3.0"; is_affected = .depends ~ "libwxgtk(-media)?3\.0-0v5" | .depends ~ "libwxgtk(-media)?3\.0-gtk3-0v5"; is_good = .depends ~ "libwxgtk(-media)?3\.0-gtk3-0v5"; is_bad = .depends ~ "libwxgtk(-media)?3\.0-0v5"; signature.asc Description: PGP signature
Bug#828503: pinot: FTBFS with openssl 1.1.0
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#894263: boinc: Renabling use of wxWebView
Source: boinc Version: 7.9.3+dfsg-1 Severity: normal Thanks to Scott Talbert we now have a GTK3 build of wxWidgets, which reinstates the webview package that boinc prefers to use but had to be disabled because the GTK2 version of the underlying library it uses was obsolete. Disabling webview apparently gives reduced functionality, so it would be good to reenable this now we can. Feel free to adjust severity - I just went for the default as I'm not entirely sure of the impact of disabling webview on users, but boinc upstream didn't seem happy about building without it. Assuming the upstream code support GTK3 (http://boinc.berkeley.edu/trac/wiki/SoftwarePrereqsUnix doesn't seem to even mention GTK is needed), it's probably a case of switching BDs from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev and libgtk2.0-dev to libgtk-3-dev (a quick look in codesearch suggests that GTK is needed for a custom taskbar widget, so that probably needs to match the GTK version used by wx). Cheers, Olly
Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk
On Tue, Feb 20, 2018 at 07:48:31AM +0100, Niels Thykier wrote: > Seen twice on lindsay.d.o in the last 24 hours. The exact reason is > unknown, but it is probably during the unpacker (last non-error in the > log is lintian starting the unpack, plus previously we had a race-condition > in the unpacker that could trigger a similar fork-bomp situation). > > Most likely we never fixed this condition and only made it > "sufficiently unlikely" until gcc-8-cross-ports showed up. > > For now, I have disabled the crontab on lindsay.d.o to avoid it taking > down our host. I tried to build the wxwidgets3.0 3.0.4+dfsg-1 in an unstable chroot a couple of days ago. I use sbuild and it's configured to run lintian in the chroot on the built packages. However lintian ran out of disk space in the chroot, which isn't something I have hit before. And I would expect the build itself to need more disk space than lintian (assuming that the debian/rules clean target is run before lintian is). Lintian appeared to be slowly failing on each binary package in turn, so I just hit Ctrl-C on it. I asked on #debian-devel in case this was a known problem, and lamby pointed out this ticket and suggested adding a note in case this is the same underlying issue, so I'm doing so. I didn't attempt to investigate further yet. Cheers, Olly
Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833
On Fri, Mar 09, 2018 at 07:00:50AM +0100, Sebastiaan Couwenberg wrote: > > There's now a patch for this: > > > > https://github.com/OSGeo/proj.4/pull/845 > > The changes look a little invasive, though. Yeah, I sighed a bit when I saw it looked like most of the file was rewritten. OTOH, it's an x.0.0 version with a new API added so presumably already full of invasive changes compared to 4.9.x - it's not like we're backporting a patch to Debian stable here. Looks like there are some teething problems with the patch but upstream are being responsive to dealing with them. Thanks for the package in experimental - I'll try to do some additional testing with Survex and that package. Cheers, Olly
Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833
Control: tags 892062 + patch On Sun, Mar 04, 2018 at 09:10:28PM +0100, Bas Couwenberg wrote: > forwarded 892062 https://github.com/OSGeo/proj.4/issues/833 > thanks There's now a patch for this: https://github.com/OSGeo/proj.4/pull/845 Cheers, Olly
Bug#889936: survex: FTBFS with proj 5.0.0
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#888334: survex: FTBFS with FFmpeg 3.5
On Sun, Jan 28, 2018 at 12:03:03AM +, James Cowgill wrote: > On 26/01/18 05:36, Olly Betts wrote: > > Based on the two errors in the log I've pushed a patch upstream (though > > not tested with the new FFmpeg yet): > > > > https://git.survex.com/?p=survex/.git;a=commit;h=5e46ae2e95e0f88c9efe8fe2a6632069ef09a18d > > I tested 1.2.32-1 with that commit applied and survex does build > successfully with FFmpeg 3.5. Thanks for testing. > > I'll probably wait for the next upstream release to upload, unless > > FFmpeg 3.5 appears first. > > That should be fine. I'm certainly happy for an NMU with the referenced commit if this becomes more pressing. Cheers, Olly
Bug#888334: survex: FTBFS with FFmpeg 3.5
Control: tags -1 + fixed-upstream patch > Build log: > https://people.debian.org/~jcowgill/ffmpeg-3.5-20180122/survex_amd64.build Thanks James, Based on the two errors in the log I've pushed a patch upstream (though not tested with the new FFmpeg yet): https://git.survex.com/?p=survex/.git;a=commit;h=5e46ae2e95e0f88c9efe8fe2a6632069ef09a18d I'll probably wait for the next upstream release to upload, unless FFmpeg 3.5 appears first. Cheers, Olly
Bug#884229: Bug #884229: [packages.debian.org] 500 error/Internal Server Error (in packages-pkgmirror-csail.debian.org)
On Wed, Jan 24, 2018 at 05:32:45PM +0100, Cyril Brulebois wrote: > > mod_fcgid: stderr: Can't call method "get_document" on an undefined value > > at ../lib/Packages/Search.pm line 264. > > End of script output before headers: dispatcher.fcgi > > Looking at the code, that's a method call on a xapian query result. > > Looking at the xapian directory on picconi: > > pkg_user@picconi:/srv/packages.debian.org$ ls -l files/db/xapian/ > > total 302384 > > -rw-r--r-- 1 pkg_user pkg_maint 1974272 Jan 24 15:56 docdata.glass > > -rw-r--r-- 1 pkg_user pkg_maint 0 Jan 24 15:53 flintlock > > -rw-r--r-- 1 pkg_user pkg_maint 138 Jan 24 15:56 iamglass > > -rw-r--r-- 1 pkg_user pkg_maint 181952512 Jan 24 15:56 position.glass > > -rw-r--r-- 1 pkg_user pkg_maint 80699392 Jan 24 15:56 postlist.glass > > -rw-r--r-- 1 pkg_user pkg_maint 44998656 Jan 24 15:56 termlist.glass > > Looking at the xapian directory on the mirror: > > pkg_user@pkgmirror-csail:/srv/packages.debian.org$ ls -l files/db/xapian/ > > total 537584 > > -rw-r--r-- 1 pkg_user pkg_maint 1974272 Jan 24 09:48 docdata.glass > > -rw-r--r-- 1 pkg_user pkg_maint 0 Jan 24 09:45 flintlock > > -rw-r--r-- 1 pkg_user pkg_maint28 Nov 8 09:26 iamchert > > -rw-r--r-- 1 pkg_user pkg_maint 138 Jan 24 09:48 iamglass > > -rw-r--r-- 1 pkg_user pkg_maint 1699 Nov 8 09:30 position.baseA > > -rw-r--r-- 1 pkg_user pkg_maint 1725 Nov 8 09:30 position.baseB > > -rw-r--r-- 1 pkg_user pkg_maint 111788032 Nov 8 09:30 position.DB > > -rw-r--r-- 1 pkg_user pkg_maint 181944320 Jan 24 09:48 position.glass > > -rw-r--r-- 1 pkg_user pkg_maint 1254 Nov 8 09:30 postlist.baseA > > -rw-r--r-- 1 pkg_user pkg_maint 1263 Nov 8 09:30 postlist.baseB > > -rw-r--r-- 1 pkg_user pkg_maint 81616896 Nov 8 09:30 postlist.DB > > -rw-r--r-- 1 pkg_user pkg_maint 80707584 Jan 24 09:48 postlist.glass > > -rw-r--r-- 1 pkg_user pkg_maint54 Nov 8 09:30 record.baseA > > -rw-r--r-- 1 pkg_user pkg_maint56 Nov 8 09:30 record.baseB > > -rw-r--r-- 1 pkg_user pkg_maint 2523136 Nov 8 09:30 record.DB > > -rw-r--r-- 1 pkg_user pkg_maint 691 Nov 8 09:30 termlist.baseA > > -rw-r--r-- 1 pkg_user pkg_maint 703 Nov 8 09:30 termlist.baseB > > -rw-r--r-- 1 pkg_user pkg_maint 44883968 Nov 8 09:30 termlist.DB > > -rw-r--r-- 1 pkg_user pkg_maint 45006848 Jan 24 09:48 termlist.glass > > For files dated Jan 24, the timestamps don't match, but that's probably > just a sync waiting to happen, and that doesn't explain the issues which > have been happening for so long. I suspected the stray files instead, > dating back to November. I've created an “old-files” directory and moved > them there, and the mirror seems to be behaving properly now. > > I'm tagging this bug report with “pending” for the time being, to give > people a chance to comment. But I suppose it should be safe to remove > those old files entirely? Yes. The directory on pkgmirror-csail actually had two different versions of the database using different database backends, so the files which aren't in the directory on picconi are essentially an old version of the same database. That alone shouldn't cause the search to fail though - it should just open one or the other (it looks like both Xapian 1.2.x and 1.4.x will open the old one in this rather odd situation). Xapian's replication should cleanly handle the database being replicated switching backends so I'm guessing the replication here is using rsync (without --delete-after) or similar? That might also explain why the old database is broken as the databases aren't safe to rsync if an update is in progress - if the last rsync of the old database happened while an update was in progress, it could have been left broken, which would typically result in particular searches failing. Updating with rsync can also break searches on the mirror while the rsync is in progress even if the master isn't updating, so perhaps we should switch to using Xapian's replication? That's already being used for the main website search (I set it up with weasel at Debconf 15). Happy to assist with that, though I'll probably need ssh access to pkgmirror-csail (seems I currently only have it for picconi). My Debian username is "olly". Cheers, Olly
Bug#877181: libwxgtk3.0-0v5: wxExecute fails with non-ascii characters
Control: tags -1 - patch On Fri, Sep 29, 2017 at 10:39:42PM +0100, Olly Betts wrote: > Control: forwarded -1 https://trac.wxwidgets.org/ticket/16206 > > On Fri, Sep 29, 2017 at 05:02:55PM +0300, Guy Rutenberg wrote: > > The fix is a simple one-line patch > > (https://github.com/wxWidgets/wxWidgets/commit/704055f200d97f327a8ee5212762b41bf1d6d503) > > which works for the current version (3.0.3.1) as well. You says this works for 3.0.3.1, but upstream says: | This is not trivial to backport, wxConvWhateverWorks doesn't exist in 3.0 And that indeed seems to be the case, so we don't actually have a patch we can use, hence I've removed the "patch" tag. Upstream are open to a patch which does backport this, but it's not a one line change. For more info, see: https://trac.wxwidgets.org/ticket/16206#comment:10 Cheers, Olly
Bug#876673: catdoc: diff for NMU version 1:0.95-4.1
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 <o...@survex.com> 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#872868: Bug#877023: debian-policy: No section numbers in policy.txt.gz
On Wed, Sep 27, 2017 at 06:43:41PM -0700, Russ Allbery wrote: > Olly Betts <o...@survex.com> writes: > > /usr/share/doc/debian-policy/policy.txt.gz no longer has any section > > numbers, which makes it useless as a way to quickly locate a policy > > section to quote to someone as a reference. The plain text version is > > the easiest to search, so this is a really annoying regression. > > Yeah, this is a limitation of Sphinx that hopefully will be fixed. It seems Sphinx upstream don't view this as a priority - at least they've not responded to the ticket at all nearly 3 months after it was opened: https://github.com/sphinx-doc/sphinx/issues/3998 > In the meantime, w3m to read the HTML version does work pretty well > and supports search (plus has an index that makes it pretty fast to > find particular sections). But I did the same thing you did, and > definitely want to fix this sooner rather than later. Perhaps for now it would be better to eschew Sphinx's text output and actually generate policy.txt using w3m something like this: w3m policy-1.html > policy.txt That gives a text file with section numbers and the formatting seems no worse overall than Sphinx's output (if anything it seems better as you don't have to wade through the massive TOC to get to actual content). Cheers, Olly
Bug#633466: lists.debian.org: List archive search delivers results containing removed spam messages
On Sun, Jul 10, 2011 at 04:57:38PM +0200, Frederik Schwarzer wrote: > If I search for e.g. "filmas" in all lists on > http://lists.debian.org/search.html > the result contains about 90% already removed spam messages. > > The results 2,3 and 4 for example are: > http://lists.debian.org/debian-68k/2011/01/msg00036.html > http://lists.debian.org/debian-alpha/2011/01/msg6.html > http://lists.debian.org/debian-amd64/2011/01/msg00013.html > > Is the search index outdated or are removed spam messages > recognised as normal messages? Thanks for reporting this, and sorry that it's not been addressed for so long. The main issue is that we don't currently have a process to purge removed spam from the index. I have been working on that, but it's not ready to deploy yet. However, we've just rebuilt the search index from scratch after upgrading the server to stretch, which means there's now nearly one million fewer already removed spam messages indexed - I just checked your example search and it currently returns valid links (many are spam, but spam that exists in the archives). Cheers, Olly
Bug#879893: Search on web returns Internal Server Error
On Fri, Oct 27, 2017 at 08:42:50AM +0200, Hanno 'Rince' Wagner wrote: > On Thu, 26 Oct 2017, Ondrej Tuma wrote: > > i try to search 'pyversions' in archive of > > debian-pyt...@lists.debian.org, but i got classic > > Apache Internal Server Error. > > Yes, you are right. we have a problem with our search engine, we are > working on it. It may take some days to fix it. Fixing this properly is going to take a while (days at least, maybe weeks) so I've installed a temporary solution to make the search functional while we work on it. Cheers, Olly
Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1
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#877181: libwxgtk3.0-0v5: wxExecute fails with non-ascii characters
Control: forwarded -1 https://trac.wxwidgets.org/ticket/16206 On Fri, Sep 29, 2017 at 05:02:55PM +0300, Guy Rutenberg wrote: > The fix is a simple one-line patch > (https://github.com/wxWidgets/wxWidgets/commit/704055f200d97f327a8ee5212762b41bf1d6d503) > which works for the current version (3.0.3.1) as well. While the patch is small, it changes established behaviour. And though arguably the current behaviour is not helpful for modern Linux, we need to think carefully before diverging from upstream on such things. So I've suggested upstream should backport this to 3.0.x as I'd like to see if they had a reason for not backporting this change already. It seems this issue can be avoided by setting the locale, or by using the char** overload of wxExecute - if upstream aren't going to fix this in 3.0.4, then apps would be well advised to make sure they do one of these things so that they work everywhere, rather than only on Debian. Cheers, Olly
Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1
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#877023: debian-policy: No section numbers in policy.txt.gz
Control: forcemerge 872868 877023 Sorry, I failed to spot the existing report. Cheers, Olly
Bug#877023: debian-policy: No section numbers in policy.txt.gz
Package: debian-policy Version: 4.1.0.0 Severity: important /usr/share/doc/debian-policy/policy.txt.gz no longer has any section numbers, which makes it useless as a way to quickly locate a policy section to quote to someone as a reference. The plain text version is the easiest to search, so this is a really annoying regression. Cheers, Olly
Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1
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 <o...@survex.com> 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 <o...@survex.com>
+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("htt
Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1
On Tue, Sep 26, 2017 at 08:24:06AM -0400, Scott Talbert wrote: > > > On September 26, 2017 1:54:34 AM EDT, Olly Betts <o...@survex.com> 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
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
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
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
Bug#876789: [Freewx-maint] Bug#876789: python-wxgtk-webview3.0: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1
On Mon, Sep 25, 2017 at 08:54:16PM -0400, Scott Talbert wrote: > On Tue, 26 Sep 2017, Olly Betts wrote: > >So it might not actually be as easy as you might think to disable > >webview here before we disable it in wxwidgets3.0... > > > >I'll kick off a build and see. If it doesn't just work, I'm inclined > >to disable this at the same time as we do wxwidgets3.0. 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. > Yeah, I would say we should just do this when wxwidgets3.0 loses its webkit1 > dependency (or preferably this problem just goes away when switching > wxwidgets to GTK+ 3). I wouldn't rely on a switch to GTK+ 3 happening for buster - I did a bit of work towards it, and upstream are responsive to reports of bugs under GTK+ 3 (at least when they can reproduce them) but unfortunately I don't really have the time to drive this forwards currently, and nobody else seems to be actively working on it. Cheers, Olly
