been ABI updates anyway, particularly in
stable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Michael Biebl writes:
> Am 10.05.2018 um 19:22 schrieb Russ Allbery:
>> I may be misunderstanding the nature of the issue, but I believe that a
>> Type=oneshot service that runs a small C program that calls getrandom()
>> and then exit(0) when it returns would provide a use
ide to take this approach (this
seems obviously correct for kadmind, for instance), having this sort of
facility available would make it easy to declare the right dependency.
It's akin to systemd-networkd-wait-online.service.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Oh, one additional piece of information that may be relevant here: this
system uses disk encryption as set up by the Debian installer, which
includes encryption of the swap partition (and therefore of the hibernate
image).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.
Ben Hutchings writes:
> On Mon, Sep 03, 2012 at 12:21:06PM -0700, Russ Allbery wrote:
> [...]
>> linux-libc-dev maintainers, when upgrading to squeeze, there is
>> currently nothing preventing linux-libc-dev from being upgraded to a
>> version that uses multiarch paths in
affected dkms, since dkms runs a compiler from postinst
scripts. I believe linux-libc-dev needs the same Breaks logic as
libc6-dev, namely something like:
Breaks: gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 4.6.0-12)
--
Russ Allbery (r...@debian.org) <
ped building my own
kernel a long time ago, so most of my understanding is hearsay.
I keep maintaining -source packages for other packages with kernel modules
mostly because I keep getting a small number of bug reports for them, so
people are clearly still using them.
--
Russ Allbery (r..
t doing
this.
I noticed that dkms now Recommends the tracking kernel header package, so
maybe that makes this somewhat more obsolete. That means that the average
user should, through the dependency tree, get the header package installed
when they install nvidia-modules-dkms, whic
ted Debian users. What
Andreas has been doing, which I think is fairly reasonable, is keeping
them out of testing until shortly before the freeze and then updating them
for the freeze, which means only doing new uploads for ABI changes that
happen during the freeze or in stable (relativel
RCFOUR_HMAC
ENCTYPE_DES_CBC_MD5
ENCTYPE_DES_CBC_CRC
ENCTYPE_DES_CBC_MD4
which is indeed every enctype that you're ever likely to care about. So
just omitting the -e flag would be correct with that set of supported
enctypes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/&
which case the right thing to do is to just leave off the -e
flag completely and let the Kerberos infrastructure use whatever its
default configured enctype list is.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ke
c.svcgssd isn't supporting arcfour-hmac
for some reason. Maybe you don't have the backported version of
everything and your daemon still only supports DES somehow?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debia
n* run klist -e and look at what encryption type the service
ticket for nfs/archiv.sag.local@SAG.LOCAL has.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "u
1:28 11/15/11 08:51:36 krbtgt/SAG.LOCAL@SAG.LOCAL
> renew until 11/15/11 22:51:28
It would be more interesting to run klist -e after attempting to contact
the server, so that you can see what the encryption type of the service
ticket for the NFS server was.
--
Russ Allbery (r...@debian.org)
e NFS machinery is going to need to support either arcfour-hmac or
aes128, since Windows never supported 3DES, and you don't want to use
plain DES any more (and it has to be specifically enabled on the Windows
side, if they haven't dropped it entirely now). I'm not sure what
en
it right now for
multiple packages. But writing the original -source package rules file is
arcane and very under-documented, so this is potentially a long-term
improvement.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debia
Ben Hutchings writes:
> On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote:
>> With hundreds of servers, we'd rather not install compilers and DKMS on
>> every one of them, and with lots of machines, the loss of
>> reproducibility from separately compiling the module
new ABI.
(So thank you very much for all the work that you put into maintaining the
ABI!)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
rting any major change in how this
is handled.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.d
t mainstream.
We think that may be fixed upstream now, although we're not sure because
none of the people currently working on the NVIDIA packages have a Xen
host to test with. (It at least compiles, which it didn't do before.)
--
Russ Allbery (r...@debian.org) &
se a single ABI number across all image
> packages so there is no indication of when the ABI changes for them.
Thanks! I'll get those kernel module builds removed before squeeze
releases.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSU
maximilian attems writes:
> On Sun, Oct 10, 2010 at 09:51:33AM -0700, Russ Allbery wrote:
>> Does this change mean that the module builds for Xen and OpenVZ kernels
>> may not continue working with later versions of those kernels because
>> the ABI might not be stable? Or i
y
about?
I ask primarily because we want to be sure it makes sense to release
pre-built modules for Xen and OpenVZ kernels with squeeze.
Thanks!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.
Package: linux-2.6
Severity: normal
There were apparently multiple problems involved here, and the upstream
bug is still open, so I'm not sure whether you want to close this. But
for the record, my problems were completely resolved by 2.6.32 and have
not recurred.
-- System Information:
Debian R
e using
libtool to do their linking. The latest GNU
libtools (>= 1.3a) can take advantage of the metadata in the
Please copy 519...@bugs.debian.org on all discussion.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE,
an adapt, so since this change is intentional, no point in having
the kernel team read through the AFS-specific details.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
it eventually, but I don't have
the new kbuild infrastructure installed anywhere yet.)
rx may require similar treatment.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
f the kernel
> without using kbuild.
OpenAFS *does* use kbuild. Aaron, what exactly breaks? Example error
messages? Is it just the symlinking to standardize the names of the
header files across platforms that doesn't work?
--
Russ Allbery (r...@debian.org) <http://www.eyrie
makes this trickier.
What's the intended use of the new layout in these packages? Are modules
expected to provide a search path for include files rather than assuming
headers are in one unified location?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
unfortunately I don't have a lot of time to try to help propose
and develop the standard and test the implications. It may end up being
somewhat moot anyway since we have at least one report that a new kernel
module does indeed require a new openafs-client -- I'm going to check with
u
separate locations?
All that's in the package is a tarball in /usr/src (it's the standard
module build pattern). If it were called something other than
openafs.tar.gz or expanded into a different directory, wouldn't that
confuse tools like module-assistant?
--
Russ Allbery ([EMAI
dann frazier <[EMAIL PROTECTED]> writes:
> On Tue, Jun 17, 2008 at 10:48:45AM -0700, Russ Allbery wrote:
>> I'm quite happy to upload new packages for etchnhalf, but I'm afraid
>> they'd have to be just that -- packages of a newer upstream. The
>> ups
n going to the current packages from
Debian testing.
So... I guess my question is, what is the policy for etchnhalf for
packages that involve kernel modules? Is it fair game to upload a new
upstream version, unlike the normal stable release policies?
--
Russ Allbery ([EMAIL PROTECTED])
ree kernel modules are not all proprietary crap. Some of them are
not GPL for reasons that have nothing to do with vendors and supposed
trade secrets; in this case, it was because OpenAFS is a huge body of code
that acquired hundreds or thousands of independent submissions under the
IBM Public Lice
management reasons. If the decision of the
Debian kernel team is that the interface is actually stable and ready to
be exported, it seems reasonable to also reverse the patch that declared
it not to be.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
-
maximilian attems <[EMAIL PROTECTED]> writes:
> kvm is a too interesting tech to be disabled,
> checkout buildserver trunk builds to see if it is solved in 2.6.21-rcX
> -> wiki.debian.org/DebianKernel
Okay, we'll check. Thanks.
--
Russ Allbery ([EMAIL PROTECTE
Package: linux-2.6
Version: 2.6.20-2
Severity: important
The 2.6.20 kernels in unstable for 686 and k7 have CONFIG_PARAVIRT enabled.
This apparently redefines various operations widely used by kernel modules
(or included via inlined functions) to redirect through a paravirts_ops
table, but the par
tch up with all the API changes. For full 2.6.19
support on all platforms I believe I'd need to pull patches from CVS for
OpenAFS, whereas the current packages are stable and functioning on
2.6.18.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
T
you're talking about may fall into this
category, but this distinction seems to be lost in this thread and I don't
want people to miss it. It *does* happen that the concept of source isn't
overly meaningful for some things.
--
Russ Allbery ([EMAIL PROTECTED]) <http://ww
39 matches
Mail list logo
