Bug#1059502: rakudo: Raku configuration requires libffi, libtommath and libuv for any tests involving native call to work

[Vadim Zeitlin]

Package: rakudo
Version: 2022.12-1
Severity: normal

Dear Maintainer,

Configuration of Rakudo packages puts `-lffi -ltommath -luv` in the "ldlibs"
key of
the "config" object which is used to build native code and this results in
build and/or
test failures when installing any packaging needing to do it -- which are very
common
in Rakudo ecosystem, as many common packages depend on them. E.g. it prevents
installing
LibXML or DBIish without --force-test.

Please notice that while this system uses 2022.12 version of the package, I've
checked
that the latest available 2023.06-1~exp1 also behaves in the same way.

AFAICS the problem comes from here:

% /usr/bin/raku -e 'say $*VM.config'
 -L/usr/local/lib -lffi -ltommath -luv -lm -lpthread -lrt -ldl

To be compared with the upstream Rakudo packages:
% /opt/rakudo/bin/raku -e 'say $*VM.config'
 -lm -lpthread -lrt -ldl

As "ldlibs" is used by e.g. compile_test_lib function used by the tests, all
test
code tries to link with the libraries listed above and so fails if they're not
installed.

Here is a slightly edited example of the problem:

% zef install --install-to=home --verbose DBIish
===> Searching for: DBIish
===> Found: DBIish:ver<0.6.6>:auth:api<1> [via
Zef::Repository::Ecosystems]
===> Searching for missing dependencies: NativeHelpers::Blob,
NativeLibs:ver<0.0.9+>:auth, NativeCall::TypeDiag
[...]
===> Extraction [OK]: NativeHelpers::Blob to
$HOME/.zef/tmp/NativeHelpers%3A%3ABlob%3Aver%3C0.1.12%3E%3Aauth%3Cgithub%3Asalortiz%3E.tar.gz
===> Testing: NativeHelpers::Blob:ver<0.1.12>:auth
[NativeHelpers::Blob] t/00-trivial.t .. ok
[NativeHelpers::Blob] t/01-basic.t  ok
[NativeHelpers::Blob] t/02-cstruct.t .. Dubious, test returned 255
[NativeHelpers::Blob] All 35 subtests passed
[NativeHelpers::Blob] t/03-pointer.t .. ok
[NativeHelpers::Blob] t/99-my-meta.t .. ok
[NativeHelpers::Blob] All tests successful.
[NativeHelpers::Blob]
[NativeHelpers::Blob] Test Summary Report
[NativeHelpers::Blob] ---
[NativeHelpers::Blob] t/02-cstruct.t (Wstat: 65280 Tests: 0 Failed: 0)
[NativeHelpers::Blob] Non-zero exit status: 255
[NativeHelpers::Blob]   Parse errors: Bad plan.  You planned 35 tests but ran
0.
[NativeHelpers::Blob] Files=5, Tests=36,  1 wallclock secs
[NativeHelpers::Blob] Result: FAILED
===> Testing [FAIL]: NativeHelpers::Blob:ver<0.1.12>:auth
Aborting due to test failure:
NativeHelpers::Blob:ver<0.1.12>:auth (use --force-test to
override)

Looking at the failure in more details it can be seen that it happens because
libtommath is not available on my
system (libffi happens to be already installed for unrelated reasons).

Either lib{ffi,tommath,uv}-dev should be made dependencies of rakudo package
or, preferably, it shouldn't include
them in "ldlibs" in its config.

Thanks in advance!


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.utf8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rakudo depends on:
ii  libc6  2.36-9+deb12u3
ii  libgraph-perl  1:0.9726-1
ii  libipc-system-simple-perl  1.30-2
ii  libpath-tiny-perl  0.144-1
ii  moarvm 2022.12+dfsg-1
ii  nqp2022.12+dfsg-1

rakudo recommends no packages.

Versions of packages rakudo suggests:
ii  valgrind  1:3.19.0-1

-- no debconf information

Bug#1004112: libunwind-13-dev: Issues when replacing libunwind-dev

[Vadim Zeitlin]

 Sorry but this bug isn't fixed at all: it is possible to keep
libgstreamer1.0-dev installed when installing libc++-dev now, but it's
still impossible to actually use it because libunwind-dev (the not-llvm
version libgstreamer1.0-dev depends on) is still uninstalled and then any
attempt to use libgstreamer via pkg-config result in

Package 'libunwind', required by 'gstreamer-1.0', not found

and it still can't be used.

 I have no idea about it but it remains impossible to use libc++ and
gstreamer on the same system which is a rather bad limitation.

 If anybody has any suggestions for a workaround, they would be very
welcome, TIA!
VZ

Bug#1041366: jing: Warnings about "unable to locate $dependency in /usr/share/java"

[Vadim Zeitlin]

Package: jing
Version: 20220510-2
Severity: minor

Dear Maintainer,

Running jing with any options produces the following warnings before any other
output:

$ jing
[warning] /usr/bin/jing: Unable to locate xml-apis in /usr/share/java
[warning] /usr/bin/jing: Unable to locate avalon-framework in /usr/share/java
[warning] /usr/bin/jing: Unable to locate batik-all in /usr/share/java
Jing version 20220510
usage: java com.thaiopensource.relaxng.util.Driver [-i] [-c] [-s] [-t] [-C
catalogFile] [-e encoding] RNGFile XMLFile...
RELAX NG is a schema language for XML
See http://relaxng.org/ for more information.

It seems like these warnings are actually harmful, at least in my use, but they
certainly are annoying. I'd rather not install avalon-framework if possible,
and so would be glad if there were some other way to get rid of them.

Thanks in advance!


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.utf8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jing depends on:
ii  default-jre [java-runtime] 2:1.17-74
ii  java-wrappers  0.4
ii  libjing-java   20220510-2
ii  openjdk-17-jre [java-runtime]  17.0.7+7-1~deb12u1

jing recommends no packages.

jing suggests no packages.

-- no debconf information

Bug#1030380: libgstreamer1.0-dev: Can't be used via pkg-config without libunwind-dev

[Vadim Zeitlin]

Package: libgstreamer1.0-dev
Version: 1.22.0-2
Severity: important
X-Debbugs-Cc: vz-deb...@zeitlins.org

Dear Maintainer,

libgstreamer1.0-dev package has a dependency on libunwind-dev which can be
satisfied by libunwind-14-dev, but this doesn't seem to actually work
because it's libunwind itself which is listed as a dependency in e.g.
/usr/lib/x86_64-linux-gnu/pkgconfig/gstreamer-1.0.pc resulting in the
following when trying to use the package:

$ pkg-config --exists --print-errors gstreamer-1.0
Package libunwind was not found in the pkg-config search path.
Perhaps you should add the directory containing `libunwind.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libunwind', required by 'gstreamer-1.0', not found

Maybe there is a bug in libunwind-14-dev which doesn't provide libunwind.pc
but the net effect is that it's impossible to use libgstreamer-dev and
libc++-dev together because the latter requires libunwind-14-dev and
installing libunwind-dev would uninstall it, so it is a fatal problem for
me.

Thanks in advance for your help!

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgstreamer1.0-dev depends on:
ii  gir1.2-gstreamer-1.0  1.22.0-2
ii  libc6 2.36-8
ii  libc6-dev [libc-dev]  2.36-8
ii  libdw-dev 0.188-2.1
ii  libglib2.0-0  2.74.5-1
ii  libglib2.0-dev2.74.5-1
ii  libgstreamer1.0-0 1.22.0-2
ii  libunwind-14-dev [libunwind-dev]  1:14.0.6-10+b1
ii  pkg-config1.8.1-1
ii  pkgconf [pkg-config]  1.8.1-1

libgstreamer1.0-dev recommends no packages.

Versions of packages libgstreamer1.0-dev suggests:
pn  gstreamer1.0-doc  

-- no debconf information

Bug#1004112:

[Vadim Zeitlin]

 Just for the record, this bug affects libunwind-14-dev too and is really,
really annoying as you basically can't use clang and GStreamer on the same
system. It would be really great if this could be fixed, especially if the
fix is really as simple as in the patch above.

 Thanks in advance,
VZ

pgpjV4kNx1RKK.pgp
Description: PGP signature

Bug#993522: Re[2]: Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work

[Vadim Zeitlin]

On Thu, 2 Sep 2021 16:27:27 +0200 Robin Jarry  wrote:

> 2021-09-02, Vadim Zeitlin:
> > Package: buildbot-worker
> > Version: 2.10.1-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
> > doesn't work because its value is used in a wrong place in the init.d
> > script: it does
> > 
> > "$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
> > 
> > when the correct syntax would be
> > 
> > "$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
> > 
> > i.e. the options must come before the operation for buildbot-worker, not
> > after it.
> 
> Actually, this is only true for the --verbose option. Other options must
> be passed after $op.

 Hello and thank you for your reply!

 Yes, indeed, sorry, I haven't realized this. Even the symmetric --quiet
option does need to come after the operation. So this looks like poor
buildbot command line UI and not a problem in the package itself, finally.

> I see that you are using systemd. You should not use the init.d script
> but the systemd unit template which is provided with the package. There
> are examples in the man page to tweak the unit parameters:
> 
> https://manpages.debian.org/bullseye/buildbot-worker/buildbot-worker.7.en.html#systemd
> 
> In your case, you should override ExecStart= in a drop-in file.

 Oh, I see... it's really a comedy of errors and it looks like I did just
about everything wrong because I did try using systemd, but when I saw that
the buildbot-worker.service was masked, I've removed the file
/lib/systemd/system/buildbot-worker.service to unmask it -- instead of
using buildbot-worker@$NAME which is, as I now understand, the right thing
to do. And while this allowed me to run "systemctl start buildbot-worker",
in the meanwhile I had added "--verbose" to the defaults file to help me
debugging the problem and this "--verbose" actually prevented things from
working.

> Also, it looks like this is a duplicate of bug #993521. Should I close
> the first one?

 Yes, sorry about this one too, I've resent the bug report accidentally.
I've tried to correct the problem by merging the 2 reports, but I'm not
sure if I made things better or worse by doing it.

 In any case, it looks like both bug reports should be closed and the only
thing to do might be to update the comment in the defaults file to say that
the "--verbose" option can't be used there.

 Thanks again for your reply and explanations!
VZ

pgpdR0QSDOh5j.pgp
Description: PGP signature

Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work

[Vadim Zeitlin]

Package: buildbot-worker
Version: 2.10.1-1
Severity: normal

Dear Maintainer,

Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
doesn't work because its value is used in a wrong place in the init.d
script: it does

"$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}

when the correct syntax would be

"$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}

i.e. the options must come _before_ the operation for buildbot-worker, not
after it.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages buildbot-worker depends on:
ii  lsb-base 11.1.0
ii  passwd   1:4.8.1-1
ii  python3  3.9.2-3
ii  python3-future   0.18.2-5
ii  python3-twisted  20.3.0-7

Versions of packages buildbot-worker recommends:
ii  git  1:2.30.2-1

buildbot-worker suggests no packages.

-- Configuration Files:
/etc/default/buildbot-worker changed [not included]

-- no debconf information

pgpU1yClnS8cy.pgp
Description: PGP signature

Bug#993521: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work

[Vadim Zeitlin]

Package: buildbot-worker
Version: 2.10.1-1
Severity: normal
X-Debbugs-Cc: vz-deb...@zeitlins.org

Dear Maintainer,

Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
doesn't work because its value is used in a wrong place in the init.d
script: it does

"$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}

when the correct syntax would be

"$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}

i.e. the options must come _before_ the operation for buildbot-worker, not
after it.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages buildbot-worker depends on:
ii  lsb-base 11.1.0
ii  passwd   1:4.8.1-1
ii  python3  3.9.2-3
ii  python3-future   0.18.2-5
ii  python3-twisted  20.3.0-7

Versions of packages buildbot-worker recommends:
ii  git  1:2.30.2-1

buildbot-worker suggests no packages.

-- Configuration Files:
/etc/default/buildbot-worker changed [not included]

-- no debconf information

Bug#567648: dash: please document that set -x in a subshell can cause non-determinism

[Vadim Zeitlin]

 Just FYI, there is a simple patch (mostly) fixing this problem now at

https://salsa.debian.org/debian/dash/merge_requests/7

VZ

pgpFP0sBO0bhM.pgp
Description: PGP signature

Bug#925172: g++-mingw-w64-i686: libstdc++fs.a not included in the Debian package

[Vadim Zeitlin]

Package: g++-mingw-w64-i686
Version: 8.2.0-21+21.1
Severity: normal

Unfortunately, std::filesystem still can't be used with the latest version
of the package: after the fix for the compilation problems previously
reported as #907369, any attempt to use this library results in linking
problems because libstdc++fs.a file is nowhere to be found.

To reproduce, compile this trivial example:

% cat -n fs.cpp
 1  #include 
 2  #include 
 3  namespace fs = std::filesystem;
 4
 5  int main(int argc, char *argv[])
 6  {
 7  fs::path p(argv[1]);
 8  std::cout << "Native:\t" << p.string() << "\n"
 9<< "Generic:\t" << p.generic_string() << "\n";
10  return 0;
11  }
% i686-w64-mingw32-g++ -std=c++17 fs.cpp
/usr/bin/i686-w64-mingw32-ld: 
fs.o:fs.cpp:(.text$_ZNSt10filesystem7__cxx114pathC1IPcS1_EERKT_NS1_6formatE[__ZNSt10filesystem7__cxx114pathC1IPcS1_EERKT_NS1_6formatE]+0x93):
 undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
[... and other similar errors ...]
collect2: error: ld returned 1 exit status
% i686-w64-mingw32-g++ -std=c++17 fs.o -lstdc++fs
/usr/bin/i686-w64-mingw32-ld: cannot find -lstdc++fs
collect2: error: ld returned 1 exit status

The latter command line works when using the native g++-8, which does
provide the library.

I don't really know if this is supposed to work or not, but it seems a bit
strange to provide the headers for the library, but not the library itself.

Note that according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
--enable-libstdcxx-filesystem-ts must be used to enable it, could it be
that it simply needs to be added to configure arguments?

Thanks in advance!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages g++-mingw-w64-i686 depends on:
ii  gcc-mingw-w64-base  8.2.0-21+21.1
ii  gcc-mingw-w64-i686  8.2.0-21+21.1
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-3
ii  libgmp102:6.1.2+dfsg-4
ii  libisl190.20-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.2-1
ii  libstdc++6  8.3.0-3
ii  zlib1g  1:1.2.11.dfsg-1

g++-mingw-w64-i686 recommends no packages.

Versions of packages g++-mingw-w64-i686 suggests:
pn  gcc-8-locales  

-- no debconf information



pgpm68nLZfxbU.pgp
Description: PGP signature

Bug#907369: g++-mingw-w64-i686: Including filesystem header results in compilation errors

[Vadim Zeitlin]

Package: g++-mingw-w64-i686
Version: 8.2.0-1+21~exp2
Severity: normal

Including filesystem header results in compilation errors, e.g.:

% echo '#include ' | i686-w64-mingw32-g++ -std=c++17 -x c++ -
In file included from 
/usr/lib/gcc/i686-w64-mingw32/8.2-win32/include/c++/filesystem:37,
 from fs.cpp:6:
/usr/lib/gcc/i686-w64-mingw32/8.2-win32/include/c++/bits/fs_path.h: In member 
function ‘std::filesystem::__cxx11::path& 
std::filesystem::__cxx11::path::operator/=(const 
std::filesystem::__cxx11::path&)’:
/usr/lib/gcc/i686-w64-mingw32/8.2-win32/include/c++/bits/fs_path.h:237:47: 
error: no match for ‘operator!=’ (operand types are 
‘std::filesystem::__cxx11::path’ and ‘std::filesystem::__cxx11::path’)
|| (__p.has_root_name() && __p.root_name() != root_name()))
   ^~
...

This is due to the fact that Windows-specific code in this header uses
operator==(path, path) which is only defined later, so the error makes
sense.

I'm not sure where exactly does this code come from as it differs from the
upstream code (in gcc repository), but I can't find the Debian patch with
it neither. FWIW it looks like using the upstream version would fix this
problem.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages g++-mingw-w64-i686 depends on:
ii  gcc-mingw-w64-base  8.2.0-1+21~exp2
ii  gcc-mingw-w64-i686  8.2.0-1+21~exp2
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-4
ii  libgmp102:6.1.2+dfsg-3
ii  libisl190.20-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-1
ii  libstdc++6  8.2.0-4
ii  zlib1g  1:1.2.11.dfsg-1

g++-mingw-w64-i686 recommends no packages.

Versions of packages g++-mingw-w64-i686 suggests:
pn  gcc-8-locales  

-- no debconf information


pgp4yPuHK3UdM.pgp
Description: PGP signature

Bug#894302: Re[2]: g++-7: Compiler generates wrong code with warning options

[Vadim Zeitlin]

On Sun, 6 May 2018 13:42:48 +0200 Matthias Klose  wrote:

MK> I am not aware of any Debian local patches which could trigger that.  Please
MK> could you check if you can reproduce this with GCC 8 as well?

 I can't reproduce the problem with the minimized test case using gcc 8
from Sid (8.1.0-1). As an aside, gcc 8 also produces much smaller (less
than 50%) assembly and object code from the same files compared to gcc 7,
which surprised me. FWIW I can still reproduce the problem with the
latest g++-7 (7.3.0-17) in exactly the same way as originally reported for
7.2.

 The original problem, in the real program I was working on, only appeared
when using MinGW, so I can't [easily] test whether it is still present or
not as there is no gcc-mingw-w64 8 in Debian yet, but I'll do it when it
becomes available.

 Thanks for looking into this,
VZ


pgpL1fzbHfWiT.pgp
Description: PGP signature

Bug#894302: g++-7: Compiler generates wrong code with warning options

[Vadim Zeitlin]

Package: g++-7
Version: 7.3.0-12
Severity: important

This is an apparently impossible bug which nevertheless can be reliably
observed when using Debian versions of g++-7 and also i686-w64-mingw32-g++.
It consists in compiler generating different, and broken, code when
compiling the same input with only warning options -- which are, of course,
not supposed to affect the code generation at all -- added.

The upstream bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
contains several test cases. Using the one from
https://gcc.gnu.org/bugzilla/attachment.cgi?id=43774 it can be seen that
running

g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -o nowarn.s

and

g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -Wnonnull 
-Woverloaded-virtual -o warn.s

commands produces different assembly. Subsequently, Martin Liška has
created a further reduced test case which allows to reproduce the problem
using just "-O1 -Woverloaded-virtual", please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091#c31

The bug is really mysterious but quite worrisome, as it results in broken
code being silently generated in practice and, worse, the generated code
oscillates between correct and broken versions when any, even apparently
completely unrelated, changes are made. Another interesting detail is that
using -fchecking=2 makes the bug disappear (but -fchecking does not).

Finally, please note that the bug doesn't seem to happen with the upstream
versions nor with g++ 7.2 from Fedora, so it's highly likely that it's due
to one of the Debian-specific patches, even if I really can't see anything
that could explain it in any of them.

Thanks in advance for any help with this!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages g++-7 depends on:
ii  gcc-77.3.0-12
ii  gcc-7-base   7.3.0-12
ii  libc62.27-2
ii  libgmp10 2:6.1.2+dfsg-3
ii  libisl19 0.19-1
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.1-1
ii  libstdc++-7-dev  7.3.0-12
ii  zlib1g   1:1.2.8.dfsg-5

g++-7 recommends no packages.

Versions of packages g++-7 suggests:
pn  g++-7-multilib
pn  gcc-7-doc 
pn  libstdc++6-7-dbg  

-- no debconf information


pgpvILPPlKYm4.pgp
Description: PGP signature

Bug#868882: libmyodbc: The package is not installable in Sid due to missing libmysqlclient18 dependency

[Vadim Zeitlin]

Package: libmyodbc
Severity: grave
Justification: renders package unusable

Trying to install this package results in

# apt install libmyodbc
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libmyodbc : Depends: libmysqlclient18 (>= 5.5.24+dfsg-1) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

And, indeed, libmysqlclient18 doesn't seem to be available. I guess this
package might be obsolete in sid (due to Maria DB transition?), but in this
case it probably ought to be removed instead of being left in the current
uninstallable state.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libmyodbc depends on:
ii  debconf   1.5.62
ii  libc6 2.24-12
pn  libmysqlclient18  
ii  odbcinst1debian2  2.3.4-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libmyodbc recommends:
ii  libodbc1  2.3.4-1

libmyodbc suggests no packages.

pgpbtDhB0QWmh.pgp
Description: PGP signature

Bug#815809: lldb-3.8: lldb binary not included in the package any more

[Vadim Zeitlin]

Package: lldb-3.8
Version: 1:3.8~+rc2-1~exp1
Severity: grave
Justification: renders package unusable

The latest version of the package contains symlinks /usr/bin/lldb-3.8 and
/usr/lib/llvm-3.8/bin/lldb but not the actual lldb binary
/usr/lib/llvm-3.8/bin/lldb-3.8.0, so it basically doesn't provide the
debugger at all.

I don't know if this is a regression or not because I had been previously
using the packages from http://llvm.org/apt/unstable/ which did include
lldb (but didn't include ASAN libraries which are available in Debian
packages, see https://llvm.org/bugs/show_bug.cgi?id=22757)

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lldb-3.8 depends on:
ii  libllvm3.8   1:3.8~+rc2-1~exp1
ii  llvm-3.8-dev 1:3.8~svn254193-1
ii  python   2.7.11-1
ii  python-lldb-3.8  1:3.8~svn254193-1

lldb-3.8 recommends no packages.

lldb-3.8 suggests no packages.

-- no debconf information

Bug#798395: python-pip doesn't specify dependency on python-html5lib correctly

[Vadim Zeitlin]

Package: python-pip
Version: 1.5.6-3

 On a mixed Wheezy/Jessie system, updating python-pip to Jessie version
left python-html5lib at 0.95-1 from Wheezy instead of upgrading it to
0.000-3 from Jessie, which later resulted in failures when running pip:

-- >8 --
Exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 278, in 
run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, 
bundle=self.bundle)
  File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1096, in 
prepare_files
req_to_install, self.upgrade)
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 256, in 
find_requirement
page_versions.extend(self._package_versions(page.links, req.name.lower()))
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 432, in 
_package_versions
for link in self._sort_links(links):
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 422, in _sort_links
for link in links:
  File "/usr/lib/python2.7/dist-packages/pip/index.py", line 769, in links
for anchor in self.parsed.findall(".//a"):
AttributeError: 'Document' object has no attribute 'findall'

Storing debug log for failure in /home/zeitlin/.pip/pip.log
-- >8 --

 I don't know in which version of python-html5lib was findall() added, but
python-pip clearly should depend on something > 0.95.

 Thanks,
VZ


pgp9XzzoeH5AO.pgp
Description: PGP signature

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

Package: elfutils
Version: 0.148-1
Severity: important

I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
library. This tools uses eu-readelf to actually read the library symbols
but eu-readelf crashes, making it unusable:

% eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so  /dev/null
[2]16820 segmentation fault (core dumped)  eu-readelf -N 
--debug-dump=loc   /dev/null

FWIW I've tried the latest git elfutils sources (elfutils-0.157-8-g3cf491e)
and the bug is still present in them, so it's not a Debian bug per se, but
I'm reporting it here because I didn't find any other place to do it (the
project has a Trac but there are no tickets there at all), please let me
know if I should do it in some other place.


-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable
  APT policy: (900, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-full (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash

Versions of packages elfutils depends on:
ii  libasm1   0.148-1library with a programmable assemb
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libdw10.148-1library that provides access to th
ii  libelf1   0.148-1library to read and write ELF file

elfutils recommends no packages.

elfutils suggests no packages.

-- no debconf information


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

Bug#728539: Re[2]: Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

On Sat, 2 Nov 2013 18:50:04 +0100 Kurt Roeckx k...@roeckx.be wrote:

KR On Sat, Nov 02, 2013 at 06:46:44PM +0100, Kurt Roeckx wrote:
KR  On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote:
KR   Package: elfutils
KR   Version: 0.148-1
KR   Severity: important
KR   
KR   I'm trying to use abi-dumper tool for analyzing the ABI of my own shared
KR   library. This tools uses eu-readelf to actually read the library symbols
KR   but eu-readelf crashes, making it unusable:
KR   
KR   % eu-readelf -N --debug-dump=loc libwx_baseu-3.0.so  /dev/null
KR   [2]16820 segmentation fault (core dumped)  eu-readelf -N 
--debug-dump=loc   /dev/null
KR  
KR  I can at least reproduce this with any shared library.
KR 
KR I even seem to be able to do this with any binary with the 0.156-1
KR version, but 0.153-2 working without a problem for me.
KR 
KR Is that 0.148-1 version right?

 I've tested both 0.148-1 (from Debian) and the latest 0.157 (from their
Git). Thanks for the hint about 0.153, I'm going to try this a.s.a.p. to
see if it works for me.

 And thanks for looking at this!
VZ


pgp0jQkvlZ3ul.pgp
Description: PGP signature

Bug#728539: Re[2]: Bug#728539: elfutils: eu-readelf crashes when reading a shared library

[Vadim Zeitlin]

On Sat, 2 Nov 2013 19:35:39 +0100 Kurt Roeckx k...@roeckx.be wrote:

KR So for me I have this problem with this combination:
KR elfutils 0.157-1
KR libdw1 0.157-1
KR libelf1 0.153-2
KR 
KR Upgrading libelf1 to 0.157-1 makes the problem go away for me.

 Sorry, I was wrong in my initial bug report: it does indeed work correctly
with all of 0.153, 0.154, 0.157 and the latest git master if I run it
properly, i.e. by setting LD_LIBRARY_PATH, from the source tree. When I
tested git sources initially, I hadn't realized that I was still using the
packaged version of libelf1 (and libdw1 too).

 Retesting with the correct versions, I see the bug with 0.148 I build
myself and here is the backtrace:

Starting program: /home/zeitlin/build/elfutils/src/readelf -N --debug-dump=loc 
/home/zeitlin/build/wx-gtkud/lib/libwx_baseu-3.0.so  /dev/null

Program received signal SIGSEGV, Segmentation fault.
print_block (n=33477184, block=0x77231000) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:3803
3803   printf ( %02x, *data++);
(gdb) bt
#0  print_block (n=33477184, block=0x77231000) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:3803
#1  0x0040cf62 in print_ops (dwflmod=optimized out, dbg=optimized 
out, indent=50, indentrest=50, addrsize=optimized out, offset_size=4, 
len=18446744073707981979, data=0x7721e242 \037\200)
at /home/zeitlin/mirrors/elfutils/src/readelf.c:4200
#2  0x0040d42f in print_debug_loc_section (dwflmod=optimized out, 
ebl=optimized out, ehdr=optimized out, scn=optimized out, shdr=optimized 
out, dbg=0x623380) at /home/zeitlin/mirrors/elfutils/src/readelf.c:6140
#3  0x00409682 in print_debug (dwflmod=optimized out, ebl=0x6230d0, 
ehdr=0x7fffde90) at /home/zeitlin/mirrors/elfutils/src/readelf.c:6732
#4  0x004116e8 in process_elf_file (dwflmod=optimized out, 
fd=optimized out) at /home/zeitlin/mirrors/elfutils/src/readelf.c:698
#5  0x00412749 in process_dwflmod (dwflmod=0x622f30, 
userdata=optimized out, name=0x7778edf0 _IO_stdfile_1_lock , 
base=4284098, arg=0x0) at /home/zeitlin/mirrors/elfutils/src/readelf.c:526
#6  0x77bc5eae in dwfl_getmodules (dwfl=0x621030, callback=0x4126f0 
process_dwflmod, arg=0x7fffe080, offset=1) at 
/home/zeitlin/mirrors/elfutils/libdwfl/dwfl_getmodules.c:103
#7  0x00404243 in process_file (only_one=true, fname=optimized out, 
fd=optimized out) at /home/zeitlin/mirrors/elfutils/src/readelf.c:596
#8  main (argc=optimized out, argv=optimized out) at 
/home/zeitlin/mirrors/elfutils/src/readelf.c:277

 But this was fixed since then and so it looks like there is nothing much
to do here, knowing that Wheezy has 0.152 which does work (just tested in a
chroot).

 Sorry again for the initial confusion!
VZ


pgpJMOQa26wGN.pgp
Description: PGP signature

Bug#496832: Any progress on this one?

[Vadim Zeitlin]

On Wed, 28 Sep 2011 01:31:41 +0200 Torsten Landschoff t.landsch...@gmx.de 
wrote:

TL is there any progress on this one?

 Hello,

 Not on my part, sorry. I totally gave up on trying to package anything for
Debian, my experience with trying to maintain wxWidgets Debian packages
and, to a lesser extent, bakefile ones, was so incredibly frustrating and
counterproductive that I completely abandoned any idea of ever doing it.

 Sorry,
VZ


pgpE3DRaYklOC.pgp
Description: PGP signature

Bug#496832: bakefile Debian packages

[Vadim Zeitlin]

 Hello,

 Another user interested in using bakefile has just pointed me to this bug
and I'd like to add that I'd be glad to maintain bakefile package in Debian. 
I already make its packages available at http://apt.tt-solutions.com/debian/
and would welcome any advice about improving them.

 Please let me know if I should submit an ITP for this package or if I
should proceed in some other way.

 Thanks,
VZ


pgpB1VWDHO5yf.pgp
Description: PGP signature

Bug#557744: Re[2]: [Pkg-libvirt-maintainers] Bug#557744: libvirt-bin: Starting domain fails with qemudOpenMonitorUnix: monitor socket did not show up.: Connection refused

[Vadim Zeitlin]

On Tue, 24 Nov 2009 14:36:57 +0100 Guido Günther a...@sigxcpu.org wrote:

GG You can run the daemon with 
GG 
GG VIRT_DEBUG=1 libvirtd
GG 
GG to find out what happens.

 Hello,

 This didn't show anything new, I only saw the same

2:54:07.693: error : qemudOpenMonitorUnix:1007 : monitor socket did not show 
up.: Connection refused
libvir: QEMU error : monitor socket did not show up.: Connection refused

when doing this.

GG Strace might help to. It's doing fine here.
GG Please also have a look at the VM logs in /var/log/libvirt/.

 But this did help as I could see an extra error (not shown anywhere else
and I had no idea about the files in this directory, I was only looking at
syslog...): Could not load option rom 'extboot.bin'. So this seems to be
the same as bug #553986. And, indeed, uninstalling qemu allowed it to start
(now I get kvm: unhandled exit 8021 and kvm_run returned -22 which
is not especially enlightening neither but it's a different/next problem at
least...).

 Thanks,
VZ


pgp6bQmszJ1vl.pgp
Description: PGP signature

Bug#557744: libvirt-bin: Starting domain fails with qemudOpenMonitorUnix: monitor socket did not show up.: Connection refused

[Vadim Zeitlin]

Package: libvirt-bin
Version: 0.7.2-3
Severity: important


Running virsh -c qemu:///system create vm.xml fails with

error: Failed to create domain from vm.xml
error: monitor socket did not show up.: Connection refused

and

kernel: [ 2863.481686] device vnet0 entered promiscuous mode
kernel: [ 2863.483550] virbr0: topology change detected, propagating
kernel: [ 2863.483555] virbr0: port 1(vnet0) entering forwarding state
kernel: [ 2863.599974] virbr0: port 1(vnet0) entering disabled state
kernel: [ 2863.630507] device vnet0 left promiscuous mode
kernel: [ 2863.630513] virbr0: port 1(vnet0) entering disabled state
libvirtd: 14:08:22.683: error : qemudOpenMonitorUnix:1007 : monitor 
socket did not show up.: Connection refused

in syslog. The symptoms are identical when running this command as a normal
user (member of libvirt group) or root.

Unfortunately I was unable to find out which socket it wants to connect to,
all I can say is that it is _not_ /var/run/libvirt/libvirt-sock as it does
connect to it successfully.

Looking at qemudOpenMonitorUnix() in libvirt Git it seems like the error is
indeed given from there but, mysteriously, I don't see these socket() and
connect() calls neither with strace nor gdb so I just don't understand
what's going on here at all. Any pointers in the right direction would be
appreciated.

Thanks in advance!

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt-bin depends on:
ii  adduser   3.111  add and remove users and groups
ii  libavahi-client3  0.6.25-1   Avahi client library
ii  libavahi-common3  0.6.25-1   Avahi common library
ii  libc6 2.10.1-7   GNU C Library: Shared libraries
ii  libdbus-1-3   1.2.16-2   simple interprocess messaging syst
ii  libdevmapper1.02. 2:1.02.39-1The Linux Kernel Device Mapper use
ii  libgnutls26   2.8.4-2the GNU TLS library - runtime libr
ii  libhal1   0.5.13-4   Hardware Abstraction Layer - share
ii  libparted1.8-12   1.8.8.git.2009.07.19-5 The GNU Parted disk partitioning s
ii  libreadline6  6.0-5  GNU readline and history libraries
ii  libsasl2-22.1.23.dfsg1-2 Cyrus SASL - authentication abstra
ii  libselinux1   2.0.88-1   SELinux runtime shared libraries
ii  libuuid1  2.16.1-4   Universally Unique ID library
ii  libvirt0  0.7.2-3library for interfacing with diffe
ii  libxenstore3.03.4.0-2Xenstore communications library fo
ii  libxml2   2.7.6.dfsg-1   GNOME XML library
ii  logrotate 3.7.8-4Log rotation utility

Versions of packages libvirt-bin recommends:
ii  bridge-utils  1.4-5  Utilities for configuring the Linu
ii  dnsmasq-base  2.51-1 A small caching DNS proxy and DHCP
ii  iptables  1.4.4-2administration tools for packet fi
ii  netcat-openbsd1.89-3 TCP/IP swiss army knife
ii  qemu  0.10.6-1   fast processor emulator

Versions of packages libvirt-bin suggests:
ii  policykit-1   0.94-4 framework for managing administrat

-- no debconf information



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

Bug#548924: gtk2-engines-ubuntulooks: Tooltips style incorrect for GTK+ 2.12+

[Vadim Zeitlin]

Package: gtk2-engines-ubuntulooks
Version: 0.9.12-2
Severity: minor
Tags: patch

Tooltips style is not set correctly in /usr/share/themes/Human/gtk-2.0/gtkrc
for GTK+ versions later than 2.12 as the tooltip widget is now gtk-tooltip
and not gtk-tooltips. The following trivial patch fixes this (following the
same change done to all the other themes included in gtk2-engine):

--- gtkrc.orig  2009-09-29 19:23:42.0 +0200
+++ gtkrc   2009-09-29 19:23:51.0 +0200
@@ -219,7 +219,7 @@
 widget_class *.GtkCombo.GtkButtonstyle clearlooks-combo
 # tooltips stuff
 widget_class *.tooltips.*.GtkToggleButton style clearlooks-tasklist
-widget gtk-tooltips style clearlooks-tooltips
+widget gtk-tooltip* style clearlooks-tooltips

 # treeview stuff
 widget_class *.GtkTreeView.GtkButton style clearlooks-tree

Thanks!

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (900, 'stable'), (100, 'testing'), (50, 'unstable'), (30, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29-acct (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash

Versions of packages gtk2-engines-ubuntulooks depends on:
ii  libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii  libc6   2.7-18   GNU C Library: Shared libraries
ii  libcairo2   1.6.4-7  The Cairo 2D vector graphics libra
ii  libglib2.0-02.16.6-2 The GLib library of C routines
ii  libgtk2.0-0 [gtk2.0-bin 2.12.12-1~lenny1 The GTK+ graphical user interface 
ii  libpango1.0-0   1.20.5-5 Layout and rendering of internatio

gtk2-engines-ubuntulooks recommends no packages.

gtk2-engines-ubuntulooks suggests no packages.

-- no debconf information



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