Hi,
what is currently used kernel on buildd for kfreebsd-* ?
According to last log of util-linux (22 May 2015/fayrfax.debian.org):
Kernel: GNU/kFreeBSD 9.0-2-amd64 kfreebsd-amd64 (x86_64)
Please beware, that F_DUPFD_CLOEXEC is not supported on this kernel.
The addition of F_DUPFD_CLOEXEC
Hi.
I uploaded a new version of gimagereader yesterday and it FTBFS[1] on kfreebsd
as sys/prctl.h is missing. The function prctl() is used here[2]. Can you give me
some hints how to fix this? Searching on the internet brought some insight but
didn't help me to propose a patch for upstream.
Hi.
[ ] trying to support it like a stable release alongside Debian jessie
See also announce for unofficial (linux-)amd64 sarge release.
https://lists.debian.org/debian-devel-announce/2005/06/msg5.html
The benefit might be to have security support for non altered packages, etc.
I
Jonathan Wiltshire wrote:
We discussed kfreebsd at length, but are not satisfied that a
release with Jessie will be of sufficient quality. We are dropping
it as an official release architecture,
:-(
I think we could support the kfreebsd core packages for an unofficial
stable release, but
I think I agree rushing in a kernel update might not be the best thing
and giving it full 10+ days of testing in unstable is a good idea
Please do upload into unstable now,
but no need to hurry with pushing into testing.
It might be better to wait for final 10.1 and ask release team in one
- Petr rewrote our threads implementation in GNU libc
Wasn't that in wheezy already? at least all the ruby hangs are gone in
wheezy (and gone completely since squeeze EOL on the buildds)
Petr first shared NPTL threads here, which was after wheezy release:
This has been added due to real need of RC-1 snapshot.
freebsd-utils in SVN trunk did not point at the new RC1 snapshot yet,
it still had version ~svn271687 and debian/rules still referred to
upstream SVN stable/10/
The changes did not have changelog entries. Did you forget to commit
some
Hi.
How did you strip the revision tag here?
- * $FreeBSD: stable/10/sys/sys/queue.h 251887 2013-06-18 02:57:56Z lstewart $
+ * $FreeBSD$
Currently if I get-orig-source then the patches don't cleanly apply.
Refreshing them would only change it to $FreeBSD: releng/10.1/... etc.
Did you
Did you shorten it to $FreeBSD$ by hand?
It might be nice to do this automatically in the get-orig-source step.
After some testing:
The keywords are not expanded for old svn:
$ svn --version
svn, version 1.6.17 (r1128011)
compiled Jun 7 2013, 08:51:48
$ svn export
BTW, many thanks for your time spent on 10.1 preparing.
Speaking of which .. can we go to usntable there?
IMHO, we should wait before beta2 d-i is officially released and announced.
Otherwise, I do not see any other blockers for kernel upload into sid.
For kfreebsd-kernel-headers, I would
-@@ -6,8 +6,7 @@
+@@ -6,8 +6,7 @@ SRCS= camlib.c scsi_cmdparse.c scsi_all
This is mostly not useful to have in the patches. And reviewing the
diff-of-diffs to see what changed is made more difficult by this.
Do you know how to turn that off? I don't seem to get that, with
quilt
(I didn't figure out yet how to rebuild the control file, to get these
installed into a .deb, and I have no clue how to test it either.)
I believe that fakeroot debian/rules control before build is sufficient.
No 'undefined reference' errors in the build log. Both regular and -m32
multilib
On 12/09/14 21:44, Petr Salinger wrote:
It seems that simple drop of kfreebsd-gnu from libphobos_no_systems does
not suffice.
In the build logs are messages like
/build/manual/gcc-4.9-4.9.1/build/x86_64-kfreebsd-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/rt/dmain2.d:419
Am 12.09.2014 um 15:13 schrieb Thibaut Paumard:
While it's your prerogative to decrease the severity, please note that
this bug means that all the packages that build-depend on gdc (22
packages in jessie) are currently in an FTBFS-state on kfreebsd.
sure, and they still will ftbfs without
Package: libc0.1
Version: 2.13-38+deb7u2
X-Debbugs-CC: jtaylor.deb...@googlemail.com , debian-bsd@lists.debian.org
On Sat, 6 Sep 2014, Julian Taylor wrote:
I encountered a weird issue on kfreebsd i386 using pthreads. It seems to
change the x87 fpu precision mode (bits 8 and 9 of the control
Question to the porters: should we build ncurses with sysmouse support?
If it actually works that seems useful, but the GNU/kFreeBSD FAQ is
currently silent on mouse topics.
So far we do not support moused,
and therefore sysmouse interface will not work [1].
Please disable this support
Since upstream plans making a new release this weekend I wanted to
speed up fixing all the FTBFS-s by asking for help.
The fix have to be different one - sockaddr6_in - sockaddr_in6:
--- lib/socket.c~
+++ lib/socket.c
@@ -506,7 +506,7 @@
((struct
Thanks. I've checked that xserver-xorg-video-nv (non-free, meant for
kfreebsd systems) still builds OK with xorg-video-abi-18,
xserver-xorg-core (= 2:1.15.99.903).
I don't have hardware available to test it with unfortunately.
I can confirm that xserver-xorg-video-nv works under
Package: transmission
Your package failed to build on kfreebsd:
In fact, the problem is sligthly different.
The transmission package does not support newly supplied
libminiupnpc-dev under both Linux and kFreeBSD:
checking supported miniupnp library... none
As a result, it tries to use
Nearer the time, if we still only have a BETA or RC in sid and serious
bugs, we may decide to just stay with 10.0. If a BETA or RC is
*already* in testing, we may want to ask the release time about getting
a pre-approved unblock when the final release comes.
I am afraid, that we have to decide
Hi,
the FreeBSD 10.1 Release schedule have been announced [1], key dates:
Code freeze begins 5 September 2014
releng/10.1 branch 3 October 2014
RELEASE announcement29 October 2014
Compare to Debian Jessie freeze schedule [2]:
5th of Sep - close down for transitions
5th of Oct -
I'm not sure if the file should be built on kfreebsd/hurd, or if it shouldn't
but there should be some fallback code in python3.4. Adding the python
maintainer, and the bsd and hurd porters to Cc.
checking on falla, the failing autoconf test is
#include unistd.h
#include fcntl.h
#include
Maye I misunderstood something but i think there's a reason the
memory is mlocked; to avoid leaking sensitive information into swap.
As far as I know, there is no gurantee, that mlocked memory
will not go into swap when whole PC is suspended, even under Linux.
man mlock (from Linux
Hi.
Did you manage to figure something additional out? Do we know if this
also kills plain freebsd?
I'm afraid I'm stuck with this.
I narrowed it down to that particular test (or prerequisites of the
test) when executed by the GCC testsuite. A large chroot is needed,
having all the GCC
Do you have any news on this bug? It is severely affecting *all* GCC
versions and prevents new versions of them from migrating to testing.
I tested it:
system up-to-date jessie, with kfreebsd-image-10.0-1-amd64/10.0-4
chroot up-to-date sid, building of gcc-4.6 4.6.4-6 rebooted the system.
It
1. stay with sysvinit
2. switch to OpenRC unconditionally
3. switch to Upstart unconditionally
4. switch to Upstart only if Linux uses it by default, otherwise OpenRC
5. further discussion
Please rank the above putting your preferred option first, as per
Debian's usual Condorcet voting system.
We have plenty of time, but we don't have plenty of manpower. I'd just
like to know where everyone stands wrt using FreeBSD 10.0 (as opposed to
just shipping its kernel as an alternate option) for Jessie.
If we're going to use 10.0, then I'd upload kfreebsd-kernel-headers 10.0
to experimental
gnutls28 3.2.6-1/experimental FTBFS on kfreebsd-*. This is
unpreducible on falla, any ideas?
It also failed on mips, in the same test - mini-handshake-timeout.c
It receives SIGPIPE during
gnutls_bye(session, GNUTLS_SHUT_RDWR);
There is a race window, which can be enlarged as shown bellow.
ulimit -S of stack size:
linux-i386: 8 MB
linux-amd64:8 MB
kfreebsd-i386: 8 MB
kfreebsd-amd64: 8 MB
ulimit -H of stack size:
linux-i386: unlimited
linux-amd64:unlimited
kfreebsd-i386: 64 MB
kfreebsd-amd64: 512 MB
***
From {nptl/fbtl}/nptl-init.c
it appears as if kFreeBSD is not able to set owners
of file descriptors. My kernel is 9.0-2-amd64 and
libc is 2.13-38, from the Wheezy release.
Many thanks for test case.
There is a typo in our bits/fcntl.h header
#if defined __USE_BSD || defined __USE_UNIX98
# define F_SETOWN 5
I found this is caused by 'make' raising RLIMIT_STACK from the default
setting of 8192k to its maximum, 65536k. It is reproducible from the
shell by setting ulimit -s 65536 before running the test program directly.
Thanks for the analysis!
I don't know if this is an eglibc bug or expected
Control: tags -1 +patch
debian-bsd,
Can you provide any assistance?
Please alter in debian/control
libusb-1.0-0-dev [linux-any], libusb-dev [!linux-any],
into
libusb-1.0-0-dev [linux-any], libusb2-dev [kfreebsd-any],
libusb-dev [!linux-any !kfreebsd-any],
Petr
--
To UNSUBSCRIBE,
Hi again,
the openpty internally uses fork() and wait().
And there is a problem with earlier signal(SIGCHLD, SIG_IGN),
as wait returns ECHILD. Please, could you alter source by:
--- src/hv.c~ 2013-10-07 15:11:54.0 +0200
+++ src/hv.c2013-10-07 15:35:36.0 +0200
@@ -156,15
I think you can avoid this by using the primitive:
lwpid_t tid;
syscall (SYS_thr_self, tid);
There is a mess in kernel interfaces,
the right one is
long tid;
syscall (SYS_thr_self, tid);
But it holds only for current pthread implementation,
it can be changed anytime.
Petr
--
To
Would be possible to switch openpty() to posix_openpt() ?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_openpt.html
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
your package needs to be rebuilt against xorg-server 1.14. That
most likely means pulling in a couple changes from upstream git HEAD.
It suffices to put attached file into debian/patches/
and enlist it in debian/patches/series.
Please, could some DD (Robert, please) do the upload.
Ideally for
I presume that using -O2 shouldn't be an issue with kfreebsd-10 now that
it is using clang (thinking about #718250 et al).
Is there any concern about doing this?
Some advice would be appreciated (specially from Petr)
Just give it a try and plug/unplug USB keyboard ;-)
I expect it will work, as
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
- co-maintain arch-related packages under the hat of the GNU/kFreeBSD
Maintainers
- read debian-bsd@l.d.o
I am not a DD/DM.
Cheers
Petr Salinger
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
Indeed this is the case. My question -- why the unusually low limit?
I do not know, that is the FreeBSD default.
I suspect it is because of the default .text, .data, and shared library
loading addresses. One can use a linker script to place .text and .data
above the shared libraries, in
Does the kernel hardwire the max brk according to the default layout,
independently of .text address? Is this runtime configurable? Is there
a workaround?
I think that it is due to ulimit setting.
Look at data seg size in ulimit -a -H.
Petr
--
To UNSUBSCRIBE, email to
Is there any point in keeping kfreebsd-8 in sid?
Just wondering if it's worth the extra work.
I am in favour of removal from sid.
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Sure. Will do both things. Thanks for the insight.
Iff you have some spare time, please look at kfreebsd-kernel-headers,
they still B-D on kfreebsd-source-9.1.
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi,
the current freebsd-manpages are severely outdated.
The last upload is more than 2 years ago.
The packaging have not been in glibc-bsd SVN repository.
I added it from last upload. The update to 8.4 is trivial.
But the upstream seems to no longer provide manpages directly
in 9.x series. The
The packaging have not been in glibc-bsd SVN repository.
I added it from last upload. The update to 8.4 is trivial.
I don't have a plan for the migration or updates. Please go ahead with your
plan, sounds good to me...
So, please could some DD do the upload ?
It is the easiest one from
The packaging have not been in glibc-bsd SVN repository.
I added it from last upload. The update to 8.4 is trivial.
I don't have a plan for the migration or updates. Please go ahead with your
plan, sounds good to me...
So, please could some DD do the upload ?
Sure. How do I build it?
But the upstream seems to no longer provide manpages directly
in 9.x series. The get-orig-source have to be rewritten.
I am not sure I understand what no longer provide manpages directly in
9.x series means. Perhaps I should just go read get-orig-source, though.
It just means that previous
Is there any reason we don't get these from SVN like most other things?
$ svn export http://svn.freebsd.org/base/releng/$(VER)/share/man/
And from other locations like libc/i386/sys/, libc/sys/, ...
Simply get-orig-source have to be rewritten.
Please note that so far solely uploader
(since
Seems similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696514
Yes I thought so at first, but this feature seems to be working on 8.3
and 9.0 kernels so it is likely a kernel ABI change instead.
But it suffices to add #include netinet/ether.h
and segfault of ifconfig is gone.
Petr
I performed yet another USB plug test, this time on 9.2 kernel.
gcc-4.8 -O2 compiled kernel (aka 9.2~svn253470-1 in experimental)
crashes too.
gcc-4.8 -O1 compiled kernel survives.
I will update SVN for 9.2 and 10 kernels to use gcc-4.8 -O1.
IMO, the 9.1 should stay at gcc-4.6 -O1, as it is a
And I now see two reasons for its migration to happen quickly:
I wonder if we should wait for 9.1 to migrate before uploading
9.2-BETA1 to unstable. If there's trouble ahead for 9.2, waiting a
long time can miss the opportunity for fixes to make it to
9.2-RELEASE.
I would still prefer 9.1 to
[...] IIRC it happens to me both, on the 9.1 and the
10 kernel but only recently.
It could be due to GCC-4.8 and/or use of -O2 compiler optimisations,
which were enabled only in the most recent upload of each.
Perfect guess!
I have been able to confirm crash also on my PC,
usually with only
Please just fix ENODATA occurence, with updated libusb2-dev
it suffices to build libgphoto2.
Hmm, Steven claimed it would work with just the patched libusb.h.
Sorry if I said/implied that; but I had applied Markus' ENODATA fix
before testing for the other issue. So yes, both libusb2-dev and
(working copy)
@@ -1,3 +1,11 @@
+freebsd-libs (9.1+ds1-3) UNRELEASED; urgency=low
+
+ [ Petr Salinger ]
+ * extend cdefs_macros.diff in libusb.h part
+ * libusb really needs libbsd
+
+ -- Robert Millan r...@debian.org Tue, 16 Jul 2013 15:24:27 +0200
+
freebsd-libs (9.1+ds1-2) unstable; urgency=low
It tries to autodetect, but then fails in a later step:
checking for libusb-1.0 to use... autodetect
checking for LIBUSB1... yes
checking libusb.h usability... no
checking libusb.h presence... yes
The attached patch may help with this. (I applied it directly to my
system libusb.h). After
What I like Git for mostly is its simple offline working, but that can
still be done locally just with `git init git commit -a` inside an
SVN working copy. Providing a .gitignore file might be a nice convenience.
What about using git-svn on user side ?
(I didn't try it myself yet).
Petr
--
Should be fixed in HEAD post r253531.
Please package and upload new snapshot.
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
111_ldd_load_address.diff changes kernel-user ABI. How mergeable is this?
It is not ABI chabge, it is only a change of
implementation defined behaviour.
Is FreeBSD also affected in some way? The testcase is reproducible
when built using their toolchain/libc, but not when using their ldd.
I'm
Would it be a suitable compromise if we agree to do this as soon as
9.2-BETA1 is available, or within 3 days from now, whichever comes
later?
Fine for me. Please could you in mean time do yet another upload of
kernel into experimental. The changes currently in SVN have been only
tested on my
Btw, I don't have time to do this right now, but it might be a good
idea to try the testsuites for ruby, perl and python (and possibly
others). They tend to break very easily on thread-related problems (as
I'm sure you remember ;-)).
During development, I used glib2.0 and ruby1.9.1 as secondary
Hi.
Updated version of FBTL (NPTL like) glibc is available from experimental.
Thanks to Aurelien.
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Package: binutils
Version: 2.23.52.20130612-1
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
compared to binutils 2.22-8, there is a significant change of
_end symbol behaviour.
glibc built by binutils 2.22-8:
readelf -a 6/lib/x86_64-kfreebsd-gnu/libc.so.0.1 |
1006: 00358e28 0 NOTYPE GLOBAL DEFAULT ABS _end@@GLIBC_PRIVATE
1006: 00358e08 0 NOTYPE GLOBAL DEFAULT 33 _end@@GLIBC_PRIVATE
What about their content? Perhaps they're some kind of fixed-size metadata.
The value itself does not matter here, but ABS-33 change.
Try
This causes gcj-4.8-jre-headless to fail during installation and, as a
result, default-jdk is currently uninstallable.
Please look at libjava in
Debian 4.8.1-5
http://lists.debian.org/debian-gcc/2013/06/msg00221.html
http://lists.debian.org/debian-gcc/2013/06/msg00223.html
Debian 4.8.1-6
/* TID of the helper thread. */
-extern __lwpid_t __helper_tid attribute_hidden;
+extern pid_t __helper_tid attribute_hidden;
(in kernel-posix-timers.h and timer_routines.c)
lwpid_t happens to match pid_t but AFAICT they're supposed to be
different things. Nothing prevents upstream from
Btw, I'm running your NPTL on my desktop (I force-fed it into a Wheezy
system) and all seems fine so far. Tried iceweasel and icedove.
Thanks for testing.
What's your deployment plan? Is this being uploaded to experimental,
or directly to sid?
I am not a DD, I cannot upload anywhere.
I
Package: kfreebsd-9
Severity: wishlist
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
To properly provide CLOCK_THREAD_CPUTIME_ID, CLOCK_PROCESS_CPUTIME_ID
and clock_id's created by clock_getcpuclockid() and
pthread_getcpuclockid(), we need a kernel support.
See also #665287.
The kernel
When I ported pthread timers, I also ported them to NPTL at the same
time, but (obviously) couldn't test them at the time. Did you test
those and/or merge them into your port? They're in
ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/nptl/ (in sysdeps.diff).
I did it in a different way, first changes
Hi.
As you might know, we are still using linuxthreads based
pthread implementation.
I would like to ask you to test NPTL like pthread implementation.
Please find it for both kfreebsd-* at
http://asdfasdf.debian.net/~salinger/eglibc.fbtl/
Cheers
Petr
--
To UNSUBSCRIBE,
GLib-GIO:ERROR:/?PKGBUILDDIR?/./gio/tests/file.c:452:test_create_delete:
assertion failed (data-monitor_created == 1): (0 == 1)
/file/async-create-delete/0: FAIL
May well be due to the kqueue support for file monitor. Help fixing it on
kfreebsd is very
Hi.
I opened a ticket in Alioth for this already:
https://alioth.debian.org/tracker/index.php?func=detailaid=314307group_id=1atid=21
We (glibc-bsd) use script from subversion-tools,
and location of that script have changed.
Our post-commit hook script have to be altered:
Now that we're using LWP in LinuxThreads, is there any particular
reason not to enable PT_LWPINFO in sys/ptrace.h ?
Im am not aware of any.
Does gdb build against such header ?
ptrace.h have been last synced 2009-12-21
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
The set as is in SVN does boot/work
on both real and kvm-based kfreebsd-amd64.
I see. Btw, why did you enable debug mode? Do you need debug builds
for your own use, or did lack of debug flags interfere with something
else?
No particular reason, I just expected crash and wanted to have debug
In ideal world, we would have whole 9.1 in unstable
and at least kernel from STABLE-9 in experimental.
For real world, one of them suffices ;-)
Maybe I could help with getting 9.1 in unstable. Is there any reason
it is currently being held?
man-power ?
And may be previously crashing new (aka
Is it allowed and viable to enable debugging only for uploads going to
experimental? And disable for everything else.
As per Policy? It should be. Experimental uploads are not intended for
a release, it's no big deal if they don't comply.
I'm still concerned about the heisenbug problem.
...
Okay. So I take it there's no technical blocker for an upgrade? I may
begin transition then.
Does this look like a reasonable order of steps? First buildutils,
then kernel, then kernel headers, then libs, then utils?
The order seems be fine.
At least the build of eglibc should be tested
Hi.
OTOH I notice Petr's changes in kfreebsd-10 which enable use of GCC
4.8. However they haven't been uploaded yet.
Only DD can.
I recall there were major problems in the past that were triggered by
using a specific version of GCC in combination with optimization =
-O2.
Petr, are you
The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
killed after 150 min of inactivity.
We would appreciate any help and insight from the kfreebsd to fix those
failures on kfreebsd-*.
Some observations
libtool: link: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/x86_64-kfreebsd-gnu/4.7/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/4.7/crtbeginS.o [*very long list of objects*]
-Wl,--whole-archive ./.libs/libWebCore.a ./.libs/libWebCoreGtk.a
-Wl,--no-whole-archive
Control: retitle -1 [kfreebsd-i386] symbol posix_fallocate64, version
GLIBC_2.3.3 not defined in file libc.so.0.1
Control: reassign -1 libc0.1 2.17-4
I installed Debian wheezy kfreebsd-i386 (standard + openssh-server, I think)
on a kvm virtual machine, upgraded to unstable to try to test a
However, itk is going to disappear soon from our source so that this is
not a serious problem to be addressed. We may do something akin to
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=commitdiff;h=2dd95f8ef64dd68b2acf55c1d1b98637fbb98903
in a way it applies to kfreebsd, too.
On Sun, 19 May 2013, Guillem Jover wrote:
I'd even volunteer to switch the repositories
Outcome of discussion seems be:
- use svn or git
switch to git
- packaging-only or full content
packaging-only
- one common repository x repository per package
repository per package
Petr
--
To
severity 709872 wishlist
--
I looked for a packaged named libzfs1-dev or libzfs-dev and couldn't find any
for Debian GNU/kFreeBSD Wheezy. It seems like the only way to get the ZFS
headers, like libzfs.h, is to download the source of libzfs1 or zfsutils.
We should have a proper development
I'm not sure if it's noteworthy, but I backported gcc-4.8 to wheezy
rather than installing directly from jessie/sid, since we're using
wheezy as a stable base internally.
I'll continue to try different things and see if there is any change
here.
What is your grub version ?
Please could you
Hi,
We already tried to get rid of
pid %d (%s) is using legacy pty devices%s\n
see
http://lists.debian.org/debian-bsd/2011/06/msg00111.html
There have been some problems, like #632452,
http://lists.debian.org/debian-bsd/2011/07/msg0.html
I'd like to propose switching and splitting the glibc-bsd repo from svn
to git repositories
My position:
- use svn or git
It does not matter for me.
- packaging-only or full content
I strongly prefer packaging-only.
- one common repository x repository per package
I slightly prefer one
As buildd admin I can't directly do the upgrade
apart from asking DSA to go ahead this which I'll do as soon as wheezy
buildds are figured out for wheezy infrastructure (which is currently
being worked on).
Please ask them to use kfreebsd-9 kernel,
as only it have (backported):
*
However, it is failing on:
lvm-toolchain-3.2-3.2repack/tools/lldb/source/Host/common/Host.cpp:156:38:
error: '::waitpid' has not been declared
The code is:
const lldb::pid_t wait_pid = ::waitpid (pid, status, options);
The full log is available here:
tags 706984 +patch
--
The last gmp upload failed to build on hurd-i386 and kfreebsd-i386
and I could use some help. The code builds but seven test cases
segfault [1]. Can someone help debug these and hopefully provide
a patch?
It crashes also for me inside kvm.
The key point seems be
Hi.
I would like to change the way we handle linuxthreads add-on.
It is not any longer in glibc git, it does not receive any updates in
eglibc. As far as I know, the GNU/kFreeBSD is the only user of
linuxthreads codebase today.
I suggest to copy latest eglibc version into
Should I assume from your updating expected results in SVN that you're
dangerously close to declaring this good enough for upload? I'm
still waiting on all the other arches to finish, so we don't get any
more surprises, but we should be close to ready to do -2 and wash our
hands of this, while I
True, but the build still fails early. And the testsuite hasn't run yet.
So far:
***
Encountered regressions that don't match expected failures
(debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc):
tst-align.out, Error 1
tst-backtrace4.out, Error 1
At first glance it looks like some feature is not being detected/enabled
during the python2.7 build.
From
https://buildd.debian.org/status/fetch.php?pkg=python2.7arch=kfreebsd-amd64ver=2.7.4-2stamp=1365768399
:
checking for sem_open... yes
checking for sem_timedwait... yes
checking for
Package: packagekit
Version: 0.8.7-1
Severity: important
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
On Thu, 18 Apr 2013, Matthias Klumpp wrote:
PackageKit in it's newest version doesn't build on !linux
architectures, due to Linux specific functions, and I don't have the
On my system the daemon fails to start in any case with 'Daemon startup
failed', but that is a separate issue and less serious. There seem to
be two separate places where pulseaudio --start may hang indefinitely on
kfreebsd:
On my system, it is slightly better:
E: [(null)] client-conf-x11.c:
clone 704598 kfreebsd-kernel-headers
--
At first glance at this, I think it was made 'static inline' because the
function (copied from FreeBSD libc) really is being inlined into the
header; it wouldn't be linked into the executable otherwise as glibc
does not have it.
I think 'static' is
There's a similar problem in sys/sys/filedesc.h reported as #686402 -
another kernel header.
Could we likewise change u_long - unsigned long? Doing so would revert
part of 'style bug' commit by upstream to its previous form.
Definitely we can ;-)
IMHO it is the best option we have.
Petr
--
As suggested by Michael Banck on IRC I've been looking at Signals used
by both parts to see if they e.g. battle over SIGUSR?. However libgc
seems to use 32+{5,6} as signals on x86 FREEBSD __GLIBC__ at
least. Petr, Steven: any idea why this is? Are these signals fine for
kfreebsd glibc (signal.h
1 - 100 of 563 matches
Mail list logo
