Bug#1037251: new version

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

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

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

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

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

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

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

Bug#914257:

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

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

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

Bug#983365: linphone-desktop: chat messages

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)

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

Bug#983365: linphone-desktop: chat messages

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

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

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

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

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

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)

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

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.

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

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

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

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

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

es, 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

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

Looks good to me. Thanks.

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

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

sue? > > 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 curr

Bug#975600: New upstream release 1.12.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/chang

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

Uploaded, thanks. For reference, the buster-pu request is 932945.

Bug#932947: (no subject)

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

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

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

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

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

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

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

Hi Sergei, Thanks for reporting this. I will upload the fix soon. Bill

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

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

Bug#914257: Update

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

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

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

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

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

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

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

Thanks for the patch!

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

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

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

Will do. Thanks.

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

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

Bug#901092: passwordsafe FTCBFS: multiple reasons

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

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

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

Bug#897582: RFS: xalan/1.11-7

ds 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

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: > > > >   *

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

Uploaded. Thanks!

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

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

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

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

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

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

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

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

Bug#882507: ext2fs: assertion error

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

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

Bug#881114: (no subject)

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

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

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

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

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

he 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 Regard

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

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 tra

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

safe_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

* 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

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

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

PS * 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

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

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

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

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

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

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

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

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,

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

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:

Bug#848867: RFS: xalan/1.11-6

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

Bug#848867: RFS: xalan/1.11-6

On December 20, 2016 4:19:01 PM EST, Tobias Frost wrote: >Uploaded! > >Tobi Thanks!

Bug#848867: RFS: xalan/1.11-6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug#847004: RFS: soci/3.2.3-2

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

Bug#847004: RFS: soci/3.2.3-2

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 :=

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

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

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

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

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

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

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

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

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

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

  1   2   >