Bug#888228: cmake: ignores linker scripts on the Hurd (and kFreeBSD?)

[Aaron M. Ucko]

Package: cmake
Version: 3.9.5-1
Severity: important
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd-i386
Control: affects -1 src:mariadb-connector-c

The build of mariadb-connector-c for hurd-i386 (admittedly not a
release architecture) [1] failed because the symbols came out
unversioned, whereas the .symbols file expects version annotations.
By my reading of [2], CMake encounters the version script on line 378
but evidently neglects to pass it along to the linker.  I suspect
kFreeBSD builds may wind up failing in the same fashion if and when
their autobuilders are back in commission.

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mariadb-connector-c=hurd-i386=3.0.3-1=1516561406=0
[2] 
https://salsa.debian.org/mariadb-team/mariadb-connector-c/blob/master/libmariadb/CMakeLists.txt

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#888225: lamarc: FTBFS on non-Linux: No match for wx-config --toolkit=osx_cocoa

[Aaron M. Ucko]

Source: lamarc
Version: 2.1.10.1+dfsg-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of lamarc for hurd-i386 (admittedly not a release
architecture) failed:

  checking build system type... i686-pc-gnu
  checking host system type... i686-pc-gnu
  checking target system type... i686-pc-gnu
  [...]
  DO NOT CHECK THIS config.ac in, it has GUI_TOOLKIT and
  LAMARC_CODE_OSTYPE hardwired for 10.7 mac
  [...]
   Here is error message from wx-config, in case that helps:
  
 Default config is gtk2-unicode-3.0 No config found to match: 
/usr/bin/wx-config --debug=no --toolkit=osx_cocoa --list in 
/usr/lib/i386-gnu/wx/config Please install the desired library build, or 
specify a different prefix where it may be found. If the library is not 
installed you may call its wx-config directly by specifying its full path. Also 
available in /usr: base-unicode-3.0 gtk2-unicode-3.0
  
  *
  configure: error: cannot proceed without suitable wxWidgets library

The kFreeBSD autobuilders still appear to be out of commission (or at
best heavily backlogged), but it looks like they'd run into the same
errors if they were to attempt to build lamarc.

In general, I expect the Linux/FreeBSD settings should make a much
more reasonable default for platforms the build system doesn't
specifically recognize than the settings for macOS, which is not so
mainstream.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Re: [Pkg-dns-devel] What to do with isc-dhcp-client-udeb?

[Ondřej Surý]

Hi KiBi,

I would also love to get rid of the isc-dhcp-client-udeb, but so far the 
message from the busybox team was that the dhcp client there doesn't compile 
there and needs some upstream work to get it working.

(As a matter of fact, the busybox doesn't compile at all on kfreebsd-* and 
hurd-i386 right now.)

As for the BIND libraries and libatomic.

There has been some effort to replace the custom atomic code with a C-provided 
counterpart - it also fixes the mips deadlocks.

But generally, I would prefer to move all BIND libraries into "custom" 
namespace, so the libraries are not used by anything else, and either:

a) use the custom copy of the libraries inside isc-dhcp
b) prepare separate package for the lib-udeb that would follow the 
BIND 9.11 development (BIND 9.11 is to be supported for next 4 years) and then 
remove those AND isc-dhcp from Debian.

The upcoming ISC-DHCP release 4.4.0 is ought to be the _last_ major upgrade, 
see: https://www.isc.org/blogs/isc-dhcp-the-last-branch/

And if porting udhcpc to kFreeBSD proves to be much work, then perhaps porting 
dhclient from OpenBSD might be an option?

Ondrej
-- 
Ondřej Surý 

On Mon, Jan 22, 2018, at 16:20, Cyril Brulebois wrote:
> Hi bind9 people,
> 
> I've just gotten this:
> 
> > Subject: udeb uninstallability trend: worse (+18/-)
> udeb uninstallability watcher  (2018-01-22):
> > Newly-broken packages in testing
> >   isc-dhcp-client-udeb armel mips mipsel
> >   libdns-export169-udebarmel mips mipsel
> >   libirs-export160-udebarmel mips mipsel
> >   libisc-export166-udebarmel mips mipsel
> >   libisccc-export160-udeb  armel mips mipsel
> >   libisccfg-export160-udeb armel mips mipsel
> > 
> > Uninstallability trend: worse (+18/-0)
> > Uninstallability count: 397
> 
> I happened to have missed its unstable counterpart, because those come in
> batches, depending on the current buildd status of packages. I thought the
> “Newly-broken” packages for armel, mips, and mipsel were an artifact of
> late builds.
> 
> I don't know anything about this libatomic1; but from a look at the 0013
> patch, it seems to be a need for a platform rather than for a feature…
> 
> Anyway, I'm not sure what to do with isc-dhcp-client-udeb; it's getting
> broken on a regular fashion, and its purpose was mainly for non-Linux
> ports AFAICR.
> 
> I'm not sure how BSD is doing these days; maybe hurd is the only user
> left?
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)