Fehler beim Bauen der v2018.1

Sorry für die unklare Formulierung. Genau so meinte ich das auch.
Ich trachte lediglich, die häufig auf solche „Forderungen“ folgende „OSS-Wanker“-Antwort zu vermeiden.

@collimas das Anpassen unserer site.conf und site.mk für 2018.1.x hat bei mir eine halbe Stunde gedauert. Zugegeben, ich verfolge die Entwicklung von gluon eng, habe mich im Wesentlichen aber einfach an die Dokumentation und Vorarbeit von @hexa gehalten.
Wenn irgendwo Verbesserungsbedarf erkannt wird, dann wären konkrete Verbesserungsvorschläge oder gar Lösungsansätze per Issue auf Github sehr hilfreich.

@Handle: Wie Wusel schon schrieb: wenn man nicht ganz eng an der Entwicklung dran ist, geht es eben nicht in 30 Minuten. Die Dokumentation ist natürlich hilfreich, setzt aber einiges an Wissen voraus. Ich wiederhole mich, wenn ich sage, dass eine funktionierende Beispielkonfiguration hilfreich wäre. Und ein Issue aufmachen wegen eines Syntaxfehlers in den Configs ist albern.

Danke, aber ich habe die Fehler nicht dokumentiert, weil ich nach einem Buildversuch abgebrochen hatte.
Jetzt geht es ja mit eigenen Configs.

Der erste erfolgreiche Build ist der Schwierigste :smiley:

Ich hab mich vor circa einem Jahr auch selbstständig ans Bauen gemacht. Ich hatte öfter das Problem, das von beim Download während des Builds irgendwelche Server nicht erreichbar waren. Da hat man dann nach eigenen Fehlern gesucht, wo garkeine waren. Nachdem ich das begriffen hatte, lief es dann meistens nach 2-3 Versuchen.
(Ob das an meinem schlechten Internet zuhause oder an irgendwelchen Servern bzw dem Routing dahin lag, kann ich nicht sagen)

Dafür cache ich die einmal heruntergeladenen Abhänigkeiten zwischen. Bspw. so:

mkdir cache
git clone https://github.com/freifunk-gluon/gluon.git -b v2018.1.x
git clone https://git.darmstadt.ccc.de/ffda/site.git -b v2018.1.x
cd gluon
ln -s ../site
make update
ln -s ../cache lede/dl

Wenn du nun baust landen alle Dependencies im Cache-Ordner, den du beim nächsten Build wieder reinlinken kannst. So stellst du sicher, dass Dinge die du einmal herunterladen konntest nicht in Zukunft Probleme schaffen.

Ich mache das schon eine Weile und veröffentliche diesen Cache auch: https://gluon.darmstadt.freifunk.net/gluon/dependencies/

1 „Gefällt mir“

Overloading ist was im Hintergrund passiert. Das einzige, was das verhindert sind die jeweiligen check_site.lua Scripte der Module. Darin wird festgelegt ob etwas in Domain, Site oder in beidem vorkommen darf. Vorrang hat dann immer die domainspezifische Einstellung.

Ein Beispiel wo es aus meiner Sicht nicht ganz sinnvoll gelöst ist, ist z.B. das authorized-keys Paket. Ich habe durchaus einen Use-Case (hier: eine Domain für Flüchtlingsheime) wo ich gerne per Default Keys von unseren Freiwilligen drin hätte, in der Default Site aber nicht.

1 „Gefällt mir“

Danke für den Einblick; dann verstehe ich es aber noch weniger: hilft es Anfängern wirklich mehr, wenn der Build nach 5-15 Minuten (nicht jeder baut mit 20+ Cores parallel) mit einem Mittelfinger aussteigt, anstatt das – ok, wie man das prominent meldet, wüßte ich auch gerade nicht – einfach eine Warnung kommt, „timezone in domains/lon.conf overwrites timezone in site.conf“? Wie gesagt, ggf. wurde das ja schon diskuiert, und mein Kontakt mit Gluon-Neu-Bauern ist homöopathisch …

Ack. Auch site_name und site_code hätte ich schon gerne in den spezifischeren Dateien gesetzt; wir bauen derzeit für den Kreis Gütersloh sowie die Müritz-Region. Statt früher mit getrennten Werten tauchen v2018.1-basierte Knoten nun auf den getrennten Karten als „Site 4830“ auf. Es sieht so aus, als ob der Wert aus domain_names leider site_name und site_code nicht überschreibt/-lagert an allen Stellen, wo site_code/site_name Verwendung findet :frowning:
Ja, I have the code to fix it, und ich werde es wohl auch tun (müssen, denn so geht das bei unserem Setup einfach nicht), und keine Software ist in der ersten Version perfekt, auch Haken dran. Aber die Probleme gäbe ohne diese „Du, Du, Du, das darfst Du nicht! (Weil, wir sehen da keinen Sinn drin.)“-Checks gar nicht, das ärgert mich ein wenig. Was soll das, warum die Gängelung? :frowning:

Ich scheitere leider auch am bauen. Ich erhalte folgende Fehlermeldung.

make[1]: Entering directory '/home/kevin/ffpi/code/gluon/lede'
make[2]: Entering directory '/home/kevin/ffpi/code/gluon/lede'
make[2]: Leaving directory '/home/kevin/ffpi/code/gluon/lede'
#
# configuration written to .config
#
make[1]: Leaving directory '/home/kevin/ffpi/code/gluon/lede'
Configuration failed:
 * unable to enable package 'gluon-luci-admin'
 * unable to enable package 'gluon-luci-autoupdater'
 * unable to enable package 'gluon-luci-portconfig'
 * unable to enable package 'gluon-luci-wifi-config'
 * unable to enable package 'gluon-luci-private-wifi'
 * unable to enable package 'gluon-luci-node-role'
 * unable to enable package 'gluon-next-node'
Makefile:124: recipe for target 'config' failed
make: *** [config] Error 1

Soweit ich das verstanden habe, habe ich an der site.conf alle nötigen Anpassungen vorgenommen, aber vermutlich hängt da doch noch irgendwo ein Fehler. Hier mein commit mit den Änderungen WIP: 2018.1 config · freifunk-pinneberg/firmware@ab14db3 · GitHub

hast du evtl. die Änderungen an der site.mk vergessen zu machen?
Die Pakete, die dort in der Fehlermeldung stehen, haben nämlich alle entweder einen neuen Namen oder existieren nicht mehr. Die Doku & Release notes nennen das auch.

1 „Gefällt mir“

an der site.mk habe ich nichts geändert. Wo finde ich denn die Info was da geändert werden muss? Hier in der Doku steht jedenfalls nichts darüber. Gluon 2018.1 — Gluon 2021.1 documentation

Der Wechsel zu gluon-web ist schon älter als die 2018.1. Seltsam, dass es bisher noch so funktioniert hat…

Hier findest du eine Gegenüberstellung der alten und der neuen Paketnamen:

Das bedeutet, du musst deine Pakete mit den neuen ersetzen:

gluon-luci-admin → gluon-web-admin
gluon-luci-autoupdater → gluon-web-autoupdater
gluon-luci-portconfig → gluon-web-network
gluon-luci-wifi-config → gluon-web-wifi-config
gluon-luci-private-wifi → gluon-web-private-wifi
gluon-luci-node-role → gluon-web-node-role
gluon-next-node → ist mittlerweile in gluon-core enthalten, der Eintrag ‚gluon-next-node‘ muss also aus der site.conf entfernt werden.

2 „Gefällt mir“

Etwas weiter bin ich dank der Paketnamen von @collimas schon gekommen. Nun scheint er an einer anderen Stelle zu hängen.

make[4]: Leaving directory '/home/kevin/ffpi/code/gluon/lede/build_dir/hostpkg/lua-5.1.5'
mkdir -p /home/kevin/ffpi/code/gluon/lede/staging_dir/hostpkg/stamp
touch /home/kevin/ffpi/code/gluon/lede/build_dir/hostpkg/lua-5.1.5/.built
touch /home/kevin/ffpi/code/gluon/lede/staging_dir/hostpkg/stamp/.lua_installed
make[3]: Leaving directory '/home/kevin/ffpi/code/gluon/lede/package/utils/lua'
make[2]: Leaving directory '/home/kevin/ffpi/code/gluon/lede'
make[1]: Leaving directory '/home/kevin/ffpi/code/gluon/lede'
lede/staging_dir/hostpkg/bin/lua: scripts/site_config.lua:10: [string "site.conf"]:6: '}' expected (to close '{' at line 1) near 'opkg'
stack traceback:
        [C]: in function 'assert'
        scripts/site_config.lua:10: in main chunk
        [C]: ?
Your site configuration (site.conf) did not pass validation.
Makefile:148: recipe for target 'all' failed
make: *** [all] Error 1

scripts/site_config.lua sieht wie folgt aus, und wurde von mir nicht angefasst. Zeile 10 ist die letzte.

local site = os.getenv('GLUON_SITEDIR') .. '/'
local config = os.getenv('GLUON_SITE_CONFIG')

local function loader()
   coroutine.yield('return ')
   coroutine.yield(io.open(site..config):read('*a'))
end

-- setfenv doesn't work with Lua 5.2 anymore, but we're using 5.1
return setfenv(assert(load(coroutine.wrap(loader), config)), {})()

Edit: Fehler gefunden, ich hatte in meiner site.conf an manchen stellen ein komma hinter den klammern vergessen.

vielleicht hattest du deine site davor noch nicht für v2017.1.x angepasst?
Es müssen immer alle Release Notes gelesen werden, also sind die Release Notes von v2017.1 bis v2017.1.8 auch relevant, wenn man diese nie gebaut hat.

Der Fehler hier liegt meines Erachtens darin, einen neuen Thread aufzumachen statt einfach mal die folgenden beiden Threads abzuarbeiten.

Was die derzeitige Diskussion hier anbelangt: Das ist unproduktives Fingerpointing.

  • „Du hast nicht alle Releasenotes und alle Commit-Kommentare nachvollzogen“
    vs
  • „Da fehlt die durchaus relevante Information xy“

und

1 „Gefällt mir“

kann weg.