Bug#987720: ITP: ksmbd-tools -- cifsd kernel server userspace utilities

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ksmbd-tools
  Version : 0+git20210428
  Upstream Authors: Namjae Jeon 
Sergey Senozhatsky 
* URL : https://github.com/namjaejeon/ksmbd-tools
* License : GPL-2-or-later
  Description : cifsd kernel server userspace utilities
 This is an alternative implementation of the CIFS/SMB3 control 
utilities.

Bug#986347: ITP: kernelshark -- Utilities for graphically analyzing function tracing in the kernel

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: kernelshark
  Version : v1.3
  Upstream Author : Steven Rostedt 
Yordan Karadzhov (VMware) 
* URL : 
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/
* License : GPL-2 and LGPL-2.1
  Programming Lang: C++
  Description : Utilities for graphically analyzing function tracing in the 
kernel.

Data for analysis may be generated by the trace-cmd utility.

kernelshark is already available in Debian as part of trace-cmd but upstream
has now decided to move kernelshark to its own repo at:
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git and the 
announcement
is at 
https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/tag/?h=trace-cmd-v2.9.2


--
Regards
Sudip

Bug#983403: ITP: vhba-dkms -- Kernel module that provides a Virtual SCSI HBA, part of the CDEmu software suite

[Matteo Bini]

Package: wnpp
Severity: wishlist
Owner: Matteo Bini 

* Package name: vhba-dkms
  Version : 20200106
  Upstream Author : Chia-I Wu 
* URL : https://cdemu.sourceforge.io/about/vhba/
* License : GPLv2
  Programming Lang: C
  Description : Kernel module that provides a Virtual SCSI HBA, part of the
CDEmu software suite

VHBA (Virtual SCSI Host Bus Adapter) is a kernel module which
acts as a low-level SCSI driver and which provides the SCSI layer with a
virtual SCSI adapter which can have multiple virtual devices.
It is part of the CDEmu software suite.

Its typical use in the CDEmu software suite is to provide virtual devices
that emulates real SCSI Optical (CD-ROM) devices. It works in cooperation with
the CDEmu daemon and libMirage to emulate an Optical (CD-ROM) drive and disc
with information contained in a disc image. For your information, a disc image
is just a copy of the information stored on an actual disc.

Bug#983402: ITP: vhba-dkms -- Kernel module that provides a Virtual SCSI HBA, part of the CDEmu software suite

[Matteo Bini]

Package: wnpp
Severity: wishlist
Owner: Matteo Bini 

* Package name: vhba-dkms
  Version : 20200106
  Upstream Author : Chia-I Wu 
* URL : https://cdemu.sourceforge.io/about/vhba/
* License : GPLv2
  Programming Lang: C
  Description : Kernel module that provides a Virtual SCSI HBA, part of the
CDEmu software suite

VHBA (Virtual SCSI Host Bus Adapter) is a kernel module which
acts as a low-level SCSI driver and which provides the SCSI layer with a
virtual SCSI adapter which can have multiple virtual devices.
It is part of the CDEmu software suite.

Its typical use in the CDEmu software suite is to provide virtual devices
that emulates real SCSI Optical (CD-ROM) devices. It works in cooperation with
the CDEmu daemon and libMirage to emulate an Optical (CD-ROM) drive and disc
with information contained in a disc image. For your information, a disc image
is just a copy of the information stored on an actual disc.


vhba-dkms_20200106-1_all.deb
Description: application/vnd.debian.binary-package

how to ignore signed kernel packages and use the unsigned instead?

[Harald Dunkel]

Hi folks,

I would like to install the unsigned kernel packages instead of the signed
ones, but using linux-headers-amd64 and linux-image-amd64 I have to wait for
a signature being applied.

Obviously the signed kernel image and header packages for amd64 rely upon
information not being publicly available, making it impossible (or at least
pretty unlikely) for me to rebuild the dpendencies for linux-headers-amd64
and linux-image-amd64 on my own.

So I wonder if linux-headers-amd64 and linux-image-amd64 shouldn't depend
upon the unsigned kernel-headers and kernel-image packages, as for other
platforms?


Regards
Harri

Bug#976425: ITP: libtracefs -- API to access the kernel tracefs directory

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 

* Package name: libtracefs
  Version : 0
  Upstream Author : Steven Rostedt 
* URL : https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git
* License : LGPL-2.1
  Programming Lang: C
  Description : API to access the kernel tracefs directory

It had been part of tracecmd but has been split into its own repo.
The announcement mail was at 
https://lore.kernel.org/lkml/20201120200314.21efa...@oasis.local.home/

Note: This is not needed for Bullseye and so I am only planning to upload to 
experimental for now.

--
Regards
Sudip

Bug#969620: ITP: metakernel -- Jupyter kernel base class

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: metakernel
  Version : 0.27.0
  Upstream Author : Metakernel Development Team
* URL : https://github.com/Calysto/metakernel
* License : BSD
  Programming Lang: Python
  Description : Jupyter kernel base class

Metakernel is a Jupyter kernel base class in Python which includes core magic
functions (including help, command and file path completion, parallel and
distributed processing, downloads, and much more).

It is used by numerous other kernels for Jupyter, including for my purposes the
octave kernel.

Happy to have co-maintainers and/or place it under the rubric of the Debian 
Python team.

--Joe

Bug#915964: marked as done (bugs.debian.org: Boot process with kernel 4.18.0.3 fails and goes to black screen.)

[Debian Bug Tracking System]

Your message dated Mon, 31 Aug 2020 01:55:09 +0200
with message-id <20200830235508.syobgdcnoir3n...@percival.namespace.at>
and subject line Re: Bug#915964: bugs.debian.org: Boot process with kernel 
4.18.0.3 fails and goes to black screen.
has caused the Debian Bug report #915964,
regarding bugs.debian.org: Boot process with kernel 4.18.0.3 fails and goes to 
black screen.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
915964: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915964
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: bugs.debian.org
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Standard terminal update of Debian Testing system that included the new kernel.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Hi alanscott221,

thanks for your interest in making Debian better and filing
this report:

* alanscott221 :
> Standard terminal update of Debian Testing system that included the new 
> kernel.

However, at this time it looks more like a support request,
and the bug tracker is not well-suited for helping users
interactively.

Please try getting help first from other venues listed at
   https://www.debian.org/support - especially IRC,
the mailing lists or http://forums.debian.net/ .

Once there is a clear bug identified, please file a new report
against the package having the bug.

Thank you for your understanding,
Chris--- End Message ---

Bug#956263: ITP: onemkl -- oneAPI Math Kernel Library (oneMKL) Interfaces

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: onemkl
* URL : https://github.com/oneapi-src/oneMKL
* License : Apache-2
  Programming Lang: C++, OpenCL (maybe SYCL)
  Description : oneAPI Math Kernel Library (oneMKL) Interfaces

It looks like intel is starting a brand new MKL implementation to
incorprate OpenCL (GPU acceleration).

I don't know how Intel will deal with its intel-mkl (proprietary) and
oneMKL (apache-2) which provide quite similar functionality. So I'm
keeping an eye on this.

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: liburing
  Version : 0.4
  Upstream Author : Jens Axboe 
* URL : https://git.kernel.dk/cgit/liburing/
* License : LGPL and MIT/X
  Programming Lang: C
  Description : Linux kernel io_uring access library

 liburing provides helpers to setup and teardown io_uring instances,
 and also a simplified interface for applications that don't need (or
 want) to deal with the full kernel side implementation.


The liburing library is supposed so supercede the libaio library which
I maintain too, so it makes sense to handle both. :)

Thanks,
Guillem

Re: Kernel parameters protecting fifos and regular files

[Craig Small]

On Thu, 30 Jan 2020 at 05:26, Moritz Mühlenhoff  wrote:

> I'm in favour of setting both to 1. From a quick search Ubuntu carried a
> patch
> in their systemd package to set this as well (LP 1845637).
>
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so I'd say that src:linux should be patched as well, this
> changes
> the default at the deepest level and the /etc/sysctl.conf kicks in for
> anyone running custom built kernels.
>
OK, I'll make them both 1 rather than 2 so there is some consistency.  I
note the concern some have brought up about procps is not installed in some
minimal installations but that's not the problem we're trying to solve
here. They'll be in the next release.

Thanks all for the input.

 - Craig

Bug#950686: ITP: partman-cros -- Add partman support for ChromeOS kernel partitions

[Alper Nebi Yasak]

Package: wnpp
Severity: wishlist
Owner: Alper Nebi Yasak 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: partman-cros
  Version : 1
  Upstream Author : Alper Nebi Yasak 
* URL : http://salsa.debian.org/alpernebbi-guest/partman-cros
* License : GPL-2.0+
  Programming Lang: sh
  Description : Add partman support for ChromeOS kernel partitions

  This package provides a 'cros' partition method for partman. The 
  firmware and bootloader used on ChromeOS systems require a special 
  ChromeOS kernel partition created by this method.

Creating partitions of this ChromeOS kernel type is one part of what's 
necessary for Debian installer to install a successfully bootable system 
on ChromeOS machines. This package is essentially a partman-prep fork 
for this partition type.

It's probably already possible to create these partitions manually using 
e.g. parted-udeb and fdisk-udeb. But, this package does some checks to 
ensure the partition is in the right disk and offers a warning if the 
partition is not created (when that could lead to an unbootable system).

It makes most sense to maintain this package under the installer team if 
they accept. I need a sponsor and will file an RFS soon.

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

[Marvin Renich]

* Richard Laager  [200129 19:05]:
> On 1/29/20 8:28 AM, Marvin Renich wrote:
> There are plenty of shades of
> grey in this, and what counts as "minimal", "medium", or "massive" is
> going to be at least somewhat subjective.

Completely agree.

> I'd say that "massive breakage" (breaking lots of things) is not the
> same as "maximal disruption" (the most disruption). Maximum disruption
> would be, for example, breaking things that were "fully correct" (not
> doing something "dodgy") before the change. This would be a "flag day"
> change. That level of disruption needs to be avoided if at all possible,
> and carefully managed if completely unavoidable and worth the pain.

My intended meaning of disruption, in my previous message, was not the
inevitable churn associated with ironing out the bugs.  It was the
resulting decrease in ease of use (and increase of other costs) after
the bugs settled.  Sorry if that wasn't clear.

There is always a trade-off between security and usability.  My point is
to not force more security on everybody _as the default_ when only some
users need that security, and most of the time the users who need the
security are the ones who are able figure out the knob to tweak to get
it (and many times they are using something like puppet to ensure that
all the machines they support get the configuration they want).

Because of this, distributions, when choosing defaults, should give more
weight to the needs of those less likely to be able to do the
configuration themselves than to those with more advanced needs.  I do
agree that sometimes having a slightly higher level of security is the
best default; just give appropriate thought to the associated costs.

> > Time and time again I see security expert "wannabes" pushing for the
> > most security possible.  Even real experts sometimes lose sight of the
> > balance between usability and security.  Unfortunately, there are a lot
> > more "wannabes" than real experts, and the "wannabes" are typically much
> > more vocal.
> 
> While I understand your point, I think it would be better to focus on
> the arguments rather than the people making them.

Okay, that paragraph was too pejorative.  Let me rephrase it.  (Note,
however, that I did not identify anyone in particular, nor did I have
any specific person or persons in mind.)

Some people actively and regularly encourage others (distributions,
large ISPs, etc.) to use a higher level of security as a default than
most people need without regard to how it affects usability and other
real costs (such as bandwidth and CPU usage, which affects how much
people have to spend).  Not only is setting the default level of
security too high a bad thing, but the act of promoting this is a bad
thing.  (This last sentence was really the point I was trying to make
with the paragraph in my previous message.)

If I offended anyone who considers themselves to be one of the people
described in the previous paragraph by calling them security expert
"wannabes" in my original message, I do apologize.  But please, stop
pushing for higher-than-necessary defaults for security.

As a specific example of unnecessary default security, take the "https
everywhere" campaign.  Having https available on most servers is
definitely good.  However, if you explicitly go to
http://www.google.com/ you are redirected to the https version.  Of all
the (hundreds of?) billions of google searches done every day, how many
of them would really cause any harm at all if the communications were
unencrypted?  Yet the entire computer-using segment of society pays the
price for higher bandwidth and CPU usage.

Note that my whole argument is not about what should or shouldn't be
available.  It is about what the defaults should be.

...Marvin

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

[Richard Laager]

[ Note: I have reordered the quoted text blocks. ]

On 1/29/20 8:28 AM, Marvin Renich wrote:
> On the other hand, I do agree with using unstable and testing to
> determine the level of disruption, on the condition that there is a
> _commitment_ to removing the feature before stable release if the
> impact on usability is more than minor.

+1

I don't think we're that far apart here. There are plenty of shades of
grey in this, and what counts as "minimal", "medium", or "massive" is
going to be at least somewhat subjective.

> Even medium disruption is the
> wrong balance for a general distribution's default.

I'm willing to go a bit further than you, as I would take (again, my
subjective) "medium" disruption for a real security win, generally speaking.

> I would like to give big kudos to the AppArmor team for providing
> Debian developers and users with an exemplary experience while adding
> a security feature as a distribution default.

+1

AppArmor had the potential to cause massive breakage, and has not,
primarily due to it being opt-in. I think this has been a big success.

I would characterize AppArmor as being on the low end of "medium"
breakage. AppArmor is something that I need to care about on an on-going
basis as a sysadmin. I need to be aware it exists, how its problems will
manifest, how to debug it, and how to fix it. I can't completely ignore
it, as it does break things from time to time. This is not to say it
breaks things out-of-the-blue. It breaks things when I change
configurations away from the default. That's totally fine. I figure it
out and go add the appropriate bit to the local/tunable file.

Something minimally disruptive would be something like Address Space
Layout Randomization (ASLR). While that may have impacts on maintainers
enabling/disabling compiler flags, it is not something I ever have to
think about as a sysadmin. It is never the problem. I never need to do
anything related to it (as a sysadmin).

Something like SELinux in the RedHat world is probably still at least on
the high end of "medium" these days and could probably be characterized
as "massive breakage" in its early days. "Massive breakage" is the sort
of thing where large numbers of experienced sysadmins respond with "just
turn it off".

With what I know about this particular change right now, my assumption
is that it will cause little to no breakage. I would characterize the
expected impact as "minor". Further, I expect that any breakage will be
"one-time" breakage that can be addressed by application developers
and/or package maintainers, and it will not cause on-going work for
system administrators.

> > Unless massive breakage is expected, the default should
> > be the most secure option.

> The above
> statement implies that the default should be the maximum security that
> does _not_ cause _maximum_ disruption.

I'd say that "massive breakage" (breaking lots of things) is not the
same as "maximal disruption" (the most disruption). Maximum disruption
would be, for example, breaking things that were "fully correct" (not
doing something "dodgy") before the change. This would be a "flag day"
change. That level of disruption needs to be avoided if at all possible,
and carefully managed if completely unavoidable and worth the pain.

> Time and time again I see security expert "wannabes" pushing for the
> most security possible.  Even real experts sometimes lose sight of the
> balance between usability and security.  Unfortunately, there are a lot
> more "wannabes" than real experts, and the "wannabes" are typically much
> more vocal.

While I understand your point, I think it would be better to focus on
the arguments rather than the people making them.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: Kernel parameters protecting fifos and regular files

[Ben Hutchings]

On Wed, 2020-01-29 at 10:13 -0800, Moritz Mühlenhoff wrote:
> Craig Small  schrieb:
> > --4806c5059d3edeb1
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > Hi,
> >   About 2 years ago the procps package added protection for hard and soft
> > symlinks. The bug report was 889098 and has seemed to work fine.
> > 
> > There is also now bug #914859 which would extend this same protection for
> > other files, as mentioned in [1]
> 
> I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
> in their systemd package to set this as well (LP 1845637).
> 
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so I'd say that src:linux should be patched as well, this changes
> the default at the deepest level and the /etc/sysctl.conf kicks in for
> anyone running custom built kernels.

There was discussion around this issue on #debian-kernel recently. 
Changing the default in src:linux doesn't help people that get their
kernel from somewhere else.  Changing it in procps also doesn't cover
minimal installations since it's only Priority: important.

Is there a higher priority package, independent of init system, that
would be suitable for carrying the Debian sysctl policy?

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




signature.asc
Description: This is a digitally signed message part

Re: Kernel parameters protecting fifos and regular files

[Moritz Mühlenhoff]

Craig Small  schrieb:
> --4806c5059d3edeb1
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>   About 2 years ago the procps package added protection for hard and soft
> symlinks. The bug report was 889098 and has seemed to work fine.
>
> There is also now bug #914859 which would extend this same protection for
> other files, as mentioned in [1]

I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
in their systemd package to set this as well (LP 1845637).

protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
by default, so I'd say that src:linux should be patched as well, this changes
the default at the deepest level and the /etc/sysctl.conf kicks in for
anyone running custom built kernels.

Cheers,
Moritz

Adding security features (was: Kernel parameters protecting fifos and regular files)

[Marvin Renich]

I have no opinion about this specific feature; at first glance it looks
like it might be a reasonable thing to do.  On the other hand, I
strongly disagree with this statement as a general rule:

> Unless massive breakage is expected, the default should
> be the most secure option.

This is the wrong way around.  In a general distribution, the default
should be to use the maximum amount of security that can reasonably be
expected to cause _minimal_ disruption to usability.  The above
statement implies that the default should be the maximum security that
does _not_ cause _maximum_ disruption.  (Even medium disruption is the
wrong balance for a general distribution's default.)

Time and time again I see security expert "wannabes" pushing for the
most security possible.  Even real experts sometimes lose sight of the
balance between usability and security.  Unfortunately, there are a lot
more "wannabes" than real experts, and the "wannabes" are typically much
more vocal.

If you change "Unless massive breakage is expected" to "If breakage is
expected to be minimal", than I would agree.

On the other hand, I do agree with using unstable and testing to
determine the level of disruption, on the condition that there is a
_commitment_ to removing the feature before stable release if the impact
on usability is more than minor.

I would like to give big kudos to the AppArmor team for providing Debian
developers and users with an exemplary experience while adding a
security feature as a distribution default.  I think the rollout went so
smoothly that the AppArmor team did not get enough attention for the
terrific job they did.  That transition should be held up as a model for
implementing any big feature change in Debian.

...Marvin

Re: Kernel parameters protecting fifos and regular files

[Richard Laager]

On 1/28/20 9:23 PM, Craig Small wrote:
> My personal preference is to lock them down by default, by setting both
> to mode 2.
FWIW: I agree. Unless massive breakage is expected, the default should
be the most secure option. If you default to secure and that breaks
something, people will be motivated to fix it (either the root issue or
by changing the setting). If you default to compatible, very few people
will find the option and tweak it, so most people will lose out on the
security. If there is massive breakage, you can back it off, of course.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Kernel parameters protecting fifos and regular files

[Craig Small]

Hi,
  About 2 years ago the procps package added protection for hard and soft
symlinks. The bug report was 889098 and has seemed to work fine.

There is also now bug #914859 which would extend this same protection for
other files, as mentioned in [1]

On the one hand, having all these file types protected by default would be
very nice. On the other, it may break things in odd ways though I suspect
this is quite rare.  A system administrator is, of course, able to set
these to whatever they would like, but what should the default be?

My personal preference is to lock them down by default, by setting both to
mode 2. However the impact is way more than my handful of systems I use,
hence the wider email.

Putting it another way, are there any real strong reasons for not
doing this?
 - Craig



1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

X-Debbugs-Cc: debian-devel@lists.debian.org

On Fri, Jan 03, 2020 at 08:23:58PM +, Sudip Mukherjee wrote:
> On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank  wrote:
> >
> > Hi Marco
> >
> > On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > > On Jan 03, Sudip Mukherjee  wrote:
> > > > Do we package libbpf from their github repo independent of the kernel
> > > > update? Then we will need to remove the libbpf building bits from the
> > > > Debian kernel source and create a separate package for libbpf.
> > > This is what some of the upstream libbpf developers requested us to do.
> >
> > What I don't understand is, if the kernel git tree is the primary
> > location for this library, why should we use an external copy?
> >
> > What are the benefits of doing so?
> 
> The only benefit will be that we will be able to update the libraries
> irrespective of kernel update. libbpf v0.0.6 has been released in
> December but we will not be able to move to that version. The
> userspace application using this library is deprived of the benefit of
> the fixes that v0.0.6 brings.

Any thoughts on this please...

I have now done an initial packaging and can open an ITP if everyone
thinks we should move this out of debian kernel packaging.

And, I think I should also point out here that libtraceevent developers
are also moving to a separate repo which will have their final releases
rather then using the kernel repo. I will open a separate bug report for
them after they have decided where they want their new repo. And, libperf
might also follow suit after libtraceevent.

It might be better if we decide now what we want to do and tell them
accordingly.


--
Regards
Sudip

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

Package: src:linux
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org

libbpf source has moved to a separate github repo but keeps the kernel
as the true/first source, and updating github repo when release is ready.
In Steve's word the problem they faced is:

> The problem I'm now having is that I'm looking at fixing and updating
> some of the code in this library, and since library versioning is
> critical for applications that depend on it, we need to have a way to
> update the versions, and this does not correspond with the Linux
> versions.

So, looking at libbpf github repo at [1], I can see libbpf has already
released v0.0.6 but we only have v0.0.5 in Debian and there is no way
to update that unless the kernel is updated to v5.5+. And looking at
the kernel repo I can see libbpf people are working on v0.0.7. The full
discussion is at [2].

Do we package libbpf from their github repo independent of the kernel
update? Then we will need to remove the libbpf building bits from the
Debian kernel source and create a separate package for libbpf.
And so, it will be great if kernel team will like to package and maintain
it, if not, then I will be happy to do it. Please reject this bug report
if you think libbpf should not be done separately and should live inside
kernel source package.


[1]. https://github.com/libbpf/libbpf
[2]. https://lore.kernel.org/lkml/20200102234950.GA14768@krava/

--
Regards
Sudip

Bug#946781: ITP: kw -- Inglorious kernel developer workflow scripts

[Rodrigo Carvalho]

Package: wnpp
Severity: wishlist
Owner: Rodrigo Carvalho 

* Package name: kw
  Version : 20191112
  Upstream Author : Rodrigo Siqueira 
* URL : https://github.com/kworkflow/kworkflow
* License : GPL-2
  Programming Lang: Shell Script
  Description : Inglorious kernel developer workflow scripts

kw is a set of scripts that
have mission to reduce the overhead
related with infrastructure project setup in
projects that have a similar workflow to the Linux Kernel.

kw stands for Kernel Workflow.

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org

* Package name: libtraceevent
  Version : 1.1.0
  Upstream Author : Steven Rostedt (VMware) 
* URL : NA
* License : GPL-2.0 and LGPL-2.1
  Programming Lang: C
  Description : The libtraceevent library provides APIs to access kernel 
tracepoint events,
located in the tracefs file system under the events 
directory.

The kernel tracepoints are now being used by multiple packages like trace-cmd, 
perf, powertop, rasdaemon.
And all of them have duplicate codes in them to use the tracepoints. 
libtraceevent is planned to move all
the duplicate codes in a single library so that the duplicate code will be 
removed from the next versions
of these packages and they can depend on libtraceevent.

The code for libtracevent lives in the kernel tree at
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
tools/lib/traceevent folder.
And so, it will be great if kernel team will like to package and maintain it, 
if not, then I will
be happy to do it. But, if I am doing it then I will need a sponsor to upload 
it.

--
Regards
Sudip

Re: Debian testing daily build - no kernel modules..!!!

[Geert Stappers]

On Sun, Nov 03, 2019 at 03:56:11AM +0100, André Verwijs wrote:
> 
> 
> 
> Debian testing daily build has no kernel modules..!!!


Reason is having booted kernel version Y
and in archive available kernel modules are for version X.

This does happen  during development.
 

> daily build: 10-21-2019 still good


Mmm, that is more then a week ago.

In that week there was another report about simular inconvinence.
That was concluded with "so you just caught a bad moment"
( https://lists.debian.org/debian-boot/2019/10/msg00273.html )
 
I'm not aware if did work in the time inbetween the reports.
(The Lonnie Cumberland report and the André Verwijs report)


Please see this message as an invention for either reporting
"works for me" or "next day retry also failed".


> Dank U - Thank You

U bedankt voor het melden - Thanking you for reporting


Groeten
Geert Stappers
-- 
Leven en laten leven

Debian testing daily build - no kernel modules..!!!

[André Verwijs]

Debian testing daily build has no kernel modules..!!!

daily build: 10-21-2019 still good









Dank U - Thank You

Twitter:
http://twitter.com/OpenSimFan

Facebook:
http://www.facebook.com/andre.verwijs

Instagram:
André Verwijs - Instagram <https://instagram.com/dutchglory

Bug#939451: ITP: nvidia-cub -- cooperative threadblock primitives and other utilities for CUDA kernel programming

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: lu...@debian.org
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-nvidia-de...@lists.alioth.debian.org

* Package name: nvidia-cub
  Version : x.y.z
  Upstream Author : nvidia
* URL : https://nvlabs.github.io/cub/
* License : BSD-3-Clause
  Programming Lang: cuda, c++
  Description : cooperative threadblock primitives and other
utilities for CUDA kernel programming

I've seen this many times in different projects e.g.
https://github.com/tensorflow/tensorflow/tree/master/third_party
https://github.com/pytorch/pytorch/tree/master/third_party
https://github.com/mitsuba-renderer/enoki

It's a sensible candidate to be packaged. The source code
is free but it depends on cuda so the resulting package
has to enter contrib.

Bug#935876: ITP: octave-kernel -- Jupyter kernel for Octave (Python 3)

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: octave-kernel
  Version : 0.31.1
  Upstream Author : Steven Silvester 
* URL : https://github.com/calysto/octave_kernel
* License : BSD
  Programming Lang: Python
  Description : Jupyter kernel for Octave (Python 3)

This package integrates the use of the Octave language within
the Jupyter Notebook by providing a kernel that communicates
using the standard API with the octave-cli.  It also handles
plotting and displays graphs within the notebook as expected.

Kernel

[anon user]

just a note to tell you that I installed the Kali 5.2.9  kernel into Debian 
10with dpkg -i -a  AND it worked !!
there were two pkgs for it.  load averages are now very low.
I tried with the source but it failed !!  don't know why ??Oh.. this was in a 
VMware 15.0  virtual machine.

anyway happyness ;D
thanks for ALL that you do
*DHF*

Bug#933766: ITP: roct-thunk-interface -- HSA Kernel Mode Thunk library for AMD KFD support

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 

* Package name: roct-thunk-interface
  Version : 2.6.0
  Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface
* License : MIT
  Programming Lang: C
  Description : HSA Kernel Mode Thunk library for AMD KFD support

 HSA Kernel Mode Thunk library contains the user-mode API interfaces used to 
interact
 with the ROCk driver.

This is part or ROCm - Open Source Platform for HPC and Ultrascale GPU 
Computing .

Processed: kernel bug it seems

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 931290 linux-image-4.9.0-9-amd64
Bug #931290 [general] general: Asrock A300 Deskmini AMD Athlon 200GE ends in 
black screen Monitor has no Signal
Bug reassigned from package 'general' to 'linux-image-4.9.0-9-amd64'.
Ignoring request to alter found versions of bug #931290 to the same values 
previously set
Ignoring request to alter fixed versions of bug #931290 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
931290: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931290
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#931354: ITP: cryptodev-linux -- kernel module for accessing Linux kernel cryptographic drivers

[Dmitry Eremin-Solenikov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Eremin-Solenikov 

* Package name: cryptodev-linux
  Version : 1.10
  Upstream Author : Cristian Stoica 
* URL : http://cryptodev-linux.org/
* License : GPLv2+
  Programming Lang: C
  Description : kernel module for accessing Linux kernel cryptographic 
drivers

 Cryptodev-linux is a device that allows access to Linux kernel
 cryptographic drivers; thus allowing of userspace applications to take
 advantage of hardware accelerators. Cryptodev-linux is implemented as a
 standalone module that requires no dependencies other than a stock
 linux kernel. Its API is compatible with OpenBSD's cryptodev userspace
 API (/dev/crypto).

Please revert LTS kernel change that will break ZFS for Buster point releases

[Mo Zhou]

control: severity -1 grave

Dear kernel maintainers,

Buster will be released with 4.19.37 kernel. That's fine
and it doesn't break ZFS. However, the changes introduced
in 4.19.38 and linux 5.0 break ZFS. That means the current
0.7.12-2 will fail to build everywhere after the first
Buster point release (with kernel version bump).
A foreseeable stable RC is grave enough.

Upstream has made a compromise to disable SIMD for kernels
that received the breaking change:
 
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730

Based on these, we Debian ZoL maintainers have several
possible choices:

1. unblock 0.7.13-1 (see rmadison -S zfs-linux)
   (it contains the above patch)
2. revert debdiff(0.7.12-2,0.7.12-5), apply the upstream
   patch and upload 0.7.12-6 through t-p-u.
3. ask kernel maintainers to revert problematic commits

Freeze policy makes it difficult for the release team to
accept solution 1. Solution 2 is able to eliminate bugs
but I doubt how useful a SIMD-less ZFS is. Compared to
the others, solution 3 is the best solution because there
won't be any future breakage or significant performance loss.

My position is solution 3, as it's the ***LTS KERNEL UPDATE***
that introduced breaking change breaks ZFS 0.7.12-2.
It's not a bug of ZFS 0.7.12-2 at all.

Debian ZFS users are sensitive because I and Aron often
receive private user reports and prodding mails. That means
reverting the problematic kernel commit is beneficial to
our users. Our priorities are our users and free software,
NOT to stick to the problematic breaking LTS update.

I believe this is a kernel bug. Instead of submitting
a grave RC for the 10.1 release, we'd better sort it out
right now before the Buster release.

Thanks,
Mo

Bug#910662: ITP: gost-crypto -- Linux kernel modules implementing GOST cryptography

[Dmitry Eremin-Solenikov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Eremin-Solenikov 

* Package name: gost-crypto
  Version : 0.1
  Upstream Author : Dmitry Eremin-Solenikov 
* URL : https://github.com/GostCrypt/linux-crypto
* License : GPL-2+
  Programming Lang: C
  Description : Linux kernel modules implementing GOST cryptography

 This is a set of Linux kernel modules implementing Russian cryptographic 
algorithms:

 - GOST 28147 cipher (RFC 5830)
 - GOST 28147 "Imitovstavka" (MAC mode) (RFC 5830)
 - GOST R 34.11-94 digest (RFC 5831)
   - HMAC using GOST R 34.11-94 (RFC 4357)
 - GOST R 34.12-2015 ciphers (Magma and Kuznyechik) (RFC 7801)
   - CMAC using GOST R 34.12-2015 (as required by GOST R 34.13-2015)
 - GOST R 34.11-2012 digest (RFC 6986)

Re: Question regarding patching in 4.9 kernel

[Andrey Rahmatullin]

On Thu, Sep 27, 2018 at 02:28:35AM +, Harish Venkatraman wrote:
> Hi Ben, 
> 
> I am trying to manually back port to Linux 4.9 since in the link I don’t see 
> a patch provided for 4.9 version. The last version that has this patch is 
> 4.11, wanted to know if back port of this patch is supported on Linux 4.9 or 
> this patch is supported only from 4.11?
This is a wrong place to ask though, as this question is not related to
Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Question regarding patching in 4.9 kernel

[Harish Venkatraman]

Hi Ben, 

I am trying to manually back port to Linux 4.9 since in the link I don’t see a 
patch provided for 4.9 version. The last version that has this patch is 4.11, 
wanted to know if back port of this patch is supported on Linux 4.9 or this 
patch is supported only from 4.11?

Sent from my iPhone

> On Sep 26, 2018, at 6:45 PM, Ben Hutchings  wrote:
> 
> [Note Reply-to: debian-kernel.]
> 
>> On Wed, 2018-09-26 at 18:00 +, Harish Venkatraman wrote:
>> Hi,
>> 
>> I want the following patch to be back ported to 4.9 kernel. Can you
>> please let me know if it can be back ported to 4.9 kernel?
>> 
>> https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8
> 
> I assume you're talking about Linux 4.9 as used in Debian 9 "stretch".
> Debian doesn't normally add features to stable releases, so I don't see
> why would we do this.

> Ben.
> 
> -- 
> Ben Hutchings
> Beware of programmers who carry screwdrivers. - Leonard Brandwein
> 
> 

Re: Question regarding patching in 4.9 kernel

[Ben Hutchings]

[Note Reply-to: debian-kernel.]

On Wed, 2018-09-26 at 18:00 +, Harish Venkatraman wrote:
> Hi,
> 
> I want the following patch to be back ported to 4.9 kernel. Can you
> please let me know if it can be back ported to 4.9 kernel?
> 
> https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8

I assume you're talking about Linux 4.9 as used in Debian 9 "stretch".
Debian doesn't normally add features to stable releases, so I don't see
why would we do this.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein




signature.asc
Description: This is a digitally signed message part

Question regarding patching in 4.9 kernel

[Harish Venkatraman]

Hi,

I want the following patch to be back ported to 4.9 kernel. Can you please let 
me know if it can be back ported to 4.9 kernel?

https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8

Thanks

Bug#904401: ITP: python-uinput -- Pythonic API to Linux uinput kernel module.

[أحمد المحم]

Package: wnpp
Severity: wishlist
Owner: "أحمد المحمودي (Ahmed El-Mahmoudy)" 

* Package name: python-uinput
  Version : 0.11.2
  Upstream Author : Tuomas Räsänen 
* URL : http://tjjr.fi/sw/python-uinput/
* License : GPL-3+
  Programming Lang: Python
  Description : Pythonic API to Linux uinput kernel module.

Python-uinput is Python interface to Linux uinput kernel module which 
allows attaching userspace device drivers into kernel. In
practice, Python-uinput makes it dead simple to create virtual 
joysticks, keyboards and mice for generating arbitrary input
events programmatically.
 
 
 - This package is needed by new versions of xpra

 - I intend to maintain the package under Python modules team

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#871613: general: Kernel Panic caused by smp.c:127 check_preempt_curr

[fran]

Package: general
Followup-For: Bug #871613

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#901679: ITP: r-cran-kedd -- Kernel Estimator+Bandwidth Selection - Density+Derivatives

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-kedd
* URL : https://cran.r-project.org/package=kedd
* License : GPL-2+
  Programming Lang: R
  Description : Kernel Estimator+Bandwidth Selection - Density+Derivatives

The package is team-maintained on
https://salsa.debian.org/r-pkg-team/r-cran-kedd

Bug#901130: ITP: anbox-modules -- Android kernel driver (binder, ashmem) in DKMS format

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: anbox-modules-dkms
  Version : 0.0~git20180608
  Upstream Author : Simon Fels 
* URL : https://github.com/anbox/anbox-modules/
* License : GPL-2
  Programming Lang: C
  Description : Android kernel driver (binder, ashmem) in DKMS format

 This package contains a out-of-tree version of the core Android
 kernel functionalities binder and ashmem.
 .
 Anbox is a container-based approach to boot a full Android system on a regular
 GNU/Linux system.
 .
 To run Android system in a container, you must have these modules.

Re: Reiser4 Kernel 4.15.15 and Upgraded wireless-regdb for Debian AMD64

[Andrey Rahmatullin]

On Tue, Apr 03, 2018 at 11:52:26PM -0700, Metztli Information Technology wrote:
> there is only a small hack to debian-example in git source for 
> wireless-regdb, from upstream, thus created attached patch for
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
Please create a patch for the official Debian package instead and send it
to #892229.

> I built *both* packages (nmu .1 and -1) and made available *without* 
> guarantee to solve your particular relevant issue:
But it's not an issue.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Reiser4 Kernel 4.15.15 and Upgraded wireless-regdb for Debian AMD64

[Metztli Information Technology]

Niltze-

Built reiser4 enhanced Linux 4.15.15 wrapped by Debian packaging for kernel 
4.15.11 (last I found) modified for GCC6 stretch-backports AMD64.

Upon booting kernel in wireless maching, it complained about:

platform regulatory.0: firmware: failed to load regulatory.db (-2)
[   12.134223] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   12.134281] platform regulatory.0: Direct firmware load for regulatory.db 
failed with error -2
[   12.134283] cfg80211: failed to load regulatory.db

Doing an online search it seems this is a 'feature' of kernels 4.15.x, i.e., 
below is for Slackware:

< 
https://www.linuxquestions.org/questions/linux-kernel-70/kernel-platform-regulatory-0-direct-firmware-load-for-regulatory-db-failed-with-error-2-a-4175622954/
 >

Notwithstanding, Debian seems to be lacking relevant files in ~2016 
(last/latest) wireless-regdb package.

Although I created a repo at Github

< https://metztli.github.io/wireless-regdb-metztli/ .

there is only a small hack to debian-example in git source for wireless-regdb, 
from upstream, thus created attached patch for

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git

cd wireless-regdb

cat debian-upgraded-regulatory-regdb-for-4.15x.patch | patch -p1

dpkg-buildpackage -F -us -uc -j2 -T binary

Generates upgraded wireless-regdb_2018.04.02-1_all.deb

./lib/firmware/
./lib/firmware/regulatory.db  #1} Specifically
./lib/firmware/regulatory.db.p7s  #2} Linux 4.15.x needs
./usr/
./usr/lib/
./usr/lib/crda/
./usr/lib/crda/regulatory.bin #3} these upgraded files.
./usr/share/
./usr/share/doc/
./usr/share/doc/wireless-regdb/
./usr/share/doc/wireless-regdb/README
./usr/share/doc/wireless-regdb/changelog.Debian.gz
./usr/share/doc/wireless-regdb/copyright

Of course, also
apt-get install crda
as it is recent from Debian repositories.

I built *both* packages (nmu .1 and -1) and made available *without* guarantee 
to solve your particular relevant issue:

https://metztli.it/readOnlyEphemeral/wireless-regdb_2018.04.02-1_all.deb

https://metztli.it/readOnlyEphemeral/crda_3.18-1.1_amd64.deb

They fix the above wireless regulatory.db issue(s) in my machine.


Best Professional Regards.


-- 
Jose R R
http://metztli.it
-
Download Metztli Reiser4: Debian Stretch w/ Linux 4.14 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/


debian-upgraded-regulatory-regdb-for-4.15x.patch
Description: Binary data

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Raju,

On Fri, Feb 16, 2018 at 09:18:06PM +0530, Raju Devidas wrote:
> Hello Kumar,
> 
> I took a look at your repository on salsa. 
> Before taking a look at your repository I have also taken a look at some
> other repositories on github which had steps for
> supporting Ubuntu on the RDP.
> 
> Specially this one.
> 
> https://github.com/sundarnagarajan/rdp-thinbook-linux
> 

Indeed. I have adapted the sound and bluetooth configuration in my
repository from that one. The author of that repository has helped me
in getting my ISO remade with all features working.

> Most of the repositories including yours do handle the issue of getting
> custom Debian/Ubuntu installed on Debian with everything working.
> 
> And I thank you and others for your work regarding this.
> 
> However it does not solve the scenario wherein, if someone has already
> installed Debian or any derivative of it, how do I get things working up
> there?
> 
> In my case I have already installed Hamara Sugam on RDP Thinbook 1130.
> 
> By following a few steps from Sundar Nagarajan's repository, I have got
> Wi-Fi working.
> 
> Sound is not working. Bluetooth works sometimes, sometimes not.
> 
> I also tried installing firmware-intel-sound from the firmware-nonfree
> package as suggested by Praveen.
> 
> But that didn't solved the issue either.
> 
> 
> Let me know of a way which can add support to already installed
> operating systems on the RDP.
> 
> Also in your mail you mentioned about your own repo which would be added
> by default on the pre-installed debian systems of RDP.
> 
> If I can get the URL of the repo, may be I can get some packages from
> there to make things working.

Currently, I have not made the custom repository. I can share the URL
of my preseeded configuration generated ISO, though that is designed
more for an OEM-style install (it destroys the data on the PC and
recreates a fresh stretch install) and it is still under development
(in sync with my salsa repository).

In you case, my suggestion would be to mail me offline and I can guide
you. But the short story for sound is that you should get the
sound-config.tar.gz from my repository:

https://salsa.debian.org/akumar/debian-installer-rdp-thinbook/raw/master/sound-config.tar.gz

Extract the files to /root and run /root/hardware/sound/install.sh.

For more help, just mail me off-list. Also, I can share the ISO I
build using the above repository; I am not publishing the URL yet
because it is still evolving.

Thanks.

Kumar

-- 
*** PUBLIC flooding detected from erikyyy
 THAT's an erik, pholx ;)
-- Seen on #LinuxGER

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Raju Devidas]

Hello Kumar,

I took a look at your repository on salsa. 
Before taking a look at your repository I have also taken a look at some
other repositories on github which had steps for
supporting Ubuntu on the RDP.

Specially this one.

https://github.com/sundarnagarajan/rdp-thinbook-linux


Most of the repositories including yours do handle the issue of getting
custom Debian/Ubuntu installed on Debian with everything working.

And I thank you and others for your work regarding this.

However it does not solve the scenario wherein, if someone has already
installed Debian or any derivative of it, how do I get things working up
there?

In my case I have already installed Hamara Sugam on RDP Thinbook 1130.

By following a few steps from Sundar Nagarajan's repository, I have got
Wi-Fi working.

Sound is not working. Bluetooth works sometimes, sometimes not.

I also tried installing firmware-intel-sound from the firmware-nonfree
package as suggested by Praveen.

But that didn't solved the issue either.


Let me know of a way which can add support to already installed
operating systems on the RDP.

Also in your mail you mentioned about your own repo which would be added
by default on the pre-installed debian systems of RDP.

If I can get the URL of the repo, may be I can get some packages from
there to make things working.



Thanks,
Raju Devidas

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware (an update)

[Kumar Appaiah]

Dear Vincent,

On Sat, Feb 10, 2018 at 08:37:59PM +0100, Vincent Bernat wrote:
>  ❦ 11 février 2018 00:05 +0530, Kumar Appaiah  :
> 
> > - Adding my custom patched rfkill DKMS package and ensuring that
> >   linux-headers is also installed, so that I can use the
> >   preseed/late_command to build the DKMS module.
> 
> dkms is able to build an udeb you can ship with the installer. This can
> be done with "dkms mkmdeb" (this also provides a regular deb).

Thanks. Since I don't really need Bluetooth during the installer, I
didn't bother. But this is good to know.

Kumar


-- 
...you might as well skip the Xmas celebration completely, and instead
sit in front of your linux computer playing with the all-new-and-improved
linux kernel version.
-- Linus Torvalds

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware (an update)

[Vincent Bernat]

 ❦ 11 février 2018 00:05 +0530, Kumar Appaiah  :

> - Adding my custom patched rfkill DKMS package and ensuring that
>   linux-headers is also installed, so that I can use the
>   preseed/late_command to build the DKMS module.

dkms is able to build an udeb you can ship with the installer. This can
be done with "dkms mkmdeb" (this also provides a regular deb).
-- 
Sometimes I wonder if I'm in my right mind.  Then it passes off and I'm
as intelligent as ever.
-- Samuel Beckett, "Endgame"


signature.asc
Description: PGP signature

Maintaining a custom out-of-tree patched Debian kernel for specific hardware (an update)

[Kumar Appaiah]

Dear Debian Developers,

This is a follow-up to
https://lists.debian.org/debian-devel/2018/01/msg00461.html
(Message-ID: <20180122140840.GA4580@odessa>).

Some good people in the thread above mentioned that maintaing a forked
kernel merely for two one-line patches is too much. I disagreed
initially, but then, found that in recent kernels, one of the patches
is not needed. For the other (related to rfkill), I managed to make a
custom DKMS package with the patch included here:

https://github.com/kumanna/rfkill-dkms

Luckily, this seems to work.

So, my customization of an official Debian ISO consists of:

- Grabbing a stable DVD ISO.

- Replacing the installed kernel with a more recent one from backports
  (should be unnecessary for testing) and ensuring that it gets chosen
  via preseed.

- Adding custom scripts for enabling sound and bluetooth (preseeding)
  grabbed from https://github.com/sundarnagarajan/rdp-thinbook-linux

- Adding the non-free firmware that is needed for wireless and sound.

- Adding my custom patched rfkill DKMS package and ensuring that
  linux-headers is also installed, so that I can use the
  preseed/late_command to build the DKMS module.

My current (hack) is documented here:
https://gitlab.com/kumanna/debian-installer-rdp

I intend moving this to salsa.debian.org and improving this
customization.

With thanks to the previous responders, I wanted to know if there are
other things I should keep in mind. Let me know if I have missed any details.

Thanks.

Kumar
-- 
We apologize for the inconvenience, but we'd still like yout to test out
this kernel.
-- Linus Torvalds, announcing another kernel patch

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Ian,

On Tue, Jan 23, 2018 at 02:08:48PM +, Ian Campbell wrote:
> > > Also, the patches being that small, what's stopping them from
> > > being upstreamed?
> > 
> > This is something beyond my understanding. Other distributions, such
> > as Linux Mint, Ubuntu etc. also do not possess those patches and
> > config changes. My hunch is that the Cherry Trail processors may not
> > be considered popular enough for inclusion in mainline at least
> > yet. So, we are going with this approach for now. Naturally, when
> > that's done, we'll offer a migration path to the stock Debian kernel
> > and the need for this hack will be gone.
> 
> The patches appear to be one new ACPI match[0] and some changes to some
> debug messages[1] (marked with a ".optional" suffix, so probably not
> really needed). Forking the kernel packages for those trivial changes
> is _way_ overkill for a first response. If those patches had been
> submitted them upstream then I would expect them to be quickly and
> easily merged into the relevant maintainer tree and thus be elligible
> for application to the Debian kernels.
> 
> I don't know if the kernel config changes/requirements in [2] are
> complete but if they are then they seem equally trivial and certainly
> worth of a discussion with the Debian kernel maintainers before
> deciding to fork.
> 
> Even simple forks are deceptively hard to back away from so avoiding
> forking for trival reasons is usually a good default, or else you could
> easily find yourself stuck with it for an extended period of time.
> 
> Googling around suggests that Cherry Trail is supported in mainline
> Linux today, with some last issues having been resolved in 4.11 (see
> e.g. [3]).

Thanks for pointing this out. Indeed, I would agree that this is the
case. However, the current timeline doesn't permit me to wait for this
process to happen, though I'll try to do it in parallel. My
expectation is that the fork will be short lived, and eventually, the
repository will provide a transition to the general Debian kernel and
be removed soon. However, I'll try my best to avoid it in the first
place, if time permits.

> Ian.
> 
> [0] 
> https://github.com/sundarnagarajan/kernel_build/blob/master/patches/001_rfkill_bluetooth_rtl8723bs_bt.patch
> [1] 
> https://github.com/sundarnagarajan/kernel_build/blob/master/patches/002_rtl8723bs_nolinked_power_save_enter.patch.optional
> [2] https://github.com/sundarnagarajan/kernel_build/blob/master/config.prefs
> [3] 
> https://liliputing.com/2017/03/linux-4-11-brings-improvements-intel-atom-pcs-bay-trail-cherry-trail.html
> 

Thanks.

Kumar
-- 
Linux: the operating system with a CLUE... Command Line User Environment.
-- seen in a posting in comp.software.testing

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Ian Campbell]

On Tue, 2018-01-23 at 18:20 +0530, Kumar Appaiah wrote:
> On Tue, Jan 23, 2018 at 10:27:06AM -0200, Antonio Terceiro wrote:
> > On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote:
> > > Dear Debian Developers,
> > > 
> > > I am part of a team working on getting Debian on low cost laptops
> > > (see
> > > http://www.rdp.in for details) so that they can be sold with
> > > Debian
> > > preinstalled. While vanilla Debian largely works, unfortunately,
> > > making Bluetooth and sound work require kernel rebuilding. The
> > > patches
> > > and config changes are not likely to be upstreamed any time soon,
> > > so
> > > we would have to ship the laptop with a patched (non-Debian
> > > kernel). Our team is, thus, taking up the responsibility of
> > > ensuring
> > > that up-to-date kernel (with security fixes) are made available
> > > to the
> > > users of our laptop. The patches and configs are adapted from
> > > here:
> > > https://github.com/sundarnagarajan/kernel_build
> > 
> > Are the the patches you need are really just those in patches/? If
> > yes,
> > they are small enough that if I were in your place I would talk to
> > the
> > Debian kernel team to see if they can be included in the official
> > Debian
> > kernel.
> > 
> > Also, the patches being that small, what's stopping them from
> > being upstreamed?
> 
> This is something beyond my understanding. Other distributions, such
> as Linux Mint, Ubuntu etc. also do not possess those patches and
> config changes. My hunch is that the Cherry Trail processors may not
> be considered popular enough for inclusion in mainline at least
> yet. So, we are going with this approach for now. Naturally, when
> that's done, we'll offer a migration path to the stock Debian kernel
> and the need for this hack will be gone.

The patches appear to be one new ACPI match[0] and some changes to some
debug messages[1] (marked with a ".optional" suffix, so probably not
really needed). Forking the kernel packages for those trivial changes
is _way_ overkill for a first response. If those patches had been
submitted them upstream then I would expect them to be quickly and
easily merged into the relevant maintainer tree and thus be elligible
for application to the Debian kernels.

I don't know if the kernel config changes/requirements in [2] are
complete but if they are then they seem equally trivial and certainly
worth of a discussion with the Debian kernel maintainers before
deciding to fork.

Even simple forks are deceptively hard to back away from so avoiding
forking for trival reasons is usually a good default, or else you could
easily find yourself stuck with it for an extended period of time.

Googling around suggests that Cherry Trail is supported in mainline
Linux today, with some last issues having been resolved in 4.11 (see
e.g. [3]).

Ian.

[0] 
https://github.com/sundarnagarajan/kernel_build/blob/master/patches/001_rfkill_bluetooth_rtl8723bs_bt.patch
[1] 
https://github.com/sundarnagarajan/kernel_build/blob/master/patches/002_rtl8723bs_nolinked_power_save_enter.patch.optional
[2] https://github.com/sundarnagarajan/kernel_build/blob/master/config.prefs
[3] 
https://liliputing.com/2017/03/linux-4-11-brings-improvements-intel-atom-pcs-bay-trail-cherry-trail.html

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Ian Campbell]

On Tue, 2018-01-23 at 17:53 +0530, Kumar Appaiah wrote:
> > You should definitately give the package a distinct version and you
> > should _probably_ give it either a distinct ABI or flavour (or possibly
> > both). You will probably also want to put a digit in your distinct ABI
> > so you can rev it if needed.
> 
> Thanks for pointing this out. Do you mean something like
> linux-image-4.14.13-2-iitb-amd64?

Something like that, yes.

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Daniel Reichelt]

On 01/23/2018 10:56 AM, Philipp Kern wrote:
> On 01/23/2018 01:34 AM, Daniel Reichelt wrote:
>> In order to not interfere with the modules provided by the linux-image-*
>> packages, [...]
>> (An alternative to changing module names might be to use
>> update-alternatives or dpkg-divert and just provide/integrate the
>> renamed .ko files)
> FWIW, this technically isn't required. You can simply overwrite existing
> modules and dkms will handle that fine. It will shadow the stock ones
> when putting the new versions into updates/dkms.
> 
> Kind regards
> Philipp Kern

Thanks for pointing that out!




signature.asc
Description: OpenPGP digital signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

On Tue, Jan 23, 2018 at 10:27:06AM -0200, Antonio Terceiro wrote:
> On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote:
> > Dear Debian Developers,
> > 
> > I am part of a team working on getting Debian on low cost laptops (see
> > http://www.rdp.in for details) so that they can be sold with Debian
> > preinstalled. While vanilla Debian largely works, unfortunately,
> > making Bluetooth and sound work require kernel rebuilding. The patches
> > and config changes are not likely to be upstreamed any time soon, so
> > we would have to ship the laptop with a patched (non-Debian
> > kernel). Our team is, thus, taking up the responsibility of ensuring
> > that up-to-date kernel (with security fixes) are made available to the
> > users of our laptop. The patches and configs are adapted from here:
> > https://github.com/sundarnagarajan/kernel_build
> 
> Are the the patches you need are really just those in patches/? If yes,
> they are small enough that if I were in your place I would talk to the
> Debian kernel team to see if they can be included in the official Debian
> kernel.
> 
> Also, the patches being that small, what's stopping them from
> being upstreamed?

This is something beyond my understanding. Other distributions, such
as Linux Mint, Ubuntu etc. also do not possess those patches and
config changes. My hunch is that the Cherry Trail processors may not
be considered popular enough for inclusion in mainline at least
yet. So, we are going with this approach for now. Naturally, when
that's done, we'll offer a migration path to the stock Debian kernel
and the need for this hack will be gone.

Thanks.

Kumar
-- 
lp1 on fire
(One of the more obfuscated kernel messages)

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

On Tue, Jan 23, 2018 at 10:02:55AM +, Ian Campbell wrote:
> On Mon, 2018-01-22 at 19:38 +0530, Kumar Appaiah wrote:
> > 1. The laptop will ship with stretch preinstalled, but with a custom
> > kernel built using the linux-source-x.xx.xx package with a custom
> > version number, such as linux-image-4.14.13-iitb-amd64.
> 
> A silly nitpick but the "4.14.13-iitb-amd64" in package a named "linux-
> image-4.14.13-iitb-amd64" is actually the kernel ABI (4.14.13-iitb) and
> arch (amd64) which is not exactly/necessarily the same as the version.
> There is also a third field "flavour" which you don't have here but
> which would go between the two e.g. "linux-image-4.14.0-3-rt-amd64" is
> a rt patched kernel.
> 
> You should definitately give the package a distinct version and you
> should _probably_ give it either a distinct ABI or flavour (or possibly
> both). You will probably also want to put a digit in your distinct ABI
> so you can rev it if needed.

Thanks for pointing this out. Do you mean something like
linux-image-4.14.13-2-iitb-amd64?

> > 4. Users will be made aware of the fact that this is Debian with a
> > custom kernel without ambiguity.
> 
> I _think_ you can add hooks/files to the package so that reportbug DTRT
> here, but I don't know the specifics of how.

I will figure this out. Thanks for the suggestion.

Kumar
-- 
...[Linux's] capacity to talk via any medium except smoke signals.
-- Dr. Greg Wettstein, Roger Maris Cancer Center

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Daniel,

On Tue, Jan 23, 2018 at 01:34:32AM +0100, Daniel Reichelt wrote:
> Hi,
> 
> what about ripping out the affected kernel modules and provide the
> patched sources in a separate package and have them built at install
> time via DKMS?
> 
> In order to not interfere with the modules provided by the linux-image-*
> packages, you could
> 
> - rename the kernel modules provided by your module package
> - add the original module names to a blacklist in /etc/modprobe.d
> - add your modules to /etc/modules-load.d/something
> - and finally add the blacklist and load list to your package as well.
> 
> (An alternative to changing module names might be to use
> update-alternatives or dpkg-divert and just provide/integrate the
> renamed .ko files)
> 
> The initial setup of the packaging/build script will require a bit of
> fiddling around but in the long run you'll be able to provide your users
> with updates much faster and without havingt to go through the
> time-consuming kernel build process. Moreover, the required storage and
> bandwith for the infrastructure holding your repository will be tiny
> compared to those for holding a full-blown kernel package.

Thanks for the idea. The reason we don't prefer this at the moment is
two-fold:

1. This would lead to "forking" some parts of the kernel source and
having to track them separately.

2. More importantly, we hope that this is a temporary measure, since
we hope that the patches will be eventuall upstreamed and the kernel
configs will also reflect the changes required.

If this becomes a longer term requirement, I will use your idea
though.

Thanks.

Kumar
-- 
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed.
-- Linus Torvalds, announcing kernel 1.3.3

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Antonio Terceiro]

On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote:
> Dear Debian Developers,
> 
> I am part of a team working on getting Debian on low cost laptops (see
> http://www.rdp.in for details) so that they can be sold with Debian
> preinstalled. While vanilla Debian largely works, unfortunately,
> making Bluetooth and sound work require kernel rebuilding. The patches
> and config changes are not likely to be upstreamed any time soon, so
> we would have to ship the laptop with a patched (non-Debian
> kernel). Our team is, thus, taking up the responsibility of ensuring
> that up-to-date kernel (with security fixes) are made available to the
> users of our laptop. The patches and configs are adapted from here:
> https://github.com/sundarnagarajan/kernel_build

Are the the patches you need are really just those in patches/? If yes,
they are small enough that if I were in your place I would talk to the
Debian kernel team to see if they can be included in the official Debian
kernel.

Also, the patches being that small, what's stopping them from
being upstreamed?


signature.asc
Description: PGP signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

On Tue, Jan 23, 2018 at 10:14:42AM +0100, Jonas Smedegaard wrote:
> > Thanks. I'll keep this in mind. The only point I'd like to emphasize 
> > is that we are clear that ours will NOT be a derived distribution; our 
> > Debian will have only a few kernel line diffs with the pristine 
> > Debian, and no further changes. And, like I have pointed our to Ian, 
> > we intend informing the users that this is the case, and provide the 
> > changes we have made through the same distribution channel as our 
> > modified packages.
> 
> Technically _any_ derivation from Debian makes it a derivative, but I 
> understand your point and appreciate it quite much!

Indeed, I agree with you technically, though I am glad you comprehend
my spirit! :-)

Kumar
-- 
Avoid the Gates of Hell.  Use Linux
(Unknown source)

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Ian Campbell]

On Mon, 2018-01-22 at 19:38 +0530, Kumar Appaiah wrote:
> 1. The laptop will ship with stretch preinstalled, but with a custom
> kernel built using the linux-source-x.xx.xx package with a custom
> version number, such as linux-image-4.14.13-iitb-amd64.

A silly nitpick but the "4.14.13-iitb-amd64" in package a named "linux-
image-4.14.13-iitb-amd64" is actually the kernel ABI (4.14.13-iitb) and
arch (amd64) which is not exactly/necessarily the same as the version.
There is also a third field "flavour" which you don't have here but
which would go between the two e.g. "linux-image-4.14.0-3-rt-amd64" is
a rt patched kernel.

You should definitately give the package a distinct version and you
should _probably_ give it either a distinct ABI or flavour (or possibly
both). You will probably also want to put a digit in your distinct ABI
so you can rev it if needed.

> 4. Users will be made aware of the fact that this is Debian with a
> custom kernel without ambiguity.

I _think_ you can add hooks/files to the package so that reportbug DTRT
here, but I don't know the specifics of how.

Ian.

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Philipp Kern]

On 01/23/2018 01:34 AM, Daniel Reichelt wrote:
> In order to not interfere with the modules provided by the linux-image-*
> packages, [...]
> (An alternative to changing module names might be to use
> update-alternatives or dpkg-divert and just provide/integrate the
> renamed .ko files)
FWIW, this technically isn't required. You can simply overwrite existing
modules and dkms will handle that fine. It will shadow the stock ones
when putting the new versions into updates/dkms.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Jonas Smedegaard]

Quoting Kumar Appaiah (2018-01-23 01:02:04)
> On Mon, Jan 22, 2018 at 04:29:22PM +0100, Jonas Smedegaard wrote:
>>> 1. The laptop will ship with stretch preinstalled, but with a custom 
>>> kernel built using the linux-source-x.xx.xx package with a custom 
>>> version number, such as linux-image-4.14.13-iitb-amd64.
>>> 
>>> 2. The installation will contain a package called 
>>> linux-image-iitb-amd64 that conflicts with linux-image-amd64, and 
>>> this package will depend on the latest patched kernel built in the 
>>> previous step.
>>
>> Specifically regarding repackaging and versioning of derived 
>> packages, I recommend that you follow the guidelines for Derivatives: 
>> https://wiki.debian.org/Derivatives/Guidelines#Packages
>>
>> You might find other things in that and related wiki pages useful too
>> :-)
>
> Thanks. I'll keep this in mind. The only point I'd like to emphasize 
> is that we are clear that ours will NOT be a derived distribution; our 
> Debian will have only a few kernel line diffs with the pristine 
> Debian, and no further changes. And, like I have pointed our to Ian, 
> we intend informing the users that this is the case, and provide the 
> changes we have made through the same distribution channel as our 
> modified packages.

Technically _any_ derivation from Debian makes it a derivative, but I 
understand your point and appreciate it quite much!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Daniel Reichelt]

Hi,

what about ripping out the affected kernel modules and provide the
patched sources in a separate package and have them built at install
time via DKMS?

In order to not interfere with the modules provided by the linux-image-*
packages, you could

- rename the kernel modules provided by your module package
- add the original module names to a blacklist in /etc/modprobe.d
- add your modules to /etc/modules-load.d/something
- and finally add the blacklist and load list to your package as well.

(An alternative to changing module names might be to use
update-alternatives or dpkg-divert and just provide/integrate the
renamed .ko files)

The initial setup of the packaging/build script will require a bit of
fiddling around but in the long run you'll be able to provide your users
with updates much faster and without havingt to go through the
time-consuming kernel build process. Moreover, the required storage and
bandwith for the infrastructure holding your repository will be tiny
compared to those for holding a full-blown kernel package.


Cheers

Daniel


On 01/22/2018 03:08 PM, Kumar Appaiah wrote:
> Dear Debian Developers,
> 
> I am part of a team working on getting Debian on low cost laptops (see
> http://www.rdp.in for details) so that they can be sold with Debian
> preinstalled. While vanilla Debian largely works, unfortunately,
> making Bluetooth and sound work require kernel rebuilding. The patches
> and config changes are not likely to be upstreamed any time soon, so
> we would have to ship the laptop with a patched (non-Debian
> kernel). Our team is, thus, taking up the responsibility of ensuring
> that up-to-date kernel (with security fixes) are made available to the
> users of our laptop. The patches and configs are adapted from here:
> https://github.com/sundarnagarajan/kernel_build
> 
> The unfortunate situation is that I am forced to issue this patched
> kernel. Since I'd like to be a good citizen of the ecosystem, I'd like
> to outline the solution I have in mind. I'd like your opinion and
> suggestion on this. All code being developed for this purpose will be
> released under a DFSG compliant license, and all packages I refer to
> that aren't in Debian will lie in our custom (outside of Debian)
> repository. If there are any things I can do to make things better,
> please do let me know.
> 
> 1. The laptop will ship with stretch preinstalled, but with a custom
> kernel built using the linux-source-x.xx.xx package with a custom
> version number, such as linux-image-4.14.13-iitb-amd64.
> 
> 2. The installation will contain a package called
> linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this
> package will depend on the latest patched kernel built in the previous
> step.
> 
> 3. The sources.list on the installation will have an entry pointing to
> my custom repository in addition to the regular http://deb.debian.org,
> and will be pinned so that the kernel and kernel related packages are
> obtained from my custom repository. Needless to say, the custom
> repository's public key will also be pre-shipped with the laptop.
> 
> 4. Users will be made aware of the fact that this is Debian with a
> custom kernel without ambiguity.
> 
> Now, whenever there is a kernel update in Debian, our team will fetch
> the source of the updated kernel, patch, rebuild and make it available
> in our repository.
> 
> Please let me know if the proposed solution is good, else I am open to
> suggestions.
> 
> Thanks.
> 
> Kumar
> 




signature.asc
Description: OpenPGP digital signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Jonas,

Good to hear from you.
On Mon, Jan 22, 2018 at 04:29:22PM +0100, Jonas Smedegaard wrote:
> Hi Kumar,
> 
> Quoting Kumar Appaiah (2018-01-22 15:08:41)
> > I am part of a team working on getting Debian on low cost laptops (see 
> > http://www.rdp.in for details) so that they can be sold with Debian 
> > preinstalled.
> 
> Looks quite interesting! Thanks for packaging raising questions here.
> 
> 
> > 1. The laptop will ship with stretch preinstalled, but with a custom 
> > kernel built using the linux-source-x.xx.xx package with a custom 
> > version number, such as linux-image-4.14.13-iitb-amd64.
> > 
> > 2. The installation will contain a package called 
> > linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this 
> > package will depend on the latest patched kernel built in the previous 
> > step.
> 
> Specifically regarding repackaging and versioning of derived packages, I 
> recommend that you follow the guidelines for Derivatives: 
> https://wiki.debian.org/Derivatives/Guidelines#Packages
> 
> You might find other things in that and related wiki pages useful too 
> :-)

Thanks. I'll keep this in mind. The only point I'd like to emphasize
is that we are clear that ours will NOT be a derived distribution; our
Debian will have only a few kernel line diffs with the pristine
Debian, and no further changes. And, like I have pointed our to Ian,
we intend informing the users that this is the case, and provide the
changes we have made through the same distribution channel as our
modified packages.

Thanks again!

Kumar
-- 
lp1 on fire
(One of the more obfuscated kernel messages)

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Ian,

On Mon, Jan 22, 2018 at 02:32:21PM +, Ian Jackson wrote:
> Kumar Appaiah writes ("Maintaining a custom out-of-tree patched Debian kernel 
> for specific hardware"):
> ...
> > 4. Users will be made aware of the fact that this is Debian with a
> > custom kernel without ambiguity.
> > 
> > Now, whenever there is a kernel update in Debian, our team will fetch
> > the source of the updated kernel, patch, rebuild and make it available
> > in our repository.
> > 
> > Please let me know if the proposed solution is good, else I am open to
> > suggestions.
> 
> Thank you for asking and for paying attention to the needs of your
> users.
> 
> This seems like a good approach to me.
> 
> One thing you don't explicitly say is how you will distribute the
> source code for your custom kernel.  It's sort of left implicit in
> your email.  You absolutely must make available the source code.
> (Reading your mail I think you probably know this but I wanted to make
> it explicit.)
> 
> Best would be to provide both (i) a Debian-format source package (.dsc
> et al) in your apt repository, so apt-source works and (ii) your
> version control branch (git branch) on some git server.  Mention both
> of these in some README that gets installed with the kernel.

My current plan is to provide the source package in the same
repository in which I will distribute the binary packages. I will also
add a link to a repository where I manage these changes. The Readme
will be clear about this.

One question I have is, if I plan to just track the
linux-source-x.xx.xx package, should I import that source into my Git
tree, or just maintain the patches?

Thanks.

Kumar
-- 
Linus?  Whose that?
-- clueless newbie on #Linux

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Jonas Smedegaard]

Hi Kumar,

Quoting Kumar Appaiah (2018-01-22 15:08:41)
> I am part of a team working on getting Debian on low cost laptops (see 
> http://www.rdp.in for details) so that they can be sold with Debian 
> preinstalled.

Looks quite interesting! Thanks for packaging raising questions here.


> 1. The laptop will ship with stretch preinstalled, but with a custom 
> kernel built using the linux-source-x.xx.xx package with a custom 
> version number, such as linux-image-4.14.13-iitb-amd64.
> 
> 2. The installation will contain a package called 
> linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this 
> package will depend on the latest patched kernel built in the previous 
> step.

Specifically regarding repackaging and versioning of derived packages, I 
recommend that you follow the guidelines for Derivatives: 
https://wiki.debian.org/Derivatives/Guidelines#Packages

You might find other things in that and related wiki pages useful too 
:-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Ian Jackson]

Kumar Appaiah writes ("Maintaining a custom out-of-tree patched Debian kernel 
for specific hardware"):
...
> 4. Users will be made aware of the fact that this is Debian with a
> custom kernel without ambiguity.
> 
> Now, whenever there is a kernel update in Debian, our team will fetch
> the source of the updated kernel, patch, rebuild and make it available
> in our repository.
> 
> Please let me know if the proposed solution is good, else I am open to
> suggestions.

Thank you for asking and for paying attention to the needs of your
users.

This seems like a good approach to me.

One thing you don't explicitly say is how you will distribute the
source code for your custom kernel.  It's sort of left implicit in
your email.  You absolutely must make available the source code.
(Reading your mail I think you probably know this but I wanted to make
it explicit.)

Best would be to provide both (i) a Debian-format source package (.dsc
et al) in your apt repository, so apt-source works and (ii) your
version control branch (git branch) on some git server.  Mention both
of these in some README that gets installed with the kernel.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Maintaining a custom out-of-tree patched Debian kernel for specific hardware

[Kumar Appaiah]

Dear Debian Developers,

I am part of a team working on getting Debian on low cost laptops (see
http://www.rdp.in for details) so that they can be sold with Debian
preinstalled. While vanilla Debian largely works, unfortunately,
making Bluetooth and sound work require kernel rebuilding. The patches
and config changes are not likely to be upstreamed any time soon, so
we would have to ship the laptop with a patched (non-Debian
kernel). Our team is, thus, taking up the responsibility of ensuring
that up-to-date kernel (with security fixes) are made available to the
users of our laptop. The patches and configs are adapted from here:
https://github.com/sundarnagarajan/kernel_build

The unfortunate situation is that I am forced to issue this patched
kernel. Since I'd like to be a good citizen of the ecosystem, I'd like
to outline the solution I have in mind. I'd like your opinion and
suggestion on this. All code being developed for this purpose will be
released under a DFSG compliant license, and all packages I refer to
that aren't in Debian will lie in our custom (outside of Debian)
repository. If there are any things I can do to make things better,
please do let me know.

1. The laptop will ship with stretch preinstalled, but with a custom
kernel built using the linux-source-x.xx.xx package with a custom
version number, such as linux-image-4.14.13-iitb-amd64.

2. The installation will contain a package called
linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this
package will depend on the latest patched kernel built in the previous
step.

3. The sources.list on the installation will have an entry pointing to
my custom repository in addition to the regular http://deb.debian.org,
and will be pinned so that the kernel and kernel related packages are
obtained from my custom repository. Needless to say, the custom
repository's public key will also be pre-shipped with the laptop.

4. Users will be made aware of the fact that this is Debian with a
custom kernel without ambiguity.

Now, whenever there is a kernel update in Debian, our team will fetch
the source of the updated kernel, patch, rebuild and make it available
in our repository.

Please let me know if the proposed solution is good, else I am open to
suggestions.

Thanks.

Kumar
-- 
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath

Re: Release Critical Kernel bug - Lenovo E550 laptop locks up repeatedly running systemctl daemon-reload

[Ian Campbell]

On Wed, 2018-01-17 at 20:31 +1300, Matt Grant wrote:
> My guess as a developer this is a release critical show stopper
> bug.

Please see
https://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2
and
https://wiki.debian.org/DebianKernelReportingBugs
for guidance on reporting a bug against the kernel.

Ian.

Release Critical Kernel bug - Lenovo E550 laptop locks up repeatedly running systemctl daemon-reload

[Matt Grant]

Hi!

On kernel 4.14.13-1 linux-image-4.14.0-3-amd64 Debian Sid my
Lenonvo Laptop will relaibaly lock up executing systemctl daemon-reload.
Under Debian stretch kernel linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 this
does not happen.  I hae attached a picture of the kernel panic on the
console.

My guess as a developer this is a release critical show stopper bug.
​
 IMG_20180117_193509.jpg
<https://drive.google.com/a/mattgrant.net.nz/file/d/1_sJLdzToo8fxL4vtMbLtaAeoduNd7pXL/view?usp=drive_web>
​
This is 100% repeatable.

Thank you!

Matt Grant

Re: kernel nvidia dkms rebuild after upgrade?

[Boyan Penkov]

Hello Dan — thanks kindly, I had indeed not noticed….

I guess I’ll have a chance to test if the libelf-dev issue is really the fix 
when the patches do roll out.

In that vein, I would like to note that 
https://security-tracker.debian.org/tracker/CVE-2017-5754 
<https://security-tracker.debian.org/tracker/CVE-2017-5754>  makes no mention 
of bpo kernels in backports.  Is this by design?

Cheers!
--
Boyan Penkov
www.boyanpenkov.com

> On Jan 7, 2018, at 18:44, Daniel Reichelt  wrote:
> 
> On 01/07/2018 07:47 PM, Boyan Penkov wrote:
>> and a backport (4.14.0-bpo2) -- in light of meltdown --
> 
> To avoid a false sense of security: according to [1], [2], [3], the
> current stretch-bpo kernel (linux-image-4.14.0-0.bpo.2-$arch) does *NOT*
> yet include any mitigations against meltdown.
> 
> Daniel
> 
> 
> 
> [1] https://security-tracker.debian.org/tracker/CVE-2017-5753
> [2] https://security-tracker.debian.org/tracker/CVE-2017-5754
> [3] https://security-tracker.debian.org/tracker/CVE-2017-5715
> 

Re: kernel nvidia dkms rebuild after upgrade?

[Boyan Penkov]

Thanks, Yao —  in messing around with this, I did end up finding a thread that 
suggested installing libelf-dev — I did so, but I guess the order in which I 
did it make me recompile my dkms modules manually.

Thanks for the note!
--
Boyan Penkov
www.boyanpenkov.com

> On Jan 7, 2018, at 18:31, Yao Wei  wrote:
> 
> It is caused by a missing dependency libelf-dev.
> It is already reported against linux-headers-4.14.0-3-amd64:
> https://bugs.debian.org/886474 
> 
> I have the same symptom of broadcom-sta-dkms
> 
> On Mon, 8 Jan 2018 at 02:47 Boyan Penkov  > wrote:
> Hello,
> 
> After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
> light of meltdown -- my nvidia drivers failed to load.
> 
> Rebulding the modules manually --
> https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
>  
> 
> -- did fix it.
> 
> Did I miss something?
> 
> Cheers!
> 
> --
> Boyan Penkov
> 

Re: kernel nvidia dkms rebuild after upgrade?

[Daniel Reichelt]

On 01/07/2018 07:47 PM, Boyan Penkov wrote:
> and a backport (4.14.0-bpo2) -- in light of meltdown --

To avoid a false sense of security: according to [1], [2], [3], the
current stretch-bpo kernel (linux-image-4.14.0-0.bpo.2-$arch) does *NOT*
yet include any mitigations against meltdown.

Daniel



[1] https://security-tracker.debian.org/tracker/CVE-2017-5753
[2] https://security-tracker.debian.org/tracker/CVE-2017-5754
[3] https://security-tracker.debian.org/tracker/CVE-2017-5715



signature.asc
Description: OpenPGP digital signature

Re: kernel nvidia dkms rebuild after upgrade?

[Yao Wei]

It is caused by a missing dependency libelf-dev.
It is already reported against linux-headers-4.14.0-3-amd64:
https://bugs.debian.org/886474

I have the same symptom of broadcom-sta-dkms

On Mon, 8 Jan 2018 at 02:47 Boyan Penkov  wrote:

> Hello,
>
> After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
> light of meltdown -- my nvidia drivers failed to load.
>
> Rebulding the modules manually --
>
> https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
> -- did fix it.
>
> Did I miss something?
>
> Cheers!
>
> --
> Boyan Penkov
>
>

kernel nvidia dkms rebuild after upgrade?

[Boyan Penkov]

Hello,

After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
light of meltdown -- my nvidia drivers failed to load.

Rebulding the modules manually --
https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
-- did fix it.

Did I miss something?

Cheers!

-- 
Boyan Penkov

Bug#880825: ITP: libkcapi -- Linux Kernel Crypto API User Space Interface Library

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 

* Package name: libkcapi
  Version : 1.0.0
  Upstream Author : Stephan Mueller 
* URL : http://www.chronox.de/libkcapi.html
* License : BSD
  Programming Lang: C
  Description : Linux Kernel Crypto API User Space Interface Library

 The Linux kernel exports a Netlink interface of type AF_ALG to allow user
 space to utilize the kernel crypto API. libkcapi uses this Netlink interface
 and exports easy to use APIs so that a developer does not need to consider the
 low-level Netlink interface handling.
 .
 The library does not implement any cipher algorithms. All consumer requests
 are sent to the kernel for processing. Results from the kernel crypto API
 are returned to the consumer via the library API.
 .
 The kernel interface and therefore this library can be used by unprivileged
 processes.

Re: building a debian kernel package(s) for a foreign architecture

[Jonathan Dowland]

Hi Roger,

On Wed, Jul 26, 2017 at 01:26:17AM +0900, Roger Shimizu wrote:

How is your build? Does it go well?


Thanks for asking. Well, I decided to try and get what I was trying to
do without using cross-compilation, and introduce cross-compilation once
I had things working without it. But I got the impression that there
were holes in the official documentation around cross compilation and
thus your wiki page had merit, so thanks for that.

The last thing I did for the issue I was looking at was post to
debian-kernel asking for advice. Alas nobody has had the time to reply.

[1] https://lists.debian.org/debian-kernel/2017/07/msg00323.html

I'm planning to write up what I've been looking at for a blog post.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: building a debian kernel package(s) for a foreign architecture

[Roger Shimizu]

On Thu, Jul 6, 2017 at 2:53 AM, Karsten Merker  wrote:
>
> IIRC both pbuilder and sbuild automatically set the "nocheck"
> profile when crossbuilding. For crossbuilding the kernel IIRC
> one needs to set a number of additional build-profiles:
>
> - cross
> - pkg.linux.notools
> - nopython
>
> So the following sbuild command should in theory (sorry, cannot
> actually test that right now) crossbuild the kernel package for
> arm64:
>
>   sbuild -d unstable --host=arm64 --profiles=cross,pkg.linux.notools,nopython 
> .dsc

Thanks so much for the info! Especially the "nopython" option, which
was confusing at first glance.

I don't see the profile setting in kernel handbook, but only in the source:
 - https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/README.source

So I updated my wiki entry:
 - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
Now I confirm it builds only image and header 2 debs when targeting
"UNRELEASED".

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: building a debian kernel package(s) for a foreign architecture

[Roger Shimizu]

Dear Jonathan,

How is your build? Does it go well?

On Thu, Jul 6, 2017 at 2:38 AM, Ben Hutchings  wrote:
> On Wed, 2017-07-05 at 23:43 +0900, Roger Shimizu wrote:
>>
>> I ever created one:
>> - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
>>
>> Hope it helps you.
>> And if you find something not current and need modify, please just edit it.
>> Thank you!
>
> Why does that talk about building from the git repository, rather than
> a source package (which duplicates the instructions at
> https://kernel-handbook.alioth.debian.org/ch-common-tasks.html)?
>
> For cross-building generally you should use the 'cross' build profile.
> And for linux specifically you can also use the 'pkg.linux.notools'
> build profile to disable the userland packages, which greatly reduces,
> the build depdendencies.

Dear Ben,

I created the wiki entry because I want to explorer some other ways
than what's telling in the kernel handbook. Of course I take the
handbook as reference, and thanks for your work!

It's easy to reproduce a kernel build by the steps in kernel handbook,
but what I want, sometimes, is to try the latest stable kernel
released upstream. Debian usually lags a few days behind upstream's
new release, especially in the freeze stage before a debian release.
So I think my wiki entry is informative in such case.

And I happened to find another topic in kernel lists:
 - 
http://debian.2.n7.nabble.com/cross-building-linux-image-packages-td3974626.html

I tried your suggested command:
  dpkg-buildpackage -Pcross,nopython -aarmel -B -uc -us
but got the following error:


dpkg-source: error: cannot read debian-kernel/debian/control: No such
file or directory
dpkg-buildpackage: error: dpkg-source --before-build debian-kernel
gave error exit status 2



On Thu, Jul 6, 2017 at 2:53 AM, Karsten Merker  wrote:
> On Wed, Jul 05, 2017 at 03:35:25PM +0100, Jonathan Dowland wrote:
>> Hi folks,
>>
>> I've never done much in the way of cross-compiling before.  I
>> understand it was once very hard, is now much easier, and is
>> considerably easier for "simple" packages (including the kernel)
>> than others.
>>
>> That said, I'm lost/stuck trying to cross-compile the Debian
>> Linux kernel package for ARM64 (target is a Raspberry Pi 3) from
>> an amd64 builder.  I believe I do not need to use multiarch for
>> my builder, yet dpkg-buildpackage (if I supply -a aarch64,
>> interestingly ARM64 doesn't work) complains of unmet build
>> dependencies, which I have resolved for amd64.  But perhaps -a to
>> dpkg-buildpackage is the wrong approach.
>
> Hello,
>
> from a technical point of view you effectively need multiarch to
> crosscompile Debian packages, but you don't have to set it up
> yourself ;-).
>
> The easiest way to crossbuild a Debian package is probably to use
> sbuild or pbuilder, which both have crossbuild-support since a
> while.  When called with the appropriate options, they
> automatically setup multiarch in their chroot and install the
> necessary crosscompilers as well as the package cross-dependencies.
> I can only talk about sbuild from personal experience, but
> according to the docs, pbuilder should work similarly.
>
> Not all packages can be crossbuilt, and for those that can be
> crossbuilt in principle, it is sometimes necessary to set
> appropriate build-profiles which e.g. cause the testsuite not to
> be run during the package build, as often the testsuite tries to
> run host-architecture binaries created during the build which
> cannot be executed on the build-architecture system (with "build"
> and "host" used in GNU terminology, i.e. "build-architecture" =
> "architecture on which the compiler runs" and "host-architecture" =
> "architeture on which the created binaries run").
>
> IIRC both pbuilder and sbuild automatically set the "nocheck"
> profile when crossbuilding. For crossbuilding the kernel IIRC
> one needs to set a number of additional build-profiles:
>
> - cross
> - pkg.linux.notools
> - nopython
>
> So the following sbuild command should in theory (sorry, cannot
> actually test that right now) crossbuild the kernel package for
> arm64:
>
>   sbuild -d unstable --host=arm64 --profiles=cross,pkg.linux.notools,nopython 
> .dsc

Thanks for your sample on sbuild, and detailed profile options.
I usually use git-pbuild for other packages. I hasn't figure out how
to do cross build kernel under pbuilder or its related tool (e.g.
git-build)
So if anybody know it, please let me know. Thanks!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: building a debian kernel package(s) for a foreign architecture

[Ben Hutchings]

On Wed, 2017-07-05 at 23:43 +0900, Roger Shimizu wrote:
> > On Wed, Jul 5, 2017 at 11:35 PM, Jonathan Dowland  wrote:
> > Hi folks,
> > 
> > I've never done much in the way of cross-compiling before. I understand it
> > was once very hard, is now much easier, and is considerably easier for
> > "simple" packages (including the kernel) than others.
> > 
> > That said, I'm lost/stuck trying to cross-compile the Debian Linux kernel
> > package for ARM64 (target is a Raspberry Pi 3) from an amd64 builder. I
> > believe
> > I do not need to use multiarch for my builder, yet dpkg-buildpackage (if I
> > supply -a aarch64, interestingly ARM64 doesn't work) complains of unmet
> > build
> > dependencies, which I have resolved for amd64.  But perhaps -a to
> > dpkg-buildpackage is the wrong approach.
> > 
> > Can someone please point me to the relevant idiot's guide?
> 
> I ever created one:
> - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
> 
> Hope it helps you.
> And if you find something not current and need modify, please just edit it.
> Thank you!

Why does that talk about building from the git repository, rather than
a source package (which duplicates the instructions at
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html)?

For cross-building generally you should use the 'cross' build profile. 
And for linux specifically you can also use the 'pkg.linux.notools'
build profile to disable the userland packages, which greatly reduces
the build depdendencies.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.


signature.asc
Description: This is a digitally signed message part

Re: building a debian kernel package(s) for a foreign architecture

[Roger Shimizu]

On Thu, Jul 6, 2017 at 12:29 AM, Jonathan Dowland  wrote:
> On Wed, Jul 05, 2017 at 11:43:58PM +0900, Roger Shimizu wrote:
>>
>> I ever created one:
>> - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
>>
>> Hope it helps you.
>> And if you find something not current and need modify, please just edit
>> it.
>> Thank you!
>
>
> Thank you, this is (probably) very useful. The one line I am not sure how to
> adjust to my situation is
>
>> fakeroot make -f debian/rules.gen setup_armel_none_marvell
>
>
> I'm going to guess at setup_arm64 here, but it could also be
> setup_arm64_none
> or setup_arm64_real and I don't know what the distinction is yet.

The magic is set in:
  https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/config/arm64
and its sub-directories.

I guess the command for amd64 is:
  fakeroot make -f debian/rules.gen setup_arm64_none_arm64

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: building a debian kernel package(s) for a foreign architecture

[Jonathan Dowland]

On Wed, Jul 05, 2017 at 11:43:58PM +0900, Roger Shimizu wrote:

I ever created one:
- https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage

Hope it helps you.
And if you find something not current and need modify, please just edit it.
Thank you!


Thank you, this is (probably) very useful. The one line I am not sure how to 
adjust to my situation is



fakeroot make -f debian/rules.gen setup_armel_none_marvell


I'm going to guess at setup_arm64 here, but it could also be setup_arm64_none
or setup_arm64_real and I don't know what the distinction is yet.


--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: building a debian kernel package(s) for a foreign architecture

[Roger Shimizu]

On Wed, Jul 5, 2017 at 11:35 PM, Jonathan Dowland  wrote:
> Hi folks,
>
> I've never done much in the way of cross-compiling before. I understand it
> was once very hard, is now much easier, and is considerably easier for
> "simple" packages (including the kernel) than others.
>
> That said, I'm lost/stuck trying to cross-compile the Debian Linux kernel
> package for ARM64 (target is a Raspberry Pi 3) from an amd64 builder. I
> believe
> I do not need to use multiarch for my builder, yet dpkg-buildpackage (if I
> supply -a aarch64, interestingly ARM64 doesn't work) complains of unmet
> build
> dependencies, which I have resolved for amd64.  But perhaps -a to
> dpkg-buildpackage is the wrong approach.
>
> Can someone please point me to the relevant idiot's guide?

I ever created one:
- https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage

Hope it helps you.
And if you find something not current and need modify, please just edit it.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

building a debian kernel package(s) for a foreign architecture

[Jonathan Dowland]

Hi folks,

I've never done much in the way of cross-compiling before. I understand it was 
once very hard, is now much easier, and is considerably easier for "simple" 
packages (including the kernel) than others.


That said, I'm lost/stuck trying to cross-compile the Debian Linux kernel
package for ARM64 (target is a Raspberry Pi 3) from an amd64 builder. I believe
I do not need to use multiarch for my builder, yet dpkg-buildpackage (if I 
supply -a aarch64, interestingly ARM64 doesn't work) complains of unmet build
dependencies, which I have resolved for amd64.  But perhaps -a to 
dpkg-buildpackage is the wrong approach.


Can someone please point me to the relevant idiot's guide?


Thanks

--

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland

⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-03-05 03:52:33 +, Ben Hutchings wrote:
> I would also expect that users running command-line tools to set the
> time, such as ntpdate, have enough technical understanding to
> distinguish the system clock and RTC.

And what's worse is that by default, ntpdate is run automatically from
/etc/network/if-up.d, so that the date could become incorrect without
a control from the user.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844520

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote:
> Daniel Pocock  writes:
> 
> > On 27/02/17 21:26, Ben Hutchings wrote:
> >> But ntpd is also known to have a large amount of code written
> >> without as much regard for security as one would hope.  It seems
> >> like an unnecessary risk for most systems.
> 
> > Thanks for that security tip, I'm tempted to get rid of some ntpd
> > instances now, however a few more questions come to mind before I rush in:
> 
> Have a look at openntpd, that's coded with security in mind.

But this doesn't apply to the Debian version, as documented. And it
is buggy. I had to remove it from my machine because it did more harm
than solving problems.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Sat, 2017-03-04 at 20:33 +, Roger Lynn wrote:
> On 28/02/17 01:00, Ben Hutchings wrote:
> > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > Right, ntpdate for some reason doesn't set the flag to do this.
> > 
> > There is a very good reason, which is that without continuous
> > adjustment the system clock cannot be assumed more stable than the RTC.
> 
> This doesn't make sense to me. Most users are probably not aware that there
> is a separate hardware RTC.

Most users don't know what ntpdate is, either.

> Why would one assume that the clock the user is not aware of is better than
> the clock the user can see and is presumably happy with?

*I* would assume that when a user sets the system clock through a high-
level UI, such as GNOME provides, that is the most accurate source of
information and the RTC should also be set.  But I would not assume
that the system clock *remains* very accurate after that point, which
is what the flag in question is supposed to indicate.

I would also expect that users running command-line tools to set the
time, such as ntpdate, have enough technical understanding to
distinguish the system clock and RTC.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.



signature.asc
Description: This is a digitally signed message part

Re: systemd, ntp, kernel and hwclock

[Roger Lynn]

On 28/02/17 01:00, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>> Right, ntpdate for some reason doesn't set the flag to do this.
> 
> There is a very good reason, which is that without continuous
> adjustment the system clock cannot be assumed more stable than the RTC.

This doesn't make sense to me. Most users are probably not aware that there
is a separate hardware RTC. Why would one assume that the clock the user is
not aware of is better than the clock the user can see and is presumably
happy with?

Roger

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Kurt Roeckx  writes:

> Having ntpdate clear the unsynced flag doesn't make sense since it would
> start writing a time to the RTC each 11 minutes, and as Ben said you
> have no idea which of the 2 clocks is the most correct one.

Oh, I thought it was a one-shot thing, but it turns on syncing behavior
from that point forward.  Thanks, that was the piece that I was missing.

> I can also understand that systemd doesn't set the clock for just the
> same reason. Either the clock is synched and it's written, or it's not
> suched, it's unknown which one is the most correct, and it's not
> written.

Yeah, it now makes perfect sense to me.

-- 
Russ Allbery (r...@debian.org)   

Re: systemd, ntp, kernel and hwclock

[Kurt Roeckx]

On Tue, Feb 28, 2017 at 05:04:08AM +, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote:
> > Ben Hutchings  writes:
> > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > > Daniel Pocock  writes:
> > > > > However, at the time when I ran ntpdate, ntp was not running.  I had
> > > > > brought up the network manually due to an interface renaming issue on
> > > > > the first boot.  Maybe when somebody runs ntpdate in a scenario like
> > > > > that the kernel is not sending the new date/time to the hardware
> > > > > clock.
> > > > Right, ntpdate for some reason doesn't set the flag to do this.
> > > 
> > > [...]
> > > There is a very good reason, which is that without continuous
> > > adjustment the system clock cannot be assumed more stable than the RTC.
> > 
> > If you've literally just synced the system clock to a remote NTP server,
> > why could you not assume it was more accurate than the RTC?
> 
> For that instant, sure, and ntpdate could follow-up the one-shot system
> clock synch with a one-short RTC synch.  But the kernel doesn't provide
> a simple API for that, and it's easy enough to add "hwclock --systohc"
> to a script right after "ntpdate ...".

If anything, having ntpdate call hwclock might make sense.

Having ntpdate clear the unsynced flag doesn't make sense since it
would start writing a time to the RTC each 11 minutes, and as Ben
said you have no idea which of the 2 clocks is the most correct
one.

I can also understand that systemd doesn't set the clock for just
the same reason. Either the clock is synched and it's written, or
it's not suched, it's unknown which one is the most correct, and
it's not written.


Kurt

Re: systemd, ntp, kernel and hwclock

[Carsten Leonhardt]

Daniel Pocock  writes:

> On 27/02/17 21:26, Ben Hutchings wrote:
>> But ntpd is also known to have a large amount of code written
>> without as much regard for security as one would hope.  It seems
>> like an unnecessary risk for most systems.

> Thanks for that security tip, I'm tempted to get rid of some ntpd
> instances now, however a few more questions come to mind before I rush in:

Have a look at openntpd, that's coded with security in mind.

 - Carsten

Re: systemd, ntp, kernel and hwclock

[Bjørn Mork]

Adam Borowski  writes:

> On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote:
>> > But ntpd is also known to have a large amount of code written
>> > without as much regard for security as one would hope.  It seems
>> > like an unnecessary risk for most systems.
>> 
>> 
>> Thanks for that security tip, I'm tempted to get rid of some ntpd
>> instances now
>
> You'd be interested in NTPsec (https://www.ntpsec.org/) then, which is a
> project to review and sanitize ntpd without downsides prevalent in most
> replacements (such as same-week accuracy or no managing clock drift).
>
> Sadly, it's not a part of stretch or even unstable yet:
> https://bugs.debian.org/819806

I don't think there are enough people caring about ntp in Debian (or the
world) to maintain two code bases.  And the fork is still young and not
"obviously better" or "clearly the one true path forward".

See also https://lwn.net/Articles/713901/ for more background
information.

IMHO, it's very unfortunate that this fork was created, and I cannot see
anything good coming out of it.  It's just wasting developer resources
which could have been used to improve ntp.


Bjørn

Re: systemd, ntp, kernel and hwclock

[Adam Borowski]

On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote:
> > But ntpd is also known to have a large amount of code written
> > without as much regard for security as one would hope.  It seems
> > like an unnecessary risk for most systems.
> 
> 
> Thanks for that security tip, I'm tempted to get rid of some ntpd
> instances now

You'd be interested in NTPsec (https://www.ntpsec.org/) then, which is a
project to review and sanitize ntpd without downsides prevalent in most
replacements (such as same-week accuracy or no managing clock drift).

Sadly, it's not a part of stretch or even unstable yet:
https://bugs.debian.org/819806

> - for a site with several machines, should they all be querying
> pool.ntp.org servers directly or can any other local ntp daemon be
> relied on?

Using a local daemon means:
* less burden on public servers or the network
* if there's a problem, your machines will be consistent at least between
  them, which is usually a bigger concern than being globally accurate

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Re: systemd, ntp, kernel and hwclock

[Daniel Pocock]

On 27/02/17 21:26, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
>>> Daniel Pocock  writes:
>> 
>>> I've observed a system that had a wildly incorrect hardware
>>> clock (when it was first unboxed), I ran ntpdate to sync the
>>> kernel clock but after a shutdown and startup again it had a
>>> wacky time again. I came across the discussion about how the
>>> hardware clock is no longer set at shutdown[1] The system has
>>> ntpd running Looking at the output of adjtimex --print | grep
>>> status the bit corresponding to 64 / STA_UNSYNC is 0 There is a
>>> time and date page on the wiki[2] and in the manual[3], neither
>>> of them appears to have up to date information about the way
>>> it works with systemd or how to troubleshoot issues like this.
>> 
>> My understanding from reading a bit about this just now is that
>> the short version is "install ntpd if you want this to happen."
>> 
>> My impression is that ntpdate has been obsolete for years and
>> upstream has been slowly trying to kill it.  ntpd is the
>> upstream-supported daemon, and it periodically asks the kernel to
>> set the hardware clock.
> 
> The kernel actually does the periodic setting automatically, so
> long as the NTP server reports that it's synchronised (by clearing
> STA_UNSYNC in timex::status).
> 
> (The kernel will only set one RTC device, which is specified in
> the build config.  On systems that have multiple RTCs and only one
> of them works (e.g. the one in the SoC doesn't have battery power
> but the one in the PMIC does) this may not work properly.  It may
> be fixable by disabling the broken RTC in the device tree.)
> 


It would seem reasonable for ntpdate to clear that flag so I opened a
bug report[1] for ntpdate

>> (And it supports various command-line options to make it act like
>> ntpdate if you really want.)
>> 
>> The much simpler systemd-timesyncd doesn't set the hardware clock
>> for reasons that one may or may not agree with (I honestly
>> haven't researched it in any depth),
> 
> It looks like it does iff the RTC is set to UTC:
> 
> /* * An unset STA_UNSYNC will enable the kernel's 11-minute mode, *
> which syncs the system time periodically to the RTC. * * In case
> the RTC runs in local time, never touch the RTC, * we have no way
> to properly handle daylight saving changes and * mobile devices
> moving between time zones. */ if (m->rtc_local_time) tmx.status |=
> STA_UNSYNC;
> 
>> but you can just run ntpd instead if you care.
> 
> But ntpd is also known to have a large amount of code written
> without as much regard for security as one would hope.  It seems
> like an unnecessary risk for most systems.
> 


Thanks for that security tip, I'm tempted to get rid of some ntpd
instances now, however a few more questions come to mind before I rush in:

- for a site with several machines, should they all be querying
pool.ntp.org servers directly or can any other local ntp daemon be
relied on?

- this discussion also reminded me of the clock drift issues[2] for
Xen virtual machines / guests / domU systems.  I don't know if such
problems still exist with modern hypervisors and kernels but I had
encountered them in the past and had been running ntpd on each VM and
then they all appeared to behave.  Does this apply to LXC, KVM or any
other environment?  What are best practices for this today, does
systemd-timesyncd solve everything and do people need to manually
tweak any sysctl like /proc/sys/xen/independent_wallclock any more?
Maybe some of this could go in the wiki too if it is still necessary.

Regards,

Daniel

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856343
2.
http://serverfault.com/questions/245401/xen-hvm-guest-has-severe-clock-drift

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote:
> Ben Hutchings  writes:
> > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > Daniel Pocock  writes:
> > > > However, at the time when I ran ntpdate, ntp was not running.  I had
> > > > brought up the network manually due to an interface renaming issue on
> > > > the first boot.  Maybe when somebody runs ntpdate in a scenario like
> > > > that the kernel is not sending the new date/time to the hardware
> > > > clock.
> > > Right, ntpdate for some reason doesn't set the flag to do this.
> > 
> > [...]
> > There is a very good reason, which is that without continuous
> > adjustment the system clock cannot be assumed more stable than the RTC.
> 
> If you've literally just synced the system clock to a remote NTP server,
> why could you not assume it was more accurate than the RTC?

For that instant, sure, and ntpdate could follow-up the one-shot system
clock synch with a one-short RTC synch.  But the kernel doesn't provide
a simple API for that, and it's easy enough to add "hwclock --systohc"
to a script right after "ntpdate ...".

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.



signature.asc
Description: This is a digitally signed message part

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Ben Hutchings  writes:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>>> Daniel Pocock  writes:

>>> However, at the time when I ran ntpdate, ntp was not running.  I had
>>> brought up the network manually due to an interface renaming issue on
>>> the first boot.  Maybe when somebody runs ntpdate in a scenario like
>>> that the kernel is not sending the new date/time to the hardware
>>> clock.

>> Right, ntpdate for some reason doesn't set the flag to do this.
> [...]

> There is a very good reason, which is that without continuous
> adjustment the system clock cannot be assumed more stable than the RTC.

If you've literally just synced the system clock to a remote NTP server,
why could you not assume it was more accurate than the RTC?

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > Daniel Pocock  writes:
> 
> > However, at the time when I ran ntpdate, ntp was not running.  I had
> > brought up the network manually due to an interface renaming issue on
> > the first boot.  Maybe when somebody runs ntpdate in a scenario like
> > that the kernel is not sending the new date/time to the hardware clock.
> 
> Right, ntpdate for some reason doesn't set the flag to do this.
[...]

There is a very good reason, which is that without continuous
adjustment the system clock cannot be assumed more stable than the RTC.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.



signature.asc
Description: This is a digitally signed message part

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Ben Hutchings  writes:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:

>> The much simpler systemd-timesyncd doesn't set the hardware clock for
>> reasons that one may or may not agree with (I honestly haven't
>> researched it in any depth),

> It looks like it does iff the RTC is set to UTC:

> /*
>  * An unset STA_UNSYNC will enable the kernel's 11-minute mode,
>  * which syncs the system time periodically to the RTC.
>  *
>  * In case the RTC runs in local time, never touch the RTC,
>  * we have no way to properly handle daylight saving changes and
>  * mobile devices moving between time zones.
>  */
> if (m->rtc_local_time)
> tmx.status |= STA_UNSYNC;

Oh!  Okay, then yes, it shouldn't matter whether it persists at shutdown
or not, since it will be setting it periodically anyway.

>> but you can just run ntpd instead if you care.

> But ntpd is also known to have a large amount of code written without
> as much regard for security as one would hope.  It seems like an
> unnecessary risk for most systems.

Indeed, I've personally switched to systemd-timesyncd on my systems, which
works fine for me.  (I think there are other lightweight clients if people
want something different.)

-- 
Russ Allbery (r...@debian.org)   

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Daniel Pocock  writes:

> However, at the time when I ran ntpdate, ntp was not running.  I had
> brought up the network manually due to an interface renaming issue on
> the first boot.  Maybe when somebody runs ntpdate in a scenario like
> that the kernel is not sending the new date/time to the hardware clock.

Right, ntpdate for some reason doesn't set the flag to do this.

> I had simply assumed that it would be persisted at shutdown but maybe
> ntpdate could be patched to do whatever ntpd does to encourage the
> kernel to persist it.

sysvinit I believe used to always persist the clock to the hardware clock
during shutdown.  systemd doesn't do that, for reasons that I've not
thought about in any depth.  So that's a change, which is understandably
surprising.

If you get in the habit of using ntpd instead of ntpdate to do the
one-time clock syncs, that might fix the problem (alas, I forget the set
of command line flags that do the same thing as ntpdate).

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

Re: systemd, ntp, kernel and hwclock

[Daniel Pocock]

On 27/02/17 20:18, Russ Allbery wrote:
> Daniel Pocock  writes:
> 
>> I've observed a system that had a wildly incorrect hardware clock (when
>> it was first unboxed), I ran ntpdate to sync the kernel clock but after
>> a shutdown and startup again it had a wacky time again.
> 
>> I came across the discussion about how the hardware clock is no longer
>> set at shutdown[1]
> 
>> The system has ntpd running
> 
>> Looking at the output of
>>adjtimex --print | grep status
> 
>> the bit corresponding to 64 / STA_UNSYNC is 0
> 
>> There is a time and date page on the wiki[2] and in the manual[3],
>> neither of them appears to have up to date information about the way it
>> works with systemd or how to troubleshoot issues like this.
> 
> My understanding from reading a bit about this just now is that the short
> version is "install ntpd if you want this to happen."
> 
> My impression is that ntpdate has been obsolete for years and upstream has
> been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
> it periodically asks the kernel to set the hardware clock.  (And it
> supports various command-line options to make it act like ntpdate if you
> really want.)
> 
> The much simpler systemd-timesyncd doesn't set the hardware clock for
> reasons that one may or may not agree with (I honestly haven't researched
> it in any depth), but you can just run ntpd instead if you care.
> 
> Alternately, if you really want to use a clock setting mechanism that
> doesn't ask the kernel to sync the hardware clock but you still want to
> set the hardware clock, you can add your own shutdown init script / unit
> to run hwclock --systohc (or even a cron job if you want).
> 


ntpd is definitely running now, it is a default configuration and it was
already on the box a long time before I observed the issue today.

However, at the time when I ran ntpdate, ntp was not running.  I had
brought up the network manually due to an interface renaming issue on
the first boot.  Maybe when somebody runs ntpdate in a scenario like
that the kernel is not sending the new date/time to the hardware clock.
I had simply assumed that it would be persisted at shutdown but maybe
ntpdate could be patched to do whatever ntpd does to encourage the
kernel to persist it.

Regards,

Daniel

Re: systemd, ntp, kernel and hwclock

[Ben Hutchings]

On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
> > Daniel Pocock  writes:
> 
> > I've observed a system that had a wildly incorrect hardware clock (when
> > it was first unboxed), I ran ntpdate to sync the kernel clock but after
> > a shutdown and startup again it had a wacky time again.
> > I came across the discussion about how the hardware clock is no longer
> > set at shutdown[1]
> > The system has ntpd running
> > Looking at the output of
> >    adjtimex --print | grep status
> > the bit corresponding to 64 / STA_UNSYNC is 0
> > There is a time and date page on the wiki[2] and in the manual[3],
> > neither of them appears to have up to date information about the way it
> > works with systemd or how to troubleshoot issues like this.
> 
> My understanding from reading a bit about this just now is that the short
> version is "install ntpd if you want this to happen."
> 
> My impression is that ntpdate has been obsolete for years and upstream has
> been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
> it periodically asks the kernel to set the hardware clock.

The kernel actually does the periodic setting automatically, so long as
the NTP server reports that it's synchronised (by clearing STA_UNSYNC
in timex::status).

(The kernel will only set one RTC device, which is specified in the
build config.  On systems that have multiple RTCs and only one of them
works (e.g. the one in the SoC doesn't have battery power but the one
in the PMIC does) this may not work properly.  It may be fixable by
disabling the broken RTC in the device tree.)

> (And it
> supports various command-line options to make it act like ntpdate if you
> really want.)
>
> The much simpler systemd-timesyncd doesn't set the hardware clock for
> reasons that one may or may not agree with (I honestly haven't researched
> it in any depth),

It looks like it does iff the RTC is set to UTC:

/*
 * An unset STA_UNSYNC will enable the kernel's 11-minute mode,
 * which syncs the system time periodically to the RTC.
 *
 * In case the RTC runs in local time, never touch the RTC,
 * we have no way to properly handle daylight saving changes and
 * mobile devices moving between time zones.
 */
if (m->rtc_local_time)
tmx.status |= STA_UNSYNC;

> but you can just run ntpd instead if you care.

But ntpd is also known to have a large amount of code written without
as much regard for security as one would hope.  It seems like an
unnecessary risk for most systems.

Ben.

> Alternately, if you really want to use a clock setting mechanism that
> doesn't ask the kernel to sync the hardware clock but you still want to
> set the hardware clock, you can add your own shutdown init script / unit
> to run hwclock --systohc (or even a cron job if you want).
> 
-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



signature.asc
Description: This is a digitally signed message part

Re: systemd, ntp, kernel and hwclock

[Russ Allbery]

Daniel Pocock  writes:

> I've observed a system that had a wildly incorrect hardware clock (when
> it was first unboxed), I ran ntpdate to sync the kernel clock but after
> a shutdown and startup again it had a wacky time again.

> I came across the discussion about how the hardware clock is no longer
> set at shutdown[1]

> The system has ntpd running

> Looking at the output of
>adjtimex --print | grep status

> the bit corresponding to 64 / STA_UNSYNC is 0

> There is a time and date page on the wiki[2] and in the manual[3],
> neither of them appears to have up to date information about the way it
> works with systemd or how to troubleshoot issues like this.

My understanding from reading a bit about this just now is that the short
version is "install ntpd if you want this to happen."

My impression is that ntpdate has been obsolete for years and upstream has
been slowly trying to kill it.  ntpd is the upstream-supported daemon, and
it periodically asks the kernel to set the hardware clock.  (And it
supports various command-line options to make it act like ntpdate if you
really want.)

The much simpler systemd-timesyncd doesn't set the hardware clock for
reasons that one may or may not agree with (I honestly haven't researched
it in any depth), but you can just run ntpd instead if you care.

Alternately, if you really want to use a clock setting mechanism that
doesn't ask the kernel to sync the hardware clock but you still want to
set the hardware clock, you can add your own shutdown init script / unit
to run hwclock --systohc (or even a cron job if you want).

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>