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

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

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

Thanks for opening this bug.
Building UML as part of the regular kernel release has been on my todo list for years now (including making a real attempt with patch long ago - didn't get much attention then).

My employer will soon sponsor some work in this area, I hope I can get a step closer at addressing this bug then.

Thanks for opening this bug.
Building UML as part of the regular kernel release has been on my todo list for years now (including making a real attempt with patch long ago - didn't get much attention then).

My employer will soon sponsor some work in this area, I hope I can get a step closer at addressing this bug then.

I'm open to the possibility of folding this into src:linux, if someone
in (or joining) the kernel team can take responsibility for maintaining
it.  Now that all the userland tools are built from src:linux, it might
not be that hard to add UML.

There are a few issues I can immediately see:

- UML binaries can't be built using the existing makefile rules for
linux-image packages, as they need different package names,
installation paths, and maintainer scripts.  This would need entirely
new rules.

- The current base config (debian/config/config) might not make any
sense for UML (but then, maybe all the irrelevant stuff will simply be
disabled automatically).

- I'm a little concerned about the possibility of build breakage in UML
that would then block everything else built from src:linux.  Does UML
break often?

Ben.

On Thu, September 15, 2016 7:16 pm, Ben Hutchings wrote:
...

There's a mini-team (Ritesh and me) taking care of UML today.
What is the expectation for that someone?
I'm willing to step forward, but I'm also aware I have limits in my
availability.

Yes, these both need to be solved. To be fair I haven't had time to look
into the specifics but that's what's next.

I haven't been tracking RCs, but stable releases aren't giving many
problems (a recent one was that then nvram module broke, but that's a case
of a module that doesn't make sense for UML and shouldn't be enabled to
start with).
From looking at the UML upstream mailing lists, there haven't been many
big breakages in recent times.

Maintain the configuration, investigate and fix build failures, that
sort of thing.

Good.  Since we do upload release candidates to experimental, it might
become necessary to fix build failures earlier.

Ben.

Sure. :)
I can handle that much.
Let's see where I get to in integrating the UML build with src:linux,
then we can talk.

Thanks

If you need help let me know.

This looks like less than a day of work to me, and I would not mind
doing it myself if you aren't already working on it.

cu
Adrian

Sure, I'll let you know.
Thanks for the offer.

…

I am taking a look at this. But before going any further, Ritesh, would
you be willing to taking care of UML within src:linux ?
If yes, I hope* to send a MR the next week.

Cheers,

Yes. It'd be ideal to have it there. But I have never looked at
building the binary that way. Since I took maintenance of the package,
I only targeted to keep it up-to-date.

And given that it is built from the same Debian Linux source package,
there's nothing else to worry for, in terms of patches and security
fixes.

The immediate benefit I see with UML being built with the rest of the
linux packages, is that on every new update/upload of Linux, UML will
be generated.

Currently, that is not the case, when it is built independently.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System