Re: What to do with d-i on armel?

[Adrian Bunk]

On Mon, Mar 04, 2024 at 09:52:14AM +0100, Gerardo Ballabio wrote:
> Gianluca Renzi wrote:
> > The same here. We never used the d-i but we are using Debian systems 
> > (kernel and root file system) as daily bases of our line of products 
> > embedded systems. Hundred of thousands of boards are using Debian since 
> > Debian Lenny 5.0. From armel to armhf 32 bit systems.
> > So a drop of the armel and/or armhf will force us to a very complicated 
> > rearrangement of our build systems.
> > Please don't do that if you can.
> 
> Hi Gianluca,
> if that is so important for your business, you might consider
> sponsoring some work on this issue.
> The Debian Long Term Support project
>  is about keeping "old stuff"
> working so that might be the right place to ask.

That's not the right place, LTS is about keeping *old Debian versions*
security supported for 2 additional years (and has dropped armel since stretch).

LTS is not doing anything at all regarding keeping older/unusual 
hardware supported, such work has to be done directly in Debian
(and upstream).

> Gerardo

cu
Adrian

Re: Ability to further support 32bit architectures

[Adrian Bunk]

On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
> 
> Okay, maybe more workarounds exist.  But none of them look really
> promising.
>...

gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.

But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.

> Bastian

cu
Adrian

Bug#1040663: linux: Please build linux-libc-dev package for loong64

[Adrian Bunk]

On Wed, Jul 12, 2023 at 11:07:12AM +0200, Bastian Blank wrote:
> Control: tags -1 confirmed
> 
> Hi
> 
> On Sat, Jul 08, 2023 at 08:41:03PM +0200, John Paul Adrian Glaubitz wrote:
> > Please enable building the linux-libc-dev package for the new Debian 
> > architecture loong64.
> > The corresponding kernel architecture is called "loongarch".
> 
> I can't find loong64 in the debian architecture table used on
> ftp-master, so we can't add it yet.

This changed in 6.6.8-1 where you made the linux-libc-dev package 
binary-all. The problem you mention no longer exists in this form,
but not having loong64 headers in the now binary-all package made
many packages FTBFS on loong64.

Please add support for linux-libc-dev-only architectures in 
debian/bin/gencontrol.py.

With a binary-all linux-libc-dev it does still work to have a different 
src:linux in unreleased, but linux-libc-dev does now break every time 
src:linux gets updated since a binary-all package 6.6.10-1 has a higher 
version than linux-libc-dev_6.6.9+loong64 in unreleased.

In practice this means that linux-libc-dev must ship headers at the 
latest when an architecture gets added in ports, far earlier than
building kernel images (which as you said might require other changes
on the ftp-master side).

> Bastian

Thanks
Adrian

Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Adrian Bunk]

On Fri, Oct 27, 2023 at 10:55:48AM +0200, Bastian Blank wrote:
> On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > > ## Image packages contains more version info
> > > > 
> > > > Example: linux-image-6.5.3-cloud-arm64
> > > 
> > > > It will not longer be possible to reliably derive the package name from
> > > > kernel release (see above), as both values are not really related
> > > > anymore.
> > 
> > This package name seems to be missing the Debian release, which is
> > mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> > parallel, which again is mandatory. That's not something we can
> > compromise on; it's absolutely vital that
> 
> Sadly in Debian there is no way to make that happen.  Think for example
> about bin-nmu.
>...

Could you give a complete list of problems?

The only problem that comes immediately into my mind is the problem that 
uploads with new binary packages are going into NEW for no good reason.

If this is the only problem, I wouldn't worry too much since I'd be 
optimistic a GR to change this will be sucessful.

> Bastian

cu
Adrian

Re: Upcoming changes to Debian Linux kernel packages

[Adrian Bunk]

On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...

If the new kernel has a regression that affects the user, the user 
usually has no good choice other than downgrading to the previously-used 
kernel and continue using it until a fixed kernel is available.

How will the user get the headers matching this previously-used kernel
that are required until we provide a kernel with the regression fixed?

> Regards,
> Bastian

cu
Adrian

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Adrian Bunk]

On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> Note that the last time the problem arised already earlier in
> experimental and Ben workarounded it there with
> https://salsa.debian.org/kernel-team/linux/-/commit/9dfe6d33a4fd220394228b30cbbfdb3b444d36ec
> We probably can do that as well here. 60443c88f3a8 ("kallsyms: Improve
> the performance of kallsyms_lookup_name()") was in fact backported to
> 6.1.42. So this is next I would try and disable MPTCP and
> FUNCTION_TRACER.
>...

Yes, that looks reasonable.

Additionally, one generic cause of bloat is:
  debian/changelog:  * Enable UNICODE. (closes: #985689)
  debian/config/config:CONFIG_UNICODE=y

That's 74 kB uncompressed, and there doesn't seem to be any 
justification for not making it modular. It's not urgent since
Bens change handles the immediate problem, but worth changing
in unstable.

cu
Adrian

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Adrian Bunk]

On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> - Relese the DSA without armel builds. This is not optimal and for the point 
> release
>   we need to have to have all builds, but this gives people who still are 
> interested
>   in this architecture to step up and propose a fix for the problem, 
> otherwise then
>   disable the image size check, and then effectively dropping some support.
>...
> armel people, can you have ideally look at it ASAP on the comments
> please, I would not like to delay the DSA for linux on
> bookworm-security too much.

Releasing this DSA without armel and sorting out the issue for the point 
release sounds like the best option to me.

> Thanks for having a look,
> 
> Regards,
> Salvatore

cu
Adrian

Re: Debian Kernel version and ABI in respect of #1040901

[Adrian Bunk]

On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
>...
> We uncouple the package names and ABI.  The ABI will include the
> complete version, so every rebuild will change it.

That's also what I meant with "It should only be impossible to make them 
co-installable".

> The package names
> can include just the upstream version, aka 6.1.1.

I am not convinced about that part in all cases.

> This means:
> - Every module will be compatible always only with the exact version.
> - External modules needs rebuilds for every update of a image package.
> 
> We already say: You need to reboot after kernel upgrade, because the ABI
> only provides compatibility from older modules to newer kernels.  This
> would be now enforced by complete lack of compatibility.
>...

It is under our control when to not rename the packages,
to prevent this issue for production systems.

A binNMU for a perl transition might reach testing users,
but these should not be production systems.

When it takes 3 attempts in *stable-pu to get the kernel to build on all 
release architectures, only the last one will ever reach *stable.

A policy question is that it might be a good idea to rename the packages 
when publishing a regression update for a DSA, that's the only place I see
where this problem might otherwise reach production systems.

> Regards,
> Bastian

cu
Adrian

Re: Debian Kernel version and ABI in respect of #1040901

[Adrian Bunk]

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
>...
> ### NMU
> 
> Can be easily added back by adding "bX" or so to the ABI.

That would be confusing, bX is naming convention for binNMUs in Debian 
revisions.

> ### BinNMU
> 
> Is impossible to support.  The version change requires changes in the
> names of the created packages.
>...

It should only be impossible to make them co-installable,
or what other reason requires a rename?

cu
Adrian

firmware-nonfree: XS-Autobuild whitelisting might need updating for non-free-firmware

[Adrian Bunk]

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#marking-non-free-packages-as-auto-buildable
https://buildd.debian.org/status/logs.php?pkg=firmware-nonfree=all
https://buildd.debian.org/status/package.php?p=firmware-nonfree

"Section: contrib/misc" at the latter URL looks very wrong,
something likely needs updating on the buildd side for
XS-Autobuild of packages whose override has been changed
from non-free to non-free-firmware.

cu
Adrian

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Sun, Jul 17, 2022 at 09:02:23PM +0200, Moritz Mühlenhoff wrote:
>...
> but the quickly vaninishing
> upstream support for i386 and the lack of active porters make i386
> problematic from the Security Team's point of view.
>
> For packages where new upstream releases are being introduced
> this makes it extra brittle: Firefox/buster fails to compile due
> to toolchain issues (triggers an ICE in GCC) for almost a year
> now (since the update to ESR91)

If anyone ever told me about it I must have missed or forgotten it.
I often follow build failures at https://buildd.debian.org/ nearly in 
realtime, but AFAIK I cannot access logs from security.

I am counting 2 architectures with ESR 91 in buster and 8 architectures 
without ESR 91 inb buster, so presenting this as an i386 problem also 
sounds a bit strange.

>...
> But there are also issues in software not following new upstream
> releases in stable, e.g. #1006935 or 1009855 which broke Samba
> in stable.
>...

AFAIR this was a random failure based on the order of hashes that could 
have happened on any architecture.

> and for Chromium there have
> also been random build failures (e.g. #1011096) and for Chromium
> current releases no longer officially i386, quoting from the
> chromium 102.0.5005.115-1 changelog entry:
> 
> | - debianization/support-i386.patch - re-enable support for i386 builds.
> | Upstream no longer officially supports i386 builds on linux, so we
> | are on our own here.
> 
> Essentially that means that noone can expect to have consistent security
> updates when running i386 for the two main browsers.

i386 is the only 32bit architecture where the upcoming Firefox ESR 
will build on all buildds.

armhf might be mitigatable on the wanna-build side by restricting it
to some specific buildds:
  https://sources.debian.org/src/firefox/102.0.1-3/debian/rules/#L236

> These two specific issues could very well be addressed by dropping
> i386 from the archs for Firefox/Thunderbird/Chromium,

I doubt security supporting these on any 32bit architecture in bookworm 
is feasible.

> but Chromium also spreads into the Qt web packages.

I didn't know that you will provide security support for these in bookworm.
Whatever you suggest for i386 also has to be done for armhf,
reducing the architecture list of the QtWebEngine packages is
an option since they were never built on all architectures.

>...
> Cheers,
> Moritz

cu
Adrian

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Sun, Jul 17, 2022 at 02:02:34PM +0200, Ben Hutchings wrote:
> On Sat, 2022-07-16 at 18:03 +0300, Adrian Bunk wrote:
>...
> > What problem is building i386 bookworm kernel binaries causing for you 
> > that are not present on other architectures like armhf or s390x?
> 
> Good question.  I think the problem is that those i386 binaries will
> mostly work on 64-bit PCs and users will wrongly expect that they are
> fully supported.  But various features aren't implemented (in the
> kernel) or aren't available (architecturally) to a 32-bit kernel on a
> 64-bit CPU.
> 
> I suppose this can be mostly dealt with by sticking warnings around the
> place:
> 
> - Installation manual for i386
> - Release notes for i386
> - Package installation (debconf)
> - Kernel boot (log and taint flag)

We are in full agreement that hardware that can run a 64-bit kernel 
should not use a 32-bit kernel.

"mostly work" also applies to i386 userspace that is also slowly 
crumbling away, I assume noone will disagree that amd64 userspace
should be the preferred option when running a 64-bit kernel
(but crossgrading might be problematic).

Raising awareness for these is good.

> Ben.

cu
Adrian

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Sat, Jul 16, 2022 at 03:54:21PM +0200, Ben Hutchings wrote:
> On Sat, 2022-07-16 at 06:23 +0300, Adrian Bunk wrote:
> > On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote:
>...
> > This is not limited to i386, it is also quite relevant for embedded arm
> > where new products using 32-bit cpus are still being developed today.
> 
> New products can build user-space with 64-bit time_t.  They don't have
> Debian's ABI constraints.
>...

Many people want to use Debian in embedded, and there are people
who would like to have a Debian release architecture that is armhf
with 64-bit time_t.

Not sure whether anyone will actually do the effort, but this is the 
most likely 32-bit release architecture we will still have after 2038.

> > > This is not to say that i386, or 32-bit architectures, should be
> > > dropped as a whole.  We've supported installing a 64-bit kernel on i386
> > > since etch, though it now requires adding amd64 as a foreign
> > > architecture.  I do think that at some time soon we should stop
> > > releasing kernel binaries or an installer for i386.
> > 
> > Speaking with my i386 porter head on, I would rather ask for moving i386 
> > to ports than dropping all support for i386 hardware.
> 
> I think we have the following use cases for i386 now:
> 
> 1. PCs with 64-bit CPUs, with i386 as the primary Debian architecture.
>This might be the result of keeping an i386 installation through
>hardware upgrades.
> 2. PCs with 64-bit CPUs, that need to run i386 binaries that can't be
>rebuilt for amd64 (proprietary, or unportable).  They might have
>either amd64 or i386 as the primary Debian architecture.
> 3. PCs with 32-bit CPUs.
> 
> Moving i386 to ports would clearly serve use case 3 better than
> dropping the kernel and installer.  Keeping i386 as a release
> architecture, but without a kernel and installer, seems to serve use
> cases 1 and 2 better.
> 
> What's not clear is how many users fall into each of these use cases.
>...

What problem is building i386 bookworm kernel binaries causing for you 
that are not present on other architectures like armhf or s390x?

> Ben.

cu
Adrian

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Wed, Jun 22, 2022 at 10:05:37AM +0200, Graham Inggs wrote:
>...
> List of concerns for architectures
> ==
>...
>  * Concern for mips64el and mipsel: builders are extremely slow.
>(Raised by kernel team; carried over from bullseye)
>...

This was mitigated with
https://lists.debian.org/debian-release/2020/11/msg00093.html

It might be possible to further trim worst-case build time by 
restricting src:linux builds to the 5 fastest buildds.
(I am not a mips porter)

> On behalf of the release team,
> Graham Inggs
>...

cu
Adrian

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote:
> 
> For i386, I have some concerns about upstream support of the Linux
> kernel.  CPU security mitigations for x86 are concentrated on amd64,
> with i386 being left behind.  Mitigation of Meltdown required a
> different implementation for i386 that was completed months after the
> public disclosure and was never backported to stable branches.  More
> recently it became clear that mitigation of RETbleed was never tested
> on i386, since it didn't even compile there.

What is the status of RETbleed mitigation on other architectures like arm64?

> More generally, on 32-bit systems Linux can only directly access about
> 1 GiB of RAM, and support for large amounts of additional RAM (highmem)
> has been steadily regressing.  This is not likely to be fixed.

Support for 32-bit systems is slowly crumbling away, and the effort that 
would be required for the year 2038 problem will likely kill most/all of
them in a few years.

The relevant question is rather whether a point is already reached right 
now where we can no longer support an architecture as release architecture.

This is not limited to i386, it is also quite relevant for embedded arm
where new products using 32-bit cpus are still being developed today.

> This is not to say that i386, or 32-bit architectures, should be
> dropped as a whole.  We've supported installing a 64-bit kernel on i386
> since etch, though it now requires adding amd64 as a foreign
> architecture.  I do think that at some time soon we should stop
> releasing kernel binaries or an installer for i386.

Speaking with my i386 porter head on, I would rather ask for moving i386 
to ports than dropping all support for i386 hardware.

> (If we don't make that change for bookworm, then we should probably
> strongly encourage users to use 64-bit kernels on 64-bit capable
> hardware, and document how to install a foreign kernel package.)

Such users should also migrate to 64-bit userspace.

> Ben.

cu
Adrian

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adrian Bunk]

On Fri, Jul 10, 2020 at 06:13:58PM +0100, Ben Hutchings wrote:
> I don't know if this should be a blocker, but the MIPS builders are
> still extremely slow for kernel builds.  In the worst case (mipsel:
> mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
> than the next slowest group of builders (armhf: hasse, henze, holby).
> This can be a problem for getting security updates out promptly.

12:32 < aurel32> starting now, eberlin, mipsel-aql-01 and mipsel-aql-02 
 do not build security anymore

(The 7 faster buildds continue to build security.)

> Ben.

cu
Adrian

Re: Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[Adrian Bunk]

Control: clone -1 -2
Control: reassign -2 src:linux 4.19.118-1
Control: found -2 5.4.6-1
Control: notforwarded -2
Control: severity -2 serious
Control: retitle -2 Please revert CONFIG_MIPS_O32_FP64_SUPPORT change

On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote:
> On 2020-05-28 09:04, YunQiang Su wrote:
> > Adrian Bunk  于2020年5月21日周四 下午3:40写道：
> > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > > > Adrian Bunk  于2020年5月21日周四 上午4:44写道：
> > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > > > >
> > > > > > FTR, after giving back golang-1.14 mipsel several times, it's 
> > > > > > finally
> > > > > > built, by a longson builder.
> > > > > > So I guess it only occurs on octeon. Since the porterbox eller is 
> > > > > > also
> > > > > > octeon, it also can't build any go program.
> > > > >
> > > > > On eller golang-1.14 fails to build both in sid and buster chroots.
> > > > >
> > > > > golang-1.11 also fails to build in a buster chroot with floating point
> > > > > test errors.
> > > > >
> > > > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > > > >
> > > > > The only kernel configuration change on eller in the buster point
> > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
> > > > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> > > >
> > > > It is just support O32_FP64. I don't expect it will have any effect.
> > > > Since currently, the toolchain/libraries are all FPXX.
> > >
> > > Only the gcc/binutils toolchain/libraries or also the Go toolchain?
> > 
> > you are right. the current golang still output FP32 object...
> > So, we think that it is buggy.
> > 
> > Since Loongson CPU has some strange behaviour, it even can work...
> > Let's try to patch golang to support FPXX or FP64.
> > 
> > https://github.com/golang/go/issues/39289
> 
> That's probably a solution for bullseye/sid, however we can't backport
> such changes and rebuild the go world in buster. I therefore think that
> for buster the kernel change has to be reverted.

What is clear at this point is that the kernel change should be reverted
in buster since it causes a regression (including build failures on 
buildds). I am cloning this bug for a revert in the kernel of
https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826

I am marking the version in bullseye as found since we might run into 
the same problem again when buster DSAs will be built on machines 
running the bullseye kernel after the release of bullseye. It might be 
possible to mitigate this problem (e.g. in the kernel or by keeping some 
buildd running with the buster kernel), but without an open bug this 
issue might get forgotten and then resurface after the bullseye release.

> Aurelien

cu
Adrian

Bug#961965: ethtool: Please change to Architecture: linux-any

[Adrian Bunk]

Source: ethtool
Version: 1:5.4-1
Severity: important

ethtool is linux specific.

Currently this is implemented in Packages-arch-specific,
but Packages-arch-specific is obsolete and will go away.

Please change the architecture in debian/control to
  Architecture: linux-any

Bug#922478: have yet to find an armhf board that works with 4.9.144-3

[Adrian Bunk]

On Sun, Feb 17, 2019 at 09:52:48AM -0800, Vagrant Cascadian wrote:
> After upgrading to the latest 4.9.x kernel in sid, all of the armhf
> boards running this kernel failed to boot.
> 
> Adding to the list:
> 
> imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad
> exynos5: Odroid-XU4
> exynos4: Odroid-U3
> rk3328: firefly-rk3288
> sunxi A20: Cubietruck
> 
> 
> So it clearly impacts a wide variety of systems...

debian/patches/debian/arm-avoid-abi-change-in-4.9.139.patch changes
the order of struct processor but lacks a corresponding change to 
arch/arm/mm/proc-macros.S

> live well,
>   vagrant

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#915995: nfs-utils FTBFS with glibc 2.28

[Adrian Bunk]

Source: nfs-utils
Version: 1:1.3.4-2.3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nfs-utils.html

...
device-discovery.c: In function 'bl_add_disk':
device-discovery.c:156:28: warning: implicit declaration of function 'major' 
[-Wimplicit-function-declaration]
  } else if (dm_is_dm_major(major(dev)))
^
...
libtool: link: gcc -Wall -Wextra -Wstrict-prototypes -pipe 
-D_LARGEFILE64_SOURCE -g -Wall -DPIPEFS_DIR=\"/run/rpc_pipefs\" 
-DGSSD_PIPEFS_DIR=\"/run/rpc_pipefs\" -O2 -Wl,-z -Wl,relro -o blkmapd 
device-discovery.o device-inq.o device-process.o dm-device.o  -ldevmapper 
../../support/nfs/libnfs.a
/usr/bin/ld: device-discovery.o: in function `bl_add_disk':
/build/1st/nfs-utils-1.3.4/utils/blkmapd/device-discovery.c:156: undefined 
reference to `major'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:506: blkmapd] Error 1

Re: Bug#912411: Cgroup memory subsystem memory leak

[Adrian Bunk]

reassign 912411 src:linux 4.9.110-3+deb9u2~deb8u1
thanks

On Wed, Oct 31, 2018 at 05:21:39PM +0800, 段熊春 wrote:
> Package: linux-image-4.9.0-0.bpo.7-amd64
> Version: 4.9.110-3+deb9u2~deb8u1
> 
> Package: systemd
> Version: 230-7~bpo8+2
> 
> hi guys：
> We suspect that we may have found a memory leak bug in cgroup memory 
> subsystem, with 1GBytes/Hour leak speed for a special case.
> This bug could be reproduced 100% on the mainstream kernel version 4.19.   
> (Tried on Debian's latest kernel 4.14 and 4.9, the same result.)
> 
> This is what we have observed (Debian 9 Stretch, with mainstream kernel 
> version 4.19, kconfig attached) and how to reprocude:
> System with Cgroup enabled. A demo service which simulates an "ill" behavior: 
> program broken, and exit immediately after just startup:
> 
> service code
> #include "stdio.h"
> #include "stdlib.h"
> int main()
> {
>  void * p = malloc(10240);
>  return 1;
> }
> Compile the above code and put the binary as /usr/bin/test 
> systemd service
> [Service]
> ExecStart=/usr/bin/test
> Restart=always
> RestartSec=2s
> MemoryLimit=1G
> StartLimitInterval=0
> [Install]
> WantedBy=default.target
> Enable and start the above service with the tool systemctl.
> 
> Some additional information：
> With strace attach to systemd before start the service: systemd will mkdir 
> under /sys/fs/cgroup/memory for that service(/usr/bin/test). After the 
> service stops, rmdir will remove the correspond entry under 
> /sys/fs/cgrou/memory
> With kprobe hook to cgroup_mkdir and cgroup_rmdir: the number of call 
> cgroup_mkdir and cgroup_rmdir are equally.
> With kprobe hook to (1)mem_cgroup_css_alloc (2)mem_cgroup_css_free 
> (3)mem_cgroup_css_released (4)mem_cgroup_css_offline:
> the invoke number of mem_cgroup_css_alloc and mem_cgroup_css_offline are 
> equally  (Assume the number is A)
> the invoke number of alloc mem_cgroup_css_free and mem_cgroup_css_released 
> are equally (Assume the number is B)
> A > B
> With jprobe: we have collected some addresses of memcg. With the crash tool, 
> inspect the living kernel: the member named refcnt's flag in the memcg->css 
> is change to __PERCPU_REF_ATOMIC_DEAD. memcg->css->refcnt->count  keeps 
> the same value as memcg->memory->count.  After 24 hours, we observed the data 
> structure is still in use, and the value of the two count both are 1.
> we wrote a kmod to put a memcg which counter is 1, nothing happen except this 
> struct has been free
> We suspect the issue maybe caused by incorrect call to  try_charge and 
> cancel_charge. Anyway, just guess.
> Following is some inspection code we used as described above:
> kprobe code
> #include https://wiki.bytedance.net/pages/kernel.h>>
> #include https://wiki.bytedance.net/pages/module.h>>
> #include https://wiki.bytedance.net/pages/kprobes.h>>
>  
>  
> static struct kprobe mmalloc = {
> .symbol_name= "mem_cgroup_css_alloc",
> };
>  
> static struct kprobe mmrealse = {
> .symbol_name= "mem_cgroup_css_free",
> };
> static struct kprobe mmmkdir = {
> .symbol_name= "mem_cgroup_css_released",
> };
> static struct kprobe mmrmdir = {
> .symbol_name= "mem_cgroup_css_offline",
> };
> atomic_t alloc;
> atomic_t realse;
> atomic_t cmkdir;
> atomic_t crmdir;
>  
>  
> static int handler_alloc_pre(struct kprobe *p, struct pt_regs *regs)
> {
> atomic_inc();
> printk(KERN_INFO "alloc release %d offline %d alloc %d free 
> %d\n",atomic_read(),atomic_read(),atomic_read(),atomic_read());
> return 0;
> }
> static int handler_realse_pre(struct kprobe *p,struct pt_regs *regs)
> {
>atomic_inc();
> printk(KERN_INFO "free release %d offline %d alloc %d free 
> %d\n",atomic_read(),atomic_read(),atomic_read(),atomic_read());
> return 0;
> }
> static int handler_mkdir_pre(struct kprobe *p,struct pt_regs *regs)
> {
>atomic_inc();
> printk(KERN_INFO "release release %d offline %d alloc %d free 
> %d\n",atomic_read(),atomic_read(),atomic_read(),atomic_read());
> return 0;
> }
> static int handler_rmdir_pre(struct kprobe *p,struct pt_regs *regs)
> {
>atomic_inc();
> printk(KERN_INFO "offline release %d offline %d alloc %d free 
> %d\n",atomic_read(),atomic_read(),atomic_read(),atomic_read());
> return 0;
> }
>  
>  
> static void handler_post(struct kprobe *p, struct pt_regs *regs,
> unsigned long flags)
> {
> }
>  
>  
> static int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
> {
> return 0;
> }
>  
> static int __init kprobe_init(void)
> {
> int ret;
> mmalloc.pre_handler 
>  = handler_alloc_pre;
> mmalloc.post_handler 
>  = handler_post;
> mmalloc.fault_handler 
>  = handler_fault;
>  
> mmrealse.pre_handler 
>  = handler_realse_pre;
> 

Re: Bug#909852: linux-image-4.18-0-0.bpo.1-amd64: backtrace in dmesg after suspend

[Adrian Bunk]

reassign 909852 src:linux
thanks

On Sat, Sep 29, 2018 at 05:36:15PM +0200, m.alfa...@gmail.com wrote:
> Package: linux-image-4.18-0-0.bpo.1-amd64
> Version: linux-image-4.18.0-0.bpo.1-amd64
> Severity: minor
> 
> Dear Maintainer,
> 
> Today i tried a suspend on my system and it resulted in backtrace in dmesg,
> but system was not affected by this. According the backtrace it was some
> trouble with amdgpu. I'we tried few times again but the backtrace did not
> appear again without rebooting the system. I dont know yet what triggered 
> this.
> I attaching a file with information from dmesg.
> 
> Thank you for your time
> 
> I hope this helps improve debians stability.
> -- System Information:
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

> 2018-09-29T14:22:10.192483+02:00 debian kernel: [ 9243.482562] PM: suspend 
> entry (deep)
> 2018-09-29T14:22:20.898486+02:00 debian kernel: [ 9243.482565] PM: Syncing 
> filesystems ... done.
> 2018-09-29T14:22:20.898568+02:00 debian kernel: [ 9243.527463] Freezing user 
> space processes ... (elapsed 0.002 seconds) done.
> 2018-09-29T14:22:20.898571+02:00 debian kernel: [ 9243.530090] OOM killer 
> disabled.
> 2018-09-29T14:22:20.898573+02:00 debian kernel: [ 9243.530092] Freezing 
> remaining freezable tasks ... (elapsed 0.002 seconds) done.
> 2018-09-29T14:22:20.898573+02:00 debian kernel: [ 9243.532308] Suspending 
> console(s) (use no_console_suspend to debug)
> 2018-09-29T14:22:20.898574+02:00 debian kernel: [ 9243.553250] sd 1:0:0:0: 
> [sda] Synchronizing SCSI cache
> 2018-09-29T14:22:20.898592+02:00 debian kernel: [ 9243.553251] sd 2:0:0:0: 
> [sdb] Synchronizing SCSI cache
> 2018-09-29T14:22:20.898593+02:00 debian kernel: [ 9243.553483] sd 2:0:0:0: 
> [sdb] Stopping disk
> 2018-09-29T14:22:20.898594+02:00 debian kernel: [ 9243.575594] sd 1:0:0:0: 
> [sda] Stopping disk
> 2018-09-29T14:22:20.898595+02:00 debian kernel: [ 9243.707832] amdgpu 
> :00:01.0: 83582941 unpin not necessary
> 2018-09-29T14:22:20.898596+02:00 debian kernel: [ 9244.333090] 
> pci_raw_set_power_state: 5 callbacks suppressed
> 2018-09-29T14:22:20.898597+02:00 debian kernel: [ 9244.333095] snd_hda_intel 
> :00:09.2: Refused to change power state, currently in D0
> 2018-09-29T14:22:20.898598+02:00 debian kernel: [ 9244.393115] ACPI: 
> Preparing to enter system sleep state S3
> 2018-09-29T14:22:20.898599+02:00 debian kernel: [ 9244.707658] PM: Saving 
> platform NVS memory
> 2018-09-29T14:22:20.898600+02:00 debian kernel: [ 9244.707748] Disabling 
> non-boot CPUs ...
> 2018-09-29T14:22:20.898600+02:00 debian kernel: [ 9244.721578] IRQ 26: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898601+02:00 debian kernel: [ 9244.721589] IRQ 37: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898602+02:00 debian kernel: [ 9244.721593] IRQ 38: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898603+02:00 debian kernel: [ 9244.721598] IRQ 40: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898603+02:00 debian kernel: [ 9244.721603] IRQ 42: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898604+02:00 debian kernel: [ 9244.721609] IRQ 43: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898605+02:00 debian kernel: [ 9244.721613] IRQ 44: no 
> longer affine to CPU1
> 2018-09-29T14:22:20.898605+02:00 debian kernel: [ 9244.722702] smpboot: CPU 1 
> is now offline
> 2018-09-29T14:22:20.898606+02:00 debian kernel: [ 9244.745468] IRQ 19: no 
> longer affine to CPU2
> 2018-09-29T14:22:20.898607+02:00 debian kernel: [ 9244.745509] IRQ 52: no 
> longer affine to CPU2
> 2018-09-29T14:22:20.898607+02:00 debian kernel: [ 9244.746527] smpboot: CPU 2 
> is now offline
> 2018-09-29T14:22:20.898608+02:00 debian kernel: [ 9244.769420] IRQ 1: no 
> longer affine to CPU3
> 2018-09-29T14:22:20.898609+02:00 debian kernel: [ 9244.770494] smpboot: CPU 3 
> is now offline
> 2018-09-29T14:22:20.898609+02:00 debian kernel: [ 9244.771422] ACPI: 
> Low-level resume complete
> 2018-09-29T14:22:20.898610+02:00 debian kernel: [ 9244.771457] PM: Restoring 
> platform NVS memory
> 2018-09-29T14:22:20.898611+02:00 debian kernel: [ 9244.771540] LVT offset 0 
> assigned for vector 0x400
> 2018-09-29T14:22:20.898611+02:00 debian kernel: [ 9244.771756] Enabling 
> non-boot CPUs ...
> 2018-09-29T14:22:20.898612+02:00 debian kernel: [ 9244.771796] x86: Booting 
> SMP configuration:
> 2018-09-29T14:22:20.898613+02:00 debian kernel: [ 9244.771797] smpboot: 
> Booting Node 0 Processor 1 APIC 0x11
> 2018-09-29T14:22:20.898614+02:00 debian kernel: [ 9244.774098]  cache: parent 
> cpu1 should not be sleeping
> 2018-09-29T14:22:20.898615+02:00 debian kernel: [ 9244.774169] microcode: 
> CPU1: patch_level=0x06006118

Bug#906769: arm kernels fail to boot

[Adrian Bunk]

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y=6bb53ee170c45f44ac80ad8318f72feff9cdee1b

We don't have that commit, and this explains why 
cpu-hotplug-boot-ht-siblings-at-least-once.patch broke ARM.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Fixing Linux getrandom() in stable

[Adrian Bunk]

On Mon, May 14, 2018 at 03:11:30AM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote:
>...
> > Due to the gdm bugs mentioned above we know that there are real-life 
> > situations where gdm currently uses "random" data that might be 
> > predictable.
> > 
> > grep tells me:
> > daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes 
> > (auth_entry.data_length, );
> > daemon/gdm-display-access-file.c:*cookie = 
> > gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE,
> > 
> > Repeat the same for every package that uses /dev/urandom.
> 
> This is certain undesirable, but it's exploitable only by local users. 
> (If you let the X server listen to the network, all authentication
> cookies are sent in the clear so you've already lost.  If you use ssh X
> forwarding, it generates a new authentication cookie for use with the X
> proxy on the remote machine.)

It is possible that this specific case is not a problem.

There was a certain "never use /dev/random, /dev/urandom is always good
enough" push that started several years before getrandom() became 
available, and I'd bet someone will find exploitable cases due to
that somewhere.

The documented behaviour is that it is safe to use /dev/urandom except
during "early boot", and this is not always true in practice.

>...
> > The proper way forward might be to deprecate /dev/urandom and add a 
> > third option GRND_UNSAFE_RANDOM to getrandom() that is documented to 
> > never block but might return predictable data in some cases.
> 
> This doesn't solve anything for us.  (It does help with the original
> problem of device nodes possibly being absent from a minimal container
> or chroot.)
>...

I am less worried about device nodes possibly being absent, and more 
worried about 3 different cases splintered over 2 completely different
APIs.

Ignoring any security implications, "workaround by switching from 
getrandom() to /dev/urandom" sounds wrong since you shouldn't be
forced to a different API for that - getrandom() is what people
should use, therefore it should offer all 3 options.

> Ben.
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Fixing Linux getrandom() in stable

[Adrian Bunk]

On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote:
>...
> # Security flaw and initial fix
> 
> Recently it was discovered that getrandom() could return successfully
> before the RNG was really ready to produce unpredictable data.  This
> issue was designated as CVE-2018-1108, and was fixed in Linux 4.17-rc2 
> and various stable updates.
> 
> We fixed CVE-2018-1108 with an update to stretch last week
> (DSA-4188-1).  The kernel versions in wheezy and jessie do not provide
> getrandom().
> 
> # Regression
> 
> The version of glibc in stretch does not provide access to getrandom(),
> but some packages in stable use syscall() to call it anyway, including:
> 
> * krb5: k5_get_os_entropy()
> * libbsd: arc4_random_buf().  This is used by many other packages
>   including libICE, and so indirectly by gnome-session.
> 
> Following DSA-4188-1, it turned out that the RNG did not become ready
> on some systems until several minutes after boot, causing severe
> regressions for GNOME/gdm (#897631, #897632) and Kerberos (#897599,
> #897917).  We therefore reverted the fix in yesterday's update
> (DSA-4196-1).
> 
> # Options for a new fix
> 
> It is unlikely that any further fix will be forthcoming on the kernel
> side, so I believe that we need to do one of:
> 
> 1. Add entropy to the kernel during boot; either:
>a. Improve systemd-random-seed
>b. Recommend use of haveged

I don't see any solution above that both always works and never results
in new CVEs.

As an example, what happens if I debootstrap and deploy the resulting
filesytem to a large number of identical embedded systems without
entropy sources?

As far as I can see, any solution above would either give me boot hangs
or might result in nasty security issues due to the same (known) entropy
being fed to /dev/random on many machines.

Similar problems for cases like live CDs and installers.

> 2. For each affected userland package, either:
>a. Revert to using /dev/urandom

I wonder whether the current issue is just the tip of the iceberg,
and usage of /dev/urandom is a gazillion CVEs waiting to be reported.

In that case the CVE-2018-1108 fix only revealed a long existing 
vulnerability in some packages that already switched to getrandom().

/dev/urandom is documented in a very misleading way, quoting random(4):
   When read during early boot time, /dev/urandom may return data prior to
   the entropy pool being initialized.  If this  is  of  concern  in  your
   application, use getrandom(2) or /dev/random instead.

What is the worst case for "early boot time" here? "always"?

Due to the gdm bugs mentioned above we know that there are real-life 
situations where gdm currently uses "random" data that might be 
predictable.

grep tells me:
daemon/gdm-x-session.c:auth_entry.data = gdm_generate_random_bytes 
(auth_entry.data_length, );
daemon/gdm-display-access-file.c:*cookie = gdm_generate_random_bytes 
(GDM_DISPLAY_ACCESS_COOKIE_SIZE,

Repeat the same for every package that uses /dev/urandom.

>b. Tolerate a longer wait for getrandom() to return

I suspect there might be no guaranteed upper bound for the waiting time.

>...
> The libbsd maintainer (Guillem Jover) favours option 2a.
> 
> One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
> also proposed that systemd could provide a wait-for-rng-ready unit to
> support this.

I don't see any general solution that is both correct and easy.

The proper way forward might be to deprecate /dev/urandom and add a 
third option GRND_UNSAFE_RANDOM to getrandom() that is documented to 
never block but might return predictable data in some cases.

It would then be up to the application to decide whether predictable
data is acceptable, and what to do in entropy-starved situations.

Regarding the suggested wait-for-rng-ready systemd unit for others to 
wait on, this only makes sense for cases where "do not start at all"
is the best handling for a "no entropy" situation.

> Ben.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#893161: linux-image-4.9.0-6-amd64: Fix for suspend on amdgpu chipsets on Debian stable

[Adrian Bunk]

reassign 893161 src:linux 4.9.82-1+deb9u3
thanks

On Sat, Mar 17, 2018 at 12:07:54AM +0100, compo...@trash-mail.com wrote:
> Package: src:linuxVersion: 4.9.82-1+deb9u3Severity: importantDear 
> Maintainer,I tracked down an issue I've been having on my Debian Stable 
> machine with suspending. Other users reported it goes away when applying the 
> patchset found at: https://patchwork.kernel.org/patch/9489859/ Please back 
> port it to 4.9 when possible.TIA

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#891418: linux-image-4.9.0-6-amd64 external USB3 HDD not show SMART info

[Adrian Bunk]

reassign 891418 src:linux 4.9.0-6
thanks

On Sun, Feb 25, 2018 at 01:54:35PM +0100, Petr wrote:
> Package: linux-image-4.9.0-6-amd64
> Version: 4.9.0-6
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> after upgrade from linux-image-4.9.0-3-amd64 to linux-image-4.9.0-6-amd64 
> smartctl stop showing
> smart info from external USB3 disk (ST2000LM007-1R8174)
> 
> Downgrade to linux-image-4.9.0-3-amd64 fix problem.
> 
> 
>  smartctl --info /dev/sda
>  smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-3-amd64] (local
>  build)
>  Copyright (C) 2002-16, Bruce Allen, Christian Franke,
>  www.smartmontools.org
> 
>  === START OF INFORMATION SECTION ===
>  Device Model: ST2000LM007-1R8174
>  Serial Number:
>  LU WWN Device Id: 5 000c50 0ac7296cf
>  Firmware Version: SBK2
>  User Capacity:2 000 398 934 016 bytes [2,00 TB]
>  Sector Sizes: 512 bytes logical, 4096 bytes physical
>  Rotation Rate:5400 rpm
>  Form Factor:  2.5 inches
>  Device is:Not in smartctl database [for details use: -P
>  showall]
>  ATA Version is:   ACS-3 T13/2161-D revision 3b
>  SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
>  Local Time is:Sun Feb 25 13:50:39 2018 CET
>  SMART support is: Available - device has SMART capability.
>  SMART support is: Enabled
> 
> 
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to cs_CZ.UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to cs_CZ.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages linux-image-4.9.0-6-amd64 depends on:
> ii  initramfs-tools [linux-initramfs-tool]  0.130
> ii  kmod23-2
> ii  linux-base  4.5
> 
> Versions of packages linux-image-4.9.0-6-amd64 recommends:
> ii  firmware-linux-free  3.4
> ii  irqbalance   1.1.0-2.3
> 
> Versions of packages linux-image-4.9.0-6-amd64 suggests:
> pn  debian-kernel-handbook  
> ii  grub-pc 2.02~beta3-5
> pn  linux-doc-4.9   

Accepted nfs-utils 1:1.3.4-2.2 (source) into unstable

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Feb 2018 21:20:36 +0200
Source: nfs-utils
Binary: nfs-kernel-server nfs-common
Architecture: source
Version: 1:1.3.4-2.2
Distribution: unstable
Urgency: medium
Maintainer: Debian kernel team <debian-kernel@lists.debian.org>
Changed-By: Adrian Bunk <b...@debian.org>
Description:
 nfs-common - NFS support files common to client and server
 nfs-kernel-server - support for NFS kernel server
Closes: 887695
Changes:
 nfs-utils (1:1.3.4-2.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add upstream fix for FTBFS with glibc 2.26,
 thanks to Juhani Numminen. (Closes: #887695)
   * Update the build dependency from the obsolete dh-systemd.
   * Stop using bzip2 for source compression,
 the default xz compresses better.
Checksums-Sha1:
 805eba685e885fab92ffa72917fe759239c15b4d 2354 nfs-utils_1.3.4-2.2.dsc
 b44c09cfce18a11c7f6812e7a21b178ecf294796 42728 
nfs-utils_1.3.4-2.2.debian.tar.xz
Checksums-Sha256:
 62f438b607eeb18ca9e7e101b5fcac14d9fe1db762e552c165030dd421061c6a 2354 
nfs-utils_1.3.4-2.2.dsc
 f87317c69f53662b68f14ecc704455527796fb3353d6bfe885d94f7e28897d9d 42728 
nfs-utils_1.3.4-2.2.debian.tar.xz
Files:
 a97fcf1c61517803e2db1114e2e3af0d 2354 net standard nfs-utils_1.3.4-2.2.dsc
 311342d7804d2ca21b65d36180bd33c7 42728 net standard 
nfs-utils_1.3.4-2.2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlp6AR8ACgkQiNJCh6LY
mLElLg//W8agzDV47rx1ncPCbeCnbwnrViBtAm7owKd+lqhrUdsV/BeE5KwQcnXp
x0lPyc0ynfU3A7BEHBlGsZX2bMRLMnuAegjx3an3P9DQvrOIUnNQ8kS49jftd9Q4
O/C3XAndXg24A1BdyBqgRkdS/Bjbel/GGAKCO/fZ+iYao8f25hRdvzgYwHHSADv3
ebBcYbTD9PEuhAkojE2rsqGqNYvT/vGeF48r3lInWodY5wMcaP/4ZChET0J0sPYc
su3A9Io0QwtyO4KOLuwyfpULyuraoWGGNUBR+ot+7KYS5SPyo11cxiNafLAj4KPz
NUgsfjT3ae1RM8j9N+zTujPI1wyFlJJ00yzzRyUW+hR78hGKJ/2NKZSWByVwpNQs
PPLQpNwB2bGyFJ2rl7+7x4DU6QPatURvU6GZ+5gyxeSdj66ai4NFNCWVX/XfxVHW
tNmLCu2dSZH6WpTH+e93jNRiiZ4WVp3OsQHqEoE9FZ5AsEYERyxb3AUv4JulE35Q
DDvwyXP960JpRMejWkikBCnkW7Sl03meZaBubI82OcMBUVIkiHOFilmNWCEefI05
i3U7P2FztVYCqb2jCatsPB+IjrJtB3o5Bd7e8tUt67OB85F5+N66U9XKpqjW2bqv
20/+tgJIt2nhCbAwV1Iqan4SlFw5SvKHoaMMFSS4jKCiJWzUbs8=
=s9F6
-END PGP SIGNATURE-

Bug#887695: nfs-utils: diff for NMU version 1:1.3.4-2.2

[Adrian Bunk]

Control: tags 887695 + pending

Dear maintainer,

I've prepared an NMU for nfs-utils (versioned as 1:1.3.4-2.2) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru nfs-utils-1.3.4/debian/changelog nfs-utils-1.3.4/debian/changelog
--- nfs-utils-1.3.4/debian/changelog	2017-03-20 17:07:55.0 +0200
+++ nfs-utils-1.3.4/debian/changelog	2018-02-06 21:20:36.0 +0200
@@ -1,3 +1,14 @@
+nfs-utils (1:1.3.4-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with glibc 2.26,
+thanks to Juhani Numminen. (Closes: #887695)
+  * Update the build dependency from the obsolete dh-systemd.
+  * Stop using bzip2 for source compression,
+the default xz compresses better.
+
+ -- Adrian Bunk <b...@debian.org>  Tue, 06 Feb 2018 21:20:36 +0200
+
 nfs-utils (1:1.3.4-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nfs-utils-1.3.4/debian/control nfs-utils-1.3.4/debian/control
--- nfs-utils-1.3.4/debian/control	2016-12-15 15:30:00.0 +0200
+++ nfs-utils-1.3.4/debian/control	2018-02-06 21:20:36.0 +0200
@@ -3,7 +3,7 @@
 Section: net
 Maintainer: Debian kernel team <debian-kernel@lists.debian.org>
 Uploaders: Anibal Monsalve Salazar <ani...@debian.org>, Ben Hutchings <b...@decadent.org.uk>, Steve Langasek <vor...@debian.org>, Daniel Pocock <poc...@debian.org>
-Build-Depends: debhelper (>= 7), libwrap0-dev, libevent-dev, libnfsidmap-dev (>= 0.24), libkrb5-dev, libblkid-dev, libkeyutils-dev, pkg-config, libldap2-dev, libcap-dev, libtirpc-dev (>= 0.2.4-2~), libdevmapper-dev, dh-autoreconf, libmount-dev, libsqlite3-dev, dh-systemd
+Build-Depends: debhelper (>= 9.20160709), libwrap0-dev, libevent-dev, libnfsidmap-dev (>= 0.24), libkrb5-dev, libblkid-dev, libkeyutils-dev, pkg-config, libldap2-dev, libcap-dev, libtirpc-dev (>= 0.2.4-2~), libdevmapper-dev, dh-autoreconf, libmount-dev, libsqlite3-dev
 Standards-Version: 3.9.8
 Homepage: http://linux-nfs.org/
 Vcs-Git: git://anonscm.debian.org/collab-maint/nfs-utils.git
diff -Nru nfs-utils-1.3.4/debian/gbp.conf nfs-utils-1.3.4/debian/gbp.conf
--- nfs-utils-1.3.4/debian/gbp.conf	2016-12-15 15:30:00.0 +0200
+++ nfs-utils-1.3.4/debian/gbp.conf	2018-02-06 21:20:36.0 +0200
@@ -6,4 +6,3 @@
 # Options only affecting git-buildpackage
 [git-buildpackage]
 sign-tags = True
-compression = bzip2
diff -Nru nfs-utils-1.3.4/debian/patches/0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch nfs-utils-1.3.4/debian/patches/0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch
--- nfs-utils-1.3.4/debian/patches/0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch	1970-01-01 02:00:00.0 +0200
+++ nfs-utils-1.3.4/debian/patches/0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch	2018-02-06 21:19:05.0 +0200
@@ -0,0 +1,25 @@
+From ba03a02c2fd912f370e1f55de921a403bf5f9247 Mon Sep 17 00:00:00 2001
+From: Steve Dickson <ste...@redhat.com>
+Date: Thu, 22 Jun 2017 12:56:41 -0400
+Subject: rpc.c: added include file so UINT16_MAX is defined.
+
+Signed-off-by: Steve Dickson <ste...@redhat.com>
+---
+ support/nsm/rpc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/support/nsm/rpc.c b/support/nsm/rpc.c
+index 4e5f40e..0a8e56f 100644
+--- a/support/nsm/rpc.c
 b/support/nsm/rpc.c
+@@ -38,6 +38,7 @@
+ #include 
+ #include 
+ 
++#include 
+ #include 
+ #include 
+ #include 
+-- 
+2.11.0
+
diff -Nru nfs-utils-1.3.4/debian/patches/series nfs-utils-1.3.4/debian/patches/series
--- nfs-utils-1.3.4/debian/patches/series	2016-12-17 12:47:35.0 +0200
+++ nfs-utils-1.3.4/debian/patches/series	2018-02-06 21:20:34.0 +0200
@@ -10,3 +10,4 @@
 unbreak-gssd-rpc_pipefs-run.patch
 28-nfs-utils_env-location.patch
 29-start-statd-fd-9.patch
+0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch
diff -Nru nfs-utils-1.3.4/debian/source/options nfs-utils-1.3.4/debian/source/options
--- nfs-utils-1.3.4/debian/source/options	2016-12-15 15:30:00.0 +0200
+++ nfs-utils-1.3.4/debian/source/options	2018-02-06 21:20:36.0 +0200
@@ -1,3 +1 @@
-compression = "bzip2"
-compression-level = 9
 extend-diff-ignore = "(^|/)(config.sub|config.guess|Makefile.in|configure|config.log|aclocal.m4|ltmain.sh|aclocal/libtool.m4)$"

Bug#887695: nfs-utils FTBFS with glibc 2.26

[Adrian Bunk]

Source: nfs-utils
Version: 1:1.3.4-2.1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nfs-utils.html

...
rpc.c: In function 'nsm_recv_getport':
rpc.c:469:13: error: 'UINT16_MAX' undeclared (first use in this function); did 
you mean 'UINT_MAX'?
  if (port > UINT16_MAX) {
 ^~
 UINT_MAX
rpc.c:469:13: note: each undeclared identifier is reported only once for each 
function it appears in
rpc.c: In function 'nsm_recv_getaddr':
rpc.c:506:25: error: 'UINT16_MAX' undeclared (first use in this function); did 
you mean 'UINT_MAX'?
  if (port < 0 || port > UINT16_MAX) {
 ^~
 UINT_MAX

Regression in linux in jessie-proposed-updates

[Adrian Bunk]

Control: reassign -1 src:linux 3.16.48-1
Control: severity -1 grave

On Wed, Oct 11, 2017 at 08:45:14AM +, Cristiano Casella wrote:
> Package: linux-image
> 
> Version: 3.16.0-4-amd64_3.16.48-1_amd64.deb
> 
> 
> Hi,
> 
> we are an hosting provider and we are offering to our customers virtual 
> machine on Microsoft Hyper-v hypervisor.
> 
> 
> Upgrading our vm with Debian 8 (also just installed) to last version of 
> linux-image package (linux-image-3.16.0-4-amd64_3.16.48-1_amd64.deb) the 
> virtual machines can't boot anymore.
> 
> 
> I attached to this email the two kind of error that we can get in the console.
> 
> 
> Looking at the changelog 
> (https://tracker.debian.org/media/packages/l/linux/changelog-3.16.48-1) I 
> suspect that this changes could be involved in this bug:
> 
> 
> - [x86] scsi: storvsc: use tagged SRB requests if supported by the device
> - [x86] scsi: storvsc: Fix a bug in the handling of SRB status flags
> - [x86] scsi: storvsc: properly handle SRB_ERROR when sense message is
>   present
> - [x86] scsi: storvsc: properly set residual data length on errors
> 
> We can provide you all test environments needed or proceede with your support 
> for a kernel bisect to find the specific error.
> 
> 
> This bug potentially could brake all our customer virtual machines using a 
> Debian 8 on our hyper-v platform.

Thanks for your report.

I'm adjusting the severity and reassign the bug to the correct place,
to make people aware that this regression shouldn't enter the next 
point release.

> Thanks for your support
> 
> Cordiali Saluti / Best Regards
> 
> Cristiano Casella

Thanks for your report
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#872921: sp5100_tco: failed to find MMIO address, giving up

[Adrian Bunk]

reassign 872921 src:linux
thanks

On Tue, Aug 22, 2017 at 01:32:05PM +, Nicolas wrote:
> Package: linux-image
> Version: 4.9.0-3-amd64
> Hi, 
> 
> Using an APU2 from pcengines, and debian stretch (uptodate, x64), when I 
> blacklist the i2c_piix4 modules and load sp5100_tco for watchdog, I got :
> 
> [271024.543673] sp5100_tco: SP5100/SB800 TCO Watchdog Module Unloaded
> [271024.571313] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
> [271024.571654] sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x780b, 
> Revision ID: 0x42
> [271024.571682] sp5100_tco: failed to find MMIO address, giving up.
> 
> No /dev/watchdog (or /dev/watchdog0) is created.
> 
> Is it a bug? How can I help to debug?
> 
> Thanks

Re: Bug#872435: linux-image-3.16.0.4-amd64: kernel panic if second display is connected with intel graphic

[Adrian Bunk]

reassign 872435 src:linux
thanks

On Thu, Aug 17, 2017 at 02:12:46PM +0200, Lars Mucha wrote:
> Package: linux-image-3.16.0.4-amd64
> Version: linux-image-3.16.0-4-amd64
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> The computer contains an intel processor with 2 digital outputs. If I want to 
> use both outputs,
> the intel driver crashes. The second display stays blank, the display is 
> starting over and over.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Swapped the displays, same result. Tried different xorg-configurations, no 
> change.
> 
> Here is an extract from the kernel-log:
> Aug 17 11:20:06 panoma0438 kernel: [2.047125] [ cut here 
> ]
> Aug 17 11:20:06 panoma0438 kernel: [2.047160] WARNING: CPU: 0 PID: 233 at 
> /build/linux-ch53fA/linux-3.16.43/drivers/gpu/drm/i915/intel_display.c:1227 
> int
> el_crtc_enable_planes+0x4f/0x2f0 [i915]()
> Aug 17 11:20:06 panoma0438 kernel: [2.047161] pipe C assertion failure 
> (expected on, current off)
> Aug 17 11:20:06 panoma0438 kernel: [2.047184] Modules linked in: ecb 
> btusb bluetooth 6lowpan_iphc joydev hid_logitech_dj usbhid hid arc4 
> x86_pkg_temp_the
> rmal intel_powerclamp intel_rapl iwlmvm kvm_intel mac80211 kvm eeepc_wmi 
> iTCO_wdt asus_wmi iTCO_vendor_support sparse_keymap crc32_pclmul evdev cryptd 
> iwlwif
> i pcspkr serio_raw cfg80211 lpc_ich rfkill mfd_core wmi i915(+) tpm_infineon 
> battery tpm_tis drm_kms_helper tpm drm video shpchp mei_me i2c_algo_bit mei 
> butt
> on processor nct6775 hwmon_vid coretemp fuse autofs4 ext4 crc16 mbcache jbd2 
> dm_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul 
> crct10dif_common
> crc32c_intel psmouse r8169 mii fan thermal thermal_sys xhci_hcd ehci_pci 
> ehci_hcd i2c_i801 i2c_core usbcore usb_common ahci libahci ata_generic libata 
> scsi_m
> od
> Aug 17 11:20:06 panoma0438 kernel: [2.047186] CPU: 0 PID: 233 Comm: 
> systemd-udevd Not tainted 3.16.0-4-amd64 #1 Debian 3.16.43-2+deb8u2
> Aug 17 11:20:06 panoma0438 kernel: [2.047187] Hardware name: ASUS All 
> Series/H81T, BIOS 0807 04/29/2016
> Aug 17 11:20:06 panoma0438 kernel: [2.047188]   
> 81514281 880096e87518 0009
> Aug 17 11:20:06 panoma0438 kernel: [2.047189]  81068897 
> 880217162000 880096e87568 880217162000
> Aug 17 11:20:06 panoma0438 kernel: [2.047190]  880097d3 
> 0002 810688fc a03de6c0
> Aug 17 11:20:06 panoma0438 kernel: [2.047190] Call Trace:
> Aug 17 11:20:06 panoma0438 kernel: [2.047194]  [] ? 
> dump_stack+0x5d/0x78
> Aug 17 11:20:06 panoma0438 kernel: [2.047197]  [] ? 
> warn_slowpath_common+0x77/0x90
> Aug 17 11:20:06 panoma0438 kernel: [2.047198]  [] ? 
> warn_slowpath_fmt+0x4c/0x50
> Aug 17 11:20:06 panoma0438 kernel: [2.047220]  [] ? 
> assert_pipe+0x92/0xf0 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047237]  [] ? 
> intel_crtc_enable_planes+0x4f/0x2f0 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047252]  [] ? 
> hsw_write32+0x40/0x180 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047267]  [] ? 
> haswell_crtc_enable+0x49c/0xa20 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047283]  [] ? 
> intel_ddi_pll_enable+0xfc/0x250 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047297]  [] ? 
> __intel_set_mode+0x7d7/0x1560 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047311]  [] ? 
> intel_set_mode+0x12/0x30 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047324]  [] ? 
> intel_crtc_set_config+0x8cf/0xd50 [i915]
> Aug 17 11:20:06 panoma0438 kernel: [2.047329]  [] ? 
> drm_mode_set_config_internal+0x61/0xe0 [drm]
> Aug 17 11:20:06 panoma0438 kernel: [2.047332]  [] ? 
> restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
> Aug 17 11:20:06 panoma0438 kernel: [2.047334]  [] ? 
> drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x60 [drm_kms_helper]
> Aug 17 11:20:06 panoma0438 kernel: [2.047336]  [] ? 
> drm_fb_helper_set_par+0x1e/0x50 [drm_kms_helper]
> Aug 17 11:20:06 panoma0438 kernel: [2.047338]  [] ? 
> fbcon_init+0x4fa/0x580
> Aug 17 11:20:06 panoma0438 kernel: [2.047340]  [] ? 
> visual_init+0xb1/0x110
> Aug 17 11:20:06 panoma0438 kernel: [2.047341]  [] ? 
> do_bind_con_driver+0x15d/0x330
> Aug 17 11:20:06 panoma0438 kernel: [2.047343]  [] ? 
> do_take_over_console+0x103/0x1b0
> Aug 17 11:20:06 panoma0438 kernel: [2.047344]  [] ? 
> do_fbcon_takeover+0x5b/0xb0
> Aug 17 11:20:06 panoma0438 kernel: [2.047346]  [] ? 
> notifier_call_chain+0x4e/0x70
> Aug 17 11:20:06 panoma0438 kernel: [2.047347]  [] ? 
> __blocking_notifier_call_chain+0x47/0x60
> Aug 17 11:20:06 panoma0438 kernel: [2.047349]  [] ? 
> register_framebuffer+0x1e6/0x310
> Aug 17 11:20:06 panoma0438 kernel: [2.047351]  [] ? 
> drm_fb_helper_initial_config+0x2fe/0x4d0 [drm_kms_helper]
> Aug 17 11:20:06 panoma0438 kernel: [ 

Bug#867358: mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[Adrian Bunk]

On Sun, Jul 16, 2017 at 11:21:27PM +0100, Ben Hutchings wrote:
> On Thu, 2017-07-06 at 13:10 +0300, Adrian Bunk wrote:
> > Control: reassign -1 src:linux 4.9.30-2
> > Control: retitle -1 mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address
> > Control: affects -1 src:golang-github-pelletier-go-toml 
> > src:golang-github-nicksnyder-go-i18n gccgo-7
> > 
> > On Thu, Jul 06, 2017 at 02:11:00AM +0300, Adrian Bunk wrote:
> > > Source: golang-github-pelletier-go-toml
> > > Version: 1.0.0-1
> > > Severity: serious
> > > 
> > > https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid
> > > 
> > > ...
> > >    dh_auto_test -a -O--buildsystem=golang
> > >   go test -v -p 4 github.com/pelletier/go-toml 
> > > github.com/pelletier/go-toml/cmd 
> > > github.com/pelletier/go-toml/cmd/tomljson 
> > > github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
> > > go build github.com/davecgh/go-spew/spew: 
> > > /usr/bin/mips-linux-gnu-gccgo-7: waitid: bad address
> > > FAIL  github.com/pelletier/go-toml [build failed]
> > > ?     github.com/pelletier/go-toml/cmd[no test files]
> > > ...
> > 
> > James Cowgill told me that this is actually a kernel bug:
> >   https://www.linux-mips.org/archives/linux-mips/2017-03/msg00580.html
> 
> That's now a 404, strangely.  Did you mean "[PATCH 0/2] Fix indirect
> syscall handler for syscalls with > 4 args"?

Yes, the link pointed at
  [PATCH 2/2] MIPS: Remove pt_regs adjustments in indirect syscall handler

> Ben.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[Adrian Bunk]

Control: reassign -1 src:linux 4.9.30-2
Control: retitle -1 mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address
Control: affects -1 src:golang-github-pelletier-go-toml 
src:golang-github-nicksnyder-go-i18n gccgo-7

On Thu, Jul 06, 2017 at 02:11:00AM +0300, Adrian Bunk wrote:
> Source: golang-github-pelletier-go-toml
> Version: 1.0.0-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid
> 
> ...
>dh_auto_test -a -O--buildsystem=golang
>   go test -v -p 4 github.com/pelletier/go-toml 
> github.com/pelletier/go-toml/cmd github.com/pelletier/go-toml/cmd/tomljson 
> github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
> go build github.com/davecgh/go-spew/spew: /usr/bin/mips-linux-gnu-gccgo-7: 
> waitid: bad address
> FAIL  github.com/pelletier/go-toml [build failed]
> ? github.com/pelletier/go-toml/cmd[no test files]
> ...

James Cowgill told me that this is actually a kernel bug:
  https://www.linux-mips.org/archives/linux-mips/2017-03/msg00580.html

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#867011: linux 4.9.30-2+deb9u1 wifi problem

[Adrian Bunk]

reassign 867011 src:linux 4.9.30-2
thanks

On Mon, Jul 03, 2017 at 03:18:18PM +0300, Vadim Kolchev wrote:
> Package: linux 4.9.30-2+deb9u1
> 
> Hello,
> Since update to Debian 9 cannot connect to WiFi using rt28xxusb
> (particularly rt2870usb is loaded) driver.
> Network Manager cannot connect.
> If using wpa_supplicant from cli, it connects for 1-2 minutes and then
> disconnects.
> On out-of-the-box Debian 9 kernel there is no such problem.
> 
> Please fix it ASAP, as many users here have wireless access and those
> dongles only.

The radvd FTBFS fix is not required for stretch

[Adrian Bunk]

Control: tags -1 sid

linux-libc-dev 4.9.30-2 reverted the headers change that caused the 
radvd FTBFS, so there does not seem to be a real need to get that fixed 
in a stretch point release (but it should still be fixed in unstable).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#862892: linux-signed FTBFS in stretch: Build-depends on linux packages no longer in stretch

[Adrian Bunk]

Source: linux-signed
Version: 4.4
Severity: serious

linux-signed has build dependencies on the exact version 4.9.18-1
of packages from src:linux, but version 4.9.25-1 is now in stretch.

Kernel packages need Breaks on older virtualbox-dkms versions

[Adrian Bunk]

Control: reopen -1
Control: reassign -1 src:linux 4.7.2-1
Control: retitle -1 Kernel packages need Breaks on older virtualbox-dkms 
versions

> From: Gianfranco Costamagna 
> To: Karl Voit , 849633-d...@bugs.debian.org
> Subject: Re: Bug#849633: virtualbox-dkms: Compiling error when updating
>  kernel
> 
> Hello,
> 
> >Version: 4.3.36-dfsg-1+deb8u1
> >Severity: grave
> >Justification: renders package unusable
> >
> >Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> 
> kernel from backports, vbox from stable.
> use vbox from backports or here instead:
> http://debomatic-amd64.debian.net/distribution#jessie-backports/virtualbox/5.1.12-dfsg-2~bpo8+1/buildlog

The bug is that the the kernel images do not have appropriate Breaks to 
enforce upgrade/removal of the old virtualbox-dkms package.

> G.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#848851: linux: FTBFS on ppc64el

[Adrian Bunk]

On Tue, Dec 20, 2016 at 08:57:55AM +0100, Salvatore Bonaccorso wrote:
> Source: linux
> Version: 4.8.15-1
> Severity: serious
> Justification: FTBFS
> 
> Hi
> 
> src:linux 4.8.15-1 FTBFS on ppc64el.
> 
> Log: 
> https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64el=4.8.15-1=1482184049
> 
> [...]
>   CC  crypto/af_alg.mod.o
>   CC  crypto/algif_aead.mod.o
> ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, 
> try linking with -N
> ld: final link failed: Bad value
> /«PKGBUILDDIR»/arch/powerpc/boot/Makefile:323: recipe for target 
> 'arch/powerpc/boot/zImage.pseries' failed
> make[6]: *** [arch/powerpc/boot/zImage.pseries] Error 1
> make[6]: *** Waiting for unfinished jobs
>   CC  crypto/algif_hash.mod.o
> arch/powerpc/Makefile:285: recipe for target 'zImage' failed
> make[5]: *** [zImage] Error 2
> make[5]: *** Waiting for unfinished jobs
>   CC  crypto/algif_skcipher.mod.o
> [...]

I'd assume this is also a duplicate of #848798, but I am less sure about 
that than for #848850 (which I already merged with the binutils bug).

> Regards,
> Salvatore

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#847779: omap2-nand not auto-loaded on gta04

[Adrian Bunk]

control: reassign 847779 linux-image-4.9.0-rc8-armmp-unsigned 4.9~rc8-1~exp1

There were some linebreaks the bug tracking system was not happy with,
reassign it to the intended package.

On Sun, Dec 11, 2016 at 05:34:06PM +0100, Josua Mayer wrote:
> Package: linux-image-4.9.0-rc8-armmp-unsigned: src:linux Version: 
> 4.9~rc8-1~exp1
> Message-ID: <148146021121.356.16709761149479929183.reportbug@localhost>
> X-Mailer: reportbug 6.6.6
> Date: Sun, 11 Dec 2016 12:43:31 +
> X-Debbugs-Cc: josua.maye...@gmail.com
> 
> Severity: normal
> 
> Dear Maintainer,
> 
> While doing some more tests on the GTA04 board I found that the nand flash
> works just fine *after* manually loading omap2-nand. The kernel should know
> to load that module on its own, why it doesn't is still to be found.
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-rc8-armmp (debian-kernel@lists.debian.org) (gcc
> version 6.2.1 20161124 (Debian 6.2.1-5) ) #1 SMP Debian 4.9~rc8-1~exp1
> (2016-12-05)
> 
> ** Command line:
> console=ttyO2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext2 rootwait
> 
> ** Tainted: E (8192)
>  * Unsigned module has been loaded.
> 
> ** Kernel log:
> [   11.949829] EXT4-fs error (device mmcblk0p1):
> ext4_mb_generate_buddy:758: group 6, block bitmap and bg descriptor
> inconsistent: 5945 vs 5947 free clusters
> [   12.437194] EXT4-fs error (device mmcblk0p1):
> ext4_mb_generate_buddy:758: group 1, block bitmap and bg descriptor
> inconsistent: 26419 vs 26417 free clusters
> [   12.556365] EXT4-fs error (device mmcblk0p1):
> ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor
> inconsistent: 18241 vs 18243 free clusters
> [   14.364379] 4805.dss supply vdda_video not found, using dummy regulator
> [   14.476654] OMAP DSS rev 2.0
> [   14.514038] omapdss_dss 4805.dss: bound 48050400.dispc (ops
> dispc_component_ops [omapdss])
> [   14.592834] omapdss_dss 4805.dss: bound 48050c00.encoder (ops
> venc_component_ops [omapdss])
> [   14.893432] omap_ssi 48058000.ssi-controller: ssi controller 0
> initialized (2 ports)!
> [   14.959777] omap_ssi_port 4805a000.ssi-port: couldn't get cawake
> gpio (err=-2)!
> [   15.034698] omap_ssi_port: probe of 4805a000.ssi-port failed with error -2
> [   15.130096] omap_ssi_port 4805b000.ssi-port: couldn't get cawake
> gpio (err=-2)!
> [   15.185852] omap_ssi_port: probe of 4805b000.ssi-port failed with error -2
> [   15.261901] input: twl4030_pwrbutton as
> /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:pwrbutton/input/input1
> [   15.357574] input: twl4030:vibrator as
> /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/twl4030-vibra/input/input2
> [   15.437683] 4807.i2c:twl@48:madc supply vusb3v1 not found,
> using dummy regulator
> [   15.552154] twl4030_bci 4807.i2c:twl@48:bci: could not request
> vac iio channel
> [   16.300292] Driver for 1-wire Dallas network protocol.
> [   16.335479] input: TSC2007 Touchscreen as
> /devices/platform/6800.ocp/48072000.i2c/i2c-1/1-0048/input/input3
> [   16.499816] omap_hdq 480b2000.1w: OMAP HDQ Hardware Rev 0.5. Driver
> in Interrupt mode
> [   16.508819] at24 1-0050: 8192 byte 24c64 EEPROM, writable, 1 bytes/write
> [   16.631317] omap-sham 480c3000.sham: hw accel on OMAP rev 0.9
> [   17.195587] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
> [   17.245086] OF: graph: no port node found in 
> /ocp@6800/isp@480bc000/ports
> [   17.292327] 480bc000.isp supply vdd-csiphy1 not found, using dummy 
> regulator
> [   17.419189] 480bc000.isp supply vdd-csiphy2 not found, using dummy 
> regulator
> [   17.456146] backlight supply power not found, using dummy regulator
> [   17.519348] omap3isp 480bc000.isp: Revision 15.0 found
> [   17.547027] connector-analog-tv connector: failed to find video source
> [   17.595306] iommu: Adding device 480bc000.isp to group 0
> [   17.671722] omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
> [   17.753997] OF: ERROR: Bad of_node_put() on
> /ocp@6800/i2c@4807/twl@48/audio
> [   17.762023] CPU: 0 PID: 230 Comm: systemd-udevd Tainted: G
>   E   4.9.0-rc8-armmp #1 Debian 4.9~rc8-1~exp1
> [   17.772827] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [   17.779418] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [   17.787506] [] (show_stack) from []
> (dump_stack+0x90/0xa4)
> [   17.795074] [] (dump_stack) from []
> (of_node_release+0xa0/0xa4)
> [   17.803070] [] (of_node_release) from []
> (kobject_put+0xc8/0x224)
> [   17.811248] [] (kobject_put) from []
> (of_node_put+0x24/0x28)
> [   17.818969] [] (of_node_put) from []
> (of_find_node_by_name+0x8c/0xdc)
> [   17.827545] [] (of_find_node_by_name) from []
> (twl4030_soc_probe+0x8c/0x438 [snd_soc_twl4030])
> [   17.838439] [] (twl4030_soc_probe [snd_soc_twl4030]) from
> [] (snd_soc_codec_drv_probe+0x28/0x2c [snd_soc_core])
> [   17.850860] [] (snd_soc_codec_drv_probe [snd_soc_core])
> from [] 

Bug#847343: firmware-misc-nonfree: breaks update-initramfs (initramfs-tools <= 0.125) if plymouth installed

[Adrian Bunk]

On Thu, Dec 08, 2016 at 02:21:21AM +, Ben Hutchings wrote:
>...
> > (2) firmware-misc-nonfree lacks "Breaks: initramfs-tools (<=
> > 0.125)" which it will need even after #847340 is fixed.
> 
> I won't add that Breaks line because:
> - Only the combination of the new firmware-misc-nonfree *and* plymouth
>   breaks with the unfixed initramfs-tools

The cost of a Breaks that is too broad is low, in the most common cases 
it might just change the order in which packages are being upgraded.

> - jessie and jessie-backports will never have a version of initramfs-
>   tools that satisfies that

It might not catch this specific case, but "upgrade only one package 
from jessie to stretch" is the kind of piupart issues that are now 
automatically blocking testing migration.

There is also the practical risk that without a defined order through 
Breaks, initramfs-tools might end up being upgraded much later than
the firmware during dist-upgrade.

> - jessie can get a fix for this in a stable update
>...

You cannot assume that a user has something more recent than the
initial jessie release installed.

> Ben.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#837920: user-mode-linux should be built directly by src:linux

[Adrian Bunk]

Package: user-mode-linux
Version: 4.7-1um-1
Severity: normal

A separate source package for user-mode-linux made sense 15 years ago,
when a huge patch of non-upstreamed kernel code existed for user-mode-linux.

What is left today in the user-mode-linux source package are 6 small
patches to UML-specific code (2 or 3 of them look Debian-specific)
and the kernel configurations for i386 and amd64.

There doesn't seem to be any good reason left for a separate source
package, and this would also bring DSA fixes for stretch kernels
automatically to the user-mode-linux kernel.

These xl2tpd bugs seem to be bugs in the kernel

[Adrian Bunk]

reassign 807010 src:linux
affects 807010 xl2tpd
reassign 822801 src:linux
affects 822801 xl2tpd
thanks

Hi,

the bugs #807010 (xl2tpd freezes all system) and #822801
(xl2tpd makes kernel soft lockup) look like bugs in the
kernel to me.

xl2tpd might also be buggy, but the worst part of these bugs is what 
happens in the kernel.

The relevant part of the xl2tpd 1.3.6+dfsg-4 changelog is:
  * rules: Enable USE_KERNEL, like upstream now does (Closes: #542521)

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Thu, Jul 21, 2011 at 12:50:01PM +0200, Ben Hutchings wrote:
 On Thu, 2011-07-21 at 07:05 +0300, Adrian Bunk wrote:
  On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote:
   On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote:
On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
...
 This is wrong on so many levels.
 1. There is no way to declare relations to 'all kernel packages'.

Why not?
   
   1. There are many different binary packages for different hardware
   configurations, and we add and remove them quite regularly.
   2. Although the binary packages provide virtual packages, virtual
   packages aren't versioned.
  
  That doesn't answer the question Why there are no versioned virtual 
  packages.
 
 Policy §7.5: If a relationship field has a version number attached,
 only real packages will be considered to see whether the relationship is
 satisfied...

And that makes Provides: linux-image-2.6.39 impossible?

 [...]
After that, a Breaks in all kernel images on the unfixed input-utils 
would be required.
   [...]
   
   Not going to happen.  You need to fix this through a stable update.
  
  Why isn't that going to happen?
 
 As you said before, input-utils is a niche package.

You fail to explain where the Breaks would cause any problem for anyone.

...
 Ben.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




--
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/2011072745.ga19...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote:
 On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote:
  On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
  ...
   This is wrong on so many levels.
   1. There is no way to declare relations to 'all kernel packages'.
  
  Why not?
 
 1. There are many different binary packages for different hardware
 configurations, and we add and remove them quite regularly.
 2. Although the binary packages provide virtual packages, virtual
 packages aren't versioned.

That doesn't answer the question Why there are no versioned virtual 
packages.

  How could a package declare I need at least kernel 2.6.39?
  (I know that self-compiled kernels are a different story, but for
   kernel packages that should be possible.)
 
 It can't.  The only kind of relation you can use to binary kernel
 packages is an exact dependency from a binary module package.
 
 [...]
   I suspect that the correct way to deal with this may be to build
   input-utils from the linux-2.6 source package and add some sort of
   wrapper in linux-base to select the right version (like we do for
   perf).
   
   Or, you change the program to check which protocol version to use at
   run-time.
  
  After looking a bit into it, and especially at commit ab4e0192
  (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in
  the kernel, the correct fix for input-utils is a different and
  quite simple one:
  
  The input kernel-userspace API might be enhanced with additional 
  functionality in the future, but it will never change in a way that 
  breaks the ABI.
  
  Therefore the old functionality input-utils is using will always
  be available, and the bug was that EVIOCGVERSION shouldn't be used
  to check with equality for EV_VERSION (version = 0x010001 might
  be a valid check for software using EVIOCGKEYCODE_V2).
  
  A patch for input-utils to remove the wrong version check is below.
  
  After that, a Breaks in all kernel images on the unfixed input-utils 
  would be required.
 [...]
 
 Not going to happen.  You need to fix this through a stable update.

Why isn't that going to happen?

That's the one proper solution in this case.

Especially considering that Backports are now more or less an official 
part of Debian, there are many scenarios where a stable update does not
solve the problem.

And keep in mind that if the fix for input-utils wasn't that trivial,
a stable update would not even be an option.

 Ben.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




-- 
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/20110721040551.gb13...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

tags 609300 +patch
thanks

On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
...
 This is wrong on so many levels.
 1. There is no way to declare relations to 'all kernel packages'.

Why not?

How could a package declare I need at least kernel 2.6.39?
(I know that self-compiled kernels are a different story, but for
 kernel packages that should be possible.)

...
 3. You know how people complain about udev and kernel upgrade ordering
dependencies?  You're proposing to do the same thing.

udev is a special case, since it is very essential and udev and kernel 
upgrade ordering was a tricky problem.

input-utils is a peripheral package without much hassle.

 I suspect that the correct way to deal with this may be to build
 input-utils from the linux-2.6 source package and add some sort of
 wrapper in linux-base to select the right version (like we do for
 perf).
 
 Or, you change the program to check which protocol version to use at
 run-time.

After looking a bit into it, and especially at commit ab4e0192
(Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in
the kernel, the correct fix for input-utils is a different and
quite simple one:

The input kernel-userspace API might be enhanced with additional 
functionality in the future, but it will never change in a way that 
breaks the ABI.

Therefore the old functionality input-utils is using will always
be available, and the bug was that EVIOCGVERSION shouldn't be used
to check with equality for EV_VERSION (version = 0x010001 might
be a valid check for software using EVIOCGKEYCODE_V2).

A patch for input-utils to remove the wrong version check is below.

After that, a Breaks in all kernel images on the unfixed input-utils 
would be required.

 Ben.

cu
Adrian


--  snip  --


--- input.c.old 2011-07-18 14:12:14.0 +0300
+++ input.c 2011-07-18 14:12:32.0 +0300
@@ -83,7 +83,7 @@
 int device_open(int nr, int verbose)
 {
char filename[32];
-   int fd, version;
+   int fd;
 
snprintf(filename,sizeof(filename),
 /dev/input/event%d,nr);
@@ -96,17 +96,6 @@
if (verbose)
printf(%s\n,filename);
 
-   if (-1 == ioctl(fd,EVIOCGVERSION,version)) {
-   perror(ioctl EVIOCGVERSION);
-   close(fd);
-   return -1;
-   }
-   if (EV_VERSION != version) {
-   fprintf(stderr, protocol version mismatch (expected %d, got 
%d)\n,
-   EV_VERSION, version);
-   close(fd);
-   return -1;
-   }
return fd;
 }
 




-- 
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/20110718112947.ga12...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Mon, Jul 18, 2011 at 02:45:20PM +0200, Uwe Kleine-König wrote:
 On Mon, Jul 18, 2011 at 02:29:47PM +0300, Adrian Bunk wrote:
  tags 609300 +patch
  thanks
  
  On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
  ...
   This is wrong on so many levels.
   1. There is no way to declare relations to 'all kernel packages'.
  
  Why not?
  
  How could a package declare I need at least kernel 2.6.39?
 See http://packages.debian.org/search?keywords=linux-image-2.6.39-2 for
 the kernel you'd have to depend on only to cover 2.6.39 and not all
 future kernels with all then valid featuresets.

You'd actually need to conflict with all older kernels, since
a dependency would force the installation of a kernel image
(which is not mandatory with self-compiled kernels).

 And note that a machine having installed 2.6.39 but runs 2.6.32
 satisfies that Depends. So you need a runtime check.
 ($(uname -r) = 2.6.39)
...

That's clear, and it is clear that the kernel is a special case you 
cannot handle completely through dependencies.

Still it's strange that there's no Provides: linux-image-2.6.39
other packages could use for forcing an upgrade of the installed
kernel image.

 Best regards
 Uwe

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




--
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/20110718132239.gb12...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Mon, Jul 18, 2011 at 08:35:21PM +0200, Julien Cristau wrote:
 On Mon, Jul 18, 2011 at 14:29:47 +0300, Adrian Bunk wrote:
 
  How could a package declare I need at least kernel 2.6.39?
 
 You can't, and shouldn't, do that (at least until after the wheezy
 release).

Why shouldn't?

What would be the correct handling for a package whose upstream sources 
use a userspace-kernel interface introduced in 2.6.39?

 Cheers,
 Julien

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




-- 
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/20110718192126.ga3...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Mon, Jul 18, 2011 at 02:30:41PM -0500, Jonathan Nieder wrote:
 Adrian Bunk wrote:
 
  What would be the correct handling for a package whose upstream sources 
  use a userspace-kernel interface introduced in 2.6.39?
 
 Check for -ENOSYS, print a helpful error message, and exit.  And cooperate
 with upstream to come up with a reasonable fallback so your package can
 work in a sid chroot on a stable system.

Why is this sid chroot on a stable system usecase so important?

And how are you currently ensuring that perf is working in your
sid chroot on a stable system usecase?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




-- 
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/20110718195653.ga4...@localhost.pp.htv.fi

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

Package: linux-image-2.6.39-2-amd64
Version: 2.6.39-3
Severity: serious

Upgrading the kernel without also upgrading input-utils (e.g. when
using the version in squeeze or the version currently in testing)
makes input-utils unusable (see #609300).

After #609300 got fixed, the linux images should therefore add Breaks
for all non-fixed versions of input-utils.



-- 
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/20110715130416.12008.876.reportbug@localhost

Bug#633961: linux images must conflict with unfixed input-utils

[Adrian Bunk]

On Fri, Jul 15, 2011 at 03:45:58PM +0100, Ben Hutchings wrote:
 On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote:
  Package: linux-image-2.6.39-2-amd64
  Version: 2.6.39-3
  Severity: serious
 
 This is not RC for the kernel.

Upgrade makes another package completely unusable when not forcing an 
upgrade of that is not RC?

  Upgrading the kernel without also upgrading input-utils (e.g. when
  using the version in squeeze or the version currently in testing)
  makes input-utils unusable (see #609300).
  
  After #609300 got fixed, the linux images should therefore add Breaks
  for all non-fixed versions of input-utils.
 
 Maybe.  But first you have to make input-utils work with both the kernel
 version in squeeze and the version in sid.

A versioned build-dependency on linux-libc-dev and a breaks for older 
kernel images seems to be the minimal fix.

 Ben.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed




-- 
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/20110715154159.ge4...@localhost.pp.htv.fi

Bug#586401: linux-libc-dev: Please remove NEWS.Debian.gz

[Adrian Bunk]

Package: linux-libc-dev
Version: 2.6.32-15
Severity: normal

I run a self-compiled kernel and have therefore no Debian kernel images
installed.

While upgrading linux-libc-dev the contents of
/usr/share/doc/linux-libc-dev/NEWS.Debian.gz
was shown, which is kinda pointless.



-- 
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/20100619081811.5617.97645.report...@localhost

Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels

[Adrian Bunk]

On Wed, Aug 22, 2007 at 08:10:19PM +0200, Josip Rodin wrote:
 Hi Adrian,
 
 On Wed, Aug 22, 2007 at 04:13:19AM +0200, Josip Rodin wrote:
   I'm reporting this bug that I have been seeing for a while and which is
   a regression from a few months/years ago - the line-in input simply 
   doesn't
   work right. arecord(1) just doesn't record anything with it, it doesn't 
   show
   any errors, it records silence. The recording from the same external 
   source
   works just fine with the microphone input.
  
  I re-selected the old-style i810_audio driver in 2.6.21 and compiled it,
  unloaded the ALSA driver, loaded the old driver, and voila, everything went
  back to normal, I can hear the TV sound just fine. So, it might be that this
  is an OSS-ALSA regression that slipped through the cracks?
 
 While browsing kernel options, I noticed:
 
 Please contact Adrian Bunk [EMAIL PROTECTED] if you had to
 say Y here because your hardware is not properly supported
 by ALSA.
 
 ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :)
 
 This is Debian bug #439072 (and #384933 also looks suspiciously similar,
 if I might add).

Please do the following:
- check at the ALSA bug tracking system [1] whether your problem was 
  already reported
- if there isn't already a bug for it, open a new bug
- in any case, tell me the bug number so that I can track this issue

TIA
Adrian

[1] http://bugtrack.alsa-project.org/alsa-bug/

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels

[Adrian Bunk]

forwarded 439072 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335
thanks

On Thu, Aug 23, 2007 at 11:17:28PM +0200, Josip Rodin wrote:
 On Thu, Aug 23, 2007 at 07:04:13PM +0200, Adrian Bunk wrote:
   While browsing kernel options, I noticed:
   
   Please contact Adrian Bunk [EMAIL PROTECTED] if you had to
   say Y here because your hardware is not properly supported
   by ALSA.
   
   ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :)
   
   This is Debian bug #439072 (and #384933 also looks suspiciously similar,
   if I might add).
  
  Please do the following:
  - check at the ALSA bug tracking system [1] whether your problem was 
already reported
  - if there isn't already a bug for it, open a new bug
  - in any case, tell me the bug number so that I can track this issue
 
 I found several bug reports that sounded familiar, but none of them
 described this exact issue. This is the new ticket I just filed:
 
 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335

Thanks for doing this.

The SOUND_ICH option is currently removed in 2.6.23-rc, but I'll get 
this reverted if this bug won't be fixed soon.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415112: merging, tagging and CVE number

[Adrian Bunk]

forcemerge 398470 415112
tags 398470 +patch
tags 398470 +security
tags 398470 serious
retitle 398470 key serial number collision (CVE-2007-0006)
thanks

Severity serious since bugs causing kernel Oopses with CVE number and
patches available are IMHO nothing a stable release should ship with.

cu
Adrian

BTW: The submitter of #398470 posted a patch to the bug 12 days
 before the latest kernel upload.

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#414773: firmware-nonfree: FTBFS

[Adrian Bunk]

Package: firmware-nonfree
Version: 0.3
Severity: serious


The build dependency on linux-support-2.6.17-2 can't be fulfilled
in unstable or testing.


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.44-rc1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#344205: [2.6 patch] fix AIRO{,_CS} - CRYPTO

[Adrian Bunk]

On Sat, Jan 07, 2006 at 05:47:14PM -0700, dann frazier wrote:
 airo.c currently has MICSUPPORT enabled, which requires CONFIG_CRYPTO.
 A user reported a build failure which is due to the lack of a Kconfig
 dependency.  See http://bugs.debian.org/344205.
 
 This patch makes Kconfig enforce this dependency.
 
 Signed-off-by: dann frazier [EMAIL PROTECTED]
...

Hi Dann,

thanks for your patch.

A more complete fix is below.

cu
Adrian


--  snip  --


drivers/net/wireless/airo.c requires CONFIG_CRYPTO for compilations.

Therefore, AIRO and AIRO_CS should select CRYPTO.

Additionally, this patch removes the #ifdef's for the non-compiling 
CRYPTO=n case from drivers/net/wireless/airo.c.

Bug report by Roland Mas [EMAIL PROTECTED],
initial patch by dann frazier [EMAIL PROTECTED].


Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 drivers/net/wireless/Kconfig |2 +
 drivers/net/wireless/airo.c  |   55 +--
 2 files changed, 4 insertions(+), 53 deletions(-)

--- linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig.old  2006-01-10 
20:40:12.0 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig  2006-01-10 
21:06:08.0 +0100
@@ -244,6 +244,7 @@
 config AIRO
tristate Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards
depends on NET_RADIO  ISA_DMA_API  (PCI || BROKEN)
+   select CRYPTO
---help---
  This is the standard Linux driver to support Cisco/Aironet ISA and
  PCI 802.11 wireless cards.
@@ -391,6 +392,7 @@
 config AIRO_CS
tristate Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards
depends on NET_RADIO  PCMCIA  (BROKEN || !M32R)
+   select CRYPTO
---help---
  This is the standard Linux driver to support Cisco/Aironet PCMCIA
  802.11 wireless cards.  This driver is the same as the Aironet
--- linux-2.6.15-mm2-full/drivers/net/wireless/airo.c.old   2006-01-10 
20:40:31.0 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/airo.c   2006-01-10 
20:42:44.0 +0100
@@ -36,6 +36,7 @@
 #include linux/in.h
 #include linux/bitops.h
 #include linux/scatterlist.h
+#include linux/crypto.h
 #include asm/io.h
 #include asm/system.h
 
@@ -87,14 +88,6 @@
 #include linux/delay.h
 #endif
 
-/* Support Cisco MIC feature */
-#define MICSUPPORT
-
-#if defined(MICSUPPORT)  !defined(CONFIG_CRYPTO)
-#warning MIC support requires Crypto API
-#undef MICSUPPORT
-#endif
-
 /* Hack to do some power saving */
 #define POWER_ON_DOWN
 
@@ -1118,7 +,6 @@
 static int writerids(struct net_device *dev, aironet_ioctl *comp);
 static int flashcard(struct net_device *dev, aironet_ioctl *comp);
 #endif /* CISCO_EXT */
-#ifdef MICSUPPORT
 static void micinit(struct airo_info *ai);
 static int micsetup(struct airo_info *ai);
 static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer 
*buffer, int len);
@@ -1127,9 +1119,6 @@
 static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi);
 static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm);
 
-#include linux/crypto.h
-#endif
-
 struct airo_info {
struct net_device_stats stats;
struct net_device *dev;
@@ -1190,12 +1179,10 @@
unsigned long   scan_timestamp; /* Time started to scan */
struct iw_spy_data  spy_data;
struct iw_public_data   wireless_data;
-#ifdef MICSUPPORT
/* MIC stuff */
struct crypto_tfm   *tfm;
mic_module  mod[2];
mic_statistics  micstats;
-#endif
HostRxDesc rxfids[MPI_MAX_FIDS]; // rx/tx/config MPI350 descriptors
HostTxDesc txfids[MPI_MAX_FIDS];
HostRidDesc config_desc;
@@ -1229,7 +1216,6 @@
 static int flashputbuf(struct airo_info *ai);
 static int flashrestart(struct airo_info *ai,struct net_device *dev);
 
-#ifdef MICSUPPORT
 /***
  *  MIC ROUTINES   *
  ***
@@ -1686,7 +1672,6 @@
digest[2] = (val8)  0xFF;
digest[3] = val  0xFF;
 }
-#endif
 
 static int readBSSListRid(struct airo_info *ai, int first,
  BSSListRid *list) {
@@ -2005,7 +1990,6 @@
 * Firmware automaticly puts 802 header on so
 * we don't need to account for it in the length
 */
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, ai-flags)  ai-micstats.enabled 
(ntohs(((u16 *)buffer)[6]) != 0x888E)) {
MICBuffer pMic;
@@ -2022,9 +2006,7 @@
memcpy (sendbuf, pMic, sizeof(pMic));
sendbuf += sizeof(pMic);
memcpy (sendbuf, buffer, len - sizeof(etherHead));
-   } else
-#endif
-   {
+   } else {
*payloadLen = cpu_to_le16(len - sizeof(etherHead));
 
dev-trans_start = jiffies;
@@ -2400,9 +2382,7 @@
ai

Bug#252745: mkfs.cramfs uses MD5 sums

[Adrian Bunk]

Hi John,

regarding your bug report cramfsprogs: Extremely inefficient 
performance on large trees:

mkfs.cramfs (shipped with the util-linux package) already uses md5sums 
the way you suggest them. Can you confirm that mkfs.cramfs fixes your 
problem?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#324414: linux-image-2.6.12-1-386 should become linux-image-2.6.12-1-486

[Adrian Bunk]

Package: linux-image-2.6.12-1-386
Version: 2.6.12-5
Severity: normal


There is not much value in shipping kernel images supporting
a CPU no longer supported by Debian since Debian 3.1 .

Renaming the kernel image and letting the compiler optimize it
for the 486 would also give your 486 and 586 users slightly
better kernels.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#320379: Errors during initrd loading when / is on LVM over RAID

[Adrian Bunk]

On Wed, Aug 03, 2005 at 08:54:37PM +0900, Horms wrote:
...
 Hi Frans,
 
 The null devfs_name check seems fine to me,
 I've CCed Richard Gooch for comment, hopefully
 he can offer one despite devfs being debricated
 upstream.
...

The DEVFS_FS config option is no longer available in 2.6.13 making any 
fixes to devfs pointless.
 
 Horms

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Inconsistent handling of sourceless packages in main

[Adrian Bunk]

On Thu, May 19, 2005 at 10:12:43AM +0200, Goswin von Brederlow wrote:
...
 And all have problems:
 
 package  | danger
 -+--
 kernel-image*| kernel-source* update replaces source
  | rebuild differs
  | but old version is retrievable through included patches
...

Silly question:

Is e.g. kernel-source-2.6.8 2.6.8-15 in sarge really sufficient to 
satisfy the GPL requirements for kernel-image-2.6.8-sparc 2.6.8-6 in 
sarge built against kernel-source-2.6.8 2.6.8-11?

IANAL, but I'd have said this was a violation GPL section 3 .

 MfG
 Goswin

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309307: kernel-image-2.4.27-sparc in sarge lacks security fixes from kernel-source-2.4.27 2.4.27-9

[Adrian Bunk]

Package: kernel-image-2.4.27-sparc
Version: 2.4.27-2
Severity: critical
Tags: security, sarge


The package in sarge lacks the security fixes from
kernel-source-2.4.27 2.4.27-9 .


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote:
 On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
  If Debian was at least consistent.
  
  Why has Debian a much more liberal interpretation of MP3 patent issues 
  than RedHat?
 
 It's impossible to treat patents consistently.
 
 The U.S. patent office, at least, has granted patents on natural laws,
 on stuff that's already patented, on stuff with clear prior art, on
 trivial math operations and so on.  Patents are being granted so quickly
 there's no way of even knowing what's patented.
 
 Or were you hoping that Debian would follow Red Hat's lead?


Even RedHat with a stronger financial background than Debian considered 
the MP3 patents being serious enough to remove MP3 support.

Yes, Debian can choose to put a higher risk on their distributors and 
mirrors - there's nothing wrong with this.


Note that this is a respose to Josselin's statement:

--  snip  --

When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.

--  snip  --


It's simply silly to be extremely picky on copyright issues while being 
extremely liberal on patent issues - the risk of a Debian distributor 
being sued for patent violations (no matter how the lawsuit might end) 
is definitely present.


 As for this particular patent, I'm not really sure what's being patented.
...


Which one of the 23 patents they list do you call this particular 
patent?


 Raul


cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 08:54:40AM +0200, Sven Luther wrote:
 On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote:
  On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote:
   On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
  ...
If your statement was true that Debian must take more care regarding 
legal risks than commercial distributions, can you explain why Debian 
exposes the legal risks of distributing software capable of decoding 
MP3's to all of it's mirrors?
   
   I don't know and don't really care. I don't maintain any mp3 player (err,
   actually i do, i package quark, but use it mostly to play .oggs, maybe i
   should think twice about this now that you made me aware of it), but in 
   any
   case, i am part of the debian kernel maintainer team, and as such have a
   responsability to get those packages uploaded and past the screening of 
   the
   ftp-masters. I believe the planned solution is vastly superior to the 
   current
   one of simply removing said firmware blobs from the drivers, which caused 
   more
   harm than helped, which is why we are set to clarifying this for the
   post-sarge kernels. 
  
  
  Debian doesn't seem to care much about the possible legal problems of 
  patents.
 
 patents are problematic, and upto recently there where no software patents in
 europe, so i don't really care. I am not sure about the details of the above
 problem you mention, could you provide me some link to the problem at hand. I

  http://www.mp3licensing.com/

The patent problems in the USA alone should impose enough legal risks.
IANAL, but even RedHat considers them to be serious problems.

And note that most of their patents are also valid in the EU. If they 
are enforcible is a different question, but it might be enough to become
a legal risk that a lawsuit might be started against e.g. a mirror.

 also believe that in the larger scheme restriction of this kind, as is the US
 restriction on distribution to cuba and everything else, is not-right and even
 immoral, and *I* personally would fight back if i was ever sued for such
 things, and there may be higher courts involved than just the US judicial
 system, which is for sale anyway, where redhat is dependent on. I cannot talk

Which court is higher ... than just the US judicial system?

If you are in the USA, there's no legal instance between the US supreme 
court and god.

 about the whole of debian on this though, and i feel it is for someone else to
 tackle and handle. If you feel strongly about this, you are free to go take it
 over with whoever handles this, post to debian-legal and debian-project about
 it, and help get the issue solved.
 
 (/me believes such restrictions of the above are a violation of the elemental
 human rights to go where one wants and run what operating system on wants).
...

Unfortunately, life isn't fair.

It's Debian's choice how cautiously or brave they are regarding legal 
risks. But it has to be consistent.

Debian simply needs an overall policy for this.

But if you say that you want to avoid any legal risks in one area while 
saying these are not my packages about perhaps even more likely legal 
risks in other areas doesn't help anyone.

 Friendly,
 
 Sven Luther

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 09:22:00AM +0200, Josselin Mouette wrote:
 Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit :
   You are mixing apples and oranges. The fact that the GFDL sucks has
   nothing to do with the firmware issue. With the current situation of
   firmwares in the kernel, it is illegal to redistribute binary images of
   the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
   be willing to distribute such binary images, but it isn't our problem.
  
  It's a grey area.
  
  debian-legal did pick one of the possible opinions on this matter.
 
 When there are several possible interpretations, you have to pick up the
 more conservative one, as it's not up to us to make the interpretation,
 but to a court.


If Debian was at least consistent.

Why has Debian a much more liberal interpretation of MP3 patent issues 
than RedHat?


...
 Instead of babbling, some people have started to discuss this with
 upstream, and are trying to come up with a GPLed documentation for GCC.
 This is much more constructive than repeating again and again Bleh,
 Debian are a bunch of bigots who don't care of the compiler being
 documented.


Will the replacement documentation for all affected software be 
available before the GFDL documentation gets removed?

At least theoretically, the users are a priority for Debian equally to 
free software.


  Is it true, that Debian will leave users with hardware affected by the 
  firmware problem without a working installer in Debian 3.1?
 
 The case of hardware really needing a firwmare to work *and* needed at
 installation time is rare. I've only heard of some tg3-based cards. Most
 of them will work without the firmware, and for the few remaining ones,
 it only means network installation won't work.


How do you install Debian on a harddisk behind a SCSI controller who's 
driver was removed from the Debian kernels due to it's firmware?


  The point is simply, that Debian does more and more look dogmatic at 
  it's definition of free software without caring about the effects to 
  it's users.
 
 Being careless in the definition of free software is a real disservice
 to users. It makes them rely on e.g. non-free documentation for everyday
 use.
...


Documentation is software?

Non-free documentation is better than no documentation.

Non-free software has several problems, but some of them like the right 
to do modifications are less important for documentation, since e.g. 
fixes for security bugs are not an issue.

Removing the available documentation without an equal replacement is a 
real disserve for your users.


cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote:
 Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit :
   When there are several possible interpretations, you have to pick up the
   more conservative one, as it's not up to us to make the interpretation,
   but to a court.
  
  If Debian was at least consistent.
  
  Why has Debian a much more liberal interpretation of MP3 patent issues 
  than RedHat?
 
 Because we already know that patents on MP3 decoders are not
 enforceable. Furthermore, the holders of these patents have repeatedly

How do you know the patents aren't enforceable?

 stated they won't ask for fees on MP3 decoders.

  http://www.mp3licensing.com/royalty/index.html

talks about 0.75 Dollar for a decoder.

  How do you install Debian on a harddisk behind a SCSI controller who's 
  driver was removed from the Debian kernels due to it's firmware?
 
 Which SCSI controller are you talking about?

Quoting README.Debian of the Debian kernel sources:

--  snip  --

* QLA2XXX firmware, driver disabled:
  . drivers/scsi/qla2xxx/*_fw.c

--  snip  --

There are a few other SCSI controllers where even the Debian kernel 
sources still ship both the drivers and the firmware. I do not claim to 
understand the latter...

   Being careless in the definition of free software is a real disservice
   to users. It makes them rely on e.g. non-free documentation for everyday
   use.
  ...
  
  Documentation is software?
 
 Sure.

Every book in my book shelf is software?

That doesn't match how people outside of Debian use the word software.

  Non-free documentation is better than no documentation.
  
  Non-free software has several problems, but some of them like the right 
  to do modifications are less important for documentation, since e.g. 
  fixes for security bugs are not an issue.
  
  Removing the available documentation without an equal replacement is a 
  real disserve for your users.
 
 GFDL documentation will still be available in the non-free archive.

Assuming you have an online connection and a friend told you how to 
manually edit your /etc/apt/sources.list for non-free.

But where's the documentation if you don't have an online connection but 
only the dozen binary CDs of Debian?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
 Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit :
  On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
   On Apr 04, Greg KH [EMAIL PROTECTED] wrote:
   
What if we don't want to do so?  I know I personally posted a solution
   Then probably the extremists in Debian will manage to kill your driver,
   like they did with tg3 and others.
  
  And as they are doing with e.g. the complete gcc documentation.
  
  No documentation for the C compiler (not even a documentation of the 
  options) will be neither fun for the users of Debian nor for the Debian 
  maintainers - but it's the future of Debian...
 
 You are mixing apples and oranges. The fact that the GFDL sucks has
 nothing to do with the firmware issue. With the current situation of
 firmwares in the kernel, it is illegal to redistribute binary images of
 the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
 be willing to distribute such binary images, but it isn't our problem.
...


It's a grey area.

debian-legal did pick one of the possible opinions on this matter.


The similarities between the GFDL and the firmware discussion can be 
described with the following two questions:


Is it true, that the removal of much of the documentation in Debian is 
scheduled soon because it's covered by the GFDL, that this is called an 
editorial change, and that Debian doesn't actually care that this will 
e.g. remove all documentation about available options of the standard C 
compiler used by and shipped with Debian?

Is it true, that Debian will leave users with hardware affected by the 
firmware problem without a working installer in Debian 3.1?


The point is simply, that Debian does more and more look dogmatic at 
it's definition of free software without caring about the effects to 
it's users.


As a contrast, read the discussion between Christoph and Arjan in a part 
of this thread how to move firmware out of kernel drivers without 
problems for the users. This might not happen today, but it's better for 
the users.


cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote:
 On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
...
  If your statement was true that Debian must take more care regarding 
  legal risks than commercial distributions, can you explain why Debian 
  exposes the legal risks of distributing software capable of decoding 
  MP3's to all of it's mirrors?
 
 I don't know and don't really care. I don't maintain any mp3 player (err,
 actually i do, i package quark, but use it mostly to play .oggs, maybe i
 should think twice about this now that you made me aware of it), but in any
 case, i am part of the debian kernel maintainer team, and as such have a
 responsability to get those packages uploaded and past the screening of the
 ftp-masters. I believe the planned solution is vastly superior to the current
 one of simply removing said firmware blobs from the drivers, which caused more
 harm than helped, which is why we are set to clarifying this for the
 post-sarge kernels. 


Debian doesn't seem to care much about the possible legal problems of 
patents.

The firmware issues are an urgent real problem?


Debian should define how much legal risk they are willing to impose on 
their mirrors and distributors and should act accordingly in all areas.

But ignoring some areas while being more religious than RMS in other 
areas is simply silly.


 That said, i was under the understanding that after the SCO disaster,
 clarification of licencing issues and copyright attributions was a welcome
 thing here, but maybe i misunderstood those whole issues.


SCO disaster?

It is a disaster for SCO.


 Friendly,
 
 Sven Luther

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
 On Apr 04, Greg KH [EMAIL PROTECTED] wrote:
 
  What if we don't want to do so?  I know I personally posted a solution
 Then probably the extremists in Debian will manage to kill your driver,
 like they did with tg3 and others.


And as they are doing with e.g. the complete gcc documentation.

No documentation for the C compiler (not even a documentation of the 
options) will be neither fun for the users of Debian nor for the Debian 
maintainers - but it's the future of Debian...

The Debian Social Contract says:
  Our Priorities are Our Users and Free Software

The next editorial changes to your social contract might remove the 
Our Users and...


Seriously:

There might be real problems with non-distributable firmware, but the 
known extremist position of Debian on such issues produces negative 
emotions if something like this comes from Debian.


 This sucks, yes.


Agreed.


 ciao,
 Marco (@debian.org)

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote:
 On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
  On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
   On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
 Mmm, probably that 2001 discussion about the keyspan firmware, right ?
 
   http://lists.debian.org/debian-legal/2001/04/msg00145.html
 
 Can you summarize the conclusion of the thread, or what you did get 
 from it,
 please ? 

That people didn't like the inclusion of firmware, I posted how you can
fix it by moving it outside of the kernel, and asked for patches.
   
   Yeah, that is a solution to it, and i also deplore that none has done the 
   job
   to make it loadable from userland. For now, debian is satisfied by moving 
   the
   whole modules involved to non-free, and this has already happened in part.
  
  
  Does this imply your installer will use these non-free modules?
 
 The installer already has provision for loading additional .udebs from floppy
 or net, not sure about other media, and we don't build yet non-free d-i images
 with those non-free modules builtin, but it could be arranged. This is
 post-sarge issues though, and we still have some time to solve them.
 
  If the driver for the controller your harddisk is behind is not used by 
  the installer you could simply remove these modules instead of moving 
  them to non-free.
 
 yeah, the problem is a whole bunch of people have tg3 network cards it seem :)


I was more thinking about SCSI controllers, but tg3 is also interesting.

Additional non-free d-i images will for sure be required, or several 
hardware setups might make installation of Debian impossible without 
bootstrapping through a different OS or distribution.


   Nope, i am aiming to clarify this issue with regard to the debian kernel, 
   so
   that we may be clear with ourselves, and actually ship something which is 
   not
   of dubious legal standing, and that we could get sued over for GPL 
   violation.
  ...
  
  
  If it was a GPL violation, it wasn't enough to contact only the small 
  subset of copyright holders that worked on this specific file since 
  this file might be compiled statically into the GPL'ed kernel.
 
 That is not a problem, since even if the firmware is built into the same
 executable as the rest of the kernel code, it still constitutes only mere
 agregation, where the kernel is the distribution media, in the GPL sense.
 Please read the mail i linked too in the original mail for detailed
 argumentation of this.
 
 The only problem to it constituting mere agregation is that the firmware blob
 is not clearly identified as such in the tg3.c file (for example), and that
 there is no licencing condition allowing their distribution apart the GPL,
 which these firmware blobs where evidently not meant to be put under.


This is one possible legal interpretation of mere aggregation.

Whether judges in all jurisdictions of the world follow this 
interpretation or an interpretation of the GPL in one direction or 
another is the more interesting question.


 Friendly,
 
 Sven Luther

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

unknown filesystem is not a kernel bug

[Adrian Bunk]

[ this mail is not in a thread with the original mail since I saw it 
  when looking through the list archives ]

Hi Thomas,

this is bug #255849 [1] in the initscripts package. The patch from this 
bug applied against /etc/init.d/checkroot.sh plus a reboot should fix  
this issue.

For most people this bug harmless, but some applications like quota no 
longer work on the root filesystem.

cu
Adrian

[1] http://bugs.debian.org/255849

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed