Re: Accepted wxwidgets3.2 3.2.2+dfsg-1 (source) into unstable

[Olly Betts]

On Sun, Feb 12, 2023 at 07:29:56PM -0500, Scott Talbert wrote:
> Sorry about that - I didn't realize that libalien-wxwidgets-perl had a
> dependency on an exact wxWidgets version (this is probably unnecessary; just
> a major.minor one is probably sufficient - that's what wxPython has).

Unfortunately the full upstream wxWidgets version is encoded in
libalien-wxwidgets-perl's "Provides:":

Provides: wxperl-gtk-3-2-1-uni-gcc-3-4

I don't know how easy that would be to change, but this probably isn't
an appropriate phase of the release cycle to try messing with this.

> Yes, a binNMU of libalien-wxwidgets-perl should fix it.

There was a note in README.source for wxwidgets3.0 which said:

After new upstream versions of this package are uploaded, you need to
ask the release team to binnmu libalien-wxwidgets-perl, and then
libwx-perl.

That's very likely still the case for wxwidgets3.2 (and probably we
should record this important detail in README.source there too...)

Cheers,
Olly

Bug#1033082: bullseye-pu: package xapian-core/1.4.18-3+deb11u1

[Olly Betts]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: xapian-c...@packages.debian.org
Control: affects -1 + src:xapian-core

[ Reason ]
This is a targetted fix for a potential database corruption if switching
the new revision live fails with ENOSPC but the recovery process does
NOT get ENOSPC:

https://bugs.debian.org/1032398

It looks like all previous 1.4.x releases are affected.  This is a
regression compared to Xapian 1.2.x (which was in jessie).

The fix here is taken from upstream's 1.4.22 release and is the simplest
way to address the problem: simply reread the current version file
from disk which means the in memory state will match the previously
committed state.

[ Impact ]
This can result in corrupted databases for users if their partition
fills up while indexing.  It doesn't happen every time, but it's
definitely been hit by one notmuch user on Debian, and likely explains
a smattering of reports of database corruption over the years.

[ Tests ]
There's a pretty thorough upstream testsuite for xapian-core.  The
specific scenario of ENOSPC isn't currently tested by that, but we've
exercised it by hand by injecting an ENOSPC failure using strace, which
reliably triggers corruption without the patch and no corruption with
it.

The fix was include in the upstream 1.4.22 release which was released
2023-02-02 (6 weeks ago) and uploaded to unstable the same day - there
haven't been any reports of issue with it.

[ Risks ]
This is a really low risk change.  It only touches the code path taken
when a commit operation fails to write to disk, and does a more complete
reset of state in that case.

The rollback being done here is actually more complicated than necessary
(the multiple tables are now committed together atomically, but used to
be committed one-by-one which required extra care to roll-back).  That's
been cleaned up on upstream git master, but I've gone for the simpler
and less invasive fix from upstream 1.4.x.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
The change switches from calling a function which attempts to roll-back
the in-memory state directly (but gets it wrong in this situation) to
one which resets the in-memory state to what it would be if the database
was opened afresh.

Cheers,
Olly
diff -Nru xapian-core-1.4.18/debian/changelog 
xapian-core-1.4.18/debian/changelog
--- xapian-core-1.4.18/debian/changelog 2021-02-24 07:33:41.0 +1300
+++ xapian-core-1.4.18/debian/changelog 2023-03-17 11:20:07.0 +1300
@@ -1,3 +1,15 @@
+xapian-core (1.4.18-3+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/fix-db-corruption-on-ENOSPC.patch: New patch to
+fix potential database corruption if switching the new revision
+live fails with ENOSPC but the recovery process does NOT get ENOSPC.
+The fix here is taken from upstream's 1.4.22 release and is the simplest
+way to address the problem: simply reread the current version file
+from disk which means the in memory state will match the previously
+    committed state.  Closes: #1032398
+
+ -- Olly Betts   Fri, 17 Mar 2023 11:20:07 +1300
+
 xapian-core (1.4.18-3) unstable; urgency=medium
 
   * debian/rules: Workaround testcase sensitivity to excess precision by
diff -Nru xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch
--- xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
1970-01-01 12:00:00.0 +1200
+++ xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
2023-03-17 11:20:07.0 +1300
@@ -0,0 +1,40 @@
+commit 90f7a35483b4cf7dd848c34634803bf28f95081d
+Author: Olly Betts 
+Date:   Wed Jan 25 11:40:44 2023 +1300
+
+Fix recovery from failed commit
+
+If renaming to switch the new version file live fails (e.g. due to
+ENOSPC) we discard the changes, try to write and switch to a different
+new version file with an increased revision (on failure of this too we
+close the database), and throw DatabaseError.
+
+Unfortunately the roll-back of state is not complete, and if switching
+to the different new version file succeeds that bad state persists on
+disk.
+
+Thanks to Uwe Kleine-König for reporting and coming up with the idea
+to reproduce using strace to inject a rename() failure - this is a
+simple reproducer:
+
+rm -rf enospc.db
+strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db 
< INSTALL
+xapian-check enospc.db
+
+No automated regression test for this yet as this doesn't trivially
+fit into the existing testsuite framework, but we ought to have
+t

Bug#930335: unblock: therion/5.4.3ds1-6

[Olly Betts]

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) &&

Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers

[Olly Betts]

severity 1019823 serious
severity 1019775 serious
severity 1019768 serious
severity 1019812 serious
severity 1019835 serious
severity 1019769 serious
severity 1019799 serious
severity 1019827 serious
severity 1019808 serious
severity 1019830 serious
severity 1019762 serious
severity 1019829 serious
severity 1019791 serious
severity 1019818 serious
severity 1019792 serious
severity 1019776 serious
severity 1019784 serious
severity 1019828 serious
severity 1019819 serious
severity 1019804 serious
severity 1019814 serious
severity 1019805 serious
severity 1019841 serious
severity 1019772 serious
severity 1019790 serious
severity 1019824 serious
severity 1019773 serious
severity 1019783 serious
severity 1019806 serious
severity 1019839 serious
severity 1019765 serious
severity 1019837 serious
severity 1019810 serious
severity 1019782 serious
severity 1019781 serious
severity 1019779 serious
thanks

Accounting for packages which are fixed in experimental or in git we're
now under 30 packages left to do, so raising the severity to "serious".

Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Please start to investigate making this transition if you haven't already.
In most cases it's proving to be an easy update, but in minority of
cases where there are obstacles it's much better to find that out sooner
rather than later.

Cheers,
Olly

Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers

[Olly Betts]

severity 1019833 serious
thanks

(I raised the severity of most of these yesterday, but missed packages
where an upload to experimental has closed the bug while it's not yet
fixed in unstable.)

Accounting for packages which are fixed in experimental or in git we're
now under 30 packages left to do, so raising the severity to "serious".

Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Please start to investigate making this transition if you haven't already.
In most cases it's proving to be an easy update, but in minority of
cases where there are obstacles it's much better to find that out sooner
rather than later.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

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#894663: transition: wxwidgets3.0

[Olly Betts]

On Mon, Sep 16, 2019 at 09:25:54AM -0400, Scott Talbert wrote:
> On Mon, 16 Sep 2019, Gunter Königsmann wrote:
> > That only partially answers my question. Currently I am playing with the
> > thought if the right idea would be uploading a wxMaxima version that
> > uses GTK3 to debian testing and looking if anyone except Vadim and me is
> > affected by the bug.

Note you don't upload to testing - you upload to unstable, and then
the package migrates to testing.

I think this is probably a good idea.  It seems there's something system
dependent here since wxmaxima rebuilt to use GTK3 doesn't seem to
flicker when scrolling horizontally or vertically to me, and so allowing
easy wider testing would be helpful in trying to work out what's going
on.

> Well, the only thing we can control is that the GTK2 build of wx will be
> gone in Bullseye, barring any unforseen circumstances.  Whether that will be
> with wx 3.0 or wx 3.2, remains to be seen.

At this point the wxwidgets3.0-gtk3 transition is reporting 54% done:

https://release.debian.org/transitions/

There's also one bug tagged "pending" and two packages uploaded to
"experimental", so effectively 57% if you include stuff that's in
progress (there are about 100 packages involved in all).

I think even if wx 3.2 does come out soon we'd really want to get the
current transition completed first.  Having to deal with 3 wx variants
at once sounds like more pain than necessary, and if we get the
GTK2->GTK3 issues dealt with now then that's less to deal with in the
second transition.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Tue, Sep 17, 2019 at 05:26:00PM +0200, Gunter Königsmann wrote:
> Making separate bug reports for that, too, and bisecting them costs more
> time than I currently have at hand. Which is why I asked if we
> absolutely need to switch to GTK3.

There's no *absolute* need, but it's unlikely wxmaxima would be in
bullseye if you insisted on sticking with GTK2.

But as Scott already said, there's time before bullseye to work through
remaining problems - that's why we started the transition early and
why we're trying to push it along now.  Please put your time and energy
into resolving any blockers rather than into questioning the transition.

The only potential fly in the ointment is that upstream are making
noises about 3.2.0 again - *if* a release actually happens and in time
for us to seriously consider it for bullseye then we'd really want to
get this transition done first.

Either way, the key thing is to provide upstream with clear bug reports
(and all the information in one place, not split over an upstream bug
report, a debian bug report, and a thread on an upstream mailing list
without even any links between any of them) and ideally their preferred
form of reproducer.

Cheers,
Olly

Bug#894663: Raising severity of wxwidgets3.0-gtk transition blockers

[Olly Betts]

severity 933407 serious
severity 933408 serious
severity 933411 serious
severity 933412 serious
severity 933415 serious
severity 933416 serious
severity 933419 serious
severity 933424 serious
severity 933425 serious
severity 933426 serious
severity 933427 serious
severity 933431 serious
severity 933433 serious
severity 933434 serious
severity 933435 serious
severity 933438 serious
severity 933440 serious
severity 933441 serious
severity 933442 serious
severity 933445 serious
severity 933451 serious
severity 933457 serious
severity 933459 serious
severity 933462 serious
severity 933463 serious
severity 933465 serious
severity 933466 serious
severity 933469 serious
severity 933473 serious
severity 933474 serious
severity 933475 serious
severity 933476 serious
severity 933478 serious
severity 933479 serious
severity 934096 serious
severity 934097 serious
severity 934098 serious
severity 933439 serious
severity 933458 serious
thanks

> We plan to remove the wxwidgets3.0 GTK2 packages before bullseye.  Please
> test *now* if you haven't already and report any problems you find.  If
> you don't find any problems, please upload your package.
>
> The severity of remaining bugs will be raised to "serious" once known
> blockers have been addressed.

All known blockers in wxwidgets3.0 have now been addressed, so I'm
raising the severity of remaining bugs.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Wed, Aug 07, 2019 at 08:29:50AM +1200, Olly Betts wrote:
> 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).

We're now at 94% with only 3 packages left:

* mrpt was updated but the build failed on mipsel due to running out of
  memory and it's now entangled in auto-opencv.  But it's due for AUTORM
  on 2019-10-28 so that should resolve itself within a week.

* codelite is orphaned and needs a new upstream version, but one of the
  upstream developers has prepared an update which is currently in the
  process of being sponsored.  If that doesn't happen, AUTORM is
  2019-10-30.

* filezilla seems to be immune to AUTORM (presumably due to its popcon
  score).  The maintainer appears to have prepared an upload 3.5 weeks
  ago but not uploaded it:
  https://qa.debian.org/cgi-bin/vcswatch?package=filezilla
  I have nudged them via #933416 and offered to sponsor it.  If there's
  no response I'll just upload it (it's already within the dev-ref rules
  for NMUing).  I've already checked what's in the VCS builds OK in
  current unstable.

So one way or another everything should be resolved by the end of this
month.  We can then upload wxwidgets3.0 dropping the GTK2 packages.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote:
> * mrpt was updated but the build failed on mipsel due to running out of
>   memory and it's now entangled in auto-opencv.  But it's due for AUTORM
>   on 2019-10-28 so that should resolve itself within a week.

No change here.

> * codelite is orphaned and needs a new upstream version, but one of the
>   upstream developers has prepared an update which is currently in the
>   process of being sponsored.

This has been uploaded and has built on all release archs.

> * filezilla seems to be immune to AUTORM (presumably due to its popcon
>   score).  The maintainer appears to have prepared an upload 3.5 weeks
>   ago but not uploaded it:

This has been uploaded and has built on all release archs.

However, checking with "dak rm" on coccia, I discovered four packages
which build-depend on libwxgtk3.0-dev but without a resulting runtime
dependency.  I've filed bugs against these and set them as blocking this
bug.  They should at least be easy to address.

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

On Fri, Oct 25, 2019 at 09:27:48AM +1300, Olly Betts wrote:
> On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote:
> > * mrpt was updated but the build failed on mipsel due to running out of
> >   memory and it's now entangled in auto-opencv.  But it's due for AUTORM
> >   on 2019-10-28 so that should resolve itself within a week.
> 
> No change here.

The AUTORM happened for mrpt.

> However, checking with "dak rm" on coccia, I discovered four packages
> which build-depend on libwxgtk3.0-dev but without a resulting runtime
> dependency.  I've filed bugs against these and set them as blocking this
> bug.  They should at least be easy to address.

Fixes for these extra four have now been uploaded and checking again:

olly@coccia:~$ dak rm -Rn -b libwxgtk3.0-dev
[...]
# Broken Depends:
wxsvg: libwxsvg-dev
wxwidgets3.0: libwxgtk-media3.0-dev

# Broken Build-Depends:
amule: libwxgtk3.0-dev
codeblocks: libwxgtk3.0-dev
cubicsdr: libwxgtk3.0-dev
objcryst-fox: libwxgtk3.0-dev
pcsx2: libwxgtk3.0-dev
sooperlooper: libwxgtk3.0-dev
treesheets: libwxgtk3.0-dev
ucblogo: libwxgtk3.0-dev
wxsvg: libwxgtk3.0-dev

Which is just the packages which are only in unstable, so aren't
blockers.

The codeblocks maintainers never responded, but taffit is preparing an
update to the latest upstream release so that at least should be off the
list fairly soon.

I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I
think we can consider this transition complete.  I'll leave actually
closing this bug to someone on the release team in case I've missed
something.

Upstream wx are making noises about actually releasing 3.2 early next
year, so we may have another wx transition before bullseye.  We've
managed to prune many of the rdeps which are inactive upstream and
unmaintained in Debian, so the next one should hopefully be less work.

Cheers,
Olly

Bug#837630: transition: xapian-core

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to transition the archive to Xapian 1.4 before the next
release.

There are packages of xapian-core 1.4.0 in experimental.  I maintain
xapian-bindings and xapian-omega, and packages of 1.4.0 for those are
also in experimental.  All three packages have built on all release
architectures:

https://buildd.debian.org/status/package.php?p=xapian-bindings+xapian-core+xapian-omega&suite=experimental

I've test rebuilt the other reverse dependencies and they all built
cleanly with the exception of:

 * pinot - this FTBFS in unstable due to GCC 6 (RC bug #812165) and
   (as I've noted in that bug) when I patch that and rebuild against
   xapian-core 1.4.0 the resulting binary segfaults when run, due to
   something which appears to be related to symbol mangling.  Since
   Xapian is GPLv2+ and pinot also links to openssl the package
   doesn't appear to be distributable anyway (RC bug #833692), and
   pinot has already been removed from testing, so this doesn't seem
   like a blocker for the transition.

 * libsearch-xapian-perl - this needs a patch for compatibility with
   xapian-core 1.4.  I have just completed such a patch, which I'm
   going to apply upstream, so depending when the transition is
   schedule we can either apply the patch or package a newer upstream
   version if one has been released by then.  I'm an uploader for this
   package, so can easily do either.

The auto-generated tracker looks good to me:
https://release.debian.org/transitions/html/auto-xapian-core.html

Cheers,
Olly


signature.asc
Description: PGP signature

Bug#837630: transition: xapian-core

[Olly Betts]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-xapian-core.html

On Thu, Sep 29, 2016 at 06:55:56PM +0200, Emilio Pozuelo Monfort wrote:
> On 13/09/16 06:50, Olly Betts wrote:
> > I've test rebuilt the other reverse dependencies and they all built
> > cleanly with the exception of:
> > 
> >  * pinot - this FTBFS in unstable due to GCC 6 (RC bug #812165) and
> >(as I've noted in that bug) when I patch that and rebuild against
> >xapian-core 1.4.0 the resulting binary segfaults when run, due to
> >something which appears to be related to symbol mangling.  Since
> >Xapian is GPLv2+ and pinot also links to openssl the package
> >doesn't appear to be distributable anyway (RC bug #833692), and
> >pinot has already been removed from testing, so this doesn't seem
> >like a blocker for the transition.
> > 
> >  * libsearch-xapian-perl - this needs a patch for compatibility with
> >xapian-core 1.4.  I have just completed such a patch, which I'm
> >going to apply upstream, so depending when the transition is
> >schedule we can either apply the patch or package a newer upstream
> >version if one has been released by then.  I'm an uploader for this
> >package, so can easily do either.

There's now a new upstream release of Search::Xapian with this patch in,
and the only other changes fix documentation typos, so I'll upload that
if the hyper-efficicent pkg-perl team don't first.

> > The auto-generated tracker looks good to me:
> > https://release.debian.org/transitions/html/auto-xapian-core.html
> 
> Go ahead!

Great, thanks.  I have just uploaded xapian-core 1.4.0-2 to unstable.

Assuming that looks good, I'll make sourceful uploads of xapian-bindings,
xapian-omega and libsearch-xapian-perl.

I'll also retest pinot in case the symbol mangling was due to a mix of
code compiled with GCC5 and GCC6 - IIRC the ABI has changed in some
obscure cases, so maybe this is due to one of those.

The rest of the pacakges in the tracker should just need a binNMU.

FYI, doxygen also BD on libxapian-dev, but the Xapian integration fails to
actually get enabled since upstream switched to cmake:

https://bugs.debian.org/822204

Cheers,
Olly

Bug#837630: transition: xapian-core

[Olly Betts]

On Thu, Sep 29, 2016 at 09:28:27PM +0100, Olly Betts wrote:
> On Thu, Sep 29, 2016 at 06:55:56PM +0200, Emilio Pozuelo Monfort wrote:
> > On 13/09/16 06:50, Olly Betts wrote:
> > > https://release.debian.org/transitions/html/auto-xapian-core.html
> > 
> > Go ahead!
> 
> Great, thanks.  I have just uploaded xapian-core 1.4.0-2 to unstable.

Done, and has now successfully built and installed on all release
architectures:

https://buildd.debian.org/status/package.php?p=xapian-core&suite=sid
 
> Assuming that looks good, I'll make sourceful uploads of xapian-bindings,
> xapian-omega and libsearch-xapian-perl.

All now uploaded and accepted.

> I'll also retest pinot in case the symbol mangling was due to a mix of
> code compiled with GCC5 and GCC6 - IIRC the ABI has changed in some
> obscure cases, so maybe this is due to one of those.

I solved this issue - the pinot sources hard code a mangled symbol
string.  It doesn't matter for this transition, but I've NMUed pinot
with this and the FTBFS with GCC6 fixed.

> The rest of the pacakges in the tracker should just need a binNMU.

For clarity, the following will need binNMUs:

akonadi-search
aptitude
baloo
khelpcenter
libept
libqapt
maildir-utils
notmuch
recoll
zeitgeist

And then:

goplay
packagesearch
synaptic

I'm in #debian-release - feel free to ping me about anything.

Cheers,
Olly


signature.asc
Description: PGP signature

Bug#844526: Bug#844486: gnuplot-qt: Mismatch between the program and library build versions with GNUTERM=wxt

[Olly Betts]

On Wed, Nov 16, 2016 at 08:14:00PM +0100, Anton Gladky wrote:
> block 844486 by 844526
> thanks
> 
> wxwidget should be binnmued to fix the bug properly.

I don't believe there's actually any real bug here, let alone an RC one.

GCC makes small fixes to obscure corner cases of the C++ ABI from time
to time and (not unreasonably) bumps the ABI version each time.  It used
to be the case that GCC defaulted to the old ABI version in this case,
but more recently they seem to make the new ABI version the default
instead.

In upstream wxWidgets, if the compile-time ABI and run-time ABI don't
match, then you get an error and the app won't run, which is just not
helpful.  In Debian we reduce that error to a warning - in practice I've
never seen an actual problem due to this, but leaving the warning there
means that this at least gets flagged as a potential issue.

However, if you want to eliminate this warning message and are going to
binNMU wxwidgets3.0 to that end, you will also need to binNMU any of its
rdeps which haven't been built with the newer compiler ABI, or else
you're just going to swap around which rdeps issue this warning.

Cheers,
Olly

Bug#820059: jessie-pu: package xapian-core/1.2.19-1

[Olly Betts]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update xapian-core in jessie to fix a bug which can cause
database corruption.  This is triggered by certain usage patterns, which
the recoll package performs:

https://bugs.debian.org/808610

It also affects some other users, but recoll is one I'm sure is affected
in jessie.

The attached patch is from the upstream git repo - it's been on git
master since 2015-04-28, and in upstream stable releases since
2015-05-20.

(wheezy is similarly affected - I can make a separate request for that
if you OK this one, but if you want to OK both now that's fine with me.
The patch for wheezy should be essentially identical).

Cheers,
Olly
Description: Increment cursor version of cancel or reopen
 Potentially increment the cursor version on cancel() or when the database is
 reopened, and flag the current cursor version as used when a cursor is
 rebuilt.
 .
 Fixes database corruption issues with certain usage patterns, which recoll
 can trigger.
Author: Olly Betts 
Origin: upstream, https://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git and https://trac.xapian.org/changeset/d784290ce015958474f965817f7a41f1483c3e03/git
Bug: https://trac.xapian.org/ticket/675
Bug-Debian: https://bugs.debian.org/808610
Forwarded: https://trac.xapian.org/ticket/675
Last-Update: 2016-04-05

--- a/backends/brass/brass_cursor.cc
+++ b/backends/brass/brass_cursor.cc
@@ -1,7 +1,7 @@
 /* brass_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
@@ -99,6 +99,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 BrassCursor::~BrassCursor()
--- a/backends/brass/brass_table.cc
+++ b/backends/brass/brass_table.cc
@@ -1446,6 +1446,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
+
 /* ready to open the main file */
 
 RETURN(true);
@@ -1985,6 +1990,11 @@
 changed_n = 0;
 changed_c = DIR_START;
 seq_count = SEQ_START_POINT;
+
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
 }
 
 / B-tree reading /
--- a/backends/chert/chert_cursor.cc
+++ b/backends/chert/chert_cursor.cc
@@ -1,7 +1,7 @@
 /* chert_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
@@ -97,6 +97,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 ChertCursor::~ChertCursor()
--- a/backends/chert/chert_table.cc
+++ b/backends/chert/chert_table.cc
@@ -1449,6 +1449,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
+
 /* ready to open the main file */
 
 RETURN(true);
@@ -2007,6 +2012,11 @@
 changed_n = 0;
 changed_c = DIR_START;
 seq_count = SEQ_START_POINT;
+
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+}
 }
 
 / B-tree reading /
--- a/backends/flint/flint_cursor.cc
+++ b/backends/flint/flint_cursor.cc
@@ -1,7 +1,7 @@
 /* flint_cursor.cc: Btree cursor implementation
  *
  * Copyright 1999,2000,2001 BrightStation PLC
- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
+ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
@@ -97,6 +97,7 @@
 C[level].n = B->C[level].n;
 C[level].p = B->C[level].p;
 version = B->cursor_version;
+B->cursor_created_since_last_modification = true;
 }
 
 FlintCursor::~FlintCursor()
--- a/backends/flint/flint_table.cc
+++ b/backends/flint/flint_table.cc
@@ -1438,6 +1438,11 @@
 
 base_letter = ch;
 
+if (cursor_created_since_last_modification) {
+	cursor_created_since_last_modification = false;
+	++cursor_version;
+

Bug#820059: jessie-pu: package xapian-core/1.2.19-1

[Olly Betts]

Control: tags -1 + patch
Control: tags -1 - moreinfo
 
On Wed, Apr 06, 2016 at 09:35:46PM +0100, Adam D. Barratt wrote:
> On Tue, 2016-04-05 at 17:06 +1200, Olly Betts wrote:
> > The attached patch is from the upstream git repo - it's been on git
> > master since 2015-04-28, and in upstream stable releases since
> > 2015-05-20.
> 
> In isolation the patch looks okay, but in order to confirm a upload
> please can we have a debdiff of the proposed source package, as built
> and tested on Jessie?

Attached.

Cheers,
Olly
diff -Nru xapian-core-1.2.19/debian/changelog 
xapian-core-1.2.19/debian/changelog
--- xapian-core-1.2.19/debian/changelog 2014-10-22 00:52:12.0 +1300
+++ xapian-core-1.2.19/debian/changelog 2016-04-19 12:09:08.0 +1200
@@ -1,3 +1,10 @@
+xapian-core (1.2.19-1+deb8u1) stable; urgency=medium
+
+  * New patch increment-cursor-version-on-cancel-or-reopen.patch fixing
+possible database corruption, especially with recoll.  (Closes: #808610)
+
+ -- Olly Betts   Tue, 19 Apr 2016 11:49:06 +1200
+
 xapian-core (1.2.19-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru 
xapian-core-1.2.19/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
 
xapian-core-1.2.19/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
--- 
xapian-core-1.2.19/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
1970-01-01 12:00:00.0 +1200
+++ 
xapian-core-1.2.19/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
2016-04-05 16:53:19.0 +1200
@@ -0,0 +1,197 @@
+Description: Increment cursor version of cancel or reopen
+ Potentially increment the cursor version on cancel() or when the database is
+ reopened, and flag the current cursor version as used when a cursor is
+ rebuilt.
+ .
+ Fixes database corruption issues with certain usage patterns, which recoll
+ can trigger.
+Author: Olly Betts 
+Origin: upstream, 
https://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git 
and 
https://trac.xapian.org/changeset/d784290ce015958474f965817f7a41f1483c3e03/git
+Bug: https://trac.xapian.org/ticket/675
+Bug-Debian: https://bugs.debian.org/808610
+Forwarded: https://trac.xapian.org/ticket/675
+Last-Update: 2016-04-05
+
+--- a/backends/brass/brass_cursor.cc
 b/backends/brass/brass_cursor.cc
+@@ -1,7 +1,7 @@
+ /* brass_cursor.cc: Btree cursor implementation
+  *
+  * Copyright 1999,2000,2001 BrightStation PLC
+- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
++ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
+@@ -99,6 +99,7 @@
+ C[level].n = B->C[level].n;
+ C[level].p = B->C[level].p;
+ version = B->cursor_version;
++B->cursor_created_since_last_modification = true;
+ }
+ 
+ BrassCursor::~BrassCursor()
+--- a/backends/brass/brass_table.cc
 b/backends/brass/brass_table.cc
+@@ -1446,6 +1446,11 @@
+ 
+ base_letter = ch;
+ 
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
++
+ /* ready to open the main file */
+ 
+ RETURN(true);
+@@ -1985,6 +1990,11 @@
+ changed_n = 0;
+ changed_c = DIR_START;
+ seq_count = SEQ_START_POINT;
++
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
+ }
+ 
+ / B-tree reading /
+--- a/backends/chert/chert_cursor.cc
 b/backends/chert/chert_cursor.cc
+@@ -1,7 +1,7 @@
+ /* chert_cursor.cc: Btree cursor implementation
+  *
+  * Copyright 1999,2000,2001 BrightStation PLC
+- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
++ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
+@@ -97,6 +97,7 @@
+ C[level].n = B->C[level].n;
+ C[level].p = B->C[level].p;
+ version = B->cursor_version;
++B->cursor_created_since_last_modification = true;
+ }
+ 
+ ChertCursor::~ChertCursor()
+--- a/backends/chert/chert_table.cc
 b/backends/chert/chert_table.cc
+@@ -1449,6 +1449,11 @@
+ 
+ base_letter = ch;
+ 
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
++
+ /* ready to open the main file */
+ 
+ RETURN(true);
+@@ -2007,6 +2012,11 @@
+ changed_n = 0;
+ changed_c = DIR_START;
+ seq_count = SEQ_START_POINT;
++
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
+ }
+ 
+ /*

Bug#821757: wheezy-pu: package xapian-core/1.2.12-2

[Olly Betts]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update xapian-core in wheezy to fix a bug which can cause
database corruption.  This is triggered by certain usage patterns, and
the recoll package is known to be affected:

https://bugs.debian.org/808610

I've attached a debdiff for the proposed upload.  The patch added is
from the upstream git repo - it's been on git master since 2015-04-28,
and in upstream stable releases since 2015-05-20.

There's already a pending request to address this in jessie:

https://bugs.debian.org/820059

The patch for wheezy is exactly the same as that for jessie, except with
a "quilt refresh" to adjust the line numbers of some of the hunks.

Cheers,
Olly
diff -Nru xapian-core-1.2.12/debian/changelog 
xapian-core-1.2.12/debian/changelog
--- xapian-core-1.2.12/debian/changelog 2012-12-11 17:22:23.0 +1300
+++ xapian-core-1.2.12/debian/changelog 2016-04-19 13:14:15.0 +1200
@@ -1,3 +1,10 @@
+xapian-core (1.2.12-2+deb7u1) oldstable; urgency=medium
+
+  * New patch increment-cursor-version-on-cancel-or-reopen.patch fixing
+possible database corruption, especially with recoll.  (Closes: #808610)
+
+ -- Olly Betts   Tue, 19 Apr 2016 13:13:31 +1200
+
 xapian-core (1.2.12-2) unstable; urgency=low
 
   * New patch fix-db-write-lock.patch which fixes database write locking to
diff -Nru 
xapian-core-1.2.12/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
 
xapian-core-1.2.12/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
--- 
xapian-core-1.2.12/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
1970-01-01 12:00:00.0 +1200
+++ 
xapian-core-1.2.12/debian/patches/increment-cursor-version-on-cancel-or-reopen.patch
2016-04-19 13:13:25.0 +1200
@@ -0,0 +1,197 @@
+Description: Increment cursor version of cancel or reopen
+ Potentially increment the cursor version on cancel() or when the database is
+ reopened, and flag the current cursor version as used when a cursor is
+ rebuilt.
+ .
+ Fixes database corruption issues with certain usage patterns, which recoll
+ can trigger.
+Author: Olly Betts 
+Origin: upstream, 
https://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git 
and 
https://trac.xapian.org/changeset/d784290ce015958474f965817f7a41f1483c3e03/git
+Bug: https://trac.xapian.org/ticket/675
+Bug-Debian: https://bugs.debian.org/808610
+Forwarded: https://trac.xapian.org/ticket/675
+Last-Update: 2016-04-19
+
+--- a/backends/brass/brass_cursor.cc
 b/backends/brass/brass_cursor.cc
+@@ -1,7 +1,7 @@
+ /* brass_cursor.cc: Btree cursor implementation
+  *
+  * Copyright 1999,2000,2001 BrightStation PLC
+- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
++ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
+@@ -99,6 +99,7 @@
+ C[level].n = B->C[level].n;
+ C[level].p = B->C[level].p;
+ version = B->cursor_version;
++B->cursor_created_since_last_modification = true;
+ }
+ 
+ BrassCursor::~BrassCursor()
+--- a/backends/brass/brass_table.cc
 b/backends/brass/brass_table.cc
+@@ -1435,6 +1435,11 @@
+ 
+ base_letter = ch;
+ 
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
++
+ /* ready to open the main file */
+ 
+ RETURN(true);
+@@ -1975,6 +1980,11 @@
+ changed_n = 0;
+ changed_c = DIR_START;
+ seq_count = SEQ_START_POINT;
++
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
+ }
+ 
+ / B-tree reading /
+--- a/backends/chert/chert_cursor.cc
 b/backends/chert/chert_cursor.cc
+@@ -1,7 +1,7 @@
+ /* chert_cursor.cc: Btree cursor implementation
+  *
+  * Copyright 1999,2000,2001 BrightStation PLC
+- * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012 Olly Betts
++ * Copyright 2002,2003,2004,2005,2006,2007,2008,2009,2010,2012,2015 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
+@@ -97,6 +97,7 @@
+ C[level].n = B->C[level].n;
+ C[level].p = B->C[level].p;
+ version = B->cursor_version;
++B->cursor_created_since_last_modification = true;
+ }
+ 
+ ChertCursor::~ChertCursor()
+--- a/backends/chert/chert_table.cc
 b/backends/chert/chert_table.cc
+@@ -1438,6 +1438,11 @@
+ 
+ base_letter = ch;
+ 
++if (cursor_created_since_last_modification) {
++  cursor_created_since_last_modification = false;
++  ++cursor_version;
++}
++
+ /* ready to open the ma

Bug#821757: wheezy-pu: package xapian-core/1.2.12-2

[Olly Betts]

On Tue, Apr 19, 2016 at 08:47:15PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Thanks, now uploaded.

Cheers,
Olly

Bug#820059: jessie-pu: package xapian-core/1.2.19-1

[Olly Betts]

On Tue, Apr 19, 2016 at 08:38:11PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Thanks, now uploaded.

Cheers,
Olly

Bug#859756: unblock: xapian-core/1.4.3-2

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xapian-core 1.4.3-2.  It's successfully built
on all release architectures (and most non-release ones).

This upload fixes important severity bug #857693 which is an upstream
bug which can lead to incorrect results being returned for queries
with certain boolean filters:

https://bugs.debian.org/857693

There are no other changes over 1.4.3-1, the version in testing.

I've attached a debdiff, which is the fix cherry-picked from upstream
git.  Most of the size is actually test coverage for the change in
the patch, so for easy review I've also attached a version of the
debdiff with that added test coverage removed.

In case you're not familiar with C++ details the key difference here
is that the new version initialises the allocated array to be all
0.0 (the old version left the memory uninitialised):

-  max_wt = new double [n_kids];
+  max_wt = new double [n_kids]();

unblock xapian-core/1.4.3-2

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-01-25 14:40:08.0 +1300
+++ xapian-core-1.4.3/debian/changelog  2017-04-06 06:48:18.0 +1200
@@ -1,3 +1,10 @@
+xapian-core (1.4.3-2) unstable; urgency=medium
+
+  * Fix incorrect results for unweighted AND with certain subqueries (new
+patch fix-unweighted-and.patch).  (Closes: #857693)
+
+ -- Olly Betts   Thu, 06 Apr 2017 06:48:18 +1200
+
 xapian-core (1.4.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru xapian-core-1.4.3/debian/patches/fix-unweighted-and.patch 
xapian-core-1.4.3/debian/patches/fix-unweighted-and.patch
--- xapian-core-1.4.3/debian/patches/fix-unweighted-and.patch   1970-01-01 
12:00:00.0 +1200
+++ xapian-core-1.4.3/debian/patches/fix-unweighted-and.patch   2017-04-06 
06:48:18.0 +1200
@@ -0,0 +1,66 @@
+Description: Fix incorrect results due to uninitialised memory
+The array holding max weight values in MultiAndPostList is never
+initialised if the operator is unweighted, but the values are still
+used to calculate the max weight to pass to subqueries, leading to
+incorrect results.  This can be observed with an OR under an unweighted
+AND (e.g. OR under AND on the right side of AND_NOT).
+
+The fix applied is to simply default initialise this array, which
+should lead to a max weight of 0.0 being passed on to subqueries.
+
+Bug reported in notmuch by Kirill A. Shutemov, and forwarded by
+David Bremner.
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/857693
+Origin: upstream
+Last-Update: 2017-04-06
+
+--- a/matcher/multiandpostlist.cc
 b/matcher/multiandpostlist.cc
+@@ -32,7 +32,7 @@
+ {
+ plist = new PostList * [n_kids];
+ try {
+-  max_wt = new double [n_kids];
++  max_wt = new double [n_kids]();
+ } catch (...) {
+   delete [] plist;
+   plist = NULL;
+--- a/tests/api_query.cc
 b/tests/api_query.cc
+@@ -658,3 +658,18 @@
+ 
+ return true;
+ }
++
++// Regression test for bug fixed in 1.4.4 and 1.2.25.
++DEFINE_TESTCASE(notandor1, backend) {
++Xapian::Database db(get_database("etext"));
++Xapian::Query q =
++  Xapian::Query("the") &~ (Xapian::Query("friedrich") &
++  (Xapian::Query("day") | Xapian::Query("night")));
++Xapian::Enquire enq(db);
++enq.set_query(q);
++
++Xapian::MSet mset = enq.get_mset(0, 10, db.get_doccount());
++TEST_EQUAL(mset.get_matches_estimated(), 344);
++
++return true;
++}
+--- a/tests/api_collated.h
 b/tests/api_collated.h
+@@ -301,6 +301,7 @@
+   { "zeroestimate1", test_zeroestimate1 },
+   { "complexphrase3", test_complexphrase3 },
+   { "complexnear3", test_complexnear3 },
++  { "notandor1", test_notandor1 },
+   { "wildquery1", test_wildquery1 },
+   { "snippet1", test_snippet1 },
+   { "snippetstem1", test_snippetstem1 },
+--- a/tests/api_query.h
 b/tests/api_query.h
+@@ -21,3 +21,4 @@
+ extern bool test_complexphrase3();
+ extern bool test_complexnear3();
+ extern bool test_subdbwithoutpos1();
++extern bool test_notandor1();
diff -Nru xapian-core-1.4.3/debian/patches/series 
xapian-core-1.4.3/debian/patches/series
--- xapian-core-1.4.3/debian/patches/series 1970-01-01 12:00:00.0 
+1200
+++ xapian-core-1.4.3/debian/patches/series 2017-04-06 06:48:13.0 
+1200
@@ -0,0 +1 @@
+fix-unweighted-and.patch
diff -Nru xapian-core-1.4.3/debian/changelog xapian-core-1.4.3/debian/changelog
--- xapian-core-1.4.3/debian/changelog  2017-01-25 14:40:08.0 +1300
+++ xapian-core-1.4.3/debian/changelog  2017-04-06 06:48:18.0 +1200
@@ -1,3 +1,10 @@
+xapian-core (1.4.3-2) 

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

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#910549: nmu: xapian-core_1.4.7-2

[Olly Betts]

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#910549: nmu: xapian-core_1.4.7-2

[Olly Betts]

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#911357: nmu: rdeps of xapian-core round 2

[Olly Betts]

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#911631: nmu: rdeps of xapian-core round 3

[Olly Betts]

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#913085: stretch-pu: package xapian-core/1.4.3-2+deb9u3

[Olly Betts]

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, &tout);
++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 th

Bug#923902: unblock: therion/5.4.3ds1-5

[Olly Betts]

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#870315: nmu: libwx-perl_1:0.9932-1+b1

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libwx-perl_1:0.9932-1+b1 . ANY . unstable . -m "Rebuild against rebuilt 
libalien-wxwidgets-perl."

After a new upstream upload of wxwidgets3.0, libalien-wxwidgets-perl needs
a binnmu because it generates a "Provides" based on the wxwidgets3.0 version
e.g.:

Provides: wxperl-gtk2-3-0-3-uni-gcc-3-4

That's already been done, but now libwx-perl needs a rebuilt so this change
is reflected in its "Depends", which currently doesn't match:

Depends: [...], wxperl-gtk2-3-0-2-uni-gcc-3-4, [...]

Cheers,
Olly

Bug#894663: transition: wxwidgets3.0

[Olly Betts]

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#903088: stretch-pu: package xapian-core/1.4.3-2

[Olly Betts]

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"));

Bug#906088: stretch-pu: package xapian-core/1.4.3-2+deb9u2

[Olly Betts]

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

Xapian 1.2 for squeeze?

[Olly Betts]

Xapian 1.2.0 was released this week, and I'd like to try to get it in for
squeeze - it's smaller, faster, has more features, and will be supported by
upstream for more of the life of squeeze.

For Debian, "Xapian" means source packages xapian-core, xapian-bindings,
xapian-omega, and libsearch-xapian-perl.

1.2.0 has come off the back of a development release series, so although it is
a ".0", new bugs are more likely to be "testsuite fails to compile under GNU
Hurd" (actual bug, fixed already) than "will set fire to your cat".  Looking
at the upstream bug database, most of the recent fixes were for bugs also
present in Xapian 1.0.x.

Xapian 1.2 is ABI incompatible with 1.0, but the API is mostly upwardly
compatible.  Removed features have been marked as deprecated for some time
(with warnings when compiling), and the intention has been to try to make
it easy to write code that works with both 1.0 and 1.2 where changes are
needed.

Xapian 1.2 introduces a new default database format, but it can read the
default format 1.0 used, so existing database won't need updating or
rebuilding.

Current status:

I've uploaded packages of xapian-core, xapian-bindings, xapian-omega to
experimental, and those that needed to have now cleared NEW.

I've test built all the reverse build-deps of libxapian-dev.  The only problems
are recoll (requires a patch to stop it including internal Xapian headers -
sent upstream, will file in the BTS shortly) and notmuch (2 tests fail, but
the same issue has been reported trying to build with Xapian 1.0.19 too -
http://article.gmane.org/gmane.mail.notmuch.general/2741 - so I'm guessing
this is a notmuch issue).

I'd like to check (or get others more familiar with them to check) the reverse
(non-build) dependencies too to try to avoid any surprises later, but I've not
really started on this yet.

I'm tracking status here:

http://trac.xapian.org/wiki/DebianXapian1.2.0

For actually making this happen, these packages would need source uploads:

xapian-core
xapian-bindings
xapian-omega
libsearch-xapian-perl
recoll (needs patch)
notmuch (probably)

These would just need a rebuild (assuming they are binnmu-safe, which I didn't
check):

libept
maildir-utils
pinot
adept

Cheers,
Olly


signature.asc
Description: Digital signature

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On 2010-04-30, I wrote:
> Xapian 1.2.0 was released this week, and I'd like to try to get it in for
> squeeze - it's smaller, faster, has more features, and will be supported by
> upstream for more of the life of squeeze.
>
> For Debian, "Xapian" means source packages xapian-core, xapian-bindings,
> xapian-omega, and libsearch-xapian-perl.
>
> 1.2.0 has come off the back of a development release series, so although it is
> a ".0", new bugs are more likely to be "testsuite fails to compile under GNU
> Hurd" (actual bug, fixed already) than "will set fire to your cat".  Looking
> at the upstream bug database, most of the recent fixes were for bugs also
> present in Xapian 1.0.x.
>
> Xapian 1.2 is ABI incompatible with 1.0, but the API is mostly upwardly
> compatible.  Removed features have been marked as deprecated for some time
> (with warnings when compiling), and the intention has been to try to make
> it easy to write code that works with both 1.0 and 1.2 where changes are
> needed.
>
> Xapian 1.2 introduces a new default database format, but it can read the
> default format 1.0 used, so existing database won't need updating or
> rebuilding.
[...]
> I'm tracking status here:
>
> http://trac.xapian.org/wiki/DebianXapian1.2.0

I've now checked all the reverse dependencies.  Three packages need a small
patch, and one (notmuch) FTBFS but also does in unstable.  I'm tracking these
in the BTS with a usertag:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=olly%40debian.org;tag=xapian-1.2
 

> For actually making this happen, these packages would need source uploads:
>
> xapian-core
> xapian-bindings
> xapian-omega
> libsearch-xapian-perl
> recoll (needs patch)
> notmuch (probably)
>
> These would just need a rebuild (assuming they are binnmu-safe, which I didn't
> check):
>
> libept
> maildir-utils
> pinot
> adept

These will also need a rebuild (I missed them before as they lack an explicit
build-dependency on libxapian-dev - it's pulled in for them by libept-dev):

aptitude
goplay
packagesearch

Also, these need a source upload, but the changes are to make Python code
compatible both with python-xapian 1.0.x and 1.2.x, so they can happen before
the main transition:

python-django-djapian
roundup

Cheers,
Olly


signature.asc
Description: Digital signature

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On Mon, May 03, 2010 at 02:48:40AM +1200, Olly Betts wrote:
> On 2010-04-30, I wrote:
> > I'm tracking status here:
> >
> > http://trac.xapian.org/wiki/DebianXapian1.2.0
> 
> I've now checked all the reverse dependencies.  Three packages need a small
> patch, and one (notmuch) FTBFS but also does in unstable.  I'm tracking these
> in the BTS with a usertag:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=olly%40debian.org;tag=xapian-1.2

Thanks to a quick response from all the other maintainers involved, there's
just a pending upload of python-django-djapian left which should be ready
soon.

I'd like the packages of Xapian 1.0.20 to transition to testing first, but
that should happen on Monday, so it seems the other transitions will be the
limiting factor.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100505123101.ga...@eisluft

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On Mon, May 10, 2010 at 11:09:08AM +0100, Adam D. Barratt wrote:
> On Thu, 2010-05-06 at 00:31 +1200, Olly Betts wrote:
> > On Mon, May 03, 2010 at 02:48:40AM +1200, Olly Betts wrote:
> > > On 2010-04-30, I wrote:
> > > > http://trac.xapian.org/wiki/DebianXapian1.2.0
> > > [...]
> > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=olly%40debian.org;tag=xapian-1.2

I've just sponsored an upload of python-django-djapian to fix #579903.

I've also noticed xappy now declares its dependency on python-xapian (it
didn't when I checked the reverse dependencies so I missed it).  I've checked
its code too and it looks fine for Xapian 1.2.

> > I'd like the packages of Xapian 1.0.20 to transition to testing first, but
> > that should happen on Monday, so it seems the other transitions will be the
> > limiting factor.

Xapian 1.0.20 packages are now in testing, so I think the other transitions are
now the only remaining blockers.

> The primary issue I can see is that the Xapian transition overlaps with
> the apt transition.  Both are in turn currently blocked by the fact that
> aptitude FTBFS on s390.

#580085 - looks like it needs someone with aptitude knowledge.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100514122250.gq4...@survex.com

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On 2010-05-14, Olly Betts  wrote:
> On Mon, May 10, 2010 at 11:09:08AM +0100, Adam D. Barratt wrote:
>> The primary issue I can see is that the Xapian transition overlaps with
>> the apt transition.  Both are in turn currently blocked by the fact that
>> aptitude FTBFS on s390.
>
> #580085 - looks like it needs someone with aptitude knowledge.

I did a lot of builds on s390 with different GCC options, and found that
compiling with -fno-gcse fixed the testsuite failure.  Daniel uploaded
aptitude with this change, and it's just transitioned to testing.

Python 2.6 has also recently been forced into testing.

So I think that means that the only overlap for Xapian now is with the
apt transition.

Is there a plan for what order to do things in?  I'm likely to be packaging
a new upstream release (Xapian 1.2.2) in the next few days, so was just
wondering if I should target unstable or experimental.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni2ot60.chp.o...@msgid.survex.com

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On 2010-07-01, Olly Betts  wrote:
> So I think that means that the only overlap for Xapian now is with the
> apt transition.
>
> Is there a plan for what order to do things in?  I'm likely to be packaging
> a new upstream release (Xapian 1.2.2) in the next few days, so was just
> wondering if I should target unstable or experimental.

There was a recent libept SONAME bump, which currently FTBFS on some archs, so
that's a blocker right now:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587764

So I guess it's probably experimental for now.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni2p74m.chp.o...@msgid.survex.com

Re: Xapian 1.2 for squeeze?

[Olly Betts]

On Mon, Aug 23, 2010 at 11:29:50PM +0100, Adam D. Barratt wrote:
> Please go ahead with the upload of xapian 1.2 to unstable.

Uploaded.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100824154403.gu16...@survex.com

Re: Proposed fixes for potential XSS issues in xapian-omega

[Olly Betts]

On Sat, Sep 24, 2011 at 01:26:57PM +0100, Adam D. Barratt wrote:
> On Thu, 2011-09-15 at 01:51 +1200, Olly Betts wrote:
> > I've discussed these with the security team, and they decided it was most
> > appropriate to handle them via a stable update.  I've attached a debdiff
> > showing the changes I'm proposing.
> 
> Apologies for the slight delay in getting back to you.  For future
> reference, a usertagged bug is generally easier for us to keep track of
> and less likely to get lost in the (periodic) noise on the list.

OK, I'll do that in future.

FWIW, the dev ref just says to email the list, so perhaps needs updating
if a usertagged bug is how the release team now prefers this to be done:

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

> > All these changes have been in upstream releases since 1.2.5 (released
> > 2011-04-04) with no reports of any issues.
> 
> Please go ahead; thanks.

I took that as implied permission to make the same changes to oldstable
too, but in the process of applying them I noticed a couple of places
which had been missed.  Neither is going to be easy to exploit, but I
think it is worth patching these too while we're at it.  I've attached a
patch showing just the two extra fixes for clarity.  I've tested these
to make sure they work as intended.

Is it OK to include these too?

And can I get an explicit OK on uploading the same fixes to oldstable?

Cheers,
Olly
Index: templates/query
===
--- templates/query	(revision 16068)
+++ templates/query	(revision 16070)
@@ -60,7 +60,7 @@
 $if{$opt{topterms},
  
- $map{$topterms,$prettyterm{$_} }
+ $map{$topterms,$html{$prettyterm{$_}} }
  
  
 }
Index: templates/godmode
===
--- templates/godmode	(revision 16068)
+++ templates/godmode	(revision 16070)
@@ -31,7 +31,7 @@
 Document Values
 
 $set{values,$list{$map{$range{0,255},$if{$value{$_,$cgi{ID}},
-$_$value{$_,$cgi{ID}}
+$_$html{$value{$_,$cgi{ID}}}
 }},}}
 $if{$opt{values},
 Value#Value

Re: Proposed fixes for potential XSS issues in xapian-omega

[Olly Betts]

On Mon, Sep 26, 2011 at 05:37:59PM +0100, Adam D. Barratt wrote:
> I've just marked the squeeze upload for acceptance at the next dinstall;
> thanks.

Thanks.

> > An upload for oldstable would also be okay.  (Note that the upload
> > window for next weekend's oldstable point release closed last night, so
> > an upload in the meantime will sit in the o-p-u-NEW queue until after
> > the point release).
> 
> This was also uploaded but as mentioned it will be staying in o-p-u-NEW
> until at least next weekend.

Understood - it was just easier to get both versions done now.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110927010137.ge28...@survex.com

xapian-bindings 1.0.10-1 on mips

[Olly Betts]

Hello,

xapian-bindings 1.0.10-1 was uploaded 19 days ago.  It's ready to
migrate apart from a missing mips build.  The buildd logs show it
built successfully on mips on feb 21st, but it seems this build
never got uploaded.

I mailed m...@buildd.d.o on Monday, but no response so far.

So please could you give back the package for rebuilding on mips?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: binNMU ruby1.8 (was Re: Bug#420325: xapian-bindings: FTBFS: declaration of 'int) eaccess(const char*, int) throw ()' throws different exceptions

[Olly Betts]

On 2007-04-21, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 21, 2007 at 07:41:00PM +0200, Adeodato Simó wrote:
>> d-r:
>
>> ruby1.8_1.8.6-1, rebuild against latest libc6-dev to drop eaccess from 
>> missing.h, 1, alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 
>> sparc
>
> Scheduled, with dep-wait set on libc6-dev 2.5 as I assume that's the version
> providing the eaccess prototype.

Short version:  The dep-wait didn't work for mips and mipsel for some
reason, so can you binNMU ruby1.8 on mips and mipsel again?

Long version:

The binNMU doesn't seem to have used the right libc6-dev version on mips
or mipsel.  For mips:

http://buildd.debian.org/fetch.cgi?pkg=ruby1.8;ver=1.8.6-1%2Bb1;arch=mips;stamp=1177496689

Toolchain package versions: libc6-dev_2.3.6.ds1-9 linux-kernel-headers_2.6.18-6 
gcc-4.1_4.1.1-21 g++-4.1_4.1.1-21 binutils_2.17-3 libstdc++6-4.1-dev_4.1.1-21 
libstdc++6_4.1.1-21

And for mipsel:

http://buildd.debian.org/fetch.cgi?pkg=ruby1.8;ver=1.8.6-1%2Bb1;arch=mipsel;stamp=1177755123

Toolchain package versions: libc6-dev_2.3.6.ds1-13 
linux-kernel-headers_2.6.18-7 gcc-4.1_4.1.1-21 g++-4.1_4.1.1-21 binutils_2.17-3 
libstdc++6-4.1-dev_4.1.1-21 libstdc++6_4.1.1-21

So the problem with the ruby1.8-dev headers which caused bug #420325
still exists for mips and mipsel, and has caused xapian-bindings to fail
to build in the same way as in the original bug report:

http://buildd.debian.org/fetch.cgi?pkg=xapian-bindings;ver=1.0.1-1;arch=mips;stamp=1181832758

/usr/include/unistd.h:270: error: declaration of 'int eaccess(const char*, int) 
throw ()' throws different exceptions
/usr/lib/ruby/1.8/mips-linux/missing.h:43: error: from previous declaration 
'int eaccess(const char*, int)'

(and the same error for mipsel).

The build logs for xapian-bindings I link to above show:

Toolchain package versions: libc6-dev_2.5-7 linux-kernel-headers_2.6.18-7 
gcc-4.1_4.1.2-12 g++-4.1_4.1.2-12 binutils_2.17cvs20070426-6 
libstdc++6-4.1-dev_4.1.2-12 libstdc++6_4.2-20070528-1

(and those for mipsel show the same version), so a binNMU now should fix
this problem.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

binNMU for recoll

[Olly Betts]

recoll needs a binNMU to get rebuilt against xapian-core 1.0.1-1
because the shlib version has increased - the shared library package is
now libxapian15 not libxapian13.

According to buildd.d.o, xapian-core 1.0.1-1 is already built and
installed for all architectures:

http://buildd.debian.org/pkg.cgi?maint=olly%40survex.com

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: binNMU for recoll

[Olly Betts]

On 2007-06-15, Olly Betts <[EMAIL PROTECTED]> wrote:
> recoll needs a binNMU to get rebuilt against xapian-core 1.0.1-1
> because the shlib version has increased - the shared library package is
> now libxapian15 not libxapian13.

This binNMU is still required, and is now blocking the migration of
xapian-core 1.0.1-1 and dependent packages to testing.

(The only other thing blocking migration seems to be that the binary
package php4-xapian needs to be dropped).

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xapian 1.0.7

[Olly Betts]

On 2008-07-29, Luk Claes <[EMAIL PROTECTED]> wrote:
> Enrico Zini wrote:
>> I've just uploaded to unstable the Xapian suite version 1.0.7, that was
>> the candidate for lenny.
>> 
>> It didn't manage to get uploaded so far because of last minute
>> polishings and work delayed due to me (sponsor) and the maintainer being
>> in opposite timezones.
>> 
>> It would be a shame if it didn't go in, so I'm bringing it to your
>> attention.
>
> unblocked, set age-days to 15.

xapian-core 1.0.7-1 was hinted, but FTBFS from source on s390 due to a
non-parallel make safe construct in debian/rules (inherited from an
older debhelper example it appears).  This is fixed by 1.0.7-2, which
has now built for all targets.

The only other change in xapian-core 1.0.7-2 was to disable the
testsuite from running on m68k.  One newly-added (upstream) regression
testcase failed on m68k, probably due to FP rounding issues in either
the testcase or the change it's testing.  Either way, the currently
installed 1.0.5-1 is no better in this area and worse in others, so it
seems better overall to let m68k get 1.0.7-2 while I track down the
problem.  AIUI, m68k isn't a release architecture for lenny anyway.

So could you update the unblock hint to xapian-core 1.0.7-2?

I'd also like to ask you to consider adding hints for the rest of the
"Xapian suite" - that's:

xapian-omega 1.0.7-2
xapian-bindings 1.0.7-2
libsearch-xapian-perl 1.0.7.0-1

The first two were uploaded by Enrico together with xapian-core.  The
last is maintained by the Debian Perl Group and the upload had to wait
for xapian-core to be updated.

On the upstream side, the changes between 1.0.5 and 1.0.7 are bug fixes
or documentation improvements, except that xapian-omega 1.0.6 adds
support for indexing DjVu files and three new OmegaScript commands
used by the lists.d.o search.  Any breakage from either of these changes
is likely to be limited to the new functionality they add.

In the Debian packaging, the updates fix all the new lintian warnings
and update to policy 3.8.0.

The following debian bugs would be fixed in lenny by updating:

xapian-core:
#484458: should stem dutch for "nl"

xapian-omega:
#484456: black on dark blue in search results can be hard to read 

xapian-bindings:
#462106: python-xapian: Laxist Depends: on libxapian15 

libsearch-xapian-perl:
#486138: crashes hard when asked to generate a stemmer for an unsupported locale

If we don't update, then the other options are to leave these and a
number of other bugs which aren't in the Debian BTS unfixed, or backport a
lot of fixes to produce something which has had a lot less testing that the
upstream 1.0.7.

I should be available to promptly address any issues which crop up as a
result of updating.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xapian 1.0.7

[Olly Betts]

On Mon, Aug 11, 2008 at 10:38:09PM +0100, Adeodato Simó wrote:
> * Olly Betts [Mon, 04 Aug 2008 05:48:32 +]:
> 
> > I'd also like to ask you to consider adding hints for the rest of the
> > "Xapian suite" - that's:
> 
> > xapian-omega 1.0.7-2
> > xapian-bindings 1.0.7-2
> > libsearch-xapian-perl 1.0.7.0-1
> 
> Luk unblocked libsearch-xapian-perl, I'm unblocking -omega and -bindings.

Great, thanks.

One issue left - Luk's unblock hint for xapian-core is now wrong:

unblock xapian-core/1.0.7-2
age-days 15 xapian-core/1.0.7-2

Since he added it, I uploaded 1.0.7-3 to fix one packaging bug and two
upstream issues:

 xapian-core (1.0.7-3) unstable; urgency=low

   * debian/rules: Run "make all" and "make check" as separate commands to
 avoid hitting parallel building bugs.  Closes: #493390
   * debian/patch: Backport fixes for upstream bug #287 (which can cause
 database corruption), and a bug without a ticket which causes problems
 iterating over tables created lazily after the database has had commits
 which are still in sequential mode.

 -- Olly Betts <[EMAIL PROTECTED]>  Fri, 8 Aug 2008 09:46:20 +0100 

Bug #287 won't affect everyone, but has been run into by at least 2 independent
users and the fix is a single line of code.  The unticketed bug is a one line
change in two places.  I don't know of anyone who has hit it besides myself,
but it can happen after using the documented procedure for upgrading a database
from the old "quartz" backend to the new "flint" backend, so I think it's an
appropriate fix for lenny.

Cheers,
Olly


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

xapian-core bug worth fixing for lenny?

[Olly Betts]

I'd like the release team's opinion on whether the bug described below
is worth fixing for lenny.  I'm happy to, but don't want to expend
effort preparing an upload which would be refused.

In a nutshell, the issue is that excess precision causes aa to
both be true, and the C++ STL nth_element() algorithm segfaults.  The
gory details are documented in a comment in the attached patch.

The patch is very simple - just store intermediate results in volatile
double - and it is only enabled for x86 and m68k.  This piece of code is
also only used by the affected feature.  So I believe the fix to be very
safe.  It also passes the upstream test suite (including a regression
test added for this bug).

The feature affected is the "elite set" query operator, used to pick the
"best N" terms from a larger set.  I've attempted to check the source of
all the packages which use xapian-core directly or via bindings and
haven't found any uses in Debian packages, though users building
unpackaged code or developing their own code could use this feature.
The bug was noticed in real world use.

There's no BTS bug filed for this issue currently, but severity
"important" for one could be argued for (random segfaults do have a
major effect on usability) or against (it only affects those using a
particular feature on certain architectures).

The package's priority is optional, and an upload can be done via
unstable.

So, should I prepare an upload with just this fix?

Cheers,
Olly
Index: matcher/queryoptimiser.cc
===
--- matcher/queryoptimiser.cc	(revision 11483)
+++ matcher/queryoptimiser.cc	(revision 11484)
@@ -1,7 +1,7 @@
 /** @file queryoptimiser.cc
  * @brief Convert a Xapian::Query::Internal tree into an optimal PostList tree.
  */
-/* Copyright (C) 2007 Olly Betts
+/* Copyright (C) 2007,2008 Olly Betts
  * Copyright (C) 2008 Lemur Consulting Ltd
  *
  * This program is free software; you can redistribute it and/or
@@ -245,7 +245,30 @@
 bool operator()(const PostList *a, const PostList *b) {
 	if (a->get_termfreq_max() == 0) return false;
 	if (b->get_termfreq_max() == 0) return true;
+
+#if defined(__i386__) || defined(__mc68000__)
+	// On some architectures, most common of which is x86, floating point
+	// values are calculated and stored in registers with excess precision.
+	// If the two get_maxweight() calls below return identical values in a
+	// register, the excess precision may be dropped for one of them but
+	// not the other (e.g. because the compiler saves the first calculated
+	// weight to memory while calculating the second, then reloads it to
+	// compare).  This leads to both a > b and b > a being true, which
+	// violates the antisymmetry property of the strict weak ordering
+	// required by nth_element().  This can have serious consequences (e.g.
+	// segfaults).
+	//
+	// To avoid this, we store each result in a volatile double prior to
+	// comparing them.  This means that the result of this test should
+	// match that on other architectures with the same double format (which
+	// is desirable), and actually has less overhead than rounding both
+	// results to float (which is another approach which works).
+	volatile double a_max_wt = a->get_maxweight();
+	volatile double b_max_wt = b->get_maxweight();
+	return a_max_wt > b_max_wt;
+#else
 	return a->get_maxweight() > b->get_maxweight();
+#endif
 }
 };
 

Re: xapian-core bug worth fixing for lenny?

[Olly Betts]

Hi Thomas,

On 2008-10-07, Thomas Viehmann <[EMAIL PROTECTED]> wrote:
> Olly Betts wrote:
>> I'd like the release team's opinion on whether the bug described below
>> is worth fixing for lenny.  I'm happy to, but don't want to expend
>> effort preparing an upload which would be refused.
> It's definitely good to have that fixed for lenny.

Well, that's my feeling to, but I was hoping for an OK from the release
team, and you don't seem to be a member (at least not according to
http://wiki.debian.org/Teams/ReleaseManager - is that list out of date?)

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xapian-core bug worth fixing for lenny?

[Olly Betts]

On Thu, Oct 09, 2008 at 07:20:32AM +0200, Luk Claes wrote:
> Please upload.

OK, xapian-core 1.0.7-4 was uploaded and has now spent 13 days in
unstable.  Everything looks good except the hppa build is missing,
though there's a log showing it successfully built there on October
14th:

http://buildd.debian.org/fetch.cgi?&pkg=xapian-core&ver=1.0.7-4&arch=hppa&stamp=1224015800&file=log

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#695649: unblock: xapian-core/1.2.12-2

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xapian-core

This update contains the following changes compared to the version
currently in testing (1.2.12-1):

Fixes grave bug http://bugs.debian.org/695542 ("Concurrent threads can
succeed in locking database").

Fixes bug http://bugs.debian.org/695643 ("Database replication fails for
files > 32GB") which is a small and safe patch relevant to the LFS release
goal: http://wiki.debian.org/ReleaseGoals/LFS

I've attached a debdiff against 1.2.12-1 (currently in testing), and
for your reviewing convenience, the two new patches individually.

Cheers,
Olly

unblock xapian-core/1.2.12-2

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru xapian-core-1.2.12/debian/changelog 
xapian-core-1.2.12/debian/changelog
--- xapian-core-1.2.12/debian/changelog 2012-06-28 19:54:11.0 +1200
+++ xapian-core-1.2.12/debian/changelog 2012-12-11 17:22:23.0 +1300
@@ -1,3 +1,13 @@
+xapian-core (1.2.12-2) unstable; urgency=low
+
+  * New patch fix-db-write-lock.patch which fixes database write locking to
+work when the lock file is already open in the same process.
+(Closes: #695542)
+  * New patch replication-above-32GB.patch which fixes database replication to
+handle files > 32GB.  (Closes: #695643)
+
+ -- Olly Betts   Tue, 11 Dec 2012 04:22:04 +
+
 xapian-core (1.2.12-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru xapian-core-1.2.12/debian/patches/fix-db-write-lock.patch 
xapian-core-1.2.12/debian/patches/fix-db-write-lock.patch
--- xapian-core-1.2.12/debian/patches/fix-db-write-lock.patch   1970-01-01 
12:00:00.0 +1200
+++ xapian-core-1.2.12/debian/patches/fix-db-write-lock.patch   2012-12-11 
17:25:07.0 +1300
@@ -0,0 +1,62 @@
+Taken from 1.2 branch of upstream SVN r16938.
+
+--- a/backends/flint_lock.cc   (revision 16937)
 b/backends/flint_lock.cc   (revision 16938)
+@@ -2,5 +2,5 @@
+  * @brief Flint-compatible database locking.
+  */
+-/* Copyright (C) 2005,2006,2007,2008,2009,2010,2011 Olly Betts
++/* Copyright (C) 2005,2006,2007,2008,2009,2010,2011,2012 Olly Betts
+  *
+  * This program is free software; you can redistribute it and/or
+@@ -134,4 +134,20 @@
+   close(fds[0]);
+ 
++  // Connect pipe to stdin and stdout.
++  dup2(fds[1], 0);
++  dup2(fds[1], 1);
++
++  // Make sure we don't hang on to open files which may get deleted but
++  // not have their disk space released until we exit.  Close these
++  // before we try to get the lock because if one of them is open on
++  // the lock file then closing it after obtaining the lock would release
++  // the lock, which would be really bad.
++  for (int i = 2; i < lockfd; ++i) {
++  // Retry on EINTR; just ignore other errors (we'll get
++  // EBADF if the fd isn't open so that's OK).
++  while (close(i) < 0 && errno == EINTR) { }
++  }
++  closefrom(lockfd + 1);
++
+   reason why = SUCCESS;
+   {
+@@ -160,5 +176,5 @@
+   // Tell the parent if we got the lock, and if not, why not.
+   char ch = static_cast(why);
+-  while (write(fds[1], &ch, 1) < 0) {
++  while (write(1, &ch, 1) < 0) {
+   // EINTR means a signal interrupted us, so retry.
+   // Otherwise we're DOOMED!  The best we can do is just exit
+@@ -169,8 +185,4 @@
+   if (why != SUCCESS) _exit(0);
+   }
+-
+-  // Connect pipe to stdin and stdout.
+-  dup2(fds[1], 0);
+-  dup2(fds[1], 1);
+ 
+   // Make sure we don't block unmount() of partition holding the current
+@@ -184,13 +196,4 @@
+   // gives a warning even if we cast the result to void.
+   }
+-
+-  // Make sure we don't hang on to open files which may get deleted but
+-  // not have their disk space released until we exit.
+-  for (int i = 2; i < lockfd; ++i) {
+-  // Retry on EINTR; just ignore other errors (we'll get
+-  // EBADF if the fd isn't open so that's OK).
+-  while (close(i) < 0 && errno == EINTR) { }
+-  }
+-  closefrom(lockfd + 1);
+ 
+   // FIXME: use special statically linked helper instead of cat.
diff -Nru xapian-core-1.2.12/debian/patches/replication-above-32GB.patch 
xapian-core-1.2.12/debian/patches/replication-above-32GB.patch
--- xapian-core-1.2.12/debian/patches/replication-above-32GB.patch  
1970-01-01 12:00:00.0 +1200
+++ xapian-core-1.2.12/debian/patches/replication-above-32GB.patch  
2012-12-11 17:25:13.

Bug#856515: unblock: xapian-omega/1.4.3-3

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xapian-omega 1.4.3-3.  It's successfully built
on all release architectures (and most non-release ones).

This upload fixes important severity bug #855490 which is an upstream
regression in 1.4.2 which broke term-based date range filtering:

https://bugs.debian.org/855490

There are no other changes over 1.4.3-2, the version in testing.

I've attached a debdiff, which is the fix cherry-picked from upstream
git.  Most of the size is actually test coverage for the change in
the patch, so for easy review I've also attached a version of the
debdiff with that added test coverage removed.

unblock xapian-omega/1.4.3-3

Cheers,
Olly
diff -Nru xapian-omega-1.4.3/debian/changelog 
xapian-omega-1.4.3/debian/changelog
--- xapian-omega-1.4.3/debian/changelog 2017-01-25 17:37:27.0 +1300
+++ xapian-omega-1.4.3/debian/changelog 2017-03-01 14:23:38.0 +1300
@@ -1,3 +1,10 @@
+xapian-omega (1.4.3-3) unstable; urgency=medium
+
+  * Fix term-based range filtering, broken in 1.4.2 - new patch
+fix-term-based-date-ranges.patch (Closes: #855490)
+
+ -- Olly Betts   Wed, 01 Mar 2017 14:23:38 +1300
+
 xapian-omega (1.4.3-2) unstable; urgency=medium
 
   * debian/control: Regenerate from debian/control.in to pick up missing
diff -Nru xapian-omega-1.4.3/debian/patches/fix-term-based-date-ranges.patch 
xapian-omega-1.4.3/debian/patches/fix-term-based-date-ranges.patch
--- xapian-omega-1.4.3/debian/patches/fix-term-based-date-ranges.patch  
1970-01-01 12:00:00.0 +1200
+++ xapian-omega-1.4.3/debian/patches/fix-term-based-date-ranges.patch  
2017-03-01 14:23:38.0 +1300
@@ -0,0 +1,131 @@
+commit dbc785d336daf7a33a7d86af16e28b16c47ca66e
+Author: Olly Betts 
+Date:   Tue Feb 14 15:45:17 2017 +1300
+
+Fix term-based date ranges
+
+Broken by changes in 1.4.2.  Found and diagnosed by Gaurav Arora.
+
+diff --git a/date.cc b/date.cc
+index b142e8fce45c..2f9b34717799 100644
+--- a/date.cc
 b/date.cc
+@@ -53,7 +53,7 @@ static void
+ format_int_fixed_width(char * p, int v, int w)
+ {
+ while (--w >= 0) {
+-  p[w] = v % 10;
++  p[w] = '0' + (v % 10);
+   v /= 10;
+ }
+ }
+@@ -63,7 +63,7 @@ date_range_filter(int y1, int m1, int d1, int y2, int m2, 
int d2)
+ {
+ char buf[10];
+ format_int_fixed_width(buf + 1, y1, 4);
+-format_int_fixed_width(buf + 1, m1, 2);
++format_int_fixed_width(buf + 5, m1, 2);
+ vector v;
+ 
+ int d_last = last_day(y1, m1);
+@@ -80,7 +80,7 @@ date_range_filter(int y1, int m1, int d1, int y2, int m2, 
int d2)
+   }
+ } else {
+   buf[0] = 'M';
+-  v.push_back(Xapian::Query(string(buf, 9)));
++  v.push_back(Xapian::Query(string(buf, 7)));
+ }
+ 
+ if (y1 == y2 && m1 == m2) {
+diff --git a/omegatest b/omegatest
+index 8bbd83942b0b..509b5beeb5e3 100755
+--- a/omegatest
 b/omegatest
+@@ -156,6 +156,63 @@ qtestcase 'VALUE_RANGE 0 20141104 20151103~' DATEVALUE=0 
END=20151103 SPAN=365
+ # Check that if START, END and SPAN are all passed, START is ignored:
+ qtestcase 'VALUE_RANGE 0 20151104 20151106~' DATEVALUE=0 START=19700101 
END=20151106 SPAN=3
+ 
++# Tests of term-based date range filtering:
++
++qtestcase '((M197001 OR M197002 OR M197003 OR M197004 OR M197005 OR M197006 
OR M197007 OR M197008 OR M197009 OR M197010 OR M197011 OR M197012 OR Y1971 OR 
Y1972 OR Y1973 OR Y1974 OR Y1975 OR Y1976 OR Y1977 OR Y1978 OR Y1979 OR Y1980 
OR Y1981 OR Y1982 OR Y1983 OR Y1984 OR Y1985 OR Y1986 OR Y1987 OR Y1988 OR 
Y1989 OR Y1990 OR Y1991 OR Y1992 OR Y1993 OR Y1994 OR Y1995 OR Y1996 OR Y1997 
OR Y1998 OR M199901 OR M199902 OR M199903 OR M199904 OR M199905 OR M199906 OR 
M199907 OR M199908 OR M199909 OR M199910 OR M199911 OR M199912) OR Dlatest)' 
END=19991231
++qtestcase '((M197001 OR M197002 OR M197003 OR M197004 OR M197005 OR M197006 
OR M197007 OR M197008 OR M197009 OR M197010 OR M197011 OR M197012 OR Y1971 OR 
Y1972 OR Y1973 OR Y1974 OR Y1975 OR Y1976 OR Y1977 OR Y1978 OR Y1979 OR Y1980 
OR Y1981 OR Y1982 OR Y1983 OR Y1984 OR Y1985 OR Y1986 OR Y1987 OR Y1988 OR 
M198901 OR M198902 OR M198903 OR M198904 OR M198905 OR M198906 OR M198907 OR 
M198908 OR M198909 OR M198910 OR M198911 OR M198912) OR Dlatest)' END=19891231
++qtestcase '((M197001 OR M197002 OR M197003 OR M197004 OR M197005 OR M197006 
OR M197007 OR M197008 OR M197009 OR M197010 OR M197011 OR M197012 OR Y1971 OR 
Y1972 OR Y1973 OR M197401 OR M197402 OR M197403 OR M197404 OR M197405 OR 
M197406 OR M197407 OR M197408 OR M197409 OR M197410 OR M197411 OR M197412) OR 
Dlatest)' END=19741231
++qtestcase '((M197001 OR M197002 OR M197003 OR M197004 OR M197005 OR M197006 
OR M197007 OR M197008 OR M197009 OR M197010 OR M197011 OR M197012 OR Y1971 OR 
Y1972 OR Y1973 OR Y1974 OR Y1975 OR Y1976 OR Y1977 OR Y1978 OR Y1979 OR Y1980 

Bug#856522: unblock: wxwidgets3.0/3.0.2+dfsg-3

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package wxwidgets3.0

The package was recently binNMUed, apparently to enabled PIE (which gcc
now defaults to).  However gcc now also defaults to C++11, which results
in wx's headers in the binNMU not being usable for applications
compiling as C++98.  This broke qutemol (which forces building as C++98
to work around C++11 incompatibilities) and may well break other rdeps -
without a mass rebuild to check we can't know.

The debian bug (severity serious) is:

https://bugs.debian.org/856350

Adrian Bunk proposed explicitly forcing C++98 mode when building
wxwidgets3.0, which seems a prudent choice for stretch - it essentially
returns us to the pre-binNMU situation.

Here is the complete debdiff against the version in testing:

diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/changelog 
wxwidgets3.0-3.0.2+dfsg/debian/changelog
--- wxwidgets3.0-3.0.2+dfsg/debian/changelog2016-07-29 11:58:02.0 
+1200
+++ wxwidgets3.0-3.0.2+dfsg/debian/changelog2017-03-01 14:15:40.0 
+1300
@@ -1,3 +1,11 @@
+wxwidgets3.0 (3.0.2+dfsg-3) unstable; urgency=medium
+
+  * Force building as C++98 for now to fix FTBFS of qutemol and perhaps
+other rdeps since recent binNMU with a GCC version which defaults
+to C++11.  Patch from Adrian Bunk.  (Closes: #856350)
+
+ -- Olly Betts   Wed, 01 Mar 2017 14:15:40 +1300
+
 wxwidgets3.0 (3.0.2+dfsg-2) unstable; urgency=medium
 
   * ACK NMUs.
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/rules 
wxwidgets3.0-3.0.2+dfsg/debian/rules
--- wxwidgets3.0-3.0.2+dfsg/debian/rules2016-07-29 11:42:43.0 
+1200
+++ wxwidgets3.0-3.0.2+dfsg/debian/rules2017-03-01 14:14:51.0 
+1300
@@ -69,7 +69,7 @@
 --with-flavour=$(DEBIAN_WXFLAVOUR) \
 --with-zlib=sys \
 --with-expat=sys \
-$(shell DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed dpkg-buildflags 
--export=configure)
+$(shell DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed 
DEB_CXXFLAGS_MAINT_APPEND=-std=gnu++98 dpkg-buildflags --export=configure)
 
 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
 COMMON_CONFIGURE_OPTIONS += --disable-optimise


unblock wxwidgets3.0/3.0.2+dfsg-3

Cheers,
Olly

Bug#755757: cecilia: Patch for wxPython 3.0

[Olly Betts]

Control: tags 755757 + patch

Dear maintainer,

With the attached patch, the wx-related errors I originally got are gone,
as is another sizer-related error I got after fixing those.

Let me know if you're like me to NMU these changes.

Cheers,
Olly
diff -Nru cecilia-5.0.9/debian/changelog cecilia-5.0.9/debian/changelog
--- cecilia-5.0.9/debian/changelog	2013-11-29 14:35:03.0 +1300
+++ cecilia-5.0.9/debian/changelog	2014-09-20 14:46:01.0 +1200
@@ -1,3 +1,11 @@
+cecilia (5.0.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update for wxPython 3.0 (Closes: #755757):
++ New patch: wxpython3.0.patch
+
+ -- Olly Betts   Sat, 20 Sep 2014 02:45:20 +
+
 cecilia (5.0.9-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru cecilia-5.0.9/debian/patches/series cecilia-5.0.9/debian/patches/series
--- cecilia-5.0.9/debian/patches/series	2013-11-29 14:35:03.0 +1300
+++ cecilia-5.0.9/debian/patches/series	2014-09-20 14:20:46.0 +1200
@@ -1 +1,2 @@
 use-distutils.diff
+wxpython3.0.patch
diff -Nru cecilia-5.0.9/debian/patches/wxpython3.0.patch cecilia-5.0.9/debian/patches/wxpython3.0.patch
--- cecilia-5.0.9/debian/patches/wxpython3.0.patch	1970-01-01 12:00:00.0 +1200
+++ cecilia-5.0.9/debian/patches/wxpython3.0.patch	2014-09-20 14:51:03.0 +1200
@@ -0,0 +1,124 @@
+Description: Update for wxPython 3.0
+ These changes should remain compatible with wxPython 2.8.
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/755757
+Forwarded: no
+Last-Update: 2014-09-20
+
+Index: cecilia-5.0.9/Resources/CeciliaLib.py
+===
+--- cecilia-5.0.9.orig/Resources/CeciliaLib.py
 cecilia-5.0.9/Resources/CeciliaLib.py
+@@ -170,7 +170,7 @@ def saveFileDialog(parent, wildcard, typ
+ defaultFile = os.path.split(getVar("currentCeciliaFile", unicode=True))[1].split(".")[0]
+ saveAsDialog = wx.FileDialog(parent, message="%s file as ..." % type,
+  defaultDir=defaultPath, defaultFile=defaultFile+ext,
+- wildcard=wildcard, style=wx.SAVE | wx.FD_OVERWRITE_PROMPT)
++ wildcard=wildcard, style=wx.FD_SAVE | wx.FD_OVERWRITE_PROMPT)
+ if saveAsDialog.ShowModal() == wx.ID_OK:
+ filePath = ensureNFD(saveAsDialog.GetPath())
+ if type == 'Save audio':
+@@ -224,7 +224,7 @@ def loadPlayerEditor(app_type):
+ path = ''
+ dlg = wx.FileDialog(None, message="Choose a %s..." % app_type,
+  defaultDir=os.path.expanduser('~'),
+- wildcard=wildcard, style=wx.OPEN)
++ wildcard=wildcard, style=wx.FD_OPEN)
+ 
+ if dlg.ShowModal() == wx.ID_OK:
+ path = dlg.GetPath()   
+@@ -540,7 +540,7 @@ def openCeciliaFile(parent, openfile=Non
+ wildcard = "Cecilia file (*.%s)|*.%s" % (FILE_EXTENSION, FILE_EXTENSION)
+ defaultPath = getVar("openFilePath", unicode=True)
+ openDialog = wx.FileDialog(parent, message='Choose a Cecilia file to open...', 
+-defaultDir=defaultPath, wildcard=wildcard, style=wx.OPEN)
++defaultDir=defaultPath, wildcard=wildcard, style=wx.FD_OPEN)
+ if openDialog.ShowModal() == wx.ID_OK:
+ cecFilePath = openDialog.GetPath()
+ setVar("openFilePath", (os.path.split(cecFilePath)[0]))
+Index: cecilia-5.0.9/Resources/CeciliaPlot.py
+===
+--- cecilia-5.0.9.orig/Resources/CeciliaPlot.py
 cecilia-5.0.9/Resources/CeciliaPlot.py
+@@ -702,7 +702,7 @@ class PlotCanvas(wx.Panel):
+ self, 
+ "Choose a file with extension bmp, gif, xbm, xpm, png, or jpg", ".", "",
+ "BMP files (*.bmp)|*.bmp|XBM files (*.xbm)|*.xbm|XPM file (*.xpm)|*.xpm|PNG files (*.png)|*.png|JPG files (*.jpg)|*.jpg",
+-wx.SAVE|wx.OVERWRITE_PROMPT
++wx.FD_SAVE|wx.FD_OVERWRITE_PROMPT
+ )
+ try:
+ while 1:
+Index: cecilia-5.0.9/Resources/DocFrame.py
+===
+--- cecilia-5.0.9.orig/Resources/DocFrame.py
 cecilia-5.0.9/Resources/DocFrame.py
+@@ -534,7 +534,7 @@ class ManualFrame(wx.Frame):
+ self.doc_panel.collapseAll()
+ 
+ if __name__ == "__main__":
+-app = wx.PySimpleApp()
++app = wx.App(False)
+ doc_frame = ManualFrame()
+ doc_frame.Show()
+ app.MainLoop()
+Index: cecilia-5.0.9/Resources/Grapher.py
+===
+--- cecilia-5.0.9.orig/Resources/Grapher.py
 cecilia-5.0.9/Resources/

Bug#755757: cecilia: Patch for wxPython 3.0

[Olly Betts]

On Sun, Sep 21, 2014 at 11:43:19AM +0200, Emilio Pozuelo Monfort wrote:
> On 20/09/14 05:21, Olly Betts wrote:
> > Control: tags 755757 + patch
> > 
> > Dear maintainer,
> > 
> > With the attached patch, the wx-related errors I originally got are gone,
> > as is another sizer-related error I got after fixing those.
> > 
> > Let me know if you're like me to NMU these changes.
> 
> Did you send this to the wrong bug?

Sorry, yes - I realised almost right away and resent it though.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140921095055.gl19...@survex.com

Bug#755757: closed by Olly Betts (Bug#755757: fixed in cecilia 5.0.9-1.1)

[Olly Betts]

Control: reopen -1

>  cecilia (5.0.9-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Update for wxPython 3.0 (Closes: #755757):
>  + New patch: wxpython3.0.patch

Aargh - I put the wrong bug number in the changelog entry, reopening...

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007121409.GA18294@debian

Bug#755757: transition: wxpython3.0

[Olly Betts]

On Wed, Jul 23, 2014 at 09:05:54AM +0200, Emilio Pozuelo Monfort wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/wxpython3.0.html
> Control: tags -1 confirmed

So the ben file I originally sent has a couple of annoying issues:

One is that packages which recommend or suggest aren't listed at all,
and neither are those which only build-depend on wxpython (e.g. ipython
did, but apparently unnecessarily as the maintainer has dropped that
dependency now).

The other is that packages which have been updated but switched to a
dependency on python-wxgtk3.0|python-wxgtk2.8 are still listed as "bad".

The result of these is that the tracker no longer presents useful
information - most of the listed packages are actually fixed already,
but several packages needing attention aren't listed.

After discussion on #debian-release, I propose the following updated
version (mehdi says that bad is checked before good, so "is_good = true"
means "if it isn't bad, it's good"):

title = "wxpython3.0";
is_affected = (.build-depends ~ "python-wxgtk2.8") | (.depends ~ 
"python-wxgtk2.8") | (.recommends ~ "python-wxgtk2.8") | (.suggests ~ 
"python-wxgtk2.8") | (.build-depends ~ "python-wxgtk3.0") | (.depends ~ 
"python-wxgtk3.0") | (.recommends ~ "python-wxgtk3.0") | (.suggests ~ 
"python-wxgtk3.0");
is_bad = (.build-depends ~ "python-wxgtk2.8" & !(.build-depends ~ 
"python-wxgtk3.0")) | (.depends ~ "python-wxgtk2.8" & !(.depends ~ 
"python-wxgtk3.0")) | (.recommends ~ "python-wxgtk2.8" & !(.recommends ~ 
"python-wxgtk3.0")) | (.suggests ~ "python-wxgtk2.8" & !(.suggests ~ 
"python-wxgtk3.0"));
is_good = true;

If that looks sane to you, please can you update the tracker?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007214328.GA5687@gemse

Bug#755757: transition: wxpython3.0

[Olly Betts]

On Fri, Oct 10, 2014 at 09:52:27AM +0200, Emilio Pozuelo Monfort wrote:
> On 07/10/14 23:43, Olly Betts wrote:
> >The result of these is that the tracker no longer presents useful
> >information - most of the listed packages are actually fixed already,
> >but several packages needing attention aren't listed.
> 
> AFAICS out of the 7 packages that are still marked as bad, there is
> only one false positive: gnumed-client.

I think gnuradio was also being shown erroneously (it has an alternative
with 3.0 first).  I also thought quisk was when I sent the updated ben
file, but I since looked closely and spotted that the BD had been
updated, but the run-time dependency was still on python-wxgtk2.8 - I
filed a bug and the maintainer promptly fixed that.

The list now matches the bugs filed but still open, aside from
wxwidgets2.8 (bogus but understandably picked up by the tracker) and
pyhoca-gui which the tracker misses because it oddly depends on
python-wxtools and wx-common, but not python-wxgtk* - I think that's
wrong as it does "import wx", and will suggest the dependencies should
include python-wxgtk3.0 in the pending upload.

So actually things are looking a little better than I thought, which is
nice.

> I have updated the tracker with your proposed new one and it shows the
> same packages except for gnumed-client, which is now marked as good
> (note however that it has wx2.8 as the first alternative so you may
> want to file a bug about that).

Oh yes, I'll file one.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141010090402.gi25...@survex.com

Bug#767980: nmu: wxmaxima_13.04.2-4 xmlcopyeditor_1.2.0.12-1.1

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 766790 by -1

nmu wxmaxima_13.04.2-4 xmlcopyeditor_1.2.0.12-1.1 . amd64 armel armhf hurd-i386 
i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc . -m "Rebuild 
for wxLANGUAGE_* ABI break in wxwidgets3.0 (#766790)"


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102225322.ga5...@survex.com

Bug#688183: unblock: wxwidgets2.8/2.8.12.1-12

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package wxwidgets2.8.

This adds a conflict to resolve an upgrade ordering issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684150

Ubuntu have had essentially the same patch (but with an Ubuntu specific
version) for some time already.

The full debdiff against the version currently in testing is:

diff -Nru wxwidgets2.8-2.8.12.1/debian/changelog 
wxwidgets2.8-2.8.12.1/debian/changelog
--- wxwidgets2.8-2.8.12.1/debian/changelog  2012-06-01 17:08:49.0 
+1200
+++ wxwidgets2.8-2.8.12.1/debian/changelog  2012-09-19 12:38:25.0 
+1200
@@ -1,3 +1,11 @@
+wxwidgets2.8 (2.8.12.1-12) unstable; urgency=low
+
+  * Make python-wxversion conflict with python-wxgtk2.8 (<< 2.8.12.1-1~) to
+guarantee upgrade ordering when moving from pycentral to dh_python2.
+(Closes: #684150)
+
+ -- Olly Betts   Wed, 19 Sep 2012 00:37:03 +
+
 wxwidgets2.8 (2.8.12.1-11) unstable; urgency=low
 
   * It looks like upstream may not make another 2.8 release, and if they do
diff -Nru wxwidgets2.8-2.8.12.1/debian/control 
wxwidgets2.8-2.8.12.1/debian/control
--- wxwidgets2.8-2.8.12.1/debian/control2012-05-31 13:51:00.0 
+1200
+++ wxwidgets2.8-2.8.12.1/debian/control2012-09-19 12:38:40.0 
+1200
@@ -157,7 +157,7 @@
 Architecture: all
 Section: python
 Depends: ${python:Depends}, ${misc:Depends}
-Conflicts: wxpython2.6-0, python-wxgtk2.6 (<< 2.6.3.2.2-2), python-wxgtk2.4 
(<< 2.4.5.1.2)
+Conflicts: wxpython2.6-0, python-wxgtk2.6 (<< 2.6.3.2.2-2), python-wxgtk2.4 
(<< 2.4.5.1.2), python-wxgtk2.8 (<< 2.8.12.1-1~)
 Replaces: wxpython2.6-0
 Description: wxWidgets Cross-platform C++ GUI toolkit (wxPython version 
selector)
  wxWidgets (formerly known as wxWindows) is a class library for C++ providing
diff -Nru wxwidgets2.8-2.8.12.1/debian/control.in 
wxwidgets2.8-2.8.12.1/debian/control.in
--- wxwidgets2.8-2.8.12.1/debian/control.in 2012-05-30 11:18:24.0 
+1200
+++ wxwidgets2.8-2.8.12.1/debian/control.in 2012-09-19 12:36:47.0 
+1200
@@ -157,7 +157,7 @@
 Architecture: all
 Section: python
 Depends: ${python:Depends}, ${misc:Depends}
-Conflicts: wxpython2.6-0, python-wxgtk2.6 (<< 2.6.3.2.2-2), python-wxgtk2.4 
(<< 2.4.5.1.2)
+Conflicts: wxpython2.6-0, python-wxgtk2.6 (<< 2.6.3.2.2-2), python-wxgtk2.4 
(<< 2.4.5.1.2), python-wxgtk2.8 (<< 2.8.12.1-1~)
 Replaces: wxpython2.6-0
 Description: wxWidgets Cross-platform C++ GUI toolkit (wxPython version 
selector)
  wxWidgets (formerly known as wxWindows) is a class library for C++ providing

unblock wxwidgets2.8/2.8.12.1-11

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


signature.asc
Description: Digital signature

xapian packages may need hinting

[Olly Betts]

It looks like the migration to testing of the latest xapian packages is
now only blocked by recursive dependencies:

http://bjorn.haxx.se/debian/testing.pl?package=xapian-core;expand=1

If this needs manual intervention to resolve, the source packages
involved are:

xapian-core
xapian-omega
xapian-bindings

The packages in unstable are a definite improvement over the versions in
testing.

There's also a newer upstream version I'm nearly ready to upload
packages for, but it would be good to get the packages currently in
unstable migrated to testing first in case the next upload doesn't make
it into etch.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

urgent hint for xapian-bindings

[Olly Betts]

I notice that vorlon has added an urgent hint for xapian-bindings to
help new versions of php4 and/or php5 move to testing.

However, due to versioned dependencies, this hint won't help unless
xapian-core and xapian-omega are also hinted as urgent too (they were
uploaded at the same time and have spent 3 out of 10 days in unstable
so far).  There shouldn't be any further packages which would also need
hinting because of dependencies beyond these.

As maintainer, I'm happy for all three to be hinted as urgent if you
believe that's the best option.  There haven't been any debian or
upstream reports of regressions in the latest versions.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: urgent hint for xapian-bindings

[Olly Betts]

On 2006-11-27, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Are there perhaps *missing* dependencies that should be here?

D'oh!  My (currently somewhat fuzzy) head noticed the hint had been
there for a couple of days and reached the wrong conclusion as to why
(the comment in the hints file itself notes that this is waiting for
php-sqlite3).

There are versioned dependencies between the *source* packages, but the
only versioned dependency between the *binary* packages is due to the
libxapian soname, which hasn't changed between the versions in testing
and unstable.

So there's nothing to worry about here - sorry for the noise.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Survex debian package uninstallable on hppa

[Olly Betts]

On Tue, Dec 19, 2006 at 09:39:26PM +0100, Marc 'HE' Brockschmidt wrote:
> Wookey <[EMAIL PROTECTED]> writes:
> > Here is mail from upstream about minor patch to fix uninstallability
> > of survex-aven on hppa. I assume this is OK to upload via unstable,
> > and with urgency high? I have the package built and await an OK for
> > upload. 
> 
> Please upload.

The previous version of the package had debian version 1.0.39 (a debian
native version number, which isn't appropriate for this package but we
can't fix what previous versions were).

The hppa binNMU was 1.0.39+b1.

Wookey uploaded 1.0.39-1, which has built for all architectures
including hppa, but the hppa upload was rejected because 1.0.39-1 is a
*lower* version than 1.0.39+b1 by the ordering dpkg uses - this outputs
`yes':

dpkg --compare-versions 1.0.39b1 '>>' 1.0.39-1 && echo yes

The options I can see are:

* Force 1.0.39-1 in for hppa somehow.  I doubt there are any hppa users
  of survex who have installed the version currently in unstable (since
  nobody complained that survex-aven was uninstallable for over 3
  months; also it's a fairly specialised application).  Even so this
  seems a bit brute force.

* Reupload the package as something like: 1.0.39debian-1

* Reupload the package with an epoch: 1:1.0.39-1

* Reupload the package as something like 1.0.39.1-1 (or 1.0.39.1 and fix
  the package to be non-native later when we aren't trying to release
  etch).  I am the upstream for survex, so I can ensure there's never an
  upstream release called 1.0.39.1.

Is there a preferred solution?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Survex debian package uninstallable on hppa

[Olly Betts]

On Tue, Dec 26, 2006 at 12:28:47PM +0100, Luk Claes wrote:
> Olly Betts wrote:
> > The hppa binNMU was 1.0.39+b1.
> > 
> > Wookey uploaded 1.0.39-1, which has built for all architectures
> > including hppa, but the hppa upload was rejected because 1.0.39-1 is a
> > *lower* version than 1.0.39+b1 by the ordering dpkg uses - this outputs
> > `yes':
> > 
> > dpkg --compare-versions 1.0.39b1 '>>' 1.0.39-1 && echo yes
> 
> 1.0.39+b1 ofcourse...

Of course - not sure where I lost the "+".  Anyway, the comparison gives
the same result for "1.0.39+b1".

> > * Reupload the package as something like: 1.0.39debian-1
> 
> Nothing debian specific, so not preferred.

I guess you must mean "nothing debian specific in the upstream release",
so putting "debian" in the upstream version doesn't make sense?

If not you've lost me, as the changes here are entirely debian-specific
(a fix for a problem caused by the debian packaging not being
binNMU-safe combined with the package previously being debian native).
None of the upstream code has been modified (all the changes over 1.0.39
are in the debian subdirectory and there's no debian/patch).

> > * Reupload the package as something like 1.0.39.1-1 (or 1.0.39.1 and fix
> >   the package to be non-native later when we aren't trying to release
> >   etch).  I am the upstream for survex, so I can ensure there's never an
> >   upstream release called 1.0.39.1.
> 
> What about 1.0.39+upstream-1 or something similar?

Well, there's nothing upstream specific here either!  But it does the
job so I'm happy to go with it, assuming Wookey (cc:-ed) is.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#712622: pu: package wv2/0.4.2.dfsg.1-9.1

[Olly Betts]

Package: release.debian.org
Severity: serious
User: release.debian@packages.debian.org
Usertags: pu

README.Debian says that src/generator/generator_wword{6,8}.htm have been
removed from the repacked wv2_0.4.2.dfsg.1.orig.tar.bz2, but they are
still present.

These two files are based on documents copyright Microsoft.  I can't see
a clear licence statement, but it seems unlikely their licence would fit
the DFSG or that talking to Microsoft would get them released under such
a licence.

README.Debian shows the intent was clearly that these files be removed.

I have uploaded 0.4.2.dfsg.2-1 to unstable and it has migrated to testing
but this issue still affects wheezy (and squeeze - I'll open a separate
bug for that proposed update in a moment).

The bug against wv2 for this issue is:

http://bugs.debian.org/710470

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130617232318.21426.31901.reportbug@debian

Bug#712623: opu: package wv2/0.4.2.dfsg.1-1

[Olly Betts]

Package: release.debian.org
Severity: serious
User: release.debian@packages.debian.org
Usertags: opu

README.Debian says that src/generator/generator_wword{6,8}.htm have been
removed from the repacked wv2_0.4.2.dfsg.1.orig.tar.bz2, but they are
still present.

These two files are based on documents copyright Microsoft.  I can't see
a clear licence statement, but it seems unlikely their licence would fit
the DFSG or that talking to Microsoft would get them released under such
a licence.

README.Debian shows the intent was clearly that these files be removed.

I have uploaded 0.4.2.dfsg.2-1 to unstable and it has migrated to testing
but this issue still affects squeeze.

The bug against wv2 for this issue is:

http://bugs.debian.org/710470

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130617233231.21502.31681.reportbug@debian

Bug#712622: pu: package wv2/0.4.2.dfsg.1-9.1

[Olly Betts]

On Tue, Jun 18, 2013 at 07:26:39PM +0100, Adam D. Barratt wrote:
> What version were you proposing to use for the re-repack?

I'm open to guidance as to what's best.

The repacked upstream tarball would be the same as testing/unstable has,
so perhaps 0.4.2.dfsg.2-1~deb7+1 (and 0.4.2.dfsg.2-1~deb6+1 for opu)?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130620013656.gs20...@survex.com

Bug#712623: opu: package wv2/0.4.2.dfsg.1-1

[Olly Betts]

On Tue, Jun 18, 2013 at 07:29:45PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo squeeze
> Control: severity -1 normal
> 
> On Tue, 2013-06-18 at 11:32 +1200, Olly Betts wrote:
> > Package: release.debian.org
> > Severity: serious
> 
> As with #712622, no, it's not.
> 
> > README.Debian says that src/generator/generator_wword{6,8}.htm have been
> > removed from the repacked wv2_0.4.2.dfsg.1.orig.tar.bz2, but they are
> > still present.
> 
> And the same question as for the wheezy bug - what's the suggested
> version for the new package?

I uploaded a package for opu and received a confirmation email:

> From: Debian FTP Masters 
> To: Debian Qt/KDE Maintainers , Olly Betts 
> 
> Subject: wv2_0.4.2.dfsg.2-1~deb6u1_amd64.changes ACCEPTED into
> oldstable-proposed-updates->oldstable-new
>
> Mapping squeeze to oldstable.
> Mapping oldstable to oldstable-proposed-updates.
>
> Accepted:
[...]

Which looks good to me.

But my QA page is showing it as a "new" upload for the unstable version of wv2:

http://qa.debian.org/developer.php?login=olly

So I'm concerned I've messed up the upload somehow.  Or is this a bug in the QA 
page?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715031940.gb12...@survex.com

Bug#704032: transition: boost-defaults 1.54

[Olly Betts]

Sorry, I'm an idiot and uploaded a new version of sffview, despite being
aware of this transition.  If the upload causes any problems for the
transition, please just boot sffview out of testing - it's a leaf
package.

It does seem to build fine with boost 1.54 at least.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131114155824.ga12...@survex.com

Bug#748169: transition: wxwidgets3.0

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

It would be good if we could eliminate wxwidgets2.8 from the archive for
jessie - the last upstream release (2.8.12) was over 3 years ago, and
there's very little upstream interest in bugs in it now.

We've had co-installable packages of wxwidgets3.0 for 6 months and they
seem to work well.  I've been working on doing test builds and filing
bugs with any patches required, tracking progress on the wiki:

https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0

But manually tracking packages is somewhat error prone, and in
particular misses people adding new dependencies on wx2.8, so I'd like
to make use of the transition tracker to automatically track which
packages still need attention.

This transition probably doesn't need allocating a "slot" to happen at
this point, since packages can mostly be updated to use wxwidgets3.0
independently of one another.

There's a (possibly incomplete) list of affected packages on the wiki
page above.  Also, everything using wxpython will need an update before
we can actually remove wxwidgets2.8, but I've been focusing on the C++
packages so far, and haven't yet uploaded packages of wxpython3 (my
current plan is to do that after the next upstream point release).

Ben file:

title = "wxwidgets3.0";
is_affected = .build-depends ~ 
/libwx(base|gtk(-media)?)3\.0-dev|wx3\.0-(headers|i18n)/ | .build-depends ~ 
/libwx(base|gtk(-media)?)2\.8-dev|wx2\.8-(headers|i18n)/;
is_good = .build-depends ~ 
/libwx(base|gtk(-media)?)3\.0-dev|wx3\.0-(headers|i18n)/;
is_bad = .build-depends ~ 
/libwx(base|gtk(-media)?)2\.8-dev|wx2\.8-(headers|i18n)/;

Cheers,
Olly


signature.asc
Description: Digital signature

Bug#750619: transition: wxsqlite3

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block 748169 by -1
Control: block -1 by 749974 749976 749978

I'm filing this on behalf of gcs (the wxsqlite3 maintainer) who's in
X-Debbugs-Cc.

As part of the wxwidgets3.0 transition, wxsqlite3 needs to switch to
using wxwidgets3.0, which requires a secondary transition for
wxsqlite3's 3 reverse dependencies:

codelite (orphaned, but being adopted; updated package ready in experimental)
guayadeque (needs updating for wx3.0; no response from maintainer yet)
maitreya (maintainer and upstream are working on updating for wx3.0)

I've already filed bugs against all three.

This transition will require sourceful uploads, as the wxsqlite3 -dev
package is changing name from libwxsqlite3-2.8-dev to
libwxsqlite3-3.0-dev.

An updated wxsqlite3 package is already in experimental.

Ben file:

title = "wxsqlite3";
is_affected = .depends ~ "libwxsqlite3-2.8-0" | .depends ~ "libwxsqlite3-3.0-0";
is_good = .depends ~ "libwxsqlite3-3.0-0";
is_bad = .depends ~ "libwxsqlite3-2.8-0";

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140605024220.GA15524@gemse

Bug#750619: transition: wxsqlite3

[Olly Betts]

On Fri, Jun 06, 2014 at 10:22:49AM +0200, Emilio Pozuelo Monfort wrote:
> On 06/06/14 08:49, László Böszörményi (GCS) wrote:
> > It's up to the guayadeque and maitreya packages
> > to make the update for wxSqlite 3.0 now.
> 
> Are there bugs for those? Please make them block this one.

They already do - I set the blocks up when I filed this bug:

| Control: block -1 by 749974 749976 749978

> Also you're welcome to provide patches to make the transition start
> faster.

I've provided a partial patch for maitreya already.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140606094548.gt10...@survex.com

Bug#755757: transition: wxpython3.0

[Olly Betts]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 734799

This is a follow-on from the wxwidgets3.0 transition.  The wxwidgets2.8
source package actually contains the wxpython source, which has an
embedded copy of wxwidgets.  This has become unworkable as the wxpython
releases now lag the corresponding wxwidgets releases by many months,
so for 3.0 we're splitting the source packages.

The intention is to eliminate wxwidgets2.8 (and hence wxpython 2.8)
before releasing jessie - the last upstream release (2.8.12) was over 3
years ago, and there's very little upstream interest in bugs in it now.

I'm just finishing off packaging wxpython3.0 and hope to upload it in
the next few days (ITP is #734799).

I've attached the output of "dak rm -Rn -b python-wxgtk2.8" to indicate
the packages affected.

This should be a "smooth transition", as the packages for wxpython 2.8
and 3.0 are co-installable.

Cheers,
Olly

Ben file:

title = "wxpython3.0";
is_affected = .depends ~ "python-wxgtk2.8" | .depends ~ "python-wxgtk3.0";
is_good = .depends ~ "python-wxgtk3.0";
is_bad = .depends ~ "python-wxgtk2.8";
Will remove the following packages from unstable:

python-wxgtk2.8 | 2.8.12.1+dfsg2-1 | amd64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc

Maintainer: wxWidgets Maintainers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
bibus: bibus
bitpim: bitpim
bittorrent: bittorrent-gui
boa-constructor: boa-constructor
cain: cain
congruity: congruity
cycle: cycle
dballe: provami
dicompyler: dicompyler
dispcalgui: dispcalgui
djvusmooth: djvusmooth
douf00: douf00
drpython: drpython
editra: editra
fontypython: fontypython
gamera: gamera-gui
gastables: gastables
gecrit: gecrit
gnumed-client: gnumed-client
gnuradio: gnuradio
grass: grass-gui
hachoir-wx: python-hachoir-wx
invesalius: invesalius
kiki: kiki
londonlaw: londonlaw
mayavi2: mayavi2
mmass: mmass
model-builder: model-builder
opendict: opendict
openstv: openstv
p9m4: prover9-mace4
paprass: paprass
phatch: phatch
photofilmstrip: photofilmstrip
playonlinux/contrib: playonlinux
presage: pyprompter
pycorrfit: pycorrfit
pype: pype
pyragua: pyragua
pyro: pyro-gui
pyscanfcs: pyscanfcs
pyspread: pyspread
python-chaco: python-chaco
python-enable: python-enable
python-fs: python-fs-browser
python-pyface: python-pyface
python-traitsui: python-traitsui
python-wxmpl: python-wxmpl
pythoncard: python-pythoncard
pytimechart: pytimechart
quisk: quisk
rurple-ng: rurple-ng
salutatoi: sat-xmpp-wix
soundgrain: soundgrain
spe: spe
squaremap: python-squaremap
stimfit: stimfit
svn-workbench: svn-workbench
taskcoach: taskcoach
thuban: thuban
torchat: torchat
tpclient-pywx: tpclient-pywx
tribler: tribler
tunapie: tunapie
wammu: wammu
whyteboard: whyteboard
wxgeometrie: wxgeometrie
wxglade: python-wxglade
wxwidgets2.8: python-wxgtk2.8-dbg
  python-wxtools
xpilot-ng: xpilot-ng-common

# Broken Build-Depends:
bitpim: python-wxgtk2.8
editra: python-wxgtk2.8
fontypython: python-wxgtk2.8
gamera: python-wxgtk2.8
gnuradio: python-wxgtk2.8
grass: python-wxgtk2.8
ipython: python-wxgtk2.8
matplotlib: python-wxgtk2.8
presage: python-wxgtk2.8
psychopy: python-wxgtk2.8
pyke: python-wxgtk2.8
pyscanfcs: python-wxgtk2.8
quisk: python-wxgtk2.8
stimfit: python-wxgtk2.8 (>= 2.8.9)
taskcoach: python-wxgtk2.8 (>= 2.8.12.1-13)
thuban: python-wxgtk2.8
wxglade: python-wxgtk2.8

Dependency problem found.



signature.asc
Description: Digital signature

Bug#755757: transition: wxpython3.0

[Olly Betts]

On Wed, Jul 23, 2014 at 02:10:19PM +0200, Matthias Klose wrote:
> Am 23.07.2014 03:38, schrieb Olly Betts:
> > The intention is to eliminate wxwidgets2.8 (and hence wxpython 2.8) before
> > releasing jessie - the last upstream release (2.8.12) was over 3 years ago,
> > and there's very little upstream interest in bugs in it now.
> 
> are you saying that around 80 packages will be removed for jessie just
> because wxpython isn't yet ported to 3.0?

I don't really understand the question - wxPython 3.0.0.0 was released
in late 2013, and packages for it are in the NEW queue.

I'm not suggesting we remove around 80 packages, but that we move them
from using wxPython 2.8 to wxPython 3.0.  As with any large transition,
it's possible that we'll find a few candidates for removal in the
process, but that's not the aim of the transition.

> > This should be a "smooth transition", as the packages for wxpython 2.8 and
> > 3.0 are co-installable.
> 
> Maybe I misunderstand something but I wouldn't call this "smooth".

Are you perhaps mixing up wxPython 3.0 and Python 3.x?  It is the case
that neither wxPython 2.8 nor wxPython 3.0 support Python 3.x, but
that's irrelevant to this transition.

In this context, "smooth transition" just means that packages can be
switched one by one, rather than having to try to coordinate uploads
of ~80 different packages.

Cheers,
Olly


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723130745.gm8...@survex.com

Bug#750619: transition: wxsqlite3

[Olly Betts]

On Sun, Jul 06, 2014 at 08:43:09AM -0500, Paul Elliott wrote:
> On Sat, Jul 05, 2014 at 10:19:53PM +0200, László Böszörményi (GCS) wrote:
> > On Sat, Jul 5, 2014 at 6:19 PM, Emilio Pozuelo Monfort  
> > wrote:
> > > With guayadeque gone from testing because upstream is switching to qt, 
> > > what's
> > > the situation here? Are the other two packages ready to switch? If so, 
> > > shall we
> > > start this?
> >  The last package which needs updating is maitreya. Its upstream
> > finished the transition two weeks ago[1]:
> > "Service Release 7.0.6 (Jun 21 2014)
> >  This is a service release with support for wxWidgets 3.0.0. It is
> > used for wx migration purposes only.".
> > But the package and its Git tree is still on 7.0.5, but hopefully Paul
> > Elliott will update it soon. Should I NMU it after some days, if that
> > doesn't happen, maybe on Thursday?

All packages involved in this transition have now been removed from
testing.

wxsqlite3 itself is ready in experimental.

codelite is also ready in experimental.

guayadeque upstream is planning a switch from wx to Qt, though I haven't
seen an indication of the timescale for this - it's possible it might
not happen before jessie.  I discussed this briefly with pochu on
#debian-release, and he said it would be better to avoid breaking
guayadeque in unstable, but that an imperfect patch would be OK, so I
had a stab at updating it to use wx3.0 and there's now a patch in
#749978 (you want the second patch I sent) which seems to work aside
from a cosmetic issue (logo missing from splash screen/about panel).

maitreya status seems to be we're waiting for upstream to address some
assertion failures with wx3.0.  Given that these would have been quietly
ignored in a default built on wx2.8, I suggest we build it with -DNDEBUG
for now which tells wx3.0 to ignore them as wx2.8 does.  Then we can
actually make this transition happen and get the updated packages out
there a decent length of time before the jessie freeze (November 5th)
to give us a chance to shake out any problems.  Assuming maitreya
upstream makes a release before the freeze, we can drop -DNDEBUG and
ship that instead.

Cheers,
Olly


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140813023813.GA10240@gemse

Bug#750619: transition: wxsqlite3

[Olly Betts]

On Fri, Aug 15, 2014 at 07:56:59PM +0200, Emilio Pozuelo Monfort wrote:
> > An updated wxsqlite3 package is already in experimental.
> 
> Go ahead.

Thanks - to get things moving, I've NMUed the wxsqlite3 version in
experimental to unstable, with one trivial fix for a failure to
substitute @VERSION@ into the .pc file which recent lintian reports an
error for.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815230831.gp2...@survex.com

Bug#750619: transition: wxsqlite3

[Olly Betts]

On Sat, Aug 16, 2014 at 07:50:56AM +0200, László Böszörményi (GCS) wrote:
>  Why do you NMU my package after five hours? I'm active and wanted to
> upload 3.1.1 with more fixes. Now I'm going to wait not to clash with
> the transition.

Sorry, I didn't mean to annoy anyone.

There no problem with you uploading 3.1.1.  It certainly won't make the
transition take any longer than if I hadn't NMUed, and at this point it
won't delay it at all, since none of the rdeps have actually been
uploaded yet.

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816061757.ge13...@survex.com

Bug#755757: transition: wxpython3.0

[Olly Betts]

On Wed, Jul 23, 2014 at 03:33:03PM +0200, Matthias Klose wrote:
> Asking what will happen with packages depending on wxPython 2.8 and
> which cannot be converted to 3.0.

There aren't many incompatible changes between wxPython 2.8 and 3.0.
With the C++ API, the Unicode changes have been quite painful, but
that's simply not relevant to wxPython.

My hope is that we will get all packages converted, though I know from
the wxwidgets2.8 transition that there are a few rdeps which are dead
upstream and effectively unmaintained in Debian.  If such a package
isn't actually working currently and nobody has reported it, removal
might be the best option.

I've had a go at updating 20 of the rdeps of python-wxgtk2.8, so I've
now got some concrete information.  I've done all the orphaned ones
(since it seemed unlikely anyone else would), the two which also depend
libwxgtk2.8-dev, and a selection of others biased towards those with
the highest popcon scores.

Several packages work without any changes (including p9m4, the last
upload of which was an NMU by me in 2011 for the wxwidgets2.8
transition!)  For most of the others the updates needed are
mechanical (e.g. wx.Color is no longer supported as an alias for
wx.Colour).  I've produced a script which automates most of these
(link below).

The 5 orphaned packages I just QA uploaded, and of the other 15, 5 have
either been uploaded by the maintainer or NMUed by me.

Of the other 10, 8 are ready to upload (so 18 are uploaded or ready to
upload).

The other two are:

grass: grass 7.0.0 is close to release, but would require a transition
for dependencies.  For grass 6.4.3 I have a patch which makes the wizard
work, but the main gui needs more work.

playonlinux: The maintainer reports problems with layout.  I've not yet
tried it myself (the description warns "PlayOnLinux downloads and
execute unchecked third-party scripts"), so I'm not sure what the cause
is.

Extrapolating to the ~80 rdeps, that suggests something like 8 that
won't be trivial to update, is a realistic number to have to address
before the freeze.

Here are the user tagged bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=wxpy3.0;users=freewx-ma...@lists.alioth.debian.org

And the transition tracker:

https://release.debian.org/transitions/html/wxpython3.0.html

And finally, the repo with the script in, and a README about using it
and updating packages for wxPython 3.0 in general:

http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git

I'd like to encourage maintainers of affected packages to try this
script out.  In many cases, it should be enough to get your packages
working (if they don't already) - if it does, please upload them.

If the script doesn't do the job, let me know (or improve the script if
you can figure out what it needs to do to get your package working).

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140818105818.gp14...@survex.com