Bug#621820: xfce4-netload-plugin: FTBFS on kfreebsd-*: os.h:125:28: error: net/ppp_defs.h: No such file or directory

[Guillem Jover]

block 621820 by 577494
reassign 621820 xfce4-netload-plugin
retitle 621820 xfce4-netload-plugin: Needs to be ported from if_ppp to ppp(8) 
on GNU/kFreeBSD
thanks

Hi!

On Wed, 2011-05-25 at 18:54:33 +0200, Guillem Jover wrote:
> On Mon, 2011-04-25 at 23:45:00 +0200, Yves-Alexis Perez wrote:
> > reassign 621820 kfreebsd-kernel-headers
> > 
> > On lun., 2011-04-25 at 12:28 +0200, Yves-Alexis Perez wrote:
> > > On Linux arches net/ppp_defs.h and net/if_ppp.h are provided by
> > > libc6-dev. On kFreeBSD it's a bit different, the headers are only
> > > provided in (versioned) kfreebsd-headers-* packages, and they are
> > > located in /usr/src/kfreebsd-headers-8.2-1/sys/ 
> > > 
> > > I don't think it's a good idea to build-dep on versioned kernel
> > > headers
> > > nor passing a (versioned) -I to the build, that'd be too much trouble.
> > > 
> > > Any idea how to fix that?
> 
> > After discussing this with Cyril on irc it seems the solution might be
> > to include the relevant header files in kfreebsd-kernel-headers, so
> > reassigning.
> 
> kFreeBSD 8.0+ does not have if_ppp any longer, so this is not
> possible, the fix upstream proposes seems to be to port to ppp(8), as
> seen from the removal commit log:
> 
>   <http://www.mail-archive.com/svn-src-all@freebsd.org/msg07293.html>
> 
>   <http://www.freebsd.org/cgi/man.cgi?query=ppp&sektion=8>
> 
> This bug should be reassigned back I guess.

Done so now, we don't currently have ppp for GNU/kFreeBSD yet but
once xfce4-netload-plugin gets ported to it, that would not disallow
the package from being built any longer.

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/20110731053939.ga15...@gaara.hadrons.org

Re: POSIX_FADV_*

[Guillem Jover]

Hi!

On Sat, 2011-08-13 at 22:17:40 +0200, Christoph Egger wrote:
>   I'm seeing some packages [0] FTBFS because of undefined
> POSIX_FADV_*. Google suggests these may be missing from freebsd
> (still?). Haven't really tried working around that much yet.

Unconditionaly assuming presence of these interfaces is
non-portable. Even POSIX.1-2008 specifies it as non mandatory:

  

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/20110814023259.ga12...@gaara.hadrons.org

Re: Bug#637693: hivex: FTBFS (kfreebsd): error: 'O_CLOEXEC' undeclared (first use in this function)

[Guillem Jover]

Hi!

On Sat, 2011-08-13 at 22:10:03 +0200, Hilko Bengen wrote:
> * Christoph Egger:
> > Your package failed to build on the kfreebsd-* buildds:
> > /bin/bash ../libtool --silent --tag=CC   --mode=compile gcc -std=gnu99 
> > -DHAVE_CONFIG_H -I. -I../../../lib -I..  -I../../../gnulib/lib 
> > -I../../../lib-g -O2 -c -o libhivex_la-hivex.lo `test -f 'hivex.c' || 
> > echo '../../../lib/'`hivex.c
> > ../../../lib/hivex.c: In function 'hivex_open':
> > ../../../lib/hivex.c:296:38: error: 'O_CLOEXEC' undeclared (first use in 
> > this function)
> > ../../../lib/hivex.c:296:38: note: each undeclared identifier is reported 
> > only once for each function it appears in
> > make[5]: *** [libhivex_la-hivex.lo] Error 1
> 
> Looks like a header file is not included -- or some definition is
> missing. I'd expect O_CLOEXEC to be defined if fcntl.h is included which
> is the case. Is there anything else that needs to be defined or
> included?

glibc for GNU/kFreeBSD is missing O_CLOEXEC, this is actually bug
635192, but in any case assuming unconditional presence of O_CLOEXEC
is non-portable, it was just added to POSIX.1-2008, and previous to
that it was specific to GNU/Linux.

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/20110814024215.gb12...@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=libpmount&arch=kfreebsd-amd64&ver=0.0.14&stamp=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

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: Please test zfsutils 9.0~svn226163-1

[Guillem Jover]

Hi!

On Mon, 2011-10-10 at 11:43:22 +0200, Arno Töll wrote:
> On 10.10.2011 07:06, Robert Millan wrote:
> > This wouldn't be accepted in Debian archive.  There's an RFP for this
> > library, but it needs some cleanup in debian/copyright before it can
> > be uploaded IIRC.
> 
> Note we do this already for some libraries embedded in zfsutils, for
> example libavl [1] (not to be confused with the libavl which already
> exists in Debian and is not API compatible).
> 
> > Maybe you can help Guillem with this?
> 
> Guillem, what's the status here? As far as I can see it's a licensing issue.

That's mostly it yes, I've a local tree with code under Beer-Ware,
BSD-2, BSD-3 and PD from OpenBSD, but the interfaces vary a bit, so
I needed to add compatibility code for the different hashing interfaces
on the BSDs. I'll try to finish it this weekend.

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/20111014220516.ga20...@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  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

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

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

[Guillem Jover]

On Sun, 2011-10-16 at 13:44:29 +0200, Robert Millan wrote:
> 2011/10/16 Jonathan Nieder :
> > More importantly, there is the question you raised of whether this
> > should be done in userspace by libc instead.  That would avoid
> > upstream having to wonder, "why should we care what happens when
> > someone using a BSD4.3-style bind() calls our BSD4.4-style kernel"?
> > So it's tempting.

Yes, I think this should be handled in glibc, and the sockaddr_un be
fixed to match what the kernel expects, the compat code would be there
to fix applications built against the bogus sockaddr_un type.

> I guess upstream would appreciate if we get rid of the length limit.
> It sets the maximum path length for sockets to 104 chars, is that so?

I'm not entirely sure what you mean with that. If you mean making
sockaddr_un variable size, well that cannot be done, as it's expected
that sockaddr_storage can hold space for any sockaddr type.

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/20111016120305.ga27...@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 , 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:

  

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

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 , 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#649234: type-handling: Planned removal tracking bug

[Guillem Jover]

Source: type-handling
Version: 0.2.23
Severity: serious

Hi!

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.

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/2019041937.ga18...@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#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:

  


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#653193: Missing patch

[Guillem Jover]

On Sun, 2011-12-25 at 11:56:45 +0100, Robert Millan wrote:
> > +#define __FAVOR_BSD 1
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#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 
> #else
> #  define __FAVOR_BSD 1
> #  include_next 
> #  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]

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:

  
  

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#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-kernel&m=132547276312101&w=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

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=libpmount&arch=kfreebsd-amd64&ver=0.0.15&stamp=1317234188
> https://buildd.debian.org/status/fetch.php?pkg=libpmount&arch=kfreebsd-i386&ver=0.0.15&stamp=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

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  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
>  is clearly intentional.

Sure, the problem here though is that nowhere “struct oexport_args” is
defined. “struct export_args” is defined in /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: 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] 

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#659280: libpmount: FDTBFS(kfreebsd): missing include?

[Guillem Jover]

Hi!

On Thu, 2012-02-09 at 20:02:05 +0100, Christoph Egger wrote:
> Package: src:libpmount
> Version: 0.0.15
> Severity: serious
> Tags: sid wheezy
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
> 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:
> 
> 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 build log at
> https://buildd.debian.org/status/fetch.php?pkg=libpmount&arch=kfreebsd-amd64&ver=0.0.15&stamp=1328346895
> 
> This mi9ght also be a bug in kernel-headers, hopefully someone from
> -bsd@ clarifies

Yes, this was filed before several times (see 630203 and 655865 :),
but ended up being a glibc issue, fixed in latest upload, so I guess
you just need to update the chroot.

But then I tried to build it locally, and now it fails due to missing
MNT_NODEV, which I've fixed and I'm uploading a package 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/20120209204732.ga25...@gaara.hadrons.org

Re: Bug #550611: please use libbsd instead of glib for strlcpy

[Guillem Jover]

Hi!

On Wed, 2012-02-15 at 18:45:53 +0800, Aron Xu wrote:
> As mentioned above, I'm looking forward to the inclusion to base
> system of this package, but in the way to achieve this, libbsd0 is not
> priority:important, what's your opinion?

This is the other way around, once you've proposed to move netcat-openbsd
to important and that's been agreed on, any dependencies should be then
promoted by the ftp-masters. There's no need to promote them prematurely.

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/20120221222602.ga21...@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 
retitle 657772 libbsd-dev: Should not provide 
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 
> thanks
> 
> El 28 de gener de 2012 17:39, Sebastian Harl  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  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

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 , 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#652575: rsyslog: /etc/init.d/rsyslog modifications for GNU/Hurd

[Guillem Jover]

Hi!

On Sun, 2012-02-12 at 14:11:41 +0100, Michael Biebl wrote:
> On 27.01.2012 10:18, Guillem Jover wrote:
> >>  * rsyslog should probably switch to use s-s-d --exec instead (why is
> >>it using --name anyway? that option has always been more unreliable).
> > 
> > Still pending.
> 
> So, I had another look at it. This seems to be a typical case of
> copy&paste. The rsyslog init script is based on the skeleton file from
> /etc/init.d/ which uses --name in stop.
> 
> Guillem, if --name is unreliable as you suggest, it might make sense to
> update the skeleton file accordingly?

--exec should be in general more reliable yes, but the problem with
it is that it will not work for interpreted scripts, and that's where
--name is useful, but then if the script name is too long it will get
truncated, so it might not match correctly (the current minimum
guaranteed to match is <= 15 chars across any kernel s-s-d supports).

> I guess I just use --exec everywhere, as I don't want to add further
> arch specific checks.

Yes, that'd be ideal.

> Could you please check the attached rsyslog init script, if it works
> properly on hurd?

I skimmed over it and it looked good, didn't have time to test it but
I'd say if it works on GNU/Linux and/or GNU/kFreeBSD then anything else
related to s-s-d --exec not working is a bug in s-s-d.

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/20120406160338.ga28...@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#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 :
> > El 20 d’abril de 2012 13:34, Anton Zinoviev  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

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

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: 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: cuse4bsd

[Guillem Jover]

Hi!

On Wed, 2012-09-19 at 14:47:49 -0700, Christoph Egger wrote:
> Also would it be a good idea to keept this in kfreebsd-maintainers
> team svn or something?

Yeah, I think that would be a good idea if you feel like putting it
there. You should have commit access 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/20120927055605.ga31...@gaara.hadrons.org

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  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
 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 ,
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: 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  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 
 #include 
 #include 
+#ifdef  OS_LINUX
 #include 
+#endif
 #include 
 
 #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: 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  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: 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:
> >  christoph: 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041#17 and #682101 
> > could give few hints more about the failures
> >  there are unconditional linuxisms there, and few of those 
> > (/proc/$pid/maps) work on kfreebsd because freebsd's procfs implements it
> >  I see
> >  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: 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 , when using libbsd it's either in 
when using the overlay (pkg-config --cflags libbsd-overlay), or in
.

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 (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 .
> [...]
> >  - 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: 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: 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  (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 ]])
> +

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

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: 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

Re: freebsd-i386 status update

[Guillem Jover]

Hi,

On Mon, Sep 16, 2002 at 10:47:45AM -0400, Nathan Hawkins wrote:
> Missing essential packages:
> bsdutils, e2fsprogs, login, mount, and util-linux.

For util-linux and bsdutils you can try the patch in #153410,
it's for the Hurd, but I think it's generic enough to work on BSDs.

regards,
guillem

Re: freebsd-i386 base packages update

[Guillem Jover]

Hi,

On Fri, Oct 18, 2002 at 11:57:50PM +0200, Robert Millan wrote:
> On Sat, Oct 19, 2002 at 10:40:58PM -0400, Nathan Hawkins wrote:
> >
> > Doesn't build, or otherwise not usable:
> > console-common,console-data,console-tools,console-tools-libs,fdutils,
> > ipchains,iptables,klogd,libcap1,libstdc++2.10-glibc2.2,lilo,makedev,
> > manpages,mbr,modconf,modutils,mount,net-tools,pcmcia-cs,ppp,pppconfig,
> > pppoe,pppoeconf,procps,psmisc,setserial,sysklogd,syslinux,util-linux
>
> util-linux has been ported to GNU, so it probably builds on GNU/FreeBSD
> without problem as it's using glibc. The patch is in bug #153410, but I
> think Guillem Jover has made a newer one, I'm CCing him.

I'm sorry, have been a little busy. I will install a Debian GNU/FreeBSD
this week to test and port it.

LaMont do you want me to talk with upstream directly or want to do it
yourself?  I will send the updated patch to the BTS anyway.

regards,
guillem

Re: util-linux on freebsd-i386

[Guillem Jover]

Hi Nathan,

On Thu, Nov 07, 2002 at 01:48:58AM -0500, Nathan Hawkins wrote:
> I now have a patch for util-linux on freebsd-i386. It is definitely not 
> finished and ready to merge. There are some things that need work still, 
> but I'd like to find out what it needs for netbsd before continuing.

I was going to install a Debian/FreeBSD to adapt my old util-linux port
to the Hurd again, and correct any issues found on the BSDs. It seems
you were faster :>

Ok, as the Hurd needs a considerable amount of changes to the upstream
src, and the upstream releases often (currently on 2.11x), I don't think
such changes will be integrated easily... so I think the right solution
is to speak with upstream directly and do such changes to the last
version. Then, once the package compiles fine on all arches, and a new
debian package is uploaded, send patches against the debian part.

We can work together with this if you want... what dou you think?

regards,
guillem

PS: there are a lot of linux specific programs that are tagged !freebsd in
  your patch, you could invert the logic.

Re: util-linux on freebsd-i386

[Guillem Jover]

[Sorry for the delay]

Hi,

On Wed, Nov 13, 2002 at 12:20:41AM -0500, Nathan Hawkins wrote:
> Guillem Jover wrote:
> >Ok, as the Hurd needs a considerable amount of changes to the upstream
> >src, and the upstream releases often (currently on 2.11x), I don't think
> >such changes will be integrated easily... so I think the right solution
> >is to speak with upstream directly and do such changes to the last
> >version. Then, once the package compiles fine on all arches, and a new
> >debian package is uploaded, send patches against the debian part.
> 
> I don't change the upstream source much. Mostly I just need agetty to 
> use termios, and disable a bunch of things.

Ok, I've adapted my last patch and yours against 2.11x. It's not against
the debian version, because I'll be sending it directly to upstream this
weekend if all is working fine (I "fear" a new upstream release really
soon).

Please give it a try, I think it should compile almost all what can be
compiled under *BSD and Hurd. This include things the BSDs may not need
but if these can be made more portable, maybe in a "near" :> future can
be used... for example cfdisk (look if it's default devices are correct).
Also, as suggested by Robert Millan, mkswap could be renamed to
mkswap.linux on non-linux OSes.

<http://lepton.hn.org/~guillem/patches/util-linux-2.11x_ports.patch.gz>

> >We can work together with this if you want... what dou you think?
> 
> Yes, I'd also like to get netbsd changes included as well.

Sure. The patch is not definitive, please comments and improvments.

> I think netbsd is probably identical to freebsd on this. Are there any 
> differences from what you need on the Hurd?

Not so much, the most important are the limit macros like MAX*, all those
resources should be dynamically allocated as the Hurd has no such hardcoded
limits. Then the normal missing headers, termios, and removing (ifdefing)
linuxisms...

regards,
guillem

Re: A request from the NetBSD folks [ please discuss ]

[Guillem Jover]

Hi Joel,

On Tue, Dec 02, 2003 at 01:50:16PM -0700, Joel Baker wrote:
> I've been contacted by a member of the NetBSD team, who expressed that the
> general opinion seems to be that "Debian GNU/KNetBSD" is a better name for
> the port than "Debian GNU/NetBSD", both because it is more specific about
> what's going on, and because it doesn't dilute the NetBSD trademark. While
> the former is less true of, say, my work, the latter is certainly a valid
> concern.

This summer Robert and I were discussing on the naming convention and
concluded that we would like to use KFreeBSD wherever possible, for
consistrency and to not confuse users or developers, etc. So now we have:

uname -s:   GNU/KFreeBSD
config.guess triplet:   -(pc|unknown)-kfreebsd-gnu
Debian port name:   Debian GNU/KFreeBSD
Debian arch name:   freebsd-

The Debian arch name is not consistent, because the dpkg maintainers
disagreed with the name change, and we didn't want to discuss it
endlessly, we wanted the patches integrated to have a functional system.

My question is, what names were you thinking on changing (if that change
is considered) ?

regards,
guillem

Implemented architecure aliases (Was Re: RFC: patch to split System/Cpu in dpkg)

[Guillem Jover]

Hi,

On Mon, Jan 24, 2005 at 04:50:26AM +0100, Robert Millan wrote:
> Please have a look at this patch I just sent to dpkg maintainers:
> 
>   http://people.debian.org/~rmh/patches/dpkg.diff
> 
> This should address all the concerns porters have had with limitations in dpkg
> architecture handling during the past few years.  I've tested it extensively
> (tried _every_ combination I can concieve), but more testing is welcome of
> course.
> 
> Independently on wether the dpkg maintainer accepts to apply it to 
> experimental
> branch currently, we'll have to send a proposal to ammend Policy.  I'm looking
> for Debian developers to second me on this.  Please let me know if this is the
> case.

I've sent an alternative implementation to solve this problem, that I
think is cleaner, clearer and less intrusive. It's on bugs #291939 and
#268377. The patch is available as well from:

  

The idea is to use architecture aliases that get expanded on package
building so this does not affect and does not need changes in tools
and infrastructure that deal with binary packages.

The general form of the aliases is:

-any
any-

For more details please refer to the bug reports above.

Comments and support for this alternative implementation welcome.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

GNUAB archive gpg key

[Guillem Jover]

Hi,

With the introduction of the new apt-get, I've added support for
signed Release files to mini-dak, the key can be found on:

  

The key is:

  pub   1024D/359AAB34 2005-07-02 [expires: 2006-01-01]
0B3E 7BC4 408E F096 3602  9825 5580 6D41 359A AB34
  uid   Gnuab Archive Automatic Signing Key (2005) <[EMAIL PROTECTED]>

regards,
guillem


signature.asc
Description: Digital signature

Re: Bug#338378: kfreebsd-5: please enable altq support

[Guillem Jover]

On Fri, Nov 11, 2005 at 12:31:07PM +0100, Aurelien Jarno wrote:
> Robert Millan a écrit :
> > On Thu, Nov 10, 2005 at 12:46:25AM +0100, Aurelien Jarno wrote:
> > > Fixed in SVN. I plan to release new kernel image this week-end, I am not
> > > sure though if I'll upload them directly or if I will ask for test first
> > > because there will be a lot of changes in the /boot directory to allow
> > > more than one kernel to be installed at a time.

> > How about `experimental'?

> currently gnuab does not support experimental. Maybe support could be added?

Maybe. =)

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New GNUAB Archive key

[Guillem Jover]

Hi,

The GNUAB Archive key expired some days ago. I've created a new one,
uploaded it to the keyservers, and it's the one that will start to be
used for new signatures.

The key is:

pub   1024D/CD02E583 2006-01-06 [expires: 2007-01-31]
  Key fingerprint = FBA8 1337 C506 565B 8E10  7B00 F621 FF3D CD02 E583
uid   Gnuab Archive Automatic Signing Key (2006) <[EMAIL PROTECTED]>

It can be found as well on:

  

Or attached to this mail.

regards,
guillem
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEO+wpwRBACbVwSB+rTbxG9jZbH4PSZ+++fJxQDVPgSeZG3FP9DmGRp6cMCJ
5USkHtzL1kd34v9dhBsWVQIvdYMR49ORgpcDaY5dAshnOkp4JEBrcq96mN4yb4Y7
ERkex4ergpeN0ujOLK+9mOPkiUQiUW4S6rSfExlphSnbR04SDmncgzbAcwCgpQWt
gZIMA7ceYT6QfjgEzz9Ev7cD/RyPM/rwDXYfb6YXSXdbKem+u0Mleq4vOYOoXOC7
7e0j5WEFrABews5OwoJLioNTWROGvZBh4KzkYDZ5xzayemn+fLUCej10dd8cdJM2
xueDZhkDJ0KcFBHVc5YXJHjKAU582bwxh0jNR2lOWW1yd338QSPLix9sDhjVAvEh
bH1DA/9JwNHe1Z1Pj83TfqZ1223xuHzqAhqb5HTcOJQFPo400rKXsnz01rihSVbb
wuhDq0hCMQRSIE1KXzhjrmZaRLxz1M9SbPYS8IuChIv6PRcfexDnMMyAJ8HG8A44
o0zSGkJAsOtb10bMGwb2PfFYQaALr/TGEU8WHhA7Go7QH5HnYrRAR251YWIgQXJj
aGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIwMDYpIDxmdHBtYXN0ZXJAZ251
YWIub3JnPohkBBMRAgAkBQJDvsKcAhsDBQkCAikABgsJCAcDAgMVAgMDFgIBAh4B
AheAAAoJEPYh/z3NAuWDFKUAoJnbHEVAF4rfrov0RKEaC0Ve38gSAJ47aIT88qBr
hZm4/fkYGViSxQEEgA==
=1eJc
-END PGP PUBLIC KEY BLOCK-


signature.asc
Description: Digital signature

Re: No Mouse in X and kbdcontrol package

[Guillem Jover]

Hi,

On Wed, Jan 18, 2006 at 06:34:16PM -0700, Christopher Desjardins wrote:
> Also, the kbdcontrol package will not install because it depends on keymaps.
> Thanks and so far I'm quite impressed with the port!
> Chris

I've the sources for kbdcontrol around I'll put them in svn, merge
into a single package and upload this week...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1188 - trunk/libbsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:17:19 + (Tue, 14 Feb 2006)
New Revision: 1188

Modified:
   trunk/libbsd/ChangeLog
Log:
Fix ChangeLog format.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-13 20:56:47 UTC (rev 1187)
+++ trunk/libbsd/ChangeLog  2006-02-14 05:17:19 UTC (rev 1188)
@@ -1,26 +1,29 @@
 2006-02-13  Robert Millan  <[EMAIL PROTECTED]>
-   
-   Add bsd_getopt.
-   * bsd_getopt.c: New.
-   * include/bsd/getopt.h: New.
-   * Versions: Add bsd_getopt and optreset.
-   * Makefile: Add bsd_getopt.c and include/bsd/getopt.h.
 
+   * bsd_getopt.c: New file.
+   * include/bsd/getopt.h: Likewise.
+   * Makefile (LIB_SRCS): Add 'bsd_getopt.c'.
+   (LIB_INCLUDES): Add 'include/bsd/getopt.h'.
+   * Versions: Added bsd_getopt and optreset.
+
 2006-02-10  Robert Millan  <[EMAIL PROTECTED]>
-   
-   Add errc, warnc, verrc and vwarnc.
-   * err.c: New.
-   * include/bsd/err.h: New.
-   * Versions: Add them.
-   * Makefile: Add err.c and include/bsd/err.h.
 
+   * err.c: New file.
+   * include/bsd/err.h: Likewise.
+   * Makefile (LIB_SRCS): Add 'err.c'.
+   (LIB_INCLUDES): Add 'include/bsd/err.h'.
+   * Versions: Added errc, warnc, verrc and vwarn.
+
 2005-12-19  Aurelien Jarno <[EMAIL PROTECTED]>
-   
-   * Added manpages
-   * fmtcheck.c: new
-   * include/stdlib.h: added fmtcheck
-   * Versions: added fmtcheck
 
+   * man/arc4random.3: New file.
+   * man/fgetln.3: Likewise.
+   * man/fmtcheck.3: Likewise.
+   * man/strlcpy.3: Likewise.
+   * fmtcheck.c:: Likewise.
+   * include/stdlib.h: Added fmtcheck declaration.
+   * Versions: Added fmtcheck.
+
 2005-11-01  Guillem Jover  <[EMAIL PROTECTED]>
 
* ip_icmp.h: Move to ...
@@ -37,14 +40,14 @@
 
 2005-08-03  Hector Garcia  <[EMAIL PROTECTED]>
 
-   * Makefile: Fixed to place soft links instead in soname and shared_so
-   instead of copying files.
+   * Makefile: Fixed to place soft links instead in soname, and
+   shared_so instead of copying files.
* md5.h (MD5End, MD5File, MD5FileChunk, MD5Data): Commented out
-   functions not available on md5c.c
+   functions not available on 'md5c.c'.
 
 2005-07-26  Guillem Jover  <[EMAIL PROTECTED]>
 
-   * Makefile (LIB_INCLUDES): Add "md5.h".
+   * Makefile (LIB_INCLUDES): Add 'md5.h'.
 
 2005-07-26  Guillem Jover  <[EMAIL PROTECTED]>
 
@@ -53,9 +56,9 @@
 
 2005-07-26  Hector Garcia  <[EMAIL PROTECTED]>
 
-   * Makefile (LIB_SRCS): Add "md5c.c".
-   * md5c.c: Changed include to "md5.h".
-   * md5.h: Replaced with the system header sys/md5.h.
+   * Makefile (LIB_SRCS): Add 'md5c.c'.
+   * md5c.c: Changed include to 'md5.h'.
+   * md5.h: Replaced with the system header 'sys/md5.h'.
 
 2005-07-25  Guillem Jover  <[EMAIL PROTECTED]>
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1189 - trunk/libbsd/debian

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:18:05 + (Tue, 14 Feb 2006)
New Revision: 1189

Modified:
   trunk/libbsd/debian/README.Debian
   trunk/libbsd/debian/copyright
Log:
Do not list all functions in the README.
Beautify copyright file.


Modified: trunk/libbsd/debian/README.Debian
===
--- trunk/libbsd/debian/README.Debian   2006-02-14 05:17:19 UTC (rev 1188)
+++ trunk/libbsd/debian/README.Debian   2006-02-14 05:18:05 UTC (rev 1189)
@@ -1,17 +1,8 @@
 libbsd for Debian
 -
 
-This package is a collection of functions missing from glibc which are
-nedded for the Debian porting to the FreeBSD kernel. So far the functions
-included are:
+This package is a collection of functions and definitions missing from glibc
+which are nedded for the Debian porting to the FreeBSD kernel.
 
-   * arc4random
-   * fgetln
-   * fmtcheck
-   * inet_net_pton
-   * md5c
-   * strlcat
-   * strlcpy
-
  -- Hector Garcia <[EMAIL PROTECTED]>, Sun, 17 Jul 2005 16:17:35 +0200
 

Modified: trunk/libbsd/debian/copyright
===
--- trunk/libbsd/debian/copyright   2006-02-14 05:17:19 UTC (rev 1188)
+++ trunk/libbsd/debian/copyright   2006-02-14 05:18:05 UTC (rev 1189)
@@ -1,10 +1,14 @@
 This package was debianized by hector Garcia <[EMAIL PROTECTED]> on
 Sun, 17 Jul 2005 16:17:35 +0200.
 
-It was downloaded from http://www.freebsd.org/
+It was downloaded from:
 
-Copyright Holder: The FreeBSD project.
+
 
+Copyright Holder:
+
+The FreeBSD project.
+
 License:
 
 Redistribution and use in source and binary forms, with or without


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1190 - trunk/libbsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:22:15 + (Tue, 14 Feb 2006)
New Revision: 1190

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/Versions
Log:
Remove optreset.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 05:18:05 UTC (rev 1189)
+++ trunk/libbsd/ChangeLog  2006-02-14 05:22:15 UTC (rev 1190)
@@ -1,3 +1,7 @@
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
+   * Versions: Remove optreset.
+
 2006-02-13  Robert Millan  <[EMAIL PROTECTED]>
 
* bsd_getopt.c: New file.

Modified: trunk/libbsd/Versions
===
--- trunk/libbsd/Versions   2006-02-14 05:18:05 UTC (rev 1189)
+++ trunk/libbsd/Versions   2006-02-14 05:22:15 UTC (rev 1190)
@@ -1,7 +1,7 @@
 LIBBSD_0.0 {
   global:
 arc4random;
-bsd_getopt; optreset;
+bsd_getopt;
 errc; warnc; verrc; vwarnc;
 fgetln;
 fgetwln;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1191 - trunk/libbsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:26:48 + (Tue, 14 Feb 2006)
New Revision: 1191

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/Makefile
Log:
* Makefile (LIB_SRCS): Line wrap.
(LIB_INCLUDES): List only the files, automatically prefix the dir.
(LIB_MANS): Likewise.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 05:22:15 UTC (rev 1190)
+++ trunk/libbsd/ChangeLog  2006-02-14 05:26:48 UTC (rev 1191)
@@ -1,5 +1,11 @@
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
+   * Makefile (LIB_SRCS): Line wrap.
+   (LIB_INCLUDES): List only the files, automatically prefix the dir.
+   (LIB_MANS): Likewise.
+
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
* Versions: Remove optreset.
 
 2006-02-13  Robert Millan  <[EMAIL PROTECTED]>

Modified: trunk/libbsd/Makefile
===
--- trunk/libbsd/Makefile   2006-02-14 05:22:15 UTC (rev 1190)
+++ trunk/libbsd/Makefile   2006-02-14 05:26:48 UTC (rev 1191)
@@ -4,11 +4,15 @@
 # $Id$
 #
 
-LIB_SRCS = arc4random.c bsd_getopt.c err.c fgetln.c inet_net_pton.c strlcat.c 
strlcpy.c md5c.c fmtcheck.c
+LIB_SRCS = arc4random.c bsd_getopt.c err.c fgetln.c inet_net_pton.c \
+  strlcat.c strlcpy.c md5c.c fmtcheck.c
 
-LIB_INCLUDES = include/bsd/err.h include/bsd/getopt.h include/bsd/ip_icmp.h 
include/bsd/random.h include/bsd/queue.h include/bsd/md5.h include/bsd/string.h 
include/bsd/bsd.h include/bsd/stdlib.h
+LIB_INCLUDES := err.h getopt.h ip_icmp.h random.h queue.h md5.h string.h \
+  bsd.h stdlib.h
+LIB_INCLUDES := $(patsubst %,include/bsd/,$(LIB_INCLUDES))
 
-LIB_MANS = man/arc4random.3 man/strlcpy.3 man/fgetln.3 man/fmtcheck.3
+LIB_MANS := arc4random.3 strlcpy.3 fgetln.3 fmtcheck.3
+LIB_MANS := $(patsubst %,man/,$(LIB_MANS))
 
 LIB_STATIC_OBJS = $(LIB_SRCS:%.c=%.o)
 LIB_SHARED_OBJS = $(LIB_SRCS:%.c=%.lo)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1192 - trunk/libbsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:33:38 + (Tue, 14 Feb 2006)
New Revision: 1192

Modified:
   trunk/libbsd/Makefile
Log:
Add missing %.


Modified: trunk/libbsd/Makefile
===
--- trunk/libbsd/Makefile   2006-02-14 05:26:48 UTC (rev 1191)
+++ trunk/libbsd/Makefile   2006-02-14 05:33:38 UTC (rev 1192)
@@ -8,11 +8,11 @@
   strlcat.c strlcpy.c md5c.c fmtcheck.c
 
 LIB_INCLUDES := err.h getopt.h ip_icmp.h random.h queue.h md5.h string.h \
-  bsd.h stdlib.h
-LIB_INCLUDES := $(patsubst %,include/bsd/,$(LIB_INCLUDES))
+   bsd.h stdlib.h
+LIB_INCLUDES := $(patsubst %,include/bsd/%,$(LIB_INCLUDES))
 
 LIB_MANS := arc4random.3 strlcpy.3 fgetln.3 fmtcheck.3
-LIB_MANS := $(patsubst %,man/,$(LIB_MANS))
+LIB_MANS := $(patsubst %,man/%,$(LIB_MANS))
 
 LIB_STATIC_OBJS = $(LIB_SRCS:%.c=%.o)
 LIB_SHARED_OBJS = $(LIB_SRCS:%.c=%.lo)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1193 - in trunk/libbsd: . src

[Guillem Jover]

Author: guillem
Date: 2006-02-14 05:39:29 + (Tue, 14 Feb 2006)
New Revision: 1193

Added:
   trunk/libbsd/src/
   trunk/libbsd/src/arc4random.c
   trunk/libbsd/src/bsd_getopt.c
   trunk/libbsd/src/err.c
   trunk/libbsd/src/fgetln.c
   trunk/libbsd/src/fmtcheck.c
   trunk/libbsd/src/inet_net_pton.c
   trunk/libbsd/src/md5.copyright
   trunk/libbsd/src/md5c.c
   trunk/libbsd/src/strlcat.c
   trunk/libbsd/src/strlcpy.c
Removed:
   trunk/libbsd/arc4random.c
   trunk/libbsd/bsd_getopt.c
   trunk/libbsd/err.c
   trunk/libbsd/fgetln.c
   trunk/libbsd/fmtcheck.c
   trunk/libbsd/inet_net_pton.c
   trunk/libbsd/md5.copyright
   trunk/libbsd/md5c.c
   trunk/libbsd/strlcat.c
   trunk/libbsd/strlcpy.c
Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/Makefile
Log:
Move sources to src/.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 05:33:38 UTC (rev 1192)
+++ trunk/libbsd/ChangeLog  2006-02-14 05:39:29 UTC (rev 1193)
@@ -1,5 +1,29 @@
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
+   * arc4random.c: Move to ...
+   * src/arc4random.c: ... here.
+   * bsd_getopt.c: Move to ...
+   * src/bsd_getopt.c:: ... here.
+   * err.c: Move to ...
+   * src/err.c:: ... here.
+   * fgetln.c: Move to ...
+   * src/fgetln.c:: ... here.
+   * fmtcheck.c: Move to ...
+   * src/fmtcheck.c:: ... here.
+   * inet_net_pton.c: Move to ...
+   * src/inet_net_pton.c:: ... here.
+   * strlcat.c: Move to ...
+   * src/strlcat.c:: ... here.
+   * strlcpy.c: Move to ...
+   * src/strlcpy.c:: ... here.
+   * md5c.c: Move to ...
+   * src/md5c.c:: ... here.
+   * md5.copyright: Move to ...
+   * src/md5.copyright:: ... here.
+   * Makefile (LIB_SRCS): Automatically prefix the src/ dir.
+
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
* Makefile (LIB_SRCS): Line wrap.
(LIB_INCLUDES): List only the files, automatically prefix the dir.
(LIB_MANS): Likewise.

Modified: trunk/libbsd/Makefile
===
--- trunk/libbsd/Makefile   2006-02-14 05:33:38 UTC (rev 1192)
+++ trunk/libbsd/Makefile   2006-02-14 05:39:29 UTC (rev 1193)
@@ -4,8 +4,9 @@
 # $Id$
 #
 
-LIB_SRCS = arc4random.c bsd_getopt.c err.c fgetln.c inet_net_pton.c \
-  strlcat.c strlcpy.c md5c.c fmtcheck.c
+LIB_SRCS := arc4random.c bsd_getopt.c err.c fgetln.c inet_net_pton.c \
+   strlcat.c strlcpy.c md5c.c fmtcheck.c
+LIB_SRCS := $(patsubst %,src/%,$(LIB_SRCS))
 
 LIB_INCLUDES := err.h getopt.h ip_icmp.h random.h queue.h md5.h string.h \
bsd.h stdlib.h

Deleted: trunk/libbsd/arc4random.c
===
--- trunk/libbsd/arc4random.c   2006-02-14 05:33:38 UTC (rev 1192)
+++ trunk/libbsd/arc4random.c   2006-02-14 05:39:29 UTC (rev 1193)
@@ -1,191 +0,0 @@
-/*
- * Arc4 random number generator for OpenBSD.
- * Copyright 1996 David Mazieres <[EMAIL PROTECTED]>.
- *
- * Modification and redistribution in source and binary forms is
- * permitted provided that due credit is given to the author and the
- * OpenBSD project (for instance by leaving this copyright notice
- * intact).
- */
-
-/*
- * This code is derived from section 17.1 of Applied Cryptography,
- * second edition, which describes a stream cipher allegedly
- * compatible with RSA Labs "RC4" cipher (the actual description of
- * which is a trade secret).  The same algorithm is used as a stream
- * cipher called "arcfour" in Tatu Ylonen's ssh package.
- *
- * Here the stream cipher has been modified always to include the time
- * when initializing the state.  That makes it impossible to
- * regenerate the same random sequence twice, so this can't be used
- * for encryption, but will generate good random numbers.
- *
- * RC4 is a registered trademark of RSA Laboratories.
- */
-
-#include 
-__FBSDID("$FreeBSD: src/lib/libc/gen/arc4random.c,v 1.10 2004/03/24 14:44:57 
green Exp $");
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct arc4_stream {
-   u_int8_t i;
-   u_int8_t j;
-   u_int8_t s[256];
-};
-
-#defineRANDOMDEV   "/dev/urandom"
-#defineTHREAD_LOCK()
-#defineTHREAD_UNLOCK()
-
-static struct arc4_stream rs;
-static int rs_initialized;
-static int rs_stired;
-
-static inline u_int8_t arc4_getbyte(struct arc4_stream *);
-static void arc4_stir(struct arc4_stream *);
-
-static inline void
-arc4_init(struct arc4_stream *as)
-{
-   int n;
-
-   for (n = 0; n < 256; n++)
-   as->s[n] = n;
-   as->i = 0;
-   as->j = 0;
-}
-
-static inline void
-arc4_addrandom(struct arc4_stream *as, u_char *dat, int datlen)
-{
-   int n;
-   u_int8_t si;
-
-   as->i--;
-   for (n = 0; n < 256; n++) {
-   

r1194 - in trunk/libbsd: . include/bsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 06:43:04 + (Tue, 14 Feb 2006)
New Revision: 1194

Added:
   trunk/libbsd/include/bsd/cdefs.h
Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/Makefile
   trunk/libbsd/include/bsd/bsd.h
Log:
Move some macros to cdefs.h.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 05:39:29 UTC (rev 1193)
+++ trunk/libbsd/ChangeLog  2006-02-14 06:43:04 UTC (rev 1194)
@@ -1,5 +1,13 @@
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
+   * include/bsd/bsd.h (setproctitle, __dead2, __unused, __printflike)
+   (__FBSDID): Moved to ...
+   * include/bsd/cdefs.h: ... here.
+   (__unused, __printflike) [__GNUC__]: Use proper __attribute__.
+   * Makefile (LIB_INCLUDES): Add 'cdefs.h'.
+
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
* arc4random.c: Move to ...
* src/arc4random.c: ... here.
* bsd_getopt.c: Move to ...

Modified: trunk/libbsd/Makefile
===
--- trunk/libbsd/Makefile   2006-02-14 05:39:29 UTC (rev 1193)
+++ trunk/libbsd/Makefile   2006-02-14 06:43:04 UTC (rev 1194)
@@ -9,7 +9,7 @@
 LIB_SRCS := $(patsubst %,src/%,$(LIB_SRCS))
 
 LIB_INCLUDES := err.h getopt.h ip_icmp.h random.h queue.h md5.h string.h \
-   bsd.h stdlib.h
+   bsd.h cdefs.h stdlib.h
 LIB_INCLUDES := $(patsubst %,include/bsd/%,$(LIB_INCLUDES))
 
 LIB_MANS := arc4random.3 strlcpy.3 fgetln.3 fmtcheck.3

Modified: trunk/libbsd/include/bsd/bsd.h
===
--- trunk/libbsd/include/bsd/bsd.h  2006-02-14 05:39:29 UTC (rev 1193)
+++ trunk/libbsd/include/bsd/bsd.h  2006-02-14 06:43:04 UTC (rev 1194)
@@ -2,22 +2,10 @@
 #define LIBBSD_H
 
 /*
- * Generic definitions.
- */
-
-#define setproctitle(fmt, args...)
-
-#define __dead2
-#define __unused
-#define __printflike(x,y)
-#define __FBSDID(x)
-
-#include 
-
-/*
  * Include all bsd compat headers.
  */
 
+#include 
 #include 
 #include 
 #include 

Added: trunk/libbsd/include/bsd/cdefs.h
===
--- trunk/libbsd/include/bsd/cdefs.h2006-02-14 05:39:29 UTC (rev 1193)
+++ trunk/libbsd/include/bsd/cdefs.h2006-02-14 06:43:04 UTC (rev 1194)
@@ -0,0 +1,34 @@
+#ifndef LIBBSD_CDEFS_H
+#define LIBBSD_CDEFS_H
+
+#include 
+
+#ifndef setproctitle
+# define setproctitle(fmt, args...)
+#endif
+
+#ifndef __dead2
+# define __dead2
+#endif
+
+#ifndef __unused
+# ifdef __GNUC__
+#  define __unused __attribute__((unused))
+# else
+#  define __unused
+# endif
+#endif
+
+#ifndef __printflike
+# ifdef __GNUC__
+#  define __printflike(x, y) __attribute((format(printf, (x), (y
+# else
+#  define __printflike(x, y)
+# endif
+#endif
+
+#ifndef __FBSDID
+# define __FBSDID(x)
+#endif
+
+#endif


Property changes on: trunk/libbsd/include/bsd/cdefs.h
___
Name: svn:keywords
   + Id Revision


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1195 - in trunk/libbsd: . include/bsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 06:45:41 + (Tue, 14 Feb 2006)
New Revision: 1195

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/include/bsd/bsd.h
Log:
Remove commented out macros.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 06:43:04 UTC (rev 1194)
+++ trunk/libbsd/ChangeLog  2006-02-14 06:45:41 UTC (rev 1195)
@@ -1,5 +1,9 @@
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
+   * include/bsd/bsd.h: Remove commented out macros.
+
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
* include/bsd/bsd.h (setproctitle, __dead2, __unused, __printflike)
(__FBSDID): Moved to ...
* include/bsd/cdefs.h: ... here.

Modified: trunk/libbsd/include/bsd/bsd.h
===
--- trunk/libbsd/include/bsd/bsd.h  2006-02-14 06:43:04 UTC (rev 1194)
+++ trunk/libbsd/include/bsd/bsd.h  2006-02-14 06:45:41 UTC (rev 1195)
@@ -82,18 +82,4 @@
 ((_x << 40) & ((__uint64_t)0xff << 48)) | ((_x << 56)));
 }
 
-/*
- * Directly from FreeBSD stdio.h
- */
-
-//#define__SMOD  0x2000  /* true => fgetln modified _p text */
-//#define__SLBF  0x0001  /* line buffered */
-//#define__SWR   0x0008  /* OK to write */
-//#define__SEOF  0x0020  /* found EOF */
-//#define__SRD   0x0004  /* OK to read */
-//#define__SRW   0x0010  /* open for reading & writing */
-//#define__SERR  0x0040  /* found error */
-//#define__SNBF  0x0002  /* unbuffered */
-//#define__SIGN  0x8000  /* ignore this file in _fwalk */
-
 #endif


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1196 - trunk/libbsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 06:55:53 + (Tue, 14 Feb 2006)
New Revision: 1196

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/Versions
Log:
Revert r1190.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 06:45:41 UTC (rev 1195)
+++ trunk/libbsd/ChangeLog  2006-02-14 06:55:53 UTC (rev 1196)
@@ -40,10 +40,6 @@
(LIB_INCLUDES): List only the files, automatically prefix the dir.
(LIB_MANS): Likewise.
 
-2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
-
-   * Versions: Remove optreset.
-
 2006-02-13  Robert Millan  <[EMAIL PROTECTED]>
 
* bsd_getopt.c: New file.

Modified: trunk/libbsd/Versions
===
--- trunk/libbsd/Versions   2006-02-14 06:45:41 UTC (rev 1195)
+++ trunk/libbsd/Versions   2006-02-14 06:55:53 UTC (rev 1196)
@@ -1,7 +1,7 @@
 LIBBSD_0.0 {
   global:
 arc4random;
-bsd_getopt;
+bsd_getopt; optreset;
 errc; warnc; verrc; vwarnc;
 fgetln;
 fgetwln;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1197 - in trunk/libbsd: . include/bsd

[Guillem Jover]

Author: guillem
Date: 2006-02-14 07:01:21 + (Tue, 14 Feb 2006)
New Revision: 1197

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/include/bsd/getopt.h
   trunk/libbsd/include/bsd/stdlib.h
Log:
Removed unused includes.
Protect header.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-14 06:55:53 UTC (rev 1196)
+++ trunk/libbsd/ChangeLog  2006-02-14 07:01:21 UTC (rev 1197)
@@ -1,5 +1,10 @@
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
+   * include/bsd/stdlib.h: Remove  and .
+   * include/bsd/getopt.h: Protect header from multiple inclusion.
+
+2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
+
* include/bsd/bsd.h: Remove commented out macros.
 
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>

Modified: trunk/libbsd/include/bsd/getopt.h
===
--- trunk/libbsd/include/bsd/getopt.h   2006-02-14 06:55:53 UTC (rev 1196)
+++ trunk/libbsd/include/bsd/getopt.h   2006-02-14 07:01:21 UTC (rev 1197)
@@ -1,4 +1,10 @@
+#ifndef LIBBSD_GETOPT_H
+#define LIBBSD_GETOPT_H
+
 #include 
+
 extern int optreset;
 
 int bsd_getopt (int, char **, char *);
+
+#endif

Modified: trunk/libbsd/include/bsd/stdlib.h
===
--- trunk/libbsd/include/bsd/stdlib.h   2006-02-14 06:55:53 UTC (rev 1196)
+++ trunk/libbsd/include/bsd/stdlib.h   2006-02-14 07:01:21 UTC (rev 1197)
@@ -1,9 +1,6 @@
 #ifndef LIBBSD_STDLIB_H
 #define LIBBSD_STDLIB_H
 
-#include 
-#include 
-
 const char *fmtcheck(const char *, const char *);
 
 #endif


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1207 - in trunk/libbsd: . include/bsd

[Guillem Jover]

Author: guillem
Date: 2006-02-15 20:41:06 + (Wed, 15 Feb 2006)
New Revision: 1207

Modified:
   trunk/libbsd/ChangeLog
   trunk/libbsd/include/bsd/cdefs.h
Log:
Disable __unused, it conflicts with a struct member in a Linux header.


Modified: trunk/libbsd/ChangeLog
===
--- trunk/libbsd/ChangeLog  2006-02-15 18:20:05 UTC (rev 1206)
+++ trunk/libbsd/ChangeLog  2006-02-15 20:41:06 UTC (rev 1207)
@@ -1,3 +1,8 @@
+2006-02-15  Guillem Jover  <[EMAIL PROTECTED]>
+
+   * include/bsd/cdefs.h: Disable __unused, it conflicts with a struct
+   member in a Linux header.
+
 2006-02-14  Guillem Jover  <[EMAIL PROTECTED]>
 
* include/bsd/stdlib.h: Remove  and .

Modified: trunk/libbsd/include/bsd/cdefs.h
===
--- trunk/libbsd/include/bsd/cdefs.h2006-02-15 18:20:05 UTC (rev 1206)
+++ trunk/libbsd/include/bsd/cdefs.h2006-02-15 20:41:06 UTC (rev 1207)
@@ -11,6 +11,9 @@
 # define __dead2
 #endif
 
+/* Linux headers define a struct with a member names __unused.
+ * Disable for now. */
+#if 0
 #ifndef __unused
 # ifdef __GNUC__
 #  define __unused __attribute__((unused))
@@ -18,6 +21,7 @@
 #  define __unused
 # endif
 #endif
+#endif
 
 #ifndef __printflike
 # ifdef __GNUC__


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

r1209 - trunk/libfreebsd

[Guillem Jover]

Author: guillem
Date: 2006-02-15 21:04:09 + (Wed, 15 Feb 2006)
New Revision: 1209

Removed:
   trunk/libfreebsd/libfreebsd-dev.install
Log:
Remove crufty file.


Deleted: trunk/libfreebsd/libfreebsd-dev.install
===
--- trunk/libfreebsd/libfreebsd-dev.install 2006-02-15 21:02:53 UTC (rev 
1208)
+++ trunk/libfreebsd/libfreebsd-dev.install 2006-02-15 21:04:09 UTC (rev 
1209)
@@ -1,4 +0,0 @@
-usr/lib/*.so
-usr/lib/*.a
-usr/include
-usr/share/man


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: glibc on kfreebsd-amd64 (was: Re: segfaults on amd64, one more update)

[Guillem Jover]

On Sun, Feb 26, 2006 at 09:13:37PM +0100, Robert Millan wrote:
> On Sun, Feb 26, 2006 at 07:59:21PM +0100, Petr Salinger wrote:
> > one more update, please could you test 
> > with sysdeps/x86_64/elf/start.S from previous mail
> > and enclosed sysdeps/x86_64/dl-machine.h
> >  
> > iff it works, I will write something better, 
> > but for test this should be sufficient.
> 
> Works!!
> 
> More complex programs like grep work fine, too.  I'm running glibc testsuite
> now, and will run coreutils testsuite within a few minutes.

Nice!

> I might be able to build sane .debs tomorrow.  Guillem, could you enable
> kfreebsd-amd64 in gnuab?

Done.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages in kfreebsd-i386 archive

[Guillem Jover]

Hi,

On Tue, 2006-05-09 at 10:29:10 +0200, Petr Salinger wrote:
> I have some notes about our kfreebsd-i386 archive.
> 
> Currently there is 525 source packages in unreleased,
> but 226 of them are superseded by newer fixed version in unstable.
> Could be possible to delete/obsolete them ?
> 
> In the opposite way, there is also 27 packages in unstable,
> which are superseded by newer version in unreleased.

I'll be applying your patch to mini-dak this weekend, so that we get
this done. Thanks by the way.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: http://www.debian.org/ports/kfreebsd-gnu

[Guillem Jover]

On Sat, 2006-06-17 at 10:57:14 +0200, Dr. Markus Waldeck wrote:
> please correct the link to the mailing list on 
> http://www.debian.org/ports/kfreebsd-gnu.
> 
> There is still http://lists.alioth.debian.org/mailman/listinfo/glibc-bsd-devel
> mentioned!

Thanks, fixed.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kfreebsd future

[Guillem Jover]

On Mon, 2006-09-25 at 20:45:45 +0200, Petr Salinger wrote:
> > For libxul-dev, http://glibc-bsd.alioth.debian.org/patches/nsprpub.diff
> > is a good stard.
> 
> xulrunner.diff is now available on alioth.
> BTW, how is http://glibc-bsd.alioth.debian.org/ synced vith web subdir in 
> subversion ? It is rather outdated now.

It's svn up:ed from my crontab, but the working dir needed a
"svn cleanup", it's now fixed and updated. Thanks for the notice!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kdenetwork, patch need revision or filing?

[Guillem Jover]

On Tue, 2006-11-14 at 14:21:03 +0100, Petr Salinger wrote:
> > Attached is an updated version of the patch for 3.5.5-2. It follows the
> > advice in PORTING [3] about using wildcards like 'linux-any' in
> > build-depends.
> 
> Unfortunately, the support for linux-any is currently only in dpkg :-(
> The "WARNING: please note that this functionality is still not supported 
> by debhelper" is still valid,

debhelper has support for few months now:

debhelper (5.0.36) unstable; urgency=low
[...]
  * Patch from Guillem Jover to make --same-arch handling code support
the new form of architecture wildcarding which allows use of things
like "linux-any" and "any-i386" in the Architecture field. Closes: #371082
[...]
 -- Joey Hess <[EMAIL PROTECTED]>  Fri,  9 Jun 2006 14:57:19 -0400

But sbuild and other tools do not, so it's not going to work for now.
I should get my act together and finish this...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Network trouble

[Guillem Jover]

On Sun, 2006-12-17 at 22:50:49 +0100, Aurelien Jarno wrote:
> It looks like the problem comes from inetutils-tools. It provides the
> package net-tools, but does not have the same capabilities. I think we
> should add a conflict on it.

Hmm it has provided that for a long time but it should not have had,
as it only have an incomplete ifconfig, so I'd just remove the
provides.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: extraneous packages in kfreebsd-i386 archive (was Re: (wishlist) Re: edos.debian.net)

[Guillem Jover]

On Sat, 2007-01-06 at 13:26:38 +0100, Petr Salinger wrote:
> There are many failures due to packages currently arch all,
> which have been formerly any.
> 
> Could be they just deleted from kfreebsd-i386 unstable archive ?
> List with 116 source packages enclosed.
> 
> The similar deletion should be also performed for packages
> already removed from Debian unstable archive.
> Again, list of 100 source packages from kfreebsd-i386 unstable archive 
> enclosed.
> 
> Finally, following source packages should be deleted from
> kfreebsd-i386 unreleased archive due to same reasons:

Done. And thanks for the lists, I should automate most of this
eventually, but I'll need to find a time slot first.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New GNUAB archive signing key (2007)

[Guillem Jover]

Hi,

The GNUAB archive key expired some days ago. I've created a new one,
uploaded it to the keyservers, and it's the one that will start to be
used for new signatures.

The key is:

pub   1024D/19BFB8AB 2007-02-07 [expires: 2008-01-30]
  Key fingerprint = 0C8F 3CAD C3B1 13F9 CA77  51E5 4590 A3D2 19BF B8AB
uid   Gnuab Archive Automatic Signing Key (2007) <[EMAIL PROTECTED]>

It can be found as well on:

  

Or attached to this mail.

regards,
guillem
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEXKXu0RBADvyvRcb7rPDq3FE16yVg+Q1ZS8nBYlAJwuMFgwgcC+g5cGQjuf
2nR2JYWKr3OxTpHx5PqanhON69dlhAseFGO9bZvE4jXKncRbiSFMMcI2bvx4/FA2
p+s66lNI9zehUGb2SnP3yL1wfdVOnfh6k8fxIVAnt2TzJBQiMoxF0G4ouwCgy38A
/jYbw0He5f/pg8sApZ47qYsEAM7JIsuSH8X7+U3fVFzPiyxMjuom7bUDDF/JJL6F
xLDH3HSjijCZM6Dy2bTUF3P1QOQaLLtRsSPxjWQFIhOqOAUuwW9PmrM8KCcfSkWm
w2/LFFtWG4ZHkqBdbBf+i1UAv5AOW8Q1IsqEzh7QP2Gohz1gCOewxcSSw2qav3zB
06E4A/9DZRnmSp70tVtMNGXVgsVSyVvhG+ld6PvIcWYKqZdcj2QS3G4kY9cJRVvk
h5np5G9ZghkZvxuKbK/peXh440j0l21A+KakplrVyhw1lXZYrjyU5WR/M0H/hkAQ
UkQPWdjkgkQi3bW3XpuVcwW68Br+5b9apd9dHKv2Tue8RyrPJLRAR251YWIgQXJj
aGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIwMDcpIDxmdHBtYXN0ZXJAZ251
YWIub3JnPohkBBMRAgAkBQJFyl7tAhsDBQkB1qeABgsJCAcDAgMVAgMDFgIBAh4B
AheAAAoJEEWQo9IZv7irFjMAnReAU33Wk46AnW+GNEGLbguxGbseAKC6Wr3FkFR3
+g0mgVZaOhOfyYH+HQ==
=FIyz
-END PGP PUBLIC KEY BLOCK-


signature.asc
Description: Digital signature

Re: extraneous packages in kfreebsd-i386/kfreebsd-amd64 archives

[Guillem Jover]

Hi,

On Thu, 2007-01-25 at 14:23:03 +0100, Petr Salinger wrote:
> this time I checked both kfreebsd-i386 and kfreebsd-amd64 archives.
> Please, could be again these source packages simply removed
> from kfreebsd archives.
> This would also make results at http://edos.debian.net/edos-debcheck/
> yet more helpfull.

Done a week ago or so.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: snapshot(s) of kfreebsd archive(s)

[Guillem Jover]

Hi,

Sorry for the delay...

On Thu, 2007-01-04 at 13:24:27 +0100, Petr Salinger wrote:
> Please, would be possible to create
> weekly snapshot(s) of kfreebsd archive(s) ?

I've done one for now, and new ones should appear once a week on
thursdays.

They are at , for all
current available arches.

> Given all *.deb files are already in obsolete/,
> the space cost of each such snapshot would be at about 100 MB.

I'll be probably a bit more aggressive in the future removing
obsoleted .deb:s.

> It will be much more usefull compared to now outdated
> http://ftp.gnuab.org/pub/debian-cd/20050910/kfreebsd-i386/iso-cd/

I just removed those.

> Or do ve have enough disk-space somewhere else (alioth ?) ?

There's several GiB free at gnuab, so no problem for now.

> IMHO, the current (especially during freeze before etch) 
> unstable+unreleased is (would be) in a good shape and
> will be very usefull for people who wants to just test kfreebsd.

I might be removing old snapshots at some point thought, after some
discussion here, for example.

> It might also serve as base for real etch based snapshot.

Sure. We could stamp one of those snapshots as a pseudo-release at
some point.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kFreeBSD is "fantastic"

[Guillem Jover]

On Wed, 2007-03-07 at 00:34:44 -0600, Drew Scott Daniels wrote:
> I feel the real concerns for kfreebsd porters are in getting patches
> accepted, and having some additional resources. For now this may be
> accomplished outside the Debian resources, but official recognition might
> make things more easy, both in Debian, and upstream. It may even
> encourage more developers.

  

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#419081: www.debian.org: Terminology issue: GNU/NetBSD

[Guillem Jover]

Hi,

Thanks for taking the time for this!

On Fri, 2007-04-13 at 18:42:45 +0300, Yavor Doganov wrote:
> Package: www.debian.org
> Severity: important
> Tags: patch

> [(X-Debbugs-)CCing the porters' list]
>·
> The Debian GNU/kNetBSD port is referred incorrectly as "GNU/NetBSD".
> I assume this mistake was not intentional and the pages just haven't
> been updated for a while.

No, the port is correctly referred, becuse it's based on the NetBSD libc
and BSD userland. So it's not like in the GNU/k*BSD ports which we
explicitely specify that we are using only the kernel from the *BSD and
not a more complete BSD system.

> By contrast, this is not the case with kfreebsd-gnu -- the GNU/kFreeBSD
> folks have been referring to the system with its proper name (also on
> wiki.d.o).  We (the GNU Webmasters) would be grateful if this issue
> is fixed, so that we can amend the last paragraph of [1] in a similar
> fashion like [2].

> Please consider applying the attached patch.

The GNU/kNetBSD has been in lethargy for some time now, we just
focused our energies in GNU/kFreeBSD, we might come back to it maybe
once GNU/kFreeBSD has been officially merged into Debian as a proper
port, and if there's developer interest. By then I'd agree to add the
new port on the webpages as knetbsd-gnu alongside knetbsd-gnu, or it
might make sense to consider the old port deprecated (with permission
from the GNU/NetBSD porters) and fix the webpages.

> Also, I was wondering why the knetbsd-gnu ports are still called
> netbsd-i386 and netbsd-alpha (i.e. without the "k" prefix)?  Is this
> for historical reasons?  dpkg-architecture lists both variants.

That's also related to it being a different port and having a
different GNU triplet.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian GNU/kFreeBSD description

[Guillem Jover]

On Fri, 2007-05-18 at 16:08:43 -0600, Warren Turkal wrote:
> The description for the Debian GNU/kFreeBSD description at [1] needs to be 
> updated. It currently says that they expect to meet the requirements for 
> release in sarge+1, but clearly GNU/kFreeBSD was not released with Etch.

Where's [1], so that we can fix it?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian GNU/kFreeBSD description

[Guillem Jover]

On Sun, 2007-05-20 at 21:55:35 -0600, Warren Turkal wrote:
> On Sunday 20 May 2007 17:22, Guillem Jover wrote:
> > On Fri, 2007-05-18 at 16:08:43 -0600, Warren Turkal wrote:
> > > The description for the Debian GNU/kFreeBSD description at [1] needs to
> > > be updated. It currently says that they expect to meet the requirements
> > > for release in sarge+1, but clearly GNU/kFreeBSD was not released with
> > > Etch.
> >
> > Where's [1], so that we can fix it?
> 
> [1]http://www.debian.org/ports/

Thanks, done.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#359002: freebsd-sendpr: includes 2 copies of the same executable

[Guillem Jover]

On Sat, 2006-03-25 at 15:03:49 -0500, Justin Pryzby wrote:
> Package: freebsd-sendpr
> Version: 3.113+5.3-6
> Severity: minor
> 
> $ diff `dpkg -L freebsd-sendpr |grep bin/`; echo $?
> 0
> 
> One of the two should probably be a symlink; also, the manpage is
> confusing, in that it only mentions send-pr, and not sendbug.

Those are already hardlinked. I'm going to fix only the man page
issue.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reestructuration of armel and kfreebsd-any repos at GNUAB

[Guillem Jover]

Hi,

The kfreebsd-i386, kfreebsd-amd64 and armel repos at GNUAB now carry
the pure arch:all packages mirrored from the main archive. The
previously needed sources.list deb line hack[0] is not anymore. This
will also make it easier to work on D-I and stop bothering users
about unathenticated packages.

The following should be enough for those architectures:

  deb http://ftp.gnuab.org/debian unstable main
  deb http://ftp.gnuab.org/debian unreleased main

regards,
guillem

[0] «deb http://ftp.debian.org/debian dists/sid/main/binary-i386/»
which can be removed now from your sources.list


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: x264 has patent issues but it's still present in the archive

[Guillem Jover]

Hi,

On Wed, 2007-08-29 at 00:23:11 +0200, Luca Capello wrote:
> =
> [Date: Sun, 13 May 2007 17:07:46 +] [ftpmaster: Joerg Jaspert]
> Removed the following packages from unstable:
> 
> libx264-54 | 0.svn20070309-4 | $ALLARCHS
> libx264-dev | 0.svn20070309-4 | $ALLARCHS
>   x264 | 0.svn20070309-4 | $ALLARCHS
> Closed bugs: 426250
> 
> --- Reason ---
> RM: RoFTPM; patent issues
> --
> =

> I think it should be removed from the kfreebsd- ports as well.

Right, done now. Thanks!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#477587: Bug#477588: kfreebsd-7: bashism in debian/rules

[Guillem Jover]

severity 477587 wishlist
retitle 477587 kfreebsd-6: Please switch debian/rules to SHELL=sh
severity 477588 wishlist
retitle 477588 kfreebsd-7: Please switch debian/rules to SHELL=sh
thanks

Hi,

On Wed, 2008-04-23 at 19:48:55 -0500, Raphael Geissert wrote:
> Source: kfreebsd-7
> Severity: important
> User: [EMAIL PROTECTED]
> Usertags: goal-dash
> 
> While checking for bashisms in debian/rules with checkbashisms (from 
> the 'devscripts' package) I've found your package making use of a bashism.
> 
> checkbashisms' output:
> > possible bashism in kfreebsd-7/debian/rules line 38 (${parm/?/pat[/str]}):
> > flavor=$${config/.config/} ; \
> > possible bashism in kfreebsd-7/debian/rules line 149 (brace expansion):
> > mkdir -p
> > $(IMAGE_PACKAGE)-$*/{boot,lib/modules/$(version)-$(abiname)-$*}

Those are not bugs, the debian/rules file sets the SHELL environment
variable to bash. Downgrading them to wishlist.

regards,
guillem



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [libbsd package] licenc e on NetBSD® files

[Guillem Jover]

Hi,

On Thu, 2008-06-12 at 21:50:37 +, Thorsten Glaser wrote:
> while they still haven’t brought out an official announcement, this seems
> to be better than noting:
> │ http://mail-index.netbsd.org/source-changes/2008/04/30/msg005553.html
> 
> I also had private replies from Martin Husemann and Alistair Crooks, both
> members of the board, confirming this, as well as the already mentioned
> blog entry from Hubert Feyrer.

First of all, thanks for having handled this, much appreciated.

> I sincerely hope libbsd will make it into lenny.

The current status is, I've converted the lib from svn to git, cleaned
it up a bit, asked for a project on freedesktop.org. I just need to do
first some changes for the release, push the git repo and writting
something in the web page.

Will release on fd.o and upload to Debian this weekend, I'll send a
proper announcement then.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#485249: setting package to freebsd-sendpr, tagging 485249

[Guillem Jover]

# Automatically generated email from bts, devscripts version 2.10.30
# via tagpending 
#
# freebsd-sendpr (3.113+5.3-9) UNRELEASED; urgency=low
#
#  * Switch all patches from -p0 to -pab. (Closes: #485249)
#

package freebsd-sendpr
tags 485249 + pending




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#485358: setting package to posixtestsuite, tagging 485358

[Guillem Jover]

# Automatically generated email from bts, devscripts version 2.10.30
# via tagpending 
#
# posixtestsuite (1.5.2-3) UNRELEASED; urgency=low
#
#  * Refresh patches with -pab. (Closes: #485358) 

package posixtestsuite
tags 485358 + pending




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbsd package

[Guillem Jover]

Hi,

On Mon, 2008-07-07 at 13:08:53 +, Thorsten Glaser wrote:
> Dixi:
> 
> >Any progress on the libbsd package, now that licence issues are out
> >of the way? IIRC, plans were to get it ready for all arches in lenny?

It took a bit more time than expected, but it's already there, as
you've already noticed. Replying to this just to explain some of the
decisions. And thanks for the suggestions, code and feedback!

> There are more problems with the libbsd package:
> 
> • debian/copyright is incomplete (only mentions the FreeBSD files)

Yeah, fixed before uploading.

> • src/fgetln.c can never work correctly:
>   │  size_t nread = 0;
>   │  while (nread == 1) {
>   Find attached a working fgetln.c used in MirMake and FreeWRT GNU/Linux

Ditto.

> • some files, like src/fmtcheck.c, can have BSDL clause 3 and 4 removed,
>   see http://www.netbsd.org/changes/#2clause

That was already on the git tree.

> • the MD5 code from RSA DSI can be replaced by a Public Domain implemen-
>   tation, I think I already sent it to… someone here I don’t remember.
>   Attached (replaces md5c.c and md5.copyright)

Ditto.

> • I also attached the version of arc4random.c currently used by the mksh
>   package for Debian, SuSE and Fedora/RHEL, as the FreeBSD version which
>   is currently in libbsd trunk seems to be older

I had already imported a version from FreeBSD with the missing functions
some time ago.

> • I had already suggested including setmode/getmode, e.g. from the mksh
>   source package (attached for convenience)

Didn't remember seeing that previous suggestion, but imported those
from FreeBSD as well before releasing 0.0.

> • In case someone is interested, I have a somewhat optimised strlcat(3)
>   implementation… I'm building it with unifdef, generating 6 source files:
>   ‣ unifdef -DHAVE_STRLCPY=0 -DHAVE_STRLCAT=1 strlfun.c >strlcpy.c
>   ‣ unifdef -DHAVE_STRLCPY=1 -DHAVE_STRLCAT=0 strlfun.c >strlcat.c
>   ‣ unifdef -DSTRXFRM strlfun.c >strxfrm.c
>   ‣ unifdef -DHAVE_WCSLCPY=0 -DHAVE_WCSLCAT=1 wcslfun.c >wcslcpy.c
>   ‣ unifdef -DHAVE_WCSLCPY=1 -DHAVE_WCSLCAT=0 wcslfun.c >wcslcat.c
>   ‣ unifdef -DWCSXFRM wcslfun.c >wcsxfrm.c
>   (of course, the strxfrm/wcsxfrm is only a stub, but okay according to
>   the specs… strcoll becomes strcmp then)

I kept the current version from OpenBSD for simplicity.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbsd package

[Guillem Jover]

Hi Florian,

On Fri, 2008-07-18 at 17:28:30 +0200, Florian Weimer wrote:
> * Thorsten Glaser:
> > Any progress on the libbsd package, now that licence issues are out
> > of the way? IIRC, plans were to get it ready for all arches in lenny?
> 
> We need a thread-safe version of something like arc4random as an element
> for various security patches (which will target etch).  Shall we
> back-port libbsd as a whole, or should we just spin a separate library
> package?

If the stable release team would be fine with introducing a new source
package to stable then I guess the easiest is to just "backport".
I think it most probably should build on etch w/o modifications.

Otherwise from where were you thinking on generating the library
package?

> I'd also see a change that limits the number of bytes which is read from
> /dev/urandom (32 or fewer should be enough).  I'm concerned about
> looping shell scripts darinign entropy from the pool at an unacceptably
> high rate.

I guess that'd be possible, but on what scenario would you see this
happening?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: devname in glibc-bsd

[Guillem Jover]

Hi!

[ Replying on debian-bsd@lists.debian.org, and BCCing glibc-bsd-devel
  as this latter is defunct and mostly no one is subscribed there anymore.
  Please use the former from now on, thanks. ]

On Wed, 2009-04-08 at 11:52:40 +0200, Resul Cetin wrote:
> I have an application which needs to call devname to get the actual name of a 
> device in /dev. It worked perfectly on FreeBSD, but I cannot find the 
> function 
> call on GNU/kFreeBSD port of debian. Is this a known problem or does there 
> exist patches which address such a problem?

This function can be found in the libfreebsd-dev package in
GNU/kFreeBSD, but be advised this is not yet a portable interface, and
your package will not build on other GNU systems. In the future we'll
try to abstract this (and other such functions) and probably move them
to libbsd.

regards,
guillem


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

Re: libbsd

[Guillem Jover]

Hi!

On Thu, 2009-04-02 at 09:25:42 +, Thorsten Glaser wrote:
> jief1.l dixit:
> > but getline store the allocated size in len, not the line length as it
> > should.

I've fixed this now in libbsd, and done a new release. Will be
preparing an updated package for Debian now.

> Your correction is correct, however, I believe I do have a *much*
> shorter, simpler and faster solution handy:
> 
> http://cvs.mirbsd.de/contrib/code/mirmake/dist/contrib/fgetln.c
> 
> The file is also attached to this eMail for convenience.
> I originally wrote it for FreeWRT Embedded GNU/Linux because
> all existing variants, even the GPL’d ones, were buggy.

Your version seems to leak the buffer every time it's getting called.

regards,
guillem


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

Bug#530450: libelfg0-dev and libbsd-dev: error when trying to install together

[Guillem Jover]

reassign 530450 libbsd-dev
thanks

On Mon, 2009-05-25 at 00:34:24 +0200, Ralf Treinen wrote:
> Package: libbsd-dev,libelfg0-dev
> Version: libbsd-dev/0.1.1-1
> Version: libelfg0-dev/0.8.10-2
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> 
> Date: 2009-05-24
> Architecture: amd64
> Distribution: sid

> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
> 
>   usr/include/nlist.h
>   
> 
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package.

It's libbsd's fault, thus taking the bug, will be fixed in next
upload.

regards,
guillem



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

Re: GNU/kFreeBSD packages in the Debian archive

[Guillem Jover]

Hi!

On Mon, 2009-06-08 at 14:21:09 +0200, Aurelien Jarno wrote:
> As a consequence, on GNU/Linux the temporary directory has lost the
> setgid bit, and is still uid=buildd, gid=sbuild. Files are unpacked with
> uid=buildd and gid=buildd, given that the temporary directory has lost
> the setgid bit.
> 
> On GNU/kFreeBSD, the temporary directory has also lost the setgid bit,
> and is also uid=buildd, gid=sbuild. Files are unpacked with uid=buildd
> and gid=sbuild as the gid is determined by the parent directory.
> 
> Some coreutils tests fail if the files are not unpack with gid being the
> primary group of the user. They are skipped if the directory is setgid,
> but the kFreeBSD case is not taken into account.
> 
> I'll temporary change /buildd to gid=buildd on the buildds, but it looks
> like we need a fix at some point. coreutils should probably be fixed,
> but skipping the tests is probably not a good idea either. I wonder if
> we should change dpkg to also force uid and gid of the temporary
> directory while unpacking. I suspect that other packages than coreutils
> might be affected. Guillem, as a dpkg maintainer, do you have an opinion
> on that?

The source should be able to build w/o the Debian packaging from an
upstream PoV anyway. The current coreutils behaviour is not really
deterministic as it depends on the system the source has been unpacked
to, the user that unpacked it (f.ex root preserves tar users by
default), and the file system options (native, mount, setgid, etc).

Given this, I'd say that if coreutils needs a specific owner in files
to be able to do some checks, then it should arrange for itself to set
them before the checks. And that the current undefined dpkg-source
behaviour should be fine as it is. This seems the most portable option
to me.

regards,
guillem


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

Re: Port insserv to kfreebsd?

[Guillem Jover]

Hi!

[ Redirecting to debian-bsd as glibc-bsd-devel is not used anymore,
  and reinclucing the whole initial mail in quotes for context. ]

On Sun, 2009-06-28 at 13:27:50 +0200, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen]
> > Hi.  I notice that the latest insserv package fail to build on
> > kfreebsd, because several posix_fadvise() arguments are unknown.  The
> > code in question is protected with #ifdefs like this:
> >
> >   #if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) >= 600
> > else if ((dfd = dirfd(rcdir)) != 0) {
> > (void)posix_fadvise(dfd, 0, 0, POSIX_FADV_WILLNEED);
> > (void)posix_fadvise(dfd, 0, 0, POSIX_FADV_SEQUENTIAL);
> > }
> >   #endif
> >
> > Why is this test not sufficient on kfreebsd?  Can any of you provide
> > patches to get insserv working on kfreebsd?  I hope to make
> > dependency based boot sequencing a core part of the boot system in
> > Debian and then insserv should work on all archs.
> 
> I made this patch based on the changes done to startpar in sysvinit,
> but fail to understand why this is needed.  Can anyone confirm that
> this work on kfreebsd?
> 
> --- insserv-1.12.0.orig/insserv.c
> +++ insserv-1.12.0/insserv.c
> @@ -40,6 +40,13 @@
>  #endif /* USE_RPMLIB */
>  #include "listing.h"
> 
> +#if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) >= 600
> +/* kfreebsd fail to provide working posix_fadvise
> +#  ifndef POSIX_FADV_SEQUENTIAL
> +#define posix_fadvise(fd, off, len, adv)(-1)
> +#  endif
> +#endif
> +
>  #ifdef SUSE
>  # define DEFAULT_START_LVL "3 5"
>  # define DEFAULT_STOP_LVL  "3 5"

posix_fadvise is optional per POSIX, so checking that that builds if
you use autoconf or for the macro is better. You should also probably
return ENOSYS instead.

regards,
guillem


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

Re: Port insserv to kfreebsd?

[Guillem Jover]

Hi!

On Mon, 2009-06-29 at 09:01:11 +0200, Petr Salinger wrote:
> Somewhen Guillem Jover wrote:
> > You should also probably return ENOSYS instead.
> 
> Well, to be 100% correct, errno should be set to ENOSYS and return -1.
> The eventually implemented posix_fadvise() could only provide hint
> to the kernel memory and io management.
> The result of posix_fadvise() is not checked anyway.

The function returns the error value, see the man page, or the stub in
glibc (io/posix_fadvise.c).

> The proper upstream way should be to guard all usage
> of posix_fadvise() by something like
> "#if USE_FADVISE" instead of current
> "#if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) >= 600"
> 
> and either check by autoconf for presence of function and macros
> or put at the begin of insserv.c light variant like
> 
> #if defined(POSIX_FADV_SEQUENTIAL)
> #define USE_FADVISE 1
> #endif

Sure on the feature check instead of system check, but to me having to
guard all instances of the call instead of doing it once, just seems
ugly, but then the one deciding is going to be Petter. :)

regards,
guillem


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

Re: Processed: libedit2: reassign 535519 358164 libbsd0

[Guillem Jover]

merge 358164 535519
reassign 358164 libedit2
close 358164 2.11-20080614-1
thanks

On Wed, 2009-07-08 at 07:03:04 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > reassign 535519 libbsd0
> Bug#535519: libedit2: huge memory leak in fgetln emulation
> Bug reassigned from package `libedit2' to `libbsd0'.
> > reassign 358164 libbsd0
> Bug#358164: libedit2: adding \n incrementally with read/write history
> Bug reassigned from package `libedit2' to `libbsd0'.

This bug got fixed when you switched to use libbsd, which has a working
implementation of fgetln.

Yuriy, when testing if a bug applies, please always do so against
latest sid version, which in this case was 2.11-20080614-1, from
2009-06-22. Thanks for the investigation and patch anyway!

regards,
guillem


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

Bug#274747: dependency on dpkg-dev is not required for provides

[Guillem Jover]

Hi!

On Mon, 2009-10-12 at 10:54:07 +0200, Aurelien Jarno wrote:
> On Sat, Oct 10, 2009 at 08:43:16PM -0700, Josh Triplett wrote:
> > Package: type-handling
> > Version: 0.2.23
> > Severity: normal
> > 
> > This issue has just become somewhat more commonplace:
> > gnome-desktop-environment now uses type-handling, depending on
> > "gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
> > Note that gnome-desktop-environment, as a metapackage, uses
> > "Architecture: all".  This seems like a very useful application of
> > type-handling.
> > 
> > Please, consider splitting the provides into a separate package which
> > does not depend on dpkg-dev.
>
> type-handling has always been a hack to workaround missing features of
> dpkg-dev, and it should disappear asap.
> 
> dpkg has already support for architecture aliases for a few years, as
> far as I remember it can't be used due to missing support on the
> build daemons.
>
> Could the dpkg team (Cc:ed) can give us a more detailed status of this
> feature, so that we can push it for Squeeze?

That only works for arch:any packages, here the problem is related to
an arch:all package. The wildcards on arch:any packages should be
mostly usable, last time I checked it was pending for all buildd to
be switched to the new sbuild (which has such support).

Adding wildcard support to arch:all packages would imply a wait time
of one release before being usable, as the syntax of the dependncy
fields would change.

Another possibility is to switch the package to an arch:any one. It's
a metapackages anyway so it does not take much space on the servers. And
actually an argument could be made that an arch:all package which
requires different dependencies on different architectures is not a
trully arch:all package.

regards,
guillem



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

Re: devd now running on my box

[Guillem Jover]

Hi!

On Wed, 2009-12-16 at 15:21:59 +0100, Werner Koch wrote:
> I worked on devd and now I am able run the rc.suspend and rc.resume
> scripts on my X31.  To make that really useful I also ported acpiconf.

Ah great!

> I added new functions pidfile_* to libbsd and would like to know how
> to proceed: Create a Debian patch or talk to upstream and get it into
> their repo first?

I was in the process to release a new upstream release for libbsd, and
can include those functions. I'll then proceed with an upload to
Debian.

regards,
guillem


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

Re: How to find number of processors?

[Guillem Jover]

Hi!

On Sat, 2010-01-09 at 21:28:33 +0100, Robert Millan wrote:
> On Sat, Jan 09, 2010 at 02:08:07PM -0600, Steve M. Robbins wrote:
> > The code in question is:
> > 
> > unsigned thread::hardware_concurrency()
> > {
> > #if defined(PTW32_VERSION) || defined(__hpux)
> > return pthread_num_processors_np();
> > #elif defined(_GNU_SOURCE)
> > return get_nprocs();
> 
> It seems that get_nprocs() is always implemented by Glibc.  Worst-case it'd
> be a dummy stub.  I'd just try to figure out why  is not
> included or not providing its declaration.

In addition to what everyone has said, _GNU_SOURCE seems the wrong check
to me, that's a user definition to request the system to expose GNU
extensions, if the code is trying to check for a glibc implementation
it should be using __GLIBC__ instead, or I guess better yet, it should
be checking for the functions availability at build time and use the
best one found.

regards,
guillem


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

Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)

[Guillem Jover]

Hi!

On Wed, 2009-12-30 at 19:46:36 +0100, Thomas Schmitt wrote:
> None of the optional libraries and system
> features is used in the buildd compile runs:
> - libacl
> - support for Extended Attributes
> - zlib
> 
> At least on Linux this astonishes me. I'll have
> to ask George for exploring the reason.
> 
> Nevertheless, the aspects of ACL and xattr are
> also porting issues.

This is a general packaging bug, there's missing Build-Depends on
the development packages for those libraries.

regards,
guillem


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

Re: [patch] pidfile_open (was: devd now running on my box)

[Guillem Jover]

Hi!

On Wed, 2009-12-16 at 17:59:23 +0100, Werner Koch wrote:
> On Wed, 16 Dec 2009 16:09:19 +0100, Guillem Jover wrote:
> > I was in the process to release a new upstream release for libbsd, and
> > can include those functions. I'll then proceed with an upload to
> > Debian.
> 
> Find below a patch against the debian source. 
> 
>   * debian/control (Description): Update.
>   * Makefile (LIB_SRCS): Add pidfile.c
>   * Versions (LIBBSD_0.2): New.
>   * include/libutil.h (struct pidfh): New.
>   (pidfile_open, pidfile_write, pidfile_close, pidfile_remove): New.
>   * src/pidfile.c: New.  Taken from
>   http://svn.freebsd.org/base/head/lib/libutil, rev 200601.
>   (flopen): Merge using flopen.c from the same repo.
> 
> I am not sure how you handle the versioning.  I added the new
> functions under a new symbol versioning branch; it seems that is the
> policy for libbsd.
> 
> I did not include flopen.c because it is not needed and may conflict
> with other code which uses the same symbol.

Sorry for the delay, and thanks for the patch, although at the end it
seemed easier to pull directly from FreeBSD as it didn't apply anyway
and had to fix some stuff. The new version node was already started in
the git tree. I also opted to just include flopen.c as a separate
module. And had to modify pidfile.c to not use EDOOFUS which is not
present on non-GNU/kFreeBSD, and to allocate pf_path dynamically instead
of using MAXPATHLEN which is not defined on GNU/Hurd, after this there
was no need for the conditional declarations depending on inclusion of
.

I've already uploaded the new version to Debian.

thanks
guillem


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