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 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
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). 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:
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 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
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 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
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
> > 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
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. 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
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
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
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
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
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
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
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
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
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
>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
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
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
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
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
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
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 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
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
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
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 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
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 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
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?
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
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 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
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 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
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
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)
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
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
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
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 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
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
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 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)
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
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
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
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]
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
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
> 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
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
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 Bloughwrites: > > > 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
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
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, 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
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
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
On December 20, 2016 4:19:01 PM EST, Tobias Frostwrote: >Uploaded! > >Tobi Thanks!
Bug#848867: RFS: xalan/1.11-6
On December 20, 2016 8:01:28 AM EST, Gianfranco Costamagnawrote: > >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
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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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