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 kfreebsd-amd6
Everything's good except for transmission, which failed on kfreebsd.
Probably a miniupnpc call only compiled on that architecture.
In fact, the problem is sligthly different.
The transmission package does not support newly
supplied libminiupnpc-dev under both Linux and kFreeBSD:
"checking suppo
If someone puts together a debdiff including them, I'm more than
happy to look at that and we can make a call from there. (Bearing in
mind that the window for 7.2 closes over the coming weekend.)
Any news here? We're now nearing the end of the window for 7.3.
Ping? The next point-release is c
- 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Conta
Hello.
One more problem popped up - #712196
The fix is one-liner:
--- kfreebsd/syscalls.list
+++ kfreebsd/syscalls.list
-sys_ktimer_settime - ktimer_settime i:ip
__syscall_ktimer_settime
+sys_ktimer_settime - ktimer_settime i:iipp
__sy
22:08:34 +0800
From: Michael Tsang
To: Petr Salinger
Subject: Re: initgroups changes egid on kfreebsd
That fixes my problem. Thank you. Please commit the patch.
On Tuesday 05 February 2013 22:16:15 you wrote:
Encountered regressions that don't match expected failures:
tst-timer2.out, Er
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please pre-approve following change for eglibc.
The rationale is that setgroups(size, groups) changes egid on kfreebsd,
precisely groups[0] is the new egid.
initgroups(user, gid) prepares
haxe isn't in wheezy; a request to change that has already been denied.
Given all of the above, we should consider whether this should wait
until after the release.
Please add as input into your consideration this:
The fix went into upstram kernel by this
http://lists.freebsd.org/pipermail/s
Just keeping you posted. The change looks reasonable, but the package
needs a separate ACK from the d-i team. Last I heard from them, they
requested that we hold all udebs for now.
It is a little problematic. The udeb is created only for
* hurd-i386 kfreebsd-amd64 kfreebsd-i386
And versi
- X.Org X server -- mouse input driver
xserver-xorg-input-mouse-udeb - X.Org X server -- mouse input driver (udeb)
xserver-xorg-input-mouse (1:1.7.2-3) unstable; urgency=medium
.
* Update bsd-array-bounds.diff patch to fix crashes on kfreebsd-*,
thanks to Petr Salinger (Closes: #681506
Apologies if I'm missing something obvious, but should
alter_to_native_keymap() not revert all of the changes made by
alter_to_debian_keymap() rather than just a couple of them?
It should generate the same sequences as before,
but it does not have use the same way for it.
The us.iso.kbd have by
Apologies if I'm missing something obvious, but should
alter_to_native_keymap() not revert all of the changes made by
alter_to_debian_keymap() rather than just a couple of them?
It should generate the same sequences as before,
but it does not have use the same way for it.
The us.iso.kbd have by
tils 8.1-4 also fixes failure of init.d script
if kbdcontrol is removed but not purged
as pointed out by Sven Joachim [2].
Petr
[1] http://lists.debian.org/debian-release/2011/01/msg00090.html
[2] http://lists.debian.org/debian-bsd/2011/01/msg00070.html
freebsd-utils (8.1-4) unstable; urgency=low
1) plain cons25 variant: current sysvinit, ncurses 5.7+20100313-4 or
5.7+20100313-5
and kfreebsd-8 8.1+dfsg-6 (or 8.1+dfsg-7.1), freebsd-utils 8.1-2
[...]
2) cons25-debian variant: needs patched sysvinit, ncurses 5.7+20100313-5,
and kfreebsd-8 8.1+dfsg-7, freebsd-utils 8.1-3
[...]
3)
Hi.
Background:
The plain FreeBSD kernel generates different sequences
for Backspace and Delete keys compared to Linux (and required by Policy).
Generated sequences can be altered by kbdcontrol (from freebsd-utils
source package) and the default sequences are of course in kernel
(kfreebsd-8 so
what would the effect on the
kfreebsd-* kernel be of removing all of the files which were originally
mentioned in Ben's mails in this bug report, and is that an option which
has been considered by the porters?
From my (non-DD) POV, the most problematic are network drivers
sys/dev/txp/3c990img
Now we have to somehow prune current source tree and disable some
modules. Could we get squeeze-ignore tag for some of the affected
files or is it necessary to prune all affected files ?
Ben's original lists included some files which we don't appear to be
able to distribute at all. If his analy
For the remainder of the files, whilst we may consider granting a
squeeze-ignore tag, we would like to come to an agreement as to how we
can resolve these issues in the medium term. We appreciate that the BSD
kernel has not received the same level of upstream attention that the
Linux kernel has i
So this (firewall/router requirement) is what brought me to kFreeBSD in
the first place and I have to say that this is not without problems.
First, I cannot run "netstat -rn" in kFreeBSD. I have yet to file a bug
on this, but it just shows how elementary communication channels between
userland an
Hi,
the Release Team is currently wondering if it makes sense to release with
kFreeBSD as a regular stable architecture with squeeze. It might be that
it is not yet up to the standards of a regular Debian release as it might
not contain everything that's expected by users.
So, what do you thin
Hi.
Please see 573940. I'm open to suggestions on how to deal with this. If
I understand correctly, kfreebsd has been declared a release arch for
squeeze, but its libc (0.1?) doesn't handle compatibility between kernel
versions, its old kernel lacks features that are standard in other
debian
reopen 551024
--
libpthread-stubs 0.2-1 was broken (see #548240 and the merged bug),
libdrm needs to be rebuilt to fix libdrm-intel1's broken dependency on
libpthread-stubs0. (amd64 is fine, other arches don't matter because
libdrm-intel1 is useless there.)
In the last sentence should be "ot
Hi,
I included more than transitions to get better picture of possible impact.
The GNU/kFreeBSD porter plans
* decide version of kernel and related utilities.
It mainly depends on freeze time. Currently we use 7.2. The 8.0 should
appear in October, but dot-zero is dot-zero.
Hi,
on both kfreebsd-i386 and kfreebsd-amd64 the latest build of
soprano and strigi have been against broken clucene-core_0.9.21b-1.
The linux-* architectures seems unaffected.
Please schedule binNMU for them to get them rebuilt against
current libclucene0ldbl.
Thanks
Petr
--
To UNSU
Hi,
please unblock security update of kfreebsd-6/kfreebsd-7
Thanks
Petr
kfreebsd-6 (6.3-7) unstable; urgency=high
* Fix amd64 swapgs local privilege escalation
(FreeBSD-SA-08:07.amd64 / CVE-2008-3890).
* Fix remote kernel panics on IPv6 connections
(FreeBSD-SA-08:09.
Hello,
please could you consider to unblock kfreebsd-6/6.3-6.
The changes compared to previous kfreebsd-6/6.3-4 in testing:
* debian/patches/*: converted to patchlevel p1
* new debian/patches/920_gcc4.diff, but not applied,
as we still use gcc-3.4 for building binary packages
* polished Build-
freebsd-sendpr (= 3.113+5.3-9): FAILED
The following constraints cannot be satisfied:
freebsd-sendpr (= 3.113+5.3-9) build-indep-depends on
freebsd5-buildutils (>= 5.3-2) {NOT AVAILABLE}
...
These three are simply bugs (of which only the first one is not
reported, though).
It is not a bug i
Hello,
it looks like it would be possible to get rid of obsolete libpcap0.7.
It should be sufficient to binNMU some packages against current
libpcap-dev (0.9.8-3), on i386 they are:
argus
fragroute
ipgrab
karpski
lft
netdiscover
nstreams
prismstumbler
scanssh
Petr
--
To UNSUBSCRIBE
> > > Current glibc does not support TLS under 2.4 kernels (see #226716),
> > > so this is probalby glibc bug (some people call it feature).
> > - provide TLS support for 2.4 kernels and an upgrade path?
> 2.4 kernels does not have the necessary stuff to support TLS,
> so that's not possible
Hello,
> On glibc maintainers request, I have added glibc to the candidate for
> the next stable release on the wiki. [1]
> According to the diff between the packages, this update only concerns
> timezone data. There is no change in the glibc code.
When (and iff) will be glibc updated due to time
30 matches
Mail list logo
