Re: lxqt-config: FTBFS on hurd-i386: udev not available

[Guillem Jover]

Hi!

On Mon, 2019-07-29 at 13:49:45 +0200, Paul Sonnenschein wrote:
> Package: lxqt-config
> Severity: important
> Version: 0.14.1-2
> Tags: patch
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> the package lxqt-config fails to build from source on hurd-i386 because
> udev is not available on non-linux (on kfreebsd-any, it is in state BD-
> Uninstallable).

> diff --git a/debian/rules b/debian/rules
> index 4f7c70d..81335e7 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -5,6 +5,12 @@ export LC_ALL=C.UTF-8
>  export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>  
> +WHICH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2>/dev/null)

The usual convention is to use the same name as the queried variable,
so «DEB_HOST_ARCH_OS = ...», but I think even better would be to just
do «include /usr/share/dpkg/architecture.mk» and then just use the
needed variables lazily defined there.

> +ifneq  ($(WHICH_OS), linux)
> +NOT_LINUX := -DWITH_TOUCHPAD=NO
> +endif

To make this variable reusable, I'd probably give it a system agnostic
name, I tend to use something like:

  confflags += -DWITH_TOUCHPAD=NO

so that it can be extended, w/o rendering the name invalid.

Thanks,
Guillem

Re: Bug#932258: console-setup-freebsd: missing dependency

[Guillem Jover]

On Wed, 2019-07-17 at 18:06:00 +0300, Anton Zinoviev wrote:
> On Wed, Jul 17, 2019 at 04:15:51PM +0200, Guillem Jover wrote:
> > this seems like a problem with console-setup-freebsd being arch:all 
> > and depending on kFreeBSD-specific packages which will not be 
> > available elsewhere, in the same way console-setup-linux is an 
> > arch:all depending on Linux-specific packages.
> 
> Why is it a problem to have an arch:all package which is installable 
> only on some architectures (due to missing dependencies)?

Because that's generally confusing for users, as they might not know
off-hand whether the unsatisfiable problem is due to a bug or it being
intended that way (even though it could be made very clear in the
Description). It also triggers all kind of alarms on automatic
dependency satisfiability checkers, which then need to be ignored
(like apparently this being the cause for thus bug report :). And
I guess in the metadata sense it seems wrong, as even though the
contents do not change across different architectures (so it has one
of the facets of an arch:all package) it is still not an archecture
indepdenent package (one of the other facets of an arch:all package).

Thanks,
Guillem

Re: Bug#932258: console-setup-freebsd: missing dependency

[Guillem Jover]

Hi!

[ I'm not sure this bug closure is entirely correct? See below. ]

On Wed, 2019-07-17 at 13:25:50 +0100, James Clarke wrote:
> On 17 Jul 2019, at 10:55, Holger Wansing  wrote:
> > Héctor Orón Martínez  (2019-07-17):
> > > Package: console-setup-freebsd
> > > Version: 1.191
> > > Severity: grave

> > >  console-setup-freebsd has a dependency on vidcontrol, which is not
> > > part of buster|bullseye|unstable, and causes the package to be
> > > uninstallable.

> > The same counts for kbdcontrol, also not existing in all suites.

> vidcontrol, and the rest of src:freebsd-utils, is available in unreleased,
> since the source package only builds for kfreebsd-amd64 and kfreebsd-i386.
> Avoiding this would require either getting the source package to build on 
> Linux
> architectures, or building at least one arch:all package, neither of which 
> seem
> to have much point to them. As an architecture on Debian Ports, it is expected
> that you also have the "unreleased" suite enabled, as is clearly documented on
> the main site[1]. This is especially important on kFreeBSD, since
> bin:freebsd-utils is Essential, containing many of the core utilities required
> for a functioning system. All ports buildds should have unreleased available,
> and debian-installer learnt over 2 years ago to include unreleased when
> downloading udebs. Thus, I consider this not a bug; as much as we would like 
> it
> to not be, as far as Debian Ports goes, unreleased is a necessary addition to
> unstable, with cases like these stemming from the fact that ftp-master does 
> not
> allow sources to exist that don't build packages for any of its architectures.

I'm not sure the report was noticed on a kFreeBSD system (and due to
the unreleased confusion), but otherwise this seems like a problem with
console-setup-freebsd being arch:all and depending on kFreeBSD-specific
packages which will not be available elsewhere, in the same way
console-setup-linux is an arch:all depending on Linux-specific packages.

The solution to the latter problem is to make these packages
Architecture kfreebsd-any and linux-any respectively, because even if
they are written in scripting languages they are not arch-independent.

Thanks,
Guillem

[RFC] The PIE unholy mess

[Guillem Jover]

Hi!

I'd like to get some feedback from porters and package maintainers,
given that this affects at least both groups. Some background first.

One of the reasons PIE has in the past not been enabled by default in
dpkg-buildflags, is because it introduced some slowness on some arches,
although this has somewhat changed recently. But also because
unconditionally setting it, breaks at least PIC builds. So PIE got
enabled recently by default in gcc, as it could easily control when it
is relevant. Although this has been done only for release architectures.

At about the same time this was being considered, I realized that dpkg
could enable this "safely" by using gcc specs files. But this is in
any case also required to be able to disable PIE when it is implicitly
enabled by default in gcc. So we'll need specs files no matter what,
at least for now.

While adapting dpkg-buildflags to cover for the new gcc defaults, I
unintentionally enabled PIE by default on all architectures, and when
I noticed, it seemed to make sense to leave it like that, because:

  * All previous build flags from dpkg-buildflags have always been
enabled globally and only blacklisted completely when they have
been non-functional.
  * It's a more consistent interface for packages, as they get built
with the same flags everywhere. Otherwise we'd get PIE enabled by
default in release arches, disabled by default elsewhere, and
enabled or disabled depending on the package requesting so.
  * It will mean that PIE coverage reporting will be shadowed in
lintian, because the tags only cover i386 and amd64, so maintainers
will probably stop enabling them globally.

Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
requesting to not enable PIE globally from dpkg-buildflags, and pretty
much immediately added a patch into gcc [P] to ignore dpkg-buildflags
PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
not enable PIE explicitly (I only fully understood the request after
seeing the gcc patch).

  [P] 


Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
does not even need to be exported from debian/rules, nor from the
dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
--export=configure or --export=cmdline. It's also a layer violation.
It also breaks unrelated stuff as now gcc emits notes when it thinks
the -specs option should not be passed. And while I could certainly
have started an arms-race by adding counter-measures by randomizing
the filenames or something similarly ugly, that'd be pretty much silly
and childish.

For better or worse, this does not affect the release architectures,
so by extension it should not affect the release, but it still sucks.

So, I'd like to know how people feel about the requested interface
(i.e. not enabling PIE globally from dpkg-buildflags). If there's
consensus that porters and maintainers want that, I'll just change
dpkg-buildflags to do this, even though I think it's a very
suboptiomal behavior.

Alternatively, porters could as well request PIE be enabled by default
in gcc on their port, which could make this also globally enabled.

Thanks,
Guillem

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Guillem Jover]

Hi!

On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> clone 845193 -1
> reassign -1 dpkg
> retitle -1 dpkg: please do not add -specs= flags only on some architectures
> thanks

I'm afraid I'll have to wontfix this because it is not really
implementable. See below… :/

> Guillem Jover dixit:
> >Those specs files should make it possible to build stuff with PIE
> 
> Yes, but they *do* break anything that
> - acts on the CFLAGS (and LDFLAGS) variables
> - uses klcc or other compiler wrappers that don't understand -specs
> - uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

> Worse, they break *differently* on whether…
> 
> >Precisely to make the behavior consistent on all architectures, dpkg
> >enables PIE (conditionally if no other flags marks it as to be
> >disabled) on all architectures were gcc has not enabled this by
> >default.
> 
> … that. And that is just plain wrong. Either dpkg should inject
> -specs= stuff on all architectures or on none. Differing like this
> just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

> Please get an agreement with the GCC maintainer on how to proceed
> from here.
>
> Personally, I’d still prefer for GCC to behave as on other systems,
> i.e. not to enable PIE by default, and to have it done completely
> within dpkg, but I can *also* live with it being done exclusively
> in GCC.
> 
> Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

> >Also BTW the gcc maintainer asked that porters
> >interested could request PIE to be enabled by default in gcc.
> 
> What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

> The two last quote sections make it clear that any architecture
> that currently has PIE enabled in dpkg should have it enabled in
> GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

> (Did dpkg enable that on porters’ requests?
> It does not look like that to me. This smells like overstepping
> boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

> tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
> as long as only one does it. FFS, just enable it on all of them
> unless known to absolutely not work; that’d still be better than
> the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Re: Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename

[Guillem Jover]

Hi!

On Fri, 2016-06-10 at 02:20:15 +0100, Steven Chamberlain wrote:
> Package: uid-wrapper
> Version: 1.2.0+dfsg1-1
> Severity: normal
> Tags: patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd

> I found this happens because src/uid_wrapper.c doesn't detect the libc's
> filename.  It matches libc.so.[0-9] whereas on kfreebsd it is named
> libc.so.0.1 currently.
> 
> The same problem will affect hurd too, which has libc.so.0.3 (although
> there are other reasons for FTBFS on hurd).
> 
> Please consider the attached patch to detect libc.so.0.[0-9] as well.
> Unless there is some neater way to do this.  Thanks a lot!

Yeah, I think the initial approach is just wrong. Consider if we ever
had an (unlikely) SONAME bump for libc, the library might end up linked
against libc.so.7 and the code loading libc.so.6. Depending on the
intended usage there are possibly better ways to achieve that.

If the library is supposed to be pre-loaded then using RTLD_NEXT as
the handle is way better, and avoids having to use an explicit library
name.

If it's not, on GNU systems we can always use LIBC_SO and LIBPTHREAD_SO
from , for example. Otherwise on non-GNU ELF systems,
we could link a small program and then readelf (or objdump) it to find
the NEEDED entry for libc. Or we could also try to readlink the libc.so
symlink and make sure it's an ELF object at build time to try to get the
SONAME (this will fail on at least GNU systems as the libc.so is a linker
script there).

Thanks,
Guillem

Re: Bug#811315: getdns: FTBFS[kfreebsd]: needs getentropy implementation

[Guillem Jover]

Control: forwarded -1 https://github.com/getdnsapi/getdns/pull/182

On Mon, 2016-01-18 at 13:59:00 +, Steven Chamberlain wrote:
> Guillem Jover wrote:
> > Steven Chamberlain wrote:
> > > getdns FTBFS on kfreebsd because it lacks a getentropy implementation
> > > for the FreeBSD kernel.  But there is one already in LibreSSL Portable
> > > we can use, and works fine here.
> > 
> > BTW, libbsd has also a getentropy(3) implementation (lifted too from
> > LibreSSL), which is currently not exposed but if people want to use it
> > I could make it public, instead of embedding this in all sorts of
> > places. The difference being that libbsd is already in Debian, while
> > LibreSSL is not.
> > 
> >   <http://cgit.freedesktop.org/libbsd/tree/src>

> I think the only use case for getentropy is arc4random, so perhaps don't
> export getentropy(3), but lets try to standardise on one implementation
> of arc4random (in libbsd?) and try to get more people using that?
> 
> It would be nice to have the kernel-specific parts (getentropy) confined
> to libbsd, and that may become even more important if applications start
> sandboxing (e.g. can't read /dev/urandom any more, have to use sysctls).
> Or if getrandom(2) becomes standard, we'd only need to implement it in
> one place (as a supplement / eventual replacement to getentropy(3)).

Sure, I've now implemented this and sent a pull request to upstream,
plus the required packaging bits, attached here both for convenience.

Thanks,
Guillem
diff --git i/debian/control w/debian/control
index 8b27205..ffa1c40 100644
--- i/debian/control
+++ w/debian/control
@@ -8,6 +8,7 @@ Build-Depends: autotools-dev,
check,
debhelper (>= 9),
dh-autoreconf,
+   libbsd-dev,
libev-dev,
libevent-dev,
libexpat-dev,
From 1fb763761b90c3269d818a736a6c81469b89629d Mon Sep 17 00:00:00 2001
From: Guillem Jover <guil...@hadrons.org>
Date: Thu, 9 Jun 2016 01:55:07 +0200
Subject: [PATCH] Use libbsd when available

Use the libbsd (https://libbsd.freedesktop.org/) overlay to transparently
use the bsd compatibility layer without needing any actual code changes.

Remove now unnecessary direct access to libbsd includes. And remove
checks for unused functions.
---
 configure.ac | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index a471327..0807f01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -238,7 +238,7 @@ if grep VERSION_TEXT $ssldir/include/openssl/opensslv.h | grep "LibreSSL" >/dev/
 	AC_DEFINE([HAVE_LIBRESSL], [1], [Define if we have LibreSSL])
 	# libressl provides these compat functions, but they may also be
 	# declared by the OS in libc.  See if they have been declared.
-	AC_CHECK_DECLS([strlcpy,strlcat,arc4random,arc4random_uniform,reallocarray])
+	AC_CHECK_DECLS([strlcpy,arc4random,arc4random_uniform])
 else
 	AC_MSG_RESULT([no])
 fi
@@ -928,7 +928,7 @@ dnl - Start of "Things needed for gldns" section
 dnl -
 dnl ---
 
-AC_CHECK_HEADERS([stdarg.h stdint.h netinet/in.h arpa/inet.h netdb.h sys/socket.h time.h sys/time.h bsd/string.h sys/select.h],,, [AC_INCLUDES_DEFAULT])
+AC_CHECK_HEADERS([stdarg.h stdint.h netinet/in.h arpa/inet.h netdb.h sys/socket.h time.h sys/time.h sys/select.h],,, [AC_INCLUDES_DEFAULT])
 
 dnl Check the printf-format attribute (if any)
 dnl result in HAVE_ATTR_FORMAT.  
@@ -967,6 +967,14 @@ AC_MSG_RESULT($ac_cv_c_unused_attribute)
 if test $ac_cv_c_unused_attribute = yes; then
   AC_DEFINE(HAVE_ATTR_UNUSED, 1, [Whether the C compiler accepts the "unused" attribute])
 fi
+# Check for libbsd, so that the next function checks pick it as their
+# system implementation.
+PKG_CHECK_MODULES([LIBBSD],[libbsd-overlay],[
+LIBS="$LIBS $LIBBSD_LIBS"
+CFLAGS="$CFLAGS $LIBBSD_CFLAGS"
+],[
+AC_MSG_WARN([libbsd not found or usable; using embedded code instead])
+])
 AC_CHECK_DECLS([strlcpy,arc4random,arc4random_uniform])
 AC_REPLACE_FUNCS(inet_pton)
 AC_REPLACE_FUNCS(inet_ntop)
@@ -1050,10 +1058,6 @@ AH_BOTTOM([
 #include 
 #include 
 
-#ifdef HAVE_BSD_STRING_H
-#include 
-#endif
-
 /* the version of the windows API enabled */
 #ifndef WINVER
 #define WINVER 0x0600 // 0x0502
-- 
2.8.1

Bug#816764: zfsutils: Could be switched to use system libmd

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sat, 2016-03-05 at 00:30:23 +0100, Guillem Jover wrote:
> Source: zfsutils
> Source-Version: 10.1~svn272500-1
> Severity: wishlist

> I noticed that this package contains an embedded version of libmd from
> FreeBSD. This package could be switched to use the now packaged libmd
> from the system.

I've implemented this now, but not build-tested it, just made sure the
patch applies. Attached.

Alos next time an upstream source is pulled the lib/libmd should
disappear from the source tarball, didn't consider it worth it to
remove that in a patch.

Thanks,
Guillem
Index: debian/control
===
--- debian/control	(revision 6065)
+++ debian/control	(working copy)
@@ -10,6 +10,7 @@
 Build-Depends: debhelper (>= 7.0.50~),
  freebsd-buildutils (>= 9.0-5~),
  libbsd-dev (>= 0.3.0),
+ libmd-dev,
  libc0.1-dev (>= 2.10),
  kfreebsd-kernel-headers (>= 10.1~4~),
  libgeom-dev,
Index: debian/patches/disable_libjail.diff
===
--- debian/patches/disable_libjail.diff	(revision 6065)
+++ debian/patches/disable_libjail.diff	(working copy)
@@ -1,7 +1,7 @@
 --- a/cddl/sbin/zfs/Makefile
 +++ b/cddl/sbin/zfs/Makefile
 @@ -1,5 +1,7 @@
- # $FreeBSD$
+ # $FreeBSD: releng/10.1/cddl/sbin/zfs/Makefile 248571 2013-03-21 08:38:03Z mm $
  
 +.include 
 +
Index: debian/patches/makefile.diff
===
--- debian/patches/makefile.diff	(revision 6065)
+++ debian/patches/makefile.diff	(working copy)
@@ -16,7 +16,7 @@
  DPADD=	${LIBMD} ${LIBPTHREAD} ${LIBUMEM} ${LIBUTIL} ${LIBM} ${LIBNVPAIR} \
  	${LIBAVL} ${LIBZFS_CORE}
 -LDADD=	-lmd -lpthread -lumem -lutil -lavl -lzfs_core
-+LDADD=	${.CURDIR}/../../../lib/libmd/libmd.a -lpthread -lumem -lzfs_core
++LDADD=	-lmd -lpthread -lumem -lzfs_core
 +
 +LDADD+= -lbsd -lm -luutil -lnvpair -lgeom
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libzfs_core
@@ -26,28 +26,18 @@
  
  SRCS=	deviceid.c \
  	fsshare.c \
-@@ -58,5 +64,6 @@
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libuutil/common
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libzfs/common
- CFLAGS+= -I${.CURDIR}/../../../cddl/contrib/opensolaris/lib/libzfs_core/common
-+CFLAGS+= -I${.CURDIR}/../../../lib/libmd
- 
- .include 
 --- a/cddl/lib/libzpool/Makefile
 +++ b/cddl/lib/libzpool/Makefile
-@@ -57,7 +57,14 @@
+@@ -57,7 +57,11 @@
  CFLAGS+=	-I${.CURDIR}/../../../lib/libthr/arch/${MACHINE_CPUARCH}/include
  
  DPADD=		${LIBMD} ${LIBPTHREAD} ${LIBZ}
 -LDADD=		-lmd -lpthread -lz -lumem -lnvpair -lavl
-+LDADD=		 -lpthread -lz -lumem -lnvpair -lavl-illumos -lbsd -lrt
++LDADD=		-lmd -lpthread -lz -lumem -lnvpair -lavl-illumos -lbsd -lrt
 +
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libumem
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libnvpair
 +LDADD+= -L${.CURDIR}/../../../cddl/lib/libavl
-+
-+CFLAGS+= -I${.CURDIR}/../../../lib/libmd
-+LDADD+= ${.CURDIR}/../../../lib/libmd/libmd.a
  
  # atomic.S doesn't like profiling.
  NO_PROFILE=
Index: debian/rules
===
--- debian/rules	(revision 6065)
+++ debian/rules	(working copy)
@@ -71,7 +71,6 @@
 		 cddl/contrib/opensolaris/cmd/stat/common/ \
 	 sys/cddl/compat/opensolaris \
 	 sys/cddl/contrib/opensolaris \
-		lib/libmd \
 	 cddl/lib/libavl \
 	 cddl/lib/libnvpair \
 	 cddl/lib/libuutil \
@@ -92,7 +91,7 @@
 
 build: build-arch build-indep
 
-build-arch: build-libmd build-libuutil build-libnvpair build-libzfs build-libumem build-libzpool build-zfsutils build-libavl
+build-arch: build-libuutil build-libnvpair build-libzfs build-libumem build-libzpool build-zfsutils build-libavl
 
 build-indep:
 # We have nothing to do by default.
@@ -115,7 +114,7 @@
 
 
 build-libzpool: build-libzpool-stamp
-build-libzpool-stamp: build-libavl build-libnvpair-stamp build-libumem build-libmd
+build-libzpool-stamp: build-libavl build-libnvpair-stamp build-libumem
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libzpool
 	touch $@
 
@@ -134,11 +133,6 @@
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libzfs_core
 	touch $@
 
-build-libmd: build-libmd-stamp
-build-libmd-stamp:
-	$(PMAKE) -C $(CURDIR)/lib/libmd
-	touch $@
-
 build-libavl: build-libavl-stamp
 build-libavl-stamp:
 	$(PMAKE) -C $(CURDIR)/cddl/lib/libavl
@@ -176,7 +170,6 @@
 	$(PMAKE) -C $(CURDIR)/cddl/usr.sbin/zdb clean
 	$(PMAKE) -C $(CURDIR)/cddl/usr.bin/ztest clean
 	$(PMAKE) -C $(CURDIR)/cddl/usr.bin/zinject clean
-	$(PMAKE) -C $(CURDIR)/lib/libmd clean
 
 	rm -f *stamp
 	dh_clean

Bug#820151: kfreebsd-10: non-DFSG mode (for ubuntuBSD)

[Guillem Jover]

Hi!

On Tue, 2016-04-05 at 23:17:08 +0200, Jon Boden wrote:
> Package: kfreebsd-10
> Version: 10.1~svn274115-4+kbsd8u3
> Severity: wishlist
> Tags: patch

> This patch has no effect on Debian but it enables "non-DFSG mode" when
> compiling kfreebsd-10 on ubuntuBSD. Please could you apply it to make
> it easier for us to resync with kfreebsd-10?

Is this acceptable for the Ubuntu archive? In any case that's
something for the current kFreeBSD manintainers to agree with.

> Index: debian/control.in
> ===
> --- debian/control.in (revision 5986)
> +++ debian/control.in (working copy)
> @@ -23,6 +23,7 @@
>   pkg-config,
>   libsbuf-dev (>= 9.0+ds1-2),
>   kernel-wedge (>= 2.79) [kfreebsd-any],
> + lsb-release,

You don't need this, see below…

>  Standards-Version: 3.9.2
>  
>  Package: kfreebsd-source-@version@
> Index: debian/rules
> ===
> --- debian/rules  (revision 5986)
> +++ debian/rules  (working copy)
> @@ -23,7 +23,13 @@
>  configfile   := DEBCUSTOM
>  abiname  := 0
>  ld_target:= $(shell ld --help | sed -ne "s/[^ :]*: supported targets: 
> \([^ ]*\) .*/\1/p")
> +distributor  := $(shell lsb_release -is || echo Debian)

…you can use dpkg-vendor instead, which does not need any additional
build dependency.

Thanks,
Guillem

Bug#816764: zfsutils: Could be switched to use system libmd

[Guillem Jover]

Source: zfsutils
Source-Version: 10.1~svn272500-1
Severity: wishlist

Hi!

I noticed that this package contains an embedded version of libmd from
FreeBSD. This package could be switched to use the now packaged libmd
from the system.

Thanks,
Guillem

Bug#609757: ITP: libmd -- Message Digest functions from BSD systems

[Guillem Jover]

Control: reassign -1 wnpp
Control: retitle -1 ITP: libmd -- Message Digest functions from BSD systems
Control: severity -1 wishlist
Control: owner -1 !

Hi!

On Mon, 2011-06-27 at 00:02:51 +0200, Guillem Jover wrote:
> Few reasons, one has been because libmd is more generic than something
> like libsbuf and it's prone to be used more widely than anything in
> freebsd-libs, so it might make sense to promote it to standard or
> higher for example. The other reason is that the licenses in the
> FreeBSD tree are a bit unfortunate so my plan is to use the OpenBSD
> implementation instead.
> 
> Just have to commit my latest changes.

Ok, I'm in the process of releasing libmd upstream, and will proceed
with the upload to Debian. Here's the ITP information:

  * Package name: libmd
  * Version : 0.0.0
  * URL : https://www.hadrons.org/software/libmd/
  * License : BSD-3, BSD-2, ISC, Beerware, PD
  * Description : Message Digest functions from BSD systems

Regards,
Guillem

Re: Bug#811315: getdns: FTBFS[kfreebsd]: needs getentropy implementation

[Guillem Jover]

Hi!

On Sun, 2016-01-17 at 21:42:03 +, Steven Chamberlain wrote:
> Package: getdns
> Version: 0.9.0-1
> Severity: normal
> Tags: patch

> getdns FTBFS on kfreebsd because it lacks a getentropy implementation
> for the FreeBSD kernel.  But there is one already in LibreSSL Portable
> we can use, and works fine here.

BTW, libbsd has also a getentropy(3) implementation (lifted too from
LibreSSL), which is currently not exposed but if people want to use it
I could make it public, instead of embedding this in all sorts of
places. The difference being that libbsd is already in Debian, while
LibreSSL is not.

  

Thanks,
Guillem

Re: Defaulting to i686 for the Debian i386 architecture

[Guillem Jover]

On Thu, 2015-10-01 at 19:15:54 +0200, Matthias Klose wrote:
> question to the Hurd and KFreeBSD maintainers ... change that on these
> platforms too?

As it currently stands, this is not a question when it comes to
dpkg, that specific change is all or nothing. The Debian ←→ GNU
cpu mapping is global for all architectures.

But as I've mentioned several times now, I think changing the GNU
triplet (only on i386) every time we bump the ISA is the wrong way
around this, and the above is another reason of why, but this has
been ignored in the past so… you'll have to sort this out.

Thanks,
Guillem

Re: kernel on buildd (Re: [Glibc-bsd-commits] r5714 - trunk/glibc-ports/kfreebsd/bits)

[Guillem Jover]

Hey Steven!

On Thu, 2015-05-28 at 22:22:06 +0100, Steven Chamberlain wrote:
 Guillem Jover wrote:
  In any case here's the patches I've prepared to send upstream. Only
  build tested, though.
 
 Thanks for this.

Thank you for the review and testing.

 Patch 1 would have been a good workaround for Debian sid, if Andreas
 had accepted it, but I don't think it should be permanent or go
 upstream.  I don't like to special-case kfreebsd in code except in
 places we really have to, and it's actually wrong for FreeBSD = 9
 (though they're not a user of util-linux).

This allows using the value even if the build system does not know
about it, either because we are building on an old system or because
the libc is not up-to-date. For FreeBSD = 9, it should be handled
by the run-time checks, so it should fallback to the other codepath.
I can reorder the patches so that this makse more sense.

In any case I think I'll just send it upstream and let them decide if
they want to carry it or not. Or did you mean something else with the
comment that it is wrong (I would not expect the value to have been
reused for example)?

 Patches 2 and 3 look good to go upstream as they benefit other systems
 not having fcntl.h or F_DUPFD_CLOEXEC (and older kfreebsd).

Sure.

 They make patch 1 unnecessary?

Well, partially I guess, if the library is being used by threaded
applications that fork, then they might end up leaking if the library
got built on an old system, but is run on a newer one.

 I tested your fallback code and it is working (duplicates the fd and
 sets FD_CLOEXEC).  Without F_DUPFD_CLOEXEC I get a compiler warning
 about unused lowfd, but that doesn't really matter here.

Cool, thanks. Sending them upstream now.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605173357.ga30...@gaara.hadrons.org

Re: kernel on buildd (Re: [Glibc-bsd-commits] r5714 - trunk/glibc-ports/kfreebsd/bits)

[Guillem Jover]

Hi!

On Thu, 2015-05-28 at 09:00:41 +0200, Petr Salinger wrote:
 what is currently used kernel on buildd for kfreebsd-* ?
 
 According to last log of util-linux (22 May 2015/fayrfax.debian.org):
 Kernel: GNU/kFreeBSD 9.0-2-amd64 kfreebsd-amd64 (x86_64)
 
 Please beware, that F_DUPFD_CLOEXEC is not supported on this kernel.
 The addition of F_DUPFD_CLOEXEC bellow is long term way, but in mean time
 (until buildd is upgraded to 10.x), we need to use fallback to previous code
 path in util-linux.

That might be needed only if that code path is executed on the buildds,
something I'm not sure about.

In any case here's the patches I've prepared to send upstream. Only
build tested, though.

Thanks,
Guillem
From e8cfe3d17d61e19203445cbf96a136fad30fc05a Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@hadrons.org
Date: Thu, 28 May 2015 17:46:02 +0200
Subject: [PATCH 1/3] include/c: Define F_DUPFD_CLOEXEC on kFreeBSD systems if
 missing

The kernel of FreeBSD version 10 and higher supports this fcntl command,
but the system libc, in this case glibc, might not yet know about it.

Signed-off-by: Guillem Jover guil...@hadrons.org
---
 include/c.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/c.h b/include/c.h
index a72e264..1eda75f 100644
--- a/include/c.h
+++ b/include/c.h
@@ -231,6 +231,12 @@ static inline int dirfd(DIR *d)
 #define O_CLOEXEC 0
 #endif
 
+#ifdef __FreeBSD_kernel__
+#ifndef F_DUPFD_CLOEXEC
+#define F_DUPFD_CLOEXEC	17	/* Like F_DUPFD, but FD_CLOEXEC is set */
+#endif
+#endif
+
 
 #ifndef AI_ADDRCONFIG
 #define AI_ADDRCONFIG 0x0020
-- 
2.2.1.209.g41e5f3a

From 0267c0f4e739b788a90500446173585502e6ddb3 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@hadrons.org
Date: Thu, 28 May 2015 17:51:09 +0200
Subject: [PATCH 2/3] lib/fileutils: Add new dup_fd_cloexec function

This function duplicates and marks a file descriptor as close-on-exec.
Takes care of build and run-time support for the fcntl F_DUPFD_CLOEXEC
command, and other errors.

Signed-off-by: Guillem Jover guil...@hadrons.org
---
 include/fileutils.h |  1 +
 lib/fileutils.c | 30 ++
 2 files changed, 31 insertions(+)

diff --git a/include/fileutils.h b/include/fileutils.h
index 3353f69..e0e2ece 100644
--- a/include/fileutils.h
+++ b/include/fileutils.h
@@ -25,6 +25,7 @@ static inline FILE *xfmkstemp(char **tmpname, char *dir)
 	return ret;
 }
 
+extern int dup_fd_cloexec(int oldfd, int lowfd);
 extern int get_fd_tabsize(void);
 
 extern int mkdir_p(const char *path, mode_t mode);
diff --git a/lib/fileutils.c b/lib/fileutils.c
index bffa8ff..81b38ad 100644
--- a/lib/fileutils.c
+++ b/lib/fileutils.c
@@ -50,6 +50,36 @@ int xmkstemp(char **tmpname, char *dir)
 	return fd;
 }
 
+int dup_fd_cloexec(int oldfd, int lowfd)
+{
+	int fd, flags, errno_save;
+
+#ifdef F_DUPFD_CLOEXEC
+	fd = fcntl(oldfd, F_DUPFD_CLOEXEC, lowfd);
+	if (fd = 0)
+		return fd;
+#endif
+
+	fd = dup(oldfd);
+	if (fd  0)
+		return fd;
+
+	flags = fcntl(fd, F_GETFD);
+	if (flags  0)
+		goto unwind;
+	if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC)  0)
+		goto unwind;
+
+	return fd;
+
+unwind:
+	errno_save = errno;
+	close(fd);
+	errno = errno_save;
+
+	return -1;
+}
+
 /*
  * portable getdtablesize()
  */
-- 
2.2.1.209.g41e5f3a

From 53e0536299ae17540a465fe3f71a636676abb965 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@hadrons.org
Date: Thu, 28 May 2015 17:52:33 +0200
Subject: [PATCH 3/3] lib/sysfs: Use dup_fd_cloexec instead of direct call to
 fcntl

Signed-off-by: Guillem Jover guil...@hadrons.org
---
 lib/sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/sysfs.c b/lib/sysfs.c
index 1ea2e77..975e264 100644
--- a/lib/sysfs.c
+++ b/lib/sysfs.c
@@ -265,7 +265,7 @@ DIR *sysfs_opendir(struct sysfs_cxt *cxt, const char *attr)
 		 * -- we cannot use cxt-sysfs_fd directly, because closedir()
 		 * will close this our persistent file descriptor.
 		 */
-		fd = fcntl(cxt-dir_fd, F_DUPFD_CLOEXEC, STDERR_FILENO + 1);
+		fd = dup_fd_cloexec(cxt-dir_fd, STDERR_FILENO + 1);
 
 	if (fd  0)
 		return NULL;
-- 
2.2.1.209.g41e5f3a

Bug#787042: util-linux: FTBFS on kFreeBSD due to missing F_DUPFD_CLOEXEC

[Guillem Jover]

Source: util-linux
Source-Version: 2.26.2-5
Severity: important
Tags: patch
X-Debbugs-Cc: debian-bsd@lists.debian.org

Hi!

Here's a patch to fix the FTBFS on kFreeBSD systems. I've gone with
the quick fix (partially lifted from Steven proposal for glibc) that
will work only with very recent kFreeBSD versions, instead of changing
the fcntl() call to fallback to set cloexec in a separate call, just
to get the packages building and unclog the buildd queues, which seem
to be piling up.

Tested to build successfully on kfreebsd-amd64.

Thanks,
Guillem
---
 include/c.h |6 ++
 1 file changed, 6 insertions(+)

--- a/include/c.h
+++ b/include/c.h
@@ -231,6 +231,12 @@ static inline int dirfd(DIR *d)
 #define O_CLOEXEC 0
 #endif
 
+#ifdef __FreeBSD_kernel__
+#ifndef F_DUPFD_CLOEXEC
+#define F_DUPFD_CLOEXEC	17	/* Like F_DUPFD, but FD_CLOEXEC is set */
+#endif
+#endif
+
 
 #ifndef AI_ADDRCONFIG
 #define AI_ADDRCONFIG 0x0020

Re: [PATCH] PR target/48904 x86_64-knetbsd-gnu missing defs

[Guillem Jover]

Hi!

On Thu, 2015-04-30 at 09:58:28 +0200, Bernhard Reutner-Fischer wrote:
 On 30 April 2015 at 07:00, Jeff Law l...@redhat.com wrote:
  On 04/29/2015 02:01 AM, Bernhard Reutner-Fischer wrote:
 
  2012-09-21  H.J. Lu  hongjiu...@intel.com
 
  PR target/48904
  * config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
  * config/i386/knetbsd-gnu64.h: New file
 
  OK.  Please install on the trunk.
 
 hmz, according to https://www.debian.org/ports/netbsd/ the debian
 knetbsd port is abandoned since about 2002.

Actually that page refers to the GNU/NetBSD port, which was based on
NetBSD's libc, the GNU/kNetBSD port (based on glibc), was started at
the same time as GNU/kFreeBSD but was short-lived and put into
hibernation to try to focus the effort on GNU/kFreeBSD. But that
has been a very long winter…

 If this is true (please confirm) then we should probably remove knetbsd from
 - upstream config repo
 - GCC
 - binutils-gdb

The difference between removing support in the toolchain and in the
upstream config repo is that for the former it will just need forward
porting the patches, but for the latter it takes a very long time and
lots of prodding to get upstream projects to update to current config.*
scripts. (In Debian we have been switching to always update the config.*
scripts at build time so it would probably not be too bad going forward
for us, but it would when using projects directly from upstream.)

Although I always find it a bit sad to remove ports support, I have the
impression the GNU/kNetBSD port is not coming to live any time soon. So
you might want to wait a bit for comments from others, perhaps someone
has been working on such port that we are not aware of, but otherwise I
think removal would be fine.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150430144920.ga11...@gaara.hadrons.org

Re: Bug#779467: dpkg: start-stop-daemon sometimes exits with _cpu_tick_frequency: no such symbol on kFreeBSD

[Guillem Jover]

Hi!

On Sat, 2015-02-28 at 18:21:13 -0600, Jeff Epler wrote:
 Package: dpkg
 Version: 1.17.23+local1
 Severity: important
 Tags: patch

 On a Debian Jessie kFreeBSD system, start-stop-daemon sometimes exits with
 an odd error:
 
 $ sudo service nfsd restart
 start-stop-daemon: _cpu_tick_frequency: no such symbol
 
 The specific command invocation which was reliably printing the error
 for me was:
 # start-stop-daemon --stop --quiet --retry=USR1/30/KILL/5 --name nfsd
 start-stop-daemon: _cpu_tick_frequency: no such symbol
 
 This turns out to be due to file descriptor exhaustion due to calls to
 kvm_openfiles without balancing calls to kvm_close, which is fixed by the
 attached patch.

Right, I had some branch around reworking that code, doing kvm_close()
calls, but I seem to have lost it somehow. In any case here's a minimal
patch that should fix it too. I've not been able to reproduce it, so
it would be nice if you could try it out.

I'll probably try to get this into 1.17.25 targetting jessie.

Thanks,
Guillem
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 6aebe9b..7ae4a7f 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -1247,9 +1247,12 @@ get_proc_stat(pid_t pid, ps_flags_t flags)
 static kvm_t *
 ssd_kvm_open(void)
 {
-	kvm_t *kd;
+	static kvm_t *kd;
 	char errbuf[_POSIX2_LINE_MAX];
 
+	if (kd)
+		return kd;
+
 	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
@@ -1795,8 +1798,6 @@ do_procinit(void)
 			prog_status = pid_status;
 	}
 
-	kvm_close(kd);
-
 	return prog_status;
 }
 #endif

Re: Pre-Depends changed for dpkg on GNU/kFreeBSD

[Guillem Jover]

On Sat, 2014-10-04 at 23:59:25 +0200, Guillem Jover wrote:
 On Fri, 2014-10-03 at 04:45:13 +0200, Guillem Jover wrote:
  On Thu, 2014-10-02 at 22:03:37 +0100, Steven Chamberlain wrote:
   No problem.  Does that mean you'd happily revert to using linprocfs?
  
  If there's no better option, yes. Right now I'm thinking to merge
  the attached patch for 1.17.14 as a hotfix, and then switch to a pure
  sysctl(2) implementation for 1.17.15, so that we can get rid of the
  libkvm dependency. Otherwise revert to linprocfs. Does that sound good?
 
 Something else I just realized now is that libkvm pulls in libbsd and
 libfreebsd-glue into the pseudo-essential set on GNU/kFreeBSD, which
 makes the situation a bit worse. So as stated above I'll be switching
 to sysctl(2) later on, but I'm open to a revert if this is deemed
 problematic too. Thanks for input Steven!

s-s-d only needs struct kinfo_proc (either when using libkvm or
sysctl(3)), so I just did a bit of digging and it seems the last time
ABI was broken for that struct was around 2005. It seems since then
upstream has gotten lots better, and added unused space to be claimed
whenever the need arises. I'd expect them to switch to a new MIB in
case they break ABI for that struct again, as they did with kinfo_file.

I'm thinking that I could also make the code fallback to linprocfs at
run-time in case the ki_structsize member differs from the size known
at build time, which would give an additional safe guard, in case the
above does not hold true.

On Sun, 2014-10-05 at 08:54:41 +0200, Sven Joachim wrote:
 On 2014-10-04 23:59 +0200, Guillem Jover wrote:
 
  Something else I just realized now is that libkvm pulls in libbsd and
  libfreebsd-glue into the pseudo-essential set on GNU/kFreeBSD, which
  makes the situation a bit worse.
 
 Both libbsd and libfreebsd-glue are already pulled in by freebsd-utils.

Ah, right, thanks Sven for looking it up, still given that libkvm can
be easily avoided, I think it's fine to get rid of it from the
pseudo-essential set.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141008104716.gb9...@gaara.hadrons.org

Re: Pre-Depends changed for dpkg on GNU/kFreeBSD

[Guillem Jover]

Hi!

On Fri, 2014-10-03 at 04:45:13 +0200, Guillem Jover wrote:
 After checking the s-s-d and libkvm code again now, it seems it does
 not require any kvm_read(3) at all, so /dev/mem should not be needed
 either, could you try the attached patch on a jail? (I need to recover
 my damaged GNU/kFreeBSD system, as now I only have access to porter
 boxes. :/ )

I just reinstalled my GNU/kFreeBSD system and I tested it outside a
jail, and ktrace tells me it does not access /dev/mem anymore.

I've also fixed an issue when kvm_getprocs(3) does not find any pid,
which might have also been involved in the errors you where seeing.

 On Thu, 2014-10-02 at 22:03:37 +0100, Steven Chamberlain wrote:
  No problem.  Does that mean you'd happily revert to using linprocfs?
 
 If there's no better option, yes. Right now I'm thinking to merge
 the attached patch for 1.17.14 as a hotfix, and then switch to a pure
 sysctl(2) implementation for 1.17.15, so that we can get rid of the
 libkvm dependency. Otherwise revert to linprocfs. Does that sound good?

Something else I just realized now is that libkvm pulls in libbsd and
libfreebsd-glue into the pseudo-essential set on GNU/kFreeBSD, which
makes the situation a bit worse. So as stated above I'll be switching
to sysctl(2) later on, but I'm open to a revert if this is deemed
problematic too. Thanks for input Steven!

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141004215925.ga18...@gaara.hadrons.org

Pre-Depends changed for dpkg on GNU/kFreeBSD

[Guillem Jover]

Hi!

In dpkg 1.17.13 I switched start-stop-daemon on GNU/kFreeBSD to use
the native kFreeBSD backend using libkvm instead of using the Linux
backend through linprocfs. Requiring linprocfs has always seemed
somewhat wrong to me, more so when on FreeBSD procfs is actually
optional.

This means the library is now part of dpkg's Pre-Depends only on
GNU/kFreeBSD. But I forgot to bring it up here as per policy §3.5
before the upload. Doing so now, but if there's no consensus, I'll
revert the change. Sorry about that.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002173402.ga15...@gaara.hadrons.org

Re: Pre-Depends changed for dpkg on GNU/kFreeBSD

[Guillem Jover]

On Thu, 2014-10-02 at 22:03:37 +0100, Steven Chamberlain wrote:
 On 19:34, Guillem Jover wrote:
  In dpkg 1.17.13 I switched start-stop-daemon on GNU/kFreeBSD to use
  the native kFreeBSD backend using libkvm instead of using the Linux
  backend through linprocfs.
 
 Ahhh I did wonder about that.  start-stop-daemon had problems inside
 of jails due to this;  KVM needs /dev/mem, and that usually should not
 be available inside a jail.

Oh, feel free to file a bug in the future if any such regressions
happen again.

After checking the s-s-d and libkvm code again now, it seems it does
not require any kvm_read(3) at all, so /dev/mem should not be needed
either, could you try the attached patch on a jail? (I need to recover
my damaged GNU/kFreeBSD system, as now I only have access to porter
boxes. :/ )

  Requiring linprocfs has always seemed
  somewhat wrong to me, more so when on FreeBSD procfs is actually
  optional.
 
 I'm usually uncomfortable seeing userland use libkvm to look at kernel
 internals, because unlike FreeBSD, we need to support mismatching
 versions of kernel and userland (e.g. sid chroot on the stable buildds).

Sure, although because in this case the code will not end up using
kvm_read(3), only stuff returned by sysctl(2), it should be safer, or
is that not guaranteed to be compatible either between major versions?

 Most of Debian GNU userland expects linprocfs so, even though it seems
 kind of lame to a FreeBSD person, it's useful to us as a psuedo-standard
 interface that is always available (including jails and any properly-
 constructed chroot).

Still, I'd prefer for s-s-d not to be the one requiring this.

  This means the library is now part of dpkg's Pre-Depends only on
  GNU/kFreeBSD. But I forgot to bring it up here as per policy §3.5
  before the upload. Doing so now, but if there's no consensus, I'll
  revert the change. Sorry about that.
 
 No problem.  Does that mean you'd happily revert to using linprocfs?

If there's no better option, yes. Right now I'm thinking to merge
the attached patch for 1.17.14 as a hotfix, and then switch to a pure
sysctl(2) implementation for 1.17.15, so that we can get rid of the
libkvm dependency. Otherwise revert to linprocfs. Does that sound good?

Thanks,
Guillem
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index fd08b94..e97e86c 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -103,6 +103,11 @@
 
 #ifdef HAVE_KVM_H
 #include kvm.h
+#if defined(OSFreeBSD)
+#define KVM_MEMFILE /dev/null
+#else
+#define KVM_MEMFILE NULL
+#endif
 #endif
 
 #ifdef _POSIX_PRIORITY_SCHEDULING
@@ -1324,7 +1329,7 @@ pid_is_exec(pid_t pid, const struct stat *esb)
 	char **pid_argv_p;
 	char *start_argv_0_p, *end_argv_0_p;
 
-	kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
 	kp = kvm_getprocs(kd, KERN_PROC_PID, pid, nentries);
@@ -1413,7 +1418,7 @@ pid_is_child(pid_t pid, pid_t ppid)
 	char errbuf[_POSIX2_LINE_MAX];
 	pid_t proc_ppid;
 
-	kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
 	kp = kvm_getprocs(kd, KERN_PROC_PID, pid, nentries);
@@ -1475,7 +1480,7 @@ pid_is_user(pid_t pid, uid_t uid)
 	struct kinfo_proc *kp;
 	char errbuf[_POSIX2_LINE_MAX];
 
-	kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
 	kp = kvm_getprocs(kd, KERN_PROC_PID, pid, nentries);
@@ -1562,7 +1567,7 @@ pid_is_cmd(pid_t pid, const char *name)
 	struct kinfo_proc *kp;
 	char errbuf[_POSIX2_LINE_MAX], *process_name;
 
-	kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
 	kp = kvm_getprocs(kd, KERN_PROC_PID, pid, nentries);
@@ -1735,7 +1740,7 @@ do_procinit(void)
 	char errbuf[_POSIX2_LINE_MAX];
 	enum status_code prog_status = STATUS_DEAD;
 
-	kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+	kd = kvm_openfiles(NULL, KVM_MEMFILE, NULL, O_RDONLY, errbuf);
 	if (kd == NULL)
 		errx(1, %s, errbuf);
 	kp = kvm_getprocs(kd, KERN_PROC_ALL, 0, nentries);

Re: Bug#763685: apt-cacher-ng: FTBFS[!linux]: C++11 syntax error, systemd dependency

[Guillem Jover]

Hi!

On Wed, 2014-10-01 at 22:20:31 +0100, Steven Chamberlain wrote:
 In addition to fixing the syntax error in include/dlcon.h, the attached
 packaging changes seem to allow apt-cacher-ng to still build on
 non-Linux, and the sysvinit scripts still work to start and stop it.

 diff -Nru apt-cacher-ng-0.8.0~rc3.orig/debian/rules 
 apt-cacher-ng-0.8.0~rc3/debian/rules
 --- apt-cacher-ng-0.8.0~rc3.orig/debian/rules 2014-09-20 11:53:25.0 
 +0100
 +++ apt-cacher-ng-0.8.0~rc3/debian/rules  2014-10-01 22:05:13.062740285 
 +0100
 @@ -13,6 +13,8 @@
  export CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
  export LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
  
 +DEB_HOST_ARCH_OS  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 +
  %:
   dh $@ --parallel --with systemd
  
 @@ -22,8 +24,10 @@
  override_dh_install:
   dh_install $(shell test -e build/acngfs || echo -Xacngfs)
   sed -e s,^Type=simple,Type=notify,  systemd/apt-cacher-ng.service  
 debian/apt-cacher-ng.service
 -# make sure it has sd_notify support enabled
 +ifeq ($(DEB_BUILD_ARCH_OS),linux)

I think you want DEB_HOST_ARCH_OS here too.

 + # on Linux, make sure it has sd_notify support enabled
   grep -q libsystemd $(TGT)/usr/sbin/apt-cacher-ng
 +endif
   cp systemd/apt-cacher-ng.conf debian/apt-cacher-ng.tmpfile
   install -m 755 scripts/expire-caller.pl $(TGT)/usr/lib/apt-cacher-ng
   $(MAKE) -C dbgen package DBGENERATOR=dbgenerator

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002032309.ga27...@gaara.hadrons.org

Re: Bug#763572: pbs-drmaa: FTBFS[kfreebsd]: uses non-POSIX mode flag

[Guillem Jover]

Hi!

On Wed, 2014-10-01 at 03:14:07 +0100, Steven Chamberlain wrote:
 Package: pbs-drmaa
 Version: 1.0.17-1
 Severity: serious
 Tags: patch
 User: debian-bsd@lists.debian.org
 Usertags: kfreebsd

 pbs-drmaa/job.c uses S_ISREG, which is not part of core POSIX
 specification;  instead it should use the S_IFREG macro.  This caused
 the FTBFS on kfreebsd.

(It seems the macros got swapped in the mail body, but are fine on
the patch.)

GNU/kFreeBSD does have S_IFREG, but it does not get exposed by default.
I guess this package might have been possibly caught up with the glibc
transition from _BSD_SOURCE and _SVID_SOURCE to _DEFAULT_SOURCE?

In any case the proposed patch is better than the current code or
enabling those feature macros anyway.

 From: Steven Chamberlain ste...@pyro.eu.org
 Subject: use POSIX-recommended macro to check file type
 
 --- a/pbs_drmaa/job.c
 +++ b/pbs_drmaa/job.c
 @@ -401,7 +401,7 @@
   struct stat tmpstat;
  
   fsd_log_error((Failed to open job status file: %s, 
 status_file));
 - if (stat(start_file, tmpstat) == 0  (tmpstat.st_mode  
 S_IFREG))
 + if (stat(start_file, tmpstat) == 0  S_ISREG(tmpstat.st_mode))
{
   exit_status = 143; /* SIGTERM */
   fsd_log_info((But start file exist %s. Assuming that 
 job was killed (exit_status=%d)., start_file, exit_status));

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002033949.gb27...@gaara.hadrons.org

Re: Bug#763693: dnsmasq: FTBFS[kfreebsd]: missing strlcpy

[Guillem Jover]

Hi!

On Wed, 2014-10-01 at 22:24:29 +0100, Steven Chamberlain wrote:
 Package: dnsmasq
 Version: 2.72-1
 Severity: serious
 Tags: patch
 User: debian-bsd@lists.debian.org
 Usertags: kfreebsd

 dnsmasq FTBFS on kfreebsd, because it builds some code to use FreeBSD
 PF, which also uses strlcpy, which is only found in FreeBSD libc.
 
 For Debian GNU/kFreeBSD it is possible to get this function from libbsd;
 patch attached!

 diff -Nru dnsmasq-2.72.orig/debian/rules dnsmasq-2.72/debian/rules
 --- dnsmasq-2.72.orig/debian/rules2014-10-01 21:57:13.0 +0100
 +++ dnsmasq-2.72/debian/rules 2014-10-01 22:05:34.282734624 +0100
 @@ -83,6 +83,11 @@
   DEB_COPTS += -DHAVE_DNSSEC
  endif
  
 +ifneq ($(DEB_BUILD_ARCH_OS),linux)

This should be DEB_HOST_ARCH_OS.

 + # For strlcpy
 + LDFLAGS += -lbsd
 +endif
 +
  clean:
   $(checkdir)
   rm -rf debian/daemon debian/base debian/utils debian/*~ debian/files 
 debian/substvars debian/utils-substvars
 diff -Nru dnsmasq-2.72.orig/src/tables.c dnsmasq-2.72/src/tables.c
 --- dnsmasq-2.72.orig/src/tables.c2014-10-01 22:05:38.761734000 +0100
 +++ dnsmasq-2.72/src/tables.c 2014-10-01 22:06:03.831679913 +0100
 @@ -19,6 +19,9 @@
  #include dnsmasq.h
  
  #if defined(HAVE_IPSET)  defined(HAVE_BSD_NETWORK)
 +#ifndef __FreeBSD__
 +#include bsd/string.h
 +#endif

The other option is to use the libbsd overlay, which should require no
upstream source patching. Either through pkg-config, or passing the
equivalent output to CPPFLAGS:

  $ pkg-config --cflags libbsd-overlay

But it needs to be tested as it could meddle with the build.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002034727.gc27...@gaara.hadrons.org

Re: Bug#754718: lmms: FTBFS on kfreebsd-*: 'ESTRPIPE' was not declared in this scope

[Guillem Jover]

Hi!

On Wed, 2014-10-01 at 23:11:45 +0100, Steven Chamberlain wrote:
 --- debian/rules.orig   2014-10-01 20:13:22.0 +0100
 +++ debian/rules2014-10-01 22:55:19.415683658 +0100
 @@ -4,9 +4,15 @@
  
  DH_CMAKE_BUILD_DIR=obj -${DEB_BUILD_GNU_TYPE}
  DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 +DEB_HOST_ARCH_OS  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 +
 +CMAKE_OPTS=
 +ifneq ($(DEB_BUILD_ARCH_OS),linux)

Here DEB_HOST_ARCH_OS too.

 +CMAKE_OPTS+= -DWANT_ALSA=0
 +endif

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141002034931.gd27...@gaara.hadrons.org

Re: getPeerCred on kfreebsd-*

[Guillem Jover]

Hi!

On Sun, 2014-09-07 at 20:13:37 +0200, Joachim Breitner wrote:
 the latest version of haskell-dbus is failing on the BSDs, as it started
 to use getPeerCred in haskell-network. That is only available if the
 following configure.ac snippet detects it:

[…]

 Would you care to see if this is actually supported on BSD, and suggest
 a patch against haskell-network (no haskell knowledge required, I
 think)? Or, if it is not supported, tell me so so that I can remove
 haskell-dbus on the BSDs.

It is supported on BSDs, you might want to use libbsd's getpeereid()
instead of reimplementing it though.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140908074438.ga27...@gaara.hadrons.org

Re: kfreebsd-10 FTBFS with libbsd/0.7.0

[Guillem Jover]

Hi!

On Mon, 2014-08-25 at 20:03:46 +0100, Steven Chamberlain wrote:
 On 25/08/14 19:07, Christoph Egger wrote:
  Indeed it works! And I'm running that 10.1 kernel just right now! As
  soon as some solution is committed I can upload it to experimental (or
  should I just go ahead and patch -glue?)
 
 I just confirmed the freebsd-glue problem happens building kfreebsd-10
 10.0 in sid.
 
 Do you think it's okay to drop those definitions from freebsd-glue and
 use libbsd's?  Even though they're different?  I'm not sure, and hope
 Guillem or someone else can explain it.

Sorry about this, I was aware of the conflicting functions when they
got added to freebsd-glue, but completely forgot about them few days
afterwards.

In any case the conflicting functions in freebsd-glue were not usable
anyway as they use the fpos_t struct which cannot be manipulated, and
does not get automatically converted into the correct type off_t. So
those would have failed to build if any code were using them anyway.
(As quoted from the libbsd commit message.)

Because the conflicts only affected function pointers, they should not
affect the ABI, only the API so no rebuild should be needed, either.

 But otherwise please go ahead and patch freebsd-glue in unstable as soon
 as you think it's the right fix.  We do need it pretty fast.

I see you've dealt with this now. Regardless, I think this was the
correct “fix”, even if usually not kosher, the freebsd-glue stuff
pulls in libbsd anyway so it's kind of part of its API/ABI.

Also there's the point raised in this thread of why kernel code might
end up pulling in userland declarations.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140827194029.gc27...@gaara.hadrons.org

Re: kfreebsd-10 FTBFS with libbsd/0.7.0

[Guillem Jover]

Hey!

On Wed, 2014-08-27 at 21:33:54 +0100, Steven Chamberlain wrote:
 Thanks for explaining this.

No problem. :)

 On 27/08/14 20:40, Guillem Jover wrote:
  I see you've dealt with this now. Regardless, I think this was the
  correct “fix”, even if usually not kosher, the freebsd-glue stuff
  pulls in libbsd anyway so it's kind of part of its API/ABI.
 
 Just one other thing - is it the overall plan that things like that will
 move out of freebsd-glue into libbsd-dev?

I don't know what the plan for freebsd-glue is, you'd need to ask
Robert I guess. I think he created it to be able to deploy things
that might not be included in libbsd fast enough, or things that are
unsuitable for it. For the former I'm always open to hear suggestions
on what else might be helpful, or to accept patches. For the latter,
it would be nice to find a suitable alternative instead, otherwise
they can always be left in freebsd-glue for now.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140828005113.ga4...@gaara.hadrons.org

Re: Clustering.

[Guillem Jover]

Hi!

On Wed, 2014-07-09 at 22:03:22 +0100, Steven Chamberlain wrote:
 On 08/07/14 13:58, Thomas Martin wrote:
  NB: output of cluster-glue's compilation (I delete iproute and
  iputils-ping from build-depends):
  ipcsocket.c: In function 'socket_verify_auth':
  ipcsocket.c:2569:3: error: #error No credential type found!

 We don't have FreeBSD's getpeereid because that's implemented in their
 libc.  We do have ucred capabilities though, which have been used in the
 past, see http://people.debian.org/~jcristau/kbsd-peercred.diff

We do have getpeereid() on all Debian ports by way of libbsd, along
many other BSD-native APIs, as I've mentioned in the past.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140711155509.ga25...@pulsar.hadrons.org

Re: Bug#630911: please provide link_ntoa()

[Guillem Jover]

On Mon, 2011-06-27 at 07:30:22 +0200, Aurelien Jarno wrote:
 On Mon, Jun 27, 2011 at 01:21:03AM +0200, Guillem Jover wrote:
  On Mon, 2011-06-27 at 00:27:12 +0200, Robert Millan wrote:
   2011/6/27 Guillem Jover guil...@debian.org:
The problem with link_ntoa() is that it relies on the BSD specific
‘struct sockaddr_dl’ which for example does not match any Linux
sockaddr structure, the closes one is sockaddr_ll, but not quite the
same, also no standard function returns such type, so the code has to
be ported anyway. As such I don't think libbsd is the correct place
for that function.
   
   Should we reassign to libc0.1-dev then?
  
  We used to have this in libfreebsd, and given the recent discussion
  about adding new functions to (e)glibc, I don't really know where we
  should put this, but the same answer should apply as for the other
  (Free)BSD specific functions.
  
 
 And if you look at the history, link_ntoa() was in libfreebsd, and 
 given freebsd-utils was the only user it has been moved to
 [freebsd-utils]/debian/patches/030_arp_libbsd.diff

This is provided now by freebsd-glue, so closing the bug report.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140306174625.ga14...@gaara.hadrons.org

Re: Roll call for porters of architectures in sid and testing

[Guillem Jover]

Hi!

On Tue, 2013-10-01 at 00:49:17 +0200, Guillem Jover wrote:
 I am an active porter for the following architectures and I intend
 to continue this for the lifetime of the jessie release:
 
 For kfreebsd-*, I
 - co-maintain arch-related packages under the hat of the GNU/kFreeBSD
   Maintainers.
 - maintain a portability guide to help others with the task.
 - test packages on this architecture.
 - assist (reviews, suggestions, etc) with arch-related bugs.
 - fix arch-related bugs.
 - read debian-bsd@l.d.o every few days
 
 I am a semi-active porter for the following architecture, I'm
 pondering about my future involvement though:
 
 For hurd-i386-*, I
 - maintain a portability guide to help others with the task.
 - assist (reviews, suggestions, etc) with arch-related bugs from time
   to time.
 - fix arch-related bugs from time to time.
 - read debian-hurd@l.d.o every few days.
 
 I am a DD.

Please, consider the above commitments rescinded.

Thanks,
Guillem


signature.asc
Description: Digital signature

Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64

[Guillem Jover]

Control: reassign -1 apt
Control: found -1 0.9.13~exp1

On Mon, 2013-12-23 at 07:00:00 +0100, Guillem Jover wrote:
 On Sun, 2013-12-22 at 21:53:19 +0100, Axel Beckert wrote:
  Michael Gilbert wrote:
   dpkg seems to often fail on kfreebsd-amd64 on unstable (I had not
   experienced this with wheezy).
  
  I can confirm that for kfreebsd-i386.
 
 Ok, this is something new, I had not seen it before, but I can see
 it being broken only when using apt. The same command using dpkg
 directly works fine.
 
 I can reproduce it with simply running:
 
   $ apt-get install --reinstall git
 
   The error message is
   
   E: Sub-process /usr/bin/dpkg returned an error code (1)
  
  Yeah, and noting else. It's not clear, why there was an error.
 
 The problem is that something messes with dpkg's standard output and
 error, and it fails when doing the fflush() and ferror() check on it
 in m_output() I think. But this seems to be coming from something
 lower than dpkg or apt, perhaps a change in glibc or the kernel. As
 I've tried with downgraded versions matching the ones in stable, and
 it still fails. I've not tested further.

Ok, my testing was flawed, I missed downgrading libapt*.deb, so my
initial suspicion was right, and with those now it stops failing with
«src:apt=0.9.12.1». I'd recommend anyone with up-to-date apt versions
on kfreebsd-* to downgrade and put these packages on hold.

 The last thing reported from dpkg to apt through the status-fd channel
 is:
 
   status: git : error : error writing to 'standard output': No such file or 
 directory
 
 and then dpkg exits “normally” after proceeding with the error
 unwinding cleanup.
 
   This is easily recoverable by running the command a second time, which
   usually succeeds.
  
  Yeah, but it often needs multiple tries though. I usually run
  aptitude install -y || aptitude install -y || aptitude install -y
  or such after I saw such a failure.
 
 Ouch.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131225235557.ga16...@gaara.hadrons.org

Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64

[Guillem Jover]

Hi!

On Sun, 2013-12-22 at 21:53:19 +0100, Axel Beckert wrote:
 Michael Gilbert wrote:
  dpkg seems to often fail on kfreebsd-amd64 on unstable (I had not
  experienced this with wheezy).
 
 I can confirm that for kfreebsd-i386.

Ok, this is something new, I had not seen it before, but I can see
it being broken only when using apt. The same command using dpkg
directly works fine.

I can reproduce it with simply running:

  $ apt-get install --reinstall git

  The error message is
  
  E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 Yeah, and noting else. It's not clear, why there was an error.

The problem is that something messes with dpkg's standard output and
error, and it fails when doing the fflush() and ferror() check on it
in m_output() I think. But this seems to be coming from something
lower than dpkg or apt, perhaps a change in glibc or the kernel. As
I've tried with downgraded versions matching the ones in stable, and
it still fails. I've not tested further.

The last thing reported from dpkg to apt through the status-fd channel
is:

  status: git : error : error writing to 'standard output': No such file or 
directory

and then dpkg exits “normally” after proceeding with the error
unwinding cleanup.

  This is easily recoverable by running the command a second time, which
  usually succeeds.
 
 Yeah, but it often needs multiple tries though. I usually run
 aptitude install -y || aptitude install -y || aptitude install -y
 or such after I saw such a failure.

Ouch.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013122306.gb32...@gaara.hadrons.org

Cleanups before leaving the team

[Guillem Jover]

Hi,

I'm planning on removing myself from the glibc-bsd alioth group in
around two weeks.

If someone is interested in the git-svn mirror, please copy the repo
and the clone script somewhere else, as I'll be removing them before
removing myself from the group, otherwise I'll not be able to disable
in the future the git-update script called from the svn hook.

Regarding libbsd, given that I'm upstream for that project, that it's
been mostly me maintaining it in the past, that it's a generic not
kfreebsd-specific package and that most packages in glibc-bsd are
anyway being moved to use freebsd-glue, I'd like to take it with me
and maintain it outside of the team. The same goes for libmd, the
difference being that this one has not been uploaded to Debian yet.
Otherwise the situation might get a bit awkward.

The only other remaining package for which I'm currently listed as
co-maintainer in svn is posixtestsuite, which I've been maintaining
alone for the past several years. I don't have a particular attachment
to it, and if someone else wants to continue maintaining it through the
team, I'll remove myself from the Uploaders, but if no one is going to
step in, I'd be fine with maintaining it outside the team too, either
way I don't really care much.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131026163710.ga22...@gaara.hadrons.org

Bug#726970: freebsd-glue: Broken funopen() implementation

[Guillem Jover]

Source: freebsd-glue
Source-Version: 0.1.11
Severity: important

Hi,

The funopen() implementation in this package uses nested functions to
wrap the argument hooks, but it returns a FILE structure pointing to
those nested functions and their references to arguments from the
stack, to be accessed outside of the function lexical scope, which is
just wrong. I've not tested if this currently breaks, but this is
explicitly stated as broken usage.

In 2011 I started some draft code to add funopen() support to libbsd,
but left it aside given the various issues with the interface. I've
just finished and polished a full implementation, and pushed to libbsd's
git master, it will be included in 0.7.0.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131021042049.ga13...@gaara.hadrons.org

Re: ufsutils experiment (please comment/test)

[Guillem Jover]

Hi!

On Tue, 2013-09-10 at 16:10:44 +, Robert Millan wrote:
 Guillem Jover:
  I'll look into updating to latest upstream preserving the current
  support, hopefully in the coming days, been a bit busy lately, sorry!
 
 That's what you said in July! :-)

Indeed, and to be honest, one (but certainly not the only) of the
reasons I've been setting this aside, is because having to deal with
subversion is such a pain that, I've been finding other stuff to do.

I've now done a git-svn clone so that I can work with something saner,
and I'd put the repo in the project git space, so that others can use
it and do not need to do the initial conversion too, but I seem to have
lost the admin bit recently, so I guess I'll put it somewhere else.

 But please take no offense. I'm sure you've been busy, and I think we
 need to be honest with ourselves here. Maintaining this port takes a lot
 of effort and the ufsutils GNU/Linux patchset is an extra burden that
 makes it lag behind in almost every release. So please understand that
 my aim is not to assign blame, but to find solutions.
 
 Given that pristine source from upstream is already buildable and
 usable, my solution would be to move GNU/Linux support aside
 until/unless someone cares enough about it to get the patchset in a
 mergeable state and submit it upstream. That's my solution but it's just
 a proposal, it doesn't have to be the one we apply.
 
 So what's the solution you have in mind? How do you see this problem
 being solved in the long term?

I've started patching the code against 9.2, there's some new stuff
broken on GNU/Linux, I guess I'll dedicate few days, and if it
snowballs too much, then I'll just restrict to kfreebsd-any for now.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131009060550.ga32...@gaara.hadrons.org

glibc-bsd svn repository git mirror

[Guillem Jover]

Hi!

I've pushed a git mirror of the svn repo to alioth, which in theory
should get updated on each svn commit, that can be used either to just
track the svn repository using read-only git:

  git://anonscm.debian.org/users/guillem/glibc-bsd.git
  http://anonscm.debian.org/gitweb/?p=users/guillem/glibc-bsd.git

or to bootstrap a git-svn local repo, using the following script:

  http://alioth.debian.org/~guillem/git-clone-glibc-bsd

after that you can use the normal git-svn workflow (please check the
man page).

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131009201659.ga9...@gaara.hadrons.org

Re: ufsutils experiment (please comment/test)

[Guillem Jover]

Hi!

On Wed, 2013-10-09 at 20:50:19 +, Robert Millan wrote:
 Guillem Jover:
  I've now done a git-svn clone so that I can work with something saner,
  and I'd put the repo in the project git space, so that others can use
  it and do not need to do the initial conversion too, but I seem to have
  lost the admin bit recently, so I guess I'll put it somewhere else.
 
 What do you need it for?

I'd have needed it to enable git for the project, and to create a git
repo for the bi-directional bridge, so that people who want to keep
using svn can do so, and anyone else that want to use git, can use
the bi-directional git-svn repo, from a better place than my home on
alioth. But I guess the current location work fine so.

 (other than unilaterally migrating the official repository to git)

Uh, that would have never even crossed my mind…

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131009224830.ga4...@gaara.hadrons.org

Re: ufsutils experiment (please comment/test)

[Guillem Jover]

On Wed, 2013-10-09 at 23:25:16 +, Robert Millan wrote:
 Guillem Jover:
  I'd have needed it to enable git for the project, and to create a git
  repo for the bi-directional bridge, so that people who want to keep
  using svn can do so, and anyone else that want to use git, can use
  the bi-directional git-svn repo, from a better place than my home on
  alioth. But I guess the current location work fine so.
 
 I'm not specially fond of this kind of proposals coming from people who
 are not actively involved with the port,

Is that directed at me? I've most probably not been as active as I
previously was, but I've considered myself active in the port… but
perhaps I should reconsider.

 but if it's useful in general
 and it doesn't prevent me from using SVN I have no objection with it.

 I suggest we wait a few days to see if everyone else is okay with this.

I have the feeling you might have jumped to conclusions on the purpose
of the the git-svn repository.

But anyway, the git mirror is already public and synced from svn, so
it's already useful and helpful for whoever else wants to use git-svn,
besides me. And to be honest at this point I don't think I can be
bothered to move the setup somewhere else, so I don't see what needs
to be waited for anyway.

  (other than unilaterally migrating the official repository to git)
  
  Uh, that would have never even crossed my mind…
 
 It's what you said initially. I'm glad it was just a missunderstanding.

Eh, I don't see where I've said anything like that, certainly not on
this thread, nor on the new post about the git mirror nor on the
previous RFC thread…

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131010044401.ga10...@gaara.hadrons.org

Re: Roll call for porters of architectures in sid and testing

[Guillem Jover]

Hi!

[ Had forgotten about this one, sorry. ]

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the jessie release:

For kfreebsd-*, I
- co-maintain arch-related packages under the hat of the GNU/kFreeBSD
  Maintainers.
- maintain a portability guide to help others with the task.
- test packages on this architecture.
- assist (reviews, suggestions, etc) with arch-related bugs.
- fix arch-related bugs.
- read debian-bsd@l.d.o every few days

I am a semi-active porter for the following architecture, I'm
pondering about my future involvement though:

For hurd-i386-*, I
- maintain a portability guide to help others with the task.
- assist (reviews, suggestions, etc) with arch-related bugs from time
  to time.
- fix arch-related bugs from time to time.
- read debian-hurd@l.d.o every few days.

I am a DD.

Thanks,
Guillem


signature.asc
Description: Digital signature

Re: ufsutils experiment (please comment/test)

[Guillem Jover]

Hi!

On Mon, 2013-09-02 at 20:46:54 +, Robert Millan wrote:
 I made a little experiment to simplify ufsutils and make it easier to
 update. By merging ufsutils into freebsd-utils package and using its
 build environment, with recent freebsd-glue (0.1.4) it is now possible
 to build ufsutils directly from pristine upstream source:
 
 http://people.debian.org/~rmh/kfreebsd-gnu/ufsutils/

 - Drops GNU/Linux support [1]

 [1] I would argue that this is less of an issue these days, as UFS
 support has been dropped from Linux since version 3.10.1-1. TBH I don't
 see the point in doing an extra effort to support the userland bits when
 Linux itself doesn't.

I'd also prefer to keep it separate. And I'd also keep non-kFreeBSD
support, because even if the other kernels do not support UFS, you can
use the tools to do some setup or recovery operations, which seem
pretty handy to me (fsck, mkfs, etc).

I'll look into updating to latest upstream preserving the current
support, hopefully in the coming days, been a bit busy lately, sorry!

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130910091455.ga30...@gaara.hadrons.org

Re: Bug#721886: FTBFS on kfreebsd-*: glibtop_machine.h:26:19: fatal error: nlist.h: No such file or directory

[Guillem Jover]

Hi!

On Thu, 2013-09-05 at 19:52:13 +0200, Michael Biebl wrote:
 Am 05.09.2013 19:42, schrieb Julien Cristau:
  On Thu, Sep  5, 2013 at 19:40:18 +0200, Michael Biebl wrote:
  Am 05.09.2013 19:29, schrieb Julien Cristau:
  On Thu, Sep  5, 2013 at 17:50:18 +0200, Michael Biebl wrote:
  Am 05.09.2013 17:29, schrieb Robert Millan:
  -#include nlist.h
  +#include bsd/nlist.h

Please try to avoid this, which cannot be easily upstreamed, or if it
can be upstreamed it unnecessarily pollutes the source.

  Does that also work with FreeBSD so can be pushed upstream?
  Apparently libgtop2 has native FreeBSD support and I wonder if nslist.h
  is using a different location on  FreeBSD.
 
  In xorg-server added `pkg-config --cflags libbsd-overlay` to CPPFLAGS
  from debian/rules.  Lets the code expecting bsd headers on bsd work
  without patching.

Yes, that's the ideal solution, which generally avoids any patching.

  That's confusing tbh. Why is libbsd-dev using different paths in the
  first place which requires such hacks?
 
  Because the normal bsd paths would conflict with gnu libc-dev headers
  (maybe not for nlist.h, but for others).
 
 Why do libc-dev and libbsd-dev have conflicting files in the first place
 and why not move just the conflicting (BSD) files to bsd/ ?

Most header files provided by libbsd-dev are overlays over the libc
ones. For example strlcpy() and friends in bsd/string.h, or slightly
different implementations like bsd/sys/queue.h.

Then there's partial implementations like bsd/libutil.h which does not
conflict with anything, but exposing it directly under /usr/include
can confuse software that might assume functionality in libc just
because the file is there, for example I think perl suffered from this
in Debian at some point.

And there's files already shipped by other pre-existing libraries,
like bsd/nlist.h, provided by libelfg0-dev and libelf-dev. And no,
Replaces does not cut it, because once you remove libbsd-dev then
the other libraries will be missing the header. This was a mistake I
corrected by namespacing it under bsd/ (the aforementioned link on
the list).

After all these cases, the only remaining non-conflicting headers are
readpassphrase.h, vis.h and md5.h. For md5.h taking over the global
namespace seems wrong (it probably belongs in the to-be-uploaded
libmd), at which point having the remaining two namespaced seems safer,
more future-proof and nicer to other projects.

 Apparently libgtop2 built just fine in the past with libbsd-dev, so this
 looks like a recent regression in that package.

I went over any package explicitly declaring a Build-Depends on
libbsd-dev when I did those changes, if libgtop2 is directly using
stuff from libbsd-dev but not declaring it explicitly, that's hardly
my fault? :)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130905210820.ga23...@gaara.hadrons.org

libedit: Fix build system to use system instead of embeded functions

[Guillem Jover]

Package: libedit
Version: 3.1-20130712-1~exp1
Severity: normal
Tags: patch

On Fri, 2013-08-02 at 22:32:13 +0200, Guillem Jover wrote:
 On Fri, 2013-08-02 at 19:34:01 +0200, Sylvestre Ledru wrote:
  I just uploaded in experimental a new upstream version of libedit
  published here:
  http://www.thrysoee.dk/editline/
  
  It would be nice if you could test if your packages still behave the
  same. I am not really worried but since it is an important package, I
  would like confirmations.
 
 I had just noticed that the version in experimental dropped the libbsd
 usage and started using its embedded function copies, with the
 consequence of exporting them as part of the shared library.
 
 I'll try to send a patch, in case this does not get fixed in
 the meantime. Most probably adding to LDFLAGS the output of
 «pkg-config --libs libbsd-overlay» and to CFLAGS the output of
 «pkg-config --clags libbsd-overlay», and passing these to ./configure
 might be enough. The fix_gcc_warnings.diff patch should probably be
 dropped then too. Plus updating the symbols file.

Here's a patch that switches libedit back to use libbsd instead of
using the embedded code copies, it also fixes the build system to not
embed fgetln() and wcsdup() even if they are found on the system,
stops embedding wcsdup() when widechar support is not enabled, and to
not check for functions twice. Fixes the pkg-config file, to not make
users unnecessarily link against tinfo. Removes the obsolete patches
related to libbsd. And adds a missing symbol to the symbols file.

I could split the patch in logical pieces if you want, I just wanted
to get this out of the way for now, in case someone else was
considering taking a look.

Thanks,
Guillem
diff --git a/debian/control b/debian/control
index aed6030..d1431c5 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: standard
 Maintainer: LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org
 Uploaders: Anibal Monsalve Salazar ani...@debian.org, Sylvestre Ledru sylves...@debian.org
 Build-Depends: dpkg-dev (= 1.16.1~), debhelper (= 9), dh-autoreconf,
+ pkg-config,
  groff-base, libbsd-dev (= 0.1.3), libncurses5-dev (= 5.9-2), bsdmainutils
 Standards-Version: 3.9.4
 Vcs-Git: git://git.debian.org/collab-maint/libedit.git
diff --git a/debian/libedit2.symbols b/debian/libedit2.symbols
index b0fc185..fc04775 100644
--- a/debian/libedit2.symbols
+++ b/debian/libedit2.symbols
@@ -77,6 +77,7 @@ libedit.so.2 libedit2 #MINVER#
  ed_tty_stop_output@Base 3.1-20130611
  ed_unassigned@Base 3.1-20130611
  el_beep@Base 2.11-20080614
+ el_cursor@Base 3.1-20130712
  el_deletestr@Base 2.11-20080614
  el_editmode@Base 3.1-20130611
  el_end@Base 2.11-20080614
@@ -166,9 +167,6 @@ libedit.so.2 libedit2 #MINVER#
  keymacro_map_str@Base 3.1-20130611
  keymacro_print@Base 3.1-20130611
  keymacro_reset@Base 3.1-20130611
- libedit_fgetln@Base 3.1-20130611
- libedit_strlcat@Base 3.1-20130611
- libedit_strlcpy@Base 3.1-20130611
  map_addfunc@Base 3.1-20130611
  map_bind@Base 3.1-20130611
  map_end@Base 3.1-20130611
@@ -179,7 +177,6 @@ libedit.so.2 libedit2 #MINVER#
  map_set_editor@Base 3.1-20130611
  max_input_history@Base 2.11-20080614
  next_history@Base 2.11-20080614
- nvis@Base 3.1-20130611
  parse__escape@Base 3.1-20130611
  parse__string@Base 3.1-20130611
  parse_cmd@Base 3.1-20130611
@@ -285,23 +282,7 @@ libedit.so.2 libedit2 #MINVER#
  sig_end@Base 3.1-20130611
  sig_init@Base 3.1-20130611
  sig_set@Base 3.1-20130611
- snvis@Base 3.1-20130611
  stifle_history@Base 2.11-20080614
- strenvisx@Base 3.1-20130611
- strnunvis@Base 3.1-20130611
- strnunvisx@Base 3.1-20130611
- strnvis@Base 3.1-20130611
- strnvisx@Base 3.1-20130611
- strsenvisx@Base 3.1-20130611
- strsnvis@Base 3.1-20130611
- strsnvisx@Base 3.1-20130611
- strsvis@Base 3.1-20130611
- strsvisx@Base 3.1-20130611
- strunvis@Base 3.1-20130611
- strunvisx@Base 3.1-20130611
- strvis@Base 3.1-20130611
- strvisx@Base 3.1-20130611
- svis@Base 3.1-20130611
  terminal__flush@Base 3.1-20130611
  terminal__putc@Base 3.1-20130611
  terminal_beep@Base 3.1-20130611
@@ -342,7 +323,6 @@ libedit.so.2 libedit2 #MINVER#
  tty_rawmode@Base 3.1-20130611
  tty_stty@Base 3.1-20130611
  unstifle_history@Base 2.11-20080614
- unvis@Base 3.1-20130611
  username_completion_function@Base 2.11-20080614
  using_history@Base 2.11-20080614
  vi_add@Base 3.1-20130611
@@ -392,7 +372,5 @@ libedit.so.2 libedit2 #MINVER#
  vi_yank@Base 3.1-20130611
  vi_yank_end@Base 3.1-20130611
  vi_zero@Base 3.1-20130611
- vis@Base 3.1-20130611
- wcsdup@Base 3.1-20130611
  where_history@Base 2.11-20080614
  write_history@Base 2.11-20080614
diff --git a/debian/patches/01-Makefile.diff b/debian/patches/01-Makefile.diff
deleted file mode 100644
index c254f86..000
--- a/debian/patches/01-Makefile.diff
+++ /dev/null
@@ -1,23 +0,0 @@
- 01-Makefile.diff by Neal H Walfield n...@cs.uml.edu and
- Gergely Nagy alger...@debian.org
-
- Add the necessary includes and other things to the libedit
- Makefile

Re: New version of libedit in experimental: tests welcome

[Guillem Jover]

Hi!

On Fri, 2013-08-02 at 19:34:01 +0200, Sylvestre Ledru wrote:
 I just uploaded in experimental a new upstream version of libedit
 published here:
 http://www.thrysoee.dk/editline/
 
 It would be nice if you could test if your packages still behave the
 same. I am not really worried but since it is an important package, I
 would like confirmations.

I had just noticed that the version in experimental dropped the libbsd
usage and started using its embedded function copies, with the
consequence of exporting them as part of the shared library.

I'll try to send a patch, in case this does not get fixed in
the meantime. Most probably adding to LDFLAGS the output of
«pkg-config --libs libbsd-overlay» and to CFLAGS the output of
«pkg-config --clags libbsd-overlay», and passing these to ./configure
might be enough. The fix_gcc_warnings.diff patch should probably be
dropped then too. Plus updating the symbols file.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130802203213.ga22...@gaara.hadrons.org

Re: zfsutils_9.1-2_kfreebsd-amd64.changes ACCEPTED into unstable

[Guillem Jover]

Hey!

On Mon, 2013-07-22 at 22:21:20 +0200, Robert Millan wrote:
 2013/7/22 Steven Chamberlain ste...@pyro.eu.org:
  On 22/07/13 20:18, Debian FTP Masters wrote:
   zfsutils (9.1-2) unstable; urgency=low
   .
 * Reupload.
 
  Just FYI there is a Lintian check that expects slightly more specific
  wording for this:
 
 Argh. This must be the first time I see a computer talking a human
 into being redundant. It is completely backwards!

While it surely sounds redundant, it's a question of context. When you
upgrade from one version to the other, and have something like
apt-listchanges installed, you only get to see the changelog entries
after the last installed versions, and seeing just a “Reupload” entry
seems rather confusing to the reader (I for example had to go check
the whole changelog to see what was going on), because at first sight
it appears as a reupload for reupload's sake.

In this case lintian is following what has been considered “best”
practice by humans. ;)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130730075458.ga12...@gaara.hadrons.org

Re: Bug#712633: marked as done (Include freebsd-config into freebsd-buildutils)

[Guillem Jover]

Hi!

On Wed, 2013-06-19 at 10:36:09 +, Debian Bug Tracking System wrote:
 Changes: 
  freebsd-buildutils (10~svn251967-1) experimental; urgency=low
[…]
[ Robert Millan ]
* Add freebsd-config back. (Closes: #712633)

Hmmm, this has the problem that it introduces a circular
build-dependency:

  freebsd-buildutils → freebsd-libs (via libsbuf-dev) → freebsd-buildutils

which is a problem when bootstrapping on new architectures. For
example I was planning on making freebsd-buildutils buildable on the
Hurd (so that freebsd-libs could follow), but this makes it more
difficult, as it will require manual bootstrapping.

We should perhaps move it to its own independent package.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130730090818.ga18...@gaara.hadrons.org

Re: FreeBSD 9.2

[Guillem Jover]

Hi!

On Mon, 2013-07-29 at 07:45:30 +0200, Petr Salinger wrote:
 Ideally whole set [1] of 9.1 based packages should migrate into
 testing before upload of a corresponding 9.2 package into sid.
 Especially lag of ufsutils (still 8.2) worries me.

I was planning on working on ufsutils, and I can do that now during
the coming days.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130729092809.ga4...@gaara.hadrons.org

Re: libgphoto2 and sane-backends FTBFS with libusb2-dev

[Guillem Jover]

On Thu, 2013-07-25 at 07:29:53 +0200, Petr Salinger wrote:
 Do we have other options except waiting for a new release of libusb2-dev
 and removing the outdated kfreebsd packages from testing to make
 libgphoto2 and sane-backends swiftly migrate to testing?
 
 Anyways, what keeps us from just integrating
 a patch in the libusb2-dev Debian package and do a quick upload.
 Be it a normal upload or an NMU.
 
 I am member of maintainer group, but not a DD. I cannot upload myself.
 Feel free to use attached patch to debian packaging, alter
 debian/changelog as needed and do an upload of freebsd-libs.

Petr, if you could commit the patch (so that authorship is preserved),
I'll do an upload today (otherwise I'll commit myself, although I
prefer to have proper attributtions on the VCS).

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130725100858.ga6...@gaara.hadrons.org

Re: libgphoto2 and sane-backends FTBFS with libusb2-dev

[Guillem Jover]

On Thu, 2013-07-25 at 12:21:37 +0200, Petr Salinger wrote:
 Petr, if you could commit the patch (so that authorship is preserved),
 I'll do an upload today (otherwise I'll commit myself, although I
 prefer to have proper attributtions on the VCS).
 
 It just remains to do upload, it is in our glibc-bsd SVN since Tuesday:
 
 http://lists.alioth.debian.org/pipermail/glibc-bsd-commits/2013-July/003446.html
 http://lists.alioth.debian.org/pipermail/glibc-bsd-commits/2013-July/003447.html

Ah, ok sorry, should have checked, I assumed they had not been
comitted due to the attached patch on the list.

I'm preparing the upload right now.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130725105539.ga7...@gaara.hadrons.org

Re: libgphoto2 and sane-backends FTBFS with libusb2-dev

[Guillem Jover]

On Thu, 2013-07-25 at 14:16:57 +0200, John Paul Adrian Glaubitz wrote:
 On 07/25/2013 12:55 PM, Guillem Jover wrote:
 I'm preparing the upload right now.
 
 I'm ready and waiting with an updated libgphoto2 here. Just ping
 me once you have uploaded freebsd-libs and I'll be pushing libgphoto2
 afterwards.

It's now uploaded, it might take some time to get built on kfreebsd-i386
though.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130725152731.ga17...@gaara.hadrons.org

Re: freebsd-libs_9.0+ds2-1_kfreebsd-amd64.changes is NEW

[Guillem Jover]

Hi!

On Wed, 2013-06-19 at 21:22:13 +, Debian FTP Masters wrote:
 binary:libelf-freebsd-1 is NEW.

At least this one is a really bad idea, because even if it doesn't
cause a file system conflict with the other libelf implementations
they are a namespace conflict, due to using the exact same SONAME.
This will cause unexpected loading of the wrong shared library when
both libelf-freebsd-1 and libelf1 are installed at the same time.
Also it will not allow for libelf-freebsd-1 to be moved to the
multiarch paths, because that's what is currently preventing the file
system conflict. Is this API incompatible with either of the other
libelf implementations (libelf-dev, libelfg0-dev)? And if yes, would
porting the code be much work?

 binary:libdwarf3 is NEW.
 binary:libdwarf3-dev is NEW.

These are a namespace grab from the existing libdward-dev package.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715170511.ga26...@gaara.hadrons.org

Re: [RFC] Switching glibc-bsd from svn to git

[Guillem Jover]

Hi!

On Mon, 2013-05-27 at 09:06:33 +0200, Petr Salinger wrote:
 On Sun, 19 May 2013, Guillem Jover wrote:
 I'd even volunteer to switch the repositories
 
 Outcome of discussion seems be:
 
 - use svn or git
   switch to git
 
 - packaging-only or full content
   packaging-only
 
 - one common repository x repository per package
   repository per package
(with a central repo using git submodules to pull the others)

Agreed, didn't want to post a summary yet, because I'm not confortable
doing the switch until Robert and Aurelien have posted their opinions,
given their amount of commits.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130527155703.ga2...@gaara.hadrons.org

[RFC] Switching glibc-bsd from svn to git

[Guillem Jover]

Hi!

I'd like to propose switching and splitting the glibc-bsd repo from svn
to git repositories, because svn is increasingly painful compared to git,
when it comes to at least partial commits, tagging (we don't seem to
be tagging much), branching and merging, offline hacking, etc...

I'd even volunteer to switch the repositories, although I'd like to
keep just the current packaging-only structure, to the point I'd rather
keep using svn instead of a full-upstream+packaging git repository, which
I find so annoying that I think I'd stop touching them.

What do people think?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130519164956.ga15...@gaara.hadrons.org

Bug#700027: kfreebsd-kernel-headers: Redefinition of struct termios

[Guillem Jover]

On Fri, 2013-03-01 at 15:14:32 +0100, Julien Cristau wrote:
 On Thu, Feb  7, 2013 at 17:17:59 +0100, Guillem Jover wrote:
 
  I'm filing this to track the issue, and because I have to do some
  other stuff, if no one else has dealt with it by then I'll look into
  fixing and uploading the package.

 Any news or ETA?

I've to finish up a dpkg upload pre-aproval request, hopefully today,
and then will get into this during the weekend, so that I can finally
request an unblock request for the inetutils security fix.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130301174632.ga20...@gaara.hadrons.org

Re: Bug#700530: qt frames empty

[Guillem Jover]

On Thu, 2013-02-21 at 16:16:54 +0100, Julien Cristau wrote:
 On Linux, the SO_PEERCRED socket option gives that information.  On
 FreeBSD, there's a getpeereid() libc call.  On kFreeBSD, no such thing
 exists in glibc as far as I can tell, so the patch uses the
 LOCAL_PEERCRED socket option instead to get a struct xucred with the
 needed info.

Not in glibc, although libbsd provides that function instead.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130221162741.ga6...@gaara.hadrons.org

Re: Bug#697032: rcpp: FTBFS[kfreebsd]: #error Rcpp::Timer not supported by your OS.

[Guillem Jover]

On Mon, 2012-12-31 at 17:41:52 +, Steven Chamberlain wrote:
 On 31/12/12 17:06, Dirk Eddelbuettel wrote:
  https://r-forge.r-project.org/scm/viewvc.php/pkg/Rcpp/src/Timer.cpp?root=rcppr1=4182r2=4181pathrev=4182
 
 Actually... presence of time.h rather depends on the libc, not the kernel?
 
 So __GLIBC__ is perhaps more relevant than __FreeBSD_kernel__ in this
 case - plus it should work for other GNU/k*BSD variants if/when they exist.

Well, that's still suboptimal, the ideal solution in this kind of
cases is to test for the feature at build time, which avoids all this
ifdef whitelists, and subsequent updates.

 While here, I think I can explain the build failure on GNU/Hurd.  The
 test for __MACH__ applies to both Apple systems and GNU systems.  I
 suggest using mach/mach_time.h only for __APPLE__, and then adding
 __GNU__ to the list for time.h

For Mac OS X I'd test for __APPLE__  __MACH__, otherwise that could
trigger on other non Mach-based Apple systems.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110233139.ga27...@gaara.hadrons.org

Re: libgeom: may cause segfault of grub-probe

[Guillem Jover]

On Fri, 2012-12-28 at 19:44:41 -0800, Christoph Egger wrote:
   I see there's a patch in this bug report. Do you think this is a
 solution for wheezy? If so I'd volunteer to upload a new version of
 freebsd-libs

I've checked now the interaction of the libbsd-overlay and freebsd-glue,
and they do not play well. Consequently that would require way more
changes than the proposed patch, so even if I've not tested it, it would
seem to be the better solution for now given the freeze. Moving the
-Werror line one up would reduce the diff by 1, but that's pretty much
insignificant, so regardless of that:

Acked-by: Guillem Jover guil...@debian.org

I'll add missing stuff to libbsd, and for jessie I'll make freebsd-glue
play well with the overlay, once that's fixed the other packages can
be switched back to use the overlay.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121229154910.ga25...@gaara.hadrons.org

Re: Bug#685625: implicit declaration of function ‘reallocf’

[Guillem Jover]

On Fri, 2012-12-21 at 23:47:47 +, Steven Chamberlain wrote:
 To further confuse things, here's a related problem in freebsd-buildutils:
 
  gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' 
  -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' 
  -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys
   -D_GNU_SOURCE=1 -isystem /usr/include/freebsd  -std=gnu99 
  -fstack-protector  -c excludes.c
  excludes.c: In function 'read_excludes_file':
  excludes.c:75:2: warning: implicit declaration of function 'fgetln' 
  [-Wimplicit-function-declaration]
  excludes.c:75:15: warning: assignment makes pointer from integer without a 
  cast [enabled by default]
  gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' 
  -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' 
  -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys
   -D_GNU_SOURCE=1 -isystem /usr/include/freebsd  -std=gnu99 
  -fstack-protector  -c misc.c
  gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' 
  -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' 
  -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys
   -D_GNU_SOURCE=1 -isystem /usr/include/freebsd  -std=gnu99 
  -fstack-protector  -c mtree.c
  gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' 
  -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' 
  -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys
   -D_GNU_SOURCE=1 -isystem /usr/include/freebsd  -std=gnu99 
  -fstack-protector  -c spec.c
  spec.c: In function 'set':
  spec.c:229:4: warning: implicit declaration of function 'setmode' 
  [-Wimplicit-function-declaration]
  spec.c:229:11: warning: assignment makes pointer from integer without a 
  cast [enabled by default]
  spec.c:232:4: warning: implicit declaration of function 'getmode' 
  [-Wimplicit-function-declaration]
 
 fgetln, setmode and getmode are defined in bsd/stdio.h and bsd/unistd.h.
  Using fgetln without its prototype truncates the pointer to 32 bits.
 Fortunately a mode_t is only 16 bits long so getmode/setmode may be okay.
 
 I think the preferred method is to use libbsd's 'overlay' in code that
 needs these functions.  Previously freebsd-buildutils couldn't use the
 overlay, so 20_libbsd_overlay.diff worked around it with extra includes:
 
 http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/20_libbsd_overlay.diff?view=markup

There were bugs in the libbsd include logic which made the overlay
unusable, this should be fixed now in latest libbsd versions. So it
should be possible to switch packages back, although I'm not sure of
the effects of mixing the libbsd overlay with the freebsd-glue stuff.
In any case I think that would be correct course of action, but then
I'm not sure either if that would be a minimal change solution, given
the freeze and all.

 Then for some unexplained reason that workaround got disabled;  the
 overlay was never re-enabled though:
 
 http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/series?r1=3805r2=3960
 
 [added Guillem Jover in Cc: in the hope he can explain any of this :) ]

Thanks, I've added Robert to it too, as he is the one who did these
changes. My guess would be that he intended to reduce duplication and
maintenance costs by centralizing those fixes into a single package
(freebsd-glue).

 Another occurrence is in freebsd-libs:
 
  cc -Wall -g -pipe -fPIC -I. 
  -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/sys
   -D_GNU_SOURCE -D__va_list=__builtin_va_list -O2 -isystem 
  /usr/include/freebsd 
  -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/debian/local/include

  -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/lib/libgeom
   -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
  -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
  -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c geom_ctl.c
  In file included from geom_ctl.c:38:0:
  /usr/include/freebsd/unistd.h: In function 'feature_present':
  /usr/include/freebsd/unistd.h:138:2: warning: implicit declaration of 
  function 'strcmp' [-Wimplicit-function-declaration]
  geom_ctl.c: At top level:
  geom_ctl.c:55:1: warning: no previous prototype for 'gctl_dump' 
  [-Wmissing-prototypes]
  geom_ctl.c: In function 'gctl_new_arg':
  geom_ctl.c:142:2: warning: implicit declaration of function 'reallocf' 
  [-Wimplicit-function-declaration]
  geom_ctl.c:142:11: warning: assignment makes pointer from integer without a 
  cast [enabled by default]
 
 And many more places in freebsd-utils according to:
 
 https://buildd.debian.org/~brlink/packages/f/freebsd-utils.html

Thanks,
Guillem


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

Re: Bogus F_SETFL usage with FD_CLOEXEC

[Guillem Jover]

On Mon, 2012-12-17 at 13:05:28 +0100, Guillem Jover wrote:
 On Sun, 2012-12-16 at 22:51:11 +, Steven Chamberlain wrote:
  Using Debian Code Search we can see other cases where possibly the same
  mistake has been made - I wonder if any of these would cause bugs:
  
  http://codesearch.debian.net/search?q=fcntl.*F_SETFL.*FD_

This might still miss flags set through a variable.

 I think we should report all these, there does not seem to be many in
 any case:

   9base (#696247)
   cctools (#696249)
   chromium-browser (webkit, #696299)
   e17 (#696276)
   fish (false positive)
   freeradius (#696250)
   gst-plugins-bad0.10 (#696278)
   jruby (#696283)
   libowfat (#696251)
   mswatch (#696252)
   ocamlnet (#696279)
   qt4-x11 (webkit, #696297)
   qtwebkit (webkit, #696296)
   ruby1.8 (#696280)
   ruby1.9.1 (#696281)
   webkit (#696295)

And can be tracked with:

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=fcntl-fd-cloexec;users=debian-bsd@lists.debian.org

 Providing patches for those should also be trivial. I'll start doing
 so if no one else offers for the task. :)

So, just went ahead and did it.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121219021702.ga2...@gaara.hadrons.org

Bogus F_SETFL usage with FD_CLOEXEC (was Re: Bug#679198: ...)

[Guillem Jover]

On Sun, 2012-12-16 at 22:51:11 +, Steven Chamberlain wrote:
 Using Debian Code Search we can see other cases where possibly the same
 mistake has been made - I wonder if any of these would cause bugs:
 
 http://codesearch.debian.net/search?q=fcntl.*F_SETFL.*FD_

Ah, nice thinking. All these are bugs, because currently on all (?)
GNU/* systems (including GNU/Linux) FD_CLOEXEC is defined as 1 which
maps to O_WRONLY for F_SETFL. So at best they are just leaking file
descriptors, and at worst they might fail if they try to set the flag
on a non-writable descriptor.

I think we should report all these, there does not seem to be many in
any case:

  9base
  cctools
  chromium-browser (webkit)
  e17
  fish
  freeradius
  gst-plugins-bad0.10
  jruby
  libowfat
  mswatch
  ocamlnet
  qt4-x11 (webkit)
  qtwebkit (webkit)
  ruby1.8
  ruby1.9.1
  webkit

Providing patches for those should also be trivial. I'll start doing
so if no one else offers for the task. :)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121217120528.ga26...@gaara.hadrons.org

Re: Re: Bug#675845: adanaxisgpl: FTBFS:

[Guillem Jover]

Hi!

On Fri, 2012-11-30 at 03:26:49 +, Steven Chamberlain wrote:
 Control: found -1 1.2.5.dfsg.1-4.1
 Control: tags -1 + patch

 The problem is a '#define off_t long', which causes a problem later when
 GNU/kFreeBSD headers include sys/types.h (again), and try to redefine
 off_t for some reason.
 
 That only happens because HAVE_OFF_T isn't being set in config.h.  In
 fact it is hard-coded to 0 by default and set to 1 on certain supported
 platforms such as Mac OS X (in rubyconfigure.h).


 With the patch below, then running:
 
 $ aclocal-1.10  autoheader  autoconf
 
 implements a proper detection for off_t and it builds now on
 kfreebsd-amd64.  Also it still builds okay and runs on GNU/Linux amd64.
 
 --- a/configure.in  2007-10-25 21:38:55.0 +0100
 +++ b/configure.in  2012-11-30 02:01:34.039114307 +
 @@ -288,6 +288,8 @@
  ])
  ])
  
 +AC_CHECK_TYPES([off_t], [], [], [[#include sys/types.h]])
 +

I guess ideally the code would be using AC_TYPE_OFF_T, but as you
mention that the code depends on HAVE_OFF_T, then this might be the
smallest change to accomplish the same thing.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121130083531.ga24...@gaara.hadrons.org

Re: Providing strl/strl.h in libbsd

[Guillem Jover]

On Fri, 2012-11-23 at 12:32:04 -0500, Scott Kitterman wrote:
 On Friday, November 23, 2012 01:25:56 AM Guillem Jover wrote:
  I've just checked to see where this strl.h is coming from, and it
  appears to be a compat library of its own, and TBH I don't see the
  point in adding support for that when it's not a standard BSD header,
  and while I'm trying to get rid of the non-standard headers from
  libbsd. If upstream is using those functions from the native BSD
  system then the libbsd overlay should imply zero changes to the
  upstream sources.
 
 Thanks.  I'll take it up with them.

Oh, and in addition upstream projects like samba have started relying
on libbsd, and it is available in most major GNU/Linux distributions
already, see the list of downstreams in
http://libbsd.freedesktop.org/wiki/, there might be others I'm not
aware of though.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121123174525.ga23...@gaara.hadrons.org

Re: Providing strl/strl.h in libbsd

[Guillem Jover]

Hi!

On Wed, 2012-11-21 at 21:14:05 -0500, Scott Kitterman wrote:
 I'm one of the maintainers of opendkim.  The upstream developer is a
 BSD user and opendkim makes use of strlcpy and strlcat and he has, up
 to now, provided an embedded copy of these functions for non-BSD
 platforms.
 
 In opendkim 2.7,  there is the possibility to use a system strlcpy and 
 srtlcat, which I can make work, but due to the lack of strl.h, there are 
 implicit declaration warnings.  Would it be possible to add this header
 file to the Debian shipped libbsd?

Well strl.h is not a “standard” BSD header, on BSDs those functions are
declared in string.h, when using libbsd it's either in string.h
when using the overlay (pkg-config --cflags libbsd-overlay), or in
bsd/string.h.

I've just checked to see where this strl.h is coming from, and it
appears to be a compat library of its own, and TBH I don't see the
point in adding support for that when it's not a standard BSD header,
and while I'm trying to get rid of the non-standard headers from
libbsd. If upstream is using those functions from the native BSD
system then the libbsd overlay should imply zero changes to the
upstream sources.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121123002556.ga10...@gaara.hadrons.org

Bug#665997: closed by Guillem Jover guil...@debian.org (Bug#665997: fixed in libbsd 0.4.0-1)

[Guillem Jover]

Hi!

On Thu, 2012-11-22 at 02:20:10 +, Colin Watson wrote:
 On Tue, May 29, 2012 at 07:06:30AM +, Debian Bug Tracking System wrote:
  This is an automatic notification regarding your Bug report
  which was filed against the src:libbsd package:
  
  #665997: libbsd uses wrong compiler when cross-building
  
  It has been closed by Guillem Jover guil...@debian.org.
 [...]
   - Autoconfiscated, supports cross-building natively. (Closes: #665997)
 
 This is nearly there, but not quite.  You're not passing the required
 --build and --host options to configure, so it doesn't know that it's
 supposed to cross-compile.  I've confirmed that the following patch
 fixes it.
 
   * Pass correct --build= and --host= options to configure.

Hmm, certainly, I've applied now a slightly modified version of the
patch, thanks. Will be included in the next upload, most probably
after the freeze.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121123003556.gb10...@gaara.hadrons.org

Re: elfutils FTBFS

[Guillem Jover]

On Thu, 2012-11-15 at 14:12:18 -0800, Christoph Egger wrote:
   Can anyone look at elfutils? it hasn't successfully built on kfreebsd
 for 2 years (and was always fixed by a binary upload)
 
 #debian-hurd:
  pinotree christoph: 
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041#17 and #682101 
  could give few hints more about the failures
  pinotree there are unconditional linuxisms there, and few of those 
  (/proc/$pid/maps) work on kfreebsd because freebsd's procfs implements it
  christoph I see
  pinotree christoph: if you see the hurd build logs, the two failing tests 
  are the same that fails on kfreebsd

I built it yesterday, and it succeeded, one test was skipped though.
Checking now the log for kbsd, I see the two additional FAILed tests
Pino was mentioning, but those didn't trigger for me. Christoph, OOC
could you trigger a binNMU for one of the kbsd arches just to see if
things have changed, or if this only triggers on buildds?

In any case I've fixed some of the problems with elflint, there's only
a remaining one there. I'll try to take a look at the build failure on
GNU/Hurd to see if it can still be reproduced there.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121116230550.ga20...@gaara.hadrons.org

Re: Bug#692992: FTBFS on kfreebsd-*

[Guillem Jover]

On Mon, 2012-11-12 at 15:03:20 +0100, Michael Biebl wrote:
 On 12.11.2012 03:24, Guillem Jover wrote:
  On Sun, 2012-11-11 at 21:01:16 +0100, Michael Biebl wrote:
  The imptcp module seems like has never been available in anything
  non-Linux, so I've restricted its build in the rules file; the ideal
  solution here would be to port it to use kqueue which would make it
  work on most BSDs (that's why I've not bothered with a configure check
  for epoll). The sys/klog.h conditional inclusion should be dependant
  on the presence of the file, but because I saw another module checking
  based on OS_LINUX, I just used that instead. The ideal fix for the
  uptime code would be to use clock_gettime(CLOCK_UPTIME) on FreeBSD
  and GNU/kFreeBSD, and sysctl kern.boottime on OpenBSD, NetBSD and
  DragonFlyBSD.

For GNU/Hurd, one should get the task creation time of PID 1 (init);
also the kern.boottime sysctl seems to be available on most (if not all
BSDs, so it might be the most portable solution), rather than special
casing FreeBSDs; I've updated my porting guidelines page to add (more)
information about this:

  http://www.hadrons.org/~guillem/debian/ports/porting

 Would anyone be interested to address these both issues as outlined by
 guillem? Disabling the code on non-Linux is an option but I would prefer
 if it would just work on the other archs.

I might get to it eventually, but as I don't use rsyslog, no promises
from my part.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121112144221.ga30...@gaara.hadrons.org

Re: Bug#692992: FTBFS on kfreebsd-*

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sun, 2012-11-11 at 21:01:16 +0100, Michael Biebl wrote:
 Package: src:rsyslog
 Version: 7.2.1-1
 Severity: serious
 User: debian-bsd@lists.debian.org
 Usertags: kfreebsd

 the current version of rsyslog from experimental (7.2.1) FTBFS on
 kfreebsd-*.

 It would be great if the kfreebsd porters would have a look and provide
 a patch.

Attached a patch fixing the issues in the code, only build tested on
GNU/kFreeBSD though (w/ the db code disabled).

The imptcp module seems like has never been available in anything
non-Linux, so I've restricted its build in the rules file; the ideal
solution here would be to port it to use kqueue which would make it
work on most BSDs (that's why I've not bothered with a configure check
for epoll). The sys/klog.h conditional inclusion should be dependant
on the presence of the file, but because I saw another module checking
based on OS_LINUX, I just used that instead. The ideal fix for the
uptime code would be to use clock_gettime(CLOCK_UPTIME) on FreeBSD
and GNU/kFreeBSD, and sysctl kern.boottime on OpenBSD, NetBSD and
DragonFlyBSD.

In any case when trying to build rsyslog on GNU/kFreeBSD, it failed to
build the libgrammar convenience library, because it seems the local
libtool script ends up getting truncated during generation. I've not
investigated why that is, but an «autoreconf -f -i» solved the issue.
And something that looked suspicious is that the previous libtool
support was coming from an Ubuntu version, so maybe that's broken
and is the reason.

thanks,
guillem
diff --git a/configure.ac b/configure.ac
index 331c77b..2930fa1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -115,7 +115,7 @@ AC_TYPE_SIGNAL
 AC_FUNC_STAT
 AC_FUNC_STRERROR_R
 AC_FUNC_VPRINTF
-AC_CHECK_FUNCS([flock basename alarm clock_gettime gethostbyname gethostname gettimeofday localtime_r memset mkdir regcomp select setid socket strcasecmp strchr strdup strerror strndup strnlen strrchr strstr strtol strtoul uname ttyname_r getline malloc_trim prctl epoll_create epoll_create1 fdatasync lseek64])
+AC_CHECK_FUNCS([flock basename alarm clock_gettime gethostbyname gethostname gettimeofday localtime_r memset mkdir regcomp select setid socket strcasecmp strchr strdup strerror strndup strnlen strrchr strstr strtol strtoul sysinfo uname ttyname_r getline malloc_trim prctl epoll_create epoll_create1 fdatasync lseek64])
 
 # the check below is probably ugly. If someone knows how to do it in a better way, please
 # let me know! -- rgerhards, 2010-10-06
diff --git a/debian/rsyslog.install b/debian/rsyslog.install
index f0233a2..51e0055 100644
--- a/debian/rsyslog.install
+++ b/debian/rsyslog.install
@@ -6,8 +6,7 @@ usr/lib/rsyslog/imfile.so
 usr/lib/rsyslog/imklog.so
 usr/lib/rsyslog/imkmsg.so
 usr/lib/rsyslog/immark.so
-usr/lib/rsyslog/impstats.so
-usr/lib/rsyslog/imptcp.so
+usr/lib/rsyslog/imp*.so
 usr/lib/rsyslog/imtcp.so
 usr/lib/rsyslog/imudp.so
 usr/lib/rsyslog/imuxsock.so
diff --git a/debian/rules b/debian/rules
index 5324d77..16b1951 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,17 +3,23 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
 %:
 	dh $@ --with autotools_dev
 
+ifeq ($(DEB_HOST_ARCH_OS), linux)
+confflags += --enable-imptcp
+endif
+
 override_dh_auto_configure:
 	dh_auto_configure -- \
+		$(confflags) \
 		--enable-mysql \
 		--enable-pgsql \
 		--enable-ommongodb \
 		--enable-mail \
 		--enable-imfile \
-		--enable-imptcp \
 		--enable-impstats \
 		--enable-kmsg \
 		--enable-klog \
diff --git a/plugins/imkmsg/kmsg.c b/plugins/imkmsg/kmsg.c
index 9ad98da..b771d68 100644
--- a/plugins/imkmsg/kmsg.c
+++ b/plugins/imkmsg/kmsg.c
@@ -32,7 +32,9 @@
 #include errno.h
 #include string.h
 #include ctype.h
+#ifdef  OS_LINUX
 #include sys/klog.h
+#endif
 #include json/json.h
 
 #include rsyslog.h
diff --git a/runtime/msg.c b/runtime/msg.c
index d874178..7da1443 100644
--- a/runtime/msg.c
+++ b/runtime/msg.c
@@ -2875,7 +2875,7 @@ uchar *MsgGetProp(msg_t *pMsg, struct templateEntry *pTpe,
 			*pbMustBeFreed = 0;
 			break;
 		case PROP_SYS_UPTIME:
-#			ifdef OS_SOLARIS
-			pRes = (uchar*) UPTIME NOT available under Solaris;
+#			ifndef HAVE_SYSINFO
+			pRes = (uchar*) UPTIME NOT available on this system;
 			*pbMustBeFreed = 0;
 #			else

Re: RFC: drop __GLIBC__ on gcc/kbsd

[Guillem Jover]

Hi!

On Tue, 2012-11-06 at 13:05:02 +0100, Pino Toscano wrote:
 years ago, when Robert Millan improved the support for k*bsd* in gcc, he 
 added the __GLIBC__ define as part of the ones provided by gcc itself 
 (see [1][2]).
 Unfortunately, __GLIBC__ is one of the defines provided by glibc itself 
 (in the internal features.h included in any public header), and 
 because of this (e)glibc on debian/kfreebsd has to carry the patch 
 local-undef-glibc.diff. Indeed, compiling trying to compile the simple:
   #ifdef __GLIBC__
   # error __GLIBC__ defined with no includes!
   #endif
   int main() { return 0; }
 fails on kFreeBSD while it succeeds on Linux and Hurd.
 This also causes that porting code like:
 -#if defined(__linux__)
 +#if defined(__linux__) || defined(__GLIBC__)
 makes it work on kFreeBSD but still failing on Hurd (in situation where 
 there is no #include of stdlib headers prior to that), and in the past 
 I've been personally hit by this few times (and I'm not the only Hurd 
 porter to have hit such situation).
 
 Since IMHO it is awkward for a compiler to claim to be a libc,

Well, yes and no, it might seem weird because as you say gcc != glibc,
but then the compiler is built targetting a specfic libc, which trickles
into the triplet (as seen from -dumpmachine), because it needs to know
how to interact with it, among other things.

For me the biggest issues are:

That the macro is defined even when using -ffreestanding (which is just
wrong, although as wrong is to build kernels w/o it, and at least Linux
is doing just that), and the possible problem of kernel headers exposed
to userland that might need to change userland (but not kernel-space)
behaviour (something like
http://lists.debian.org/debian-bsd/2012/02/msg00025.html comes to
mind).

And that it's not consistent across GNU systems, currently upstream gcc
on GNU/kFreeBSD, GNU/kNetBSD and GNU/kOpenSolaris define __GLIBC__,
other systems might not (which can create portability issues due to the
uncertainty as has been pointed out in the past, an example that came to
mind could be http://lists.debian.org/debian-bsd/2010/02/msg00097.html,
or the examples that you mention about problems for GNU/Hurd).

 my suggestion (as also shown in the topic) is to drop the definition of 
 __GLIBC__ done in the k*bsd* configuration of gcc.
 My proposal would be to remove it upstream and, once Whezy is released, 
 backport the patch for any gcc version in Debian. This should leave 
 plenty of time (at least 1-1½ years) to fix the (few?) kFreeBSD-specific 
 build failures and issues that could arise because of that (note that 
 some of the cases were fixed in the past with Hurd porting).

I think -ffreestanding should never define those, after or while that
is fixed in whatever way, all GNU systems should be unified in either
direction, because otherwise it just creates confusion. But that would
require the porters for those systems to agree on either direction,
because as you mention it might cause build failures for them.
GNU/kNetBSD is a non-issue as it's not currently under development.
For GNU/kFreeBSD I'd support either solution, although I think it'd
be better to just stop defining the macro.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121107070201.ga30...@gaara.hadrons.org

Re: freebsd-utils_9.0+ds1-6_kfreebsd-i386.changes ACCEPTED into unstable

[Guillem Jover]

On Fri, 2012-06-22 at 12:33:32 +0100, Steven Chamberlain wrote:
 Was that a mistake, or is there going to be an upload of that too?  In
 the latter case, an urgency=low upload of freebsd-glue would now need a
 freeze unblock.

I don't see why, the freeze is supposed to let any package in sid at
the time migrate automatically to testing.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120622211209.gb3...@gaara.hadrons.org

Bug#678136: zfsutils: FTBFS with libbsd-dev = 0.4.0

[Guillem Jover]

On Thu, 2012-06-21 at 21:40:39 +0200, Arno Töll wrote:
 tag 678136 + pending
 thanks

 On 21.06.2012 21:18, Steven Chamberlain wrote:
  Actually you're right, it's fine now in up-to-date sid chroot.
 
 cool, thanks. I'll wait a bit for Robert or someone else to comment on
 the patch. Otherwise I'll upload it soon.

I guess the libbsd-overlay could be used instead to avoid having to
patch the sources.

And sorry I didn't catch this when I was supposed to check all reverse
depends.

thanks,
guillem



--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120622211026.ga3...@gaara.hadrons.org

Re: Bug#677227: screen: Workaround for #644788 fails to detect a running screen on kfreebsd / process renaming does not work on kfreebsd

[Guillem Jover]

On Tue, 2012-06-12 at 14:34:16 +0100, Steven Chamberlain wrote:
 On 12/06/12 14:23, Axel Beckert wrote:
  But on kfreebsd this process renaming don't seem to work. This doesn't
  seem to be a screen issue but a general kfreebsd issue as the following
  works as expected on Linux, but not on kfreebsd:
  
  $ perl -e '$0 = foobar!; '

 I recall that setproctitle was implemented as a no-op in libbsd.  So
 that is probably a known bug / unimplemented yet.

I don't think neither perl nor screen are using libbsd-dev, though?

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120612164206.ga27...@gaara.hadrons.org

Re: Bug#674260: RM: aspectc++ [kfreebsd-i386 kfreebsd-amd64] -- ROM; FTBFS on kfreebsd

[Guillem Jover]

On Thu, 2012-05-24 at 08:12:50 +0200, Reinhard Tartler wrote:
 Package: ftp.debian.org
 Severity: normal

 The package aspectc++ does not build on kfreebsd since April now. The
 reason for this is, as I suspect, a bug or insufficienty in the fnctl()
 implementation on kfreebsd. In order to speed up compilation (ac++ is
 dead slow), the compilation is run in parallel where possible. However,
 each compilation step needs to store information about the found join
 points and woven advice instantiation in project wide aspect
 repository, which needs to be guarded against concurrent updates from
 ac++ processes. And this locking now seems to fail fatally since
 upstream release 1.1.
 
 Before 1.1, AFAIUI locking didn't work either, and you ended up with a
 corrupt aspect repository -- rending the package pretty much useless
 IMO, but YMMV.
 
 This has been documented as #633402, and porters have already been asked
 for help. Unfortunately, no solution could be found. Therefore, I have
 to ask for an architecture specific removal in order to allow the
 package to migrate to testing.

I've just quickly checked the aspectc++ source code and found out the
problem is in there, and as such this removal request is not warranted.
All struct flock initializers in (at least) Puma/src/basics/SysCall.cc
are bogus, as it assumes the layout of the struct flock whose members
are explicitly defined as not having a specific order. The code should
switch to use named initializers or simple member assignments [0]. I've
not checked or tested if there's other portability issues though.

[0]

  struct flock fl = { .l_type = A, .l_whence = B, ... };

or

  struct flock fl;

  fl.l_type = A;
  fl.l_whence = B;
  ...


thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120524233509.ga13...@gaara.hadrons.org

Bug#669604: kbdcontrol can't load any keymap

[Guillem Jover]

On Wed, 2012-05-16 at 23:28:29 +0200, Robert Millan wrote:
 tag 669604 unreproducible moreinfo
 thanks

 2012/4/20 Robert Millan r...@debian.org:
  El 20 d’abril de 2012 13:34, Anton Zinoviev an...@lml.bas.bg ha escrit:
  # kbdcontrol -l any_file.kbd
  kbdcontrol: setting keymap: Inappropriate ioctl for device
 
  Try:
 
  kbdcontrol -l file.kbd  /dev/console
 
  /dev/console works for me.  If I don't hear any more news on this,
 I'll assume that it also works for everyone else and consider this bug
 as fixed.

I experienced this too when running a kfreebsd 8.2 kernel, it went
away when switching to either 8.3 or 9.0, IIRC.

Seeing the initial System Information from Anton, this would seems to
confirm it.

thanks,
guillem



--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120519144235.ga32...@gaara.hadrons.org

Bug#668705: libbsd: Tracking upload of prospective 0.4.0 release

[Guillem Jover]

Source: libbsd
Version: 0.3.0-2
Severity: wishlist

Hi!

This is just a bug to track the upload of the yet to be released
libbsd 0.4.0. I've it almost ready but I wanted to test build
Build-Dependencies to check if everything was fine due to some
header cleanup included in that release, and there's some packages
which FTBFS due to some previously wrong assumptions. So I might
reinclude some removed compat headers to avoid disruption, but
those will really go away for 0.5.0.

I'll be filing bug reports blocking this bug, once they are fixed
I'll proceed with the upload.

thanks,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120414053007.ga7...@gaara.hadrons.org

Bug#649234: RM: type-handling -- RoM; unmaintained, debian specific, obsoleted by dpkg arch wildcards

[Guillem Jover]

retitle 649234 RM: type-handling -- RoM; unmaintained, debian specific, 
obsoleted by dpkg arch wildcards
severity 649234 normal
reassign 649234 ftp.debian.org
thanks

Hi!

On Thu, 2012-03-15 at 12:58:36 +0100, Jakub Wilk wrote:
 * Guillem Jover guil...@debian.org, 2011-11-19, 05:19:
 This is a tracking bug report for the removal of the package, once
 the blocking bugs have been fixed or we decide we want to remove
 it regardless (ideally before wheezy is released), this can be
 reassigned to ftp-master for the removal from the archive.
 
 I believe that there are no packages using type-handling left in
 unstable or experimental. :)

Right, I noticed your coreutils NMU some days ago and was planning on
acting on this, doing it now, thanks!

ftp-masters please remove type-handling from the archive, in case you
need more details:

 http://lists.debian.org/debian-bsd/2011/11/msg00180.html

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120317225926.ga13...@gaara.hadrons.org

Re: Bug#657772: collectd: FTBFS(kfreebsd): deprecated libbsd-dev usage and Werror

[Guillem Jover]

clone 657772 -1
reassign -1 libkvm-dev
retitle -1 libkvm-dev: Should use bsd/nlist.h
retitle 657772 libbsd-dev: Should not provide nlist.h
severity 657772 important
thanks

On Sat, 2012-01-28 at 18:04:42 +, Robert Millan wrote:
 reassign 657772 libbsd-dev
 found 657772 0.3.0-1
 retitle 657772 libbsd-dev: please provide a working nlist.h
 thanks
 
 El 28 de gener de 2012 17:39, Sebastian Harl tok...@debian.org ha escrit:
  Hrm, this sounds like a problem in libkvm to me and should be fixed
  there. The only thing I could do in collectd is disable the use of
  libkvm (and, thus, probably remove support for a few plugins).
 
 I agree that libkvm users shouldn't have to bother about this problem.

Yes.

 However we don't need to add a workaround in libkvm-dev since this is
 very easy to fix in libbsd-dev (simply by installing nlist.h in its
 standard location).

The problem is that nlist.h is provided too by libelf*-dev, so libbsd-dev
has had to Replace those, which is actually wrong, as then the file will
disappear in the following sequence:

  apt-get install libbsd-dev libelf-dev
  apt-get remove libbsd-dev

After this, packages Build-Depending on libelf-dev will no longer be
able to find nlist.h. For the next libbsd upstream release I've actually
moved all those headers under /usr/include/bsd/, so this will have to
be fixed anyway.

libkvm-dev could instead Build-Depend on libelf-dev/libelfg0-dev, but
given that it's linking against libbsd anyway, it seems like a
gratuituous build and runtime dependency.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120225202441.ga19...@gaara.hadrons.org

Re: sysvinit: FTBFS on kfreebsd due to missing sys/signalfd.h

[Guillem Jover]

Hi!

On Fri, 2012-01-27 at 21:42:17 +, Roger Leigh wrote:
 Package: sysvinit
 Version: 2.88dsf-19
 Severity: normal
 
 cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Wformat-security -Werror=format-security -W -Wall -D_GNU_SOURCE  
 -DACCTON_OFF  -c -o last.o last.c
 cc -Wl,-z,relro  last.o oldutmp.h   -o last
 cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Wformat-security -Werror=format-security -W -Wall -D_GNU_SOURCE  
 -DACCTON_OFF  -c -o mesg.o mesg.c
 cc -Wl,-z,relro  mesg.o   -o mesg
 make[2]: Leaving directory 
 `/build/buildd-sysvinit_2.88dsf-19-kfreebsd-amd64-q08mr8/sysvinit-2.88dsf/src'
 /usr/bin/make  -C startpar
 make[2]: Entering directory 
 `/build/buildd-sysvinit_2.88dsf-19-kfreebsd-amd64-q08mr8/sysvinit-2.88dsf/startpar'
 gcc   -D_GNU_SOURCE  -Wall -W -pipe -DVERSION=\0.58\ -DNOTSUSE -c startpar.c
 startpar.c:45:26: fatal error: sys/signalfd.h: No such file or directory
 compilation terminated.
 make[2]: *** [startpar.o] Error 1
 make[2]: Leaving directory 
 `/build/buildd-sysvinit_2.88dsf-19-kfreebsd-amd64-q08mr8/sysvinit-2.88dsf/startpar'
 make[1]: *** [override_dh_auto_build] Error 2
 make[1]: Leaving directory 
 `/build/buildd-sysvinit_2.88dsf-19-kfreebsd-amd64-q08mr8/sysvinit-2.88dsf'
 make: *** [build] Error 2
 
 This needs a kfreebsd workaround (also fails on kfreebsd-i386).

signalfd is a Linux only interface (see [0]), BSD based systems can use
kqueue instead, also Solaris through libkqueue, for GNU/Hurd I'm not sure
what's the equivalent. In any case this worked fine with -18, so given
the extent of this regression wouldn't reverting back to the previous
startpar be the ideal solution for now? Or does the new code base give
significant improvements?

Also this seems should be of serious severity instead?

[0] http://www.hadrons.org/~guillem/debian/ports/porting

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120127225015.ga11...@gaara.hadrons.org

Re: Bug#655865: FTBFS on kfreebsd-*: field 'export' has incomplete type

[Guillem Jover]

On Sun, 2012-01-15 at 13:41:12 +, Robert Millan wrote:
 El 14 de gener de 2012 19:17, Guillem Jover guil...@debian.org ha escrit:
  This is a problem with the newer kfreebsd-kernel-headers, reassigning.
 
 Actually it's not.  Upstream considers that users of some headers are
 responsible for satisfying their dependencies.  I don't know if
 there's a rule of thumb, but the missing include in
 isofs/cd9660/cd9660_mount.h is clearly intentional.

Sure, the problem here though is that nowhere “struct oexport_args” is
defined. “struct export_args” is defined in triplet/sys/mount.h. So
I'd say either the member fields need a rename or the missing struct
needs to be reintroduced. This definitely seems to me like a problem
with kfreebsd-kernel-headers?

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120115192030.ga11...@gaara.hadrons.org

Re: Bug#655865: FTBFS on kfreebsd-*: field 'export' has incomplete type

[Guillem Jover]

reassign 655865 kfreebsd-kernel-headers
retitle 655865 kfreebsd-kernel-headers: missing type to define 'export' field 
in headers breaks program compilation
affects 630203 src:libpmount
forcemerge 630203 655865
thanks

Hi!

On Sat, 2012-01-14 at 13:44:17 +0100, Luca Falavigna wrote:
 Source: libpmount
 Version: 0.0.14
 Severity: serious
 Justification: fails to build from source

 libpmount fails to build from source on kfreebsd-*, but built in the past:
 
 make[2]: Leaving directory 
 `/build/buildd-libpmount_0.0.15-kfreebsd-amd64-vqaT4T/libpmount-0.0.15/tests'
 make[1]: Leaving directory 
 `/build/buildd-libpmount_0.0.15-kfreebsd-amd64-vqaT4T/libpmount-0.0.15'
 dh_clean
  debian/rules build
 dh_testdir
 /usr/bin/make build \
 CPPFLAGS= CFLAGS=-Wall -g -O2 -fstack-protector 
 --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
 -Werror=format-security LDFLAGS=-Wl,-z,relro
 make[1]: Entering directory 
 `/build/buildd-libpmount_0.0.15-kfreebsd-amd64-vqaT4T/libpmount-0.0.15'
 cc  -Wall -g -O2 -fstack-protector --param=ssp-buffer-size=4 
 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
 -D_REENTRANT -DUSE_LOOP -fPIC -c -o src/kerndep.lo src/kerndep.c
 In file included from src/kfreebsd.c:61:0,
  from src/kerndep.c:4:
 /usr/include/isofs/cd9660/cd9660_mount.h:43:22: error: field 'export' has 
 incomplete type
 make[1]: *** [src/kerndep.lo] Error 1
 make[1]: Leaving directory 
 `/build/buildd-libpmount_0.0.15-kfreebsd-amd64-vqaT4T/libpmount-0.0.15'
 make: *** [build-arch] Error 2
 
 https://buildd.debian.org/status/fetch.php?pkg=libpmountarch=kfreebsd-amd64ver=0.0.15stamp=1317234188
 https://buildd.debian.org/status/fetch.php?pkg=libpmountarch=kfreebsd-i386ver=0.0.15stamp=1317234226

This is a problem with the newer kfreebsd-kernel-headers, reassigning.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120114191759.ga2...@gaara.hadrons.org

Bug#631639: __unused in libbsd. workaround for #522773 (linux) and #522774 (libc)

[Guillem Jover]

On Mon, 2012-01-02 at 04:27:54 +0100, Guillem Jover wrote:
 On Sat, 2011-06-25 at 19:06:48 +0200, Robert Millan wrote:
  Package: libbsd-dev
  Version: 0.3.0-1
  Severity: wishlist
  Tags: patch
  User: debian-bsd@lists.debian.org
  Usertags: kfreebsd
  
  This patch implements a workaround for __unused name collision with Linux 
  and
  Glibc.  The trick is to define __unused only when in overlay mode, and then
  provide replacements for broken headers using the overlay.
 
 I think this crosses my threshold of something acceptable for libbsd.
 What I've done instead is prepare and send patches to Linux and glibc
 upstream, which is the correct fix on this issue IMO:
 
   http://marc.info/?l=linux-kernelm=132547276312101w=2
   http://www.cygwin.com/ml/libc-ports/2012-01/msg0.html
 
 The one on libc-alpha is not yet visible though. Let's see how these go.

Now visible at:

  http://sourceware.org/ml/libc-alpha/2012-01/msg1.html

thanks,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102213143.ga5...@gaara.hadrons.org

Bug#631639: __unused in libbsd. workaround for #522773 (linux) and #522774 (libc)

[Guillem Jover]

Hi!

On Sat, 2011-06-25 at 19:06:48 +0200, Robert Millan wrote:
 Package: libbsd-dev
 Version: 0.3.0-1
 Severity: wishlist
 Tags: patch
 User: debian-bsd@lists.debian.org
 Usertags: kfreebsd
 
 This patch implements a workaround for __unused name collision with Linux and
 Glibc.  The trick is to define __unused only when in overlay mode, and then
 provide replacements for broken headers using the overlay.

I think this crosses my threshold of something acceptable for libbsd.
What I've done instead is prepare and send patches to Linux and glibc
upstream, which is the correct fix on this issue IMO:

  http://marc.info/?l=linux-kernelm=132547276312101w=2
  http://www.cygwin.com/ml/libc-ports/2012-01/msg0.html

The one on libc-alpha is not yet visible though. Let's see how these go.

thanks,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102032754.ga11...@gaara.hadrons.org

Bug#653193: Missing patch

[Guillem Jover]

On Sun, 2011-12-25 at 11:56:45 +0100, Robert Millan wrote:
  +#define __FAVOR_BSD 1
   #include netinet/in_systm.h
   #include netinet/in.h
   #include netinet/ip.h
   #include netinet/ip_icmp.h
   #include netinet/tcp.h
   #include netinet/udp.h
  +#undef __FAVOR_BSD
 
 Shouldn't this kind of fix be in libbsd-dev?  E.g. in overlay netinet/in.h:
 
 #if __FAVOR_BSD
 #  include_next netinet/in.h
 #else
 #  define __FAVOR_BSD 1
 #  include_next netinet/in.h
 #  undef __FAVOR_BSD
 #endif

I'd rather not, libbsd is there to help in porting by making embedded
sources unnecessary and adding missing declarations and similar, but
there's a limit to what extent it should include major hacks like this,
some times the source just need to be made more portable or fixed some
other way. In this case __FAVOR_BSD is an internal glibc macro, the
source should be using _BSD_SOURCE instead of _GNU_SOURCE, currently
passed through CFLAGS in debian/rules.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231223353.ga11...@gaara.hadrons.org

Bug#631639: __unused in libbsd. workaround for #522773 (linux) and #522774 (libc)

[Guillem Jover]

On Sat, 2011-06-25 at 17:24:00 +, Thorsten Glaser wrote:
 That won’t help. The overlay mode uses pkg-config which no BSD thing
 touches.

Well, even OpenBSD has its own re-implementation:

  
http://www.openbsd.org/cgi-bin/man.cgi?query=pkg-configsektion=1format=html

regards,
guillem



--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231013742.ga23...@gaara.hadrons.org

Bug#631639: proposed workaround for __unused problem

[Guillem Jover]

Hey Robert,

On Fri, 2011-11-25 at 19:51:02 +0100, Robert Millan wrote:
 Please can you comment on my proposed workaround in bug #631639?

Sorry for the disappearence regarding libbsd and libmd, I've been tied
up with other stuff and never got to finalize the bureaucratic part of
the libmd release, and to prepare a new libbsd release too. I'll try to
allocate some time this next week to handle both.

thanks,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2027234406.ga17...@gaara.hadrons.org

Bug#274747: type-handling: 274747: dpkg-dev dependency removal

[Guillem Jover]

Hi!

On Fri, 2011-11-18 at 02:47:33 +0100, Jakub Wilk wrote:
 * Jakub Wilk jw...@debian.org, 2011-11-17, 12:18:
   Ah, thanks for the list Jakub! Is that exhaustive, against all
   possible Provides generated by type-handling or only a selected
   few?
 
  I believe it's exhaustive, but I'll double-check later today.
 
 I set up pages to track reverse (build-) dependencies:
 http://people.debian.org/~jwilk/type-handling/reverse-depends
 http://people.debian.org/~jwilk/type-handling/reverse-build-depends
 
 The code used to generate them is available here:
 http://people.debian.org/~jwilk/type-handling/Makefile

Wonderful, thanks!

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2018180804.ga26...@gaara.hadrons.org

Bug#274747: type-handling: 274747: dpkg-dev dependency removal

[Guillem Jover]

Hi!

On Thu, 2011-11-17 at 00:58:30 +0100, Jakub Wilk wrote:
 * Robert Millan r...@debian.org, 2011-11-16, 18:18:
 I just added Depends: linux to iotop (arch all, written in
 python and depends on a Linux kernel) before I realised that
 type-handling pulls in dpkg-dev. I would really appreciate it if
 the type-handling Provides were split off into a second package,
 or maybe dpkg is the right place for the Provides?

dpkg is not the right place for the Provides, those are a hack, are
overstepping on the package name space, and they should really go.

The only reason this has not happened yet is because there's still
packages depending on it on the archive.

There's also the other questionable reasons related to arch:all
packages. Used up to now to either be able to conditionalize arch
specific dependencies or as in your case to make it uninstallable
on specific arches.

But I'd argue that both those usages are bogus:

 * For the first one, if the script is portable and can work w/o the
   specific dependency on other systems, then that implies it should
   not be a Depends but a Recommends, so no need for the Provides.

 * The second case comes from conflating the two roles of arch:all
   packages, saving archive space by avoiding duplication sharing
   the same files across arches and shipping truly arch independent
   files/scripts. In the iotop case the scripts are not arch independent
   even if they are shareable. Restricting it by uninstallability is
   just another hack, the users on a package manager frontend will
   wonder why they are shown a packages they cannot possibly install,
   the Packages files get unneedingly bloated, etc. A possible clean
   solution to this could be something like: linux-all, all-i386, etc,
   for example which was discussed already during the design of the
   arch wildcards.

 Given that there are only two packages that still use
 type-handling in their Build-Depends (e2tools and gdb),
 
 (There's also control-center, which is fixed only in experimental.)
 
 and that both have bugs tagged pending that fix that, I think the
 dpkg-dev dependency can just be removed.
 
 dpkg-dev is build-essential, so it shouldn't make a difference for
 packages build-depending on it.
 
 buildcross (in experimental) depends on type-handling, though I
 don't know why.

 There are also some users of virtual packages provided by type-handling:

 Source: coreutils
 Build-Depends: ..., libattr1-dev | not+linux-gnu, libacl1-dev | 
 not+linux-gnu, libselinux1-dev (= 1.32) | not+linux-gnu, ...
 
 Source: mc
 Build-Depends: ..., libgpm-dev | not+linux-gnu, ...
 
 Source: ntp
 Build-Depends: ..., libcap2-dev | not+linux-gnu, ...
 
 Package: usb-modeswitch-data
 Depends: udev (= 0.140) | not+linux-gnu
 
 Package: iotop
 Depends: ..., linux

Ah, thanks for the list Jakub! Is that exhaustive, against all
possible Provides generated by type-handling or only a selected few?

 Given how little used type-handling is, maybe it's time to remove it?

Yes, see:

  http://lists.debian.org/debian-bsd/2011/10/msg00199.html

I'll be filing bug reports against those packages to switch to arch
wildcards if no one beats me to it eventually. In addition those have
the problem that they will not match on things like linux-gnueabi for
example.

thanks,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2017021127.ga15...@gaara.hadrons.org

Getting rid of type-handling from the archive

[Guillem Jover]

Hi!

I've been filing bug reports on packages Build-Depending on
type-handling to switch to native arch wildcards, the bugs still open
are:

  #639117 [w|+|  ] e2tools: Remove unused type-handling from Build-Depends
  #639332 [w|+|  ] buildcross: Remove deprecated Depends on type-handling
  #639164 [w|+P| ] gdb: Stop using deprecated type-handling Build-Depends

The remaining issue is the virtual architectures Provided by
type-handling itself used in dependency fields, which are known to
cause problems on buildds.

Before even considering its removal I think we should know how many
packages make use of those virtual architecture dependencies, and file
bugs accordingly (maybe after a mass-bug discussion on devian-devel).
Those would need to be checked against every architecture Packages file
for anything matching «dpkg-architecture -L» output, and the split
cpu/system variants.

Thorsten Glaser proposed to try to make this a release goal, but even
if we've had in mind getting rid of type-handling for a long time, I
don't think I could take active responsibility of such release goal at
the moment.

Anyone volunteers?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111016102805.ga25...@gaara.hadrons.org

Re: Please test zfsutils 9.0~svn226163-1

[Guillem Jover]

On Mon, 2011-10-10 at 01:35:36 +0200, Arno Töll wrote:
 * We could get rid of the last delta in 01_glibc_kludge.diff and the
 whole (hacky and ugly) 16-wrap-cdefs.diff if kfreebsd-kernel-headers
 would export cdefs.h like it does upstream [2].

As Petr has said sys/cdefs.h is already exported by eglibc, the only
issue I see here is that our kernel headers [0] do not match what's
expected from them by eglibc ones, so we should fix those because this
affects *all* software using specific features and their visibility, I
don't think it's reasonable for every package to use libbsd-dev to
workaround this.

[0] Some of the affected headers seem to be (grepped for _VISIBLE):
/usr/include/sys/limits.h
/usr/include/sys/timespec.h
/usr/include/machine-*/endian.h
/usr/include/machine-*/float.h
/usr/include/machine-*/setjmp.h
/usr/include/machine-*/signal.h
/usr/include/machine-*/stdarg.h

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111014223318.gb20...@gaara.hadrons.org

Re: Bug#644431: theunarchiver: FTBFS(kfreebsd): undefined reference to `reallocf'

[Guillem Jover]

Hi!

On Wed, 2011-10-05 at 21:36:16 +0200, Christoph Egger wrote:
 Package: src:theunarchiver
 Version: 2.7.1-2
 Severity: serious
 Tags: sid wheezy
 X-Debbugs-Cc: debian-bsd@lists.debian.org
 Justification: fails to build from source (but built successfully in the past)

 Your package failed to build on the kfreebsd-* buildds:
 
 make[3]: Leaving directory 
 `/build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/UniversalDetector'
 gcc -Wl,--whole-archive -fexceptions -fgnu-runtime -o unar unar.o 
 CSCommandLineParser.o CommandLineCommon.o NSStringPrinting.o libXADMaster.a 
 ../UniversalDetector/libUniversalDetector.a -Wl,--no-whole-archive 
 -lgnustep-base -lcrypto -lbz2 -lz -licuuc -lobjc -lstdc++ -lm
 libXADMaster.a(XADPrefixCode.o): In function `NewNode':
 /build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADPrefixCode.m:42:
  undefined reference to `reallocf'
 /build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADPrefixCode.m:42:
  undefined reference to `reallocf'
 /build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADPrefixCode.m:42:
  undefined reference to `reallocf'
 /build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADPrefixCode.m:42:
  undefined reference to `reallocf'
 /build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADPrefixCode.m:42:
  undefined reference to `reallocf'
 libXADMaster.a(XADSkipHandle.o):/build/buildd-theunarchiver_2.7.1-2-kfreebsd-amd64-xipvuN/theunarchiver-2.7.1/XADMaster/XADSkipHandle.m:137:
  more undefined references to `reallocf' follow
 collect2: ld returned 1 exit status

I see this has already been fixed, but in any case I wanted to let be
known that libbsd-dev could (have been|be) used instead.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111008183318.ga22...@gaara.hadrons.org

Bug#644669: freebsd-utils: Consider importing iostat from upstream

[Guillem Jover]

Hi!

On Sat, 2011-10-08 at 01:50:19 +0200, Mats Erik Andersson wrote:
   in order to avoid the conflict with sysstat. However, the
   [...]
  
  Could you explain this conflict in more detail?  Why can't iostat be
  in /usr/bin?

 A priori the package sysstat installs the file /usr/bin/iostat
 at the most natural location for Debian. Observe, however, that FreeBSD
 locates its native executable in /usr/sbin/iostat.

It could as long as the interface is the same (either that or a
wrapper would be needed).

 But on the other hand, the same package builds as [!kfreebsd-any]
 so there is supposedly no instanteous conflict.

Even if they are not installable on the same architecture, I think the
same concerns apply as any Conflicting package. Installing on a different
pathname would not be right either (see #562863).

 The alternative solution, worthy of consideration, would be
 
/usr/bin/iostat.bsd
/usr/share/man/man1/iostat.bsd.1.gz
 
 where the manual page has a new location in relation to FreeBSD,
 which prefers iostat(8). All opposition is welcome!

The man page could also be installed as iostat.1freebsd.gz or similar,
but I don't think iostat.bsd would be a good idea, it would mask the
conflict in a path arch specific way, which adds unportability to the
integration with other packages or sysadmins expectations.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111008190407.gb22...@gaara.hadrons.org

Re: Bug#630203: libpmount: FTBFS: error: field 'export' has incomplete type

[Guillem Jover]

reassign 630203 kfreebsd-kernel-headers
retitle 630203 kfreebsd-kernel-headers: missing type to define 'export' field 
in headers breaks program compilation
affects 630203 libpmount
thanks

Hi!

On Sun, 2011-06-12 at 12:12:21 +0200, Christoph Egger wrote:
 Your package failed to build on the kfreebsd-* buildds:
 
 make[1]: Entering directory 
 `/build/buildd-libpmount_0.0.14-kfreebsd-amd64-CGlbFG/libpmount-0.0.14'
 cc  -Wall -g -O2 -D_REENTRANT -DUSE_LOOP -fPIC -c -o src/kerndep.lo 
 src/kerndep.c
 In file included from src/kfreebsd.c:61:0,
  from src/kerndep.c:4:
 /usr/include/isofs/cd9660/cd9660_mount.h:43:22: error: field 'export' has 
 incomplete type
 make[1]: *** [src/kerndep.lo] Error 1
 
 Full log at:
 https://buildd.debian.org/status/fetch.php?pkg=libpmountarch=kfreebsd-amd64ver=0.0.14stamp=1307130130

This is a problem with the newer kfreebsd-kernel-headers, reassigning.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110929054829.ga7...@gaara.hadrons.org

Bug#609757: libmd in freebsd-libs?

[Guillem Jover]

Hi!

On Sat, 2011-06-18 at 17:03:20 +0200, Robert Millan wrote:
 I noticed libmd has its own directory in SVN.  Is there any
 reason for not merging it in freebsd-libs?
 
 If it's because of Architecture: any setting, note that
 freebsd-libs already includes portable libraries (like
 libsbuf).

Few reasons, one has been because libmd is more generic than something
like libsbuf and it's prone to be used more widely than anything in
freebsd-libs, so it might make sense to promote it to standard or
higher for example. The other reason is that the licenses in the
FreeBSD tree are a bit unfortunate so my plan is to use the OpenBSD
implementation instead.

Just have to commit my latest changes.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110626220251.gb29...@gaara.hadrons.org

Bug#630911: please provide link_ntoa()

[Guillem Jover]

On Sat, 2011-06-18 at 19:10:46 +0200, Robert Millan wrote:
 Package: libbsd-dev
 Version: 0.2.0-1
 Severity: wishlist
 
 Please provide link_ntoa() so that it can be removed from
 [freebsd-utils]/debian/patches/030_arp_libbsd.diff
 
 Implementation from FreeBSD is available in:
 
 http://svnweb.freebsd.org/base/head/lib/libc/net/linkaddr.c?revision=165903view=markup

The problem with link_ntoa() is that it relies on the BSD specific
‘struct sockaddr_dl’ which for example does not match any Linux
sockaddr structure, the closes one is sockaddr_ll, but not quite the
same, also no standard function returns such type, so the code has to
be ported anyway. As such I don't think libbsd is the correct place
for that function.

regards,
guillem



--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110626221621.gc29...@gaara.hadrons.org

Re: Bug#630911: please provide link_ntoa()

[Guillem Jover]

On Mon, 2011-06-27 at 00:27:12 +0200, Robert Millan wrote:
 2011/6/27 Guillem Jover guil...@debian.org:
  The problem with link_ntoa() is that it relies on the BSD specific
  ‘struct sockaddr_dl’ which for example does not match any Linux
  sockaddr structure, the closes one is sockaddr_ll, but not quite the
  same, also no standard function returns such type, so the code has to
  be ported anyway. As such I don't think libbsd is the correct place
  for that function.
 
 Should we reassign to libc0.1-dev then?

We used to have this in libfreebsd, and given the recent discussion
about adding new functions to (e)glibc, I don't really know where we
should put this, but the same answer should apply as for the other
(Free)BSD specific functions.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110626232103.gb30...@gaara.hadrons.org

Bug#630107: [kfreebsd] cannot configure grub-pc (error: cannot find a GRUB drive for /dev/ad0s1)

[Guillem Jover]

Hi!

On Sun, 2011-06-12 at 11:53:51 +0200, Robert Millan wrote:
 2011/6/12 Jonathan Nieder jrnie...@gmail.com:
  A better fix is to wait for Guillem's upload and then schedule a
  binnmu.  Sorry for the noise.
 
 OK

Just in case it has not been noticed, I did this the other day, and
freebsd-libs is sitting in NEW now.

  http://ftp-master.debian.org/new/freebsd-libs_8.2+ds1-1.html

thanks,
guillem



--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011061636.ga9...@gaara.hadrons.org

Bug#630107: [kfreebsd] cannot configure grub-pc (error: cannot find a GRUB drive for /dev/ad0s1)

[Guillem Jover]

Hi!

On Sat, 2011-06-11 at 19:55:17 -0500, Jonathan Nieder wrote:
 Robert Millan wrote:
  I'd check if a GRUB rebuild helps.
 
 It does!  I should never have doubted.
 
 After a rebuild, running grub-probe -t drive / with libgeom from
 unstable produces no output and exits with status 139 (sigsegv).  I
 assume libgeom could benefit from a symbols bump in addition to a
 Breaks against the previous grub-common version.

The problem is an ABI change as can be seen from:

  
http://svnweb.freebsd.org/base/head/lib/libgeom/libgeom.h?r1=182843r2=202454

So the library needs the SOVERSION bumped. I'll do that and use the
opportunity to add libjail too, now that we have to go through NEW.
I'll try to check for other possible ABI changes on the rest of the
libraries.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110612012003.ga6...@gaara.hadrons.org

Re: Testing new getpt(3) and posix_openpt(3) implementation

[Guillem Jover]

On Thu, 2011-06-09 at 11:05:28 +0200, Petr Salinger wrote:
 or run tested the code, so if someone with an eglibc
 build-tree around could test the attached patch (against the
 glibc-ports tree) that would be pretty helpful
 
 With slight modification in progress.

Thanks for the building and testing!

 There are failures in testsuite, at least ptsname.c have to be
 updated too.

Ah right, had a small change for that one, but as there seemed to be
more changed needed there I didn't include it, was not suspecting it
would cause test suite failures. :) Attached now.

Although the line with:

  p[0] = 't';

seems a bit suspicious, but then I've not analyzed the function in
depth.

thanks,
guillem
Index: kfreebsd/ptsname.c
===
--- kfreebsd/ptsname.c	(revision 3434)
+++ kfreebsd/ptsname.c	(working copy)
@@ -26,8 +26,11 @@
 #include unistd.h
 
 
+/* Directory where we can find the slave pty nodes.  */
+#define _PATH_DEVPTS /dev/pts/
+
 /* Static buffer for `ptsname'.  */
-static char buffer[sizeof (_PATH_TTY) + 2];
+static char buffer[sizeof (_PATH_DEVPTS) + 20];
 
 
 /* Return the pathname of the pseudo terminal slave associated with

Re: Testing new getpt(3) and posix_openpt(3) implementation

[Guillem Jover]

On Thu, 2011-06-09 at 11:05:28 +0200, Petr Salinger wrote:
 There are failures in testsuite, at least ptsname.c have to be
 updated too.
 
 Other related functions are:
 grantpt(), ptsname(), unlockpt()

Ok, I guess the obvious answer to this is:

  
http://svnweb.freebsd.org/base/release/8.2.0/lib/libc/stdlib/ptsname.c?view=markup

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110609100315.ga18...@gaara.hadrons.org