Bug#1037251: new version

[Bill Blough]

Hi,

Version 1.17.0 is now available in unstable and testing.  Can you
confirm whether or not this issue still happens with the new version?

Regards,
Bill


-- 

Bug#1036971: pwsafe: empty window after internal timeout or screen blank

[Bill Blough]

Ah, I see.  Thanks for the clarification.

Yes, that sounds like a bug to me.

I'll test with the upstream version and see if the problem exists there
(I assume it will - I don't think any of our packaging would cause
this), and then forward upstream.

Thanks for your report!

Bug#1036971: pwsafe: empty window after internal timeout or screen blank

[Bill Blough]

Hi,

If I understand your report correctly, this sounds like expected
behavior - the program will lock itself in order to protect your
passwords.

You can change this behavior by going to Manage->Options->Security and
then toggling the settings that relate to "Lock password database".

Please let me know if this doesn't address your issue.  Thanks.


On Wed, May 31, 2023 at 09:48:45AM +0200, Giuseppe Sacco wrote:
> Package: passwordsafe
> Version: 1.16.0+dfsg-4
> Severity: normal
> 
> Dear Maintainer,
> after running pwsafe, it select the default keystore, prompts for the
> password and displays the keystore content in the GUI. After some time the
> window automatically disappear but I may get it back using Alt-Tab key.
> Once the window is shown again, it is empty: it does not list the keystore
> content and it does not prompt for the keystore password either. Here, if I
> open the File menu and select the 'Unlock Safe' menu item, I see the
> keystore content correctly.
> 
> I did not find any configuration option that could prevent the password
> prompt when getting back the pswafe window. Is this an error?
> 
> Thank you,
> Giuseppe
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwordsafe depends on:
> ii  libc6    2.36-9
> ii  libgcc-s1    12.2.0-14
> ii  libmagic1    1:5.44-3
> ii  libqrencode4 4.1.1-1
> ii  libstdc++6   12.2.0-14
> ii  libuuid1 2.38.1-5+b1
> ii  libwxbase3.2-1   3.2.2+dfsg-2
> ii  libwxgtk3.2-1    3.2.2+dfsg-2
> ii  libx11-6 2:1.8.4-2
> ii  libxerces-c3.2   3.2.4+debian-1
> ii  libxtst6 2:1.2.3-1.1
> ii  libykpers-1-1    1.20.0-3
> ii  passwordsafe-common  1.16.0+dfsg-4
> 
> Versions of packages passwordsafe recommends:
> pn  xvkbd  
> 
> passwordsafe suggests no packages.
> 
> -- no debconf information
> 

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#1034302: fixed in passwordsafe 1.16.0+dfsg-3

[Bill Blough]

It looks like there might have been another issue with the package (test
issues on i386).

I'm uploading another version today to fix that, so it will reset the 20
day timer, but it should migrate without issue after that unless there's
another problem.

Bug#1034302: fixed in passwordsafe 1.16.0+dfsg-3

[Bill Blough]

I believe it only needs the 20 day delay.  If it doesn't migrate after that, 
I'll file an unblock request.

Bug#986324: soci: libsoci-dev needs Depends: on libboost1.74-dev

[Bill Blough]

Hi Dennis,

On Sun, Oct 30, 2022 at 09:04:41AM +0100, Dennis Filder wrote:

> (Reply is late as I wasn't CC'ed)
Apologies - I meant to CC you, but apparently forgot.


> BTW: If #1021125 is still open by 2022-11-07 we'll probably NMU it
> (it's just a soversion bump/library package rename).

Please feel free to NMU at your convenience. I'm going to be very busy
this week, and it's unlikely that I will get to it in time.


Best regards,

Bill

Bug#914257:

[Bill Blough]

Apologies for keeping this idled for so long.  As it turns out, I will
no longer be packaging it.

Bug#986324: soci: libsoci-dev needs Depends: on libboost1.74-dev

[Bill Blough]

The package build-depends on libboost-dev, which depends on the default
boost-dev version (libboost1.74-dev in bullseye).  So it's not clear to
me how this issue could be occurring unless transitive dependencies
aren't being satisfied for some reason.

Bug#985982: redshift: reshift flickers randomly between night mode and daylight mode

[Bill Blough]

On my system, the repeated cycling between day and night only seems to happen
with the "randr" adjustment method.

If I manually set the method to "vidmode" either on the command line
(-m vidmode) or in the config file (adjustment-method = vidmode), the
color adjusts and stays constant as expected.

I haven't investigated any further, but maybe that's a work-around until
a proper fix can be found.

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#983365: linphone-desktop: chat messages

[Bill Blough]

On Sat, Mar 13, 2021 at 04:21:02PM +0100, Dennis Filder wrote:
> Good, I just tried it with linphone 4.4.21-2, linphone-desktop 4.2.5-3
> and soci 4.0.1-5 and chat message history restoration works nicely.

That's great to hear!  Glad you got it sorted out.

Bug#983365: (no subject)

[Bill Blough]

Hi Dennis,

I did respond to your email on the 7th.  Maybe it wound up in your spam
folder?

At any rate, apologies for the delay - things have been a bit busy the
past several days.

I'm currently building/testing the data type patch, and hope to upload
it to unstable today.  I'll file the unblock request once that's done.

Since we're in the freeze, I'm going to hold off on applying the test
regen patch for now, but I'll add it eventually.

Best regards,
Bill

Bug#983365: linphone-desktop: chat messages

[Bill Blough]

Hi,

> Have you reached out to the SOCI maintainer in private already? I don't
> see a bug report on this. If we can get a targeted fix uploaded for this
> within the next days (next step of the freeze is on March 10th, with a
> migration time of 10 days right now) I will attempt to push through a
> new src:linphone upload. Do you know whether we need a new
> src:linphone-desktop upload as well?

I'm the SOCI maintainer.   Dennis did email me and explain the
situation, and I don't see an issue making the change.

I'll prepare the upload today.  If someone would please file a bug
against SOCI regarding this, I would appreciate it.

Best regards,
Bill

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#983535: sbuild: source-only-changes only includes most recent changelog entry despite -v arg

[Bill Blough]

> 
> it seems you are running sbuild 0.79.1 which explains that you see this issue.
> This is the same as has already been reported in #884428, #891247, #917849,
> #947755 and fixed in 0.80.0.

I looked through the changelog for the version in unstable, but I guess
I completely missed the entry where it was fixed.  Of course, now that
you pointed it out, I see it.

The next stable release is fine.

Sorry for the noise!

Best regards,
Bill

Bug#979327: xalan: FTBFS on i386: architecture confusion

[Bill Blough]

I had already pushed the initial fix by the time I received this, so I've
reopened the bug.  I'll address it later this evening.

Bug#977568: xml-security-c changes for xalan 1.12

[Bill Blough]

Hi,

I've uploaded xalan 1.12 to unstable.  If you would like me to NMU
xml-security-c with the necessary changes (attached to 977568), I would
be happy to do so.

Best regards,
Bill



-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#961067: Should be fixed in 1.2.0-1 (not verified)

[Bill Blough]

Support for Django 3 has been added upstream, so this should be fixed as of
the 1.2.0-1 upload.  However, I haven't had a chance to test it with
Django 3 to confirm that everything plays nicely.


-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

I've uploaded 3.2.3+debian-3 to unstable with a fix for the test failure
on 32-bit archs.

They're still building, but several of the 32-bit archs have already
completed successfully, and I fully expect the others to complete as
well.

The updated quilt patch is attached.


https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311

--- a/src/xercesc/internal/IGXMLScanner.cpp
+++ b/src/xercesc/internal/IGXMLScanner.cpp
@@ -1532,7 +1532,6 @@ void IGXMLScanner::scanDocTypeDecl()
 DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager);
 declDTD->setSystemId(sysId);
 declDTD->setIsExternal(true);
-Janitor janDecl(declDTD);
 
 // Mark this one as a throw at end
 reader->setThrowAtEnd(true);
@@ -3095,7 +3094,6 @@ Grammar* IGXMLScanner::loadDTDGrammar(co
 DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager);
 declDTD->setSystemId(src.getSystemId());
 declDTD->setIsExternal(true);
-Janitor janDecl(declDTD);
 
 // Mark this one as a throw at end
 newReader->setThrowAtEnd(true);
--- a/tests/expected/MemHandlerTest1.log
+++ b/tests/expected/MemHandlerTest1.log
@@ -1,4 +1,4 @@
-At destruction, domBuilderMemMonitor has 0 bytes.
-At destruction, sax2MemMonitor has 0 bytes.
-At destruction, sax1MemMonitor has 0 bytes.
+At destruction, domBuilderMemMonitor has 276 bytes.
+At destruction, sax2MemMonitor has 276 bytes.
+At destruction, sax1MemMonitor has 276 bytes.
 At destruction, staticMemMonitor has 0 bytes.
--- /dev/null
+++ b/tests/expected/MemHandlerTest1_32.log
@@ -0,0 +1,4 @@
+At destruction, domBuilderMemMonitor has 180 bytes.
+At destruction, sax2MemMonitor has 180 bytes.
+At destruction, sax1MemMonitor has 180 bytes.
+At destruction, staticMemMonitor has 0 bytes.
--- a/scripts/run-test.in
+++ b/scripts/run-test.in
@@ -46,6 +46,11 @@ run_test() {
 sed -i -e 's;\( *[0-9][0-9]* *ms *\);{timing removed};' "$output"
 
 exp=$(cat "${srcdir}/expected/${name}.log")
+
+if [ "${name}" = "MemHandlerTest1" ] && [ "$(dpkg-architecture -q DEB_HOST_ARCH_BITS)" -eq 32 ]; then
+exp=$(cat "${srcdir}/expected/${name}_32.log")
+fi
+
 obs=$(cat "$output")
 
 echo "--"

Bug#976130: passwordsafe: pwsafe hangs and yubikey stops working

[Bill Blough]

The hang/unresponsiveness *may* be related to 
https://github.com/pwsafe/pwsafe/issues/559
or it might be something else.

If it is related to the above, then there's no fix for it yet, as it's been
difficult to reliably reproduce.

Since it seems to be happening pretty consistently for you, would you
mind doing some additional testing and data gathering to help
troubleshoot?

Specifically, I'd be interested to know if the yubikey is related.  If
you unplug the yubikey, and attempt to go through normal usage patterns
without the yubikey in the picture, does it work normally?  If so, it
could indicate problem with passwordsafe's yubikey support.

If it's the same regardless whether or not the yubikey is present, then
it's probably something else.

Also, it might be helpful if you could provide a log of running
passwordsafe under strace, up to and including the point you notice the
the hang.  That might help give an indication of what's happening.


On Sun, Nov 29, 2020 at 09:17:52PM -0800, jackie wrote:
> Package: passwordsafe
> Version: 1.11.0+dfsg-1
> Severity: important
> X-Debbugs-Cc: jac...@pobox.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I just started using pwsafe for testing purposes
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> The first time I ran it it worked fine. The second time it would hang. After
> that even after rm -rf .pwsafe it would just hang. Also my yubikey would stop
> working. If I logged out the problem with the yubi would persist. If I reboot
> the yubikey would work and pwsafe would be more responsive but not actually
> work. I tried buildind my own version 1.11 and got the same error.
> 
> After another reboot it worked but then the enter conbination screen came up
> and hang. reboot unresposive. yubikey does not work.
> 
>* What was the outcome of this action?
> hangs
>* What outcome did you expect instead?
> for it to work normally
> *** End of the template - remove these template lines ***
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwordsafe depends on:
> ii  libc6 2.31-4
> ii  libgcc-s1 10.2.0-19
> ii  libmagic1 1:5.38-5
> ii  libqrencode4  4.0.2-2
> ii  libstdc++610.2.0-19
> ii  libuuid1  2.36.1-1
> ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2
> ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2
> ii  libx11-6  2:1.6.12-1
> ii  libxerces-c3.23.2.3+debian-1+bkk1
> ii  libxtst6  2:1.2.3-1
> ii  libykpers-1-1 1.20.0-2.1
> ii  passwordsafe-common   1.11.0+dfsg-1
> 
> Versions of packages passwordsafe recommends:
> ii  xvkbd  4.1-1
> 
> passwordsafe suggests no packages.
> 
> -- no debconf information
> 

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

FYI, it looks like the test suite is failing on 32-bit architectures
due to different amounts of memory being leaked than what the updated
leak test is expecting. (I'm guessing due to pointer size differences)

I'll try to figure out a solution that will pass everywhere, but if all
else fails, I may wind up temporarily marking that test as XFAIL as a
work-around.

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

This patch has been applied in 3.2.3+debian-2 which has been uploaded to
unstable.

I'll leave this bug open in hopes of an eventual upstream fix.

On Wed, Dec 09, 2020 at 05:46:33PM +0100, Sylvain Beucler wrote:
> Hi,
> 
> Here's a debdiff against buster.
> 
> The testsuite passes, provided we modify MemHandlerTest1 to take the leak
> into account.
> 
> What do you think?
> 
> Cheers!
> Sylvain Beucler
> Debian LTS Team
> 
> On 24/11/2020 17:39, Bill Blough wrote:
> > The package has a test suite, so that's probably the minimum. But I'm
> > not sure how much it exercises the DTD code, if at all.
> > 
> > I also typically test with some of our internal code at work.  But
> > again, no DTDs in use there, either.
> > 
> > On Mon, Nov 23, 2020 at 03:56:37PM +0100, Sylvain Beucler wrote:
> > > Hi,
> > > 
> > > I can assist with this, notably a LTS upload - not necessarily immediately
> > > either.
> > > 
> > > Bill, do you have testing procedures to recommend for this package?
> > > 
> > > Security Team, before issuing a LTS upload, what is your view on a Stable
> > > upload for this issue?
> > > 
> > > Cheers!
> > > Sylvain Beucler
> > > Debian LTS Team
> > > 
> > > On 23/11/2020 03:01, Bill Blough wrote:
> > > > Yes, this seems reasonable.
> > > > 
> > > > I'll prepare an upload to unstable prior to the freeze.  But it likely
> > > > won't be for a couple of weeks due to my current workload.
> > > > 
> > > > Since I assume one of your concerns is for LTS, feel free to do the LTS
> > > > upload.  Or, if you'd rather, I can make an attempt at that in a couple
> > > > of weeks as well.

> diff -Nru xerces-c-3.2.2+debian/debian/changelog 
> xerces-c-3.2.2+debian/debian/changelog
> --- xerces-c-3.2.2+debian/debian/changelog2018-09-19 21:19:49.0 
> +0200
> +++ xerces-c-3.2.2+debian/debian/changelog2020-12-09 16:42:11.0 
> +0100
> @@ -1,3 +1,12 @@
> +xerces-c (3.2.2+debian-1+deb10u1) buster-security; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * CVE-2018-1311 mitigation: fix use-after-free vulnerability when
> +processing external DTD, at the expense of a memory leak.  Users may
> +mitigate both by setting the XERCES_DISABLE_DTD environment variable.
> +
> + -- Sylvain Beucler   Wed, 09 Dec 2020 16:42:11 +0100
> +
>  xerces-c (3.2.2+debian-1) unstable; urgency=medium
>  
>* New upstream version 3.2.2+debian Closes: 909202
> diff -Nru xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch 
> xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch
> --- xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch   
> 1970-01-01 01:00:00.0 +0100
> +++ xerces-c-3.2.2+debian/debian/patches/CVE-2018-1311-mitigation.patch   
> 2020-12-09 16:42:11.0 +0100
> @@ -0,0 +1,35 @@
> +
> +https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311
> +
> +Index: xerces-c-3.2.2+debian/src/xercesc/internal/IGXMLScanner.cpp
> +===
> +--- xerces-c-3.2.2+debian.orig/src/xercesc/internal/IGXMLScanner.cpp
>  xerces-c-3.2.2+debian/src/xercesc/internal/IGXMLScanner.cpp
> +@@ -1532,7 +1532,6 @@ void IGXMLScanner::scanDocTypeDecl()
> + DTDEntityDecl* declDTD = new (fMemoryManager) 
> DTDEntityDecl(gDTDStr, false, fMemoryManager);
> + declDTD->setSystemId(sysId);
> + declDTD->setIsExternal(true);
> +-Janitor janDecl(declDTD);
> + 
> + // Mark this one as a throw at end
> + reader->setThrowAtEnd(true);
> +@@ -3095,7 +3094,6 @@ Grammar* IGXMLScanner::loadDTDGrammar(co
> + DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, 
> false, fMemoryManager);
> + declDTD->setSystemId(src.getSystemId());
> + declDTD->setIsExternal(true);
> +-Janitor janDecl(declDTD);
> + 
> + // Mark this one as a throw at end
> + newReader->setThrowAtEnd(true);
> +Index: xerces-c-3.2.2+debian/tests/expected/MemHandlerTest1.log
> +===
> +--- xerces-c-3.2.2+debian.orig/tests/expected/MemHandlerTest1.log
>  xerces-c-3.2.2+debian/tests/expected/MemHandlerTest1.log
> +@@ -1,4 +1,4 @@
> +-At destruction, domBuilderMemMonitor has 0 bytes.
> +-At destruction, sax2MemMonitor has 0 bytes.
> +-At destruction, sax1MemMonitor has 0 bytes.
> ++At destruction, domBuilderMemMonitor has 276 bytes.
> ++At destruction, sax2MemMonitor has 276 bytes.
> ++At destruction, sax1MemMonitor has 276 bytes.
> + At destruction, staticMemMonitor has 0 bytes.
> diff -Nru xerces-c-3.2.2+debian/debian/patches/series 
> xerces-c-3.2.2+debian/debian/patches/series
> --- xerces-c-3.2.2+debian/debian/patches/series   2018-09-19 
> 21:19:49.0 +0200
> +++ xerces-c-3.2.2+debian/debian/patches/series   2020-12-09 
> 16:42:11.0 +0100
> @@ -0,0 +1 @@
> +CVE-2018-1311-mitigation.patch


-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

Looks good to me.  Thanks.

Bug#976299: xalan: FTBFS during separate binary-indep build

[Bill Blough]

Hi,

Thanks for your report.

I hope to address these issues next week.

Best regards,
Bill

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

The package has a test suite, so that's probably the minimum. But I'm
not sure how much it exercises the DTD code, if at all.

I also typically test with some of our internal code at work.  But
again, no DTDs in use there, either.

On Mon, Nov 23, 2020 at 03:56:37PM +0100, Sylvain Beucler wrote:
> Hi,
> 
> I can assist with this, notably a LTS upload - not necessarily immediately
> either.
> 
> Bill, do you have testing procedures to recommend for this package?
> 
> Security Team, before issuing a LTS upload, what is your view on a Stable
> upload for this issue?
> 
> Cheers!
> Sylvain Beucler
> Debian LTS Team
> 
> On 23/11/2020 03:01, Bill Blough wrote:
> > Yes, this seems reasonable.
> > 
> > I'll prepare an upload to unstable prior to the freeze.  But it likely
> > won't be for a couple of weeks due to my current workload.
> > 
> > Since I assume one of your concerns is for LTS, feel free to do the LTS
> > upload.  Or, if you'd rather, I can make an attempt at that in a couple
> > of weeks as well.

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#975600: New upstream release 1.12.0

[Bill Blough]

Hi Roger,

Thanks for the reminder.  1.12 is currently setting in experiemental.
I expect to be filing a transition request in the next week or two.

Best regards,
Bill




On Mon, Nov 23, 2020 at 10:56:39PM +, Roger Leigh wrote:
> Package: xalan
> Version: 1.11-9
> 
> Hi Bill,
> 
> This was mentioned on the upstream mailing list earlier in the year.  Just 
> opening a bug to track this.
> 
> New upstream release 1.12 was made a few months back 
> (https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could 
> be packaged to replace the decade-old 1.11 release.  Note that the new 
> release brings with it a new CMake-based build system to match Xerces-C.  All 
> the configuration options of the old build system are exposed via CMake 
> options.  It's all documented in the manual: 
> https://apache.github.io/xalan-c/build.html
> 
> Kind regards,
> Roger

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

Yes, this seems reasonable.

I'll prepare an upload to unstable prior to the freeze.  But it likely
won't be for a couple of weeks due to my current workload.

Since I assume one of your concerns is for LTS, feel free to do the LTS
upload.  Or, if you'd rather, I can make an attempt at that in a couple
of weeks as well.

Best regards,
Bill

Bug#971054: Fwd: Bug#971054: winedbg --gdb does not work with 32-bit WINEPREFIX

[Bill Blough]

Hi Bernhard,

Thanks very much for investigating this!

I can confirm that adjusting the PATH works around the issue for me.

Best regards,
Bill

Bug#947899: xerces-c: FTBFS on ports without java support

[Bill Blough]

Thanks for the report and patch.  I'm still getting caught up from the
holidays, so it will be a little bit longer before I get to this.

If it's a blocker for you, please feel free to NMU. Otherwise, I'll
update the package in the next week or two.

Bug#942529: phabricator: Please provide phabricator package again

[Bill Blough]

Understood, thanks.  I don't have time right now, either, but I might be
able to help with this at some point in the future.

Bug#939080: Updated patch

[Bill Blough]

There were a couple of issues with the previous patch that I didn't
notice earlier:

1) Line endings seem to have gotten mangled

2) Newer versions of quilt don't appear to like it if you manually edit
the series file.

The attached patch has the same changes as the previous patch except
that it doesn't modify the quilt series file, and it should preserve the
correct line endings.



-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84
Description: Add new-style constructors
 Old-style (php4) constructors are deprecated.  They generate warnings
 currently, and will stop working in php8.  Adding new-style constructors
 while keeping the old ones silences the warnings and prepares for php8
Author: Bill Blough 
Last-Update: 2019-09-06
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/lib/class.nusoap_base.php
+++ b/lib/class.nusoap_base.php
@@ -222,11 +222,21 @@ class nusoap_base {
 	*
 	* @access	public
 	*/
-	function nusoap_base() {
+	function __construct() {
 		$this->debugLevel = $GLOBALS['_transient']['static']['nusoap_base']['globalDebugLevel'];
 	}
 
 	/**
+	* old constructor
+	*
+	* @access	public
+	*/
+	function nusoap_base() {
+		$self::__construct();
+	}
+
+
+	/**
 	* gets the global debug level, which applies to future instances
 	*
 	* @return	integer	Debug level 0-9, where 0 turns off
@@ -993,4 +1003,4 @@ function usleepWindows($usec)
 }
 
 
-?>
\ No newline at end of file
+?>
--- a/lib/class.soap_fault.php
+++ b/lib/class.soap_fault.php
@@ -45,7 +45,7 @@ class nusoap_fault extends nusoap_base {
 * @param string $faultstring human readable error message
 * @param mixed $faultdetail detail, typically a string or array of string
 	*/
-	function nusoap_fault($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
+	function __construct($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
 		parent::nusoap_base();
 		$this->faultcode = $faultcode;
 		$this->faultactor = $faultactor;
@@ -54,6 +54,18 @@ class nusoap_fault extends nusoap_base {
 	}
 
 	/**
+	* old constructor
+*
+* @param string $faultcode (SOAP-ENV:Client | SOAP-ENV:Server)
+* @param string $faultactor only used when msg routed between multiple actors
+* @param string $faultstring human readable error message
+* @param mixed $faultdetail detail, typically a string or array of string
+	*/
+	function nusoap_fault($faultcode,$faultactor='',$faultstring='',$faultdetail=''){
+		$self::__construct($faultcode,$faultactor,$faultstring,$faultdetail);
+	}
+
+	/**
 	* serialize a fault
 	*
 	* @return	string	The serialization of the fault instance.
@@ -87,4 +99,4 @@ class soap_fault extends nusoap_fault {
 }
 
 
-?>
\ No newline at end of file
+?>
--- a/lib/class.soap_parser.php
+++ b/lib/class.soap_parser.php
@@ -57,7 +57,7 @@ class nusoap_parser extends nusoap_base
 	* @paramstring $decode_utf8 whether to decode UTF-8 to ISO-8859-1
 	* @access   public
 	*/
-	function nusoap_parser($xml,$encoding='UTF-8',$method='',$decode_utf8=true){
+	function __construct($xml,$encoding='UTF-8',$method='',$decode_utf8=true){
 		parent::nusoap_base();
 		$this->xml = $xml;
 		$this->xml_encoding = $encoding;
@@ -144,6 +144,20 @@ class nusoap_parser extends nusoap_base
 	}
 
 	/**
+	* old constructor
+	*
+	* @paramstring $xml SOAP message
+	* @paramstring $encoding character encoding scheme of message
+	* @paramstring $method method for which XML is parsed (unused?)
+	* @paramstring $decode_utf8 whether to decode UTF-8 to ISO-8859-1
+	* @access   public
+	*/
+	function nusoap_parser($xml,$encoding='UTF-8',$method='',$decode_utf8=true){
+		$self::__construct($xml,$encoding,$method,$decode_utf8);
+	}
+
+
+	/**
 	* start-element handler
 	*
 	* @paramresource $parser XML parser object
@@ -640,4 +654,4 @@ class soap_parser extends nusoap_parser
 }
 
 
-?>
\ No newline at end of file
+?>
--- a/lib/class.soap_server.php
+++ b/lib/class.soap_server.php
@@ -170,7 +170,7 @@ class nusoap_server extends nusoap_base
 * @param mixed $wsdl file path or URL (string), or wsdl instance (object)
 	* @access   public
 	*/
-	function nusoap_server($wsdl=false){
+	function __construct($wsdl=false){
 		parent::nusoap_base();
 		// turn on debugging?
 		global $debug;
@@ -228,6 +228,17 @@ class nusoap_server extends nusoap_base
 	}
 
 	/**
+	* old constructor
+* the optional parameter is a path to a WSDL file that you'd like to bind the server instance to.
+	*
+* @param mixed $wsdl file path or URL (string), or wsdl instance (object)
+	* @access   public
+	*/
+	function nusoap_server($wsdl=false){
+		$self::__construct($wsdl);
+	}
+
+	/**
 	* processes request and returns response
 	*
 	* @paramstring $data usually is the value of $HTTP_RAW_POST_DATA
@@ -1124,4 +1135,4 @@ class soap_server extends nusoap_server
 }
 
 
-?>
\ No newline at end of file
+?>
--- a/lib/class.soap_transport_http.php
+++ b/lib/class.soap_tra

Bug#677673: Please reject packages with distribution UNRELEASED in changelog

[Bill Blough]

>I'd like to request that the archive automatically reject packages with
>this problem

+1

Due to a bug [1], I accidentally uploaded a package with the changelog
distribution set to UNRELEASED.

When I discovered it after the fact, I was surprised that the upload wasn't
automatically rejected.  The Debian New Maintainer's Guide implies that
it should be [2].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934721
[2] https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

Hi Josch,

Here's an updated patch.

Now .changes.new is written to $build_dir, then renamed to .changes, and
copied from the chroot to sys_build_dir.

I removed the call to unlink() since we want to keep the .changes file
in $build_dir so it can be used by lintian.

Also, I saw in HACKING that the emacs perl-mode style is used.  I don't
use emacs, and unfortunately a web search didn't turn up the specifics
of what that styling entails.  So I tried to match the style the best I
could.  Apologies if it's off slightly.

Let me know if you see any issues with the patch.

Thanks,
Bill
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index f5660148..5e60436f 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2601,8 +2601,9 @@ sub build {
 	}
 
 	my $sys_build_dir = $self->get_conf('BUILD_DIR');
-	if (!open( F2, ">$sys_build_dir/$changes.new" )) {
-		$self->log("Cannot create $sys_build_dir/$changes.new: $!\n");
+	my $F2 = $session->get_write_file_handle("$build_dir/$changes.new");
+	if (!$F2) {
+		$self->log("Cannot create $build_dir/$changes.new\n");
 		$self->log("Distribution field may be wrong!!!\n");
 		if ($build_dir) {
 		if(!$session->copy_from_chroot("$build_dir/$changes", ".")) {
@@ -2611,14 +2612,21 @@ sub build {
 		}
 	} else {
 		$pchanges->output(\*STDOUT);
-		$pchanges->output(\*F2);
-
-		close( F2 );
-		rename("$sys_build_dir/$changes.new", "$sys_build_dir/$changes")
-		or $self->log("$sys_build_dir/$changes.new could not be " .
-		"renamed to $sys_build_dir/$changes: $!\n");
-		unlink("$build_dir/$changes")
-		if $build_dir;
+		$pchanges->output(\*$F2);
+
+		close( $F2 );
+
+		$session->rename("$build_dir/$changes.new", "$build_dir/$changes");
+		if ($? == 0) {
+		$self->log("$build_dir/$changes.new could not be " .
+			"renamed to $build_dir/$changes: $!\n");
+		$self->log("Distribution field may be wrong!!!");
+		}
+		if ($build_dir) {
+		if (!$session->copy_from_chroot("$build_dir/$changes", "$sys_build_dir")) {
+			$self->log("Could not copy $build_dir/$changes to $sys_build_dir");
+		}
+		}
 	}
 
 	return $pchanges;

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

On Thu, Aug 15, 2019 at 01:38:48PM +0200, Johannes Schauer wrote:
> 
> > Also, after the new .changes file is written, there's an attempt to delete
> > the old one in , but it seems to fail silently.  So I assume this
> > is a bug, rather than an intentional choice. (Also, the variables in 
> > question
> > are very similarly named, so I think it would be an easy mistake to make).
> 
> I assume you are referring to this unlink call?
> 
> https://sources.debian.org/src/sbuild/0.78.1-2/lib/Sbuild/Build.pm/#L2620

Yes.

> 
> > I've attached a small patch that makes it use the modified .changes file
> > instead of the unmodified one.  On my system, this makes it behave as I 
> > would
> > expect.  That is, lintian run via sbuild behaves the same way as lintian run
> > manually, since they're now using the exact same .changes file.
> 
> that your patch works for you is coincidental. By using
> $self->get_conf('BUILD_DIR') instead of $self->get('Build Dir') you will end 
> up
> using the output directory of the build artifacts *outside* the chroot. See 
> the
> documentation for the BUILD_DIR config option in sbuild.conf(5). That it works
> for you might mean that you have set up your chroots in a way such that 
> lintian
> inside the chroot has access to the path outside of it. Maybe you are building
> in /tmp and have that mounted inside as well, for example?

You're right.  I forgot that for troubleshooting purposes I modified my schroot
to mount my homedir. Good catch.

> 
> If you would like to prepare a patch that fixes this issue, then what should
> actually happen is probably that the "copy_changes()" subroutine modifies the
> .changes files inplace inside the chroot so that when Lintian is called later,
> it sees the same files as the ones that get copied to the outside by
> "copy_changes()".

Sure.  I'll see what I can do.

Thanks.

Bill

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

I've had a chance to do some more exploration.

Lintian is indeed getting run with a different .changes file than what
is output to screen/disk.

The package build creates a changes file in the temporary 
that contains a Distribution of UNRELEASED.  This happens even if the
distribution is specified with -d.

The .changes file later gets written to BUILD_DIR, with the Distribution
field set to what was specified by -d.

However, lintian is run against the original (Dist: UNRELEASED) .changes
file left in , not the modified version written in BUILD_DIR.

It seems to me that lintian should be run against the modified .changes
file that is provided to the user after the build, rather than the
leftover one in  that is different.


Also, after the new .changes file is written, there's an attempt to delete the
old one in , but it seems to fail silently.  So I assume this
is a bug, rather than an intentional choice. (Also, the variables in
question are very similarly named, so I think it would be an easy
mistake to make).


I've attached a small patch that makes it use the modified .changes file
instead of the unmodified one.  On my system, this makes it behave as I
would expect.  That is, lintian run via sbuild behaves the same way as
lintian run manually, since they're now using the exact same .changes file.


Best regards,
Bill
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index f5660148..83dc295f 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1684,7 +1684,7 @@ sub run_lintian {
 my $pipe = $session->pipe_command(
 { COMMAND => \@lintian_command,
   PRIORITY => 0,
-  DIR => $self->get('Build Dir'),
+  DIR => $self->get_conf('BUILD_DIR'),
 	  PIPE => "in"
 });
 if (!$pipe) {

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

Hi Josch,

Thanks for taking the time to give that explanation.

In my testing, I observed exactly what you said - using '-d' sets the
Distribution field in the .changes file.  Not using '-d' causes the
Distribution to be populated with the distribution value from the
d/changelog entry

But I feel like there's still an issue, or I'm still not understanding
something correctly.

When sbuild calls lintian, it passes the filename of the .changes file.

If my understanding is correct, using or not using '-d' has already
affected the contents of the .changes file at that point.  Then linitan
runs against that .changes file, and gets all of its information from
there.

So shouldn't running lintian outside of sbuilt using the *exact same*
.changes file produce the same output?

I would think yes, unless-

1) the .changes file passed to lintian is different than the .changes
file written to the log and left on disk after the build

or

2) the output from lintian is somehow altered/modified by sbuild.

Neither of those seem to be the case, but I'm not 100% sure.  However,
either of those could explain the discrepancy.


> 
> Do you see any way sbuild could improve to be less confusing?

I think most of the docs are pretty clear.  But I guess that depends on if
there's really an issue as I suspect, or if I'm just greatly
misunderstanding thing.

I guess I'll let you know once we figure out which one :-)

Best regards,
Bill

Bug#932945: buster-pu: package passwordsafe/1.06+dfsg-1

[Bill Blough]

On Sun, Aug 04, 2019 at 04:43:20PM +0100, Jonathan Wiltshire wrote:
> On Sun, Aug 04, 2019 at 02:42:07PM +0000, Bill Blough wrote:
> > diff -Nru passwordsafe-1.06+dfsg/debian/changelog 
> > passwordsafe-1.06+dfsg/debian/changelog
> > --- passwordsafe-1.06+dfsg/debian/changelog 2018-08-15 05:32:43.0 
> > -0400
> > +++ passwordsafe-1.06+dfsg/debian/changelog 2019-07-21 18:19:37.0 
> > -0400
> > @@ -1,3 +1,10 @@
> > +passwordsafe (1.06+dfsg-1+deb9u1) buster; urgency=medium
> 
> The change is fine but this version number is not; looks like it might have
> been recycled from the corresponding update to stretch. With it fixed
> (deb10u1) please go ahead.

Ah, yes. Apologies for that.  I've fixed the version number and
uploaded the package.  Thanks!

Bug#932944: stretch-pu: package passwordsafe/1.00+dfsg-1

[Bill Blough]

Uploaded, thanks.

For reference, the buster-pu request is 932945.

Bug#932947: (no subject)

[Bill Blough]

Above I wrote fsaccessat() - that should have been faccessat().


-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#932947: --mime-type fails on arm64 arch due to seccomp

[Bill Blough]

Package: file
Version: 1:5.37-4
Severity: normal

With seccomp enabled, --mime-type is no longer working on arm64.  It
still works on other architectures.

Looking at straces, it seems to be because arm64 is using fsaccessat()
instead of access(). (It's my understanding that arm64 doesn't implement
access()).

Is it possible/reasonable to adjust the seccomp rules to allow
fsaccessat() to restore this functionality on arm64 and bring it back in
line with the other architectures?


To reproduce on sid:

/usr/bin/file --mime-type '/usr/share/icons/hicolor/48x48/apps/xterm.png'

On arm64 this produces "bad system call"

On other archs this produces the expected output, including mimetype.


I have also attached the aforementioned sample straces for amd64, arm64
when failing, and arm64 when run (successfully) with --no-sandbox.

Best regards,

Bill
execve("/usr/bin/file", ["/usr/bin/file", "-b", "--mime-type", 
"data/image1.jpg"], 0x7ffe448fc038 /* 19 vars */) = 0
brk(NULL)   = 0x556986a7b000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32092, ...}) = 0
mmap(NULL, 32092, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7efd0925d000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libmagic.so.1", O_RDONLY|O_CLOEXEC) 
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`G\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=157928, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7efd0925b000
mmap(NULL, 160744, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd09233000
mmap(0x7efd09237000, 102400, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7efd09237000
mmap(0x7efd0925, 32768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x1d000) = 0x7efd0925
mmap(0x7efd09258000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7efd09258000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libseccomp.so.2", 
O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3001\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=293096, ...}) = 0
mmap(NULL, 295176, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd091ea000
mmap(0x7efd0920d000, 40960, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0x7efd0920d000
mmap(0x7efd09217000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2d000) = 0x7efd09217000
mmap(0x7efd0921b000, 98304, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x7efd0921b000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0205\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=158400, ...}) = 0
mmap(NULL, 160400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd091c2000
mmap(0x7efd091c5000, 98304, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7efd091c5000
mmap(0x7efd091dd000, 45056, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x1b000) = 0x7efd091dd000
mmap(0x7efd091e8000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7efd091e8000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libbz2.so.1.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\"\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=74688, ...}) = 0
mmap(NULL, 76840, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd091af000
mmap(0x7efd091b1000, 53248, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7efd091b1000
mmap(0x7efd091be000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xf000) = 0x7efd091be000
mmap(0x7efd091c, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7efd091c
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320#\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=121280, ...}) = 0
mmap(NULL, 2216336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7efd08f91000
mprotect(0x7efd08fad000, 2097152, PROT_NONE) = 0
mmap(0x7efd091ad000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7efd091ad000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 1837056, PROT_READ, 

Bug#932945: buster-pu: package passwordsafe/1.06+dfsg-1

[Bill Blough]

Package: release.debian.org
Severity: normal
Tags: buster
Usertags: pu

I would like to update passwordsafe in buster in order to fix
#932626.

As it stands, localization of the application is broken (only
English works) due to my mistake in installing the localization files
with an extra subdirectory in the path.

The only change is to move the localization files to the correct
directory, which based on the user report, and my own testing, resolves
the problem.

A debdiff is attached.

Thanks.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru passwordsafe-1.06+dfsg/debian/changelog 
passwordsafe-1.06+dfsg/debian/changelog
--- passwordsafe-1.06+dfsg/debian/changelog 2018-08-15 05:32:43.0 
-0400
+++ passwordsafe-1.06+dfsg/debian/changelog 2019-07-21 18:19:37.0 
-0400
@@ -1,3 +1,10 @@
+passwordsafe (1.06+dfsg-1+deb9u1) buster; urgency=medium
+
+  * Don't install localization files under an extra subdirectory.
+Closes: 932626
+
+ -- William Blough   Sun, 21 Jul 2019 18:19:37 -0400
+
 passwordsafe (1.06+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru passwordsafe-1.06+dfsg/debian/passwordsafe-common.install 
passwordsafe-1.06+dfsg/debian/passwordsafe-common.install
--- passwordsafe-1.06+dfsg/debian/passwordsafe-common.install   2018-08-15 
05:32:43.0 -0400
+++ passwordsafe-1.06+dfsg/debian/passwordsafe-common.install   2019-07-21 
18:19:37.0 -0400
@@ -1,4 +1,4 @@
 help/*.zip usr/share/passwordsafe/help
 install/graphics/pwsafe.png usr/share/icons/hicolor/48x48/apps
-src/ui/wxWidgets/I18N/mos usr/share/locale
+src/ui/wxWidgets/I18N/mos/* usr/share/locale
 xml/* usr/share/passwordsafe/xml

Bug#932944: stretch-pu: package passwordsafe/1.00+dfsg-1

[Bill Blough]

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

I would like to update passwordsafe in stretch in order to fix
#932626.

As it stands, localization of the application is broken (only
English works) due to my mistake in installing the localization files
with an extra subdirectory in the path.

The only change is to move the localization files to the correct
directory, which based on the user report, and my own testing, resolves
the problem.

A debdiff is attached.

Thanks.


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru passwordsafe-1.00+dfsg/debian/changelog 
passwordsafe-1.00+dfsg/debian/changelog
--- passwordsafe-1.00+dfsg/debian/changelog 2016-11-07 18:07:30.0 
-0500
+++ passwordsafe-1.00+dfsg/debian/changelog 2019-07-21 18:19:37.0 
-0400
@@ -1,3 +1,10 @@
+passwordsafe (1.00+dfsg-1+deb9u1) stretch; urgency=medium
+
+  * Don't install localization files under an extra subdirectory.
+Closes: 932626
+
+ -- William Blough   Sun, 21 Jul 2019 18:19:37 -0400
+
 passwordsafe (1.00+dfsg-1) unstable; urgency=medium
 
   * Change d/rules to eliminate depencdency on locales-all.  Thanks to
diff -Nru passwordsafe-1.00+dfsg/debian/passwordsafe-common.install 
passwordsafe-1.00+dfsg/debian/passwordsafe-common.install
--- passwordsafe-1.00+dfsg/debian/passwordsafe-common.install   2016-11-07 
18:07:30.0 -0500
+++ passwordsafe-1.00+dfsg/debian/passwordsafe-common.install   2019-07-21 
18:19:37.0 -0400
@@ -1,4 +1,4 @@
 help/*.zip usr/share/passwordsafe/help
 install/graphics/pwsafe.png usr/share/icons/hicolor/48x48/apps
-src/ui/wxWidgets/I18N/mos usr/share/locale
+src/ui/wxWidgets/I18N/mos/* usr/share/locale
 xml/* usr/share/passwordsafe/xml

Bug#932626: passwordsafe-common: It's not possible to switch to a non-english locale via Manage->Select Language

[Bill Blough]

Hi Sergei,

Thanks for reporting this.  I will upload the fix soon.

Bill

Bug#924787: Bug#926556: unblock: yubikey-personalization/1.19.3-3

[Bill Blough]

It appears that the needed changes are located in Salsa [1], and that the
release was prepared but not uploaded (since it's nowhere to be found).

This package is team maintained, and since it's not clear to me if the
rest of the team is aware of this issue, I'm CC'ing the team address in
this message.

If there's no response from nicoo or the rest of the team, I would like to go
ahead with an NMU, assuming that's permissible under these circumstances.


[1] 
https://salsa.debian.org/auth-team/yubikey-personalization/commits/debian/master



-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#914257: Update

[Bill Blough]

This is taking a little longer than expected due to various factors,
both technical and non-technical.  That said, packaging work is still ongoing,
albeit slowly.

Bug#926907: unblock: python-django-casclient/1.2.0-2.2

[Bill Blough]

On Sun, Apr 14, 2019 at 01:02:55PM +0100, Jonathan Wiltshire wrote:
> On Thu, Apr 11, 2019 at 09:37:03PM -0400, William Blough wrote:
> 
> I do not comment on your proposed fix, but I do question the value of
> including this package in buster at all. If it is broken with Django
>  >=1.10, doesn't that mean the bug affects stable too and nobody has
> noticed all this time?

That would appear to be the case.  Popcon only reports about a dozen
installs, so it doesn't appear to be widely used.  The only assumptions
I can make are that the people with it installed either aren't using it,
or are using it with an older version of Django.  Or maybe they
installed it, discovered that it didn't work, and installed a newer
version via pip instead (which admittedly is a wild guess - no evidence
one way or the other).  Regardless, I agree the numbers are low.

> 
> Besides that it has had just one other upload since it was first in the
> archive, which was also an NMU. What are the plans for its long-term
> maintenance if it is indeed included in buster?

With Stanford's WebAuth now EOL, one of the projects I work on at my
employer is moving from WebAuth to CAS for SSO.  I already maintain
python-django-cas-server under the umbrella of the Python Modules Team,
and my intent is to also supply whatever support is needed for
python-django-casclient.

Unfortunately, I noticed the state of the package too late to get
everything in top shape in time for buster, but I would like to get this
particular fix uploaded to stable in the next point release, as well as
get the package updated to the latest upstream release for inclusion in
backports and Bullseye.

I plan to discuss co-maintenance and/or adoption of the package with the
current maintainer in order to help make all of this happen.

Does this sound reasonable, or do you think I'm going down the wrong
path here?

Bug#926350: CAS middleware incompatible with Django >= 1.10

[Bill Blough]

Package: python3-django-casclient
Version: 1.2.0-2
Severity: grave
Tags: upstream patch

Due to middleware API changes in Django 1.10, django-cas-client 1.2 no
longer works (fails with an unhandled exception).  This currently
effects stable, testing, and unstable (oldstable used django 1.7).  So
unless a user upgraded from jessie but did *not* upgrade django, this
package is broken. (hence grave severity)

There is a fix upstream [1] that was applied as part of the 1.3.0
release.  I have tested the patch locally against 1.2.0 and it seems to
correct the issue without any side effects.  However I have not tested
it with versions of django < 1.10.

[1] 
https://patch-diff.githubusercontent.com/raw/kstateome/django-cas/pull/64.diff


I'd be willing to NMU the fix and file the unblock request if that is helpful.


-- System Information:
Debian Release: 9.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-django-casclient depends on:
ii  python3  3.5.3-1

python3-django-casclient recommends no packages.

Versions of packages python3-django-casclient suggests:
pn  python-django-cas-doc  

-- no debconf information

Bug#361954: [Pkg-ossec-devel] [Bug #361954] Any news?

[Bill Blough]

The others that were working on it stopped (I never asked why).  I'm
still interested in getting OSSEC-HIDS into Debian, but have limited
time right now, so unfortunately can't commit to it at this time.


On Thu, Jan 31, 2019 at 03:03:42PM +0100, Oliver Schraml wrote:
> Hi there,
> 
> quite a while since something happened on the ossec package request, is
> there still progress or are there still issues to deal with to get int
> ready?
> 
> 
> Many thanks and br
> 
> -- 
> 
> COBOL unser,
> das Du bist im Speicher,
> codiert werde Dein Filter,
> Dein Programm komme,
> Dein Statement geschehe,
> wie auf Band,
> so auch auf Platte;
> unsser täglich Putout gib uns heute,
> und vergib uns unsere Errors,
> wie wir vergeben unseren Technikern,
> und erlöse uns vom Assembler,
> denn Dein ist das Band,
> die Platte und die Zentraleinheit,
> in Ewigkeit,
> 
> -- 
> To unsubscribe, send mail to 361954-unsubscr...@bugs.debian.org.

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#884037: xalan: Xalan does not support building on hurd arch

[Bill Blough]

Thanks for the patch!

Bug#801727: pugixml: Please package pugixml variant with wchar enabled

[Bill Blough]

block 801727 by 911805
thanks

I looked at this a little back when we discussed it, but it looked like
it was going to take more time than I had right then, so I put it off.

I recently had time to dig into this properly, but have hit a snag.

After several hours of testing and tweaking, and reading cdbs files,
it appears that the multiple builds work under autotools, but not under
cmake.

I've opened  #911805 against cdbs requesting that this functionality be
added for cmake.  I think that rabbit hole is a little too deep for me
to go down myself right now.

Bug#911791: drupal7: DATE_RFC7231 already defined in PHP 7.0.19 and 7.1.5

[Bill Blough]

Will do.  Thanks.

Bug#801727: pugixml: Please package pugixml variant with wchar enabled

[Bill Blough]

On Mon, Jul 30, 2018 at 12:39:15PM +0200, Gianfranco Costamagna wrote:
> Hello,
> On Tue, 13 Oct 2015 18:30:15 -0400 William Blough  wrote:
> > Source: pugixml
> > Severity: wishlist
> > 
> > The passwordsafe package uses pugixml, but requires wchar to be enabled.  
> > If a
> > wchar enabled version (see pugiconfig.hpp) was included along side the 
> > current 
> > version, I could remove the embedded copy of pugixml from passwordsafe and
> > depend on the packaged version instead.
> > 
> 
> isn't this an ABI breaking change?

I'm not sure.  This is why I suggested a separate version which could be
marked as conflicting with the existing verison.  This would at least guarantee
that existing reverse dependencies wouldn't break.  I realize now that this
probably isn't a simple as it sounds.

> please check if reverse-dependencies still work with the same ABI versioning 
> and wchar enabled, and provide a patch to make a proper transition.
> I can help there, but I lack the time to do proper checks.

If it's an ABI change, that can be handled, but I'm worried about
non-ABI-related behavior changes breaking existing packages.  I can try
to test for some of those issues, but as I'm not familiar with any of the
reverse dependencies, I'm concerned I may miss edge cases.

That said, I'll look into it and see what I can figure out.

Thanks,

Bill

Bug#901092: passwordsafe FTCBFS: multiple reasons

[Bill Blough]

Thanks for the patch.  I will apply it soon, and also forward the
relevant parts upstream.

Bug#898296: RFS: passwordsafe/1.05+dfsg-2~bpo9+1 -- simple and secure password management

[Bill Blough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "passwordsafe".  Since it hasn't
yet been backported for strech, it must go through NEW.  However, I am a
DM with upload rights and I'm in the backports ACL. So after the initial
upload, I will be able to upload future backported versions myself.


  * Package name: passwordsafe
Version : 1.05+dfsg-2~bpo9+1
Upstream Author : Rony Shapiro <ro...@users.sf.net>
  * URL : https://pwsafe.org
  * License : Artistic 2.0
Section : utils

It builds those binary packages:

passwordsafe - Simple & Secure Password Management
passwordsafe-common - architecture independent files for Password Safe

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/passwordsafe


Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_1.05+dfsg-2~bpo9+1.dsc

More information about passwordsafe can be obtained from https://www.pwsafe.org

Changes since the last upload:

 passwordsafe (1.05+dfsg-2~bpo9+1) stretch-backports; urgency=medium
 .
   * Rebuild for stretch-backports.
 .
 passwordsafe (1.05+dfsg-2) unstable; urgency=medium
 .
   * Fix build issue that causes help files to not be found by the program
 due to a mixed release/debug build (patch forwarded)
 .
 passwordsafe (1.05+dfsg-1) unstable; urgency=medium
 .
   * New upstream release
   * Remove patches applied upstream
   * Update standards to version 4.1.4 (no changes)
 .
 passwordsafe (1.04+dfsg-2) unstable; urgency=medium
 .
   * Fixes for big-endian architectures (forwarded).
 .
 passwordsafe (1.04+dfsg-1) unstable; urgency=medium
 .
   * New upstream release
   * Remove patch applied upstream
   * Update standards version to 4.1.3
 - Adjust perl shebangs
   * Update dh compat to 11
 .
 passwordsafe (1.03+dfsg-2) unstable; urgency=medium
 .
   * Add patch to fix test failure on 32-bit systems (forwarded)
 .
 passwordsafe (1.03+dfsg-1) unstable; urgency=medium
 .
   * Update upstream signing key
   * New upstream version
   * Refresh quilt patches
   * Update standards version to 4.1.1
 - change copyright format URL to HTTPS
   * Lintian fixes
 - Override false positive spelling error
 - Enable hardening flags
   * Update dh compat to 10


Regards,
Bill Blough

Bug#897582: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#897582: RFS: xalan/1.11-7)

[Bill Blough]

On Tue, May 08, 2018 at 12:51:05AM +, Debian Bug Tracking System wrote:
> Date: Tue, 8 May 2018 02:49:25 +0200
> From: Adam Borowski 
> 
> One quite visible change is that the location of documentation has changed. 
> This might be interesting to the user.
> 
> Uploaded.
> 

To be honest, I missed that.  I need to make sure I don't forget to use
debdiff in the future.

Though it looks like it wasn't the documentation, but rather the
examples, that moved from the -doc to the -dev package.  It wasn't a
change that I made, but rather, looks like fallout from going to dh
compat 11.

I'll do another upload to fix it.  Thanks for pointing it out.  And
thanks for your upload, and for giving me permissions.

Best regards,
Bill

Bug#897582: RFS: xalan/1.11-7

[Bill Blough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor and/or someone to grant upload permissions
(I am a DM) for my package "xalan".

 * Package name: xalan
   Version : 1.11-7
   Upstream Author : The Apache Software Foundation
 * URL : https://xalan.apache.org/xalan-c/index.html
 * License : Apache 2.0
   Section : text

It builds those binary packages:

  libxalan-c-dev - XSLT processor library for C++ [development]
  libxalan-c-doc - XSLT processor library for C++ [development docs]
  libxalan-c111 - XSLT processor library for C++
  xalan - XSLT processor utility

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xalan


Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xalan/xalan_1.11-7.dsc

More information about hello can be obtained from 
https://xalan.apache.org/xalan-c/index.html

Changes since the last upload:

  * Add makefile dependencies to fix parallel builds. Closes: #849344
  * Upgrade to dh compat 11
  * Update to standards version 4.1.4
- Update copyright format link to use https
  * Lintian fixes
- Remove trailing whitespace from changelog
- Switch d/watch to use https
- Fix NOTICE file issues
- Remove unused override

Best regards,
Bill Blough


signature.asc
Description: PGP signature

Bug#896940: stretch-pu: package xerces-c/3.1.4+debian-2

[Bill Blough]

Uploaded.  Thanks!

On Sat, Apr 28, 2018 at 08:30:02PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2018-04-26 at 03:17 -0400, William Blough wrote:
> > I would like to update xerces-c in a future point release.  This
> > update
> > will fix two issues:
> > 
> >   * Fix CVE-2017-12627: Alberto Garcia, Francisco Oca and Suleman Ali
> > of
> > Offensive Research discovered that the Xerces-C XML parser
> > mishandles
> > certain kinds of external DTD references, resulting in
> > dereference of a
> > NULL pointer while processing the path to the DTD. The bug allows
> > for a
> > denial of service attack in applications that allow DTD
> > processing and do
> > not prevent external DTD usage, and could conceivably result in
> > remote code
> > execution.
> >   * Fix a regression that forced gcc to use SSE2, even on platforms
> > that do not
> > support it (e.g., i386).  This caused program crashes due to
> > invalid CPU
> > instructions.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Bug#896942: jessie-pu: package xerces-c/3.1.1-5.1+deb8u3

[Bill Blough]

Uploaded.  Thanks!

Bug#895068: xerces-c: baseline violation on i386' from 'freecad does not start : "Illegal Instruction" returned

[Bill Blough]

The fix for stable has been uploaded to proposed-updates, and should be
included in the next point release.  Oldstable was not affected by this
bug, so nothing was needed there.

Bug#895068: xerces-c: baseline violation on i386' from 'freecad does not start : "Illegal Instruction" returned

[Bill Blough]

My apologies for this - this is my fault.

I'm about to upload the fix to unstable, and will submit an update for
for stable and oldstable to hopefully be included in the next point
release.

Bill

Bug#894050: Reopening

[Bill Blough]

While this is fixed for unstable/testing, the security team has informed
me that there will be no DSA for this issue for stable/oldstable.

As such, I'm reopening this until stable/oldstable can be updated via a
point release.

Bug#888887: passwordsafe FTBFS on big endian: test failures

[Bill Blough]

I have uploaded passwordsafe-1.04+dfsg-2 which fixes the failures on all
big endian archs except for alpha and sparc64.

While those are not offically supported archs, if I can get access to a
porterbox for them, I will try to resolve those remaining issues, also.

Bug#888887: passwordsafe FTBFS on big endian: test failures

[Bill Blough]

Thanks for your report.

I have been looking at this exact issue recently.

I've gotten some of the tests to pass by fixing a lot of the more
straightforward issues, but there are some problems that may require
more invasive changes.

As such, I want to work with upstream to figure out the best approach
for those.

I don't have a timeline for the fix yet, but it is being actively  worked on.

Bug#881920: xerces-c: FTBFS on hurd-i386: ThreadTest15 failed

[Bill Blough]

After running the tests in a loop for many hours, I have encountered 2
issues.

The first is an assertion failure in ext2fs that causes the entire
system to freeze (#882507).  Based on the build log, this isn't the
issue in question, but it's definitely a problem (and it made
troubleshooting much more frustrating).

The second is an exception being thrown due to a call to getcwd()
failing.  I believe that this is the issue that caused the test failure
referenced in the build log.  However, getcwd is returning "No such file
or directory" but the directory clearly exists, and as such, I'm not sure how
this is happening.  I'm wondering if this is somehow related to the
ext2fs issues, or maybe load-related.

I've requested a binNMU for xerces-c on hurd to see what happens.

Bug#882507: ext2fs: assertion error

[Bill Blough]

Apologies for that. I somehow missed the newer image.

I just tried debian-hurd-20171101.img and got the exact same behavior -
same error message, freeze, etc.

Bug#882507: ext2fs: assertion error

[Bill Blough]

Package: hurd
Version: 1:0.9.git20170507-1
Severity: normal

Running debian-hurd-20170613.img under KVM, I'm frequently getting the
following assertion error:

ext2fs: ../../libshouldbeinlibc/refcount.h:171 refcounts_ref: Assertion
'! (r.hard == 1 && r.weak == 0) || !"refcount detected use-after-free!"'
failed.

This seems to happen randomly when doing package builds, etc., and
causes the entire system to freeze, requiring hard reboot of the VM,
fsck, etc.


-- System Information:
Debian Release: 9.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.8+git20170609-486/Hurd-0.9
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.9.git20170507-1
ii  libblkid1 2.29.2-1
ii  libbz2-1.01.0.6-8.1
ii  libc0.3   2.24-11
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20161126-1
ii  libtinfo5 6.0+20161126-1
ii  libx11-6  2:1.6.4-3
ii  lsb-base  9.20161125
ii  netdde0.0.20150828-4
ii  sysv-rc   2.88dsf-59.9
ii  xkb-data  2.19-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages hurd recommends:
ii  bf-utf-source  0.07

Versions of packages hurd suggests:
pn  hurd-doc  

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='true'
DISPLAY='-d vga --font-width=9'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'


-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#881114: (no subject)

[Bill Blough]

Apologies - I got my steps out of order. I should have waited to bump
the severities until my RFS had been processed, instead of when I issued
the RFS.

As it stands, xerces-c3.2 has been uploaded, and the only issue is
related to a xerces failure on hurd arch.  I am reducing serverity to
important, but would like to leave this open until the hurd issue is
resolved.

Bug#881920: xerces-c: FTBFS on hurd-i386: ThreadTest15 failed

[Bill Blough]

That's very odd, as it built ok when it was uploaded to experimental, and the 
only change for unstable was the version bump.

I'll definitely look into it.

Bug#881127: transition: xerces-c

[Bill Blough]

The package has been uploaded to unstable and the severities bumped.

Thanks.

Bug#881363: RFS: xerces-c/3.2.0+debian-2

[Bill Blough]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor and/or someone to grant upload permissions (I am
  a DM) for my package "xerces-c"

  NOTE: This is the unstable upload for a SONAME transition.  The package has
  already been uploaded to experimental and upload to unstable has been
  approved.  The transition bug is viewable at the following URL -

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

 * Package name: xerces-c
   Version : 3.2.0+debian-2
   Upstream Author : Apache Xerces Team
 * URL : https://xerces.apache.org/xerces-c
 * License : Apache 2.0
   Section : libs

  It builds those binary packages:

libxerces-c-dev - validating XML parser library for C++ (development files)
libxerces-c-doc - validating XML parser library for C++ (documentation)
libxerces-c-samples - validating XML parser library for C++ (compiled 
samples)
libxerces-c3.2 - validating XML parser library for C++

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xerces-c


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/x/xerces-c/xerces-c_3.2.0+debian-2.dsc

  More information about xerces-c can be obtained from 
https://xerces.apache.org/xerces-c

  Changes since the last upload:

* Upload to unstable


  Regards,
   Bill Blough



signature.asc
Description: PGP signature

Bug#879696: RFS: xerces-c/3.2.0+debian-1

[Bill Blough]

Done.  Thanks.

On Wed, Oct 25, 2017 at 09:08:22PM +0200, Tobias Frost wrote:
> Control: tags -1 moreinfo
> 
> Hi Bill,
> 
> On Tue, Oct 24, 2017 at 02:17:03PM -0400, Bill Blough wrote:
> 
> >   NOTE:  Due to the SONAME change, this will require a transition.  
> > Therefore
> >   this this package should be uploaded to experimental rather than unstable.
> 
> The changelog says "unstable", so you want to fix that and reupload
> to mentors.
> 
> Please let me know when ready!
> 
> --
> tobi 

Bug#879744: RFS: passwordsafe/1.03+dfsg-2 [RC]

[Bill Blough]

Package: sponsorship-requests
Severity: important

  Dear mentors,

  I am looking for a sponsor and/or someone to grant upload permissions 
  (I am a DM) for my package "passwordsafe"


 * Package name: passwordsafe
   Version : 1.03+dfsg-2
   Upstream Author : Rony Shapiro <ro...@users.sf.net>
 * URL : https://pwsafe.org/
 * License : Artistic 2.0
   Section : utils

  It builds those binary packages:

passwordsafe - Simple & Secure Password Management
passwordsafe-common - architecture independent files for Password Safe

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/passwordsafe


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_1.03+dfsg-2.dsc

  More information about passwordsafe can be obtained from  https://pwsafe.org/

  Changes since the last upload:

  * Add patch to fix test failure on 32-bit systems (forwarded)

  Regards,
   Bill Blough


signature.asc
Description: PGP signature

Bug#879696: RFS: xerces-c/3.2.0+debian-1

[Bill Blough]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor and/or someone to grant upload permissions 
  (I am a DM) for my package "xerces-c"

  NOTE:  Due to the SONAME change, this will require a transition.  Therefore
  this this package should be uploaded to experimental rather than unstable.


 * Package name: xerces-c
   Version : 3.2.0+debian-1
   Upstream Author : Apache Xerces Team
 * URL : https://xerces.apache.org/xerces-c/
 * License : Apache 2.0
   Section : libs

  It builds those binary packages:

libxerces-c-dev - validating XML parser library for C++ (development files)
libxerces-c-doc - validating XML parser library for C++ (documentation)
libxerces-c-samples - validating XML parser library for C++ (compiled 
samples)
libxerces-c3.2 - validating XML parser library for C++

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xerces-c


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/x/xerces-c/xerces-c_3.2.0+debian-1.dsc

  More information about xerces-c can be obtained from  
https://xerces.apache.org/xerces-c/

  Changes since the last upload:

  * New upstream version
  * Update to policy 4.1.1
- Change d/copyright Format URL to use https
  * Remove patches that have been applied upstream
  * Set dh compat to 10
  * Patch: Fix test failures for parallel builds (forwarded)

  Regards,
   Bill Blough


signature.asc
Description: PGP signature

Bug#873669: xerces-c: New upstream release 3.2.0

[Bill Blough]

> Have you got any ETA for the Xerces 3.2 packages?  They would make my life
> easier, even if experimental only.

I have the packaged prepared.  I'll need to find a sponsor to upload it
to experimental so I can start the necessary steps for the SONAME
transition.  I'll send out an RFS today.  Thanks for the reminder.


> Please consider https://issues.apache.org/jira/browse/XERCESC-2122 if
> you decide to use the CMake build system.

Because of that issue as well as some others, I decided to stay with the
autotools build until the CMake build has had time to be tested more.
But I will definitely keep it in mind for the future.

Bug#879651: RFS: passwordsafe/1.03+dfsg-1

[Bill Blough]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor and/or someone to grant me upload permissions
  (I am a DM) for my package "passwordsafe".

 * Package name: passwordsafe
   Version : 1.03+dfsg-1
   Upstream Author : Rony Shapiro <ro...@users.sf.net>
 * URL : https://pwsafe.org
 * License : Artistic-2.0
   Section : utils

  It builds those binary packages:

passwordsafe - Simple & Secure Password Management
passwordsafe-common - architecture independent files for Password Safe

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/passwordsafe


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_1.03+dfsg-1.dsc

  More information about passwordsafe can be obtained from https://pwsafe.org

  Changes since the last upload:

  * Update upstream signing key
  * New upstream version
  * Refresh quilt patches
  * Update standards version to 4.1.1
- change copyright format URL to HTTPS
  * Lintian fixes
- Override false positive spelling error
- Enable hardening flags


  Regards,
   Bill Blough



signature.asc
Description: PGP signature

Bug#873669: xerces-c: New upstream release 3.2.0

[Bill Blough]

Thanks for your report.  I'm currently on vacation, but will work on
updating the package as soon as I return.

Bug#801727: pugixml: Please package pugixml variant with wchar enabled

[Bill Blough]

On Tue, Jul 11, 2017 at 08:40:53PM +0530, Vasudev Kamath wrote:
> Hey William,
> 
> Very very sorry about such a delayed response.

No worries.

> 
> William Blough  writes:
> 
> > Source: pugixml
> > Severity: wishlist
> >
> > The passwordsafe package uses pugixml, but requires wchar to be enabled.  
> > If a
> > wchar enabled version (see pugiconfig.hpp) was included along side the 
> > current 
> > version, I could remove the embedded copy of pugixml from passwordsafe and
> > depend on the packaged version instead.
> 
> Is it OK to enable this in default version itself instead of creating
> one more version?. Will it create any problems?.

It would be fine for my use case, but I don't know how it would affect
other users.  I'm thinking it would probably be fine, as a nonwide char
should fit in a wide char.  But I don't really work with wide charsets
that much, so my intuition may be wrong.

Bug#866047: ITP: factorio-server -- headless server for the game Factorio

[Bill Blough]

On Mon, Jun 26, 2017 at 07:27:23PM -0400, Justin Gerhardt wrote:
> 
> games. Community efforts have so far created distributions for Docker,
> Ansible and a number of cloud offerings. I beleive adding a package
> for Debian and its derivatives would benefit many users though
> easier updates and init system intergration. 

The docker and ansible versions that I looked at all download the
factorio server executable from factorio.com when run.  So they're not
packaging/redistributing the server, just automatically downloading and
installing it.

I didn't see anything on the Factorio website or in the server tarball
that says redistribution is OK.  So unless you can find something
official showing permission to redistribute, you would need to do
something similar - package an installer that downloads the package and
installs it, then add your init script, etc., as part of that package.

> 
> This is my first time creating a package. I intent to the best
> of my abilities maintain it myself. It should be simple enough not to
> require a comaintainer. I will need a sponsor for the ultimate inclusion 
> in the non-free repo games section. 

If you can get permission to redistribute, I believe non-free is
correct.  If you wind up creating an installer package, then it could
pontentially go in contrib instead, depending on licensing.

Bug#850562: passwordsafe: Package 1.00 in jessie-backports

[Bill Blough]

The package has been uploaded and will soon be available in
jessie-backports.

Closing.

Bug#850562: passwordsafe: Package 1.00 in jessie-backports

[Bill Blough]

Resending to BTS due to addressing mistake on my part

On Tue, Jan 10, 2017 at 09:36:07PM -0500, Bill Blough wrote:
> On Mon, Jan 09, 2017 at 11:17:46AM +0300, Sergei Golovan wrote:
> > 
> > I'll be glad to sponsor the backport upload for you.
> > 
> 
> Excellent, thanks!
> 
> I've prepared the backport package and have uploaded it to mentors.d.n:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_1.00+dfsg-1~bpo8+1.dsc
> 
> 
> Please let me know if you see any issues with it.
> 
> Cheers,
> Bill

Bug#850562: passwordsafe: Package 1.00 in jessie-backports

[Bill Blough]

Hi Sergei,
`
Since you were nice enough to backport the version of passwordsafe
that's currently in jessie-backports, I figured I would reach out to you
directly before trying alternative methods.

On Sat, Jan 07, 2017 at 11:30:31AM -0800, Bill Wohler wrote:
> Package: passwordsafe
> Version: 0.98.1+dfsg-3~bpo8+1
> Severity: normal
> 
> I see version 1.00+dfsg-1 has been packaged on stretch. Would it be
> possible to package this in jessie-backports as well?

Would you also be willing to backport the version that's in stretch in
order to satisfy the above user request?  Or if you'd prefer, I can
prepare the backport package if you would be willing to sponsor/upload it.

My DM applicaiton is still pending approval, but in the future I hope to be
able to handle these requests myself.

Best regards,
Bill

Bug#848867: RFS: xalan/1.11-6

[Bill Blough]

On Wed, Dec 21, 2016 at 07:05:52AM +, Gianfranco Costamagna wrote:
> Hi
> 
> 
> a quick look seems to show a progress when removing debian/autoreconf file.
> http://debomatic-amd64.debian.net/distribution#unstable/xalan/1.11-6.1/buildlog
> G.

Yes, it looks like using debian/autoreconf with --sourcedirectory causes
autoreconf to get called on/from (depending on your perspective) the
wrong directory.

Thanks for looking at it.  Now I just need to figure out why the build
is failing.  I hope to have some time later today.

Bug#848867: RFS: xalan/1.11-6

[Bill Blough]

On December 20, 2016 4:19:01 PM EST, Tobias Frost  wrote:

>Uploaded!
>
>Tobi

Thanks!

Bug#848867: RFS: xalan/1.11-6

[Bill Blough]

On December 20, 2016 8:01:28 AM EST, Gianfranco Costamagna 
 wrote:

>
>what about bumping compat/debhelper level to 10, remove autoreconf from
>rules/control
>file?
>
>G.

That's causing the build to fail for some reason. I'll look into it.

Bill

Bug#848867: RFS: xalan/1.11-6

[Bill Blough]

Package: sponsorship-requests
Severity: normal

I am looking for a sponsor for my package "xalan"

 * Package name: xalan
   Version : 1.11-6
   Upstream Author : Steven J. Hathaway <shatha...@apache.org>
 * URL : https://xalan.apache.org/xalan-c/index.html
 * License : Apache-2.0
   Section : text

 It builds those binary packages:

 libxalan-c-dev - XSLT processor library for C++ [development]
 libxalan-c-doc - XSLT processor library for C++ [development docs]
 libxalan-c111 - XSLT processor library for C++
 xalan - XSLT processor utility

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xalan


  Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xalan/xalan_1.11-6.dsc

  More information about xalan can be obtained from 
https://xalan.apache.org/xalan-c/index.html

  Changes since the last upload:

  * Update makefiles to honor CPPFLAGS
  * Remove lintian override for hardening flags
  * Update standards version to 3.9.8 (no changes)
  * Remove autotools-dev dependency due to using dh-autoreconf
  * Add bindnow hardening flag
  * Add lintian override for doxygen's copy of jquery
  * Build in release mode instead of debug mode.  This works around
the assertion error reported in bug 783173.
  * Remove and symlink duplicate files in examples (lintian fix)


  Regards,
   Bill Blough


signature.asc
Description: Digital signature

Bug#783173: xalan-c-dev: xalan-c assert falure in XalanSourceTreeDocument::createAttributes

[Bill Blough]

tags 783173 + fixed
thanks

--

This problem exists in upstream, but it's not apparent because
assertions are disabled in the upstream build.  Reenabling assertions
in the upstream build causes it to fail in the same way. Likewise,
disabling assertions in the Debian build allows it to work as expected.

As such, I will disable assertions in the Debian build to work around
this, and I will forward the info upstream.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

Since compiling with -O1 works, I'm tagging this as fixed, and will
continue to try to find the root cause.  I was going to submit an
unblock for 819530, but wasn't sure if was appropriate for me to be
the one to do it.

Gianfranco and Mattia, thanks very much for your help.  I wouldn't have
been able to make much progress without it.  I sincerely appreciate it.

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

I've prepared a new package and uploaded it to mentors:

https://mentors.debian.net/debian/pool/main/x/xerces-c/xerces-c_3.1.4+debian-2.dsc


If someone wants to test and/or upload it, I would appreciate it.

Note: I didn't put an entry to close this bug because I intend to
retitle it, lower the severity, and still look for a cause/fix.  This
seems better to me than closing the bug and opening a new one for follow
up.


Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Fri, Dec 16, 2016 at 08:25:02AM +, Gianfranco Costamagna wrote:
> Hi,
> 
> 
> >export DEB_BUILD_MAINT_OPTIONS=noopt
> 
> >
> >to the top of d/rules and rebuilding should do it.
> 
> 
> it worked:
> DEB_BUILD_OPTIONS=noopt dpkg-buildpackage
> 
> [...]
> 

Interesting.  Under the emulator some of the floating point tests fail.
But it is an emulator, so maybe it's not perfect.

I also compared compiler defaults between Ubuntu and Debian, and tried
some other flags and settings that might be relevant, but so far I
haven't found anything else that's helpful.

I'd still like to find the root cause and fix it, but in the interest of
getting it solved before the freeze, I'd like to build the s390x
package with O1 and continue building the rest of the archs with O2.

If there are no objections, I can have a package ready for upload later
today.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On a whim, I decided to install the Hercules s390 emulator and see if I
could reproduce the problem there.  It's slow (4+ hours to do a build of
xerces) but it appears to work, and the issue shows up there as well.

I started trying to trace down the memory issue in real time, but the
variables I needed to inspect had been optimized out.  As it turns out,
building with reduced/no optimization (I tested both -O1 and -O0) allows
all of the tests to pass except for one (XSValueTest).  Can someone
please confirm this on the porterbox?

Adding

export DEB_BUILD_MAINT_OPTIONS=noopt

to the top of d/rules and rebuilding should do it.

Thanks!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Wed, Dec 14, 2016 at 07:11:12AM +, Gianfranco Costamagna wrote:
> 
> >So while I'm not sure it will help, there might be benefit to try to get a
> >stack trace from DOMCount.  It's possible there's an exception being
> >thrown but it's getting caught/squashed.  If someone wants to try to get
> >a stack trace, the command will be
> >
> >libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml
> >
> >and the steps inside of gdb will be the same as before.
> 
> 
> 
> http://paste.debian.net/902113/
> 
> G.


Segfault trying to read from a buffer...  That goes along well with what
I saw in the previous program, and makes me think I'm on the right track.

Thanks!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Tue, Dec 13, 2016 at 11:15:26PM +, Gianfranco Costamagna wrote:
> 
> http://paste.debian.net/902086/
> 
>  ^^ this is the file you requested
> 
> G.

That's great.  As I had hoped, ignoring that exception allows SAXCount
to complete successfully, and with the expected output (despite the
possible memory leak and/or corruption that is still an issue).

It now appears to be failing later in the test process. This time
there's no exception terminating the program, rather, it's just not
printing what it's supposed to be printing.

Although, SAXCount should have caught and handled the exception we saw
there, but somehow it skipped the handler and terminated the program
rather than being caught and handled.

So while I'm not sure it will help, there might be benefit to try to get a
stack trace from DOMCount.  It's possible there's an exception being
thrown but it's getting caught/squashed.  If someone wants to try to get
a stack trace, the command will be

libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml

and the steps inside of gdb will be the same as before.


In the mean time, I'll dig back into the source.

Thanks!

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Tue, Dec 13, 2016 at 12:06:46PM +, Gianfranco Costamagna wrote:
> Hi
> 
> 
> >Based on the stack trace, the exception is thrown because a managed
> 
> >buffer that is being freed isn't actually registered to the buffer manager.
> >his shouldn't happen, since the only way to get a buffer is to request
> >it from the manager in the first place.  It's possible there's a memory
> >corruption bug somewhere.
> >
> >What I'd like to do is see what happens if the program doesn't abort at
> >that point.  Not freeing the buffer will lead to a memory leak, so it's
> >not a fix, but seeing what happens without the exception being thrown
> >could give useful data.
> >
> >The attached patch comments out the line that throws the exception,
> >causing the function to simply return.  This should let the program
> >continue running, hopefully producing useful output (whether correct or not).
> >
> >Could someone please apply the patch and rebuild?
> 
> 
> http://paste.debian.net/901967/
> 
> does this help?
> 
> G.

Was that the only exception?  If so, that exception gets thrown (and
handled) even on a successful run.  In which case, can you post the
test-results.log?

Bug#783173: xalan-c-dev: xalan-c assert falure in XalanSourceTreeDocument::createAttributes

[Bill Blough]

I haven't had much luck with this issue to date, but I've started looking at
it again in hopes that I can get it resolved.

I can still reproduce the problem with the information you provided.
However, I still see the issue when using the upstream version, too.

Can you provide the build settings/steps that you're using for the upstream
version?

Thanks!

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

Based on the stack trace, the exception is thrown because a managed
buffer that is being freed isn't actually registered to the buffer manager.
This shouldn't happen, since the only way to get a buffer is to request
it from the manager in the first place.  It's possible there's a memory
corruption bug somewhere.

What I'd like to do is see what happens if the program doesn't abort at
that point.  Not freeing the buffer will lead to a memory leak, so it's
not a fix, but seeing what happens without the exception being thrown
could give useful data.

The attached patch comments out the line that throws the exception,
causing the function to simply return.  This should let the program
continue running, hopefully producing useful output (whether correct or not).

Could someone please apply the patch and rebuild?

Thanks,
Bill

diff --git a/src/xercesc/framework/XMLBufferMgr.cpp b/src/xercesc/framework/XMLBufferMgr.cpp
index 327f8de..2068233 100644
--- a/src/xercesc/framework/XMLBufferMgr.cpp
+++ b/src/xercesc/framework/XMLBufferMgr.cpp
@@ -108,7 +108,7 @@ void XMLBufferMgr::releaseBuffer(XMLBuffer& toRelease)
 }
 
 // It was not a legal buffer
-ThrowXMLwithMemMgr(RuntimeException, XMLExcepts::BufMgr_BufferNotInPool, fMemoryManager);
+//ThrowXMLwithMemMgr(RuntimeException, XMLExcepts::BufMgr_BufferNotInPool, fMemoryManager);
 }
 
 XERCES_CPP_NAMESPACE_END

Bug#847004: RFS: soci/3.2.3-2

[Bill Blough]

On Mon, Dec 12, 2016 at 03:07:28AM +0500, Andrey Rahmatullin wrote:
> On Sun, Dec 11, 2016 at 12:03:56PM -0500, Bill Blough wrote:
> > > - Please remove the -dbg package in favour of the automatic dbgsym
> > > packages (https://wiki.debian.org/DebugPackage)
> > 
> > Done.
> Note that you cannot just drop -dbg if you had them, you must use dh_strip
> --dbgsym-migration option.
> 

Yes, that's exactly what I did.

Cheers,
Bill

Bug#847004: RFS: soci/3.2.3-2

[Bill Blough]

On Sun, Dec 11, 2016 at 09:59:22PM +0100, Tobias Frost wrote:
> 
> I did an test, seems so that adding this to d/rules would also have
> fixed it:
> 
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
> export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed

Interesting.  I was under the impression that bindnow was part of the default 
flags for dh/dpkg-buildflags, otherwise Lintian wouldn't be flagging it.
But I guess not.

Thanks for testing it!  I'll update it for the next upload.

> 
> Uploaded!
> Many thanks for your contribution!

Excellent, thank you!

Best regards,
Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

> 
> It still fails the very same way.
> Attached the backtrace I get with the way you said above (without
> exporting anything).  It seems to really be full, what Gianfranco posted
> looks more like the non-full/regular bt, dunno why.

Thanks.  Disregard my other email.

GDB didn't find the debug symbols for the other backtrace, but for yours
it did.  This could help.

Thanks,
Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 07:43:08PM +0100, Mattia Rizzolo wrote:
> On Sun, Dec 11, 2016 at 01:34:18PM -0500, Bill Blough wrote:
> > I just found a reference in the Debian Maintainer's Guide that says the
> > default build locale is C.  And it looks like the Ubuntu build is
> > explicitly setting a locale of C.UTF-8.
> 
> Where is that?

I misspoke, it's not the Debian Maintainer's Guide, but the "Guide for
Debian Maintainers"

https://www.debian.org/doc/manuals/debmake-doc/ch07.en.html#utf-8-build

> Really, in Debian there is no "default build locale", and I've seen RC
> bugs for packages failing to build in non-C locales.
> See also the Reproducible Builds project, which is making sure packages
> built in different locales are always the same.

The link above says

  The default locale of the build environment is C

I certainly agree that we shouldn't be using arbitrary locales, but here
I'm talking about using C.UTF-8, which the above link says should be
used when necessary.


> 
> > Would you be willing to add
> > 
> > LC_ALL := C.UTF-8
> > export LC_ALL
> > 
> > to the top of debian/rules and try another build?
> 
> running.
> 

Thanks very much.

Bill

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 06:20:13PM +, Mattia Rizzolo wrote:
> anyhow, 1) build should not depend on the locale it runs
I'll admit, I don't know a lot about locales, etc., but some of the
tests use files in UTF-8.  Wouldn't that generally require UTF-8 support
from the locale?

> 2) afaik it isn't any different than other archs
Yes, that's true, but I've seen arch-dependent locale issues in the
past.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On Sun, Dec 11, 2016 at 05:57:38PM +, Gianfranco Costamagna wrote:
> Hi,
> 
> >Does anyone know (or can find out) the default locale on the s390
> >systems, and does that differ from the other architectures?
> >
> >env | egrep "(LC|LANG)"
> >
> >should give a list of relevant vars.
> 
> 
> (not sure if it is related to my laptop configuration, I did ssh and 
> copy-pasted)
> 
> locutusofborg@zelenka:~$ uname -a
> Linux zelenka 3.16.0-4-s390x #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) 
> s390x GNU/Linux
> locutusofborg@zelenka:~$ env | egrep "(LC|LANG)"
> LC_PAPER=it_IT.UTF-8
> LC_ADDRESS=it_IT.UTF-8
> LC_MONETARY=it_IT.UTF-8
> LC_NUMERIC=it_IT.UTF-8
> LC_TELEPHONE=it_IT.UTF-8
> LC_IDENTIFICATION=it_IT.UTF-8
> LANG=en_US.UTF-8
> LC_MEASUREMENT=it_IT.UTF-8
> LC_TIME=it_IT.UTF-8
> LC_NAME=it_IT.UTF-8
> 

Hmm... That must be set by ssh based on your local environment.

I just found a reference in the Debian Maintainer's Guide that says the
default build locale is C.  And it looks like the Ubuntu build is
explicitly setting a locale of C.UTF-8.

I've run into locale-related issues that affected one architecture but not
others (though it was i386 vs amd64 in that case), and since we're
dealing with an ICU update, and the runtime exception is dealing with a
bad buffer (which could mean there was a buffer, but it was the
incorrect size), I'm thinking this could be locale related. But
admittedly, it's a shot in the dark.

Would you be willing to add

LC_ALL := C.UTF-8
export LC_ALL

to the top of debian/rules and try another build?  Or I could prepare
another package with the changes if you'd rather not muck with editing
files.

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

Does anyone know (or can find out) the default locale on the s390
systems, and does that differ from the other architectures?

env | egrep "(LC|LANG)"

should give a list of relevant vars.

Thanks,
Bill