mirror of
https://github.com/openglow-org/forgefirm.git
synced 2026-09-28 09:11:11 -07:00
ScottW514
64301d3221
ForgeFIRM's own files live under /data/forgefirm; two configuration files did not. The machine settings sat at /data/forgefirm.conf, in the root of /data beside the factory's own files, and the cloud-mode configuration sat at /data/etc/gfhome.conf, inside a directory the factory owns. Both move: /data/forgefirm.conf -> /data/forgefirm/forgefirm.conf /data/etc/gfhome.conf -> /data/forgefirm/gfhome.conf There is no migration: only the bench has ever run this firmware. /data/etc now holds only the factory's wpa_supplicant.conf. The acceptance check of the file modes reads the settings file at its new path, and the two bench tools that read it directly follow. The pins move to the revisions that carry the change, forgectrl also bringing the fix that reads the module's disabled state as idle: forgectrl 468ee21 (0.1.12) grblhal-glowforge 9ee624b (0.1.10) forgefirm-app 56f134a (0.1.28+git) The lock moves meta-openglow to b7ad6d9, which pins python3-gfhardware on the same revision. The four upstream layers stay where they were: `kas lock --update` moves every floating repository, and a release is not the place to take poky, meta-openembedded and meta-freescale along for the ride.
13 lines
660 B
PHP
13 lines
660 B
PHP
# forgefirm-app pin (python3-gfhardware repository, forgefirm-app/ tree).
|
|
# Bump deliberately (AUTOREV is not reproducible); keep only SRCREV and PV
|
|
# here - the image manifest leaves *-pin.inc out of the layer content hash
|
|
# because the component entry already identifies the pinned source
|
|
# (forgefirm-image-manifest.bbclass). The python3-gfhardware recipe in
|
|
# meta-glowforge-bsp pins the same repository; move both together.
|
|
SRCREV = "56f134a1e6393a2096c16e8226027fbbd38d79c7"
|
|
|
|
# Bump PV with every SRCREV move: the hash-derived package version is not
|
|
# monotonic on its own and buildhistory QA fails the build when it sorts
|
|
# backwards.
|
|
PV = "0.1.28+git"
|