Bug#902946: [systemd/systemd] Fails to load autofs module through autofs4 alias (#9501)
Trying to send test-patch to the Debian bug tracker too.. I suspect this will be rejected as spam, but I can try. Linus fs/autofs/Makefile | 4 ++-- fs/autofs/init.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/autofs/Makefile b/fs/autofs/Makefile index 43fedde15c26..1f85d35ec8b7 100644 --- a/fs/autofs/Makefile +++ b/fs/autofs/Makefile @@ -2,6 +2,6 @@ # Makefile for the linux autofs-filesystem routines. # -obj-$(CONFIG_AUTOFS_FS) += autofs.o +obj-$(CONFIG_AUTOFS_FS) += autofs4.o -autofs-objs := init.o inode.o root.o symlink.o waitq.o expire.o dev-ioctl.o +autofs4-objs := init.o inode.o root.o symlink.o waitq.o expire.o dev-ioctl.o diff --git a/fs/autofs/init.c b/fs/autofs/init.c index cc9447e1903f..79ae07d9592f 100644 --- a/fs/autofs/init.c +++ b/fs/autofs/init.c @@ -23,7 +23,7 @@ static struct file_system_type autofs_fs_type = { .kill_sb = autofs_kill_sb, }; MODULE_ALIAS_FS("autofs"); -MODULE_ALIAS("autofs4"); +MODULE_ALIAS("autofs"); static int __init init_autofs_fs(void) {
Bug#815787: May be a kernel problem not a pulseaudio one?
On Feb 28, 2016 9:36 AM, "Cristian Ionescu-Idbohrn" < cristian.ionescu-idbo...@axis.com> wrote: > > > "Apparently there is some work under way to allow both ZONE_DEVICE > (needed for DAX) and ZONE_DMA (needed by the sound drivers) to be > supported in the same kernel configuration." Yeah, but do you actually need or use ZONE_DEVICE? Even DAX doesn't actually need it except for some special cases, iirc. I don't think distributions should necessarily enable it at all yet. > and there may be some hope with: > > http://www.spinics.net/lists/kernel/msg2170767.html > > Is there, Linus? Yes, but that's 4.6 of later. And unlikely to be marked for back porting to stable. So *eventually* we'll support that combination, but for now... Linus
Bug#815787: May be a kernel problem not a pulseaudio one?
On Sat, Feb 27, 2016 at 1:52 PM, Cristian Ionescu-Idbohrn wrote: > Background: https://bugs.debian.org/815787 > > "Until recently the Sound Blaster Live! card in my workstation worked > fine. Sometime recently it has stopped working." > > On Sat, 27 Feb 2016, Ben Hutchings wrote: >> On Sat, 2016-02-27 at 10:39 +0100, Cristian Ionescu-Idbohrn wrote: >> > >> > No mention of that in the changelog. >> >> Yes there is: >> >> * [amd64] mm,nvdimm: Disable ZONE_DMA; enable ZONE_DEVICE, NVDIMM_PFN >> - This disables drivers for some AC'97 sound cards > > Alright, but not obvious to me. > > So, what is to do about that? If I read this right, this seems to be a Debian kernel configuration choice rather than anything else. Does it work if you just compile your own kernel? Linus
Bug#789875: subsurface: FTBFS in experimental
On Wed, Aug 26, 2015 at 3:41 PM, Mikko Rasa wrote: > > Have you considered in-source copies of the modified libraries? Ehh. That's what subsurface has done since day#1 - even back when I maintained it (long long ago), I refused to link against a dynamic libdivecomputer, because the libdivecomputer versioning is broken, and it's stupid to do dynamic linking for something that isn't shared anyway. The Debian people were crazy, and said "that's against our rules", and wanted a separate libdivecomputer library. These days, subsurface does its own libgit2 and libmarble due to similar issues. No, not using git submodules, but in the build scripts. And again, who complains? So quite frankly, the fact that Debian people now attack Dirk, who has been bending over backwards over these kinds of stupidities, is not a big surprise. I think it's in the Debian DNA to care more about rules than about technical sanity. The whole "this is the only right way to do licensing" thing extends to "this is the only correct waty to do packaging". It's sad to see. Linus
Bug#563313: [165/197] ACPI: EC: Allow multibyte access to EC
On Thu, 22 Apr 2010, Greg KH wrote: > > From: Alexey Starikovskiy > > commit dadf28a10c3eb29421837a2e413ab869ebd upstream Hmm. Doesn't this need commit 2060c44576c79086ff24718878d7edaa7384a985 to fix things up for crazy access_bit_width values? Maybe it's there in the series somewhere, but I didn't see it. Linus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org