Bug#983365: linphone-desktop: chat messages

[Bill Blough]

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

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

Bug#983365: (no subject)

[Bill Blough]

Hi Dennis,

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

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

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

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

Best regards,
Bill

Bug#983365: linphone-desktop: chat messages

[Bill Blough]

Hi,

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

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

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

Best regards,
Bill

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

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

[Bill Blough]

Hi,

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

Best regards,
Bill



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

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

[Bill Blough]

Hi,

Thanks for your report.

I hope to address these issues next week.

Best regards,
Bill

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

[Bill Blough]

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

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

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


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



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

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

[Bill Blough]

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

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

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

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


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


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

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

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

python3-django-casclient recommends no packages.

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

-- no debconf information

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

[Bill Blough]

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

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

[Bill Blough]

My apologies for this - this is my fault.

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

Bill

Bug#894050: Reopening

[Bill Blough]

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

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

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

[Bill Blough]

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

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


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

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


Bill

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

[Bill Blough]

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

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

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

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

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

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

[Bill Blough]

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

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

Adding

export DEB_BUILD_MAINT_OPTIONS=noopt

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

Thanks!

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

[Bill Blough]

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


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

Thanks!

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

[Bill Blough]

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

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

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

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

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

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

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


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

Thanks!

Bill

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

[Bill Blough]

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

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

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

[Bill Blough]

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

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

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

Could someone please apply the patch and rebuild?

Thanks,
Bill

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

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

[Bill Blough]

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

Thanks.  Disregard my other email.

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

Thanks,
Bill

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

[Bill Blough]

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

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

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

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

The link above says

  The default locale of the build environment is C

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


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

Thanks very much.

Bill

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

[Bill Blough]

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

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

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

[Bill Blough]

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

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

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

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

Would you be willing to add

LC_ALL := C.UTF-8
export LC_ALL

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

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

[Bill Blough]

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

env | egrep "(LC|LANG)"

should give a list of relevant vars.

Thanks,
Bill

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

[Bill Blough]

On Sat, Dec 10, 2016 at 08:56:29AM +, Gianfranco Costamagna wrote:
> 
> >  libtool --mode=execute gdb --args samples/SAXCount 
> > samples/data/personal.xml
> > catch throw
> >
> >  bt full
> >continue
> > quit
> >This will hopefully help me to isolate this issue.
> >
> 
> 
> here we are!
> http://paste.debian.net/901516/

Thanks, looking into it.

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

[Bill Blough]

On Sat, Dec 10, 2016 at 02:25:08AM +0100, Mattia Rizzolo wrote:
> On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > > >Or does anyone have other suggestions?
> 
> I have one: please try to CC people (and/or MLs) sooner.  I now noticed
> that you asked for help more than one month ago, but I wasn't aware of
> that at all.  And now the freeze is hovering upon us.

Yes, fair enough.  That's my mistake.

> 
> > In the mean time, would it be possible to get a
> > stack trace showing the exception thrown by any one of the test
> > programs?
> 
> I got a build in the s390x porterbox, and reproduced the failure; at
> least, near enough, mine says
> diff test-results.log ./scripts/sanityTest_ExpectedResult.log
> Binary files test-results.log and ./scripts/sanityTest_ExpectedResult.log 
> differ
> Makefile:950: recipe for target 'check' failed
> Instead of actually showing the diff.
> 
> I'm happy to provide stacktraces and/or core dumps if you can tell me
> how to get them without me needed to figure things out.

After the build completes, from the build root, run

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

At the GDB prompt, type

  catch throw

then

  run

It will stop, saying exception thrown. To generate the stack trace, type

  bt full

There will likely be several screens of data.  If you could please
copy/paste them all. Once you're back at the gdb prompt, that's the end of
that trace.

Because there may be multiple exceptions thrown (including as part of
normal operation), I'd appreciate a stack trace of all of them.
Unfortunately, I don't know how many there will be.  On my (working) system
there's only one before successful completion.  Hopefully there won't be
much more than two on the failing system, but depending on the failure
there could be several.

>From the gdb prompt, typing

 continue

will continue execution until the next exception, at which point you can
repeat from the "bt full" step above.

Once you get a message saying the process exited, it's done, and you can
exit by typing

  quit


This will hopefully help me to isolate this issue.

Thanks for your help.

Bill

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

[Bill Blough]

On Fri, Dec 09, 2016 at 11:07:54PM +, Gianfranco Costamagna wrote:
> >Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
> >understand it correctly, it shouldn't have any effect on this, but I
> >have no way to test it other than another upload.
> 
> 
> I still prefer the default -Ofoo different as root cause
> 

According to the build logs, both are being compiled with -O2.  The only
difference I see in the build flags is the symbolic-functions link flag
I referenced earlier.  But as I said, I don't see how that would affect
it.


> >Assuming that's not it, would someone be willing to sponsor access to the 
> >s390x
> >porter box so I can get this sorted out?
> 
> 
> not so easy :/ are you a dm?

Unfortunately, not yet.  I hope to change that soon.


> 
> >Or does anyone have other suggestions?
> 
> 
> https://ufile.io/f0872
> 
> I did a build, and uploaded the whole build directory on that file, including
> 
> a complete build log (in the root directory), let me know if it sounds good 
> to you to debug
> building after export C{,PP,XX}FLAGS=-O3 didn't help either

Thanks, I really appreciate that. I'll look through it and see if I can
find any new leads.  In the mean time, would it be possible to get a
stack trace showing the exception thrown by any one of the test
programs?

Thanks,
Bill

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

[Bill Blough]

I'd really like to get this resolved before the freeze.

Can anyone comment on the use of -Bsymbolic_functions in Ubuntu?  If I
understand it correctly, it shouldn't have any effect on this, but I
have no way to test it other than another upload.

Assuming that's not it, would someone be willing to sponsor access to the s390x
porter box so I can get this sorted out?

Or does anyone have other suggestions?

Bug#833754: New upstream version

[Bill Blough]

I diffed the Debian and Ubuntu build logs, and the only difference I see
in build flags is that Ubuntu adds the -Bsymbolic_functions link flag.
Though, if I correctly understand the description of the flag, then I
don't think that's related.

As for package version differences, the only signficiant dependency at
runtime (other than libc6/libstdc++) is libicu, but the package verison
in Debian and Ubuntu is identical.

What I'd really like to get is a stack trace of one of the exceptions
thrown by the sample programs.  A core file would be even better.  But I
don't have access to an s390x system.

Would someone be willing to sponsor my temporary access to the s390x
porter box?  If not, could someone with access get me a stack trace or
core file showing the failure?  I could provide instructions if needed.

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

[Bill Blough]

I looked at it briefly, but had to refocus on  other issues before I
could really get anywhere. I'll get it sorted out and/or forwarded
shortly.

Thanks for the ping!

On Thu, Nov 03, 2016 at 04:10:27PM -0400, Sandro Tosi wrote:
> On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo  wrote:
> > source: xerces-c
> > version: 3.1.3+debian-2.1
> > severity: serious
> >
> > Dear maintainer,
> >
> > your package failed to build on buildds on the s390x architecure only
> > during a rebuild for the transition to icu57, using gcc6 as compiler.
> > You can see the build log at:
> > https://buildd.debian.org/status/fetch.php?pkg=xerces-c=s390x=3.1.3%2Bdebian-2.1%2Bb1=1470418530
> 
> Hey William, did you have a chance to look at this bug? i couldnt find
> much on the upstream bug tracker but there is also a 3.1.4 new release
> you might want to test if fixes this bug else report it upstream.
> thanks!!

Bug#718303: segmentation fault xalanc_1_11::XalanDOMString::XalanDOMString

[Bill Blough]

On Fri, Oct 10, 2014 at 02:30:10PM +0200, Mathieu Malaterre wrote:
 Any chance patch from upstream be applied ? We are very close to
 entering freeze period.

The upstream patch has already been applied in the repository, so it is 
technically pending.

Now that we're not blocked from Jessie by #718315, I'll be preparing the upload
sometime in the next week.



signature.asc
Description: Digital signature