[Buildroot] [PATCH 1/2] package/skeleton-init-openrc: prepare runlevels from make over skeleton

[Buildroot] [PATCH 1/2] package/skeleton-init-openrc: prepare runlevels from make over skeleton

[James Knight via buildroot]

The following commit changes the creation of an OpenRC environment's
`/etc/runlevels/default/sysv-rcs` symbolic link from the skeleton to
inside the package's Makefile (triggered from the
`SKELETON_INIT_OPENRC_INSTALL_TARGET_CMDS` call). The original symlink
to a `/etc/init.d/sysv-rcs` path may not gracefully work for all
developer environments. For example, on a fresh checkout in a Windows
environment, the symbolic link may be automatically updated to
include a drive specification. For example:

    $ git diff
    diff --git a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs b/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
    index ef5e00823c..e417b4bb44 120000
    --- a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
    +++ b/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
    @@ -1 +1 @@
    -/etc/init.d/sysv-rcs
    \ No newline at end of file
    +G:/etc/init.d/sysv-rcs
    \ No newline at end of file

If a developer built with fresh checkout using an example
`qemu_x86_defconfig` tailored to target an OpenRC init system, an
improper symlink can be observed in the target system:

    ...
    Welcome to Buildroot
    buildroot login: root
    Jun 22 20:42:34 login[971]: root login on 'console'
    # /etc/runlevels/default/sysv-rcs  --version
    -sh: /etc/runlevels/default/sysv-rcs: not found
    # readlink /etc/runlevels/default/sysv-rcs
    /??/G:/etc/init.d/sysv-rcs
    #  /etc/init.d/sysv-rcs --version
    sysv-rcs (OpenRC) 0.43.3 (Buildroot 2022.05-225-g64390b6c42-dirty)

By switching from having the symbolic link in the skeleton file to
building it during the package's install stage, this (1) prevents
oddities with a Git working environment on environments like Windows,
as well as (2) ensures a proper symlink is created in a Windows
environment. For example:

    # readlink /etc/runlevels/default/sysv-rcs
    /etc/init.d/sysv-rcs
    # /etc/runlevels/default/sysv-rcs --version
    sysv-rcs (OpenRC) 0.43.3 (Buildroot 2022.05-225-g64390b6c42-dirty)

Signed-off-by: James Knight <james.knight@collins.com>
---
 package/skeleton-init-openrc/skeleton-init-openrc.mk             | 1 +
 .../skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 120000 package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs

diff --git a/package/skeleton-init-openrc/skeleton-init-openrc.mk b/package/skeleton-init-openrc/skeleton-init-openrc.mk
index b0538ad03ff6203cbe24ebc2e2e4bd2a5af4bed9..625c5d8a8ea0476f9574da9718083c3de69a3c1f 100644
--- a/package/skeleton-init-openrc/skeleton-init-openrc.mk
+++ b/package/skeleton-init-openrc/skeleton-init-openrc.mk
@@ -32,6 +32,7 @@ endif # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
 define SKELETON_INIT_OPENRC_INSTALL_TARGET_CMDS
 	$(call SYSTEM_RSYNC,$(SKELETON_INIT_OPENRC_PKGDIR)/skeleton,$(TARGET_DIR))
 	$(SKELETON_INIT_OPENRC_ROOT_RO_OR_RW)
+	ln -s /etc/init.d/sysv-rcs $(TARGET_DIR)/etc/runlevels/default/sysv-rcs
 endef
 
 $(eval $(generic-package))
diff --git a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs b/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
deleted file mode 120000
index ef5e00823c63ed0244be26e6082e17d8e135f5ea..0000000000000000000000000000000000000000
--- a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
+++ /dev/null
@@ -1 +0,0 @@
-/etc/init.d/sysv-rcs
\ No newline at end of file
-- 
2.30.0.windows.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] .gitattributes: default lf line endings for text files

[James Knight via buildroot]

Default the line endings for text files to be LF. The building of a
Buildroot project is most likely always invoked from an environment
using LF line endings. For developers working with various environments
(e.g. Linux and Windows), defaulting to LF can help improve a
developer's user experience. For example, with a clean checkout on a
Windows environment, a developer can trigger a configure and build with
two commands in their desired VM/container, without having to worry
about configuring `core.autocrlf`:

    make O=~/buildtest qemu_x86_defconfig
    make O=~/buildtest

Signed-off-by: James Knight <james.knight@collins.com>
---
 .gitattributes | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000000000000000000000000000000000000..74dcc97d294192e61f4b241dbf4aa10449de5626
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+# default lf for text files to help with cross platform development
+* text=auto eol=lf
-- 
2.30.0.windows.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] .gitattributes: default lf line endings for text files

[James Hilliard]

On Wed, Jun 22, 2022 at 4:09 PM James Knight via buildroot
<buildroot@buildroot.org> wrote:
>
> Default the line endings for text files to be LF. The building of a
> Buildroot project is most likely always invoked from an environment
> using LF line endings. For developers working with various environments
> (e.g. Linux and Windows), defaulting to LF can help improve a
> developer's user experience. For example, with a clean checkout on a
> Windows environment, a developer can trigger a configure and build with
> two commands in their desired VM/container, without having to worry
> about configuring `core.autocrlf`:

Been a while since I've tried sharing a Linux cross compile env with windows
but I recall things tended to break horribly due to filesystem case sensitivity
issues on Windows based hosts.

I'm curious if that's an issue you've run across with these hybrid setups.

>
>     make O=~/buildtest qemu_x86_defconfig
>     make O=~/buildtest
>
> Signed-off-by: James Knight <james.knight@collins.com>
> ---
>  .gitattributes | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 .gitattributes
>
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000000000000000000000000000000000000..74dcc97d294192e61f4b241dbf4aa10449de5626
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,2 @@
> +# default lf for text files to help with cross platform development
> +* text=auto eol=lf
> --
> 2.30.0.windows.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [External] Re: [PATCH 2/2] .gitattributes: default lf line endings for text files

[Knight, James D - Collins via buildroot]

James,

> -----Original Message-----
> From: James Hilliard <james.hilliard1@gmail.com>
> Sent: Thursday, June 23, 2022 1:52 AM
> 
> Been a while since I've tried sharing a Linux cross compile env with windows
> but I recall things tended to break horribly due to filesystem case sensitivity
> issues on Windows based hosts.
> 
> I'm curious if that's an issue you've run across with these hybrid setups.

For sure there are issues for some things, especially when trying to manage the Linux kernel in a Windows environment. Typically, when trying to manage some Linux sources in a Windows environments, I utilize sparse checkouts to work in some areas of interest which do not have case sensitivity issues. I have yet to try Window's recent case sensitive file system option.

With respect to Buildroot, typically "real" builds I perform are solely done in a Linux environment. For misc. development, I've had success managing Buildroot (and other) sources from a Windows environment, and configuring Buildroot to output ("O=") on a ext-configured disk/partition without any major issues.

Although, it has been awhile since I have had the time to work with a newer version of Buildroot, so I don't know if there is any other new concerns. The use of symbolic links within Buildroot appear to be working for the most part (with a supported Git/Windows configuration); aside from one issue that can be with a proposed patch to "skeleton-init-openrc". While the proposed change to `.gitattributes` can make my own life easier, it is not a show-stopper. I don't mind sync.-ing two Git working directories off a Git repository in these mixed environments. The related change for "skeleton-init-openrc" is more key, since I'd rather not have to deal with sparse checkouts when maintaining/cherry-picking patches for Buildroot repositories when sometimes operating from in a Windows environment.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/2] .gitattributes: default lf line endings for text files

[Arnout Vandecappelle]

  Hi James,

On 22/06/2022 23:20, James Knight via buildroot wrote:
> Default the line endings for text files to be LF. The building of a
> Buildroot project is most likely always invoked from an environment
> using LF line endings. For developers working with various environments
> (e.g. Linux and Windows), defaulting to LF can help improve a
> developer's user experience. For example, with a clean checkout on a
> Windows environment, a developer can trigger a configure and build with
> two commands in their desired VM/container, without having to worry
> about configuring `core.autocrlf`:
> 
>      make O=~/buildtest qemu_x86_defconfig
>      make O=~/buildtest
> 
> Signed-off-by: James Knight <james.knight@collins.com>
> ---
>   .gitattributes | 2 ++
>   1 file changed, 2 insertions(+)
>   create mode 100644 .gitattributes
> 
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000000000000000000000000000000000000..74dcc97d294192e61f4b241dbf4aa10449de5626
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,2 @@
> +# default lf for text files to help with cross platform development
> +* text=auto eol=lf

  We do have a few patches in-tree which have windows line endings (because the 
source has those line endings). For example
boot/edk2/0001-MdeModulePkg-UsbBusDxe-fix-NOOPT-build-error.patch

- Will these still have proper line endings when you clone?

- When you add such a patch, is it complicated to make sure they have correct 
line endings?

  Regards,
  Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/skeleton-init-openrc: prepare runlevels from make over skeleton

[Thomas Petazzoni via buildroot]

Hello James,

On Wed, 22 Jun 2022 17:20:44 -0400
James Knight via buildroot <buildroot@buildroot.org> wrote:

> The following commit changes the creation of an OpenRC environment's
> `/etc/runlevels/default/sysv-rcs` symbolic link from the skeleton to
> inside the package's Makefile (triggered from the
> `SKELETON_INIT_OPENRC_INSTALL_TARGET_CMDS` call). The original symlink
> to a `/etc/init.d/sysv-rcs` path may not gracefully work for all
> developer environments. For example, on a fresh checkout in a Windows
> environment, the symbolic link may be automatically updated to
> include a drive specification. For example:
> 
>     $ git diff
>     diff --git a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs b/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
>     index ef5e00823c..e417b4bb44 120000
>     --- a/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
>     +++ b/package/skeleton-init-openrc/skeleton/etc/runlevels/default/sysv-rcs
>     @@ -1 +1 @@
>     -/etc/init.d/sysv-rcs
>     \ No newline at end of file
>     +G:/etc/init.d/sysv-rcs
>     \ No newline at end of file
> 
> If a developer built with fresh checkout using an example
> `qemu_x86_defconfig` tailored to target an OpenRC init system, an
> improper symlink can be observed in the target system:
> 
>     ...
>     Welcome to Buildroot
>     buildroot login: root
>     Jun 22 20:42:34 login[971]: root login on 'console'
>     # /etc/runlevels/default/sysv-rcs  --version
>     -sh: /etc/runlevels/default/sysv-rcs: not found
>     # readlink /etc/runlevels/default/sysv-rcs
>     /??/G:/etc/init.d/sysv-rcs
>     #  /etc/init.d/sysv-rcs --version
>     sysv-rcs (OpenRC) 0.43.3 (Buildroot 2022.05-225-g64390b6c42-dirty)
> 
> By switching from having the symbolic link in the skeleton file to
> building it during the package's install stage, this (1) prevents
> oddities with a Git working environment on environments like Windows,
> as well as (2) ensures a proper symlink is created in a Windows
> environment. For example:
> 
>     # readlink /etc/runlevels/default/sysv-rcs
>     /etc/init.d/sysv-rcs
>     # /etc/runlevels/default/sysv-rcs --version
>     sysv-rcs (OpenRC) 0.43.3 (Buildroot 2022.05-225-g64390b6c42-dirty)
> 
> Signed-off-by: James Knight <james.knight@collins.com>

Thanks for the patch, but the proposed solution is not really
desirable, and in fact is probably not the full explanation. Indeed,
the OpenRC skeleton in package/skeleton-init-openrc/skeleton/ has
plenty of other symlinks, and you didn't complain about them.

However, one key difference between the symlinks in
package/skeleton-init-openrc/skeleton/ and the sysv-rcs symlink your
patch is fixing is that the former symlinks have a relative path to the
target, while the latter have a relative path to the target.

Could you try instead to change this symlink to use a relative path to
its target?

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot