Hi,
I made a little experiment to simplify ufsutils and make it easier to
update. By merging ufsutils into freebsd-utils package and using its
build environment, with recent freebsd-glue (0.1.4) it is now possible
to build ufsutils directly from pristine upstream source:
I do not mind
To run a dynamically-linked mksh, ld needs to be found at
/compat/linux/lib/ld-linux.so.2. Maybe it is possible to create a full
set of (sym)links inside /compat/linux/ to suit the paths used by multiarch?
Sounds ugly. We already have proper, non-colliding locations for i386
amd64
IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1]
still should be aplied by perl upstream. While it might not be
problem for this testcase, the unlocking in forked child is fragile.
Hi,
I finally (!) got round to submitting this upstream, at [1], and the
comment so far is that
Hi,
I am active with the following architectures and I intend
to continue this for the lifetime of the Jessie release:
For kfreebsd-*, I
- test a lot of packages on kfreebsd-amd64
- fix (e)glibc issues
- investigate arch-specific bugs
- submit fixes of arch-related bugs into BTS
On 09/09/13 09:10, Petr Salinger wrote:
Sounds ugly. We already have proper, non-colliding locations for i386
amd64 ld-linux.so under /lib/$(DEB_HOST_MULTIARCH)/ it should be
possible to use those. I don't want to re-create multiarch libraries
in /compat/, instead a Debian system should
Bruno Melo:
well, i think it's time to bring kfreebsd 10 r254885 to test radeonkms, or
not?
Sure why not. Thanks for the reminder.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: libc6
Version: 2.17-92
Severity: wishlist
Dear Maintainer,
kfreebsd-i386 kfreebsd-amd64 have linux emulatrion layer that can
emulate 2.6.16 linux API level. Which is also the minimum kernel version
that glibc2.17 2.18 require. At configure time though, the minimal
kernel version is set
freebsd-glue_0.1.5_kfreebsd-amd64.changes uploaded successfully to localhost
along with the files:
freebsd-glue_0.1.5.dsc
freebsd-glue_0.1.5.tar.gz
freebsd-glue_0.1.5_kfreebsd-amd64.deb
Greetings,
Your Debian queue daemon (running on host franck.debian.org)
--
To UNSUBSCRIBE,
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 09 Sep 2013 15:06:42 +0200
Source: freebsd-glue
Binary: freebsd-glue
Architecture: source kfreebsd-amd64
Version: 0.1.5
Distribution: unstable
Urgency: low
Maintainer: GNU/kFreeBSD Maintainers
On Mon, Sep 09, 2013 at 10:14:53AM +0200, Petr Salinger wrote:
IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1]
still should be aplied by perl upstream. While it might not be
problem for this testcase, the unlocking in forked child is fragile.
Hi,
I finally (!) got round
kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes uploaded successfully to
localhost
along with the files:
kfreebsd-10_10.0~svn255412-1.dsc
kfreebsd-10_10.0~svn255412.orig.tar.xz
kfreebsd-10_10.0~svn255412-1.debian.tar.gz
kfreebsd-source-10.0_10.0~svn255412-1_all.deb
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 09 Sep 2013 14:18:49 +0200
Source: kfreebsd-10
Binary: kfreebsd-source-10.0 kfreebsd-headers-10.0-0
kfreebsd-image-10.0-0-686-smp kfreebsd-image-10-686-smp
kfreebsd-headers-10.0-0-686-smp
Christoph Egger:
../../../dev/aic7xxx/aicasm/aicasm.c:759:2: warning: implicit declaration of
function 'TAILQ_INSERT_TAIL' is invalid in C99
[-Wimplicit-function-declaration]
TAILQ_INSERT_TAIL(cs_tailq, new_cs, links);
^
fatal error: too many errors emitted, stopping now
Debian FTP Masters:
kfreebsd-10 (10.0~svn255412-1) experimental; urgency=low
.
* New upstream snapshot.
- 920_linux_cflags.diff: Set __FreeBSD__=10 in order to fix stddef.h
buildability.
- Switch to clang (at least until/unless GCC wmmintrin.h becomes
buildable).
Therefore I can use gcc to compile my programs normally and use the
kernel with no problems, i agree.
I agree that build it with gcc for a project called GNU/kFreeBSD is more
acceptable but if it's impossible, don't lose time to build with
clang ;)
--
To UNSUBSCRIBE, email to
15 matches
Mail list logo