Embedded Linux: It's Linux, but somehow worse

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Embedded Linux: It's Linux, but somehow worse

«‹›11 »

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Congrats! Also this is a good demonstration of why selinux is bad

nah. If I had labeled the files and binaries normal things like bin_exec_t then the lines changed would be a few hundred long at most. SELinux is good OP. Sorry for the brainworms.

# ? Dec 15, 2021 17:27

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 06:27

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

anyone who thinks selinux is bad shouldn't be administrating a linux system

# ? Dec 15, 2021 18:28

hobbesmaster: Jan 28, 2008

selinux does have strong "black and white part of a made for tv ad" vibes

# ? Dec 15, 2021 18:35

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

hobbesmaster posted:

selinux does have strong "black and white part of a made for tv ad" vibes

"there's got to be a better way!!"

# ? Dec 15, 2021 18:41

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

what about SMACK or AppArmor, anybody tried those out?

# ? Dec 15, 2021 18:44

Cybernetic Vermin: Apr 18, 2005

maybe use all the things at once in an entirely random amalgamation without properly delineated responsibility?

# ? Dec 15, 2021 18:48

hobbesmaster: Jan 28, 2008

Poopernickel posted:

"there's got to be a better way!!"

looks at "better way"

huh, guess not

# ? Dec 15, 2021 18:53

FlapYoJacks: Feb 12, 2009

CRIP EATIN BREAD posted:

anyone who thinks selinux is bad shouldn't be administrating a linux system

# ? Dec 15, 2021 19:06

Best Bi Geek Squid: Mar 25, 2016

CRIP EATIN BREAD posted:

anyone who thinks shouldn't be administrating a linux system

# ? Dec 15, 2021 20:03

Shaggar: Apr 26, 2006

Best Bi Geek Squid posted:

# ? Dec 15, 2021 20:49

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

Best Bi Geek Squid posted:

# ? Dec 18, 2021 16:31

sb hermit: Dec 13, 2016

selinux is cool and good, in my opinion.

# ? Dec 19, 2021 15:07

FlapYoJacks: Feb 12, 2009

sb hermit posted:

selinux is cool and good, in my opinion.

# ? Dec 19, 2021 16:01

Progressive JPEG: Feb 19, 2003

selinux

selinux run

run selinux run

# ? Dec 20, 2021 03:52

The_Franz: Aug 8, 2003

Progressive JPEG posted:

selinux

selinux run

run selinux run

set

setenforce

setenforce 1

# ? Dec 20, 2021 03:57

FlapYoJacks: Feb 12, 2009

I just spent a good 12 hours figuring out how to solve qt submodules not building in Buildroot when parallel package building is enabled.

The fix is very easy, and I learned that qmake is very bad and hardcodes paths in .pc, .cmake, and .pri files. :suicide:

The problem:

- qt5base-5.15.2 is built in output/per-package/qt5base
- qt5svg (for example) requires qt5base
- Buildroot calls rsync on output/per-package/qt5base/host -> output/per-package/qt5svg/host
- qt5svg now has a bunch of config .pc files that point to output/per-package/qt5base/ instead of output/per-package/qt5svg.

Solution:

Makefile code:

# When per-package is enabled, packages may generate files with absolute paths
# that point to the given sysroot. However, after the rsync step for another
# package that uses those files, per-package isolation is broken because the
# hard-coded paths point to directories outside the per-package sysroot.
# As a pre-configure step, sed all .cmake, .pc, and .pri files in a given
# package sysroot containing the word "per-package" and replace the line with
# the appropriate per-package directory.
ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
define FIXUP_CONFIG_FILES_ABSOLUTE_PATHS
	$(Q)find $(HOST_DIR)/ -name "*.pc" -o -name "*.cmake" -o -name "*.pri" \
		| xargs --no-run-if-empty \
		$(SED) "s:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$(NAME)/:g"
endef
endif
$(2)_PRE_CONFIGURE_HOOKS += FIXUP_CONFIG_FILES_ABSOLUTE_PATHS

A simple sed callout before the packages are configured.

FlapYoJacks fucked around with this message at 19:09 on Jan 4, 2022

# ? Jan 4, 2022 19:05

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

is per-package reliable in general yet? also how does it it construct each package's build environment? cp everything, or something more slick?

# ? Jan 4, 2022 19:57

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

is per-package reliable in general yet? also how does it it construct each package's build environment? cp everything, or something more slick?

It's quite reliable! The only issue I have ran into was the above qmake funk which seems to be fixed!

Instead of cp, Buildroot calls rsync -a --link-dest= on each dependent package.

# ? Jan 4, 2022 20:22

FlapYoJacks: Feb 12, 2009

I have been working with a few friends over the last week to finally get rid of Python2 from Buildroot. We just have a few packages left to migrate over to Python 3! QT5webengine is the largest pain in the rear end though. Embedding Chromium into a package is a gigantic pile of what the gently caress. :gonk:

# ? Jan 6, 2022 04:52

outhole surfer: Mar 18, 2003

DoomTrainPhD posted:

- Having more than one config means nothing to Buildroot, and both are built independently of each other, so no host-tool sharing.

I see you have not experienced the glory that is make sdk combined with an external tool chain.

Split your toolchain config off into something like sdk_defconfig:

code:

BR2_x86_64=y
BR2_REPRODUCIBLE=y
BR2_TOOLCHAIN_BUILDROOT_VENDOR="brc"
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_BINUTILS_VERSION_2_32_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y

build it with make sdk

then reference the created artifact like this:

code:

BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="https://blah.com/your-sdk.tgz"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_REDIS=y

# ? Jan 12, 2022 03:07

FlapYoJacks: Feb 12, 2009

nudgenudgetilt posted:

I see you have not experienced the glory that is make sdk combined with an external tool chain.

Split your toolchain config off into something like sdk_defconfig:
code:
BR2_x86_64=y
BR2_REPRODUCIBLE=y
BR2_TOOLCHAIN_BUILDROOT_VENDOR="brc"
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_BINUTILS_VERSION_2_32_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
build it with make sdk

then reference the created artifact like this:
code:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="https://blah.com/your-sdk.tgz"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_REDIS=y

Oh, I meant host package sharing :P

# ? Jan 13, 2022 01:46

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

DoomTrainPhD posted:

I just spent a good 12 hours figuring out how to solve qt submodules not building in Buildroot when parallel package building is enabled.

The fix is very easy, and I learned that qmake is very bad and hardcodes paths in .pc, .cmake, and .pri files.

The problem:

- qt5base-5.15.2 is built in output/per-package/qt5base
- qt5svg (for example) requires qt5base
- Buildroot calls rsync on output/per-package/qt5base/host -> output/per-package/qt5svg/host
- qt5svg now has a bunch of config .pc files that point to output/per-package/qt5base/ instead of output/per-package/qt5svg.

Solution:
Makefile code:
# When per-package is enabled, packages may generate files with absolute paths
# that point to the given sysroot. However, after the rsync step for another
# package that uses those files, per-package isolation is broken because the
# hard-coded paths point to directories outside the per-package sysroot.
# As a pre-configure step, sed all .cmake, .pc, and .pri files in a given
# package sysroot containing the word "per-package" and replace the line with
# the appropriate per-package directory.
ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
define FIXUP_CONFIG_FILES_ABSOLUTE_PATHS
	$(Q)find $(HOST_DIR)/ -name "*.pc" -o -name "*.cmake" -o -name "*.pri" \
		| xargs --no-run-if-empty \
		$(SED) "s:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$(NAME)/:g"
endef
endif
$(2)_PRE_CONFIGURE_HOOKS += FIXUP_CONFIG_FILES_ABSOLUTE_PATHS
A simple sed callout before the packages are configured.

ugh i had to do something like this too when i wrote a layer for qt5 that wasnt available yet quite a few years ago.

# ? Jan 13, 2022 04:12

Tankakern: Jul 25, 2007

And now Linux has a Real-Time Linux Analysis (RTLA) tool!

# ? Jan 18, 2022 07:53

Radia: Jul 14, 2021; And someday, together.. We'll shine.

where the heck could i get started messing around in embedded linux? it feels neat as hell

# ? Jan 18, 2022 08:02

outhole surfer: Mar 18, 2003

Lady Radia posted:

where the heck could i get started messing around in embedded linux? it feels neat as hell

Start with the second half of the first post in the thread -- the bit about buildroot.

Look in configs/ and find a board you own or can buy.

gently caress around with menuconfig.

Find another hobby to kill time while you constantly rebuild your toolchain and/or image.

# ? Jan 18, 2022 23:42

FlapYoJacks: Feb 12, 2009

Lady Radia posted:

where the heck could i get started messing around in embedded linux? it feels neat as hell

Get a Raspberry Pi 4, an sdcard reader, and a Uart cable

Then, choose a SDK. There are two major ones:
- Yocto
- Buildroot

Buildroot tends to be much easier (I am biased) and Yocto has more packages, although the non-core packages are of questionable quality and they range from up-to-date to horribly old.

Buildroot has an IRC channel at irc.oftc.net #buildroot
(Note: Most developers for Buildroot are in UTC+2 time.)

Yocto has an IRC channel at irc.libera.chat #yocto

Go crazy!

# ? Jan 18, 2022 23:45

outhole surfer: Mar 18, 2003

DoomTrainPhD posted:

Get a Raspberry Pi 4, an sdcard reader, and a Uart cable

Then, choose a SDK. There are two major ones:
- Yocto
- Buildroot

Buildroot tends to be much easier (I am biased) and Yocto has more packages, although the non-core packages are of questionable quality and they range from up-to-date to horribly old.

Buildroot has an IRC channel at irc.oftc.net #buildroot
(Note: Most developers for Buildroot are in UTC+2 time.)

Yocto has an IRC channel at irc.libera.chat #yocto

Go crazy!

RPi sits somewhere between obscenely overpriced and unobtainium right now.

Get a ROCKPro64 for something that's affordably obtainable and supports a project worth supporting.

# ? Jan 19, 2022 00:47

FlapYoJacks: Feb 12, 2009

Buildroot just removed Python2 completely. :woop:

# ? Feb 11, 2022 20:23

sb hermit: Dec 13, 2016

DoomTrainPhD posted:

Buildroot just removed Python2 completely.

# ? Feb 11, 2022 21:04

Cybernetic Vermin: Apr 18, 2005

cool cool, long as they don't go and use that as an excuse to add python3

# ? Feb 11, 2022 22:42

FlapYoJacks: Feb 12, 2009

Cybernetic Vermin posted:

cool cool, long as they don't go and use that as an excuse to add python3

Python3 is at 3.10.2 :smug:

# ? Feb 11, 2022 23:09

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

nice! Congrats to you and the BR team.

# ? Feb 12, 2022 16:05

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

The best plang for embedded devices is pbusybox-ash

Python 3 is the second best one

# ? Feb 13, 2022 21:41

FlapYoJacks: Feb 12, 2009

Buildroot 2022.02.1 is out. Python 2 is gone, NodeJS 14 is in, QT5 is now using the KDE repositories and is at the equivalent to 5.15.18. :smug:

Edit:
OpenJDK 11 and 17 are both supported as well.

# ? Apr 20, 2022 17:25

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

Buildroot 2022.02.1 is out. Python 2 is gone, NodeJS 14 is in, QT5 is now using the KDE repositories and is at the equivalent to 5.15.18.

Edit:
OpenJDK 11 and 17 are both supported as well.

Nice! Doomtrain, didn't you do a bunch of the Python2 / NodeJS stuff?

# ? Apr 20, 2022 21:21

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Nice! Doomtrain, didn't you do a bunch of the Python2 / NodeJS stuff?

yes I did. :v:

# ? Apr 21, 2022 01:43

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

yes I did.

Congrats my dude

# ? Apr 21, 2022 05:02

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Congrats my dude

Thanks! It�s nice to see all the Python 2/3 hacks gone as well.

# ? Apr 21, 2022 20:26

FlapYoJacks: Feb 12, 2009

I'm about to submit a version bump for PyQT5 for Buildroot. The current version is 5.7 :stare:

In other news, Buildroot also just merged in a patch series that allows qt5webengine to build against Python 3! It's unfortunate that 2022.02 was released with the package completely broken (due to Python 2 being ripped out.) Better late than never!

# ? May 23, 2022 17:11

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 06:27

FlapYoJacks: Feb 12, 2009

PyQT5 is now at 5.15.6. :woop:

# ? Jun 3, 2022 17:46

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Embedded Linux: It's Linux, but somehow worse

«‹›11 »