Dear all,
let me initiate a spinoff subject related to Axel Beckert's
followup from the FOSDEM meeting.
My interest in activating
option QUOTA
is well known. My work from last week points also to
option IPSEC
option IPSEC_NAT_T
device crypto
device enc
However, I have
2011/2/8 Mats Erik Andersson mats.anders...@gisladisker.se:
Anyway, there is certainly functionality that is not default
in upstream FreeBSD, but could justly be considered mandatory
for GNU/kFreeBSD. Could we collect some kind of central information
source on this matter?
I would suggest
On 02-08 14:49, Mats Erik Andersson wrote:
Dear all,
let me initiate a spinoff subject related to Axel Beckert's
followup from the FOSDEM meeting.
My interest in activating
option QUOTA
is well known. My work from last week points also to
option IPSEC
option IPSEC_NAT_T
tisdag den 8 februari 2011 klockan 15:50 skrev Robert Millan detta:
2011/2/8 Mats Erik Andersson mats.anders...@gisladisker.se:
Anyway, there is certainly functionality that is not default
in upstream FreeBSD, but could justly be considered mandatory
for GNU/kFreeBSD. Could we collect some
2011/2/8 Mats Erik Andersson mats.anders...@gisladisker.se:
If you and other are of the view that the BTS is the best
first step, then I will abide that mechanism of raising any
issues concerning the capacity of the packaged kernel.
That's my first impression, but keep in mind my voice is not
A particular example I have encounterd is ipsec-tools
where a recent upload aims at adaptions to BSD, but where
the present kernel is neither supporting the API, nor the
relevant devices. Here I will prepare information for making
an official decision in the end, but other cases are certain
to
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Anyway, there is certainly functionality that is not default
in upstream FreeBSD, but could justly be considered mandatory
for GNU/kFreeBSD. Could we collect some kind of central information
source on this matter?
Thanks for the
Hi!
On Tue, 2011-02-08 at 18:55:25 +0100, Petr Salinger wrote:
If you and other are of the view that the BTS is the best
first step, then I will abide that mechanism of raising any
issues concerning the capacity of the packaged kernel.
The mails into BTS are forwarded to maintainer e-mail
2011/2/8 Guillem Jover guil...@debian.org:
[...] upstream might not
have enabled them because they are not deemed ready for wider use,
for stability, performance, or other reasons.
A possible solution to this could be to build another kernel image
flavour with some default diverging options
9 matches
Mail list logo
