Patch to add linux-libre mnt/reform variant

  • Done
  • quality assurance status badge
Details
2 participants
  • pelzflorian (Florian Pelz)
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
normal

Debbugs page

V
V
Vagrant Cascadian wrote on 17 Mar 18:21 -0700
(address . guix-patches@gnu.org)
874izrm8vc.fsf@wireframe
The attached patch adds a kernel variant for mnt/reform systems.


I have boot tested it on a MNT/Reform2 rk3588 using Guix System, though
it may also work on other MNT/Reform variants to some degree.

Worked well enough to use sway as a desktop environment and run
librewolf while compiling it's own kernel (in ~37 minutes, on one test
build)!

Working hardware:

Built-in LCD Display
Keyboard
Trackball
USB
NVMe
SD
eMMC
serial
8 CPU cores (with frequency scaling, 4@1.2-2.4GHZ & 4@1.0-1.8GHz)
32GB of ram!

Flaky hardware:

Ethernet (workarounds available, may require updated libgpiod package)

Unsupported or untested hardware:

Wifi (DEBLOBBED, though uses mPCIe, so other cards are possible)
Sound (may need workarounds, untested)
HDMI output (untested)
Battery monitoring (requires out-of-tree module, workaround is
monitoring battery status on built-in OLED display!)


It does pull in a fair number of patches; Some patches have already
landed in linux-next in some form (device-tree for MNT/Reform rk3588),
and some others are on their way upstream.


Any suggestions on a better way to implement 'appy-reform-patches ... I
struggled for days trying to figure out how to get them applied in
(source (patches ... or (source (snippet ... but ultimately implementing
as a phase was the only way I could get it to work.

Is "patch --force" really a good idea? It seems a common pattern in
other packages that manually implement a patching phase, but reading the
patch manpage suggests it might potentially ignore patches failing to
apply in some cases.


I already have some ideas how to simplify the 'copy-reform-dts-files
phase (e.g. by moving the files into the right place in
reform-debian-packages to require less fiddly bits in the phase).


The 'adjust-makefiles-with-new-dtb phase could reasonably be implemented
as a regular patch instead of a few (substitute* ... calls.


Suggestions are very much welcome, especially with my very limited guile
skills. Took me several days to figure some of these out, mostly staring
at inscrutible guile tracebacks, and persistently trying again, so bear
with me!

Thanks!

live well,
vagrant
Attachment: 0001-gnu-Add-linux-arm64-libre-mnt-reform.patch
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ9jKlwAKCRDcUY/If5cW
qrMYAQCafusuaAsiwLIqjy4kNfgNOJ6395GqwuhSIPXhpBFm7AEA08+Isa6a/tDr
C2eHGNlcuVhZBbWqHDazT/nVLA1WKAU=
=sNLF
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 18 Mar 06:20 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87ldt2wk4p.fsf@pelzflorian.de
Well; I tested linux-libre-arm64-mnt-reform on my Orange Pi 5 Plus
with Armbian’s U-Boot; as expected your kernel runs as good/bad as
linux-libre-arm64-generic there. Of course is a different machine,
but it does use RK3588.

Orange Pi still has flaky Ethernet despite patches. You described it
as flaky as well, though. Ethernet works on some boots, as before.
Maybe the patches you put in do help on the MNT Reform, though.

USB3 is still broken. I do not own a MIPI DSI phone/tablet display,
apparently laptop display for MNT Reform, which should work, I guess,
with appropriate device tree settings, which I guess your patches do
for MNT Reform. Perhaps also your kernel patches.

As far as I understand, HDMI on Orange Pi 5 Plus would require the
blob
It seems likely that the MNT Reform RK3588 uses the CPU’s HDMI for
external displays as well, maybe, don’t know.

I have not reviewed the suitability nor license of patches. Is it the
same license as that of the project to which each patch had been sent?

I have not run guix style nor lint and do not want to judge the Scheme
code style.

Regards,
Florian
V
V
Vagrant Cascadian wrote on 18 Mar 10:49 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87msdikz4h.fsf@wireframe
On 2025-03-18, pelzflorian (Florian Pelz) wrote:
Toggle quote (5 lines)
> Well; I tested linux-libre-arm64-mnt-reform on my Orange Pi 5 Plus
> with Armbian’s U-Boot; as expected your kernel runs as good/bad as
> linux-libre-arm64-generic there. Of course is a different machine,
> but it does use RK3588.

Interesting! I think all the rk3588 specific patches are actually
indirectly from collabora's work on rk3588; a quick glance at some of
the patch names makes it clear they are not actually all mnt/reform
specific. I suspect with each kernel version those patches will be
fewer.

I am most interested in the rk3588 patches, which is the largest current
patchset, but the imx8mq, imx8mp, ls1028a and meson-g12b are other
variants produced by mnt/reform, and require fewer patches to
upstream. I have no idea how many of each are out there in the wild, and
I suspect new ones are focused on rk3588, largely because it outperforms
all the others. There is also a RISC-V core option.

A comparison of all the current module options:



Toggle quote (4 lines)
> Orange Pi still has flaky Ethernet despite patches. You described it
> as flaky as well, though. Ethernet works on some boots, as before.
> Maybe the patches you put in do help on the MNT Reform, though.

The kernal patches alone are not sufficient, the workaround for
mnt/reform rk3588 requires a newer libgpiod than present in guix
currently:


Maybe that or something similar would also works on the Orange PI 5
Plus?


Toggle quote (5 lines)
> USB3 is still broken. I do not own a MIPI DSI phone/tablet display,
> apparently laptop display for MNT Reform, which should work, I guess,
> with appropriate device tree settings, which I guess your patches do
> for MNT Reform. Perhaps also your kernel patches.

Right. I hope, anyways. I have not specifically tested USB-3 devices,
but definitely USB-2 and maybe USB-1...


Toggle quote (6 lines)
> As far as I understand, HDMI on Orange Pi 5 Plus would require the
> blob
> <https://web.git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rockchip/dptx.bin>.
> It seems likely that the MNT Reform RK3588 uses the CPU’s HDMI for
> external displays as well, maybe, don’t know.

It does not mention it on the modularity page listed above (only the DDR
issues), so what I need to do is boot it and try out HDMI output with
linux-libre and not firmware installed and see... :)


Toggle quote (3 lines)
> I have not reviewed the suitability nor license of patches. Is it the
> same license as that of the project to which each patch had been sent?

Ah, good reminder, I did a sloppy job with the license field of
reform-debian-packages. Most of the patches have clearly defined
SPDX-License-Identifier fields:

+ ;; FSFAP GPL-2.0 GPL-2.0+ GPL-2.0-only (GPL-2.0-only OR BSD-2-Clause)
+ ;; GPL-2.0-only OR BSD-2-Clause (GPL-2.0 OR BSD-2-Clause) GPL-2.0-or-later
+ ;; GPL-2.0 or MIT (GPL-2.0+ OR MIT) (GPL-3.0 OR BSD-2-Clause) MIT

Obviously all the GPL-2 and GPL-3 permutations are good, and the others
look good to my eye as well:



Toggle quote (2 lines)
> I have not run guix style nor lint

Oh, but I probably should try those... good reminder!


Toggle quote (2 lines)
> and do not want to judge the Scheme code style.

I am begging for a little bit of judgement here, but if you are not game
at the moment hopefully someone else can. :)


Thanks for taking the kernel for a spin and leaving some good comments!


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ9myLwAKCRDcUY/If5cW
qie6AP4taCWn/1hv3fEtslxTbhuCVDV5e9ctIvi+en59mp/YxwEAvvpn0KOG9l7E
U9eguTbaPfYdQa4LFDnDSRx129CFGwY=
=3W9b
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 18 Mar 16:21 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
875xk6kjrb.fsf@wireframe
On 2025-03-18, Vagrant Cascadian wrote:
Toggle quote (11 lines)
> On 2025-03-18, pelzflorian (Florian Pelz) wrote:
>> As far as I understand, HDMI on Orange Pi 5 Plus would require the
>> blob
>> <https://web.git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rockchip/dptx.bin>.
>> It seems likely that the MNT Reform RK3588 uses the CPU’s HDMI for
>> external displays as well, maybe, don’t know.
>
> It does not mention it on the modularity page listed above (only the DDR
> issues), so what I need to do is boot it and try out HDMI output with
> linux-libre and not firmware installed and see... :)

Confirmed that at least basic HDMI output on the MNT/Reform rk3588 works
without binary blobs; it shows on both screens at boot and sway detects
the 2nd display and sets it up without me having to do anything.

Maybe there is some optional functionality (DRM anti-features?) that is
missing without the blob?

live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ9n/+AAKCRDcUY/If5cW
qjUaAP9pYILGccZzXuLXaqNspO9ZKxk88VjtrHsGvabKoixZLAEAuBMrcfu1A8Wi
/30f64tSVcaDWAloqesqKzk8WdLy8wI=
=aK/c
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 19 Mar 03:55 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87msdhjnlv.fsf@pelzflorian.de
Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (7 lines)
> The attached patch adds a kernel variant for mnt/reform systems.
>
> https://mntre.com/reform.html
>
> I have boot tested it on a MNT/Reform2 rk3588 using Guix System, though
> it may also work on other MNT/Reform variants to some degree.

Oops, only now have I understood the MNT/Reform modularity means there
can be many “processor modules” and you made this
linux-arm64-libre-mnt-reform to support them all.

Could you make this clear in a package synopsis, description?

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 19 Mar 04:05 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87iko5jn64.fsf@pelzflorian.de
Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (4 lines)
> Confirmed that at least basic HDMI output on the MNT/Reform rk3588 works
> without binary blobs; it shows on both screens at boot and sway detects
> the 2nd display and sets it up without me having to do anything.

Wow, yes, it seems to me your working HDMI of MNT/Reform rk3588 really
is the RK3588’s HDMI. Wrongly did I think RK3588’s HDMI worked only
through Synopsys DesignWare DPTX controller blob. Apparently not;
apparently HDMI could be made to work on my Orange Pi somehow, too, if I
tried harder.

Thanks for correcting my view.

Regards,
Florian
V
V
Vagrant Cascadian wrote on 19 Mar 13:40 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87y0x0kb3y.fsf@wireframe
On 2025-03-19, pelzflorian (Florian Pelz) wrote:
Toggle quote (14 lines)
> Vagrant Cascadian <vagrant@debian.org> writes:
>> The attached patch adds a kernel variant for mnt/reform systems.
>>
>> https://mntre.com/reform.html
>>
>> I have boot tested it on a MNT/Reform2 rk3588 using Guix System, though
>> it may also work on other MNT/Reform variants to some degree.
>
> Oops, only now have I understood the MNT/Reform modularity means there
> can be many “processor modules” and you made this
> linux-arm64-libre-mnt-reform to support them all.
>
> Could you make this clear in a package synopsis, description?

Thanks for the suggestion!

I implemented a bare minimal description/synopsis update, but on
re-reading what you suggested again it could probably be elaborated on
to more explicitly mention the variants with different CPU modules...

Attached is a v2 of the patch that includes some of those suggestions
and other improvements.

Summary of changes since v0:

reform-debian-packages:
* apply guix style
* drop useless commented out #:tests?
* clean up comments around licenses
* install .dts files in vendor-specific directories

linux-libre-arm64-mnt-reform:
* apply guix style (except keep #true instead of #t, seriously!)
* do not use --force when applying patches
* simplify 'copy-reform-dts-files phase
* extend description and synopsis to mention mnt/reform systems

live well,
vagrant
Attachment: v2-0001-gnu-Add-linux-libre-arm64-mnt-reform.patch
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ9srwQAKCRDcUY/If5cW
ql6QAQCXTN4juXGjtH+o4ABFLSaEXYVFgrLl68UazUbZHIpfdAD7BQIiNR4If4A7
k7e8r+GkCZK/hykbeqX08ZT2+/lzBAg=
=DUlG
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 22 Mar 11:01 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87sen5x7v2.fsf@pelzflorian.de
Thank you Vagrant for this work.

Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (2 lines)
> + (version "278f964619e597bf0b3aae67fef52bb541bc89e6")

This is a bad version; newer versions are not increasing.

The commit 278f964619e597bf0b3aae67fef52bb541bc89e6 you use for
reform-debian-packages is no longer the most recent commit. Which commit
should we use?

We may need to remove the reprepro.sh (see end of this e-mail),

Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (8 lines)
> + (license (list
> + ;; FIXME license:mit
> + ;; FIXME license:FSFAP
> + license:bsd-2
> + license:gpl2
> + license:gpl2+
> + license:gpl3))))

Likely should be
(list license:gpl2
license:gpl2+
license:gpl3+
license:x11
license:expat
license:fsf-free)

I do not know where in your list, license:bsd-2 comes from. Possibly
license:bsd-2 is correct for some file, too?

is license:gpl2, because bmaptools is and it is from a pull request to it.

ffmpeg is license:gpl2+

is not copyright-worthy, but anyway
flash-kernel script is license:gpl2+

Mesa has license:x11.
License:x11 is the MIT license.

(define x11
(license "X11"


which is license:gpl3+

appears to be license:gpl2 or license:gpl2+

is # SPDX-License-Identifier: MIT
is license:expat

is # SPDX-License-Identifier: FSFAP
guix/import/utils.scm maps with %spdx-license-identifiers this way:
("FSFAP" . license:fsf-free)

has no license :(
Remove it in an origin snippet?
Though you also do not use this tiny script.

I have not looked at the linux patches, but likely gpl2 or another
of the above GPL versions.

Regards,
Florian
V
V
Vagrant Cascadian wrote on 22 Mar 11:58 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87ecyoki3s.fsf@wireframe
On 2025-03-22, pelzflorian (Florian Pelz) wrote:
Toggle quote (2 lines)
> Thank you Vagrant for this work.

And thanks for the review! :)


Toggle quote (5 lines)
> Vagrant Cascadian <vagrant@debian.org> writes:
>> + (version "278f964619e597bf0b3aae67fef52bb541bc89e6")
>
> This is a bad version; newer versions are not increasing.

Yeah, I wondered about this... did not think it mattered too much
because it just ships some patch files used as an input; it is not a
package someone is likely to include in a profile where the version
would matter. Might be a case for using (define ... instead of
(define-public ... of course I can make up a more meaningful
git-commit-hash derived version if we absolutely must... :)


Toggle quote (4 lines)
> The commit 278f964619e597bf0b3aae67fef52bb541bc89e6 you use for
> reform-debian-packages is no longer the most recent commit. Which commit
> should we use?

Current head is probably also fine (seems to have one new or updated
patch to the relevent kernel patches which might require adjusting patch
phase), but that was the commit I tested so far.


Toggle quote (17 lines)
> Vagrant Cascadian <vagrant@debian.org> writes:
>> + (license (list
>> + ;; FIXME license:mit
>> + ;; FIXME license:FSFAP
>> + license:bsd-2
>> + license:gpl2
>> + license:gpl2+
>> + license:gpl3))))
>
> Likely should be
> (list license:gpl2
> license:gpl2+
> license:gpl3+
> license:x11
> license:expat
> license:fsf-free)

Sounds plausible to me. :)

FWIW, I am also fine with dropping anything outside of linux/ in a
snippet, if it makes the licensing simpler, as we really use none of
the other files.


Toggle quote (3 lines)
> I do not know where in your list, license:bsd-2 comes from. Possibly
> license:bsd-2 is correct for some file, too?

Most .dts related files in linux are dual-licensed under GPL and one of
various permissive licenses ... (e.g. GPL-2* OR BSD|MIT|X11).

$ git grep SPDX linux/patches6.12/ | grep BSD
linux/patches6.12/imx8mq-mnt-reform2/v19_20241126_sandor_yu_initial_support_cadence_mhdp8501_hdmi_dp_for_i_mx8mq.mbx:+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
linux/patches6.12/imx8mq-mnt-reform2/v19_20241126_sandor_yu_initial_support_cadence_mhdp8501_hdmi_dp_for_i_mx8mq.mbx:+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
linux/patches6.12/rk3588-mnt-reform2/0036-dt-bindings-display-bridge-Add-schema-for-Synopsys-D.patch:+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
linux/patches6.12/rk3588-mnt-reform2/0037-dt-bindings-display-rockchip-Add-schema-for-RK3588-H.patch:+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
linux/patches6.12/rk3588-mnt-reform2/0042-dt-bindings-media-Document-bindings-for-HDMI-RX-Cont.patch:+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
linux/patches6.12/rk3588-mnt-reform2/3001-display-rockchip-add-schema-for-rk3588-hdmi-tx.patch:+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
linux/patches6.12/rk3588-mnt-reform2/5001-rk3588-dsi2-driver.patch:+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)


Toggle quote (13 lines)
> Mesa has license:x11.
> License:x11 is the MIT license.
>
> (define x11
> (license "X11"
> "http://directory.fsf.org/wiki/License:X11"
> "https://www.gnu.org/licenses/license-list#X11License"))
>
> <https://directory.fsf.org/wiki/License:X11>
> is the same as the license header
> <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/lib/pan_layout.c

That's good to know. I am a little less familiar with GNU licensing
conventions, mostly coming from Debian, while not totally different,
have some different conventional takes.


Toggle quote (8 lines)
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/common.sh?ref_type=heads
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/setup.sh?ref_type=heads
> is # SPDX-License-Identifier: MIT
> is <https://spdx.org/licenses/MIT.html>
> is <https://directory.fsf.org/wiki/License:Expat>
> is license:expat

Also useful, thanks!


Toggle quote (5 lines)
> is # SPDX-License-Identifier: FSFAP
> guix/import/utils.scm maps with %spdx-license-identifiers this way:
> ("FSFAP" . license:fsf-free)

Great!


Toggle quote (5 lines)
> has no license :(
> Remove it in an origin snippet?
> Though you also do not use this tiny script.

I can probably get upstream to fix that, but we also do not need it at
all.


Toggle quote (3 lines)
> I have not looked at the linux patches, but likely gpl2 or another
> of the above GPL versions.

I focused on linux/patches6.12 mainly, as those were the ones I am
actually using, and other than the device-tree patches that are
dual-licensed, likely all the rest should be gpl2 or gpl2+.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ98IVwAKCRDcUY/If5cW
qh3KAPwK34PtVPV1pL7A51ml6nmNHLTxpD7VwKnDf3aDcn3seAD8D+yp4UVdR0dR
BM8kP8ns4SlpcBtAV4ZeMZBHrN3qdQ0=
=kzt9
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 22 Mar 16:33 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
878qowk5cs.fsf@wireframe
On 2025-03-22, Vagrant Cascadian wrote:
Toggle quote (13 lines)
> On 2025-03-22, pelzflorian (Florian Pelz) wrote:
>> Vagrant Cascadian <vagrant@debian.org> writes:
>>> + (version "278f964619e597bf0b3aae67fef52bb541bc89e6")
>>
>> This is a bad version; newer versions are not increasing.
>
> Yeah, I wondered about this... did not think it mattered too much
> because it just ships some patch files used as an input; it is not a
> package someone is likely to include in a profile where the version
> would matter. Might be a case for using (define ... instead of
> (define-public ... of course I can make up a more meaningful
> git-commit-hash derived version if we absolutely must... :)

Used a version based on the output from git describe.


Toggle quote (8 lines)
>> The commit 278f964619e597bf0b3aae67fef52bb541bc89e6 you use for
>> reform-debian-packages is no longer the most recent commit. Which commit
>> should we use?
>
> Current head is probably also fine (seems to have one new or updated
> patch to the relevent kernel patches which might require adjusting patch
> phase), but that was the commit I tested so far.

Updated to the latest commit, which updated one of the patches (but did
not change names, so no further updates needed in the packaging.


Toggle quote (19 lines)
>> Vagrant Cascadian <vagrant@debian.org> writes:
>>> + (license (list
>>> + ;; FIXME license:mit
>>> + ;; FIXME license:FSFAP
>>> + license:bsd-2
>>> + license:gpl2
>>> + license:gpl2+
>>> + license:gpl3))))
>>
>> Likely should be
>> (list license:gpl2
>> license:gpl2+
>> license:gpl3+
>> license:x11
>> license:expat
>> license:fsf-free)
>
> Sounds plausible to me. :)

I incorporated all these; they seem consistent with my observations,
although fsf-free required arguments.


Toggle quote (8 lines)
>> has no license :(
>> Remove it in an origin snippet?
>> Though you also do not use this tiny script.
>
> I can probably get upstream to fix that, but we also do not need it at
> all.

Working on submitting the issue upstream...

Changes since v2:

reform-debian-packages:
* Update to 2023-07-10-318-g85274b8.
* Update license field.

linux-libre-arm64-mnt-reform:
* Add ATH9K wireless to configuration.

live well,
vagrant
Attachment: v3-0001-gnu-Add-linux-libre-arm64-mnt-reform.patch
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ99I4wAKCRDcUY/If5cW
qgGJAQC8IdquZQccSJnLsy0JZdYsypirwx5KZPoj7MlJxHLU9gD8D2xRD5WPaCgD
jgWR+2ayOM3Iwl9j4sTuTXfAbNDbgAc=
=wn13
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 23 Mar 09:02 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87zfhbu456.fsf@pelzflorian.de
Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (2 lines)
> Working on submitting the issue upstream...

Thank you; if you include this license header you made upstream include
(commit
it LGTM. Please push. Although I cannot judge your style of
customizing linux-libre and configuration, but style could be altered
later.

I also have not tested the new v3 kernel, because I have no MNT Reform
and its devicetree, kernel features do nothing for my Orange Pi anyway.
Though its patches might serve as inspiration for fixing devicetree.

Further:

Toggle quote (5 lines)
> + (license:fsf-free "file://filter-output" "# SPDX-License-Identifier: FSFAP
> +# Copying and distribution of this file, with or without modification, are
> +# permitted in any medium without royalty provided the copyright notice and
> +# this notice are preserved. This file is offered as-is, without any warranty.")

When I git grep for license:fsf-free, others do not include the license
in a comment. But I do not know more.

Toggle quote (2 lines)
> + license:bsd-2

Good!

Regards,
Florian
V
V
Vagrant Cascadian wrote on 23 Mar 09:48 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
871punk810.fsf@wireframe
On 2025-03-23, pelzflorian (Florian Pelz) wrote:
Toggle quote (8 lines)
> Vagrant Cascadian <vagrant@debian.org> writes:
>> Working on submitting the issue upstream...
>
> Thank you; if you include this license header you made upstream include
> (commit
> <https://source.mnt.re/reform/reform-debian-packages/-/commit/af0a461d38e13481323f061d9ff6827d1d13873b>),
> it LGTM. Please push.

Will in the new upstream version that includes the licensing
clarification, for, well... clarity!

If I understood correctly, you suggested to have
SPDX-License-Identifier: MIT be be represented as license:x11, so that
should already be present in the license field.


Toggle quote (4 lines)
> Although I cannot judge your style of
> customizing linux-libre and configuration, but style could be altered
> later.

Fair!


Toggle quote (4 lines)
> I also have not tested the new v3 kernel, because I have no MNT Reform
> and its devicetree, kernel features do nothing for my Orange Pi anyway.
> Though its patches might serve as inspiration for fixing devicetree.

Understood! I have tested it on at least the MNT/Reform rk3588, and this
should make it easier for others to attempt on other MNT/Reform
platforms, which it is always easier to provide small patches than test
the whole thing.


Toggle quote (10 lines)
> Further:
>
>> + (license:fsf-free "file://filter-output" "# SPDX-License-Identifier: FSFAP
>> +# Copying and distribution of this file, with or without modification, are
>> +# permitted in any medium without royalty provided the copyright notice and
>> +# this notice are preserved. This file is offered as-is, without any warranty.")
>
> When I git grep for license:fsf-free, others do not include the license
> in a comment. But I do not know more.

I included the reasonably short "full" text in the comment just to be
clear. It looks like this license comes from gnu.org:


And is documented at spdx.org as the "FSF All Permissive License":


Maybe including a link to the gnu.org URL (and/or spdx.org) in the
comment would still be very clear, without triggering the overly long
comment feeling. :)

I think I will include the gnu.org link. We can always improve upon it
later if needed.

Seems like file://filter-output needs to stay, as that includes the
reference to the actual source where the license is declared.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ+A7WwAKCRDcUY/If5cW
qtV+AQCXOA+l6EA5RjCF+XArMKDRGPi/cBvDa7LSITCsvtwG4QD+K2eyovpwu6zb
eGgCSRb2mekpUrqCjlJMBuXgHbEqGAA=
=wQCN
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 23 Mar 10:26 -0700
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87v7rziroc.fsf@wireframe
On 2025-03-23, Vagrant Cascadian wrote:
Toggle quote (6 lines)
> On 2025-03-23, pelzflorian (Florian Pelz) wrote:
>> Thank you; if you include this license header you made upstream include
>> (commit
>> <https://source.mnt.re/reform/reform-debian-packages/-/commit/af0a461d38e13481323f061d9ff6827d1d13873b>),
>> it LGTM. Please push.

Done.

Pushed as 490b4e190a6589ff18f7ba76b4d9302697c113d6 gnu: Add
linux-libre-arm64-mnt-reform.

live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZ+BEZAAKCRDcUY/If5cW
qiEDAP4vjYF7JJ85XtBsbEtZ0rCwgmtsSL1zTM+f7xRShphoRQD9Gn0Ub//sf+IU
Otb8NW/0LrTXBRDErASGDe2NkBXjMAs=
=5ZHa
-----END PGP SIGNATURE-----

Closed
P
P
pelzflorian (Florian Pelz) wrote on 23 Mar 16:27 -0700
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87sen3pbt9.fsf@pelzflorian.de
pelzflorian writes:
Toggle quote (12 lines)
> Mesa has license:x11.
> License:x11 is the MIT license.
> […]
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/build_custom.sh?ref_type=heads
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/common.sh?ref_type=heads
> https://source.mnt.re/reform/reform-debian-packages/-/blob/main/setup.sh?ref_type=heads
> is # SPDX-License-Identifier: MIT
> is <https://spdx.org/licenses/MIT.html>
> is <https://directory.fsf.org/wiki/License:Expat>
> is license:expat

Vagrant Cascadian <vagrant@debian.org> writes:
Toggle quote (4 lines)
> If I understood correctly, you suggested to have
> SPDX-License-Identifier: MIT be be represented as license:x11, so that
> should already be present in the license field.

license:x11 is for panfrost; license:expat is SPDX-License-Identifier:
MIT. Anyway, both are present!

Toggle quote (3 lines)
> (license:fsf-free "file://filter-output"
> "https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html")

Looks good.

Thanks for packaging! It will help the MNT reform users.

Regards,
Florian
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 77090@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 77090
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch