Re: Upcoming changes to Debian Linux kernel packages

> "Bastian" == Bastian Blank writes: Bastian> The same as now: nowhere, because those packages have been Bastian> removed from the archive already. Bastian> And sadly you did not answer the question why a second Bastian> degree error must not be worse then a worked around

Re: Upcoming changes to Debian Linux kernel packages

> "Bastian" == Bastian Blank writes: Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote: >> On 25/09/2023 00.50, Bastian Blank wrote: >> > Already built modules remain until someone deletes it. So you >> can also > switch back to the still installed

Bug#1035908: Bullseye regression: NFS4 referals appear not to work

package: nfs-utils severity: important justification: regression from bullseye with silent failure version: 1:2.6.2-4 Hi. I've noticed that since upgrading to bookworm the refer option in /etc/exports appears to be entirely ignored. Looking through the sources to exportd and

Bug#1028451: 2nd DisplayPort doesn't get video

> "Moritz" == Moritz Mühlenhoff writes: Moritz> Not moving to 6.1.x (which is most likely the next Linux Moritz> kernel LTS) is by far a worse regression since it applies to Moritz> every single Debian system. Moritz> As a community distro without paid, full time kernel

Re: Which package is responsible for setting rlimits?

>>>>> "Simon" == Simon McVittie writes: Simon> On Mon, 01 Feb 2021 at 11:49:25 -0500, Sam Hartman wrote: >> >>>>> "Simon" == Simon McVittie writes: I'm >> assuming that the proposal is to change this for bookworm.

Re: Which package is responsible for setting rlimits?

> "Simon" == Simon McVittie writes: I'm assuming that the proposal is to change this for bookworm. It seems like it's too late in the process to change something like this for bullseye without more explicit and significant harm documented than you have given so far. Simon> Rationale:

Re: Producing verifiable initramfs images

This is not a disagreement with anything you write. I've noticed that there is a lot more configuration that gets encoded in the initramfs than I thought. The most surprising for me is that if you want to control the names of network devices or anything else set by the .link file, that ends up

Re: Merge request friendly handling of debian/changelog

I agree that better handling of things like debian/changelog is something we should focus effort on. I think we can either do something gbp dch like, possibly allowing commits to annotate whether and to what extent they should be included in changelog. Or some code that knows how to merge

Re: Bits from the Release Team: ride like the wind, Bullseye!

> "Ben" == Ben Hutchings writes: Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: Ben> [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle

Bug#929557: Some Thoughts

The linux Kernel introduced an upstream commit designed to remove an interface that was being misused. That does not meet the kind of requirements for changes that we (Debian) make in stable releases. If I filed an unblock for krb5 to remove an interface at this point in the release process it

Re: ZFS in Buster

Hi. Thanks for bringing up this issue originally. I think it has started some good discussion with the Debian zfs maintainers. However, I think this particular subthread about zfs has served its purpose. I cannot find anything in your message that is on topic for the debian-devel mailing list.

Re: Fixing Linux getrandom() in stable

> "Thorsten" == Thorsten Glaser writes: Thorsten> Adrian Bunk dixit: >> As an example, what happens if I debootstrap and deploy the >> resulting filesytem to a large number of identical embedded >> systems without entropy sources? Thorsten> Just get into

Bug#808293: freeradius stopped working after kernel upgrade

control: -1 severity important I'm not sure what the best way to avoid freeradius being pulled out of jessie is besides dropping the severity. If tagging it wheezy and bringing the severity back up would work feel free to do that. Is anyone seeing this with jessie or is this a wheezy-only issue?

Bug#622146: This is broken for me.

Rob == Rob Naccarato r...@naccy.org writes: Rob This doesn't appear to be fixed to me. I get the same Rob problems. I have even installed backported kernel Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I Rob still get these: This requires fixes in krb5 and

Bug#622146: nfs-common: compatibility between squeeze and sid broken

It should be fixed in unstable by actually supporting the new enctypes. While ncice, that rather misses the point. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#622146: nfs-common: compatibility between squeeze and sid broken

Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam The krb5 package was uploaded and I've (somewhat belatedly) Adam marked it for acceptance at the next dinstall. What's the Adam status of the nfs-utils upload? My guess is they were waiting for krb5. Remember they have

Bug#622146: nfs-common: compatibility between squeeze and sid broken

I expect to get to the krb5 package in a day or so. I expect nfs-utils will want to up its build-depends on krb5 to 1.8.3+dfsg-4squeeze2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#622146: nfs-common: compatibility between squeeze and sid broken

Philipp == Philipp Kern pk...@debian.org writes: Philipp On Mon, Aug 01, 2011 at 01:34:34AM -0700, Steve Langasek wrote: On Tue, Jul 19, 2011 at 05:42:34PM -0400, Sam Hartman wrote: I don't have checkouts handy, but my strong suspicion is that if someone is now passing

Bug#622146: nfs-common: compatibility between squeeze and sid broken

If I get an ack from SRM i'll do the krb5 upload. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tsllivd472o@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

Steve == Steve Langasek vor...@debian.org writes: Steve Hi Sam, I've also run into this bug, in the context of Steve preparing to update nfs-utils in Ubuntu for IPv6 support. My Steve NFS server is running squeeze, and updating causes the client Steve and server to fail to

Bug#622146: nfs-common: compatibility between squeeze and sid broken

I don't have checkouts handy, but my strong suspicion is that if someone is now passing in GSS_C_NT_HOSTBASED_SERVICE into gssd_acquire_cred and there isn't an argument slot, you can leave it off. gss_c_nt_hostbased_service has always been the default for gssd. -- To UNSUBSCRIBE, email to

Bug#622146: nfs-common: compatibility between squeeze and sid broken

OK, I have no clue nor really any interest in debugging DES. There is a real bug here introduced in krb5 1.7 which added enctype negotiation . I'd expect that to create some problems for sid clients talking to squeeze servers. There's a solution to that which involves backporting the nfs-utils

Bug#622146: nfs-common: compatibility between squeeze and sid broken

Hi. I was missing some context here. My suspicion is that things will work if you add permitted_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc to the configuration of the nfs server And make sure that the nfs principal on the NFS server has nothing but a des-cbc-crc key in the KDC

Bug#622146: nfs-common: compatibility between squeeze and sid broken

Luk == Luk Claes l...@debian.org writes: Luk On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote: Adding the following line in the [libdefaults] section of /etc/krb5.conf fixed the problem for me (tm), probably not the best solution, but works: permitted_enctypes =

Re: openafs in etchnhalf

Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Rainer Dorsch [EMAIL PROTECTED] writes: is anybody taking care of the openafs modules which do not compile any more with the etchnhalf kernel? The openafs modules in backports.org do compile though with the