• partman, growlight, discoverable partitions, and fun

    From nick black@21:1/5 to All on Thu Sep 23 23:00:01 2021
    XPost: linux.debian.maint.boot

    Hello there, debian-boot!

    I am just finishing up the implementation of Discoverable GPT
    Partitions [0] in my growlight tool, and it seems a good time to
    see if I can push this discussion [1] forward.

    I'd like to sound out especially the d-i shareholders on
    replacement of partman with growlight. I can already hear
    hackles raising; I invite you to watch [2]/read [3] my Debconf
    21 presentation, "Parting Ways with Partman", where I hope
    I've made a fairly complete and not-too-incorrect assessment
    of the situation.

    Essentially, my argument is that a tool which can both (a) play
    the system preparation role of partman in d-i and (b) function
    as a mainstream post-install disk management/analysis tool is
    likely to minimize time to support of new features, and doesn't
    consume developer time that can't be used outside of d-i.

    If any longtime developers are truly wedded to partman, I don't
    want to step on any toes; I'm the new guy; I certainly don't see
    any immediately compelling technical reason to make a switch.
    If you enjoy volunteer hackery on partman, great. I suspect,
    however, that partman is no one's great love. Growlight is a
    tool I've maintained and expanded over a decade, and intend to
    continue improving, outside of any system installation role.

    Christian PERRIER wrote on debian-boot 2013-02-07 [4]:

    "It's quite likely that the first step is then to have
    growlight in main Debian, isn't it?"

    Just so, and that was accomplished last year [5]. So let's move on
    to the second step, and consider this major move. I very very
    much hope you'll read through [3] with an open mind.

    Thanks!

    --nick

    [0] https://systemd.io/DISCOVERABLE_PARTITIONS/
    [1] https://lists.debian.org/debian-boot/2013/02/msg00122.html
    [2] https://nick-black.com/tabpower/debconf21-growlight.mkv
    [3] https://nick-black.com/dankwiki/index.php?title=File:Parting_ways_with_partman.pdf
    [4] https://lists.debian.org/debian-boot/2013/02/msg00164.html
    [5] https://tracker.debian.org/pkg/growlight

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFM6hoACgkQX0NADCHL +sxEdg//Y/iCkXUzY8fmz7M6o8co0KfBw1IMuclDvYi1UJf+vovPFs/U7hkbGnEm y+IoDmXjoLSYZA9J7CN06ylajwTFjlnZZ1RYwPy1rdtyWCuVT7Sw5FVOaGQDjOoF W1T8sBvqQGGs6VjiW80FM0rsWelo0v15hCYO8odVKM/GXDRq7oPyZHqBzL7xAxGO 6Nb7wpA88Cfpo5cMhnUKixCPKq0GLC8h0cPtsW0bWIqNaPUBDm36Rb+mcnZj4LfN WWQWsnFNNz0bDpSSaBn3sTaRS5VDE5wNOrORKbBdQz3S5YoctQBsfxEa6LeuDdLn pK7j2F9qNugMPJBZOzezzjCpthMcgmUzdEmwijtlVAWp+0y4iKgdloV6blZirq6z mIrgOKRnSa+va/aXYEkl0QEK2/rVJhWJDQhvECjvL+simEiK2R5qmIe3kQe8o0Rm +PsxTeY3IzgIix/P/jm9avrMbBCa86a9pXzJZfpNOFJKL1Vl1LcVR69k0Xc1ibjd Y04x4AsAZk9pUjQJ5uiXT6faeZjV7Mp3Ud7BzwzpEgoyDm4i7rgpgWVE5o48brl9 u8Z4KgCn+Jn70nngNLlh6ZWuzMIAsmk5fxJkKqNdqUp55nzol5B7WAGGIzkL+Cj5 26n+w3WW9pMXO7DEGV27oEJF0BY8bMbXU+tIgFurJsZD4ejZ1qA=
    =vWQs
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From John Paul Adrian Glaubitz@21:1/5 to nick black on Thu Sep 23 23:30:01 2021
    XPost: linux.debian.maint.boot

    Hello!

    On 9/23/21 22:57, nick black wrote:
    I am just finishing up the implementation of Discoverable GPT
    Partitions [0] in my growlight tool, and it seems a good time to
    see if I can push this discussion [1] forward.

    Does it support partition tables other than GPT, in particular all
    of the partition tables that parted supports?

    If not, I don't think it would be a viable replacement for partman.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to glaubitz@physik.fu-berlin.de on Fri Sep 24 10:40:02 2021
    On Thu, 23 Sep 2021 23:29:14 +0200, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
    If not, I don't think it would be a viable replacement for partman.

    But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco d'Itri@21:1/5 to Marc Haber on Fri Sep 24 12:50:02 2021
    On Sep 24, Marc Haber <mh+debian-devel@zugschlus.de> wrote:

    But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations.
    And the preseeding syntax is as powerful as it is inconvenient.
    I had not heard of growlight before yesterday, but from what I have read
    I think that it is very promising.

    Implementing support for more partition formats, if missing, should be
    rather easy.
    But which ones do we need for architectures which are not actually dead?

    --
    ciao,
    Marco

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCYU2szAAKCRDLPsM64d7X gRCvAP0Yn4RlqD06AfDtGqtPPQUzpEH+xC7pMxKpl6OORRT7CwEAn1GNQaBpCCAA m5Q+ywCBmJVG6dolVuQEAfX6jA87/As=
    =KkJG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nick Black@21:1/5 to glaubitz@physik.fu-berlin.de on Sun Sep 26 01:10:02 2021
    XPost: linux.debian.maint.boot

    It supports MBR, GPT, and APM:

    https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123

    (sorry for the gmail-style top posting; i can't find your mail in my mbox
    for whatever reason)

    Any other partition schemes ought be trivial to add; they've not been added
    yet
    simply because I don't have means with which to test them.

    Looking at the "partition types" section of the Linux configuration, I see:
    Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris
    x86, Unixware,
    Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68.

    Looking at the disk-label code from partman, I see:
    gpt, msdos, amiga, atari, mac, sun

    So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun,
    and mac (if mac is not the same as APM). I don't see any difficulty in
    adding these four, so long
    as there's someone with an Amiga or ATARI who'd be willing to test them
    out. If there are no such
    people, is it that important?

    On Thu, Sep 23, 2021 at 5:29 PM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hello!

    On 9/23/21 22:57, nick black wrote:
    I am just finishing up the implementation of Discoverable GPT
    Partitions [0] in my growlight tool, and it seems a good time to
    see if I can push this discussion [1] forward.

    Does it support partition tables other than GPT, in particular all
    of the partition tables that parted supports?

    If not, I don't think it would be a viable replacement for partman.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913



    --
    nick black <nickblack@linux.com>
    to make an apple pie from scratch, one need first invent a universe.

    <div dir="ltr"><div>It supports MBR, GPT, and APM:<br></div><div><br></div><div><a href="https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123">https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123</a><br></div>
    <div><br></div><div>(sorry for the gmail-style top posting; i can&#39;t find your mail in my mbox for whatever reason)<br><br></div><div>Any other partition schemes ought be trivial to add; they&#39;ve not been added yet</div><div>simply because I don&#
    39;t have means with which to test them.</div><div><br></div><div>Looking at the &quot;partition types&quot; section of the Linux configuration, I see:</div><div> Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris x86, Unixware,</div>
    <div> Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68.</div><div><br></div><div>Looking at the disk-label code from partman, I see:</div><div> gpt, msdos, amiga, atari, mac, sun</div><div><br></div><div>So the only ones covered by partman and
    not covered by growlight would be: amiga, atari, sun,</div><div>and mac (if mac is not the same as APM). I don&#39;t see any difficulty in adding these four, so long</div><div>as there&#39;s someone with an Amiga or ATARI who&#39;d be willing to test
    them out. If there are no such</div><div>people, is it that important?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 23, 2021 at 5:29 PM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de">
    glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>

    On 9/23/21 22:57, nick black wrote:<br>
    &gt; I am just finishing up the implementation of Discoverable GPT<br>
    &gt; Partitions [0] in my growlight tool, and it seems a good time to<br>
    &gt; see if I can push this discussion [1] forward.<br>

    Does it support partition tables other than GPT, in particular all<br>
    of the partition tables that parted supports?<br>

    If not, I don&#39;t think it would be a viable replacement for partman.<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">nick black &lt;<a href="mailto:nickblack@linux.com" target="_blank">nickblack@linux.com</a>&gt;<br>to make an apple pie from scratch, one need
    first invent a universe.<br></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nick black@21:1/5 to All on Sun Sep 26 07:50:02 2021
    Marco d'Itri left as an exercise for the reader:
    On Sep 24, Marc Haber <mh+debian-devel@zugschlus.de> wrote:

    But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations.
    And the preseeding syntax is as powerful as it is inconvenient.
    I had not heard of growlight before yesterday, but from what I have read
    I think that it is very promising.

    Implementing support for more partition formats, if missing, should be rather easy.
    But which ones do we need for architectures which are not actually dead?

    So, as I responded to Adrian [0], the only missing partition
    types appear to be amiga, atari, and sun. Adding them ought be
    simple enough, though I'd need testers with the hardware, or
    access to the hardware.

    My biggest worry personally (aside from the realpolitik of
    getting this change through) regards the automated partitioning
    language available through the preseed system. Trying to emulate
    this bug-for-bug is a non-starter, I think, both from a
    technical and quality-of-life standpoint. If the emulation can't
    be perfectly accurate, I don't think it ought be attempted for
    such a critical, delicate procedure.

    If faithfully honoring the preseed language is seen as a hard
    requirement (not that I've heard this from anyone), it's
    probably not happening. How important is that?

    I could do a limited implementation, perhaps, where I clearly
    error out on a spec I can't handle, falling back to partman.

    If, on the other hand, it seems time to revamp the automatic
    partitioning specification DSL, I could probably get behind
    that. Maybe even the old one; I'd need see how complex it is (I
    recall some pain trying to write complicated partman specs in
    the past, but it was many years ago).

    So...how do I go about making this happen? fwiw, I'm but a lowly
    DM, not a DD.

    --nick

    [0] https://lists.debian.org/debian-devel/2021/09/msg00365.html

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFQB/oACgkQX0NADCHL +szCHQ/9H9dBTTCa2Rq2QdFrOX5H6ZypZuBe/RUXyEByRoBmRt8WYGvTUHSDhP9s MbgFVGSUdsJz7I8dFOqLCR8SHUl+6mu5FHsZxH31xsla+QbpAunHFVxN83MVfv7a lVpkkTmT1NyycCN5F9dU7Mj2QNhD2a3fGVEzHSR+yM/g0HPObsWlO2anvgUU14uz j8m6ohtCPcn9aPVkphPlAvy35zYdCk4Txu4BZD+3XE5zOtEvKAoxSxPsNeuo0MGt UMFjE/zbGJNFJoaM4vudEvnYK2X7y70YCJCbsOxG3CqptNSZ8OEhK89jfW61s9+m K2S+cuC6AwUV2RfzZYHmB1MGVoDArtTeZbdCnZcz4iq/lBxNB/hrFKTN32yzEHs1 7WjXERZvNAU8O9EYcyx9TCV8TCW7GkdAJWm5XUayBb0eSwGG/pGzgHnWGsRKJln1 xwQsCg1cekCaCdIwmsx3rWnnTvUb3hgQS75U9RjdzM9wiX19Xd8zqifDDIsPoF8S dv5xkQcG68PQEbO2VDc4XFSWTJJs36i68VMVNaX0yHaoVv8K3lR/MbkW6BgRL5rp hZEUluXzXcdW7o4tiCdoL3ulhPnxxMqe7ZLHXh5HqUoLoO3cuAimW/PO5Y2wwd4M MFvT4fEvSVZXcfTNba+xhQjX3nsDYt7OuE4ifdXYAgVTpJjJ+0g=
    =h9mH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From John Paul Adrian Glaubitz@21:1/5 to Nick Black on Sun Sep 26 11:10:01 2021
    XPost: linux.debian.maint.boot

    Hello Nick!

    On 9/26/21 00:49, Nick Black wrote:
    It supports MBR, GPT, and APM:

    https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123

    (sorry for the gmail-style top posting; i can't find your mail in my mbox
    for whatever reason)

    Any other partition schemes ought be trivial to add; they've not been added yet
    simply because I don't have means with which to test them.

    So, you are not using libparted then?

    Looking at the "partition types" section of the Linux configuration, I see:
    Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris
    x86, Unixware,
    Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68.

    Looking at the disk-label code from partman, I see:
    gpt, msdos, amiga, atari, mac, sun

    So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun,
    and mac (if mac is not the same as APM). I don't see any difficulty in
    adding these four, so long
    as there's someone with an Amiga or ATARI who'd be willing to test them
    out. If there are no such
    people, is it that important?

    Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1],
    for example.

    I think it makes little sense to not use libparted as it already supports
    all common and less common partition types and reimplementing everything
    that libparted makes little sense to me.

    Adrian

    [1] https://git.savannah.gnu.org/cgit/parted.git/commit/?id=9c266205416ec956d6205c828211480de3767d02

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam Borowski@21:1/5 to nick black on Sun Sep 26 11:00:01 2021
    On Sun, Sep 26, 2021 at 01:41:18AM -0400, nick black wrote:
    Marco d'Itri left as an exercise for the reader:
    And the preseeding syntax is as powerful as it is inconvenient.

    Implementing support for more partition formats, if missing, should be rather easy.
    But which ones do we need for architectures which are not actually dead?

    So, as I responded to Adrian [0], the only missing partition
    types appear to be amiga, atari, and sun. Adding them ought be
    simple enough, though I'd need testers with the hardware, or
    access to the hardware.

    I'd start with asking porters of m68k and sparc64 whether today's systems
    even run anything but Linux. I think there's little point in keeping compat with 80s' OSes.

    At a risk of drawing ire of m68k/sparc64 folks, I'd also suggest not putting your tuits there until this millenium's hardware is covered well.

    My biggest worry personally (aside from the realpolitik of
    getting this change through) regards the automated partitioning
    language available through the preseed system. Trying to emulate
    this bug-for-bug is a non-starter, I think, both from a
    technical and quality-of-life standpoint. If the emulation can't
    be perfectly accurate, I don't think it ought be attempted for
    such a critical, delicate procedure.

    I personally think that preseed is nasty enough that users who do automation
    on a scale that would make learning it worthwhile already have a better way to do such automation. For me, d-i is for manual installs, scripted stuff
    wants a partitioner + glorified debootstrap.


    I do have a different wish, though. Could you please purge any references
    to drivemakers' units (stuff like MiB = million bytes, which current partitioner maliciously[1] swaps around with proper MB of 1048576B)?
    Having them in the user interface is deeply harmful: people will get
    unoptimal alignment unless they 1. know about it, and 2. are careful enough. >From your comments before I see that you try to do proper alignment, but in too many cases no matter how you try, the installer won't align well enough because the hardware might be newer than the version of growlight, hide its inner workings for marketing reason (like stealth SMR drives), etc.
    On the other hand, a completely oblivious user will get good alignment if
    you show numbers measured in gigabytes rather than gillionbytes.

    I know of only one case of multi-GB alignment (some early versions of ipmctl wanted a multiple of 32GB because certain vendor BIOSes had problems with smaller blocks), but the required alignment there is 1GB for years.

    And most importantly: thanks for this effort, it's greatly appreciated!


    Meow.

    [1]. The malice hasn't been invented by the implementor of the old
    partitioner -- it was done by marketing departments of disk vendors in the
    old days; they don't even do so anymore but as they tried going through standard bodies while fighting lawsuits, some damage lingers on. The fault
    of our old partitioner is that it didn't filter out the malice.
    --
    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship.
    ⢿⡄⠘⠷⠚⠋⠀
    ⠈⠳⣄⠀⠀⠀⠀

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nick black@21:1/5 to All on Sun Sep 26 11:50:01 2021
    Adam Borowski left as an exercise for the reader:
    I do have a different wish, though. Could you please purge any references
    to drivemakers' units (stuff like MiB = million bytes, which current partitioner maliciously[1] swaps around with proper MB of 1048576B)?

    this really probably belongs over in the growlight bugtracker, but:

    * i actually use the "memory units" for almost all interfaces,
    because that gives you the numbers you expect. for instance,
    my Seagate Exos 12TBs are 5859442688 4GB AF physical sectors,
    addressable as 23437770752 512B logical sectors. using
    tebibytes, this is 10.914TiB, as opposed to 12.000TB.

    as you can see at [0], we see 12T.

    there's only one place off the top of my head where they're
    *not* used, which is...

    Having them in the user interface is deeply harmful: people will get unoptimal alignment unless they 1. know about it, and 2. are careful enough.

    * alignment =] there we absolutely want to be using MiB etc.,
    and we do.

    From your comments before I see that you try to do proper alignment, but in too many cases no matter how you try, the installer won't align well enough because the hardware might be newer than the version of growlight, hide its inner workings for marketing reason (like stealth SMR drives), etc.
    On the other hand, a completely oblivious user will get good alignment if
    you show numbers measured in gigabytes rather than gillionbytes.

    so i'm not sure i necessarily buy that claim. if i'm overriding
    the default alignment, i typically want to specify a value
    that's independent of the disk size, and i always want it to be
    in a *iB unit. oh, do you mean secondary and later partitions?
    iirc, i accept (in addition to absolute sector numbers) a "+"
    syntax where "+1M" would mean "the first possible 1MiB alignment
    within this empty space", equal to the beginning of the empty
    space when it happens to start on 1MiB multiple.

    i don't know, mang; if i'm explicitly supplying sectors for
    alignment purposes, i'm checking units pretty carefully.
    preferably, i'm never doing that -- the only reason i can see
    would be if i want to leave some large (larger than the
    desirable alignment) chunk of empty space between two partitions.

    and again, in any kind of alignment context, that's when you
    *want* to be using MiB. and in such a context, "M" by itself is
    interpreted that way.

    I know of only one case of multi-GB alignment (some early versions of ipmctl wanted a multiple of 32GB because certain vendor BIOSes had problems with smaller blocks), but the required alignment there is 1GB for years.

    where here i assume you mean 1GiB aka 2³⁰ bytes, not 1GB aka 10⁹
    bytes, correct? you could enter that as 1G, or 1GiB, or 1024MiB,
    or 1048576KiB, or 1073741824. Using 1GB or 1000MB or 1000000KB
    or 1000000000 would force undesirable behavior.

    changes to the text/UI to gently nudge users to the correct
    behavior will be cheerfully considered!

    And most importantly: thanks for this effort, it's greatly appreciated!

    thank you for your kind words! i'd love to see this happen.

    --nick

    [0] https://nick-black.com/images/growlight-2021-09-26.png

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFQQGUACgkQX0NADCHL +syeIw//Sn/Z23HPkVk2y36wI5XG3KeOynKBkRl0BPsywPn2Yu2gCBd/bT6b36mR 83dv3SUDGEi9cgi+4vMNlbJ68A2h94+S2gBiHEacO9jGHD1VUDVXoffjgvN5nquJ KQDtmbXdl2NyzJ1PFp/hrZFPHy7+7tQt6qkHNm3d+/cFw1SgJI0sahCtLVdoi00G XPujIsljcjwWqJ9LbOQ4ieKLc28nQ66Hc/3aursUhqGqWc6FbTOkoeMisJQAP9hv Yj5+MkjI0BJBXepWlXXMo3pnN/JOM0N3dK5eMHFRn/pYDKBgFS8BDqAksjsYvJfi 9p/ELOtUpEngWu+5wzxb4c+P7FvCqVc1kxk9Ciq9YuSalcZ4Sa031OISF6b2ZLTl JwA56kknS0wsAkN5i8pd4YhYSPNlfuKcBNCVMBOrlrozFScl39m7nrlkVDGZfk7q Y9ivXR4nBmcQEgHlTSkMN1sCqLhp2VNof9D7Dwc7cKGWixd1ysrJ3YHMfGlWsotB tk+fmNn4QokvH3/x04s2wKGklSznrkTVSRVdh7xoeCRs2/Oep9TZyIKZyzGgGDz1 q6p3YeDgUhtu2t4NqW8Fu00NttCK4QOrDErxhI/cA4tCMx3dPFEALDpHlIiUNjjq OkRIZ1EZcC/zN83eHKHIxD/qhHkwQD4jinSP9c7QvmwcoDf5BfE=
    =7och
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From John Paul Adrian Glaubitz@21:1/5 to Luca Boccassi on Sun Sep 26 12:50:03 2021
    XPost: linux.debian.maint.boot

    Hello!

    On 9/26/21 12:40, Luca Boccassi wrote:
    Does libparted support the discoverable partitions spec?

    I'm not sure, this thread is the first time I have heard about discoverable partitions. I have read up first what the motivations for these are and
    how useful they would be for Debian.

    Also, since parted is maintained by RedHat, I would expect that this feature would land in parted soon as well.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to glaubitz@physik.fu-berlin.de on Sun Sep 26 13:00:03 2021
    XPost: linux.debian.maint.boot

    On Sun, 26 Sept 2021 at 10:05, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    Hello Nick!

    On 9/26/21 00:49, Nick Black wrote:
    It supports MBR, GPT, and APM:

    https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123

    (sorry for the gmail-style top posting; i can't find your mail in my mbox for whatever reason)

    Any other partition schemes ought be trivial to add; they've not been added yet
    simply because I don't have means with which to test them.

    So, you are not using libparted then?

    Looking at the "partition types" section of the Linux configuration, I see:
    Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris x86, Unixware,
    Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68.

    Looking at the disk-label code from partman, I see:
    gpt, msdos, amiga, atari, mac, sun

    So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun,
    and mac (if mac is not the same as APM). I don't see any difficulty in adding these four, so long
    as there's someone with an Amiga or ATARI who'd be willing to test them out. If there are no such
    people, is it that important?

    Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1],
    for example.

    I think it makes little sense to not use libparted as it already supports
    all common and less common partition types and reimplementing everything
    that libparted makes little sense to me.

    Adrian

    Does libparted support the discoverable partitions spec?

    Kind Regards,
    Luca Boccassi

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Kern@21:1/5 to Adam Borowski on Sun Sep 26 16:40:02 2021
    On 26.09.21 10:50, Adam Borowski wrote:
    My biggest worry personally (aside from the realpolitik of
    getting this change through) regards the automated partitioning
    language available through the preseed system. Trying to emulate
    this bug-for-bug is a non-starter, I think, both from a
    technical and quality-of-life standpoint. If the emulation can't
    be perfectly accurate, I don't think it ought be attempted for
    such a critical, delicate procedure.
    I personally think that preseed is nasty enough that users who do automation on a scale that would make learning it worthwhile already have a better way to
    do such automation. For me, d-i is for manual installs, scripted stuff
    wants a partitioner + glorified debootstrap.

    As someone who has tried in the past to get partitioning correct using preseeding on a wider variety of disk shapes, I think anything but would
    be an improvement. FAI's setup-storage is obviously better. But good
    riddance to the lack of sensible debugging of the shell script horror
    story that is the existing system. :)

    Kind regards
    Philipp Kern

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nick Black@21:1/5 to All on Sun Sep 26 16:30:01 2021
    XPost: linux.debian.maint.boot

    John Paul Adrian Glaubitz left as an exercise for the reader:
    So, you are not using libparted then?

    i am not.

    Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1],
    for example.

    I'd be delighted to support them -- as in, I am honestly eager
    to add ATARI support; that sounds awesome -- I just need some
    way to test the implementations, either via someone running it
    on the environment, or getting access to such a machine.

    I think it makes little sense to not use libparted as it already supports
    all common and less common partition types and reimplementing everything
    that libparted makes little sense to me.

    parted did not have ZFS support when I embarked on this project
    (it appears to have it now). i would not be opposed to
    leveraging libparted if it presents a definite advantage;
    supporting more partition types, so long as it exposes an API i
    can easily work with, would be such an advantage.

    i do note that libparted2 is 621K in the archive, whereas
    growlight itself is only 555K. it is of course possible that
    all that weight is desirable functionality.

    with that said, i would *still want to test on the target
    environment*, to make sure i'm using libparted correctly there.
    so that necessity remains.

    would this allay your concerns?

    --nick

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFQg7gACgkQX0NADCHL +syzjw/+LhE//pDlxXRRNHKVKWN2dvrSl+Jz4NDCXXf3rHTELAomVngtYKVfETXa J7pOReyVn8xP74PISnvtZzC5jO1GiQjig+982//bA8tvoXe9WtVWn7iyc6MzAPXq q2r1uxoQJ+XcatJgV3yEmmzQV/SZ9iUYzPTqIFD5jThadkjnGo1oIpcVwTvFxB07 F1RTH6fWDA2981WjMxR6h/c51rY8hCC4vrGJMaZSzCnaloFn0MTqnZ+CePh4ZGuG EghOaiteffQvVb61W8g9OEr8e98gxi3QUaS4/JJ4GHy80j3jRTHXnd+NtvqZlTa+ yK7PQ8IXMdqoaWRyW+LEs5XQnOI9tsDvCQBRjOR0uUwRztWGftSdjiDeKGoiQ7wU gt/gTlnbkoJDpTAFIgN9ppAmCKnoSezcGBdssJwo3up6LdhO1RWZP25E1awSJ9nn xPt6SljlQ96f4Fod6yJHltH2REqCV4MuRXvcEFnfqwQF8I99TyGAQbk3msTsdUnp LYLwD9gbX30lF7b+c3rW6vP7QU9MfH1VF4kO5TkiVKoZvIr0yvSc6K9IQo5Qo3PY WXzEyIYdBkM84h1EGkd0zbWEm0+Dh4TULx2APH4yp1Eu41ibWLjIOZXkUukkxVQM 0J4YDU/7MYQaaqJ2VxnKX8eXxvegG3Meh2mNmX7HaGsGN5R7fic=
    =657g
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From John Paul Adrian Glaubitz@21:1/5 to Nick Black on Mon Sep 27 13:10:02 2021
    XPost: linux.debian.maint.boot

    Hello Nick!

    On 9/26/21 16:29, Nick Black wrote:
    I'd be delighted to support them -- as in, I am honestly eager
    to add ATARI support; that sounds awesome -- I just need some
    way to test the implementations, either via someone running it
    on the environment, or getting access to such a machine.

    There are emulators available for Atari such as Aranym. And emulators
    available for Amiga such as fs-uae. FWIW, parted should contain everything needed to be able to implement your own support for these partition tables.

    I think it makes little sense to not use libparted as it already supports
    all common and less common partition types and reimplementing everything
    that libparted makes little sense to me.

    parted did not have ZFS support when I embarked on this project
    (it appears to have it now). i would not be opposed to
    leveraging libparted if it presents a definite advantage;
    supporting more partition types, so long as it exposes an API i
    can easily work with, would be such an advantage.

    Well, using a missing feature in the past against parted that is present
    there is not such a good argument against using it, to be honest.

    i do note that libparted2 is 621K in the archive, whereas
    growlight itself is only 555K. it is of course possible that
    all that weight is desirable functionality.

    I think 70k more disk space is not really a concern.

    with that said, i would *still want to test on the target
    environment*, to make sure i'm using libparted correctly there.
    so that necessity remains.

    I thought you didn't depend on libparted?

    would this allay your concerns?

    No, not really. I consider a partitioning tool to be too important
    to be replaced by an unproven solution.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 12:50:02 2021
    XPost: linux.debian.maint.boot

    On Sun, 2021-09-26 at 12:45 +0200, John Paul Adrian Glaubitz wrote:
    Hello!

    On 9/26/21 12:40, Luca Boccassi wrote:
    Does libparted support the discoverable partitions spec?

    I'm not sure, this thread is the first time I have heard about discoverable partitions. I have read up first what the motivations for these are and
    how useful they would be for Debian.

    Also, since parted is maintained by RedHat, I would expect that this feature would land in parted soon as well.

    Adrian

    If the question is "why does X not use libparted", "does not support discoverable parts spec" is a good enough answer for me.

    --
    Kind regards,
    Luca Boccassi

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmFRoRYACgkQKGv37813 JB5X9g//Z/zhklbxhB5DrFU83mZs13f/RUicxYF6cNPJ6Z7D0+t1bPsF33nlMxIl Q9s4e4YJ+FbGKOQMZ8+YsQQU4CWQRFPSOX7yKNUrwcxFgfA0PjhWssdmubZNV/mM GmdQeALjUHIl6pVQ991yZsdTqcLEgMXk2TDsLj93tIPVVLzY/BkOjgXB/yOEys3m aLtEDnpvDcebzPvedXXf9Xc8zbiNoWSeN3d5PENlD8z/OjruNwV1WZLzav9ZQlJb uJcnJGZPr+ZOjj0kiftDX9zgh2V3vYH8SRBQjn0CYC+JakUAQ2TrwAxUTRuj0Y9S nZgd0F2Sy+ot6q5p4mOPmrw86X/KbfnDrOWs5D/mDxl6TOj2k9IdnHx8AU1gx038 crAb8XEpahWQfKgdAZ7uPOkRZD5xYjizd9Wfj/QaFMUOOJzwRFr6F8IgWlnnHyiV JZWug7h8A2ory2+oX3y+2mJ5oZmz45mdpcJ1NBb3Fp9rvnoOxbXRzmmbz5QqN1ai jz2BpdLVWAqZm7cpUbprWeQRIPr3ldUxTJAMb3vSDg0Iq3/lFzhKBRXkr/GGniNW I5XKAeSXHgB9jNvgc+UL73dnGWcfhbdebEktRGq1ydTKvaVE5/e69I77iN3PAyTY OBA9EW07SUm2oIXlwGYe2GN9zCpXTIrT3ApfiI9jWMMSmlXQKzw=
    =QtY8
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Luca Boccassi on Mon Sep 27 13:10:02 2021
    XPost: linux.debian.maint.boot

    Hello!

    On 9/27/21 12:46, Luca Boccassi wrote:
    Also, since parted is maintained by RedHat, I would expect that this feature >> would land in parted soon as well.

    If the question is "why does X not use libparted", "does not support discoverable parts spec" is a good enough answer for me.

    Not for me, though. Debian has always followed the philosophy to be a universal operating system, which also meant that we can't (immediately) use all the new technologies and features that other distributions or upstream projects develop.

    For example, we don't use systemd-homed or systemd-firstboot either. That doesn't
    mean Debian is per se worse off. It just means Debian tries to cater different use
    cases and follows different concepts.

    It's different for distributions like Fedora or openSUSE which focus on a very limited set of targets and use cases. That's why they can quickly adopt to all the new features and technologies that upstream projects like systemd develop.

    I'm not saying that one philosophy is better than the other. I'm just saying that
    Debian is not like these other distributions.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Lohoff@21:1/5 to Adam Borowski on Mon Sep 27 14:10:01 2021
    On Sun, Sep 26, 2021 at 10:50:35AM +0200, Adam Borowski wrote:
    On Sun, Sep 26, 2021 at 01:41:18AM -0400, nick black wrote:
    Marco d'Itri left as an exercise for the reader:
    And the preseeding syntax is as powerful as it is inconvenient.

    Implementing support for more partition formats, if missing, should be rather easy.
    But which ones do we need for architectures which are not actually dead?

    So, as I responded to Adrian [0], the only missing partition
    types appear to be amiga, atari, and sun. Adding them ought be
    simple enough, though I'd need testers with the hardware, or
    access to the hardware.

    I'd start with asking porters of m68k and sparc64 whether today's systems even run anything but Linux. I think there's little point in keeping compat with 80s' OSes.

    At a risk of drawing ire of m68k/sparc64 folks, I'd also suggest not putting your tuits there until this millenium's hardware is covered well.

    This might be needed for booting purposes. 80ies Workstations tend to
    have ROMs/BIOSes much like UEFI today and may even be booting files from
    a Filesystem on a specific partition and thus disk label type.

    So you are not breaking compatibility with 80ies OSes but
    the platform as a whole.

    Flo
    --
    Florian Lohoff f@zz.de
    Any sufficiently advanced technology is indistinguishable from magic.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEdb9o7oebX2papQ/KkN1BIMsJ8i8FAmFRrsAACgkQkN1BIMsJ 8i+nfRAAlW5nLMf3Xdr/Omx5CVcVLKE6z+3TeZ+CPhoLbpMWbbJHIeGjjKo9R237 B4cBCdN8CeFVIEwjHw3VCaytlZgjMUUGbIxD7lxqiDvMHpdnKd/TnOaQJejMzxuY TB6mmPPtXVV0aBbWJAAUA6ZyQpXqAYt5zDbJFbNtFpGwo8eQF7224YO5VtXE3JwX C2ft8ZwhWMQy2y1RjgD2xRUc0OELBkh8wbT4dzf8jIZtcKMFonGYoXwsmCndrYyP cY1MXm+3jLGVWrofzLc09HsCWXiRbgYJrk90dafniBe33qTiWKsFmOPFaTF9zIop Qkv8yQbXtpdZfZk26hgWg11RlZCKapwXOfcMbOqKry/dDR55pXvbJfow4xSB+shp 1+6hC48s10XeZeBqVElhHOMh90BjVZFqXNpFbz5TN5TOkQhqf/yf1lH9YwJHn7M+ oqoOcsRoMdFS5aIeEo9NBhY3UOhfb7PDAObwwXFGeE+/OO4jF3q0n09NOsOkCNMI 3myQA8WPArN7Ic/8FgQaWbhlH8WeCprnbUeO6KuwfJhkU1yJdy+eqyVTBpmtn2L0 N6Fye98REYR6EueptYod6t0JLMQx3aHiSom4x5C8o1tVd5qbuhnuJ6RpYfX/AcQB EjtXiCmcMA0d1G4+fibury4bcgLgUIg8XCGaCE214aSiOLEa/gY=
    =cgfE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win3
  • From Holger Levsen@21:1/5 to Nick Black on Mon Sep 27 15:00:02 2021
    XPost: linux.debian.maint.boot

    On Sat, Sep 25, 2021 at 06:49:53PM -0400, Nick Black wrote:
    So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun,
    and mac (if mac is not the same as APM). I don't see any difficulty in
    adding these four, so long
    as there's someone with an Amiga or ATARI who'd be willing to test them
    out. If there are no such
    people, is it that important?

    those ancient hardwares are not important to Debian, we have ceased to support them years ago.

    some people OTOH support them on Debian Ports and some of these people are very vocal about the need of supporting architectures there. In my opinion they should
    only be heard if they also offer to do the work needed to keep those ancient architectures alive. (and so far I've not even read an offer to help *testing* such code there and also no offer to help developing such code...)

    blocking progress on main Debian architectures because of some unsupported ancient
    hardwares seems more problematic to me than not supporting those ancient plattform.


    --
    cheers,
    Holger

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
    ⠈⠳⣄

    It's not about saving the climate or the planet, it's about saving us, the children and grandchildren. The planet will survive anyway.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmFRv6AACgkQCRq4Vgaa qhyzOQ//aE6WNmzSr1XquFpcaMDvc30jcA/22UGG11dn0AiJfjkDsj+SVmaA2uJN mCqC92VEfjDMexBoL8MecRkH4sCgKcgtbKqZ2kSwa2B5vsN8+buFwR2Va6BkcuqV Ku5WvvrxJD6+PoNVqfH6rjsPyv5wVXoNhjckHFRgEYDmWBVinXr73mhLCrk61+nY mYh2dxQrvWqiMHQfMZjXlIoRU25XjsQ+toAg38BWfXepo64BLyIhi3astDrqKbks k/zu63uUw5tmAPL19TLZyEFN04f6kf0QOh62OFGpXYrRNAYZ+ayS2qOaaSwObGbs fyVRL2ZUopu4CQ4DDTdy/sS5Qlqb2KkG8L8KxT9YAAGsUFrv2SklUd3sX9sZm9Zk HQEGxAxHiKp7fVCbSuIT/pIq5xzo6NgSjyjehQOstyixJnKhkUX7MnmfVfFGQAYU s/kKYd9tfW+zB41UFEy9oarenOafsPQvk1zliWu3LeE1r0qtnvEPaz0CwJtk/BVI /tVfpnF36ILZqhwU0/k8bTBvKQrbShs/rdGBBpXfRf4
  • From Luca Boccassi@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 14:30:01 2021
    XPost: linux.debian.maint.boot

    On Mon, 2021-09-27 at 13:06 +0200, John Paul Adrian Glaubitz wrote:
    Hello!

    On 9/27/21 12:46, Luca Boccassi wrote:
    Also, since parted is maintained by RedHat, I would expect that this feature
    would land in parted soon as well.

    If the question is "why does X not use libparted", "does not support discoverable parts spec" is a good enough answer for me.

    Not for me, though. Debian has always followed the philosophy to be a universal
    operating system, which also meant that we can't (immediately) use all the new
    technologies and features that other distributions or upstream projects develop.

    For example, we don't use systemd-homed or systemd-firstboot either. That doesn't
    mean Debian is per se worse off. It just means Debian tries to cater different use
    cases and follows different concepts.

    It's different for distributions like Fedora or openSUSE which focus on a very
    limited set of targets and use cases. That's why they can quickly adopt to all
    the new features and technologies that upstream projects like systemd develop.

    I'm not saying that one philosophy is better than the other. I'm just saying that
    Debian is not like these other distributions.

    Adrian

    Even if that interpretation would work as an excuse to never do
    anything, and I'm not really sure it does, this specification has been published in 2014 [0] so even by Debian standard it's old stuff. It's
    older than Debian Jessie, which was EOL'd last year. If libparted can't
    keep up with 7 years old stuff that in the meantime was implemented in util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
    and so on, then to me it sounds like a tool in maintenance mode:
    perfectly fine and adequate for existing tools and programs, but not
    quite the best choice for new tools developed from scratch.

    --
    Kind regards,
    Luca Boccassi

    [0] https://cgit.freedesktop.org/wiki/www/log/Specifications/DiscoverablePartitionsSpec.mdwn

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmFRuAYACgkQKGv37813 JB7EFA//UthKutL6NuAxZX2tDwF5F3QDkDpbvDCj2N+hbptk2NCi5p2FFIRTTRp6 M6FmnDbbrcBpM8Z7c3uoWMRta4PtQeG4wr+KfAmo9x5+DjaDaiHnncMSgWDF53os fPhdR1lzzJsYdw23i5NeauWBlrU6Vgv5/0y6CE5M5hREnolrFzPI393wfbdxh3kk Num9C8M8grQPo3D4QrnP34nbJduAcC0EJuS+i9xye4HV2vZtjuDKzCIKmluPxmBQ KIVIt7eGgCQwmjEZLSTMvzMrw1I11dVgOKny44RtD5y9enAoilUV2xwwRe7QgT8z H0wp3G3Njn47PvV2NDnP8zgXAqZ073/U/FNAma+9SB+dij+6dVv0paK4V/qtiqRd c4TRZtA3ZcEuWW30bAr4b9rFS+URcXbhsyy+28/uGT71sli6uUMTpmoEgObfu7Vf d7IEIm32dXufDAa7XbEqZWFYznFaHyq76LNVDOEYrZuO27RB68NAFtATY4CSAhRv FjrEgIwL6JdbvvV2quiV06KZo6bPvWI03+RJMuRcl3Fdvr9bW1P9yp48CamO4zP4 jc9YkQSH+xRMOYxctCxL8YQ0Lq48n7YroFHMsgCLc5j5YtvDL/dZvu9me3XOa7lF l8quffde7Y43yyBmyNDhW9qWnHLlFdFyo+ZElDtijlMi56AQGy8=
    =KMiE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fs
  • From Lennart Sorensen@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 15:50:02 2021
    XPost: linux.debian.maint.boot

    On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
    Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software.

    And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements.

    Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project.

    I would have thought that if libparted was missing 1 or 2 features,
    it would make more sense to add those features than to write a new tool duplicating most of the functionality.

    Well unless working with the maintainers of libparted is imposible.
    There are a few projects like that but I don't remember ever seeing
    complains about libparted. Now you have two tools both missing some
    features. Hardly an improvement.

    --
    Len Sorensen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Mon Sep 27 15:30:01 2021
    XPost: linux.debian.maint.boot

    On Sep 27, 2021, at 2:25 PM, Luca Boccassi <bluca@debian.org> wrote:

    Even if that interpretation would work as an excuse to never do
    anything, and I'm not really sure it does, this specification has been published in 2014 [0] so even by Debian standard it's old stuff.

    That’s not what I said so. You’re trying to dismiss my opinion as completely invalid now by trying to frame it such that I am against progress. I am not.

    It's
    older than Debian Jessie, which was EOL'd last year. If libparted can't
    keep up with 7 years old stuff that in the meantime was implemented in util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
    and so on, then to me it sounds like a tool in maintenance mode:
    perfectly fine and adequate for existing tools and programs, but not
    quite the best choice for new tools developed from scratch.

    Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software.

    And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements.

    Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 15:50:02 2021
    XPost: linux.debian.maint.boot

    On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:

    On Sep 27, 2021, at 2:25 PM, Luca Boccassi <bluca@debian.org> wrote:

    Even if that interpretation would work as an excuse to never do
    anything, and I'm not really sure it does, this specification has been published in 2014 [0] so even by Debian standard it's old stuff.

    That’s not what I said so. You’re trying to dismiss my opinion as completely invalid now by trying to frame it such that I am against progress. I am not.

    You dismissed it because it's "new technology":

    Not for me, though. Debian has always followed the philosophy to be a universal
    operating system, which also meant that we can't (immediately) use all the new
    technologies and features that other distributions or upstream projects develop.

    I simply pointed out that it's a 7 years old spec that saw an entire
    LTS Debian version (8, we are now at 11) being released and EOL'ed
    since the time it was published. If this is too new to consider, then
    so are all Debian releases newer than Wheezy.

    It's
    older than Debian Jessie, which was EOL'd last year. If libparted can't keep up with 7 years old stuff that in the meantime was implemented in util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
    and so on, then to me it sounds like a tool in maintenance mode:
    perfectly fine and adequate for existing tools and programs, but not
    quite the best choice for new tools developed from scratch.

    Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software.

    And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements.

    Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project.

    Adrian

    Of course. But jumping in and saying "you should use X instead of Y",
    you can't pretend that nobody asks questions such as "ok, but does libX
    support this very much related and relevant 7 years old specification
    that other comparable tools support", no matter how awkward it is for
    libX.

    --
    Kind regards,
    Luca Boccassi

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmFRydkACgkQKGv37813 JB5OdRAAxUUJlk5DdN5TtFkyDoeWKCWk6zgtzYih48H359aQHUfaK79HXCXcKhpI LWa6nNSbLGMYooLGSSytBPyRmjW9vulZXE6D+V/hvbEDpzbrPsLKN3jcMimSOaeI 1TYmZnGrig74N3H55XO4Pf8ksnJdAO8C+q/+ZatT14Ori2rDHsHsp8dcvNB+E64K TITMkJK+GNHoXrWk2s/OSwadv063CoLtypYAR/muTV36/A71Jo2skdD2tCcU5OO6 n1rMGtPy9zPoN2SrGnHXOkbEE03lZk1C7T8GV/d1mr8kVagg4NcMiNBj+k9sN7TR cyq02i4E1NAasPunMowvW3PEdkI7PhhiTilXckO6DRKyFYtDzBhwXZDJgI5qTtb/ 3/fjsdsfXEnJy0cPC7iFboaoh+7b8nzbSqUrsbfHguhKrS+QpCUaQr/u0mXE2vrJ SDMlJE6khHxnIuxZokM6gU5TlyNQeKrnYcLI3Np/InrUjqMQqw9ivluehAvbITh2 cjauSIuEly4ajs7wmNf97BvorqebevL389P/3YjY1N0CyJy5T3RKsXPeBbDeHW3p 1sYkM0yvUZniRj1tkMADmGstRtawV8hllqSntWmQ6PMUSUp+0T3zouI7MTy4aYLr wJbKJCEYmrzWPEYdJr5wjGfH0QqkqK/mjqC9ffN4DUpsADDIUsU=
    =Qi/T
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco d'Itri@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 17:00:02 2021
    XPost: linux.debian.maint.boot

    On Sep 27, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    Not for me, though. Debian has always followed the philosophy to be a universal
    operating system, which also meant that we can't (immediately) use all the new
    technologies and features that other distributions or upstream projects develop.
    It never meant that.

    --
    ciao,
    Marco

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCYVHahQAKCRDLPsM64d7X gW13APwL348zDRovMcVOzG+Iq7W0dkgo667VbkKFbDL3gMvD2QD+OYBqTPq3vxMg rtSp+j0lehq4mqSc7TBxds2gllqNPgQ=
    =L/me
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Mon Sep 27 16:30:02 2021
    XPost: linux.debian.maint.boot

    On Sep 27, 2021, at 3:41 PM, Luca Boccassi <bluca@debian.org> wrote:

    On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:

    On Sep 27, 2021, at 2:25 PM, Luca Boccassi <bluca@debian.org> wrote:

    Even if that interpretation would work as an excuse to never do
    anything, and I'm not really sure it does, this specification has been
    published in 2014 [0] so even by Debian standard it's old stuff.

    That’s not what I said so. You’re trying to dismiss my opinion as completely invalid now by trying to frame it such that I am against progress. I am not.

    You dismissed it because it's "new technology":

    Not for me, though. Debian has always followed the philosophy to be a universal
    operating system, which also meant that we can't (immediately) use all the new
    technologies and features that other distributions or upstream projects develop.

    You’re reducing my argument to the word “new” which is definitely not my point. As you can see from the rest of my message my primary point is that Debian follows a different philosophy meaning that we don’t always adopt technologies that other
    distributions use.

    Fedora and openSUSE are much more similar to each other than Debian is to both.

    I simply pointed out that it's a 7 years old spec that saw an entire
    LTS Debian version (8, we are now at 11) being released and EOL'ed
    since the time it was published. If this is too new to consider, then
    so are all Debian releases newer than Wheezy.

    Yes, but the age was never my argument. My argument was that replacing such a fundamental software component like the partitioning tool in an installer is something that has to be justified by technical merits and by weighing pros and cons against each
    other.

    The fact that’s it’s newer or has the single feature X is not sufficient in my opinion. Especially when there is no proof yet that getting support for discoverable partitions justifies the loss of features that parted has.

    It's
    older than Debian Jessie, which was EOL'd last year. If libparted can't
    keep up with 7 years old stuff that in the meantime was implemented in
    util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
    and so on, then to me it sounds like a tool in maintenance mode:
    perfectly fine and adequate for existing tools and programs, but not
    quite the best choice for new tools developed from scratch.

    Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software.

    And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements.

    Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project.

    Adrian

    Of course. But jumping in and saying "you should use X instead of Y",
    you can't pretend that nobody asks questions such as "ok, but does libX support this very much related and relevant 7 years old specification
    that other comparable tools support", no matter how awkward it is for
    libX.

    I was not the one that was making this request, it was Nick. I’m perfectly fine with the status quo.

    Again, the party introducing the new solution should provide the arguments to convince the maintainers of the existing solution.

    For example, a convincing argument would be a demonstration installation ISO which let’s others interested in the project test it and check whether it delivers the improvements that were promised.

    I don’t think that this is such an extraordinary requirement to ask for.

    Also, I would be interested to know what approaches are currently used in Fedora, Arch, Gentoo and openSUSE (I will check that later myself when I’m back at the computer).

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Metztli Information Technology@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 17:30:01 2021
    XPost: linux.debian.maint.boot

    This is a multi-part message in MIME format.
    On 9/27/21 4:01 AM, John Paul Adrian Glaubitz wrote:
    Hello Nick!

    On 9/26/21 16:29, Nick Black wrote:
    I'd be delighted to support them -- as in, I am honestly eager
    to add ATARI support; that sounds awesome -- I just need some
    way to test the implementations, either via someone running it
    on the environment, or getting access to such a machine.
    There are emulators available for Atari such as Aranym. And emulators available for Amiga such as fs-uae. FWIW, parted should contain everything needed to be able to implement your own support for these partition tables.

    I think it makes little sense to not use libparted as it already supports >>> all common and less common partition types and reimplementing everything >>> that libparted makes little sense to me.
    parted did not have ZFS support when I embarked on this project
    (it appears to have it now). i would not be opposed to
    leveraging libparted if it presents a definite advantage;
    supporting more partition types, so long as it exposes an API i
    can easily work with, would be such an advantage.
    Well, using a missing feature in the past against parted that is present there is not such a good argument against using it, to be honest.

    i do note that libparted2 is 621K in the archive, whereas
    growlight itself is only 555K. it is of course possible that
    all that weight is desirable functionality.
    I think 70k more disk space is not really a concern.

    with that said, i would *still want to test on the target
    environment*, to make sure i'm using libparted correctly there.
    so that necessity remains.
    I thought you didn't depend on libparted?

    would this allay your concerns?
    No, not really. I consider a partitioning tool to be too important
    to be replaced by an unproven solution.

    Growlight seems like an adequate tool for Debian expert option as it has potential to enable additional flexibility and extensibility for file
    system options which may not offered in the current set of Parted
    utilities. For instance, the current Growlight string/option 'enter
    filesystem name' could be re-implemented, with a couple lines of code,
    into something like 'enter plugin override'

    < https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png >

    etc., for other filesystems.


    Also Growlight may reduce at least a subset of UDEB modules needed for
    each file system supported by Debian, thus reducing complexity. For
    instance, it was relatively straightforward to add support for reiser4
    -- as compared to initial efforts developing substantial code for a partman-[filesystem] UDEB module.

    < https://metztli.it/bullseye/gl/growlight-reiser4.png >

    In other words, even if there is no compelling reason to update d-i at
    the moment, Growlight has potential to decrease complexity in the long run.

    Just a point of view from an outsider, of course, I do not want anyone
    'to have a cow' for refusing to potentially move away from their place
    of comfort and/or entertaining a perspective that may be considered 'taboo.'


    Best Professional Regards.

    --

    Jose R R
    http://metztli.it <http://metztli.it> ---------------------------------------------------------------------------------------------
    Download Metztli Reiser4: Debian Buster w/ Linux 5.13.14 AMD64 ---------------------------------------------------------------------------------------------
    feats ZSTD compression https://sf.net/projects/metztli-reiser4/ <https://sf.net/projects/metztli-reiser4/> ---------------------------------------------------------------------------------------------
    or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/ <https://sf.net/projects/debian-reiser4/> -------------------------------------------------------------------------------------------
    Official current Reiser4 resources: https://reiser4.wiki.kernel.org/ <https://reiser4.wiki.kernel.org/>

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 9/27/21 4:01 AM, John Paul Adrian
    Glaubitz wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:a217aa68-644f-b80e-2a9d-e0dee6d5187a@physik.fu-berlin.de">
    <pre class="moz-quote-pre" wrap="">Hello Nick!

    On 9/26/21 16:29, Nick Black wrote:
    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">I'd be delighted to support them -- as in, I am honestly eager
    to add ATARI support; that sounds awesome -- I just need some
    way to test the implementations, either via someone running it
    on the environment, or getting access to such a machine.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    There are emulators available for Atari such as Aranym. And emulators
    available for Amiga such as fs-uae. FWIW, parted should contain everything needed to be able to implement your own support for these partition tables.

    </pre>
    <blockquote type="cite">
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">I think it makes little sense to not use libparted as it already supports
    all common and less common partition types and reimplementing everything
    that libparted makes little sense to me.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    parted did not have ZFS support when I embarked on this project
    (it appears to have it now). i would not be opposed to
    leveraging libparted if it presents a definite advantage;
    supporting more partition types, so long as it exposes an API i
    can easily work with, would be such an advantage.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    Well, using a missing feature in the past against parted that is present
    there is not such a good argument against using it, to be honest.

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">i do note that libparted2 is 621K in the archive, whereas
    growlight itself is only 555K. it is of course possible that
    all that weight is desirable functionality.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    I think 70k more disk space is not really a concern.

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">with that said, i would *still want to test on the target
    environment*, to make sure i'm using libparted correctly there.
    so that necessity remains.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    I thought you didn't depend on libparted?

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">would this allay your concerns? </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    No, not really. I consider a partitioning tool to be too important
    to be replaced by an unproven solution.

    </pre>
    </blockquote>
    <p>Growlight seems like an adequate tool for Debian expert option as
    it has potential to enable additional flexibility and
    extensibility for file system options which may not offered in the
    current set of Parted utilities. For instance, the current
    Growlight string/option 'enter filesystem name' could be
    re-implemented, with a couple lines of code, into something like
    'enter plugin override'</p>
    <p><a class="moz-txt-link-rfc2396E" href="https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png">&lt;
    https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png &gt;</a></p>
    <p>etc., for other filesystems.<br>
    </p>
    <p><br>
    </p>
    <p> Also Growlight may reduce at least a subset of UDEB modules
    needed for each file system supported by Debian, thus reducing
    complexity. For instance, it was relatively straightforward to add
    support for reiser4 -- as compared to initial efforts developing
    substantial code for a partman-[filesystem] UDEB module.<br>
    </p>
    <p><a class="moz-txt-link-rfc2396E" href="https://metztli.it/bullseye/gl/growlight-reiser4.png">&lt; https://metztli.it/bullseye/gl/growlight-reiser4.png &gt;</a><br>
    </p>
    <p>In other words, even if there is no compelling reason to update
    d-i at the moment, Growlight has potential to decrease complexity
    in the long run.</p>
    <p>Just a point of view from an outsider, of course, I do not want
    anyone 'to have a cow' for refusing to potentially move away from
    their place of comfort and/or entertaining a perspective that may
    be considered 'taboo.'</p>
    <p><br>
    </p>
    <p>Best Professional Regards.</p>
    <p>-- <br>
    </p>
    <div dir="ltr" class="gmail_signature"
    data-smartmail="gmail_signature">
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>
    <div dir="ltr">
    <div>Jose R R<br>
    <a href="http://metztli.it"
    target="_blank">http://metztli.it</a><br> ---------------------------------------------------------------------------------------------<br>
    Download Metztli Reiser4: Debian
    Buster w/ Linux 5.13.14 AMD64<br> ---------------------------------------------------------------------------------------------<br>
    feats ZSTD compression <a
    href="https://sf.net/projects/metztli-reiser4/"
    target="_blank">https://sf.net/projects/metztli-reiser4/</a><br>
    <font color="#888888">---------------------------------------------------------------------------------------------<br>
    or SFRN 5.1.3, Metztli Reiser5 <a
    href="https://sf.net/projects/debian-reiser4/"
    rel="noreferrer" target="_blank">https://sf.net/projects/debian-reiser4/</a></font><br>
    -------------------------------------------------------------------------------------------<br>
    Official current Reiser4 resources: <a href="https://reiser4.wiki.kernel.org/" target="_blank">https://reiser4.wiki.kernel.org/</a></div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nick black@21:1/5 to All on Tue Sep 28 00:30:01 2021
    Marc Haber left as an exercise for the reader:
    But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations.

    so overall, i've got to say the feedback i heard here was a lot
    more positive than i was expecting, though there was a bit less
    than i had hoped for. but perhaps something that can be touched
    would see more interest?

    given that no one seemed to reject the idea out of hand, i'm
    going to go ahead and rebase my work from 2012 (or more likely
    look at it once and redo it) in a Salsa fork of d-i, and make
    some installation media available. forgive me for likely only
    having x86 available at first. i'll try to have this done within
    a week or so, and put it up on my server. people can then give
    it a whirl.

    it's hard to see how exactly i proceed from that point, save in
    a reactive fashion (not complaining, just saying). but we'll see
    what happens when an ISO is available!

    note that there would still be some questions where i'd need
    input from Project members (as noted in my Debconf [0]
    presentation), particularly regarding translation (even if i can
    lift significant portions from partman, i'd need it looked
    over) and facilitating accessibility technology.

    --nick

    [0] https://nick-black.com/dankwiki/images/b/b9/Parting_ways_with_partman.pdf

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFSRLwACgkQX0NADCHL +swR/w/+MJ8O/3mU2jN8+L+5+O/ij1qr7voMuNNZRkDOthepq/Z9DGXMrJD466pv ZQ+Y/hMCTgnjY9rDhDkLPpcVRwr0UPYYbqLoIYp1+5w1rM7O1wHpx4VW4HmM60rK Lps2fuEd0AsnqrznbzAhu/BGlLOM1mHoPYuqiHmJkxvAdq0VKNVAuQt0DWT3vvdQ BpZeZ7sGYwqve2N+cad5JMYCR6kTXmEk09CKpMZ53HGVIoUQt84rG0B4M2BZ6OCI PfIY3GhdWNRu5HEwAyrWbH9oSojGU5UeF9AK7LSEMs5N6f1SHwkUxflNZxT2rNBl 5e2FWyx4tINFMNxFK2J0zRKp8lOXsKXvaUmF6qN0eLUth0JF2P4oAQZqhMYYqKw6 9ccZ6xr7rKqHT88HG1tf13T7fDfcub6Bzky1ds31JVxhQUts3tlhX0V9cedDm0Y/ bEssCihTeja2tIxFzgseysGIijl8BwhoaqRa2PPZd+zl2Ddyl+jpNn2o7l+PRxnX Ik2Rl3T9hjWsN7VuBzL98GJ8RUu/Mq8/tP1E9BdUnnpXYJPehrN3DCzqLfVzkDkj dhD/Jn+UMGF5lqym9JUVQFts+PUewTcBLsAL5qUBAw+l7BNcJy0yA9lVsHIizgHm Wch3ybnnRPNed5HwO//FT30TLIyoc/yj8Kt7qr5TzOHejh4S+IQ=
    =bWAJ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From Wouter Verhelst@21:1/5 to nick black on Tue Sep 28 12:10:01 2021
    Hi Nick,

    On Mon, Sep 27, 2021 at 06:25:03PM -0400, nick black wrote:
    Marc Haber left as an exercise for the reader:
    But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations.

    so overall, i've got to say the feedback i heard here was a lot
    more positive than i was expecting, though there was a bit less
    than i had hoped for. but perhaps something that can be touched
    would see more interest?

    given that no one seemed to reject the idea out of hand, i'm
    going to go ahead and rebase my work from 2012 (or more likely
    look at it once and redo it) in a Salsa fork of d-i, and make
    some installation media available. forgive me for likely only
    having x86 available at first. i'll try to have this done within
    a week or so, and put it up on my server. people can then give
    it a whirl.

    I hadn't replied to it *yet*, but had fully intended to do so (just
    didn't get around to that yet).

    One thing that partman does is "support plug-ins", to allow for
    configuring block devices before being able to partition them, where
    needed. This can be useful for iSCSI, multipath, or (the one I care most
    about) NBD. I wrote a "partman-nbd" a few years back to do just that:

    https://salsa.debian.org/installer-team/partman-nbd

    This adds a few options to the partitioner menu to allow you to
    add or remove an NBD device, and then if used makes sure the resulting
    system is configured properly so that the NBD device(s) configured in
    the installer will work after the system has been booted.

    It would be nice if whatever component you write to replace partman has
    support for things along these lines too. I don't mind having to rewrite partman-nbd if that ends up being necessary (it's trivial enough), but
    others might have different ideas about, say, partman-iscsi (just using
    that as an example though, no idea about the details there).

    Thanks,

    --
    w@uter.{be,co.za}
    wouter@{grep.be,fosdem.org,debian.org}

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From nick black@21:1/5 to All on Tue Sep 28 12:30:02 2021
    Wouter Verhelst left as an exercise for the reader:
    One thing that partman does is "support plug-ins", to allow for
    configuring block devices before being able to partition them, where
    needed. This can be useful for iSCSI, multipath, or (the one I care most about) NBD. I wrote a "partman-nbd" a few years back to do just that: https://salsa.debian.org/installer-team/partman-nbd

    Thanks a lot for pointing this out, Wouter -- this is *exactly*
    the kind of feedback I was hoping for! I allow loopback devices
    to be set up, but not in any reboot-crossing manner, and I have
    no NBD nor iSCSI functionality.

    https://github.com/dankamongmen/growlight/issues/150

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFS7DAACgkQX0NADCHL +sx5sA//abxmdC8KFwk2fQJflDU053DiEz1EVlKuD6hyEty+gO2Pqbs+AnolpGS5 oLrGwupKD5ybPlVJuRfxxrDvrfnuIR2rTTz2Aka9IuzypApQblzMmvLbbfXBPJFp 5y9Bz7Ok5Xzq1r9ARZXUgRTEp/Sy6vuB06MYfkBYbH2PJRs3tooaBxVtTQLro4g9 11FKoZKX3lhxBPex+hVjP3By3X4JtnZMcCIUfTMMy/KY06J+9HWX6F0QhCso9DWl IGfFWyQOXjcssv4yFRf2ia7GnjgecKA/XfAhcJl3QhzPrVm7aF+y1c2vZLKsZpwX d/0wUxC0oIjtGA8lTa+MTo1ZflpMzMFyO+eNn7TVzbGp1XQXZiEIjh5Xf+oqX6Bp 5lsjYlvCaumNXDd4ckLF8djl2jqLIREGVk9rBSbYPyfY33dOnLqLovPmzjXiM63O oDydMYibfpSKtzV/ZdJNl1IlM8KGSC9xMgqiw4S8kpViB0UBojZGL6AYxjzYqtDQ yt/st06Rs0emnbXxBGR4Tc0VE2MXac4YkPpaK47j9c/HCsAGIY51Ndb0LbPQWuGL EEg1PaNeKHJTDw6kKtBsQrGjmeY9ERHClsaDnOsFnxtVqDymVMBAtn8sozPVH4dE jpf0dssaDNvhKvGHsZHIlb+o6Wg1h5Ivos4GNCmKHzhnmciBqHI=
    =ZVqC
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From John Paul Adrian Glaubitz@21:1/5 to Wouter Verhelst on Tue Sep 28 12:30:02 2021
    XPost: linux.debian.maint.boot

    On 9/28/21 12:13, Wouter Verhelst wrote:
    IOW, chill out, nobody's going to kill off partman unless there's
    something that's *actually* better than partman.

    Just some comments after reading after this [1] because I honestly find it unfair the way I am being cornered here.

    First of all, neither Fedora or openSUSE seem to use glowlight as their
    primary partitioning tool nor are they using discoverable partitions.

    Secondly, discoverable partitions are primarily intended for containers
    and systemd is using mkosi [2] for generating such images with discoverable partitions.

    Thirdly, Luca Boccassi considers himself to be systemd upstream [3] without disclosing that information here. This is an information that he should
    at least have disclosed before starting to voice his support for discoverable partitions and insisting that the feature is important enough to kill off parted.

    Thanks,
    Adrian

    [1] https://lwn.net/Articles/859240/
    [2] http://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html
    [3] https://lwn.net/Articles/859769/

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wouter Verhelst@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 13:00:01 2021
    XPost: linux.debian.maint.boot

    On Tue, Sep 28, 2021 at 12:22:18PM +0200, John Paul Adrian Glaubitz wrote:
    On 9/28/21 12:13, Wouter Verhelst wrote:
    IOW, chill out, nobody's going to kill off partman unless there's
    something that's *actually* better than partman.

    Just some comments after reading after this [1] because I honestly find it unfair the way I am being cornered here.

    Yes, and what I'm saying is, I don't think anyone is trying to corner
    you here, Nick are just saying "hey here's some cool new tech, what do
    people think". The consensus in my reading is that people like it enough
    that we might want to see some proof of concept, and then, assuming it
    doesn't lack functionality that we don't want to lose and gives us
    something new that we do like (e.g., better usability, more features,
    etc etc) then we can perhaps replace partman one or more releases down
    the line as the default partitioner.

    You have some very good arguments against growlight in its *current*
    state. That's fine. Just stay on top of things, and perhaps help Nick
    out with testing a few of the more exotic features that partman
    currently supports? Either through emulators or by giving him access to
    real hardware if you can provide it (and given your collection, I
    suspect you can ;-) ).

    partman is currently being maintained by the d-i team very much in a
    drive-by patches manner, but it's not actually seeing development of new features. If Nick is offering to take over that work by replacing the
    parted bits in d-i by his pet project, *and* he's offering to make sure
    that we don't lose functionality we actually care about, then I think
    that's a good thing? It's just a matter of making sure Nick *knows*
    about the important bits, and that they get implemented in whatever we
    end up replacing partman with before we actually do so...

    --
    w@uter.{be,co.za}
    wouter@{grep.be,fosdem.org,debian.org}

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wouter Verhelst@21:1/5 to nick black on Tue Sep 28 12:40:01 2021
    On Tue, Sep 28, 2021 at 06:19:28AM -0400, nick black wrote:
    Wouter Verhelst left as an exercise for the reader:
    One thing that partman does is "support plug-ins", to allow for
    configuring block devices before being able to partition them, where needed. This can be useful for iSCSI, multipath, or (the one I care most about) NBD. I wrote a "partman-nbd" a few years back to do just that: https://salsa.debian.org/installer-team/partman-nbd

    Thanks a lot for pointing this out, Wouter -- this is *exactly*
    the kind of feedback I was hoping for! I allow loopback devices
    to be set up, but not in any reboot-crossing manner, and I have
    no NBD nor iSCSI functionality.

    https://github.com/dankamongmen/growlight/issues/150

    NBD is fairly easy to set up (well, it is for me, but then I'm biased).
    For the server side, you install nbd-server, you create a (probably
    sparse) large file somewhere, and then edit /etc/nbd-server/config to
    point to that. For the client side, you install nbd-client and read "man
    5 nbdtab" if you want to persist things, or you read "man 8 nbd-client"
    if you just want to connect now and not care about reboot.

    iSCSI works very differently and is way more complex, but I remember
    from when I last played with it (which is a while ago, so the details
    are hazy) that it's not possible to set up in a non-persistent manner
    (i.e., all iSCSI connections survive reboot unless explicitly deleted,
    although obviously partman-iscsi has to do some dark magic to ensure the configuration is migrated from the d-i environment to the live system).

    There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath,
    and a whole slew of other things, if you want to configure this from
    growlight.

    That said though, I would personally recommend against doing that. From
    where I'm standing, it seems to be out of scope for growlight? If you're replacing partman in d-i, you'd still need to add *some* d-i
    integration, and I'd imagine that integration is where this type of
    device configuration would go. As far as running growlight outside of
    d-i goes, there I'd think you'd just tell the user to configure the
    device before starting growlight (or you'd give them the ability to
    re-scan for new devices after they'd set up the device in a (different) terminal), and then that'll be all? Otherwise you'll end up with a
    neverending story of "oh here's another type of device that needs to be
    added", and I don't think that's a great rabbit hole to go down.

    I could be wrong though, haven't looked at growlight in much detail, and
    in the end it's your call, not mine :-D

    --
    w@uter.{be,co.za}
    wouter@{grep.be,fosdem.org,debian.org}

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cyril Brulebois@21:1/5 to All on Tue Sep 28 12:50:01 2021
    XPost: linux.debian.maint.boot

    Hi nick,

    [ cc += debian-boot@ ]

    nick black <dankamongmen@gmail.com> (2021-09-27):
    Marc Haber left as an exercise for the reader:
    But maybe an alternative? I find the partitioning step one of the
    most error-prone and hard-to-use parts of non-trivial Debian
    installations.

    so overall, i've got to say the feedback i heard here was a lot more
    positive than i was expecting, though there was a bit less than i had
    hoped for. but perhaps something that can be touched would see more
    interest?

    FWIW I've followed the answers to your mail over the last few days,
    but I haven't had a chance to look at either the video or the slides
    (only 4 days before your initial mail and the one I'm replying to…).


    At first glance, it seems fine to be experimenting with a different partitioner; of course all people are somewhere on the love/hate
    spectrum regarding partman and the zillions of partman-* packages, but
    it's indeed a shell maze and it *probably* could use some heavy lifting.
    I keep hoping that simple use cases are made simple(r)… maybe growlight
    could help there (e.g. “I'd like soft RAID1 with encrypted LVM, all that
    with a UEFI boot — therefore ESP —, without being a storage wizard”).

    I suppose some step (once you've experimented on a growlight-only
    d-i) would be to have both partman and growlight, and let people
    choose (maybe with a flag at boot time, or by entering expert mode or whatever), until we have a better idea what works, what doesn't, what
    can be fixed, what cannot, and until a decision is made for the next
    Debian stable release.


    Leaving the technical integration aside for a moment, one question
    that comes to mind is whether this would be a one-shot contribution or
    some kind of longer commitment to maintain that different partitioner.
    I seem to remember earlier attempts at revamping the partitioning
    step, which stalled eventually.

    (Your recent mail to debian-newmaint@ is a hint; your apparent
    steadiness of those packages maintenance-wise is another; and your
    apparent interest in adding support to possibly missing features yet
    another.)

    Of course, one might object that the question is moot as there isn't
    much active development on partman components (even if some patches have
    been submitted over the last few days), but at least that's a known
    (imperfect, but…) beast.

    given that no one seemed to reject the idea out of hand, i'm going to
    go ahead and rebase my work from 2012 (or more likely look at it once
    and redo it) in a Salsa fork of d-i, and make some installation media available. forgive me for likely only having x86 available at first.
    i'll try to have this done within a week or so, and put it up on my
    server. people can then give it a whirl.

    Feel free to touch base with debian-boot@ and/or debian-cd@ once you
    have a working proof of concept that some people have toyed with; we can discuss how the “alternative” part could be implemented (different
    images, or both partitioners ship together, with some option/selection — people might remember GRUB vs. LILO). I cannot guarantee a timely answer
    (life tends to keep me busy), but you shouldn't see a lack of answer
    after just a few days as if people were not interested.

    note that there would still be some questions where i'd need input
    from Project members (as noted in my Debconf [0] presentation),
    particularly regarding translation (even if i can lift significant
    portions from partman, i'd need it looked over) and facilitating accessibility technology.

    I won't delve into specifics (I did mention I didn't do any research,
    right?) but as long as your application can be controlled via debconf,
    it should fit right in within all our installation images (text based installer, graphical installer, network-controller installer, etc.), and
    things like localization and accessibility support should be automatic
    (of course you'd still need to get the translation process bootstrapped
    for your own strings at some point, but the inner workings should all be
    there already).


    Cheers,
    --
    Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
    D-I release manager -- Release team member -- Freelance Consultant

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmFS8qkACgkQ/5FK8MKz VSBI9hAAhngBTL595fhpvjjKT7Pv2ZiaGKMkSd+r5xQTgHQx4Z7QgaKR0et8sSv3 CNuRBSLfYAaEs9CRhFBD/tLUYjdh0b+y37LUp/upphxlm218Bqz7SzzYlLufCw/Y BGO48SWpwn6V4yNSdwBrxEWUF/jd9pJyX4QOHR42PBioKfN7tbmfbBy3HJgD6Mqf ZOSWvq+P7QWtAxoFitFjnFNoUmmRl1ICheOuZW1vl6MXRAF48jXvKlVlXuRgRTCp P2gZRVC7oYg6dDbUhmPYoEjzUfsOV9ZrhCh4/SYEf0RqnGOxHyCosnEVFPqqWW34 RxRzy/BVfxBvXQe09VIzkrN4ArL2WUMCvo9EeT5Z98avkYf55qX6vC5PeAv+qg2n IAs3N7+jhb/R83Fk6kSrSSP/jzDdQjGh187938NHgDMwqi0W2y/18lRhN7kgCbLZ xBHX5HIKLUnBM30Ua4t1ipUg3SBxTCmrIwN+/MT/8eiL4bJiJUSNzbdtzDe7/C3F Of9oTgv5H4aiW1Q6zzSqCSaLrpVMt3tw4ndmBWp6qt28Kw9M4IoZ1VM00F234Phf tC8sHFajt71n/oiBiJ8W0VKw0BTRVpqf6UeFIXeNJMeywxVTdvV7Kx8zcEzRZrLd NefNBex8yRlVPFXSnZR2Gvovu6e4D1Lk6uvyY8jHbkIhVTG1DqQ=
    =JsZg
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    *
  • From nick black@21:1/5 to All on Tue Sep 28 13:00:01 2021
    Wouter Verhelst left as an exercise for the reader:
    iSCSI works very differently and is way more complex, but I remember
    from when I last played with it (which is a while ago, so the details
    are hazy) that it's not possible to set up in a non-persistent manner
    (i.e., all iSCSI connections survive reboot unless explicitly deleted, although obviously partman-iscsi has to do some dark magic to ensure the configuration is migrated from the d-i environment to the live system).

    i've actually worked pretty extensively with iSCSI--i presented
    on it at LPC2015 [0] =]. as far as i understand, iSCSI
    connections are initiated and managed by the iscsid userspace
    daemon (aside from root-on-iSCSI, which uses iscsistart, or at
    least did. UEFI/BIOS iSCSI can also server here).

    There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath,
    and a whole slew of other things, if you want to configure this from growlight.

    as you note, most of this is not stuff i want to slap a UI on,
    but i'd certainly want to hit full partman feature parity...in
    time. if it's best early on, i feel no shame punting more
    esoteric setups to partman; as i've said, i would expect partman
    to remain present on the installation media for at least some
    significant time.

    I could be wrong though, haven't looked at growlight in much detail, and
    in the end it's your call, not mine :-D

    nope, pretty much totally correct.

    --nick

    [0] https://nick-black.com/dankwiki/images/e/ea/Public_LPC2015_-_Dynamic_iSCSI_at_Scale-_Remote_paging_at_Google.pdf

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFS8+8ACgkQX0NADCHL +szc4w/9Hqb56RceNmqS7154YQB86EWmGArglLpO5gWn2aAMJcRbZaZwx/JABCdm 7smX0B/TuImIYEEc9zw13qB31TZYnKPoaeEsLTX/qSVSMzMDvt561qdHFYBzNjTg +vuedL5TGtM2vn634d0OkjAvPi86FHNc2E5cOqEhpwXiOaVSu098dO5lPMxHDG8G ep2/bhgn4lC9xixs3iF1XzdAqcnir4OxYKE5AcSEJMz8ix9QYXeAEY+X/27IdZdZ 5KTFQvfiExPPtlQ/6Kz6ssSW0U0UXIY4cDwXGwR0ZR5ko3/hbS6vy2RyLC8+pNEF 2aBPpd05drfeFfdrRhEdW6fJuL7Tf4tB5ijp+n+xS7tt5/maBjzX18jz8fWJjFbd Cetq3yYBvivluAZ5M9KZJfMJQddlV0LZvS60iTK0kLz1J9k1xL3yQBjFQ77k7L6I PD3Y2x18H2ztgOwh1QYenUYOQZYhJg4qQL76J9x0eUMLS6FDkMdeBXuQQmXya56h NfVguSKN0xF4mRMhiQUt5OlyFzaxtRS1JupWoihbJzrG9jD0ID1rDC1zWEV7x7y1 hQdSckS5e0NXfcARHbQQSBOnbtvqS4Dm0HUpopODHwttQX/iQ+kYzoH0Yx7fAC5B bjv3xjZzBSvyldDPsx++WVJIqZ66fPJn7+GW0LSWQJjWlKnsJnA=
    =XQ/s
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From nick black@21:1/5 to All on Wed Sep 29 00:50:01 2021
    XPost: linux.debian.maint.boot

    Steve McIntyre left as an exercise for the reader:
    100% true - expect people are busy, rather than hostile! :-)

    i must have come across as far more disappointed than i felt --
    i meant "hoped" in the literal sense, of "did not expect, but
    thought plausible and welcome" =]. no, this has been an A-, A
    interaction in my book--i half-expected flat rejection.

    so thanks, debian! i will return to my codehole and bring
    back something more tangible. but i found this quite promising.

    --
    nick black -=- https://www.nick-black.com
    to make an apple pie from scratch,
    you need first invent a universe.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmFTmyEACgkQX0NADCHL +synRQ/7BQU8Vc8M94UoVz5UFNDLP4C4L9HEM4iqlWQDukIfHoO+pxMUdj5sXvzw zNo+CX6HOBMAn09SRuB+TlN7S8/n6WgtvURPpQ/kBzjHzqaXlRfsqqshtuB3oyoa PVhoDbqutf+f6lpEJhuEcnVCPv9NqDV65mEjK6aPxd4hIsGffeb6vumFOY8ykzH5 hrofAfOo4uVVvnDSnL5Du4Ei7eqlExf9Rh5mytUUhtoiaB6DXz3da6yo2Bl0IGvW soCZXRn4fT/i4svvRvqLWL6vnjcEGRbq1AlTsxb7T3hYLKRNuMet7EGdCw7KMjck 7ELACLF94INn7svOzv+ghE9iu5OsdKnqB9ONOlaJspMXsMgiI6ZYfh1/hEy128NV de7N+19ItabUkC8kEWQWC+5ancBLJ8vfHIWPKLGcHWVktJRpE9TyevStu1ynjMpd Kn5iTVyPmDh7jfnmg9qyxKF9wevKP8pT3RblXEoBq2AprFPbA/gFHk5hVv9dWriY A4Bxm8lDJJr0HkqDhai9iv8x8wALYN5aPs4EZZ94q72RY9jraSe11W+TLxcJ1RRC OV8dBkzPqEOCxNyPHc9Tp86a48Lh6AdxMInfmflrhyWpTWeRUsLEpOJXpYwMTdUx Sy5l/BWuvbeJntenrVJkqscaxrwbfj1ak5CddS0Z/Cv2nOw9moQ=
    =xmF6
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet G
  • From Steve McIntyre@21:1/5 to Cyril Brulebois on Wed Sep 29 00:20:02 2021
    XPost: linux.debian.maint.boot

    Hi Nick!

    On Tue, Sep 28, 2021 at 12:47:11PM +0200, Cyril Brulebois wrote:
    Hi nick,

    [ cc += debian-boot@ ]

    nick black <dankamongmen@gmail.com> (2021-09-27):
    Marc Haber left as an exercise for the reader:
    But maybe an alternative? I find the partitioning step one of the
    most error-prone and hard-to-use parts of non-trivial Debian
    installations.

    so overall, i've got to say the feedback i heard here was a lot more
    positive than i was expecting, though there was a bit less than i had
    hoped for. but perhaps something that can be touched would see more
    interest?

    FWIW I've followed the answers to your mail over the last few days,
    but I haven't had a chance to look at either the video or the slides
    (only 4 days before your initial mail and the one I'm replying to…).

    Amen to that!

    At first glance, it seems fine to be experimenting with a different >partitioner; of course all people are somewhere on the love/hate
    spectrum regarding partman and the zillions of partman-* packages, but
    it's indeed a shell maze and it *probably* could use some heavy lifting.
    I keep hoping that simple use cases are made simple(r)… maybe growlight >could help there (e.g. “I'd like soft RAID1 with encrypted LVM, all that >with a UEFI boot — therefore ESP —, without being a storage wizard”).

    ACK. I've done a *bit* of hacking around partman over the last few
    years - it's heavy going and probably the least well understood part
    of d-i... :-/

    I suppose some step (once you've experimented on a growlight-only
    d-i) would be to have both partman and growlight, and let people
    choose (maybe with a flag at boot time, or by entering expert mode or >whatever), until we have a better idea what works, what doesn't, what
    can be fixed, what cannot, and until a decision is made for the next
    Debian stable release.

    Leaving the technical integration aside for a moment, one question
    that comes to mind is whether this would be a one-shot contribution or
    some kind of longer commitment to maintain that different partitioner.
    I seem to remember earlier attempts at revamping the partitioning
    step, which stalled eventually.

    (Your recent mail to debian-newmaint@ is a hint; your apparent
    steadiness of those packages maintenance-wise is another; and your
    apparent interest in adding support to possibly missing features yet >another.)

    Of course, one might object that the question is moot as there isn't
    much active development on partman components (even if some patches have
    been submitted over the last few days), but at least that's a known >(imperfect, but…) beast.

    Nod!

    given that no one seemed to reject the idea out of hand, i'm going to
    go ahead and rebase my work from 2012 (or more likely look at it once
    and redo it) in a Salsa fork of d-i, and make some installation media
    available. forgive me for likely only having x86 available at first.
    i'll try to have this done within a week or so, and put it up on my
    server. people can then give it a whirl.

    Feel free to touch base with debian-boot@ and/or debian-cd@ once you
    have a working proof of concept that some people have toyed with; we can >discuss how the “alternative” part could be implemented (different >images, or both partitioners ship together, with some option/selection — >people might remember GRUB vs. LILO). I cannot guarantee a timely answer >(life tends to keep me busy), but you shouldn't see a lack of answer
    after just a few days as if people were not interested.

    100% true - expect people are busy, rather than hostile! :-)

    --
    Steve McIntyre, Cambridge, UK. steve@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd
    Debian does NOT ship free CDs. Please do NOT contact the mailing
    lists asking us to send them to you.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)