Bug#1079473: ITP: tinyalsa -- TinyALSA is a small library to interface with ALSA in the Linux kernel.

[erebion]

Package: wnpp
Severity: wishlist
Owner: erebion 
X-Debbugs-Cc: debian-devel@lists.debian.org, ereb...@erebion.eu

* Package name : tinyalsa
Version : git20240621
Upstream Contact: Taylor Holberton 
* URL : https://github.com/tinyalsa/tinyalsa
* License : BSD
Programming Lang: C
Description : TinyALSA is a small library to interface with ALSA in the 
Linux kernel.


TinyALSA is a small library to interface with ALSA in the Linux kernel.
The aims are:

Provide a basic pcm and mixer API.
If it's not absolutely needed, don't add it to the API.
Avoid supporting complex and unnecessary operations, that could be
dealt with at a higher level.
Provide comprehensive documentation.

FAQ:

Q: Why is this relevant?
A: It is a dependency of q6voiced, which I also would like to package 
once that is done, as q6voiced is required for call audio on phones that 
use a Qualcomm SoC. It is therefore an important ingedrient of porting 
Debian to many phone models.


Q: Is it a dependency of another package?
A: Yes, it is a dependency of q6voiced.

Q: Do you use it?
A: Yes, I've built a package already, now I want to get it into Debian.

Q: Are there other packages that provide similar functionality?
A: My research has not lead to finding any packages providing similar 
functionality.


Q: How are you planning to maintain the package?
A: It is a small package and does not have releases often, therefore it 
is managable. I will also talk to the Mobian team about this.


--
erebion



OpenPGP_0x8EAF40326E02AE7D.asc
Description: OpenPGP public key
BEGIN:VCARD
VERSION:4.0
N:;erebion;;;
FN:erebion
EMAIL;PREF=1:ereb...@erebion.eu
IMPP:matrix:u/erebion:erebion.eu
URL:https://erebion.eu
TZ:Europe/Berlin
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1079269: ITP: ocaml-intrinsics-kernel -- a library of intrinsics for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-intrinsics-kernel
  Version : 0.17.1
  Upstream Contact: Jane Street developers
* URL : https://github.com/janestreet/ocaml_intrinsics_kernel
* License : MIT
  Programming Lang: OCaml, C
  Description : a library of intrinsics for OCaml

 The ocaml_intrinsics_kernel library provides an OCaml interface to
 operations that have dedicated hardware instructions on some
 micro-architectures. Currently, it provides the following operations:
 .
  * conditional select
 .
 ocaml_intrinsics_kernel can be used by programs compiled to
 javascript.

This package is a new dependency of janest-base. It will be maintained
in the OCaml team.

Re: File descriptor hard limit is now bumped to the kernel max

[Michael Biebl]

Am 14.06.24 um 14:13 schrieb Mourad De Clerck:

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.


Hi,

It seems some proprietary software (the JetBrains IDEs) has some 
problems with this change.


See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522


See https://github.com/JetBrains/pty4j/pull/149

Feel free to upvote the MR.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: File descriptor hard limit is now bumped to the kernel max

[Luca Boccassi]

On Fri, 14 Jun 2024 at 13:21, Mourad De Clerck  wrote:
>
> > PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
> > bumped early at boot from 1048576 to the max value that the kernel
> > allows, which on amd64 is currently 1073741816.
>
> Hi,
>
> It seems some proprietary software (the JetBrains IDEs) has some
> problems with this change.
>
> See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522
>
> While I wait for them to fix this on their end, what's the best way to
> revert this to the original behaviour on my machine?
>
> I would think:
>
> echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf
>
> … would do the trick, but "ulimit -Hn" reports 524288.
>
> Something to do with DefaultLimitNOFILE=1024:524288 maybe? But
> overriding that didn't work.

For user instances the link you shared has a workaround, it has to do
with PAM limits, that should work.
Please keep the pressure on the upstream project to fix that bug as
well. Thanks.

Re: File descriptor hard limit is now bumped to the kernel max

[Mourad De Clerck]

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.


Hi,

It seems some proprietary software (the JetBrains IDEs) has some 
problems with this change.


See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522

While I wait for them to fix this on their end, what's the best way to 
revert this to the original behaviour on my machine?


I would think:

echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf

… would do the trick, but "ulimit -Hn" reports 524288.

Something to do with DefaultLimitNOFILE=1024:524288 maybe? But 
overriding that didn't work.


Thanks,

--
Mourad De Clerck

Re: File descriptor hard limit is now bumped to the kernel max

[Mike Hommey]

On Thu, Jun 06, 2024 at 06:39:15PM +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie  wrote:
> 
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffected anyway - unless some larger
> > component is raising rlim_cur.
> Something did, because inn would start reporting ~1G available fds and 
> then explode, and that patch solved the issue. :-)

There are conditions under which the 1024 limit doesn't apply, like
running in a docker container.

Mike

Re: File descriptor hard limit is now bumped to the kernel max

[Russ Allbery]

Simon McVittie  writes:
> On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:

>> Something did, because inn would start reporting ~1G available fds and
>> then explode, and that patch solved the issue. :-)

> It might be worthwhile to try to track down what larger component did
> this, because inheriting a larger rlim_cur without opt-in can also break
> users of select(2) as described in
> .

I took a quick look at the old INN source and didn't see anything obvious.
I was half-expecting it to do something like set the soft limit to the
hard limit (that sounds like a very INN sort of thing to do), but if so, I
couldn't find it in a quick search.

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

Re: File descriptor hard limit is now bumped to the kernel max

[Simon McVittie]

On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie  wrote:
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffected anyway - unless some larger
> > component is raising rlim_cur.
>
> Something did, because inn would start reporting ~1G available fds and 
> then explode, and that patch solved the issue. :-)

It might be worthwhile to try to track down what larger
component did this, because inheriting a larger rlim_cur
without opt-in can also break users of select(2) as described in
.

smcv

Re: File descriptor hard limit is now bumped to the kernel max

[Marco d'Itri]

On Jun 06, Simon McVittie  wrote:

> I believe the change Luca describes is increasing rlim_max (hard limit)
> but not rlim_cur (soft limit), and the code touched by that patch is
> looking at rlim_cur, so it should be unaffected anyway - unless some larger
> component is raising rlim_cur.
Something did, because inn would start reporting ~1G available fds and 
then explode, and that patch solved the issue. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: File descriptor hard limit is now bumped to the kernel max

[Simon McVittie]

On Thu, 06 Jun 2024 at 15:21:22 +0200, Marco d'Itri wrote:
> On Jun 06, Luca Boccassi  wrote:
> > The last time this was tried some packages were still not ready, so it
> > was patched out to let them be fixed.
>
> I missed the venerable inn 1.x at the time, and I never noticed that it 
> allocates some data structures for all available fds. Apparently this 
> worked well enough for 1M file descriptors, but not for 1G. :-)
> 
> The solution was easy enough:
> https://salsa.debian.org/md/inn/-/blob/master/debian/patches/limit_getfdcount

I believe the change Luca describes is increasing rlim_max (hard limit)
but not rlim_cur (soft limit), and the code touched by that patch is
looking at rlim_cur, so it should be unaffected anyway - unless some larger
component is raising rlim_cur.

Raising rlim_cur is also a problem for anything that relies on select(2),
which can only represent the first 1024 fds (based on FD_SETSIZE).

In (sufficiently) legacy-free code that can promise that it only uses more
scalable mechanisms like poll/epoll, close_range, and dynamically-sized
data structures, getting the benefit of this change requires locally
raising rlim_cur to match rlim_max, like e.g. dbus-daemon does.

However, if programs that raise the soft limit run subprocesses that are
outside their control, then they should also drop rlim_cur back to 1024
for those subprocesses, like dbus-daemon does for activated services.

smcv

Re: File descriptor hard limit is now bumped to the kernel max

[Marco d'Itri]

On Jun 06, Luca Boccassi  wrote:

> The last time this was tried some packages were still not ready, so it
> was patched out to let them be fixed. Enough time has passed now, and
> it's time to let any unknown leftover just break and be fixed. In all
> known cases, the buggy pattern was to manually iterate over the hard
> limit and close every FD one by one, which is completely unnecessary
> since kernel 5.9 (bullseye/oldstable) since the close_range() syscall
> is available, that can do it in one fell swoop. Any packages still
I missed the venerable inn 1.x at the time, and I never noticed that it 
allocates some data structures for all available fds. Apparently this 
worked well enough for 1M file descriptors, but not for 1G. :-)

The solution was easy enough:
https://salsa.debian.org/md/inn/-/blob/master/debian/patches/limit_getfdcount

-- 
ciao,
Marco


signature.asc
Description: PGP signature

File descriptor hard limit is now bumped to the kernel max

[Luca Boccassi]

Hi,

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.

(I meant to send this last week but it fell off the wagon and
languished in the draft folder, sorry!)

This allows modern applications to use as many file descriptors as they
want, since they are an extremely cheap resource nowadays, and it's
more important than ever given that, for example, process tracking is
switching over to PID FDs for security reasons. Please note that the
soft limit still is 1024, as that's what legacy syscalls like select()
can handle.

The last time this was tried some packages were still not ready, so it
was patched out to let them be fixed. Enough time has passed now, and
it's time to let any unknown leftover just break and be fixed. In all
known cases, the buggy pattern was to manually iterate over the hard
limit and close every FD one by one, which is completely unnecessary
since kernel 5.9 (bullseye/oldstable) since the close_range() syscall
is available, that can do it in one fell swoop. Any packages still
doing the iteration manually need to switch to close_range, which is
very simple to use and documented at:

https://man7.org/linux/man-pages/man2/close_range.2.html

Please enjoy your extra file descriptors responsibly.

-- 
Kind regards,
Luca Boccassi


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

Processed: reassigning bugreport to kernel

[Debian Bug Tracking System]

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

> reassign 1069735 linux-image-6.6.15-amd64
Bug #1069735 [general] general: atlantic driver doesn't work on thinkpad
Bug reassigned from package 'general' to 'linux-image-6.6.15-amd64'.
Ignoring request to alter found versions of bug #1069735 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1069735 to the same values 
previously set
> thanks
Stopping processing here.

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

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Traut Manuel LCPF-CH]

> On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
>> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
>>> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
>>>
>>> Hi. Thanks for your contribution. I looked at the upstream code a tiny
>>> bit, and it looks like it might have portability bug, at least on
>>> big-endian architectures. For instance:
>>>
>>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
>>>
>>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
>>> nice to fix. Are you upstream or do you know upstream? Can yall fix
>>> these?
>>>
>> The kernel expects a 4 byte write here, since unsigned long is defined as at 
>> least 32 bit this shall work on all architectures.
>>
>> If your concern is about endianess this is not in the current scope of 
>> libuio and needs to be addressed by a higher layer.
>>
>> I am very familiar with library and in close contact with upstream.
>>
> In the case of uio_disable_irq() the bug is nicely hidden by the fact
> that tmp is guaranteed to be all-zeroes. However, consider the previous
> function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
> then the "tmp" variable's value of 1 will be encoded in memory as
> 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
> When uio_enable_irq() calls write(..., &tmp, 4), it will only send
> the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
> So it turns out that uio_disable_irq() and uio_enable_irq() do
> exactly the same - send a 32-bit zero value to the kernel.
>
> ...of course, this will only happen on a big-endian system, as
> Dima Kogan was concerned about. On a little-endian system, this
> will work by chance.
>
> Is this the expected behavior indeed?

No it is not :) Thanks for the detailed explanation.

Looks this fix sane to you?
https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55

I am not sure if users also expect an automatic conversion for the read/write 
functions:
https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e

It will be somehow inconsistent since a user could also access the device 
memory by pointer:
https://github.com/manut/libuio/blob/add-ci/mem.c#L93
and than needs to take care on the endianess by its own anyway.

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Peter Pentchev]

On Wed, Mar 13, 2024 at 10:40:51AM +, Traut Manuel LCPF-CH wrote:
> > On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
> >> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
> >>> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
> >>>
> >>> Hi. Thanks for your contribution. I looked at the upstream code a tiny
> >>> bit, and it looks like it might have portability bug, at least on
> >>> big-endian architectures. For instance:
> >>>
> >>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
> >>>
> >>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
> >>> nice to fix. Are you upstream or do you know upstream? Can yall fix
> >>> these?
> >>>
> >> The kernel expects a 4 byte write here, since unsigned long is defined as 
> >> at least 32 bit this shall work on all architectures.
> >>
> >> If your concern is about endianess this is not in the current scope of 
> >> libuio and needs to be addressed by a higher layer.
> >>
> >> I am very familiar with library and in close contact with upstream.
> >>
> > In the case of uio_disable_irq() the bug is nicely hidden by the fact
> > that tmp is guaranteed to be all-zeroes. However, consider the previous
> > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
> > then the "tmp" variable's value of 1 will be encoded in memory as
> > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
> > When uio_enable_irq() calls write(..., &tmp, 4), it will only send
> > the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
> > So it turns out that uio_disable_irq() and uio_enable_irq() do
> > exactly the same - send a 32-bit zero value to the kernel.
> >
> > ...of course, this will only happen on a big-endian system, as
> > Dima Kogan was concerned about. On a little-endian system, this
> > will work by chance.
> >
> > Is this the expected behavior indeed?
> 
> No it is not :) Thanks for the detailed explanation.
> 
> Looks this fix sane to you?
> https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55

Yeah, after I sent the e-mails I realized that I forgot to mention that
using uint32_t would be one of the best ways to fix that.

Thanks for the fast reaction!

> I am not sure if users also expect an automatic conversion for the read/write 
> functions:
> https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e
> 
> It will be somehow inconsistent since a user could also access the device 
> memory by pointer:
> https://github.com/manut/libuio/blob/add-ci/mem.c#L93
> and than needs to take care on the endianess by its own anyway.

...and this part I have no opinion about. I don't have any realistic
idea about how people actually use libuio (or how they will use it),
and I do not think that I will use it soon, so this should be left for
others to decide.

Thanks again for paying attention to the comments!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Peter Pentchev]

On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
> > Hi Dima,
> > 
> > > On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
> > > 
> > > Hi. Thanks for your contribution. I looked at the upstream code a tiny
> > > bit, and it looks like it might have portability bug, at least on
> > > big-endian architectures. For instance:
> > > 
> > >  
> > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
> > > 
> > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be
> > > nice to fix. Are you upstream or do you know upstream? Can yall fix
> > > these?
> > 
> > The kernel expects a 4 byte write here, since unsigned long is defined as 
> > at least 32 bit this shall work on all architectures.
> > 
> > If your concern is about endianess this is not in the current scope of 
> > libuio and needs to be addressed by a higher layer.
> > 
> > I am very familiar with library and in close contact with upstream.
> 
> In the case of uio_disable_irq() the bug is nicely hidden by the fact
> that tmp is guaranteed to be all-zeroes. However, consider the previous
> function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
> then the "tmp" variable's value of 1 will be encoded in memory as
> 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
> When uio_enable_irq() calls write(..., &tmp, 4), it will only send
> the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
> So it turns out that uio_disable_irq() and uio_enable_irq() do
> exactly the same - send a 32-bit zero value to the kernel.

...of course, this will only happen on a big-endian system, as
Dima Kogan was concerned about. On a little-endian system, this
will work by chance.

> Is this the expected behavior indeed?

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Peter Pentchev]

On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
> Hi Dima,
> 
> > On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
> > 
> > Hi. Thanks for your contribution. I looked at the upstream code a tiny
> > bit, and it looks like it might have portability bug, at least on
> > big-endian architectures. For instance:
> > 
> >  
> > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
> > 
> > This assumes that sizeof(long)==4. Maybe this is benign, but it would be
> > nice to fix. Are you upstream or do you know upstream? Can yall fix
> > these?
> 
> The kernel expects a 4 byte write here, since unsigned long is defined as at 
> least 32 bit this shall work on all architectures.
> 
> If your concern is about endianess this is not in the current scope of libuio 
> and needs to be addressed by a higher layer.
> 
> I am very familiar with library and in close contact with upstream.

In the case of uio_disable_irq() the bug is nicely hidden by the fact
that tmp is guaranteed to be all-zeroes. However, consider the previous
function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
then the "tmp" variable's value of 1 will be encoded in memory as
8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
When uio_enable_irq() calls write(..., &tmp, 4), it will only send
the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
So it turns out that uio_disable_irq() and uio_enable_irq() do
exactly the same - send a 32-bit zero value to the kernel.

Is this the expected behavior indeed?

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Manuel Traut]

Hi Dima,

> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
> 
> Hi. Thanks for your contribution. I looked at the upstream code a tiny
> bit, and it looks like it might have portability bug, at least on
> big-endian architectures. For instance:
> 
>  
> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
> 
> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
> nice to fix. Are you upstream or do you know upstream? Can yall fix
> these?

The kernel expects a 4 byte write here, since unsigned long is defined as at 
least 32 bit this shall work on all architectures.

If your concern is about endianess this is not in the current scope of libuio 
and needs to be addressed by a higher layer.

I am very familiar with library and in close contact with upstream.

Best regards 
Manuel

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Manuel Traut]

> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
> 
> Hi. Thanks for your contribution. I looked at the upstream code a tiny
> bit, and it looks like it might have portability bug, at least on
> big-endian architectures. For instance:
> 
>  
> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78

Thanks for having a look. I will take care.

> 
> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
> nice to fix. Are you upstream or do you know upstream? Can yall fix
> these?

I will try to do a MR upstream


> 
> Thanks!
> 

Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Dima Kogan]

Hi. Thanks for your contribution. I looked at the upstream code a tiny
bit, and it looks like it might have portability bug, at least on
big-endian architectures. For instance:

  
https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78

This assumes that sizeof(long)==4. Maybe this is benign, but it would be
nice to fix. Are you upstream or do you know upstream? Can yall fix
these?

Thanks!

Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Manuel Traut]

Package: wnpp
Severity: wishlist
Owner: Manuel Traut 
X-Debbugs-Cc: debian-devel@lists.debian.org, ma...@mecka.net

* Package name: libuio
 Version : 0.2.8
 Upstream Contact: Benedikt Spranger 
* URL : https://github.com/missinglinkelectronics/libuio
* License : LGPL
 Programming Lang: C
 Description : Linux Kernel UserspaceIO helper library

A small Userspace IO driver helper library.
More details about UIO can be found here:
https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html

UIO can be used to map device memory and interrupts into user-space.
It is used to write user-space drivers for devices that do not fit in
any existing kernel subsystem.

libuio makes it easy to access a UIO device from user-space. It is
what is libgpio for GPIOs or libiio for IIO devices.

I would need a sponsor to upload this package.

Re: Kernel 6.5 from Experimental working

[Luna Jernberg]

Also updated this to 6.5.1 today and still works

Den tors 7 sep. 2023 kl 08:37 skrev Luna Jernberg :
>
> Hey!
>
> Just installed Kernel 6.5 from experimental during Debcamp 2023 on my
> ThinkPad Edge 0217A16 and it works as intended on this laptop :)
>
> //Luna bittin Jernberg 

Bug#1049961: ITP: composable-kernel -- library for writing performance critical kernels for ML workloads

[Christian Kastner]

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

* Package name: composable-kernel
  Version : 0+git20230816
  Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform/composable_kernel
* License : MIT
  Programming Lang: C++
  Description : library for writing performance critical kernels for ML 
workloads

Composable Kernel (CK) library aims to provide a programming model for
writing performance critical kernels for machine learning workloads
across multiple architectures including GPUs, CPUs, etc, through general
purpose kernel languages, like HIP C++.

CK utilizes two concepts to achieve performance portability and code
maintainability:

 * A tile-based programming model
 * Algorithm complexity reduction for complex ML operators, using
   innovative technique we call "Tensor Coordinate Transformation".

This is needed by MIOpen, which is also in the process of being
packaged.

This will be maintained by the Debian ROCm Team.

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org, 
Steve Dickson , Chuck Lever III 

* Package name: ktls-utils
  Version : 0.9
  Upstream Contact: kernel-tls-handsh...@lists.linux.dev
* URL : https://github.com/oracle/ktls-utils
* License : GPLv2
  Programming Lang: C
  Description : TLS handshake utilities for in-kernel TLS consumers

In-kernel TLS consumers need a mechanism to perform TLS handshakes on
a connected socket to negotiate TLS session parameters that can then
be programmed into the kernel's TLS record protocol engine.

This package of software provides a TLS handshake user agent that
listens for kernel requests and then materializes a user space socket
endpoint on which to perform these handshakes. The resulting
negotiated session parameters are passed back to the kernel via
standard kTLS socket options.

This will be maintained by the kernel team.

Bug#1041189: general: Optimize kernel settings for gaming

[Yves]

Package: general
Severity: wishlist
X-Debbugs-Cc: yves.quey...@gmail.com

Dear maintainer,

By default with Debian 12 Bookworm, the file named 
"/etc/sysctl.d/99-sysctl.conf" contains a lot of settings, but they are all 
disabled.
It coult be interesting to add and activate the following setting by default : 
vm.max_map_count=2147483642
This option is already set by default with other Linux distributions like 
Fedora. 
It is useful to optimize performances for gaming.
This setting increases memory allocated to the game.

I hope this suggestion will be useful.

Thanks in advance.
Yves

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello Ricardo,

  Yes, I'll try to get to it later today or over the weekend.

On Fri, 30 Jun 2023 at 13:56, Ricardo Ribalda Delgado
 wrote:
>
> Hi Hector
>
> Can you check the current version on my repo? i think it is on a good
> state to push it
>
> Thanks!
>
> On Tue, Jun 20, 2023 at 4:19 PM Andrea Righi  
> wrote:
> >
> > Hi Ricardo,
> >
> > On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote:
> > ...
> > > > > > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > > > > > >
> > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > > > > > >
> > > > > > > > Hector, Andrea, can you take a look at it?
> > > > > > > >
> > > > > > > > Hector the fun bits are at
> > > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > > > > > >
> > > > > > > Reviewed and added some comments, thanks!
> >
> > FYI, I've applied all your debian/ changes (with some adjustments) to my
> > git repo, I think we should be (more or less) aligned now.
> >
> > At some point, if this package lands in Debian I would like to remove
> > the debian/ folder from my upstream repository and completely rely on
> > the Debian one for the deb packaging, but for now I'm maintaining it
> > also upstream, so that we have a central point that can use as a
> > reference for all the next changes.
> >
> > Thanks,
> > -Andrea



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi Hector

Can you check the current version on my repo? i think it is on a good
state to push it

Thanks!

On Tue, Jun 20, 2023 at 4:19 PM Andrea Righi  wrote:
>
> Hi Ricardo,
>
> On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote:
> ...
> > > > > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > > > > >
> > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > > > > >
> > > > > > > Hector, Andrea, can you take a look at it?
> > > > > > >
> > > > > > > Hector the fun bits are at
> > > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > > > > >
> > > > > > Reviewed and added some comments, thanks!
>
> FYI, I've applied all your debian/ changes (with some adjustments) to my
> git repo, I think we should be (more or less) aligned now.
>
> At some point, if this package lands in Debian I would like to remove
> the debian/ folder from my upstream repository and completely rely on
> the Debian one for the deb packaging, but for now I'm maintaining it
> also upstream, so that we have a central point that can use as a
> reference for all the next changes.
>
> Thanks,
> -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

Hi Ricardo,

On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote:
...
> > > > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > > > >
> > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > > > >
> > > > > > Hector, Andrea, can you take a look at it?
> > > > > >
> > > > > > Hector the fun bits are at
> > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > > > >
> > > > > Reviewed and added some comments, thanks!

FYI, I've applied all your debian/ changes (with some adjustments) to my
git repo, I think we should be (more or less) aligned now.

At some point, if this package lands in Debian I would like to remove
the debian/ folder from my upstream repository and completely rely on
the Debian one for the deb packaging, but for now I'm maintaining it
also upstream, so that we have a central point that can use as a
reference for all the next changes.

Thanks,
-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, Jun 20, 2023 at 02:17:38PM +0200, Ricardo Ribalda Delgado wrote:
> Hi Andrea
> 
> On Tue, Jun 20, 2023 at 10:02 AM Andrea Righi
>  wrote:
> >
> > On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote:
> > > On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote:
> > > > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi 
> > > >  wrote:
> > > > >
> > > > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado 
> > > > > wrote:
> > > > > > Hi
> > > > > >
> > > > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > > > >
> > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > > > >
> > > > > > Hector, Andrea, can you take a look at it?
> > > > > >
> > > > > > Hector the fun bits are at
> > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > > > >
> > > > > Reviewed and added some comments, thanks!
> > > > >
> > > > > >
> > > > > > Andrea: the build seems to be having issues with 32 bits:
> > > > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
> > > > >
> > > > > Ah yes, I hit that yesterday as well:
> > > > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
> > > >
> > > > Can you check  if
> > > > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
> > > > does the trick for you?
> > >
> > > usize seems to do the trick for me, I think it's more portable than
> > > c_ulong (that comes from std::os::raw:c_ulong).
> 
> I thought  that std::os::raw:c_ulong was more or less ok, as I said...
> me no rust :P

I think they are both ok, I prefer usize just because it is more
idiomatic Rust (usize is actually a distinct type) and c_ulong is
provided to maintain compatibility with libc.

> 
> 
> > >
> > > I'll push a fix soon, I just want to make sure it builds everywhere
> > > (testing right now). :)
> >
> > I confirm that this one seems to fix the build error:
> > https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29
> >
> > I'd like to cut a new version (v1.11) at this point, if/when you have a
> > new PR ready I can also include your changes (no rush).
> 
> Cool, let me know when you want to land it, so I update my package.

Ok, will do.

> 
> I have added support for cross-compilation of the package:
> https://salsa.debian.org/ribalda/virtme-ng/-/commit/0e6ffec3897504ef1b7af7171f3b9cf68decfc76
> 
> Also, to ease the development at some point we should converge on the
> content of the debian folder. Is the package already in ubuntu?

Absolutely, I would like to apply all your changes so that the content
of debian/ upstream will be the same as yours.

The package for Ubuntu is only available in a ppa at the moment. My plan
is to land a proper package in Debian and then ask a resync of the same
package in Ubuntu.

Thanks,
-andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi Andrea

On Tue, Jun 20, 2023 at 10:02 AM Andrea Righi
 wrote:
>
> On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote:
> > On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote:
> > > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi  
> > > wrote:
> > > >
> > > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > > > > Hi
> > > > >
> > > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > > >
> > > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > > >
> > > > > Hector, Andrea, can you take a look at it?
> > > > >
> > > > > Hector the fun bits are at
> > > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > > >
> > > > Reviewed and added some comments, thanks!
> > > >
> > > > >
> > > > > Andrea: the build seems to be having issues with 32 bits:
> > > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
> > > >
> > > > Ah yes, I hit that yesterday as well:
> > > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
> > >
> > > Can you check  if
> > > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
> > > does the trick for you?
> >
> > usize seems to do the trick for me, I think it's more portable than
> > c_ulong (that comes from std::os::raw:c_ulong).

I thought  that std::os::raw:c_ulong was more or less ok, as I said...
me no rust :P


> >
> > I'll push a fix soon, I just want to make sure it builds everywhere
> > (testing right now). :)
>
> I confirm that this one seems to fix the build error:
> https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29
>
> I'd like to cut a new version (v1.11) at this point, if/when you have a
> new PR ready I can also include your changes (no rush).

Cool, let me know when you want to land it, so I update my package.

I have added support for cross-compilation of the package:
https://salsa.debian.org/ribalda/virtme-ng/-/commit/0e6ffec3897504ef1b7af7171f3b9cf68decfc76

Also, to ease the development at some point we should converge on the
content of the debian folder. Is the package already in ubuntu?



Cheeers!

>
> -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, Jun 20, 2023 at 09:19:58AM +0200, Andrea Righi wrote:
> On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote:
> > On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi  
> > wrote:
> > >
> > > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > > > Hi
> > > >
> > > > I have updated my repo to uprev v1.10 and support argcomple3.
> > > >
> > > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > > >
> > > > Hector, Andrea, can you take a look at it?
> > > >
> > > > Hector the fun bits are at
> > > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> > >
> > > Reviewed and added some comments, thanks!
> > >
> > > >
> > > > Andrea: the build seems to be having issues with 32 bits:
> > > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
> > >
> > > Ah yes, I hit that yesterday as well:
> > > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
> > 
> > Can you check  if
> > https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
> > does the trick for you?
> 
> usize seems to do the trick for me, I think it's more portable than
> c_ulong (that comes from std::os::raw:c_ulong).
> 
> I'll push a fix soon, I just want to make sure it builds everywhere
> (testing right now). :)

I confirm that this one seems to fix the build error:
https://github.com/arighi/virtme-ng/commit/438158e15a8af04fadfbb3943a227271db4b6e29

I'd like to cut a new version (v1.11) at this point, if/when you have a
new PR ready I can also include your changes (no rush).

-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, Jun 20, 2023 at 08:47:54AM +0200, Ricardo Ribalda Delgado wrote:
> On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi  
> wrote:
> >
> > On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > > Hi
> > >
> > > I have updated my repo to uprev v1.10 and support argcomple3.
> > >
> > > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> > >
> > > Hector, Andrea, can you take a look at it?
> > >
> > > Hector the fun bits are at
> > > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
> >
> > Reviewed and added some comments, thanks!
> >
> > >
> > > Andrea: the build seems to be having issues with 32 bits:
> > > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
> >
> > Ah yes, I hit that yesterday as well:
> > https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz
> 
> Can you check  if
> https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
> does the trick for you?

usize seems to do the trick for me, I think it's more portable than
c_ulong (that comes from std::os::raw:c_ulong).

I'll push a fix soon, I just want to make sure it builds everywhere
(testing right now). :)

-Andrea

> 
> warning! not a rust hacker myself :P
> 
> >
> > Part of these errors are fixed by:
> > `879b4d4 ("virtme-ng-init: support 32-bit architectures")`
> >
> > But there are still some 32-bit related errors, I'll push an additional
> > fix later today.
> >
> > -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

On Tue, Jun 20, 2023 at 7:46 AM Andrea Righi  wrote:
>
> On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> > Hi
> >
> > I have updated my repo to uprev v1.10 and support argcomple3.
> >
> > https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> >
> > Hector, Andrea, can you take a look at it?
> >
> > Hector the fun bits are at
> > https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c
>
> Reviewed and added some comments, thanks!
>
> >
> > Andrea: the build seems to be having issues with 32 bits:
> > https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837
>
> Ah yes, I hit that yesterday as well:
> https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz

Can you check  if
https://salsa.debian.org/ribalda/virtme-ng/-/blob/debian/debian/patches/32bit.patch
does the trick for you?

warning! not a rust hacker myself :P

>
> Part of these errors are fixed by:
> `879b4d4 ("virtme-ng-init: support 32-bit architectures")`
>
> But there are still some 32-bit related errors, I'll push an additional
> fix later today.
>
> -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Mon, Jun 19, 2023 at 09:54:41PM +0200, Ricardo Ribalda Delgado wrote:
> Hi
> 
> I have updated my repo to uprev v1.10 and support argcomple3.
> 
> https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian
> 
> Hector, Andrea, can you take a look at it?
> 
> Hector the fun bits are at
> https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c

Reviewed and added some comments, thanks!

> 
> Andrea: the build seems to be having issues with 32 bits:
> https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837

Ah yes, I hit that yesterday as well:
https://launchpadlibrarian.net/673040751/buildlog_ubuntu-mantic-armhf.virtme-ng_1.12-1ubuntu1_BUILDING.txt.gz

Part of these errors are fixed by:
`879b4d4 ("virtme-ng-init: support 32-bit architectures")`

But there are still some 32-bit related errors, I'll push an additional
fix later today.

-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi

I have updated my repo to uprev v1.10 and support argcomple3.

https://salsa.debian.org/ribalda/virtme-ng/-/tree/debian

Hector, Andrea, can you take a look at it?

Hector the fun bits are at
https://salsa.debian.org/ribalda/virtme-ng/-/merge_requests/1/diffs?commit_id=943dd90136e5e30fc39d0061347fea3bcbe44c4c

Andrea: the build seems to be having issues with 32 bits:
https://salsa.debian.org/ribalda/virtme-ng/-/jobs/4338837


Thanks!


On Mon, Jun 19, 2023 at 2:27 PM Andrea Righi  wrote:
>
> On Mon, Jun 19, 2023 at 02:15:51PM +0200, Héctor Orón Martínez wrote:
> > Hello,
> >
> > On Mon, 19 Jun 2023 at 13:56, Andrea Righi  
> > wrote:
> > >
> > > On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote:
> > > > Hello Andrea,
> > > >
> > > > On Wed, 31 May 2023 at 20:47, Andrea Righi  
> > > > wrote:
> > > >
> > > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado 
> > > > > wrote:
> > > >
> > > > > > I think I have the first version of virtme-ng.
> > > > > >
> > > > > > @Héctor Orón Martínez can you help reviewing and pushing
> > > > > > https://salsa.debian.org/ribalda/virtme-ng ?
> > > > > >
> > > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng
> > > > >
> > > > > Is there any update on this? Anything I can do to help?
> > > >
> > > > I tried to build the package posted in the salsa repo, but failed for
> > > > me, then I was unable to get back to this. Have you been able to
> > > > review such a source tree?
> > >
> > > I'm able to build the package from Ricardo's repo. It's still at v1.6
> > > and upstream is already v1.10, but in general it looks good to me.
> > >
> > > What error did you get?
> >
> > I tried in a different machine now:
> >
> > register-python-argcomplete virtme-ng > virtme-ng-prompt
> > /bin/sh: line 1: register-python-argcomplete: command not found
> >
> > This should be register-python-argcomplete3, solving that issue I was
> > able to build it.
>
> Oh I see, in Ubuntu python3-argcomplete provides
> register-python-argcomplete, while in Debian it's
> register-python-argcomplete3.
>
> Not sure why it's different, maybe we should just do something like the
> following to support both (if you like it I'll apply it upstream).
>
> Thanks for checking!
> -Andrea
>
>  debian/rules | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/debian/rules b/debian/rules
> index db18ccd..0888cf2 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,7 +1,13 @@
>  #!/usr/bin/make -f
>
> +ARGCOMPLETE := $(shell command -v register-python-argcomplete3 2>/dev/null 
> || command -v register-python-argcomplete 2>/dev/null)
> +
> +ifeq ($(strip $(ARGCOMPLETE)),)
> +$(error Neither register-python-argcomplete nor 
> register-python-argcomplete3 found in PATH)
> +endif
> +
>  virtme-ng-prompt:
> -   register-python-argcomplete virtme-ng vng > $@
> +   $(ARGCOMPLETE) virtme-ng vng > $@
>
>  %:
> dh $@ --with python3 --buildsystem=pybuild
>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Mon, Jun 19, 2023 at 02:15:51PM +0200, Héctor Orón Martínez wrote:
> Hello,
> 
> On Mon, 19 Jun 2023 at 13:56, Andrea Righi  wrote:
> >
> > On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote:
> > > Hello Andrea,
> > >
> > > On Wed, 31 May 2023 at 20:47, Andrea Righi  
> > > wrote:
> > >
> > > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:
> > >
> > > > > I think I have the first version of virtme-ng.
> > > > >
> > > > > @Héctor Orón Martínez can you help reviewing and pushing
> > > > > https://salsa.debian.org/ribalda/virtme-ng ?
> > > > >
> > > > > Maybe you could also create salsa.debian.org/debian/virtme-ng
> > > >
> > > > Is there any update on this? Anything I can do to help?
> > >
> > > I tried to build the package posted in the salsa repo, but failed for
> > > me, then I was unable to get back to this. Have you been able to
> > > review such a source tree?
> >
> > I'm able to build the package from Ricardo's repo. It's still at v1.6
> > and upstream is already v1.10, but in general it looks good to me.
> >
> > What error did you get?
> 
> I tried in a different machine now:
> 
> register-python-argcomplete virtme-ng > virtme-ng-prompt
> /bin/sh: line 1: register-python-argcomplete: command not found
> 
> This should be register-python-argcomplete3, solving that issue I was
> able to build it.

Oh I see, in Ubuntu python3-argcomplete provides
register-python-argcomplete, while in Debian it's
register-python-argcomplete3.

Not sure why it's different, maybe we should just do something like the
following to support both (if you like it I'll apply it upstream).

Thanks for checking!
-Andrea

 debian/rules | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index db18ccd..0888cf2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,13 @@
 #!/usr/bin/make -f
 
+ARGCOMPLETE := $(shell command -v register-python-argcomplete3 2>/dev/null || 
command -v register-python-argcomplete 2>/dev/null)
+
+ifeq ($(strip $(ARGCOMPLETE)),)
+$(error Neither register-python-argcomplete nor 
register-python-argcomplete3 found in PATH)
+endif
+
 virtme-ng-prompt:
-   register-python-argcomplete virtme-ng vng > $@
+   $(ARGCOMPLETE) virtme-ng vng > $@
 
 %:
dh $@ --with python3 --buildsystem=pybuild

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello,

On Mon, 19 Jun 2023 at 13:56, Andrea Righi  wrote:
>
> On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote:
> > Hello Andrea,
> >
> > On Wed, 31 May 2023 at 20:47, Andrea Righi  
> > wrote:
> >
> > > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:
> >
> > > > I think I have the first version of virtme-ng.
> > > >
> > > > @Héctor Orón Martínez can you help reviewing and pushing
> > > > https://salsa.debian.org/ribalda/virtme-ng ?
> > > >
> > > > Maybe you could also create salsa.debian.org/debian/virtme-ng
> > >
> > > Is there any update on this? Anything I can do to help?
> >
> > I tried to build the package posted in the salsa repo, but failed for
> > me, then I was unable to get back to this. Have you been able to
> > review such a source tree?
>
> I'm able to build the package from Ricardo's repo. It's still at v1.6
> and upstream is already v1.10, but in general it looks good to me.
>
> What error did you get?

I tried in a different machine now:

register-python-argcomplete virtme-ng > virtme-ng-prompt
/bin/sh: line 1: register-python-argcomplete: command not found

This should be register-python-argcomplete3, solving that issue I was
able to build it.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Mon, Jun 19, 2023 at 01:20:04PM +0200, Héctor Orón Martínez wrote:
> Hello Andrea,
> 
> On Wed, 31 May 2023 at 20:47, Andrea Righi  wrote:
> 
> > On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:
> 
> > > I think I have the first version of virtme-ng.
> > >
> > > @Héctor Orón Martínez can you help reviewing and pushing
> > > https://salsa.debian.org/ribalda/virtme-ng ?
> > >
> > > Maybe you could also create salsa.debian.org/debian/virtme-ng
> >
> > Is there any update on this? Anything I can do to help?
> 
> I tried to build the package posted in the salsa repo, but failed for
> me, then I was unable to get back to this. Have you been able to
> review such a source tree?

I'm able to build the package from Ricardo's repo. It's still at v1.6
and upstream is already v1.10, but in general it looks good to me.

What error did you get?

-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello Andrea,

On Wed, 31 May 2023 at 20:47, Andrea Righi  wrote:

> On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:

> > I think I have the first version of virtme-ng.
> >
> > @Héctor Orón Martínez can you help reviewing and pushing
> > https://salsa.debian.org/ribalda/virtme-ng ?
> >
> > Maybe you could also create salsa.debian.org/debian/virtme-ng
>
> Is there any update on this? Anything I can do to help?

I tried to build the package posted in the salsa repo, but failed for
me, then I was unable to get back to this. Have you been able to
review such a source tree?

Regards

> > >> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias  
> > >> > escribió:
> > >> >>
> > >> >> Oh, I did not note/check that virtme already exists in Debian.
> > >> >>
> > >> >> Anyway, I am interest in the package, so I will follow 
> > >> >> virtme/virme-ng project :-)
> > >> >>
> > >> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
> > >> >>  escribió:
> > >> >>>
> > >> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
> > >> >>>  wrote:
> > >> >>> >
> > >> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado 
> > >> >>> > wrote:
> > >> >>> > > Hi
> > >> >>> > >
> > >> >>> > >
> > >> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> > >> >>> > >  wrote:
> > >> >>> > > >
> > >> >>> > > > Hello,
> > >> >>> > > >
> > >> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
> > >> >>> > > >  escribió:
> > >> >>> > > >>
> > >> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón 
> > >> >>> > > >> Martínez wrote:
> > >> >>> > > >> > Hello,
> > >> >>> > > >> >
> > >> >>> > > >> >   virtme already exists in Debian, what would be the 
> > >> >>> > > >> > benefit of virtme-ng
> > >> >>> > > >> > over virtme?
> > >> >>> > > >> >
> > >> >>> > > >> > https://salsa.debian.org/debian/virtme
> > >> >>> > > >> >
> > >> >>> > > >> > Regards
> > >> >>> > > >>
> > >> >>> > > >> The original virtme project is not maintained anymore
> > >> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the 
> > >> >>> > > >> project
> > >> >>> > > >> and continue the development / bug fixing in virtme-ng
> > >> >>> > > >> (https://github.com/arighi/virtme-ng).
> > >> >>> > > >>
> > >> >>> > > >> Some people are already using and contributing to virtme-ng 
> > >> >>> > > >> and there
> > >> >>> > > >> are plans to package it in SuSE.
> > >> >>> > > >>
> > >> >>> > > >> Honestly I don't know what would be the right procedure to 
> > >> >>> > > >> "obsolete"
> > >> >>> > > >> the old virtme package and replace it virtme-ng (if 
> > >> >>> > > >> possible), but
> > >> >>> > > >> ideally it would be nice to do something like this. Any 
> > >> >>> > > >> guidance or
> > >> >>> > > >> suggestion is welcome.
> > >> >>> > > >
> > >> >>> > > >
> > >> >>> > > > I suggest we evaluate switching upstream from virtme to 
> > >> >>> > > > virtme-ng, on the Debian virtme package. I would not mind if 
> > >> >>> > > > you want to be added as uploader for the package.
> > >> >>> > > >
> > >> >>> > > > Ricardo has been working on virtme. What do you think?
> > >> >>> > >
> > >> >>> > > SGTM. Maybe we can send an email out of courtesy to the old 
> > >> >>> > > virtme author.
> > >> >>> >
> > >> >>> > All good to me as well! I already sent an email to the virtme 
> > >> >>> > author
> > >> >>> > (Andrew Lutomirski) to inform him that I was forking the project, 
> > >> >>> > but I
> > >> >>> > didn't get any response.
> > >> >>>
> > >> >>> That sounds good.
> > >> >>>
> > >> >>> >
> > >> >>> > Maybe I can try to ping him again and see if he's also happy about 
> > >> >>> > this
> > >> >>> > plan.
> > >> >>>
> > >> >>> May I suggest that when you ping them, tell them about the plans to
> > >> >>> replace virtme with virtme-ng on Debian and put  me on cc?
> > >> >>>
> > >> >>> Thanks!
> > >> >>>
> > >> >>>
> > >> >>> >
> > >> >>> > -Andrea



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:
> Hi all
> 
> I think I have the first version of virtme-ng.
> 
> @Héctor Orón Martínez can you help reviewing and pushing
> https://salsa.debian.org/ribalda/virtme-ng ?
> 
> Maybe you could also create salsa.debian.org/debian/virtme-ng

Is there any update on this? Anything I can do to help?

-Andrea

> 
> 
> Thanks and regards!
> 
> On Wed, May 10, 2023 at 5:04 PM Emmanuel Arias  wrote:
> >
> >
> >
> >
> > On Wed, May 10, 2023 at 11:41 AM Ricardo Ribalda Delgado 
> >  wrote:
> >>
> >> Hi Emmanuel
> >>
> >>
> >> On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
> >> >
> >> > Upstream respond  without  objection. Is there any volunter  to this 
> >> > transition?  If not i would happy to work on it.
> >>
> >> I can take care of it. I won't probably start until the weekend though
> >
> >
> > Sounds good, thanks!
> >
> > Cheers,
> >>
> >>
> >> Regards
> >>
> >> >
> >> > Cheers
> >> >
> >> >
> >> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias  
> >> > escribió:
> >> >>
> >> >> Oh, I did not note/check that virtme already exists in Debian.
> >> >>
> >> >> Anyway, I am interest in the package, so I will follow virtme/virme-ng 
> >> >> project :-)
> >> >>
> >> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
> >> >>  escribió:
> >> >>>
> >> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
> >> >>>  wrote:
> >> >>> >
> >> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado 
> >> >>> > wrote:
> >> >>> > > Hi
> >> >>> > >
> >> >>> > >
> >> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> >> >>> > >  wrote:
> >> >>> > > >
> >> >>> > > > Hello,
> >> >>> > > >
> >> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
> >> >>> > > >  escribió:
> >> >>> > > >>
> >> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez 
> >> >>> > > >> wrote:
> >> >>> > > >> > Hello,
> >> >>> > > >> >
> >> >>> > > >> >   virtme already exists in Debian, what would be the benefit 
> >> >>> > > >> > of virtme-ng
> >> >>> > > >> > over virtme?
> >> >>> > > >> >
> >> >>> > > >> > https://salsa.debian.org/debian/virtme
> >> >>> > > >> >
> >> >>> > > >> > Regards
> >> >>> > > >>
> >> >>> > > >> The original virtme project is not maintained anymore
> >> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the 
> >> >>> > > >> project
> >> >>> > > >> and continue the development / bug fixing in virtme-ng
> >> >>> > > >> (https://github.com/arighi/virtme-ng).
> >> >>> > > >>
> >> >>> > > >> Some people are already using and contributing to virtme-ng and 
> >> >>> > > >> there
> >> >>> > > >> are plans to package it in SuSE.
> >> >>> > > >>
> >> >>> > > >> Honestly I don't know what would be the right procedure to 
> >> >>> > > >> "obsolete"
> >> >>> > > >> the old virtme package and replace it virtme-ng (if possible), 
> >> >>> > > >> but
> >> >>> > > >> ideally it would be nice to do something like this. Any 
> >> >>> > > >> guidance or
> >> >>> > > >> suggestion is welcome.
> >> >>> > > >
> >> >>> > > >
> >> >>> > > > I suggest we evaluate switching upstream from virtme to 
> >> >>> > > > virtme-ng, on the Debian virtme package. I would not mind if you 
> >> >>> > > > want to be added as uploader for the package.
> >> >>> > > >
> >> >>> > > > Ricardo has been working on virtme. What do you think?
> >> >>> > >
> >> >>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme 
> >> >>> > > author.
> >> >>> >
> >> >>> > All good to me as well! I already sent an email to the virtme author
> >> >>> > (Andrew Lutomirski) to inform him that I was forking the project, 
> >> >>> > but I
> >> >>> > didn't get any response.
> >> >>>
> >> >>> That sounds good.
> >> >>>
> >> >>> >
> >> >>> > Maybe I can try to ping him again and see if he's also happy about 
> >> >>> > this
> >> >>> > plan.
> >> >>>
> >> >>> May I suggest that when you ping them, tell them about the plans to
> >> >>> replace virtme with virtme-ng on Debian and put  me on cc?
> >> >>>
> >> >>> Thanks!
> >> >>>
> >> >>>
> >> >>> >
> >> >>> > -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Mon, May 15, 2023 at 10:45:15PM +0200, Ricardo Ribalda Delgado wrote:
> Hi all
> 
> I think I have the first version of virtme-ng.
> 
> @Héctor Orón Martínez can you help reviewing and pushing
> https://salsa.debian.org/ribalda/virtme-ng ?
> 
> Maybe you could also create salsa.debian.org/debian/virtme-ng
> 
> 
> Thanks and regards!

Thank you so much for this Ricardo, and thank you for picking 1.6, that
I just released a few hours ago. Perfect timing! :)

-Andrea

> 
> On Wed, May 10, 2023 at 5:04 PM Emmanuel Arias  wrote:
> >
> >
> >
> >
> > On Wed, May 10, 2023 at 11:41 AM Ricardo Ribalda Delgado 
> >  wrote:
> >>
> >> Hi Emmanuel
> >>
> >>
> >> On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
> >> >
> >> > Upstream respond  without  objection. Is there any volunter  to this 
> >> > transition?  If not i would happy to work on it.
> >>
> >> I can take care of it. I won't probably start until the weekend though
> >
> >
> > Sounds good, thanks!
> >
> > Cheers,
> >>
> >>
> >> Regards
> >>
> >> >
> >> > Cheers
> >> >
> >> >
> >> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias  
> >> > escribió:
> >> >>
> >> >> Oh, I did not note/check that virtme already exists in Debian.
> >> >>
> >> >> Anyway, I am interest in the package, so I will follow virtme/virme-ng 
> >> >> project :-)
> >> >>
> >> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
> >> >>  escribió:
> >> >>>
> >> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
> >> >>>  wrote:
> >> >>> >
> >> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado 
> >> >>> > wrote:
> >> >>> > > Hi
> >> >>> > >
> >> >>> > >
> >> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> >> >>> > >  wrote:
> >> >>> > > >
> >> >>> > > > Hello,
> >> >>> > > >
> >> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
> >> >>> > > >  escribió:
> >> >>> > > >>
> >> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez 
> >> >>> > > >> wrote:
> >> >>> > > >> > Hello,
> >> >>> > > >> >
> >> >>> > > >> >   virtme already exists in Debian, what would be the benefit 
> >> >>> > > >> > of virtme-ng
> >> >>> > > >> > over virtme?
> >> >>> > > >> >
> >> >>> > > >> > https://salsa.debian.org/debian/virtme
> >> >>> > > >> >
> >> >>> > > >> > Regards
> >> >>> > > >>
> >> >>> > > >> The original virtme project is not maintained anymore
> >> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the 
> >> >>> > > >> project
> >> >>> > > >> and continue the development / bug fixing in virtme-ng
> >> >>> > > >> (https://github.com/arighi/virtme-ng).
> >> >>> > > >>
> >> >>> > > >> Some people are already using and contributing to virtme-ng and 
> >> >>> > > >> there
> >> >>> > > >> are plans to package it in SuSE.
> >> >>> > > >>
> >> >>> > > >> Honestly I don't know what would be the right procedure to 
> >> >>> > > >> "obsolete"
> >> >>> > > >> the old virtme package and replace it virtme-ng (if possible), 
> >> >>> > > >> but
> >> >>> > > >> ideally it would be nice to do something like this. Any 
> >> >>> > > >> guidance or
> >> >>> > > >> suggestion is welcome.
> >> >>> > > >
> >> >>> > > >
> >> >>> > > > I suggest we evaluate switching upstream from virtme to 
> >> >>> > > > virtme-ng, on the Debian virtme package. I would not mind if you 
> >> >>> > > > want to be added as uploader for the package.
> >> >>> > > >
> >> >>> > > > Ricardo has been working on virtme. What do you think?
> >> >>> > >
> >> >>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme 
> >> >>> > > author.
> >> >>> >
> >> >>> > All good to me as well! I already sent an email to the virtme author
> >> >>> > (Andrew Lutomirski) to inform him that I was forking the project, 
> >> >>> > but I
> >> >>> > didn't get any response.
> >> >>>
> >> >>> That sounds good.
> >> >>>
> >> >>> >
> >> >>> > Maybe I can try to ping him again and see if he's also happy about 
> >> >>> > this
> >> >>> > plan.
> >> >>>
> >> >>> May I suggest that when you ping them, tell them about the plans to
> >> >>> replace virtme with virtme-ng on Debian and put  me on cc?
> >> >>>
> >> >>> Thanks!
> >> >>>
> >> >>>
> >> >>> >
> >> >>> > -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi all

I think I have the first version of virtme-ng.

@Héctor Orón Martínez can you help reviewing and pushing
https://salsa.debian.org/ribalda/virtme-ng ?

Maybe you could also create salsa.debian.org/debian/virtme-ng


Thanks and regards!

On Wed, May 10, 2023 at 5:04 PM Emmanuel Arias  wrote:
>
>
>
>
> On Wed, May 10, 2023 at 11:41 AM Ricardo Ribalda Delgado 
>  wrote:
>>
>> Hi Emmanuel
>>
>>
>> On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
>> >
>> > Upstream respond  without  objection. Is there any volunter  to this 
>> > transition?  If not i would happy to work on it.
>>
>> I can take care of it. I won't probably start until the weekend though
>
>
> Sounds good, thanks!
>
> Cheers,
>>
>>
>> Regards
>>
>> >
>> > Cheers
>> >
>> >
>> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias  
>> > escribió:
>> >>
>> >> Oh, I did not note/check that virtme already exists in Debian.
>> >>
>> >> Anyway, I am interest in the package, so I will follow virtme/virme-ng 
>> >> project :-)
>> >>
>> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
>> >>  escribió:
>> >>>
>> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
>> >>>  wrote:
>> >>> >
>> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado 
>> >>> > wrote:
>> >>> > > Hi
>> >>> > >
>> >>> > >
>> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
>> >>> > >  wrote:
>> >>> > > >
>> >>> > > > Hello,
>> >>> > > >
>> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
>> >>> > > >  escribió:
>> >>> > > >>
>> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez 
>> >>> > > >> wrote:
>> >>> > > >> > Hello,
>> >>> > > >> >
>> >>> > > >> >   virtme already exists in Debian, what would be the benefit of 
>> >>> > > >> > virtme-ng
>> >>> > > >> > over virtme?
>> >>> > > >> >
>> >>> > > >> > https://salsa.debian.org/debian/virtme
>> >>> > > >> >
>> >>> > > >> > Regards
>> >>> > > >>
>> >>> > > >> The original virtme project is not maintained anymore
>> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the 
>> >>> > > >> project
>> >>> > > >> and continue the development / bug fixing in virtme-ng
>> >>> > > >> (https://github.com/arighi/virtme-ng).
>> >>> > > >>
>> >>> > > >> Some people are already using and contributing to virtme-ng and 
>> >>> > > >> there
>> >>> > > >> are plans to package it in SuSE.
>> >>> > > >>
>> >>> > > >> Honestly I don't know what would be the right procedure to 
>> >>> > > >> "obsolete"
>> >>> > > >> the old virtme package and replace it virtme-ng (if possible), but
>> >>> > > >> ideally it would be nice to do something like this. Any guidance 
>> >>> > > >> or
>> >>> > > >> suggestion is welcome.
>> >>> > > >
>> >>> > > >
>> >>> > > > I suggest we evaluate switching upstream from virtme to virtme-ng, 
>> >>> > > > on the Debian virtme package. I would not mind if you want to be 
>> >>> > > > added as uploader for the package.
>> >>> > > >
>> >>> > > > Ricardo has been working on virtme. What do you think?
>> >>> > >
>> >>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme 
>> >>> > > author.
>> >>> >
>> >>> > All good to me as well! I already sent an email to the virtme author
>> >>> > (Andrew Lutomirski) to inform him that I was forking the project, but I
>> >>> > didn't get any response.
>> >>>
>> >>> That sounds good.
>> >>>
>> >>> >
>> >>> > Maybe I can try to ping him again and see if he's also happy about this
>> >>> > plan.
>> >>>
>> >>> May I suggest that when you ping them, tell them about the plans to
>> >>> replace virtme with virtme-ng on Debian and put  me on cc?
>> >>>
>> >>> Thanks!
>> >>>
>> >>>
>> >>> >
>> >>> > -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello Emilio,

On Thu, 11 May 2023 at 11:12, Emilio Pozuelo Monfort  wrote:
>
> On 09/05/2023 09:51, Andrea Righi wrote:
> > On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> >> Hello,
> >>
> >>virtme already exists in Debian, what would be the benefit of virtme-ng
> >> over virtme?
> >>
> >> https://salsa.debian.org/debian/virtme
> >>
> >> Regards
> >
> > The original virtme project is not maintained anymore
> > (https://github.com/amluto/virtme), so we decided to fork the project
> > and continue the development / bug fixing in virtme-ng
> > (https://github.com/arighi/virtme-ng).
>
> If the original project is no longer maintained, I'd suggest to keep the same
> name and move it into a github group, then invite the original author if he 
> ever
> wants to come back. That way there's no need to add new packages with
> transitional packages in every distribution. That's e.g. what happened with
> terminator. Not sure if it's too late to do that in this specific case.

There has been some communication off debian-devel with the upstream
maintainer and that's indeed part of the plan.
Ricardo has volunteered to swap the upstream on virtme to be
virtme-ng, avoiding transitional packages. Since the package is not
part of bookworm (it is sid only ATM), there is no issue.


-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emilio Pozuelo Monfort]

On 09/05/2023 09:51, Andrea Righi wrote:

On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:

Hello,

   virtme already exists in Debian, what would be the benefit of virtme-ng
over virtme?

https://salsa.debian.org/debian/virtme

Regards


The original virtme project is not maintained anymore
(https://github.com/amluto/virtme), so we decided to fork the project
and continue the development / bug fixing in virtme-ng
(https://github.com/arighi/virtme-ng).


If the original project is no longer maintained, I'd suggest to keep the same 
name and move it into a github group, then invite the original author if he ever 
wants to come back. That way there's no need to add new packages with 
transitional packages in every distribution. That's e.g. what happened with 
terminator. Not sure if it's too late to do that in this specific case.


Cheers,
Emilio

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emmanuel Arias]

On Wed, May 10, 2023 at 11:41 AM Ricardo Ribalda Delgado <
rica...@ribalda.com> wrote:

> Hi Emmanuel
>
>
> On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
> >
> > Upstream respond  without  objection. Is there any volunter  to this
> transition?  If not i would happy to work on it.
>
> I can take care of it. I won't probably start until the weekend though
>

Sounds good, thanks!

Cheers,

>
> Regards
>
> >
> > Cheers
> >
> >
> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias 
> escribió:
> >>
> >> Oh, I did not note/check that virtme already exists in Debian.
> >>
> >> Anyway, I am interest in the package, so I will follow virtme/virme-ng
> project :-)
> >>
> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado <
> rica...@ribalda.com> escribió:
> >>>
> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi <
> andrea.ri...@canonical.com> wrote:
> >>> >
> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado
> wrote:
> >>> > > Hi
> >>> > >
> >>> > >
> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> >>> > >  wrote:
> >>> > > >
> >>> > > > Hello,
> >>> > > >
> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi <
> andrea.ri...@canonical.com> escribió:
> >>> > > >>
> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez
> wrote:
> >>> > > >> > Hello,
> >>> > > >> >
> >>> > > >> >   virtme already exists in Debian, what would be the benefit
> of virtme-ng
> >>> > > >> > over virtme?
> >>> > > >> >
> >>> > > >> > https://salsa.debian.org/debian/virtme
> >>> > > >> >
> >>> > > >> > Regards
> >>> > > >>
> >>> > > >> The original virtme project is not maintained anymore
> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the
> project
> >>> > > >> and continue the development / bug fixing in virtme-ng
> >>> > > >> (https://github.com/arighi/virtme-ng).
> >>> > > >>
> >>> > > >> Some people are already using and contributing to virtme-ng and
> there
> >>> > > >> are plans to package it in SuSE.
> >>> > > >>
> >>> > > >> Honestly I don't know what would be the right procedure to
> "obsolete"
> >>> > > >> the old virtme package and replace it virtme-ng (if possible),
> but
> >>> > > >> ideally it would be nice to do something like this. Any
> guidance or
> >>> > > >> suggestion is welcome.
> >>> > > >
> >>> > > >
> >>> > > > I suggest we evaluate switching upstream from virtme to
> virtme-ng, on the Debian virtme package. I would not mind if you want to be
> added as uploader for the package.
> >>> > > >
> >>> > > > Ricardo has been working on virtme. What do you think?
> >>> > >
> >>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme
> author.
> >>> >
> >>> > All good to me as well! I already sent an email to the virtme author
> >>> > (Andrew Lutomirski) to inform him that I was forking the project,
> but I
> >>> > didn't get any response.
> >>>
> >>> That sounds good.
> >>>
> >>> >
> >>> > Maybe I can try to ping him again and see if he's also happy about
> this
> >>> > plan.
> >>>
> >>> May I suggest that when you ping them, tell them about the plans to
> >>> replace virtme with virtme-ng on Debian and put  me on cc?
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> >
> >>> > -Andrea
>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi Emmanuel


On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
>
> Upstream respond  without  objection. Is there any volunter  to this 
> transition?  If not i would happy to work on it.

I can take care of it. I won't probably start until the weekend though

Regards

>
> Cheers
>
>
> El mar, 9 de may de 2023, 07:54, Emmanuel Arias  escribió:
>>
>> Oh, I did not note/check that virtme already exists in Debian.
>>
>> Anyway, I am interest in the package, so I will follow virtme/virme-ng 
>> project :-)
>>
>> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
>>  escribió:
>>>
>>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi  
>>> wrote:
>>> >
>>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
>>> > > Hi
>>> > >
>>> > >
>>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
>>> > >  wrote:
>>> > > >
>>> > > > Hello,
>>> > > >
>>> > > > El mar, 9 may 2023, 9:51, Andrea Righi  
>>> > > > escribió:
>>> > > >>
>>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
>>> > > >> > Hello,
>>> > > >> >
>>> > > >> >   virtme already exists in Debian, what would be the benefit of 
>>> > > >> > virtme-ng
>>> > > >> > over virtme?
>>> > > >> >
>>> > > >> > https://salsa.debian.org/debian/virtme
>>> > > >> >
>>> > > >> > Regards
>>> > > >>
>>> > > >> The original virtme project is not maintained anymore
>>> > > >> (https://github.com/amluto/virtme), so we decided to fork the project
>>> > > >> and continue the development / bug fixing in virtme-ng
>>> > > >> (https://github.com/arighi/virtme-ng).
>>> > > >>
>>> > > >> Some people are already using and contributing to virtme-ng and there
>>> > > >> are plans to package it in SuSE.
>>> > > >>
>>> > > >> Honestly I don't know what would be the right procedure to "obsolete"
>>> > > >> the old virtme package and replace it virtme-ng (if possible), but
>>> > > >> ideally it would be nice to do something like this. Any guidance or
>>> > > >> suggestion is welcome.
>>> > > >
>>> > > >
>>> > > > I suggest we evaluate switching upstream from virtme to virtme-ng, on 
>>> > > > the Debian virtme package. I would not mind if you want to be added 
>>> > > > as uploader for the package.
>>> > > >
>>> > > > Ricardo has been working on virtme. What do you think?
>>> > >
>>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme 
>>> > > author.
>>> >
>>> > All good to me as well! I already sent an email to the virtme author
>>> > (Andrew Lutomirski) to inform him that I was forking the project, but I
>>> > didn't get any response.
>>>
>>> That sounds good.
>>>
>>> >
>>> > Maybe I can try to ping him again and see if he's also happy about this
>>> > plan.
>>>
>>> May I suggest that when you ping them, tell them about the plans to
>>> replace virtme with virtme-ng on Debian and put  me on cc?
>>>
>>> Thanks!
>>>
>>>
>>> >
>>> > -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emmanuel Arias]

Upstream respond  without  objection. Is there any volunter  to this
transition?  If not i would happy to work on it.

Cheers


El mar, 9 de may de 2023, 07:54, Emmanuel Arias 
escribió:

> Oh, I did not note/check that virtme already exists in Debian.
>
> Anyway, I am interest in the package, so I will follow virtme/virme-ng
> project :-)
>
> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado <
> rica...@ribalda.com> escribió:
>
>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
>> wrote:
>> >
>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
>> > > Hi
>> > >
>> > >
>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
>> > >  wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
>> escribió:
>> > > >>
>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez
>> wrote:
>> > > >> > Hello,
>> > > >> >
>> > > >> >   virtme already exists in Debian, what would be the benefit of
>> virtme-ng
>> > > >> > over virtme?
>> > > >> >
>> > > >> > https://salsa.debian.org/debian/virtme
>> > > >> >
>> > > >> > Regards
>> > > >>
>> > > >> The original virtme project is not maintained anymore
>> > > >> (https://github.com/amluto/virtme), so we decided to fork the
>> project
>> > > >> and continue the development / bug fixing in virtme-ng
>> > > >> (https://github.com/arighi/virtme-ng).
>> > > >>
>> > > >> Some people are already using and contributing to virtme-ng and
>> there
>> > > >> are plans to package it in SuSE.
>> > > >>
>> > > >> Honestly I don't know what would be the right procedure to
>> "obsolete"
>> > > >> the old virtme package and replace it virtme-ng (if possible), but
>> > > >> ideally it would be nice to do something like this. Any guidance or
>> > > >> suggestion is welcome.
>> > > >
>> > > >
>> > > > I suggest we evaluate switching upstream from virtme to virtme-ng,
>> on the Debian virtme package. I would not mind if you want to be added as
>> uploader for the package.
>> > > >
>> > > > Ricardo has been working on virtme. What do you think?
>> > >
>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme
>> author.
>> >
>> > All good to me as well! I already sent an email to the virtme author
>> > (Andrew Lutomirski) to inform him that I was forking the project, but I
>> > didn't get any response.
>>
>> That sounds good.
>>
>> >
>> > Maybe I can try to ping him again and see if he's also happy about this
>> > plan.
>>
>> May I suggest that when you ping them, tell them about the plans to
>> replace virtme with virtme-ng on Debian and put  me on cc?
>>
>> Thanks!
>>
>>
>> >
>> > -Andrea
>>
>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

On Tue, May 9, 2023 at 12:46 PM Andrea Righi  wrote:
>
> On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
> > Hi
> >
> >
> > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> >  wrote:
> > >
> > > Hello,
> > >
> > > El mar, 9 may 2023, 9:51, Andrea Righi  
> > > escribió:
> > >>
> > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> > >> > Hello,
> > >> >
> > >> >   virtme already exists in Debian, what would be the benefit of 
> > >> > virtme-ng
> > >> > over virtme?
> > >> >
> > >> > https://salsa.debian.org/debian/virtme
> > >> >
> > >> > Regards
> > >>
> > >> The original virtme project is not maintained anymore
> > >> (https://github.com/amluto/virtme), so we decided to fork the project
> > >> and continue the development / bug fixing in virtme-ng
> > >> (https://github.com/arighi/virtme-ng).
> > >>
> > >> Some people are already using and contributing to virtme-ng and there
> > >> are plans to package it in SuSE.
> > >>
> > >> Honestly I don't know what would be the right procedure to "obsolete"
> > >> the old virtme package and replace it virtme-ng (if possible), but
> > >> ideally it would be nice to do something like this. Any guidance or
> > >> suggestion is welcome.
> > >
> > >
> > > I suggest we evaluate switching upstream from virtme to virtme-ng, on the 
> > > Debian virtme package. I would not mind if you want to be added as 
> > > uploader for the package.
> > >
> > > Ricardo has been working on virtme. What do you think?
> >
> > SGTM. Maybe we can send an email out of courtesy to the old virtme author.
>
> All good to me as well! I already sent an email to the virtme author
> (Andrew Lutomirski) to inform him that I was forking the project, but I
> didn't get any response.

That sounds good.

>
> Maybe I can try to ping him again and see if he's also happy about this
> plan.

May I suggest that when you ping them, tell them about the plans to
replace virtme with virtme-ng on Debian and put  me on cc?

Thanks!


>
> -Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
> Hi
> 
> 
> On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
>  wrote:
> >
> > Hello,
> >
> > El mar, 9 may 2023, 9:51, Andrea Righi  
> > escribió:
> >>
> >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> >> > Hello,
> >> >
> >> >   virtme already exists in Debian, what would be the benefit of virtme-ng
> >> > over virtme?
> >> >
> >> > https://salsa.debian.org/debian/virtme
> >> >
> >> > Regards
> >>
> >> The original virtme project is not maintained anymore
> >> (https://github.com/amluto/virtme), so we decided to fork the project
> >> and continue the development / bug fixing in virtme-ng
> >> (https://github.com/arighi/virtme-ng).
> >>
> >> Some people are already using and contributing to virtme-ng and there
> >> are plans to package it in SuSE.
> >>
> >> Honestly I don't know what would be the right procedure to "obsolete"
> >> the old virtme package and replace it virtme-ng (if possible), but
> >> ideally it would be nice to do something like this. Any guidance or
> >> suggestion is welcome.
> >
> >
> > I suggest we evaluate switching upstream from virtme to virtme-ng, on the 
> > Debian virtme package. I would not mind if you want to be added as uploader 
> > for the package.
> >
> > Ricardo has been working on virtme. What do you think?
> 
> SGTM. Maybe we can send an email out of courtesy to the old virtme author.

All good to me as well! I already sent an email to the virtme author
(Andrew Lutomirski) to inform him that I was forking the project, but I
didn't get any response.

Maybe I can try to ping him again and see if he's also happy about this
plan.

-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emmanuel Arias]

Oh, I did not note/check that virtme already exists in Debian.

Anyway, I am interest in the package, so I will follow virtme/virme-ng
project :-)

El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado <
rica...@ribalda.com> escribió:

> On Tue, May 9, 2023 at 12:46 PM Andrea Righi 
> wrote:
> >
> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
> > > Hi
> > >
> > >
> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > > El mar, 9 may 2023, 9:51, Andrea Righi 
> escribió:
> > > >>
> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez
> wrote:
> > > >> > Hello,
> > > >> >
> > > >> >   virtme already exists in Debian, what would be the benefit of
> virtme-ng
> > > >> > over virtme?
> > > >> >
> > > >> > https://salsa.debian.org/debian/virtme
> > > >> >
> > > >> > Regards
> > > >>
> > > >> The original virtme project is not maintained anymore
> > > >> (https://github.com/amluto/virtme), so we decided to fork the
> project
> > > >> and continue the development / bug fixing in virtme-ng
> > > >> (https://github.com/arighi/virtme-ng).
> > > >>
> > > >> Some people are already using and contributing to virtme-ng and
> there
> > > >> are plans to package it in SuSE.
> > > >>
> > > >> Honestly I don't know what would be the right procedure to
> "obsolete"
> > > >> the old virtme package and replace it virtme-ng (if possible), but
> > > >> ideally it would be nice to do something like this. Any guidance or
> > > >> suggestion is welcome.
> > > >
> > > >
> > > > I suggest we evaluate switching upstream from virtme to virtme-ng,
> on the Debian virtme package. I would not mind if you want to be added as
> uploader for the package.
> > > >
> > > > Ricardo has been working on virtme. What do you think?
> > >
> > > SGTM. Maybe we can send an email out of courtesy to the old virtme
> author.
> >
> > All good to me as well! I already sent an email to the virtme author
> > (Andrew Lutomirski) to inform him that I was forking the project, but I
> > didn't get any response.
>
> That sounds good.
>
> >
> > Maybe I can try to ping him again and see if he's also happy about this
> > plan.
>
> May I suggest that when you ping them, tell them about the plans to
> replace virtme with virtme-ng on Debian and put  me on cc?
>
> Thanks!
>
>
> >
> > -Andrea
>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi


On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
 wrote:
>
> Hello,
>
> El mar, 9 may 2023, 9:51, Andrea Righi  escribió:
>>
>> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
>> > Hello,
>> >
>> >   virtme already exists in Debian, what would be the benefit of virtme-ng
>> > over virtme?
>> >
>> > https://salsa.debian.org/debian/virtme
>> >
>> > Regards
>>
>> The original virtme project is not maintained anymore
>> (https://github.com/amluto/virtme), so we decided to fork the project
>> and continue the development / bug fixing in virtme-ng
>> (https://github.com/arighi/virtme-ng).
>>
>> Some people are already using and contributing to virtme-ng and there
>> are plans to package it in SuSE.
>>
>> Honestly I don't know what would be the right procedure to "obsolete"
>> the old virtme package and replace it virtme-ng (if possible), but
>> ideally it would be nice to do something like this. Any guidance or
>> suggestion is welcome.
>
>
> I suggest we evaluate switching upstream from virtme to virtme-ng, on the 
> Debian virtme package. I would not mind if you want to be added as uploader 
> for the package.
>
> Ricardo has been working on virtme. What do you think?

SGTM. Maybe we can send an email out of courtesy to the old virtme author.

>
> Regards

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Simon McVittie]

On Tue, 09 May 2023 at 10:03:13 +0200, Andrea Righi wrote:
> On Tue, May 09, 2023 at 09:51:42AM +0200, Andrea Righi wrote:
> > The original virtme project is not maintained anymore
> 
> Moreover, it's worth mentioning that virtme-ng doesn't break the
> compatibility with virtme, meaning that all the commands and options
> that were available in virtme are also available in virtme-ng, so users
> can transition to virtme-ng without breaking their workflow.

Given all that, please talk to the Debian maintainer of the virtme package
- they might be interested in helping to maintain virtme-ng instead, and
it sounds like it would be better for our users if virtme-ng was used as a
direct replacement for virtme.

If they're command-line-compatible, then virtme-ng could build an empty
transitional virtme_*.deb binary package that depends on virtme-ng, similar
to how the transition from pkg-config to pkgconf was implemented. That
would result in virtme-ng fully replacing virtme in Debian 13.

smcv

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello,

El mar, 9 may 2023, 9:51, Andrea Righi 
escribió:

> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> > Hello,
> >
> >   virtme already exists in Debian, what would be the benefit of virtme-ng
> > over virtme?
> >
> > https://salsa.debian.org/debian/virtme
> >
> > Regards
>
> The original virtme project is not maintained anymore
> (https://github.com/amluto/virtme), so we decided to fork the project
> and continue the development / bug fixing in virtme-ng
> (https://github.com/arighi/virtme-ng).
>
> Some people are already using and contributing to virtme-ng and there
> are plans to package it in SuSE.
>
> Honestly I don't know what would be the right procedure to "obsolete"
> the old virtme package and replace it virtme-ng (if possible), but
> ideally it would be nice to do something like this. Any guidance or
> suggestion is welcome.
>

I suggest we evaluate switching upstream from virtme to virtme-ng, on the
Debian virtme package. I would not mind if you want to be added as uploader
for the package.

Ricardo has been working on virtme. What do you think?

Regards

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, May 09, 2023 at 09:51:42AM +0200, Andrea Righi wrote:
> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> > Hello,
> > 
> >   virtme already exists in Debian, what would be the benefit of virtme-ng
> > over virtme?
> > 
> > https://salsa.debian.org/debian/virtme
> > 
> > Regards
> 
> The original virtme project is not maintained anymore
> (https://github.com/amluto/virtme), so we decided to fork the project
> and continue the development / bug fixing in virtme-ng
> (https://github.com/arighi/virtme-ng).
> 
> Some people are already using and contributing to virtme-ng and there
> are plans to package it in SuSE.
> 
> Honestly I don't know what would be the right procedure to "obsolete"
> the old virtme package and replace it virtme-ng (if possible), but
> ideally it would be nice to do something like this. Any guidance or
> suggestion is welcome.
> 
> Once we have a package in Debian I can take care of providing a package
> also in Ubuntu.

Moreover, it's worth mentioning that virtme-ng doesn't break the
compatibility with virtme, meaning that all the commands and options
that were available in virtme are also available in virtme-ng, so users
can transition to virtme-ng without breaking their workflow.

-Andrea

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
> Hello,
> 
>   virtme already exists in Debian, what would be the benefit of virtme-ng
> over virtme?
> 
> https://salsa.debian.org/debian/virtme
> 
> Regards

The original virtme project is not maintained anymore
(https://github.com/amluto/virtme), so we decided to fork the project
and continue the development / bug fixing in virtme-ng
(https://github.com/arighi/virtme-ng).

Some people are already using and contributing to virtme-ng and there
are plans to package it in SuSE.

Honestly I don't know what would be the right procedure to "obsolete"
the old virtme package and replace it virtme-ng (if possible), but
ideally it would be nice to do something like this. Any guidance or
suggestion is welcome.

Once we have a package in Debian I can take care of providing a package
also in Ubuntu.

Thanks,
-Andrea

> 
> El lun, 8 may 2023, 17:48, Emmanuel Arias  escribió:
> 
> > Control: retitle -1 ITP: virtme-ng -- Tool to build and run a kernel
> > inside a virtualized snapshot of your live system
> > Control: owner -1 eam...@yaerobi.com
> >
> > Hi,
> >
> > I'm interested to work in this package. I'm going to package it.
> >
> > Thanks!
> >
> > Cheers,
> > eamanu
> >
> >
> >
> > On Sun, May 7, 2023 at 10:39 AM Andrea Righi 
> > wrote:
> >
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Andrea Righi 
> >> X-Debbugs-CC: debian-devel@lists.debian.org
> >> Control: affects -1 ITP
> >>
> >> * Package name: virtme-ng
> >>   Version : 1.2
> >>   Upstream Author : Andrea Righi 
> >> * URL : https://salsa.debian.org/arighi/virtme-ng
> >> * License : GPL-2
> >>   Programming Lang: Python
> >>   Description : Tool to build and run a kernel inside a virtualized
> >> snapshot of your live system
> >>
> >> virtme-ng is a tool that allows to easily and quickly recompile and test
> >> a Linux kernel, starting from the source code.
> >>
> >> It allows to recompile the kernel in few minutes (rather than hours),
> >> then the kernel is automatically started in a virtualized environment
> >> that is an exact copy-on-write copy of your live system, which means
> >> that any changes made to the virtualized environment do not affect the
> >> host system.
> >>
> >> In order to do this a minimal config is produced (with the bare minimum
> >> support to test the kernel inside qemu), then the selected kernel is
> >> automatically built and started inside qemu, using the filesystem of the
> >> host as a copy-on-write snapshot.
> >>
> >> This means that you can safely destroy the entire filesystem, crash the
> >> kernel, etc. without affecting the host.
> >>
> >> Kernels produced with virtme-ng are lacking lots of features, in order
> >> to reduce the build time to the minimum and still provide you a usable
> >> kernel capable of running your tests and experiments.
> >>
> >> virtme-ng is based on virtme, written by Andy Lutomirski
> >> (https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).
> >>
> >>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Héctor Orón Martínez]

Hello,

  virtme already exists in Debian, what would be the benefit of virtme-ng
over virtme?

https://salsa.debian.org/debian/virtme

Regards

El lun, 8 may 2023, 17:48, Emmanuel Arias  escribió:

> Control: retitle -1 ITP: virtme-ng -- Tool to build and run a kernel
> inside a virtualized snapshot of your live system
> Control: owner -1 eam...@yaerobi.com
>
> Hi,
>
> I'm interested to work in this package. I'm going to package it.
>
> Thanks!
>
> Cheers,
> eamanu
>
>
>
> On Sun, May 7, 2023 at 10:39 AM Andrea Righi 
> wrote:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Andrea Righi 
>> X-Debbugs-CC: debian-devel@lists.debian.org
>> Control: affects -1 ITP
>>
>> * Package name: virtme-ng
>>   Version : 1.2
>>   Upstream Author : Andrea Righi 
>> * URL : https://salsa.debian.org/arighi/virtme-ng
>> * License : GPL-2
>>   Programming Lang: Python
>>   Description : Tool to build and run a kernel inside a virtualized
>> snapshot of your live system
>>
>> virtme-ng is a tool that allows to easily and quickly recompile and test
>> a Linux kernel, starting from the source code.
>>
>> It allows to recompile the kernel in few minutes (rather than hours),
>> then the kernel is automatically started in a virtualized environment
>> that is an exact copy-on-write copy of your live system, which means
>> that any changes made to the virtualized environment do not affect the
>> host system.
>>
>> In order to do this a minimal config is produced (with the bare minimum
>> support to test the kernel inside qemu), then the selected kernel is
>> automatically built and started inside qemu, using the filesystem of the
>> host as a copy-on-write snapshot.
>>
>> This means that you can safely destroy the entire filesystem, crash the
>> kernel, etc. without affecting the host.
>>
>> Kernels produced with virtme-ng are lacking lots of features, in order
>> to reduce the build time to the minimum and still provide you a usable
>> kernel capable of running your tests and experiments.
>>
>> virtme-ng is based on virtme, written by Andy Lutomirski
>> (https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).
>>
>>

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emmanuel Arias]

Control: retitle -1 ITP: virtme-ng -- Tool to build and run a kernel inside
a virtualized snapshot of your live system
Control: owner -1 eam...@yaerobi.com

Hi,

I'm interested to work in this package. I'm going to package it.

Thanks!

Cheers,
eamanu



On Sun, May 7, 2023 at 10:39 AM Andrea Righi 
wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Andrea Righi 
> X-Debbugs-CC: debian-devel@lists.debian.org
> Control: affects -1 ITP
>
> * Package name: virtme-ng
>   Version : 1.2
>   Upstream Author : Andrea Righi 
> * URL : https://salsa.debian.org/arighi/virtme-ng
> * License : GPL-2
>   Programming Lang: Python
>   Description : Tool to build and run a kernel inside a virtualized
> snapshot of your live system
>
> virtme-ng is a tool that allows to easily and quickly recompile and test
> a Linux kernel, starting from the source code.
>
> It allows to recompile the kernel in few minutes (rather than hours),
> then the kernel is automatically started in a virtualized environment
> that is an exact copy-on-write copy of your live system, which means
> that any changes made to the virtualized environment do not affect the
> host system.
>
> In order to do this a minimal config is produced (with the bare minimum
> support to test the kernel inside qemu), then the selected kernel is
> automatically built and started inside qemu, using the filesystem of the
> host as a copy-on-write snapshot.
>
> This means that you can safely destroy the entire filesystem, crash the
> kernel, etc. without affecting the host.
>
> Kernels produced with virtme-ng are lacking lots of features, in order
> to reduce the build time to the minimum and still provide you a usable
> kernel capable of running your tests and experiments.
>
> virtme-ng is based on virtme, written by Andy Lutomirski
> (https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).
>
>

RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

Package: wnpp
Severity: wishlist
Owner: Andrea Righi 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: affects -1 ITP

* Package name: virtme-ng
  Version : 1.2
  Upstream Author : Andrea Righi 
* URL : https://salsa.debian.org/arighi/virtme-ng
* License : GPL-2
  Programming Lang: Python
  Description : Tool to build and run a kernel inside a virtualized 
snapshot of your live system

virtme-ng is a tool that allows to easily and quickly recompile and test
a Linux kernel, starting from the source code.

It allows to recompile the kernel in few minutes (rather than hours),
then the kernel is automatically started in a virtualized environment
that is an exact copy-on-write copy of your live system, which means
that any changes made to the virtualized environment do not affect the
host system.

In order to do this a minimal config is produced (with the bare minimum
support to test the kernel inside qemu), then the selected kernel is
automatically built and started inside qemu, using the filesystem of the
host as a copy-on-write snapshot.

This means that you can safely destroy the entire filesystem, crash the
kernel, etc. without affecting the host.

Kernels produced with virtme-ng are lacking lots of features, in order
to reduce the build time to the minimum and still provide you a usable
kernel capable of running your tests and experiments.

virtme-ng is based on virtme, written by Andy Lutomirski
(https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).

Re: RFP: kernelcraft -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

On Thu, Apr 27, 2023 at 05:56:41PM +0200, Andrea Righi wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrea Righi 
> X-Debbugs-CC: debian-devel@lists.debian.org
> Control: affects -1 ITP
> 
> * Package name: kernelcraft
>   Version : 2.0
>   Upstream Author : Andrea Righi 
> * URL : https://salsa.debian.org/arighi/kernelcraft
> * License : GPL-2
>   Programming Lang: Python
>   Description : Tool to build and run a kernel inside a virtualized 
> snapshot of your live system
> 
> KernelCraft is a tool that allows to easily and quickly recompile and
> test a Linux kernel, starting from the source code.
> 
> It allows to recompile the kernel in few minutes (rather than hours),
> then the kernel is automatically started in a virtualized environment
> that is an exact copy-on-write copy of your live system, which means
> that any changes made to the virtualized environment do not affect the
> host system.
> 
> In order to do this a minimal config is produced (with the bare minimum
> support to test the kernel inside qemu), then the selected kernel is
> automatically built and started inside qemu, using the filesystem of the
> host as a copy-on-write snapshot.
> 
> This means that you can safely destroy the entire filesystem, crash the
> kernel, etc. without affecting the host.
> 
> Kernels produced with KernelCraft are lacking lots of features, in order
> to reduce the build time to the minimum and still provide you a usable
> kernel capable of running your tests and experiments.
> 
> KernelCraft is based on virtme, written by Andy Lutomirski
> (https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).

Please ignore this, we are currectly renaming the project to virtme-ng
to avoid a potential naming conflict with another project.

I will send another RFP when the renaming will be completed.

Sorry for the noise,
-Andrea

RFP: kernelcraft -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Andrea Righi]

Package: wnpp
Severity: wishlist
Owner: Andrea Righi 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: affects -1 ITP

* Package name: kernelcraft
  Version : 2.0
  Upstream Author : Andrea Righi 
* URL : https://salsa.debian.org/arighi/kernelcraft
* License : GPL-2
  Programming Lang: Python
  Description : Tool to build and run a kernel inside a virtualized 
snapshot of your live system

KernelCraft is a tool that allows to easily and quickly recompile and
test a Linux kernel, starting from the source code.

It allows to recompile the kernel in few minutes (rather than hours),
then the kernel is automatically started in a virtualized environment
that is an exact copy-on-write copy of your live system, which means
that any changes made to the virtualized environment do not affect the
host system.

In order to do this a minimal config is produced (with the bare minimum
support to test the kernel inside qemu), then the selected kernel is
automatically built and started inside qemu, using the filesystem of the
host as a copy-on-write snapshot.

This means that you can safely destroy the entire filesystem, crash the
kernel, etc. without affecting the host.

Kernels produced with KernelCraft are lacking lots of features, in order
to reduce the build time to the minimum and still provide you a usable
kernel capable of running your tests and experiments.

KernelCraft is based on virtme, written by Andy Lutomirski
(https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git).

Bug#1033934: ITP: puppet-module-voxpupuli-kmod -- Puppet module for manipulating modprobe and kernel modules

[Thomas Goirand]

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

* Package name: puppet-module-voxpupuli-kmod
  Version : 3.2.0
  Upstream Author : Voxpupuli
* URL : https://github.com/voxpupuli/puppet-kmod
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for manipulating modprobe and kernel modules

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages kernel module loading and options.

Processed: reassign bug to kernel

[Debian Bug Tracking System]

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

> reassign 1033149 linux
Bug #1033149 [general] general: debian 11 fails to hibernate when RAM usage 
above 7GB
Bug reassigned from package 'general' to 'linux'.
Ignoring request to alter found versions of bug #1033149 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033149 to the same values 
previously set
>
End of message, stopping processing here.

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

Bug#1026127: ITP: python-comm -- Register a comm implementation in the Jupyter kernel

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org

* Package name: python-comm
  Version : 0.1.2
* URL : https://github.com/ipython/comm
* License : BSD-3-clause
  Programming Lang: Python
  Description : Register a comm implementation in the Jupyter kernel

It provides a way to register a Kernel Comm implementation, as per the Jupyter
kernel protocol. It also provides a base Comm implementation and a default
CommManager that can be used.

This is a new dependency of the ipykernel package and will be maintained
as part of the Python Team.

Re: official Debian kernel-free images

[Patrice Duroux]

Many thanks Étienne and Paul for all the resources.

Regards,
Patrice

Re: official Debian kernel-free images

[Paul Wise]

On Sat, 2022-11-05 at 20:20 +0100, Patrice Duroux wrote:

> There are many projects here and there (Termux, AnLinux, etc.) that are based 
> on
> some sorts of kernel-free images of a minimal Debian system to be used through
> chroot (other Linux) or PRoot (Android) or whatever environments.

Some examples of those linked from this page:

https://wiki.debian.org/ChrootOnAndroid

> Is there something already available at Debian?

Most Debian users are currently expected to create their own installs,
using either the official Debian installer or the tools it is based on
like debootstrap. One of the reasons for this is that packages often do
system-specific configuration in their maintainer scripts (like the
systemd machine identifier or OpenSSH creating private keys), so you
can't always expect an install to be able to be duplicated safely.
There are folks working on reproducible installs though.

https://wiki.debian.org/ReproducibleInstalls

There have been five types of pre-installed systems available from the
Debian community; live images, cloud images, RPi images, minimal docker
containers, and the WSL install. The first three of those are partition
images, but the WSL installer is basically a kernel-free rootfs tarball
wrapped in a PE executable and the docker containers are similarish.
All of these have to work around the issue mentioned above.

https://www.debian.org/CD/live/
https://cloud.debian.org/images/cloud/
https://raspi.debian.net/
https://docker.debian.net/
https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows/SubsystemForLinux

> Something interesting to develop?

There are lots of potential artefacts Debian could create from our
binaries rather than expecting all users to install their systems.

There are lots of different types of installs being explored outside of
Debian, including system snapshots, server containers, app containers,
appliance images, chroots/VMs under other operating systems etc.

Debian could potentially be converting our binary packages to each of
these different types of installs.

Debian users could then be directed by default to the most appropriate
install type for their use-case.

PS: a list of system/package build tools is here:

https://wiki.debian.org/SystemBuildTools

PS: a recent article about some new image based installs:

https://lwn.net/SubscriberLink/912774/b95d0bf96ebb67ab/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: official Debian kernel-free images

[Étienne Mollier]

Hi Patrice,

Patrice Duroux, on 2022-11-05:
> There are many projects here and there (Termux, AnLinux, etc.) that are based 
> on
> some sorts of kernel-free images of a minimal Debian system to be used through
> chroot (other Linux) or PRoot (Android) or whatever environments.
> Most of the time, it is provided as an archive file downloaded at their own
> upstream project through their own (G)UI interface for which the content can 
> be
> more or less similar to what could be an «official» Debian one.
> 
> Is there something already available at Debian?

Maybe I misunderstood, but you sound like you are after
something like:

sudo debootstrap \
/srv/chroot/debian-stable \
stable \
http://deb.debian.org./debian

> Something interesting to develop?

Unsure, there are many alternatives to debootstrap already:
mmdebstrap, cdebootstrap, bdebstrap, to name the few I see with
a loose research with apt.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: A Helmet of Gnats - Cuchifrita's Ballet Lesson


signature.asc
Description: PGP signature

official Debian kernel-free images

[Patrice Duroux]

Hi,

There are many projects here and there (Termux, AnLinux, etc.) that are based on
some sorts of kernel-free images of a minimal Debian system to be used through
chroot (other Linux) or PRoot (Android) or whatever environments.
Most of the time, it is provided as an archive file downloaded at their own
upstream project through their own (G)UI interface for which the content can be
more or less similar to what could be an «official» Debian one.

Is there something already available at Debian?
Something interesting to develop?

Thanks,
Patrice

Bug#1022946: ITP: ltp -- The LTP testsuite contains a collection of tools for testing the Linux kernel and related features

[Vignesh Raman]

Package: wnpp
Severity: wishlist
Owner: Vignesh Raman 
X-Debbugs-Cc: debian-devel@lists.debian.org, vignesh.ra...@collabora.com

Hi,

* Package name: ltp
  Version : 20220527
  Upstream Author : l...@lists.linux.it
* URL : http://linux-test-project.github.io/
* License : GNU General Public License v2.0
  Programming Lang: C, Perl, Python, Shell
  Description : The LTP testsuite contains a collection of tools for 
testing the Linux kernel and related features

The LTP testsuite contains a collection of tools for testing the
linux kernel and related features. It is useful to have LTP package
in debian for testing linux kernel. LTP package was presviously in
debian but removed because it was unmaintained and RC-buggy.
My current plan is to package the latest upstream release (20220527),
and maintain it.

Regards,
Vignesh

Bug#1018891: marked as done (general: Can't install fans on msi laptop due to missing ec_sys kernel. Command prompt modprobe ec_sys write_support=1, I get error: FATAL: Module ec_sys not found in dire

[Debian Bug Tracking System]

Your message dated Tue, 13 Sep 2022 21:33:03 +0200
with message-id 
and subject line Re: Bug#1018891: general: Can't install fans on msi laptop due 
to missing ec_sys kernel. Command prompt modprobe ec_sys write_support=1, I get 
error: FATAL: Module ec_sys not found in directory /lib/modules/5.10.0-17-amd64
has caused the Debian Bug report #1018891,
regarding general: Can't install fans on msi laptop due to missing ec_sys 
kernel. Command prompt modprobe ec_sys write_support=1, I get error: FATAL: 
Module ec_sys not found in directory /lib/modules/5.10.0-17-amd64
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.)


-- 
1018891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018891
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal
X-Debbugs-Cc: velmory...@gmail.com

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 ***
--- End Message ---
--- Begin Message ---
On Thu, 2022-09-01 at 18:43 +0300, Psyho786 wrote:
> Package: general
> Severity: normal
> X-Debbugs-Cc: velmory...@gmail.com
> 
> 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 ***
> 

We intentionally do not enable this debug driver.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#1019459: ITP: gvisor -- Application Kernel for Containers

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: gvisor
  Version : 20220905.0-1
  Upstream Author : Google
* URL : https://github.com/google/gvisor
* License : Apache-2.0 and MIT
  Programming Lang: Go
  Description : Application Kernel for Containers

 gVisor is an
 application kernel, written in Go, that implements a substantial portion
 of the Linux system surface.  This package includes the subset of gVisor
 necessary for applications that use its TCP/IP stack, which was formerly
 split out into inet.af/netstack.

inet.af/netstack is deprecated thanks to the new support in Go for partial
module compilation.  NNCP now uses gVisor.

Bug#1018891: general: Can't install fans on msi laptop due to missing ec_sys kernel. Command prompt modprobe ec_sys write_support=1, I get error: FATAL: Module ec_sys not found in directory /lib/modul

[Psyho786]

Package: general
Severity: normal
X-Debbugs-Cc: velmory...@gmail.com

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 ***

Bug#1016019: ITP: libusbgx -- libusbgx is a C library encapsulating the kernel USB gadget-configfs

[Manuel Traut]

Package: wnpp
Severity: wishlist
Owner: Manuel Traut 
X-Debbugs-Cc: debian-devel@lists.debian.org, manuel.tr...@mt.com

* Package name: libusbgx
  Version : 0.2.0
  Upstream Author : Krzysztof Opasiak 
* URL : https://github.com/linux-usb-gadgets/libusbgx
* License : GPL, LGPL
  Programming Lang: C
  Description : libusbgx is a C library encapsulating the kernel USB 
gadget-configfs

It provides routines for creating and parsing USB gadget devices using
the configfs API. Currently, all USB gadget configfs functions that can
be enabled in kernel release 3.11 (Linux for Workgroups!) are supported.

The package is used in many embedded Linux based products.

I would need a sponsor and help for uploading the package.

Bug#1013110: ITP: rapiddisk -- Linux RAM Drive and Caching kernel modules (DKMS)

[Gürkan Myczko]

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

* Package name: rapiddisk
  Version : 8.1.0
  Upstream Authors: Petros Koutoupis 
  URL : https://github.com/pkoutoupis/rapiddisk
* License : GPL-2.0-or-later
  Description : Linux RAM Drive and Caching kernel modules (DKMS)
 This software defined advanced RAM drive and storage
 caching solution. This suite includes a collection of modules,
 configuration files, and command line utilities for managing
 RapidDisk enabled storage volumes and accessing them either
 locally or across an NVMe Target network.
 .
 This is the kernel module for Linux.

Bug#1010829: ITP: libkdumpfile -- Kernel coredump file access

[Michel Alexandre Salim]

Package: wnpp
Severity: wishlist
Owner: Michel Alexandre Salim 
X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name

* Package name: libkdumpfile
  Version : 0.4.1
  Upstream Author : Petr Tesarik 
* URL : https://github.com/ptesarik/libkdumpfile
* License : LGPL-3+ or GPL-2+
  Programming Lang: C
  Description : Kernel coredump file access

libkdumpfile is a library to read kdump-compressed kernel core dumps.

It is an optional dependency for packaging drgn (ITP: #1001581). I work
with the drgn author, we already maintain libkdumpfile and drgn in
Fedora and would like to make sure they are available in Debian as well.

Bug#1008044: ITP: openvpn-dco-dkms -- DCO (Data-Channel Offload) kernel module for OpenVPN

[Bernhard Schmidt]

Package: wnpp
Severity: wishlist
Owner: Bernhard Schmidt 

* Package name: openvpn-dco-dkms
  Version : Git Snapshot
  Upstream Author : Antonio Quartulli 
* URL : https://github.com/OpenVPN/ovpn-dco
* License : GPL-2.0
  Programming Lang: C
  Description : DCO (Data-Channel Offload) kernel module for OpenVPN

OpenVPN Data Channel Offload in the linux kernel (ovpn-dco)
.
This kernel module allows OpenVPN to offload any data plane management to the
linux kernel, thus allowing it to exploit any Linux low level API, while
avoiding expensive and slow payload transfer between kernel space and user
space. You need a matching dco-enabled OpenVPN to use this, the feature is
supposed to land in OpenVPN 2.6.
.
This package uses DKMS to automatically build the ovpn-dco kernel module.

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

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

* Package name: kmscon
  Version : 8+40
  Upstream Author : Aetf 
* URL : https://github.com/Aetf/kmscon
* License : Expat
  Programming Lang: C
  Description : Simple terminal emulator based on Kernel Mode Setting

kmscon is a system console for linux. It does not depend on any
graphics-server on your system (like X.org), but instead provides
a raw console layer that can  be used independently.
It can replace the linux kernel console entirely but was designed to
work well side-by-side, too.
Even though initially targeted at providing internationalization to
the system-console, it has grown into a fully modularized console
layer including features like multi-head support, internationalized
font rendering, XKB-compatible keyboard handling,
hardware-accelerated graphics access and more.

I have used this package since Linux dropped scrollback support
from the kernel in 2020 [1]. The original upstream [2] has been
dead since 2014, but Aetf has picked up development.

Kmscon depends on a newer, forked version of libtsm. I'll file
a separate bug to address that.

[1]: 
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Drops-Soft-Scrollback
[2]: https://www.freedesktop.org/wiki/Software/kmscon/

Bug#1001228: ITP: jupyter-kernel-test -- tool to test Jupyter kernels

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
j...@nahmias.net

* Package name: jupyter-kernel-test
  Version : 0.4.2
  Upstream Author : Jupyter Development Team 
* URL : https://github.com/jupyter/jupyter_kernel_test
* License : BSD
  Programming Lang: Python
  Description : tool to test Jupyter kernels

jupyter_kernel_test is a tool for testing Jupyter kernels. It tests kernels
for successful code execution and conformance with the Jupyter Messaging
Protocol (currently 5.0).

Re: Kernel building question (Is -j8 safe and correct?)

[Ben Hutchings]

On Sun, 2021-06-13 at 15:07 +0200, Philipp Hahn wrote:
[...]
> > 3. If both of the above are true, why isn't something like that suggested 
> > on [1]?
> 
> Debian does not know your specifics and thus does not use parallel build 
> by default.
> 

Debian *does* use parallel builds by default.  But that default
behaviour is implemented in dpkg-buildpackage, so doesn't apply in this
case.

>  You must give permissions first:
> 
>  > export DEB_BUILD_OPTIONS="parallel=$(nproc)"
> 
> See 
> .
> 

That has no effect in this case.  The makefile being used is
debian/rules.gen, not debian/rules.


Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


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

Re: Kernel building question (Is -j8 safe and correct?)

[Ben Hutchings]

On Fri, 2021-06-11 at 19:34 -0600, Antonio Russo wrote:
> Hello,
> 
> I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
> irrelevant).
> I'm following [1], and the critical command
> 
> $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real
> 
> does not suggest using -j8 (or -jnumber_of_cores).
> 
> 1. Is it safe to add -j8 ?

Yes.

> 2. Will this indeed give me the speed up I want and expect on my multi-core 
> processor?

Yes.

> 3. If both of the above are true, why isn't something like that suggested on 
> [1]?

Because no-one thought to add them yet.

Please report this as a bug in the "kernel-handbook" package (which is
the source for this web site).  If you can provide a patch, that would
be even better.

Ben.

> Best,
> Antonio
> 
> [1] 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> 

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


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

Re: Unique kernel with my own backup of all Debian repositories

[Jonathan Dowland]

On Mon, Jun 14, 2021 at 12:36:30PM -0400, Polyna-Maude Racicot-Summerside wrote:
> I only repeated in a different way what was already explained (fair use
> for servers not meant to be sucked up).

My point was not about the technical content of your message, but the
phrasing, that had started to assume an authoritative voice, which could
be misleading.

It's clear you want to get more involved in Debian, and that's great:
have you read ? That lays out the
best ways to get started.


-- 
👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Unique kernel with my own backup of all Debian repositories

[Polyna-Maude Racicot-Summerside]

On 2021-06-14 12:55 p.m., Marc Haber wrote:
> On Mon, 14 Jun 2021 07:23:45 -0700, John E Petersen
>  wrote:
>> Thanks Paul, but I'm having a hard time finding the precise version I would
>> like to archive on any ftp mirror. My scrape is actually working quite
>> correctly now, though, since I added a sleep in there -- the source and
>> machine-installation instructions are tidily tucked away in different
>> directories, with names, locations, and success/failure logged into a
>> key-value (more of a dictionary-ish, really) text file. I get that an ftp
>> request is more civilized, but this scrape is quite convenient for me. If
>> it is more palatable to the community, I can increase the sleep time in the
>> loop to a couple of minutes or even a few or more, and throw it on one of
>> my raspberry pis and forget about it for a while, since I'm not in a major
>> hurry.
> 
> rsync is incomprehensible rocket science?
> 

When you expect to build a "new" Debian kernel (Hurd ? FreeBSD ?)
because there's too much government agent involved in Debian, that you
complain there's a security hole in Ubuntu (but we are in Debian here)
because your hosting provider's web panel doesn't allow you to connect
without first passing in a SSH key... Then let me say, that pretty much
all of your life is... rocket science ! And you failed much of it.

I still can't understand why would it be easier to build a custom system
to scrape a website than to use either :
apt-mirror / debmirror / aptly
OR
rsync -avH rsync.debian.org/debian/... ./mylocalrepo
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unique kernel with my own backup of all Debian repositories

[Marc Haber]

On Mon, 14 Jun 2021 07:23:45 -0700, John E Petersen
 wrote:
>Thanks Paul, but I'm having a hard time finding the precise version I would
>like to archive on any ftp mirror. My scrape is actually working quite
>correctly now, though, since I added a sleep in there -- the source and
>machine-installation instructions are tidily tucked away in different
>directories, with names, locations, and success/failure logged into a
>key-value (more of a dictionary-ish, really) text file. I get that an ftp
>request is more civilized, but this scrape is quite convenient for me. If
>it is more palatable to the community, I can increase the sleep time in the
>loop to a couple of minutes or even a few or more, and throw it on one of
>my raspberry pis and forget about it for a while, since I'm not in a major
>hurry.

rsync is incomprehensible rocket science?

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Unique kernel with my own backup of all Debian repositories

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-14 8:13 a.m., Jonathan Dowland wrote:
> On Sat, Jun 12, 2021 at 04:47:26PM -0400, Polyna-Maude Racicot-Summerside 
> wrote:
>> This is why your address is being blocked and will continue to do so.
> 
> Writing something like this runs the risk of giving the impression that
> you are somehow involved in, or authoritative for, the official Debian
> mirrors. To avoid any doubt, it would be best in future to state clearly
> that you don't, and aren't; in fact it would be best to be clear that
> you aren't involved in developing Debian at all (unless that changes).
> 

I only repeated in a different way what was already explained (fair use
for servers not meant to be sucked up).

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unique kernel with my own backup of all Debian repositories

[John E Petersen]

Thanks Paul, but I'm having a hard time finding the precise version I would
like to archive on any ftp mirror. My scrape is actually working quite
correctly now, though, since I added a sleep in there -- the source and
machine-installation instructions are tidily tucked away in different
directories, with names, locations, and success/failure logged into a
key-value (more of a dictionary-ish, really) text file. I get that an ftp
request is more civilized, but this scrape is quite convenient for me. If
it is more palatable to the community, I can increase the sleep time in the
loop to a couple of minutes or even a few or more, and throw it on one of
my raspberry pis and forget about it for a while, since I'm not in a major
hurry.

Have a great Monday folks,
John

On Sat, Jun 12, 2021 at 5:19 PM Paul Wise  wrote:

> On Sat, Jun 12, 2021 at 8:15 PM John E Petersen wrote:
>
> > If I find it is possible to simply download the entire collection,
> without having to host a mirror, I may very well go that route.
>
> That is definitely possible, there are two sides to every Debian
> mirror: 1) downloading Debian 2) making the files available on the
> web. The second part is definitely optional and many Debian folks do
> just the first part in order to serve their personal machines with
> Debian packages.
>
> > If I continue the scraping route, would adding wait time in my loop
> between downloads make my repeated access less of a problem? I would like
> to let it run until it is finished. It is tedious to restart my scrape
> periodically.
>
> Please use the ftpmirror method recommended by Étienne, it is more
> likely to produce a correct result than scraping and much less likely
> to get blocked. The Debian archive is only updated every six hours, so
> it would be a waste of bandwidth to update more often than that.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: Unique kernel with my own backup of all Debian repositories

[Jonathan Dowland]

On Sat, Jun 12, 2021 at 04:47:26PM -0400, Polyna-Maude Racicot-Summerside wrote:
> This is why your address is being blocked and will continue to do so.

Writing something like this runs the risk of giving the impression that
you are somehow involved in, or authoritative for, the official Debian
mirrors. To avoid any doubt, it would be best in future to state clearly
that you don't, and aren't; in fact it would be best to be clear that
you aren't involved in developing Debian at all (unless that changes).

-- 
👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Kernel building question (Is -j8 safe and correct?)

[Philipp Hahn]

Hello Anionio,

Am 12.06.21 um 03:34 schrieb Antonio Russo:

I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
irrelevant).
I'm following [1], and the critical command

$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real

does not suggest using -j8 (or -jnumber_of_cores).

1. Is it safe to add -j8 ?


That depends on many factors, most importantly how many CPU cores your 
build host has and how many of them you want to use:
- if this is a single-user system and you're the only user and you don't 
want to do much in parallel: yes
- using all CPU cores on a multi-user system might get you complaints 
from the other users.
- watching videos while waiting for the compile to finish might be 
problematic.



2. Will this indeed give me the speed up I want and expect on my multi-core 
processor?


Probably yes, but see above. It also depends on how much RAM you have 
and how fast your disk/SSD is.



3. If both of the above are true, why isn't something like that suggested on 
[1]?


Debian does not know your specifics and thus does not use parallel build 
by default. You must give permissions first:


> export DEB_BUILD_OPTIONS="parallel=$(nproc)"

See 
<https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules>.


For example the VMs and hosts of Debians build system are dedicated to 
building packages. They are controlled by the Debian admins and parallel 
building is enabled there by default - if applicable.
If you have to build many packages it might be more effective to build 
multiple source packages in parallel, as there are still packages which 
can only use one CPU. Mixing both strategies is also an option, but 
heavily depends on your usage scenario.


Philipp

Re: Unique kernel with my own backup of all Debian repositories

[Marc Haber]

On Sat, 12 Jun 2021 12:58:46 -0700, John E Petersen
 wrote:
>If I find it is possible to simply download
>the entire collection, without having to host a mirror, I may very well go
>that route.

The question is, why are you trying to do so?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Unique kernel with my own backup of all Debian repositories

[Marc Haber]

On Sat, 12 Jun 2021 12:52:32 -0700, John E Petersen
 wrote:
>Dear *Polyna-Maude R.-Summerside, *I would appreciate it if you would stay
>out of conversations which you do not understand. Your rude response was
>not well-received. Are you suggesting there are no government employees in
>the open source community? Such an assertion is naive at best.

I only see one person being rude. It's a Mr "Peterson".

Greetings
Marc

-- 
"Manche Leute hier benehmen sich wie Funktio-  | Marc Haber
näre der Maurer-Innung auf einer Fertighaus-  | Mailadresse im Header
Ausstellung." Anselm Lingnau in   | 
de.comp.os.unix.linux.misc, 1999-05-31| No courtesy copies, please!

Bug#989784: ITP: macaulay2-jupyter-kernel -- Jupyter kernel for Macaulay2

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-devel@lists.debian.org, dtorra...@piedmont.edu

* Package name: macaulay2-jupyter-kernel
  Version : 0.6.7~beta
  Upstream Author : Radoslav Zlatev
* URL : https://github.com/rz839/Macaulay2-Jupyter-Kernel
* License : MIT
  Programming Lang: Python
  Description : Jupyter kernel for Macaulay2

Macaulay 2 is a software system for algebraic geometry research, written by
Daniel R. Grayson and Michael E. Stillman.  Based on Groebner bases, it
provides algorithms for computing homological invariants of rings and
modules.

This package contains the Jupyter kernel for Macaulay2.

I intend to maintain this package as a member of the Debian Science Team.

Re: Unique kernel with my own backup of all Debian repositories

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-12 8:19 p.m., Paul Wise wrote:
> On Sat, Jun 12, 2021 at 8:15 PM John E Petersen wrote:
> 
>> If I find it is possible to simply download the entire collection, without 
>> having to host a mirror, I may very well go that route.
> 
> That is definitely possible, there are two sides to every Debian
> mirror: 1) downloading Debian 2) making the files available on the
> web. The second part is definitely optional and many Debian folks do
> just the first part in order to serve their personal machines with
> Debian packages.
> 
>> If I continue the scraping route, would adding wait time in my loop between 
>> downloads make my repeated access less of a problem? I would like to let it 
>> run until it is finished. It is tedious to restart my scrape periodically.
> 
> Please use the ftpmirror method recommended by Étienne, it is more
> likely to produce a correct result than scraping and much less likely
> to get blocked. The Debian archive is only updated every six hours, so
> it would be a waste of bandwidth to update more often than that.
> 
I think you got this one on the wrong side...

This guy is trying to copy all the source code repository as he seem to
have explained.

Well it's not really easy to understand what he's trying to do but he
seem to have the idea to build a Debian derived distribution "that has
the government and other controlled-entity removed" (?).

Kind of awkward to build a Debian derivative because you ain't happy
with the web panel that Digital Ocean offers you to manage Ubuntu and
feel Ubuntu too opinionated.

Maybe shall try a plain Debian first !

Was saying there's a security hole because you can't send your private
key to a server without first doing some manipulation in a web browser.

1st : I don't send my private key, I send the public one. And using scp
work pretty good.

2nd : There's no web interface for key management that is mandatory with
Debian (but there's some software usable as web interface for management).

3rd : His plan are to build a "kernel" but as I asked him why replace
the Linux kernel, and even more, how many person do you have for such a
huge work.

We already gave him hints on using debmirror / ftpmirror / apt-mirror /
aptly...



-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unique kernel with my own backup of all Debian repositories

[Paul Wise]

On Sat, Jun 12, 2021 at 8:15 PM John E Petersen wrote:

> If I find it is possible to simply download the entire collection, without 
> having to host a mirror, I may very well go that route.

That is definitely possible, there are two sides to every Debian
mirror: 1) downloading Debian 2) making the files available on the
web. The second part is definitely optional and many Debian folks do
just the first part in order to serve their personal machines with
Debian packages.

> If I continue the scraping route, would adding wait time in my loop between 
> downloads make my repeated access less of a problem? I would like to let it 
> run until it is finished. It is tedious to restart my scrape periodically.

Please use the ftpmirror method recommended by Étienne, it is more
likely to produce a correct result than scraping and much less likely
to get blocked. The Debian archive is only updated every six hours, so
it would be a waste of bandwidth to update more often than that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Unique kernel with my own backup of all Debian repositories

[Daniel Leidert]

Am Samstag, dem 12.06.2021 um 12:58 -0700 schrieb John E Petersen:

> Maybe I misunderstand the concept of a mirror, but I do not wish to maintain
> a server which allows the public to download Debian repositories.

You don't have to allow anybody having access to your mirror. You seem to
misunderstand.

> I'll look into it, in any case. If I find it is possible to simply download
> the entire collection, without having to host a mirror, I may very well go
> that route. 

That is exacty what you can achieve: create a local mirror for yourself and
keep that in sync with the Debian mirrors. There are several tools to do this
(debmirror, aptly, apt-mirror, reprepro, ...). Just know that mirroring the
Debian repositories needs a lot of disk space.

> If I continue the scraping route, would adding wait time in my loop between
> downloads make my repeated access less of a problem? I would like to let it
> run until it is finished. It is tedious to restart my scrape periodically.

What exactly are you doing to get blocked?


Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Re: Unique kernel with my own backup of all Debian repositories

[Polyna-Maude Racicot-Summerside]

There's a thing in the world called reasonable use.
If you scrape a whole bunch of repository in a short time, this will put
a heavy load on server not meant to be used this way.

This is why your address is being blocked and will continue to do so.
As already written by other people too, there's no such authority that
could change this for you. So you'll have to find a way to lower the
resources used for your actions.

One way to do so is put a delay in between the requests, like already
suggested.

I'd give you a hint of using the debmirror software (or aptly /
apt-mirror) as this is meant to create a local copy of the Debian
packages repository, you can add options for getting source code too.

Maybe you shall learn how to copy a public key using scp and entering a
password. (because you keep the private one on your own computer, but
you seem to do it the other way around).

Don't confuse between Ubuntu itself and the interface offered by Digital
Ocean, two different thing. They only offer a control panel, accessible
from the web without any link to Ubuntu (or Debian or whatever).

If you don't believe what I say, then install a Ubuntu box on your local
network and copy a key directly to it. And be assured, it will work
using scp. First time you'll need to enter the password and after the
key is added to authorized_keys then it will be okay.

Not please, save us from those delusion style affirmation such as


> server on Digital Ocean, for example, using Ubuntu 18.04. Unless they
> are just picking on me in particular, you will find some changes in

You are far from being so much of importance, please get back to earth
if you want some help.

And use the proper words for what you mean.

If I say, I want to write a new kernel based on Debian then it means I
want to replace the "Linux kernel". There's no other kernel, unless you
talk about the FreeBSD based version of Debian or the Mach version of
Debian, both who use a different Kernel than the Linux one.

The basis for communication is a common language or the desire to use a
recognized and standard protocol for communication. If I use word
because they seem great but are out of their meaning, then it's
pointless to communicate.

Hope you get this one now.

On 2021-06-12 3:52 p.m., John E Petersen wrote:
> Dear *Polyna-Maude R.-Summerside, *I would appreciate it if you would
> stay out of conversations which you do not understand. Your rude
> response was not well-received. Are you suggesting there are no
> government employees in the open source community? Such an assertion is
> naive at best.
> 
> The green light I'm requesting is to keep my ip addresses from being
> blocked as I scrape the Debian repositories. Please work on your reading
> comprehension skills. I am requesting permission from the community as a
> whole, which is why I am using a mailing list which addresses the
> developers of said community.
> 
> Existing servers should be fine. However, I invite you to create a new
> server on Digital Ocean, for example, using Ubuntu 18.04. Unless they
> are just picking on me in particular, you will find some changes in
> protocol, such as the inability to upload a private key within a bash
> shell without first making configurations in a web browser. This is a
> new security hole, in case you were not aware.
> 
> Again, work on your reading comprehension skills. I said I am developing
> a unique kernel, based on Debian Linux... I said nothing about writing
> an entire Linux kernel from scratch... Furthermore, I never said
> anything about copying code... Plus, I said credit would be given where
> it was due, if I even ever decided to distribute it.
> 
> It is really a simple task to modify and personalize a kernel. Perhaps
> you should try before you criticize someone you have never met before.
> Additionally, you have zero knowledge of my relationship with any
> government, so do not assume you know anything about me, besides what I
> just told you, which you clearly are not a skilled enough reader to
> comprehend.
> 
> Finally, there was only one question mark in the entire email. Let me
> paraphrase, because your reading comprehension skills are lacking: *why
> is my ip address getting blocked repeatedly as I scrape open source, and
> may I have permission to scrape appropriately without being blocked?*
> I'm asking permission from the community as a whole, which is why I am
> asking the developer mailing list as a whole. If you do not know the
> answer to my question, what was the purpose of your ridiculous retorts?
> 
> On Sat, Jun 12, 2021 at 9:52 AM Polyna-Maude Racicot-Summerside
> mailto:deb...@polynamaude.com>> wrote:
> 
> Hi,
> 
> On 2021-06-12 12:21 p.m., John E Petersen wrote:
> > Hey folks, I’m deve

Re: Unique kernel with my own backup of all Debian repositories

[John E Petersen]

Dear Étienne Mollier,

Aha, a logical response. Thank you for shedding some light on this for me.
That is probably the case. My access could perhaps be misinterpreted as an
attack. Maybe I misunderstand the concept of a mirror, but I do not wish to
maintain a server which allows the public to download Debian repositories.
I'll look into it, in any case. If I find it is possible to simply download
the entire collection, without having to host a mirror, I may very well go
that route.

If I continue the scraping route, would adding wait time in my loop between
downloads make my repeated access less of a problem? I would like to let it
run until it is finished. It is tedious to restart my scrape periodically.

Thanks,
John

On Sat, Jun 12, 2021 at 10:35 AM Étienne Mollier 
wrote:

> Hi John,
>
> John E Petersen, on 2021-06-12:
> > Hey folks, I’m developing a unique kernel based on Debian Linux, and I’ve
> > been scraping the website for repositories. After a few thousand, the
> > servers start to block my ip.
>
> I'm not too sure what you are trying to achieve.  It sounds to
> me like you wish to either develop a Debian derivative, or make
> a backup copy of Debian.  The IP blocking you see is probably
> automated, and the result of your having done repeated access on
> a system that might not have been sized to be mirrored directly.
> I would suppose this is in place, so regular users can access to
> these ressources without being impacted by numerous background
> download tasks hammering the websites.
>
> Please have a look at the mirroring page[1] to assess whether
> you want to mirror the packages archive, and if so, how to do it
> with tools tailored for such task.
>
> [1]: https://www.debian.org/mirror/ftpmirror
>
> In hope this helps!
> --
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
>

Re: Unique kernel with my own backup of all Debian repositories

[John E Petersen]

Dear *Polyna-Maude R.-Summerside, *I would appreciate it if you would stay
out of conversations which you do not understand. Your rude response was
not well-received. Are you suggesting there are no government employees in
the open source community? Such an assertion is naive at best.

The green light I'm requesting is to keep my ip addresses from being
blocked as I scrape the Debian repositories. Please work on your reading
comprehension skills. I am requesting permission from the community as a
whole, which is why I am using a mailing list which addresses the
developers of said community.

Existing servers should be fine. However, I invite you to create a new
server on Digital Ocean, for example, using Ubuntu 18.04. Unless they are
just picking on me in particular, you will find some changes in protocol,
such as the inability to upload a private key within a bash shell without
first making configurations in a web browser. This is a new security hole,
in case you were not aware.

Again, work on your reading comprehension skills. I said I am developing a
unique kernel, based on Debian Linux... I said nothing about writing an
entire Linux kernel from scratch... Furthermore, I never said anything
about copying code... Plus, I said credit would be given where it was due,
if I even ever decided to distribute it.

It is really a simple task to modify and personalize a kernel. Perhaps you
should try before you criticize someone you have never met before.
Additionally, you have zero knowledge of my relationship with any
government, so do not assume you know anything about me, besides what I
just told you, which you clearly are not a skilled enough reader to
comprehend.

Finally, there was only one question mark in the entire email. Let me
paraphrase, because your reading comprehension skills are lacking: *why is
my ip address getting blocked repeatedly as I scrape open source, and may I
have permission to scrape appropriately without being blocked?* I'm asking
permission from the community as a whole, which is why I am asking the
developer mailing list as a whole. If you do not know the answer to my
question, what was the purpose of your ridiculous retorts?

On Sat, Jun 12, 2021 at 9:52 AM Polyna-Maude Racicot-Summerside <
deb...@polynamaude.com> wrote:

> Hi,
>
> On 2021-06-12 12:21 p.m., John E Petersen wrote:
> > Hey folks, I’m developing a unique kernel based on Debian Linux, and
> > I’ve been scraping the website for repositories. After a few thousand,
> > the servers start to block my ip.
> >
> > I’m just trying to keep the crazy government out of Linux, because they
> > keep monkeying with repositories on Ubuntu, not to mention
> > snap/snapd/brltty/systemd…
>
> Did you smoke something that wasn't meant to end up in your lungs ? Have
> you ingested some mushrooms ?
>
> What you write here is a total screw-up non-sense !
>
> 1st : There's no "government" in Linux. It's a community driven project,
> like Debian.
>
> 2nd : You talk about Ubuntu repository, sorry, beep, bong, whatever,
> wake-up call, this is Debian, no Ubuntu repository here.
>
> 3rd : What's the link between Snap/SnapD/Brltyy and SystemD ?
>
> Plus, they’ve totally screwed up Digital
> > Ocean and more or less OVH, so I need a unique kernel (and physical
> > servers) to host my wholesome websites. Not to rant, but it has really
> > gotten ridiculous.
>
> And now, you put on some specific entities to have screwed Digital Ocean
> and OVH (two different company). Sorry dude ! I'm running many OVH rack
> and none of them have any problem running Debian Buster or Bullseye,
> straight out of the box.
>
>
> >
> > I’m not doing anything malicious, and the repositories seem to have
> > extremely flexible licensing, so what’s the problem? If I ever wind up
> > distributing such a kernel which allows access to my copies of the
> > repositories, I would give credit where it’s due, of course.
> >
>
> So you woke up and decided on your own, you're gonna write a brand new
> kernel, fully compatible with the Linux kernel ? All by yourself ?
>
> Watch what you are doing, because it would be a bad thing to copy the
> code of others while doing so !
>
> > If you guys would give me the green light, I’d appreciate it. I’m not
> > saying I would ever distribute such a thing, but I’m not ruling out the
> > possibility either. I’m not looking to mirror, just to be clear.
> >
>
> What "green light" are you expecting here ? Everyone talk for their own
> self. I think you are missing a really important part here...
>
> There's no "central" entity that will give you a "go a head" on the name
> of others. It's not like working for IBM where you employer hold the
> copyright of your works.
> > Salud de Mexico,
> > John (Tarbal)
>
> --
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development
>
>

Re: Unique kernel with my own backup of all Debian repositories

[Étienne Mollier]

Hi John,

John E Petersen, on 2021-06-12:
> Hey folks, I’m developing a unique kernel based on Debian Linux, and I’ve
> been scraping the website for repositories. After a few thousand, the
> servers start to block my ip.

I'm not too sure what you are trying to achieve.  It sounds to
me like you wish to either develop a Debian derivative, or make
a backup copy of Debian.  The IP blocking you see is probably
automated, and the result of your having done repeated access on
a system that might not have been sized to be mirrored directly.
I would suppose this is in place, so regular users can access to
these ressources without being impacted by numerous background
download tasks hammering the websites.

Please have a look at the mirroring page[1] to assess whether
you want to mirror the packages archive, and if so, how to do it
with tools tailored for such task.

[1]: https://www.debian.org/mirror/ftpmirror

In hope this helps!
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: Unique kernel with my own backup of all Debian repositories

[The Wanderer]

On 2021-06-12 at 12:52, Polyna-Maude Racicot-Summerside wrote:

> Hi,
> 
> On 2021-06-12 12:21 p.m., John E Petersen wrote:
> 
>> Hey folks, I’m developing a unique kernel based on Debian Linux,
>> and I’ve been scraping the website for repositories. After a few
>> thousand, the servers start to block my ip.
>> 
>> I’m just trying to keep the crazy government out of Linux, because
>> they keep monkeying with repositories on Ubuntu, not to mention
>> snap/snapd/brltty/systemd…
> 
> Did you smoke something that wasn't meant to end up in your lungs ?
> Have you ingested some mushrooms ?
> 
> What you write here is a total screw-up non-sense !

I think it's mostly just a matter of mistaken terminology. There may
well be faulty assumptions underlying parts of it (certainly there are
things which it seems to be assuming are true that I would probably
disagree about), but not nearly as much as you seem to be parsing.

I interpreted the original mail as asking a question roughly along the
lines of:


"I'm trying to create my own Linux distribution, based on Debian,
because I think a lot of the things that have been happening in
Debian-derived distributions such as Ubuntu lately are the result of
insane government action.

However, in the course of trying to pull all existing Debian packages et
cetera to create a local repository to use as the base of this distro, I
can only download a few thousand items; after that, the server starts
blocking my IP address, even though I'm not doing anything malicious.

Why is this happening, and how can I get an appropriate replica of the
appropriate repositories / et cetera, to use as the basis of such a
derived distribution?"


Except mistakenly using the term "kernel" instead of "distribution", and
with more detail (albeit still vague and FUD-ish) about specific things
which are interpreted as evidence of government-insanity meddling.

Just at a glance, I'd guess that the problem is that the downloads are
hammering the servers, and they're blocking the downloading IP address
as an anti-DoS measure. I had a similar issue at one point for rather
different reasons, and if memory serves, I avoided the issue by just
adding a (possibly-semi-random) delay period - of only a few seconds -
after the download of each consecutive file.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Unique kernel with my own backup of all Debian repositories

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-12 12:21 p.m., John E Petersen wrote:
> Hey folks, I’m developing a unique kernel based on Debian Linux, and
> I’ve been scraping the website for repositories. After a few thousand,
> the servers start to block my ip. 
> 
> I’m just trying to keep the crazy government out of Linux, because they
> keep monkeying with repositories on Ubuntu, not to mention
> snap/snapd/brltty/systemd… 

Did you smoke something that wasn't meant to end up in your lungs ? Have
you ingested some mushrooms ?

What you write here is a total screw-up non-sense !

1st : There's no "government" in Linux. It's a community driven project,
like Debian.

2nd : You talk about Ubuntu repository, sorry, beep, bong, whatever,
wake-up call, this is Debian, no Ubuntu repository here.

3rd : What's the link between Snap/SnapD/Brltyy and SystemD ?

Plus, they’ve totally screwed up Digital
> Ocean and more or less OVH, so I need a unique kernel (and physical
> servers) to host my wholesome websites. Not to rant, but it has really
> gotten ridiculous.

And now, you put on some specific entities to have screwed Digital Ocean
and OVH (two different company). Sorry dude ! I'm running many OVH rack
and none of them have any problem running Debian Buster or Bullseye,
straight out of the box.


> 
> I’m not doing anything malicious, and the repositories seem to have
> extremely flexible licensing, so what’s the problem? If I ever wind up
> distributing such a kernel which allows access to my copies of the
> repositories, I would give credit where it’s due, of course. 
> 

So you woke up and decided on your own, you're gonna write a brand new
kernel, fully compatible with the Linux kernel ? All by yourself ?

Watch what you are doing, because it would be a bad thing to copy the
code of others while doing so !

> If you guys would give me the green light, I’d appreciate it. I’m not
> saying I would ever distribute such a thing, but I’m not ruling out the
> possibility either. I’m not looking to mirror, just to be clear.
> 

What "green light" are you expecting here ? Everyone talk for their own
self. I think you are missing a really important part here...

There's no "central" entity that will give you a "go a head" on the name
of others. It's not like working for IBM where you employer hold the
copyright of your works.
> Salud de Mexico,
> John (Tarbal) 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Unique kernel with my own backup of all Debian repositories

[John E Petersen]

Hey folks, I’m developing a unique kernel based on Debian Linux, and I’ve
been scraping the website for repositories. After a few thousand, the
servers start to block my ip.

I’m just trying to keep the crazy government out of Linux, because they
keep monkeying with repositories on Ubuntu, not to mention
snap/snapd/brltty/systemd… Plus, they’ve totally screwed up Digital Ocean
and more or less OVH, so I need a unique kernel (and physical servers) to
host my wholesome websites. Not to rant, but it has really gotten
ridiculous.

I’m not doing anything malicious, and the repositories seem to have
extremely flexible licensing, so what’s the problem? If I ever wind up
distributing such a kernel which allows access to my copies of the
repositories, I would give credit where it’s due, of course.

If you guys would give me the green light, I’d appreciate it. I’m not
saying I would ever distribute such a thing, but I’m not ruling out the
possibility either. I’m not looking to mirror, just to be clear.

Salud de Mexico,
John (Tarbal)

Kernel building question (Is -j8 safe and correct?)

[Antonio Russo]

Hello,

I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
irrelevant).
I'm following [1], and the critical command

$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real

does not suggest using -j8 (or -jnumber_of_cores).

1. Is it safe to add -j8 ?
2. Will this indeed give me the speed up I want and expect on my multi-core 
processor?
3. If both of the above are true, why isn't something like that suggested on 
[1]?

Best,
Antonio

[1] 
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official